Last month I discussed the domain models that Windows NT networks use. I explained the need for trust relationships between domains. This month I discuss setting up trust relationships and examining their properties. I also highlight trust changes in NT 5.0. (For more information about trust relationships, see "Related Articles in Windows NT Magazine," page 213.)
Trust Relationships
A trust relationship is a communications channel, or an enabling mechanism. Trust relationships let you perform certain functions. For example, trust relationships let you assign permissions on resources in one domain to users in another domain. Trust relationships let you set up permissions so that you log on only once from anywhere in the domain structure.
A one-time logon is possible because when you log on to a computer in a remote domain, your home domain controller can validate the logon. The remote domain controller trusts your local domain controller. If your home domain controller validates your user account and password, the remote domain controller lets you log on.
Determining whether a remote computer has a trust relationship with your domain is easy. Open the computer's logon dialog box and look for your domain name. If your domain name appears in the drop-down menu, the computer is in your domain or has a trust relationship with your domain.
Properties of Trusts
To set up domain trust relationships correctly, you need to understand the properties of a trust relationship. First, trusts are only one-way. If domain A trusts domain B, domain B does not necessarily trust domain A. Second, trusts are not transitive. If domain A trusts domain B, and domain B trusts domain C, no implied trusts exist between domains A and C. Third, you must set up reciprocal trusts from both sides. However, either side can break the trust relationship.
Systems administrators often complain that trust relationships are not transitive. Many administrators want implied trusts so that they do not need to set up numerous trust relationships. But transitive trusts create security risks. For example, company A might set up a trust with supplier B to let the supplier monitor the company's inventory and automatically ship orders to replenish the inventory. In turn, supplier B might give system access to consulting company C for development purposes. Consulting company C is also consulting for company D, a rival of company A. If trust relationships were transitive, company A would automatically trust rival company D, an obvious security risk.
NT 5.0 addresses many of these concerns. Domains and organizational units (OUs) will use trust relationships based on the Kerberos security model. NT 5.0 will establish these trusts as necessary on the network, with fewer limitations than current trusts have. You can use the NT 4.0 trust model where appropriate, as in the previous example, to prevent a trust from going further than you intend.
Setting Up a Trust Relationship
Only a domain administrator can set up trust relationships. From the Start menu, select Programs, Administrative Tools, User Manager for Domains. From the Policies menu, select Trust Relationships, as Screen 1, page 212, shows. Screen 2, page 212, shows the Trust Relationships dialog box, with two windows in which you add trusted domains or trusting domains. You must set up a trust from both sides. The process goes more smoothly if the trusted domain first adds the trusting domain.
Suppose you are the Engineering administrator and you want to set up a trust so that the Production domain trusts the Engineering domain. Click Add in the Trusting Domains section of the Trust Relationships dialog box. Add Production as a trusting domain, and enter a password, as Screen 3, page 212, shows. This case-sensitive password is necessary for only initial communication between the domains. The system changes the password after the initial communication. The Production domain administrator must then add Engineering as a trusted domain, as Screen 4 shows. If you entered a password when you added the Production domain, the Production administrator must enter that password to add Engineering as a trusted domain. If you set up the trust correctly, the Production administrator gets a confirmation window, which Screen 5 shows.
You might also want to establish a trust so that Engineering trusts Production. Suppose you reverse the steps. If Engineering first sets up Production as a trusted domain, the administrator receives an error message, which Screen 6 shows. The error message tells the Engineering administrator to contact the Production administrator and ensure that Engineering is listed as a trusting domain. Engineering is not a trusting domain, because the Production administrator has not added it. The trusted domain must first accept the responsibility for validating users for the trusting domain.
You might have difficulty remembering who needs to set up a trust first. Begin by determining which domain is the trusted domain and which domain is the trusting domain. Then, open the Add dialog box. The domain administrator of the trusted domain has two password boxes (Initial Password and Confirm Password) and must set and confirm the password first. The other domain administrator has only one password box, to confirm the password the first administrator enters. When you set up a trust relationship, communicate with the other administrator via telephone to facilitate the process.
Trust Passwords
The system changes the initial password after you establish the trust. Every 7 days thereafter, the two Primary Domain Controllers (PDCs) communicate to change the password. Even the domain administrators do not know the password. This anonymity prevents either side from reestablishing a broken trust relationship without the other administrator's cooperation.
Broken Trust Relationships
Either side of a trust relationship can break the trust at any time. Click Remove in the Trust Relationships dialog box to break a trust. Rebuilding a trust is more complicated than breaking it; you must repeat the entire setup process.
Logons and Shared Resources
After you establish a trust relationship, administrators from both domains can log on at a computer in either domain. The administrators can also assign permissions on shared resources to users from the other domain. Users do not immediately have permissions when you establish a trust relationship. Permissions are not automatic: You must assign permissions if you want users from one domain to have access to resources in the other domain.
Cross-Domain Administration
Administrators control access to their local domains but have no authority in the trusted or trusting domain. For the Engineering administrator to administer the Production domain, the Production administrator must add the Engineering Domain Admins global group to the local Administrators group.
Warnings
If you change a domain's name, you break its trust relationships. This problem originates not on the domain with the name change but on the domains it trusts. A trust relationship uses the domain security ID (SID) rather than the domain name, so the problem should not occur. However, the trust relationship dialog boxes, logon dialog box, and permissions dialog boxes refer to the trusted domain by the name you used when you established the trust. When the trusted domain's name becomes invalid, the trust becomes obsolete.
Sometimes a user has accounts in two domains that do not have a trust relationship. You cannot establish a trust if you have open connections to another domain. You must remove the local accounts to establish a trust relationship.
Avoid Confusion
Multiple domains necessitate trust relationships. Trusts might seem confusing, but do not let them intimidate you. If you plan ahead and coordinate with other domain administrators to set up trusts, the trusts maintain themselves.