DC Locator Process | Client moved to another Site | Automatic Site Coverage (sites with no DC)

Note: This is a compilation of data from various resources in order to give a quick view about the main processes regarding clients' authentication to domain.

DC Locator Process

How does a computer client find a domain controller to authenticate to domain? Basically, it goes like this:

1.       Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
2.       DNS server returns list of DC’s.
3.       Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
4.       DC returns…
1.       The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
2.       The site that the current domain controller is in.
3.       A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
5.       The client decides whether to use the current DC or to look for a closer option.
1.       Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
2.       If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.




Client subnet moved to another Site:

















Automatic Site Coverage (sites with no DC)

DCs perform automatic site coverage. Every domain controller in the forest follows this procedure:

  1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
  2. Build a list of candidate sites — sites that have domain controllers for this domain.
  3. For every target site, follow these steps:
1.       Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
2.       Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
3.       If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
4.       If more than one, break ties by choosing the site that is first alphabetically.
5.       Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

Commands to properly consult which Site and Domain Controller the client is located/authenticated by:

nltest /dsgetdc:contoso.com

The output of this command shows:
- DC the client is authenticated to;
- Site the client is located;
- Site the DC is located.

If the client does not have a subnet added on AD Sites and Services, the above output will only show the site of the DC used to authenticated the client, which could be a DC located in a different site than the client, causing a delay to client's authentication and future queries if they are connected through a WAN link, for example.

After to add the clients' subnet in AD Sites and Services, you can force the client to check information against a DNS server instead of its logon cache:

nltest /dsgetdc:contoso.com /force

References:
https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/

Comentários