Alexander’s Blog

In Windows Server 2003 Active Directory domains, there is a concept of immediate and urgent replication. Certain types of information gets replicated immediately, rather than waiting for the standard Active Directory replication. One such example is user account lockout. If an administrator locks a user account, the information is replicated to the PDC emulator immediately. Microsoft recommends that you define account lockout and password policies in only one Group Policy object (GPO) for every domain (in the Default Domain policy settings).

Microsoft explains the concepts of immediate and urgent replications in this TechNet article:

Account lockout relies on the replication of lockout information between domain controllers to ensure that all domain controllers are notified of an accounts status. In addition, password changes must be communicated to all domain controllers to ensure that a user’s new password is not considered incorrect. This data replication is accomplished by the various replication features of Active Directory and is also discussed in this section.

Immediate Replication
When you change a password, it is sent over Netlogon’s secure channel to the PDC operations master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC operations master that includes the user name and new password information. The PDC operations master then locally stores this value.

Immediate replication between Windows 2000 domain controllers is caused by the following events:
- Lockout of an account
- Modification of a Local Security Authority (LSA) secret
- State changes of the Relative ID (RID) Manager

Urgent Replication
Active Directory replication occurs between domain controllers when directory data is updated on one domain controller and that update is replicated to all other domain controllers. When a change in directory data occurs, the source domain controller sends out a notice that its directory store now contains updated data. The domain controller’s replication partners then send a request to the source domain controller to receive those updates. Typically, the source domain controller sends out a change notification after a delay. This delay is governed by a notification delay. (The Windows 2000 default notification delay is 5 minutes; the Windows Server 2003 default notification delay is 15 minutes.) However, any delay in replication can result in a security risk for certain types of changes. Urgent replication ensures that critical directory changes are immediately replicated, including account lockouts, changes in the account lockout policy, changes in the domain password policy, and changes to the password on a domain controller account. With urgent replication, an update notification is sent out immediately, regardless of the notification delay. This design allows other domain controllers to immediately request and receive the critical updates. Note, however, that the only difference between urgent replication and typical replication is the lack of a delay before the transmission of the change notification. If this does not occur, urgent replication is identical to standard replication. When replication partners request and subsequently receive the urgent changes, they receive, in addition, all pending directory updates from the source domain controller, and not only the urgent updates.

When either an administrator or a delegated user unlocks an account, manually sets password expiration on a user account by clicking User Must Change Password At Next Logon, or resets the password on an account, the modified attributes are immediately replicated to the PDC emulator operations master, and then they are urgently replicated to other domain controllers that are in the same site as the PDC emulator. By default, urgent replication does not occur across site boundaries. Because of this, administrators should make manual password changes and account resets on a domain controller that is in that user’s site.

The following events are not urgent replications in Windows 2000 domains:
- Changing the account lockout policy
- Changing the domain password policy
- Changing the password on a computer account
- Domain trust passwords

According to reports, some Microsoft Windows computers are experiencing a “Black Screen of Death.” The phrase Black Screen of Death came out of the famous “Blue Screen of Death”, which caused system crash on earlier Windows operating systems. According to MSNBC:

The problem may be tied to security updates recently released by the software maker. “Microsoft is investigating reports that its latest release of security updates is resulting in system issues for some customers,” the company said in a statement. “Once we complete our investigation, we will provide detailed guidance on how to prevent or address these issues.”

British security firm Prevx writes about the problem on its blog, and suggests following this procedure:

1. Restart your PC
2. Log on and wait for the black screen to appear
3. Make sure your PC should be able to connect to the Internet (black screen does not appear to affect this)
4. Press the CTRL, ALT and DEL keys simultaneously
5. When prompted, Click Start Task Manager
6. In Task Manager Click on the Application Tab
7. Next Click New Task
8. Now enter the command:
“C:\Program Files\Internet Explorer\iexplore.exe” “http://info.prevx.com/download.asp?GRAB=BLACKSCREENFIX”
9.  Click OK and your (Web) browser should start up and begin the download process
10.  When prompted for the download Click run, the black screen fix program will download and run to automatically fix the issue.
11.  Now restart your PC and the black screen problem will hopefully be gone.

