Examining Domain Design Features
153
Examining Domain Design Features
AD DS has evolved over the years and has added additional functionality with Windows
Server 2003, Windows Server 2003 R2, Windows Server 2008, and, finally, Windows
Server 2008 R2. Some of these functionality improvements have changed some of the
design concepts associated with Windows Server 2008 R2. These functionality changes are
as follows:
 Active Directory Recycle Bin—The ability to do a full-fidelity recovery of deleted
objects in AD DS was introduced in this latest version of AD DS included with
Windows Server 2008 R2. By adding this critical functionality, there is less worry
that accidental deletion of user accounts, groups, or even entire OUs will cause
major havoc, and there is subsequently less reason to create multiple domains in a
forest simply to spread the risk of domain object deletion. Note that this capability
is only available when the forest functional level is raised to Windows Server 2008
R2 functional level and when it is subsequently turned on in a domain. More information about this topic can be found in Chapter 4, “Active Directory Domain
Services Primer.”
within a single domain was originally released in Windows Server 2008 and is still
supported with Windows Server 2008 R2. The addition of this functionality means
that many organizations that previously implemented additional domains because
of the restriction of a single password policy per domain might be able to collapse
those domains. Note that this functionality is only available in either Windows
Server 2008 or Windows Server 2008 R2 domain functional levels. For more information on using fine-grained password policies, see Chapter 4.
 Domain rename function—The capability to rename a domain in a Windows
Server 2003/2008 forest has opened up a new field of possibilities for the design and
potential redesign of AD DS domain structures. Previously, stern caveats were issued
about the inability to rename domains or change the overall structure of an AD DS
forest. With the domain rename functionality present in AD DS implementation,
these limitations are lifted, and designers can take heart in the fact that design
changes can be made after implementation. Having this ability does not change the
fact that it is still wise to plan out your domain design thoroughly, however. Not
having to make changes to domain names or reposition domains in a forest is much
easier than having to go through the domain rename process. Just knowing that
such functionality exists, however, is a breath of fresh air for designers.
 Cross-forest transitive trusts—Introduced in Windows Server 2003, the concept of
cross-forest transitive trusts lessens domain designers’ connectivity worries. In the
past, some administrators balked at the limitations of collaboration within Windows
2000 AD DS structures. The cross-forest transitive trust capability of AD DS negates
those concerns because multiple AD DS forests can now be joined via cross-forest
trusts that are transitive, rather than explicit, in nature. The combination of these
forests is known in the Microsoft world as federated forests. Note that both forests
5
 Fine-grained password policies—The ability to have multiple password policies
154
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
must be at Windows Server 2003 or Windows Server 2008 R2 functional levels for
this feature to work.
 Domain controller promotion from media—The capability to promote remote
servers to domain controllers via a CD image of the global catalog helps to limit
replication traffic and the time associated with establishing remote domain controllers. 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 promotion (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
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 implementation. 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.
The most basic of all AD DS structures is the single domain model; this type of domain
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 boundaries 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, specifically, 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.
5
Understanding the Single Domain Model
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 organization 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 boundaries, 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 administration, 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
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 administrative 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
Delegation of password-change control and other local administrative functions was
granted to individuals in each specific geographical OU, which gave those administrators
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 positioned 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 environment 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.
5
FIGURE 5.3 AD DS structure with organizational unit structure.