Domains and Forests Technical ReferenceUpdated: March 28, 2003Domains 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 DirectoryActive 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 StructureThe 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 StructureThe 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

Units

Organizational units are container objects. You use these container objects to arrange other objects in a

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

Component Description

objects, connection 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 DirectoryThe 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 ForestWithin 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 ObjectsOrganizational 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 UnitsThe 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.

ObjectsActive 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 PolicyA 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 ReplicationThe 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 ControllersThe 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.

SitesWithin 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 MastersActive 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 BoundariesBy 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 TrustA 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 NotDomains 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 OtherWithin 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 DomainAlthough 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 DomainA 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 ReplicationUnlike 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

Partition Description

stored 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 RolesThere 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.”

SitesSites 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 CatalogsThe 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 BoundariesEach 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 DelegationThe 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 InformationThe 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 WorkUpdated: March 28, 2003

How Domains and Forests WorkIn 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 StructureA 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-ReferencesCross-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 StructureFor 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-ReferencesAn 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 RelationshipsActive 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 DomainThe 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 DomainsA 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 TreesA 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 DomainsChild 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 NamesActive 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 InternetActive 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 ObjectsActive 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 UniquenessEach 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.

GUIDsEvery 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 NamesObject 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 NamesActive 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 NameObjects 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 NameThe 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 NameBy 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 NamesA 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 NameIn 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 NameA 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 UnitsActive 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 HierarchyOrganizational 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 PolicyGroup 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 ControlThe 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 ControlActive 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 AuthorizationIn 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 DescriptorsAccess 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 AccountsEach 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 InterfacesThe 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.

LDAPLDAP 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.”

RPCActive 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 ProtocolsDomain 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.

NTLMThe 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 ProtocolThe 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 APIsYou 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

ADSIActive 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 CThe 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.

REPLThe 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.

MAPIMessaging 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.

SAMSecurity 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 InteractionsMany 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 DomainWhen 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 ForestsWhen 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 DomainJoining 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.logWhen 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 ControllersWhen 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 LevelsWhen 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 PartitionsActive 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 ForestsThe 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

internal forest

LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

 N/A Internal domain domain

controllers–External domain

domain controllers (all ports)

Trust validation from the internal forest

domain controller to the external forest

domain controller (outgoing trust only)

LDAP (389 UDP)

