Process of locating Domain Controller

Following article describes the mechanism that Windows XP Professional uses to locate a domain controller in a Windows-based domain. Understanding the workstation logon process makes easier for future troubleshooting issues. Some of the key services in windows need to be understood clearly. Netlogon service is one of them.

• On the client (the computer that is trying to locate the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Netlogon service implements the Locator DsGetDcName API call.
  
• The client collects the information that is needed to select a domain controller, and then passes the information to the Netlogon service by using the DsGetDcName call.
  

The Netlogon 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, Netlogon queries DNS by using the IP/DNS-compatible Locator--that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and "A" records from DNS after the domain name is appended to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in this general form

_service._protocol.DnsDomainName

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

• The Netlogon service sends a datagram to 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 that UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.
  

Each available domain controller responds to the datagram to indicate that it is working and returns the information to DsGetDcName.

The Netlogon service caches the domain controller information so that subsequent requests do not need to repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

_LDAP._TCP.dc._msdcs.domainname

 

After the client locates a domain controller, the client establishes communication by using Lightweight Directory Access Protocol (LDAP) to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in, based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain

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 own subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again by using the name of the optimal site. The domain controller uses some of the directory service information for identifying sites and subnets.

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 15 minutes and discards the cache entry. The client then attempts to find an optimal domain controller in its own site.

After the client has established a communications path to the domain controller, the client can establish its logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform 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 uses Security Accounts Manager (SAM). Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through SAM to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Best

Oz Ozugurlu