9.6. Designing a Password Policy

A password policy is a set of rules that govern how passwords are used in a given system. The Directory Server's password policy specifies the criteria that a password must satisfy to be considered valid, like the age, length, and whether users can reuse passwords.
The following sections provide more information on designing a sound password policy:

9.6.1. How Password Policy Works

Directory Server supports fine-grained password policy, which means password policies can be defined at the subtree and user level. This allows the flexibility of defining a password policy at any point in the directory tree:
  • The entire directory.
    Such a policy is known as the global password policy. When configured and enabled, the policy is applied to all users within the directory except for the Directory Manager entry and those user entries that have local password policies enabled.
    This can define a common, single password policy for all directory users.
  • A particular subtree of the directory.
    Such a policy is known as the subtree level or local password policy. When configured and enabled, the policy is applied to all users under the specified subtree.
    This is good in a hosting environment to support different password policies for each hosted company rather than enforcing a single policy for all the hosted companies.
  • A particular user of the directory.
    Such a policy is known as the user level or local password policy. When configured and enabled, the policy is applied to the specified user only.
    This can define different password policies for different directory users. For example, specify that some users change their passwords daily, some users change it monthly, and all other users change it every six months.
By default, Directory Server includes entries and attributes that are relevant to the global password policy, meaning the same policy is applied to all users. To set up a password policy for a subtree or user, add additional entries at the subtree or user level and enable the nsslapd-pwpolicy-local attribute of the cn=config entry. This attribute acts as a switch, turning fine-grained password policy on and off.
You can change password policies by using the command line or the web console. Use the dsconf pwpolicy command to change global policies and the dsconf localpwp command to change local policies. For more information about setting password policies, see the Administration Guide.

Note

The ns-newpwpolicy.pl script that previously managed local password policies has been deprecated. However, this script is still available in the 389-ds-base-legacy-tools package.
After password policy entries are added to the directory, they determine the type (global or local) of the password policy the Directory Server should enforce.
When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user's entry.
  • To determine whether the fine-grained password policy is enabled, the server checks the value (on or off) assigned to the nsslapd-pwpolicy-local attribute of the cn=config entry. If the value is off, the server ignores the policies defined at the subtree and user levels and enforces the global password policy.
  • To determine whether a local policy is defined for a subtree or user, the server checks for the pwdPolicysubentry attribute in the corresponding user entry. If the attribute is present, the server enforces the local password policy configured for the user. If the attribute is absent, the server logs an error message and enforces the global password policy.
The server then compares the user-supplied password with the value specified in the user's directory entry to make sure they match. The server also uses the rules defined by the password policy to ensure that the password is valid before allowing the user to bind to the directory.
Password Policy Checking Process

Figure 9.3. Password Policy Checking Process

In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute (explained in the following section) is present in the request.
Modifying the value of userPassword checks two password policy settings:
  • The password minimum age policy is activated. If the minimum age requirement has not been satisfied, the server returns a constraintViolation error. The password update operation fails.
  • The password history policy is activated. If the new value of userPassword is in the password history, or if it is the same as the current password, the server returns a constraintViolation error. The password update operation fails.
Both adding and modifying the value of userPassword checks password policies set for the password syntax:
  • The password minimum length policy is activated. If the new value of userPassword is less than the required minimum length, the server returns a constraintViolation error. The password update operation fails.
  • The password syntax checking policy is activated. If the new value of userPassword is the same as another attribute of the entry, the server returns a constraintViolation error. The password update operation fails.

9.6.2. Password Policy Attributes

The following sections describe the attributes to create a password policy for the server:
See the Red Hat Directory Server Administration Guide for instructions on how to set these attributes.

9.6.2.1. Maximum Number of Failures

This is a setting in the password policy which enables password-based account lockouts. If a user attempts to log in a certain number of times and fails, then that account is locked until an administrator unlocks it or, optionally, a certain amount of time passes. This is set in the passwordMaxFailure parameter.
There are two different ways to count login attempts when evaluating when the maximum number of failed attempts is reached. It can be a hard limit which locks the account when the number is hit (n) or which locks the account only when the count is exceeded (n+1). For example, if the failure limit is three attempts, then the account could be locked at the third failed attempt (n) or at the fourth failed attempt (n+1). The n+1 behavior is the historical behavior for LDAP servers, so it is considered legacy behavior. Newer LDAP clients expect the stricter hard limit. By default, the Directory Server uses the strict limit (n), but the legacy behavior can be enabled in the passwordLegacyPolicy parameter.

