Trusted and Trusting Domains in NT 4.0

Establishing Trust Relationships
You create trust relationships in User Manager for Domains, Policies, Trust Relationships. To establish a one-way trust, in the Trust Relationships dialog box, which Screen 1 shows, type the name of the trusting domain in the Trusting Domains text box and click Add. Next, type the name of the trusted domain to the Trusted Domains text box and click Add.

Although you can establish either side of the trust first, Microsoft recommends that you establish the trusting domain first. When you set up a one-way trust as Microsoft recommends, upon establishing the trusting domain, the system immediately verifies the password you used to set up the relationship between the domains. Only the trusted domain receives the system message that indicates initial trust relationship establishment success or failure. Therefore, if you establish the trusted domain first, you'll receive the message The trust relationship could not be verified at this time. If you find that it was not established, contact the administrator of the <Trusted Domain> domain and verify that it includes <Trusting Domain> on its list of Trusting Domains. You avoid this error message (and the confusion it causes) by establishing the trusting domain first.

When you establish a reciprocal trust relationship, you set up both domains as trusted and trusting domains. For each domain, type the domain name first in the Trusting Domains text box and click Add. Then, type the domain name in the Trusted Domains text box and click Add.

Establishing Interdomain Trust Accounts
When a domain administrator establishes a trust relationship and provides the initial password, User Manager for Domains creates a trust account in the directory database of the master domain. Only the PDC uses interdomain trust accounts; users can't see the trust accounts in User Manager for Domains.

In the following steps that the system takes to establish an interdomain trust account, I refer to the trusted domain as the Master domain. I refer to the trusting domain as the Resource domain.

1. The system creates a trusted domain object in the Local Security Authority (LSA) on each domain controller in the Resource domain. The object contains the trusted domain name and the domain SID. During the domain account synchronization process, the Resource domain PDC synchronizes the domain name and SID with each BDC in the Resource domain.
2. Next, on each of the domain controllers of the Resource domain, the system creates an LSA secret object. In Windows 3.x, a limit of 256 LSA secrets existed; in NT 4.0, this limit has increased to 4096. Because NT uses LSA secret objects not only for trust relationships but also for saving service passwords, you must use no more than half the total 4096 LSA secrets for domain trusts. The Netlogon service uses the LSA secret to establish a secure channel between the domains in the trust relationship. The LSA secret object retains the password associated with the trust link. The Resource domain's PDC stores the LSA secret object in the HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets Registry key. (You can view this key by assigning full rights to \SECURITY to the administrator. To reset the original rights in regedt32.exe, go to Security, Permissions and reestablish the HKEY_LOCAL_MACHINE\SECURITY rights to the administrator by choosing Special Access for the Type of Access and choosing Write DAC and Read Control permissions. You need to reset the original rights to the \SECURITY key after you view or make any changes to the Secrets Registry key.) The PDC synchronizes the LSA secret object with each of the Resource domain's BDCs.
3. User Manager for Domains creates an interdomain trust account in a SAM user account on each of the Master domain's domain controllers. (The SAM assigns rights and permissions to objects in NT.) The interdomain trust user accounts store the interdomain trust account's password. The Registry path HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names stores the interdomain trust user account. (You can view this Registry path by assigning full rights to \SAM to the administrator, as I explained in step 2 for the SECURITY hive.) The Master domain's PDC synchronizes the interdomain trust user account with each Master domain BDC.
4. After the system creates the trusted domain object, LSA secret object, and interdomain trust accounts, the Resource domain's PDC requests a session with the Master domain's PDC. (However, the Resource domain PDC establishes a session with the first domain controller in the Master domain to respond to the session request.) The Master domain's PDC returns the error 0xc0000198, Status_Nologon_Interdomain_Trust_Account because a normal session logon can't use the special interdomain trust account. Consequently, the session request fails.
5. The error message signals to the Resource domain's PDC that the interdomain trust is possible and a trust account exists. The system then establishes an unauthenticated, or null, session. Remote procedure call (RPC) transactions use remote API calls to establish the trust relationship.
6. The Resource domain's Netlogon service seeks discovery (i.e., seeks recognition) on the Master domain when the trust relationship is established. Using the trust information that User Manager for Domains stores, the Netlogon service sets up a secure channel between the domains. The Master domain's PDC then authenticates the interdomain trust account.
7. After the trust is established, the Resource domain's PDC changes the trusted domain object password. I describe the procedure for this password change in the following section, "Trusted Domain Object Password Changes."
8. All domain controllers in each domain perform intradomain synchronization of the SAM and LSA databases for the trust account objects. The Resource domain's domain controllers receive the LSA secret object during the LSA database update. The Master domain's domain controllers receive the account information during the SAM database update. The trust account objects let any domain controller in the Resource domain set up a secure channel to any domain controller in the Master domain.

Trusted Domain Object Password Changes
In NT 4.0, the Resource domain's PDC automatically changes the trusted domain object's password every 7 days. (In Windows 2000—Win2K—the default password-change interval is 30 days.) NT 4.0 marks password changes announce immediately, which initiates synchronization between domain controllers in the Resource domain each time the password undergoes modification. A secure channel must exist between domains before a password change can occur. Because only Resource domains establish secure channels, and because password changes must succeed before a Resource domain can establish a secure channel (with one exception I'll explain shortly), Master domains never initiate password changes. NT 4.0 performs a trusted domain object password change in the following way:

1. The Resource domain PDC generates a random password.
2. The system copies the information in the Resource domain's LSA secret object's NewPassword field to the OldPassword field as a backup.
3. The system sets the LSA secret object's NewPassword field to the password that the Resource domain PDC generated in step 1. The system retains the old password so that the Resource domain's domain controllers can always access a valid password should a crash occur.
4. The Resource domain sends an I_NetServerPasswordSet RPC to the Master domain domain controller to which the Resource domain has established a secure channel. The RPC requests that the Master domain's domain controller set the password on the SAM user trust account to equal the new value that the Resource domain LSA secret object's NewPassword field contains. The Master domain's domain controller passes the request to the Master domain PDC.
5. The system changes the password on both domain PDCs. Normal synchronization between domain controllers distributes the password objects to each domain's BDCs.

NT 4.0 includes a safeguard for the unlikely event that the Resource domain can't update the password on a Master domain domain controller. The Resource domain's LSA secret object retains old and new passwords in case the Master domain controller fails during the password-updating process. The Resource domain's PDC doesn't change to the new password unless the PDC can use the new password to set up a secure channel to a Master domain controller. If the secure-channel setup fails because the new password isn't valid, the Resource domain PDC uses the old password to attempt the setup. If the old password succeeds in establishing the secure channel, the password-change process initiates within 15 minutes and begins with step 4.

Establish Trust Relationships
Trust relationships are necessary in a multiple domain environment and can make your job easier by centralizing administration. When you take time to learn about and plan trust relationships, you can optimize performance and enhance security in your enterprise.