Domains and Forests Technical Reference

Updated: March 28, 2003

Domains and forests are logical representations of the directory hierarchy in the Microsoft Windows Server 2003
Active Directory directory service. Active Directory domains and forests allow administrators to organize elements of a
network (such as users, computers, devices, resources, and application-specific data from Active Directory–enabled
applications) into a non-physical hierarchical structure, known as the logical structure. You can use domains and forests to
provide an information repository and services to make information available to users and applications.
In this subject

• What Are Domains and Forests?

• How Domains and Forests Work

Domains and Forests Tools and
•
Settings

What Are Domains and Forests?

Updated: March 28, 2003
What Are Domains and Forests?
In this section

• The Logical Structure of Active Directory

• The Physical Structure of Active Directory

• What are Domains?

• What are Forests?

• Related Information
The Active Directory directory service is a distributed database that stores and manages information about network
resources, as well as application-specific data from directory-enabled applications. Active Directory allows administrators to
organize objects of a network (such as users, computers, and devices) into a hierarchical collection of containers known as
the logical structure. The top-level logical container in this hierarchy is the forest. Within a forest are domain containers, and
within domains are organizational units.
Understanding domains and forests requires understanding the possible relationships they might have in Active Directory.
The relationships between these logical containers might be based on administrative requirements, such as delegation of
authority, or they might be defined by operational requirements, such as the need to provide for data isolation. Service
administrators can use domain and forest containers to meet a number of specific requirements, including:

• Implementing an authentication and authorization strategy for sharing resources across a network

• Providing a mechanism for centralizing management of multiple domains and forests

• Providing an information repository and services to make information available to users and applications
Organizing objects of a network (such as users, computers, devices, resources, and application specific data from
•
directory-enabled applications) into a non-physical hierarchical structure
To learn more about domains and forests, you must first understand the logical and physical structures of Active Directory.
This section describes how those structures differ, and defines domains and forests in terms of the logical structure.
Top of page
The Logical Structure of Active Directory
Active Directory stores network object information and implements the services that make this information available and
usable to users. Active Directory presents this information through a standardized, logical structure that helps you establish
and understand the organization of domains and domain resources in a useful way. This presentation of object information is
referred to as the logical structure because it is independent of the physical aspects of the Active Directory infrastructure,
such as the domain controllers required for each domain in the network.

Benefits of the Logical Structure

The logical structure provides a number of benefits for deploying, managing, and securing network services and resources.
These benefits include:
Increased network security. The logical structure can provide security measures such as autonomy for individual groups or
•
complete isolation of specific resources.
 Simplified network management. The hierarchical nature of the logical structure simplifies configuration, control, and
•
administration of the network, including managing user and group accounts and all network resources.
Simplified resource sharing. The logical structure of domains and forests and the relationships established between them
•
can simplify the sharing of resources across an organization.
Low total cost of ownership. The reduced administration costs for network management and the reduced load on network
•
resources that can be achieved with the Active Directory logical structure can significantly lower the total cost of
ownership.
An efficient Active Directory logical structure also facilitates the system integration of features such as Group Policy, enabling
desktop lockdown, software distribution, and administration of users, groups, workstations, and servers. In addition, the
logical structure can facilitate the integration of services such as Exchange 2000, public key infrastructure (PKI), and
domain-based distributed file system (DFS).

Components of the Logical Structure

The logical structure consists of leaf object and container object components that must conform to the hierarchical structure
of an Active Directory forest. Leaf objects are objects that have no child objects, and are the most basic component of the
logical structure. Container objects store other objects and occupy a specific level within the forest hierarchy.
The relationships among the components of the logical structure control access to stored data and determine how that data
is managed across one or more domains within a single forest. The components that make up the Active Directory logical
structure are described in the following table.
Components of the Active Directory Logical Structure

Component Description

Organizational Organizational units are container objects. You use these container objects to arrange other objects in a
Units manner that supports your administrative purposes. By arranging objects in organizational units, you make it
easier to locate and manage them. You can also delegate the authority to manage an organizational unit.
Organizational units can be nested in other organizational units.
You can arrange objects that have similar administrative and security requirements into organizational units.
Organizational units provide multiple levels of administrative authority, so that you can apply Group Policy
settings and delegate administrative control. This delegation simplifies the task of managing these objects
and enables you to structure Active Directory to fit your organization’s requirements.

Domains Domains are container objects. Domains are a collection of administratively defined objects that share a
common directory database, security policies, and trust relationships with other domains. In this way, each
domain is an administrative boundary for objects. A single domain can span multiple physical locations or
sites and can contain millions of objects.

Domain Trees Domain trees are collections of domains that are grouped together in hierarchical structures. When you add a
domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached
is called the parent domain.
A child domain might in turn have its own child domain. The name of a child domain is combined with the
name of its parent domain to form its own unique Domain Name System (DNS) name such as
Corp.nwtraders.msft. In this manner, a tree has a contiguous namespace.

Forests A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses
all domain containers for that particular Active Directory instance. A forest can contain one or more domain
container objects, all of which share a common logical structure, global catalog, directory schema, and
directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the
forest is called the forest root domain. The name of that domain refers to the forest, such as Nwtraders.msft.
By default, information in Active Directory is shared only within the forest. In this way, the forest is a security
boundary for the information that is contained in that instance of Active Directory.

Site Objects Sites are leaf and container objects. The sites container is the topmost object in the hierarchy of objects that
are used to manage and implement Active Directory replication. The sites container stores the hierarchy of
objects that are used by the Knowledge Consistency Checker (KCC) to effect the replication topology. Some
of the objects located in the sites container include NTDS Site Settings objects, subnet objects, connection
Component Description

objects, server objects, and site objects (one site object for each site in the forest). The hierarchy is
displayed as the contents of the Sites container, which is a child of the Configuration container.
By understanding the purpose and hierarchical structure of these components, you can complete a variety of tasks, including
installing, configuring, managing, and troubleshooting Active Directory. Although the logical structure of Active Directory is a
hierarchical organization of all users, computers, and other physical resources, the forest and domain form the basis of the
logical structure.
Forests, which are the security boundaries of the logical structure, can be structured to provide data and service autonomy
and isolation in an organization in ways that can both reflect site and group identities and remove dependencies on the
physical topology. Domains can be structured within a forest to provide data and service autonomy (but not isolation) and to
optimize replication with a given region.
This separation of logical and physical structures improves manageability and reduces administrative costs because the
logical structure is not impacted by changes in the physical structure, such as the addition, removal, or reorganization of
users and groups.
Note
You can view and manage components of the logical structure by using the Active Directory Users and Computers, Active
•
Directory Domains and Trusts, and Active Directory Schema Microsoft Management Console (MMC) snap-ins, and other
tools.
Top of page
The Physical Structure of Active Directory
The physical structure of Active Directory is represented by a set of physical components which, when configured correctly,
can help optimize the transmission of network replication and authentication in ways specifically tailored to fit your physical
network. Physical network components, such as domain controllers and physical subnets, are used to facilitate network
communication and to set physical boundaries around network resources. More specifically, the physical structure of Active
Directory represents all of the physical subnets in your enterprise network, the domain controllers in those physical subnets
(commonly referred to as Sites in Active Directory) and the replication connections between the domain controllers.
Sites and subnets are represented in Active Directory by site and subnet objects. Computers on TCP/IP networks are
assigned to site objects based on their location in a physical subnet or a set of physical subnets. Physical subnets group
computers in a way that identifies their physical proximity on the network. Each site object is associated with one or more
subnet objects. Subnet objects are used during the process of domain controller location to find a domain controller in the
same site as the computer that is logging on. This information also is used during Active Directory replication to determine
the best routes between domain controllers. This enables you to use network bandwidth more efficiently. For example, it
ensures that when users log on to the network they are authenticated by the authentication authority nearest to the user,
thus reducing the amount of network traffic.
The physical domain controller contains the directory partitions that are replicated. Although the logical and physical
structures are defined and configured independently, they have interdependencies that affect replication.
Note
You can view the physical structure of Active Directory by using Active Directory Sites and
•
Services.
For more information about the network components associated with the physical structure of Active Directory, see the
“Active Directory Replication Topology Technical Reference.”
Top of page
What Are Domains?
Domains are logical directory components that you create to manage the administrative requirements of your organization.
The logical structure is based on the administrative requirements of an organization, such as the delegation of administrative
authority, and operational requirements, such as the need to control replication. In general, domains are used to control
where in the forest replication of domain data occurs and organizational units are used to further organize network objects
into a logical hierarchy and delegate control to appropriate administrative support personnel.
A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate data only to where it
is needed. In this way, the directory can scale globally over a network that has limited available bandwidth. Domains can
also be defined as:
• Containers within a forest

• Units of Policy

• Units of Replication

• Authentication and Authorization Boundaries

• Units of Trust
Each domain has a domain administrators group. Domain administrators have full control over every object in the domain.
These administrative rights are valid within the domain only and do not propagate to other domains.

Domains as Containers within a Forest

Within the scope of a forest, a domain is a container. Objects in that container inherently trust each other and the security
services located in that same container. Each time you create a new domain container in a forest, a two-way, transitive trust
relationship is automatically created between the new domain and its parent domain. Trusts are logical relationships
established between domains to allow pass-through authentication in which a trusting domain honors the logon
authentications of a trusted domain. Because all domain containers within a forest are joined together by two-way transitive
trusts, objects within one domain container also inherently trust all other objects and security services located in every
domain container located in that forest.
Domain containers are used to store and manage Active Directory objects, some of which have a physical representation. All
of the objects within the domain container are stored in a central database that stores only objects created within that
domain. Some objects represent people or groups of people, while others represent computers or network servers. Examples
of Active Directory objects that have a physical representation are user, computer, and group objects.
While domains contain objects that represent physical things, they also contain objects that are used to help self-regulate
domain operations such as trusted domain objects (TDOs) and site link objects. Domain containers can also hold subordinate
containers such as organizational units. The following figure shows where objects are stored within the logical structure of a
domain.
Domain Containment Structure Within a Forest

Organizational Units and Objects

Organizational units are used to group objects, including accounts and resources in a domain, for administrative purposes,
such as the application of Group Policy or delegation of authority. Control over an organizational unit, including the objects
within it, is determined by the access control lists (ACLs) on the organizational unit and on the objects in the organizational
unit.

Organizational Units
The organizational unit is a particularly useful type of directory object contained within domains. Each organizational unit is
an Active Directory container within a domain into which users, groups, computers, and other organizational units of the
domain can be placed. An organizational unit cannot contain objects from other domains.
An organizational unit is the smallest scope or unit to which Group Policy settings can be assigned or to which administrative
authority can be delegated. A hierarchy of organizational units can be extended as necessary to model the hierarchy of an
organization within a domain. The administrative model of the organizational unit can be scaled to any size. For more
information about Group Policy, see “How Core Group Policy Works.”
Administrative authority can be delegated for individual organizational units or for multiple organizational units.
Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users,
groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy
within a domain is independent of the structure of other domains: Each domain can implement its own hierarchy. Likewise,
domains that are managed by the central authority can implement similar organizational unit hierarchies. The structure is
flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is centralized
or decentralized.

Objects
Active Directory objects represent the physical entities that make up a network. An object stores an instance of a class. A
class is defined in the Active Directory schema as a specific set of mandatory and optional attributes — that is, an attribute
can be present in an object in Active Directory only when that attribute is permitted by the object’s class. Classes also
contain rules that determine which classes of objects can be superior to (parents of) a particular object of the class. Each
attribute is also defined in the directory schema. The attribute definitions determine the syntax for the values the attribute
can have.
Creation of an Active Directory object requires specification of values for the attributes of the object in its particular class,
consistent with the rules of the directory schema. For example, creating a user object requires specification of alphanumeric
values for the user’s first and last names and the logon identifier, which are mandatory according to the directory schema.
Other non-mandatory values can also be specified, such as telephone number and address.
Applications that create or modify objects in Active Directory use the directory schema to determine what attributes the
object must and might have, and what those attributes can look like in terms of data structures and syntax constraints. The
directory schema is maintained forest-wide so that all objects created in the directory conform to the same values.
Objects are either container objects or leaf objects. A container object stores other objects, and as such occupies a specific
level in a subtree hierarchy. An object class is a container if at least one other class specifies it as a possible superior, so any
object class defined in the schema can become a container. A leaf object does not store other objects, so it occupies the
endpoint of a subtree. For more information about Active Directory Objects, see “How Domains and Forests Work” and “How
the Active Directory Schema Works.”

Domains as Units of Policy

A domain defines a scope or unit of policy within a forest. Some policy settings apply only to the scope of a domain, that is,
the policy settings are domain-wide. Account policies, for example, apply uniformly to all user accounts in the domain.
Although a domain is not the smallest unit of policy that can be assigned (policies can be assigned to organizational units) it
is the most commonly used unit when splitting administrative duties between departments and subsidiaries located in
different geographical locations. As shown in the following figure, you might need to create multiple domains to provide for
policy variance among domains throughout a forest. A domain is also considered a unit of access control, in that it can be
used for business groups requiring general autonomy.
Delegation of Domains to Domain Admins that Require Different Policies or Autonomy
You cannot define different account policies for different organizational units in the same domain. Policy settings are stored
as Group Policy objects (GPOs) in Active Directory. A GPO establishes how domain resources can be accessed, configured,
and used. The policies associated with a GPO are applied only within the domain and not across domains. A GPO can be
associated with one or more Active Directory containers, such as a site, domain, or organizational unit.
Account policies and Public Key policies have domain-wide scope and are set at the domain GPO level. All other policies can
be specified at the level of the organizational unit. Some policies that can be applied only at the domain container level
include:

• Password policy. Determines the rules, such as password length, that must be met when a user sets a password.

• Account lockout policy. Defines rules for intruder detection and account deactivation.
Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is obtained during the logon process
•
and is used for network authentication. A particular ticket is only valid for the lifetime specified in the policy.
Because organizational units provide multiple levels of administrative authority, you can use them to systematically apply
Group Policy settings and delegate administrative control. Delegation simplifies the task of managing these objects and
enables you to structure Active Directory to fit the requirements of your organization. Using delegated authority in
conjunction with GPOs and group memberships allows one or more administrators to be assigned rights and permissions to
manage objects in an entire domain or in one or more organizational units within the domain.
For more information about Group Policy, see “How Core Group Policy Works.”

Domains as Units of Replication

The physical significance of a domain is that it is a unit of replication. In fact, with the exception of application partitions,
which replicate only non-security principal objects, the domain is the smallest unit of replication that can be administered
within an Active Directory forest. This is because all objects that are located within a domain container, also referred to as
domain data, are replicated to other domain controllers within that same domain, regardless of whether those domain
controllers are located over a local area network (LAN) or wide area network (WAN) connection.
As shown in the following figure, Active Directory multi-master replication manages the transfer of domain objects to the
appropriate domain controllers automatically, keeping domain data up-to-date among all domain controllers in the domain,
regardless of location.
Replication of Domain Data Within Each Domain in the Forest

All domain controllers in the forest are also updated with changes to forest-wide data. For more information about replication
at the Forest level, see “Forests as Units of Replication” later in this section Domain-wide replication relies on three
components of the Active Directory physical structure to be in place for optimal performance, these include:

Domain Controllers
The physical domain controller contains the domain partition data that is replicated to other domain controllers in that same
domain. A domain partition stores only the information about objects located in that domain. All domain controllers in a
domain receive changes and replicate those changes to the domain partition stored on all other domain controllers in the
domain. In this way, all domain controllers are peers in the domain and manage replication as a unit.
Domain controllers also have two non-domain directory partitions that store forest-wide data, which includes the directory
schema and configuration data. Optionally, on Windows Server 2003 domain controllers, application partitions can be
configured to be located on designated domain controllers anywhere in a forest. Unlike the schema and configuration
partitions, application partitions are not located on every domain controller in a forest. For more information about the
replication of forest-wide data, see “Forests as Units of Replication” later in this section.
Partitioning Active Directory data into three physical partitions on each domain controller helps to control replication so that
data is replicated only to where it is needed. In this way, Active Directory can scale globally over a network that has limited
available bandwidth.
Sites
Within the scope of a forest, sites are a representation of the physical network topology. This includes physical subnet and
site definitions. Replication of updates to domain data occurs between multiple domain controllers to keep replicas
synchronized. Multiple domains are common in large organizations, as are multiple sites in disparate locations. In addition,
domain controllers for the same domain are commonly placed in more than one site.
Therefore, replication must often occur both within sites and between sites to keep domain and forest data consistent among
domain controllers that store the same directory partitions. Replication within sites generally occurs at typical LAN speeds
between domain controllers that are on the same network segment. Replication between sites usually occurs over WAN links
that might be costly in terms of bandwidth. To accommodate the differences in distance and cost of replication within a site
and between sites, the intrasite replication topology is used to optimize speed, and the intersite replication topology is used
to minimize cost based on a configurable replication schedule.
The Knowledge Consistency Checker (KCC) is a distributed application that runs on every domain controller and is
responsible for creating the connections between domain controllers that collectively form the replication topology. The KCC
uses Active Directory data to determine where to create connections between source domain controllers and destination
domain controllers.
Intersite replication is optimized for bandwidth efficiency, and directory updates between sites occur automatically based on
a configurable schedule.

Domain-Wide Operations Masters

Active Directory supports multi-master replication of the directory data store between all domain controllers in the domain.
However, some changes are impractical to perform in multi-master fashion, so only a single domain controller, called the
operations master, accepts requests for such changes. Because these roles can be transferred to other domain controllers
within the domain or forest, they are sometimes referred to as operations master roles.
There are three operations master roles per domain. These include the Relative Identifier (RID) Master, Primary Domain
Controller (PDC) emulator, and Infrastructure Master. These three roles must be unique in each domain, so each domain can
have only one RID master, one PDC emulator, and one Infrastructure Master. For information about forest-wide roles, see
“Forest-Wide Operations Master Roles” later in this section. For more information about replication, see “How Active Directory
Replication Topology Works.”

Domains as Authentication and Authorization Boundaries

By default, a domain provides authentication and authorization services for all its accounts in order to facilitate logons and
single sign-on access control to shared resources within the boundaries of the domain. The process of authentication ensures
that users are who they claim to be. Once identified, the user can be authorized access to a specific set of network resources
based on permissions.Authorization takes place through the mechanism of access control, using access control lists (ACLs)
that define permissions on file systems, network file and print shares, and entries in Active Directory.
Authorization is determined not only by the identity of the user but also the membership of the user in one or more security
groups. In fact, the preferred method of controlling domain-wide resources is to grant access to groups rather than to
individuals, adjusting the level of authorization for a group according to the needs of its members. This method of controlling
access makes it easier to keep ACLs up-to-date on domains that have thousands of users and objects. Group membership
can be managed centrally by anyone with the appropriate administrative credentials. You can change the level of
authorization a particular user has to many resources simply by adding or removing the user from a group. The following
figure shows when authentication and authorization for a user in a given domain occur.
Authentication and Authorization of a User Within the Same Domain
Authentication is not limited to users. Computers and services are also authenticated when they make network connections
to other servers. For example, Windows Server 2003–based servers and client computers connect Active Directory in their
domain for policy information during startup. Computers and services also prove their identity to clients that request mutual
authentication. Mutual authentication prevents an intruder from adding another computer as an imposter between the client
and the real network server. The Kerberos version 5 authentication protocol is a technology for single sign-on to network
resources. Windows Server 2003 uses the Kerberos V5 protocol to provide single sign-on to network services within a
domain, and to services residing in trusted domains. The Kerberos V5 protocol verifies both the identity of the user and of
the network services, providing mutual authentication.
Authentication and authorization services in one domain can be extended to accounts that are located in trusted domains.
This can be done by using trusts. Trusts are logical relationships established between domains to allow pass-through
authentication in which a trusting domain honors the logon authentications of a trusted domain. Consequently, trust
relationships inherently allow domain-specific authentication and authorization services to be extended, thereby enabling
single sign-on access control capabilities throughout a forest. Because the domain trust relationships between all domains in
the forest are bidirectional by default, authentication in one domain is sufficient for referral or pass-through authentication to
resources in other domains in the forest.

Domains as Units of Trust

A domain is the smallest container within Active Directory that can be used in a trust relationship. All domains within a forest
are connected by Kerberos-based trusts. Kerberos-based trusts are two-way and transitive in nature. Trusts act as
authentication pipelines that must be present in order for users in one domain to access resources in another domain. All
authentication requests made between domains located inside or outside of a forest must occur over trusts. Trust
relationships within a forest are created as implicit two-way transitive trusts.
Note

• “Access to resources” in any discussion of trust relationships always assumes the limitations of access control.
Within a forest, trust relationships are automatically created between the forest root domain and any tree root domains on
the one hand, and all child domains that are subordinate to the forest root domain on the other. Because trust relationships
are two-way and transitive by default, users and computers can be authenticated between any domain containers in the
forest, as shown in the following figure.
Domains as Units of Trust and the Authentication Paths they Provide
In accordance with DNS naming standards, Active Directory domains within a single forest are created in an inverted tree
structure, with the forest root domain at the top. This tree structure requires that trusts exist between domains to facilitate
security of communications. Adding a domain tree to a forest requires specification of the forest root domain, which results in
the establishment of a trust relationship between the root domain of the new tree and the forest root domain. For more
information about trusts and root domains, see “Forests as Collections of Domain Containers that Trust Each Other” later in
this section.

What Domains Are Not

Domains are not security boundaries within the scope of Active Directory and do not provide complete isolation in the face of
possible attacks by malicious service administrators who might manage that forest. This is because a malicious service
administrator, such as a member of the Domain Admins group, can use nonstandard tools and procedures to gain full access
to any domain in the forest or to any computer in the forest. For example, service administrators in a non-root domain can
make themselves members of the Enterprise Admins or Schema Admins group.
However, administrative rights do not flow across domain boundaries, nor do they flow down through a domain tree. For
example, if you have a domain tree with domains A, B, and C, where A is the parent domain of B and B is the parent domain
of C, users with administrative rights in domain A do not have administrative rights in B, nor do users with administrative
rights in domain B have administrative rights in domain C. For a user to obtain administrative rights in a given domain, a
higher authority must grant them. This does not mean, however, that an administrator cannot have administrative rights in
multiple domains; it simply means that all rights must be explicitly defined.
For more information about isolation, see “Forests as Security Boundaries” later in this section.
Top of page
What Are Forests?
At its highest level, a forest is a single instance of Active Directory. Therefore, a forest is synonymous with Active Directory,
meaning that the set of all directory partitions in a particular Active Directory instance (which includes all domain,
configuration, schema and optional application information) makes up a forest. This means that when you have multiple
forests in an enterprise they will, by default, act separately from each other as if they were the only directory service in your
organization.
This behavior, however, is easily be modified so that multiple forests can share Active Directory responsibilities across an
enterprise. This is done by creating external or forest trust relationships between the forests. In this way, each forest can be
connected with every other forest to form a collaborative directory service solution for any enterprise with business needs
that include multiple forest collaboration.
Forests can also be defined as:

• Collections of Domain Containers that Trust Each Other

• Units of Replication

• Security Boundaries

• Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other

Within the scope of Active Directory, a forest is a collection of domain containers that inherently trust each other and other
security services that are located in that same forest. All domain containers in a forest share a common global catalog,
directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. Because all of the
domain containers are inherently joined through two-way transitive trusts, all authentication requests made from any domain
in the forest to any other domain in the same forest will be granted. In this way, all security principals that are located in
domain containers within a forest inherently trust each other.
Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies known as domain
trees. Although each domain tree consists of a unique namespace the schema and configuration data for the forest are
shared throughout all the domain containers in a forest irrespective of namespace. Each domain container in a forest must
adhere to DNS naming schemes and all domains are organized in a root and subordinate domain hierarchy. Root domains,
such as forest root and tree root domains, define the DNS namespace for their subordinate domains. Although a forest can
consist of multiple domain trees, it represents one organization. However, an organization can have multiple forests. For
more information about multiple forests, see “Forests as Units of Delegation” later in this section. As shown in the following
figure, the namespace for each root domain must be unique.
Domain Containers, Root Domains and DNS Namespaces Within a Forest
Forest Root Domain
Although trees in a forest do not share the same DNS namespace, a forest does have a single root domain, called the forest
root domain. The forest root domain is, by definition, the first domain created in the forest. The Enterprise Admins and
Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative
credentials. In Windows 2000 Active Directory, the forest root domain cannot be deleted, changed, or renamed. In Windows
Server 2003 Active Directory, the forest root domain cannot be deleted, but it can be restructured or renamed.
Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active
Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name
(also known as a DN). The distinguished name is unambiguous (identifies one object only) and unique (no other object in the
directory has this name). By using the full path to an object, including the object name and all parent objects to the root of
the domain, the distinguished name uniquely and unambiguously identifies an object within a domain hierarchy.
The distinguished name of the forest root domain is used to locate the configuration and schema directory partitions in the
namespace. The distinguished names for the Configuration and Schema containers in Active Directory always show these
containers as child objects in the forest root domain. For example, in the child domain Noam.wingtiptoys.com (where
Wingtiptoys.com is the name of the forest root domain), the distinguished name of the Configuration container is
cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of the Schema container is
cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention provides only a logical location for
these containers.
These containers do not exist as child objects of the forest root domain, nor is the schema directory partition actually a part
of the configuration directory partition: They are separate directory partitions. Every domain controller in a forest stores a
copy of the configuration and schema directory partitions, and every copy of these partitions has the same distinguished
name on every domain controller.

Tree Root Domain

A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built
as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root
domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related
to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain
(child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the
root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always
children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth).
Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have
noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each
other, the trees share a single overall namespace because names of objects can still be resolved by the same Active
Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member
trees. Transitive trusts at the root domain of each namespace provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct
trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of
the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any
two domains in different trees must pass through the forest root.

Forests as Units of Replication

Unlike domains, forests are the largest unit of replication that can be administered in an Active Directory environment. To
efficiently synchronize data between domain controllers throughout a forest, Active Directory replication transfers updates
according to directory partition. Directory partitions are used to help organize how replication occurs within a forest. Active
Directory uses four distinct directory partition types to store and copy four different types of data.
One directory partition contains domain data; the other three are forest-wide partitions, and contain configuration, schema,
and application data. This storage and replication design provides directory information to users and administrators
throughout the domain. Each domain controller receives directory updates to the data stored in its domain only, as well as
updates to the data in the two directory partitions that store configuration and schema data for the forest. As shown in the
following figure, schema and configuration data must be replicated to all domain controllers that exist in a forest, while
optional Application data is replicated only to domain controllers within the same forest running Windows Server 2003 that
are specified as replication partners.
Forest-Wide Replication Scope
The following table describes each of the three forest-wide partitions in more detail.
Forest-Wide Directory Partitions

Partition Description

Schema The schema partition contains the forest-wide schema. Each forest has one schema so that the definition of
each object class is consistent. The schema is the formal definition of all object and attribute data that can be
stored in the directory. Active Directory domain controllers include a default schema that defines many object
types, such as user and computer accounts, groups, domains, organization units, and security policies.
Administrators and programmers can extend the schema by defining new object types and attributes or by
adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that
only authorized users can alter the schema. The schema partition is replicated to each domain controller in the
forest.

Configuration The configuration partition describes the topology of the forest as well as other forest, domain and domain
controller settings. This configuration data includes a list of all domains, trees, and forests and the locations of
the domain controllers and global catalogs. The configuration partition is replicated to each domain controller in
the forest.

Application Applications and services can use application directory partitions to store application-specific data. Data stored
Partition Description

in the application directory partition is intended to satisfy cases where information needs to be replicated but
not necessarily on a global scale. Application directory partitions can contain any type of object, except security
principals. Application directory partitions are usually created by the applications that will use them to store and
replicate data. One of the benefits of an application directory partition is that, for redundancy, availability, or
fault tolerance, the data in it can be replicated to different domain controllers in a forest. The data can be
replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs
from a domain directory partition in which data is replicated to all domain controllers in that domain.
Only domain controllers running Windows Server 2003 can host a replica of an application directory partition.
Application directory partitions are created, configured, and managed by the administrator.
All forest replication is Multi-Master with the exception of the three domain-wide and two forest-wide operations master
roles. Forest-wide replication requires domain controllers and three other components of the Active Directory physical
structure to be in place for optimal performance. These components are forest-wide operations master roles, sites, and
global catalogs.

Forest-Wide Operations Master Roles

There are two operations master roles assigned for the entire forest. These include the domain naming master and the
schema master. Each forest must have one and only one schema master and one domain naming master, so these two roles
must remain in the forest root domain. The other three operations master roles are assigned to each domain in the forest.
These three roles must be unique in each domain, so each domain can have only one relative ID master, one PDC emulator,
and one infrastructure master.
In an Active Directory forest with only one domain and one domain controller, that domain controller has all the operations
master roles. For more information about operations master roles, see “How Operations Masters Work.”

Sites
Sites in Active Directory represent the physical structure, or topology, of the network. Within the scope of a forest, sites are
a representation of the physical network topology, including physical subnet and site definitions. When you establish sites,
domain controllers within a single site communicate frequently. This communication minimizes the latency within the site;
that is, the time required for a change that is made on one domain controller to be replicated to other domain controllers.
You create sites to optimize use of the bandwidth between domain controllers in different locations. For more information
about sites, see “How Active Directory Replication Topology Works.”

Global Catalogs
The global catalog stores a full copy of all Active Directory objects in the directory for its host domain and a partial copy of all
objects for all other domains in the forest. Users in a forest do not need to be aware of directory structure because all users
see a single directory through the global catalog. Applications and clients can query the global catalog to locate any object in
a forest. The global catalog is hosted on one or more domain controllers in the forest. It contains a partial replica of every
domain directory partition in the forest. These partial replicas include replicas of every object in the forest, including the
attributes most frequently used in search operations and the attributes required to locate a full replica of the object. A global
catalog is created automatically on the first domain controller in the forest. Optionally, other domain controllers can be
configured to serve as global catalogs.
A global catalog serves the following roles:

• Enables user searches for directory information about objects throughout all domains in the forest
Resolves user principal names (UPNs) during authentication, when the authenticating domain controller does not have
•
information about the account
• Supplies universal group membership information in a multiple domain environment

• Validates references to objects in other domains in the forest

For more information about global catalogs and their roles, see “How the Global Catalog Works.”
Forests as Security Boundaries
Each forest is a single instance of the directory, the top-level Active Directory container, and a security boundary for all
objects that are located in the forest. This security boundary defines the scope of authority of the administrators. In general,
a security boundary is defined by the top-level container for which no administrator external to the container can take control
away from administrators within the container. As shown in the following figure, no administrators from outside a forest can
control access to information inside the forest unless first given permission to do so by the administrators within the forest.
Enterprise Administrators Outside of a Forest Can Administer Only Within Their Own Forest

A forest is the only component of the Active Directory logical structure that is a security boundary. By contrast, a domain is
not a security boundary because it is not possible for administrators from one domain to prevent a malicious administrator
from another domain within the forest from accessing data in their domain. A domain is, however, the administrative
boundary for managing objects, such as users, groups, and computers. In addition, each domain has its own individual
security policies and trust relationships with other domains.

Forests as Units of Delegation

The forest is the largest management unit of Active Directory as well as the ultimate unit of autonomy and isolation of
authority. Members of the Enterprise Admins and forest root Domain Admins security groups are known as enterprise
administrators. Enterprise administrators control the Active Directory objects in the configuration container that do not
belong to any one domain, including Enterprise Certification Authority objects and other configuration data that affects all
domains in the forest.
Because enterprise administrators have authority over all domains in the forest, the domain administrators in each domain
must trust the enterprise administrators. You cannot truly restrict enterprise administrators from managing objects in any
domain in the forest. Enterprise administrators can always regain control over objects. Some organizations with political
challenges, such as those frequently encountered in mergers and acquisitions, might find the scope of this enterprise
authority too great and require more than one forest. If your organization requires strict isolation of authority between
domains, you must deploy multiple forests with manually created trusts between domains in the different forests.
Because each forest is administered separately, adding additional forests to your organization increases the management
overhead of the organization. The number of forests that you need to deploy is based on the autonomy and isolation
requirements of each group within your organization. Reasons to create multiple forests in your organization include:

• To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.
To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new
•
domains to a forest have forest-wide impact only within that forest, not on a trusting forest.
Because the forest is a security boundary, each forest does not trust or allow access from any other forest by default.
However, in Windows Server 2003 Active Directory, transitive trust relationships can be manually established between
forests to establish cross-forest access to resources, so that users in one forest can access resources in another forest.
Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support
for accessing resources and other objects across multiple forests. By using forest trusts, you can link two different Windows
Server 2003 forests to form a one-way or two-way transitive trust relationship. A forest trust allows administrators to
federate two Active Directory forests with a single trust relationship to provide a seamless authentication and authorization
experience across the forests.
When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can
be routed between forests to provide access to resources in both forests. Trust security settings and firewalls can be
configured between domains in different forests that are joined by trust relationships to limit cross-forest connectivity to
specific users or applications. For more information about trust security settings, see “Security Considerations for Trusts.”
A forest trust can be created only between a forest root domain in one Windows Server 2003 forest and a forest root domain
in another Windows Server 2003 forest. Forest trusts can be created between two forests only and cannot be implicitly
extended to a third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and another forest trust
is created between Forest 2 and Forest 3, Forest 1 does not have an implicit trust with Forest 3. The following figure shows
two separate forest trust relationships between three Windows Server 2003 forests in a single organization.
Two Forest Trusts Between Three Windows Server 2003 Forests

Top of page
Related Information
The following resources contain additional information that is relevant to this section.
How Active Directory Replication Topology
•
Works
• How Core Group Policy Works

• How Domains and Forests Work

• How Operations Masters Work

• How the Active Directory Schema Works

• How the Global Catalog Works

• Security Considerations for Trusts

How Domains and Forests Work

Updated: March 28, 2003
How Domains and Forests Work
In this section

• Domain and Forest Structure

• Active Directory Objects

• Domain and Forest Protocols and Programming Interfaces

• Domains and Forests Processes and Interactions

• Network Ports used by Domains and Forests

• Related Information
Active Directory stores data for an entire forest. A forest is a distributed database, which is made up of directory partitions
spread across multiple computers. A domain is one partition of the database; each domain contains Active Directory objects,
such as security principal objects (users, computers, and groups) to which you can grant or deny access to network
resources. All domain data stored in the domain directory partition is replicated to domain controllers in that domain only.
The directory partitions that store configuration and schema information are replicated to domain controllers in all domains.
In this way, Active Directory provides a data repository that is logically centralized but physically distributed. Because all
domain controllers store forest-wide configuration and schema information, a domain controller in one domain can reference
a domain controller in any other domain if the information that it is requesting is not stored locally.
This section details how domains and forests work, discusses the various components of domains and forests, describes
several common processes that depend on domains and forests, and lists the network ports related to domains and forests.
 Top of page
Domain and Forest Structure
A forest consists of a hierarchical structure of domain containers that are used to categorically store information about
objects on the network. Domain containers are considered the core functional units in the forest structure. This is because
each domain container in a forest is used primarily to store and manage Active Directory objects, most of which have a
physical representation (such as people, printers, or computers). Forests also provide the structure by which domain
containers can be segregated into one or more unique Domain Name System (DNS) namespace hierarchies known as domain
trees.
In addition, the domain tree hierarchy is based on trust relationships — that is, the domain containers are linked by intra-
forest trust relationships. When it is necessary for domain containers in the same organization to have different namespaces,
you can create a separate tree for each namespace. In Active Directory, the roots of trees are linked automatically by two-
way, transitive trust relationships. Trees linked by trust relationships form a forest. A single tree that is related to no other
trees constitutes a forest of one tree. The domain and forest structure is made up of the following components:

• Cross-References

• Trust Relationships

• Forest Root
Domain Trees and Child
•
Domains
• Domain Names
For more information about Active Directory Domains and DNS, see “How DNS Support for Active Directory Works.”
This section describes the structure and function of these components, and describes how this structure helps administrators
manage the network so that users can accomplish business objectives.

Cross-References
Cross-references enable every domain controller to be aware not only of the partitions that it holds, but of all directory
partitions in the forest. The information contained within cross-references form the glue that holds the pieces of the domain
and forest structure together. Because Active Directory is logically partitioned, and directory partitions are the discrete
components of the directory that replicate between domain controllers, either all objects in a directory partition are present
on a particular domain controller or no objects in the directory partition are present on the domain controller. For this reason,
cross references have the effect of linking the partitions together, which allows operations such as searches to span multiple
partitions.
Cross-references are stored as directory objects of the class crossRef that identify the existence and location of all directory
partitions, irrespective of location in the directory tree. In addition, these objects contain information that Active Directory
uses to construct the directory tree hierarchy. Values for the following attributes are required for each cross-reference:
nCName. The distinguished name of the directory partition that the crossRef object references. (The prefix nC stands for
•
naming context, which is a synonym for directory partition.) The combination of all of the nCName properties in the forest
defines the entire directory tree, including the subordinate and superior relationships between partitions.
dNSRoot. The DNS name of the domain where servers that store the particular directory partition can be reached. This
•
value can also be a DNS host name.

How Cross-Reference Information is Propagated Throughout the Domain and Forest

Structure
For every directory partition in a forest, there is an internal cross-reference object stored in the Partitions container
(cn=Partitions,cn=Configuration,dc=ForestRootDomain). Because cross-reference objects are located in the Configuration
container, they are replicated to every domain controller in the forest, and thus every domain controller has information
about the name of every partition in the forest. By virtue of this knowledge, any domain controller can generate referrals to
any other domain in the forest, as well as to the schema and configuration directory partitions.
When you create a new forest, the Active Directory Installation Wizard creates three directory partitions: the first domain
directory partition, the configuration directory partition, and the schema directory partition. For each of these partitions, a
cross-reference object is created automatically. Thereafter, when a new domain is created in the forest, another directory
partition is created and the respective cross-reference object is created. When the configuration directory partition is
replicated to the new domain controller, a cross-reference object is created on the domain naming master and is then
replicated throughout the forest.
Note
The state of cross-reference information at any specific time is subject to the effects of replication
•
latency.
For more information about cross-reference objects, see “How Active Directory Searches Work.” Cross-reference objects can
also be used to generate referrals to other directory partitions located in another forest through external cross-references.

External Cross-References
An external cross-reference is a cross-reference object that can be created manually to provide the location of an object that
is not stored in the forest. If your Lightweight Directory Access Protocol (LDAP) clients submit operations for an external
portion of the global LDAP namespace against servers in your forest, and you want servers in your forest to refer the client to
the correct location, you can create a cross-reference object for that directory in the Partitions container. There are two ways
that external cross-references are used:
To reference external directories by their disjoint directory name (a name that is not contiguous with the name of this
•
directory tree). In this case, when you create the cross-reference, you create a reference to a location that is not a child of
any object in this directory.
To reference external directories by a name that is within the Active Directory namespace (a name that is contiguous with
•
the name of this directory tree). In this case, when you create the cross-reference, you create a referenceto a location
that is a child of a real object in this directory.
Because the domain component (dc=) portion of the distinguished names of all Active Directory domains matches their DNS
addresses, and because DNS is the worldwide namespace, all domain controllers can generate external referrals to each
other automatically.

Trust Relationships
Active Directory provides security across multiple domains through intra-forest trust relationships. When there are trust
relationships between domains in the same forest, the authentication mechanism for each domain trusts the authentication
mechanism for all other trusted domains. If a user or application is authenticated by one domain, its authentication is
accepted by all other domains that trust the authenticating domain. Users in a trusted domain have access to resources in
the trusting domain, subject to the access controls that are applied in the trusting domain.
Note
Default intra-forest trust relationships are created at the time the domains are created. The number of trust relationships
•
required to connect n domains is n–1, whether the domains are linked in a single, contiguous parent-child hierarchy or
constitute two or more separate contiguous parent-child hierarchies.
A trust relationship is a relationship established between two domains that allows users in one domain to be recognized by a
domain controller in the other domain. Trusts let users access resources in the other domain, and also let administrators
manage user rights for users in the other domain. Account authentication between domains is enabled by two-way, transitive
trust relationships. All domain trusts in an Active Directory forest are two-way and transitive and are have the following
attributes:
Two-way. When you create a new child domain, the child domain automatically trusts the parent domain, and vice versa.
•
At the practical level, this means that authentication requests can be passed between the two domains in both directions.
Transitive. A transitive trust reaches beyond the two domains in the initial trust relationship. For example, if Domain A
•
and Domain B (parent and child) trust each other, and if Domain B and Domain C (also parent and child) trust each other,
Domain A and Domain C also trust each other (implicitly), even though no direct trust relationship between them exists.
At the level of the forest, a trust relationship is created automatically between the forest root domain and the root domain of
each domain tree added to the forest, with the result that complete trust exists between all domains in an Active Directory
forest. At the practical level, because trust relationships are transitive, a single logon process lets the system authenticate a
user (or computer) in any domain in the forest. As shown in the following figure, this single logon process lets the account
access resources on any domain in the forest.
Transitive Trusts Facilitate Cross-Domain Access to Resources With a Single Logon
Note
Single logons enabled by trusts do not necessarily imply that the authenticated user has rights and permissions in all
•
domains in the forest. This is because in any discussion of trust relationships, access to resources always assumes the
limitations of access control.

Forest Root Domain

The first domain created in the forest is called the forest root domain. When you create a new tree, you specify the root
domain of the initial tree, and a trust relationship is established between the root domain of the second tree and the forest
root domain. If you create a third tree, a trust relationship is established between the root domain of the third tree and the
forest root domain. Because all trust relationships created within a forest are transitive and two-way, the root domain of the
third tree also has a two-way trust relationship with the root domain of the second tree. In Windows 2000 Active Directory,
the forest root domain cannot be deleted, changed, or renamed. In Windows Server 2003 Active Directory, the forest root
domain cannot be deleted, but it can be restructured or renamed.
The distinguished name of the forest root domain is used to locate the configuration and schema directory partitions in the
namespace. The distinguished names for the configuration and schema containers in Active Directory always show these
containers as child objects in the forest root domain. For example, in the child domain Noam.wingtiptoys.com, the
distinguished name of the Configuration container is cn=configuration,dc=wingtiptoys,dc=com. The distinguished name of
the Schema container is cn=schema,cn=configuration,dc=wingtiptoys,dc=com. However, this naming convention provides
only a logical location for these containers.
The containers do not exist as child objects of the forest root domain, nor is the schema directory partition actually a part of
the configuration directory partition. They are separate directory partitions. Every domain controller in a forest stores a copy
of the configuration and schema directory partitions, and every copy of these partitions has the same distinguished name on
every domain controller. The following operations occur when you create the forest root domain:

• The Schema container and the Configuration container are created.

The Active Directory Installation Wizard assigns the PDC emulator, RID master, domain naming master, schema master,
•
and infrastructure master roles to the domain controller.
The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups
have forest-wide administrative credentials.

Domain Trees and Child Domains

A forest is a collection of one or more domain trees, organized as peers and connected by two-way, transitive trust
relationships. A single domain constitutes a tree of one domain, and a single tree constitutes a forest of one tree. Thus, a
forest is synonymous with Active Directory — that is, the set of all directory partitions in a particular directory service
instance (which includes all domains and all configuration and schema information) makes up a forest.
Trees in the same forest do not form a contiguous namespace. They form a noncontiguous namespace that is based on
different DNS root domain names. However, trees in a forest share a common directory schema, configuration, and global
catalog. (The global catalog is a domain controller that stores all objects of all domains in an Active Directory forest, which
makes it possible to search for objects at the forest level rather than at the tree level.) This sharing of common schema and
configuration data, in addition to trust relationships between their roots, distinguishes a forest from a set of unrelated trees.
Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall
namespace because names of objects can still be resolved by the same Active Directory instance.
Note
The directory schema and configuration data are shared because they are stored in separate logical directory partitions
•
that are replicated to domain controllers in every domain in the forest. The data about a particular domain is replicated
only to domain controllers in the same domain.

Domain Trees
A domain tree is a DNS namespace: it has a single root domain and is built as a strict hierarchy; each domain below the root
domain has exactly one superior, or parent, domain. The namespace created by this hierarchy, therefore, is contiguous —
each level of the hierarchy is directly related to the level above it and to the level below it, if any. In Active Directory, the
following rules determine the way that trees function in the namespace:

• A tree has exactly one name. The name of the tree is the DNS name of the domain at the root of the tree.
The names of domains created beneath the root domain (child domains) are always contiguous with the name of the tree
•
root domain.
The DNS names of the child domains of the tree root domain reflect this organization; therefore, the children of a tree root
•
domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain,
Child2.somedomain, and so forth).
Note
Tree and forest hierarchies are specific to Active Directory domains. A Windows NT 4.0 domain that is configured to trust
•
or to be trusted by a Active Directory domain is not part of the forest to which the Active Directory domain belongs.
The forest structure provides organizations with the option of constructing their enterprise from separate, distinct,
noncontiguous namespaces. Having a separate namespace is desirable under conditions where, for example, the namespace
of an acquired company should remain intact. If you have business units with distinct DNS names, you can create additional
trees to accommodate the names.
Note
Before creating a new domain tree when you want a different DNS namespace, consider creating another forest. Multiple
•
forests provide administrative autonomy, isolation of the schema and configuration directory partitions, separate security
boundaries, and the flexibility to use an independent namespace design for each forest.
When you create a new domain tree, you specify the root domain of the initial tree, and a trust relationship is established
between the root domain of the new tree (the second tree) and the forest root domain. If you create a third tree, a trust
relationship is established between the root domain of the third tree and the forest root domain. Because a trust relationship
is transitive and two-way, the root domain of the third tree also has a two-way trust relationship with the root domain of the
second tree. The following operations occur when you create a new tree root domain in an existing forest:
Location of a source domain controller in the forest root domain and synchronization of domain system time with the
•
system time of the source domain controller.
Creation of a tree-root trust relationship between the tree root domain and the forest root domain, and creation of the
•
trusted domain object (TDO) in both domains. The tree-root trust relationship is two-way and transitive.
Child Domains
Child domains can represent geographical entities (for example, the United States and Europe), administrative entities within
the organization (for example, sales and marketing departments), or other organization-specific boundaries, according to the
needs of the organization. Domains are created below the root domain to minimize Active Directory replication and to provide
a means for creating domain names that do not change. Changes in the overall domain architecture, such as domain
collapses and domain re-creation, create difficult and potentially IT-intensive support requirements. A good namespace
design should be capable of withstanding reorganizations without the need to restructure the existing domain hierarchy.
Each time you create a new child domain, a two-way transitive trust relationship (known as the parent-child trust) is
automatically created between the parent and new child domain. In this way, transitive trust relationships flow upward
through the domain tree as it is formed, creating transitive trusts between all domains in the domain tree. The parent-child
relationship is a naming and trust relationship only. Administrators in a parent domain are not automatically administrators
of a child domain. Likewise, policies set in a parent domain do not automatically apply to child domains.
The following operations occur when you create a child domain in an existing tree:

• Verification of the name that you provide as a valid child domain name.
Location of a source domain controller in the parent domain and synchronization of the system time of the child domain
•
with the system time of the source domain controller.
Creation of parent-child TDOs in the System folder on both the parent domain and the child domain. The TDO objects
•
identify two-way transitive trust relationships between the child domain and the parent domain.
Replication of the Active Directory Schema container and the Configuration container from a domain controller in the
•
parent domain.

Domain Names
Active Directory uses DNS naming standards for hierarchical naming of Active Directory domains and computers. For this
reason, domain and computer objects are part of both the DNS domain hierarchy and the Active Directory domain hierarchy.
Although these domain hierarchies have identical names, they represent separate namespaces.
The domain hierarchy defines a namespace. A namespace is any bounded area in which standardized names can be used to
symbolically represent some type of information (such as an object in a directory or an Internet Protocol [IP] address) and
that can be resolved to the object itself. In each namespace, specific rules determine how names can be created and used.
Some namespaces, such as the DNS namespace and the Active Directory namespace, are hierarchically structured and
provide rules that allow the namespace to be partitioned. Other namespaces, such as the Network Basic Input/Output
System (NetBIOS) namespace, are flat (unstructured) and cannot be partitioned.
The main function of DNS is to map user-readable computer names to computer-readable IP addresses. Thus, DNS defines a
namespace for computer names that can be resolved to IP addresses, or vice versa. In Windows NT 4.0 and earlier, DNS
names were not required; domains and computers used NetBIOS names, which were mapped to IP addresses by using the
Windows Internet Name Service (WINS). Although DNS names are required for Active Directory domains and
Windows 2000–, Windows XP–, and Windows Server 2003–based computers, NetBIOS names also are supported in Windows
Server 2003 for interoperability with Windows NT 4.0 domains and with clients that are running Windows NT 4.0 or earlier,
Windows for Workgroups, Windows 98, or Windows 95.
Note
WINS and NetBIOS are not required in an environment where computers run only Windows 2000, Windows XP or Windows
•
Server 2003, but WINS is required for interoperability between Windows 2000 Server– and Windows Server 2003–based
domain controllers, computers that are running earlier versions of Windows, and applications that depend on the NetBIOS
namespace — for example, applications that call NetServerEnum and other so-called Net* application programming
interfaces (APIs) that depend on NetBIOS.
Active Directory domains have both DNS names and NetBIOS names. In general, both names are visible to end users. The
DNS names of Active Directory domains include two parts, a prefix and a suffix. The DNS prefix is the first label in the DNS
name of the domain. The suffix is the name of the Active Directory forest root domain. For example, the first label of the
DNS name for the Child1.wingtiptoys.com domain is Child1 and is referred to as the DNS prefix. The name of the forest root
domain in that same forest is wingtiptoys.com and is referred to as the DNS suffix.

Active Directory Domain Names and the Internet

Active Directory domain names can exist within the scope of the global Internet DNS namespace. When an Internet presence
is required by an individual or organization, the Active Directory namespace is maintained as one or more hierarchical
Windows 2000 domains beneath a root domain that is registered as a DNS namespace. Registration of individual and
organizational root domain DNS names ensures the global uniqueness of all DNS names and provides for the assignment of
network addresses that are recorded in the global DNS database. Registration of the DNS name for the root domain of the
individual or organization also grants that individual or organization the authority to manage its own hierarchy of child
domains, zones, and hosts within the root domain.
Note
An organization might or might not choose to be part of the global Internet DNS namespace. However, even if the root
•
domain of the organization is not registered as an Internet DNS namespace, the DNS service is required to locate
Windows 2000–, Windows XP– and Windows Server 2003–based computers in general and Windows 2000 Server– and
Windows Server 2003–based domain controllers in particular.
For more information about domain names, see “How DNS Support for Active Directory Works.”
Top of page
Active Directory Objects
Active Directory objects represent the entities that make up a network. An object is a distinct, named set of attributes that
represents something concrete, such as a user, a printer, or an application. When you create an Active Directory object,
Active Directory generates values for some of the attributes of the object; others you provide. For example, when you create
a user object, Active Directory assigns a globally unique identifier (GUID) and a security identifier (SID), and you provide
values for such attributes of the user as the given name, surname, logon identifier, and so on. This section describes the key
identifiers assigned to objects by Active Directory and their associated naming schemes

Object Uniqueness
Each object in Active Directory is associated with at least one identifier that identifies that object as unique in an enterprise.
This object identifier is referred to as a globally unique identifier (GUID). Another identifier, referred to as a security ID
(SID), is used on security-enabled objects so that authentication and authorization services can determine its origin and
validity within the domain or forest. Active Directory objects that are security-enabled are referred to as security principals.
A security principal is an object managed by Active Directory that is automatically assigned a SID for logon authentication
and for access to resources. A security principal can be a user account, computer account, or a group, and is unique within a
single domain. A security principal object must be authenticated by a domain controller in the domain in which the security
principal object is located, and it can be granted or denied access to network resources.

GUIDs
Every object in Active Directory has a GUID, a 128-bit number assigned by the Directory System Agent when the object is
created. The GUID, which cannot be altered or removed, is stored in an attribute that is required for every object, not just
security principal objects. The GUID of each object is stored in its Object-GUID (objectGUID) property. When storing a
reference to an Active Directory object in an external store (for example, a Microsoft SQL Server database), the objectGUID
value should be used.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of the properties of an object that is
published in the global catalog. Searching the global catalog for the GUID of a User object will yield results if the user has an
account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of
finding the object you want to find. This is because the values of other object properties can change, but the Object-GUID
never changes. When an object is assigned a GUID, it always keeps that value.

Security IDs (SIDs)

When a new security principal is created, Active Directory stores the SID of the security principal in the Object-SID
(objectSID) property of the object and assigns the new object a GUID. Each security principal (as well as the domain itself)
has a SID, which is the property that authoritatively identifies the object to the Windows security subsystem. The SID of a
user, group, or computer is derived from the SID of the domain to which the object belongs; this SID is made up of the value
of the domain SID and one additional 32-bit component called the relative identifier (RID).
In Windows 2000, Windows XP and Windows Server 2003 operating systems, ACLs are used to identify users and groups by
SID, not by GUID — even ACLs on resources in Active Directory. A user gains access to, for example, a Group Policy object,
based on one of the SIDs belonging to the user, not based on the GUID for the User object.
SIDs and Migrations
When an employee moves to a different location or to a new position, their user account might need to be moved or
migrated to a different domain within the organization. Migrating a user account from one domain to another replaces the
SID of the account with a new SID and new RID assigned by the new domain. For example, if Nicolette moves from North
America to Europe, but stays in the same company, her account can be transferred with her. An administrator with the
appropriate credentials can simply move her User object from, say, the Noam.wingtiptoys.com domain to the
Euro.wingtiptoys.com domain. When the account is moved, the User object for her account needs a new SID. The domain
identifier portion of a SID issued in Noam is unique to Noam, so the SID for her account in Euro has a different domain
identifier. The RID portion of a SID is unique relative to the domain, so if the domain changes, the RID also changes.
Thus when a User object moves from one domain to another, a new SID must be generated for the user account and stored
in the Object-SID property. Before the new value is written to the property, the previous value is copied to another property
of a User object, SID History (SIDHistory). This property can hold multiple values. Each time a User object moves to another
domain, a new SID is generated and stored in the Object-SID property and another value is added to the list of old SIDs in
SIDHistory. When a user logs on and is successfully authenticated, the domain authentication service queries Active
Directory for all of the SIDs associated with the user — the current SID of the user, any old SIDs of the user, and the SIDs
for the groups to which the user belonged. All of these SIDs are returned to the authentication client and are included in the
access token of the user. When the user tries to gain access to a resource, any one of the SIDs in the access token, including
one of the SIDs in SIDHistory, can be used to authorize the user to the resource.
For more information about SIDHistory, see “How Security Identifiers Work” and “Security Considerations for Trusts.”

Object Names
Object names are used to identify accounts in an Active Directory network. Objects have both LDAP-related names and logon
names. Each object name represents a unique attribute for that object.

LDAP-Related Names
Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service. In the Windows 2000 Server
and Windows Server 2003 operating systems, all access to Active Directory objects occurs through LDAP. LDAP defines what
operations can be performed in order to query and modify information in a directory, and how information in a directory can
be accessed in compliance with established security requirements. Therefore, you can use LDAP to find or enumerate
directory objects and to query or administer Active Directory.
It is possible to query by LDAP distinguished name (which is itself an attribute of the object), but because these names are
difficult to remember, LDAP also supports querying by other attributes (for example, by using the attribute “color” to find
“color” printers). This lets you find an object without having to know the distinguished name. If your organization has several
domains, it is possible to use the same user name or computer name in different domains.
Like some other types of object names, LDAP-related names can change. The SID, globally unique ID, LDAP distinguished
name, and canonical name generated by Active Directory uniquely identify each user, computer, or group in the forest. If the
security principal object is renamed or moved to a different domain, the SID, LDAP relative distinguished name, LDAP
distinguished name, and canonical name change, but the globally unique ID generated by Active Directory does not change.
Top of page
Distinguished Name
Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active
Directory domain name and each level of container objects. The full path to the object is defined by the distinguished name
(also known as a DN). The name of the object itself, separate from the path to the object, is defined by the relative
distinguished name.
The distinguished name is unambiguous (identifies one object only) and unique (no other object in the directory has this
name). By using the full path to an object, including the object name and all parent objects to the root of the domain, the
distinguished name uniquely and unambiguously identifies an object within a domain hierarchy. It contains sufficient
information for an LDAP client to retrieve information the about the object from the directory.
For example, a user named Samantha Smith works in the marketing department of a company as a promotions coordinator.
Therefore, her user account is created in an organizational unit that stores the accounts for marketing department employees
who are engaged in promotional activities. The user identifier for Samantha Smith is Ssmith, and she works in the North
American branch of the company. The root domain of the company is wingtiptoys.com, and the local domain is
noam.wingtiptoys.com. The following distinguished name is of the user object Ssmith in the noam.wingtiptoys.com domain.
cn=Ssmith,ou=Promotions,ou=Marketing,dc=noam,dc=wingtiptoys,dc=com
Note
Active Directory tools do not display the LDAP abbreviations for the naming attributes domain component (dc=),
•
organizational unit (ou=), common name (cn=), and so forth. These abbreviations are shown only to illustrate how LDAP
recognizes the portions of the distinguished name. Most Active Directory tools display object names in canonical form, as
described later in this section. Because distinguished names are difficult to remember, it is useful to have other means for
retrieving objects. Active Directory supports querying by attribute (for example, the building number where you want to
find a printer), so an object can be found without having to know the distinguished name.
Top of page
Relative Distinguished Name
The relative distinguished name of an object is the part of the name that is an attribute of the object itself — the part of the
object name that identifies this object as unique from its siblings at its current level in the naming hierarchy. Using the
distinguished name mentioned earlier, the relative distinguished name of the object is SSmith. The relative distinguished
name of the parent object is Promotions. The maximum length allowed for a relative distinguished name is 255 characters,
but attributes have specific limits imposed by the directory schema. For example, in the case of the common name (cn),
which is the attribute type often used for naming the relative distinguished name, the maximum number of characters
allowed is 64.
Active Directory relative distinguished names are unique within a specific parent — that is, Active Directory does not permit
two objects with the same relative distinguished name under the same parent container. However, two objects can have
identical relative distinguished names but still be unique in the directory because within their respective parent containers,
their distinguished names are not the same. (For example, the object cn=SSmith,dc=noam,dc=wingtiptoys,dc=com is
recognized by LDAP as being different from cn=SSmith,dc=wingtiptoys,dc=com.)
The relative distinguished name for each object is stored in the Active Directory database. Each record contains a reference
to the parent of the object. By following the references to the root, the entire distinguished name is constructed during an
LDAP operation.
Top of page
Canonical Name
By default, the user interface in Windows 2000, Windows XP, and Windows Server 2003 displays object names that use the
canonical name, which lists the relative distinguished names from the root downward and without RFC 1779 naming attribute
descriptors; it uses the DNS domain name (the form of the name where domain labels are separated by periods). For the
LDAP distinguished name in the previous example, the respective canonical name would appear as follows:
noam.wingtiptoys.com/marketing/promotions/ssmith
Note
If the name of an organizational unit contains a forward slash character (/), Active Directory requires an escape character
•
in the form of a backslash (\) to distinguish between forward slashes that separate elements of the canonical name and
the forward slash that is part of the organizational unit name. The canonical name that appears in Active Directory Users
and Computers properties pages displays the escape character immediately preceding the forward slash in the name of the
organizational unit. For example, if the name of an organizational unit is Promotions/Northeast and the name of the
domain is Wingtiptoys.com, the canonical name is displayed as Wingtiptoys.com/Promotions\/Northeast.

Logon Names
A unique logon name is required for user security principals to gain access to a domain and its resources. Security principals
are objects to which Windows security is applied in the form of authentication and authorization. Users are security
principals, and they are authenticated (their identity is verified) at the time they log on to the domain or local computer.
They are authorized (allowed or denied access) when they use resources.
In the Windows 2000, Windows XP and Windows Server 2003 operating systems, user security principals require a unique
logon name to gain access to a domain and its resources. Security principal objects might be renamed, moved, or contained
within a nested domain hierarchy. The names of security principal objects must conform to the following guidelines:
The name cannot be identical to any other user, computer, or group name in the domain. It can contain up to 20
•
uppercase or lowercase characters except for the following:" / \ [ ] : ; | = , + * ? <>
• A user name, computer name, or group name cannot consist solely of periods (.) or spaces.
The two types of logon names are user principal name and Security Account Manager account names.

User Principal Name

In Active Directory, each user account has a user principal name (UPN) in the format user@DNS-domain-name. A UPN is a
friendly name assigned by an administrator that is shorter than the LDAP distinguished name used by the system and easier
to remember. The UPN is independent of the DN of the user object, so a user object can be moved or renamed without
affecting the user logon name. When logging on using a UPN, users do not have to choose a domain from a list on the logon
dialog box.
The three parts of a UPN are the UPN prefix (user logon name), the @ character, and the UPN suffix (usually a domain
name). The default UPN suffix for a user account is the DNS name of the Active Directory domain where the user account is
located. For example, the UPN for user Frank Miller, who has a user account in the Wingtiptoys.com domain (if
Wingtiptoys.com is the only domain in the tree), is FMiller@Wingtiptoys.com. The UPN is an attribute (userPrincipalName) of
the security principal object. If the userPrincipalName attribute of a User object has no value, the User object has a default
UPN of userName@DnsDomainName.
If your organization has many domains forming a deep domain tree organized by department and region, default UPN names
can become unwieldy. For example, the default UPN for a user might be Sales.westcoast.microsoft.com. The logon name for
a user in that domain is user@sales.westcoast.microsoft.com. Instead of accepting the default DNS domain name as the UPN
suffix, you can simplify both administration and user logon processes by providing a single UPN suffix for all users. (The UPN
suffix is used only within the Active Directory domain and is not required to be a valid DNS domain name.) You can choose to
use your e-mail domain name as the UPN suffix — userName@microsoft.com. This gives the user in the example the UPN
name of user@microsoft.com.
For a UPN–based logon, a global catalog might be necessary, depending on the user logging on and the domain membership
of the computer where the user logs on. A global catalog is needed if the user logs on with a non-default UPN and the
computer account of the user is in a different domain than the user account of the user. For example, if, instead of accepting
the default DNS domain name as the UPN suffix (in the example user@sales.westcoast.microsoft.com), you provide a single
UPN suffix for all users (so that the user then becomes simply user@microsoft.com), a global catalog is required for logon.
You use the Active Directory Domains and Trusts tool to manage UPN suffixes for a domain. UPNs are assigned at the time a
user is created. If you have created additional suffixes for the domain, you can select from the list of available suffixes when
you create the user or group account. The suffixes appear in the list in the following order:
Alternate suffixes (if any; last one created appears
•
first)
• Root domain

• The current domain

SAM Account Name

A Security Accounts Manager (SAM) account name is required for compatibility with Windows NT 3.x and Windows NT 4.0
domains. The user interface in Windows 2000, Windows XP, and Windows Server 2003 refers to the SAM account name as
User logon name (pre-Windows 2000).
SAM account names are sometimes referred to as flat names because — unlike DNS names — SAM account names do not
use hierarchical naming. Because SAM names are flat, each one must be unique in the domain.

Organizational Units
Active Directory allows administrators to create a hierarchy within a domain that meets the needs of their organization. The
object class of choice for building these hierarchies is the organizationalUnit, a general-purpose container that can be used
to group most other object classes together for administrative purposes. An organizational unit in Active Directory is
analogous to a directory in the file system; it is a container that can hold other objects. You can use organizational units for
purposes such as creating an administrative hierarchy, applying Group Policy, and delegating control of administration.

Administrative Hierarchy
Organizational units can be nested to create a hierarchy within a domain and form logical administrative units for users,
groups, and resource objects, such as printers, computers, applications, and file shares. The organizational unit hierarchy
within a domain is independent of the structure of other domains; each domain can implement its own hierarchy. Likewise,
domains that are managed by a central authority can implement similar organizational unit hierarchies. The structure is
completely flexible, which allows organizations to create an environment that mirrors the administrative model, whether it is
centralized or decentralized.

Group Policy
Group Policy can be applied to organizational units to define the abilities of groups of computers and users that are contained
within the organizational units. Levels of control range from complete desktop lockdown to a relatively autonomous user
experience. Group Policy can affect functionality, such as what applications are available to a group of users, what features
within an application are accessible on a particular computer, where documents are saved, and can affect access and user
permissions. Group Policy also affects where, when, and how application and operating system updates or special scripts are
applied.
Group Policy settings are stored as Group Policy objects in Active Directory. A Group Policy object can be associated with one
or more Active Directory containers, such as a site, domain, or organizational unit.

Delegation of Control
The Active Directory object-based security model implements default access control that is propagated down a subtree of
container objects. You can use this technology to determine the security for an entire group of objects according to the
security that you set on the organizational unit that contains the objects. By default, most Active Directory objects inherit
ACEs from the security descriptor on their parent container object. If necessary, you can change the inherited permissions.
However, as a best practice, you should avoid changing the default permissions or inheritance settings on Active Directory
objects unless you have additional security requirements.
Note
Because Active Directory is indexed, you can organize the tree to match your administrative model, instead of having to
•
organize it for ease of browsing.
Inheritance enables the access control information defined at a container object in Active Directory to apply to the security
descriptors of any subordinate objects, including other containers and their objects. One benefit this provides is that it
eliminates the need to apply permissions each time a child object is created. You can apply or delegate administrative control
over directory objects to organizational units by setting access control.
This inheritance of access effectively delegates administrative control to individuals in the organization. The best way to take
full advantage of delegation and inherited control on directory objects is to organize the hierarchy to match the way that the
directory is administered.

User Accounts and Access Control

Active Directory authenticates and authorizes security principals such as user, inetorgperson, and computer accounts to
access shared resources on the network. The Local Security Authority (LSA) is the security subsystem responsible for all
interactive user authentication and authorization services on a local computer. The LSA also processes authentication
requests made through the Kerberos V5 protocol or the NTLM protocol in Active Directory.
Once the identity of a user is verified in Active Directory, the LSA on the authenticating domain controller creates a security
access token for that user. An access token contains the name of the user, the groups to which that user belongs, a SID for
the user, SIDs included in the SIDHistory property and all of the SIDs for the groups to which the user belongs.
The information in the access token is used to determine the level of access a user has to resources whenever the user
attempts to access them. The SIDs in the access token are compared with the list of SIDs that make up the discretionary
access control list (DACL) on the resource to ensure that the user has sufficient permission to access the resource. This is
because the access control process identifies user accounts by SID rather than by name.
Note
When a domain controller provides an access token to a user, the access token only contains information about
•
membership in domain local groups if the domain local groups are local to the domain where the domain controller is
located.

User Authorization
In addition to securing network access through user authentication, Active Directory protects shared resources by facilitating
user authorization. Once a user logon has been authenticated by Active Directory, the user rights assigned to the user
through security groups and the permissions assigned on the shared resource determine if the user will be authorized to
access that resource. This authorization process protects shared resources from unauthorized access and permits access to
only authorized users or groups.
Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory,
access control is administered at the object level by setting different levels of access, or permissions, to objects, such as Full
Control, Write, Read, Delete, or No Access. Access control in Active Directory defines how users can use Active Directory
objects. By default, most permissions on objects in Windows Server 2003 Active Directory are at the most secure setting.
The elements that define access control permissions on Active Directory objects include security descriptors and the concept
of object inheritance.

Security Descriptors
Access control permissions are assigned to securable objects and Active Directory objects to control how different users can
use each object. A securable object, or shared resource, is an object that is intended to be used over a network by one or
more users, and includes files, printers, folders, and services. All securable objects and Active Directory objects store access
control permissions in security descriptors.
A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object:
these are the discretionary access control list (DACL) and the system access control list (SACL).
Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access
permissions on an object. If a DACL does not explicitly allow access to a user, or to any group that a user is a member of,
the user is implicitly denied access to that object. By default, a DACL is controlled by the owner of an object or the person
who created the object (In Windows, the creator of an object is also the owner). The DACL contains access control entries
(ACEs) that determine user access to the object.
System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully
access or fail to access an object. Auditing is used to monitor events related to system or network security, to identify
security breaches, and to determine the extent and location of any damage. By default, a SACL is controlled by the owner of
an object or the person who created the object. A SACL contains ACEs that determine whether to record a successful or
failed attempt by a user to access an object using a given permission, for example, Full Control or Read.
Active Directory allows you to apply access control permissions to objects at very low levels, including the ability to assign
permissions on a per-attribute basis. To view DACLs and SACLs on Active Directory objects using Active Directory Users and
Computers, on the View menu, click Advanced Features to access the Security tab for each object. You can also use the
DSACLS support tool to manage access control lists in Active Directory.
By default, DACLs and SACLs are associated with every Active Directory object, which helps reduce attacks to your network
by malicious users or any accidental mistakes made by domain users.

Computer Accounts
Each computer account created in Active Directory has a relative distinguished name, a pre-Windows 2000 computer name
(Security Accounts Manager account name), a primary DNS suffix, a DNS host name, and a service principal name (SPN).
The administrator enters the computer name when creating the computer account. This computer name is used as the LDAP
relative distinguished name.
Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the relative distinguished name. The
administrator can change the pre-Windows 2000 name at any time.
The DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). The full computer
name is a concatenation of the computer name (the first 15 bytes of the SAM account name of the computer account without
the $ character) and the primary DNS suffix (the DNS domain name of the domain in which the computer account exists). It
is listed on the Computer Name tab in System Properties in Control Panel.
By default, the primary DNS suffix portion of the FQDN for a computer must be the same as the name of the Active Directory
domain where the computer is located. To allow different primary DNS suffixes, a domain administrator might create a
restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This
attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or LDAP.
The SPN is a multivalue attribute. It is usually built from the DNS name of the host. The SPN is used in the process of mutual
authentication between the client and the server hosting a particular service. The client finds a computer account based on
the SPN of the service to which it is trying to connect. The SPN can be modified by members of the Domain Admins group.
 Top of page
Domain and Forest Protocols and Programming Interfaces
The primary protocol that is used by domain controllers in every domain throughout the forest is LDAP, which runs on top of
TCP/IP. LDAP is both a protocol and an API. In addition, the secured communications between domain controllers must use
the remote procedure call (RPC) protocol for Messaging Application Programming Interface (MAPI), replication, domain
controller management, and SAM-related operations.

LDAP
LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can also run
over User Datagram Protocol (UDP) connectionless transports. Clients can use LDAP to query, create, update, and delete
information that is stored in a directory service over a TCP connection through the TCP default port 389. Active Directory
supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 3377). LDAP v3 is an industry standard that can be used with any directory
service that implements the LDAP protocol. LDAP is the preferred and most common way of interacting with Active Directory.
Historically, LDAP is a simplified (lightweight) version of Directory Access Protocol (DAP), which is the original protocol that
was used to interact with X.500 directories. X.500 defines an earlier set of standards that was developed by the International
Organization for Standardization (ISO). LDAP is simpler than DAP in two key ways:
Rather than using its own protocol stack according to the Open Systems Interconnection (OSI) networking model, LDAP
•
communicates over Internet Protocol (IP) by using either UDP or TCP.
• LDAP syntax is easier to use than DAP syntax.
For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access. The following key
aspects characterize LDAP:
The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and over UDP
•
for connectionless transport (sent or received data is not acknowledged).
• Most protocol data elements can be encoded as ordinary strings, for example, as distinguished names.

• Referrals to other servers can be returned to the client.

Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated security
•
services. SASL Digest is supported in Windows Server 2003 as the authentication standard for LDAP.
• Attribute values and distinguished names can be internationalized using the ISO 10646 character set.

• The protocol can be extended to support new operations, and controls can be used to extend existing operations.

• The schema is published through an attribute on the directory root object (rootDSE) for use by clients.
For more information about LDAP, see “How Active Directory Searches Work.”

RPC
Active Directory uses remote procedure call (RPC) for replication (REPL) and domain controller management
communications, MAPI communications, and SAM-related communications. RPC is a powerful, robust, efficient, and secure
interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality located in a
different process. That different process can be on the same computer, on the local area network (LAN), or across the
Internet.

Authentication Protocols
Domain controllers authenticate users and applications by using one of two protocols: either the Kerberos version 5
authentication protocol or the NTLM authentication protocol. When two Active Directory domains or forests are connected by
a trust, authentication requests made using these protocols can be routed to provide access to resources in both forests.

NTLM
The NTLM protocol is the default protocol used for network authentication in the Windows NT 4.0 operating system. For
compatibility reasons, it is used by Active Directory domains to process network authentication requests that come from
earlier Windows-based clients and servers. Computers running Windows 2000, Windows XP or Windows Server 2003 use
NTLM only when authenticating to servers running Windows NT 4.0 and when accessing resources in Windows NT 4.0
domains.
When the NTLM protocol is used between a client and a server, the server must contact a domain authentication service on a
domain controller to verify the client credentials. The server authenticates the client by forwarding the client credentials to a
domain controller in the client account domain.

Kerberos Version 5 Protocol

The Kerberos version 5 protocol is the default authentication protocol used by computers running Windows 2000,
Windows XP Professional, or Windows Server 2003. This protocol is specified in RFC 1510 and is fully integrated with Active
Directory, server message block (SMB), HTTP, and RPC, as well as the client and server applications that use these protocols.
In Active Directory domains, the Kerberos protocol is used to authenticate logons when any of the following conditions is
true:

• The user who is logging on uses a security account in an Active Directory domain.

• The computer that is being logged on to is a Windows 2000, Windows XP or Windows Server 2003–based computer.

• The computer that is being logged on to is joined to an Active Directory domain.

• The computer account and the user account are in the same forest.
The computer from which the user is trying to access resources is located in a non-Windows-based operating system
•
Kerberos version 5 realm.
If any computer involved in a transaction does not support the Kerberos version 5 protocol, the NTLM protocol is used.
The authentication protocol of choice for Active Directory authentication requests is Kerberos V5. In contrast to NTLM, when
the Kerberos protocol is used, the server does not have to contact the domain controller. Instead, the client gets a ticket for
a server by requesting one from a domain controller in the server account domain; the server validates the ticket without
consulting any other authority.
For more information about Kerberos, see “How the Kerberos Version 5 Authentication Protocol Works.”

Active Directory APIs

You can use the following application programming interfaces (APIs) to access information in any LDAP directory including
Active Directory:
Active Directory Service Interface
•
(ADSI)
• LDAP C API

• REPL

• MAPI

• SAM

ADSI
Active Directory Service Interfaces (ADSI) provides a simple, powerful, object-oriented interface to Active Directory. ADSI
makes it easy for programmers and administrators to create directory programs by using high-level tools, such as Microsoft
Visual Basic, without having to worry about the underlying differences between the different namespaces.
ADSI is supplied as a software development kit that enables you to build or buy programs that give you a single point of
access to multiple directories in your network environment, whether those directories are based on LDAP or another protocol.
ADSI is fully scriptable for ease of use by administrators.
ADSI also enables access to Active Directory by exposing objects stored in the directory as Component Object Model (COM)
objects. A directory object is manipulated using the methods available on one or more COM interfaces. ADSI has a provider-
based architecture that allows COM access to different types of directories for which a provider exists.

LDAP C
The LDAP C API, defined in Internet standard RFC 1823, is a set of low-level C-language APIs to the LDAP protocol. Microsoft
supports LDAP C APIs on all Windows platforms.
Developers have the choice of writing Active Directory-enabled applications using LDAP C APIs or ADSI. LDAP C APIs are
most often used to ease portability of directory-enabled applications to the Windows platform. ADSI is a more powerful
language and is more appropriate for developers writing directory-enabled code on the Windows platform.
LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to the DSA through the LDAP
interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.

REPL
The REPL management interface provides functionality for finding data about domain controllers, converting the names of
network objects between different formats, manipulating SPNs and DSAs, and managing replication of servers.

MAPI
Messaging clients gain access to the Microsoft Exchange Server directory service by using MAPI address book providers. For
compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book provider, which provides
access to Active Directory, for example, to find the telephone number of a user.

SAM
Security Accounts Manager (SAM) is a proprietary interface for connecting to the DSA on behalf of clients that use
Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM.
Replication with Windows NT 4.0 backup domain controllers (BDCs) goes through the SAM interface as well.
Top of page
Domain and Forest Processes and Interactions
Many network related operations depend on domains and forests in order to complete various tasks. This section describes
some of the processes and interactions that commonly occur within the boundaries of domains or forests.

Logging on to a Domain
When a user with an account in an Active Directory domain logs on at the keyboard of a computer running Windows 2000,
Windows XP or Windows Server 2003, the logon request is processed in three stages:
1. The user requests admission to the ticket-granting service for the domain.
This is accomplished through an Authentication Service (AS) Exchange between the Kerberos security support provider
(SSP) on the computer and the Key Distribution Center (KDC) in the domain in which the user account exists. The result
is a ticket-granting ticket (TGT) that the user can present in future transactions with this KDC.
2. The user requests a ticket for the computer.
This is accomplished through a Ticket-Granting Service (TGS) Exchange between the Kerberos SSP on the computer and
the KDC for the domain in which the computer account exists. The result is a session ticket that the user can present
when he or she requests access to system services on the computer.
3. The user requests admission to Local System services on the computer.
This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer.
If the account domain of the computer is different from the account domain of the user, an extra step is involved. Before the
Kerberos SSP can request a session ticket for the computer, it must ask the KDC in the domain where the user account
exists for a TGT that is good for admission to the KDC in the domain where the computer account exists. The SSP can then
present the TGT to the KDC in the domain of the computer and get a session ticket for the computer.
The precise steps in the logon process depend on how the computer is configured. With standard configurations of Windows,
interactive users log on with a password. In another optional configuration of Windows, users log on with a smart card.
Although the basic process is the same for both configurations, there are some differences. For more information about the
domain logon process, see “How Interactive Logon Works.”

Processing Authentications Across Domains and Forests

When a request for authentication is referred to a domain, before the domain controller in that domain authenticates the
user to access resources in the domain, it must determine whether a trust relationship exists with the domain from which the
request comes, as well as the direction of the trust and whether the trust is transitive or nontransitive. The authentication
process between trusted domains varies according to the authentication protocol in use. The Kerberos version 5 and NTLM
protocols in Windows 2000 Server and Windows Server 2003 process referrals for authentication to a domain differently, as
do other authentication protocols, such as Digest and SChannel, that Windows 2000 Server and Windows Server 2003
support.
In an Active Directory environment the Kerberos-based authentication process is most commonly used. To access a shared
resource in another domain by using Kerberos authentication, a computer where the user logs on first requests a ticket from
a domain controller in its account domain to the server in the trusting domain that hosts the requested resource. This ticket
is then issued by an intermediary trusted by both the requesting computer and the server. The computer then presents this
trusted ticket to the server in the trusting domain for authentication. This process, however, becomes more complex when a
workstation in one forest attempts to access data on a resource computer in another forest.
In this case, the Kerberos authentication process contacts the domain controller for a service ticket to the SPN of the
resource computer. Once the domain controller queries the global catalog and determines that the SPN is not in the same
forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that
point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it
reaches the domain where the resource is located. For more detailed information about how authentication requests are
processed across domains and forests, see “How Domain and Forest Trusts Work.”

Joining a Computer to a Domain

Joining a computer to a domain creates the computer account object for the client in an Active Directory location where all
computer accounts are created by default during a join operation. The default location is set to the Computers container in
Active Directory. A computer account differs from a user account in that it identifies the computer to the domain, while a
user account identifies a user to a computer.
The act of joining a computer to a domain creates an account for the computer on the domain if it does not already exist.
When you join a client computer running Windows NT 4.0, Windows 2000, Windows XP or Windows Server 2003 to an Active
Directory domain, the following events occur:

• The domain name is validated.

• A domain controller in the domain is located through a call to the DsGetDcName API.
A session is established with the domain controller under the security context of the passed-in credentials that are
•
supplied in the Network Identification tab under System Properties in Control Panel.
The computer account is enabled. If the flags so specify (NETSETUP_ACCT_CREATE), the APIs create the computer
•
account on the domain controller.
• The local password for this account is created in the Local Security Authority (LSA).
The local primary domain information LSA policy is set to refer to the new domain. This includes the domain name and the
•
domain SID.
Note
For clients running Windows 2000, Windows XP and Windows Server 2003 only, the LSA policy consists of the domain
•
name, domain SID, DNS domain name, DNS forest name, and domain GUID.
• The DNS name assigned to the local computer is updated.
The local group membership is changed to add members of the Domain Admins group to the Local Accounts
•
Administrators group.
• The Net Logon trusted domain cache is initialized to the trusted domains domain list.
For clients running Windows 2000, Windows XP and Windows Server 2003 only, the Windows Time Service is enabled and
•
started.
• The Net Logon service is started.
To join a workstation or member server to a domain, you can use the Netdom tool. For example, to join a workstation to the
Wingtiptoys.com domain in the engineering organizational unit, type the following command at the workstation:
Netdom join /d:wingtiptoys.com /OU:OU=engineering,DC=wingtiptoys,DC=com
When a computer joins a domain, the following changes occur on domain controllers running Windows NT 4.0, Windows 2000
Server and Windows Server 2003:
A computer object is created. The name of this object is generated by appending a dollar sign ($) to the name (uppercase
•
letters) of the client.
On Windows 2000 Server– and Windows Server 2003–based domain controllers only, the Net Logon service creates SPNs
•
on the computer object.

Netsetup.log
When joining a computer to an Active Directory domain, the Networking Setup (NetSetup) utility installs all the necessary
Microsoft supported networking components. The Netsetup.log file provides information about attempts to join domains and
records any errors that might prevent the join operation from succeeding.
Registering DNS Names and Locating Domain Controllers
When a Windows 2000 Server–based server or Windows Server 2003–based member server is promoted to a domain
controller by installing Active Directory, the Net Logon service registers the DNS resource records necessary for network
hosts and services to locate the domain controller on the network. When network hosts and services attempt an operation
(such as joining a domain) that requires a domain controller, the locator mechanism attempts to locate the domain controller
through DNS.
DNS is used because every Active Directory–based domain controller dynamically registers SRV records in DNS. The SRV
records enable servers to be located by service type (for example, LDAP) and protocol (for example, TCP). Because domain
controllers are LDAP servers that communicate over TCP, SRV records can be used to find the DNS computer names of
domain controllers. In addition to registering LDAP-specific SRV records, Net Logon also registers Kerberos v5 authentication
protocol–specific SRV records to enable locating servers that run the Kerberos Key Distribution Center (KDC) service.
Domain controllers not only register their DNS domain names on a DNS server, but also register their NetBIOS names by
using a transport-specific mechanism (for example, WINS). Thus, a DNS client locates a domain controller by querying DNS,
and a NetBIOS client locates a domain controller by querying the appropriate transport-specific name service. The domain
controller locator service consists of two main parts:

• Locator finds which domain controllers are registered with a DNS server.
Locator submits a DNS query to the DNS server to locate a domain controller in the specified
•
domain.
After this query is resolved, an LDAP User Datagram Protocol (UDP) lookup is sent to one or more of the domain controllers
listed in the response to the DNS query to ensure their availability. Finally, the Net Logon service caches the discovered
domain controller to aid in resolving future requests.
For more information about the DC Locator process, see “How DNS Support for Active Directory Works.”

Raising Domain and Forest Functional Levels

When Active Directory is installed on a server running Windows Server 2003, a set of basic Active Directory features is
enabled by default. In addition to the basic Active Directory features on individual domain controllers, there are new domain-
and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows
Server 2003.
To enable the new domain-wide features, all domain controllers in the domain must be running Windows Server 2003, and
the domain functional level must be raised to Windows Server 2003. To enable new forest-wide features, all domain
controllers in the forest must be running Windows Server 2003, and the forest functional level must be raised to Windows
Server 2003.
Before raising the forest functional level to Windows Server 2003, verify that all domains in the forest are set to the domain
functional level of Windows 2000 native or Windows Server 2003. Note that domains that are set to the domain functional
level of Windows 2000 native will automatically be raised to Windows Server 2003 at the same time the forest functional
level is raised to Windows Server 2003. For more detailed information about functional levels, see the “How Active Directory
Functional Levels Work.”

Replicating Directory Partitions

Active Directory uses RPC over IP to transfer replication data between domain controllers. RPC over IP is used for both
intersite and intrasite replication. To keep data secure while in transit, RPC over IP replication uses both authentication
(using the Kerberos V5 authentication protocol) and data encryption.
When a direct or reliable IP connection is not available, replication between sites can be configured to use the Simple Mail
Transfer Protocol (SMTP). However, SMTP replication functionality is limited, and requires an enterprise certification authority
(CA). SMTP can only be used to replicate the configuration, schema and application directory partitions, and does not support
the replication of domain directory partitions. For more detailed information about the replication process, see “How Active
Directory Replication Topology Works.”
Top of page
Network Ports Used by Domains and Forests
The following tables list the network ports that are associated with domains and forests.
Port Assignments for Raising Active Directory Functional Levels
Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Port Assignments for Data Store

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Service Publication and SPNs

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Kerberos 88 88
Port Assignments for Raising Active Directory Searches

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Global Catalogs

Service Name UDP TCP

LDAP N/A 3268

LDAP N/A 3269 (global catalog Secure Sockets Layer [SSL])

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL 135 135 (endpoint mapper)

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Replication
Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

LDAP N/A 3268

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Operations Masters

Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

Netlogon N/A 137

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Interactive Logon

Service Name UDP TCP

Kerberos 88 88

Local Security Authority (LSA) RPC Dynmaic RPC Dynamic RPC

NTLM Dynamic Dynamic

Port Assignments for Kerberos V5 Protocol

Service Name UDP TCP

DNS 53 53

Kerberos 88 88
Port Assignment for DC Locator

Service Name UDP TCP

LDAP 389 389

The following table shows the list of ports that might need to be opened before you establish trusts.
Ports Required for Trusts

Task Outbound Ports Inbound Ports From–To

Set up trusts on both sides from the LDAP (389 UDP and TCP) N/A Internal domain domain
internal forest Microsoft SMB (445 TCP) controllers–External domain
Kerberos (88 UDP) domain controllers (all ports)
Endpoint resolution —
Task Outbound Ports Inbound Ports From–To

portmapper (135 TCP) Net

Logon fixed port

Trust validation from the internal forest LDAP (389 UDP) N/A Internal domain domain
domain controller to the external forest Microsoft SMB (445 TCP) controllers–External domain
domain controller (outgoing trust only) Endpoint resolution — domain controllers (all ports)
portmapper (135 TCP) Net
Logon fixed port

Use Object picker on the external forest N/A LDAP (389 UDP and TCP) External server–Internal
to add objects that are in an internal Windows NT Server 4.0 domain PDCs (Kerberos)
forest to groups and DACLs directory service fixed port External domain domain
Net Logon fixed port controllers–Internal domain
Kerberos (88 UDP) domain controllers (Net Logon)
Endpoint resolution
portmapper (135 TCP)

Set up trust on the external forest from N/A LDAP (389 UDP and TCP) External domain domain
the external forest Microsoft SMB (445 TCP) controllers–Internal domain
Kerberos (88 UDP) domain controllers (all ports)

Use Kerberos authentication (internal Kerberos (88 UDP) N/A Internal client–External domain
forest client to external forest) domain controllers (all ports)

Use NTLM authentication (internal N/A Endpoint resolution – External domain domain
forest client to external forest) portmapper (135 TCP) Net controllers–Internal domain
Logon fixed port domain controllers (all ports)

Join a domain from a computer in the LDAP (389 UDP and TCP) N/A Internal client–External domain
internal network to an external domain Microsoft SMB (445 TCP) domain controllers (all ports)
Kerberos (88 UDP)
Endpoint resolution —
portmapper (135 TCP) Net
Logon fixed port
Windows NT Server 4.0
directory service fixed port
Top of page
Related Information
The following resources contain additional information that is relevant to this section.

• Active Directory Schema Technical Reference

• Data Store Technical Reference

• DNS Support for Active Directory Technical Reference

• Active Directory Replication Model Technical Reference

• Logon and Authentication Technologies

• Domain Controller Roles

• Active Directory Search and Publication Technologies

Active Directory Installation, Upgrade, and Migration
•
Technologies
• Windows Support Tools

Domains and Forests Tools and Settings

Updated: March 28, 2003
In this section
• Tools for Managing Domains and Forests

• Domains and Forests Registry Entries

• Domains and Forests Group Policy Settings

• Domains and Forests WMI Classes

Network Ports Used by Domains and
•
Forests
• Related Information
Administrators can use a number of methods to configure and manage Active Directory domain and forest environments.
This section contains information about the tools, registry entries, Group Policy settings, Windows Management
Instrumentation (WMI) classes, and network ports that are associated with Active Directory domains and forests.
Note
When using Windows Server 2003 Active Directory administrative tools to connect to a domain controller running
•
Windows 2000 you must first make sure that the Windows 2000–based domain controller to which you are connecting has
Service Pack 3 or later installed. This is because Windows Server 2003 administrative tools sign and encrypt all LDAP
traffic by default. If business reasons do not permit the installation of Service Pack 3 or later on domain controllers
running Windows 2000 it is possible to disable this default behavior.
Tools for Managing Domains and Forests
The following tools are associated with domains and forests.

Adsiedit.exe: ADSI Edit

Category
ADSI Edit is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
ADSI Edit is a Microsoft Management Console (MMC) tool that uses Active Directory Service Interfaces (ADSI), which
ultimately uses the LDAP protocol. This tool can be used to view and modify directory objects in the Active Directory
database.
To find more information about ADSI Edit, see “Adsiedit Overview.”
Csvde.exe: Csvde
Category
Csvde is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Csvde to import and export data from Active Directory by using files that store data in the comma-separated
value (CSV) file format. Csvde also supports batch operations that are based on CSV.
To find more information about Csvde, see Command-Line References in the “Tools and Settings Collection.”

Dcdiag.exe: Domain Controller Diagnostic Tool

Category
The Domain Controller Diagnostic Tool command-line tool (Dcdiag) is included when you install the Windows Server 2003
Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
Can Be Run From Can Be Run Against

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

You can use the Domain Controller Diagnostic Tool to verify external trusts. This tool cannot be used to verify trust
relationships based on the Kerberos version 5 authentication protocol; to verify Kerberos V5-based trust relationships, the
recommended method is to use the Netdom tool. Using the Domain Controller Diagnostic Tool you can scope your external
trust verification by site or by domain controller, check for trust establishment, check secured channel setup, and check for
ticket validity between each pair of domain controllers. By default, errors are flagged. In verbose mode, successes are
printed as well.
You can use the Domain Controller Diagnostic Tool to verify that there are sufficient resources for the DNS infrastructure
when deploying the Windows 2000 Server or Windows Server 2003 Active Directory directory service. This tool analyzes the
state of domain controllers in a forest or enterprise and reports any problems to assist in troubleshooting. As an end-user
reporting program, the Domain Controller Diagnostic Tool queries the directory service infrastructure and uses the results to
identify abnormal behavior in the system. The Domain Controller Diagnostic Tool provides a framework for executing tests to
verify different functional areas of the system. This framework selects which domain controllers are tested according to scope
directives from the user, such as enterprise, site, or single server.

Dcpol.msc: Domain Controller Security Policy

Category
Domain Controller Security Policy is a snap-in for MMC and is automatically installed when you install Active Directory. You
can also use Domain Controller Security Policy on computers not running Active Directory by installing the Administration
Tools Pack (Adminpak.msi).

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can set security settings for a domain controller in Domain Controller Security Policy.
For more information about Domain Controller Security Policy, see Help and Support Center in Windows Server 2003.
Dcpromo.exe: Active Directory Installation Wizard
Category
An Active Directory wizard that is included with Windows Server 2003 and is available from the command line or from the
Configure Your Server Wizard on any computer running Windows Server 2003.

Version compatibility
This tool is compatible with computers running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise
Edition, and Windows Server 2003, Datacenter Edition.
The Active Directory Installation Wizard provides a graphical user interface for setting up a domain controller by installing
Active Directory and, optionally, DNS. The Active Directory Installation Wizard can also be used on a Windows NT 4.0
primary domain controller (PDC) when upgrading it to Windows Server 2003 and forming a new forest, to raise the forest
functional level to Windows Server 2003 interim, if appropriate.

Domain.msc: Active Directory Domains and Trusts

Category
An Active Directory Administrative Tools MMC snap-in that is automatically installed on all domain controllers running
Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional with Adminpak.msi installed

Note
You cannot run the Windows Server 2003 Administration Tools Pack (Adminpak.msi) on a computer that is running
•
Windows XP Professional, Windows XP Home Edition, or Windows XP 64-Bit Edition Version 2003 without Windows XP
Service Pack 1 (SP1).
Active Directory Domains and Trusts provides a graphical interface in which you can view all domains in the forest. Using this
tool, an administrator can manage each of the domains in the forest, trust relationships between domains, configure the
functional level for each domain or forest, and configure the alternative user principal name (UPN) suffixes for a forest.
Active Directory Domains and Trusts can be used to accomplish most trust related tasks. It can be used to target all Active
Directory domain controllers and can verify all Active Directory trust types. Trust verification takes place between two
domains by enumerating all of the domain controllers in each domain. If you choose to have Active Directory Domains and
Trusts create both sides of the trust at once, the trust password is automatically generated.
For more information about Active Directory Domains and Trusts, see Help in Active Directory Domains and Trusts.

Dompol.msc: Domain Security Policy

Category
Domain Security Policy is a snap-in for MMC and is automatically installed when you install Active Directory. You can also use
Domain Controller Security Policy on computers not running Active Directory by installing the Administration Tools Pack
(Adminpak.msi).

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
Security settings for a domain are set in Domain Security Policy. Group Policy settings can be applied to lock-down which
users are allowed to log on to the server as well as who can access the server from the network.
For more information about Domain Security Policy, see Help and Support Center in Windows Server 2003.

Dsa.msc: Active Directory Users and Computers

Category
An Active Directory Administrative Tools MMC snap-in that is automatically installed on all Windows Server 2003 domain
controllers running Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
Can Be Run From Can Be Run Against

• Windows Server 2003, Standard Edition • Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition • Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional with Adminpak.msi installed

Active Directory Users and Computers provides a graphical user interface that can be used to manage users and computers
in Active Directory domains.
Additionally, LDAP Query can be used in this tool for the following:
To identify domain controllers running
•
Windows NT 4.0
• To connect to a domain

Dsadd.exe: Dsadd
Category
Dsadd is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsadd to add specific types of objects to the directory.
To find more information about Dsadd, see Command-Line References in the “Tools and Settings Collection.”

Dsget.exe: Dsget
Category
Dsget is a command-line tool that ships with Windows Server 2003.
Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Dsget to display the selected properties of a specific object in the directory.
To find more information about Dsget, see Command-Line References in the “Tools and Settings
•
Collection.”

Dsmod.exe: Dsmod
Category
Dsmod is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Dsmod to modify an existing object of a specific type in the directory.
To find more information about Dsmod, see Command-Line References in the “Tools and Settings Collection.”
Dsmove.exe: Dsmove
Category
Dsmove is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Dsmove to move a single object in a domain from its current location in the directory to a new location. You can
also use Dsmove to rename a single object without moving it in the directory tree.
To find more information about Dsmove, see Command-Line References in the “Tools and Settings Collection.”

Dsquery.exe: Dsquery
Category
Dsquery is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
Can Be Run From Can Be Run Against

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Dsquery to perform searches against Active Directory according to specified criteria. To find more information
about Dsquery, see Command-Line References in the “Tools and Settings Collection.”

Dsrm.exe: Dsrm
Category
Dsrm is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsrm to delete an object of a specific type, or any general object, from the directory.
To find more information about Dsrm, see Command-Line References in the “Tools and Settings Collection.”

Dssite.msc: Active Directory Sites and Services

Category
An Active Directory Administrative Tools MMC snap-in that is automatically installed on all Windows Server 2003 domain
controllers running Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
Can Be Run From Can Be Run Against

• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

You can use Active Directory Sites and Services to create, modify, and delete site configuration objects in Active Directory,
including sites, subnets, connection objects, and site links. You can also use Active Directory Sites and Services to create the
intersite topology, including mapping subnet addresses to sites, creating and configuring site links, creating manual
connection objects, forcing replication over a connection, setting a domain controller to be a global catalog server, and
selecting preferred bridgehead servers.
For more information about Active Directory Sites and Services, see Help and Support Center in Windows Server 2003.

Ldifde.exe: Ldifde
Category
Ldifde is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Ldifde to create, modify, and delete directory objects on domain controllers. You can also use Ldifde to extend
the schema, export Active Directory user and group information to other applications or services, and populate
Active Directory with data from other directory services.
To find more information about Ldifde, see Command-Line References in the “Tools and Settings Collection.”

Ldp.exe: Ldp
Category
Ldp is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
Ldp is a Lightweight Directory Access Protocol (LDAP) graphical user interface (GUI) tool that you can use to perform
operations such as connect, bind, search, modify, add, and delete against any LDAP-compatible directory, such as
Active Directory. You can also use Ldp to view objects that are stored in Active Directory, along with their metadata, such as
security descriptors and replication metadata.
To find more information about Ldp, see “Windows Support Tools.”

Netdiag.exe: Network Connectivity Tester

Category
The Network Connectivity Tester command-line tool (Netdiag) is included when you install Windows Server 2003 Support
Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
Can Be Run From Can Be Run Against

• Windows Server 2003, Standard Edition • Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition • Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional with Adminpak.msi installed

The Netdiag command-line tool examines .dll files, output from other tools, and the system registry to find potential
problems. You can use Netdiag to troubleshoot connectivity over the secured channel that exists between a workstation and
a domain controller.
For the various trust related tasks that can be performed using this tool, see the table Trust Tools Comparison by Task earlier
in this section. To find more information about Netdiag, see “Windows Support Tools.”

Netdom.exe: Windows Domain Manager

Category
The Windows Domain Manager command-line tool (Netdom) is included when you install Windows Server 2003 Support
Tools.

Version compatibility
This tool is compatible with computers running Windows XP Professional, Windows Server 2003, Standard Edition; Windows
Server 2003, Web Edition, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition.
Netdom is a command-line tool that allows you to create and manage Active Directory trust relationships (except forest
trusts) and can help reduce the number of steps needed to create a trust by using Active Directory Domains and Trusts. You
can also use the Netdom command line tool to complete batch management of trusts, join computers to domains, verify
trusts (including forest trusts) and secured channels, and obtain information about the status of trusts.
Netdom can be targeted at all Active Directory domain controllers and can verify all Active Directory trust types. Verification
is accomplished between two domains by enumerating the domain controllers in each domain. If you choose to have Netdom
create both sides of the trust at once the trust password is automatically generated.
To find more information about Netdom, see “Windows Support Tools.”

Nltest.exe: NLTest
Category
The NLTest command-line tool is included when you install Windows Server 2003 Support Tools.

Version compatibility
This tool is compatible with computers running Windows XP Professional, Windows Server 2003, Standard Edition; Windows
Server 2003, Web Edition, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition.
You can use the NLTest command-line tool to perform trust-related network administrative tasks such as testing the trust
relationship between a Windows–based computer that is a member of a domain and the domain controller on which its
computer account is located. In domains where an external trust is defined, NLTest can be used to test the trust relationship
between all domain controllers in the trusting domain and a domain controller in the trusted domain. Nltest can also be used
to verify any secured channel.
To find more information about NLTest, see “Windows Support Tools.”
Ntdsutil.exe: Ntdsutil
Category
Ntdsutil is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Ntdsutil.exe provides management capabilities for Active Directory. You can use Ntdsutil.exe to perform Active Directory
database maintenance, manage and control single-master operations, and remove replication metadata left behind by
domain controllers that are removed from the network without uninstalling Active Directory. You can also use Ntdsutil to
create application directory partitions and perform authoritative restore operations. This tool is intended for use by
experienced administrators.
To find more information about Ntdsutil, see Command-Line References in the “Tools and Settings Collection.”

Repadmin: Repadmin
Category
Repadmin is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
Administrators can use Repadmin to monitor and manage replication between domain controllers. You can determine the last
successful replication of all directory partitions, identify inbound and outbound replication partners, identify the current
bridgehead servers, view object metadata, and generally manage Active Directory replication topology. You can use
Repadmin to force replication of an entire directory partition or of a single object. You can also list domain controllers in a
site.
To find more information about Repadmin, at a command prompt type repadmin /? or see Command-Line References in the
Tools and Settings Collection.

Schmmgmt.msc: Active Directory Schema

Category
An Active Directory Administrative Tools MMCsnap-in that is automatically installed on all domain controllers running
Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

Active Directory Schema is a graphical user interface that can be used to manage Active Directory objects and their
associated attributes. The Active Directory Schema snap-in allows members of the Schema Admins group to manage the
schema through a graphical interface. You can create and modify classes and attributes and also specify what attributes are
indexed and what attributes are replicated to the Global Catalog. The tool should only be used in a test environment because
it does not permit the user to set some important values on new schema objects.
Before the snap-in can be used, it must be registered so that it appears as an available snap-in for MMC.

Setspn.exe: Setspn
Category
Setspn is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
Can Be Run From Can Be Run Against

• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
Administrators can use this command-line tool to read, modify, and delete values in the servicePrincipalNames attribute
on an Active Directory service account object.
To find more information about Setspn, see “Windows Support Tools.”
Top of page
Domains and Forests Registry Entries
The following registry entries are associated with domains and forests.

• For data store related registry entries, see “Data Store Tools and Settings.”

• For global catalog related registry entries, see “Global Catalog Tools and Settings.”
For replication related registry entries, see “Active Directory Replication Tools and
•
Settings.”
• For logon related registry entries, see “Interactive Logon Tools and Settings.”

• For Kerberos related registry entries, see “Kerberos Authentication Tools and Settings.”

• For Access Token related registry entries, see “Access Tokens Tools and Settings.”
Top of page
Domains and Forests Group Policy Settings
The following tables list and describe the Group Policy settings that are associated with domains and forests.
Group Policy Settings Associated with Data Store

Group Policy Setting Description

Audit Directory When it is enabled, this Group Policy setting causes successful and failed directory access events to
Services Access be logged in the Directory Service event log.
Group Policy Settings Associated with Active Directory Searches

Group Policy Description

Setting

Maximum size of Specifies the maximum number of objects that the system displays in response to a command to
Active Directory browse or search Active Directory.
searches This policy affects all browse displays that are associated with Active Directory, such as those in Local
Users and Groups, Active Directory Users and Computers, and dialog boxes that are used to set
permissions for user or group objects in Active Directory.
If you enable this policy, you can use it to limit the number of objects that are returned from an
Active Directory search.
If you disable this policy or if you do not configure it, the system displays up to 10,000 objects.

Enable filter in Find Displays the filter bar above the results of an Active Directory search. The filter bar consists of buttons
dialog box for applying additional filters to search results.
Group Policy Description
Setting

If you enable this policy, the filter bar appears when the Active Directory Find dialog box opens, but
users can hide it.

Hide Active Directory Hides the Active Directory folder in My Network Places.
folder The Active Directory folder displays Active Directory objects in a browse window.
If you enable this policy, the Active Directory folder does not appear in the My Network Places folder.
If you disable this policy or if you do not configure it, the Active Directory folder appears in the My
Network Places folder.
Group Policy Settings Associated with Global Catalogs

Group Policy Setting Description

Automated Site Determines whether domain controllers dynamically register DC Locator site-specific SRV resource
Coverage by the DC records for the closest sites where no domain controller for the same domain exists (or no global
Locator DNS SRV catalog server for the same forest exists). These DNS records are dynamically registered by the Net
Records Logon service, and they are used to locate domain controllers.

Sites Covered by the Specifies the sites for which global catalog servers should register the site-specific GC Locator SRV
GC Locator DNS SRV resource records in DNS. These records are registered in addition to the site-specific SRV resource
Records records registered for the site where the global catalog server is located and, if the global catalog
server is appropriately configured, for the sites without a global catalog server in the same forest for
which this global catalog server is the closest global catalog server. These records are registered by
Net Logon service.
If this policy is not configured, it is not applied to any global catalog servers and global catalog
servers use their local configuration.
Group Policy Settings Associated with Replication

Group Policy Setting Description

Account Lockout Policy: Changes to these settings in the Domain Security Policy trigger urgent replication.

• Account lockout duration

• Account lockout
threshold

• Reset account lockout

counter after

Password Policy: Changes to these settings in the Domain Security Policy trigger urgent replication.

• Enforce password
history

• Maximum password age

• Minimum password age
• Minimum password
length

• Password must meet

complexity requirements

• Store passwords using

reversible encryption
Group Policy Setting Description

Contact PDC on logon Account lockout and domain password changes rely on contacting the primary domain controller
failure (PDC) emulator urgently to update the PDC emulator with the change. If Contact PDC on logon
failure is disabled, replication of password changes to the PDC emulator occurs non-urgently.
Group Policy Settings Associated with Interactive Logon

Group Policy Setting Description

Password Policy: Changes to the Password Policy settings control:

• Enforce password history • The strength and complexity required of the password of every
user
• Maximum password age
• Minimum password age
• Minimum password length
• Password must meet complexity requirements
• Store password using reversible encryption for all
users in the domain

Audit Policy: Changes to the Audit Policy settings control:

• Audit account logon events • Auditing of logons and log offs

• Audit account management • Auditing of password and permissions changes
• Audit logon events
User Rights Assignment: Changes to the User Rights Assignment settings control:

• Access the computer from the network • Which users are allowed or disallowed to log on to perform
different tasks, including logging on as a batch job and a service
• Deny logon as a batch job
• Which users are allowed or disallowed to logon locally or through
terminal services, as well as who can or cannot access the
• Deny logon as a service
computer from the network
• Deny logon locally
• Deny logon through terminal services
• Logon as a batch job
• Logon as a service
• Logon locally
Security Options: Changes to the Security Options settings control:

• Accounts: Limit local accounts use of blank • Message text and title displayed by the GINA during an interactive
passwords to console logon only logon

• Domain member: Maximum machine account • Domain member settings

password age
• Authentication settings, including allowing or disallowing blank
• Domain member: Require strong (in passwords and password age
Windows 2000 or later) session key
Group Policy Setting Description

• Interactive logon: Do not display last user name

• Interactive logon: Do not require CTRL+ALT+DEL
• Interactive logon: Message Text for users
attempting to log on

• Interactive logon: Message title for users

attempting to log on

• Interactive logon: Number of previous logons to

cache (in case the domain controller is not
available)

• Interactive logon: Require domain controller

authentication to unlock workstation

• Interactive logon: Smart card removal behavior

• Recovery console: Allow automatic administrative
logon

• Shutdown: Allow system to be shut down without

having to log on

Group Policy Settings Associated with Access Tokens

Group Policy Setting Description

User Rights Assignment: Changes to these settings control:

• Create a token object • Calling APIs to create tokens.

• Replace a process level token • Whether a process can replace a token.
Audit Policy: Changes to this setting will:

• Audit policy change • Generate audits when rights are assigned with one of the tools discussed
earlier.
• Audit privilege use
• Enable audit privilege use. Will log when SeAssignPrimaryTokenPrivilege was
used.
• Audit process tracking
• Create an audit for assigning a primary token that contains the two
processes involved and the identity of the token assigned.

Security Options: Changes to this setting affect whether Everyone is in the token for anonymous
users.
• Network access: Let Everyone
permissions apply to anonymous users

Group Policy User Rights Assignment Settings Associated with Kerberos

Group Policy Description

Setting

Impersonate a client Windows 2000 security setting that was first introduced in Windows 2000 SP4. When you assign this
after authentication user right to a user, you permit programs that run on behalf of that user to impersonate a client. This
security setting helps to prevent unauthorized servers from impersonating clients that connect to it
through methods such as remote procedure calls (RPC) or named pipes.
Group Policy Description
Setting

By default, members of the Administrators group and the System account are assigned this user right.
The following components also are assigned this user right:

• Services that are started by the Service Control Manager

• Component Object Model (COM) servers that are started by the COM infrastructure and that are
configured to run under a specific account

Group Policy Kerberos Policy Settings Associated with Kerberos

Group Policy Setting Description

Enforce user logon Determines whether the KDC validates every request for a session ticket against the user rights
restrictions policy on the target computer. When this policy is enabled, the user requesting the session ticket
must have the right to either Log on locally or to Access this computer from network. Validation of
each request is optional because the extra step takes time and might slow network access to
services. By default, this policy is enabled.

Maximum lifetime for Determines the maximum amount of time (in minutes) that a ticket granted for a service (that is, a
service ticket session ticket) can be used to access the service. If the setting is zero minutes, the ticket never
expires. Otherwise, the setting must be greater than ten minutes and less than the setting for
Maximum lifetime for user ticket. By default, the setting is 600 minutes (10 hours).

Maximum lifetime for Determines the maximum amount of time (in hours) that a ticket-granting ticket (TGT) for a user
user ticket can be used. When a TGT expires, a new one must be requested or the existing one must be
renewed. By default, the setting is ten hours.

Maximum lifetime for Determines the longest period of time (in days) that a TGT can be used if it is repeatedly renewed.
user ticket renewal By default, the setting is seven days.

Maximum tolerance for Determines the maximum difference (in minutes) that the Kerberos V5 protocol tolerates between
computer clock the clock time on a client and the clock time on a server while still considering the two clocks
synchronization synchronous. By default, the setting is five minutes.
To find more information about these Group Policy settings, see Group Policy Settings Reference in the “Tools and Settings
Collection” or see “Account Policy Settings.”
Top of page
Domains and Forests WMI Classes
Windows Management Instrumentation (WMI) provides access to information about certain objects in a Windows 2000
Server or Windows Server 2003 operating system. WMI providers and classes represent the managed resources on a
computer and are used by administrators and developers for scripting and monitoring purposes. The following tables list and
describe the WMI classes that are associated with Active Directory domains and forests.
WMI Classes Associated with Data Store, Service Principal Names (SPNs) and Active Directory Searches

Class Name Namespace Version Compatibility

rootDSE root\directory\LDAP Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
DS_LDAP_Class_Containment root\directory\LDAP Domain controllers running:

• Windows Server 2003

Class Name Namespace Version Compatibility

• Windows 2000 Server

DS_LDAP_Instance_Containment root\directory\LDAP Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
WMI Classes Associated with Active Directory Replication

Class Name Namespace Version Compatibility

MSAD_DomainController \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
MSAD_NamingContext \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
MSAD_ReplNeighbor \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
MSAD_ReplCursor \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
MSAD_ReplPendingOp \\root\MicrosoftActiveDirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
WMI Classes Associated with Trusts

Class Name Namespace Version Compatibility

Microsoft_TrustProvider root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
Microsoft_DomainTrustStatus root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
Class Name Namespace Version Compatibility

Microsoft_LocalDomainInfo root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003

• Windows 2000 Server
WMI Classes Associated with Interactive Logon

Class Name Namespace Version Compatibility

Win32_LogonSession \root\cimv2 Computers running:

• Windows Server 2003

• Windows XP
Win32_LogonSessionMappedDisk \root\cimv2 Computers running:

• Windows Server 2003

• Windows XP
Win32_NetworkLoginProfile \root\cimv2 Computers running:

• Windows Server 2003

• Windows XP
WMI Classes Associated with Access Tokens

Class Name Namespace Version Compatibility

Win32_TokenGroups \root\cimv2 Computers running:

• Windows Server 2003

• Windows XP
Win32_TokenPrivileges \root\cimv2 Computers running:

• Windows Server 2003

• Windows XP
For more information about these WMI classes, see the WMI SDK documentation on MSDN.
Top of page
Network Ports Used by Domains and Forests
The following tables list the network ports associated with domains and forests.
Port Assignments for Raising Active Directory Functional Levels

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Port Assignments for Data Store
Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Service Publication and SPNs

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Kerberos 88 88
Port Assignments for Raising Active Directory Searches

Service Name UDP TCP

LDAP 389 389

LDAP SSL N/A 636

Global Catalog LDAP N/A 3268

Global Catalog LDAP SSL N/A 3269

Port Assignments for Global Catalogs

Service Name UDP TCP

LDAP N/A 3268

LDAP N/A 3269 (global catalog Secure Sockets Layer [SSL])

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL 135 135 (endpoint mapper)

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Replication

Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

LDAP N/A 3268

Service Name UDP TCP

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Operations Masters

Service Name UDP TCP

LDAP 389 389

LDAP N/A 686 (SSL)

RPC/REPL N/A 135 (endpoint mapper)

Netlogon N/A 137

Kerberos 88 88

DNS 53 53

SMB over IP 445 445

Port Assignments for Interactive Logon

Service Name UDP TCP

Kerberos 88 88

Local Security Authority (LSA) RPC Dynamic RPC Dynamic RPC

NTLM Dynamic Dynamic

Port Assignments for Kerberos V5 Protocol

Service Name UDP TCP

DNS 53 53

Kerberos 88 88
Port Assignment for DC Locator

Service Name UDP TCP

LDAP 389 389

The following table shows the list of ports that might need to be opened before you establish trusts.
Ports Required for Trusts

Task Outbound Ports Inbound Ports From–To

Set up trusts on both sides from the
internal forest
LDAP (389 UDP and TCP) N/A Internal domain domain
Microsoft SMB (445 TCP) controllers–External domain
Kerberos (88 UDP) domain controllers (all ports)
Endpoint resolution —
portmapper (135 TCP) Net
Logon fixed port

Trust validation from the internal forest LDAP (389 UDP) N/A Internal domain domain
domain controller to the external forest Microsoft SMB (445 TCP) controllers–External domain
domain controller (outgoing trust only) Endpoint resolution — domain controllers (all ports)
Task Outbound Ports Inbound Ports From–To

portmapper (135 TCP) Net

Logon fixed port

Use Object picker on the external forest N/A LDAP (389 UDP and TCP) External server–Internal
to add objects that are in an internal Windows NT Server 4.0 domain PDCs (Kerberos)
forest to groups and DACLs directory service fixed port External domain domain
Net Logon fixed port controllers–Internal domain
Kerberos (88 UDP) domain controllers (Net Logon)
Endpoint resolution
portmapper (135 TCP)

Set up trust on the external forest from N/A LDAP (389 UDP and TCP) External domain domain
the external forest Microsoft SMB (445 TCP) controllers–Internal domain
Kerberos (88 UDP) domain controllers (all ports)

Use Kerberos authentication (internal Kerberos (88 UDP) N/A Internal client–External domain
forest client to external forest) domain controllers (all ports)

Use NTLM authentication (internal N/A Endpoint resolution – External domain domain
forest client to external forest) portmapper (135 TCP) Net controllers–Internal domain
Logon fixed port domain controllers (all ports)

Join a domain from a computer in the LDAP (389 UDP and TCP) N/A Internal client–External domain
internal network to an external domain Microsoft SMB (445 TCP) domain controllers (all ports)
Kerberos (88 UDP)
Endpoint resolution —
portmapper (135 TCP) Net
Logon fixed port
Windows NT Server 4.0
directory service fixed port
Top of page
Related Information
The following resources contain additional information that is relevant to this section.

• Windows Support Tools

• Command-Line References in the Tools and Settings Collection for information about DSQuery and Ntdsutil.
Microsoft Platform SDK on MSDN for more information about many WMI classes that are associated with the DNS Server
•
service.
Group Policy Settings Reference in the Tools and Settings Collection for information about Group Policy settings that are
•
associated with the DNS Client service.
• Registry Reference in the Tools and Settings Collection for information about registry entries that are associated with DNS.

Active Directory Schema Technical Reference

Updated: March 28, 2003
The schema is the component of the Active Directory directory service that defines all the objects and attributes that the
directory service uses to store data. You can combine some objects in the schema to create more-complex definitions if
objects of greater complexity are required. You can also add new definitions to the schema to support new types of objects in
the directory.
In this subject

• What Is the Active Directory Schema?

• How the Active Directory Schema Works

Active Directory Schema Tools and
•
Settings
What Is the Active Directory Schema?
Updated: March 28, 2003
What Is the Active Directory Schema?
In this section

• Using Objects to Store Data

• Building the Schema

• Related Information
The schema is the Active Directory component that defines all the objects and attributes that the directory service uses to
store data.
Active Directory stores and retrieves information from a wide variety of applications and services. So that it can store and
replicate data from a potentially infinite variety of sources, Active Directory standardizes how data is stored in the directory.
By standardizing how data is stored, the directory service can retrieve, update, and replicate data while ensuring that the
integrity of the data is maintained.
The directory service uses objects as units of storage. All objects are defined in the schema. Each time that the directory
handles data, the directory queries the schema for an appropriate object definition. Based on the object definition in the
schema, the directory creates the object and stores the data.
Object definitions control the types of data that the objects can store, as well as the syntax of the data. Using this
information, the schema ensures that all objects conform to their standard definitions. As a result, Active Directory can store,
retrieve, and validate the data that it manages, regardless of the application that is the original source of the data. Only data
that has an existing object definition in the schema can be stored in the directory. If a new type of data needs to be stored, a
new object definition for the data must first be created in the schema.
Top of page
Using Objects to Store Data
Active Directory uses objects to store information. Objects are data structures that consist of multiple attributes that store
both data and its related metadata. Metadata is data that describes the properties of other data. For example, an object that
stores a user account has many attributes, including attributes that contain the user’s logon name, first name, last name,
and password. Each of those attributes has additional attributes that contain metadata about the information that the
attribute stores. The logon name attribute, for example, has multiple attributes of its own. One attribute that is associated
with the logon name specifies that the logon name is a required attribute, which means that the user object is not valid
unless it contains the logon name attribute. Another attribute that is associated with the logon name specifies the syntax of
the value that is stored in the logon name attribute. This ensures that the value that the logon name attribute contains is in a
valid format. Both of these attributes contain metadata for the logon name attribute; that is, they define the characteristics
of the logon name attribute.
The object definitions in the schema list all the object attributes and define how these attributes relate to each other. Some
objects are simple and contain only a few attributes, while other objects are quite complex and contain hundreds of
attributes. Attributes themselves are objects, and the schema contains a definition for each one. To define new objects,
smaller objects are associated with one another to define the necessary attributes of the new objects.
For a user object, the user’s logon name attribute is a smaller object that contains a number of attributes of its own. Among
them are attributes that define the syntax of the logon name and specify whether or not the logon name attribute is optional
or required. The first name and last name attributes are also smaller objects whose definitions can be found in the schema.
The object definition that defines the user object lists the logon name attribute object, the first name and last name attribute
objects, and many other attribute objects, and it defines how these objects relate to each other to store the data that
represents a user account.
Defining objects and attributes in this manner gives the schema the ability to efficiently define many different types of
objects while retaining the ability to add new types of objects when necessary. Many objects have some attributes in
common. For example, many objects have a security descriptor to define who is allowed to access and change their contents.
Rather than create a separate security descriptor definition for each object definition, the schema defines a single security
descriptor object, and all other object definitions refer to the single security descriptor definition. This makes it possible for
every object that needs a security descriptor to have one security descriptor while keeping only one definition for the security
descriptor in the schema.
Top of page
Building the Schema
The Active Directory installation process that creates the forest also generates the default schema. Thereafter, the default
schema replicates to each new domain controller during the installation of the directory on that new domain controller. The
default schema contains all the standard object definitions that are necessary for Active Directory to function in a standard
deployment of Windows Server 2003.
Active Directory uses a multimaster replication topology, which means that any domain controller in a forest can write a
change to the directory database and then replicate that change to other domain controllers in the same forest. For a domain
controller to create a new object and write it to the directory, the domain controller must have access to the object definition
that is needed to create the new object. Every domain controller in a forest maintains a copy of the schema, which makes it
possible for domain controllers to have access to the object definitions that they need to store and retrieve information in the
directory.
In some situations, the default attributes and object definitions in the schema are insufficient to create new object types that
are required by some applications or services that interoperate with the directory. In these situations, it is possible to
customize the schema by adding new object definitions to it. The process of adding definitions to the schema is referred to as
“extending the schema.”
It is important to plan the deployment of schema extensions carefully. The directory stores the schema and replicates
schema changes to every domain controller throughout the forest. Therefore, extending the schema creates replication
traffic, which can briefly affect network traffic. For more information about extending the schema, see “How the Active
Directory Schema Works.”

How the Active Directory Schema Works

Updated: March 28, 2003
How the Active Directory Schema Works
In this section

• Active Directory Schema Architecture

• Active Directory Schema Physical Structure

• Active Directory Schema Processes and Interactions

• Related Information
The schema is the Active Directory component that defines all the objects and attributes that the directory service uses to
store data. The physical structure of the schema consists of the object definitions. The schema itself is stored in the
directory.
The schema is stored in its own partition (the schema partition) in the directory. The schema is replicated among all the
domain controllers in the forest, and any change that is made to the schema is replicated to every domain controller in the
forest. Because the schema dictates how information is stored, and because any changes that are made to the schema affect
every domain controller, changes to the schema should be made only when necessary — through a tightly controlled process
— after testing has been performed to ensure that there will be no adverse effects on the rest of the forest.
Top of page
Active Directory Schema Architecture
In Active Directory, the schema defines the following:

• Objects that are used to store data in the directory

• The rules that govern the structure of those objects

• The structure and the content of the directory itself

These definitions consist of objects, attributes, and classes, which are described in the following section.

Schema Components
Objects, attributes, and classes are the basic components that are used to build object definitions in the schema.
Objects
Objects are structures that store both data that the objects represent and data that controls the content and structure of the
objects. For example, a user account object contains a user’s logon name as well as data that indicates the proper syntax for
storing the user’s logon name in the user object.
Active Directory uses objects to store data while the data is maintained in the directory. When the directory stores an object,
some associated data is also stored along with the object. The extra data is stored in the attributes of the object.

Attributes
Attributes contain data that defines the information that is stored in an object or in another attribute. For example, a user
account object has attributes that store user information, such as the user’s first name, last name, password, office number,
and telephone number. Different types of objects have different attributes. A printer object has attributes that store
information that is related to printers, such as the printer model, the number of paper trays, the current location of the
printer, and the port to which the printer is attached.
Some attributes contain information that relates to other attributes, such as syntax information or flags that label the
attribute as optional or required. Syntax attributes define the format that is used to store data in other attributes. For
example, because a telephone number comprises only digits, a syntax attribute might specify that the phone number
attribute can only store digits 0 through 9, and letters of the alphabet are prohibited. Active Directory uses syntax attributes
to ensure that information is stored in a legitimate format and that the information is a valid data type.
Attributes can be required or optional. A user account object requires a user name attribute and a password attribute,
although the office number attribute is optional. That is, a user account cannot be used without a user name; however, it can
be used without an office number. The office number attribute is included for convenience, and it is considered an optional
attribute.
An object definition is really an association of various attributes that are used to describe the characteristics of an object that
stores specific pieces of data. The kind of data that the object stores determines which attributes are needed to define the
object.
Large objects are made up of many smaller objects. In the user account object example, the user’s logon name attribute is a
smaller object that contains a number of attributes of its own, including attributes that define the syntax of the logon name
and that specify whether or not the logon name attribute is optional or required. The first name and last name attributes are
also smaller objects that are defined in the schema. The object definition for the user account object lists the logon name
attribute and the first name and last name attributes, as well as many other attributes, and it defines how these attributes
relate to each other to store the data that represents a user account.
Defining objects and attributes this way gives the schema the ability to efficiently define many different types of objects.
Many objects have some attributes in common. For example, many objects have a security descriptor to define who is
allowed to access and make changes to the contents of the object. Rather than create a separate security descriptor
definition for each object definition, the schema defines a single security descriptor object, and all other object definitions
refer to the single security descriptor definition. This makes it possible for every object that needs a security descriptor to
have one, while keeping only one definition for the security descriptor in the schema.

Classes
Object definitions are categorized into groups that are called classes. Classes act as blueprints that can be used each time a
new object is created. When a new object is created in the directory, the object’s class determines the attributes that are
associated with the new object, including which attributes are required and which attributes are optional.
Active Directory has predefined classes that define all of the different object type’s that the directory needs to function
properly. For example, when a new user account object is created in the directory, its definition comes from the classUser
class. The class dictates that the new account object is required to have a user name attribute and a password attribute, and
optionally it might have an office number attribute.
Object definitions are created by nesting classes inside one another. Nesting classes produces a parent/child relationship
between the classes. Classes that are nested inside another class are referred to as subclasses. The parent of a subclass is
referred to as a superclass. When one class is nested inside another, the nested class inherits the properties of the parent
superclass. When various classes that contain particular attributes are nested inside another object class, a new object
definition is created. Which classes are nested depends on which attributes are needed to define the new object type.
The schema stores class information, but it does not store the actual objects that are derived from a class. For example,
when a new user account object is created, it is not stored in the schema. Active Directory looks up the user class in the
schema. Active Directory then retrieves information regarding the object type and its associated attributes from the user
class in the schema and uses that information to create the new user account object. When the new account is created, the
data is stored in the new object, and Active Directory then writes the new account information into the directory database.
The schema is the master list of all classes and attributes that can be used in the directory. During the installation of Active
Directory, the Schema.ini file is used to build the default schema on the first domain controller in the forest. The default
schema provides all the necessary classes that Active Directory needs to function. Administrators or developers might want
to add their own classes or add their own attributes to an existing object type. They can do this through the process of
extending the schema. The schema should only be extended in special situations. For more information on extending the
schema, see “Modifying the Schema” later in this section.

Schema Objects
Active Directory uses objects to store and reference data in the directory. The schema defines the types of objects that are
available to the directory service. The schema is stored in the schema partition, which is also defined as an object in the
directory. The attributes and classes in Active Directory are stored in the schema partition as directory objects that are called
schema objects. The schema partition itself is represented in Active Directory by an object that is an instance of the Directory
Management Domain (dMD) class.
Storing the schema in the directory has many advantages. For example, when user applications locate the schema in the
directory, they can read the schema to discover what types of objects and properties are available. Because the schema is
stored in the directory — like the rest of the data in the directory — applications can locate the schema by using the same
process that they use to locate any other object in the schema.
A schema object, called a classSchema object, defines each class in the schema. Another schema object, called an
attributeSchema object, defines each attribute in the schema. Therefore, every class is actually an instance of the
classSchema class, and every attribute is an instance of the attributeSchema class, as shown in the following figure.
Schema Objects

Schema objects are used to define classes and attributes in the schema. Classes in the schema are used to define objects in
the directory.

attributeSchema Objects
Attributes describe the classes that are defined in the schema. Attributes are defined in the schema separately from classes,
which enables a single attribute definition to be applied to many classes.
Attributes are attributeSchema objects. Each attributeSchema object is an instance of the attributeSchema class. Like any
other object, the attributeSchema object has its own attributes. The attributes for the attributeSchema object store, among
other things, the following information:

• The Lightweight Directory Access Protocol (LDAP) display name of the attribute

• The object identifier for the attribute

• The globally unique identifier (GUID) for the attribute

• The syntax of the attribute
The range for the attribute. For integers, range defines the minimum and maximum value; for strings, range defines the
•
minimum and maximum length.
Whether the attribute is a multivalue attribute. Note that multivalue attributes hold a set of values with no particular
•
order. Multivalue attributes might not be returned in the order in which they were stored (or in any other order).
• Whether and how the attribute is indexed

Attributes for the attributeSchema class

Attributes for the attributeSchema class are described in the following table.
Attributes for the attributeSchema Class

Attribute Syntax Mandatory? Multivalue? Description

cn Unicode Yes No Descriptive relative distinguished name for the schema

object

attributeID Object Yes No Object identifier that uniquely identifies this attribute
identifier

lDAPDisplayName Unicode Yes, but No Name by which LDAP clients identify this attribute
automatic

schemaIDGUID String(Octet) Yes No GUID that uniquely identifies this attribute

mAPIID Integer No No Integer by which Messaging API (MAPI) clients identify

this attribute

attributeSecurityGUID GUID No No GUID by which the security system identifies the

property set of this attribute

attributeSyntax Object Yes No Syntax object identifier of this attribute

identifier

oMSyntax Integer Yes No Syntax of this attribute as defined by the XAPIA

X/Open Object Model (XOM) specification

isSingleValue BOOL Yes No Indicates whether this attribute is a single-value or

multivalue attribute
Note that multivalue attributes hold a set of values
with no particular order. Multivalue attributes might
not be returned in the order in which they were stored
(or in any other order).

extendedCharsAllowed BOOL No No Indicates whether extended characters are allowed in

the value of this attribute
Applies only to attributes of syntax String(teletex).

rangeLower Integer No No Lower range of values that are allowed for this
attribute

rangeUpper Integer No No Upper range of values that are allowed for this
attribute

systemFlags Integer No No Flags that determine specific system operations

Note: This attribute cannot be set or modified.
The following systemFlags attributes are relevant to
the schema objects:
Attribute is required to be a member of the partial
set = 0x00000002
Attribute is not replicated = 0x00000001
Attribute is a constructed attribute = 0x00000004
Attribute Syntax Mandatory? Multivalue? Description

searchFlags Integer No No The searchFlags property of each property’s

attributeSchema object defines whether a property is
indexed and other behavior.
The seven currently defined bits for this attribute are:
1 = Index over attribute only
2 = Index over container and attribute
4 = Add this attribute to the ambiguous name
resolution (ANR) set (should be used in conjunction
with 1)
8 = Preserve this attribute on logical deletion (that is,
make this attribute available on tombstones)
16 = Include this attribute when copying a user object
32 = Create a Tuple index for the attribute to improve
medial searches
64 = Reserved for future use; value should be 0.
128 = Available in Windows Server 2003 Service
Pack 1 (SP1) only. Mark the attribute confidential
(CONTROL_ACCESS is required to read it).

isMemberof BOOL No No A Boolean value that defines whether the attribute is

PartialAttributeSet replicated to the global catalog
A value of TRUE means that the attribute is replicated
to the global catalog. In environments where domain
controllers are running Windows 2000 Server,
changing this value might cause full synchronization of
the Partial Attribute Set. For more information about
the conditions under which full synchronization occurs,
see How the Global Catalog Works on the Microsoft
Web site at http://go.microsoft.com/fwlink/?
LinkId=47817.

systemOnly BOOL No No Attributes on which Windows Server 2003 and

Active Directory depend for normal operations
If TRUE, only the system can modify this attribute. No
user-defined attribute must ever have the
systemOnly flag set.

objectClass Object Yes Yes Class of this object, which is always attributeSchema
identifier

nTSecurityDescriptor NT-Sec-Des Yes No Security descriptor on the attributeSchema object

itself

oMObjectClass String(Octet) No No For object-syntaxed attributes (OM-syntax = 127), the

Basic Encoding Rules (BER) encoded object identifier
of the XOM object class
For more information about BER encoding, see
Request for Comments (RFC) 2251 in the IETF RFC
Database.

LinkID Integer No No Whether it is for a linked attribute or not, an even

integer denotes a forward link; an odd integer denotes
a back link.
Attribute Syntax Mandatory? Multivalue? Description

A forward link points to another object in the

directory; a back link points back to the first object
that has a forward link to it.

Single-value and multivalue attributes

Some attributes contain a single value, and other attributes can contain multiple values. For example, the password
attribute on a user object contains a single value: the password that is associated with the user account. The memberOf
attribute contains multiple values: a list of the various groups of which the user account is a member. Each item in the list is
stored as a separate value in the memberOf attribute. Attributes that can store more than a single value are referred to as
“multivalue” attributes.
Whether or not attributes are single-value or multivalue is defined by the singleValue attribute as a Boolean value. The
Active Directory Schema snap-in reports this attribute as “single-value” or multivalue rather than as the attribute-value pair.
(Active Directory Schema is a Microsoft Management Console (MMC) graphical interface tool in Windows Server 2003 that
administrators can use to manage the schema.)
All values that are defined for a multivalue attribute must have a uniform syntax. Multivalue attributes that are not linked
can store a maximum of 1,300 entries. This limit is based on the size and type of the values that are stored.
Note
When it retrieves data, LDAP reads a multivalue attribute as a single entity. This can be inconvenient or even impossible
•
when the number of values in a multivalue attribute becomes large. A property called Range can be specified as part of
an attribute description to retrieve the values of a multivalue attribute incrementally. Servers might or might not honor
the Range property. Servers that support the Range property include the object identifier 1.2.840.113556.1.4.802 in the
supportedControls operational attribute on the rootDSE. Clients must not use the Range property unless this object
identifier is present. The Range property is a constant, case-insensitive string value (Range=), followed by a range
specifier that lists the initial value and terminal value in the range.

Linked attributes
Linked attributes make it possible to associate one attribute with another attribute. A linked attribute consists of a pair of
attributes for which the system calculates the values of one attribute based on the values that are set on the other attribute.
One attribute of the pair is referred to as the back link, and the other attribute is referred to as the forward link. The back
link is a multivalue attribute that contains the distinguished names of all the other objects that have an attribute linked to it.
The forward link is a single-value attribute that contains the distinguished name of the object to which it is linked.
For example, you can create an object to store information in the directory that is related to a specific project. Among other
things, the project object stores the names of the project team members. To store the names of the team members, you can
use the linked attributes ProjectName and TeamMembers. ProjectName is the forward link, and it is an attribute of the
team member’s user account object that stores the name of the project that the user works on. TeamMembers is the back
link, and it is an attribute of the project object that stores the list of team members who work on the project. Assume that
Mike and Amanda are members of the project team. If you store the distinguished name of the project object in the
ProjectName attribute of Mike’s user object and Amanda’s user object, the distinguished names of Mike’s user object and
Amanda’s user object appear in the TeamMembers attribute of the project’s object.
A linked pair is identified by the linkID values of two attributeSchema objects. The linkID of the forward link is an even,
positive, nonzero value, and the linkID of the associated back link is the value of the forward linkID, incremented by one.
For example, if the linkID for ProjectTeam is 37, the linkID for TeamMembers is 38.

Automated links
The linkIDs must be unique within the forest. In Windows 2000 Server, linkIDs are allocated by the applications that used
them, and it is up to application developers to make sure that the linkIDs for the applications do not conflict with linkIDs
that are already in use. Windows Server 2003 can generate link values automatically to ensure that there are no conflicts
within the forest. When new objects that use linked attributes are created, Active Directory automatically generates the
necessary linkIDs.
Indexed attributes
Directory searches for attributes that are indexed are more efficient than searches for attributes that are not indexed.
Attributes are indexed when the least significant bit in their searchFlags attribute is set to the value 1. Changing the value
of the bit to 1 dynamically builds an index; changing the value to 0 or deleting it removes an index for the attribute in
question. The index is built automatically by a background thread on the directory server.
The values for indexed attributes are stored in a sorted list. This makes searching much more efficient because the system
needs to search only until it locates the area in the list where the value should be, based on the sort. If the value is not
there, the system can assume it will not find the value anywhere else in the list, and it can terminate the search. When
attributes are not indexed, the entire list must be searched to determine whether or not a particular value actually exists.
Indexing requires more storage to maintain the lists, but it makes searching more efficient. Nonindexed attributes are less
efficient to search, but they require less storage to maintain. With this in mind, only attributes that are frequently referenced
should be indexed. Ideally, indexed attributes are single-value attributes with unique values that are evenly distributed
across the set of instances. Multivalue attributes can be indexed, but building the index requires more storage and updating.

Confidential attributes
On domain controllers running Windows Server 2003 with SP1, attributes whose attributeSchema objects are marked with
a specific search flag are interpreted as confidential. Attributes that are so marked can be read only by users to whom the
following access is granted:

• READ_PROPERTY

• CONTROL_ACCESS
The ability to mark attributes as confidential allows administrators to protect attributes from the read access that is granted
by default to most users. Rather than changing the defaults that are expected by existing applications, administrators can
create new attributes that can be read only by administrators or those to whom access is specifically granted. Because
domain controllers must be running Windows Server 2003 with SP1 to recognize the flag that marks the attribute as
confidential, protection of marked attributes is fully effective only in environments where all domain controllers have been
upgraded to Windows Server 2003 with SP1. In particular, the schema operations master (also known as the schema flexible
single-master operations (FSMO) role holder) must be upgraded to Windows Server 2003 with SP1.
By default, Active Directory performs a read-access check on an object in the following cases:

• When evaluating whether the object matches the search filter

When returning attributes of an object that matches the search
•
filter
Default security in Windows 2000 Server and Windows Server 2003 allows read access to the Pre-Windows 2000 Compatible
Access group, which usually contains Authenticated Users. Authenticated Users is a security group that includes users whose
identities can be authenticated by the server or by a trusted security authority. Because the Pre-Windows 2000 Compatible
Access group is granted Read_Property permissions on user objects (including inetOrgPerson) and group objects, it is
difficult to introduce a new attribute on these objects that is protected from reading by most users. For example, you might
want to add a social security number attribute to the user class.
To solve this problem, Windows Server 2003 SP1 provides a way to mark an attribute as confidential by setting a
searchFlags value on the attributeSchema object in the schema. The search flag contains multiple bits representing various
properties of an attribute. In Windows 2000 Server and Windows Server 2003 schemas, the searchFlags attribute has six
bits that can be set. (See the bits that are defined for the searchFlags attribute in "Attributes for the attributeSchema class"
earlier in this section.) For example, a value of 1 in the least significant bit means that the attribute is indexed. The binary
form of this flag value is 00000001. A new bit is added in Windows Server 2003 with SP1: A value in bit 128 (10000000)
designates the attribute as confidential. Therefore, on a domain controller running Windows Server 2003 with SP1, you can
designate an attribute as confidential by setting bit 128 in the searchFlags attribute of the respective attributeSchema
object.
Note
You cannot set this flag on base-schema attributes, such as common-name.
When an attribute is so designated, in addition to READ_PROPERTY permission (for that attribute or all attributes on that
object), CONTROL_ACCESS permission (for that attribute or a property set that contains that attribute) is required to read
the attribute.
Note
When you assign CONTROL_ACCESS permissions to a user or group, you must specify a GUID — in this case, the GUID of
the attribute or property set that contains the attribute.
To set the bit flag when no values are set, you can simply add the value 128 to the searchFlags attribute in the properties
of the attributeSchema object for the confidential attribute. If a value is already present in the attribute, perform a bitwise
OR operation to add 10000000 to the existing binary value, and then convert to decimal. For example, if the bit is set for
indexing and containerized search (00001001), the combined values 10000000 OR 00001001 equal 10001001, translating to
a decimal value of 137.
By default, only members of the Administrators built-in group are granted CONTROL_ACCESS to all objects. Therefore, only
administrators can read confidential attributes. You can delegate the CONTROL_ACCESS right to any specific group by using
the Dsacls command-line tool or by scripting. Dsacls is included in Windows Support Tools. To grant access to a confidential
attribute, use Dsacls to grant the CONTROL_ACCESS right (CA) to the required group or user. Doing so introduces a way to
impose additional security checks that control read access to selected attributes. For more information about Dsacls, see
Dsacls.exe in the Active Directory Management Support Tools section of Windows Support Tools on the Microsoft Web site at
http://go.microsoft.com/fwlink/?LinkId=43235. For more information about property sets and CONTROL_ACCESS
permissions, see the Security Descriptors and Access Control Lists Technical Reference.

Syntaxes
The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property
types. The syntax defines whether the attribute value must be a string, a number, or a unit of time. Each attribute of every
object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are
programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined. You cannot
add new syntaxes.
When you define a new attribute, you must specify both the attributeSyntax and the oMSyntax numbers of the syntax
that you want for that attribute. The attributeSyntax number is an object identifier, and the oMSyntax number is an
integer. oMSyntax is defined by the XOM specification. Using this model, the syntax can provide detailed syntax definitions.
For example, distinct oMSyntax attributes distinguish several types of printable strings, according to such factors as the
supported character set and whether case is significant. The following table lists the valid syntaxes for attributes in the
Active Directory schema.
Valid Syntaxes for Attributes in the Active Directory Schema

Syntax attributeSyntax oMSyntax ASN 1-Encoded Description

Object Identifier

Undefined 2.5.5.0 \x550500 Not a legal syntax

Object(DN-DN) 2.5.5.1 127 \x550501 The fully qualified name of an

object in the directory

String(Object-Identifier) 2.5.5.2 6 \x550502 The object identifier

Case-Sensitive String 2.5.5.3 27 \x550503 General string — differentiates

uppercase and lowercase

CaseIgnoreString(Teletex) 2.5.5.4 20 \x550504 Teletex — does not differentiate

uppercase and lowercase

String(Printable), String(IA5) 2.5.5.5 19, 22 \x550505 Printable string or IA5-String

Both character sets are case
sensitive.

String(Numeric) 2.5.5.6 18 \x550506 A sequence of digits

Object(DN-Binary) 2.5.5.7 127 \x550507 A distinguished name plus a binary

large object

Boolean 2.5.5.8 1 \x550508 TRUE or FALSE values

Integer, Enumeration 2.5.5.9 2, 10 \x550509 A 32-bit number or enumeration

Syntax attributeSyntax oMSyntax ASN 1-Encoded Description
Object Identifier

String(Octet) 2.5.5.10 4 \x55050A A string of bytes

String(UTC-Time), 2.5.5.11 23, 24 \x55050B UTC time or generalized-time

String(Generalized-Time)

String(Unicode) 2.5.5.12 64 \x55050C Unicode string

Object(Presentation-Address) 2.5.5.13 127 \x55050D Presentation address

Object(DN-String) 2.5.5.14 127 \x55050E A DN-String plus a Unicode string

String(NT-Sec-Desc) 2.5.5.15 66 \x55050F A Windows NT security descriptor

LargeInteger 2.5.5.16 65 \x550510 A 64-bit number

String(Sid) 2.5.5.17 4 \x550511 Security identifier (SID)

Object identifiers
Object identifiers are unique numeric values that are granted by various issuing authorities to identify data elements,
syntaxes, and other parts of distributed applications. Because they are globally unique, object identifiers ensure that the
objects that are defined by these issuing authorities do not conflict with one another when different directories, such as
Active Directory and Novell Directory Services, are used concurrently within a global directory namespace.
Object identifiers are found in Open Systems Interconnection (OSI) applications, X.500 directories, applications that use
Simple Network Management Protocol (SNMP), and other applications in which uniqueness is important. Object identifiers are
based on a tree structure in which a superior issuing authority allocates a branch of the tree to a subordinate authority,
which in turn allocates subbranches of the tree.
LDAP requires a directory service, such as Active Directory, to identify object classes and attributes with an object identifier
syntax. The object identifier is the value for the governsID attribute in a classSchema object and for the attributeID
attribute in an attributeSchema object. These are required attributes; therefore, object identifiers are necessary when you
create new classes or attributes.
Object identifiers in the Active Directory base schema include some object identifiers that are issued by the International
Organization for Standardization (ISO) for X.500 classes and attributes and some object identifiers that are issued by
Microsoft. Object identifier notation is a dotted string of nonnegative numbers, for example, 1.2.840.113556.1.5.4. The
components of this object identifier are shown in the following table.
Components of an Object Identifier (1.2.840.113556.1.5.4)

Numerical Values of the Object Identifier What the Numerical Values Mean

1 ISO (“root” authority) issued 1.2 to ANSI.

2 ANSI issued 1.2.840 to the USA.

840 USA issued 1.2.840.113556 to Microsoft.

113556 Microsoft internally manages several object identifier branches under

1.2.840.113556 that include the following three identifiers.

1 A branch called Active Directory that includes the following two identifiers.

5 A branch called Classes that includes the following identifier.

4 A class called Builtin-Domain.

Object identifiers ensure that every object is interpreted appropriately, for example, that a telephone number is not mistaken
for an employee number. A series of widely used objects and attributes is standardized for use in object identifiers. New
object identifiers are issued by standards authorities, and they form a hierarchy below which new object identifiers can be
managed internally.
Most countries and regions in the world have an identified National Registration Authority (NRA) that is responsible for
issuing object identifiers to enterprises. In the United States, the NRA is the American National Standards Institute (ANSI).
The NRA issues root object identifiers. An enterprise can register a name for the object identifier as well. A fee is associated
with registering root object identifiers and registered names. Contact the NRA for your country or region for details. The ISO
recognizes NRAs and maintains a list of contacts on its Web site.
The issuing authority assigns an object identifier space that is a branch of the ISO-International Telecommunication Union
(ITU) object identifier tree. For example, your organization might be assigned the space 1.2.840.111111. You can extend
this space internally within the constraints of the structure of an object identifier. You can subdivide this space further (by
appending dotted decimals to the object identifier root) and assign these subspaces to various divisions within your
organization. Each division, in turn, can further subdivide the subspace that is allotted to it.
For the example object identifier 1.2.840.111111, your organization might use the subspace 1.2.840.111111.1.4 for
attributes and the subspace 1.2.840.111111.1.5 for classes. An internal issuing authority in your organization, using an
Administrator account, might then allocate object identifiers from this space when requested. The governsID attribute on
every classSchema object and the attributeID attribute on every attributeSchema object are mandatory attributes that
contain an object identifier string. In this example, all of your organization-created classSchema objects have a governsID
attribute of the form 1.2.840.111111.1.5.x, where x is a decimal number. Similarly, all of your organization-created
attributeSchema objects have an attributeID attribute of the form 1.2.840.111111.1.4.x.
Microsoft also offers a free object identifier registration service.

classSchema Objects
The classSchema object specifies the various attributes of the class with which it is associated. Among other things, it defines
the following constraints for objects that are instances of the class:
mustContainattributes, which include mandatory attributes that must be present on any object that is an instance of this
•
class
• mayContain attributes, which include optional attributes that may be found on an object that is an instance of this class

• Hierarchy rules that determine the possible parents in the directory tree of an object that is an instance of the class
An object can have attributes that belong only to either the mustContain list or the mayContain list for the class.
The classSchema object is essentially a template that contains the rules for creating objects in an Active Directory class.
When a new object is created in a class, the classSchema object ensures that this new object has the same attributes as all
other objects in the class.
The classSchema object contains, among other things, the following information:

• The LDAP display name of the class

• The object identifier for the class

• The GUID for the class

• The attributes that must be present for an instance of the class

• Other attributes that can be present for an instance of the class

• The classes to which the parent of instances of this class may belong

• The superclass from which this class inherits characteristics

• Other Auxiliaryauxiliary classes from which this class inherits attributes

• The type of class (Abstractabstract, Structuralstructural, or Auxiliaryauxiliary)

The default hiding state for the class. If you do not want instances of the class to be displayed by the end-user user
•
interface (UI), you can define the class as hidden by default.

Attributes for classSchemaobjects

The following table lists the attributes that a classSchema object can have.
Attributes for a classSchema Object

Attribute Syntax Mandatory? Multivalue? Description

cn Unicode Yes No Descriptive relative distinguished name for the

schema object

governsID Object identifier Yes No The object identifier that uniquely identifies this
Attribute Syntax Mandatory? Multivalue? Description

class

lDAPDisplayName Unicode Yes No The name by which LDAP clients identify this class

schemaIDGUID String(Octet) Yes, but No The GUID that uniquely identifies this class
defaulted

rDNAttID Object identifier No No The relative distinguished name type of instances

of this class (OU, CN)

subClassOf Object identifier Yes No The class from which this object inherits attributes

systemMustContain Object identifier No Yes The list of mandatory attributes for instances of
this class
This list cannot be changed.

mustContain2 Object identifier No Yes The mandatory attributes for instances of this
class

systemMayContain Object identifier No Yes The optional attributes for instances of this class

mayContain2 Object identifier No Yes The optional attributes for instances of this class

systemPossSuperiors2 Object identifier No Yes The classes that can be parents of this class in the
directory hierarchy
After the class is created, this property cannot be
changed.

possSuperiors2 Object identifier No Yes The classes that can be parents of this class in the
directory hierarchy
For an existing classSchema object, values can be
added to this property but not removed.

systemAuxiliaryClass2 Object identifier No Yes The Auxiliaryauxiliary classes from which this
class inherits its optional (mayContain) and
mandatory (mustContain) attributes
After creation of the class, this property cannot be
changed.

auxiliaryClass2 Object identifier No Yes The Auxiliaryauxiliary classes from which this
class inherits its optional (mayContain) and
mandatory (mustContain) attributes
This is a multivalue property that specifies the
auxiliary classes that this class inherits from. For
an existing classSchema object, values can be
added to this property but not removed.

defaultHidingValue BOOL No No The default hiding state for the class

If you do not want instances of the class displayed
in the UI for Active Directory admin tools New
menus, you can define the class as hidden.

defaultSecurityDescriptor String(Octet) No No The default security descriptor that is assigned to

new instances of this class if no security
descriptor is specified during creation of the class
or that is merged into a security descriptor if a
security descriptor is specified

objectClassCategory Integer Yes No Class types are defined as follows:

88 Class = 0
Attribute Syntax Mandatory? Multivalue? Description

Structural = 1
Abstract = 2
Auxiliary = 3
The 88 class type is included for compatibility with
older directories. Active Directory does not use
88 class type objects, and they should not be
used in defining new classes for Active Directory.

systemOnly BOOL No No An attribute of a classSchema object

If it is set to TRUE, only the system can create
and modify instances of this class. If it is set to
FALSE, modifications can also be made by users
who have appropriate permissions.

objectClass Object Yes Yes This object’s class, which is always classSchema
Identifier

nTSecurityDescriptor NT-Sec-Desc Yes No The security descriptor on the classSchema object

defaultObjectCategory Distinguished Yes No The default object category of new instances of

name this class
If none has been specified, the objectClass value
is used.
The attributes in a classSchema object’s mustContain attribute list are not the complete set of attributes that must be
present for an instance of a class to exist. For example, in a class A, the classSchema object B specifies a list of
mustContain attributes that an instance of A must have through the systemMustContain and mustContain attributes.
However, because mandatory attributes are also inherited, the complete list of attributes for an instance of class A includes
the inherited mustContain attributes from all classes from which B inherits, that is, all classes in the subClassOf and
auxiliaryClass lists for the classSchema object B. The mayContain attributes for object B are also defined this way. The
possSuperiors attributes are defined this way as well, except that possSuperiors attributes are inherited only from classes
in the subClassOf list, not from the classes in the auxiliaryClass list.

Mandatory attributes
Mandatory attributes are object attributes for which you must specify values. If you do not specify a value for a mandatory
attribute, the attribute receives a default value or the object is not created until you specify a value for the attribute. The
object’s mandatory attributes are determined by the class to which the object belongs.
Some mandatory attributes are inherited. Because every classSchemaobject belongs to a superclass called Top in the class
hierarchy, each classSchema object inherits the mandatory attributes that belong to Top. The following table lists the
mandatory attributes that every object inherits from Top. To see a graphical representation of the Active Directory class
hierarchy, see the figure under “Object class hierarchy” later in this section.
Mandatory Attributes That All classSchemaObjects Inherit

Inherited Mandatory Default Status

Attribute

nTSecurityDescriptor Set to a default value if not specified. The default value depends on the default security
descriptor for the classSchema object.

objectCategory Automatically set to the value of the default object category of the class, which is usually the
class itself. Can be changed after the class is created.

objectClass No default. An administrator must specify the class.

You can view an object’s mandatory attributes by using the Active Directory Schema snap-in. The attributes are displayed on
the Attributes tab in the properties dialog box for the object. Because some of an object’s mandatory attributes are
inherited from its parent class, you might need to view the attributes of the parent class to identify all the mandatory
attributes of the object.

System and changeable attribute pairs

Some properties of a class-definition object are contained in pairs of attributes, in which the value of one of these attributes
can be changed by administrators and the value of the other attribute cannot be changed. These attribute pairs are as
follows:

• mustContain/systemMustContain

• mayContain/systemMayContain

• possSuperiors/systemPossSuperiors

• auxiliaryClass/systemAuxiliaryClass
In each of these pairs, the value of the attribute that begins with the word “system” cannot be changed by administrators.
This enables Active Directory to protect certain key attributes of certain classes and to ensure that the schema stays
consistent and usable. System-only properties can be changed only by the Directory System Agent (DSA). System-only
properties are those properties on which Windows Server 2003 and Active Directory depend for normal operations. For
example, the attributeID attribute and the governsID attribute in the schema are system-only attributes. The values of
the other (nonsystem) attributes in each pair can be changed by administrators.

Categories of Object Classes

Different categories of object classes make it possible to define structure in the directory. The 1993 X.500 specification
requires that object classes be assigned to one of three categories:

• Structural

• Abstract

• Auxiliary
A fourth category, which is referred to as 88 classes, is associated with object classes, although this category is not part of
the 1993 specification. The 88 class category is in the specification that existed before 1993, and it should not be used for
adding classes to Active Directory.

Structural classes
Structural classes are the only classes that can have instances in the directory. That is, you can create directory objects
whose class is one of the structural classes. A structural class:

• Can be used in defining the structure of the directory.

• Is derived from either an abstract class or another structural class.

• Can include any number of auxiliary classes in its definition.

This type of class is specified by a value of 1 in the objectClassCategory attribute.

Abstract classes
Abstract classes are templates that are used to derive new structural classes. Abstract classes cannot be instantiated in the
directory. This means that no object can belong only to an abstract class; each object of an abstract class also belongs to
some structural subclass of that class. A new abstract class can be derived from an existing abstract class. This type of class
is specified by a value of 2 in the objectClassCategoryattribute. Abstract classes only provide attributes for subordinate
classes, which are called subclasses. A subclass contains all mandatory and optional attributes of the class from which it is
derived (its superclass) in addition to those attributes that are specific to the class itself. Likewise, the subclass of that class
contains all attributes of both superclasses, and so forth.

Auxiliary classes
Auxiliary classes are like include files; they contain a list of attributes. Adding an auxiliary class to the definition of a
structural class or an abstract class’ adds the auxiliary classs attributes to the definition. An auxiliary class cannot be
instantiated in the directory, but new auxiliary classes can be derived from existing auxiliary classes. This type of class is
specified by a value of 3 in the objectClassCategory attribute. For example, the securityPrincipal class is an auxiliary
class, and it derives its attributes from the parent abstract class called Top. Although you cannot create a security principal
object in the directory (because auxiliary classes cannot have instances), you can create an object of the structural class
user, which has the securityPrincipal class as an auxiliary class. The attributes of the securityPrincipal class help the
system recognize the user object as a security account. Similarly, the group class has securityPrincipal as an auxiliary
class.
The behavior of auxiliary classes has changed in Windows Server 2003. In Windows 2000 Server, changes that are made to
an auxiliary class affect its parent class as well as all instances of the parent object. For example, adding an auxiliary class
called pager to the structural class user affects all instances of user, which is all of the user accounts that are created with
the user class.
In Windows Server 2003, auxiliary classes can be assigned dynamically to individual instances of classes, rather than being
applied automatically to all instances. For example, you can assign the pager auxiliary class to only those users who need it.

88 classes
Classes that were defined before 1993 are not required to fall into one of the preceding categories; assigning classes to
categories was not required in the X.500 1988 specification. Classes that were defined before the X.500 1993 standards are
assigned to the 88 class. This type of class is specified by a value of 0 in the objectClassCategory attribute. Do not use
88 classes or define new 88 classes.

Object class hierarchy

Inheritance, which is also referred to as derivation, is the ability to build new object classes from existing object classes. A
new object is defined as a subclass of its parent object. A subclass is a class that inherits from some other class; for
example, a subclass inherits structure and content rules from the parent class. The parent object becomes a superclass of
the new object. A superclass is a class from which one or more other classes inherit information. The inherited information
includes mandatory and optional attributes (systemMustContain, mustContain, systemMayContain, and mayContain)
and the parent classes in the directory hierarchy (systemPossSuperiors and possSuperiors). This relationship between
the superclasses and their subclasses represents the object class hierarchy, which is illustrated in the following figure.
Object Class Hierarchy

All structural object classes are subclasses, directly or indirectly, of a single abstract object class, which is called Top. Every
object that is represented in the directory belongs to Top, and as a result every entry must have an objectClass attribute.
When you create a new class, you must specify the superclass. If you do not create a subclass of an existing class, the new
class is a subclass of Top.
A new class can inherit mandatory and optional attributes from more than one existing class. However, any additional classes
must be specified by the auxiliaryClass attribute.
Note
 If you later add another attribute to a class that has subclasses or auxiliary subclasses, the new attribute is automatically
•
added to the subclasses after the schema cache has been updated.

Structure and Content Rules

The schema enforces rules that govern both the structure and the content of Active Directory. These rules validate changes
to objects to ensure the integrity of the directory.

Structure rules
Structure rules define the possible tree structures. When you create a new object, structure rules determine the validity of
the object class to which you designate the new object. You cannot create an object that belongs to a nonexistent class. You
must first create the new class.
Conversely, these rules do not allow you to delete or modify an object that has already been deleted. In Active Directory, the
structure rules are completely expressed by the possSuperiors and systemPossSuperiors attributes that are present on
each classSchema object. These attributes specify the possible classes that can be parents of an object instance of the class.
In other words, the possSuperiors and systemPossSuperiors attribute values determine the object classes and,
therefore, the location in the directory tree under which objects of the class can be instantiated.

Content rules
Content rules determine the mandatory and optional attributes of the class instances that are stored in the directory. New
objects must contain all the mandatory attributes that are specified by the classSchema object in the schema. New objects
can contain any of the optional attributes. In Active Directory, the content rules are completely expressed by the mustHave,
mayHave,mayContain, systemMustContain, and systemMayContain attributes of the schema definitions for each class.
In addition, there are some operational attributes that are read-only. These are identified by the first bit of the systemFlags
property for an attribute definition that is set to 1, for example, lastLogon.
For more information about mandatory and optional attributes, see Active Directory Schema in the Microsoft Platform SDK on
MSDN.
Top of page
Active Directory Schema Physical Structure
The schema exists as a set of directory objects, and it is stored in the directory. Active Directory partitions the information in
the directory to facilitate more efficient replication. The schema is stored in its own directory partition so that it can replicate
independently of other data that is stored in the directory.

Schema Location
The objects that are stored in Active Directory are arranged in a logical hierarchy called the directory tree. The directory tree
is divided into directory partitions. A directory partition is a tree of objects that forms a unit of replication in Active Directory.
The schema has its own directory partition to prevent potential dependency problems that can arise when new schema
classes and new instances of the class are replicated simultaneously. Because the schema has its own tree, it is possible to
replicate new schema changes to other domain controllers before replicating any new objects that may have been created
based on those changes. This is important because the other domain controllers must have access to the object definitions
that are stored in the schema before those domain controllers can properly store any new objects that are created by using
those definitions.
Active Directory includes a preconfigured database, commonly referred to as the base directory information tree (DIT), which
contains the information that is required to install and run Active Directory. The base DIT is created during a fresh
installation of a Windows Server 2003 domain controller. The base DIT is contained in a file named Ntds.dit. One section of
the base DIT is the base schema.

Schema Head
The schema head is the topmost object of the schema directory partition. Conceptually, the schema head functions like other
containers in the directory tree, which means that it contains all of the schema information. However, the schema head is not
a container in the sense of a special Active Directory object that contains other objects; rather, it is a special-purpose object
class. Therefore, it is referred to as the schema head rather than the Schema container. The schema head contains all of the
class definitions and attribute definitions that are required to locate objects in Active Directory and create new objects.
The relationships of the schema head, Configuration container, and Domain container are illustrated in the following figure.
Schema Head

Every Active Directory object can be referenced by a unique and unambiguous name known as the distinguished name. The
distinguished name identifies the domain that holds the object as well as the complete path through the container hierarchy
by which the object is reached. The distinguished name of the schema head can be expressed as follows:
cn=schema,cn=configuration,dc=forest rootdomainname
You can view the contents of the schema head by using the Active Directory Schema snap-in. You can also bind to the
schema directory partition and view schema objects by using the Active Directory Service Interfaces (ADSI) Edit snap-in or
the Ldp tool.
Note
ADSI Edit is not one of the default MMC snap-ins that are provided with Windows Server 2003. To use ADSI Edit and Ldp,
•
install the support tools that are located in the Support\Tools folder on the Windows Server 2003 operating system CD.
You can locate the schema head without knowing the domain name. Installation scripts and other applications can gain
access to the schema because they bind to a special entry at the top of the logical namespace, called the root DSA-specific
Entry (rootDSE), which provides the schema location. rootDSE represents the top of the logical namespace and, therefore,
the top of the LDAP search tree. The attributes of rootDSE identify, among other things, the directory partitions — that is,
the domain, schema, and configuration directory partitions — as well as the forest root domain directory partition. One
attribute, schemaNamingContext, provides the location of the schema so that applications that connect to any domain
controller can find and read the schema.

subSchema Subentry
rootDSE also carries a mandatory attribute called subSchemaSubEntry. The value of this attribute is the distinguished
name of a subSchema object in the directory that defines the attributes (in attributeTypes) and classes (in objectClasses)
that make up the Active Directory schema. This special object, which is an instance of the unique subSchema class, is used
for administering information about the schema, in particular, the object classes and attribute types that are supported. This
enables client applications to retrieve the schema information by querying the subSchema entry. Clients must only retrieve
attributes from a subSchemaentry by requesting a base object search of the entry, where the LDAP search filter is
(objectClass=subSchema). The following distinguished name describes the location of the SubSchemaSubEntry container:
CN=Aggregate,CN=Schema,CN=Configuration,DC=DomainName,DC=DomainRoot
For more information about LDAP searches, distinguished names, and containers, see “Data Store Technical Reference.”

Schema Files
Active Directory data is distributed among all domain controllers in the forest. No single domain controller stores all
Active Directory data for the entire forest, but every domain controller does hold a copy of the schema. The database that
stores the Active Directory data on a particular domain controller is in a file named Ntds.dit. The location of the Ntds.dit file is
an option that you can set during the domain controller promotion process while you create the directory. The default
location for Ntds.dit and the database log files is systemroot\Ntds. For more information about the Ntds.dit file, see “Data
Store Technical Reference.”
Another file, the Schema.ini initialization file, contains the information that is necessary for creating the default directory
objects and the default security for the directory tree, as well as the Active Directory display specifiers. Although this file is
named Schema.ini, the schema itself is actually stored in the Active Directory database, Ntds.dit. Schema.ini is only used by
the Active Directory Installation Wizard to build the initial schema structure in the directory during the domain controller
promotion process. The Schema.ini file must not be modified.
Top of page
Active Directory Schema Processes and Interactions
Normally, you do not interact directly with the schema on a daily basis. Active Directory uses the schema to help create
objects that are stored in the directory. You interact with those objects, not the schema. You interact directly with the
schema when you make modifications to the schema by adding definitions to it or by modifying existing definitions.
Schema changes can affect the entire directory. Before you make any changes to the schema, you should thoroughly test
those changes in an isolated environment to ensure that the directory continues to function as planned after the changes
have been deployed. Only members of the Schema Admins group can make changes to the schema.
The two most common reasons for modifying the schema are:
Installation of an application that needs to add customized object definitions so that it can store information in the
•
directory, for example, an e-mail program that stores the user’s e-mail names in the directory
Testing of the development of applications that use the directory for data storage in which customized object definitions
•
need to be added to the schema and modified throughout their lifetimes as the development process proceeds

Modifying the Schema

When the existing class and attribute definitions in the schema do not meet the needs of your organization, you can add or
modify schema objects to extend the schema. You modify an existing attribute or add a new class or attribute to the schema
to store a new type of information in the directory. The process of modifying or updating the schema is often referred to as
extending the schema.
Before you extend the schema, you must take steps to ensure that the extension does not cause problems in the directory.
Do not extend the schema in your production forest without testing the extension in a private forest. First, make changes in
a test environment, and check that the changes behave as expected and that they meet your needs. After verifying the
changes, you can use various utilities, such as Ldifde, and scripts or customized applications to export the extensions from
the test environment and import them into the production environment. You perform most schema extensions by using
applications or scripts that are written to extend the schema.
Note
As is true for every object in Active Directory, schema objects are protected by access control lists (ACLs). Therefore, only
•
authorized users can alter the schema.
To add or modify a class definition or attribute definition, you add or modify the corresponding classSchema object or
attributeSchema object. This process is similar to adding or modifying any object in Active Directory, except that additional
checks are performed to ensure that changes do not cause inconsistencies or problems in the schema.

Adding Information to the Schema

Extending the schema is a major change, with implications throughout the directory. Extend the schema only when it is
absolutely necessary. Many schema modifications cannot be reversed; therefore, you must thoroughly plan and test changes
before you deploy them in your production forest.

Planning to extend the schema

Planning to extend the schema involves examining the default schema that comes with Active Directory to verify that there is
no way to use the existing classes or attributes for your needs. It also involves understanding the types of modifications that
can and cannot be made.
For more information about modifying the schema, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

Enabling schema extensions

After you decide to make changes to the schema and you carefully plan the types of changes that you are going to make,
you can proceed by implementing and testing the schema extensions in a test environment that is isolated from your
production network.
Because extending the schema is a significant operation, Active Directory has the following safety features, or interlocks, that
restrict schema modifications:
The Active Directory Schema snap-in must be registered. Active Directory Schema is not listed with the default MMC snap-
•
ins. It must be registered before it can be made available. This means that Schmmgmt.dll must be registered by using
Regsvr32.exe.
Changes to the schema must be written only on the schema master. Although all domain controllers have a copy of the
•
schema in their Active Directory database, only the domain controller that holds the schema operations master role (also
 known as flexible single master operations (FSMO)) is allowed to write changes to the schema.
Administrators must have specific access rights. Only members of the schema administrators group (Schema Admins) or
•
another administrator with explicit permission can make changes to the schema.
Schema modifications must be enabled. By default, schema modification is disabled on all domain controllers, including the
•
domain controller that hosts the schema operations master role.

Identifying or transferring the schema operations master role

Active Directory performs schema updates in a single-master fashion to prevent conflicts such as conflicts resulting from
simultaneous schema updates on two different computers. The one domain controller in the forest that is allowed to perform
schema updates at any specific time is referred to as the schema master. The schema master is the domain controller that
holds the schema operations master role. After the schema master completes an update, it replicates the changes to all other
domain controllers by normal replication channels. In this way, changes to the schema are distributed throughout the forest.
Note
To update the schema, the domain controller that holds the schema operations master role must be available on the
•
network. All schema modifications must be made to the domain controller that holds the schema operations master role. If
you attempt to modify the schema from a domain controller that does not hold that role, the domain controller generates
a referral to the current schema master to process the modifications.
Because the schema master must be used to extend the schema, the domain controller that currently holds the schema
operations master role in the forest must be identified. As the forest grows and changes, it may also become necessary to
assign the schema operations master role to a different domain controller. You can accomplish both of these tasks by using
Active Directory Schema or the command-line tool Ntdsutil.
You can change the domain controller that serves as the schema master at any time. The current schema master in the
enterprise is identified by the value of the FSMORoleOwner attribute on the schema head of the domain. By default, the
first domain controller that is installed in the forest is the initial schema master.

Granting access rights to make schema changes

To modify the schema, you must use an account that is a member of the Schema Admins group. By default, the only
member in the Schema Admins group is the Administrator account in the root domain of the enterprise. You must explicitly
add other accounts.
You can use Active Directory Users and Computers in MMC to verify that an account is a member of the Schema Admins
group. Restrict membership in the Schema Admins group to prevent unauthorized access to the schema. Improper
modification of the schema can have serious consequences.
By default, only members of the Schema Admins group have permission to write to the schema. You can grant explicit
permissions to use Active Directory Schema to specific users. However, this is not recommended.

Enabling schema modifications on a domain controller

If you want to allow the domain controller that holds the schema operations master role to modify the schema, use Active
Directory Schema to enable schema modifications.

Removing Information from the Schema

It is not possible to remove object definitions from the schema. However, object definitions can be rendered unusable
through the process of deactivation. When an object definition is deactivated, it can no longer be used to create new objects
in the directory. Objects whose definitions have been deactivated in the schema are referred to as defunct.

Deactivating schema objects

You cannot deactivate schema objects that are part of the default schema that ships with Active Directory. You can freely
deactivate schema objects that have been added to the default schema.
As a result of replication latency, it is not possible to accurately determine if any objects have been created by using a given
schema definition or to predict if the objects may be restored from backup media. Therefore, Active Directory does not
support the actual deletion of schema objects. Rather, it provides a mechanism for deactivating schema objects in such a
way that they become unavailable for use in the directory. Although a schema object still physically exists in the directory
after it has been deactivated, new instances of it cannot be created in the directory. Any existing instances of data that are
associated with the deactivated schema object continue to exist in the directory; however, there is no way to modify these
data instances other than to delete them. This behavior makes the schema object appear to be deleted from the schema.
You can use Active Directory Schema or ADSI Edit to deactivate a class or an attribute by setting the attribute isDefunct to
the Boolean value of TRUE on the schema object.
You can use Active Directory Schema to view defunct schema objects: on the View menu, make sure that Defunct Objects
is selected. In addition, you can write programs and scripts to search for all schema objects that have the attribute
isDefunct set to TRUE. You can also use the Search function of the Ldp tool to search the schema with a filter that is set to
isDefunct=TRUE.
As with the addition or modification of classes or attributes, some special validation checks are performed on the deactivation
of classes or attributes to ensure consistency of the schema. In particular, when you deactivate a class, Active Directory
verifies that the class is not used in the subClassOf, auxiliaryClass, or possSuperiors attributes of any existing active
class. Similarly, when you deactivate an attribute, Active Directory checks that the attribute is not used in the mustContain
or mayContain attributes of any existing active class.

Deactivating existing classes and attributes

Deactivation of schema classes and attributes is subject to the following restrictions:
You cannot deactivate a class or attribute that appears in the base Active Directory schema. You can only deactivate
•
schema extensions of the base schema.
You cannot deactivate an attribute that is referenced in the mustContain, systemMustContain,
•
mayContain,systemMayContain, or rdnAttId properties of an active class.
You cannot deactivate a class that is referenced in the subClassOf, auxiliaryClass, orpossibleSuperior properties of an
•
active class.
To deactivate an attribute, set the isDefunctattribute of itsattributeSchema object to TRUE. When an attribute is
deactivated, it can no longer be added to new class definitions. To reactivate an attribute, set the isDefunctattribute to
FALSE.
To deactivate a class, set the isDefunct attribute of its classSchema object to TRUE. When a class is deactivated, new object
instances of the class can no longer be created. To reactivate a class, set the isDefunct attribute to FALSE.

Effects of deactivating a schema object on schema updates

After a class salesUseris deactivated, any subsequent addition or modification of instances of salesUserfails as if
salesUserhas been deleted from the system; the same error codes are returned as if salesUsernever existed at all. For
example, creating a new instance of salesUserfails, and trying to modify or rename an existing instance of salesUserfails.
Similarly, if an attribute hasPager is deactivated,hasPager is treated as nonexistent for new object creations, and
attempting to modify (add or replace) the value of hasPagerin an existing object fails.
However, you can still search for and delete existing instances of deactivated schema objects. For example, you can still
search for all existing instances of salesUserand delete them, if necessary. Note that what you are doing is searching for
and deleting objects that were created in the directory using the deactivated class, salesUser, not deleting the actual class
definition from the schema. Similarly, you can search for all instances that have a value for the attribute hasPagerand
delete hasPagerfrom the existing objects. This facilitates cleanup after a schema object is deactivated. If you decide that a
class is not needed anymore, you can deactivate it so that no one can use it for any modifications. You can then clean up the
existing instances of the class by searching for all instances and deleting them. Active Directory does not perform any
automatic cleanup of data instances after a schema object is deactivated.
Similarly, you can deactivate an attribute and clean up all its instances. Note that, for a deactivated attribute, you can delete
only the entire attribute from an object, not certain values of the attribute. For example, ifhasPageris a multivalue attribute
and an object has more than one value for hasPager, you cannot delete only one value of hasPagerfrom the object.
In addition to affecting instances of the schema object, deactivating a schema object also affects schema updates, because
schema object updates are subject to special validation checks. For example, if you deactivate the class salesUser or the
attribute hasPager, subsequent schema object updates behave as follows:
Deactivated classes and attributes can be renamed in the schema. They can also be modified to make other changes to
•
the corresponding classSchema and attributeSchema objects. Note that this behavior is different from the behavior of the
Windows 2000 Active Directory schema, in which no modifications are allowed on defunct classes or attributes, except
modifications of the isDefunct attribute to reactivate the deactivated class or attribute.
Validation checks that are performed when you add a new class or attribute or when you modify an existing nondefunct
•
 class or attribute treat salesUser as nonexistent. For example, if hasPager is a defunct attribute, trying to modify an
existing nondefunct class by adding mayContain=hasPager fails because the validation checks that are performed at
schema modification time fail as if hasPager does not exist. Or, in the case of a defunct class salesUser, trying to add a
new class with subClassOf=salesUser fails, because salesUser is treated as nonexistent by the validation checks that are
performed during the addition of the class.
There is an exception to the rule of defunct classes being treated as nonexistent in Windows 2000 Active Directory. When
you try to add or modify a class or attribute so that it has the same distinguished name; object identifier (attributeID,
governsID); lDAPDisplayName; mAPIID; or schemaIDGUID as the defunct class or attribute, the operation fails. In
these cases, the class or attribute is treated as an active schema object from the standpoint of schema consistency checks
during schema update operations. In Windows Server 2003, this behavior has changed. Defunct objects are still left in the
directory. However, it is possible to create a new object that uses the same identification attribute values (that is,
attributeID, governsID, lDAPDisplayName, mAPIID, or schemaIDGUID) as a defunct schema object, as long as the
new object’s distinguished name is unique. This makes it possible to deactivate a schema object and then create an entirely
new schema object — reusing the same values in its definition as the deactivated object — as if the old object were actually
deleted. For example, you can change the canonical name (CN) of a defunct object so that you can reuse its old name in the
definition of a new schema object. This is very valuable for developers who must constantly modify various classes and
attributes for testing purposes. It is possible now to mark an old version of an object definition as defunct and install a new
version of the object that uses the same identifiers, making it much easier to develop and test applications that interact with
the directory.
This ability to make schema objects defunct can be very useful in different ways in production environments. You can clean
up schema objects that are no longer needed by making them defunct. Defunct schema objects are not visible in
Active Directory Schema unless you specifically select them on the View menu. Then, you can delete existing instances of
those classes or attributes if you want to. At the same time, if you need a schema object later, you can reactivate it by
modifying the isDefunct attribute on the object. This also protects against the accidental removal of a schema object by
making it defunct. Making a schema object defunct can be reversed easily with no side effects. Note that because
Active Directory does not do any cleanup of data instances after a schema object is made defunct, all instances of the
schema object that are made defunct by mistake remain and become valid data when the defunct schema object is made
active again.

Reactivating schema objects

You can reactivate a defunct schema object either by removing the isDefunct attribute from the object or by setting the
value of the isDefunctattribute to FALSE. You can perform both operations by using either Active Directory Schema or ADSI
Edit. Because reactivating a defunct schema object requires schema updates that are similar to adding a new schema object,
Active Directory performs the same validation checks as it does when you add a new schema object.
The following validation checks are performed when a defunct schema object is reactivated:
A defunct class cannot be reactivated unless the attributes that are referenced in its mustContain, systemMustContain,
•
mayContain,systemMayContain, or rdnAttId attributes — as well as the classes that are referenced in its subClassOf,
auxiliaryClass, and possibleSuperior attributes — are already active.
A defunct class cannot be reactivated if the value of any of the attributeslDAPDisplayName, governsID,
•
orschemaIDGUID is the same as the value that is stored in an already active class or attribute.
A defunct attribute cannot be reactivated if the value of any of the attributeslDAPDisplayName, attributeID,
•
schemaIDGUID, mAPIID is already in use by an active class or attribute.
A defunct schema object can be reactivated at any time. The only restriction is that the isDefunct attribute should be the
only attribute that is present in the modify call. This helps prevent any ambiguity problems while schema consistency checks
are performed.

Updating the Schema Cache

When changes are made to Active Directory, they are validated against the schema, which can affect domain controller
performance.
The schema is stored in the directory database. Because all changes are validated against the schema, they result in queries
of the schema in the directory database, which can increase the workload on a domain controller. To make the operation
more efficient, domain controllers cache the schema in memory. Anytime the schema is updated, the schema cache is also
updated automatically.
After the domain controller is started, the schema cache is loaded from the schema information in the underlying database
and updated automatically whenever the schema is updated. When changes are made, the schema cache is updated
automatically within five minutes after the first change is applied. During the interval before the schema updates are copied
to the schema cache, objects that reference a new or modified class or attribute cannot be added. If another domain
controller attempts to use the new schema modifications, a replication interval must pass before the change becomes
available. This behavior keeps the cache consistent, but it can be confusing because changes are not apparent until the cache
is updated, even though they are applied to the directory database. When a change is replicated to a domain controller from
a replication partner, the cache is updated immediately, without the five-minute delay.
You can update the schema cache by adding the schemaUpdateNow attribute to rootDSE with a value of 1. The value is
not used; it acts as a trigger or operational attribute. You can write this attribute to start a cache reload.
Adding the schemaUpdateNow attribute causes a schema cache update to start immediately. The update operation is
“blocking,” which means that no other modifications can be made until this operation is complete. This prevents multiple
changes from being made to the schema simultaneously. If the operation finishes with no errors, the cache is updated and all
schema updates are ready to be used. The return of an error, however, indicates that the cache update is not successful.
Applications that add the schemaUpdateNow attribute should be designed to accommodate the blocking write, particularly
to provide feedback if the program or script runs interactively.
You can also update the schema cache immediately by using Active Directory Schema: in the console tree right-click
Schema, and then click Reload the Schema.
Note
If you must make multiple changes to the schema, complete all changes before forcing an immediate schema cache
•
update, rather than forcing an update after each change. Multiple cache loads can result in increased workload on the
server.

Default Security Settings for Active Directory Objects

The default security descriptor for an Active Directory object is specified in the schema. When a new object is created, Active
Directory configures the default access rights for that new object. The security descriptor contains the settings that are used
to configure the default access rights, and the security descriptor is stored in the schema as part of that object types
definition.
Note
There are special cases in which default security is not applied on newly created objects. For more information about
•
access rights, see “Active Directory Schema” in the Microsoft Platform SDK on MSDN.

Default security settings for the domain directory partition

The domain directory partition object is derived from the object class domainDNS. Therefore, the default security of the
domain directory partition object is equivalent to the default security for domainDNS.
The default security descriptor for the domain directory partition includes the following permissions:

• Full Control to the Domain Admins group and the System group and Read to the Authenticated Users group.
Read on all properties to the Everyone group. This permission provides backward compatibility for application
•
programming interfaces (APIs).
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise
•
Domain Controllers group. These permissions allow members of the Enterprise Domain Controllers group to manage
replication automatically.
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin
•
Administrators group. Administrators of individual domain controllers can use these permissions to troubleshoot replication
problems.
Inheritable Full Control to the Enterprise Admins group. Enterprise Admins, by definition, have complete control of each
•
domain.
• Inheritable List Contents to the Pre–Windows 2000 Compatible Access group.
Inheritable Read Property on Remote Access Service (RAS) Information, General Information, Membership, User Account
•
Restrictions, and User Logon on all User Objects permissions to the Pre–Windows 2000 Compatible Access group.
• Inheritable Read on all Group objects.
Inheritable Auditing successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that
•
are performed on any object in the directory are audited immediately, without the need for extra user intervention.
 Inheritable access control entries (ACEs) provide a convenient way to remove auditing policy.

Default security settings for the configuration directory partition

The default security descriptor for the configuration directory partition includes the following permissions:

• Full Control to the Domain Admins group and System and Read to the Authenticated Users group.
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Enterprise
•
Domain Controllers group. These permissions enable domain controllers in the forest to replicate from each other and
automatically reconfigure the replication topology on the basis of replication delays and latency for the configuration
directory partition.
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin
•
Administrators group. These permissions enable administrators from individual domain controllers to synchronize
replication and topology management for the configuration directory partition.
Enable Inheritable Full Control to the Enterprise Admins group. This permission allows members of the Enterprise Admins
•
group exclusive control over the Configuration container. The Enable Inheritable Full Control permission is required to
control the Configuration container throughout the forest.
Enable Inheritable Auditing to the Writes by the Everyone group. Activating the auditing policy ensures that writes that are
•
performed on any object in the directory are audited immediately, without the need for extra user intervention. Inheritable
ACEs provide a convenient way to remove auditing policy.

Default security settings for the schema directory partition

The default security descriptor for the schema directory partition includes the following permissions:

• Write access to the schema head to the Schema Admins group.

Change Schema Master control permission to the Schema Admins group. This permission enables members of the Schema
•
Admins group to change which domain controller holds the schema operations master role.
Inheritable Full Control permission to the Schema Admins group. By default, the Schema Admins group is the only group
•
that has Write access to the entire schema head. A schema object does not have any exclusive control over its own
security; therefore, the object inherits its security from the schema head.
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology to the Enterprise Domain
•
Controllers group. These permissions enable the members of the Enterprise Domain Controllers group to manage
replication of the schema in the forest automatically.
Replicating Directory Changes, Replication Synchronize, and Manage Replication Topology permissions to the Builtin
•
Administrators group. These permissions enable the administrators of domain controllers to resolve replication issues.
Read permissions to the Authenticated Users group. This permission gives the members of the Authenticated Users group
•
the right to read the schema.
Audit successful/failed writes to the Everyone group. Activating the auditing policy ensures that writes that are performed
•
on any object in the directory are audited immediately without the need for extra user intervention. Inheritable ACEs
provide a convenient way of removing auditing policy.

Default security settings for attributes and classes

All attributes and classes inherit security from the ACLs on the schema head. This ensures that security for the entire schema
is consistent.
Note
The default security settings allow Write access to the schema head only to the Schema Admins
•
group.

Issues Related to Modifying the Schema

Three main issues relate to modifying the schema:

• The impact on replication

• Managing concurrent schema modification operations

• Handling invalid object instances

Impact on replication
Because the schema is replicated across all domain controllers in the forest, a schema update that is performed at one
domain controller is propagated throughout the forest. This guarantees that the schema is consistent across the forest.
However, because of replication latencies, there can be temporary inconsistencies.
Active Directory solves this problem by explicitly replicating the schema head from the originating server when failures occur.
Additionally, the replication of the schema head triggers an immediate schema cache update on the target server.
Active Directory then replicates the failed object again.

Managing concurrent schema modification operations

Programs that modify the schema should not be run concurrently unless the programs include provisions to check that
schema modifications that are made by one program will not conflict with schema modifications that are made by the other
programs. Active Directory must ensure that different program threads do not perform simultaneous, conflicting schema
updates, such as one thread deleting an attribute when another thread is adding the attribute to the mayContain list of a
class.
To ensure that different program threads do not perform simultaneous, conflicting schema updates, any thread that attempts
to perform a schema update also writes a special attribute on the schema head automatically as part of the transaction.
Active Directory automatically causes the thread to write the attribute so that you do not have to do so in your program
code. Only one thread can write this attribute at any one time. This method guarantees schema consistency, but it does not
guarantee which of the updates is successful. This is an important consideration when schema updates are made in a batch,
such as during the installation of directory-enabled applications.
For example, consider a scenario in which two programs, program A and program B, are being installed simultaneously. Both
programs are designed to create several new schema objects. Because Active Directory creates one thread per object
update, it is possible that some of the objects in program A and some of the objects in program B are created (if the internal
threads do not overlap). Then, one of the installations fails because a thread for a schema object creation for program A
overlaps with a thread for a schema object creation for program B.
Assume that program A fails because of the thread conflict and the resulting failure to create some of the needed schema
objects. Attempting to reinstall program A again does not work because some of the objects that program A created are
already in the schema, and trying to create them again in the second run returns an error.

Handling invalid object instances

Schema updates can make an existing instance of an object invalid. For example, suppose a user account object, JohnDoe, is
an instance of classSalesEmployee. The classSalesEmployee class has an attribute, POBox, in its mayContain list.
Therefore, because JohnDoe is an instance of classSalesEmployee, JohnDoe can have the POBox attribute defined in it.
Assume that JohnDoe does have this attribute currently defined in it. A schema update is performed that modifies
classSalesEmployee by deactivating the attribute POBox from its mayContain list. Note that this change makes the
instance of JohnDoe invalid because JohnDoe now has an attribute, POBox, that it is not allowed to have according to the
class definition of classSalesEmployee (of which JohnDoe is an instance). Active Directory allows the now-invalid objects to
remain in the directory and ensures that they do not cause problems in the rest of the schema. Active Directory does not
automatically clean up invalid objects, but invalid objects and attributes appear in searches and can be deactivated manually.

Interoperating with Other Directories

To provide more support for industry standards in Active Directory, the schema supports the inetOrgPerson object class
and the use of a standard file format for importing and exporting schema modifications.

inetOrgPerson Object Class

The Active Directory schema in Windows Server 2003 supports the inetOrgPerson object class. The inetOrgPerson object
class and its associated attributes are defined in RFC 2798. The inetOrgPerson object class is used in several non-Microsoft
LDAP and X.500 directory services to represent users in the directory.
Support for inetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The
inetOrgPerson class was added by adding new attributes to the schema and deriving inetOrgPerson from the user class
and the new attributes. As a result, inetOrgPerson can be used as a security principal.
inetOrgPerson in Windows Server 2003
To help organizations migrate their applications and directory data to Active Directory, the inetOrgPerson class has been
added to the base schema.
The definition of the inetOrgPerson class is based on RFC 2798. However, some issues have caused the Active Directory
definition of this class to differ from the RFC definition, as follows:
The inetOrgPerson class is derived from the user class, not the organizationalPerson class. This makes it possible for
•
inetOrgPerson to operate as a security principal. Accounts that are created as inetOrgPerson objects can log in to
Active Directory.
Attributes that are already defined in the base schema are not changed.
•
Several attributes in the base schema are defined as single-value instead of multivalue, or the reverse, as defined in the
RFC 2798. The object identifier of some attributes differs from the definition in the RFC. Changing the definition of these
attributes in the base schema to match the RFC causes backward compatibility problems with the Windows 2000
Active Directory schema and may result in application problems. For example, Microsoft Outlook will not display the data
for attributes that have an unexpected value for the isSingleValued attribute. Active Directory management tools may
treat the attributes incorrectly and inadvertently overwrite data or fail to update them at all.
The inetOrgPerson class inherits two mandatory attributes:
•
• The cn attribute is used to name a new instance of the class. The samAccountName attribute is the user’s login ID.
The objectCategory attribute for inetOrgPerson is set to Person. This has the effect of returning all user, computer,
•
and inetOrgPerson objects when the filter in a query is objectCategory=Person.

Importing and Exporting Directory Information

Active Directory supports the use of files that are formatted with LDAP Data Interchange Format (LDIF) for importing and
exporting information in the directory. This includes information that is stored in the schema, such as schema modifications.
LDIF is an industry-standard, ASCII, text-based file format that can be used to define data in a text file that is used to import
information, such as schema modifications, into LDAP-based directories. LDIF is defined in RFC 2849.
After an LDIF file is created, a tool such as Ldifde.exe, which is available in Windows Server 2003, performs the import
operation using the data file for input. Ldifde.exe can also be used to export data from the directory. Exported data is also
stored using the LDIF file format to make it easier to import the data into another LDAP-based directory. For more
information about LDAP, see “Data Store Technical Reference.”
Top of page

Active Directory Schema Tools and Settings

Updated: March 28, 2003
Active Directory Schema Tools and Settings
In this section

• Active Directory Schema Tools

• Related Information
When existing class and attribute definitions in the Active Directory schema do not meet the needs of your organization, you
can use schema-based administrative tools to modify or add schema objects. You can modify an existing attribute or add a
new class or attribute to the schema to store a new type of information in the directory. The process of modifying or
updating the schema is often referred to as “extending the schema.” In addition to using schema tools to extend the schema,
you can perform most schema extensions by using customized applications or Active Directory Service Interfaces (ADSI)
scripts.
Note
Extending the schema is a major change with implications for the entire directory. Extend the schema only when it is
•
absolutely necessary. Many schema modifications cannot be reversed; therefore, you must thoroughly plan and test
changes in an isolated environment before you deploy them in your production forest.
This section contains information about the tools that are associated with the Active Directory schema.
Top of page
Active Directory Schema Tools
Normally, you do not interact directly with the schema on a daily basis. Active Directory uses the schema to create objects
that are stored in the directory. You interact with those objects, not with the schema. You interact directly with the schema
when you make modifications to the schema by adding definitions to it or by modifying existing definitions.
Only members of the Schema Admins group can make changes to the schema. The two most common scenarios for
modifying the schema are as follows:
You install an application that adds customized object definitions so that it can store information in the directory; for
•
example, you install an e-mail program that stores user e-mail names in the directory.
You test the development of applications that use the directory for data storage. In this scenario, you add customized
•
object definitions to the schema and modify them throughout their lifetimes as the development process proceeds.
Note
Changes to the schema must be written only on the schema master. Although all domain controllers have a copy of the
•
schema in their Active Directory database, only the domain controller that holds the schema operations master role (also
known as flexible single master operations (FSMO)) is allowed to write changes to the schema.
The following tools are associated with the Active Directory schema.

Adsiedit.exe: ADSI Edit

Category
ADSI Edit is included when you install Support Tools for Windows Server 2003.
Version Compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
ADSI Edit is a Microsoft Management Console (MMC) snap-in that uses ADSI, which uses the Lightweight Directory Access
Protocol (LDAP). You can use ADSI Edit to view and modify directory objects in the Active Directory database. You can also
use it to view schema directory partition objects and properties. When you open ADSI Edit, the Schema container is
displayed by default. You can expand the container to view schema classes and attributes.
To find more information about ADSI Edit, see “Support Tools Help” in Tools and Settings Collection.

Csvde.exe: Csvde
Category
Csvde is a command-line tool that ships with Windows Server 2003.
Version compatibility
Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
The comma-separated value (CSV) file format is a simple format whose primary benefit is ease of use. In the CSV file
format, each line represents a discrete object in the directory, and the object’s attributes are separated by commas. The first
line of the file always contains all of the attribute names. Each subsequent line represents a different entry in the directory.
Values for multivalue attributes can also be specified, and they are delimited by semicolons (;).
Because this format is compatible with the Microsoft Excel CSV format, you can use Csvde.exe to export directory
information to an Excel spreadsheet or to import data from a spreadsheet into Active Directory. You can use this format only
for additions to the directory. Csvde.exe cannot be used to modify or delete objects. Csvde.exe also supports batch
operations that are based on CSV.
The parameters that are used for the Csvde.exe tool are the same as the parameters that are used for the Ldifde.exe tool.
However, unlike Ldifde.exe, Csvde.exe can export data from Active Directory into files that can be read by certain
applications. For example, if you want to view all Active Directory users in an Excel report, you can use Csvde.exe to export
the directory data into the CSV file format, which you can then read in Excel.
To find more information about Csvde.exe, see “Command-Line References” in Tools and Settings Collection.

Dsa.msc: Active Directory Users and Computers

Category
Active Directory Users and Computers is an MMC snap-in in Administrative Tools that is installed automatically on all domain
controllers running Windows Server 2003.
Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
Can Be Run From Can Be Run Against

• Windows Server 2003, Enterprise Edition • Windows 2000 Datacenter Server

• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional with Adminpak.msi installed

Active Directory Users and Computers is a graphical user interface (GUI) tool that you can use to manage users and
computers in Active Directory domains. To modify the schema, you must use an account that is a member of the Schema
Admins group. By default, the only member in the Schema Admins group is the Administrator account in the root domain of
the enterprise. You must explicitly add other accounts.
You can use Active Directory Users and Computers to verify that an account is a member of the Schema Admins group.
Restrict membership in the Schema Admins group to prevent unauthorized access to the schema. Improper modification of
the schema can have serious consequences.
By default, only members of the Schema Admins group have permission to write to the schema. You can assign explicit
permissions to use the Active Directory Schema snap-in to specific users; however, this is not recommended.

Ldifde.exe: Ldifde
Category
Ldifde is a command-line tool that ships with Windows Server 2003.
Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
Active Directory supports the use of files that are formatted with the LDAP Data Interchange Format (LDIF) for importing and
exporting information in the directory. This includes information that is stored in the schema, such as schema modifications.
After an LDIF file is created, a tool such as Ldifde.exe performs the import operation by using the LDIF file for input. You can
also use Ldifde.exe to add, modify, and delete directory objects; export Active Directory user and group information to other
applications or services; and populate Active Directory with data from other directory services.
To find more information about Ldifde.exe, see “Command-Line References” in Tools and Settings Collection.
Ntdsutil.exe: Ntdsutil
Category
Ntdsutil is a command-line tool that ships with Windows Server 2003.
Version Compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Ntdsutil.exe provides advanced management capabilities for Active Directory. For the Active Directory schema, you can use
Ntdsutil.exe to identify, transfer, or seize the schema operations master role. This tool is intended for use by experienced
administrators.
To find more information about Ntdsutil, see “Command-Line References” in Tools and Settings Collection.

Schmmgmt.msc: The Active Directory Schema snap-in

Category
The Active Directory Schema snap-in is an MMC snap-in in Administrative Tools that is installed automatically on all domain
controllers running Windows Server 2003. However, you must register it manually before you use it for the first time.
Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional with Adminpak.msi installed

The Active Directory Schema snap-in is a GUI tool that members of the Schema Admins group can use to manage
Active Directory objects and their associated attributes. You can use this tool to create and modify classes and attributes.
You can also use it to specify what attributes are indexed and what attributes are replicated to the global catalog.
The Active Directory Schema snap-in is not one of the default MMC snap-ins that is provided with Windows Server 2003. To
make it appear in the list of available snap-ins, install the Windows Server 2003 Administration Tools Pack (Adminpak.msi).
To register the Active Directory Schema snap-in, run Regsvr32 Schmmgmt.dll from the command prompt or from the Run
command on the Start menu.
ADSI and Visual Basic Scripts
Active Directory provides a set of interfaces that you can use programmatically to gain access to directory objects, including
schema objects. ADSI conforms to the Component Object Model (COM), and it supports standard COM features. ADSI defines
a directory service model and a set of COM interfaces that you can easily use with a variety of programming languages. With
Microsoft Visual Basic, Scripting Edition and ADSI, you can write scripts to modify the directory in various ways, including
extending the schema.
For more information about using ADSI and scripting to modify the schema, see Using Active Directory Service Interfaces in
the Microsoft Platform SDK on MSDN.
Top of page

Data Store Technical Reference

Updated: March 28, 2003
In the Active Directory directory service, the data store contains database files and processes that store and manage
directory information for users, services, and applications. A copy of the data store runs on each domain controller in the
forest. The data store provides access to directory information through a process called the Directory System Agent (DSA).
The data store holds directory information in a database file called Ntds.dit. The Active Directory data store is often referred
to as the directory.

What Is the Data Store?

Updated: March 28, 2003
In this section

• The Business Need

• The Data Store Solution

• Data Store Scenarios

Directories and
•
Databases
• Data Store Dependencies

• Related Information
In Active Directory, the data store contains database files and processes that store and manage directory information for
users, services, and applications. A copy of the data store runs on each domain controller in the forest. The Active Directory
data store is often referred to as the directory.

The Business Need

Organizations generate and store data about many different kinds of entities (computers, users, services, and so on) that
exist in their information technology (IT) infrastructure. Historically, organizations maintain this information in multiple
locations and formats. For example, an organization might store employee information in a human resources database,
application data in an application-specific database, Quality of Service (QoS) rules on routers, and security information (user
name and password) on a network server. Storing, managing, and making available many disparate data sets is expensive
and time consuming.
Top of page
The Data Store Solution
The Active Directory data store solves the problem of managing disparate data sets across an organization. The data store is
a single, general-purpose database that can hold many types of data and distribute that data to users anywhere on the
network. The following figure illustrates the use of the Active Directory data store as a single, general-purpose database for
all of an organization’s data.
Data Store
The Active Directory data store achieves the following major design goals:
To provide distributed access to the directory by users and applications, a copy of the data store resides on all domain
•
controllers in a domain or forest.
To provide standard interfaces for accessing data, the data store includes a Lightweight Directory Access Protocol (LDAP)
•
interface and a Messaging API (MAPI) interface.
• To support quick searches of directory data, the data store includes efficient query and index mechanisms.
To ensure scalability, the data store uses a hierarchical, or tree, model that supports partitioning. The data store also
•
ensures scalability by automatically managing database growth and increasing the database file size when necessary.
To support both full and incremental restoration of data, the data store uses a transactional model, logging uncommitted
•
transactions in log files.
To ensure data consistency, the data store enforces a set of extensible data type and format constraints, called the
•
schema.
Top of page
Data Store Scenarios
Active Directory is required for the deployment and operation of Windows Server 2003 domains and forests. The data store is
a key and required part of any Active Directory deployment. Therefore, the data store exists in any Windows Server 2003
domain or forest. Use of the data store can be further delineated into two main scenarios, based on the type of data that is
stored. These scenarios are the network operating system (NOS) directory scenario and the NOS and application directory
scenario.

NOS Directory Scenario

In the NOS directory scenario, an organization uses the data store only for storage of NOS-related information, including
information about users, computers, services, printers, and so on. This scenario applies to organizations that are not running
directory-enabled applications (applications that can communicate with and store data in a directory data store) or to
organizations that are using a different directory data store than Active Directory for storing application data. In this
scenario, you can manage the data in the data store by using the command-line and graphical user interface (GUI) tools that
are provided with Windows Server 2003.

NOS and Application Directory Scenario

In the NOS and application directory scenario, directory-enabled applications that are not a part of the NOS use the data
store to hold application-specific data. Examples of directory-enabled applications include messaging, customer relationship
management (CRM), enterprise resource planning (ERP), and document management applications. In this scenario, the
schema (the set of rules that define the type and formatting of data) is generally extended to include data definitions that
are specific to the directory-enabled applications that use the data store.
Top of page
Directories and Databases
In the context of directory services, questions often arise regarding the differences between directories and databases. The
Active Directory data store shares many aspects in common with databases, including the storage of data in rows and
columns and the use of a hierarchical data model.
A directory differs from a database primarily in its intended use. A directory is optimized for read operations, while a
database is optimized for write and change operations. Therefore, any data that is read many more times than it is written or
modified is a good candidate for storage in a directory.
A directory also typically differs from a database in the protocols that it uses to access information in the data store. A
directory, such as Active Directory, is most often accessed with LDAP. A database is most often accessed with an interface
such as Structured Query Language (SQL).
Top of page
Data Store Dependencies
The Active Directory data store depends on several related technologies and resources for its proper functioning. The
following sections describe these technologies and resources.

NTFS
The data store requires a disk volume that is formatted with the NTFS file system. NTFS is more powerful than FAT16 or
FAT32, and NTFS includes features that are required for hosting Active Directory. For more information about NTFS, see
“NTFS Technical Reference.”

Network Connectivity
So that users and computers can access the data store, and to support replication of the data store between domain
controllers, network connectivity with TCP/IP is required. For more information about networking and TCP/IP, see “TCP/IP
Technical Reference.”

Active Directory Replication

Except for very small networks, directory data must reside in more than one place on the network to be equally useful to all
users. Through the process of replication, Active Directory maintains copies, or replicas, of the data store on each domain
controller in the forest, which helps to ensure data availability and performance for all users. For more information about
replication, see “Active Directory Replication Model Technical Reference.”

FRS
The File Replication service (FRS) is a process that is associated with the Distributed File System (DFS). FRS is used by
Active Directory to replicate the system volume (SYSVOL) between domain controllers. SYSVOL holds certain kinds of Active
Directory information, including Group Policy objects (GPOs) and scripts. For more information about FRS, see “FRS Technical
Reference.”

Disk Space
There are no practical limits to the number of objects that can be stored in the Active Directory data store. The Active
Directory directory database has been tested for up to 40 million objects. Performance tests show logon performance for a
single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1 million objects; that is, the directory service
does not slow measurably when the size of the database increases.
The minimum free disk space requirements for the directory database and log files depend on the size of the database. On
partitions that hold the database only (and not the database log files), free disk space must not fall below the greater of
20 percent of the disk space that is consumed by the database or 500 megabytes (MB). On disk volumes that hold the
database and the database log files, free disk space must not fall below the greater of 20 percent of the combined size of the
Ntds.dit and log files or 1 gigabyte (GB). For more information about the Ntds.dit and log files, see “How the Data Store
Works.”

How the Data Store Works

Updated: March 28, 2003
In this section

• Data Store Architecture

• Data Store Protocols

• Data Store Interfaces

• Data Store Logical Structure

• Data Store Physical Structure

• Data Store Processes and Interactions

• Network Ports Used by the Data Store

• Related Information
In Active Directory, the data store contains database files and processes that store and manage directory information for
users, services, and applications. A copy of the data store runs on each domain controller in the forest. The Active Directory
data store is often referred to as the directory.
The ideal environment for the data store includes the following:
A domain controller running an operating system in the Windows Server 2003 family and containing hardware that meets
•
the minimum hardware requirements of the edition of the operating system (Windows Server 2003, Standard Edition;
Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition)
For environments consisting of multiple domain controllers, the presence of a fully functioning Active Directory replication
•
topology
For environments consisting of multiple domain controllers, the presence of a fully functioning File Replication service
•
(FRS) topology
• A regular backup schedule
Regular monitoring of Active Directory, either through manual review of event logs or through an automated monitoring
•
solution, such as Microsoft Operations Manager (MOM)
This section describes the elements of the Active Directory data store, including its architecture, protocols, interfaces, logical
structure, physical structure, processes and interactions, and network ports.

Data Store Architecture

The Active Directory data store consists of several components that together provide directory services to directory clients
and to other directory servers. These components include three service components, four interfaces, and the directory
database where data is actually stored.
The following figure illustrates the architecture of the data store.
Data Store Architecture

The following table describes the components of the data store.

Data Store Components

Component Description

Interfaces: Lightweight Directory Access The data store interfaces provide a way for directory clients and other directory
Protocol (LDAP), replication (REPL) and servers to communicate with the data store.
domain controller management interface,
Messaging API (MAPI), Security Accounts
Manager (SAM))

Directory System Agent (DSA) (Ntdsa.dll) The DSA, which runs as Ntdsa.dll on each domain controller, provides the
interfaces through which directory clients and other directory servers gain access
Component Description

to the directory database. In addition, the DSA enforces directory semantics,

maintains the schema, guarantees object identity, and enforces data types on
attributes.

Database layer The database layer is an application programming interface (API) that resides in
Ntdsa.dll and provides an interface between applications and the directory
database to protect the database from direct interaction with applications. Calls
from applications are never made directly to the database; they go through the
database layer. In addition, because the directory database is flat, with no
hierarchical namespace, the database layer provides the database with the
abstraction of an object hierarchy.

Extensible Storage Engine (ESE) (Esent.dll) The ESE, which runs as Esent.dll, manages the tables of records — each with
one or more columns — that make up the directory database.

Database files The data store stores directory information in a single database file called
Ntds.dit. In addition, the data store also uses log files, to which it temporarily
writes uncommitted transactions.
The DSA, database layer, and ESE are described in the following sections. For information about the interfaces, see “Data
Store Interfaces" later in this section. For information about the database files, see “Data Store Physical Structure” later in
this section.

DSA
The DSA runs on every domain controller as Ntdsa.dll, and it provides access to the directory database. The DSA runs as part
of the Local Security Authority (LSA) process (Lsass.exe), which manages authentication packages and authenticates users
and services. Running in Lsass.exe enables Active Directory to securely manage sensitive information, such as account
passwords.
Clients can use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write to Active
Directory objects and their attributes.
A forest-wide object in the directory, the NTDS Settings object (class nTDSDSA), represents the DSA on a domain controller,
and this object contains configuration information about the DSA on that domain controller.
In addition to providing the interfaces through which directory clients gain access to directory data, the DSA provides the
following functionality.

Object identification
Every object in Active Directory has a permanent globally unique identifier (GUID), which is associated with several string
forms of the object name (SAMAccountName, user principal name, and distinguished name), as well as a security identifier
(SID). The object names and the SID are not permanent; that is, they can be changed. All permanent references to the
object are kept in terms of the GUID. The object name is used for hierarchy navigation and display purposes, and the SID is
used for access control. The DSA maintains the GUID association with an object when the object’s string name or SID
changes, for example, when the object is moved to a different folder (the string name changes) or when the object is moved
to a different domain (the string name and the SID change).

Schema enforcement
The DSA ensures that data in the directory adheres to the data definitions that are provided by the directory schema. The
schema is the set of rules that determines what kind of data the directory can hold.
Note
In Windows 2000 Server and Windows Server 2003 forests, if an update does not produce a conflict with the schema at
•
the originating replica, the update is considered acceptable at all replicas. Therefore, replicated updates do not perform
schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or
attribute. For more information about replication, see “Active Directory Replication Model Technical Reference”.
Access control enforcement
The DSA enforces security limitations in the directory by reading SIDs on the access token.

Support for replication

The API that is called to initiate replication is implemented in the DSA.

Referrals
The DSA manages the directory hierarchy information (referred to as knowledge), which it receives from the database layer.
The DSA is responsible for cross-references of Active Directory domain objects.

Functional levels
Beginning with Windows Server 2003 domain controllers, the DSA has a built-in numeric value that identifies its operating
system version — and therefore its functional capabilities — to other services. Services that rely on the DSA can use this
numeric value to determine which of their service features to enable.

DSA GUID and Invocation ID

Both the DSA and the Active Directory database are represented uniquely and have their own respective GUIDS. The DSA
GUID is the GUID of the NTDS Settings object (class nTDSDSA). The value of the DSA GUID is stored in the objectGUID
attribute of the NTDS Settings object of the given domain controller server object, which resides in the Sites container in the
configuration directory partition.
Domain controllers use the DSA GUID to locate replication partners. Replication uses a special Domain Name System (DNS)
name that contains the DSA GUID. This GUID-based DNS name is an alias for the local computer name. The Net Logon
service registers this alias resource record in DNS in the form of the CNAME (canonical name) resource record.
The DSA GUID is created when the domain controller is initially promoted, that is, when Active Directory is installed. The DSA
GUID is destroyed only if Active Directory is removed from the domain controller. The DSA GUID ensures that the DSA
remains recognizable when a domain controller is renamed. The DSA GUID is also not affected by the Active Directory
backup and restore process.
The Active Directory database has its own GUID, which the DSA uses to identify the database instance (the version of the
database). The database GUID is stored in the invocationId attribute on the nTDSDSA object. Unlike the DSA GUID, which
never changes for the lifetime of the domain controller, the invocation ID changes during the Active Directory restore process
to ensure the consistency of the replication process. On domain controllers running Windows Server 2003, the invocation ID
also changes when an application directory partition is removed from or added to the domain controller.

Database Layer
The database layer is an API that resides in Ntdsa.dll and provides an object view of the directory database, making the data
accessible to the DSA as a set of hierarchical containers. By applying schema semantics to database records, the database
layer isolates the upper components of the directory service from the underlying database system. The database layer is an
internal interface. No database access calls are made directly to the ESE; instead, all database access is routed through the
database layer.
In the directory database, each object is identified by its relative distinguished name, which is unique in the object’s parent
container. The relative distinguished name and the chain of successive parent object names make up the object’s
distinguished name. The database stores the relative distinguished name for each object, as well as a reference to the parent
object. The database layer follows these parent references and concatenates the successive relative distinguished names to
form distinguished names, thereby defining the object hierarchy.
The database layer is also responsible for the creation, retrieval, and deletion of individual records (objects), attributes within
records, and values within attributes. To carry out these functions, the database layer uses the schema cache (an in-memory
structure in the DSA) to get the information about the attributes that it needs.

ESE
The Extensible Storage Engine (ESE) is a Windows component that is used by Active Directory, as well as by several other
Windows components, as an interface to the data that is stored in an indexed and sequential access method (ISAM)
database. (The Active Directory database is an ISAM database.) The ESE is responsible for indexing the data in the database
file and for transferring the data in and out of the database. Its purpose is to enable applications to store and retrieve data
by using the ISAM. The ESE provides applications with a consistent data state by means of transacted data update and
retrieval. A crash recovery mechanism maintains data consistency, even in the event of a system crash. Transactions in the
ESE are highly concurrent, making the ESE suitable for server applications. The ESE caches data intelligently to ensure high-
performance access to data. In addition, the ESE is resource efficient, making it suitable for applications that perform
auxiliary roles.
The version of the ESE that runs on domain controllers running Windows Server 2003 and Windows 2000 Server is
implemented in Esent.dll.
The following characteristics of the ESE make it well suited to the storage needs of Active Directory. The ESE:

• Supports databases of up to 16 terabytes (TB) in size, and it can hold many millions of objects per domain.

• Supports indexing.

• Supports multivalued attributes.

• Supports update operations that are transacted for stability and integrity across system failures.

• Can be backed up while the domain controller is online.

Handles sparsely populated objects well; that is, space in the database is not reserved for attributes that do not have
•
values.
Note
The encrypting file system (EFS) enables users to encrypt individual files, folders, or entire data drives. Because EFS
•
initialization and domain controller startup occur in parallel, EFS recovery operations can interfere with the ability of the
ESE to start Active Directory and cause domain controller startup to fail.
The Active Directory schema defines all the attributes that are required and allowed for a given object. However, the ESE
reserves storage only for the space that is used — that is, only for the attributes that have values, not for all possible
attributes. For example, if a user object has 50 attributes defined in the schema and you create a user with values for only
4 attributes, storage space is allocated only for those 4 attributes. If more attributes are added later, more storage is
allocated for them.
The ESE implements the search and retrieval functionality of the underlying database. Also, the ESE is able to store
attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user
without requiring a different phone number attribute for each phone number.
ESE provides transactional views of the database. The cost of providing these views is that any object that is modified in a
transaction has to be temporarily copied so that two views of the object can be provided: one to the thread inside that
transaction and one to threads in other transactions. This copy must remain as long as any two transactions in the process
have different views of the object. The repository that holds these temporary copies is called the version store. Because the
version store requires contiguous virtual address space, it has a size limit. If a transaction is open for a long time while
changes are being made (either in that transaction or in others), eventually the version store can be exhausted. At this point,
no further database updates are possible.
Note
The percentage of version store space that is available for processing has been significantly increased in
•
Windows Server 2003.
Top of page
Data Store Protocols
The primary protocol that is used by the Active Directory data store is Lightweight Directory Access Protocol (LDAP), which
runs on top of TCP/IP. In addition, the data store uses remote procedure call (RPC) for MAPI, replication, domain controller
management, and SAM-related operations. And, although it is not widely used, the data store also supports the use of
Simple Mail Transfer Protocol (SMTP) for replication between domain controllers where “always on” network connections do
not exist.
The following figure illustrates the protocols and interfaces that are used by the data store. For more information about the
data store protocols, see the table that follows this figure. For more information about the data store interfaces, see “Data
Store Interfaces” later in this section.
Data Store Protocols
The following table describes the protocols that are used by the data store.
Data Store Protocols

Protocol Description

LDAP LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can
also run over User Datagram Protocol (UDP) connectionless transports. Clients can use LDAP to query, create,
update, and delete information that is stored in a directory service over a TCP connection through the TCP default
port 389. Active Directory supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 2251). LDAP v3 is an industry standard
that can be used with any directory service that implements the LDAP protocol. LDAP is the preferred and most
common way of interacting with Active Directory.
Historically, LDAP is a simplified (“lightweight”) version of Directory Access Protocol (DAP), which is the original
protocol that was used to interact with X.500 directories. X.500 defines an earlier set of standards that was
developed by the International Organization for Standardization (ISO). LDAP is simpler than DAP in two key ways:

• Rather than using its own protocol stack according to the Open Systems Interconnection (OSI) networking
model, LDAP communicates over Internet Protocol (IP) by using either UDP or TCP.

• LDAP syntax is easier to use than DAP syntax.

For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access.
The following key aspects characterize LDAP:

• The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged)
and over UDP for connectionless transport (sent or received data is not acknowledged).

• Most protocol data elements can be encoded as ordinary strings, for example, as distinguished names.
• Referrals to other servers can be returned to the client.
• Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated
security services. SASL Digest is supported in Windows Server 2003 as the authentication standard for LDAP.

• Attribute values and distinguished names can be internationalized through the use of the ISO 10646 character
set.

• The protocol can be extended to support new operations, and controls can be used to extend existing
operations.

• The schema is published through an attribute on the directory root object (rootDSE) for use by clients.
RPC The data store uses RPC for replication (REPL) and domain controller management communications, MAPI
communications, and SAM-related communications. RPC is a powerful, robust, efficient, and secure interprocess
communication (IPC) mechanism that enables data exchange and invocation of functionality residing in a different
process. That different process can be on the same computer, on the local area network (LAN), or across the
Internet.

SMTP The data store can use Internet-standard SMTP as the protocol for replication communications when a permanent,
Protocol Description

“always on” network connection does not exist between two domain controllers. SMTP is used to transport and
deliver messages based on specifications in Request for Comments (RFC) 821 and RFC 822. SMTP also includes
enhancements that build on the basic delivery functions of the protocol. There are SMTP options available that
provide control over the routing and delivery of messages and that provide secure communications.
Top of page
Data Store Interfaces
As shown in the “Data Store Architecture” figure earlier in this section, network clients and other directory servers obtain
access to Active Directory through one of the interfaces that are described in the following table.
Data Store Interfaces

Interface Description

LDAP LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to the DSA through the
LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.

REPL The REPL management interface provides functionality for finding data about domain controllers, converting the
names of network objects between different formats, manipulating service principal names (SPNs) and DSAs, and
managing replication of servers.

MAPI Messaging clients gain access to the Microsoft Exchange Server directory service by using MAPI address book
providers. For compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book
provider, which provides access to Active Directory, for example, to find the telephone number of a user.

SAM SAM is a proprietary interface for connecting to the DSA on behalf of clients that use Windows NT 4.0 or earlier.
These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM. Replication with
Windows NT 4.0 backup domain controllers (BDCs) goes through the SAM interface as well.
Note
The MAPI interface is provided only for support of legacy Microsoft Outlook clients. Development against the MAPI
•
interface is no longer supported.
Top of page
Data Store Logical Structure
The Active Directory data store uses the LDAP information model as its model for organizing data. In addition, the data store
is organized into logical partitions that can each be replicated independently, so that individual domain controllers only need
to store data that is pertinent to the domain in which they reside.

LDAP Information Model

The LDAP information model is based on the entry, which contains information about some object, for example, a person or
computer. In Active Directory, an LDAP entry is referred to as an object. Active Directory objects are composed of attributes,
which have a type and one or more values.
The implementation of the information model is called the schema, which is a set of objects that defines the structure and
content of every object that can be created in a directory service.

Directory Tree
Active Directory organizes objects into a hierarchical tree structure. The directory tree represents the hierarchy of
Active Directory objects for a given forest. The structure of the hierarchy is derived from the schema, and the directory
service implements the hierarchy. The hierarchy provides the basis both for using names for navigation and for defining the
scope of search requests.
Every object in Active Directory has exactly one parent, and a reference to the parent object is stored with the object. As a
result of these parent references, the hierarchy of objects that are managed by Active Directory forms a tree structure. The
objects that populate the directory create this tree structure according to the rules of the schema. For example, the schema
might dictate that a given class of object can be the child of one class but not the child of another class.
The architectural restrictions and requirements in the directory tree are as follows:
 Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the
•
child of an organizational unit (OU).
The root object of the directory tree is called the DSA-specific Entry (DSE), or rootDSE. The rootDSE object has no
•
hierarchical name or schema class, but it does have a set of attributes that identify the contents of the domain controller
on which it resides. Therefore, rootDSE constitutes the root of the directory tree from the perspective of the domain
controller to which you are connected.
Below the rootDSE, every directory has a root domain, which is the first domain that is created in a forest. This domain
•
always has a child container called Configuration, which contains configuration data for the forest.

rootDSE
In the LDAP information model, one or more directory servers can jointly provide access to a directory tree. The servers that
host directories are known in LDAP terminology as Directory System Agents (DSAs). In Active Directory, the DSAs are always
domain controllers.
At the root of a directory tree is a DSE, which is not part of any directory partition. TherootDSE represents the top of the
logical namespace for one domain controller. The rootDSE attributes contain information about the directory server, including
its capabilities and configuration.
There is only one root for a given directory, but the information that is stored in the root is specific to the domain controller
to which you connect. Among other things, the attributes of rootDSE identify the following key information:
The directory partitions (the domain, schema, and configuration directory partitions) that are specific to one domain
•
controller.
• The forest root domain directory partition.
In this way, the rootDSE provides a “table of contents” for a given domain controller.

rootDSE operational attributes

The rootDSE publishes information through attributes on the rootDSE object. RFC 2251 and RFC 2252 define a set of seven
rootDSE operational attributes that LDAP v3 servers are expected to publish, and these attributes are described in the
following list. All LDAP servers recognize these attribute names, but when the attribute corresponds to a feature that the
server does not implement, the attribute is absent.

supportedLDAPVersion
LDAP versions that the server implements. Domain controllers running Windows Server 2003 and Windows 2000 Server
support LDAP v2 and LDAP v3.

namingContexts
Naming contexts (directory partitions) that this server masters (stores as a writable replica) or shadows (stores as a read-
only replica). A client uses this attribute to choose suitable base objects for searching when the client contacts a server.

subschemaSubentry
The name of a subschema entry, which is used to administer information about the schema, in particular, the object classes
and attribute types that are supported.

altServer
Uniform Resource Locators (URLs) of other servers that can be contacted when this server becomes unavailable. If the server
does not know of any other servers, this attribute is absent. Clients can cache this information in case their preferred LDAP
server becomes unavailable. This attribute is absent by default for Active Directory servers.

supportedExtension
Object identifiers that identify the supported extended LDAP operations that the server supports. LDAP extensions include
operations such as different query types, paging operations, and sorting methods, which each have a different object
identifier. This attribute is absent by default for Active Directory servers.
Note
A new extended LDAP operation on domain controllers running Windows Server 2003 enables client refresh of a dynamic
•
 entry in the directory. Object identifier = 1.3.6.1.4.1.1466.101.119.1 is defined and published in the
supportedExtension attribute of the rootDSE object.

supportedControl
Object identifiers that identify the LDAP controls that the server supports. If the server does not support any controls, this
attribute is absent. Server controls extend LDAP functionality; examples include a control to move objects across domains
and a control to delete an entire subtree of a container object.

supportedSASLMechanisms
The names of the SASL mechanisms that the server supports. SASL is a standard for negotiating an authentication
mechanism and, optionally, an encryption mechanism to provide client authorization for accessing Active Directory. By
default, Generic Security Service API (GSSAPI) is supported.

rootDSE informational attributes

In addition to the previous operational attributes, Active Directory also supports the following informational attributes.

currentTime
The current time in the generalized time format.

dsServiceName
The distinguished name of the NTDS settings object that represents this domain controller in the configuration directory
partition.

defaultNamingContext
The default naming context (directory partition) for a particular server. This value is the distinguished name of the domain
directory partition for which this domain controller is authoritative.

schemaNamingContext
The naming context (directory partition) for the forest schema.

configurationNamingContext
The naming context (directory partition) for the forest Configuration container.

rootDomainNamingContext
The distinguished name for the domain naming context (directory partition) of the first domain that is created in this forest.
This domain functions as the forest root domain.

supportedLDAPPolicies
Supported LDAP administrative query policies, such as the maximum size of a result set (MaxResultSetSize) and maximum
page size (MaxPageSize).

highestCommittedUsn
Highest update sequence number (USN) that is committed to the database on this domain controller.

dnsHostName
The DNS name of this domain controller.

serverName
The fully qualified distinguished name for this domain controller.

supportedCapabilities
The object identifier value (1.2.840.113556.1.4.800) that indicates the additional capabilities of an Active Directory server,
such as dynamic update, integrated DNS zones, and LDAP policies.

LdapServiceName
The SPN for the LDAP server, which is used for mutual authentication.

isSynchronized
A Boolean indicator for whether the domain controller has completed its initial synchronization with replica partners.

isGlobalCatalogReady
A Boolean indicator for whether the domain controller is prepared to advertise itself as a global catalog.

domainControllerFunctionality
The numeric level of Active Directory functionality for the domain controller.

Distribution of Directory Data

So that it can scale to tens of millions of objects, the Active Directory data store is logically partitioned in such a way that
each domain controller does not store the entire directory. To accomplish logical partitioning, the data is categorized
according to a naming scheme: object names group objects into logical categories so that the objects can be managed and
replicated appropriately. In Active Directory, the largest of these logical categories is called a directory partition.
Every domain controller holds at least one directory partition that stores domain data, such as users, groups, and OUs. Every
domain controller also stores two nondomain directory partitions that store forest-wide data, which includes the schema and
configuration data.
The data store holds data for a single forest. Although there is a single directory, some directory data is distributed within
domains, while other data is distributed throughout the forest without regard for domain boundaries. In
Windows Server 2003, data can also be distributed to domain controllers according to applications that use the data, where
the scope of distribution is set by the application. The following table describes the three types of data that are stored in the
Active Directory data store.
Types of Active Directory Data

Data Type Description

Domain-
wide data
• Domain-specific data is stored in a domain directory partition.
• A full, writable replica of the domain directory partition is replicated to every domain controller in the
domain.

Forest-wide
data
• Forest-wide data is stored in two directory partitions: the configuration directory partition and the schema
directory partition. The Configuration container is the topmost object of the configuration directory
partition; the Schema container is the topmost object of the schema directory partition.

• A full, writable replica of the configuration directory partition is replicated to every domain controller in the
forest.

• A read-only replica of the schema directory partition is replicated to every domain controller in the forest.
The schema is writable on only the domain controller that holds the schema operations master role, and
writing to the schema requires first adding a registry entry on the schema master. Schema updates
replicate to every domain controller in the forest.

• In addition to a full, writable replica of a single domain (the domain for which the domain controller is
authoritative), special domain controllers that are designated as global catalog servers also store partial,
read-only replicas of every other domain directory partition in the forest. (The read-only replicas in the
global catalog are “partial” because they store only some of the attributes for each object.) A domain
controller that is a global catalog server can be queried to find any object in the forest.
Data Type Description

Application
data
• Applications can use a new type of directory partition in Windows Server 2003 Active Directory, called an
application directory partition, to store application-specific data that has a scope of interest that is smaller
than the entire forest or domain. This data can be characterized as either changing frequently (dynamic) or
having a short useful lifetime (volatile). For example, Windows Server 2003 DNS can use application
directory partitions to store dynamically updated DNS zone data on only those domain controllers that are
DNS servers rather than on all domain controllers in the domain, as is required for Windows 2000
Active Directory–integrated zones.

Directory Partition Hierarchy

In Active Directory, a directory partition is a portion of the directory namespace. Each directory partition contains a subtree
of the directory objects in the directory tree. The same directory partition can be stored as a replica on many domain
controllers, and the replicas are updated through directory replication.
There is an important distinction between the physical storage of a directory partition and its logical position in the directory
tree. Physically, all objects are stored in a single database table, regardless of the directory partition to which they are
assigned because of their object names. Logically, the head of a directory partition appears in the naming hierarchy as the
topmost object; that is, the Domain container, the Configuration container, and the Schema container each has a
distinguished name that identifies its position in the hierarchy.
Every domain controller stores a replica of a domain directory partition, the configuration directory partition, and the schema
partition. For more information about these partitions, see “Directory Partitions” later in this section.
Note
Although the schema directory partition is replicated to every domain controller in the forest, it can be updated only on the
•
domain controller that holds the schema operations master role.
The following figure is a conceptual diagram of the directory tree hierarchy, including the directory root (rootDSE) and the
default directory partitions below the directory root. TherootDSE represents the top of the logical namespace for one domain
controller and, as such, it represents the top of the LDAP search tree. There is only one root for a given directory, but the
information that is stored in the root is specific to the domain controller to which you connect.
In any Active Directory forest, the first domain directory partition that is created in the forest (the forest root domain), the
configuration directory partition, and the schema directory partition always form the hierarchy that is illustrated in the
following figure.
Default Active Directory Partitions

Additional directory partitions are possible in the form of application directory partitions, but these partitions are not stored
by default on every domain controller.

Directory Partition Cross-Reference Objects

When Active Directory is installed to create the first domain controller in a new forest, the three directory partitions that are
shown in the previous figure are created on the domain controller. At this time, a cross-reference object (class crossRef) is
created for each directory partition in the Partitions container in the configuration directory partition
(CN=partitions,CN=configuration,DC=forestRootDomain). Creation of each subsequent directory partition in the forest, either
by installing Active Directory to create a new domain or by creating a new application directory partition on an existing
domain controller, initiates the creation of an associated cross-reference object in the Partitions container.
Note
You can also manually create a cross-reference object for an application directory
•
partition.
A cross-reference object identifies the name and server location of each directory partition in the forest. The replication
system uses this information to identify servers that store the same directory partitions. LDAP queries use cross-reference
objects to create referrals to different domains.

Forest Root Domain

Because the forest root domain is the first domain that is created in a forest, it is the root name in the domain namespace
hierarchy. In naming only, the topmost object of the configuration directory partition — the Configuration container — is the
child of the forest root domain object in the hierarchy. The LDAP distinguished name of the Configuration container
(CN=configuration,DC=forestRootDomain) reflects this naming hierarchy, which links the configuration directory partition to
the forest.
Similarly, the topmost object in the schema directory partition — the Schema container — is the child of the Configuration
container. The distinguished name of the Schema container (CN=schema,CN=configuration,DC=forestRootDomain) links the
schema to the forest.

Directory Partitions
The Active Directory data store holds three default directory partitions:

• The configuration directory partition

• The schema directory partition

• The domain directory partition

Optionally, the data store may also hold one or more application directory partitions.

Configuration Directory Partition

The configuration directory partition is created initially when the first domain of a forest is created during the installation of
Active Directory. Thereafter, it is replicated to every new domain controller that is added to the forest. The configuration
directory partition holds information of global interest, for example, the default configuration and policy information for all
instances of a given service in the forest.
Note
Global information should be stored in one of two places: in a child of the Services container or in a child of a site
•
object.

Contents of the configuration directory partition

In Active Directory tools, such as ADSI Edit, the configuration directory partition is represented by a Configuration container.
When you open ADSI Edit (Adsiedit.msc) from the Run dialog box, the Configuration container for the forest of the domain
to which you are connected is displayed, along with the current domain directory partition and the schema directory
partition.
Note
If you open ADSI Edit with Microsoft Management Console (MMC) (as opposed to opening ADSI Edit from the Run dialog
•
box), you must connect to the directory partition to view it.
The following objects are child containers in the Configuration container.

DisplaySpecifiers
Contains the objects that define different user interfaces (UIs) for each object class in the schema that requires a graphical
user interface (GUI), for example, context menus and property pages. The display specification system uses the information
that is stored in the display specifiers to form different UIs for administrators and end users. One set of elements can be
associated with administrative applications, and a different set of elements can be associated with end-user applications.
What you see and what the user sees are different, even though in both cases the UI references the same objects. The
display specification system stores information for property sheets, context menus, icons, creation wizards, and localized
class and attribute names.
This UI specification occurs at the level of each object class as defined in the schema in classSchema objects. Each
classSchema object can have UI display specification information that is uniquely associated with it.
The DisplaySpecifiers container stores other containers that correspond to each locale that is supported. A locale is either a
language or a language in combination with a country/region. Windows supports more than 150 locales, such as French
(Belgium), Arabic (Saudi Arabia), and so forth. The names of locale containers are the hexadecimal representations of the
locale identifiers (LCIDs). For example, the English (United States) locale container is 409.
Display-specifier objects (class displaySpecifier) are named by appending the LDAP Display Name of the class object with
the string -“-Display.”. For example, the user class has a corresponding display-specifier object called user-Display.
Therefore, when an Active Directory administrative tool displays an object of a particular class, the object is displayed
according to information that is contained in the display-specifier object whose name contains the same name as the
respective class in the container for the current locale.
Because the Active Directory schema can be modified by creating new classes and attributes or by modifying existing
classes, display-specifier objects can be modified to reflect any new UI elements that schema modifications require.

Extended-rights
Stores objects of the class controlAccessRight that can be used by applications to extend standard access control.

ForestUpdates
Stores operation objects that are generated by forest preparation tasks (when you run adprep /forestprep) so that the
system can check for the tasks that have and have not been completed when you upgrade the first domain controller in the
forest to Windows Server 2003. The child object CN=Operations contains the objects that represent each update operation.
These objects are named for the GUID of the operation. The child object CN=Windows2003Update is created to indicate that
all adprep operations have run.

LostAndFoundConfig
Provides storage for configuration directory partition objects that are being created in containers that are simultaneously
being deleted on another domain controller in the same forest. If, before replication, an object is created in or moved to a
location that no longer exists after replication, the “lost” object is added to the LostAndFoundConfig container. A
LostAndFound container in each domain directory partition serves the same purpose for domain-specific objects.

NTDS Quotas
Stores objects (class msDS-QuotaControl) that contain object ownership quota assignments for the configuration directory
partition. Quotas limit the number of objects that a user (including inetOrgPerson), group, computer, or service can own in a
domain directory partition, configuration directory partition, or application directory partition.

Partitions
Stores the cross-references to every directory partition in the forest, including the configuration partition, the schema
partition, and all domain directory partitions. These cross-references to directory partitions make referrals to other domains
possible during LDAP searches.

Physical locations
Not used in this version of Windows but reserved for future use.

Services
Stores data for various networking services and applications, such as Message Queuing (MsmqServices), public key
services, and Routing and Remote Access. In the Windows NT container, the Directory Service object (nTDSService) has
attributes that you can use to manage garbage collection intervals and dynamic object Time to Live (TTL). For the most part,
however, objects in the Services container do not require administration. Specifically, do not publish application services in
this container. Such services are best published in the Program Data container in the domain directory partition.

Sites
Identifies all of the sites in the network, the domain controllers in those sites, and the replication topology. The contents take
the form of replication transports, subnets, and the first site and site link that are created, called Default-First-Site-Name and
Default-First-Site-Link, respectively.

Well-known security principals

Contains the special identities that are defined by the security system, such as Everyone, Local System, Principal Self,
Authenticated User, and Creator Owner.

Schema Directory Partition

The Active Directory schema is stored in the Schema container in the schema directory partition. The schema consists of a
set of object classes, attributes, and syntaxes. It also defines rules that ensure that objects are created and modified with
consistency. Active Directory contains a default set of classes and attributes that cannot be modified. However, if you have
Schema Admins credentials and if schema modification is enabled for the domain controller, you can extend the schema by
adding new attributes and classes to represent application-specific classes. These changes are targeted at the domain
controller that is the schema master for the forest. Only the schema master stores a writable copy of the schema.

Domain Directory Partition

When you create a new domain, a domain directory partition is created in Active Directory as an instance of the class
domainDns. A cross-reference object is added for the domain in the Partitions container to advertise the domain’s location
in the directory.

Contents of a domain directory partition

The topmost object in each domain directory partition is a domainDns object that is named with the DNS name of the
domain.
A domain directory partition is represented by a domain container, and a domain directory partition has the following child
containers.

Builtin
Default local group accounts, such as Administrators and Users, that are installed whenever a new workstation, server, or
domain controller is set up.

Computers
A default storage area for “new” computer objects that were originally created through legacy APIs. When a Windows NT 4.0
domain or a Windows NT 3.51 domain is upgraded to Windows 2000, or when a Windows NT 4.0 domain is upgraded to
Windows Server 2003, the computer accounts are moved automatically to the Computers container. The Computers
container also supports the Windows NT 4.0 tool User Manager (Usrmgr). This container cannot be renamed, but when a
Windows Server 2003 domain has a domain functional level of Windows Server 2003, the default location for computer
accounts can be specified as an OU to redirect the location of newly created computer objects.

Domain Controllers
The default container for new domain controllers. The Domain Controllers container cannot be renamed.

ForeignSecurityPrincipals
Proxy objects for security principals that are from Windows NT 4.0 domains or Windows NT 3.51 domains, or that are from
different forests, and that have been added to Windows 2000 or Windows Server 2003 groups.

LostAndFound (advanced features)

A storage area for new domain objects whose containers were deleted elsewhere at the same time that the object was
created. If an object has been created in or moved to a location that is missing after replication, the “lost” object is added to
the LostAndFound container. The LostAndFoundConfig container in the configuration directory partition serves the same
purpose for forest-wide objects.
NTDS Quotas (advanced features)
A storage area for objects of the class msDS-QuotaControl that contain object ownership quotas for the domain directory
partition. Quotas limit the number of objects that a user, group, computer, or service can create in a directory partition.

Program Data (advanced features)

An empty container that is available for applications to store application-specific data in the domain directory partition.

System (advanced features)

Built-in system settings for the various system service containers and objects.

Users
A default storage area for new user accounts created through legacy APIs that are not Active Directory–aware. When a
Windows NT 4.0 domain or a Windows NT 3.51 domain is upgraded to Windows 2000, or when a Windows NT 4.0 domain is
upgraded to Windows Server 2003, the user accounts and groups are moved automatically to the Users container. The Users
container also supports the Windows NT 4.0 tool User Manager (Usrmgr). This container cannot be renamed, but when a
Windows Server 2003 domain has a domain functional level of Windows Server 2003, the default location for user and group
accounts can be specified as an OU to redirect the location of newly created user objects.
Note
The Users and Computers containers and several other special containers, called “well-known” containers, can be located
•
dependably by applications.

Deleted Objects
A special container, which is not visible in the UI, to which objects are moved when they are deleted. The deleted objects are
stored as tombstones, which are eventually removed by garbage collection. The contents of the Deleted Objects container
are visible if you search by using the 1.2.840.113556.1.4.417 control, which enables you to see deleted objects.

Infrastructure
An object of class infrastructureUpdate that identifies the NTDS Settings object of the domain controller that holds the
infrastructure operations master role for the domain.

Contents of the System container

The System container stores per-domain operational information, which includes the default local security policy, file link
tracking, Microsoft NetMeeting network meeting objects, objects representing other trusted domains, and containers for RPC
and Windows Sockets (Winsock) connection points.
The System container has the following child containers.

AdminSDHolder
Administrator security descriptor holder. Windows Server 2003 implements protection of administrative groups through a
background task that computes the set of memberships and checks whether their security descriptors are well-known
protected security descriptors. If the security descriptor of any administrative account does not match that of
AdminSDHolder, the security descriptor is overwritten with the security descriptor of AdminSDHolder. This task is executed
only on the domain controller that holds the primary domain controller (PDC) emulator operations master role.

COMPartitions
A namespace that is used by Component Services to allow multiple versions of the same COM+ application to exist on the
same physical computer.

ComPartitionSets
A conceptual collection of COM+ partitions.

Default Domain Policy

The common domain location for the AppCategories container (class classStore), which holds objects of the class
categoryRegistration. These objects are managed by the Group Policy Software Installation MMC extension, and they can
be associated with applications that are deployed through Group Policy in the domain.
Note
The Group Policy object (GPO) for the default domain policy is stored in the Policies
•
container.

Dfs-Configuration
Lists the fault-tolerant Distributed File System (DFS) configuration and DFS volume information.

DomainUpdates
Stores operation objects that are generated by domain preparation tasks (when you run adprep /domainprep) so that the
system can check for tasks that have and have not been completed when you upgrade the first domain controller in the
domain to Windows Server 2003. The child Operations object contains the objects that represent each update operation.
These objects are named for the GUID of the operation. The child Windows2003Update object is created to indicate that all
adprep operations have run.

File Replication Service

Lists the Domain System Volume (SYSVOL) and provides a replication schedule from Sunday through Saturday, 12:00 A.M.
to 12:00 A.M.

FileLinks
Used by the Distributed Link Tracking Server service (TrkSvr) to store information about linked files that have moved across
NTFS volumes. Includes ObjectMoveTable, which tracks moved files, and VolumeTable, which maps volume IDs to
computer IDs.

IP Security
Contains the Internet Protocol security (IPSec) policies that are applied to local computers, domain member servers,
domains, OUs, or any GPO in Active Directory. Depending on your organization’s guidelines, IPSec policies can store multiple
security specifications, called rules, so that one policy can be applied to multiple computers. These rules apply to all users
who log on to the computer

Meetings
A folder that is used by Microsoft NetMeeting to publish network meeting objects.

MicrosoftDNS
A container in which Active Directory–integrated zone database records are created when the scope of replication is all
domain controllers in the domain. When DNS data is stored in Active Directory, each DNS zone is an Active Directory
container object (dnsZone). The dnsZone object contains a dnsNode object for every unique name in that zone. The dnsNode
object has a dnsRecord multivalue attribute that contains a value for every resource record that is associated with an
object’s name. When the scope of replication of DNS data is all DNS servers in the domain or all DNS servers in the forest,
DNS zone data is stored in application directory partitions, not in the domain directory partition.

Policies
Contains GPOs, which specify user and computer configurations for groups of users and computers. This container stores the
default domain policy (lists the security groups and default permissions for the domain); default domain controller policy;
and policy for passwords, lockouts, Kerberos, EFS data recovery, and trusted root certificates. Each GPO in the Policies
container is identified by a GUID, and each GPO includes the following:
Version information that is used to ensure that information is synchronized with Group Policy template
•
information
• Status information that indicates whether the GPO is enabled or disabled

• A list of components, or extensions, that have settings in the GPO

In addition to being stored in the Policies container, GPOs are also stored in a Group Policy template, and they are identified
by GUID. The Group Policy template is located in the SYSVOL, and it is used to store file type data for the GPOs.

RAS and IAS Servers Access Check

Verifies permissions for the RAS and IAS Servers domain local security group to access user account properties. When
Routing and Remote Access (configured for Windows authentication) or Internet Authentication Service (IAS) queries a
domain controller to validate user account credentials and receives a failure notification, there is no indication why the failure
occurred. It might have occurred because the user’s credentials were invalid or because the server running Routing and
Remote Access or IAS did not have the appropriate permissions to access user account properties. Routing and Remote
Access and IAS servers obtain access to user account properties by adding the computer account of the server to the RAS
and IAS Servers group. The RAS and IAS Servers group has Read permission to the RAS and IAS Servers Access Check
container. By attempting access to the RAS and IAS Servers Access Check container, the Routing and Remote Access or IAS
server determines whether or not it has permissions to access user account properties.

RpcServices
Includes the RPC name service lookup for domains using versions of Windows earlier than Windows 2000.

WinsockServices
Winsock services that publish themselves by using the registration and resolution (RnR) APIs are published in this container.

WMIPolicy
Stores Windows Management Instrumentation (WMI) filters. A WMI filter is a query based on configuration and event
information that is made available by WMI providers. By associating a WMI filter with a specific GPO, that WMI filter
determines which computers process policy settings in that GPO. Computers that meet all of the conditions that are specified
in the WMI filter return a value of TRUE and then process the GPO.

Application Directory Partitions

Application directory partitions are special partitions that can be created on domain controllers running Windows Server 2003
to provide LDAP storage for dynamic and volatile data. In Windows 2000 Server, nondomain data is limited to configuration
and schema data, which is replicated to every domain controller in the forest. In a Windows Server 2003 forest, application
directory partitions provide storage for nondomain, application-specific data that can be replicated to any arbitrary set of
domain controllers in the forest — as few or as many as needed by the application that uses the data.
Note
Applications must be specifically programmed to use application directory
•
partitions.

Characteristics and requirements

Application directory partitions have characteristics that make them suitable for storing dynamic data (data that is updated
frequently) or volatile data (data that has a specified useful lifetime), as opposed to more static data that domain directory
partitions and other directory partitions store. Although application directory partitions are represented as instances of the
domainDNS class, as are domain directory partitions, they have characteristics that differentiate their behavior from domain
directory partitions.
Note
Applications can create application directory partitions on Windows Server 2003–based domain controllers by explicitly
•
creating a domainDNS object. Only Windows Server 2003–based and later domain controllers allow creation of domainDNS
objects by means other than Active Directory installation. Because Windows 2000 Server and earlier domain controllers do
not recognize the request to create a domainDNS object, no special instance type is required to differentiate between
application directory partitions and domain directory partitions.

Similarities to domain directory partitions

The following characteristics of application directory partitions are the same as the characteristics of domain directory
partitions:
 Naming: Application directory partitions can be named in the same manner as domains, and they can be attached
•
anywhere in the Active Directory namespace where a domain can be attached. Therefore, an application directory partition
can be a child of a domain or of another application directory partition.
• DNS location: Application directory partitions can be discovered through DNS.
Cross-reference object: A cross-reference object is created in the CN=partitions,CN=configuration,DC=ForestRootDomain
•
container for each application directory partition.
Change notification for replication: The time intervals that control the latency of the initiation of an originating change
•
notification to replication partners within a site can be configured. These configuration changes are applied to all directory
partitions, but they are most useful for application directory partition replication of dynamic data.
Access control: The security and access control model for the application directory partition is the same as that for other
•
partitions in Active Directory.
TTL: For objects that are stored in an application directory partition, you can assign a TTL value that is configurable. The
•
only requirement is that the domain controller is running Windows Server 2003.
For objects that are stored in a domain directory partition replica on a Windows Server 2003–based domain controller in a
forest that has a forest functional level of Windows Server 2003, you can assign a TTL. For all other functional levels,
however, TTL values cannot be assigned to objects in domain directory partitions.

Differences from domain directory partitions

The following characteristics are different from domain directory partitions and specific to application directory partitions:
Credentials for creation: Creating an application directory partition requires Domain Admins credentials in the forest root
•
domain or Enterprise Admins credentials.
Replication scope: Whereas domain directory partitions are replicated to every domain controller in a domain, application
•
directory partitions can be replicated to any selected set of domain controllers in the forest. Because application directory
partitions do not have domain or site affiliations, either an administrator or the application that creates the directory
partition must explicitly define the scope of replication.
Note
It is best to store replicas of dynamic data on domain controllers in the same site because intersite replication latency
•
might not be acceptable for replica consistency.
NetBIOS name: Application directory partition objects do not have network basic input/output system (NetBIOS) names.
•
For this reason, their cross-reference objects, which are usually identified by the unique NetBIOS names of their respective
directory partitions, are named by GUIDs.
• Contents: Security principals (users, groups, services, and computers) cannot be stored in application directory partitions.

• Global catalog: Application directory partitions are not replicated to the global catalog.
Volatility: Whereas domain data should be relatively static, application directory partition data can be volatile, such as the
•
real-time data that is used by Microsoft Telephony API (TAPI) voice conferencing applications.

Stored objects
Any type of object, with the exception of security principals, can be stored in an application directory partition. In addition,
objects that reside in an application directory partition:
Can maintain distinguished-name references to other objects in the same application directory partition, objects in the
•
configuration and schema directory partitions, and any directory partition root object.
Cannot maintain distinguished-name references to objects in other application directory partitions or in domain directory
•
partitions.
• Cannot be moved to other Active Directory partitions outside the application directory partition in which they were created.
Applications can be programmed to store their dynamic data in application directory partitions. The following are examples of
applications and the kinds of dynamic objects that they store:
Real-time communication applications: These types of applications typically maintain rendezvous information about active
•
users (user name, computer, and IP address) and conferences in progress (conference name, description, time, and
originator).
Network services: Routing and Remote Access, Remote Authentication Dial-In User Service (RADIUS), Dynamic Host
•
Configuration Protocol (DHCP), and Common Open Policy Service (COPS) servers need to store dynamically changing
forms of data in a directory so that they can be accessed using one uniform method: LDAP. This data generally does not
require global replication, and it is also shared by many applications in the proximity of a single directory. (In this case,
the data is shared between RAS, RADIUS, DHCP, and COPS servers in a particular site.) The object types include
information about user sessions and bandwidth used.
 Directory-enabled networking: For implementing policy-based networking, there is a large amount of nonstatic, or volatile,
•
information that must be maintained, including information about the state of network links, the flows that are active
through a router, and the data rate for each flow. Policy servers might need access to such information to make a decision
based on policies that are predicated on dynamic network state in addition to static data that is stored in the directory.
The application directory partition, with its controlled replication scope, can accommodate transient data needs in
Active Directory by providing network applications with uniform and consistent access through LDAP to both static and
dynamic data.

Security descriptor reference domains

When an object is created in Active Directory, it is assigned a security descriptor that contains default access control entries
(ACEs) that are taken from the defaultSecurityDescriptor attribute of the class of which the object is an instance. The
default ACEs can include domain-relative, well-known SIDs. In the case of objects in a domain directory partition, the
reference domain by which the system interprets the domain-relative SIDs is the domain that is represented by the domain
directory partition.
In the case of an application directory partition, there is no security association between the application directory partition
and the domain of the domain controller on which it is created. In a Windows Server 2003 forest, a new, single-valued
attribute on the cross-reference object — msDS-SDReferenceDomain — stores the name of the reference domain that is
used to interpret the domain-relative SIDs in default ACEs for new objects in an application directory partition.
When an application directory partition is created, the value of msDS-SDReferenceDomain on the respective cross-
reference object is determined as follows:
If the parent object of the application directory partition is another application directory partition, the value of msDS-
•
SDReferenceDomain is set to the value of msDS-SDReferenceDomain on the cross-reference object of the parent
application directory.
• If the parent object is a domain directory partition, the value of msDS-SDReferenceDomain is set to the parent domain.
If there is no parent object, the value of msDS-SDReferenceDomain is set to the forest root domain.
•
Note
It is recommended that domain local groups not be used in the access control lists (ACLs) of objects in application
•
directory partitions. If an application directory partition has replicas on domain controllers in two different domains, the
membership of such domain local groups in ACLs can expand to yield different results, depending on the domain
controller to which a user connects.

GUID names for cross-reference objects

Domains in Active Directory must have NetBIOS names that are unique in the forest so that they are backward compatible
with computers that are running earlier versions of Windows. Domains must also have DNS names that are unique. The
relative distinguished name of the cross-reference object for each domain directory partition is taken from its NetBIOS name,
which guarantees that each cross-reference object is unique within the Partitions container. For example, if a domain has a
NetBIOS name of CONCORP and a fully qualified DNS domain name of concorp.contoso.com, the distinguished name of its
cross-reference object is CN=concorp,CN=partitions,CN=configuration,DC=contoso,DC=com. The domain component (DC) of
the cross-reference object distinguished name is always the forest root domain, which is always the parent of the
configuration directory partition. If there were another domain in the same forest named concorp.avionics.contoso.com, this
domain would necessarily be given a NetBIOS name other than CONCORP (for example, CONCORPAV).
In the case of application directory partitions, there is no associated NetBIOS name, only the DNS name. Given the nature of
DNS hierarchical naming, which allows identical left-most name components, a cross-reference object cannot use the left-
most DNS name component as its relative distinguished name. For this reason, cross-reference objects that reference
application directory partitions use their object GUID as their relative distinguished names.
To associate a cross-reference object with its application directory partition, you can read the nCName attribute of the
cross-reference object, which gives the distinguished name of the directory partition.
Top of page
Data Store Physical Structure
The physical structure of the data store consists of the Active Directory database file (Ntds.dit) and its associated log and
temporary files. The data that is held in the database file includes both static data and dynamic data. The following figure
illustrates the physical structure of the data store.
Data Store Physical Structure
The following table describes the physical components of the data store.
Data Store Physical Structure Components

Component Description

NTDS.DIT The physical database file in which all directory data is stored. This file consists of three internal tables: the
data table, link table, and security descriptor (SD) table.

EDB.LOG The log file into which directory transactions are written before being committed to the database file.

EDB.CHK The file that is used to track the point up to which transactions in the log file have been committed.

RES1.LOG, Files that are used to reserve space for additional log files if EDB.LOG becomes full.
RES2.LOG

Active Directory Database

Active Directory data is stored in the Ntds.dit database file. The Active Directory database (Ntds.dit) contains three internal
tables, the data table, link table, and SD table, which are described in the following sections.
Two copies of Ntds.dit are present in separate default locations on a domain controller, systemroot\NTDS and
systemroot\System32:
systemroot\NTDS\Ntds.dit stores the database that is in use on a domain controller. It contains the values for the domain
•
and a replica of the values for the forest (the Configuration container data).
systemroot\System32\Ntds.dit is the distribution copy of the default directory that is used when you install Active
•
Directory on a server running Windows Server 2003 to create a domain controller. Because this file is available, you can
run the Active Directory Installation Wizard without having to use the server operating system CD.

Data Table
The data table contains all the information in the Active Directory data store: users, groups, application-specific data, and
any other data that is stored in Active Directory after its installation. The data table can be thought of as having rows (each
representing an instance of an object, such as a user) and columns (each representing an attribute in the schema, such as
GivenName). For each attribute in the schema, the table contains a column, called a field. Field sizes can be fixedor
variable. Fixed-size fields contain an integer or long integer as the data type. Variable-size fields typically hold string types,
for example, Unicode strings. The database allocates only as much space as a variable-size field needs: 16 bits for a 1-
character Unicode string, 160 bits for a 10-character Unicode string, and so on.
The database space that is used to store an object depends on the number of attributes for which values are set and the size
of the values. For example, if the administrator creates two user objects (User1 and User2), sets only the minimum
attributes on them, and then later adds a 10-character description to User2, the User2 space is approximately 80 bytes
bigger than the User1 space (20 bytes for the 10 characters, plus metadata on the newly generated attribute).
Database records cannot span database pages; therefore, each object is limited to 8 kilobytes (KB). However, some attribute
values of an object do not count fully against this limit. Long, variable-length values can be stored on a different page than
the object record, leaving behind only a 9-byte reference. In this way, an object and all its attribute values can be much
larger than 8 KB.

Link Table
The link table contains data that represents linked attributes, which contain values that refer to other objects in
Active Directory. An example is the MemberOf attribute on a user object, which contains values that reference groups to
which the user belongs. The link table is much smaller than the data table.

SD Table
The SD Table contains data that represents inherited security descriptors for each object. With the introduction of the SD
table in Windows Server 2003, inherited security descriptors no longer have to be duplicated on each object that inherits
security descriptors. Instead, inherited security descriptors are stored in the SD table and linked to the appropriate objects.

Log Files
The Active Directory data store includes the log files that are described in the following table. For information about how
these log files are used, see “Logging Transactions to Enable Log-based Recovery” later in this section.
Log Files

File Description

Edb.log This file stores directory transactions before they are written to the Ntds.dit directory
database file. This file has a fixed size of 10 megabytes (MB).

Edb00001.log, Edb00002.log, Active Directory creates additional log files as necessary as existing log files fill up. Each
Edb00003.log, and so on log file has a fixed size of 10 MB.

Edb.chk This file keeps track of the point up to which transactions in the log file have been
committed.

Minimum Space Requirements

The minimum space requirements for the directory database and log files — and the requirements for which monitoring is
essential — are free disk space on the partition or partitions that store the directory database and logs, as follows:
Ntds.dit partition and log file partition: On either partition, free disk space must not fall below the greater of 500 MB or
•
20 percent of the combined Ntds.dit and log file sizes.
Ntds.dit and log files on the same volume: Free disk space must not fall below the greater of 1 gigabyte (GB) or
•
20 percent of the combined Ntds.dit and log file sizes.

Objects and Capacity

There are no practical limits to the number of objects that can be stored in Active Directory. The Active Directory database
has been tested for up to 60 million objects. Performance tests show logon performance for a single LDAP client to be the
same with 10,000 objects, 100,000 objects, and 1 million objects; that is, the directory service does not slow measurably
when the size of the database increases.
Note
In a mixed environment in which backup domain controllers (BDCs) are running Windows NT 4.0, the recommended limit
•
for the number of security principal objects per domain is 40,000 (the sum of users, groups, and computers). This limit is
based on the Windows NT 4.0 SAM database storage capacity.

Maximum Database Record Size

The maximum size of a database record is 8110 bytes, based on an 8-kilobyte (KB) page size. Because of variable overhead
requirements and the variable number of attributes that an object might have, it is impossible to provide a precise limit for
the maximum number of multivalues that an object can store in its attributes. For all practical purposes, the size of objects is
not significant in Windows Server 2003 Active Directory and is not significant in Windows 2000 if you use the recommended
guidelines described in "Static Data" later in this chapter.
The only value that can actually be computed is the maximum number of values in a nonlinked, multivalued attribute when
the object has only one attribute (which is impossible). In Windows 2000 Active Directory, this number is computed at
1575 values. From this value, taking various overhead estimates into account and generalizing about the other values that
the object might store, the practical limit for number of multivalues stored by an object is estimated at 800 nonlinked values
per object across all attributes.
Note
Attributes that represent links do not count in this value. For example, the members linked, multivalued attribute of a group
object can store many thousands of values because the values are links only.
The practical limit of 800 nonlinked values per object is increased in Windows Server 2003. When the forest has a functional
level of Windows Server 2003 or Windows Server 2003 interim, for a theoretical record that has only one attribute with the
minimum of overhead, the maximum number of multivalues possible in one record is computed at 3937. Using similar
estimates for overhead, a practical limit for nonlinked multivalues in one record is approximately 1200. These numbers are
provided only to point out that the maximum size of an object is somewhat larger in Windows Server 2003.

Active Directory Data

The key characteristics of data that is stored by any directory service are size and latency. A directory service should store
objects that are not so large that they hamper replication. Therefore, large unstructured data sets are not appropriate for
storage in Active Directory. Domain data and configuration data are typically static in nature, having a useful lifetime at least
as long as a single period of replication latency.
In a Windows 2000 Server forest, Active Directory does not support storage of nonstatic (dynamic or volatile) data. In a
Windows Server 2003 forest, however, Active Directory can store nonstatic data in application directory partitions, which can
be configured for limited replication or used as real-time data stores for data that is too volatile for replication.

Static Data
Active Directory is appropriate for the storage of static data that has the following characteristics:
The data is globally useful information in the domain that needs to be replicated to each Active Directory domain
•
controller.
• The data has well-defined object attributes and semantics.
The data has a useful life that is at least two times the maximum replication latency for the forest, including replication of
•
data that is marked to replicate to the global catalog. In general, if data can become outdated before the completion of a
replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be able to tolerate the
inability to update data for at least as long as it takes for the data to be replicated throughout the domain.
The data-per-attribute value is not so large that it affects performance. Most attribute values are replicated as a single
•
block of data; therefore, an attribute that is x MB in size requires an equivalent amount of buffer space in the sending
domain controller and in the receiving domain controllers. If the amount of required buffer space is large, the performance
of the domain controllers can be affected adversely.
Attributes can have large values when the attribute is multivalued and linked. For these attributes, only the values that
change are replicated, not the entire attribute.

Dynamic Data
An object that has a TTL value is considered to be dynamic data. Windows Server 2003 introduces a new auxiliary class,
dynamicObject, that can be attached to object instances for the storage of TTL values. For an object containing a TTL
value, when the time that is specified by the TTL value is reached, the object is automatically removed from Active Directory
by garbage collection. Dynamic data typically changes faster than the replication latency that is required for propagating the
change to all replicas of the data.
The following characteristics apply to dynamic data:

• A dynamic object that is deleted as a result of expiration of its TTL does not leave a tombstone.
Dynamic objects are treated in the same manner as nondynamic objects during search, compare, add, delete, and modify
•
(including rename) operations.
A nondynamic object, after it is created, cannot be changed to a dynamic object. Likewise, a dynamic object, after it is
•
created, cannot be changed to a nondynamic object.
• A nondynamic object cannot be added in a subordinate position to a dynamic object.
 Dynamic objects with TTL values are supported in the following directory partitions:
•
• Domain directory partitions at the Windows Server 2003 forest functional level
Application directory partitions on a Windows Server 2003–based domain controller, irrespective of domain or forest
•
functional level
• Dynamic objects are not supported in configuration directory partitions or schema directory partitions.

TTL for dynamic objects

The TTL for a dynamic object is set when the object is created, and it is automatically decremented thereafter. When its TTL
expires, the dynamic object disappears without leaving a tombstone. However, a client application can programmatically
cause a dynamic object to remain longer than its current remaining lifetime by refreshing (modifying) its TTL value, as stored
in the entryTTL attribute on the object.
The Directory Service object (nTDSService) in the Configuration container (CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC= forestRootDomain) stores the default and minimum dynamic object TTL values for
the forest in the multivalue attribute msDS-Other-Settings.
The default values for the two configurable TTL parameters are as follows:

• Default TTL value = 86400 seconds (1 day)

Minimum TTL value = 900 seconds
•
(15 minutes)
The default TTL value is assigned to a newly created dynamic object if a TTL is not explicitly specified by the application that
creates the object. The minimum TTL overrides any client-specified TTL value that is lower than the configured minimum. No
configurable maximum TTL value needs to be provided, because a maximum is imposed by the attributeSchema object.
The syntax for the two configurable TTL parameters is as follows, where NNNN is expressed in seconds:
DynamicObjectDefaultTTLSeconds=NNNN

DynamicObjectMinTTLSeconds=NNNN

By configuring these values, you can set TTL values that enforce a low level of refresh traffic or, conversely, provide a highly
up-to-date directory.
Top of page
Data Store Processes and Interactions
The Active Directory data store performs a number of processes and interactions that are important to the functioning of
Active Directory. The following sections describe these processes and interactions.
These descriptions make the following assumptions regarding the environment in which the Active Directory data store is
running:
The disk volume on which the directory database is stored contains ample free
•
space.
• Network connectivity on the domain controller is functioning properly.

Database Operations
Data operations (such add, modify, and delete) are committed to the Active Directory database as transactions, which are
the units of work that are performed by a database. Transactions are atomic; that is, they are either completed in full or not
applied at all. If for any reason an error occurs and a transaction is unable to complete all of its steps, the system is returned
to the state that existed before the transaction began. An example of an atomic transaction is an account transfer
transaction in which money is removed from account A and placed into account B. If the system fails after it removes the
money from account A and before it places the money into account B, the transaction processing system puts the money
back into account A and returns the system to its original state; that is, the transaction processing system rolls back the
transaction.
In Active Directory, operations on a single object cannot be applied across multiple objects. Active Directory writes a
transaction synchronously to the transaction log file and then to the database. First, a change is made to an in-memory copy
of the object. Then, the change is written to the log file, which ensures that the change takes effect, even if the database
shuts down after that point. The database engine continually updates the database file with recent changes. The database
update works from memory — not from the log files — and it keeps pace with the updates, rather than waiting for the server
to be available. This method of performing updates is referred to as “advancing the checkpoint,” where the checkpoint is the
point in time at which all changes that have been made so far have been fully written to the database.
LDAP Functional Model
Database operations in Active Directory are based on the LDAP functional model. The LDAP functional model includes support
for common database operations, such as connecting to a directory database, searching for data, and modifying data. An
LDAP client connects to Active Directory and requests information or performs an operation. Active Directory performs the
operation or provides the information, or it refers the client to another LDAP server that might be able to do so.
Nine operations form the LDAP functional model. These operations are grouped into three areas:
Authentication. Enables the client to prove its identity to the DSA:
•
• Bind

• Unbind

• Abandon
Interrogation. Enables the client to interrogate the directory and retrieve
•
information:

• Search

• Compare
Update. Enables the client to update information in the directory tree:
•
• Add

• Delete

• Modify
Modify relative distinguished
•
name
A typical LDAP client application interacts with Active Directory through the operations that are described in the following
sections.
For more information about LDAP, see “Lightweight Directory Access Protocol (LDAP)” in the Microsoft Platform SDK on
MSDN.

Establishing a connection
When an LDAP client connects to Active Directory, an LDAP session is established. Options are available to affect the way in
which the connection is established. These options include setting a time-out value, connecting to a secure LDAP server, and
verifying that a server is available.
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope. LDAPMessageis
encapsulated in the Protocol Data Unit (PDU) format. LDAPMessage consists of protocol operations, such as LDAP Bind
Request, LDAP Bind Response, LDAP Search Request, and LDAP Search Response operations.
LDAPMessage PDUs are mapped directly to the TCP data stream. Active Directory clients use the following LDAP ports:
Port 389. In accordance with RFC 2251, Active Directory uses port 389 as the default port for domain controller
•
communications.
• Port 636. Active Directory supports port 636 for LDAP Secure Sockets Layer (SSL) communications.
Port 3268 and port 3269. The global catalog monitors port 3268 for LDAP communications and port 3269 for LDAP SSL
•
communications.

Modifying a directory object

The LDAP API contains functions for adding and deleting directory objects and for comparing and modifying attribute values
in existing objects. LDAP v3 provides extensions to add, delete, and modify functions that enable the use of controls to
perform these operations. Controls are described in RFC 2251 as a mechanism to extend the functionality of LDAP. Windows
Server 2003 supports several extension controls that go beyond the controls that are identified by LDAP v3.

Searching the directory

Searching is the most common directory activity, and the LDAP APIs provide a variety of search criteria and result-retrieval
methods. The client searches the LDAP server by passing it a set of parameters that describe the information of interest.
These parameters describe where and how to search, and they define the search criteria that a client needs. The client uses
a search filter to describe the objects that it wants. Search filters are defined in RFC 2254. Extensions to the base LDAP API,
in the form of LDAP v3 controls, provide the ability to sort results and set various limits on the search operation. Search
results can be processed by paging and by sorting. Paging and sorting are supported in Windows Server 2003 and
Windows 2000 Server as new LDAP v3 control extensions for processing search results on the server.

Closing the connection (unbinding)

Unbinding closes the connection between the directory client and the DSA and disposes of the session handle. Applications
call the unbind function when an LDAP client finishes communicating with a server. There is no server response to an unbind
request.

Logging Transactions to Enable Log-based Recovery

To maximize system efficiency and ensure data integrity, Active Directory uses “write ahead” logging. With “write ahead”
logging, transactions are written as quickly as possible to a transaction log file, and they are then written to the Ntds.dit
database file as the system has time or at system shutdown.
The log file that is used by Active Directory to record transactions is called Edb.log, which has a fixed size of 10 MB. When
this log file becomes full, Active Directory automatically creates a new log file, for example, Edb00001.log, which also has a
fixed size of 10 MB. Active Directory continues to create additional log files as they become necessary. Through circular
logging, the oldest log file is purged when all transactions in that log have been written to the Ntds.dit database. In addition
to the active log files, two reserve log files exist, called Res1.log and Res2.log, ,also with a fixed size of 10 MB. These files
reserve the last 20 MB of disk space on the drive to provide room for a graceful shutdown if all other disk space is consumed.
Active Directory also maintains a checkpoint file (Edb.chk) that records which transactions in the log have been committed to
the database. In circular logging, log files are deleted when the checkpoint advances past the last transaction that is included
in that log file. The checkpoint cannot be advanced past the beginning of any transaction that is still open.
If the computer stops responding, the ESE can detect an improper shutdown by checking the last log recorded. If the last
record is not a “shutdown” record, the ESE reprocesses the logs from the checkpoint that is stored in Edb.chk. This event
occurs at the first reboot after the system is shut down improperly. If the checkpoint file is missing for any reason, every
transaction within the log file is reprocessed.
The number of log files that exist at any point in time is related to the number and size of transactions that are running in
the database. If a system is idle, you can expect to see one log file. If a domain controller is making large changes (for
example, replicating a 5,000-member group), you can expect to see several log files. If you just edited the schema to define
an index on an attribute that has many large data values, you might see hundreds of log files. (The checkpoint cannot be
advanced until the index creation is completed.)

Growth and Space Management

The directory database is a self-maintained system in which growth is managed by periodically compacting data and
reorganizing free space into contiguous pages. Other than regular backup, the directory database requires no maintenance
during ordinary operation. The only requirement is adequate space to accommodate normal growth.
The directory database grows when more data is added to it than free space is available to accommodate the new values.
Free space, also called “white space,” is managed automatically by the directory database. Conditions under which free space
is made available to the database can affect database size, sometimes in ways that are not expected. For this reason, an
understanding of how free space is managed can help provide correct interpretation of changes in the size of the directory
database file. The following sections describe space allocation and free space reclamation.

Space Allocation
Space is allocated hierarchically in the directory database, with the database at the top of the hierarchy. Object tables are
children of the database. Each table has a child long-value table, and each table can have child indexes. The long-value table
stores values that are too large for the main object table. Security descriptors are examples of values that are often large
enough to require storage in the long-value table.
As objects are deleted and values are replaced with smaller values, free space is returned to the database. However, there is
no optimum or target amount of white space to be maintained. The amount of unused space in the directory database is of
concern only when monitoring indicates that free disk space is becoming limited. You can configure a domain controller to log
an event that reports the amount of unused space in the directory database that can be reclaimed by offline
defragmentation.
Requesting space
The database can use free space if the space is available to the table or index that needs it and if the space occurs in blocks
that are large enough to accommodate the transaction. When an index or table requires additional space, it can request
space only from its parent. For example, the available space in an index cannot be used by another index. If the parent table
requires space, it must request space from the database. If space is not available at the database level to complete the
request, the database increases its size to accommodate the transaction.

Space consumption by indexes

The estimated space that is required for adding an index to an attribute is rarely greater than 1 percent of database size.
However, Tuple indexes, which index an attribute in a way that allows users to search the attribute by using partial text
strings, can be quite large. To provide partial text string searching, a Tuple index includes one entry for each substring of a
Text or Long Text column, with a minimum and maximum length allowed for the substrings that are indexed. Although
Tuple indexes can dramatically speed queries of the form “find all records that contain string value,” they can potentially
increase database size by as much as 20 percent, and they should be used with caution.

Storing data
Objects are stored in records that are written to 8-KB data pages. The maximum record size is 8110 bytes, with the
exception of long-value columns, which can be up to 2 GB. As values are deleted, space that is freed by transactions is
returned to the table that owns the space. Free space is returned gradually in small segments, and it is periodically
reorganized into contiguous pages through an automatic process called online defragmentation.
Data pages are filled with records in an ordered fashion. For example, all records beginning with A must be stored in the
page that is designated as storing the values that range from A to some other value. For example, given pages A-E and F-J,
if a value corresponds to the A-E page and that page is full, the value cannot be stored in the F-J page, even if space is
available. Instead, one or more new pages are added. When a table grows, it grows in increments equal to one-fourth its
initially allocated size.
In this way, Active Directory data storage optimizes lookup speed as opposed to storage space. However, because of the
hierarchical means of allocating free space and the order that is required for filling data pages, free space that is present in
the database is not always available for use.

Free Space Reclamation

The version store is the area of the database that manages version control. When a transaction is committed to the
database, a cleanup process returns space that is freed by modify and delete transactions to the database. For each modify
or delete operation, the existing version of the record is written to the version store so that the database maintains a copy of
the old version until the new version is written to the database. After the transaction is committed to the database, any
space that is freed from deleted records and long values is returned to the table or index that owns the space. Until the
change is committed to the database, requests for the object continue to access the old version. If the transaction is rolled
back, the version store record is used to undo the transaction.
The version store has a size limit that is the lesser of the following: one-fourth of total random access memory (RAM) or
100 MB.
Because most domain controllers have more than 400 MB of RAM, the most common version store size is the maximum size
of 100 MB. If too many large changes or deletions occur simultaneously, it is possible for the version store to run out of
processing space. In this event, cleanup of free space is suspended temporarily. On domain controllers running
Windows 2000 Server, the most common cause of version store overload is large-scale bulk deletions.

Bulk deletions and database growth in Windows 2000

Delete operations are the most CPU-intensive operations that the version store processes. On domain controllers running
Windows 2000 Server, bulk deletions, such as the deletion of an entire tree of objects at one time, can cause a temporary
condition in which free space cannot be returned to the database in a timely fashion because the cleanup process cannot
keep up with the deletions. Event ID 602 is logged in the Directory Services event log to indicate this condition.
During the time that pages are being skipped by the cleanup process, free space is not released to the database, and space
is not reclaimed until the next scheduled online defragmentation occurs. In the meantime, processing requirements can
cause the database to grow. In particular, when bulk deletions or other bulk changes coincide with database additions,
significant growth can occur. In addition, space from the deletion of long values is not returned to the database by online
defragmentation. As a result of these conditions, the directory database on domain controllers running Windows 2000 Server
can actually increase in size following a bulk deletion.
On domain controllers running Windows Server 2003, the effects of these conditions are greatly reduced by improvements in
version store cleanup and online defragmentation. However, if event ID 602 is logged in the Directory Services event log,
running online defragmentation manually can alleviate the problem. On domain controllers running Windows 2000 Server,
the only way to prompt online defragmentation is to change the garbage collection interval to the minimum value of one hour
to force garbage collection and online defragmentation to occur as soon as possible.

Improved space processing in Windows Server 2003

Two improvements in the Windows Server 2003 processing of free space eliminate the database growth problems that can
result from large-scale bulk deletions:
The threshold at which the database begins skipping cleanup operations is increased from 5 percent to
•
90 percent.
• Space is reclaimed from long-value deletions.
The threshold of maximum pages that can be processed by the version store is the limiting factor in whether the cleanup
process can keep pace with deletions. The version store cleanup process can take place only as long as the version store has
sufficient space. With a maximum version store size of 100 MB, only 5 MB (5 percent) is available in Windows 2000 Server,
and this low threshold is responsible for early suspension of the cleanup process. The threshold of 90 MB (90 percent) in
Windows Server 2003 eliminates this problem. For this reason, large-scale bulk deletions that can be problematic on domain
controllers running Windows 2000 Server present no significant growth concerns on domain controllers running
Windows Server 2003.
In addition, online defragmentation on domain controllers running Windows Server 2003 returns the space that is freed by
long values to the long-value table, which further optimizes the availability of space in the database.

Bulk Changes and Inheritable Security Descriptors

In addition to bulk deletions, large-scale bulk changes can cause database growth, particularly on domain controllers running
Windows 2000 Server. The most common cause of database growth on domain controllers running Windows 2000 Server is
the propagation of inherited security descriptor changes in a large directory tree.
Every object in Active Directory has a security descriptor attribute that contains the identification and authorization values
that apply to that object. Authorization information takes the form of discretionary access control lists (DACLs) (access
information) and system access control lists (SACLs) (auditing information). Because every object has a security descriptor, a
security descriptor change that affects every object in a large tree (for example, an entire domain) can significantly affect
database size.

How Inheritable Security Descriptors Are Written

The value of the security descriptor attribute changes when a new permission, right, or auditing setting is added or an
existing permission, right, or auditing setting is removed from an object’s DACL or SACL by adding, removing, or modifying
an ACE. When an inheritable ACE is applied to an object in a directory tree, you can specify the type of object that is affected
by the ACE. However, the change is written to every object in the tree, not just to the object type to which the permission,
right, or auditing setting applies. The ACE applies to all objects, but it is effective only on objects whose object type matches
the object GUID that is specified in the ACE.
This system ensures that the appropriate security descriptor can always be inherited from a parent object. For example,
suppose you apply an inheritable ACE at the domain level that applies to all computers. Computers exist in container objects,
to which the ACE does not directly apply. However, when you create a computer object in the container, the computer object
receives its inherited security descriptor from its parent container. Every object that is within the scope of the inheritance
receives the update to the security descriptor.

Security Descriptors in Windows 2000 Server

On domain controllers running Windows 2000 Server, the full security descriptor value is stored for every object. The
average size of a security descriptor is 5 KB, and as a result security descriptors can account for 40 percent or more of
database size. On domain controllers running Windows 2000 Server, an ACL change that is inherited by a large directory tree
(for example, a domain) that contains hundreds of thousands or millions of objects can cause significant database growth.
For example, suppose you add 30 ACEs to an inheritable SACL or DACL on the domain object of a domain that has 1,000,000
objects. At an estimated 52 bytes per ACE, each object grows by approximately 1.5 KB. The propagation of this change to
1 million objects results in database growth of 1.4 GB. In the worst-case scenario, the database grows beyond its storage
limits, and Active Directory cannot function.
You can use Active Directory administrative tools to manage security settings on Active Directory objects to a high degree of
specificity. Significant and unexpected changes to security descriptors can occur during the management of access control
and auditing if an administrator does not understand the effects of the changes. The UI provides the ability to select general
ACE categories that have prepopulated permissions, but the UI also provides the ability to modify the properties of a general
ACE. The effect of editing an existing general ACE on a DACL or SACL by removing one of the properties is the replacement
of a single ACE with multiple ACEs, one for each of the permissions that is selected in the modified ACE. On domain
controllers running Windows 2000 Server, such a change can cause significant database growth if the modified ACE is
inherited to a large tree of objects. For example, if directory services access auditing is enabled and an administrator edits
the access to specify only a subset of the activity and objects to be audited, the result is propagation of a separate ACE for
each selection to every object in the tree. Given the default settings for the Everyone group in Windows 2000 Server, such a
change can result in significant database growth.
Default settings in Windows Server 2003 and the storage of only unique security descriptors greatly decrease the likelihood
that such a change can cause unmanageable growth.

Single-Instance Security Descriptors in Windows Server 2003

On domain controllers running Windows Server 2003, the potential for database growth as a result of the volume of changes
that might be caused by security descriptor inheritance is mitigated by a new method of storing single instances of unique
security descriptors.
On domain controllers running Windows Server 2003, a unique security descriptor is stored only once rather than being
stored for every object that inherits it. For every object that inherits the security descriptor or otherwise stores an identical
security descriptor, only a pointer is stored. This change eliminates data redundancy and the database growth that can result
from changes to inheritable ACEs.
The object itself stores an 8-byte pointer to the appropriate unique security descriptor. Unique security descriptors are stored
in memory in a relatively small table. In addition, the information that is required to map these pointers to the respective
security descriptor is cached on domain controllers. By using this cached information and the in-memory table of unique
security descriptors, domain controllers can match pointers to security descriptors without having to access the database
itself. Therefore, checks to establish whether a new security descriptor matches an existing one have no significant impact on
domain controller performance.
Note
When you upgrade a domain controller from Windows 2000 Server to Windows Server 2003, the conversion of duplicate
•
security descriptors to pointers can result in +40 percent of the database size being converted to unused space.
Performing offline defragmentation after the upgrade decreases the database size by removing that unused space.

Effect of Object Ownership on Unique Security Descriptors

Having different owners causes objects that would otherwise have the same security descriptor to require several unique
security descriptors. For example, if a member of the Domain Admins group creates a container object and sets permissions
on the container that are inherited by all child objects, all child objects have the same security descriptor. In this case, only
one security descriptor is actually stored in Active Directory; the rest of the objects simply reference that unique security
descriptor. However, if objects that are created in the parent container are created by individuals who are not members of
the Domain Admins group, those objects have security descriptors that are different from the security descriptors of the
objects that are created by members of the Domain Admins group.
Despite the fact that having different object owners requires unique security descriptors, most Active Directory databases
contain a relatively small number of user objects in comparison to the number of nonuser objects. In addition, most objects
are created by the system and not by individual users. Because duplication of security descriptors far outweighs the potential
for different object owners, the positive effect of single-instance security descriptors is not usually lessened to a noticeable
degree by multiple object owners.
Storage and Removal of Object Deletions
When data is deleted from Active Directory, the data cannot simply disappear from the directory because the deletion must
be replicated. Therefore, instead of deleting an object physically from the database, the directory service removes most of
the attributes and then tags the object as a tombstone by setting the isDeleted attribute value to TRUE, which means that
the object has been logically deleted from the directory but not yet completely removed. Tombstones are replicated to
communicate object deletions. The isDeleted attribute value alerts replication partners that the object has been deleted.
Objects that are identified as tombstones are moved to the hidden Deleted Objects container of their respective directory
partition. Tombstones remain in the directory for a default period of 60 days, which is referred to as the tombstone lifetime.

Garbage Collection: Permanent Removal of Expired Tombstones

Garbage collection is a housekeeping process that runs on every domain controller to permanently remove expired
tombstones from the directory database. Although they represent deleted objects, tombstones take up space in every
directory partition replica. Eventually, the tombstones themselves must be deleted to keep the directory database from
growing without limit. At regular intervals, objects that are no longer needed by the directory service are deleted as
“garbage.”
The garbage collection process:

• Deletes tombstones.
Defragments the database file to compact data and optimize free space (triggers online
•
defragmentation).
Garbage collection runs independently on each domain controller. When the garbage collection process occurs, the process
finds the set of tombstones whose originating deletion occurred more than a tombstone lifetime ago, and then it deletes each
tombstone in that set.
Two attributes of the Directory Service object (nTDSService) in the configuration container (CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration, DC=forestRootDomain) control how garbage collection runs and
what it removes, as follows:
The tombstone lifetime determines the amount of time that a deleted object lives as a tombstone in the directory before
•
being collected as garbage. This amount of time is set in the tombstoneLifetime attribute. The minimum setting is
2 days. The default setting for this attribute varies according to operating system and forest creation or upgrade, as
follows:
Forests that were created on a domain controller running Windows Server 2003 with no service pack installed or any
•
version of Windows 2000 Server: 60 days.
Forests that were upgraded from Windows Server 2003 with no service pack installed or any version of
•
Windows 2000 Server: 60 days.
• Forests that were created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1): 180 days.
Note
You cannot purge tombstones before the expiration of the tombstone
•
lifetime.
The garbage collection interval determines how often a domain controller examines its database for expired tombstones
•
that can be collected. This interval is set in the garbageCollPeriod attribute. The default setting is 12 hours, and the
minimum setting is 1 hour.
Note
The default value for each of these two attributes applies if the attribute is not set (which is the initial state of the
•
system). The minimum value applies if the attribute is set to a value that is below the minimum (that is, if the minimum
is not declared in the schema).
The maximum garbage collection interval is one-third of the tombstone lifetime (in hours). For example, if you set
tombstoneLifetime to 30 days and garbageCollPeriod to 300 hours, the actual garbage collection period is only 10 days
or 240 hours.

Tombstone Lifetime and Active Directory Backup and Restore

Active Directory does not allow a restore from a directory backup that is older than the tombstone lifetime. A restore from
backup creates a directory partition replica that has not performed replication since the time of backup (or earlier). If the
backup is taken more than a tombstone lifetime before the restore, objects that are deleted in the meantime have no
tombstones; therefore, a new directory partition replica that is created by the restore operation never receives these
deletions. For this reason, a restore procedure will not restore a backup that is taken more than one tombstone lifetime
before the time of the restore. Therefore, it is a recommended best practice to back up Active Directory at least twice during
a tombstone lifetime. On domain controllers running Windows Server 2003 with SP1, event ID 2089 in the Directory Service
event log provides notification when any directory partition, including application directory partitions and Active Directory
Application Mode (ADAM) partitions, has not been backed up since the beginning of a specified time period. By default, this
period is half the tombstone lifetime interval, as defined in the registry entry Backup latency interval (days) in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
It is likewise important that the tombstone lifetime be substantially longer than the expected replication latency. The default
setting of 60 days or 180 days for the tombstone lifetime is generous enough to accommodate unforeseen circumstances.
However, monitoring domain controller operation is essential for ensuring that a domain controller does not remain offline
without detection.
Because the expiration of a tombstone lifetime is based on the time when an object is deleted logically — rather than the
time when a particular server receives that tombstone through replication — an object’s tombstone is collected as garbage
on all servers at approximately the same time. If the tombstone has not yet replicated to a particular server, that server
never records the deletion. A domain controller that becomes outdated by being disconnected from the replication topology
for longer than a tombstone lifetime cannot be restored from backup. However, an object that remains on an outdated
domain controller is retained if the domain controller is reconnected to the replication topology. An object that remains after
its tombstone is deleted is called a lingering object. Such objects create inconsistency in Active Directory and should be
removed. For information about removing lingering objects, see "Fixing Replication Lingering Object Problems (Event IDs
1388, 1988, 2042)" in "Troubleshooting Active Directory Replication Problems" in the Windows Server 2003 Operations Guide
at http://go.microsoft.com/fwlink/?LinkId=44131.

Garbage Collection Scheduling Enhancements

The process for completing garbage collection has changed in Windows Server 2003 to improve storage conditions in the
directory database. Garbage collection removes a maximum of 5,000 objects per pass to avoid indefinitely delaying other
directory service tasks. However, the rate at which remaining tombstones are deleted when more than 5,000 tombstones
have expired has increased from Windows 2000 Server to Windows Server 2003, as follows:
Windows 2000 Server: If collection stops because of the 5,000-object limit (rather than by running out of objects to
•
collect), the next garbage collection pass is scheduled for half the normal garbage collection interval (by default, every
6 hours instead of 12 hours). Garbage collection continues running at this accelerated pace until all objects have been
collected.
Windows Server 2003: Rather than waiting a set time to remove a subsequent set of 5,000 tombstones, a domain
•
controller continues deleting tombstones according to CPU availability. If no other process is using the CPU, garbage
collection proceeds. Removing tombstones in this way keeps the database size from increasing inordinately as a result of
the inability of garbage collection to fully complete removal of all tombstones during a garbage collection interval.

Garbage Collection and Linked Attributes

When an object that has a linked attribute is deleted, although the object itself becomes a tombstone (for example, when a
user object is deleted), the referent object (for example, a group object to which the user belonged) does not reference the
tombstone of the deleted object. Rather, the group-user link value is simply deleted from the database, and the group object
shows no evidence of the former user’s membership.
However, when an object to which a link refers is removed as a referent (for example, when a user is removed from a
group), the user value is treated differently by Active Directory in Windows 2000 Server and in Windows Server 2003. In
Windows 2000 Server, the entire group member attribute is replicated. In Windows Server 2003, the link value for the
removed user is marked “absent” and then replicated, much like a tombstone.

Reanimating Tombstones — Restoring Individual Objects Online

The Windows Server 2003 directory database supports an LDAP API that reanimates the tombstone of a single object
(undeletes the object) to avoid the necessity for an offline restore process in the event that an object is deleted
unintentionally. This API is available for creating applications to restore the attributes that are preserved on tombstones,
which include the object SID, GUID, and security descriptor, as well as any indexed attributes.
Note
When the deletion is performed on a domain controller that is running Windows Server 2003 with SP1, the sIDHistory
attribute is also retained.
Only attributes that are retained on the tombstone are restored; all other data must be recreated. Therefore, to restore an
entire deleted container or a set of multiple objects, authoritative restore is still the best option.

Stale Account Detection

Stale account detection is required so that unused computer and user accounts can be removed from Active Directory. On
domain controllers running Windows Server 2003 and Windows Server 2003 with SP1, these accounts can be identified by
the value in the lastLogonTimeStamp attribute of user and computer objects. This attribute identifies the last time that a
user or computer successfully logged on to a domain. The attribute value is replicated to all domain controllers in the
domain. lastLogonTimeStamp is new in Windows Server 2003, and its use is enhanced in Windows Server 2003 with SP1.

Scenarios that generate stale accounts

The following common scenarios result in the proliferation of computer and user accounts that are often abandoned by the
users who create the accounts:
Delegated computer account creation, which is common in corporate environments, provides the freedom to create
•
multiple accounts but no requirement for deleting them.
• Web applications allow external partners to create and manage user accounts that are provided by the host company.

• Employees leave the company.

Detection of successful password verification

In earlier versions of Windows, the pwdLstSet attribute was used to identify stale accounts. However, many conditions
interfere with the accuracy of this method, such as users who are on sabbatical or otherwise temporarily not using an
account. In addition, password time limits can vary throughout an organization. The most efficient way to identify an account
that is stale is by evaluating the last time that the user successfully logged on to the domain, rather than the last time the
password was reset.
The introduction of the lastLogonTimeStamp attribute in Windows Server 2003 provides the ability to mark an account
each time that the system is asked to validate the account password (that is, at logon) for NTLM and Kerberos
authentication. These two security protocols update the lastLogonTimeStamp attribute during successful authentication.

Implementation in the domain

Updates to lastLogonTimeStamp are replicated in the domain directory partition. Therefore, the value of this attribute can
be checked on any domain controller in the domain. To minimize the effect of domain-wide replication every time that a user
or computer logs on, lastLogonTimeStamp is updated only periodically. The period of update is configurable, as follows:

• Object: DC=DomainName

• Attribute: msDS-LogonTimeSyncInterval

• Default value: 14 days

Because the lastLogonTimeStamp attribute is available only when the Windows Server 2003 schema is in effect on all
domain controllers in the domain, the feature is activated when the domain functional level is raised to
Windows Server 2003. After the domain functional level increase, the first time that a successful logon occurs, the
lastLogonTimeStamp attribute is activated on the user or computer object. This method of activation can result in
loopholes for certain accounts, as follows:
Accounts that are created before the domain functional level increase but that are not used
•
subsequently
• Accounts that are created after the domain functional level increase but that are not used
In these cases, lastLogonTimeStamp is not present on the account object. To identify these accounts, you can query for
user and computer objects that have no lastLogonTimeStamp attribute and that have a value in the whenCreated
attribute that is earlier than or equal to a specified date.
For example, suppose a user account is created on 1/1/2005. The user leaves the company on 5/1/2005. The domain
functional level is raised on 6/1/2005. On 9/1/2005, you query for accounts that do not have the lastLogonTimeStamp
attribute. The query returns the account of the user who left the company before the raising of the functional level. However,
you need to know if the account was created recently and has not yet been used or if the account was created before the
functional level increase and is legitimately out of use. To answer this question, you query for accounts that do not have the
lastLogonTimeStamp and that have a whenCreated value of 8/15/2005 or earlier. You select this date on the assumption
that any account that was created within the last two weeks will have been used and any account that was created between
June 1 and August 15 will certainly have been used. Accounts that are returned by the query are therefore legitimately out of
use and can be deleted.

Randomization mechanism for initial use of lastLogonTimeStamp

To avoid network overloads due to thousands of concurrent lastLogonTimeStamp updates when the domain functional
level is raised, a five-day window is used to calculate whether the lastLogonTimeStamp value should be updated. The
following randomization mechanism is applied to control updates after the domain functional level is raised:
1. At the time that the functional level is raised, the default value of 14 days for msDS-LogonTimeSyncInterval is used,
regardless of whether a different value is set in the attribute.
2. The value in lastLogonTimeStamp is used to determine the number of days since the last valid logon of the account.
3. A random percentage of the value 5 is taken and then subtracted from the value in msDS-LogonTimeSyncInterval.
4. If the result is greater than or equal to the value in lastLogonTimeStamp, the value in lastLogonTimeStamp is
updated.
For example, suppose that the value in lastLogonTimeStamp indicates 12 days since the last successful logon. Suppose
also that the random percentage is 80 percent of 5 = 4. With the default value of 14 days in effect for msDS-
LogonTimeSyncInterval, the calculation is 14 - 4 = 10. Because 12 > 10, lastLogonTimeStamp is updated. In this
example, in all cases where the value is less than 10, lastLogonTimeStamp is not updated until the first successful logon
that occurs after the msDS-LogonTimeSyncInterval value is reached.
Note
If the value in msDS-LogonTimeSyncInterval is set to 0, the stale account detection feature is disabled and
lastLogonTimeStamp is not updated.

Security protocols that update lastLogonTimeStamp in Windows Server 2003

In the initial implementation of lastLogonTimeStamp in Windows Server 2003, lastLogonTimeStamp is updated by the
following authentication protocols:

• NTLM

• Kerberos
Security protocols notify the directory database of a successful logon so that the account can be marked appropriately in the
lastLogon and lastLogonTimeStamp attributes. Therefore, to use stale account detection effectively, it is important that
administrators are aware of the security protocols that are in use in their environments.
For example, in Windows Server 2003 environments, the following security protocols request that the system validate a user
password:

• Secure channel setup (computer accounts only)

• NTLM authentication (both interactive and network)

• Kerberos authentication

• Digest authentication

• Third-party Security Support Provider Interfaces (SSPIs) when using the LSA APIs
The following security protocols can reference an account for a security operation:

• Schannel, when mapped to an account

• Kerberos Service-for-User (S4U) logons

• AuthZ APIs in non-S4U mode

The obvious problem is that some accounts might be authenticated without updating the lastLogonTimeStamp, and if this
detection method is relied on for stale account cleanup, accounts might be deleted that are still in use.
For example, the following issues occur in Windows Server 2003 implementations:
The NTLM authentication protocol does not update the lastLogonTimeStamp attribute for all network logons. NTLM is
•
therefore not reliable for stale account detection.
The Kerberos S4U authentication protocol, which is used for Web single sign on (SSO) provisioning, does not update
•
lastLogonTimeStamp. Specifically, when extranet users log on to servers running Microsoft Internet Information
 Services (IIS), Active Directory user accounts are mapped to certificates that are trusted by the IIS server. These
certificates are distributed to the client computer so that users do not have to specify credentials. (That is, they are not
directly authenticated by a security protocol.)

lastLogonTimeStamp improvements in Windows Server 2003 SP1

Windows Server 2003 SP1 corrects the problems of some protocols not updating lastLogonTimeStamp, as follows:

• The inconsistency of NTLM updates of lastLogonTimeStamp is corrected.

Updates to the Key Distribution Center (KDC) ensure that lastLogonTimeStamp is updated in Active Directory when a
•
user logs on to a protected IIS Web site.

Scripting stale account detection

You can implement a scripting solution for managing stale account detection and cleanup. For more information about
lastLogonTimeStamp and instructions for creating scripts, see "Dandelions, VCR Clocks, and Last Logon Times: These are
a Few of Our Least Favorite Things" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=47965.

Database Defragmentation
As described earlier in this section, the database system uses the quickest way to fill database pages. Although this system is
efficient in searching and updating the database quickly, it does not make the most efficient use of space in the database. As
write operations occur and data pages fill, a certain amount of space often remains in a page that cannot be used by other
transactions because the space is not large enough. In addition, space that is freed by version store cleanup is returned to
the owning indexes or tables in noncontiguous chunks. Therefore, free space that exists in the database is not always
available for use because it is fragmented.
Defragmentation rearranges how the data is stored in the database, compressing the data and making free space available in
contiguous pages. Free space is managed automatically during database defragmentation.
Database defragmentation can take place online (while the computer is running as a domain controller) or offline (while the
computer is running in Directory Services Restore Mode). Defragmentation has different effects on database size, depending
on whether defragmentation is run while the domain controller is online or offline:
Online defragmentation: Occurs automatically by default. Online defragmentation compacts data and optimizes free space
•
for database use, thereby maintaining the file size of the database.
Offline defragmentation: Occurs only manually in Directory Services Restore Mode. Offline defragmentation compacts data
•
and returns free space to the file system, thereby decreasing the file size of the database.

Online Defragmentation
During online defragmentation, space in partially filled data pages is reorganized to consolidate it into full 8-KB pages. In
addition, any pages that have been skipped by version store cleanup are reclaimed for use by the database. Online
defragmentation returns a freed page directly to the part of the tree (database, object table, index, or long-value table) that
owns the page that is being freed. When a sufficient number of contiguous free pages (approximately 16) exist in a given
child tree, the space is released to the parent tree.
Note
On domain controllers running Windows 2000 Server, online defragmentation does not reclaim free space that is deleted
•
from long-value tables.

Automatic online defragmentation

Both Windows 2000 Server–based and Windows Server 2003–based domain controllers perform online defragmentation
automatically. The ESE invokes online defragmentation after each garbage collection, which occurs every 12 hours by
default.

Manual online defragmentation

On domain controllers running Windows Server 2003, you can prompt online defragmentation to run manually. Although
online defragmentation occurs automatically following garbage collection and the garbage collection interval is known and
configurable, the duration of the garbage collection process is variable, depending on how many tombstones have expired
and the load requirements of the domain controller at the time of garbage collection. The variable nature of garbage
collection can cause unpredictable performance between the time garbage collection begins and online defragmentation
completes.
By performing online defragmentation during off-peak hours, you can ensure more-even directory performance during peak
hours. To control when online defragmentation occurs, you can configure domain controllers running Windows Server 2003
as follows:
To start online defragmentation manually at any time, irrespective of garbage collection intervals, you can add the
•
operational attribute doOnlineDefrag to the rootDSE object. The value of this attribute dictates the duration (in seconds)
for which online defragmentation runs. After setting this attribute value, you can create a script that takes the duration as
input so that online defragmentation can be triggered by the script at any time for any duration of runtime.
If you want online defragmentation to always occur only on demand, you can configure the registry so that automatic
•
online defragmentation is disabled.
Note
The information here is provided as a reference for use in troubleshooting or verifying that the required settings are
•
applied. It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications
to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect
values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other
Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry
directly. If you must edit the registry, use extreme caution.
You do not have to disable automatic online defragmentation to manually start online defragmentation. After you add the
doOnlineDefrag attribute, you can start manual online defragmentation at any time that conditions warrant it, while
allowing automatic online defragmentation to continue as well.

Offline Defragmentation
Offline defragmentation rebuilds the directory database and releases unneeded space back to the file system. Offline
defragmentation must be performed in Directory Services Restore Mode, which restarts the computer as a stand-alone
server, that is, as a computer that is not acting as a domain controller. In Directory Services Restore Mode, you can use the
ntdsutil command-line tool to defragment the Ntds.dit file. Offline defragmentation produces a defragmented version of the
database file in a separate directory. You can archive the original Ntds.dit file and move the defragmented file into the
current directory.
Only offline defragmentation provides a clear picture of the amount of space that is consumed by the database file. You can
use offline defragmentation to test database growth by comparing the defragmented version of the file with the fragmented
version. For example, on a newly installed domain controller, if you perform a bulk load of objects and then defragment the
database file offline, the difference between the two files is the space that is occupied by the new objects. There is no
standard or optimal value for the percentage of free space that might exist in the database at any given time. If you are
concerned about database size, set the DSA to log a message in the Directory Service event log during garbage collection
that states how much disk space could be freed up through offline defragmentation.

Linked Attribute Management

Attributes of certain objects can be linked in the directory database to attributes of other objects to provide interobject
references from one object back to the other object for either usability or administrative purposes. For example, a user
object can be a member of a group, and a group can have users and groups as members. To define this relationship, the
group object has a member attribute that can have multiple values of the distinguished names of every user, computer, or
group that has membership in the group. Similarly, the user, computer, and group objects have a multivalued memberOf
attribute that identifies all the groups to which a user, computer, or group belongs. These attributes are “linked” in the Active
Directory database so that you can, for example, look at the member attribute on the object GroupA and determine that
UserB is a member of GroupA. Likewise, you can look at the memberOf attribute on the object UserB and determine that
UserB belongs to GroupA.
The GUID of an object unambiguously indicates which object the linked value applies to, even if the object has been
renamed, deleted, or garbage-collected (permanently removed from the database). Individual values of multivalued
attributes do not have an associated GUID. Instead, a link-value identifier serves the purpose of distinguishing existing
values (including value tombstones) from values that have been garbage-collected and then recreated. This identifier, called
the link ID, remains fixed from the creation of the value until the value is garbage-collected. When the originating server
creates a new value, an ID is assigned to the value. Linked values replicate with the GUID of the object that contains them.

Effect of Moving Linked Objects

Active Directory maintains referential integrity between objects that reference each other by distinguished name so that
when one object is moved in the directory tree, the referencing object can track the referenced object. For example, an
object UserB is a member of GroupA. If you move the object UserB from the CN=Users,DC=concorp,DC=contoso,DC=com
container to the OU=Sales,DC=concorp,DC=contoso,DC=com OU, the distinguished name value for UserB in the member
attribute on the GroupA object automatically changes as follows:

• Before the move: CN=UserB,CN=users,DC=concorp,DC=contoso,DC=com

• After the move: CN=UserB,OU=sales,DC=concorp,DC=contoso,DC=com

This change occurs as soon as the move occurs. In this way, linked attributes effectively share their values.

Identifying Link Pairs

The sharing of values by linked attributes is achieved when two attributes are marked in the schema as having the same
link-pair identifier — one is marked as the forward link (it points to another object in the directory) and the other as the
back-link (it points back to the object that has a forward link to it). Changing the forward link attribute on one object affects
the back-link on the referenced object. In the current example, the member attribute is the forward link and the memberOf
attribute points back to the value in member. For reasons that relate to security and replication, only the forward-linked
attribute can be modified.
Note
The decision to link two objects must be made at the time that the objects are added to the
•
schema.
To find all the objects that are members of GroupA, links are examined for all records in which the link pair is
member/memberOf and the back-linked attribute identifies GroupA. The link pairs of those records provide the database
identifiers of all the records (objects) that are members of GroupA.
The member and memberOf example uses a multivalued forward link and a multivalued back-link, but there is no
requirement that the forward link be a multivalued link. For example, each group has one manager, but a manager can
manage multiple groups. This relationship is identified in the database by the manager/directReports link pair, where
manager is a single-valued attribute of a user object and directReports (common name Reports) is a multivalued attribute
of a user object. The back-linked attribute must always be multivalued because it is impossible to restrict who creates links
to various objects.

Deleting Linked Objects

When an object that is linked through a multivalued attribute is deleted, all of its linked attribute values are removed from
the respective linked objects. In the preceding example, if a user manages multiple users and one of the users is deleted, the
directReports multivalued attribute on the user object of the user that is the manager suddenly (and with no change to any
replication-related metadata) loses a value. Similarly, if the user object for the manager is deleted, the value of the
manager attribute on the user object of the user who was a direct report is suddenly blank. Nothing about the nondeleted
object changes in either case, except that the attribute value is gone.

Restoring Linked Objects and Their Back-Links

When objects are deleted by mistake, you can restore them in Active Directory by performing an authoritative restore of the
deleted objects. You perform authoritative restore by restoring the domain controller from its latest backup and then marking
the deleted objects as authoritative so that they are not removed by replication.
However, when an object that has back-links is restored on a domain controller running Windows 2000 Server, its back-links
are not restored as part of the authoritative restore process. For example, when user objects or group objects are deleted
and then authoritatively restored, the memberOf values must be restored manually. You must add a restored user or group
back to the groups to which it belonged at the time that its account was deleted.
On domain controllers running Windows Server 2003 in a forest that has a forest functional level of Windows Server 2003 or
Windows Server 2003 interim, back-links are restored automatically for authoritatively restored objects under the following
conditions:
The link was added after the forest functional level was raised to Windows Server 2003 or Windows Server 2003 interim
•
(linked-value replication was in effect).
Replication of a restored user object precedes replication of a restored group to which it belongs when the user and group
•
are both authoritatively restored at the same time.
If the domain controller on which you are authoritatively restoring objects is running Windows Server 2003 with SP1, you can
use the Windows Server 2003 SP1 version of Ntdsutil to restore back-links for any authoritatively restored objects that have
links, including objects in different domains. For more information about how to restore back-links on domain controllers
running Windows Server 2003 with SP1, see "Performing an Authoritative Restore of Active Directory Objects" in
"Administering Active Directory Backup and Restore" in the Windows Server 2003 Operations Guide at
http://go.microsoft.com/fwlink/?LinkId=44194.
For more information about replication of deleted linked objects, see “Active Directory Replication Model Technical
Reference”.

Phantom Records for Interdomain Object References

An attribute that has a distinguished name as a value references (points to) the named object. When the referenced object
does not actually exist in the local directory database because it is in a different domain, a placeholder record called a
phantom is created in that database as the object reference. Because there is a reference to it, the referenced object must
exist in some form, either as the full object (if the domain controller stores the respective domain directory partition) or as
an object reference (when the domain controller does not store that domain).
A phantom record contains the GUID and the distinguished name of the object that is being referenced. In the case of
references to security principals, the phantom also contains the SID. A common example of a distinguished name value that
references an object in a different domain is the nCName attribute of a cross-reference (crossRef) object. Every domain
controller stores a cross-reference object (in the configuration directory partition) for every other domain directory partition
in the forest. Therefore, the nCName attribute value for every cross-reference object necessarily references a phantom in
the local directory database.

Infrastructure Master and Phantom Records

The infrastructure master is a single domain controller in each domain that tracks name changes of referenced objects and
updates the references on the referencing object. When a referenced object is moved to a different domain (which effectively
renames the object), the infrastructure master updates the distinguished name of the phantom. (The infrastructure master
finds phantom records by using a database index that is created only on domain controllers that hold the infrastructure
operations master role.) When the reference count of the phantom falls to zero (no objects are referencing the object that
the phantom represents), garbage collection on each domain controller removes the phantom.
Note
Because objects can reference objects in different domains, the infrastructure operations master role is not compatible
•
with global catalog server status if there is more than one domain in the forest. If a global catalog server holds the
infrastructure operations master role, phantom records are never created because the referenced object is always located
in the directory database on the global catalog server.

Ownership Quotas on Directory Objects

On domain controllers running Windows Server 2003, you can specify quotas that limit the number of objects that a security
principal (user, group, computer, or service) can own in a domain, configuration, or application directory partition. By
default, the security principal (or administrative group in some cases) that creates an object is the object owner, although
ownership can be transferred. With Active Directory quotas, no one can create unlimited numbers of objects in a directory
partition, which is a method that can be used to launch denial-of-service attacks.
Note

• The term “user” in this discussion of security principals indicates both the user and inetOrgPerson classes of objects.
By default, quotas are not set, so there are no limits to the number of objects that can be owned by any security principal.
For each target directory partition, you can set different limits for different security principals or you can set limits that apply
to all security principals, or you can do both.
Quotas can be set per directory partition, except for the schema directory partition, which does not support quotas. You can
set quotas to apply to security principals for a directory partition by using the command line. Use the following commands to
manage quotas:

• dsadd quota to set quotas for a directory partition

• dsmod quota to modify existing quotas

• dsmod partition to modify default quota settings for a partition

dsquery quota to search for quota assignments and quota
•
consumption
For more information about directory quotas and how to use dsadd, dsmod, and dsquery commands to manage directory
quotas, see “Data Store Tools and Settings”.

Quota Assignment Objects

Quota assignments for security principals are represented in a directory partition as instances of the object class msDS-
QuotaControl. Each object in this class has the following attributes:
Common-Name: The relative distinguished name (RDN) of the security principal object. This mandatory value should be
•
a friendly name (or sAMAccountName) of the security principal whose quota is being specified.
• msDS-QuotaTrustee: The SID of the security principal (user, computer, or group) for which the quota is being assigned.
msDS-QuotaAmount: The mandatory value of the assigned quota (number of objects owned in the database) for the
•
security principal. A value of -1 for this attribute denotes an unlimited quota.
• Flags: This optional attribute is reserved for future use.
Instances of msDS-QuotaControl objects are stored in a well-known container called NTDS Quotas in the directory partition
to which the quota applies.

Quota Containers
The NTDS Quotas container (class msDS-QuotaContainer) is a special system container that the quota system uses. The
NTDS Quotas container has the following characteristics:
It is a child object of the root of a parent directory partition (including domain, configuration, and application directory
•
partitions).
• It cannot be deleted, but it can be renamed.

• It is tracked by the parent container through the wellKnownObjects attribute on the parent container.
Each directory partition has exactly one well-known NTDS Quotas container that stores explicit quota assignment objects for
the partition.
Two attributes of this well-known container specify a default quota value and how quotas are computed for that directory
partition:
msDS-DefaultQuota: A default quota that applies to any security principal that creates objects in the directory partition
•
and for which no explicit quota assignment exists. If no value is set for this attribute or if the attribute has the value -1,
there is no default quota for the directory partition. In this case, security principals that do not have explicit quotas
assigned have the ability to create unlimited objects in that directory partition, subject to access control. The default value
for msDS-DefaultQuota on a directory partition is unlimited (not set). To manage this value, use the dsmod partition
command.
msDS-TombstoneQuotaFactor: The percentage factor by which tombstone object count should be reduced for the
•
purpose of quota accounting. By default, the setting is 100, which means that a tombstone (a deleted object) that was
originally created by a security principal is equal to 1 object of that user’s quota. If the percentage factor were set to 50,
each tombstone would represent only half an object rather than an entire object. Likewise, a tombstone quota factor of
25 means that four tombstones are the equivalent of 1 owned object. In this way, the quota for a security principal is
computed relative to objects and tombstones. To manage this value, use the dsmod partition command.
Tracking Object Ownership
To enforce compliance with Active Directory quotas, object ownership is tracked by each domain controller running
Windows Server 2003. After a domain controller is upgraded to Windows Server 2003, the system determines the number of
objects that are owned by each security principal and for each directory partition that the domain controller hosts, and the
system generates a tracking table for internal object ownership to track quota consumption. Thereafter, when objects are
created, deleted, or reanimated or their ownership is transferred in a directory partition that the domain controller hosts, the
quota tracking data is suitably updated.

Enforcing Quotas
Quotas are enforced only on originating updates and only by domain controllers running Windows Server 2003. When an
update originates on a Windows Server 2003 domain controller, quotas are enforced. At the time of the operation, if the
requestor is not exempt from quotas, the effective quota limit for the requestor is computed on the basis of the default quota
setting for the directory partition or any explicit quota assignments. Further, the requestor’s current quota consumption is
computed using the object ownership tracking data and the tombstone quota factor. If the pending object transaction
(create, delete, reanimate, or transfer of ownership) causes the quota limit to be exceeded, the transaction fails.
If an originating update occurs on a domain controller running Windows 2000 Server, quotas are not enforced. However, as
Windows Server 2003 domain controllers receive replicated updates, regardless of their origin, they update object ownership
tracking data for the respective security principal.
Thus, although Windows Server 2003 domain controllers can always update quota tracking data, quotas are effectively
enforced at the domain level only when all domain controllers in the domain are running Windows Server 2003 and at the
forest level (for the configuration directory partition) only when all domain controllers in the forest are running
Windows Server 2003.

Effective quota
Multiple quota assignments can exist for a given security principal through an individual quota assignment or through quota
assignments for one or more security groups of which the principal is a member, or both. When multiple quota assignments
exist for a security principal, the effective quota is computed to be the maximum of the applicable quota assignments that
are specified. For example, if a user belongs to two groups that have different quotas specified for the same directory
partition, the higher of the two quota values applies to the user.
If no quota assignments are specified for a security principal or for any of the security groups of which the security principal
is a member, the effective quota is the default quota that is specified for the directory partition in the msDS-DefaultQuota
attribute on the NTDS Quotas container.

Quota exemptions
Members of the Domain Admins and Enterprise Admins groups are exempted from all quota-imposed limits.

Using Quotas
You can use quotas in combination with security groups to manage objects that are created in Active Directory. The following
examples illustrate using a default quota, with exceptions to set explicit quota assignments for those groups that need the
ability to create large numbers of objects.

Managing DNS data in application directory partitions

When you use Active Directory–integrated DNS, zone data can be stored in the domain directory partition, if you want DNS
data to replicate to all domain controllers, or in application directory partitions, if you want DNS data to replicate only to
domain controllers that are DNS servers.
To decrease domain-wide replication and avoid replicating zone data to the global catalog, you can take advantage of
application directory partitions on DNS servers running Windows Server 2003. By default, members of the Authenticated
Users group have the ability to create resource records on DNS servers that are in the domain of the client computer. This
ability is required to allow all computers to dynamically update DNS zone data. A typical authenticated user needs to register
a maximum of 10 records in DNS. To ensure that malicious users or applications do not create inappropriate resource
records, you can set a default quota on the application directory partitions ForestDnsZones and DomainDnsZones, which are
replicated to every DNS server in the forest and domain, respectively. A default limit of 10 objects ensures that all computers
can update DNS appropriately but cannot launch denial-of-service attacks.

Explicit quotas for domain controllers and other servers

The number of resource records that must be registered in DNS is significantly greater for domain controllers and for
multihomed computers that register adapter-specific records for all of their connections. To accommodate the resource
record requirements of atypical authenticated users such as domain controllers, multihomed computers, and multiadapter
servers, you can create special groups for these specific types of computers. For example, you might create the Enterprise
Domain Controllers group that has all domain controllers as members. To ensure that this group can create the maximum
DNS resource records that might be required, set a quota of 300 to 400 objects for this group on the DomainDnsZones and
ForestDnsZones application directory partitions.
The same rule applies to servers such as virtual private network (VPN) or Web servers, which are required to register a large
number of resource records in DNS. Depending on how many adapter-specific resource records your VPN or Web server must
register, you can create a group for those servers and assign the appropriate quota to ensure that the Authenticated Users
default quota does not apply.

Explicit quotas for DHCP servers

To allow DHCP servers to have essentially unlimited ability to create resource records when clients depend on DHCP-assigned
IP addresses, you can create a group that contains all DHCP servers in the domain or forest and then set an explicit quota
assignment for that group on the DomainDnsZones and ForestDnsZones application directory partitions, respectively. Set a
quota that is appropriate to the number of clients for which your DHCP server registers records, multiplied by the upper limit
of the number of records registered per computer. In this way, DHCP servers can update DNS with client resource records as
needed.

Managing print objects in domain directory partitions

When Active Directory is used to publish shared printing resources, print servers require the ability to create potentially large
numbers of objects in Active Directory. Print servers publish printers in Active Directory as print queue objects (class
printQueue), which are child objects of the print server computer object and which contain a subset of the information that
is stored on the print server for a printer. When print servers go offline for any reason, they must republish their print
queues when they return to service. For this reason, print servers require the ability to create large numbers of objects in the
domain directory partition.
To ensure that print servers can create appropriate numbers of objects in the domain, you can create a group that contains
all print servers in the domain and then specify an explicit quota assignment on the domain that is higher than the default
assignment.
Top of page
Network Ports Used by the Data Store
The network ports that are used by the data store are listed in the following table.
Port Assignments for the Data Store

Service Name UDP TCP

LDAP None 389

LDAP SSL None 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP None 3268

Global Catalog LDAP SSL None 3269

Top of page

Data Store Tools and Settings

Updated: March 28, 2003
In this section

• Data Store Tools

• Data Store Registry Entries

• Data Store Group Policy Settings

• Data Store WMI Classes

Network Ports Used by the Data
•
Store
This section contains information about the tools, registry entries, Group Policy settings, Windows Management
Instrumentation (WMI) classes, and network ports that are associated with the data store.

Data Store Tools

The following tools are associated with the data store.

Adsiedit.msc: ADSI Edit

Category
This tool ships with Support Tools for Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
ADSI Edit is a Microsoft Management Console (MMC) tool that you can use to view and modify directory objects.
To find more information about ADSI Edit, see Support Tools Help in Tools and Settings Collection.

Csvde.exe: Csvde
Category
This tool ships with Windows Server 2003.

Version compatibility
Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Csvde to import and export data from Active Directory by using files that store data in the comma-separated
value (CSV) file format standard. Csvde also supports batch operations that are based on CSV.
To find more information about Csvde, see “Command-Line References” in Tools and Settings Collection.

Dsadd.exe: Dsadd
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsadd to add specific types of objects to the directory.
To find more information about Dsadd, see “Command-Line References” in Tools and Settings Collection.
Dsget.exe: Dsget
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Dsget to display the selected properties of a specific object in the directory.
To find more information about Dsget, see “Command-Line References” in Tools and Settings Collection.

Dsmod.exe: Dsmod
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Can Be Run From Can Be Run Against

Computers running:

• Windows XP Professional
You can use Dsmod to modify an existing object of a specific type in the directory.
To find more information about Dsmod, see “Command-Line References” in Tools and Settings Collection.

Dsmove.exe: Dsmove
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsmove to move a single object, within a domain, from its current location in the directory to a new location.
You can also use Dsmove to rename a single object without moving it in the directory tree.
To find more information about Dsmove, see “Command-Line References” in Tools and Settings Collection.

Dsquery.exe: Dsquery
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
Can Be Run From Can Be Run Against

• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsquery to query Active Directory according to specified criteria.
To find more information about Dsquery, see “Command-Line References” in Tools and Settings Collection.

Dsrm.exe: Dsrm
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
You can use Dsrm to delete an object of a specific type, or any general object, from the directory.
To find more information about Dsrm, see “Command-Line References” in Tools and Settings Collection.

Ldifde.exe: Ldifde
Category
This tool ships with Windows Server 2003.
Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
Servers running:
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional
You can use Ldifde to create, modify, and delete directory objects on domain controllers. You can also use Ldifde to extend
the schema, export Active Directory user and group information to other applications or services, and populate
Active Directory with data from other directory services.
To find more information about Ldifde, see “Command-Line References” in Tools and Settings Collection.

Ldp.exe: Ldp
Category
This tool ships with Support Tools for Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
Servers running:
• Windows 2000 Server
• Windows Server 2003, Standard Edition
• Windows 2000 Advanced Server
• Windows Server 2003, Enterprise Edition
• Windows 2000 Datacenter Server
• Windows Server 2003, Datacenter Edition
• Windows Server 2003, Web Edition
Computers running:

• Windows XP Professional
Ldp is a Lightweight Directory Access Protocol (LDAP) graphical user interface (GUI) tool that you can use to perform
operations such as connect, bind, search, modify, add, and delete against any LDAP-compatible directory, such as
Active Directory. You can also use Ldp to view objects that are stored in Active Directory, along with their metadata, for
example, security descriptors and replication metadata.
You can use the online dbdump feature in Ldp to view values that are stored in the database while the domain controller is
running. You can trigger dbdump by modifying the dumpDatabase attribute on the rootDSE.
To find more information about Ldp, see “Support Tools Help” in Tools and Settings Collection.

Ntdsutil.exe: Ntdsutil
Category
This tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard Edition
• Windows Server 2003, Enterprise Edition • Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition • Windows Server 2003, Datacenter Edition
You can use Ntdsutil to perform Active Directory database maintenance, manage and control single master operations, and
remove metadata left behind by domain controllers that are removed from the network without being properly uninstalled.
This tool is intended for use by experienced administrators.
To find more information about Ntdsutil, see “Command-Line References” in Tools and Settings Collection.
Top of page
Data Store Registry Entries
The following registry entries are associated with the data store.
The registry entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics control
the logging level for the component or process that is specified in the entry name. The value for each entry is set to an
integer from and including 0 (no logging) through 5 (most verbose logging).
The registry entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters control
or contain information about the configuration of the data store.
The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied.
It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry
are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be
stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such
as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the
registry, use extreme caution.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
The following registry entries are located under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.

3 ExDS Interface Events

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that result from communication between Active Directory and Microsoft Exchange clients.

4 MAPI Interface Events

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that result from communication between Active Directory and Microsoft Exchange clients.

6 Garbage Collection
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are generated when objects that are marked for deletion are actually deleted.

7 Internal Configuration
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of internal operations.

8 Directory Access
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of read and write operations to directory objects from all sources.

9 Internal Processing
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to internal directory service operations.

11 Initialization/Termination
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are generated by starting and stopping Active Directory.

12 Service Control
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of Active Directory service events.

13 Name Resolution
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are generated by the resolution of addresses and Active Directory names.

14 Backup
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to backing up Active Directory. Specifically, controls the logging of events that
occur when Extensible Storage Engine (ESE) database records are read or written during backup.
16 LDAP Interface Events
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to LDAP.

18 Global Catalog
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to the global catalog.

22 DS RPC Client
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to communication between Directory System Agents (DSAs). Examples of
such communication include replication and the forwarding of look-ups to a global catalog. Examples of logged events include
remote procedure call (RPC) errors, canceled calls, Domain Name System (DNS) resolution failures, and service principal
name (SPN)–related operations.

23 DS RPC Server
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to a DSA acting as an RPC server. A DSA acts as an RPC server, for example,
during outbound replication, replication setup operations, cross-domain moves, and membership queries or when a client
makes a look-up call.
24 DS Schema
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls the logging of events that are related to schema errors and operations. Such errors and operations include schema
additions, deletions, modifications, look-up errors, look-up failures, and caching errors.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
The following registry entries are located under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

Configuration NC
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Contains the distinguished name of the configuration directory partition.

Database Backup Path

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines the directory that is used as the target directory when online backups of the directory database are performed.

Database Log Files Path

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines the directory path that is used to store Active Directory log files.
Database Logging/Recovery
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Controls a Microsoft Jet database engine parameter called JET_paramRecovery that determines whether database operations
are logged.

DS Drive Mappings
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Used to track local drive mapping names, so that the database file can be located if drive mappings are modified.

DSA Database File

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines the file that is used by the domain controller for storing Active Directory objects.

DSA Working Directory

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines the working directory of Active Directory.

Hierarchy Table Recalculation Interval (minutes)

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines how frequently the hierarchy table for the directory database is built. The hierarchy table is used only by the
Messaging API (MAPI) interface.

Ldapserverintegrity
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Determines whether connection integrity is required (by means of checksum-signed packets) for LDAP connections.

Machine DN Name
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Contains the distinguished name of the computer on which the domain controller is running.

Root Domain
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Contains the distinguished name of the root domain of the Active Directory forest to which the domain controller is
connected.

Schema Version
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server;
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter
Edition.
Contains the schema version for which a particular operating system is configured.
System Schema Version
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Domain controllers running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and
Windows Server 2003, Datacenter Edition.
Contains the version of the schema at the time that a backup is taken. This value is used to prevent an incompatible schema
version from being restored from backup.
Top of page
Data Store Group Policy Settings
The following table lists and describes the Group Policy settings that are associated with the data store.
Group Policy Settings Associated with the Data Store

Group Policy Setting Description

Audit Directory When it is enabled, this Group Policy setting causes successful and failed directory access events to
Services Access be logged in the Directory Service event log.
Top of page
Data Store WMI Classes
The following table lists and describes the WMI classes that are associated with the data store.
WMI Classes Associated with the Data Store

Class Name Namespace Version Compatibility

rootDSE root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition

DS_LDAP_Class_Containment
• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition
• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
DS_LDAP_Instance_Containment root\directory\LDAP Domain controllers running:

• Windows Server 2003, Standard Edition

Class Name Namespace Version Compatibility

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
For more information about these WMI classes, see “Mapping Active Directory to WMI” in the WMI SDK documentation on
MSDN.
Top of page
Network Ports Used by the Data Store
The network ports that are used by the data store are listed in the following table.
Port Assignments for the Data Store

Service Name UDP TCP

LDAP None 389

LDAP SSL None 636

RPC Endpoint Mapper 135 135

Global Catalog LDAP None 3268

Global Catalog LDAP SSL None 3269

Top of page