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 \\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 Validate111. (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.)
£ The iiu*r ClV^wx ti vgtdvsdloi itiei^ownfiM^ii:
siT-.rt iharJ» ¿iCjnfie) cr. jofiavi t vitrokv I dom oJ dcr.>r ifli- IDdHlAh ncdemrs" djni iMiii^fh ontr. " ncre J? CMrcntVnolo^r rtt tri iviliife ta MS EC H-w la Jin Hquf :l
-ifltb! iru'rH Mst^cn: r. ¡ct-L "e [' OHHII Do IKJU ^'JTP!;^ 'i« tuil DHIMrdl?
Hf. (tand io:iVitfl i™J pssswanfe
(■' Vil. l.-uLl lOIWd S*P»«w6(i:;.jei|liPJil|hiwiidPltrp««ViBrvil;a(; nit*: rabdOmnH Jyi ilenwi Tj-pi it* uin riah; wdtsiiwad of aftMeotrtm'h.aditniiiaiwff fliiwts»!
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.
Post a comment