We provide the How To details of the process of locating a domain by its DNS-style name vs the its flat-style (NetBIOS) name.
We also have some details on Getting information on Domain Controllers.
The Sequence #This sequence describes how the Locator finds a domain controller: On the client (the computer that is locating the domain controller), the Locator is initiated as an remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.
The client collects the information that is needed to select a Domain Controller and passes the information to the Netlogon service by using the DsGetDcName call.
For a Domain Name System (DNS) name, Netlogon service 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 it appends the domain name to the appropriate string that specifies the SRV records.
A workstation that is logging on to a Windows-based domain queries DNS SRV Records in the general form:
Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server (ie Domain Controller) by querying DNS SRV Records for a record of the form:
The Netlogon 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 a consistent view of Active Directory.
When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client's own subnet. Therefore, clients find a Domain Controller by querying DNS for a record of the form: _LDAP._TCP.dc._msdcs.domainname
After the client locates a domain controller, it establishes communication by using LDAP to gain access to Microsoft Active Directory.
After the client locates a domain controller, the Domain Controller entry is cached.
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-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. 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 Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).Domain Controller identifies which Active Directory 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 closet (most optimal) site, the domain controller returns the name of the client's 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 is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.
NOTE: A client does not know and does not determine which site is to be used. The Active Directory Site information is provided by the Domain Controller and the client writes the information to the client's registry for future reference.
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 Active Directory Site as the client.