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 additions as well.
Understanding AD DS’s X.500 Roots
AD DS loosely follows, but
does not exactly conform to, the X.500 directory services information
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 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 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 1, enables an administrator to view, delete, and modify schema
attributes. Great care should be taken before schema modifications are
undertaken because problems in the schema can be difficult to fix.
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: distinguished 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
This
object would have a relative distinguished name of OU=Sydney. The
relative distinguished 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
information. 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 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 multiple global
catalog servers in each large location, which distributes load, provides
redundancy, 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,
multimaster-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 distributed
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 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 addition 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.
RID master—
All objects within AD DS that can be assigned permissions are uniquely
identified through the use of a security identifier (SID). Each SID is
composed of a domain SID, which is the same for each object in a single
domain, and a relative identifier (RID), which is unique for each object
within that domain. When assigning SIDs, a domain controller must be
able to assign a corresponding RID from a pool that it obtains from the
RID master. When that pool is exhausted, it requests another pool from
the RID master. If the RID master is down, you might not be able to
create new objects in your domain if a specific domain controller runs
out of its allocated pool of RIDs. There is one RID master per AD DS
domain.
Infrastructure master—
The infrastructure master manages references to domain objects not
within its own domain. In other words, a DC in one domain contains a
list of all objects within its own domain, plus a list of references to
other objects in other domains in the forest. If a referenced object
changes, the infrastructure master handles this change. Because it deals
with only referenced objects and not copies of the object itself, the
infrastructure master must not reside on a global catalog server in
multiple domain environments. The only exceptions to this are if every
domain controller in your domain is a global catalog server or if you
are in a single-domain environment. In the first case, there is no need
to reference objects in other domains because full copies are available.
In the second case, the infrastructure master role is not utilized
because all copies of objects are local to the domain.
Transfer of an OM role to
another domain controller can be performed as part of regular
maintenance, or in the case of a disaster recovery situation where an OM
server is brought offline, the OM can be seized to be brought back
online. This is true for conditions where the schema master, domain
naming master, PDC emulator, infrastructure master, or RID master either
needs to be moved to another system (transfer) or has gone down and no
backup is available (seized). The transfer and seizure of an OM role is
done through the use of a command-line tool called ntdsutil, shown in Figure 2.
Keep in mind that you should use this utility only in emergency
situations and should never bring the old OM server that has had its
role seized back online into the domain at risk of some serious system conflicts.
