One of the Windows Server 2003 features that I think is the most under utilized is the forest level trust. As the name implies, a forest level trust is a trust between two separate forests, through which every domain trusts every other domain. There are lots of reasons why you might want to create forest level trusts. There are so many reasons in fact, that I could probably dedicate an entire article to the subject.
One of the most common uses of forest level trusts has to do with corporate acquisitions. For example, if your company were to purchase another company, you might want to create a forest level trust between the two networks until you can eventually merge the networks together.
Another common use for forest level trusts is Active Directory isolation. For example, I am involved in the beta testing for Exchange Server 2007. Because of the way that Exchange Server uses the Active Directory, I can’t install Exchange 2007 into my production forest without affecting my Exchange Server 2003 deployment. As such, I created an entirely separate forest through which I can run Exchange 2007. Since I still need to be able to capture screen shots and save them to my production network, I have created a forest level trust between the two forests.
The Four Types of Trusts
Although this article’s primary focus is on trusts between forests, I wanted to take a moment and mention that there are actually four different types of trusts that are supported by Windows Server 2003. These four types of trusts each have their own unique purposes.
The first type of trust is an external trust. An external trust is a trust relationship in which a domain within your forest trusts a domain that does not belong to the forest. Typically, these types of trusts are most often used for migrations. In Windows 2000 and 2003, a forest can contain multiple domains. However, in Windows NT Server, there was no concept of a forest. A domain was its own, self contained autonomous unit. If you need to migrate resources from a Windows NT domain into an existing Active Directory forest, then establishing an external trust between one of the Active Directory domains and the Windows NT domain is often the first step.
The second type of trust that’s supported by Windows Server 2003 is what’s known as a shortcut trust. As I’m sure that you probably know, the Active Directory is designed so that every domain in a forest automatically trusts every other domain in a forest. What this means is that if a user from one domain has been granted permissions to access a resource in another domain, then the user can transparently authenticate through a domain controller within the resource domain.
Most of the time this global trust within a forest works pretty well. However, there are some cases in which a forest is so large, and is made up of so many domains, that it takes a workstation quite a while to locate a resource domain. This is particularly true of domains that exist across WAN links. This is where the shortcut trust comes into play. A shortcut trust doesn’t give either domain access to anything new, but rather it just sort of introduces the two domains to each other. Once the shortcut trust is in place, the two domains can access each other directly without having to traverse the forest in an attempt to locate a domain controller.
The third type of trust is a realm trust. The concept of domains are not unique to Windows networks. Other network operating systems include similar structures, they just call them something different. The UNIX equivalent to a domain is a realm. If a UNIX realm is designed to use Kerberos authentication, then it is possible to create a realm trust between a Windows domain and a UNIX realm.
The fourth type of trust is of course the forest trust. Forest trusts only exist in Windows Server 2003. What this means is that you can not create a trust between a Windows 2000 forest and a Windows Server 2003 forest. Creating a forest trust has the implication of creating external trusts between each of the forest’s domains. For example, if you were to create a trust between Forest A and Forest B, then every domain in Forest A would trust every domain in Forest B, and visa versa.
The Prep Work
Before you can create a trust between forests, you must do a little bit of prep work to prepare the forests that will be involved in the trusts. The first thing that you must do is to raise the forest functional level of the two forests to Windows Server 2003. To do so, select the Active Directory Domains and Trusts command from the server’s Administrative Tools menu. When the console opens, right click on the Active Directory Domains and Trusts container and select the Raise Forest Functional Level command from the resulting shortcut menu. When the Raise Forest Functional Level dialog box appears, select the Windows Server 2003 option and click the Raise button.
The next step in preparing to create a forest level trust is that you must make sure that each forest’s root domain can see the root domain from the other forest. This means that you will have to create the necessary DNS records and use the NSLOOKUP command to make sure that you can resolve domain names in the other forest.
Finally, you must make sure that you know the username and password for a forest level administrator account in each forest.
Creating Forest Trusts
Now that you have completed all of the prep work, you can begin the trust creation process by opening the Active Directory Domains and Trusts console. When the console opens, locate the forest’s root domain. You can only create a forest trust at the root domain level. Once you locate the root domain, right click on it and select the Properties command from the resulting shortcut menu. When you do, you will see the domain’s properties sheet.
At this point, you must select the properties sheet’s Trust tab, shown in Figure A. Click the New Trust button to launch the New Trust wizard.
Figure A: Click the New Trust button to create a trust
When the wizard starts, click Next to bypass the wizard’s Welcome screen. At this point, the wizard will prompt you to enter the domain, forest, or realm name of the trust. This screen can be a little bit confusing, but all you have to do is to type the domain name of the root domain in the forest that you would like to establish the trust with.
Click Next and the wizard will ask you if you are creating a realm trust or a trust with a windows domain. Select the Windows domain option and click Next. At this point, you will see what is probably the most important question asked by the wizard. The wizard wants to know if you will be creating an external trust or a forest trust. Choose the Forest Trust option and click Next.
At this point, you will see a screen asking you if you want to establish a one way incoming, a one way outgoing, or a two way trust. A trust has two sides. For example, imagine that you have two domains named A and B. Now imagine that domain A contains resources that users in Domain B need access to. In a situation like this, domain A would be the trusting domain, and Domain B would be the trusted domain. In this particular instance, a two way trust would not be appropriate because users in Domain A do not need access to anything in Domain B. A lot of times in real life though, a two way trust is the most appropriate choice.
For the purposes of this article, I am assuming that you have chosen a two way trust. You will now be asked if you want to configure only your own side of the trust or both sides of the trust. What this is referring to is the fact that you will need an administrative password for both domains in order to establish the trust. If you only have the administrative password for your own domain, then you will have to choose the This Domain Only option and the administrator of the other domain will have to repeat the procedure on their end with their own password. If you know both passwords though, it’s a lot simpler to configure both sides of the trust at the same time.
Click Next and Windows will ask you if you want to perform Forest Wide Authentication or Selective Authentication. Selective Authentication allows you to fine tune the authentication process, but it involves a lot more work. Most of the time you will be fine using Forest Wide Authentication.
Click Next and you will see a summary of the options that you have chosen. Click Next one last time and the trust will be established. When the process completes, you will see a message asking you if you want to confirm the link between the forests. Go ahead and try to confirm the link, but keep in mind that Microsoft has had problems with this particular piece of code. Sometimes it works and sometimes it doesn’t. If the confirmation process fails, it doesn’t necessarily mean that the trust hasn’t been established.
Conclusion
As you can see, there are some situations in which you may need to trust users from another forest. In this article, I have explained how you can create such a trust.
