Windows Server 2008 R2 Unleashed (31 page)

duced in the Windows Server 2008 R2 version of AD DS.

The additional Active Directory services outside of AD DS

are covered in subsequent chapters, primarily in Chapter 8,

“Creating Federated Forests and Lightweight Directories.”

114

CHAPTER 4

Active Directory Domain Services Primer

Examining the Evolution of Directory Services

Directory services have existed in one form or another since the early days of computing

to provide basic lookup and authentication functionality for enterprise network imple-

mentations. A directory service provides detailed information about a user or object in a

network, much in the same way that a phone book is used to look up a telephone number

for a provided name. For example, a user object in a directory service can store the phone

number, email address, department name, and as many other attributes as an administra-

tor desires.

Directory services are commonly referred to as the white pages of a network. They provide

user and object definition and administration. Early electronic directories were developed

soon after the invention of the digital computer and were used for user authentication

and to control access to resources. With the growth of the Internet and the increase in the

use of computers for collaboration, the use of directories expanded to include basic

contact information about users. Examples of early directories included MVS PROFS (IBM),

Grapevine’s Registration Database, and WHOIS.

Application-specific directory services soon arose to address the specific addressing and

contact-lookup needs of each product. These directories were accessible only via propri-

etary access methods and were limited in scope. Applications utilizing these types of direc-

ptg

tories were programs such as Novell GroupWise, Lotus Notes, and the UNIX sendmail

/etc/aliases file.

The further development of large-scale enterprise directory services was spearheaded by

Novell with the release of Novell Directory Services (NDS) in the early 1990s. It was

adopted by NetWare organizations and eventually was expanded to include support for

mixed NetWare/NT environments. The flat, unwieldy structure of NT domains and the

lack of synchronization and collaboration between the two environments led many orga-

nizations to adopt NDS as a directory service implementation. It was these specific defi-

ciencies in NT that Microsoft addressed with the introduction of AD DS.

The development of the Lightweight Directory Access Protocol (LDAP) corresponded with

the growth of the Internet and a need for greater collaboration and standardization. This

nonproprietary method of accessing and modifying directory information that fully

utilized TCP/IP was determined to be robust and functional, and new directory services

implementations were written to utilize this protocol. AD DS itself was specifically

designed to conform to the LDAP standard.

Reviewing the Original Microsoft Directory Systems

Exchange Server 5.5 ran its own directory service as part of its email environment. In fact,

AD DS took many of its key design components from the original Exchange directory

service. For example, the AD DS database uses the same Jet database format as Exchange

5.5 and the site replication topology is similar in many ways.

Several other Microsoft applications ran their own directory services, namely Internet

Information Server and Site Server. However, each directory service was separate from the

others, and integration was not very tight between the different implementations.

Understanding the Development of AD DS

115

Examining the Key Features of Active Directory Domain Services

Five key components are central to AD DS’s functionality. As compatibility with Internet

standards has become required for new directory services, the existing implementations

have adjusted and focused on these areas:

.
TCP/IP compatibility—
Unlike some of the original proprietary protocols such as

IPX/SPX and NetBEUI, the Transmission Control Protocol/Internet Protocol (TCP/IP)

was designed to be cross-platform. The subsequent adoption of TCP/IP as an Internet

standard for computer communications has propelled it to the forefront of the

protocol world and essentially made it a requirement for enterprise operating

systems. AD DS and Windows Server 2008 R2 utilize the TCP/IP protocol stack as

their primary method of communications.

.
Lightweight Directory Access Protocol support—
The Lightweight Directory

Access Protocol (LDAP) has emerged as the standard Internet directory protocol and

4

is used to update and query data within the directory. AD DS directly supports LDAP.

.
Domain name system (DNS) support—
DNS was created out of a need to translate

simplified names that can be understood by humans (such as www.cco.com) into an

IP address that is understood by a computer (such as 12.155.166.151). The AD DS

structure supports and effectively requires DNS to function properly.

ptg

.
Security support—
Internet standards-based security support is vital to the smooth

functioning of an environment that is essentially connected to millions of comput-

ers around the world. Lack of strong security is an invitation to be hacked, and

Windows Server 2008 R2 and AD DS have taken security to greater levels. Support

for IP Security (IPSec), Kerberos, Certificate Authorities, and Secure Sockets Layer

(SSL) encryption is built in to Windows Server 2008 R2 and AD DS.

.
Ease of administration—
Although often overlooked in powerful directory services

implementations, the ease in which the environment is administered and configured

directly affects the overall costs associated with its use. AD DS and Windows Server

2008 R2 are specifically designed for ease of use to lessen the learning curve associat-

ed with the use of a new environment. Windows Server 2008 R2 also enhanced AD

DS administration with the introduction of the Active Directory Administration

Center, Active Directory Web Services, and an Active Directory module for Windows

PowerShell command-line administration.

Understanding the Development of AD DS

Introduced with Windows 2000 Server as a replacement to Windows NT 4.0 domains, AD

DS (then known simply as AD) was later greatly improved in Windows Server 2003 and

Windows Server 2003 R2 Edition. AD DS has achieved wide industry recognition and

acceptance and has proven itself in reliability, scalability, and performance. The introduc-

