![]() If the client has already tried to find domain controllers in that site, the client uses the domain controller that isn't optimal. If the client is communicating with a domain controller that isn't in the closest (most optimal) site, the domain controller returns the name of the client's site. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. So clients find a domain controller by querying DNS for a record of the form: _LDAP._TCP.dc._msdcs.domainnameĪfter the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client's own subnet. When a client logs on or joins the network, it must be able to locate a domain controller. ![]() Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory. The Netlogon service caches the domain controller information so that later requests need not repeat the discovery process.Each available domain controller responds to the datagram to indicate that it's currently operational and returns the information to DsGetDcName.UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer. UDP allows a program on one computer to send a datagram to a program on another computer. TCP is a connection-oriented transport protocol.)Įach available domain controller responds to the datagram to indicate that it's currently operational and returns the information to DsGetDcName. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. For NetBIOS domain names, the datagram is implemented as a mailslot message. The Netlogon service sends a datagram to the computers that registered the name. In Windows NT 4.0 and earlier, "discovery" is a process to locate a domain controller for authentication in either the primary domain or a trusted domain. That is, by using the transport-specific mechanism, such as WINS. So clients find an LDAP server by querying DNS for a record of the form:įor a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-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.Ī workstation that's logging on to a Windows-based domain queries DNS for SRV records in the general form: _service._protocol.DnsDomainNameĪctive Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. ![]() 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:įor a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator. Then it passes the information to the Netlogon service by using the DsGetDcName call. The client collects the information that's needed to select a domain controller. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service. On the client (the computer that's locating the domain controller), the Locator is started as a remote procedure call (RPC) to the local Netlogon service. This sequence describes how the Locator finds a domain controller: How the Locator finds a domain controller This article also addresses troubleshooting the domain controller location process. In all other cases, DNS-style names should be used as a matter of policy. The flat-style name is used for backward compatibility. This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. For more information, see the Microsoft Support Lifecycle Policy.Īpplies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Original KB number: 247811 Summary The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. Support for Windows 2000 ends on July 13, 2010.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |