Supporting Windows NT in a medium-to-large scale environment required administrators to establish complex trust relationships between domains. In Windows 2000, all of the rules for establishing trusts have changed. In this Daily Drill Down, I’ll explain how trust relationships have changed in Windows 2000. I’ll then go on to explain how to go about managing these trusts.
How trusts work in NT
In a Windows NT environment, each domain is completely independent of other domains. This means that if a user in one domain needs to access a network resource found in another domain, a trust relationship must be established that allows the domain containing the resource to recognize the domain that contains the user.
A trust relationship is essentially a way of telling domain A that it’s safe to trust users from domain B. However, domain A’s administrator must still manually grant access to resources. Simply telling domain A to trust domain B doesn’t magically give the users in domain B full access to everything. Instead, it simply adds the users in domain B to the users that domain A’s administrator can assign permissions to. This is an example of a one-way trust: Domain A trusts domain B.
However, Windows NT also supports a two-way trust in which both domains trust each other. In this particular case, domain A trusts domain B, and domain B trusts domain A. Since each trust relationship in Windows NT must be specifically assigned, things can get a little confusing when establishing trust relationships between more than two domains.
In Windows NT, each trust must be specifically assigned. For example, if you wanted to create a full trust between domains A, B, and C, you’d have to make domain A trust domains B and C, domain B trust domains A and C, and domain C trust domains A and B. That’s six separate trust relationships. You can imagine how difficult it can be to maintain trust relationships in really big Windows NT organizations with a lot of domains.
Windows 2000 trusts
One of the biggest differences between Windows NT and Windows 2000 is the presence of Active Directory (AD). Every domain in the entire organization uses some AD components, such as the schema master and the global catalog. For Windows 2000 to make this exchange possible, it needs some sort of trust relationship in place.
Windows 2000 allows you to create parent and child domains where one domain falls beneath another domain in the domain tree hierarchy. With parent and child domains, the DNS name of the child domain in some way reflects the name of the parent domain. For example, suppose that you had a parent domain named posey.com. Any child domains that fell beneath posey.com would contain posey.com within its DNS name. You could have a child domain named talainia.posey.com or brien.posey.com. Any time you create a child domain, Windows 2000 automatically creates a two-way trust relationship in which the parent trusts the child and the child trusts the parent.
Now, suppose for a moment that the domains posey.com, talainia.posey.com, and brien.posey.com actually existed. Talainia.posey.com would fully trust brien.posey.com and vice versa. Windows 2000 doesn’t explicitly create this trust relationship automatically, and you don’t have to create it either. Instead, the trust relationship between these domains is established via transitive trusts.
A transitive trust is an arrangement where if domain A trusts domain B, and domain B trusts domain C, then domain A will automatically trust domain C. Although no explicit trust relationship between the two parallel domains has been assigned, a full two-way trust exists because of transitive trusts. Windows NT didn’t offer transitive trusts, but they are offered in Windows 2000.
Trusts between unrelated domains
To see how trusts work in an environment that contains parallel domains that aren’t involved in a parent/child relationship of any kind, let’s look at my network. It contains two domains, posey.com and bud.com. As you can tell by their DNS names, although these domains belong to the same forest—an absolute requirement for any type of trust relationship—they are otherwise unrelated.
Because these two domains are unrelated, they function as totally separate entities from a user standpoint. Sure, they still share a common AD, but no trusts exist. So an administrator in posey.com wouldn’t be able to assign any sort of permissions to allow a user from the bud.com domain to access domain resources. The reverse is also true.
If I wanted to build a trust between these two domains, I would have to do so through AD. The two domains are a part of the same AD and are therefore already sharing some information, so to complete the trusting process, you need only to make an entry into AD indicating it’s okay to implement a normal trust relationship between the two domains.
To establish a trust between two unrelated domains within the same forest, select Programs | Administrative Tools | Active Directory Domains And Trusts from the Start menu. When you do, Windows will open the Active Directory Domains And Trusts console. This console displays all of the top-level domains in a format that can be expanded to display any child domains beneath them, as shown in Figure A.
To create a trust relationship, right-click one of the domains and select Properties to view the domain’s properties sheet, and then select the Trusts tab.
As you can see in Figure B, the Trusts tab contains two mail sections, the Domains Trusted By This Domain section and the Domains That Trust This Domain section.
The first section indicates that administrators in the present domain—in this case posey.com—will be able to assign permissions to domain resources to users from the foreign domain, bud.com. The second section indicates that the local domain, posey.com, is being trusted by the remote domain, bud.com. As you can see in the figure, both sections contain the bud.com domain. You’ll also notice that the Domains That Trust This Domain section contains an Add, an Edit, and a Remove button. It may seem strange that you can add a remote domain to the list of domains that trust the local domain. However, you’re not actually controlling the security of a remote domain. Instead, you’re establishing one half of the trust relationship.
For example, imagine you work in a very high-security environment. You wouldn’t want the administrator of one domain to start allowing users in another domain to access resources without someone knowing he or she has done so. So as a security precaution, Windows 2000 requires that when a trust relationship is established, both domains’ administrators must be involved in the process. If you wanted to establish a one-way trust relationship in which the domain posey.com trusted the domain bud.com, an administrator from posey.com would add bud.com to the list of trusted domains. Then, to complete the process, an administrator from bud.com would have to add posey.com to the list of domains that trust this domain. In a two-way trust, each administrator would have to add the name of the remote domain to both the Domains Trusted By This Domain section and to the Domains That Trust This Domain section.
Another security feature built in to trust relationships is that any time you create a trust relationship, you must enter a password. When you specify a trusted domain, you must enter the administrative password for that domain. Likewise, when you are about to permit a remote domain to trust your domain, you must enter the remote domain’s password. This process ensures that administrators in both domains have full knowledge and final approval before any trust relationships are established.
Also, when you create a new trust, you can either enable transitive trusts or disable them. When you think about it, just because you want someone to trust your domain doesn’t necessarily mean you also want that domain to trust every domain that trusts you or every domain that you trust. Likewise, if you’re about to trust a remote domain, you don’t really know which other domains the administrator of that domain trusts or which domains trust that domain. For added security, a nontransitive, regular trust relationship may be the way to go.
Also, once you’ve created a trust, it might take anywhere from 15 minutes to an hour for the trust to become active. In the meantime, you can verify a trust by selecting the trust, clicking the Edit button, and then clicking Verify. In my experience, if you have one domain running in native mode and one domain running in mixed mode, the trust will sometimes fail to verify, even though it may be working correctly. The real test of a trust is to see if you can access the user list from the remote domain.
While it’s still sometimes necessary to implement trust relationships between Windows 2000 domains, the rules for doing so differ considerably from those in Windows NT. If you’re a Windows NT administrator who’s moving to a Windows 2000 environment, this guide to the new concepts and tools to make trusts work should put you on the right track. Then, you can make sure your users can access resources across your network no matter which domain they’re in.