NLTest (NLtest.exe) (ST)

The NLTest tool helps administrators to manage both Windows 2000 native and mixed mode (with Windows NT 4.0 BDCs) domains as well as Windows .NET (version 2002) mode domains. The tool has a number of options including the following:

  • Verifying and resetting secure channels (trusts)

  • Getting information on network topology (a list of DCs, sites, domain trusts, etc.)

  • Forcing synchronization with BDCs

  • Forcing shutdown on a computer, and other options

NLTest is a very useful tool for troubleshooting authentication problems, since it allows you to test the trust relationships between pairs of specific computers (e.g., between a DC from one domain and a DC located in another domain, or a DC and a domain client) for which these trusts were established.


With most commands of the Windows 2000 version of the NLTest, it is preferable to specify DNS rather than NetBIOS names of computers.

Some options of NLTest are similar to the options realized in the NetDom tool. (See Chapter 12, "Manipulating Active Directory Objects.") You may choose the tool that is the most appropriate for your specific tasks.

Verifying Secure Channels

First of all, you should not confuse transitive Kerberos trust relationships (established in Windows 2000 and Windows .NET domains) with non-transitive secure channels (trust links). Although you can, for example, log on to a domain that belongs to one forest tree on a computer that has a machine account in another forest tree, this does not mean that domain controllers from the corresponding domains have direct trust relationships. (You can, however, manually establish such a relationship named a shortcut trust. See Chapter 5, "Deploying Active Directory.") That is why you can only verify secure channels directly between a child and its parent domain, or between tree root domains.

Normally, you should get the following result on every domain computer:

    C:\>nltest /query    Flags: 0    Connection Status = 0 0x0 NERR_Success    The command completed successfully 

This output means that the computer has been authenticated by a domain controller, and a secure channel exists between the client computer and the domain controller. If a user has been logged on locally, or for some reason a network logon has not been performed (e.g., the DC has not been found, and so on), you will see the following message:

    Connection Status = 1311 0x51f ERROR_NO_LOGON_SERVERS 

The following message indicates that the Netlogon service failed to start or is not running on the computer (since it is stopped or disabled):

    I_NetLogonControl failed: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF 

In that case, you should open the Services snap-in and check the status of the service.

If the domain computer account has been reset, NLTest will respond with the message:

    Connection Status = 5 0x5 ERROR_ACCESS_DENIED 

If an administrator has disabled the domain computer account, NLTest reports:

    Connection Status = 1787 0x6fb ERROR_NO_TRUST_SAM_ACCOUNT 

If the account is re-enabled, restart the Netlogon service on the computer or run the nltest /sc_reset command (see below).

To verify a secure channel or find the logon server, use the nltest /sc_query command, for example:

    C:\>nltest /sc_query:net.dom    Flags: 30 HAS_IP HAS_TIMESERV    Trusted DC Name \\    Trusted DC Connection Status Status = 0 0x0 NERR_Success    The command completed successfully 

If the command responds

    Connection Status = 1311 0x51f ERROR_NO_LOGON_SERVERS 

you may try to log off and log on to the system, or to reset (re-establish) a secure channel by using the following command:

    C:\>nltest /sc_reset:net.dom 

If there are multiple DCs in the domain, the client computer will establish a secure channel with the DC that responds first.


For verifying and resetting secure channels, it is also possible to use the netdom /VERIFY and netdom /RESET commands.

Now let us consider a specific scenario. Suppose you have two domains in the forest — a child and a parent — and want to test whether the domain controller from the parent domain will be authenticated by the child domain, i.e., whether the trusts between domains is in the proper state (the child must trust the parent and vice versa). You use the following command, and for some reason it fails:

    C:\>nltest / /    Flags: 0    Trusted DC Name    Trusted DC Connection Status Status = 1311 0x51f ERROR_NO_LOGON_SERVERS    The command completed successfully 

You could check this trust in another way. Run the Active Directory Domain and Trusts snap-in, open the Properties window for the domain net.dom, and click the Trusts tab. Select the child domain in the Domains that trust this domain (incoming trusts) list and click Properties, and then Validate[1]. (For an alternate way to start verification, you can: run the Active Directory Users and Computers snap-in on a DC located in the child domain, point to the System container, and open the Properties window for the object net.dom of the Trusted Domain type. Then click Validate.) The system will display a window shown in Fig. 11.1. (In Windows 2000, the window, though similar, has a different design; however, the sequence of operations will be same.)

click to expand
Figure 11.1: This window informs you that the secure channel between two DCs in related domains is broken, but you can reset it

If you select Yes, reset the trust passwords, provide the administrator's credentials, and click OK. The system will try to reset the secure channel that failed.

The following command will help you to repair the secure channel from the command prompt:

    C:\>nltest / /    Flags: 30 HAS_IP HAS_TIMESERV    Trusted DC Name \\    Trusted DC Connection Status Status = 0 0x0 NERR_Success    The command completed successfully 

To troubleshoot authentication issues, you can test necessary domain controllers and clients in a similar manner and locate the source of the problems.

Viewing Trusted Domains

Using NLTest, you can display all trust relationships that have been established between the current domain and other domains in the same or another forest. Verbose mode allows you to view domain SIDs and GUIDs. Look at a sample output:

    C:\>nltest /trusted_domains /v    List of domain trusts:       0: SUBDOM (NT 5) (Forest: 2) (Direct Outbound)    (Direct Inbound) (Attr: 0x20)          Dom Guid: 5bcbeeb3-e619-40a6-86b9-4e3d3d9647b2          Dom Sid: S-1-5-21-1193178465-209799049-3125462871       1: W2K w2k.dom (NT 5) (Direct Inbound)          Dom Sid: S-1-5-21-2025429265-113007714-1060284298       2: NET net.dom (NT 5) (Forest Tree Root) (Primary Domain) (Native)          Dom Guid: 941fecfd-d067-472b-9253-a3ce94f43b3e          Dom Sid: S-1-5-21-2033051489-2658513307-2223184096          The command completed successfully 

