Trusted and Trusting Domains in NT 4.0

A Windows NT domain comprises a collection of computers that share a common directory database. A domain administrator maintains the domain, and only centralized user accounts can access the domain. What do these facts mean? Simply that a domain organizes the resources from one or more NT servers into one administrative structure. NT grants logon privileges to the domain, rather than to the individual servers within the domain, and each domain has a unique name that distinguishes it from other domains. Domain administrators grant end users access to a domain's resources. Therefore, when you establish multiple domains in a network, you must create trust relationships between the domains so that you can selectively assign users access to necessary resources. In this article, I explain trust relationships in NT 4.0, and I describe the four domain models. Then, I walk you through the process of establishing trust relationships and show you how NT 4.0 establishes interdomain trust accounts. The sidebar, "Troubleshooting Synchronization Errors," page 107, gives you step-by-step instructions for solving the synchronization problems that can occur in interdomain trusts.

Trust Relationships
In a domain trust relationship, users log on in only one domain. Other domains that trust the user's logon domain (i.e., trusting domains) rely on the logon, or trusted, domain to authenticate the end user's logon and password. When the trusting domain's administrator assigns the appropriate permissions, user accounts in the trusted domain can access resources in the trusting domain. Establishing a trust between domains doesn't automatically grant users rights to resources in the trusting domains; the domain administrator must assign such rights.

Setting up trusts between domains lets administrators manage multiple domains as one administrative unit. The trusted domain's administrator can perform administrative tasks in the trusting domain; the trusted domain contains the user accounts. The trusting domain trusts the trusted domain to manage users, groups, and resources. The trusting domain contains the resources that validated users need to access. (Validated users are users with assigned permissions to access the resources of a domain. These resources include files, directories, workstations, and printers.) Administrators of trusting domains can still manage their users, groups, and resources but can't manage users in trusted domains unless a two-way trust relationship exists between the trusting and trusted domains.

Trust relationships aren't transitive. In other words, if the Production domain trusts the Engineering domain and the Engineering domain trusts the Administrative domain, the Production domain doesn't necessarily trust the Administrative domain. A domain's administrator must explicitly grant a trust to another domain to establish a trust relationship.

Trusts flow in one direction. For example, if the Production domain trusts the Engineering domain, validated users in the Engineering domain can access resources in the Production domain. However, users in the Production domain can't access resources in the Engineering domain. Arrows in trust-relationship diagrams always point from the resources toward the domain that is trusted to use the resources, as Figure 1 shows.

Even though trusts flow in only one direction, you can establish a reciprocal trust relationship between two domains. As Figure 2 shows, validated users in both the Production and the Engineering domains can access the resources of both domains because each domain trusts the other. Domain administrators use NT 4.0's User Manager for Domains to establish explicit trust relationships and manage trusts.

Four Domain Models
There are several reasons why an organization might need to establish more than one domain. For best performance, Microsoft suggests that an NT 4.0 domain database not exceed 40MB. Obviously, this limitation restricts the number of workstations, users, and groups you can define in a given domain. (For information about how to plan domain capacity, see Michael D. Reilly, "The Accounts Database," February 1997.) Another reason to establish multiple domains is that some departments within an organization might prefer to manage their own resources. When you establish separate domains for such departments, you can grant resource control to them. Finally, because too many servers on one domain can impair performance, keeping domains small to limit the number of necessary domain servers is a sound management practice.

Four NT domain models exist: single domain, master domain, multiple master domain, and complete trust. You can use one model or a combination of models to manage your network. (For in-depth descriptions of each domain model, see Michael D. Reilly, "Domains and Trust Relationships," September 1998.)

The single domain model. The single domain model consists of only one domain and thus is the simplest of the four domain models. Because the single domain model comprises one domain, it doesn't require trust relationships. This model works well for small networks.

The master domain model. Figure 3 illustrates the master domain model. In this model, users belong to one domain—the master, or accounts, domain. Resources (i.e., databases, folders, files, printers) belong to multiple resource domains. The domain administrator establishes trust relationships between the master and the resource domains. Each resource domain trusts the master domain. However, the resource domains don't necessarily trust one another, and the master domain doesn't need to trust the resource domains.

The multiple master domain model. As Figure 4 shows, this model consists of two or more master domains with reciprocal trusts between the master domains. That is, each master domain trusts every other master domain in the model. You need to establish trusts in the multiple master domain model so that each resource domain trusts each master domain. Because this model lets you manage complex relationships, it's useful for large enterprises or when companies merge.

The complete trust model. Figure 5 illustrates the complete trust model. In this model, each domain is a separate entity, and a reciprocal trust exists between all domains. The number of trust relationships rapidly increases as the domains in a complete-trust-model network increase. Microsoft recognizes that this domain model lacks central security control; therefore, the company recommends that, when possible, companies use the multiple master domain model rather than the complete trust model. When you choose the complete trust model, you must be sure that each domain administrator maintains a high level of security.

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.