Windows Server 2008 R2 Unleashed (46 page)

and effectively administer its own environments without the need for broad, sweeping

administrative powers over the entire domain.

Best Practices

193

Berlin IT Admins

Global

Europe OU DL

Delegation of

Europe

Control

Kiev IT Admins

Global

FIGURE 6.14

Nested delegation of control.

The added advantage of this design is that it is completely flexible, and administrative

control can be redelegated on the fly, so to speak. For example, if a branch office opens in

Paris, and IT administrators in that location need to have equivalent administrative

control over the Europe OU, a simple global group can be created and added as a member

to the Europe OU DL domain local group. Removing permissions is subsequently straight-

forward. In addition, entire OU memberships can effectively be collapsed into a different

OU structure, as required by the changing needs of different organizations.

ptg

Summary

6

Without some form of logical organization of users within your network environment,

chaos reigns and administration grinds to a halt. Administrators need some way to lasso

groups of users together into logically identifiable groupings so that changes, security priv-

ileges, and administration can be accomplished en masse. AD DS was specifically designed

to be extremely scalable in regard to administrative functionality, and the flexibility of

organizational unit and group design is a testament to this strength. Proper design of both

OU and group structure will go a long way toward helping gain control and reduce over-

head in a domain environment.

Best Practices

The following are best practices from this chapter:

. Move your user and computer objects into an OU structure, as opposed to the

default Users and Computers containers, as Group Policy Objects cannot be applied

to the container objects.

. Create critical OUs with Deletion Protection enabled, to avoid accidental deletion.

Enable the Active Directory Recycle Bin to be able to recover OUs and their objects if

they have been deleted.

. Keep the OU structure as simple as possible, and only expand on the design if there

is a specific reason to do so.

194

CHAPTER 6

Designing Organizational Unit and Group Structure

. Do not nest OUs more than 10 layers deep, and preferably keep them less than 3

layers deep if possible.

. Use the principles of role-based access control (RBAC) to control access to resources.

. Apply Group Policy to members of groups through Group Policy Security Filtering to

avoid the creation of OUs simply for the sake of creating group policies.

. Use domain local groups to control access to resources, and use global groups to

organize similar groups of users.

. Use distribution groups or mail-enabled security groups to create email distribution

lists in environments with Exchange Server.

. Mail-enable security groups if separation of security and email functionality is not

required. Alternately, use distribution groups if separation is required.

. Don’t simply delete and re-create groups on the fly because each group SID is unique.

. Don’t use local groups for permissions in a domain environment.

ptg

CHAPTER 7

IN THIS CHAPTER

Active Directory
. Understanding AD DS

Replication in Depth

Infrastructure
. Understanding Active Directory

Sites

. Planning Replication Topology

. Outlining Windows Server 2008

R2 IPv6 Support

In an ideal world, all areas of your network would be

. Detailing Real-World

connected with high-capacity links, and every server would

Replication Designs

communicate with each other without latency or conges-

. Deploying Read-Only Domain

tion. Alas, no real networks work this way, and traffic

Controllers (RODCs)

concerns must be taken into consideration in all but the

smallest, single-server Active Directory Domain Services (AD

DS) structure. Windows Server 2008 R2 expands upon the

AD DS replication capabilities introduced with the original

Active Directory implementation in Windows 2000 Server

ptg

with a range of new features and functionality.

Consequently, the introduction of these new capabilities

greatly increases the capabilities of AD DS and also changes

some of the fundamental design elements of Active

Directory (AD) replication.

This chapter focuses on the definition of the components of

Windows Server 2008 R2’s AD DS that make up its replica-

tion topology. It details design strategies for AD DS sites and

provides real-world examples to illustrate the principles

behind them. The concept of Read-Only Domain

Controllers (RODCs) and how they can be deployed in

remote sites is covered. In addition, Windows Server 2008

R2’s support for IPv6 (Internet Protocol version 6) is

outlined and described.

Understanding AD DS Replication

in Depth

Windows Server 2008 R2 improvements in AD DS replica-

tion are directly drawn from lessons learned in Windows

2000, Windows Server 2003, and Windows Server 2008.

196

CHAPTER 7

Active Directory Infrastructure

Read-Only Domain Controllers (RODCs) can be created in remote sites to reduce replica-

tion and increase security. Replication compression can now be disabled in well-connected

sites, enabling designers to sacrifice bandwidth for processor utilization in domain

controllers (DCs). In addition, concepts such as DC promotion from media allow global

catalog servers to be created from CDs or other media, which greatly increases DC place-

ment flexibility. Other improvements, such as universal group caching on domain

controllers, allow remote domain controllers to function as global catalog servers by

caching frequently used universal group membership locally.

Many of these improvements to AD DS replication were introduced with Windows Server

2008 and, although there are few new replication-specific improvements in Windows

Server 2008 R2, this latest version cements these new features and fixes design limitations

that have thwarted replication plans in the past. Problems with replication design can

potentially cripple a network; therefore, it is wise to put some serious thought into the

