A
feature of Windows Server 2008 R2’s AD DS implementation is the concept
of cross-forest transitive trusts. In essence, this enables 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 at
least Windows Server 2003 (or higher) functional levels.
The federated forest
design model is ideal for two different situations. One is to unite two
disparate AD DS 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 AD DS forests could take advantage of
this capability and link their two environments, as shown in Figure 1, 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.
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 interdomain 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 might 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 2,
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 other types of trusts,
cross-forest trusts are one-way by default. Unlike explicit trusts,
however, cross-forest trusts are transitive. 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 AD DS 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.
Exploring a Federated Forests Real-World Design Example
To illustrate a good example
of an organization that would choose a federated forest design model,
let’s consider fictional ConglomerateA, which is a food distributor with
multiple sites worldwide. It currently operates a Windows Server 2008
R2 AD DS 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.
ConglomerateA has recently
entered into a joint venture with SupplierA and wants to facilitate the
sharing of information between the two companies. SupplierA also
currently operates in a Windows Server 2008 R2 AD DS environment and
keeps all user and computer accounts in an AD DS 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 3.
Remember, 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.
