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: set log

  LOGONSERVER=\\MUN-DC02

• In the output of the following command: systeminfo | find /i "logon server"
• From the environment variable: echo %logonserver%
• You can also get the value of the environment variable using PowerShell: $env:LOGONSERVER
• In the output of the command gpresult /r 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): nltest /DSGETDC:woshub.com

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:

get-service netlogon

In a simplified way, the process of finding a domain controller by the Windows client looks like this:

1. The NetLogon sends a DNS query to get a list of domain controllers (SVR _ldap._tcp.dc._msdcs.domain_ ) at Windows boot;
2. DNS returns a list of DCs in the domain;
3. The client sends an LDAP query to the DC to get an AD site by its IP address;
4. 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\Parameters and used at the next logon for a faster search);
5. The client requests a list of domain controllers on the target site via DNS (under the _ tcp.sitename._sites...);
6. 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

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.