9.6.2.2. Password Change After Reset

The Directory Server password policy can specify whether users must change their passwords after the first login or after the password has been reset by the administrator.
The default passwords set by the administrator typically follow a company convention, such as the user's initials, user ID, or the company name. If this convention is discovered, it is usually the first value that a cracker uses in an attempt to break into the system. It is therefore recommended that users be required to change their password after it has been reset by an administrator. If this option is configured for the password policy, users are required to change their password even if user-defined passwords are disabled.
If users are not required or allowed change their own passwords, administrator-assigned passwords should not follow any obvious convention and should be difficult to discover.
The default configuration does not require that users change their password after it has been reset.
See Section 9.6.2.3, “User-Defined Passwords” for more information.

9.6.2.3. User-Defined Passwords

The password policy can be set either to allow or not to allow users to change their own passwords. A good password is the key to a strong password policy. Good passwords do not use trivial words; any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself), is a poor choice for a password.
A good password should contain a combination of letters, numbers, and special characters. For the sake of convenience, however, users often use passwords that are easy to remember. Consequently, some enterprises choose to set passwords for users that meet the criteria of a strong password, and do not allow users to change their passwords.
There are two disadvantages to having administrators set passwords for users:
  • It requires a substantial amount of an administrator's time.
  • Because administrator-specified passwords are typically more difficult to remember, users are more likely to write their password down, increasing the risk of discovery.
By default, user-defined passwords are allowed.

9.6.2.4. Password Expiration

The password policy can allow users to use the same passwords indefinitely or specify that passwords expire after a given time. In general, the longer a password is in use, the more likely it is to be discovered. If passwords expire too often, however, users may have trouble remembering them and resort to writing their passwords down. A common policy is to have passwords expire every 30 to 90 days.
The server remembers the password expiration specification even if password expiration is disabled. If the password expiration is re-enabled, passwords are valid only for the duration set before it was last disabled.
For example, if the password policy is set for passwords to expire every 90 days, and then password expiration is disabled and re-enabled, the default password expiration duration is 90 days.
By default, user passwords never expire.

9.6.2.5. Expiration Warning

If a password expiration period is set, it is a good idea to send users a warning before their passwords expire.
The Directory Server displays the warning when the user binds to the server. If password expiration is enabled, by default, a warning is sent (using an LDAP message) to the user one day before the user's password expires, provided the user's client application supports this feature.
The valid range for a password expiration warning to be sent is from one to 24,855 days.

Note

The password never expires until the expiration warning has been sent.

9.6.2.6. Grace Login Limit

A grace period for expired passwords means that users can still log in to the system, even if their password has expired. To allow some users to log in using an expired password, specify the number of grace login attempts that are allowed to a user after the password has expired.
By default, grace logins are not permitted.

9.6.2.7. Password Syntax Checking

Password syntax checking enforces rules for password strings, so that any password has to meet or exceed certain criteria. All password syntax checking can be applied globally, per subtree, or per user. Password syntax checking is set in the passwordCheckSyntax attribute.
The default password syntax requires a minimum password length of eight characters and that no trivial words are used in the password. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mailattributes of the user's entry.
Additionally, other forms of password syntax enforcement are possible, providing different optional categories for the password syntax:
  • Minimum required number of characters in the password (passwordMinLength)
  • Minimum number of digit characters, meaning numbers between zero and nine (passwordMinDigits)
  • Minimum number of ASCII alphabetic characters, both upper- and lower-case (passwordMinAlphas)
  • Minimum number of uppercase ASCII alphabetic characters (passwordMinUppers)
  • Minimum number of lowercase ASCII alphabetic characters (passwordMinLowers)
  • Minimum number of special ASCII characters, such as !@#$ (passwordMinSpecials)
  • Minimum number of 8-bit characters (passwordMin8bit)
  • Maximum number of times that the same character can be immediately repeated, such as aaabbb (passwordMaxRepeats)
  • Minimum number of character categories required per password; a category can be upper- or lower-case letters, special characters, digits, or 8-bit characters (passwordMinCategories)
  • Directory Server checks the password against the CrackLib dictionary (passwordDictCheck)
  • Directory Server checks if the password contains a palindrome (passwordPalindrome)
  • Directory Server prevents setting a password that has more consecutive characters from the same category (passwordMaxClassChars)
  • Directory Server prevents setting a password that contains certain strings (passwordBadWords)
  • Directory Server prevents setting a password that contains strings set in administrator-defined attributes (passwordUserAttributes)