“There appears to be many causes of the black screen issue,” wrote Dave Kennerley of Prevx Support on the company’s blog. “The symptoms are very distinctive and troublesome. After starting your Windows 7, Vista, XP, NT, W2K, W2K3 or W2K8 PC or server the system appears normal.

“However, after logging on there is no desktop, task bar, system tray or side bar. Instead you are left with a totally black screen and a single My Computer Explorer window. Even this window might be minimized making it hard to see.”

The reason that the KRBTGT account is disabled in Windows 2000/2003 Server is that there is no reason or need for someone to be logging in with the KRBTGT domain account. Therefore, it cannot be enabled. Because it is a built-in account, you cannot enable or rename KRBTGT account. If  you try to rename the account you will get the error:

One of the names could not be changed due to the following problem:
Cannot perform this operation on built-in accounts.
Please try again.

If you try to enable the account you will get the error:

Krbtgt could not be enabled due to the following problem:
Cannot perform this operation on built-in accounts.

Kerberos is the default authentication protocol in Windows 2000/2003. The KRBTGT account is used for Kerberos Ticket Granting Ticket (TGT). TGT  is a ticket that must be presented to the Kerberos service when a session request is made. The TGT is enciphered with a key that is derived from the password of the KRBTGT account, which is known only to the Kerberos service. As administrators we don’t need to mess with this account.

Group nesting and membership can get confusing, especially when you are dealing with multiple domains and different types of groups in Windows Server 2000/2003/2008. I have created a table (color-coded to make it more readable) that you may find helpful whether you are designing or troubleshooting group membership, or preparing to take a Microsoft exam.

Here’s how you can read this table. Keep in mind that I have tried to cover both the bases by listing: “Can contain from” and “Can be a member of.” I will use Global Group as an example.

- A Global Group can contain User Accounts from the same domain.

- A Global Group can be a member of Local Groups in the same domain as well as Local Groups in the other domains.

- A Global Group can contain a Global Group from the same domain and a Global Group can be a member of a Global Group in the same domain.

Here are some Excel spreadsheets offered by Microsoft that contain the Group Policy settings.

Group Policy Settings Reference  – Windows Server 2003

This spreadsheet lists Group Policy settings described in Administrative Template (.adm) files and Security Settings that shipped with Windows Server 2003 Service Pack 1. This includes all Administrative Template policy settings supported on the following operating systems: Microsoft Windows Server 2003, Windows XP Professional with SP2 or earlier service packs, and Microsoft Windows 2000 with Service Pack 4 or earlier service packs. In addition, this spreadsheet includes the following categories of security policy settings: Account Policies (Password Policy, Account Lockout Policy, and Kerberos Policy), Local Policies (Audit Policy, User Rights Assignment, and Security Options), Event Log, Restricted Groups, System Services, Registry, and File System policy settings. Note: This does not include security settings that exist outside of the Security Settings extension (scecli.dll), such as Wireless Network extension, Public Key Policies, or Software Restriction Policies.

The spreadsheet includes separate worksheets for each of the .adm files and the security policy settings that shipped in Windows XP SP2 , a consolidated worksheet for easy searching, and an Update History worksheet that lists policy settings that have been added since the Windows Server 2003 operating systems were released. Using column filters, you can easily filter the information in the spreadsheet by operating system, component, or machine/user configuration. You can also search for information by using text or keywords.

System Requirements:

- Supported Operating Systems: Windows 2000; Windows Server 2003; Windows XP
- Excel 2000 and later

Click here to download this reference.

Group Policy Settings Reference  – Windows Vista

System Requirements:

Group Policy Settings Reference – Windows Server 2008 and Windows Vista SP1