When I worked for the Army years ago, the current server operating system was Windows NT 4.0. I remember trust relationships being especially difficult to deal with, because every unit had their own Windows NT domain with their own administrator. What made this situation so difficult to deal with was that Army regulations mandated that the Department of Information Management (my office) had to have a trust relationship with all of the other domains that existed on the base.
To establish this trust relationship, we had to manually tell our domain to establish a trust with the remote domain. The administrator of the remote domain then had to manually establish a trust with us. Of course there were passwords that had to be entered each time a trust was established, and sharing those passwords became a major political issue.
Creating trust relationships in the manner that I just described simply meant that every domain on the base trusted users from my office and that my office trusted users from every other domain. These trust relationships did not create trusts between any of the remote domains. If trusts were required between remote domains, the administrators of those domains had to submit the proper paper work to use, we then had to review the security implications of creating such a trust and then manually establish the trust.
Trust relationships were a major pain for us. Because there were so many domains on the base, there were countless individual trust relationships that we had to maintain. There were also lots of situations in which we had to destroy and recreate trusts because they would suddenly stop working for no apparent reason.
Now that I have told you one of my “war stories” from my Army days, let’s fast forward to the present. Windows Server 2003 does away with the problems that I described above (as does Windows 2000 Server). In Windows Server 2003, a domain is not an independent entity as it was in Windows NT Server. Instead, a domain is considered to be an object within the Active Directory. All objects within the Active Directory (including domains) are considered to be a part of a forest.
The interesting thing about having domains exist as a part of a larger structure (the forest) is that the forest has knowledge of all of the domains that fall within it. Furthermore, no one can just create a new domain and have it exist as a part of an existing forest unless they have the appropriate administrative credentials.
Because the forest knows about all of the domains within it, and because each domain has been authorized by a forest level administrator (a member of the Enterprise Admins group), all of the domains within a forest are assumed to be trustworthy. Therefore, Windows creates an automatic trust relationship between every domain in a forest and every other domain in the forest.
Since every domain automatically trusts every other domain, you might assume that there is no reason for anyone to ever run into a situation like my nightmare with the Army ever again, as long as all of the domains are Active Directory based. In a way, this is true. If I were working for the Army today, it is certainly conceivable that I could create a forest that spans the entire base. Each unit could still maintain their own domain, but the domain would be a part of the forest and forest wide trust relationships would be automatically created. In fact, I know of several large companies that have their networks configured in exactly that way.
Although the forest-wide trust greatly simplifies administration, it isn’t always appropriate. For example, consider my earlier example with the Army. A forest that spans the entire base would not be appropriate in that situation because of the fact that many of the units deal with classified information.
Just to be perfectly clear, I want to point out that having one domain trust another domain does not automatically give users in the trusted domain access to any of the resources in the trusting domain. It is up to that domain’s administrator to grant permissions. Even so, a forest that spans an entire Army base would not be appropriate for the military because the Army would not want to risk having an Administrator grant permissions to access classified materials to someone in a different domain, either intentionally or maliciously.
OK, so the Army has a lot of picky rules and red tape, so what about a corporation? Well, there are even situations in the corporate world in which a company-wide forest is a bad idea. Imagine for a moment that you work for a large company with offices in many different cities. Now imagine that the company’s network is structured so that the company has only a single forest, and each individual office has its own domain within that forest. At first, this structure doesn’t sound too bad. It might even seem logical. Keep in mind though that the feasibility of such a design all boils down to trust.
For example, imagine that you are the network administrator in our fictitious company’s Miami, Florida office. One day you get a phone call from the corporate headquarters and they want you to grant access to a particular file share to the Marketing group in the Las Vegas, Nevada office. Remember that the Las Vegas office consists of an independent domain over which you have absolutely no control. You could blindly obey the corporate headquarters and assign the required rights, but remember that you have no control of the Marketing group’s membership. The best that you can do is to hope that the network administrator in Las Vegas would not make someone who would do harm to your resources, a member of the Marketing group.
As you can see, it all boils down to trust. The question is how much trust do you have in the administrators of the other domains? What if one of the other administrators is focused on network domination? Normally, a domain level administrator has administrative permissions over their own domain, but not over the forest. This means that they have absolutely no control over any of the other domains. However, all an administrator needs in order to become a forest level administrator is to have their account added to the Enterprise Admins group. There are numerous elevation of privilege exploits that can be used to add a user to the Enterprise Admins group. Since the user in question is already a domain administrator, such exploits become much easier to pull off. To put it simply, it wouldn’t take a lot for a domain level administrator to promote themselves to a forest wide administrator. Once they do, they have full control over every domain in the forest, including yours.
As you can see, there are lots of situations in which full trusts are not exactly desirable. If your company needs a little more isolation between domains for security reasons, consider implementing multiple forests rather than having a single forest.
What’s neat about having multiple forests is that you can create trust relationships between forests where necessary. However, when ever a trust is created between forests, the trust exists only between the domains that explicitly approved the trust. For example, suppose that a domain named Posey was a part of a multi domain forest. As a part of that forest, a trust relationship would automatically exist between the Posey domain and every other domain in the forest. Now, suppose that the Administrator of the Posey domain decided to create an external trust with another forest. The administrator wouldn’t be able to tell the domain to trust the entire forest, because external trusts can only be created at the domain level. Therefore, the administrator would have to explicitly specify which domains within the external forest that they would like to trust.
Imagine that the Administrator of the Posey domain created a bunch of external trusts without his company’s forest level administrator’s knowledge. It doesn’t matter because these trusts can’t undermine the forest’s security. Just because the Posey domain chooses to trust some domains from an external forest, it doesn’t mean that other domains in the same forest as the Posey domain will honor that trust. In fact, as far as the other domains are concerned, the trust does not even exist. It the other domains in the forest want to honor the external trusts, the administrators of those domains must explicitly define the trust relationships from their own domain to the external domains.
As you can see, there are times when having every one of your company’s domains trust each other is a major security risk. In these situations, you can isolate domains or groups of domains by creating separate forests. You can then create external trust relationships that allow certain domains to trust other external domains without fear of accidentally establishing unintentional trusts.