If you are looking for to understand how a Windows client does consult and find the closest Domain Controller to authenticate to domain, and also would like to know how to change a client subnet to a different AD Site, this post gathered some useful information you might be interested in.
How does my computer locate the best (read closest) Domain Controller?
The answers is something called DC Locator Process.
In a few words, DC Locator process is used by Windows systems to locate the closest available Domain Controller within an AD Domain. It relies on DNS resolution and AD Sites and Subnets configuration for the identification.
That's why the importance to have an environment correctly configured and working with DNS resolution and Active Directory Sites and Services, especially when in your scenario exists remote offices connecting across WAN links; it's mandatory to plan with your network team how the network topology is set up, and then, define the physical topology of Active Directory (Sites and Services).
Ok, to better understand that, let's have a look on some theoretical stuff and then we go to the nicest part and show how to set up it on practical.
So, 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...:
4.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).
4.2. The site that the current domain controller is in.
4.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:
5.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.
5.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.
So to summarize, the client gets the whole list of DCs available on domain, and do a LDAP query to any of them. The return of this consult will determine if the client do a second query to find the closest DC or, if the client authenticates to the same DC.
For more detailed information related to DC Locator Process, have a look on this Technet page
Now the best part, how to set up your environment to properly work as described above?
Simple, open Active Directory Sites and Services, add and link the subnet to the correct AD Site.
If you have no idea how to set up Active Directory Sites and Services from scratch, have a look on this Technet Blog page.
Ok, nice! But what happens when I change my client's subnet to a different AD Site?
That's a really good question because eventually you will have the needed to move clients to a different AD Site.
I faced this situation already, and in my case the network team was redesigning the subnets topology to meet a global network integration, where the old domain controllers located in a specific AD site were using a subnet that would be decommissioned.
On the practical, the procedure will be similar than showed in the pictures above, except from the part your subnets will already exist, and you will just need to change the link to a new AD Site.
We can better understand the flow of how the client will identify that it was changed to a different AD Site in the picture below:
As we can see, the client will form affinity to the same Domain Controller that authenticated him at first time. So when this Domain Controller is offline, or if the client was moved to a different AD Site, the flow showed above is start from the scratch and the new Site will be stored in the client registry and the first DC will be that one the client will create affinity again.
Right, but how can I see what DC my computer is authenticated to, and what AD Site it's linked?
A great command to test and troubleshoot AD Sites and Subnets issues, is the showed below: (nltest /dsgetdc:contoso.local)
The output of this command shows:
- DC the client is authenticated to (DC: \\LON-DC1);
- Site the client is located (Our Site Name);
- Site the DC is located (DC Site Name).
Ok, so If the client does not have the subnet add on AD Sites and Services, the above output will only show the site of the Domain Controller that authenticated the client, or if the client subnet is linked to a wrong AD Site, you would be able to identify that through this command too.
Now, imagine if your computer's client are being authenticated by a Domain Controller from a remote office using a slow WAN link? Not good!
So time to fix it and force the client to check information against a DNS server instead of its logon cache (will start the above flow from scratch). To do that, run the command:
nltest /dsgetdc:contoso.com /force
And again to confirm all is good now:
nltest /dsgetdc:contoso.local
For any doubts or suggestions, please leave a comment below.
References: