When an application requests access to Active Directory, a domain controller is located by a mechanism called the Domain Controller Locator.
The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.
Then, the servers on the list are queried to test if they are alive.
The client is initialized with DomainName.FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example mockup1.contoso.com
The general process is shown in the following diagram:
The first step is to perform the DNS discovery.
The client issues a DNS request for _ldap._tcp.dc._msdcs.mockup1.contoso. com
The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
The DNS exchange is done as specified in the DNS protocols (RFC 1769 and related RFCs).
If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order (see RFC2052).
The client then resolves the SRV record to an address, again as specified in the DNS protocols.
Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain controller is in fact handling requests and determining the characteristics of this domain controller. The LDAP “Ping” also known as connectionless LDAP is sent over UDP
After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.
When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.
The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”
The domain controller server inspects the query and returns the NetLogon result.
The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.
Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.
If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.
Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.
These sorts of negative results are cached by the client; however, they are purged promptly (on the order of minutes).
Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.
If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.
Upon successful response from the domain controller, the location portion completes.
The DomainController element is set to the name and address of the domain controller that was selected.