Authentication
Authentication |
|
The account database that provides information about security principals to the KDC is the domain's Active Directory. Each security principal is represented by an account object in Active Directory. The cryptographic key used in communications with a user, a computer, or a 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 that accounts can be created, passwords reset, and group memberships modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows 2000 does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for Active Directory by 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 that is integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client that wants 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 for access to an object or attribute in the directory are subject to validation by Windows 2000 access control mechanisms. Like file and folder objects in the NTFS file system, objects in Active Directory are protected by access control lists (ACLs) that specify who can have access to the object and in what way. Unlike the ACLs on files and folders, however, ACLs on Active Directory objects can allow or deny access not only to the entire object but also to individual attributes of the object. Thus, attributes for sensitive account information can be protected by permissions that are more restrictive than permissions granted for other attributes of an account object.
The most sensitive information about an account is, of course, its password. Although an account object's password attribute stores an encryption key that is derived from the password, not the password itself, this key is just as useful as the password to a would-be intruder. Therefore, access to an account object's password attribute is granted only to the account holder, never to anyone else, not even to administrators. Only processes with Trusted Computer 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 using a system key to encrypt its value. This key can be stored on removable media so that it can be safeguarded separately, or it can be stored on the domain controller and protected by a dispersal mechanism. Administrators can choose where the system key is stored and which of several algorithms is used to encrypt password attributes. For more information about using system key protection, see "Encrypting File System" in this book.