The components that make Active Directory work are relatively simple. Active Directory includes a special database to store directory data and components to manage access to the directory itself from a variety of clients. Figure 2-11 shows the basic components of Active Directory on a domain controller.
Figure 2-11 Components of Active Directory on a domain controller.
Developers working with Active Directory do not necessarily have to understand the ins and outs of the various Active Directory components. In fact, developers are purposely isolated from these details. However, an understanding of how Active Directory works as a whole will always be a benefit when creating robust, high-performance applications.
The directory system agent (DSA) is a collection of services and processes that run on each Windows 2000 domain controller. It's primary function is as an interface between clients requesting directory data and the directory database, known as the store.
The DSA executes as part of the LSA subsystem. The LSA is responsible for ensuring security for the local machine. The DSA depends on the LSA to provide security for Active Directory. Clients, both local and those external to the domain controller, access the DSA using a variety of protocols: LDAP, the Lightweight Directory Access Protocol, is the primary means for clients to interact with Active Directory. Finally, the DSA communicates with other domain controllers using remote procedure calls (RPCs).
The DSA also provides a number of Win32 APIs for local and remote clients to use. These APIs start with DsXXX and provide a wealth of management functions. I'll discuss some of the available APIs as we need them throughout this book. From a programming perspective, access to Active Directory will be exclusively through LDAP and provided by the Active Directory Service Interfaces (ADSI) components, which I'll introduce in Chapter 3.
For compatibility with older clients, Active Directory provides a translation layer. Since the Security Account Manager is now part of Active Directory, clients that use the SAM APIs are routed to the Security Accounts Manager, which translates the request for the DSA to fulfill. This mechanism ensures that older clients still function with Windows 2000 domain controllers.
Clients do not communicate directly with the database layer. It sits between the data store and the DSA and provides for an object-like view of the directory store. Information in the store is contained in database-like records that correspond to objects, with columns that correspond to attributes. Clients using Active Directory see an object-oriented, hierarchical view of the directory that is provided by the database layer. The database layer also applies consistency checks to new objects added to the directory and ensures that they comply with the schema in use. As a performance enhancement, the schema is loaded into a schema cache, an in-memory copy of the schema, while the DSA and database layer are running.
The Extensible Storage Engine (ESE) is the component of Active Directory that actually stores data in and retrieves data from a physical file. Programmers familiar with Microsoft database technology might recognize ESE as the database foundation from Microsoft Exchange 4.0 and 5.0/5.5. This technology was also known as the Microsoft Jet Database Engine. Because of its replication features, the ESE technology is also used by the file replication service (FRS) and other components of Windows 2000.
The ESE maintains an Indexed Sequential Access Method (ISAM) table–driven database that supports transactions to ensure safe database operations. The database contains two tables: a link table for linked attributes such as the memberOf attribute, and the much larger data table for the rest of the Active Directory information. The actual file that the ESE writes for Active Directory is Ntds.dit (which stands for Windows NT Directory Services, Directory Information Tree), contained in the %SystemRoot%\NTDS folder of the domain controller.
The ESE also writes log files that are used for transaction rollback and database recovery purposes. These are circular files and are always allocated 10 MB of space. Every 12 hours, a garbage collection process runs on the domain controller. The purpose of this process is to delete unused log files and defragment the database file. This online defragmentation does not reduce the database file size, but rearranges the data to keep empty records in large blocks. Using the Ntdsutil tool (discussed later in this chapter), you can perform an offline defragmentation that will reduce the size of the Ntds.dit file.
Are you wondering how large the Ntds.dit file could get for a large company? The book Building Enterprise Active Directory Services, published by Microsoft Press, provides a look at a sample company storing the following types of objects in Active Directory: 100,000 users, 100,000 computers, 10,000 groups, 10,000 printers, and 10,000 volumes. The size of the resulting Ntds.dit is about 1,400 MB, or 1.4 gigabytes! This is with minimal attributes set on the objects. In Chapter 9, I'll discuss the effect of extending Active Directory with your own objects and attributes.