19.4. Managing the Password Policy

A password policy minimizes the risks of using passwords by enforcing a certain level of security. For example, a password policy can define that:

Users must change their passwords according to a schedule.

Users must provide non-trivial passwords.

The password syntax must meet certain complexity requirements.

For an overview on password policy, see "Designing a Password Policy" in the "Designing a Secure Directory" chapter in the Deployment Guide.

Warning

When using a password administrator account or the Directory Manager (root DN) to set a password, password policies are bypassed and not verified. Do not use these accounts for regular user password management. Use them only to perform password administration tasks that require bypassing the password policies.

Directory Server supports fine-grained password policy, so password policies can be applied to the entire directory (global password policy), a particular subtree (subtree-level or local password policy), or a particular user (user-level or local password policy).

The complete password policy applied to a user account is comprised of the following elements:

The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local (subtree/user-level) password policies.

Password policies work in an inverted pyramid, from general to specific. A global password policy is superseded by a subtree-level password policy, which is superseded by a user-level password policy. Only one password policy is enforced for the entry; password policies are not additive. This means that if a particular attribute is configured in the global or subtree-level policy, but not in the user-level password policy, the attribute is not used for the user when a login is attempted because the active, applied policy is the user-level policy.

Password add and modify information. The password information includes password syntax and password history details.

Bind information. The bind information includes the number of grace logins permitted, password aging attributes, and tracking bind failures.

Note

After establishing a password policy, user passwords can be protected from potential threats by configuring an account lockout policy. Account lockout protects against hackers who try to break into the directory by repeatedly guessing a user's password.

19.4.1.1. Configuring a Global Password Policy Using the Console

A global password policy applies to every entry in the entire directory.

Select the Configuration tab and then the Data node.

In the right pane, select the Passwords tab.

This tab contains the password policy for the entire Directory Server.

Set the password policies for how users can change their own passwords.

To require users to change their password the first time they log on, select the User must change password after reset check box.

To allow users to change their own passwords, select the User may change password check box.

To prevent users from changing their password for a specific duration, enter the number of days in the Allow changes in X day(s) text box. This keeps users from quickly cycling through passwords to reuse a password in their password history.

For the server to maintain a history list of passwords used by each user, select the Keep password history check box. Enter the number of passwords for the server to keep for each user in the Remember X passwords text box.

Set the policies for when passwords expire.

If user passwords should not expire, select the Password never expires radio button.

To require users to change their passwords periodically, select the Password expires after X days radio button, and then enter the number of days that a user password is valid.

The maximum value for the password age is derived by subtracting January 18, 2038, from today's date. The entered value must not be set to the maximum value or too close to the maximum value. Setting the value to the maximum value can cause the Directory Server to fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, correct the passwordMaxAge attribute value in the dse.ldif file.

A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).

If the Password expire after X days radio button is selected, specify how long before the password expires to send a warning to the user. In the Send Warning X Days Before Password Expires text enter the number of days before password expiration to send a warning.

Note

It is not necessary to configure the Directory Server to send a warning to users. The Directory Server automatically issues a warning the next time the user attempts to log into the Directory Server Console that the password will soon expire or has expired. This is analogous to an operating system warning that reads "Warning: password will expire in 7 days" when a user logs in.

For the server to check the syntax of a user password to make sure it meets the minimum requirements set by the password policy, select the Check Password Syntax check box. Then, specify required password complexity, such as the minimum length and required number of numeric and special characters.

From the Password Encryption pull-down menu, select the encryption method for the server to use when storing passwords.

19.4.1.2. Configuring a Global Password Policy Using the Command Line

To set up the password policy for a subtree or user, add the required entries and attributes at the subtree- or user-level, set the appropriate values to the password policy attributes, and enable fine-grained password policy checking.

No password policy attributes are set by default. Each password policy attribute must be added manually to the cn=config entry to create a global policy. These can be passed all together by passing an LDIF file with ldapmodify.

Create the LDIF file. Each statement is the same as inputting the changes through stdin, with separate update statements separated by a dash (-).

For updating a subtree entry, use the -S option. For updating a user entry, use the -U option. The ns-newpwpolicy.pl script accepts only one user or subtree entry at a time. It can, however, accept both user and suffix entries at the same time. For details about the script, see the Red Hat Directory Server Configuration, Command, and File Reference.

The script adds the required attributes depending on whether the target entry is a subtree or user entry.

For a subtree (for example, ou=people,dc=example,dc=com), the following entries are added:

A container entry (nsPwPolicyContainer) at the subtree level for holding various password policy-related entries for the subtree and all its children. For example:

Set the password policy attributes for the subtree or user entry with the appropriate values.

Table 19.2, “Password Policy-related Attributes” lists the attributes available to configure the password policy. The ldapmodify utility can be used to change these attributes in the subtree or user entry which contains the nsPwPolicyEntry object class.

Note

The nsslapd-pwpolicy-local attribute of the cn=config entry controls the type of password policy the server enforces. By default, this attribute is disabled (off). When the attribute is disabled, the server only checks for and enforces the global password policy; the subtree and user-level password policies are ignored. When the ns-newpwpolicy.pl script runs, it first checks for the specified subtree and user entries and, if they exist, modifies them. After updating the entries successfully, the script sets the nsslapd-pwpolicy-local configuration parameter to on. If the subtree and user-level password policy should not be enabled, be sure to set nsslapd-pwpolicy-local to off after running the script.

To turn off user- and subtree-level password policy checks, set the nsslapd-pwpolicy-local attribute to off by modifying the cn=config entry. For example:

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.