Password Policies and Worksheet

This section explains password policy settings and provides a worksheet to help you define password policies that fit your requirements.

Password Policy Settings

When you specify a password policy in Directory Server, you either modify or create an entry that includes the object class pwdPolicy(5dsoc).

When defining a password policy for a particular type of user, you need to consider the following:

• How accounts get locked out when an intruder appears to be trying to crack a password.

  See Policy for Account Lockout for details.

• How password changes can be made.

  See Policy for Password Changes for details.

• What password values are allowed.

  See Policy for Password Content for details.

• How password expiration is handled.

  See Policy for Password Expiration for details.

• If the server records the time of the last successful authentication.

  See Policy for Tracking Last Authentication Time.

Subsequent sections in this chapter explain how you handle these areas of password policy. Use the Worksheet for Defining Password Policy to clarify each password policy that you plan to implement.

Policy for Account Lockout

This section explains the policy attributes that govern account lockout.

A Directory Server account refers loosely to a user's entry and to the permissions that user has to perform operations on the directory. Each account is associated with a bind DN and a user password. When an intruder appears to be trying to crack a password, you want Directory Server to lock the account. The lock prevents the intruder from using the account to bind. The lock also prevents the intruder from being able to continue the attack.

As administrator, you can also manually render inactive an account or the accounts of all users who share a role. See Manually Locking Accounts for instructions. Yet, a key part of your password policy is specifying under what circumstances Directory Server locks an account without your intervention.

First of all, you must specify that Directory Server can use pwdLockout(5dsat) to automatically lock accounts when too many failed binds occur. Directory Server keeps track of consecutive failed attempts to bind to an account. You use pwdMaxFailure(5dsat) to specify how many consecutive failures are allowed before Directory Server locks the account.

Directory Server locks accounts strictly according to password policy. The operation is purely mechanical. Accounts can lock not because an intruder is mounting an attack against the account, but because the user typed the password incorrectly. Thus, you can use pwdFailureCountInterval(5dsat) to specify how long Directory Server should wait between tries before cleaning out the records of failed attempts. You use pwdLockoutDuration(5dsat) to specify how long lockout should last before Directory Server automatically unlocks the account. The administrator does not have to intervene to unlock accounts of users who make legitimate mistakes with no malicious intent.

If your user data is replicated across a replication topology, lockout attributes are replicated along with other entry data. The pwdIsLockoutPrioritized(5dsat) attribute's default setting is TRUE, so updates for lockout attributes are replicated with a higher priority. A user is thus limited to making pwdMaxFailure consecutive failed attempts to bind to any single replica before being locked out, and probably fewer attempts at other replicas before being locked out. For details about how to make sure that a user gets exactly pwdMaxFailure attempts before being locked out across an entire replicated topology, see Preventing Authentication by Using Global Account Lockout in Oracle Directory Server Enterprise Edition Deployment Planning Guide.

Policy for Password Changes

This section explains the policy attributes that govern changes to passwords.

In many deployments, Directory Server is the repository for identity data. Users should be able to change their own passwords, as specified by pwdAllowUserChange(5dsat), so you do not have to change the passwords.

After you allow users to change their own passwords, you might also want to control the circumstances under which users can change their passwords. You can use pwdSafeModify(5dsat) to specify that users who change a password must provide the correct existing password before they are allowed to replace the password. See Modifying Passwords From the Command Line When pwdSafeModify Is TRUE for an example of how to modify the password. You can prevent users from reusing passwords by using pwdInHistory(5dsat) to specify how many passwords Directory Server remembers. You can also prevent users from changing their passwords too often by setting pwdMinAge(5dsat).

In many cases either you as administrator or some application that you manage creates user entries in the directory. You can assign a user password value to change when the user first binds to the new account. You might also have to reset a user password, after which the user should change the password when next using the account. Directory Server has a specific attribute, pwdMustChange(5dsat), that you can use to indicate whether a user must change passwords after the password value is reset by another user.

You can also specify that the Directory Administrator is not subject to policy when changing passwords by setting passwordRootdnMayBypassModsChecks(5dsat).

Policy for Password Content

This section explains the policy attributes that govern password content.

Although password values are not generally returned in directory searches, an attacker could potentially gain access to the directory database. Therefore, password values are generally stored in one of the supported hashed formats that you specify using passwordStorageScheme(5dsat).

You can also enforce a check that passwords meet your definition of minimum password quality, by setting pwdCheckQuality(5dsat). The server then checks that the password does not match any of the values of the cn, givenName, mail, ou, sn, or uid attributes. The comparison of the password with any of these attributes is case-insensitive.

Additional checks are available with pwdCheckQuality(5dsat) set. You can enforce that passwords have at least a specified number of characters by setting pwdMinLength(5dsat). Furthermore, when the Strong Password Check plug-in is enabled, Directory Server checks that the password does not contain strings from the dictionary file that the plug-in uses. The server also checks that the password contains an appropriate mix of different types of characters.

You can enable strong password checking with the dsconf set-server-prop command. Use the pwd-strong-check-enabled property to turn on the plug-in, and restart the server for the change to take effect. Use the pwd-strong-check-require-charset property to specify what character sets to require in passwords. The pwd-strong-check-require-charset property takes a mask of the following values:

lower

The new password must include a lower case character.

upper

The new password must include an upper case character.

digit

The new password must include a digit.

special

The new password must include a special character.

any-two

The new password must include at least one character from each of at least two of the above mentioned character sets.

any-three

The new password must include at least one character from each of at least three of the above mentioned character sets.

The default setting for the pwd-strong-check-require-charset property is lower && upper && digit && special.

Policy for Password Expiration

This section explains the policy attributes that govern password expiration.

To ensure that users change their passwords regularly, you can configure Directory Server to have passwords expire after the passwords reach a certain age, by setting pwdMaxAge(5dsat).

Users must be informed that their passwords are going to expire. You can configure Directory Server to return a warning that the password used to bind is going to expire. Use pwdExpireWarning(5dsat) to define how long before expiration that the warning should be returned when a client binds. Notice that the client application gets the warning. The user does not get the warning directly. Client applications must notify the end user when the applications receive the warning that the password is about to expire.

You can allow users one or more tries to bind with an expired password, by setting pwdGraceAuthNLimit(5dsat). Users who failed to change their passwords in time can thus still bind to change their passwords. Be aware that, when a user binds with a grace login, the user can perform any operation. A grace login works as if the password had not expired.

Directory Server updates the operational attribute pwdChangedTime(5dsat) every time that the password on the entry is modified. As a result, if you wait to enable password expiration, user passwords that have already aged expire immediately when you enable password expiration. Use warnings and grace logins if this behavior is not what you intend.

Policy for Tracking Last Authentication Time

This section covers the use of the password policy attribute pwdKeepLastAuthTime(5dsat).

When set, pwdKeepLastAuthTime causes Directory Server to track the time of the last successful bind every time that a user authenticates. The time is recorded on the pwdLastAuthTime(5dsat) operational attribute of the user's entry.

Because this behavior adds an update for each successful bind operation, the pwdKeepLastAuthTime feature is not activated by default. You must explicitly turn the feature on to use it in your deployment.

Worksheet for Defining Password Policy

This worksheet is designed to help you define a password policy to implement either through the command-line interface or using Directory Service Control Center (DSCC). Use one worksheet for each password policy.

After you record the DN of the password policy entry, record your decisions about settings for attributes in each policy area. Also record your rationale for those settings.