Account Database

The Active Directory provides the account database that the KDC uses to obtain information about security principals in the domain. Each principal is represented by an account object in the directory. The encryption key used in communicating with a user, computer, or service is stored as an attribute of that security principal's account object.

Only domain controllers are Active Directory servers. Each domain controller keeps a writable copy of the directory, so accounts can be created, passwords reset, and group membership modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Microsoft® Windows NT® does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for the Active Directory using a proprietary multimaster replication protocol over a secure channel between replication partners.

Physical storage of account data is managed by the Directory System Agent (DSA), a protected process integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client wanting access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA and then search for, read, and write directory objects and their attributes.

Requests to access an object or attribute in the directory are subject to validation by Windows NT access control mechanisms. Like file and folder objects in the Windows NT File System (NTFS), objects in the Active Directory are protected by Access Control Lists (ACLs) that specify who can access the object and in what way. Unlike files and folders, however, Active Directory objects have an ACL for each of their attributes. Thus attributes for sensitive account information can be protected by more restrictive permissions than those granted for other attributes of the account.

The most sensitive information about an account is of course its password. Although an account object's password attribute stores an encryption key derived from a password, not the password itself, this key is just as useful to an intruder. Therefore, access to an account object's password attribute is granted only to the account holder, never to anyone else, not even administrators. Only processes with Trusted Computing Base privilege—processes running in the security context of the LSA—are allowed to read or change password information.

To hinder an offline attack by someone with access to a domain controller's backup tape, an account object's password attribute is further protected by a second encryption using a system key. This encryption key can be stored on removable media so that it can be safeguarded separately, or it can be stored on the domain controller but protected by a dispersal mechanism. Administrators are given the option to choose where the system key is stored and which of several algorithms is used to encrypt password attributes.