3.5 Trusts and secure channels | Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

When a trust relationship is set up between two Windows domains, a secure channel will be created between these domains every time the domain controllers on both sides of the trust are started. In the context of a secure channel, “secure” means providing authentication of the requestor and also confidentiality, integrity, and data authentication services for the data sent across the channel. A secure channel always involves a domain controller.

In a Windows environment, secure channels are not only set up between domains and their domain controllers. They also provide a secure communication path between the security principals listed here:

Between a workstation or member server and a domain controller located in the same domain
Between domain controllers located in the same domain
As mentioned earlier, between domain controllers located in different domains

A secure channel enables the secure replication of Active Directory data between domain controllers in the same and different domains. Also, the exchange of Kerberos authentication messages and the exchange of the challenge-response messages and pass-through authentication in an NTLM authentication sequence take place across a secure channel.

You can look at a secure channel as the enabler of secure communication between machines and their trusted authority in the same domain and between the trusted authorities of different domains. The security services offered by a secure channel are based on machine account passwords (within a domain) and on trustedDomain account passwords (between domains).

Secure channels are set up at system startup time. To authenticate the requestor of the secure channel, different accounts are used depending on where the secure channel is set up:

Between a workstation or member server and a domain controller located in the same domain, the workstation or member server’s machine account is used.
Between domain controllers located in the same domain, the domain controller’s machine account is used.
Between domain controllers located in different domains, the trustedDomain account is used.

The service responsible for setting up the secure channel is the Net- Logon service. An important difference in the way a secure channel is set up between Windows 2000, Windows Server 2003, and NT4 is the way the requestor locates a domain controller: In NT4 the localization method was dependent on the way the machine’s NetBIOS name resolution was configured; in Windows 2000 and Windows Server 2003 a domain controller is located using DNS.

3.5.1 Controlling secure channels setup

In Windows Server 2003 there are two ways to control secure channel setup: using an entry in the LMHosts file and using the nltest.exe utility (in NT 4.0, there was a third way: using the setprfdc.exe utility). The “control secure channel setup” means making sure that the secure channel is set up to a particular domain controller (DC). This may be an interesting option for cross-domain authentication traffic when domains are spanning different physical AD sites.

Using the LMHosts file

You can use the LMHosts file to preload DC entries for a particular domain in the NetBIOS name resolution cache. The following LMHosts entry will preload DC1 for domain HP in the client’s Net- BIOS cache:
```
10.0.0.1 DC1 #PRE #DOM:HP
```
Using the nltest.exe utility

To set the secure channel to a domain "HP" to a DC called "DC1," use the following nltest command:
```
Nltest /sc_reset:HP\DC1
```

3.5.2 Validating secure channels between domains

In Windows Server 2003 there are different methods to validate secure channels between domains. You can do so from the GUI or from the command line.

click to expand
Figure 3.23: Validating a secure channel from the GUI.

To validate a secure channel between domains from the GUI, open the Domains and Trusts MMC snap-in, open the properties of the domain whose secure channel you want to verify, go to the trusts tab, then open the properties of the trust relationship whose secure channel you want to verify: Clicking the Verify button will verify the secure channel associated to that particular trust relationship. If the secure channel and the trust are OK, the system will pop up a dialog box similar to the one illustrated in Figure 3.23. If the secure channel is not okay, the system will automatically try to reset the secure channel.

To validate a secure channel from the command line, you can use the nltest.exe, netdom.exe, or dcdiag.exe command-line tool. The exact syntax needed to do this is explained in Section 3.5.4.

3.5.3 Fine-tuning secure channel security services

Besides authentication of the requestor, a secure channel also provides “confidentiality,” “integrity,” and “data authentication” services for the data sent across the channel. These security services can be fine-tuned using the registry hacks shown in Table 3.3 (located in the HKLM\System\Current- ControlSet\Services\Netlogon\Parameters registry folder). Obviously, these hacks can also be controlled using Windows 2000 and Windows Server 2003 Group Policy Object settings. By default, every Windows 2000, Windows XP, and Windows Server 2003 workstation and server has the “Sealsecurechannel” and“Signsecurechannel” parameters set.

