How Clients Locate Domain Controllers

When a computer attempts to locate a domain controller, a process called the domain controller locator (Locator) is initiated so the appropriate Active Directory domain controller can be located. Locator uses information that is stored in Active Directory and DNS to attempt to find a domain controller with the desired roles and that is located in a site closest to the client.

The Locator uses information that is defined in the Configuration container in the forest root domain, which is replicated to every domain controller in the forest. Site objects, subnet objects, and domain controller server objects are all imperative for the Locator to find the closest domain controller for a client computer. Site objects are used to represent Active Directory sites. Subnet objects are used to represent IP address segments and are associated with the appropriate site object. Domain controller server objects are used to represent domain controllers and are associated with a site object.

Active Directory domain controllers register DNS records that specify the site in which the DC resides. The number of DNS records that each domain controller registers depends on the roles the DC has. For example, a DC that is a Global Catalog server will register an additional DNS record that advertises itself as such. Similarly, a domain controller that holds an Operations Master role will register a DNS record that advertises itself as this.

The process for a client computer to locate a domain controller is as follows:

1. The Locator is initiated on the client computer as a remote procedure call (RPC) to the local 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.

3. The Net Logon service on the client computer uses the collected information to build a query to send to DNS to identify the appropriate domain controller.

4. The Net Logon service on the client computer sends a datagram to the discovered domain controllers.

5. The directory service intercepts the query and passes it to the Net Logon service on the domain controller.

6. The Net Logon service on the domain controller looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information to the client: the name of the site in which the client is located, or the site that most closely matches the client IP address; the name of the site in which the current domain controller is located; and a bit that indicates whether the found DC is located in the site closest to the client.

7. The client inspects the information to determine whether it should try to find a better domain controller. The decision is made as follows: If the returned domain controller is in the closest site, the client uses this domain controller; If the client has found a DC in the site in which the DC claims the client is located, the client uses this domain controller; If the DC is not in the closest site, the client updates its site information and sends a new DNS query to find a new DC in the site. If the second query is successful, the new DC is used. If the second query fails, the original DC is used.

8. If the domain that is being queried by the client is the same as the domain to which the computer is joined, the site in which the computer resides is stored in the registry on the client computer.

9. After the client locates a DC, 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.

In the case where a client computer uses an IP address that is not represented in the subnet-to-site mapping table, the DC returns a NULL site name and the client uses the returned domain controller, which may reside in any Active Directory site.

To find out which domain controller your PC is talking which is handy for trouble shooting purposes visit this blog post:

http://clintboessen.blogspot.com/2010/05/how-to-find-out-which-domain-controller.html

Please note that the contents of this blog post was written by John Policelli as part of the article "Using Catch-All Subnets in Active Directory". John Policelli reserves all rights to the content posted above. Please view the original article posted here:

http://technet.microsoft.com/en-us/magazine/2009.06.subnets.aspx