What Is the Active Directory?
Stated very simply, the Active Directory is a network-based object store and service that locates and manages resources, and makes these resources available to authorized users and groups. An underlying principle of the Active Directory is that everything is considered an objectpeople, servers, workstations, printers, documents, and devices. Each object also has certain attributes and its own security Access Control List (ACL). Objects can be organized within the Active Directory in a special kind of object known as a container, which can be used on a very granular level. Specifically, the Active Directory plays several very important roles within a Windows 2000 enterprise, which include but are not limited to the following:
A store for information about every network object and its attributes
A security conduit for ACL authentication and domain trusts
A focal point for system administration
A mechanism for operating system interoperability
A means of consolidating divergent directory services
A system for replication of object data
The Active Directory is a distributed, hierarchical, replicated, and secure directory service designed for Windows 2000 that is theoretically capable of interoperability within heterogeneous directory service environments.
The Active Directory catalogs file objects with their attributes in a hierarchical arrangement, fully embracing naming resolution services such as DNS. It also organizes users and groups with their associated attributes. The Active Directory plays an important role in identifying security policies across the network, integrating e-mail, Internet addressing, and groupware applications. In essence, the Windows 2000 Active Directory merges all of these directory services within an extensible system environment.
A user inquiry about an object is passed through the Global Catalog (GC), which, as we will discuss later, is an abstraction of object information contained in the Active Directory data store. The GC resolves the most common object inquiries. It is created and refreshed with updated information for the Active Directory. The schema residing within the Active Directory presents object definitions. The Active Directory manages the store of data through an Extensible Storage Engine (ESE). The upper functions of the directory services themselves are separated from the ESE by APIs through the Directory System Agent (DSA) layer. No direct calls are made to the ESE.
Queries made by a user are passed through the Global Catalog. If the object cannot be resolved by the GC, it is passed to the data store via the ESE database API.
The Active Directory stores database and log files. It is important to understand the nature of these files in order to facilitate a backup and restoration policy in the event of system corruption.
The Active Directory database file, Ntds.dit, is stored in the %system/NTDS folder. Every domain controller has a copy of it. Ntds.dit stores all domain objects together with their attribute data organized into several tables. The schema table contains the definitions of the possible objects that can be created. The object table organizes a single object per role, with a column provided for every attribute that contains data. Finally, the link table contains the relationship data between the object itself and the object table.
The Active Directory creates and stores four types of log files on the maintenance and management of transactions. These files are stored in %system/NTDS and include
Transaction log files. The current transaction file is Edb.log, which by default contains information about recent transactions and is limited to 10MB. When this limit is reached, transaction files are automatically created with the name edbxxxxx.log (where x is a sequential number). They are retained until the transactions are committed to the Active Directory. Once every 12 hours, old previous transaction files are purged during a process known as garbage collection. If you do not want previous transaction files created, it is possible to set circular logging, in which the current file is overridden when it is filled. This action is not recommended because it could limit your ability to recover recent transactions.
Checkpoint files. The checkpoint is Edb.chk, and it is used to list transactions that have been committed to the Active Directory and those that remain uncommitted. Each time a transaction is committed, it advances to the next entry. If all transactions are not committed at the time of shutdown, the checkpoint file is read when the system is rebooted, and all remaining transactions are then committed to the Active Directory.
Reserved log files. The reserved log file can be a number sequence of logs, with a maximum size of 10MB, named res1.log, res2.log, and so on. These logs are used in place of the transaction log when the creation of a new log file is attempted, but insufficient disk space is available. When this occurs, the system will automatically shut down.
Patch files. Patch files (with a .pat suffix) are used during the backup-and-restore process of the Active Directory. Database entries are sometimes divided during backup into what is known as split transactions. The patch files are used to record these splits, and "patch" the transaction back together during restoration.
Data Stores and Partitions
To facilitate information storage and replications, the Active Directory uses three types of data store for directory partitions, each of which is discretely replicated as a separate unit according to its own schedule. The three Active Directory partitions are
Schema data. Schema information comprises definitions of the objects that are available or can be created within the Active Directory. It also includes the required and optional object attributes.
Configuration data. The logical structure of the domain is reflected in configuration data. Common to all domain trees and forests is a strategy for replicating all three Active Directory partitions between domain controllers. This replication topology is stored in the configuration data partition.
Domain data. All objects within the tree are stored as domain data. This information relates strictly to the objects within the domain, and is not replicated to other domains. Instead of total replication of all domain object information, a subset is derived for the Global Catalog. In addition to this subset, the Global Catalog server contains the schema and configuration data. It becomes the index for locating data within a domain, or across a tree or forest.