Windows Server 2008 R2 Unleashed (41 page)

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 5.10.

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 environ-

ment as such.

Understanding the Empty-Root Domain Model

165

Two-Way Cross-Forest Trust

conglomeratea.net

Forest

Forest

Root

Root

suppliera.com

supplierabranch.org

asia.conglomeratea.net

na.conglomeratea.net

sales.suppliera.com

europe.conglomeratea.net

Conglomerate A Forest

Supplier A Forest

FIGURE 5.10

Cross-forest trust between root domains in each forest.

5

Understanding the Empty-Root Domain Model

ptg

The schema is the most critical component of AD DS and should, therefore, be protected

and guarded closely. Unauthorized access to the schema master domain controller for a

forest can cause some serious problems and is probably the best way to corrupt the entire

directory. Needless to say, segregation of the keys to the schema from the user base is a

wise option to consider. From this concept was born the empty-root domain model,

shown in Figure 5.11.

Forest

Root

abcschema.root

companyabc.com

Users

Computers

Printers

FIGURE 5.11

Empty-root domain model with an unpopulated forest root.

In short, the peer-root domain model makes use of an unpopulated forest root domain

that exists solely to segregate the schema master function from the rest of the network.

166

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

In Figure 5.11, the companyabc.com domain is used for all user and computer accounts,

whereas the abcschema.root domain is the peer-root domain that holds the schema

master role for the company. Most users would not even be aware of the fact that this

domain exists, which makes it even more secure.

The one major disadvantage to this design model lies in the hardware costs. Because a

separate domain is necessary, at least one extra domain controller will be needed as part of

the design plan, and preferably two for redundancy issues. This domain controller for the

empty-root domain will not need to be the speediest machine because it will not perform

much work, but it should definitely be made redundant, because the forest-specific FSMO

roles will be handled by the machine.

NOTE

Instead of using a physical hardware system for the schema master, an organization

could choose to use Windows Server 2008 R2 Hyper-V virtualization and create virtu-

al domain controllers for the empty-root domain. This would help to reduce the costs

of deploying the empty-root model. Do be sure to treat these virtual machines with

the same respect as you would any other domain controller, with regular maintenance

and backups, as losing the forest root would be disastrous for the other domains in

the forest.

ptg

Determining When to Choose the Empty-Root Model

Security needs vary from organization to organization. A company that performs top-

secret work for the military is going to have drastically different security issues than a

company that manufactures toys. Consequently, if the needs of your organization require

a greater amount of security, the peer-root domain model might be the right one for you.

An additional advantage that this type of environment gives you is the flexibility to

rename domains, add domains, and essentially move in and out of subdomains without

the need to rename the forest. Although the domain rename tool exists in Windows

Server 2008 R2, undertaking this task is still complicated, and using the peer-root model

can help to simplify changes. In a merger, for example, if your peer root is named

root.network and all your resource domains are located in companyabc.com in the same

forest, it becomes much easier to add companya.net into your forest by joining it to the

root.network domain.

The beauty of the peer-root domain model is that it can be incorporated into any one of

the previously defined domain models. For example, a large grouping of trees with

published namespaces can have a forest root with any name desired.

The example shown in Figure 5.12 demonstrates how this type of environment could

conceivably be configured. The flexibility of AD DS is not limited by this design model

because the options available for multiple configurations still exist.

Of course, many organizations often cannot justify the increased hardware costs, and this

type of design model can prove to be more costly. Realistically, at least two domain

controllers need to be established in the root domain to handle authentication requests

Understanding the Placeholder Domain Model

167

microsoft.com

Forest

Root

msn.com

root.msft

hotmail.com

redmond.microsoft.com

tokyo.microsoft.com

europe.msn.com

asia.msn.com

sales.redmond.microsoft.com

FIGURE 5.12

The empty-root domain model using different domain tree names throughout

the forest.

and to provide for redundancy within the domain. Keeping these costs in mind, it is

important to align your organization’s security requirements with the cost-benefit ratio of

5

this design model.

ptg

Examining a Real-World Empty-Root Domain Design Example

CompanyD is a biomedical corporation centered in the San Francisco Bay area.

Infrastructure security is highly important for the organization, and the company needs to

ensure that directory information is safe and secure in the network environment. The IT

organization is centralized, and most employees are located at the main headquarters

building.

The administrators of CompanyD originally chose AD DS and Windows Server 2008 R2 to

provide for robust security for their environment and to take advantage of the increased

functionality. However, management was concerned about limiting access to vital compo-

