Directory Service Architecture
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:
Directory system agent. Builds a hierarchy from the parent-child relationships stored in the directory. Provides APIs for directory access calls.
Database layer. Provides an abstraction layer between applications and the database. Calls from applications are never made directly to the database; they go through the database layer.
Extensible storage engine. Communicates directly with individual records in the directory data store on the basis of the object's relative distinguished name attribute.
Data store (the database file Ntds.dit). This file is manipulated only by the extensible storage engine database engine. You can administer the file by using the Ntdsutil command-line tool. (To use Ntdsutil, install the Support Tools that are located in the Support\Tools folder on the Windows 2000 Server operating system CD. To install the tools, double-click the Setup icon in that folder. For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the Support\Tools folder of the Windows 2000 operating system CD.)
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 MicrosoftWindows 2000 Support Tools Help.
Clients obtain access to Active Directory by using one of the following mechanisms that are supported by Active Directory:
LDAP/ADSI. Clients that support LDAP use it to connect to the directory system agent. The extensible storage engine (ESE) that is used by Microsoft® Exchange Server version 5.5 (and earlier) client/server messaging and groupware also uses LDAP. Active Directory supports LDAPv3 (defined by RFC 2251) and LDAPv2 (defined by RFC 1777). Windows 2000 clients, as well as Microsoft® Windows® 98 and Microsoft® Windows® 95 clients that have the Active Directory client components installed, use LDAPv3 to connect to the directory system agent. Active Directory Service Interfaces (ADSI) is a means of abstracting the LDAP API by providing component object model (COM) interfaces to Active Directory; however, Active Directory uses only LDAP. The LDAP API is part of Wldap32.dll.
MAPI. Microsoft® Outlook® messaging and collaboration clients connect to the directory system agent by using the MAPI remote procedure call (RPC) Address Book provider interface.
SAM. Windows clients that use Windows NT 4.0 or earlier use the SAM interface to connect to the directory system agent. Replication from backup domain controllers in a mixed-mode domain goes through the SAM interface as well.
REPL. During directory replication, Active Directory directory system agents connect to each other by using a proprietary RPC interface.
Directory System Agent
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.
Extensible Storage Engine
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.
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:
Is used by the directory service and information store in Exchange Server version 5.5.
Supports multivalue 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 sparse rows well — that is, rows in which many of the properties do not have values.
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.