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