Authentication Topology

You're designing a new Windows 2000 Active Directory (AD) deployment for a network with more than 10,000 users and more than 300 servers in 30 physical locations, connected with occasionally overcommitted T1 lines. What's your biggest headache? If you're like most AD designers, replication is what wakes you up at 3:00 a.m. and keeps your mind spinning long after your eighth cup of coffee at 10:00 a.m. But as important as your replication topology is, it probably isn't what you should be paying the most attention to. During typical operations, replication accounts for relatively little of the network traffic that AD generates, and an end-to-end replication latency of even a few hours won't cause users any real heartburn. But if you let even one user's AD authentication time grow to more than 20 seconds or so, you can bet that your Help desk phone will be ringing off the hook. When you understand how AD clients locate a domain controller (DC) to which to authenticate, you can configure your clients and DCs to shave time off authentication and improve overall performance.

Locating a DC
When a DC boots, and periodically while it's running, the DC's Netlogon service uses the dynamic DNS (DDNS) protocol to publish DNS SRV records (see the sidebar "DNS SRV Records," page 62, for more information about the format of these records). These SRV records describe the types of services that the DC provides—for example, Kerberos authentication, Lightweight Directory Access Protocol (LDAP)—based directory access, and AD Global Catalog (GC) lookups. AD DCs organize SRV records hierarchically so that clients can find the DCs that provide a specific service within a domain or within a particular site and domain.

Figure 1, page 62, shows the DNS naming hierarchy that DCs use to publish their SRV records. You've certainly seen this structure in your Win2K DNS. The structure lets clients locate services even when the clients don't have full knowledge of a service's characteristics. For example, to find any GC in the forest, the client need only specify the forest name and the protocol for which to search (i.e., search the forestname._tcp domain for _gc SRV records). This type of search would return SRV records for all the GC servers in the specified forest. If the client knows a specific AD site name, it can search the forestname._sites.sitename._tcp domain for _gc SRV records. This type of search will return the GCs in the specified site.

Publishing these SRV records in DNS helps clients find the DCs that can most efficiently handle their requests. When a client computer authenticates to a domain, the computer must first locate and authenticate with a DC in its domain. To get the best possible performance, the client computer needs to select a DC in its AD site.

The client's Netlogon process handles the client's end of the authentication process, and Netlogon's DC Locator component is responsible for finding a DC with which to authenticate. In earlier versions of Windows, the client's DC Locator uses WINS to locate a DC. However, Win2K machines and other AD-enabled clients search for the appropriate DNS SRV records.

The first time a workstation authenticates to its domain, the workstation doesn't know which site it's part of, so its first task is to find any DC in the domain. The workstation issues a DNS query for _ldap SRV records in the _tcp.dcs._msdcs.domainname domain. The client queries the primary DNS service specified in its TCP/IP configuration. If the client gets no response from this DNS service, the client fails over to the subsequent DNS services that the TCP/IP configuration specifies.

The DNS service responds with a list of SRV records that correspond to all the DCs in the client's domain. The client takes the records with the lowest-priority value and issues an AD ping (which is actually an LDAP-over-UDP query) to each DC in turn. If a DC doesn't respond within a tenth of a second, the client tries the next DC, and so on, until a DC responds.

When a DC receives an AD ping from a client, the DC calculates two crucial pieces of information before sending a response. First, the DC determines the site closest to the client; to do so, the DC compares the IP address in the request packet with an in-memory data structure that contains the site and subnet associations defined in AD's site objects. The DC also determines whether it's in the site closest (from an IP topology point of view) to the client's site. The DC sends this information and the name of the responding DC's site in a UDP response to the client.

When the client receives this response, it determines whether the responding DC is in the site closest to its site. If so, the client saves the returned client site name in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry subkey's DynamicSiteName entry and uses that DC for further domain-authentication requests. If the DC response indicates that the DC isn't in the site closest to the client's site, the client returns to DNS to find a DC in the closest site. This time, because the client knows its site name, it queries DNS for _ldap SRV records in the _tcp.sitename.sites.dc._msdcs.domainname domain. DNS responds with a list of SRV records for DCs in the specified site. The client again selects those SRV records with the lowest priority and issues AD pings to each in turn until one responds within a tenth of a second.