Windows Server 2008 R2 Unleashed (39 page)

replication traffic and the time associated with establishing remote domain con-

trollers. Windows Server 2003/2008 solves the issue of replication over the wide area

network (WAN) by providing you with the ability to save the global catalog to media

(like a CD-ROM), ship it to a remote site, and, finally, run domain controller promo-

tion (dcpromo) and insert the data disk with the directory on it for restoration. Only

the deltas, or changes made since media creation, are then replicated, saving time

and bandwidth. The effect of this on domain design creation is reflected in reduced

setup times, less network bandwidth consumption, and increased flexibility of global

catalog domain controller placement.

Choosing a Domain Structure

There is a basic tenet to consider when designing the AD DS domain structure. Start

simple, and then expand only if expansion is necessary to address a specific need. This

concept is, by and large, the most important concept to remember when you’re designing

AD DS components. In regard to domain design, this means you should always start the

ptg

design process with a single domain and then add on to your design if your organizational

concerns dictate that you do so. Following this basic philosophy during the design process

will reduce headaches down the road.

When you’re designing the AD DS, you must contemplate a common framework for

diagrams. In AD DS, for example, domains are often pictorially represented by triangles, as

shown in Figure 5.2. So, when beginning your design, start with a single triangle.

companyabc.com

FIGURE 5.2

Domain diagram representation as a triangle.

In this example, the fictional company named CompanyABC has begun the process of

domain design. Depending on its unique needs, CompanyABC might decide to expand

upon that model or keep it simplistic. These decisions should be made with a detailed

knowledge of the different domain design models and the environments in which they

work best.

Active Directory was designed to be a flexible, forgiving directory services implementa-

tion. This is even more true with Windows Server 2008 R2’s AD DS implementation.

Consequently, there are multiple design models available to choose from, depending on

the individual needs of organizations. The major design models are as follows:

Understanding the Single Domain Model

155

. Single domain model

. Multiple domain model

. Multiple trees in a single forest model

. Federated forests design model

. Peer-root model

. Placeholder domain model

. Special-purpose domain model

In reality, not all AD structures fall underneath these categories because the possibilities

exist for numerous variations and mutations of AD structure. However, most domain

structures either fall into these categories or are a hybrid model, possessing traits of two

different models. Out of all these models, however, the single domain model is the most

common design model and also happens to be the easiest to deploy.

Understanding the Single Domain Model

5

The most basic of all AD DS structures is the single domain model; this type of domain

ptg

structure comes with one major advantage over the other models: simplicity. A single

security boundary defines the borders of the domain, and all objects are located within

that boundary. The establishment of trust relationships between other domains is not

necessary, and implementation of technologies such as Group Policies is made easier by

the simple structure. More organizations than not can take advantage of this design

because AD DS has been simplified, and its capability to span multiple physical bound-

aries has been enhanced.

Choosing the Single Domain Model

The single domain model is ideal for many organizations and can be modified to fit many

more. A single domain structure possesses multiple advantages, first and foremost being

simplicity. As any administrator or engineer who has done work in the trenches can

confirm, often the simplest design works the best. Adding unnecessary complexity to the

system’s architecture introduces potential risk and makes troubleshooting these systems

more difficult. Consequently, consolidating complex domain structures into a simpler

single domain AD DS structure can reduce the costs of administration and minimize

headaches in the process.

Another advantage realized by the creation of a single domain is the attainment of

centralized administration. Many organizations with a strong central IT structure want the

capability to consolidate control over the entire IT and user structure. AD DS and, specifi-

cally, the single domain model allows for a high level of administrative control and the

ability to delegate tasks to lower sets of administrators. This has proven to be a strong

draw to AD DS.

156

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

Not all AD DS structures can be composed of a single domain, however, and some factors

might limit an organization’s ability to adopt a single domain structure. If these factors

affect your organization, you might need to begin expanding your domain model to

include other domains in the forest and a different domain design. For example, the single

security boundary formed by a single domain might not be exactly what your organiza-

tion needs. Organizational units (OUs) can be used to delegate administration of security

elements, but members of the Domain Admins group can still override permissions within

different OUs. If the security lines within your organization need to follow exact bound-

aries, a single domain might not be for you. For example, if your HR department requires

that no users from IT have access to resources within its environment, you will need to

expand your domain structure to accommodate the additional security concerns.

Another disadvantage of the single domain model is that a single domain in a forest

necessitates that the computer with the role of schema master is located in that domain.

This places the schema master within the domain that contains all the user accounts.

Although access to the schema master can be strictly controlled through proper adminis-

tration, your risk of schema exposure is greater when the schema master role resides in a

user domain. For example, members of the domain administrators group could override

the security of the schema administrators group and add their account to that group. If

this design model poses problems for you as an organization, design models that separate

