Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
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
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.
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
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
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,