Sometimes you may want to find out which domain controller your computer is authenticated to (your
Logon Server). This can come in handy when there are issues applying Group Policies or when users complain about slow logons. A user’s computer may be authenticated to a wrong domain controller if the nearest DC is not available, the firewall is blocking access to it, Active Directory sites or subnets are misconfigured, or there are problems with DNS. As a result, a user may get all GPO settings, scripts, etc. from any other DC instead of the nearest one. It may result in slow GPO processing, slow software deployment, etc.
How to Identify Which DC a Computer is Authenticated to?
You can detect the domain controller you logged in using some methods:
- With the command prompt:
- In the output of the following command:
systeminfo | find /i "logon server"
- From the environment variable:
- You can also get the value of the environment variable using PowerShell:
- In the output of the command
Group Policy was applied from: MUN-DC02
- The nltest tool shows the domain controller a computer authenticated to (user and computer logon servers may sometimes differ). Nltest also allows to check the trust relationship between the computer and the domain controller, and shows the name of the Active Directory site the DC belongs to (Dc Site Name):
If you know the domain controller, you can get user information from the logon DC security logs (for example, the user’s logon history to the domain and other logs).
How Windows Finds the Closest Domain Controller?
The NetLogon service is responsible for discovering the LogonServer when Windows is booting. The service must be running:
In a simplified way, the process of finding a domain controller by the Windows client looks like this:
- The NetLogon sends a DNS query to get a list of domain controllers (SVR
_ldap._tcp.dc._msdcs.domain_) at Windows boot;
- DNS returns a list of DCs in the domain;
- The client sends an LDAP query to the DC to get an AD site by its IP address;
- The DC returns the AD site that matches the client’s IP or the closest site (this information is cached in the registry:
HKLM\System\CurrentControlSet\Services\Netlogon\Parametersand used at the next logon for a faster search);
- The client requests a list of domain controllers on the target site via DNS (under the
- Windows sends requests to all DCs on the AD site and the first one that responds is used as a LogonServer to perform authentication.
Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \\MUN-DC02.woshub.com Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully
If the specified DC is not available, an error will appear:
I_NetLogonControl failed: Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
If neither of the domain controllers is available or the computer is disconnected from the network, the following message appears when a user logs on:
There are currently no logon servers available to service the logon request.
You can log on to such a computer using domain user cached credentials only.
You can find out the closest domain controller according to the site hierarchy, subnet, and weight using the Get-ADDomainController cmdlet from the Active Directory for PowerShell module:
Get-ADDomainController -Discover -NextClosestSite
This will allow you to find the name of the domain controller through which the computer should authenticate. If it differs from the current one, you will have to troubleshoot this.