tion of AD DS served to address some limitations in the legacy NT 4.0 domain structure

design and also allowed for future Microsoft and third-party products to tie into a

common interface.

116

CHAPTER 4

Active Directory Domain Services Primer

Detailing Microsoft’s Adoption of Internet Standards

Since the early development of Windows 2000/2003 and continuing with Windows Server

2008 R2, Microsoft has strived to make all its products embrace the Internet. Standards

that before had been options or previously incompatible were subsequently woven into

the software as primary methods of communication and operability. All applications and

operating systems became TCP/IP compliant, and proprietary protocols such as NetBEUI

were phased out.

With the introduction of Windows Server 2008 R2, the Internet readiness of the Microsoft

environment reaches new levels of functionality, with enhancements such as the ability to

restore deleted objects using the Active Directory Recycle Bin, Offline Domain Join,

Managed Service Accounts, the ability to use multiple password policies per domain, Read-

Only Domain Controller (RODC) support, the ability to start/stop AD on a domain

controller (DC), and the ability to audit changes made to AD objects.

Examining AD DS’s Structure

The logical structure of AD DS enables it to scale from small offices to large, multinational

organizations. Administrative granularity is built in to allow delegation of control to

ptg

groups or specific users. No longer is the assigning of administrative rights an all-or-

nothing scenario.

AD DS loosely follows an X.500 directory model but takes on several characteristics of its

own. Many of us are already getting used to the forests and trees of AD DS, and some limi-

tations that existed before in Windows 2000 and Windows Server 2003 have been lifted.

To understand AD DS, we must first take a good look at its core structural components.

Understanding the AD DS Domain

An AD DS domain, traditionally represented by a triangle, as shown in Figure 4.1, is the

initial logical boundary of AD DS. In a standalone sense, an AD DS domain acts very

much like the legacy Windows NT 4.0 domain structure that it replaced. Users and

computers are all stored and managed from within the boundaries of the domain.

However, several major changes have been made to the structure of the domain and how

it relates to other domains within the AD DS structure.

companyabc.com

FIGURE 4.1

Examining a sample domain in AD DS.

Domains in AD DS serve as administrative security boundaries for objects and contain

their own security policies. It is important to keep in mind that domains are a logical

Examining AD DS’s Structure

117

organization of objects, and can easily span multiple physical locations. Consequently, it

is no longer necessary to set up multiple domains for different remote offices or sites as

replication concerns and security concerns are more properly addressed with the use of

AD DS sites or Read-Only Domain Controllers, which will be described in greater detail in

the following sections.

Describing AD DS Domain Trees

An AD DS tree is composed of multiple domains connected by two-way transitive trusts.

Each domain in an AD DS tree shares a common schema and global catalog. In Figure 4.2,

the root domain of the AD DS tree is companyabc.com and the subdomains are

asia.companyabc.com and europe.companyabc.com.

4

companyabc.com

ptg

asia.companyabc.com

europe.companyabc.com

FIGURE 4.2

Viewing a sample Windows Server 2008 R2 AD DS tree with subdomains.

The transitive trust relationship is automatic. The transitive trust relationship means that

because the Asia domain trusts the root companyabc domain, and the Europe domain

trusts the companyabc domain, the Asia domain trusts the Europe domain as well. The

trusts flow through the domain structure.

NOTE

Although trusts are transitive in an AD DS environment, that does not mean that per-

missions are fully accessible to all users or even to administrators between domains.

The trust only provides a pathway from one domain to another. By default, no access

rights are granted from one transitive domain to another. The administrator of a domain

must issue rights for users or administrators in another domain to access resources

within their domain.

All domains within a tree share the same namespace, in this example companyabc.com,

but have security mechanisms in place to segregate access from other domains. In other

words, an administrator in the Europe domain could have relative control over his entire

118

CHAPTER 4

Active Directory Domain Services Primer

domain, without users from the Asia or companyabc domains having privileges to

resources. Conversely, the administrators in Europe can allow groups of users from other

domains access if they so want. The administration is granular and configurable.

Describing Forests in AD DS

Forests are a group of interconnected domain trees. Implicit trusts connect the roots of

each tree together into a common forest.

The overlying characteristics that tie together all domains and domain trees into a

common forest are the existence of a common schema and a common global catalog.

However, domains and domain trees in a forest do not need to share a common name-

space. For example, the domains microsoft.com and msnbc.com could theoretically be

part of the same forest but maintain their own separate namespaces.

Forests are the main organizational security boundary for AD DS, and it is assumed that all

domain administrators within a forest are trusted to some degree. If a domain administra-

tor is not trusted, that domain administrator should be placed in a separate forest.

Understanding AD DS Authentication Modes

Windows NT 4.0 used a system of authentication known as NT LAN Manager (NTLM).

ptg

This form of authentication sent the encrypted password across the network in the form

of a hash. The problem with this method of authentication was that anyone could

monitor the network for passing hashes, collect them, and then use third-party decryption

tools that effectively decrypt the password using dictionary and brute-force techniques.

All versions of Windows Server beyond Windows 2000 utilize a form of authentication

known as Kerberos, which is described in greater detail in the following sections of this

chapter. In essence, Kerberos does not send password information over the network and is