nents of the directory service, such as the schema. Further investigation into the varying

domain design models for AD DS uncovered the peer-root domain model as a fully func-

tional substitute to the single domain model, but with the added schema security that

they desired. This resulted in a forest structure similar to the one shown in Figure 5.13.

Organizational units were created for each department and placed in the companyd.com

domain. The only user account in the rootd.peer domain is the Administrator account for

the forest. Access to this account was limited to a choice group of high-level administra-

tors. This helped to control access to the schema root for the security-conscious organiza-

tion and provided for the simplicity of a single domain environment for its users.

Understanding the Placeholder Domain Model

The placeholder domain model, also known as the sterile parent domain model,

deserves special mention because of its combination of a single namespace/multiple

domain model and the peer-root model. Simply put, the placeholder domain model,

168

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

Forest

Root

companyd.com

Administrator

rootd.peer

Sales

Corporate

Engineering

IT

Research

HR

FIGURE 5.13

Peer-root domain with schema security for added protection and integrity.

shown in Figure 5.14, is composed of an unoccupied domain as the forest root, with

multiple subdomains populated with user accounts and other objects.

companyabc.com

ptg

Unpopulated

Forest

Root

Placeholder Domain

asia.companyabc.com

na.companyabc.com

europe.companyabc.com

Computer

User

Printers

OUs

Objects

Objects

Subdomains

Populated with AD

Objects

FIGURE 5.14

Unpopulated placeholder domain.

There are two distinct advantages to this design. First, as with the peer-root model, the

schema is separate from the user domains, thus limiting their exposure and helping to

protect the schema. Second, the namespace for the user accounts is consistent in the

namespace, thus mitigating any potential political issues. In other words, because all users

in all locations are at the same logical level in the domain structure, no one group will

feel superior or inferior to another. This issue might seem trite, but the psychological

nature of humans is finicky, and you might find that this design offers advantages for

certain organizations.

Understanding the Special-Purpose Domain Design Model

169

Examining a Placeholder Domain Real-World Design Example

CompanyE is an architectural firm with major offices located in New York, Chicago, Los

Angeles, San Paulo, Rio de Janeiro, Berlin, Paris, London, Tokyo, Singapore, and Hong

Kong. Administration is centralized in New York, but regional administration takes place

in Rio de Janeiro, London, and Tokyo. The company has recently migrated to AD DS and

has chosen to deploy a placeholder domain model for its organization that looks similar

to Figure 5.15.

companye.com Forest

Root

Company E

Placeholder Domain

Structure

5

ptg

San Paulo

Rio de Janeiro

Paris

London

Berlin

sa.companye.com

europe.companye.com

New York

Chicago

LA

Singapore

Tokyo

Hong Kong

na.companye.com

asia.companye.com

FIGURE 5.15

Complex AD DS placeholder domain structure.

All users authenticate to geographically centric subdomains. In addition, the administra-

tors in New York have segregated the schema master function into the placeholder

domain, limiting its exposure and have limited access to this domain to a small group of

high-level administrators. Each domain is logically oriented as well, to give the impression

of autonomy to each geographical unit.

Understanding the Special-Purpose Domain Design

Model

A special-purpose domain or forest is one that is set up to serve a specific need. For

example, your organization might set up a special-purpose domain to house outside

contractors or temporary workers to limit their exposure to the main AD DS forest. In

170

CHAPTER 5

Designing a Windows Server 2008 R2 Active Directory

addition, trust relationships could be established between this domain or other domains

to allow for resource access.

Generally, there has to be a good reason before additional domains are deployed in AD

DS. Overhead is increased with each domain that is added to an environment, and your

logical network structure begins to look convoluted. However, in some unique cases, a

special-purpose domain might become necessary.

Another possible use for a separate special-purpose domain structure is to house a direc-

tory service–capable application that requires itself, for security or other reasons, to have

exclusive access to the schema. In other words, if your HR department runs an application

that stores confidential employee information in an application that utilizes an LDAP-

compliant directory, such as AD DS, a domain could be set up for that application alone.

A cross-forest trust relationship can be established to allow for the sharing of information

between the two environments. This type of situation is rare because most of these appli-

cations make use of their own directory, but it is possible. Because the AD DS schema

must be unique across the forest, this would preclude the use of a single forest if these

applications require exclusive access or utilize common schema attributes. This concept,

known as Active Directory Lightweight Domain Services (AD LDS), is further elaborated in

Chapter 8, “Creating Federated Forests and Lightweight Directories.”