This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
How Domain Controllers Are Located in Windows
How Domain Controllers Are Located in Windows

Version management

Difference between version and

At line 1 added 42 lines
!!! Overview[1]
[{$pagename}] describes the [Discovery Mechanism] used by Windows to locate a [Domain Controller] in a [Microsoft Active Directory] based [AD DOMAIN].
[{$applicationname}] provide the [How To] details of the process of locating a domain by its [DNS]-style name vs the its flat-style (NetBIOS) name.
[{$applicationname}] 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 [Netlogon service] on the client uses the collected information to look up a [Domain Controller] for the specified domain.
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)|DNS SRV Records] 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:
{{{_service._protocol.DnsDomainName }}}
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:
{{{_ldap._tcp.DnsDomainName}}}
When a client logs on or joins the network, it must be able to locate a domain controller. Therefore, clients find a [Domain Controller] by querying DNS for a record of the form:
{{{_LDAP._TCP.dc._msdcs.domainname }}}
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. After the client locates a domain controller, the [Domain Controller] entry is cached.
After the client locates a [Domain Controller], it establishes communication by using [LDAP] to gain access to [Microsoft Active Directory]. The client establishes an [LDAP] connection to the [Domain Controller] using a [LDAP ping] and retrieves the [Netlogon attribute]. The [Client] determines if the [Domain Controller] is appropriate for starting the [Windows Logon] using the [Windows Client Authentication Architecture]
! [Active Directory Site]
As part of the negotiation, the [Domain Controller] identifies which [Active Directory Site] of 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 ([ClientSiteName]). 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 [ClientSiteName]. 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.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [How Domain Controllers Are Located in Windows|http://support.microsoft.com/kb/247811|target='_blank'] - based on information observed 2014-01-06
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop