Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
.
Unique DNS namespace considerations—
If two organizational entities want to
use their Internet-registered namespace for AD DS but use a common forest, such as
hotmail.com or microsoft.com, those domains must be added as separate domains.
This type of domain model is described more fully in the “Understanding the
5
Multiple Trees in a Single Forest Model” section later in this chapter.
.
Enhanced security concerns—
Depending on the needs of your organization, sepa-
ptg
rating the schema master role into a domain separate from your users might be
applicable. In this case, the single domain model would not be applicable, and a
model such as the peer-root or placeholder domain would be more appropriate.
When contemplating additional domains, remember the mantra, “Simplicity is best.”
However, if during the design process, the specific need arises to add domains, proper
design is still warranted, or your environment will run the risk of becoming more ineffi-
cient than it could be.
Exploring a Multiple Domain Real-World Design Example
The following example illustrates an organization that would have grounds to establish
multiple domains. CompanyB is an engineering company based in York, Pennsylvania.
Administration for all branch locations is currently centralized in the home office, and
OUs and group policies are used for delegation of lower-level tasks. Recently, the company
acquired two separate companies named Subsidiary A and Subsidiary B; each contains its
own IT department and operates in separate geographical areas. CompanyB decided to
implement AD DS as part of a Windows Server 2008 R2 implementation and wanted to
include the two acquired companies into a single common forest.
Because each acquired company possesses its own IT department and there was no agree-
ment on the ownership of the Domain Admins accounts, CompanyB decided to deploy an
AD DS structure with two subdomains for Subsidiary A and Subsidiary B, as shown in
Figure 5.5.
160
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
companyb.com
subsidiarya.companyb.com
subsidiaryb.companyb.com
FIGURE 5.5
AD DS with two subdomains.
This design model allowed for a certain degree of administrative freedom with the newly
acquired subsidiaries but also allowed for a common forest and schema to be used and
kept the domains within the same DNS namespace.
This design model has the particular advantage of being politically easier to implement
ptg
than consolidation of existing domains. Branch offices and subsidiary companies can keep
their own domain structure and security boundaries, and their IT teams can retain a
greater deal of administrative autonomy.
Be warned, however, that consolidation of a larger number of domains into fewer domains
is a key feature of AD DS, so the addition of domains purely for political reasons adds
complexity and potentially unnecessary infrastructure. It is, therefore, very important to
consider the alternatives before deciding on this design model.
Understanding the Multiple Trees in a Single Forest
Let’s say that your organization wants to look at AD DS and wants to use an external
namespace for your design. However, your environment currently uses multiple DNS
namespaces and needs to integrate them into the same design. Contrary to popular
misconception, integration of these namespaces into a single AD forest can be done
through the use of multiple trees that exist in one forest. One of the most misunderstood
characteristics of AD DS is the difference between a contiguous forest and a contiguous
DNS namespace. Many people do not realize that multiple DNS namespaces can be inte-
grated into a single AD DS forest as separate trees in the forest. For example, Figure 5.6
shows how Microsoft could theoretically organize several AD DS domains that share the
same forest but reside in different DNS namespaces.
Only one domain in this design is the forest root—in this case, microsoft.com—and only
this domain controls access to the forest schema. All other domains, including subdo-
mains of microsoft.com and the other domains that occupy different DNS structures, are
Understanding the Multiple Trees in a Single Forest Model
161
hotmail.com
microsoft.com
msn.com
msnbc.com
Forest
Root
sales.microsoft.com
service.microsoft.com
FIGURE 5.6
Sample AD DS forest with multiple unique trees within the same forest.
members of the same forest. All trust relationships between the domains are transitive,
and trusts flow from one domain to another.
Choosing When to Deploy a Multiple Tree Domain Model
If an organization currently operates multiple units under separate DNS namespaces, one
option might be to consider a design such as this one. It is important to understand,
however, that simply using multiple DNS namespaces does not automatically qualify you
5
as a candidate for this domain design. For example, you could own five separate DNS
namespaces and instead decide to create an AD DS structure based on a new namespace
ptg
that is contiguous throughout your organization. Consolidating your AD DS under this
single domain could simplify the logical structure of your environment while keeping
your DNS namespaces separate from AD DS.
If your organization makes extensive use of its separate namespaces, you might want to
consider a design like this. Each domain tree in the forest can then maintain a certain
degree of autonomy, both perceived and real. Often, this type of design will seek to satisfy
even the most paranoid of branch office administrators who demand complete control
over their entire IT structure.
Examining a Multiple Tree Domain Real-World Design Example
To gain a greater understanding of the times an organization might use this particular
design model, examine the following AD structure. CityA is a local county governmental
organization with a loose-knit network of semi-independent city offices, such as the
police and fire departments that are spread out around the city. Each department
currently uses a DNS namespace for name resolution to all hosts and user accounts local
to itself, which provides different email addresses for users located in the fire department,
police department, and other branches. The following namespaces are used within the
city’s infrastructure:
. citya.org
. firedeptcitya.org
. policeofcitya.org
. cityalibrary.org
162
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
The decision was made to merge the existing network environments into a single AD DS
forest that will accommodate the existing departmental namespaces but maintain a
common schema and forest root. To accomplish this, AD DS was established with
citya.gov as the namespace for the root domain. The additional domains were added to
the forest as separate trees but with a shared schema, as shown in Figure 5.7.
cityalibrary.org
citya.org
firedeptcitya.org
policeofcitya.org
Forest
Root
FIGURE 5.7
Single AD DS forest with separate directory trees for departments..
The individual departments were able to maintain control over their individual security
and are disallowed from making changes in domains outside their control. The common
forest schema and global catalog helped to increase collaboration between the varying
organizations and allow for a certain amount of central administration.
This type of domain design is logically a bit messier but technically carries the same func-
tionality as any other single forest design model. All the domains are set up with two-way
transitive trusts to the root domain and share a common schema and global catalog. The
ptg
difference lies in the fact that they all utilize separate DNS namespaces, a fact that must
also be reflected in the zones that exist in DNS.
Understanding the Federated Forests Design Model
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 orga-
nizations with fully populated AD DS 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.
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
Understanding the Federated Forests Design Model
163
Two-Way Cross-Forest Trust
Forest
Forest
Root
Root
First Merged Company
Second Merged Company
Forest
Forest
FIGURE 5.8
Cross-forest trust between two completely different organizations needing to
share resources.
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
5
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 infor-
ptg
mation between the two forests to facilitate communication exchange.
This type of design is sometimes precipitated by a need for the complete isolation of secu-
rity 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 advan-
tage 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 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 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
164
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
One-Way Cross-Forest Trust
Forest
Forest
Root
Root
AD Forest for Military
AD Forest for Civilian
Branch of the Company
Branch of the Company
FIGURE 5.9
One-way cross-forest trust.
specific departments or areas to have complete control over their own forests, while allow-
ing for the transfer of information between the domains.
Exploring a Federated Forests Real-World Design Example
ptg
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 imple-
mentation across its entire organization. All computers are members of the forest with a