Domain Computer Boot Up Process and site info

When first joining the domain, the client makes general DNS and LDAP queries and gets a list of all the domain controllers in the domain, and it goes down the list, trying LDAP binds, and the first successful DC that it binds to - that is the first DC it authenticates with.

After the client has joined the domain, Active Directory will tell the client which site it belongs to. Active Directory knows this because the administrator has put the IP subnet of the client in AD Sites & Services and associated it to a Site.

Active Directory tells the client what its AD site is, and the client stores that in its own registry in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName registry value. That way, the next time the client boots up, it knows what site-specific DNS query to make so that it gets only the DCs that are in that site.

Of course the full behavior is documented in KB247811, but if you want to see it for yourself, you could run Wireshark or NetMon and do a packet trace, and then join a domain while the trace is running. You will see the exact sequence of DNS queries and LDAP binds. Subsequent DNS queries and LDAP binds are made to the site-specific sub-zones because the client has been told by AD what site it belongs to.

The Netlogon service will periodically refresh its AD site info, so if you move to a different network, your client will get its new site automatically. This can be adjusted in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeout registry value.

------------------------------------------

The detail:

This sequence describes how the Locator finds a domain controller:
1. 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.

2. 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.

3. 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 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 for SRV records in the 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 

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS). 

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

4. 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.)

5. Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
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.

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

7. 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 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 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.

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 fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client. 

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).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:
1.  Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

2. Check the IP configuration by using the ipconfig /all command at a command prompt.

3. Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

4. Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:
netdiag /v >test.txt

Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

5. To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix.

6. Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

7. Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved. 

For example, to verify record registration, use the following commands:
nslookup -qt=srv _LDAP._TCP.westdistrict._sites.dc._msdcs.sulancn.com

nslookup -qt=srv _LDAP._TCP.dc._msdcs.sulancn.com

8. If either of these commands does not succeed, use one of the following methods to reregister records with DNS:
To force host record registration, type ipconfig /registerdns.
To force domain controller service registration, stop and start the Netlogon service.

9. To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file:
dcdiag /v >dcdiag.txt

10. Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

11. If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff. The information is then logged in the Debug folder in the Netlogon.log file.

12. If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

on windows 7 client: 

nslookup -qt=srv _LDAP._TCP.westdistrict._sites.dc._msdcs.sulancn.com
nslookup -qt=srv _LDAP._TCP.dc._msdcs.sulancn.com
nltest /dsgetdc:sulancn.com
nltest /SC_QUERY:sulancn.com
nltest /DCLIST:sulancn.com
nltest /DSGETSITE
nltest /DSADDRESSTOSITE:sc-test1

 DcDiag /Fix or NetDiag /fix

pls refer to:

https://support.microsoft.com/en-us/kb/247811

http://serverfault.com/questions/486518/how-does-a-client-system-in-an-active-directory-network-find-in-which-site-it-re   

本文转自 zhangfang526 51CTO博客，原文链接:http://blog.51cto.com/zhangfang526/1712205