1. Understanding AD DS 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.
2. 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, significantly from the default size. An upgrade from Windows
2003 or 2008 AD to Windows Server 2012 AD DS also extends the schema to
include attributes specific to Windows Server 2012. Many third-party
products have their own schema extensions as well, each providing for
different types of directory information to be displayed. It should be
noted that schema extensions should only be performed when absolutely
required, however, as an improper schema extension can wreak havoc on
an AD DS environment.
Performing Schema Modifications with the AD DS Service Interfaces
An interesting way to actually view the nuts
and bolts of the AD DS schema is by using the AD 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.
Figure 1. Using the ADSIEdit tool to view schema attributes in AD DS.
3. Defining the Lightweight Directory Access Protocol
The Directory Service Protocol that is used
by AD DS is compliant with the Internet-standard Lightweight Directory
Access Protocol as defined by RFC 2251. 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.
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 Joel Oleson can be represented by the
following distinguished name:
CN=Joel Oleson,OU=SLC,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.
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=SLC,DC=companyabc,DC=com
This object would have a relative distinguished name of OU=SLC. The relative distinguished name in this case defines itself as an organizational unit within its current domain container.
4. Detailing Multimaster Replication with AD DS Domain Controllers
AD DS uses domain controllers (DCs)
to authenticate users. These DCs use the concept of multiple DCs that
each contains a master read/write copy of domain information. Changes
that are made on any DC within the environment are replicated to all
other DCs in what is known as multimaster replication.
5. Understanding 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 tree 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 DCs 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 use RODCs in remote sites because
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
use multiple DCs 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 DCs is vital to the proper functionality of your AD
DS environment.
6. Defining the Operations Master Roles
Most DC functionality in Windows
2000/2003/2008 and Windows Server 2012 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 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 PDC for
down-level clients. With Windows Server 2012, 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 DC 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 DC 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
DC 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 used because
all copies of objects are local to the domain.
Transfer of an OM role to another DC 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, 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 the risk of some serious
system conflicts).
Figure 2. The Ntdsutil utility for AD DS management.
