How the Data Store Works
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
In this section
Data Store Architecture
Data Store Protocols
Data Store Interfaces
Data Store Logical Structure
Data Store Physical Structure
Data Store Processes and Interactions
Network Ports Used by the Data Store
Related Information
In Active Directory, the data store contains database files and processes that store and manage directory information for users, services, and applications. A copy of the data store runs on each domain controller in the forest. The Active Directory data store is often referred to as the directory.
Note
In Windows 2000 Server and Windows Server 2003, the directory service is named Active Directory. In Windows Server 2008 and Windows Server 2008 R2, the directory service is named Active Directory Domain Services (AD DS). The rest of this topic refers to Active Directory, but the information is also applicable to Active Directory Domain Services.
The ideal environment for the data store includes the following:
A domain controller running an operating system in the Windows Server 2003 or later family and containing hardware that meets the minimum hardware requirements of the edition of the operating system.
For environments consisting of multiple domain controllers, the presence of a fully functioning Active Directory replication topology
For environments consisting of multiple domain controllers, the presence of a fully functioning File Replication Service (FRS) topology
A regular backup schedule
Regular monitoring of Active Directory, either through manual review of event logs or through an automated monitoring solution, such as Microsoft Operations Manager (MOM)
This section describes the elements of the Active Directory data store, including its architecture, protocols, interfaces, logical structure, physical structure, processes and interactions, and network ports.
Data Store Architecture
The Active Directory data store consists of several components that together provide directory services to directory clients and to other directory servers. These components include three service components, four interfaces, and the directory database where data is actually stored.
The following figure illustrates the architecture of the data store.
Data Store Architecture
.gif "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.
DSA
The DSA runs on every domain controller as Ntdsa.dll, and it provides access to the directory database. The DSA runs as part of the Local Security Authority (LSA) process (Lsass.exe), which manages authentication packages and authenticates users and services. Running in Lsass.exe enables Active Directory to securely manage sensitive information, such as account passwords.
Clients can use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write to Active Directory objects and their attributes.
A forest-wide object in the directory, the NTDS Settings object (class nTDSDSA), represents the DSA on a domain controller, and this object contains configuration information about the DSA on that domain controller.
In addition to providing the interfaces through which directory clients gain access to directory data, the DSA provides the following functionality.
Object identification
Every object in Active Directory has a permanent globally unique identifier (GUID), which is associated with several string forms of the object name (SAMAccountName, user principal name, and distinguished name), as well as a security identifier (SID). The object names and the SID are not permanent; that is, they can be changed. All permanent references to the object are kept in terms of the GUID. The object name is used for hierarchy navigation and display purposes, and the SID is used for access control. The DSA maintains the GUID association with an object when the object’s string name or SID changes, for example, when the object is moved to a different folder (the string name changes) or when the object is moved to a different domain (the string name and the SID change).
Schema enforcement
The DSA ensures that data in the directory adheres to the data definitions that are provided by the directory schema. The schema is the set of rules that determines what kind of data the directory can hold.
Note
- In forests, if an update does not produce a conflict with the schema at the originating replica, the update is considered acceptable at all replicas. Therefore, replicated updates do not perform schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute. For more information about replication, see “Active Directory Replication Model Technical Reference”.
Access control enforcement
The DSA enforces security limitations in the directory by reading SIDs on the access token.
Support for replication
The API that is called to initiate replication is implemented in the DSA.
Referrals
The DSA manages the directory hierarchy information (referred to as knowledge), which it receives from the database layer. The DSA is responsible for cross-references of Active Directory domain objects.
Functional levels
Beginning with Windows Server 2003 and later domain controllers, the DSA has a built-in numeric value that identifies its operating system version — and therefore its functional capabilities — to other services. Services that rely on the DSA can use this numeric value to determine which of their service features to enable.
DSA GUID and Invocation ID
Both the DSA and the Active Directory database are represented uniquely and have their own respective GUIDS. The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA). The value of the DSA GUID is stored in the objectGUID attribute of the NTDS Settings object of the given domain controller server object, which resides in the Sites container in the configuration directory partition.
Domain controllers use the DSA GUID to locate replication partners. Replication uses a special Domain Name System (DNS) name that contains the DSA GUID. This GUID-based DNS name is an alias for the local computer name. The Net Logon service registers this alias resource record in DNS in the form of the CNAME (canonical name) resource record.
The DSA GUID is created when the domain controller is initially promoted, that is, when Active Directory is installed. The DSA GUID is destroyed only if Active Directory is removed from the domain controller. The DSA GUID ensures that the DSA remains recognizable when a domain controller is renamed. The DSA GUID is also not affected by the Active Directory backup and restore process.
The Active Directory database has its own GUID, which the DSA uses to identify the database instance (the version of the database). The database GUID is stored in the invocationId attribute on the nTDSDSA object. Unlike the DSA GUID, which never changes for the lifetime of the domain controller, the invocation ID changes during the Active Directory restore process to ensure the consistency of the replication process. On domain controllers running Windows Server 2003 or later, the invocation ID also changes when an application directory partition is removed from or added to the domain controller.
Database Layer
The database layer is an API that resides in Ntdsa.dll and provides an object view of the directory database, making the data accessible to the DSA as a set of hierarchical containers. By applying schema semantics to database records, the database layer isolates the upper components of the directory service from the underlying database system. The database layer is an internal interface. No database access calls are made directly to the ESE; instead, all database access is routed through the database layer.
In the directory database, each object is identified by its relative distinguished name, which is unique in the object’s parent container. The relative distinguished name and the chain of successive parent object names make up the object’s distinguished name. The database stores the relative distinguished name for each object, as well as a reference to the parent object. The database layer follows these parent references and concatenates the successive relative distinguished names to form distinguished names, thereby defining the object hierarchy.
The database layer is also responsible for the creation, retrieval, and deletion of individual records (objects), attributes within records, and values within attributes. To carry out these functions, the database layer uses the schema cache (an in-memory structure in the DSA) to get the information about the attributes that it needs.
ESE
The Extensible Storage Engine (ESE) is a Windows component that is used by Active Directory, as well as by several other Windows components, as an interface to the data that is stored in an indexed and sequential access method (ISAM) database. (The Active Directory database is an ISAM database.) The ESE is responsible for indexing the data in the database file and for transferring the data in and out of the database. Its purpose is to enable applications to store and retrieve data by using the ISAM. The ESE provides applications with a consistent data state by means of transacted data update and retrieval. A crash recovery mechanism maintains data consistency, even in the event of a system crash. Transactions in the ESE are highly concurrent, making the ESE suitable for server applications. The ESE caches data intelligently to ensure high-performance access to data. In addition, the ESE is resource efficient, making it suitable for applications that perform auxiliary roles.
The version of the ESE that runs on domain controllers 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 and later.
Data Store Protocols
The primary protocol that is used by the Active Directory data store is Lightweight Directory Access Protocol (LDAP), which runs on top of TCP/IP. In addition, the data store uses remote procedure call (RPC) for MAPI, replication, domain controller management, and SAM-related operations. And, although it is not widely used, the data store also supports the use of Simple Mail Transfer Protocol (SMTP) for replication between domain controllers where “always on” network connections do not exist.
The following figure illustrates the protocols and interfaces that are used by the data store. For more information about the data store protocols, see the table that follows this figure. For more information about the data store interfaces, see “Data Store Interfaces” later in this section.
Data Store Protocols
.gif "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:
For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access. The following key aspects characterize LDAP:
|
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. |
Data Store Interfaces
As shown in the “Data Store Architecture” figure earlier in this section, network clients and other directory servers obtain access to Active Directory through one of the interfaces that are described in the following table.
Data Store Interfaces
| Interface | Description |
|---|---|
LDAP |
LDAP is the primary interface for the data store. Directory clients use LDAP v3 to connect to the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2. |
REPL |
The REPL management interface provides functionality for finding data about domain controllers, converting the names of network objects between different formats, manipulating service principal names (SPNs) and DSAs, and managing replication of servers. |
MAPI |
Messaging clients gain access to the Microsoft Exchange Server directory service by using MAPI address book providers. For compatibility with existing messaging clients, Active Directory supports the MAPI-RPC address book provider, which provides access to Active Directory, for example, to find the telephone number of a user. |
SAM |
SAM is a proprietary interface for connecting to the DSA on behalf of clients that use Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect to the DSA through SAM. Replication with Windows NT 4.0 backup domain controllers (BDCs) goes through the SAM interface as well. |
Note
- The MAPI interface is provided only for support of legacy Microsoft Outlook clients. Development against the MAPI interface is no longer supported.
Data Store Logical Structure
The Active Directory data store uses the LDAP information model as its model for organizing data. In addition, the data store is organized into logical partitions that can each be replicated independently, so that individual domain controllers only need to store data that is pertinent to the domain in which they reside.
LDAP Information Model
The LDAP information model is based on the entry, which contains information about some object, for example, a person or computer. In Active Directory, an LDAP entry is referred to as an object. Active Directory objects are composed of attributes, which have a type and one or more values.
The implementation of the information model is called the schema, which is a set of objects that defines the structure and content of every object that can be created in a directory service.
Directory Tree
Active Directory organizes objects into a hierarchical tree structure. The directory tree represents the hierarchy of Active Directory objects for a given forest. The structure of the hierarchy is derived from the schema, and the directory service implements the hierarchy. The hierarchy provides the basis both for using names for navigation and for defining the scope of search requests.
Every object in Active Directory has exactly one parent, and a reference to the parent object is stored with the object. As a result of these parent references, the hierarchy of objects that are managed by Active Directory forms a tree structure. The objects that populate the directory create this tree structure according to the rules of the schema. For example, the schema might dictate that a given class of object can be the child of one class but not the child of another class.
The architectural restrictions and requirements in the directory tree are as follows:
Domain objects, which are containers, can be children only of other domain objects. For example, a domain cannot be the child of an organizational unit (OU).
The root object of the directory tree is called the DSA-specific Entry (DSE), or rootDSE. The rootDSE object has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of the domain controller on which it resides. Therefore, rootDSE constitutes the root of the directory tree from the perspective of the domain controller to which you are connected.
Below the rootDSE, every directory has a root domain, which is the first domain that is created in a forest. This domain always has a child container called Configuration, which contains configuration data for the forest.
rootDSE
In the LDAP information model, one or more directory servers can jointly provide access to a directory tree. The servers that host directories are known in LDAP terminology as Directory System Agents (DSAs). In Active Directory, the DSAs are always domain controllers.
At the root of a directory tree is a DSE, which is not part of any directory partition. TherootDSE represents the top of the logical namespace for one domain controller. The rootDSE attributes contain information about the directory server, including its capabilities and configuration.
There is only one root for a given directory, but the information that is stored in the root is specific to the domain controller to which you connect. Among other things, the attributes of rootDSE identify the following key information:
The directory partitions (the domain, schema, and configuration directory partitions) that are specific to one domain controller.
The forest root domain directory partition.
In this way, the rootDSE provides a “table of contents” for a given domain controller.
rootDSE operational attributes
The rootDSE publishes information through attributes on the rootDSE object. RFC 2251 and RFC 2252 define a set of seven rootDSE operational attributes that LDAP v3 servers are expected to publish, and these attributes are described in the following list. All LDAP servers recognize these attribute names, but when the attribute corresponds to a feature that the server does not implement, the attribute is absent.
supportedLDAPVersion
LDAP versions that the server implements. Domain controllers running Windows 2000 Server and later support LDAP v2 and LDAP v3.
namingContexts
Naming contexts (directory partitions) that this server masters (stores as a writable replica) or shadows (stores as a read-only replica). A client uses this attribute to choose suitable base objects for searching when the client contacts a server.
subschemaSubentry
The name of a subschema entry, which is used to administer information about the schema, in particular, the object classes and attribute types that are supported.
altServer
Uniform Resource Locators (URLs) of other servers that can be contacted when this server becomes unavailable. If the server does not know of any other servers, this attribute is absent. Clients can cache this information in case their preferred LDAP server becomes unavailable. This attribute is absent by default for Active Directory servers.
supportedExtension
Object identifiers that identify the supported extended LDAP operations that the server supports. LDAP extensions include operations such as different query types, paging operations, and sorting methods, which each have a different object identifier. This attribute is absent by default for Active Directory servers.
Note
- A new extended LDAP operation on domain controllers running Windows Server 2003 enables client refresh of a dynamic entry in the directory. Object identifier = 1.3.6.1.4.1.1466.101.119.1 is defined and published in the supportedExtension attribute of the rootDSE object.
supportedControl
Object identifiers that identify the LDAP controls that the server supports. If the server does not support any controls, this attribute is absent. Server controls extend LDAP functionality; examples include a control to move objects across domains and a control to delete an entire subtree of a container object.
supportedSASLMechanisms
The names of the SASL mechanisms that the server supports. SASL is a standard for negotiating an authentication mechanism and, optionally, an encryption mechanism to provide client authorization for accessing Active Directory. By default, Generic Security Service API (GSSAPI) is supported.
rootDSE informational attributes
In addition to the previous operational attributes, Active Directory also supports the following informational attributes.
currentTime
The current time in the generalized time format.
dsServiceName
The distinguished name of the NTDS settings object that represents this domain controller in the configuration directory partition.
defaultNamingContext
The default naming context (directory partition) for a particular server. This value is the distinguished name of the domain directory partition for which this domain controller is authoritative.
schemaNamingContext
The naming context (directory partition) for the forest schema.
configurationNamingContext
The naming context (directory partition) for the forest Configuration container.
rootDomainNamingContext
The distinguished name for the domain naming context (directory partition) of the first domain that is created in this forest. This domain functions as the forest root domain.
supportedLDAPPolicies
Supported LDAP administrative query policies, such as the maximum size of a result set (MaxResultSetSize) and maximum page size (MaxPageSize).
highestCommittedUsn
Highest update sequence number (USN) that is committed to the database on this domain controller.
dnsHostName
The DNS name of this domain controller.
serverName
The fully qualified distinguished name for this domain controller.
supportedCapabilities
The object identifier value (1.2.840.113556.1.4.800) that indicates the additional capabilities of an Active Directory server, such as dynamic update, integrated DNS zones, and LDAP policies.
LdapServiceName
The SPN for the LDAP server, which is used for mutual authentication.
isSynchronized
A Boolean indicator for whether the domain controller has completed its initial synchronization with replica partners.
isGlobalCatalogReady
A Boolean indicator for whether the domain controller is prepared to advertise itself as a global catalog.
domainControllerFunctionality
The numeric level of Active Directory functionality for the domain controller.
Distribution of Directory Data
So that it can scale to tens of millions of objects, the Active Directory data store is logically partitioned in such a way that each domain controller does not store the entire directory. To accomplish logical partitioning, the data is categorized according to a naming scheme: object names group objects into logical categories so that the objects can be managed and replicated appropriately. In Active Directory, the largest of these logical categories is called a directory partition.
Every domain controller holds at least one directory partition that stores domain data, such as users, groups, and OUs. Every domain controller also stores two nondomain directory partitions that store forest-wide data, which includes the schema and configuration data.
The data store holds data for a single forest. Although there is a single directory, some directory data is distributed within domains, while other data is distributed throughout the forest without regard for domain boundaries. In Windows Server 2003 and later, 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 |
|
Forest-wide data |
|
Application data |
|
Directory Partition Hierarchy
In Active Directory, a directory partition is a portion of the directory namespace. Each directory partition contains a subtree of the directory objects in the directory tree. The same directory partition can be stored as a replica on many domain controllers, and the replicas are updated through directory replication.
There is an important distinction between the physical storage of a directory partition and its logical position in the directory tree. Physically, all objects are stored in a single database table, regardless of the directory partition to which they are assigned because of their object names. Logically, the head of a directory partition appears in the naming hierarchy as the topmost object; that is, the Domain container, the Configuration container, and the Schema container each has a distinguished name that identifies its position in the hierarchy.
Every domain controller stores a replica of a domain directory partition, the configuration directory partition, and the schema partition. For more information about these partitions, see “Directory Partitions” later in this section.
Note
- Although the schema directory partition is replicated to every domain controller in the forest, it can be updated only on the domain controller that holds the schema operations master role.
The following figure is a conceptual diagram of the directory tree hierarchy, including the directory root (rootDSE) and the default directory partitions below the directory root. TherootDSE represents the top of the logical namespace for one domain controller and, as such, it represents the top of the LDAP search tree. There is only one root for a given directory, but the information that is stored in the root is specific to the domain controller to which you connect.
In any Active Directory forest, the first domain directory partition that is created in the forest (the forest root domain), the configuration directory partition, and the schema directory partition always form the hierarchy that is illustrated in the following figure.
Default Active Directory Partitions
.gif "Default Active Directory Partitions")
Additional directory partitions are possible in the form of application directory partitions, but these partitions are not stored by default on every domain controller.
Directory Partition Cross-Reference Objects
When Active Directory is installed to create the first domain controller in a new forest, the three directory partitions that are shown in the previous figure are created on the domain controller. At this time, a cross-reference object (class crossRef) is created for each directory partition in the Partitions container in the configuration directory partition (CN=partitions,CN=configuration,DC=forestRootDomain). Creation of each subsequent directory partition in the forest, either by installing Active Directory to create a new domain or by creating a new application directory partition on an existing domain controller, initiates the creation of an associated cross-reference object in the Partitions container.
Note
- You can also manually create a cross-reference object for an application directory partition.
A cross-reference object identifies the name and server location of each directory partition in the forest. The replication system uses this information to identify servers that store the same directory partitions. LDAP queries use cross-reference objects to create referrals to different domains.
Forest Root Domain
Because the forest root domain is the first domain that is created in a forest, it is the root name in the domain namespace hierarchy. In naming only, the topmost object of the configuration directory partition — the Configuration container — is the child of the forest root domain object in the hierarchy. The LDAP distinguished name of the Configuration container (CN=configuration,DC=forestRootDomain) reflects this naming hierarchy, which links the configuration directory partition to the forest.
Similarly, the topmost object in the schema directory partition — the Schema container — is the child of the Configuration container. The distinguished name of the Schema container (CN=schema,CN=configuration,DC=forestRootDomain) links the schema to the forest.
Directory Partitions
The Active Directory data store holds three default directory partitions:
The configuration directory partition
The schema directory partition
The domain directory partition
Optionally, the data store may also hold one or more application directory partitions.
Configuration Directory Partition
The configuration directory partition is created initially when the first domain of a forest is created during the installation of Active Directory. Thereafter, it is replicated to every new domain controller that is added to the forest. The configuration directory partition holds information of global interest, for example, the default configuration and policy information for all instances of a given service in the forest.
Note
- Global information should be stored in one of two places: in a child of the Services container or in a child of a site object.
Contents of the configuration directory partition
In Active Directory tools, such as ADSI Edit, the configuration directory partition is represented by a Configuration container. When you open ADSI Edit (Adsiedit.msc) from the Run dialog box, the Configuration container for the forest of the domain to which you are connected is displayed, along with the current domain directory partition and the schema directory partition.
Note
- If you open ADSI Edit with Microsoft Management Console (MMC) (as opposed to opening ADSI Edit from the Run dialog box), you must connect to the directory partition to view it.
The following objects are child containers in the Configuration container.
DisplaySpecifiers
Contains the objects that define different user interfaces (UIs) for each object class in the schema that requires a graphical user interface (GUI), for example, context menus and property pages. The display specification system uses the information that is stored in the display specifiers to form different UIs for administrators and end users. One set of elements can be associated with administrative applications, and a different set of elements can be associated with end-user applications. What you see and what the user sees are different, even though in both cases the UI references the same objects. The display specification system stores information for property sheets, context menus, icons, creation wizards, and localized class and attribute names.
This UI specification occurs at the level of each object class as defined in the schema in classSchema objects. Each classSchema object can have UI display specification information that is uniquely associated with it.
The DisplaySpecifiers container stores other containers that correspond to each locale that is supported. A locale is either a language or a language in combination with a country/region. Windows supports more than 150 locales, such as French (Belgium), Arabic (Saudi Arabia), and so forth. The names of locale containers are the hexadecimal representations of the locale identifiers (LCIDs). For example, the English (United States) locale container is 409.
Display-specifier objects (class displaySpecifier) are named by appending the LDAP Display Name of the class object with the string -“-Display.”. For example, the user class has a corresponding display-specifier object called user-Display. Therefore, when an Active Directory administrative tool displays an object of a particular class, the object is displayed according to information that is contained in the display-specifier object whose name contains the same name as the respective class in the container for the current locale.
Because the Active Directory schema can be modified by creating new classes and attributes or by modifying existing classes, display-specifier objects can be modified to reflect any new UI elements that schema modifications require.
Extended-rights
Stores objects of the class controlAccessRight that can be used by applications to extend standard access control.
ForestUpdates
Stores operation objects that are generated by forest preparation tasks (when you run adprep /forestprep) so that the system can check for the tasks that have and have not been completed when you upgrade the first domain controller in the forest to Windows Server 2003 or later. The child object CN=Operations contains the objects that represent each update operation. These objects are named for the GUID of the operation. The child object CN=Windows2003Update is created to indicate that all adprep operations have run.
LostAndFoundConfig
Provides storage for configuration directory partition objects that are being created in containers that are simultaneously being deleted on another domain controller in the same forest. If, before replication, an object is created in or moved to a location that no longer exists after replication, the “lost” object is added to the LostAndFoundConfig container. A LostAndFound container in each domain directory partition serves the same purpose for domain-specific objects.
NTDS Quotas
Stores objects (class msDS-QuotaControl) that contain object ownership quota assignments for the configuration directory partition. Quotas limit the number of objects that a user (including inetOrgPerson), group, computer, or service can own in a domain directory partition, configuration directory partition, or application directory partition.
Partitions
Stores the cross-references to every directory partition in the forest, including the configuration partition, the schema partition, and all domain directory partitions. These cross-references to directory partitions make referrals to other domains possible during LDAP searches.
Physical locations
Not used in this version of Windows but reserved for future use.
Services
Stores data for various networking services and applications, such as Message Queuing (MsmqServices), public key services, and Routing and Remote Access. In the Windows NT container, the Directory Service object (nTDSService) has attributes that you can use to manage garbage collection intervals and dynamic object Time to Live (TTL). For the most part, however, objects in the Services container do not require administration. Specifically, do not publish application services in this container. Such services are best published in the Program Data container in the domain directory partition.
Sites
Identifies all of the sites in the network, the domain controllers in those sites, and the replication topology. The contents take the form of replication transports, subnets, and the first site and site link that are created, called Default-First-Site-Name and Default-First-Site-Link, respectively.
Well-known security principals
Contains the special identities that are defined by the security system, such as Everyone, Local System, Principal Self, Authenticated User, and Creator Owner.
Schema Directory Partition
The Active Directory schema is stored in the Schema container in the schema directory partition. The schema consists of a set of object classes, attributes, and syntaxes. It also defines rules that ensure that objects are created and modified with consistency. Active Directory contains a default set of classes and attributes that cannot be modified. However, if you have Schema Admins credentials and if schema modification is enabled for the domain controller, you can extend the schema by adding new attributes and classes to represent application-specific classes. These changes are targeted at the domain controller that is the schema master for the forest. Only the schema master stores a writable copy of the schema.
Domain Directory Partition
When you create a new domain, a domain directory partition is created in Active Directory as an instance of the class domainDns*.* A cross-reference object is added for the domain in the Partitions container to advertise the domain’s location in the directory.
Contents of a domain directory partition
The topmost object in each domain directory partition is a domainDns object that is named with the DNS name of the domain.
A domain directory partition is represented by a domain container, and a domain directory partition has the following child containers.
Builtin
Default local group accounts, such as Administrators and Users, that are installed whenever a new workstation, server, or domain controller is set up.
Computers
A default storage area for “new” computer objects that were originally created through legacy APIs. When a Windows NT 4.0 domain or a Windows NT 3.51 domain is upgraded to Windows 2000, or when a Windows NT 4.0 domain is upgraded to Windows Server 2003 or later, 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 or later domain has a domain functional level of Windows Server 2003 or later, the default location for computer accounts can be specified as an OU to redirect the location of newly created computer objects.
Domain Controllers
The default container for new domain controllers. The Domain Controllers container cannot be renamed.
ForeignSecurityPrincipals
Proxy objects for security principals that are from Windows NT 4.0 domains or Windows NT 3.51 domains, or that are from different forests, and that have been added to Windows 2000 or later groups.
LostAndFound (advanced features)
A storage area for new domain objects whose containers were deleted elsewhere at the same time that the object was created. If an object has been created in or moved to a location that is missing after replication, the “lost” object is added to the LostAndFound container. The LostAndFoundConfig container in the configuration directory partition serves the same purpose for forest-wide objects.
NTDS Quotas (advanced features)
A storage area for objects of the class msDS-QuotaControl that contain object ownership quotas for the domain directory partition. Quotas limit the number of objects that a user, group, computer, or service can create in a directory partition.
Program Data (advanced features)
An empty container that is available for applications to store application-specific data in the domain directory partition.
System (advanced features)
Built-in system settings for the various system service containers and objects.
Users
A default storage area for new user accounts created through legacy APIs that are not Active Directory–aware. When a Windows NT 4.0 domain or a Windows NT 3.51 domain is upgraded to Windows 2000 or later, or when a Windows NT 4.0 domain is upgraded to Windows Server 2003 or later, 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 or later domain has a domain functional level of Windows Server 2003 or later, the default location for user and group accounts can be specified as an OU to redirect the location of newly created user objects.
Note
- The Users and Computers containers and several other special containers, called “well-known” containers, can be located dependably by applications.
Deleted Objects
A special container, which is not visible in the UI, to which objects are moved when they are deleted. The deleted objects are stored as tombstones, which are eventually removed by garbage collection. The contents of the Deleted Objects container are visible if you search by using the 1.2.840.113556.1.4.417 control, which enables you to see deleted objects.
Infrastructure
An object of class infrastructureUpdate that identifies the NTDS Settings object of the domain controller that holds the infrastructure operations master role for the domain.
Contents of the System container
The System container stores per-domain operational information, which includes the default local security policy, file link tracking, Microsoft NetMeeting network meeting objects, objects representing other trusted domains, and containers for RPC and Windows Sockets (Winsock) connection points.
The System container has the following child containers.
AdminSDHolder
Administrator security descriptor holder. Windows Server 2003 and later implements protection of administrative groups through a background task that computes the set of memberships and checks whether their security descriptors are well-known protected security descriptors. If the security descriptor of any administrative account does not match that of AdminSDHolder, the security descriptor is overwritten with the security descriptor of AdminSDHolder. This task is executed only on the domain controller that holds the primary domain controller (PDC) emulator operations master role.
COMPartitions
A namespace that is used by Component Services to allow multiple versions of the same COM+ application to exist on the same physical computer.
ComPartitionSets
A conceptual collection of COM+ partitions.
Default Domain Policy
The common domain location for the AppCategories container (class classStore), which holds objects of the class categoryRegistration. These objects are managed by the Group Policy Software Installation MMC extension, and they can be associated with applications that are deployed through Group Policy in the domain.
Note
- The Group Policy object (GPO) for the default domain policy is stored in the Policies container.
Dfs-Configuration
Lists the fault-tolerant Distributed File System (DFS) configuration and DFS volume information.
DomainUpdates
Stores operation objects that are generated by domain preparation tasks (when you run adprep /domainprep) so that the system can check for tasks that have and have not been completed when you upgrade the first domain controller in the domain to Windows Server 2003 or later. The child Operations object contains the objects that represent each update operation. These objects are named for the GUID of the operation. The child Windows2003Update object is created to indicate that all adprep operations have run.
File Replication Service
Lists the Domain System Volume (SYSVOL) and provides a replication schedule from Sunday through Saturday, 12:00 A.M. to 12:00 A.M.
FileLinks
Used by the Distributed Link Tracking Server service (TrkSvr) to store information about linked files that have moved across NTFS volumes. Includes ObjectMoveTable, which tracks moved files, and VolumeTable, which maps volume IDs to computer IDs.
IP Security
Contains the Internet Protocol security (IPSec) policies that are applied to local computers, domain member servers, domains, OUs, or any GPO in Active Directory. Depending on your organization’s guidelines, IPSec policies can store multiple security specifications, called rules, so that one policy can be applied to multiple computers. These rules apply to all users who log on to the computer
Meetings
A folder that is used by Microsoft NetMeeting to publish network meeting objects.
MicrosoftDNS
A container in which Active Directory–integrated zone database records are created when the scope of replication is all domain controllers in the domain. When DNS data is stored in Active Directory, each DNS zone is an Active Directory container object (dnsZone). The dnsZone object contains a dnsNode object for every unique name in that zone. The dnsNode object has a dnsRecord multivalue attribute that contains a value for every resource record that is associated with an object’s name. When the scope of replication of DNS data is all DNS servers in the domain or all DNS servers in the forest, DNS zone data is stored in application directory partitions, not in the domain directory partition.
Policies
Contains GPOs, which specify user and computer configurations for groups of users and computers. This container stores the default domain policy (lists the security groups and default permissions for the domain); default domain controller policy; and policy for passwords, lockouts, Kerberos, EFS data recovery, and trusted root certificates. Each GPO in the Policies container is identified by a GUID, and each GPO includes the following:
Version information that is used to ensure that information is synchronized with Group Policy template information
Status information that indicates whether the GPO is enabled or disabled
A list of components, or extensions, that have settings in the GPO
In addition to being stored in the Policies container, GPOs are also stored in a Group Policy template, and they are identified by GUID. The Group Policy template is located in the SYSVOL, and it is used to store file type data for the GPOs.
RAS and IAS Servers Access Check
Verifies permissions for the RAS and IAS Servers domain local security group to access user account properties. When Routing and Remote Access (configured for Windows authentication) or Internet Authentication Service (IAS) queries a domain controller to validate user account credentials and receives a failure notification, there is no indication why the failure occurred. It might have occurred because the user’s credentials were invalid or because the server running Routing and Remote Access or IAS did not have the appropriate permissions to access user account properties. Routing and Remote Access and IAS servers obtain access to user account properties by adding the computer account of the server to the RAS and IAS Servers group. The RAS and IAS Servers group has Read permission to the RAS and IAS Servers Access Check container. By attempting access to the RAS and IAS Servers Access Check container, the Routing and Remote Access or IAS server determines whether or not it has permissions to access user account properties.
RpcServices
Includes the RPC name service lookup for domains using versions of Windows earlier than Windows 2000.
WinsockServices
Winsock services that publish themselves by using the registration and resolution (RnR) APIs are published in this container.
WMIPolicy
Stores Windows Management Instrumentation (WMI) filters. A WMI filter is a query based on configuration and event information that is made available by WMI providers. By associating a WMI filter with a specific GPO, that WMI filter determines which computers process policy settings in that GPO. Computers that meet all of the conditions that are specified in the WMI filter return a value of TRUE and then process the GPO.
Application Directory Partitions
Application directory partitions are special partitions that can be created on domain controllers running Windows Server 2003 or later 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 or later forest, application directory partitions provide storage for nondomain, application-specific data that can be replicated to any arbitrary set of domain controllers in the forest — as few or as many as needed by the application that uses the data.
Note
- Applications must be specifically programmed to use application directory partitions.
Characteristics and requirements
Application directory partitions have characteristics that make them suitable for storing dynamic data (data that is updated frequently) or volatile data (data that has a specified useful lifetime), as opposed to more static data that domain directory partitions and other directory partitions store. Although application directory partitions are represented as instances of the domainDNS class, as are domain directory partitions, they have characteristics that differentiate their behavior from domain directory partitions.
Note
- Applications can create application directory partitions on Windows Server 2003 or later based domain controllers by explicitly creating a domainDNS object. Only Windows Server 2003–based and later domain controllers allow creation of domainDNS objects by means other than Active Directory installation. Because Windows 2000 Server and earlier domain controllers do not recognize the request to create a domainDNS object, no special instance type is required to differentiate between application directory partitions and domain directory partitions.
Similarities to domain directory partitions
The following characteristics of application directory partitions are the same as the characteristics of domain directory partitions:
Naming: Application directory partitions can be named in the same manner as domains, and they can be attached anywhere in the Active Directory namespace where a domain can be attached. Therefore, an application directory partition can be a child of a domain or of another application directory partition.
DNS location: Application directory partitions can be discovered through DNS.
Cross-reference object: A cross-reference object is created in the CN=partitions,CN=configuration,DC=ForestRootDomain container for each application directory partition.
Change notification for replication: The time intervals that control the latency of the initiation of an originating change notification to replication partners within a site can be configured. These configuration changes are applied to all directory partitions, but they are most useful for application directory partition replication of dynamic data.
Access control: The security and access control model for the application directory partition is the same as that for other partitions in Active Directory.
TTL: For objects that are stored in an application directory partition, you can assign a TTL value that is configurable. The only requirement is that the domain controller is running Windows Server 2003.
For objects that are stored in a domain directory partition replica on a Windows Server 2003–based or later domain controller in a forest that has a forest functional level of Windows Server 2003 or later, you can assign a TTL. For all other functional levels, however, TTL values cannot be assigned to objects in domain directory partitions.
Differences from domain directory partitions
The following characteristics are different from domain directory partitions and specific to application directory partitions:
Credentials for creation: Creating an application directory partition requires Domain Admins credentials in the forest root domain or Enterprise Admins credentials.
Replication scope: Whereas domain directory partitions are replicated to every domain controller in a domain, application directory partitions can be replicated to any selected set of domain controllers in the forest. Because application directory partitions do not have domain or site affiliations, either an administrator or the application that creates the directory partition must explicitly define the scope of replication.
Note
- It is best to store replicas of dynamic data on domain controllers in the same site because intersite replication latency might not be acceptable for replica consistency.
NetBIOS name: Application directory partition objects do not have network basic input/output system (NetBIOS) names. For this reason, their cross-reference objects, which are usually identified by the unique NetBIOS names of their respective directory partitions, are named by GUIDs.
Contents: Security principals (users, groups, services, and computers) cannot be stored in application directory partitions.
Global catalog: Application directory partitions are not replicated to the global catalog.
Volatility: Whereas domain data should be relatively static, application directory partition data can be volatile, such as the real-time data that is used by Microsoft Telephony API (TAPI) voice conferencing applications.
Stored objects
Any type of object, with the exception of security principals, can be stored in an application directory partition. In addition, objects that reside in an application directory partition:
Can maintain distinguished-name references to other objects in the same application directory partition, objects in the configuration and schema directory partitions, and any directory partition root object.
Cannot maintain distinguished-name references to objects in other application directory partitions or in domain directory partitions.
Cannot be moved to other Active Directory partitions outside the application directory partition in which they were created.
Applications can be programmed to store their dynamic data in application directory partitions. The following are examples of applications and the kinds of dynamic objects that they store:
Real-time communication applications: These types of applications typically maintain rendezvous information about active users (user name, computer, and IP address) and conferences in progress (conference name, description, time, and originator).
Network services: Routing and Remote Access, Remote Authentication Dial-In User Service (RADIUS), Dynamic Host Configuration Protocol (DHCP), and Common Open Policy Service (COPS) servers need to store dynamically changing forms of data in a directory so that they can be accessed using one uniform method: LDAP. This data generally does not require global replication, and it is also shared by many applications in the proximity of a single directory. (In this case, the data is shared between RAS, RADIUS, DHCP, and COPS servers in a particular site.) The object types include information about user sessions and bandwidth used.
Directory-enabled networking: For implementing policy-based networking, there is a large amount of nonstatic, or volatile, information that must be maintained, including information about the state of network links, the flows that are active through a router, and the data rate for each flow. Policy servers might need access to such information to make a decision based on policies that are predicated on dynamic network state in addition to static data that is stored in the directory.
The application directory partition, with its controlled replication scope, can accommodate transient data needs in Active Directory by providing network applications with uniform and consistent access through LDAP to both static and dynamic data.
Security descriptor reference domains
When an object is created in Active Directory, it is assigned a security descriptor that contains default access control entries (ACEs) that are taken from the defaultSecurityDescriptor attribute of the class of which the object is an instance. The default ACEs can include domain-relative, well-known SIDs. In the case of objects in a domain directory partition, the reference domain by which the system interprets the domain-relative SIDs is the domain that is represented by the domain directory partition.
In the case of an application directory partition, there is no security association between the application directory partition and the domain of the domain controller on which it is created. In a Windows Server 2003 or later forest, a new, single-valued attribute on the cross-reference object — msDS-SDReferenceDomain — stores the name of the reference domain that is used to interpret the domain-relative SIDs in default ACEs for new objects in an application directory partition.
When an application directory partition is created, the value of msDS-SDReferenceDomain on the respective cross-reference object is determined as follows:
If the parent object of the application directory partition is another application directory partition, the value of msDS-SDReferenceDomain is set to the value of msDS-SDReferenceDomain on the cross-reference object of the parent application directory.
If the parent object is a domain directory partition, the value of msDS-SDReferenceDomain is set to the parent domain.
If there is no parent object, the value of msDS-SDReferenceDomain is set to the forest root domain.
Note
- It is recommended that domain local groups not be used in the access control lists (ACLs) of objects in application directory partitions. If an application directory partition has replicas on domain controllers in two different domains, the membership of such domain local groups in ACLs can expand to yield different results, depending on the domain controller to which a user connects.
GUID names for cross-reference objects
Domains in Active Directory must have NetBIOS names that are unique in the forest so that they are backward compatible with computers that are running earlier versions of Windows. Domains must also have DNS names that are unique. The relative distinguished name of the cross-reference object for each domain directory partition is taken from its NetBIOS name, which guarantees that each cross-reference object is unique within the Partitions container. For example, if a domain has a NetBIOS name of CONCORP and a fully qualified DNS domain name of concorp.contoso.com, the distinguished name of its cross-reference object is CN=concorp,CN=partitions,CN=configuration,DC=contoso,DC=com. The domain component (DC) of the cross-reference object distinguished name is always the forest root domain, which is always the parent of the configuration directory partition. If there were another domain in the same forest named concorp.avionics.contoso.com, this domain would necessarily be given a NetBIOS name other than CONCORP (for example, CONCORPAV).
In the case of application directory partitions, there is no associated NetBIOS name, only the DNS name. Given the nature of DNS hierarchical naming, which allows identical left-most name components, a cross-reference object cannot use the left-most DNS name component as its relative distinguished name. For this reason, cross-reference objects that reference application directory partitions use their object GUID as their relative distinguished names.
To associate a cross-reference object with its application directory partition, you can read the nCName attribute of the cross-reference object, which gives the distinguished name of the directory partition.
Data Store Physical Structure
The physical structure of the data store consists of the Active Directory database file (Ntds.dit) and its associated log and temporary files. The data that is held in the database file includes both static data and dynamic data. The following figure illustrates the physical structure of the data store.
Data Store Physical Structure
.gif "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 Database
Active Directory data is stored in the Ntds.dit database file. The Active Directory database (Ntds.dit) contains three internal tables, the data table, link table, and SD table, which are described in the following sections.
Two copies of Ntds.dit are present in separate default locations on a domain controller, systemroot\NTDS and systemroot\System32:
systemroot\NTDS\Ntds.dit stores the database that is in use on a domain controller. It contains the values for the domain and a replica of the values for the forest (the Configuration container data).
systemroot\System32\Ntds.dit is the distribution copy of the default directory that is used when you install Active Directory on a server running Windows Server 2003 or later to create a domain controller. Because this file is available, you can run the Active Directory Installation Wizard without having to use the server operating system CD.
Data Table
The data table contains all the information in the Active Directory data store: users, groups, application-specific data, and any other data that is stored in Active Directory after its installation. The data table can be thought of as having rows (each representing an instance of an object, such as a user) and columns (each representing an attribute in the schema, such as GivenName). For each attribute in the schema, the table contains a column, called a field. Field sizes can be fixedor variable. Fixed-size fields contain an integer or long integer as the data type. Variable-size fields typically hold string types, for example, Unicode strings. The database allocates only as much space as a variable-size field needs: 16 bits for a 1-character Unicode string, 160 bits for a 10-character Unicode string, and so on.
The database space that is used to store an object depends on the number of attributes for which values are set and the size of the values. For example, if the administrator creates two user objects (User1 and User2), sets only the minimum attributes on them, and then later adds a 10-character description to User2, the User2 space is approximately 80 bytes bigger than the User1 space (20 bytes for the 10 characters, plus metadata on the newly generated attribute).
Database records cannot span database pages; therefore, each object is limited to 8 kilobytes (KB). However, some attribute values of an object do not count fully against this limit. Long, variable-length values can be stored on a different page than the object record, leaving behind only a 9-byte reference. In this way, an object and all its attribute values can be much larger than 8 KB.
Link Table
The link table contains data that represents linked attributes, which contain values that refer to other objects in Active Directory. An example is the MemberOf attribute on a user object, which contains values that reference groups to which the user belongs. The link table is much smaller than the data table.
SD Table
The SD Table contains data that represents inherited security descriptors for each object. With the introduction of the SD table in Windows Server 2003 or later, inherited security descriptors no longer have to be duplicated on each object that inherits security descriptors. Instead, inherited security descriptors are stored in the SD table and linked to the appropriate objects.
Log Files
The Active Directory data store includes the log files that are described in the following table. For information about how these log files are used, see “Logging Transactions to Enable Log-based Recovery” later in this section.
Log Files
| File | Description |
|---|---|
Edb.log |
This file stores directory transactions before they are written to the Ntds.dit directory database file. This file has a fixed size of 10 megabytes (MB). |
Edb00001.log, Edb00002.log, 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 Requirements
The minimum space requirements for the directory database and log files — and the requirements for which monitoring is essential — are free disk space on the partition or partitions that store the directory database and logs, as follows:
Ntds.dit partition and log file partition: On either partition, free disk space must not fall below the greater of 500 MB or 20 percent of the combined Ntds.dit and log file sizes.
Ntds.dit and log files on the same volume: Free disk space must not fall below the greater of 1 gigabyte (GB) or 20 percent of the combined Ntds.dit and log file sizes.
Objects and Capacity
There are no practical limits to the number of objects that can be stored in Active Directory. The Active Directory database has been tested for up to 60 million objects. Performance tests show logon performance for a single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1 million objects; that is, the directory service does not slow measurably when the size of the database increases.
Note
- In a mixed environment in which backup domain controllers (BDCs) are running Windows NT 4.0, the recommended limit for the number of security principal objects per domain is 40,000 (the sum of users, groups, and computers). This limit is based on the Windows NT 4.0 SAM database storage capacity.
Maximum Database Record Size
The maximum size of a database record is 8110 bytes, based on an 8-kilobyte (KB) page size. Because of variable overhead requirements and the variable number of attributes that an object might have, it is impossible to provide a precise limit for the maximum number of multivalues that an object can store in its attributes. For all practical purposes, the size of objects is not significant in Active Directory 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 and later. When the forest has a functional level of Windows Server 2003 or higher, 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 and later.
Active Directory Data
The key characteristics of data that is stored by any directory service are size and latency. A directory service should store objects that are not so large that they hamper replication. Therefore, large unstructured data sets are not appropriate for storage in Active Directory. Domain data and configuration data are typically static in nature, having a useful lifetime at least as long as a single period of replication latency.
In a Windows 2000 Server forest, Active Directory does not support storage of nonstatic (dynamic or volatile) data. In a Windows Server 2003 or later forest, however, Active Directory can store nonstatic data in application directory partitions, which can be configured for limited replication or used as real-time data stores for data that is too volatile for replication.
Static Data
Active Directory is appropriate for the storage of static data that has the following characteristics:
The data is globally useful information in the domain that needs to be replicated to each Active Directory domain controller.
The data has well-defined object attributes and semantics.
The data has a useful life that is at least two times the maximum replication latency for the forest, including replication of data that is marked to replicate to the global catalog. In general, if data can become outdated before the completion of a replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be able to tolerate the inability to update data for at least as long as it takes for the data to be replicated throughout the domain.
The data-per-attribute value is not so large that it affects performance. Most attribute values are replicated as a single block of data; therefore, an attribute that is x MB in size requires an equivalent amount of buffer space in the sending domain controller and in the receiving domain controllers. If the amount of required buffer space is large, the performance of the domain controllers can be affected adversely.
Attributes can have large values when the attribute is multivalued and linked. For these attributes, only the values that change are replicated, not the entire attribute.
Dynamic Data
An object that has a TTL value is considered to be dynamic data. Windows Server 2003 introduces a new auxiliary class, dynamicObject, that can be attached to object instances for the storage of TTL values. For an object containing a TTL value, when the time that is specified by the TTL value is reached, the object is automatically removed from Active Directory by garbage collection. Dynamic data typically changes faster than the replication latency that is required for propagating the change to all replicas of the data.
The following characteristics apply to dynamic data:
A dynamic object that is deleted as a result of expiration of its TTL does not leave a tombstone.
Dynamic objects are treated in the same manner as nondynamic objects during search, compare, add, delete, and modify (including rename) operations.
A nondynamic object, after it is created, cannot be changed to a dynamic object. Likewise, a dynamic object, after it is created, cannot be changed to a nondynamic object.
A nondynamic object cannot be added in a subordinate position to a dynamic object.
Dynamic objects with TTL values are supported in the following directory partitions:
Domain directory partitions at the Windows Server 2003 or higher forest functional level
Application directory partitions on a Windows Server 2003 or higher–based domain controller, irrespective of domain or forest functional level
Dynamic objects are not supported in configuration directory partitions or schema directory partitions.
TTL for dynamic objects
The TTL for a dynamic object is set when the object is created, and it is automatically decremented thereafter. When its TTL expires, the dynamic object disappears without leaving a tombstone. However, a client application can programmatically cause a dynamic object to remain longer than its current remaining lifetime by refreshing (modifying) its TTL value, as stored in the entryTTL attribute on the object.
The Directory Service object (nTDSService) in the Configuration container (CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC= forestRootDomain) stores the default and minimum dynamic object TTL values for the forest in the multivalue attribute msDS-Other-Settings.
The default values for the two configurable TTL parameters are as follows:
Default TTL value = 86400 seconds (1 day)
Minimum TTL value = 900 seconds (15 minutes)
The default TTL value is assigned to a newly created dynamic object if a TTL is not explicitly specified by the application that creates the object. The minimum TTL overrides any client-specified TTL value that is lower than the configured minimum. No configurable maximum TTL value needs to be provided, because a maximum is imposed by the attributeSchema object.
The syntax for the two configurable TTL parameters is as follows, where NNNN is expressed in seconds:
DynamicObjectDefaultTTLSeconds=NNNN
DynamicObjectMinTTLSeconds=NNNN
By configuring these values, you can set TTL values that enforce a low level of refresh traffic or, conversely, provide a highly up-to-date directory.
Data Store Processes and Interactions
The Active Directory data store performs a number of processes and interactions that are important to the functioning of Active Directory. The following sections describe these processes and interactions.
These descriptions make the following assumptions regarding the environment in which the Active Directory data store is running:
The disk volume on which the directory database is stored contains ample free space.
Network connectivity on the domain controller is functioning properly.
Database Operations
Data operations (such add, modify, and delete) are committed to the Active Directory database as transactions, which are the units of work that are performed by a database. Transactions are atomic; that is, they are either completed in full or not applied at all. If for any reason an error occurs and a transaction is unable to complete all of its steps, the system is returned to the state that existed before the transaction began. An example of an atomic transaction is an account transfer transaction in which money is removed from account A and placed into account B. If the system fails after it removes the money from account A and before it places the money into account B, the transaction processing system puts the money back into account A and returns the system to its original state; that is, the transaction processing system rolls back the transaction.
In Active Directory, operations on a single object cannot be applied across multiple objects. Active Directory writes a transaction synchronously to the transaction log file and then to the database. First, a change is made to an in-memory copy of the object. Then, the change is written to the log file, which ensures that the change takes effect, even if the database shuts down after that point. The database engine continually updates the database file with recent changes. The database update works from memory — not from the log files — and it keeps pace with the updates, rather than waiting for the server to be available. This method of performing updates is referred to as “advancing the checkpoint,” where the checkpoint is the point in time at which all changes that have been made so far have been fully written to the database.
LDAP Functional Model
Database operations in Active Directory are based on the LDAP functional model. The LDAP functional model includes support for common database operations, such as connecting to a directory database, searching for data, and modifying data. An LDAP client connects to Active Directory and requests information or performs an operation. Active Directory performs the operation or provides the information, or it refers the client to another LDAP server that might be able to do so.
Nine operations form the LDAP functional model. These operations are grouped into three areas:
Authentication. Enables the client to prove its identity to the DSA:
Bind
Unbind
Abandon
Interrogation. Enables the client to interrogate the directory and retrieve information:
Search
Compare
Update. Enables the client to update information in the directory tree:
Add
Delete
Modify
Modify relative distinguished name
A typical LDAP client application interacts with Active Directory through the operations that are described in the following sections.
For more information about LDAP, see “Lightweight Directory Access Protocol (LDAP)” in the Microsoft Platform SDK on MSDN.
Establishing a connection
When an LDAP client connects to Active Directory, an LDAP session is established. Options are available to affect the way in which the connection is established. These options include setting a time-out value, connecting to a secure LDAP server, and verifying that a server is available.
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope. LDAPMessageis encapsulated in the Protocol Data Unit (PDU) format. LDAPMessage consists of protocol operations, such as LDAP Bind Request, LDAP Bind Response, LDAP Search Request, and LDAP Search Response operations.
LDAPMessage PDUs are mapped directly to the TCP data stream. Active Directory clients use the following LDAP ports:
Port 389. In accordance with RFC 2251, Active Directory uses port 389 as the default port for domain controller communications.
Port 636. Active Directory supports port 636 for LDAP Secure Sockets Layer (SSL) communications.
Port 3268 and port 3269. The global catalog monitors port 3268 for LDAP communications and port 3269 for LDAP SSL communications.
Modifying a directory object
The LDAP API contains functions for adding and deleting directory objects and for comparing and modifying attribute values in existing objects. LDAP v3 provides extensions to add, delete, and modify functions that enable the use of controls to perform these operations. Controls are described in RFC 2251 as a mechanism to extend the functionality of LDAP. Windows Server 2003 and later 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 2000 Server and later as new LDAP v3 control extensions for processing search results on the server.
Closing the connection (unbinding)
Unbinding closes the connection between the directory client and the DSA and disposes of the session handle. Applications call the unbind function when an LDAP client finishes communicating with a server. There is no server response to an unbind request.
Logging Transactions to Enable Log-based Recovery
To maximize system efficiency and ensure data integrity, Active Directory uses “write ahead” logging. With “write ahead” logging, transactions are written as quickly as possible to a transaction log file, and they are then written to the Ntds.dit database file as the system has time or at system shutdown.
The log file that is used by Active Directory to record transactions is called Edb.log, which has a fixed size of 10 MB. When this log file becomes full, Active Directory automatically creates a new log file, for example, Edb00001.log, which also has a fixed size of 10 MB. Active Directory continues to create additional log files as they become necessary. Through circular logging, the oldest log file is purged when all transactions in that log have been written to the Ntds.dit database. In addition to the active log files, two reserve log files exist, called Res1.log and Res2.log, ,also with a fixed size of 10 MB. These files reserve the last 20 MB of disk space on the drive to provide room for a graceful shutdown if all other disk space is consumed.
Active Directory also maintains a checkpoint file (Edb.chk) that records which transactions in the log have been committed to the database. In circular logging, log files are deleted when the checkpoint advances past the last transaction that is included in that log file. The checkpoint cannot be advanced past the beginning of any transaction that is still open.
If the computer stops responding, the ESE can detect an improper shutdown by checking the last log recorded. If the last record is not a “shutdown” record, the ESE reprocesses the logs from the checkpoint that is stored in Edb.chk. This event occurs at the first reboot after the system is shut down improperly. If the checkpoint file is missing for any reason, every transaction within the log file is reprocessed.
The number of log files that exist at any point in time is related to the number and size of transactions that are running in the database. If a system is idle, you can expect to see one log file. If a domain controller is making large changes (for example, replicating a 5,000-member group), you can expect to see several log files. If you just edited the schema to define an index on an attribute that has many large data values, you might see hundreds of log files. (The checkpoint cannot be advanced until the index creation is completed.)
Growth and Space Management
The directory database is a self-maintained system in which growth is managed by periodically compacting data and reorganizing free space into contiguous pages. Other than regular backup, the directory database requires no maintenance during ordinary operation. The only requirement is adequate space to accommodate normal growth.
The directory database grows when more data is added to it than free space is available to accommodate the new values. Free space, also called “white space,” is managed automatically by the directory database. Conditions under which free space is made available to the database can affect database size, sometimes in ways that are not expected. For this reason, an understanding of how free space is managed can help provide correct interpretation of changes in the size of the directory database file. The following sections describe space allocation and free space reclamation.
Space Allocation
Space is allocated hierarchically in the directory database, with the database at the top of the hierarchy. Object tables are children of the database. Each table has a child long-value table, and each table can have child indexes. The long-value table stores values that are too large for the main object table. Security descriptors are examples of values that are often large enough to require storage in the long-value table.
As objects are deleted and values are replaced with smaller values, free space is returned to the database. However, there is no optimum or target amount of white space to be maintained. The amount of unused space in the directory database is of concern only when monitoring indicates that free disk space is becoming limited. You can configure a domain controller to log an event that reports the amount of unused space in the directory database that can be reclaimed by offline defragmentation.
Requesting space
The database can use free space if the space is available to the table or index that needs it and if the space occurs in blocks that are large enough to accommodate the transaction. When an index or table requires additional space, it can request space only from its parent. For example, the available space in an index cannot be used by another index. If the parent table requires space, it must request space from the database. If space is not available at the database level to complete the request, the database increases its size to accommodate the transaction.
Space consumption by indexes
The estimated space that is required for adding an index to an attribute is rarely greater than 1 percent of database size. However, Tuple indexes, which index an attribute in a way that allows users to search the attribute by using partial text strings, can be quite large. To provide partial text string searching, a Tuple index includes one entry for each substring of a Text or Long Text column, with a minimum and maximum length allowed for the substrings that are indexed. Although Tuple indexes can dramatically speed queries of the form “find all records that contain string value,” they can potentially increase database size by as much as 20 percent, and they should be used with caution.
Storing data
Objects are stored in records that are written to 8-KB data pages. The maximum record size is 8110 bytes, with the exception of long-value columns, which can be up to 2 GB. As values are deleted, space that is freed by transactions is returned to the table that owns the space. Free space is returned gradually in small segments, and it is periodically reorganized into contiguous pages through an automatic process called online defragmentation.
Data pages are filled with records in an ordered fashion. For example, all records beginning with A must be stored in the page that is designated as storing the values that range from A to some other value. For example, given pages A-E and F-J, if a value corresponds to the A-E page and that page is full, the value cannot be stored in the F-J page, even if space is available. Instead, one or more new pages are added. When a table grows, it grows in increments equal to one-fourth its initially allocated size.
In this way, Active Directory data storage optimizes lookup speed as opposed to storage space. However, because of the hierarchical means of allocating free space and the order that is required for filling data pages, free space that is present in the database is not always available for use.
Free Space Reclamation
The version store is the area of the database that manages version control. When a transaction is committed to the database, a cleanup process returns space that is freed by modify and delete transactions to the database. For each modify or delete operation, the existing version of the record is written to the version store so that the database maintains a copy of the old version until the new version is written to the database. After the transaction is committed to the database, any space that is freed from deleted records and long values is returned to the table or index that owns the space. Until the change is committed to the database, requests for the object continue to access the old version. If the transaction is rolled back, the version store record is used to undo the transaction.
The version store has a size limit that is the lesser of the following: one-fourth of total random access memory (RAM) or 100 MB.
Because most domain controllers have more than 400 MB of RAM, the most common version store size is the maximum size of 100 MB. If too many large changes or deletions occur simultaneously, it is possible for the version store to run out of processing space. In this event, cleanup of free space is suspended temporarily. On domain controllers running Windows 2000 Server, the most common cause of version store overload is large-scale bulk deletions.
Bulk deletions and database growth in Windows 2000
Delete operations are the most CPU-intensive operations that the version store processes. On domain controllers running Windows 2000 Server, bulk deletions, such as the deletion of an entire tree of objects at one time, can cause a temporary condition in which free space cannot be returned to the database in a timely fashion because the cleanup process cannot keep up with the deletions. Event ID 602 is logged in the Directory Services event log to indicate this condition.
During the time that pages are being skipped by the cleanup process, free space is not released to the database, and space is not reclaimed until the next scheduled online defragmentation occurs. In the meantime, processing requirements can cause the database to grow. In particular, when bulk deletions or other bulk changes coincide with database additions, significant growth can occur. In addition, space from the deletion of long values is not returned to the database by online defragmentation. As a result of these conditions, the directory database on domain controllers running Windows 2000 Server can actually increase in size following a bulk deletion.
On domain controllers running Windows Server 2003 or later, the effects of these conditions are greatly reduced by improvements in version store cleanup and online defragmentation. However, if event ID 602 is logged in the Directory Services event log, running online defragmentation manually can alleviate the problem. On domain controllers running Windows 2000 Server, the only way to prompt online defragmentation is to change the garbage collection interval to the minimum value of one hour to force garbage collection and online defragmentation to occur as soon as possible.
Improved space processing in Windows Server 2003 and Later
Two improvements in the Windows Server 2003 and later 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 and later 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 or later.
In addition, online defragmentation on domain controllers running Windows Server 2003 or later returns the space that is freed by long values to the long-value table, which further optimizes the availability of space in the database.
Bulk Changes and Inheritable Security Descriptors
In addition to bulk deletions, large-scale bulk changes can cause database growth, particularly on domain controllers running Windows 2000 Server. The most common cause of database growth on domain controllers running Windows 2000 Server is the propagation of inherited security descriptor changes in a large directory tree.
Every object in Active Directory has a security descriptor attribute that contains the identification and authorization values that apply to that object. Authorization information takes the form of discretionary access control lists (DACLs) (access information) and system access control lists (SACLs) (auditing information). Because every object has a security descriptor, a security descriptor change that affects every object in a large tree (for example, an entire domain) can significantly affect database size.
How Inheritable Security Descriptors Are Written
The value of the security descriptor attribute changes when a new permission, right, or auditing setting is added or an existing permission, right, or auditing setting is removed from an object’s DACL or SACL by adding, removing, or modifying an ACE. When an inheritable ACE is applied to an object in a directory tree, you can specify the type of object that is affected by the ACE. However, the change is written to every object in the tree, not just to the object type to which the permission, right, or auditing setting applies. The ACE applies to all objects, but it is effective only on objects whose object type matches the object GUID that is specified in the ACE.
This system ensures that the appropriate security descriptor can always be inherited from a parent object. For example, suppose you apply an inheritable ACE at the domain level that applies to all computers. Computers exist in container objects, to which the ACE does not directly apply. However, when you create a computer object in the container, the computer object receives its inherited security descriptor from its parent container. Every object that is within the scope of the inheritance receives the update to the security descriptor.
Security Descriptors in Windows 2000 Server
On domain controllers running Windows 2000 Server, the full security descriptor value is stored for every object. The average size of a security descriptor is 5 KB, and as a result security descriptors can account for 40 percent or more of database size. On domain controllers running Windows 2000 Server, an ACL change that is inherited by a large directory tree (for example, a domain) that contains hundreds of thousands or millions of objects can cause significant database growth. For example, suppose you add 30 ACEs to an inheritable SACL or DACL on the domain object of a domain that has 1,000,000 objects. At an estimated 52 bytes per ACE, each object grows by approximately 1.5 KB. The propagation of this change to 1 million objects results in database growth of 1.4 GB. In the worst-case scenario, the database grows beyond its storage limits, and Active Directory cannot function.
You can use Active Directory administrative tools to manage security settings on Active Directory objects to a high degree of specificity. Significant and unexpected changes to security descriptors can occur during the management of access control and auditing if an administrator does not understand the effects of the changes. The UI provides the ability to select general ACE categories that have prepopulated permissions, but the UI also provides the ability to modify the properties of a general ACE. The effect of editing an existing general ACE on a DACL or SACL by removing one of the properties is the replacement of a single ACE with multiple ACEs, one for each of the permissions that is selected in the modified ACE. On domain controllers running Windows 2000 Server, such a change can cause significant database growth if the modified ACE is inherited to a large tree of objects. For example, if directory services access auditing is enabled and an administrator edits the access to specify only a subset of the activity and objects to be audited, the result is propagation of a separate ACE for each selection to every object in the tree. Given the default settings for the Everyone group in Windows 2000 Server, such a change can result in significant database growth.
Default settings in Windows Server 2003 and later, and the storage of only unique security descriptors greatly decrease the likelihood that such a change can cause unmanageable growth.
Single-Instance Security Descriptors in Windows Server 2003 and Later
On domain controllers running Windows Server 2003 or later, 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 or later, a unique security descriptor is stored only once rather than being stored for every object that inherits it. For every object that inherits the security descriptor or otherwise stores an identical security descriptor, only a pointer is stored. This change eliminates data redundancy and the database growth that can result from changes to inheritable ACEs.
The object itself stores an 8-byte pointer to the appropriate unique security descriptor. Unique security descriptors are stored in memory in a relatively small table. In addition, the information that is required to map these pointers to the respective security descriptor is cached on domain controllers. By using this cached information and the in-memory table of unique security descriptors, domain controllers can match pointers to security descriptors without having to access the database itself. Therefore, checks to establish whether a new security descriptor matches an existing one have no significant impact on domain controller performance.
Note
- When you upgrade a domain controller from Windows 2000 Server to Windows Server 2003, the conversion of duplicate security descriptors to pointers can result in +40 percent of the database size being converted to unused space. Performing offline defragmentation after the upgrade decreases the database size by removing that unused space.
Effect of Object Ownership on Unique Security Descriptors
Having different owners causes objects that would otherwise have the same security descriptor to require several unique security descriptors. For example, if a member of the Domain Admins group creates a container object and sets permissions on the container that are inherited by all child objects, all child objects have the same security descriptor. In this case, only one security descriptor is actually stored in Active Directory; the rest of the objects simply reference that unique security descriptor. However, if objects that are created in the parent container are created by individuals who are not members of the Domain Admins group, those objects have security descriptors that are different from the security descriptors of the objects that are created by members of the Domain Admins group.
Despite the fact that having different object owners requires unique security descriptors, most Active Directory databases contain a relatively small number of user objects in comparison to the number of nonuser objects. In addition, most objects are created by the system and not by individual users. Because duplication of security descriptors far outweighs the potential for different object owners, the positive effect of single-instance security descriptors is not usually lessened to a noticeable degree by multiple object owners.
Storage and Removal of Object Deletions
When data is deleted from Active Directory, the data cannot simply disappear from the directory because the deletion must be replicated. Therefore, instead of deleting an object physically from the database, the directory service removes most of the attributes and then tags the object as a tombstone by setting the isDeleted attribute value to TRUE, which means that the object has been logically deleted from the directory but not yet completely removed. Tombstones are replicated to communicate object deletions. The isDeleted attribute value alerts replication partners that the object has been deleted. Objects that are identified as tombstones are moved to the hidden Deleted Objects container of their respective directory partition. Tombstones remain in the directory for a default period of 60 days, which is referred to as the tombstone lifetime.
Garbage Collection: Permanent Removal of Expired Tombstones
Garbage collection is a housekeeping process that runs on every domain controller to permanently remove expired tombstones from the directory database. Although they represent deleted objects, tombstones take up space in every directory partition replica. Eventually, the tombstones themselves must be deleted to keep the directory database from growing without limit. At regular intervals, objects that are no longer needed by the directory service are deleted as “garbage.”
The garbage collection process:
Deletes tombstones.
Defragments the database file to compact data and optimize free space (triggers online defragmentation).
Garbage collection runs independently on each domain controller. When the garbage collection process occurs, the process finds the set of tombstones whose originating deletion occurred more than a tombstone lifetime ago, and then it deletes each tombstone in that set.
Two attributes of the Directory Service object (nTDSService) in the configuration container (CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=forestRootDomain) control how garbage collection runs and what it removes, as follows:
The tombstone lifetime determines the amount of time that a deleted object lives as a tombstone in the directory before being collected as garbage. This amount of time is set in the tombstoneLifetime attribute. The minimum setting is 2 days. The default setting for this attribute varies according to operating system and forest creation or upgrade, as follows:
Forests that were created on a domain controller running Windows Server 2003 with no service pack installed or any version of Windows 2000 Server: 60 days.
Forests that were upgraded from Windows Server 2003 with no service pack installed or any version of Windows 2000 Server: 60 days.
Forests that were created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1) or later: 180 days.
Note
- You cannot purge tombstones before the expiration of the tombstone lifetime.
The garbage collection interval determines how often a domain controller examines its database for expired tombstones that can be collected. This interval is set in the garbageCollPeriod attribute. The default setting is 12 hours, and the minimum setting is 1 hour.
Note
- The default value for each of these two attributes applies if the attribute is not set (which is the initial state of the system). The minimum value applies if the attribute is set to a value that is below the minimum (that is, if the minimum is not declared in the schema).
The maximum garbage collection interval is one-third of the tombstone lifetime (in hours). For example, if you set tombstoneLifetime to 30 days and garbageCollPeriod to 300 hours, the actual garbage collection period is only 10 days or 240 hours.
Tombstone Lifetime and Active Directory Backup and Restore
Active Directory does not allow a restore from a directory backup that is older than the tombstone lifetime. A restore from backup creates a directory partition replica that has not performed replication since the time of backup (or earlier). If the backup is taken more than a tombstone lifetime before the restore, objects that are deleted in the meantime have no tombstones; therefore, a new directory partition replica that is created by the restore operation never receives these deletions. For this reason, a restore procedure will not restore a backup that is taken more than one tombstone lifetime before the time of the restore. Therefore, it is a recommended best practice to back up Active Directory at least twice during a tombstone lifetime. On domain controllers running Windows Server 2003 with SP1 and later, 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 https://go.microsoft.com/fwlink/?LinkId=44131.
Garbage Collection Scheduling Enhancements
The process for completing garbage collection has changed in Windows Server 2003 and later 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 or later, 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 and later: Rather than waiting a set time to remove a subsequent set of 5,000 tombstones, a domain controller continues deleting tombstones according to CPU availability. If no other process is using the CPU, garbage collection proceeds. Removing tombstones in this way keeps the database size from increasing inordinately as a result of the inability of garbage collection to fully complete removal of all tombstones during a garbage collection interval.
Garbage Collection and Linked Attributes
When an object that has a linked attribute is deleted, although the object itself becomes a tombstone (for example, when a user object is deleted), the referent object (for example, a group object to which the user belonged) does not reference the tombstone of the deleted object. Rather, the group-user link value is simply deleted from the database, and the group object shows no evidence of the former user’s membership.
However, when an object to which a link refers is removed as a referent (for example, when a user is removed from a group), the user value is treated differently by Active Directory in Windows 2000 Server and in Windows Server 2003 and later. In Windows 2000 Server, the entire group member attribute is replicated. In Windows Server 2003 and later, the link value for the removed user is marked “absent” and then replicated, much like a tombstone.
Reanimating Tombstones — Restoring Individual Objects Online
The Windows Server 2003 and later 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 or later, the sIDHistory attribute is also retained.
Only attributes that are retained on the tombstone are restored; all other data must be recreated. Therefore, to restore an entire deleted container or a set of multiple objects, authoritative restore is still the best option.
Stale Account Detection
Stale account detection is required so that unused computer and user accounts can be removed from Active Directory. On domain controllers running Windows Server 2003 and later, these accounts can be identified by the value in the lastLogonTimeStamp attribute of user and computer objects. This attribute identifies the last time that a user or computer successfully logged on to a domain. The attribute value is replicated to all domain controllers in the domain. lastLogonTimeStamp is new in Windows Server 2003, and its use is enhanced in Windows Server 2003 with SP1.
Scenarios that generate stale accounts
The following common scenarios result in the proliferation of computer and user accounts that are often abandoned by the users who create the accounts:
Delegated computer account creation, which is common in corporate environments, provides the freedom to create multiple accounts but no requirement for deleting them.
Web applications allow external partners to create and manage user accounts that are provided by the host company.
Employees leave the company.
Detection of successful password verification
In earlier versions of Windows, the pwdLstSet attribute was used to identify stale accounts. However, many conditions interfere with the accuracy of this method, such as users who are on sabbatical or otherwise temporarily not using an account. In addition, password time limits can vary throughout an organization. The most efficient way to identify an account that is stale is by evaluating the last time that the user successfully logged on to the domain, rather than the last time the password was reset.
The introduction of the lastLogonTimeStamp attribute in Windows Server 2003 and later provides the ability to mark an account each time that the system is asked to validate the account password (that is, at logon) for NTLM and Kerberos authentication. These two security protocols update the lastLogonTimeStamp attribute during successful authentication.
Implementation in the domain
Updates to lastLogonTimeStamp are replicated in the domain directory partition. Therefore, the value of this attribute can be checked on any domain controller in the domain. To minimize the effect of domain-wide replication every time that a user or computer logs on, lastLogonTimeStamp is updated only periodically. The period of update is configurable, as follows:
Object: DC=DomainName
Attribute: msDS-LogonTimeSyncInterval
Default value: 14 days
Because the lastLogonTimeStamp attribute is available only when the Windows Server 2003 and later 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 or higher. After the domain functional level increase, the first time that a successful logon occurs, the lastLogonTimeStamp attribute is activated on the user or computer object. This method of activation can result in loopholes for certain accounts, as follows:
Accounts that are created before the domain functional level increase but that are not used subsequently
Accounts that are created after the domain functional level increase but that are not used
In these cases, lastLogonTimeStamp is not present on the account object. To identify these accounts, you can query for user and computer objects that have no lastLogonTimeStamp attribute and that have a value in the whenCreated attribute that is earlier than or equal to a specified date.
For example, suppose a user account is created on 1/1/2005. The user leaves the company on 5/1/2005. The domain functional level is raised on 6/1/2005. On 9/1/2005, you query for accounts that do not have the lastLogonTimeStamp attribute. The query returns the account of the user who left the company before the raising of the functional level. However, you need to know if the account was created recently and has not yet been used or if the account was created before the functional level increase and is legitimately out of use. To answer this question, you query for accounts that do not have the lastLogonTimeStamp and that have a whenCreated value of 8/15/2005 or earlier. You select this date on the assumption that any account that was created within the last two weeks will have been used and any account that was created between June 1 and August 15 will certainly have been used. Accounts that are returned by the query are therefore legitimately out of use and can be deleted.
Randomization mechanism for initial use of lastLogonTimeStamp
To avoid network overloads due to thousands of concurrent lastLogonTimeStamp updates when the domain functional level is raised, a five-day window is used to calculate whether the lastLogonTimeStamp value should be updated. The following randomization mechanism is applied to control updates after the domain functional level is raised:
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.
The value in lastLogonTimeStamp is used to determine the number of days since the last valid logon of the account.
A random percentage of the value 5 is taken and then subtracted from the value in msDS-LogonTimeSyncInterval.
If the result is greater than or equal to the value in lastLogonTimeStamp, the value in lastLogonTimeStamp is updated.
For example, suppose that the value in lastLogonTimeStamp indicates 12 days since the last successful logon. Suppose also that the random percentage is 80 percent of 5 = 4. With the default value of 14 days in effect for msDS-LogonTimeSyncInterval, the calculation is 14 - 4 = 10. Because 12 > 10, lastLogonTimeStamp is updated. In this example, in all cases where the value is less than 10, lastLogonTimeStamp is not updated until the first successful logon that occurs after the msDS-LogonTimeSyncInterval value is reached.
Note
If the value in msDS-LogonTimeSyncInterval is set to 0, the stale account detection feature is disabled and lastLogonTimeStamp is not updated.
Security protocols that update lastLogonTimeStamp in Windows Server 2003
In the initial implementation of lastLogonTimeStamp in Windows Server 2003, lastLogonTimeStamp is updated by the following authentication protocols:
NTLM
Kerberos
Security protocols notify the directory database of a successful logon so that the account can be marked appropriately in the lastLogon and lastLogonTimeStamp attributes. Therefore, to use stale account detection effectively, it is important that administrators are aware of the security protocols that are in use in their environments.
For example, in Windows Server 2003 environments, the following security protocols request that the system validate a user password:
Secure channel setup (computer accounts only)
NTLM authentication (both interactive and network)
Kerberos authentication
Digest authentication
Third-party Security Support Provider Interfaces (SSPIs) when using the LSA APIs
The following security protocols can reference an account for a security operation:
Schannel, when mapped to an account
Kerberos Service-for-User (S4U) logons
AuthZ APIs in non-S4U mode
The obvious problem is that some accounts might be authenticated without updating the lastLogonTimeStamp, and if this detection method is relied on for stale account cleanup, accounts might be deleted that are still in use.
For example, the following issues occur in Windows Server 2003 implementations:
The NTLM authentication protocol does not update the lastLogonTimeStamp attribute for all network logons. NTLM is therefore not reliable for stale account detection.
The Kerberos S4U authentication protocol, which is used for Web single sign on (SSO) provisioning, does not update lastLogonTimeStamp. Specifically, when extranet users log on to servers running Microsoft Internet Information Services (IIS), Active Directory user accounts are mapped to certificates that are trusted by the IIS server. These certificates are distributed to the client computer so that users do not have to specify credentials. (That is, they are not directly authenticated by a security protocol.)
lastLogonTimeStamp improvements in Windows Server 2003 SP1
Windows Server 2003 SP1 corrects the problems of some protocols not updating lastLogonTimeStamp, as follows:
The inconsistency of NTLM updates of lastLogonTimeStamp is corrected.
Updates to the Key Distribution Center (KDC) ensure that lastLogonTimeStamp is updated in Active Directory when a user logs on to a protected IIS Web site.
Scripting stale account detection
You can implement a scripting solution for managing stale account detection and cleanup. For more information about lastLogonTimeStamp and instructions for creating scripts, see "Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least Favorite Things" on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=47965.
Database Defragmentation
As described earlier in this section, the database system uses the quickest way to fill database pages. Although this system is efficient in searching and updating the database quickly, it does not make the most efficient use of space in the database. As write operations occur and data pages fill, a certain amount of space often remains in a page that cannot be used by other transactions because the space is not large enough. In addition, space that is freed by version store cleanup is returned to the owning indexes or tables in noncontiguous chunks. Therefore, free space that exists in the database is not always available for use because it is fragmented.
Defragmentation rearranges how the data is stored in the database, compressing the data and making free space available in contiguous pages. Free space is managed automatically during database defragmentation.
Database defragmentation can take place online (while the computer is running as a domain controller) or offline (while the computer is running in Directory Services Restore Mode). Defragmentation has different effects on database size, depending on whether defragmentation is run while the domain controller is online or offline:
Online defragmentation: Occurs automatically by default. Online defragmentation compacts data and optimizes free space for database use, thereby maintaining the file size of the database.
Offline defragmentation: Occurs only manually in Directory Services Restore Mode. Offline defragmentation compacts data and returns free space to the file system, thereby decreasing the file size of the database.
Online Defragmentation
During online defragmentation, space in partially filled data pages is reorganized to consolidate it into full 8-KB pages. In addition, any pages that have been skipped by version store cleanup are reclaimed for use by the database. Online defragmentation returns a freed page directly to the part of the tree (database, object table, index, or long-value table) that owns the page that is being freed. When a sufficient number of contiguous free pages (approximately 16) exist in a given child tree, the space is released to the parent tree.
Note
- On domain controllers running Windows 2000 Server, online defragmentation does not reclaim free space that is deleted from long-value tables.
Automatic online defragmentation
Windows 2000 Server and later based domain controllers perform online defragmentation automatically. The ESE invokes online defragmentation after each garbage collection, which occurs every 12 hours by default.
Manual online defragmentation
On domain controllers running Windows Server 2003 and later, 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 and later as follows:
To start online defragmentation manually at any time, irrespective of garbage collection intervals, you can add the operational attribute doOnlineDefrag to the rootDSE object. The value of this attribute dictates the duration (in seconds) for which online defragmentation runs. After setting this attribute value, you can create a script that takes the duration as input so that online defragmentation can be triggered by the script at any time for any duration of runtime.
If you want online defragmentation to always occur only on demand, you can configure the registry so that automatic online defragmentation is disabled.
Note
- The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied. It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution.
You do not have to disable automatic online defragmentation to manually start online defragmentation. After you add the doOnlineDefrag attribute, you can start manual online defragmentation at any time that conditions warrant it, while allowing automatic online defragmentation to continue as well.
Offline Defragmentation
Offline defragmentation rebuilds the directory database and releases unneeded space back to the file system. Offline defragmentation must be performed in Directory Services Restore Mode, which restarts the computer as a stand-alone server, that is, as a computer that is not acting as a domain controller. In Directory Services Restore Mode, you can use the ntdsutil command-line tool to defragment the Ntds.dit file. Offline defragmentation produces a defragmented version of the database file in a separate directory. You can archive the original Ntds.dit file and move the defragmented file into the current directory.
Only offline defragmentation provides a clear picture of the amount of space that is consumed by the database file. You can use offline defragmentation to test database growth by comparing the defragmented version of the file with the fragmented version. For example, on a newly installed domain controller, if you perform a bulk load of objects and then defragment the database file offline, the difference between the two files is the space that is occupied by the new objects. There is no standard or optimal value for the percentage of free space that might exist in the database at any given time. If you are concerned about database size, set the DSA to log a message in the Directory Service event log during garbage collection that states how much disk space could be freed up through offline defragmentation.
Linked Attribute Management
Attributes of certain objects can be linked in the directory database to attributes of other objects to provide interobject references from one object back to the other object for either usability or administrative purposes. For example, a user object can be a member of a group, and a group can have users and groups as members. To define this relationship, the group object has a member attribute that can have multiple values of the distinguished names of every user, computer, or group that has membership in the group. Similarly, the user, computer, and group objects have a multivalued memberOf attribute that identifies all the groups to which a user, computer, or group belongs. These attributes are “linked” in the Active Directory database so that you can, for example, look at the member attribute on the object GroupA and determine that UserB is a member of GroupA. Likewise, you can look at the memberOf attribute on the object UserB and determine that UserB belongs to GroupA.
The GUID of an object unambiguously indicates which object the linked value applies to, even if the object has been renamed, deleted, or garbage-collected (permanently removed from the database). Individual values of multivalued attributes do not have an associated GUID. Instead, a link-value identifier serves the purpose of distinguishing existing values (including value tombstones) from values that have been garbage-collected and then recreated. This identifier, called the link ID, remains fixed from the creation of the value until the value is garbage-collected. When the originating server creates a new value, an ID is assigned to the value. Linked values replicate with the GUID of the object that contains them.
Effect of Moving Linked Objects
Active Directory maintains referential integrity between objects that reference each other by distinguished name so that when one object is moved in the directory tree, the referencing object can track the referenced object. For example, an object UserB is a member of GroupA. If you move the object UserB from the CN=Users,DC=concorp,DC=contoso,DC=com container to the OU=Sales,DC=concorp,DC=contoso,DC=com OU, the distinguished name value for UserB in the member attribute on the GroupA object automatically changes as follows:
Before the move: CN=UserB,CN=users,DC=concorp,DC=contoso,DC=com
After the move: CN=UserB,OU=sales,DC=concorp,DC=contoso,DC=com
This change occurs as soon as the move occurs. In this way, linked attributes effectively share their values.
Identifying Link Pairs
The sharing of values by linked attributes is achieved when two attributes are marked in the schema as having the same link-pair identifier — one is marked as the forward link (it points to another object in the directory) and the other as the back-link (it points back to the object that has a forward link to it). Changing the forward link attribute on one object affects the back-link on the referenced object. In the current example, the member attribute is the forward link and the memberOf attribute points back to the value in member. For reasons that relate to security and replication, only the forward-linked attribute can be modified.
Note
- The decision to link two objects must be made at the time that the objects are added to the schema.
To find all the objects that are members of GroupA, links are examined for all records in which the link pair is member/memberOf and the back-linked attribute identifies GroupA. The link pairs of those records provide the database identifiers of all the records (objects) that are members of GroupA.
The member and memberOf example uses a multivalued forward link and a multivalued back-link, but there is no requirement that the forward link be a multivalued link. For example, each group has one manager, but a manager can manage multiple groups. This relationship is identified in the database by the manager/directReports link pair, where manager is a single-valued attribute of a user object and directReports (common name Reports) is a multivalued attribute of a user object. The back-linked attribute must always be multivalued because it is impossible to restrict who creates links to various objects.
Deleting Linked Objects
When an object that is linked through a multivalued attribute is deleted, all of its linked attribute values are removed from the respective linked objects. In the preceding example, if a user manages multiple users and one of the users is deleted, the directReports multivalued attribute on the user object of the user that is the manager suddenly (and with no change to any replication-related metadata) loses a value. Similarly, if the user object for the manager is deleted, the value of the manager attribute on the user object of the user who was a direct report is suddenly blank. Nothing about the nondeleted object changes in either case, except that the attribute value is gone.
Restoring Linked Objects and Their Back-Links
When objects are deleted by mistake, you can restore them in Active Directory by performing an authoritative restore of the deleted objects. You perform authoritative restore by restoring the domain controller from its latest backup and then marking the deleted objects as authoritative so that they are not removed by replication.
However, when an object that has back-links is restored on a domain controller running Windows 2000 Server, its back-links are not restored as part of the authoritative restore process. For example, when user objects or group objects are deleted and then authoritatively restored, the memberOf values must be restored manually. You must add a restored user or group back to the groups to which it belonged at the time that its account was deleted.
On domain controllers running Windows Server 2003 or later in a forest that has a forest functional level of Windows Server 2003 or higher, 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 higher (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 or later, you can use the Windows Server 2003 SP1 or later 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 or later, see "Performing an Authoritative Restore of Active Directory Objects" in "Administering Active Directory Backup and Restore" in the Windows Server 2003 Operations Guide at https://go.microsoft.com/fwlink/?LinkId=44194.
For more information about replication of deleted linked objects, see “Active Directory Replication Model Technical Reference”.
Phantom Records for Interdomain Object References
An attribute that has a distinguished name as a value references (points to) the named object. When the referenced object does not actually exist in the local directory database because it is in a different domain, a placeholder record called a phantom is created in that database as the object reference. Because there is a reference to it, the referenced object must exist in some form, either as the full object (if the domain controller stores the respective domain directory partition) or as an object reference (when the domain controller does not store that domain).
A phantom record contains the GUID and the distinguished name of the object that is being referenced. In the case of references to security principals, the phantom also contains the SID. A common example of a distinguished name value that references an object in a different domain is the nCName attribute of a cross-reference (crossRef) object. Every domain controller stores a cross-reference object (in the configuration directory partition) for every other domain directory partition in the forest. Therefore, the nCName attribute value for every cross-reference object necessarily references a phantom in the local directory database.
Infrastructure Master and Phantom Records
The infrastructure master is a single domain controller in each domain that tracks name changes of referenced objects and updates the references on the referencing object. When a referenced object is moved to a different domain (which effectively renames the object), the infrastructure master updates the distinguished name of the phantom. (The infrastructure master finds phantom records by using a database index that is created only on domain controllers that hold the infrastructure operations master role.) When the reference count of the phantom falls to zero (no objects are referencing the object that the phantom represents), garbage collection on each domain controller removes the phantom.
Note
- Because objects can reference objects in different domains, the infrastructure operations master role is not compatible with global catalog server status if there is more than one domain in the forest. If a global catalog server holds the infrastructure operations master role, phantom records are never created because the referenced object is always located in the directory database on the global catalog server.
Ownership Quotas on Directory Objects
On domain controllers running Windows Server 2003 or later, you can specify quotas that limit the number of objects that a security principal (user, group, computer, or service) can own in a domain, configuration, or application directory partition. By default, the security principal (or administrative group in some cases) that creates an object is the object owner, although ownership can be transferred. With Active Directory quotas, no one can create unlimited numbers of objects in a directory partition, which is a method that can be used to launch denial-of-service attacks.
Note
- The term “user” in this discussion of security principals indicates both the user and inetOrgPerson classes of objects.
By default, quotas are not set, so there are no limits to the number of objects that can be owned by any security principal. For each target directory partition, you can set different limits for different security principals or you can set limits that apply to all security principals, or you can do both.
Quotas can be set per directory partition, except for the schema directory partition, which does not support quotas. You can set quotas to apply to security principals for a directory partition by using the command line. Use the following commands to manage quotas:
dsadd quota to set quotas for a directory partition
dsmod quota to modify existing quotas
dsmod partition to modify default quota settings for a partition
dsquery quota to search for quota assignments and quota consumption
For more information about directory quotas and how to use dsadd, dsmod, and dsquery commands to manage directory quotas, see “Data Store Tools and Settings”.
Quota Assignment Objects
Quota assignments for security principals are represented in a directory partition as instances of the object class msDS-QuotaControl. Each object in this class has the following attributes:
Common-Name: The relative distinguished name (also known as 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
-1for this attribute denotes an unlimited quota.Flags: This optional attribute is reserved for future use.
Instances of msDS-QuotaControl objects are stored in a well-known container called NTDS Quotas in the directory partition to which the quota applies.
Quota Containers
The NTDS Quotas container (class msDS-QuotaContainer) is a special system container that the quota system uses. The NTDS Quotas container has the following characteristics:
It is a child object of the root of a parent directory partition (including domain, configuration, and application directory partitions).
It cannot be deleted, but it can be renamed.
It is tracked by the parent container through the wellKnownObjects attribute on the parent container.
Each directory partition has exactly one well-known NTDS Quotas container that stores explicit quota assignment objects for the partition.
Two attributes of this well-known container specify a default quota value and how quotas are computed for that directory partition:
msDS-DefaultQuota: A default quota that applies to any security principal that creates objects in the directory partition and for which no explicit quota assignment exists. If no value is set for this attribute or if the attribute has the value -1, there is no default quota for the directory partition. In this case, security principals that do not have explicit quotas assigned have the ability to create unlimited objects in that directory partition, subject to access control. The default value for msDS-DefaultQuota on a directory partition is unlimited (not set). To manage this value, use the dsmod partition command.
msDS-TombstoneQuotaFactor: The percentage factor by which tombstone object count should be reduced for the purpose of quota accounting. By default, the setting is 100, which means that a tombstone (a deleted object) that was originally created by a security principal is equal to 1 object of that user’s quota. If the percentage factor were set to 50, each tombstone would represent only half an object rather than an entire object. Likewise, a tombstone quota factor of 25 means that four tombstones are the equivalent of 1 owned object. In this way, the quota for a security principal is computed relative to objects and tombstones. To manage this value, use the dsmod partition command.
Tracking Object Ownership
To enforce compliance with Active Directory quotas, object ownership is tracked by each domain controller running Windows Server 2003 or later. After a domain controller is upgraded to Windows Server 2003 or later, the system determines the number of objects that are owned by each security principal and for each directory partition that the domain controller hosts, and the system generates a tracking table for internal object ownership to track quota consumption. Thereafter, when objects are created, deleted, or reanimated or their ownership is transferred in a directory partition that the domain controller hosts, the quota tracking data is suitably updated.
Enforcing Quotas
Quotas are enforced only on originating updates and only by domain controllers running Windows Server 2003 or later. When an update originates on a Windows Server 2003 or later 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 or later 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 and later 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 or later and at the forest level (for the configuration directory partition) only when all domain controllers in the forest are running Windows Server 2003 or higher.
Effective quota
Multiple quota assignments can exist for a given security principal through an individual quota assignment or through quota assignments for one or more security groups of which the principal is a member, or both. When multiple quota assignments exist for a security principal, the effective quota is computed to be the maximum of the applicable quota assignments that are specified. For example, if a user belongs to two groups that have different quotas specified for the same directory partition, the higher of the two quota values applies to the user.
If no quota assignments are specified for a security principal or for any of the security groups of which the security principal is a member, the effective quota is the default quota that is specified for the directory partition in the msDS-DefaultQuota attribute on the NTDS Quotas container.
Quota exemptions
Members of the Domain Admins and Enterprise Admins groups are exempted from all quota-imposed limits.
Using Quotas
You can use quotas in combination with security groups to manage objects that are created in Active Directory. The following examples illustrate using a default quota, with exceptions to set explicit quota assignments for those groups that need the ability to create large numbers of objects.
Managing DNS data in application directory partitions
When you use Active Directory–integrated DNS, zone data can be stored in the domain directory partition, if you want DNS data to replicate to all domain controllers, or in application directory partitions, if you want DNS data to replicate only to domain controllers that are DNS servers.
To decrease domain-wide replication and avoid replicating zone data to the global catalog, you can take advantage of application directory partitions on DNS servers running Windows Server 2003 or later. By default, members of the Authenticated Users group have the ability to create resource records on DNS servers that are in the domain of the client computer. This ability is required to allow all computers to dynamically update DNS zone data. A typical authenticated user needs to register a maximum of 10 records in DNS. To ensure that malicious users or applications do not create inappropriate resource records, you can set a default quota on the application directory partitions ForestDnsZones and DomainDnsZones, which are replicated to every DNS server in the forest and domain, respectively. A default limit of 10 objects ensures that all computers can update DNS appropriately but cannot launch denial-of-service attacks.
Explicit quotas for domain controllers and other servers
The number of resource records that must be registered in DNS is significantly greater for domain controllers and for multihomed computers that register adapter-specific records for all of their connections. To accommodate the resource record requirements of atypical authenticated users such as domain controllers, multihomed computers, and multiadapter servers, you can create special groups for these specific types of computers. For example, you might create the Enterprise Domain Controllers group that has all domain controllers as members. To ensure that this group can create the maximum DNS resource records that might be required, set a quota of 300 to 400 objects for this group on the DomainDnsZones and ForestDnsZones application directory partitions.
The same rule applies to servers such as virtual private network (VPN) or Web servers, which are required to register a large number of resource records in DNS. Depending on how many adapter-specific resource records your VPN or Web server must register, you can create a group for those servers and assign the appropriate quota to ensure that the Authenticated Users default quota does not apply.
Explicit quotas for DHCP servers
To allow DHCP servers to have essentially unlimited ability to create resource records when clients depend on DHCP-assigned IP addresses, you can create a group that contains all DHCP servers in the domain or forest and then set an explicit quota assignment for that group on the DomainDnsZones and ForestDnsZones application directory partitions, respectively. Set a quota that is appropriate to the number of clients for which your DHCP server registers records, multiplied by the upper limit of the number of records registered per computer. In this way, DHCP servers can update DNS with client resource records as needed.
Managing print objects in domain directory partitions
When Active Directory is used to publish shared printing resources, print servers require the ability to create potentially large numbers of objects in Active Directory. Print servers publish printers in Active Directory as print queue objects (class printQueue), which are child objects of the print server computer object and which contain a subset of the information that is stored on the print server for a printer. When print servers go offline for any reason, they must republish their print queues when they return to service. For this reason, print servers require the ability to create large numbers of objects in the domain directory partition.
To ensure that print servers can create appropriate numbers of objects in the domain, you can create a group that contains all print servers in the domain and then specify an explicit quota assignment on the domain that is higher than the default assignment.
Network Ports Used by the Data Store
The network ports that are used by the data store are listed in the following table.
Port Assignments for the Data Store
| Service Name | UDP | TCP |
|---|---|---|
LDAP |
None |
389 |
LDAP SSL |
None |
636 |
RPC Endpoint Mapper |
135 |
135 |
Global Catalog LDAP |
None |
3268 |
Global Catalog LDAP SSL |
None |
3269 |
Related Information
The following resources contain additional information that is relevant to this section.
Microsoft Platform SDK on MSDN for more information about LDAP (in “Lightweight Directory Access Protocol”) (https://go.microsoft.com/fwlink/?linkid=20540)