Authentication Topology

SRV weight. RFC 2782 also provides a load-balancing mechanism of sorts. An SRV record's weight field is an integer that defines which SRV records the client should prefer in its selection process. Although the client randomly selects an SRV record from a set of records with the same priority, the probability that the client will select a particular SRV record is proportional to the weight associated with that record.

To define the weight that the DC will publish with its SRV records, set the DC's HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's LdapSrvWeight entry to a value from 0 to 100. By default, DCs use the value 100, indicating that the likelihood that a client will select that DC is 100 percent.

Suppose you have 5000 clients and two DCs in a site. DC1 is a dual-processor 1.6GHz Pentium 4 Xeon box with 1GB of RAM, and DC2 is a single-processor 800MHz Pentium with 256MB of RAM. Without any manual registry configuration, approximately half the clients will attempt to authenticate with DC1 and the other half will attempt to authenticate with DC2. As you can imagine, DC2 will be severely overloaded. However, if you set the weight on DC1 to 80 and the weight on DC2 to 20, clients will prefer the dual-processor box to the single-processor box by a factor of 4-to-1, as Figure 5 shows.

Configuring the Publication of Generic SRV Records
When a client can't find a DC through site-specific SRV records, it will search generic SRV records. This behavior can create some undesirable results. Consider a hub-and-spoke scenario in which the hub site and each satellite site contain a DC. If a client in a satellite site fails to contact its local DC, the client will search DNS for generic SRV records for a DC in its domain. Because all DCs publish generic records by default, the client might select a DC from anywhere in the network, including another remote satellite site—something you almost certainly don't want to happen.

AD provides a way to disable the publication of individual SRV records so that you can make a DC invisible to clients in other sites or even the DC's own site. This ability gives you great control over which DCs clients will use to authenticate. To control the SRV records that a DC publishes, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's DnsAvoidRegisterRecords value to a list of mnemonics (separated by spaces) that correspond to the SRV record you want to inhibit. Table 1 shows the available mnemonics and corresponding SRV records.

Consider our hub-and-spoke example: a simple network with a hub in Denver and satellite offices in Scottsdale, San Antonio, and Albuquerque, New Mexico. By default, a client in Scottsdale (i.e., WSSC1) will select the Scottsdale DC (i.e., DCSC1) for authentication. But suppose DCSC1 is down. Ideally, we'd like WSSC1 to fail over to a DC in the Denver hub site. But by default, WSSC1 will simply search the network's generic SRV records, with a good chance of selecting a DC in one of the other satellite sites (i.e., DCSA1 or DCAL1). The solution is to make the DCs in the satellite sites invisible to clients outside each site. In this example, you would disable the publication of all generic records for the DCs in the satellite sites so that clients from other sites won't select them. Specifically, for DCSC1, DCSA1, and DCAL1, set the DnsAvoidRegisterRecords value to include the following mnemonics: Dc, DcByGuid, Gc, GcIpAddress, GenericGc, Kdc, Ldap, LdapIpAddress, Rfc1510Kdc, Rfc1510Kpwd, Rfc1510UdpKdc, and Rfc1510UdpKpwd.

Here's another interesting scenario: Suppose you want to dedicate a DC at some central site for hot backup purposes only. You want the DC to sit there, replicating with the other DCs in the domain, but doing nothing else. In fact, you want to make the DC invisible both inside and outside its site. To do so, set all the mnemonics except DcByGuid, which controls publication of the SRV record that other DCs use to find replication partners.

Speeding Things Up
When you understand how the DC Locator mechanism works, how it depends completely on DCs' SRV records, and how you can control the way in which DCs publish those records, you can optimize your authentication topology to provide the fastest possible logons and directory lookups for your users. Your users—and your Help desk personnel—will thank you.