How to locate the domain controller in Windows

This article describes how Windows can locate domain controllers in Windows domains. This article describes how to locate a domain by using the domain's DNS-style name and flat-style (NetBIOS) Name. The flat-style name is used for backward compatibility. In all other cases, the DNS-style name should be used as a policy. This article also describes how to troubleshoot problems encountered during domain controller locating.
The following describes how to use a positioner to find a domain controller:
 
On the client (computer that searches for the domain controller), the locator is started by executing Remote Procedure Call (RPC) on the local netlogon service. Locator dsgetdcname ApplicationProgramProgramming interface (API) calls are implemented through the netlogon service.
The client collects the information required when selecting a domain controller and uses the dsgetdcname call to transmit the information to the netlogon service.
The netlogon service on the client uses the collected information to find the specified domain from a domain controller. One of the following two methods is used:

1. for DNS names, netlogon queries DNS by using an IP/DNS compatibility locator-that is, after the DNS attaches the domain name to an appropriate string of the specified SRV record, dsgetdcname calls dnsquery to read "service resource" (SRV) Records and "A" records from DNS.
Log on to the Windows-based domain workstation to query the general form of SRV records from the DNS:
_ Service. _ protocol. dnsdomainname
The Active Directory Server provides the LDAP service through the TCP protocol. Therefore, the client finds an LDAP server by querying a record in the following form from DNS:
_ LDAP. _ TCP. dnsdomainname
2. For NetBIOS names, netlogon uses the Microsoft Windows NT 4.0 compatible locator to perform Domain Controller discovery (that is, by using a transfer-specific mechanism, such as wins ).

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

 
• The netlogon Service sends a datagram to the computer that registers the name. For NetBIOS domain names, datagram is implemented as a mail box message. For DNS domain names, datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is a connectionless datagram transport protocol, which is part of a TCP/IP protocol group. TCP is a connection-oriented transmission protocol .)
• Each available Domain Controller responds to this datagram, indicating that it is currently running and returns this information to dsgetdcname.

Note that UDP allows programs on one computer to send data packets to programs on another computer. UDP includes a protocol port number that allows the sender to distinguish multiple targets (programs) on a remote computer ).
• Each available Domain Controller responds to this datagram, indicating that it is currently running and returns this information to dsgetdcname.
• The netlogon service caches Domain Controller information so that subsequent requests do not have to repeat this discovery process. Caching this information helps ensure consistency between the use of the same domain controller and the Active Directory view.

When a client logs on or joins the network, it must be able to find a domain controller. This client sends a "DNS lookup" query to the DNS to find the domain controller, and it is best to find it in the client's own subnet. Therefore, the client finds a domain controller by querying a record in the following form from DNS:
_ LDAP. _ TCP. DC. _ msdcs. domainname
After the client finds a domain controller, it uses LDAP to establish communication to obtain access to active directory. As part of this negotiation, the Domain Controller determines the site where the client is located based on the IP subnet of the client. If the client is communicating with a domain controller that is not in the latest (BEST) site, the domain controller returns the site name of the client. If this client has tried to search for the domain controller in this site (for example, when the client sends a "DNS lookup" query to the DNS to search for the domain controller in the subnet of this client ), the client uses this not optimal domain controller. Otherwise, the client will use the new best site name to re-execute a site-specific DNS lookup. The domain controller uses some directory service information to identify the site and subnet.

After the client finds a domain controller, the entries of this domain controller will be cached. If this domain controller is not on the best site, the client will refresh the cache and discard the cache entries in fifteen minutes. Then it will try to find an optimal Domain Controller in its own site.

After the client establishes a communication path to the domain controller, it can establish logon and authentication creden。. Moreover, for Windows-based computers, a secure channel can also be established when necessary. Then, the client can perform regular query and search information in the directory.

The client establishes an LDAP connection to the domain controller for logon. The "Security Account Manager" is used for this logon process ". Because the communication path uses the LDAP interface and the client is authenticated by a domain controller, therefore, after the customer account is verified, it is passed to the Directory Service proxy through the "Security Account Manager", then to the database layer, and finally to the database in the "extensible storage engine" (ESE.
Troubleshoot domain positioner Problems
Check the Event Viewer on the client and server. The event log may contain error messages that indicate problems. To view the Event Viewer, click Start, point to program, point to administrative tools, and then click event viewer. View System logs on the client and server. In addition, check the Directory Service Log On the server and DNS log on the DNS server.
Run the ipconfig/all command at the command prompt to check the IP configuration.
Use the Ping utility to check network connection and name resolution. Run the ping command on the IP address and server name. You may also need to ping the domain name.
Use the netdiag tool to determine whether the network components work properly. To send the detailed output to a text file, run the following command:
Netdiag/V> test.txt
Check the log file, locate the problem, and carefully check any related components. This file also contains details about other network configurations.
To fix minor issues, use the netdiag tool netdiag/fix in the following syntax.
Use the nltest/dsgetdc: domain name command to check whether a domain controller can be found for a specific domain.
Use the NSLookup tool to check whether DNS entries are correctly registered in DNS. Check whether the server host record and guid SRV record can be parsed.

For example, to check record registration, run the following command:
NSLookup server name. Root Domain sublevel. root domain. com

NSLookup guid. _ msdcs. root domain. com
If neither of the two commands succeeds, use either of the following methods to register records with DNS. • To force host record registration, Type ipconfig/registerdns.
• To forcibly register the domain controller service, stop the netlogon service and restart it.
 
To detect Domain Controller problems, run the dcdiag utility at a command prompt. This utility runs Multiple tests to check whether the domain controller is running properly. Use this command to send the result to a text file:
Dcdiag/V> dcdiag.txt
Use the ldp.exe tool to connect to and bind to the domain controller to check whether there is an appropriate LDAP connection capability.

 
If you suspect that a specific domain controller is faulty, enabling netlogon debugging logs may be helpful. Run the following command to use the nltest utility: nltest/dbflag: 0x2000ffff. The information is then recorded in the netlogon. log file in the debug folder.
 
If the problem persists, use network monitor to monitor network traffic between the client and the domain controller.