Microsoft Windows Server 2003 Unleashed (R2 Edition)

A new feature of Windows Server 2003's Active Directory implementation is the addition of cross-forest transitive trusts. In essence, this allows you to establish transitive trusts between two forests with completely separate schemas that allow users between the forests to share information and to authenticate users.

The capability to perform cross-forest trusts and synchronization is not automatic, however, because the forest functionality of each forest must be brought up to Windows Server 2003 functionality levels. What this means is that all domain controllers in each forest must first be upgraded to Windows Server 2003 before any cross-forest trusts can be established. This can prove to be a difficult prospect for organizations already deployed with Windows 2000. Consequently, the federated forest design model is easier to consider if you do not currently have an Active Directory structure in place.

The federated forest design model is ideal for two different situations. One is to unite two disparate Active Directory structures in situations that arise from corporate acquisitions, mergers, and other forms of organizational restructuring. In these cases, two AD forests need to be linked to exchange information. For example, a corporate merger between two large organizations with fully populated Active Directory forests could take advantage of this capability and link their two environments, as shown in Figure 5.8, without the need for complex domain migration tools.

In this example, users in both forests now can access information in each other's forests through the two-way cross-forest trust set up between each forest's root.

Note

Windows Server 2003 R2 introduced the concept of Active Directory Federation Services (ADFS), which effectively makes it easier to administer and provision users in disparate forests. More information on ADFS can be found in Chapter 8, "Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories."

The second type of scenario in which this form of forest design could be chosen is one in which absolute security and ownership of IT structure are required by different divisions or subsidiaries within an organization, but exchange of information is also required. For example, an aeronautics organization could set up two AD forests, one for the civilian branch of its operations and one for the military branch. This would effectively segregate the two environments, giving each department complete control over its environment. A one- or two-way cross-forest trust could then be set up to exchange and synchronize information between the two forests to facilitate communication exchange.

This type of design is sometimes precipitated by a need for the complete isolation of security between different branches of an organization. Since the release of Active Directory in Windows 2000, several inter-domain security vulnerabilities have been uncovered that effectively set the true security boundary at the forest level. One in particular takes advantage of the SIDHistory attribute to allow a domain administrator in a trusted domain in the forest to mimic and effectively seize the schema admin or enterprise admin roles. With these vulnerabilities in mind, some organizations may choose separate forests, and simply set up trusts between the forests that are specifically designed to strip off the SIDHistory of a user.

In Figure 5.9, a one-way cross-forest transitive trust with SIDHistory-filtering enabled was set up between the civilian branch and the military branch of the sample aeronautics organization. In this example, this setup would allow only accounts from the military branch to be trusted in the civilian branch, in essence giving the military branch users the ability to access files in both forests. As with NT domains, cross-forest trusts are one-way by default. Unlike NT trusts, however, cross-forest trusts in Windows Server 2003 can be transitive if both forests are running at Windows Server 2003 functional levels. To set up two-way transitive trusts, you must establish two one-way trusts between the two forest roots.

Determining When to Choose Federated Forests

The concept of federated forests greatly enhances the abilities of Active Directory forests to exchange information with other environments. In addition, organizations that were reluctant to implement AD because of the lack of a solid security boundary between domains can now take heart in the capability of the federated forest design to allow specific departments or areas to have complete control over their own forests, while allowing for the transfer of information between the domains.

A Federated Forest Real-World Design Example

To illustrate a good example of an organization that would choose a federated forest design model, let's consider fictional Conglomerate A, which is a food distributor with multiple sites worldwide. It currently operates a Windows Server 2003 Active Directory implementation across its entire organization. All computers are members of the forest with a namespace of companyb.net. A root domain exists for conglomeratea.net, but it is not populated because all users exist in one of three subdomains: asia, europe, and na.

Conglomerate A has recently entered into a joint venture with Supplier A and would like to facilitate the sharing of information between the two companies. Supplier A also currently operates in a Windows Server 2003 Active Directory environment and keeps all user and computer accounts in an Active Directory forest that is composed of two domains in the suppliera.com namespace and a separate tree with a DNS namespace of supplierabranch.org that reflects a certain function of one of its branches.

The decision was made to create a cross-forest trust between the two forests so that credentials from one forest are trusted by the other forest and information can be exchanged. The cross-forest trust was put into place between the root domains in each forest, as shown in Figure 5.10.

Remember, that just as in NT 4.0, a trust does not automatically grant any permissions in other domains or forests; it simply allows for resources to be implicitly shared. Administrators from the trusting domain still need to manually grant access. In our example, administrators in both forests can decide what resources will be shared and can configure their environment as such.