the schema master into a placeholder domain can do the trick. The placeholder domain

ptg

model is described in more detail later in this chapter in the section “Understanding the

Placeholder Domain Model.”

Exploring a Single Domain Real-World Design Example

To illustrate a good example of an organization that would logically choose a single

domain model, let’s consider fictional CompanyA. CompanyA is a 500-user organization

with a central office located in Minneapolis. A few smaller branch offices are scattered

throughout the Midwest, but all help desk administration is centralized at the company

headquarters. CompanyA currently utilizes a single user domain and has multiple resource

domains in various locations across the country.

The IT team in Minneapolis is designing an AD DS structure and wants to centralize

administration at corporate headquarters. Branch offices should have the capability to

change passwords and clear print jobs locally, but should have no other form of adminis-

trative privilege on the network.

During the AD DS design process, CompanyA started with a single AD DS forest, domain,

and namespace named companya.net. Organizational units for each branch office were

added to delegate password-change control and print administration to those offices.

Current legacy Windows 2000 AD and Windows Server 2003 forests and domains were

consolidated into the AD DS structure, as shown in Figure 5.3. CompanyA could not

justify the existence of additional domains because their security model was centralized,

and it did not have any far-flung geographical locations with slow link speeds to the main

office or any other similar constraints that required additional domains.

Understanding the Multiple Domain Model

157

companya.net

Minneapolis

Grand Forks

Milwaukee

Crookston

Winnipeg

FIGURE 5.3

AD DS structure with organizational unit structure.

5

Delegation of password-change control and other local administrative functions was

granted to individuals in each specific geographical OU, which gave those administrators

ptg

permissions specific to only resources within their own group but maintained central

administrative control in Minneapolis. A detailed discussion of organizational unit design

is covered in Chapter 6, “Designing Organizational Unit and Group Structure.”

Several AD DS sites were created to control the frequency of replication. A site was posi-

tioned to correspond with each separate geographical area, creating a site structure similar

to the one shown in Figure 5.4.

Creating the separate sites helped to throttle replication traffic and reduce the load placed

on the WAN links between the sites. For more details about site links and replication, see

Chapter 7, “Active Directory Infrastructure.”

This type of single domain design is ideal for the type of organization described in this

section and actually can be used for many other types of organizations, large and small.

Because delegation of administration is now accomplished through the use of OUs and

Group Policy Objects, and the throttling of replication is accomplished through AD sites,

the number of reasons for organizations to use multiple domains has been reduced.

Understanding the Multiple Domain Model

For various reasons, organizations might need to add more than one domain to their envi-

ronment but preserve the functionality that is inherent in a single forest. When this

occurs, the addition of one or multiple domains into the forest is warranted. Domain

addition should not be taken lightly, however, and proper consideration must be given to

the particular characteristics of multiple domain models.

158

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

Site Structure

Minneapolis

companya.net

Grand Forks

Crookston

Winnipeg

ptg

Milwaukee

FIGURE 5.4

Site structure created by geographical locations.

By default, two-way transitive trusts exist between subdomains and domains in AD DS.

Bear in mind, however, that this does not mean that resource access is automatically

granted to members of other domains. A user in subdomain B is not automatically granted

any rights in domain A; the rights need to be explicitly defined through the use of groups.

Understanding this concept will help to determine the logistics of domain addition.

Choosing When to Add Additional Domains

As previously mentioned, it is advisable to begin your Windows Server 2008 R2 AD DS

design with a single domain and then add domains only when absolutely necessary.

Adding child domains to an existing domain structure might become necessary if the

following traits exist within an infrastructure:

.
Decentralized administration—
If different branches of an organization generally

manage their own IT structure and there are no future plans to consolidate them

into a centralized model, multiple interconnected domains might be ideal. Each

domain acts as a security boundary for most types of activity and can be set up to

disallow administration from escaping the boundaries of domains. This approach,

however, exposes many of the limitations associated with a multiple domain envi-

ronment. In other words, it is better to try to centralize administration before

deploying AD DS because you will gain more of AD’s advantages. It is also much

Understanding the Multiple Domain Model

159

better to organize administration along organizational unit boundaries than by

domains, so consider this option first.

.
Geographic limitations—
If extremely slow or unreliable links or great geographi-

cal distances separate different parts of your company, it might be wise to segment

the user population into separate domains. This will help to limit replication activity

between domains and also make it easier to provide support during business hours

for distant time zones. Keep in mind that slow links by themselves do not necessi-

tate the creation of multiple domains, as Windows Server 2008 R2 AD DS uses the

concept of AD DS sites to throttle replication across slow links. The main reason that

might exist for domain creation for geographical reasons is administrative flexibility.

In other words, if there is a problem with the network in Japan, a Japanese adminis-

trator will have more power to administer the Asia domain and will not need to call

the North American administrator in the middle of the night.