In Windows 2000 and 2003, the DC Locator process locates domain controllers (DCs) to perform certain functions for various client and application purposes. This process searches DNS Service Locator (SRV) records, registered by each DC for such purposes as finding an LDAP server, Kerberos server, Global Catalog Server and PDC Emulator. There are, however, legitimate reasons to prevent the registration of certain SRV records for certain DCs. This would force requests such as authentication requests to avoid certain DCs, or looking at it another way, it would force authentication to only go to certain DCs for bandwidth restrictions or performance reasons.
For instance, in a previous article, I described the use of the "lag site" to facilitate immediate "online" recovery of mistakenly deleted objects. In this method, two DCs per domain are placed in a separate site (with no other DCs) and replication is scheduled to happen only once or twice a week, depending on your recovery strategy. Thus, if you mistakenly delete an OU with 10,000 users, you can go to one of the lag site DCs that have not replicated that deletion, and perform an authoritative restore to recover the deleted objects. This eliminates the time and hassle of restoring from backup.
I noted briefly in my previous article that in this strategy you must prevent the lag site DCs from authenticating users, since they will potentially contain old password and account information and could cause user authentication failures. Thus, we want to prevent these DCs from authenticating users.
To accomplish this, you can use a group policy setting, "DC Locator DNS Records Not Registered by the DCs." This setting permits you to specify which DNS records a DC will not register. Of course an important part of the overall strategy is to make sure this policy only applies to the DCs of choice. You don't want to define a policy to prevent registration of SRV records required for authentication, and have it apply to all DCs, or you will have a lot of very unhappy users.
CAUTION: It is very important to note that implementing this policy can have disastrous effects on your AD environment. Be certain to thoroughly test implementing this policy before introducing it into your production domain.
The step by step process to prevent DNS registration of SRV records is as follows:
Figure 1:
Note: It is important to note that this action is not without consequences. Please be aware of the following caveats:
- If you are doing this to implement a lag site for disaster recovery, you should put the Lag DCs into a separate site and implement this as a Site Policy.
- You will need to create multiple policies if you want to prevent some DCs from registering Kerberos records and other DCs from registering LDAP records.
- Please be sure to test this thoroughly before putting it in production. The example described here works well for preventing authentication by lag site DCs. If you want to use this method to restrict SRV record registration for other purposes, you must test it to make sure you get the desired results before putting into production.
For a thorough description of how to implement this policy for the use of lag sites in Active Directory disaster recovery, see my book,
Windows Server 2003 on ProLiant Servers(pages 872-873).
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.