Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
inherently more secure than NTLM.
Outlining Functional Levels in Windows Server 2008 R2 AD DS
Just as Windows 2000 and Windows 2003 had their own functional levels that ensured
down-level compatibility with legacy domain versions, Windows Server 2008 R2 has its
own functional levels that are used to maintain compatibility. The following functional
levels exist in Windows Server 2008 R2:
.
Windows 2000 Native functional level—
This functional level allows Windows
Server 2008 R2 domain controllers to coexist with both Windows 2000 SP3+ and
Windows 2003 domain controllers within a forest.
.
Windows Server 2003 functional level—
This functional level allows Windows
2003 and Windows Server 2008 R2 domain controllers to coexist. Additional func-
tionality is added to the forest, including cross-forest transitive trust capabilities and
replication enhancements.
.
Windows Server 2008 functional level—
In this functional level, all domain
controllers must be running Windows Server 2008 or later. Changing the domain
Outlining AD DS’s Components
119
and forest functional level to Windows Server 2008 adds additional functionality,
such as fine-grained password policies.
.
Windows Server 2008 R2 functional level—
In this functional level, all domain
controllers must be running Windows Server 2008 R2. Changing the forest function-
al level to this latest AD DS level grants Windows Server 2008 R2 feature functionali-
ty, such as access to the Active Directory Recycle Bin.
By default, a fresh installation of Active Directory on Windows Server 2008 R2 domain
controllers allows you to choose which functional level you want to start the forest in. If
an existing forest is in place, it can be brought to Windows Server 2008 R2 functional
level by performing the following steps:
1. Ensure that all domain controllers in the forest are upgraded to Windows Server
2008 R2 or replaced with new Windows Server 2008 R2 DCs.
4
2. Open Active Directory Domains and Trusts from the Administrative Tools menu on a
domain controller.
3. In the left scope pane, right-click on the domain name, and then click Raise Domain
Functional Level.
4. In the box labeled Raise Domain Functional Level, select Windows Server 2008 R2,
and then click Raise.
ptg
5. Click OK and then click OK again to complete the task.
6. Repeat steps 1–5 for all domains in the forest.
7. Perform the same steps on the root node of Active Directory Domains and Trusts,
except this time choose Raise Forest Functional Level and follow the prompts.
When all domains and the forest level have been raised to Windows Server 2008 R2 func-
tionality, the forest can take advantage of the latest AD DS functionality, such as the
Active Directory Recycle Bin, outlined in more detail later in this chapter. Remember,
before you accomplish this task, Windows Server 2008 R2 essentially operates in a down-
graded mode of compatibility.
The main components of AD DS were designed to be highly configurable and secure. AD
DS and all it contains are physically located in a database file but are composed of a wide
assortment of objects and their attributes. Many of these characteristics are familiar to
those acquainted with other directory services products, but there are some new addi-
tions as well.
Understanding AD DS’s X.500 Roots
AD DS loosely follows, but does not exactly conform to, the X.500 directory services infor-
mation model. In a nutshell, X.500 defines a directory service through a distributed
approach defined by a Directory Information Tree (DIT). This logically divides a directory
service structure into the now familiar servername.subdomainname.domainname.com
120
CHAPTER 4
Active Directory Domain Services Primer
layout. In X.500, directory information is stored across the hierarchical layout in what are
called Directory System Agents (DSAs). Microsoft designed AD DS around many of the
basic principles of the X.500 definition, but AD DS itself is not compatible with X.500
implementations, as X.500 follows an OSI model that is inefficient under the TCP/IP
implementation that AD DS follows.
Conceptualizing the AD DS Schema
The AD DS schema is a set of definitions for all object types in the directory and their
related attributes. The schema determines the way that all user, computer, and other
object data are stored in AD DS and configured to be standard across the entire AD DS
structure. Secured by the use of discretionary access control lists (DACLs), the schema
controls the possible attributes to each object within AD DS. In a nutshell, the schema is
the basic definition of the directory itself and is central to the functionality of a domain
environment. Care should be taken to delegate schema control to a highly selective group
of administrators because schema modification affects the entire AD DS environment.
Schema Objects
Objects within the AD DS structure such as users, printers, computers, and sites are
defined in the schema as objects. Each object has a list of attributes that define it and that
ptg
can be used to search for that object. For example, a user object for the employee named
Weyland Wong will have a FirstName attribute of Weyland and a LastName attribute of
Wong. In addition, there might be other attributes assigned, such as departmental name,
email address, and an entire range of possibilities. Users looking up information in AD DS
can make queries based on this information, for example, searching for all users in the
Sales department.
Extending the Schema
One of the major advantages to the AD DS structure is the ability to directly modify and
extend the schema to provide for custom attributes. A common attribute extension occurs
with the installation of Microsoft Exchange Server, which extends the schema, more than
doubling it in size. An upgrade from Windows Server 2003 or Windows Server 2008 AD to
Windows Server 2008 R2 AD DS also extends the schema to include attributes specific to
Windows Server 2008 R2. Many third-party products have their own schema extensions as
well, each providing for different types of directory information to be displayed.
Performing Schema Modifications with the AD DS Service Interfaces
An interesting method of actually viewing the nuts and bolts of the AD DS schema is by
using the AD DS Service Interfaces (ADSI) utility. This utility was developed to simplify
access to the AD DS and can also view any compatible foreign LDAP directory. The
ADSIEdit utility, shown in Figure 4.3, enables an administrator to view, delete, and modify
Outlining AD DS’s Components
121
schema attributes. Great care should be taken before schema modifications are undertaken
because problems in the schema can be difficult to fix.
4
FIGURE 4.3
Viewing and editing the Active Directory schema using the ADSIEdit utility.
ptg
Defining the Lightweight Directory Access Protocol (LDAP)
The Directory Service Protocol that is utilized by AD DS is based on the Internet-standard
Lightweight Directory Access Protocol defined by RFC-3377. LDAP allows queries and
updates to take place in AD DS. Objects in an LDAP-compliant directory must be uniquely
identified by a naming path to the object. These naming paths take two forms: distin-
guished names and relative distinguished names.
Explaining Distinguished Names in AD
The distinguished name of an object in AD DS is represented by the entire naming path
that the object occupies in AD DS. For example, the user named Brian McElhinney can be
represented by the following distinguished name:
CN=Brian McElhinney,OU=Sydney,DC=Companyabc,DC=com
The CN component of the distinguished name is the common name, which defines an
object within the directory. The OU portion is the organizational unit in which the object
belongs. The DC components define the DNS name of the Active Directory domain.
Outlining Relative Distinguished Names
The relative distinguished name of an object is basically a truncated distinguished name
that defines the object’s place within a set container. For example, take a look at the
following object:
OU=Sydney,DC=companyabc,DC=com
122
CHAPTER 4
Active Directory Domain Services Primer
This object would have a relative distinguished name of OU=Sydney. The relative distin-
guished name in this case defines itself as an organizational unit within its current
domain container.
Detailing Multimaster Replication with AD DS Domain Controllers
AD DS uses domain controllers (DCs) to authenticate users. These DCs use the concept of
multiple domain controllers that each contain a master read/write copy of domain infor-
mation. Changes that are made on any domain controller within the environment are
replicated to all other domain controllers in what is known as multimaster replication.
Conceptualizing the Global Catalog and Global Catalog Servers
The global catalog is an index of the AD DS database that contains a partial copy of its
contents. All objects within the AD DS forest are referenced within the global catalog,
which allows users to search for objects located in other domains. Not every attribute of
each object is replicated to the global catalogs, only those attributes that are commonly
used in search operations, such as first name, last name, and so on.
Global catalog servers, commonly referred to as GCs or GC/DCs, are AD DS domain
ptg
controllers that contain a copy of the global catalog. It is wise to either locate a minimum
of one global catalog server in each physical location or utilize Read-Only Domain
Controllers (RODCs) in remote sites as the global catalog must be referenced often by
clients and the traffic across slower wide area network (WAN) links would limit this traffic.
In addition, technologies such as Microsoft Exchange Server need fast access to global
catalog servers for all user transactions, making it very important to have a global catalog
server nearby. Note that Exchange cannot make use of RODCs or Read-Only Global
Catalog (ROGC) servers.
Often, a larger organization will employ the use of multiple domain controllers and multi-
ple global catalog servers in each large location, which distributes load, provides redun-
dancy, and locates resources where they are needed. Choosing the right blend of global
catalog servers and domain controllers is vital to the proper functionality of your AD DS
environment.
Numbering the Operations Master (OM) Roles
Most domain controller functionality in Windows Server 2000, Windows Server 2003,
Windows Server 2008, and Windows Server 2008 R2 was designed to be distributed, multi-
master-based. This effectively eliminated the single point of failure that was present with
Windows NT primary domain controllers (PDCs). However, five functions still require the
use of a single server because their functionality makes it impossible to follow a distrib-
uted approach. These Operations Master (OM) roles (previously referred to as FSMO roles)
are outlined as follows:
.
Schema master—
There is only one writable master copy of the AD DS schema in a
single AD DS forest. It was deliberately designed this way to limit access to the
Outlining AD DS’s Components
123
schema and to minimize potential replication conflicts. There can be only one
schema master in the entire AD DS forest.
.
Domain naming master—
The domain naming master is responsible for the addi-
tion of domains into the AD DS forest. This OM role must be placed on a global
catalog server because it must have a record of all domains and objects to perform its
function. There can be only one domain naming master in a forest.
.
PDC emulator—
This role used to exist to emulate the legacy Windows NT 4.0
primary domain controller (PDC) for down-level clients. With Windows Server 2008
R2, the PDC emulator still performs certain roles, such as acting as the primary time
sync server for the domain. There is one PDC emulator FSMO role per AD DS
domain.