proper layout and design of an effective replication scheme.

Understanding the Role of Replication in AD DS

All enterprise directory environments must include mechanisms to synchronize and

update directory information across the entire directory structure. In Windows Server

2008 R2 AD DS, this means that every domain controller must be updated with the most

ptg

recent information so that users can log on, access resources, and interact with the direc-

tory accurately.

AD DS differs from many directory services implementations in that the replication of

directory information is accomplished independently from the actual logical directory

design. The concept of AD DS sites is completely independent from the logical structure of

AD DS forests, trees, and domains. In fact, a single site in AD DS can actually host domain

controllers from different domains or different trees within the same forest. This allows for

the creation of a replication topology based on a wide area network (WAN) structure,

while the directory topology can mirror the organization’s structure.

Outlining Multimaster Topology Concepts

AD DS was specifically written to allow for the creation, modification, and deletion of

directory information from multiple domain controllers. This concept, known as multi-

master replication, allows no one domain controller to be authoritative. If any domain

controllers go out of service, any one of the rest of the writable domain controllers can

make changes to directory information. Those changes are then replicated across the

domain infrastructure. Of course, there needs to be some level of control on this type of

replication so that only the most recent changes take precedence. This type of control is

realized in AD DS through the concept of Update Sequence Numbers (USNs).

Explaining Update Sequence Numbers (USNs)

All enterprise directory services implementations require a mechanism to handle the

incremental storage of changes made to directory objects. In other words, whenever a

password is changed, that information must be accurately passed to all domain controllers

Understanding AD DS Replication in Depth

197

in the domain. This mechanism must also be able to apply only those changes that

occurred at the most recent intervals.

Many directory services implementations relied on exact time synchronization on all

domain controllers to synchronize information. However, keeping the clocks of multiple

servers in sync has been proven to be extremely difficult, and even slight variations in

time could affect replication results.

Thus was born the concept of the Update Sequence Number. AD DS utilizes USNs to

provide for accurate application of directory changes. A USN is a 64-bit number that is

maintained by each domain controller in AD DS. The USN is sequentially advanced upon

each change that is made to the directory on that specific server. Each additional domain

controller also contains a copy of the last-known USN from its peers. Updates are subse-

quently made to be more straightforward. For example, when requesting a replication

update from Server2, Server1 will reference its internal table for the most recent USN that

it received from Server2 and request only those changes that were made since that specific

number. The simplicity of this design also ensures accuracy of replication across the

domain environment.

The integrity of replication is ensured with USNs because the USN number is updated only

upon confirmation that the change has been written to the specific domain controller.

This way, if a server failure interrupts the replication cycle, the server in question will still

ptg

seek an update based on its USN number, ensuring the integrity of the transaction.

Describing Replication Collisions

The concept of USNs does not completely eliminate the role of proper time synchroniza-

tion in AD DS. It is still important to maintain accurate time across a domain environ-

7

ment because of the possibility of replication collisions. A replication collision is an

inaccuracy in replicated information that takes place because of changes that are enacted

on the same object, but before that change has been replicated to all domain controllers.

For example, if an administrator resets a user’s password on Server1, and another adminis-

trator resets the same user’s password on Server2 before Server1 has had a chance to repli-

cate that change, a replication collision will occur. Replication collisions are resolved

through the use of property version numbers.

Understanding Property Version Numbers

Property version numbers are applied as an attribute to all objects within AD DS. These

numbers are sequentially updated and time-stamped whenever a change is made to that

object. If a replication collision occurs, the property version number with the latest time

stamp will be enacted, and the older change will be discarded. In the example from the

preceding section, the password change with the latest time stamp will be applied to the

user.

This concept subsequently requires accurate time synchronization to be a priority for an

AD DS domain—although it is not as critical as in other directory services implementa-

tions that rely on it for all replication activity.

198

CHAPTER 7

Active Directory Infrastructure

WINDOWS TIME

Time is an important aspect in AD DS. Kerberos is the native authentication mecha-

nism used by Windows AD DS and bases its ticketing system on an accurate time

source. If two machines in the same domain differ by more than five minutes, authenti-

cation will break. As such, accurate time must be shared among domain members.

Windows Server 2008 R2 utilizes the Windows Time Service and the domain hierarchy

to maintain a consistent source of time among all the domain controllers throughout

the domain.

One server, the PDC emulator, is responsible for getting accurate time from a manual

trusted source, such as NIST, time.windows.com, pool.ntp.org, or a GPS clock. This

trusted source is known as stratum 0. The PDC emulator is stratum 1. Stratum 2 goes

to all other DCs in the same site as the PDC emulator. The bridgehead server in

remote sites is stratum 3 and all other DCs in the same remote site are stratum 4.

Member computers will try to get time from the lowest stratum DC in their own site. If

that DC is not serving time, they will use the next highest stratum.

Domain computers always honor this system, which explains why the clock will reset to

the domain time automatically, even if you change the local clock. Time normally syncs

at startup and every 45 minutes thereafter for three consecutive, successful times,