The data that is stored in Active Directory is physically stored in just a few files. The information is mainly stored in a file called ntds.dit, but there are also transaction logs that are used in conjunction with ntds.dit to support the database. You will physically find these files on each domain controller in the %systemroot%\NTDS folder.
These files contain the information that is stored in Active Directory such as user, computer, organizational units, domains, sites objects, etc. If the domain controller also functions as a Global Catalog server, information from other domains in the forest is stored in the database as well.
While administrators do not interact directly with these files, there are times such as disaster recovery, routine maintenance, and other events that will require the administrator to work directly with these files generally via the command prompt. However, this interaction with the database is not accessed directly, but via one or more interfaces that support communication with the data store.
Here are some of the various interfaces that may be used to communicate with the database: Lightweight Directory Access Protocol (LDAP), Replication (REPL), Messaging API (MAPI), and the Security Accounts Manager (SAM). To communicate with the data store, there is a service called the Directory Service Agent (DSA) which provides the access. This runs as a DLL called ntdsai.dll.
The DSA ensures that certain rules are enforced when accessing the store. When access is required, one of the interfaces is used to bind to the DSA. The DSA sits in the Database layer and cannot access the store directly. The DSA uses the Extensible Storage Engine (ESE) to communicate with the store. The ESE is responsible for transferring information in and out of the database.
This multi-layer approach ensures that each component can run independently while providing various interfaces for accessing information in the data store. These various interfaces allow components to access information using different formats.
While certain clients and applications rely on LDAP, others, such as pre-Windows 2000 systems may access using the SAM interface. This approach also allows for future implementations to incorporate newer interfaces without having to modify all of the layers involved in the support of Active Directory Domain Services.
