Secure channels are an important element in the trust relationships between Windows NT 4.0 domains. (Administrators establish trust relationships between domains by giving users from one domain permission to access resources in another domain without needing to log on to the second domain. For more information about trust relationships, see "Trusted and Trusting Domains in NT 4.0," December 1999.) NT workstations establish secure channels locally to domain controllers, and domain controllers establish secure channels to one another. In secure channels between domains, the domain controller for each trusting (i.e., resource) domain establishes a secure channel to the domain controller in the trusted (i.e., master) domain. Secure channels let domain controllers exchange trust communications and validate user requests for access to resources in trusting domains.
Secure channels between master and resource domains are important. To understand these types of secure channels, you need to be familiar with the secure channel discovery process, Registry edits for making channels more secure, and domain-management utilities to monitor and reestablish secure channels.
Secure Channel Discovery Process
When a domain controller in the resource domain starts, it tries to discover and establish a secure channel with a domain controller in the master domain. The process for establishing this secure channel is complex.
First, when an administrator installs a domain controller, the system creates a unique machine account for the computer and assigns a password. The Local Security Authority (LSA) stores this password in the hidden file $machine.acc. By default, the system changes the password every 7 days.
Second, the domain controller in the resource domain uses its defined name-resolution node type to obtain a list of master domain controllers. If the machine is a WINS client, it sends requests to its designated WINS server; NetBEUI clients use broadcast transmissions or LMHOSTS file entries. The name-resolution node type specifies how NetBIOS over TCP/IP (NetBT) identifies and accesses network resources. Node types include b-node, p-node, m-node, and h-node. For NT machines that use DHCP, the administrator can configure the DHCP server to assign any of these node types.
B-node uses broadcast messages to resolve names. The machine sends a broadcast message to look for the computer it wants to communicate with and waits a specified length of time to receive a response. B-node is the default type for machines that aren't configured to use WINS.
P-node uses point-to-point communications with a name server to resolve names. In this node type, all the machines register with the WINS server.
M-node is a mixed method that uses b-node and p-node. If name resolution isn't successful with b-node, the machine uses p-node to resolve names.
H-node is a mixed method that uses b-node and p-node. This node type is the default for machines that are configured to use WINS. If name resolution isn't successful with p-node because the name isn't registered in the database or because the WINS server isn't available, the machine uses b-node to resolve names.
The list of master domain controllers that the resource domain controller obtains has a set order. The PDC is always the first entry. Next are the domain controllers that are registered with the WINS server, in order of most recently to least recently refreshed. The last domain controllers in the list are those which the WINS database contains only because WINS servers replicated them.
The third step in establishing a secure channel is that the resource domain controller seeks validation of its machine account. The domain controller sends a Netlogon broadcast locally, then sends unicast Netlogon requests to all the master domain controllers.
Fourth, the resource domain controller establishes a secure channel connection with the first master domain controller that validates its Netlogon request. Typically, the domain controller that responds to the request most quickly is the one that is physically closest to the resource domain controller or that has the fastest link. The secure channel completes only after each computer is satisfied that the other computer has correctly identified itself through its machine account.
After a resource domain controller establishes a secure channel with a master domain controller, user account logon requests pass from the resource domain controller to the master domain controller. The system must repeat the secure channel discovery process if the secure channel connection breaks or one of the domain controllers or the Netlogon service stops and restarts.
Secure Channel Integrity Checking
Although some information that passes through secure channels is encrypted (e.g., passwords), secure channels lack integrity checking. Thus, your system is open to attackers who can intercept and modify information in requests that you send or receive over secure channels. The worst part is that you wouldn't even know that an attacker had administrator access to machines on your network.
Fortunately, you can use Service Pack 4 (SP4) to enable integrity checking on your NT systems. Start regedt32, and go to the HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Registry entry. (Back up your Registry and update your Emergency Repair Disks—ERDs—before you make changes to the Registry.)
To specify whether the system signs outgoing secure channel traffic, create or modify the entry SignSecureChannel with the data type REG_WORD. Set the value to 1 for True or 0 for False. The default value is 1. Setting the SealSecureChannel value to 1 (True) overrides the SignSecureChannel value and forces it to 1. Likewise, setting the RequiresSignOrSeal parameter to 1 overrides the SignSecureChannel value.
To specify whether the system encrypts outgoing secure channel traffic, create or modify the entry SealSecureChannel with the data type REG_WORD. Set the value to 1 for True or 0 for False. The default value is 1.
To specify that the system must sign or seal outgoing secure channel traffic, create or modify the entry RequiresSignOrSeal with the data type REG_WORD. Set the value to 1 for True or 0 for False. The default value is 0. Set this parameter to 1 only if all the trusted domains support signing and sealing.
These Registry changes might slow your system down because they create additional network traffic. If your network has slow WAN links or many domain controllers, you need to balance security with operational speed. You need to determine whether security or speed is more important.
Tools for Monitoring and Reestablishing Secure Channels
If you encounter problems such as logon scripts not running, user logons taking a long time to complete, remote rather than local BDCs authenticating users, or unnecessary use of WAN links, you might have a secure channel problem on your network. Perhaps the secure channels aren't connected properly, or maybe a problem with load-balance validation occurred between the resource domain and the master domain controllers.
These types of problems occur most often in large NT environments. For example, a nonlocal BDC might authenticate, without the user's knowledge, a user who logs on to a local BDC for master domain authentication. This problem occurs when a large NT deployment uses multiple master domain BDCs to authenticate local users spread across wide geographical areas. Simply placing a BDC for the master domain in the remote areas doesn't guarantee local user authentication because the discovery process establishes the secure channel with the server that responds first to the Netlogon request. If the local domain controllers are busy at the time of the request, the secure channel might be established with a remote domain controller or with a domain controller that has a slow link. Four tools are available to help you monitor and manage the secure channels in your domains.
DomMon. The Microsoft Windows NT Server 4.0 Resource Kit utility DomMon graphically monitors domain controllers' status. DomMon checks the status of the secure channel to the domain controller, the status of servers in a domain, and the status of domain controllers in trusted domains.
You run this utility from the command line. To specify domains to monitor, select Add Domain or Remove Domain from the Domain menu. Screen 1 shows a list of domains to monitor. To display a domain controller's properties for a domain, highlight the domain name, click on Domain on the menu bar, and select Properties. Screen 2, page 124, shows the properties for three domain controllers. You can view each domain controller's state, status, and replication status, and you can see whether a domain controller's connection to the PDC and link to the trusted domain are successful. The domain controller's state shows whether the domain controller is online or offline. If DomMon lists a domain controller's state as offline, the domain controller might be powered down, or the Netlogon service, workstation service, or server service might not be running.
For each domain controller in the Domain Controller Status dialog box's top window, you can view the domain controller's link status in the bottom window. You can see the domain controller's trusted domain, trusted domain controller, and secure channel status.
You can set an automatic refresh interval for DomMon to display domain controllers' status. Select Intervals from the DomMon Options menu. The default interval rate is 900 seconds (15 minutes). Keep in mind that a refresh update can take several minutes if you have a large number of servers in the specified domains or if you have a long list of domains to monitor.
Netdom. Another resource kit command-line utility that lets you monitor secure channels is Netdom. (For more information, see Mark Minasi, This Old Resource Kit, "Netdom 2000," November 1999.) This tool lets you check the status of the secure channel from a resource domain controller. To use the utility, type
netdom master /query
Netdom's output for a successful check is
You can also use Netdom to reset the secure channel between a BDC and a PDC if Netlogon error 3210, 5721, or 5723 occurs on the BDC or if Netlogon error 5722 occurs on the PDC.
On the BDC, Netlogon error 3210 (i.e., Failed to authenticate with \\PDC name for domain domain name) occurs when the computer account's password and the LSA secret, which the Netlogon service uses to establish a secure channel, aren't synchronized. The result of this error is that the Nelogon service doesn't start because the secure channel isn't functional. Netlogon error 5721 (i.e., The session setup to the Windows NT Domain Controller \\PDC name for the domain domain name failed because the Windows NT Domain Controller does not have an account for the computer BDC name) occurs when the computer account no longer exists. Netlogon error 5723 (i.e., The session setup from the computer BDC name failed because there is no trust account in the security database for this computer. The name of the account referenced in the security database is BDC name$) also occurs when the computer account no longer exists.
On the PDC, Netlogon error 5722 (i.e., The session setup from the computer BDC name failed to authenticate. The name of the account referenced in the security database is BDC name$. The following error occurred; access is denied) occurs when the password isn't synchronized. When this error occurs because the password isn't authenticated, the event data contains the error 0xC0000022, which means that the computer account's password isn't valid. When the error occurs because the computer account no longer exists, the event data contains the error 0xC000018B.
When a secure channel problem prevents the Netlogon service from starting on the BDC, you can use Netdom to reset the BDC secure channel. To use the utility to reset a secure channel, type
Netdom's output for a successful reset is
Nltest. Nltest is another command-line utility that lets you monitor secure channels. This tool is available in the resource kit or as part of the Microsoft Windows NT 4.0 Resource Kit Support Tools, which you can download at http://www.microsoft.com/ntserver/nts/downloads/recommended/ntkit/default
.asp. (For more information, see Mark Minasi, This Old Resource Kit, "NL
TEST," February 1998.)
You can use Nltest to check the status of a secure channel between servers, local or remote workstations, or BDCs. You can also run the command on a PDC when you have an explicit trust relationship between two domains and you specify the trusted domain. To check the status of a secure channel, enter
Nltest's output for a successful check is
You can also use Nltest to reestablish secure channels between machines that belong to one domain and between domain controllers that trust other domains. To validate user logon access to resources in a resource domain, the resource domain's PDC establishes a secure channel with a domain controller in the master domain. Pass-through authentication can then occur over this secure channel. Pass-through authentication occurs when, to authenticate a user account, logon information for the account must pass to the domain controller on which the account is defined.
In a WAN environment, master domain controllers might be dispersed over a wide range of slow and fast links. As a result, the resource domain's PDC might establish a secure channel with a master domain controller over a slow link if a fast link is unavailable when the PDC makes the request. When a fast link later becomes available, pass-through authentication to the master domain controller might still occur over the slow link.
The system tracks how much time authentication takes over a secure channel. If pass-through authentication takes longer than 45 seconds, a rediscover process begins, the current secure channel disconnects, and the resource domain's PDC sends logon requests to all the master domain controllers to reestablish a secure channel. Although the system considers any amount of time less than 45 seconds acceptable, users will probably complain if logging on typically takes 44 seconds. Nltest doesn't let you specify which master domain controller to establish the secure channel with.
The first step in reestablishing a secure connection is to check which master domain controller your resource PDC has a secure channel with. To accomplish this task, use the Netdom or Nltest query command. If your resource PDC has a secure channel with the wrong master domain controller, you need to restart the discovery process to search for the fastest link for the secure channel. To restart the discovery process, enter the following command on the resource domain's PDC:
Nltest's output for this command is
Setprfdc. The full download version of NT SP4 includes the Setprfdc utility. This utility goes a step beyond Nltest in reestablishing secure channels. The standard version of SP4 doesn't include this tool; you must download the full version of SP4 and use the /x switch to extract the file. If you obtain the file from the SP4 CD-ROM, you need to manually copy the file to the \winnt\system32 folder.
Setprfdc lets you supply a list of master domain controllers you want to establish a secure channel with, in the order you want the resource domain controller to try them. This option lets you direct the resource domain controller to a preferred master domain controller for the secure channel. If the resource domain controller can't establish a secure channel with one of the preferred master domain controllers in the list, the current secure channel remains intact until the next time you run Setprfdc. To run Setprfdc, type
where trusted domain is the master domain and list of domain controllers in trusted domain is the list of master domain controllers you want to establish the secure channel with. The list of master domain controllers is in the form of DC1, DC2, and so on.
Channel Your Knowledge
Secure channels are one of NT's least understood concepts. To fine-tune the secure channels between your master and resource domains, you need to understand the secure channel discovery process, integrity checking procedures, and methods for monitoring and reestablishing secure channels.