Table 3.3: Secure Channel Security Registry Hacks
Registry Parameter	Meaning
Requiresignorseal	If set to1, secure channel traffic must be either signed or sealed; if this cannot be done, the system refuses to set up a secure channel. If set to 0, the use of signing and sealing will depend on the outcome of the negotiation between the two entities.
Sealsecurechannel	Encrypt secure channel traffic (if set to 1).
Signsecurechannel	Sign secure channel traffic (if set to 1). If “Sealsecurechannel” is set, the channel will be sealed and not signed.
RequireStrongKey	If set to 1, enforces the use of a strong 128-bit key for securing the channel. The 128-bit key encryption will only be used if both sides of the channel support 128-bit encryption (in Windows 2000, this setting requires the high-encryption pack, which is available by default in Windows Server 2003).

These parameters (explained in Knowledge Base article Q183859) should not be confused with “SMB signing and sealing” (explained in Knowledge Base article Q161372).

3.5.4 Secure channel–related and trust-related management tools

Table 3.4 lists some tools you can use to monitor, test, and troubleshoot your Windows Server 2003 secure channels and where you can find them.

Table 3.4: Trust and Secure Channel Troubleshooting Tools
Tool (Available From)	Function
Netdom.exe (Support Tools)	Command prompt tool enabling an administrator to manage trusts and secure channels, check their status, and reset them. Sample netdom commands: To query the trusts defined: netdom query trust To verify the status of a trust (secure channel) to a particular domain: netdom trust <trusting_domainname> / domain:<trusted_domainname /verify To reset a trust (secure channel) to a particular domain: netdom trust <trusting_domainname> / domain:<trusted_domainname /reset To create a trust from one domain to another: netdom trust <trusting_domainname> / domain:<trusted_domainname> /add
Nltest.exe (Support Tools)	Command prompt tool enabling an administrator to check the status of a trust and to reset it. Sample nltest commands: To list the trust relationships existing from a particular domain controller: nltest /trusted_domains /server:<dcname> To verify the status of a trust: nltest /sc_query:<domainname> To reset a trust (secure channel) from a particular domain controller to a particular domain: nltest /server:<dcname> / sc_reset:<domainname> To force a secure channel password change for a particular machine and a particular domain: nltest /server:<machinename> / sc_change_pwd:<domainname> To reset a trust (secure channel) for a particular domain to a particular domain controller: nltest /sc_reset:<domainname>\<dcname> To identify all domain controllers in a domain nltest /dclist:<domainname>
Dcdiag (Support Tools)	Command prompt tool to test domain controllers. Sample dcdiag command: To test the secure channels originating from a particular domain controller to a particular domain: Dcdiag /s:<dcname> / test:outboundsecurechannels / testdomain:<domainname>
Netdiag (Resource Kit)	Command prompt tool that can be used to validate and test secure channels. Sample netdiag command: To test and validate secure channels: Netdiag /test:Trust
Setprfdc.exe (NT4 SP4)	Enables the specification of a preferred list of domain controllers for secure channel setup.

The last tool in the list—the setprfdc.exe tool—can be used to influence the Windows secure channel setup behavior.

Monitoring Trust Relationships Using Windows Management Instrumentation (WMI) To monitor trust relationships using WMI, you can use one of the following three WMI classes. All three are part of the Root\MicrosoftActiveDirectory namespace:

Microsoft_LocalDomainInfo: This class provides information about the domain on which the instance of the trust monitor is running.
Microsoft_DomainTrustStatus: Instances of this class provide information about the domains that have a trust relationship with the local domain.
Microsoft_TrustProvider: The properties of this class define the parameters of the operation of the trust monitor.

Here is a sample WMI Query Language (WQL) event query you can use to monitor a trust:

Select * From __InstanceModificationEvent Within 10 Where TargetInstance ISA ‘Microsoft_DomainTrustStatus’ And  TargetInstance.TrustIsOk = “False”