To find out the Domain Controller (DC) that authenticated a logged-in user in Windows 10/11, you need to use the “echo” command along with the “%logonserver%” environment variable in the Command Prompt. Here’s how:
1. Open the “Start” menu and type “cmd” in the search bar.
2. Click on “Command Prompt” from the search results.
3. Once the Command Prompt opens, type the following command and press “Enter“:
echo %logonserver%
The command will return the name of the Domain Controller that authenticated the current logged-in user.
It’s important to note that the %logonserver% environment variable holds the name of the server that authenticated the current user’s login session. This server might not be the main Domain Controller; instead, it could be any server that is part of the Active Directory depending upon which server responded to the authentication request.
Also, the returned name will be in the format of \\DCName. The “\\” denotes that it is a network device.
NLTEST COMMAND
The `nltest /dsgetdc:` command and the `echo %logonserver%` command both retrieve information about the Domain Controller (DC) in a Windows network environment, but they provide slightly different information.
The `echo %logonserver%` command will return the name of the Domain Controller that authenticated the current user session. This is simply the server that validated your username and password at login. It does not necessarily represent the Domain Controller that is currently being used for Active Directory services.
On the other hand, the `nltest /dsgetdc:` command is a much more advanced tool. When used with the `/dsgetdc:` switch, it queries the Locator service on a specified domain and provides detailed information about the Domain Controller. This includes the DC name, the domain name, the DC IP address, and several flags that describe the DC’s capabilities and roles.
The difference is essentially that `echo %logonserver%` tells you who authenticated the current session, while `nltest /dsgetdc:` gives you a more detailed view of a specified domain controller’s roles and capabilities.
Here’s how you would use `nltest /dsgetdc:`:
1. Open the “Start” menu and type “cmd” in the search bar.
2. Click on “Command Prompt” from the search results.
3. Once the Command Prompt opens, type the following command and press “Enter” (replacing “domain_name” with the name of your domain):
nltest /dsgetdc:domain_name
This will return a lot of useful information about the DC, such as the DC’s fully qualified domain name (FQDN), the IP address, and more.
It’s worth mentioning that the `nltest` command might require administrative privileges to run, while the `echo %logonserver%` command does not.
KLIST COMMAND RUN-AS
The klist command in Windows displays Kerberos tickets for the logged-in user session, and it doesn’t provide information about any other sessions authenticated using “Run as“.
When you use the “Run as” command to execute a program, a new authentication token is generated for the duration of that process, and a Kerberos ticket is issued. However, this doesn’t change the ticket list for the logged-in session you’re currently in, and therefore, the “Run as” user information won’t be displayed using klist from the original session.
If you wish to see the Kerberos tickets for a “Run as” user, you would have to execute klist in the context of the “Run as” user.
Remember, finding the exact Domain Controller which authenticated a specific “Run as” request isn’t straightforward due to the nature of how Windows handles authentication requests. The requests are distributed across different Domain Controllers and it might not be possible to pinpoint the exact Domain Controller that handled a specific “Run as” request without more advanced techniques such as detailed auditing and logging, or network traffic analysis.
Here’s how to use it:
1. Open the Command Prompt with the “Run as” user credentials.
2. Type the following command and press “Enter“:
klist
This command will display all Kerberos tickets for the current user. Look for the entry that corresponds to the service you’re running with “Run as“. The issuing authority of that ticket would be the Domain Controller that authenticated the “Run as” request.
Note: You might need to install the Windows Resource Kit or enable the Active Directory module for Windows PowerShell to have access to the `klist` command depending on your system setup.