Windows Server 2008 R2 Unleashed (40 page)

.
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

Model

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