Problem solve Get help with specific problems with your technologies, process and projects.

Preventing DNS registration of certain SRV records

If you have performance issues or bandwidth restrictions, you can force authentication requests to only go to certain domain controllers by preventing DNS registration of certain Service Locator (SRV) records.

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:

  • Create a specific OU. Create a child OU off of the Domain Controllers OU and put the DCs that are to not register certain SRV records into this new OU.
  • Create a separate group policy called "Restrict Authentication" (example) for that OU:
    a. Go to Computer Settings → Administrative Templates → System → NetLogon → DC Locator DNS records.
    b. Select "DC Locator DNS Records not registered by the DCs" setting, and click the enable radio button. These settings allow you to specify which SRV records are not registered by the NetLogon service as shown in Figure 1 below.
    c. To make this work you have to list the records that will NOT be registered, in the Mnemonics field. A description of all the records is shown in the Explain tab. Note that in Figure 1, you enter each SRV record to restrict, in the Mnemonics field. These records are separated by spaces.
  • Example: To restrict a DC from authenticating clients if you are implementing a Lag Site DC, you will need to restrict all SRV records except CNAME and Host records. These need to be entered in the Mnemonics field, separated by spaces as shown here:
    Ldap LdapAtSite Pdc Gc GcAtSite GcIpAddress DcByGuid Kdc KdcAtSite Dc DcAtSite 
    Rfc1510Kdc Rfc1510KdcAtSite GenericGc GenericGcAtSite Rfc1510UdpKdc
    Rfc1510Kpwd Rfc1510UdpKpwd.

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.

Dig Deeper on Windows systems and network management