Password policy

 

With the use of LDAP servers for authentication, is important that a LDAP server support policies regarding password expiration, failed login attempts, and password rules. Directory Server provides configurable support for all three of these kinds of policies.

Password policy is applied to all directory entries having a userPassword attribute. You cannot define one policy for one set of users, and different policies for other sets of users. Directory Server also provides a mechanism for clients to be informed of password policy related conditions (password expires in three days), and a set of operational attributes that an administrator can use to search for such things as users with expired passwords or locked out accounts.

 

Configuration

You can configure behavior of the server with respect to passwords in the following areas:

• A global "on/off" switch for enabling or disabling password policy

• Rules for changing passwords, including:

  • Users can change their own passwords. Note that this policy applies in addition to any access control. That is, access control must give a user authority to change the userPassword attribute, as well as password policy allowing users to change their own passwords. If this policy is disabled, users cannot change their own passwords. Only an administrator or other user with authority to change the userPassword attribute can change the password for an entry.

  • Passwords must be changed after reset. If this policy is enabled, when a password is changed by anybody other than that user, the password is marked as reset and must be changed by the user before he can perform other directory operations. A bind request with a reset password is successful. To be notified that the password must be reset, the application must be password policy aware.

  • Users must send old password when changing password. If this policy is enabled, a password can be changed only by a modify request that includes both a delete of the userPassword attribute (with the old value) and an add of the new userPassword value. This ensures that only a user who knows their password can change it. The administrator, or other users authorized to change the userPassword attribute can always set the password.

• Rules for password expiration, including:

  • Passwords never expire, or passwords expire a configurable time after they were last changed.

  • Do not warn users when a password expires, or warn users a configurable time before the password expires. To be warned of approaching password expiration, the application must be password policy aware.

  • Allow a configurable number of grace logins after the user's password has expired. A password policy aware application will be notified of the number of remaining grace logins. If no grace logins are allowed, a user cannot authenticate or change their own password once it has expired.

• Rules for password validation, including:

  • A configurable password history size, which tells the server to keep a history of the last N passwords and reject passwords that have been previously used.

  • Password syntax checking, including a setting for how the server should behave when passwords are hashed. This setting affects whether the server should ignore the policy under either of the following conditions:

    • The server is storing hashed passwords.

    • A client presents a hashed password to the server (this can happen when transferring entries between servers using an LDIF file if the source server stores hashed passwords).

    In either of these cases the server might not be able to apply all syntax rules. The following syntax rules are supported: Minimum length, minimum number of alphabetic characters, minimum number of numeric or special characters, number of repeated characters, and number of characters in which the password must differ from the previous password.

• Rules for failed logins, including:

  • A minimum time allowed between password changes, which prevents users from quickly cycling through a set of passwords to get back to their original password.

  • A maximum number of failed login attempts before the account is locked.

  • A configurable password lockout duration. After this time, a previous locked account can be used. This can help to lockout a hacker attempting to crack a password, while aiding a user that has forgotten their password.

  • A configurable time for which the server keeps track of failed login attempts. If the maximum number of failed login attempts occurs within this time, the account is locked. Once this time has expired, the server discards information about previous failed login attempts for the account.

The password policy settings for the directory server are stored in the object "cn=pwdpolicy", which looks like this:

cn=pwdpolicy 
objectclass=container 
objectclass=pwdPolicy 
objectclass=ibm-pwdPolicyExt 
objectclass=top 
cn=pwdPolicy 
pwdExpireWarning=0 
pwdGraceLoginLimit=0 
passwordMaxRepeatedChars=0 
pwdSafeModify=false 
pwdattribute=userpassword 
pwdinhistory=0 
pwdchecksyntax=0 
passwordminotherchars=0 
passwordminalphachars=0 
pwdminlength=0 
passwordmindiffchars=0 
pwdminage=0 
pwdmaxage=0 
pwdallowuserchange=true 
pwdlockoutduration=0 
ibm-pwdpolicy=true 
pwdlockout=true 
pwdmaxfailure=2 
pwdfailurecountinterval=0 
pwdmustchange=false 

 

