Windows Server 2008 R2 Unleashed (32 page)

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.

Outlining AD DS’s Components

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.