The more categories of syntax required, the stronger the password.
By default, password syntax checking is disabled.

9.6.2.8. Password Length

The password policy can require a minimum length for user passwords. In general, shorter passwords are easier to crack. A good length for passwords is eight characters. This is long enough to be difficult to crack but short enough that users can remember the password without writing it down. The valid range of values for this attribute is from two to 512 characters.
By default, no minimum password length is set.

9.6.2.9. Password Minimum Age

The password policy can prevent users from changing their passwords for a specified time. When used in conjunction with the passwordHistory attribute, users are discouraged from reusing old passwords.
For example, if the password minimum age (passwordMinAge) attribute is two days, users cannot repeatedly change their passwords during a single session. This prevents them from cycling through the password history so that they can reuse an old password.
The valid range of values for this attribute is from zero to 24,855 days. A value of zero (0) indicates that the user can change the password immediately.

9.6.2.10. Password History

The Directory Server can store from two to 24 passwords in the password history; if a password is in the history, a user cannot reset his password to that old password. This prevents users from reusing a couple of passwords that are easy to remember. Alternatively, the password history can be disabled, thus allowing users to reuse passwords.
The passwords remain in history even if the password history is off so that if the password history is turned back on, users cannot reuse the passwords that were in the history before the password history was disabled.
The server does not maintain a password history by default.

9.6.2.11. Password Storage Schemes

The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. The Directory Server supports several different password storage schemes:
  • Salted Secure Hash Algorithm (SSHA, SSHA-256, SSHA-384, and SSHA-512). This is the most secure password storage scheme and is the default. The recommended SSHA scheme is SSHA-256 or stronger.
  • CLEAR, meaning no encryption. This is the only option which can be used with SASL Digest-MD5, so using SASL requires the CLEAR password storage scheme.
    Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store plain text passwords in the directory.
  • Secure Hash Algorithm (SHA, SHA-256, SHA-384, and SHA-512). This is less secure than SSHA.
  • UNIX CRYPT algorithm. This algorithm provides compatibility with UNIX passwords.
  • MD5. This storage scheme is less secure than SSHA, but it is included for legacy applications which require MD5.
  • Salted MD5. This storage scheme is more secure than plain MD5 hash, but still less secure than SSHA. This storage scheme is not included for use with new passwords but to help with migrating user accounts from directories which support salted MD5.

9.6.2.12. Password Last Change Time

The passwordTrackUpdateTime attribute tells the server to record a timestamp for the last time that the password was updated for an entry. The password change time itself is stored as an operational attribute on the user entry, pwdUpdateTime (which is separate from the modifyTimestamp or lastModified operational attributes).
By default, the password change time is not recorded.

9.6.3. Designing a Password Policy in a Replicated Environment

Password and account lockout policies are enforced in a replicated environment as follows:
  • Password policies are enforced on the data supplier.
  • Account lockout is enforced on all servers in the replication setup.
The password policy information in the directory, such as password age; the account lockout counter; and the expiration warning counter are all replicated. The configuration information, however, is stored locally and is not replicated. This information includes the password syntax and the history of password modifications.
When configuring a password policy in a replicated environment, consider the following points:
  • All replicas issue warnings of an impending password expiration. This information is kept locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times. In addition, if the user changes the password, it may take time for this information to filter through to the replicas. If a user changes a password and then immediately rebinds, the bind may fail until the replica registers the changes.
  • The same bind behavior should occur on all servers, including suppliers and replicas. Always create the same password policy configuration information on each server.
  • Account lockout counters may not work as expected in a multi-supplier environment.