Active Directory Data Storage
Active Directory Data Storage |
|
Active Directory functionality can be described as a layered architecture in which the layers represent the server processes that provide directory services to client applications. Active Directory consists of three service layers and several interfaces and protocols that work together to provide directory services. The three service layers accommodate the different types of information that are required to locate records in the directory database. Above the service layers in this architecture are the protocols and APIs (APIs are on the clients only) that enable communication between clients and directory services or, in the case of replication, between two directory services.
Figure 2.3 shows the Active Directory service layers and their respective interfaces and protocols. The direction of the arrows indicates the manner in which the different clients gain access to Active Directory through the interfaces. LDAP and Messaging API (MAPI) clients gain access to the directory by calling functions, indicated by one-way arrows into the directory system agent. The SAM exists as separate dynamic-link library (DLL) and can call only entry points exported by the directory system agent DLL, Ntdsa.dll. All other components except the extensible storage engine (Esent.dll) are in Ntdsa.dll itself and are linked to the functions that they want to call. Thus, a three-way interaction is required between the three DLLs.
Figure 2.3 Active Directory Service Layers and Interface Agents
The key service components include the following:
For more information about using Ntdsutil, see "Active Directory Diagnostic Utility (Ntdsutil.exe)" and "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book, and see Microsoft Windows 2000 Support Tools Help.
Clients obtain access to Active Directory by using one of the following mechanisms that are supported by Active Directory:
The directory system agent (DSA) is the process that provides access to the store. The store is the physical store of directory information located on a hard disk. The DSA is the server-side process that creates an instance of a directory service. Clients use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write Active Directory objects and their attributes.
The Active Directory namespace is partitioned so that individual domain controllers do not store the entire directory. Every DSA holds at least a single Windows 2000 directory partition that stores domain data for a domain (such as users, groups, and organizational units) plus two non-domain directory partitions that store forestwide data, which includes the schema and configuration data.
The DSA layer provides the following functionality:
Object Identification Every object in Active Directory has a permanent globally unique identifier (GUID) that is associated with several string forms of the object name (SAMAccountName, user principal name, distinguished name) as well as a security identifier. These object names and the security identifier 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 security identifier is used for access control. The DSA maintains the GUID association with an object when the object's string name or security identifier changes.
Schema Enforcement of Updates In a multimaster system, a change to a schema object in one replica might conflict with existing objects in that replica and also with objects in other replicas. In Windows 2000, a schema change is a single-master operation, so if an update does not produce a conflict at the originating replica, the update is considered acceptable at all replicas. Thus, replicated updates do not perform any schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute.
Access Control Enforcement The DSA enforces security limitations in the directory. The DSA layer reads security identifiers (SIDs) on the access token.
Support for Replication The DSA contains the hooks for replication notifications. All object updates ultimately must go through the appropriate function for the directory service to work properly.
Referrals DSA manages the directory hierarchy information (referred to as "knowledge"), which it receives from the database layer. DSA is responsible for cross-references of Active Directory domain objects up and down the hierarchy and also out to other domain hierarchies.
The database layer provides an object view of database information by applying schema semantics to database records, thereby isolating the upper layers 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 extensible storage engine; instead, all database access is routed through the database layer.
Active Directory provides a hierarchical namespace. Each object is uniquely identified in the database by its distinguished name. The individual naming attribute, called the relative distinguished name, is unique within 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.
All data that describes an object is held as a set of attributes, which are stored as columns in the database. The database layer is responsible for the creation, retrieval, and deletion of individual records, 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. For more information about the schema cache, see "Active Directory Schema" in this book. For more information about distinguished names and relative distinguished names, see "Active Directory Logical Structure" in this book.
Active Directory is implemented on top of an indexed sequential access method (ISAM) table manager. This database is a version of the ESE database that is used by Microsoft® Exchange Server version 5.5 client/server messaging and groupware. The Windows 2000 version of this database is Esent.dll.
ESE stores all Active Directory objects. It can support a database up to 16 terabytes in size, which can theoretically hold many millions of objects per domain.
Note
Testing of the database has been carried out to 40 million objects per domain.
The following ESE characteristics make it well suited to the storage needs of Active Directory:
Active Directory comes with a predefined schema that defines all of the attributes that are required and allowed for a given object. 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 already 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.
Esent.dll implements the search and retrieval functionality of the underlying database. Also, 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.
