Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
. Understanding the Placeholder
that, theoretically, organizations of every shape and size
Domain Model
should be able to implement the technology. For obvious
reasons, this means that the structure of the AD DS forest
. Understanding the Special-
Purpose Domain Design Model
will vary from organization to organization.
. Renaming an AD DS Domain
This chapter focuses on best practices for AD DS design,
including a discussion of the specific elements that
compose AD DS, such as feature upgrades added in this
latest version, Windows Server 2008 R2. Various domain
design models for AD DS are presented and identified with
specific real-world scenarios. The domain rename procedure
is outlined as well, to provide for an understanding of how
the concept affects domain design decisions.
Before any domain design decisions can be made, it is
important to have a good grasp of AD DS’s domain struc-
ture and functionality. Some fairly major changes have
150
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
been made in Windows Server 2008 R2 that require a reintroduction to the domain design
process. In addition, real-world experience with AD domain design has changed some of
the assumptions that were made previously.
Examining Domain Trusts
Windows Server 2008 R2’s AD DS domains can be linked to each other through the use
of a concept known as trusts. A trust is essentially a mechanism that allows resources in
one domain to be accessible by authenticated users from another domain. AD trusts take
on many forms but typically fall into one of the four categories described in the follow-
ing sections.
Transitive Trusts
Transitive trusts are automatic two-way trusts that exist between domains in the same
forest in AD DS. These trusts connect resources between domains in AD DS and are differ-
ent from explicit trusts in that the trusts flow through from one domain to the other. In
other words, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A
trusts Domain C. This flow greatly simplifies the trust relationships between Windows
domains because it forgoes the need for multiple exponential trusts between each domain.
ptg
Explicit Trusts
An explicit trust is one that is set up manually between domains to provide for a specific
path for authentication sharing between domains. This type of trust relationship can be
one-way or two-way, depending on the needs of the environment. In other words, all
trusts in legacy Windows NT 4.0 could have been defined as explicit trusts because they all
are manually created and do not allow permissions to flow in the same way as transitive
trusts do. The use of explicit trusts in AD DS allows designers to have more flexibility and
to be able to establish trusts with external and down-level domains. All trusts between AD
DS domains and other forest domains that aren’t in Windows Server 2003, Windows
Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2 forest functional level
are explicit trusts.
Shortcut Trusts
A shortcut trust is essentially an explicit trust that creates a shortcut between any two
domains in a domain structure. For example, if a domain tree has multiple subdomains
that are many layers deep, a shortcut trust can exist between two domains deep within
the tree, similar to the shortcut trust shown in Figure 5.1. This relationship allows for
increased connectivity between those two domains and decreases the number of hops
required for authentication requests. Normally, those requests would have to travel up the
transitive trust tree and back down again, thus increasing overhead.
The example in Figure 5.1 shows how a shortcut trust could theoretically be used to
reduce the overhead involved in sharing resources between the two sales subdomains in
the companyabc.com tree. More information on these trusts can be found in the individ-
ual design model sections later in this chapter.
Choosing a Domain Namespace
151
companyabc.com
asia.companyabc.com
europe.companyabc.com
Shortcut Trust
sales.asia.companyabc.com
sales.europe.companyabc.com
FIGURE 5.1
Shortcut trusts minimize hops between domains.
Cross-Forest Transitive Trusts
5
Cross-forest transitive trusts are essentially two-way transitive trusts that exist between two
ptg
disparate AD DS forests. Although explicit trusts between separate AD domains in separate
forests were possible in Windows 2000 Server, the cross-forest trusts in all versions of
Windows Server beyond the 2003 release allow for two-way transitive trusts to exist
between two separate forests. More information about these trusts can be found later in
this chapter in the section “Understanding the Federated Forests Design Model.”
The first step in the actual design of the AD DS structure is the decision on a common
Domain Name System (DNS) namespace that AD DS will occupy. AD DS revolves around,
and is inseparable from, DNS, and this decision is one of the most important ones to
make. The namespace chosen can be as straightforward as microsoft.com, for example, or
it can be more complex. Multiple factors must be considered, however, before this deci-
sion can be made. Is it better to register an AD namespace on the Internet and potentially
expose it to intruders, or is it better to choose an unregistered internal namespace? Is it
necessary to tie in multiple namespaces into the same forest? These and other questions
must be answered before the design process can proceed.
Choosing an External (Published) Namespace
The simplest method of implementing an AD DS structure is through the use of a single,
common DNS namespace that reflects the company’s name and is registered on the
Internet. Microsoft.com is an obvious example, and a myriad of other possibilities exist as
well. Several advantages to a published namespace are that it is readily accessible from the
152
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
Internet and there is less confusion on the end user’s part in regard to the location on the
network and on the Internet. For example, a user named Rosemary Nahrvar working for
the CompanyABC Corporation will be represented in the network through the user princi-
pal name (UPN) as [email protected]. This name can be set up to exactly
match her email address, limiting confusion for the end user.
The limitations to this type of namespace strategy are primarily security based. Publishing
your AD DS namespace leaves potential hackers with the name of your domain system
and part of what is needed to compromise user accounts. Administering your firewall to
block internal DNS queries also becomes less intuitive when the namespace is the same as
the published Internet namespace for the organization. If the namespaces were separate,
for example, a simple rule could be written to block any traffic to the internal domain
structure. Another limitation would arise if an organization currently employs multiple
namespaces to identify itself, and all those namespaces need to be joined into the same
forest; in this case, a common namespace design is not an option. Mergers and acquisi-
tions or even multiple business units within the same corporate parent can present these
types of problems.
Choosing an Internal Namespace
If desired or required by your organization, the namespace that the AD DS structure
ptg
inhabits can be internal, or not published to the Internet. Using internal namespaces adds
a layer of complexity to your network because users’ UPNs are different from their email
addresses. However, the increase in security that is realized from this design is also a factor
that leads organizations to choose this route. Another factor that might influence your
decision to choose an Internet namespace is that you are no longer limited to the
InterNIC standard namespaces of .com, .net, .biz, .info, and so on. For example, many
organizations use the .internal namespace, or some other namespace that is not used on
the Internet.
Keep in mind that it is important to secure an internal namespace from registration
anywhere on the Internet other than in your own network. In other words, if an organiza-
tion registers internalnetwork.net, and another organization on the Internet registers the
same domain name for its network, there could be naming conflicts with applications and
other systems that perform DNS lookups against your forest. For example, if an applica-
tion on a laptop usually attempts to access an internal namespace but then tries to access
it remotely through an Internet service provider (ISP), the ISP’s DNS will forward you to
the registered DNS name on the Internet. In a nutshell, if you are going to design your
domain with an unpublished namespace but use a standard such as .net or .org that
someone else could theoretically register, it is best to register and reserve that domain but
not point it anywhere. Another common tactic is to name your domain something that
will never be published, such as a root with your company’s stock ticker symbol (for
example, network.msft), or by utilizing the .internal suffix, which has been specifically
reserved for internal use only.
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 infor-
mation about this topic can be found in Chapter 4, “Active Directory Domain
Services Primer.”
.
5
Fine-grained password policies—
The ability to have multiple password policies
within a single domain was originally released in Windows Server 2008 and is still
ptg
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 informa-
tion 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
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