Windows 2000 Active Directory Password History

In Microsoft Windows 2000, Active Directory enforces password history constraints by storing cryptographic hashes of previous passwords in the directory database and validating new password requests against this historical record before committing changes. This mechanism prevents users from reusing recently used passwords, ensuring organizational credential rotation policies are strictly upheld. Managed via Domain Group Policy, enforcement relies on domain controllers—specifically the PDC Emulator role—comparing incoming password hashes to an array of stored historical hashes within the user object.

Policy Configuration and Scope

Password history in Windows 2000 Active Directory is defined at the domain level through Group Policy Objects (GPOs), specifically the Default Domain Policy. The policy setting, Enforce password history, determines the number of unique new passwords a user must use before an old password can be reused (ranging from 0 to 24 passwords).

For this constraint to be effective, it works in tandem with the Minimum password age policy. Without a minimum age requirement, users could rapidly change their password multiple times in succession to cycle through the history threshold and revert to their preferred password immediately.

Directory Storage: ntds.dit and Password Attributes

Windows 2000 Active Directory does not store plaintext passwords. Instead, credentials and their histories are retained as one-way cryptographic hashes inside the Active Directory database file (ntds.dit).

When password history is enabled, the directory tracks historical credentials using hidden, system-managed attributes associated with the user account object:

• ntPwdHistory: Stores a sequence of historical NTLM hashes (MD4-based Unicode hashes).
• lmPwdHistory: Stores a sequence of historical LAN Manager (LM) hashes (DES-based), maintained for legacy backward compatibility unless explicitly disabled.

These attributes function as sequential arrays of binary data. Each hash is appended to the list until the configured policy limit is reached.

The Enforcement Process

The enforcement workflow occurs dynamically whenever a password modification is initiated:

1. Request Routing to the PDC Emulator: Password change requests are routed to the domain controller holding the Primary Domain Controller (PDC) Emulator Flexible Single Master Operation (FSMO) role, or processed locally by a domain controller which then replicates the change with high priority to the PDC Emulator.
2. Hash Generation: The Local Security Authority Subsystem Service (lsass.exe) receives the requested new password over an encrypted RPC or Kerberos connection and computes its corresponding NTLM and LM hashes.
3. History Comparison: lsass.exe extracts the historical hash arrays from ntPwdHistory and lmPwdHistory in the user's database record. It compares the newly generated hash against the current password hash and each entry in the history array up to the configured constraint value N.
4. Acceptance or Rejection:
   • If the new hash matches any entry within the designated history threshold, the system rejects the operation and returns an error (STATUS_PASSWORD_RESTRICTION).
   • If the new hash does not match any historical entries, the change is accepted.
5. History Update: Active Directory updates the user object. The current active password hash is moved to the top of the history list, the oldest hash beyond the threshold limit is discarded, and the new hash is written as the active credential.