How should you analyze the displayed information? From these output lines, you can conclude the following:

  • A Windows 2000-based domain w2k.dom has an explicit, one-way incoming trust with the current domain (i.e., users from the current domain can access resource in the domain w2k.dom).

  • A Windows .NET-based domain is in mixed mode, and belongs to the same forest (Forest: 2) as the current domain.

  • The current (Primary) domain net.dom is in Windows .NET (Windows 2002) mode, and is the forest root domain.


This command does not distinguish Windows 2000 domains from Windows .NET domains and marks them both as NT 5. Also, the command cannot discern Windows 2000 native mode from Windows .NET (Windows 2002) mode (functional level).

Viewing Information on Network Topology

Information about the site (in a multiple site network) a client computer is connected to is not configured on that computer in any way. (The site is selected on the basis of client and subnet IP address data.) The following command will help you to find the site to which the local or remote computer has been connected after it has been booted and logged on to the domain:

    C:\>nltest /dsGetSite    NET-Site    The command completed successfully 

(Add /server:<computerName> for a remote computer.)

Sometimes, a domain controller can serve more than one site. (If a new site has been created but you did not move a DC to that site, some DC from an existing site will be selected to serve the new site. To increase network fault-tolerance, you can also intentionally configure a DC to serve a site when the domain controllers of that site are unavailable.) The following command lists all sites, which the DC can serve:

    C:\>nltest /dsGetSiteCov /    NET-Site    Remote-Site    The command completed successfully 

(The /server parameter is not required if the command is performed on a domain controller.)

Quite often, it is necessary to see the list of controllers located in a domain. A command similar to the following allows you to view all DCs in an AD-based domain:

    C:\>nltest /DClist:net.dom    Get list of DCs in domain 'net.dom' from'\\'. [PDC] [DS] Site: NET-Site [DS] Site: NET-Site               nt4bdc5    The command completed successfully 

Servers present in this list may be offline! (Notice that the PDC is marked. To find the PDC, you can also use the nltest /DCname:<NetBIOSDomainName> command.) Notice also that a Windows 4.0-based BDC nt4bdc5 has no directory service and is not connected to the site topology.

To search a domain for a DC performing a specific role (PDC, Global Catalog, writable replica, etc.), use a command similar to the following (search for the PDC Emulator):

    C:\>nltest / /PDC               DC: \\          Address: \\         Dom Guid: 5bcbeeb3-e619-40a6-86b9-4e3d3d9647b2         Dom Name:      Forest Name: net.dom     DC Site Name: Remote-Site            Flags: PDC DS LDAP KDC WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST    CLOSE_SITE    The command completed successfully 

You can add the/FORCE parameter, and the command will try to find another (different) DC with a specified property (if this is possible).

The Windows .NET version of NLTest offers a new option that performs the same actions as the /dsGetDC parameter provides (this option uses another system call — DsGetDcOpen):

    C:\>nltest / /PDC    List of DCs in pseudo-random order taking into account SRV priorities and weights:    Non-Site specific:    The command completed successfully 

Note that the command displays the TCP/IP port number (389) used for access to the service specified.


To find all GC servers in the forest, use ReplMon or query the DNS server for records in the gc._msdcs.<forestDNSname>subdomain, e.g.:

    C:\>nslookup    Server:    Address:    Name:    Addresses:, 

Note that all GC servers register their IP addresses in the same DNS subdomain regardless of which domain they belong to, and you should always search for a GC server by specifying the DNS name of the forest root domain.


For discovering domain controllers you can also use the netdiag /test:DcList and netdiag /test:DsGetDc /v commands.

Miscellaneous Options

Forcing Shutdown on a Remote Computer

You can use NLTest as an analog to the Shutdown.exe command (from the Resource Kit). The following command issues a warning message to the computer and shuts it down in 60 seconds:

    C:\>nltest /shutdown:"Administrative request for shutdown" 60       / 


In contrast to Shutdown.exe, NLTest cannot reboot the computer after shutdown.

Directory Time Conversion

Some attributes, e.g., pwdLastSet, lastLogon, or badPasswordTime, are stored in Active Directory as Large Integers (INTEGER8 format). NLTest can convert these values to a human-readable format. The conversion procedure is rather cumbersome, so you may prefer to use the repadmin /showtime or w32tm /ntte commands (see later in this chapter). Let us, for example, consider converting a time value 126679218485309520 obtained with the ADSI Edit snap-in. Copy and paste the value in the Calculator, and convert it to a hexadecimal format. The result will be 1C20E13FA3DB050. Enter nltest /time: at the command prompt and paste in the hexadecimal value. Then you must highlight the eight rightmost digits and place them before the other digits. You should get the following result:

    C:\>nltest /time:FA3DB050 1C20E13    fa3db050 01c20e13 = 6 /7 /2002 15:10:48    The command completed successfully 

Notice that the command converts the entered value into local time rather than UTC.

[1]In Windows 2000, the buttons have other names; however, the procedure, in general, is the same.

Windows  .NET Domains & Active Directory
Windows .NET Server 2003 Domains & Active Directory
ISBN: 1931769001
EAN: 2147483647
Year: 2002
Pages: 154 © 2008-2017.
If you may any questions please contact us: