Windows Server 2008 R2 Unleashed (38 page)

. 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.

Understanding AD DS Domain

Design

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.”

Choosing a Domain Namespace

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