Password policy aware applications

The Directory Server password policy support includes a set of LDAP controls which can be used by a password policy aware application to receive notification of additional password policy related conditions.

An application can be informed of the following warning conditions:

• Time remaining before password expiration

• Number of grace logins remaining after the password has expired

An application can also be informed of the following error conditions:

• Password has expired

• Account is locked

• Password has been reset and must be changed

• User is not allowed to change their password

• Old password must be supplied when changing password

• New password violates syntax rules

• New password is too short

• Password has been changed too recently

• New password is in history

Two controls are used. A password policy request control is used to inform the server that the application wishes to be informed of password policy related conditions. This control must be specified by the application on all operations for which it is interested, typically the initial bind request and any password change requests. If the password policy request control is present, a password policy response control is returned by the server when any of the above error conditions are present.

The Directory Server client APIs include a set of APIs which can be used by C applications to work with these controls. These APIs are:

• ldap_parse_pwdpolicy_response

• ldap_pwdpolicy_err2string

For applications not using these APIs, the controls are defined below. You must use the capabilities provided by the LDAP client APIs being used to process the controls. For example, the Java™ Naming and Directory Interface (JNDI) has built-in support for some well-known controls, and also provides a framework for supporting controls that JNDI does not recognize.

 

Password Policy Request Control

Control name: 1.3.6.1.4.1.42.2.27.8.5.1 
Control criticality: FALSE 
Control value: None

 

Password Policy Response Control

Control name: 1.3.6.1.4.1.42.2.27.8.5.1 (same as the request control) 
Control criticality: FALSE 
Control value: A BER encoded value defined in ASN.1 as follows:  
  PasswordPolicyResponseValue ::= SEQUENCE { 
  warning	[0] CHOICE OPTIONAL { 
		timeBeforeExpiration	[0] INTEGER (0 .. MaxInt), 
		graceLoginsRemaining	[1] INTEGER (0 .. maxInt) } 
  error		[1] ENUMERATED OPTIONAL { 
		passwordExpired			(0), 
		accountLocked				(1), 
		changeAfterReset			(2), 
		passwordModNotAllowed	(3), 
		mustSupplyOldPassword	(4), 
		invalidPasswordSyntax	(5), 
		passwordTooShort			(6), 
		passwordTooYoung			(7), 
		passwordInHistory			(8) } } 

Like other LDAP protocol elements, the BER encoding uses implicit tagging.

 

Password policy operational attributes

The Directory Server maintains a set of operational attributes for each entry that has a userPassword attribute. These attributes can be searched by authorized users, either used in search filters, or returned by the search request. These attributes are:

• pwdChangedTime - A GeneralizedTime attribute containing the time the password was last changed.

• pwdAccountLockedTime - A GeneralizedTime attribute containing the time at which the account was locked. If the account is not locked, this attribute is not present.

• pwdExpirationWarned - A GeneralizedTime attribute containing the time at which the password expiration warning was first sent to the client.

• pwdFailureTime - A multi-valued GeneralizedTime attribute containing the times of previous consecutive login failures. If the last login was successful, this attribute is not present.

• pwdGraceUseTime - A multi-valued GeneralizedTime attribute containing the times of the previous grace logins.

• pwdReset - A Boolean attribute containing the value TRUE if the password has been reset and must be changed by the user.

• ibm-pwdAccountLocked - A Boolean attribute indicating that the account has been administratively locked.

 

Replication of Password Policy

Password policy information is replicated by supplier servers to consumers. Changes to the entry cn=pwdpolicy are replicated as global changes, like changes to the schema. Password policy state information for individual entries is also replicated, so that, for example, if an entry is locked on a supplier server, that action will be replicated to any consumers. Password policy state changes on a read-only replica do not replicate to any other servers, however.

 

Parent topic:

Directory Server security

 

Related concepts

Password tasks
Operational attributes