Microsoft SMB (445 TCP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

 N/A Internal domain domain

controllers–External domain

domain controllers (all ports)

Use Object picker on the external forest

to add objects that are in an internal

 N/A LDAP (389 UDP and TCP)

Windows NT Server 4.0

External server–Internal

domain PDCs (Kerberos)

Task Outbound Ports Inbound Ports From–To

forest to groups and DACLs directory service fixed

port

Net Logon fixed port

Kerberos (88 UDP)

Endpoint resolution

portmapper (135 TCP)

External domain domain

controllers–Internal domain

domain controllers (Net

Logon)

Set up trust on the external forest from

the external forest

 N/A LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

External domain domain

controllers–Internal domain

domain controllers (all ports)

Use Kerberos authentication (internal

forest client to external forest)

Kerberos (88 UDP)  N/A Internal client–External

domain domain controllers

(all ports)

Use NTLM authentication (internal

forest client to external forest)

 N/A Endpoint resolution –

portmapper (135 TCP)

Net Logon fixed port

External domain domain

controllers–Internal domain

domain controllers (all ports)

Join a domain from a computer in the

internal network to an external domain

LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

Windows NT Server 4.0

directory service fixed

port

 N/A Internal client–External

domain domain controllers

(all ports)

Top of page

Related InformationThe 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 SettingsUpdated: March 28, 2003In 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 ForestsThe following tools are associated with domains and forests.

Adsiedit.exe: ADSI Edit

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

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryCsvde 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:

Can Be Run From Can Be Run Against

• 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, Web Edition

Computers running:

• Windows XP Professional

• 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

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

CategoryThe 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

CategoryDomain 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:

• 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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryAn 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 compatibilityThis 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

CategoryAn 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

CategoryDomain 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:

• 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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryAn 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

CategoryDsadd is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryDsget is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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

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

Can Be Run From Can Be Run Against

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional

• Windows 2000 Datacenter Server

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

CategoryDsmod is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryDsmove is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryDsquery is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryDsrm is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryAn 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:

• 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

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

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 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

CategoryLdifde is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryLdp is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThe 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

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

Version compatibilityThis 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

CategoryThe NLTest command-line tool is included when you install Windows Server 2003 Support Tools.

Version compatibilityThis 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

CategoryNtdsutil is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

Can Be Run From Can Be Run Against

• 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

CategoryRepadmin is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryAn 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

CategorySetspn is included when you install Windows Server 2003 Support Tools.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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 EntriesThe 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 SettingsThe 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 Services

Access

When it is enabled, this Group Policy setting causes successful and failed directory access events to

be logged in the Directory Service event log.

Group Policy Settings Associated with Active Directory Searches

Group Policy Setting

Description

Maximum size of

Active Directory

searches

Specifies the maximum number of objects that the system displays in response to a command to

browse or search Active Directory.

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

dialog box

Displays the filter bar above the results of an Active Directory search. The filter bar consists of buttons

for applying additional filters to search results.

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

folder

Hides the Active Directory folder in My Network Places.

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

Coverage by the DC

Locator DNS SRV

Records

Determines whether domain controllers dynamically register DC Locator site-specific SRV resource

records for the closest sites where no domain controller for the same domain exists (or no global

catalog server for the same forest exists). These DNS records are dynamically registered by the Net

Logon service, and they are used to locate domain controllers.

Group Policy Setting Description

Sites Covered by the

GC Locator DNS SRV

Records

Specifies the sites for which global catalog servers should register the site-specific GC Locator SRV

resource records in DNS. These records are registered in addition to the site-specific SRV resource

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:

• Account lockout

duration

• Account lockout

threshold

• Reset account lockout

counter after

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

Password Policy:

• Enforce password

history

• Maximum password

age

• Minimum password

age

• Minimum password

length

• Password must meet

complexity

requirements

• Store passwords using

reversible encryption

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

Contact PDC on logon

failure

Account lockout and domain password changes rely on contacting the primary domain

controller (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:

• Enforce password history

Changes to the Password Policy settings control:

• The strength and complexity required of the password of every

Group Policy Setting Description

• 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

user

Audit Policy:

• Audit account logon events

• Audit account

management

• Audit logon events

Changes to the Audit Policy settings control:

• Auditing of logons and log offs

• Auditing of password and permissions changes

User Rights Assignment:

• Access the computer from the network

• Deny logon as a batch job

• Deny logon as a service

• Deny logon locally

• Deny logon through terminal services

• Logon as a batch job

• Logon as a service

• Logon locally

Changes to the User Rights Assignment settings control:

• Which users are allowed or disallowed to log on to perform

different tasks, including logging on as a batch job and a service

• Which users are allowed or disallowed to logon locally or through

terminal services, as well as who can or cannot access the

computer from the network

Security Options:

• Accounts: Limit local accounts use of blank

passwords to console logon only

• Domain member: Maximum machine account

password age

• Domain member: Require strong (in

Windows 2000 or later) session key

• 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

Changes to the Security Options settings control:

• Message text and title displayed by the GINA during an

interactive logon

• Domain member settings

• Authentication settings, including allowing or disallowing blank

passwords and password age

Group Policy Setting Description

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:

• Create a token object

• Replace a process level

token

Changes to these settings control:

• Calling APIs to create tokens.

• Whether a process can replace a token.

Audit Policy:

• Audit policy change

• Audit privilege use

• Audit process tracking

Changes to this setting will:

• Generate audits when rights are assigned with one of the tools discussed

earlier.

• Enable audit privilege use. Will log when SeAssignPrimaryTokenPrivilege

was used.

• Create an audit for assigning a primary token that contains the two

processes involved and the identity of the token assigned.

Security Options:

• Network access: Let Everyone

permissions apply to anonymous

users

Changes to this setting affect whether Everyone is in the token for anonymous

users.

Group Policy User Rights Assignment Settings Associated with Kerberos

Group Policy Setting

Description

Impersonate a client

after authentication

Windows 2000 security setting that was first introduced in Windows 2000 SP4. When you assign this

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.

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:

Group Policy Setting

Description

• 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

restrictions

Determines whether the KDC validates every request for a session ticket against the user rights

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

service ticket

Determines the maximum amount of time (in minutes) that a ticket granted for a service (that is, a

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

user ticket

Determines the maximum amount of time (in hours) that a ticket-granting ticket (TGT) for a user

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

user ticket renewal

Determines the longest period of time (in days) that a TGT can be used if it is repeatedly renewed.

By default, the setting is seven days.

Maximum tolerance for

computer clock

synchronization

Determines the maximum difference (in minutes) that the Kerberos V5 protocol tolerates between

the clock time on a client and the clock time on a server while still considering the two clocks

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 ClassesWindows 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

• Windows 2000 Server

Class Name Namespace Version Compatibility

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

Microsoft_LocalDomainInfo root\microsoftactivedirectory Domain controllers running:

• Windows Server 2003

Class Name Namespace Version Compatibility

• 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 ForestsThe 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

Service Name UDP TCP

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

Service Name UDP TCP

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 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 LDAP (389 UDP and TCP)  N/A Internal domain domain

Task Outbound Ports Inbound Ports From–To

internal forest Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

controllers–External domain

domain controllers (all ports)

Trust validation from the internal forest

domain controller to the external forest

domain controller (outgoing trust only)

LDAP (389 UDP)

Microsoft SMB (445 TCP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

 N/A Internal domain domain

controllers–External domain

domain controllers (all ports)

Use Object picker on the external forest

to add objects that are in an internal

forest to groups and DACLs

 N/A LDAP (389 UDP and TCP)

Windows NT Server 4.0

directory service fixed

port

Net Logon fixed port

Kerberos (88 UDP)

Endpoint resolution

portmapper (135 TCP)

External server–Internal

domain PDCs (Kerberos)

External domain domain

controllers–Internal domain

domain controllers (Net

Logon)

Set up trust on the external forest from

the external forest

 N/A LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

External domain domain

controllers–Internal domain

domain controllers (all ports)

Use Kerberos authentication (internal

forest client to external forest)

Kerberos (88 UDP)  N/A Internal client–External

domain domain controllers

(all ports)

Use NTLM authentication (internal

forest client to external forest)

 N/A Endpoint resolution –

portmapper (135 TCP)

Net Logon fixed port

External domain domain

controllers–Internal domain

domain controllers (all ports)

Join a domain from a computer in the

internal network to an external domain

LDAP (389 UDP and TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

Endpoint resolution —

portmapper (135 TCP)

Net Logon fixed port

Windows NT Server 4.0

directory service fixed

port

 N/A Internal client–External

domain domain controllers

(all ports)

Top of page

Related InformationThe 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 ReferenceUpdated: March 28, 2003The 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 DataActive 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 SchemaThe 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 WorksUpdated: March 28, 2003

How the Active Directory Schema WorksIn 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 ArchitectureIn 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 ComponentsObjects, attributes, and classes are the basic components that are used to build object definitions in the schema.

ObjectsObjects 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.

AttributesAttributes 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.

ClassesObject 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 ObjectsActive 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 ObjectsAttributes 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 classAttributes 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

identifier

Yes No Object identifier that uniquely identifies this attribute

lDAPDisplayName Unicode Yes, but

automatic

No Name by which LDAP clients identify this attribute

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

identifier

Yes No Syntax object identifier of this attribute

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.

Attribute Syntax Mandatory? Multivalue? Description

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

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

PartialAttributeSet

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

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

identifier

Yes Yes Class of this object, which is always attributeSchema

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

Attribute Syntax Mandatory? Multivalue? Description

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.

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 attributesSome 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 attributesLinked 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 linksThe 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 attributesDirectory 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 attributesOn 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.

SyntaxesThe 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 Object Identifier

Description

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

Syntax attributeSyntax

oMSyntax ASN 1-Encoded Object Identifier

Description

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

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

String(UTC-Time),

String(Generalized-Time)

2.5.5.11 23, 24 \x55050B UTC time or 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 identifiersObject 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.

Numerical Values of the Object Identifier What the Numerical Values Mean

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 ObjectsThe 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 classSchemaobjectsThe 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

class

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

class

schemaIDGUID String(Octet) Yes, but

defaulted

No The GUID that uniquely identifies this class

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

Attribute Syntax Mandatory? Multivalue? Description

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.

defaultSecurityDescripto

r

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

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

Identifier

Yes Yes This object’s class, which is always

classSchema

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

object

defaultObjectCategory Distinguished

name

Yes No The default object category of new instances of

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 Attribute

Default Status

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 pairsSome 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 ClassesDifferent 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 classesStructural 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 classesAbstract 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 classesAuxiliary 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 classesClasses 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 hierarchyInheritance, 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 RulesThe 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 rulesStructure 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 rulesContent 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 LocationThe 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 HeadThe 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 SubentryrootDSE 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 FilesActive 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 InteractionsNormally, 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 SchemaWhen 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 SchemaExtending 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 schemaPlanning 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 extensionsAfter 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 roleActive 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 changesTo 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 controllerIf 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 SchemaIt 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 objectsYou 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 attributesDeactivation 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 CacheWhen 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 ObjectsThe 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 partitionThe 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 partitionThe 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 partitionThe 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 classesAll 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 SchemaThree main issues relate to modifying the schema:

• The impact on replication

• Managing concurrent schema modification

operations

• Handling invalid object instances

Impact on replicationBecause 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 operationsPrograms 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 instancesSchema 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 DirectoriesTo 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 ClassThe 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 2003To 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 InformationActive 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 SettingsUpdated: March 28, 2003

Active Directory Schema Tools and SettingsIn 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 ToolsNormally, 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

CategoryADSI 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:

• 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, Web Edition

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

Can Be Run From Can Be Run Against

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

CategoryCsvde is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryActive 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:

• 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, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

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

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

CategoryLdifde is a command-line tool that ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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

Domain controllers 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, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

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

CategoryNtdsutil is a command-line tool that ships with Windows Server 2003.

Version Compatibility

Can Be Run From Can Be Run Against

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise 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

CategoryThe 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:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Can Be Run From Can Be Run Against

Servers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional with Adminpak.msi installed

• Windows 2000 Server

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

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 ScriptsActive 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 ReferenceUpdated: March 28, 2003In 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, 2003In 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 NeedOrganizations 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 SolutionThe 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 ScenariosActive 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 ScenarioIn 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 ScenarioIn 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 DatabasesIn 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 DependenciesThe Active Directory data store depends on several related technologies and resources for its proper functioning. The

following sections describe these technologies and resources.

NTFSThe 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 ConnectivitySo 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 ReplicationExcept 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.”

FRSThe 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 SpaceThere 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 WorksUpdated: March 28, 2003In 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 ArchitectureThe 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

Protocol (LDAP), replication (REPL) and

domain controller management interface,

Messaging API (MAPI), Security Accounts

Manager (SAM))

The data store interfaces provide a way for directory clients and other directory

servers to communicate with the data store.

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 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.

DSAThe 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 identificationEvery 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 enforcementThe 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 enforcementThe DSA enforces security limitations in the directory by reading SIDs on the access token.

Support for replicationThe API that is called to initiate replication is implemented in the DSA.

ReferralsThe 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 levelsBeginning 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 IDBoth 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 LayerThe 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.

ESEThe 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 ProtocolsThe 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.

Protocol Description

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,

“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 InterfacesAs 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 StructureThe 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 ModelThe 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 TreeActive 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.

rootDSEIn 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 attributesThe 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.

supportedLDAPVersionLDAP versions that the server implements. Domain controllers running Windows Server 2003 and Windows 2000 Server

support LDAP v2 and LDAP v3.

namingContextsNaming 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.

subschemaSubentryThe 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.

altServerUniform 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.

supportedExtensionObject 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.

supportedControlObject 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.

supportedSASLMechanismsThe 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 attributesIn addition to the previous operational attributes, Active Directory also supports the following informational attributes.

currentTimeThe current time in the generalized time format.

dsServiceNameThe distinguished name of the NTDS settings object that represents this domain controller in the configuration directory

partition.

defaultNamingContextThe 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.

schemaNamingContextThe naming context (directory partition) for the forest schema.

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

rootDomainNamingContextThe 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.

supportedLDAPPoliciesSupported LDAP administrative query policies, such as the maximum size of a result set (MaxResultSetSize) and maximum

page size (MaxPageSize).

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

dnsHostNameThe DNS name of this domain controller.

serverNameThe fully qualified distinguished name for this domain controller.

supportedCapabilitiesThe 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.

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

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

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

domainControllerFunctionalityThe numeric level of Active Directory functionality for the domain controller.

Distribution of Directory DataSo 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.

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 HierarchyIn 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 ObjectsWhen 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 DomainBecause 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 PartitionsThe 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 PartitionThe 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 partitionIn 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.

DisplaySpecifiersContains 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-rightsStores objects of the class controlAccessRight that can be used by applications to extend standard access control.

ForestUpdatesStores 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.

LostAndFoundConfigProvides 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 QuotasStores 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 locationsNot used in this version of Windows but reserved for future use.

ServicesStores 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.

SitesIdentifies 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 principalsContains the special identities that are defined by the security system, such as Everyone, Local System, Principal Self,

Authenticated User, and Creator Owner.

Schema Directory PartitionThe 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 PartitionWhen 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 partitionThe 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.

BuiltinDefault local group accounts, such as Administrators and Users, that are installed whenever a new workstation, server, or

domain controller is set up.

ComputersA 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 ControllersThe default container for new domain controllers. The Domain Controllers container cannot be renamed.

ForeignSecurityPrincipalsProxy 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.

UsersA 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 ObjectsA 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.

InfrastructureAn 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 containerThe 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.

AdminSDHolderAdministrator 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.

COMPartitionsA namespace that is used by Component Services to allow multiple versions of the same COM+ application to exist on the

same physical computer.

ComPartitionSetsA conceptual collection of COM+ partitions.

Default Domain PolicyThe 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-ConfigurationLists the fault-tolerant Distributed File System (DFS) configuration and DFS volume information.

DomainUpdatesStores 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 ServiceLists the Domain System Volume (SYSVOL) and provides a replication schedule from Sunday through Saturday, 12:00 A.M. to

12:00 A.M.

FileLinksUsed 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 SecurityContains 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

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

MicrosoftDNSA 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.

PoliciesContains 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 CheckVerifies 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.

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

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

WMIPolicyStores 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 PartitionsApplication 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 requirementsApplication 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 partitionsThe 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 partitionsThe 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 objectsAny 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 domainsWhen 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 objectsDomains 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 StructureThe 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,

RES2.LOG

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

Active Directory DatabaseActive 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 TableThe 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 TableThe 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 TableThe 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 FilesThe 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,

Edb00003.log, and so on

Active Directory creates additional log files as necessary as existing log files fill up.

Each 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 RequirementsThe 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 CapacityThere 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 SizeThe 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 DataThe 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 DataActive 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 DataAn 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 objectsThe 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 InteractionsThe 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 OperationsData 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 ModelDatabase 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

• Abando

n

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

• Search

• Compar

e

• 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 connectionWhen 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 objectThe 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 RecoveryTo 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 ManagementThe 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 AllocationSpace 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 spaceThe 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 indexesThe 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 dataObjects 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 ReclamationThe 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 2000Delete 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 2003Two 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 DescriptorsIn 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 WrittenThe 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 ServerOn 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 2003On 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 DescriptorsHaving 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 DeletionsWhen 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 TombstonesGarbage 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 RestoreActive 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 EnhancementsThe 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 AttributesWhen 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 OnlineThe 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 DetectionStale 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 accountsThe 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 verificationIn 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 domainUpdates 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 lastLogonTimeStampTo 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 2003In 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 SP1Windows 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 detectionYou 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 DefragmentationAs 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 DefragmentationDuring 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 defragmentationBoth 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 defragmentationOn 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 DefragmentationOffline 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 ManagementAttributes 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 ObjectsActive 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 PairsThe 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 ObjectsWhen 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-LinksWhen 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 ReferencesAn 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 RecordsThe 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 ObjectsOn 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 ObjectsQuota 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 ContainersThe 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 OwnershipTo 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 QuotasQuotas 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 quotaMultiple 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 exemptionsMembers of the Domain Admins and Enterprise Admins groups are exempted from all quota-imposed limits.

Using QuotasYou 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 partitionsWhen 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 serversThe 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 serversTo 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 partitionsWhen 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 StoreThe 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 SettingsUpdated: March 28, 2003In 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 ToolsThe following tools are associated with the data store.

Adsiedit.msc: ADSI Edit

CategoryThis tool ships with Support Tools for Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

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

Can Be Run From Can Be Run Against

• 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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Can Be Run From Can Be Run Against

Servers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows XP Professional

• Windows 2000 Server

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Support Tools for Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

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, Web Edition

Computers running:

• Windows XP Professional

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

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

CategoryThis tool ships with Windows Server 2003.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Domain controllers running:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise 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 EntriesThe 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\DiagnosticsThe following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\

Diagnostics.

3 ExDS Interface Events

Registry pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

VersionDomain 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\ParametersThe following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\

Parameters.

Configuration NC

Registry pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 pathHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

VersionDomain 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 SettingsThe 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 Services

Access

When it is enabled, this Group Policy setting causes successful and failed directory access events to

be logged in the Directory Service event log.

Top of page

Data Store WMI ClassesThe 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

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

Class Name Namespace Version Compatibility

• Windows 2000 Server

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

DS_LDAP_Class_Containment 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

• 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 StoreThe 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