Secure Channels in NT 4.0

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.

   Previous  [1]  2  3  Next