|
|
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.
Note | 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. |
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 \\netdc1.net.dom 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.
Note | 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 netdc1.net.dom from the parent domain will be authenticated by the child domain subdom.net.dom, 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 /sc_query:subdom.net.dom /server:netdc1.net.dom 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 subdom.net.dom 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.)
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 /sc_reset:subdom.net.dom /server:netdc1.net.dom Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \\netdc2.subdom.net.dom 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.
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 subdom.net.dom (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 subdom.net.dom 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.
Note | 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). |
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 /server:netdc1.net.dom 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'\\netdc1.net.dom'. netdc1.net.dom [PDC] [DS] Site: NET-Site netdc4.net.dom [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 /dsGetDC:subdom.net.dom /PDC DC: \\netdc2.subdom.net.dom Address: \\192.168.0.2 Dom Guid: 5bcbeeb3-e619-40a6-86b9-4e3d3d9647b2 Dom Name: subdom.net.dom 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 /dnsGetDc:subdom.net.dom /PDC List of DCs in pseudo-random order taking into account SRV priorities and weights: Non-Site specific: netdc2.subdom.net.dom 192.168.0.2:389 The command completed successfully
Note that the command displays the TCP/IP port number (389) used for access to the service specified.
Note | 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 gc._msdcs.net.dom Server: netdc1.net.dom Address: 192.168.0.1 Name: gc._msdcs.net.dom Addresses: 192.168.0.1, 192.168.0.2
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.
Note | For discovering domain controllers you can also use the netdiag /test:DcList and netdiag /test:DsGetDc /v commands. |
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 netdc4.net.dom and shuts it down in 60 seconds:
C:\>nltest /shutdown:"Administrative request for shutdown" 60 /server:netdc4.net.dom
Note | In contrast to Shutdown.exe, NLTest cannot reboot the computer after shutdown. |
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.
|
|