Password Policy Enforcer History Rule

History Rule

The History rule rejects passwords that are identical to a recently used password. Password reuse should be avoided because it defeats the purpose of regular password changes. PPE can stop users from reusing passwords for a number of password changes or a number of days.

Select the Enabled check box to enable the History rule.

Select the one of the last option to stop passwords from being reused for a specified number of password changes. Choose the number of password changes from the drop-down list.

Select the password used in the last option to stop passwords from being reused for a specified number of days. Type the number of days in the text box.

The History rule is normally not enforced when a password is reset. Select the Enforce this rule when a password is reset check box to override the default behavior. The History rule will not be enforced during a reset if the Do not check admin/helpdesk password resets option is enabled in the PPS Properties page.

Click the Messages tab to customize the Password Policy Client rule inserts for this rule.

PPE stores the password history in an Active Directory attribute. You can create a new attribute for the password history, or configure PPE to use an existing attribute. If you do not want PPE to store a password history, then leave the History rule disabled. You can use the Windows history rule instead of PPE's.

The History rule is not enforced during policy testing.

PPE updates a user's password history whenever their password changes. The password history is updated even if PPE, or the assigned policy is disabled. A user's password history is deleted if the user does not have an assigned policy, or if the History rule in the assigned policy is disabled at the time of the password change.

PPE does not store passwords in the password history, it only stores the SHA-256 message digests (hashes). A salt protects the hashes from precomputed attacks, including rainbow tables. This technique is used by most modern operating systems to validate passwords without storing them. It is beyond the scope of this document to explain how hash functions, salts and rainbow tables work. A good cryptography book will explain these topics.

PPE can store up to 100 password hashes for each user, but it only stores the minimum number needed to enforce the current password policy. For example, if PPE is configured to reject passwords matching the last 24 passwords, then only the last 24 password hashes are stored in the history. Reconfiguring PPE to reject the last 30 passwords will not have an immediate effect as only 24 password hashes are currently stored. The full effect of the new configuration will be realized after users change their passwords six more times as PPE will then have 30 stored password hashes for each user.

As PPE is limited to storing the last 100 password hashes, it is possible for the History rule to run out of storage space before the specified minimum number of days elapses. If this happens, a password may be reused before the required number of days. Use the Minimum Age rule to avoid this problem by limiting the frequency of password changes. For example, if PPE is configured not to allow password reuse for 365 days, then set the minimum password age to four or more days. Even if a user changes their password every four days, they can only perform 91 password changes in 365 days.

If you do not want PPE to store a password history, then leave the History rule disabled. You can use the Windows history rule instead of PPE's and use PPE to enforce the rest of your password policy.

Creating a new attribute for the password history

Windows stores a user's password history in two Active Directory attributes, but these attributes cannot be used by other applications. PPE can store the password history in a new or existing attribute. A new attribute is recommended, but you can use an existing attribute if you do not want to extend the AD schema.

PPE's password history attribute is marked as confidential to stop authenticated users from accessing it. Confidential attributes were introduced in Windows 2003 SP1, so this protection is lost if any of your domain controllers are running an older version of Windows. Send an e-mail to support@anixis.com before using PPE's History rule in a domain that contains any Windows 2000 or Windows 2003 (without SP1 or later) domain controllers. You can use permissions to protect the password history on these operating systems. Microsoft Article 922836 has more information about confidential attributes.

To create a new Active Directory attribute for the password history:

Log on to the server holding the Schema Operations Master role with an account that is a member of the Schema Admins group.

Open a Command Prompt window to the PPE installation folder
\Program Files\Password Policy Enforcer\ or
\Program Files (x86)\Password Policy Enforcer\ on Windows x64.

Type the following command
ldifde -i -f History.ldf -c "DC=X" "DC=yourdomain,DC=yourdomain"
Replacing the last parameter with your domain's DN.

Press ENTER and check the output for errors.

Using an existing attribute for the password history

PPE can also store the password history in an existing attribute. The desktopProfile attribute is well suited because it is not used by Windows. Many other attributes are also suitable if they are not being used. Send an e-mail to support@anixis.com if you would like to use PPE's History rule with an existing attribute. We will help you to choose a suitable attribute and send you step-by-step configuration instructions.