Domain Controller Locator

When an application requests access to Active Directory, an Active Directory server (domain controller) is located by a mechanism called the domain controller locator (Locator). Locator is an algorithm that runs in the context of the Net Logon service. Locator can find domain controllers by using DNS names (for IP or DNS-compatible computers) or by using Network Basic Input/Output System (NetBIOS) names (for computers that are running Microsoft® Windows® 3.x, Microsoft® Windows® for Workgroups, Microsoft® Windows NT® version 3.5 or later, Windows 95, or Windows 98), or it can be used on a network where IP transport is not available.

The following sequence describes how the Locator is able to find a domain controller:

1. On the client (the computer locating the domain controller), the Locator is initiated as an RPC to the local Net Logon service. The Locator application programming interface (API) (DsGetDcName) is implemented by the Net Logon service.
2. The client collects the information that is needed to select a domain controller and passes the information to the Net Logon service by using the DsGetDcName API.
3. The Net Logon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:
   • For a DNS name, Net Logon queries DNS by using the IP/DNS-compatible Locator — that is, DsGetDcName calls the DnsQuery API to read the Service Resource (SRV) records and A records from DNS, after it appends an appropriate string to the front of the domain name that specifies the SRV record.

   A workstation that is logging on to a Windows 2000 domain queries DNS for SRV records in the general form:

   _service._protocol.DnsDomainName

   Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:

   _ldap._tcp.DnsDomainName

   • For a NetBIOS name, Net Logon performs domain controller discovery by using the Microsoft® Windows NT® version 4.0–compatible Locator, that is, by using the transport-specific mechanism (for example, WINS).



Note

In Windows NT 4.0 and earlier, "discovery" is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

4. The Net Logon service sends a datagram to (that is, pings) the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)



Note

UDP allows an application on one computer to send a datagram to an application on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (applications) on the remote computer.

5. Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
6. The Net Logon service returns the information to the client from the domain controller that responds first.
7. The Net Logon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and, thus, a consistent view of Active Directory.

Note

The debug log for the Net Logon service can be enabled by carrying out nltest\dbflag:0x2000ffff at the command prompt. Restart the computer, and then review entries in the [INIT] category of the Net Logon.log file that is located in the %systemroot%\Debug folder. Net Logon still uses the event log to notify administrators of "well known" problems that might occur, and it is recommended that you look in this place first.

In general to enable logging, it is not necessary to restart the computer. Setting the dbflag automatically enables logging. The restart is for purposes of viewing the [INIT] category of the Net Logon.log file.

Figure 10.1 illustrates the process of a client locating a domain controller.

Enlarge figure

Figure 10.1 Domain Controller Locator Process

Note

The locator can also be called by using a NetBIOS domain name, in which case it flows down to the Windows NT 4.0–compatible locator.

When a client logs on or joins to the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers in the subnet of the client. Therefore, DNS finds the closest domain controller in its subnet.

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in on the basis of the IP subnet of that client. If the client is communicating with a direct domain controller that is not in the closest (most optimal) site, it then receives the name of the site in which the client is located with a bit that indicates whether the current domain controller is in the closest site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client's subnet), the client uses the domain controller that isn't optimal. Otherwise, the client again does a site-specific DNS lookup with the new optimal site name. The domain controller uses some of the DSA information for identifying sites and subnets.

Note

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes, and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows 2000 platforms, set up a secure channel. Then the client is ready to perform the normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process goes through the Security Accounts Manager. As the communications path goes through the LDAP interface and the client is authenticated through the DSA, the client account is verified and passed through the Security Accounts Manager to the DSA, the database layer, and, finally, to the database in the ESE. Therefore, there are a number of different component interactions. To effectively troubleshoot your system, you must be able to identify and diagnose problems that might occur in any of these different interactions.

For more information about Locator, see "Name Resolution in Active Directory" in this book.

© 1985-2000 Microsoft Corporation. All rights reserved.