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