Tivoli Directory Server 6.1 password policy : enhancements, configuration and troubleshooting

A password policy is a set of rules designed to enhance security by encouraging users to employ strong passwords and use them properly. A password policy is often part of an organization's official regulations which ensures that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. This article is intended to highlight the new features introduced with IBM® Tivoli® Directory Server (TDS) 6.1 release and describe the ways of debugging trivial password policy problems in TDS.

Nikhil Firke (nikhilfirke@in.ibm.com), System Software Engineer, IBM India Software Labs

Nikhil FirkeNikhil is a System Software Engineer, currently working with Tivoli Directory Server Level 2 support team, IBM India Software Labs. He holds a degree in Computer Engineering from Pune Institute of Computer Technology, Pune (India).



Nilesh T. Patel (nilesh.patel@in.ibm.com), System Software Engineer, IBM India Software Labs

Nilesh PatelNilesh is a System Software Engineer, currently working with level 2 Tivoli security team, IBM India Software Labs and he holds a degree in Information technology from Pune Institute of Computer Technology, Pune (India). His areas of expertise include IBM Tivoli Directory Server from the Tivoli Security Products and DB2®.



29 September 2008

Introduction

Password policy is a set of rules that controls how passwords are used and administered in the Directory Server. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts.

Before TDS 6.1 was released, cn=pwdpolicy was the only entry in which the password policy of the IBM Directory could be stored. All users, except directory administrators or members of administrative groups, were forced to comply with the rules defined in this entry. In TDS 6.1, more options are available. In addition to the global password policy, each user in the directory may have an individual password policy. Furthermore, to assist administrators, group password policy is supported to enable effective password management. When it is time to decide to which set of password rules a user should adhere, all three policies, if they exist, will be taken into consideration.

In addition to this, TDS 6.1 returns enhanced password policy related error messages. Besides IETF approved password policy error response codes, plain text messages are sent as part of the LDAP response protocol to improve usability and serviceability.

Some acronyms used throughout this article are given below :

  • TDS: Tivoli Directory Server
  • TAM: Tivoli Access Manager
  • WAS: Websphere® Application Server
  • DIT: Directory Information Tree
  • DN: Distinguished Name
  • IETF: Internet Engineering Task Force

Multiple password policies

Tivoli Directory Server 6.0 users had a restriction that they could only configure a global password policy with the entry cn=pwdpolicy . This policy, if enabled, all users, except the directory administrator or members of administrative group, are forced to comply with the rules defined in this entry. With the release of TDS 6.1, more options are available. In addition to the global password policy, each user in the directory may have an individual password policy. Furthermore, to assist administrators, group password policy is supported to enable effective password management. When it is time to decide to which set of password rules a user should adhere, all three policies, if they exist, will be taken into considerations.

1. Group password policy

With the introduction of group password policy, an association between a group object and a password policy entry is introduced so that the members of the group can be controlled by a set of special password rules. A new operational attribute, ibm-pwdGroupPolicyDN pointing to a password policy entry can be used in any user group objects, such as accessGroup, accessRole, groupOfNames, groupOfUniqueNames, ibm-nestedGroup and ibm-dynamicGroup, AIXaccessGroup, eNTGroup, ePasswordGenerator, ibm-globalAdminGroup, ibm-proxyGroup, ibm-staticGroup, seicResGroup.

Note:

If a user belongs to one or more group(s) that have cn=noPwdPolicy specified, and they belong to no groups for which the ibm-pwdGroupPolicyDN attribute refers to a valid password policy entry, and they have no individual password policy, then the user is exempt from any password policy rules.

Since a user entry may belong to more than one group, multiple group password policy entries will be evaluated before the user's group policy can be determined.

Attributes in all the group password policy entries are combined to form a union of attributes with the most restrictive attribute values taking precedence. By associating a value of cn=noPwdPolicy with attribute ibm-pwdGroupPolicyDN for a password policy extended group entry, an administrator may exempt that group's policy from being used in the evaluation of the composite group policy. This means, if a user belongs to a group to which a cn=noPwdPolicy is assigned, then the user's effective policy will not include any attributes from this group policy. Other group policies as well as the global policy and the individual policy will still be evaluated.

2. Individual password policy

Note:

Not all of the password policy attributes need to be defined in a user's individual or group password policy entry. During password policy evaluation time, a user's individual, group and global password policy are searched in this order. If an attribute is not defined in the individual password policy entry, it will be searched in the composite group password policy entry. If it is not found, the attribute in the global password policy entry will be used. In case the attribute is not defined in the global password policy entry, then a default value will be assumed.

With the introduction of individual password policy, every user is allowed to have his or her own password policy. With a new operational attribute, ibm-pwdIndividualPolicyDN pointing to a password policy entry, a user entry will have its own password policy entry. This named reference password policy design provides an easy way to associate multiple user entries to the same policy entry. By changing the attributes of the password policy entry, an administrator can effectively manage a set of users without modifying any of the user entries.

By assigning a value of cn=noPwdPolicy to attribute ibm-pwdIndividualPolicyDN for a password policy extended user entry, an administrator may exempt a user from any password policy controls. This is different from not defining the attribute in the entry. If the attribute is not defined, the user's effective password policy will be derived from the user's group if it exists and the global policy. However, if the attribute is defined with the special value, then the effective password policy will not be evaluated at all and the user will not be controlled by any password rules.

3.Global password policy

When the global password policy entry is created by a server, attribute ibm-pwdPolicy is set to FALSE, which means all password policy entries will be ignored by the server. Only when the attribute is set to TRUE, will the password rules be enforced by the server.

In the TDS releases before TDS 6.1, the global password policy entry cn=pwdPolicy was automatically replicated based on the replication topology specified for cn=ibmPolices. This setup is quite confusing. Now, from the TDS 6.1 release, this entry has been moved under cn=ibmPolicies. This means entry cn=pwdPolicy,cn=ibmPolicies will be replicated based on the replication topology defined for cn=ibmPolicies. This new setup not only consolidates IBM Directory policies into one place, but also makes the current replication topology setup for replicating global password policy easier to understand.

An auxiliary object called ibm-pwdGroupAndIndividualPolicies is introduced. This object class may only be added to the global password policy entry. The only attribute in this object class would be the "MUST" attribute - "ibm-pwdGroupAndIndividualEnabled". If global password policy is turned ON, a value of "TRUE" indicates that global, group and individual password policies are to be considered when evaluating password policy. A value of "FALSE" indicates that only the global password policy is used. The default value is FALSE.

Enhancement in password policy initialization

Previous to TDS 6.1 release, when a directory administrator first turns ON Password Policy on a populated directory, the server would query for all the entries in the directory that contain the userPassword attribute, and do not contain a pwdChangedTime attribute. For such entries the server then would create a pwdChangedTime attribute in the database containing the date/time at which the request to turn ON Password Policy was performed. Following were the problems in the previous release :

  • With respect to startup time: If there are less than a few hundred thousand entries in the directory that contain the userPassword attribute, the query and the update complete in a reasonable amount of time. If the directory gets very large, over a million users and up, then the amount of time it takes to find out which entries need this time stamp and then add these time stamps to the database gets very lengthy.
  • With respect to log size: The number and size of the DB2 transaction logs have to be increased in order to complete this operation properly. So, while this operation is being carried out the responsiveness of the server is reduced as well.
  • With respect to replication: pwdChangedTime attributes will not be consistent across the servers in the replicated environment. The pwdChangedTime attribute gets generated locally when each replica gets a request to "turn ON" password policy. So, if the directory contains a large amount of users, then the request on the master server may take a long time to complete, and it will not send the request to turn ON Password Policy to the peers or replicas until it has finished processing this request and has committed the changes. The pwdChangedTime attributes on each server down the line from the master will be further and further from the original pwdChangedTime on the master. Also, if a replica is currently off-line when Password Policy is turned ON, its value of pwdChangedTime attribute for all its users will not be set until it is turned back on, the initial value for this attribute could differ greatly from the other servers.
  • Another problem with respect to replication: Replication is multi-threaded, the replica server could try to process any password policy attributes that it receives from the master from normal operations on that server before the setup of Password Policy initialization is complete on the replica. Depending on what is being attempted, this could also cause inconsistencies in the data between the master and its peers or replicas.

To solve the above mentioned issues, the design has been modified for the initialization of password policy attributes. When Password Policy is first turned ON, a new Password Policy attribute, ibm-pwdPolicyStartTime is added to the cn=pwdPolicy,cn=ibmpolicies entry. This attribute will be generated by the server when the administrator sends a request to turn ON Password Policy.

Points to remember for ibm-pwdPolicyStartTime:

1. The current time will be put into this attribute.
2. This attribute is an optional attribute and cannot be deleted by a client request.
3. It cannot be modified by a client request except for administrators with administrative control.
4. It can be replaced by a master server generated request.
5. The value of this attribute is changed when the password policy gets turned OFF and ON by an administrator.

  • No user entries are modified at this time. During normal password policy functioning, if pwdChangedTime attribute does not exist for the entry being processed, the server will use the user entry's createTimestamp as the pwdChangedTime. The server will compare the pwdChangedTime with the value of the ibm-pwdPolicySTartTime attribute and use the more recent one.
  • The value of ibm-pwdPolicyStartTime will be replicated to all peers and replicas, so all the servers will now have the same value for the entry's pwdChangedTime attribute. When the master updates the pwdChangedTime attribute, the change is propagated to the replicas and this change is also present on the replicas in both the audit log, and the Changelog just as all the other Password Policy attributes. The setting of the pwdChangedTime attribute will still not be present in the audit log, or Changelog on the master, which is the same as changes to the other Password Policy attributes on the master if they are generated by an internal server operation, and not a direct request from the directory administrator.
  • By improving the performance of password policy startup time, the inconsistencies introduced by multi-threaded replication as described above in the write up, will be reduced.

Password policy configuration

Password policy can be defined and turned ON from the command line and the Web Admin Tool as well. Here, in this article we have shown how the password policy can be defined for a particular user or a group from command line. The Password Policy attributes mentioned below have been defined in the section "Meaning of Various Parameters in Password Policy".

Command Line configuration of password policy

Command to enable group and individual password policy
#idsldapmodify -D <AdminDN> -w <AdminPW> -p <port> -k 
 dn: cn=pwdpolicy,cn=ibmPolicies 
 ibm-pwdpolicy:true 
 ibm-pwdGroupAndIndividualEnabled:true
Command to define group password policy
#idsldapadd -D <AdminDN> -w <AdminPW> 
dn:cn=group_pwd_policy,cn=ibmPolicies 
objectclass: container 
objectclass: pwdPolicy 
objectclass: ibm-pwdPolicyExt 
objectclass: top 
cn:group_pwd_policy 
pwdAttribute: userPassword 
pwdGraceLoginLimit: 1 
pwdLockoutDuration: 30 
pwdMaxFailure: 2 
pwdFailureCountInterval: 5 
pwdMaxAge: 999 
pwdExpireWarning: 0 
pwdMinLength: 8 
pwdLockout: true 
pwdAllowUserChange: true 
pwdMustChange: false 
ibm-pwdpolicy:true
Command to define individual password policy
#idsldapadd -D <AdminDN> -w <AdminPW> 
dn:cn=individual1_pwd_policy,cn=ibmPolicies 
objectclass: container 
objectclass: pwdPolicy 
objectclass: ibm-pwdPolicyExt 
objectclass: top 
cn:individual1_pwd_policy
pwdAttribute: userPassword 
pwdGraceLoginLimit: 3 
pwdLockoutDuration: 50 
pwdMaxFailure: 3 
pwdFailureCountInterval: 7 
pwdMaxAge: 500 
pwdExpireWarning: 0 
pwdMinLength: 5 
pwdLockout: true 
pwdAllowUserChange: true 
pwdMustChange: false 
ibm-pwdpolicy:true

To associate the group and individual password policies with a group or a user, issue the following commands.

To associate a group password policy with a group:
#idsldapmodify -D <AdminDN> -w <AdminPW> -k 
dn:cn=group1,o=sample 
changetype:modify 
add:ibm-pwdGroupPolicyDN 
ibm-pwdGroupPolicyDN:cn=group_pwd_policy,cn=ibmPolicies
To associate an individual password policy with a user:
#idsldapmodify -D <AdminDN> -w <AdminPW> -k 
dn:cn=user1 ,o=sample 
changetype:modify 
add:ibm-pwdIndividualPolicyDN 
ibm-pwdIndividualPolicyDN:cn= individual1_pwd_policy,cn=ibmPolicies

Meaning of various parameters in password policy

This section defines the various password policy configuration attributes and the operational attributes. A small description of the attributes has been provided to help the users in defining and understanding the password policy.

Password policy configuration attributes

  • pwdPolicyStartTime: This attribute contains the time when the password policy was turned ON.
  • pwdAttribute: pwdAttribute attribute specifies the name of the attribute to which the password policy is being applied, this attribute can only be set to the userPassword attribute.
  • pwdMinAge: pwdMinAge attribute specifies the number of seconds that must pass since the last password modification, before modifying a password.
  • pwdMaxAge: pwdMaxAge attribute specifies the number of seconds after which a modified password will expire (0 means password does not expire).
  • pwdInHistory: pwdInHistory attribute specifies the number of passwords, which are stored in the pwdHistory attribute.
  • pwdCheckSyntax: pwdCheckSyntax attribute indicates whether or not the password will be checked for syntax. ( '0' means syntax checking will not be enforced, '1' means the server will check the syntax, and if the server is unable to check the syntax (due to a hashed password or other reasons) it will be accepted. '2' means the server will check the syntax, and if the server is unable to check the syntax it returns an error refusing the password).
  • pwdMinLength: pwdMinLength attribute specifies the minimum length of the password string.
  • pwdExpireWarning: pwdExpireWarning attribute specifies the maximum number of seconds before a password is about to expire that expiration warning messages will be returned to an authenticating user.
  • pwdGraceLoginLimit: pwdGraceLoginLimit attribute specifies the number of times an expired password can be used to authenticate user.
  • pwdLockoutDuration: pwdLockoutDuration attribute specifies the number of seconds that the password cannot be used to authenticate due to specified 'pwdMaxFailure' failed bind attempts.
  • pwdMaxFailure: pwdMaxFailure attribute specified the maximum number of consecutive failed bind attempts allowed, after which the password may not be used to authenticate.(0 means the value of pwdLockout will be ignored).
  • pwdFailureCountInterval: pwdFailureCountInterval attribute specifies the number of seconds after which the password failures are removed from the failure counter even though no successful authentication has happened.
  • passwordMinAlphaChars: passwordMinAlphaChars attribute specifies the minimum number of alphabet characters which the password string must have. If the server is unable to check the number of alphabetic characters, then the server will continue processing depending on the value of the pwdCheckSyntax attribute.
  • passwordMinOtherChars: passwordMinOtherChars attribute specifies the minimum number of numeric and special characters which the password string must have. If the server is unable to check the number of other characters, then the server will continue processing depending on the value of the pwdCheckSyntax attribute.
  • passwordMaxRepeatedChars: passwordMaxRepeatedChars attribute specifies the maximum number of times a given character can be used in a password. If the server is unable to check the actual password characters, then the server will continue processing depending on the value of the pwdCheckSyntax attribute.
  • passwordMinDiffChars: passwordMinDiffChars attribute specifies the minimum number of characters in the new password that must be different from the characters in the old password, and any passwords stored in the pwdHistory. If the password has been one-way encrypted the server is unable to check actual password characters, then the server will continue processing depending on the value of the pwdCheckSyntax attribute.
  • ibm-pwdPolicy: ibm-pwdPolicy attribute specifies whether the password policy is turned ON or OFF.
  • pwdLockout: pwdLockout attribute indicates whether or not a password may be used to authenticate after a specified number of consecutive failed bind attempts.
  • pwdAllowUserChange: pwdAllowUserChange attribute specifies whether or not the users are allowed to change their own passwords
  • pwdMustChange: pwdMustChange attribute specifies whether or not the users must change their password when they first bind to the directory after the administrator has reset their password.
  • pwdSafeModify: pwdSafeModify attribute specifies whether or not the existing password must be sent when changing a password.
  • pwdGroupAndIndividualEnabled: pwdGroupAndIndividualEnabled attribute determines if the Group Password policy and the Individual Password policies have to be considered or not during the Effective Password policy evaluation.

Password policy Operational attributes

  • pwdAccountLockedTime: Contains the time at which the account was locked. If the account is not locked, this attribute is not present.
  • pwdChangedTime: Contains the time the password was last changed or the password policy start time whichever is recent.
  • pwdExpirationWarned: Contains the time at which the password expiration warning was first sent to the client.
  • pwdFailureTime: A multi-valued attribute containing the times of previous consecutive login failures. If the last login was successful, this attribute is not present.
  • pwdGraceUseTime: A multi-valued attribute containing the times of the previous grace logins.
  • pwdReset: Contains the value TRUE if the password has been reset and must be changed by the user. The value is FALSE or not present.
  • ibm-pwdAccountLocked: Indicates that the account has been administratively locked.
  • ibm-pwdIndividualPolicyDn: DN of a password policy entry which can be associated with a user entry.
  • ibm-pwdGroupPolicyDn: DN of a password policy entry which can be associated with a group entry.

TDS 6.1 Password policy debugging practices

This section not only lists various commands which the users can use to debug the problems with the password policies but the sections also includes general commands which can be used by the password policy administrators for day to day working with password policy.

1. Collect password policy attributes.

To debug the problems with Password Policy, it is better to start from the password policy operational attributes and other effective password policy attributes. Collect such attributes on a given user using the following commands:

Operational Attributes on a given user can be listed using the following ldapsearch command :

#idsldapsearch -D <AdminDN> -w <AdminPW> -s base -b "<UserEntryDN>" 
 objectclass=* +ibmpwdpolicy

Global Password Policy settings can be listed using the following ldapsearch command :

#idsldapsearch -D <AdminDN> -w <AdminPW> -s base -b "cn=pwdpolicy,cn=ibmPolicies" 
 objectclass=*

Group / User Password Policies can be listed using the following ldapsearch command :

#idsldapsearch -D <AdminDN> -w <AdminPW> -s sub -b " " objectclass=ibm-pwd*

Effective Password Policy on a Given User can be calculated using the following ldapexop command :

#idsldapexop -D <AdminDN> -w <AdminPW> -op effectpwdpolicy -d "<UserEntryDN>"

2. Listing password policy DN in a user/group.

If ibm-pwdGroupAndIndividualEnabled is set to true from above search results, then a particular group and user might have a separate password policy defined to it . To list such password policies, refer to the commands below :

Password Policy DN can be collected from a Group entry with the following ldapsearch command :

#idsldapsearch -D <AdminDN> -w <AdminPW> -s base -b <GroupEntryDN> 
 objectclass=* ibm-pwdGroupPolicyDN

User password policy DN can be collected from a user entry by running the following ldapsearch command :

#idsldapsearch -D <AdminDN> -w <AdminPW> -s base -b <UserEntryDN> 
 objectclass=* ibm-pwdIndividualPolicyDN

3. To query for entries for which the password is about to expire.

Use the pwdChangedTime attribute to list the users whose passwords are going to expire on a particular date with a password expiration policy of certain number of days. Below example ldapsearch would list the users whose passwords are expiring on May 5th, 2008 with a password expiration policy of 100 days. This search queries for the entries whose pwdChangedTime is set to a date which is 100 days before May 5, 2008. pwdChangedTime is set to less than or equal to the midnight of January 26, 2008.

#idsldapsearch -D <AdminDN> -w <AdminPW> -b <Base DN for User Subtree> 
 -s sub "(!(pwdChangedTime>=20080126000000Z))" dn

4. To query for locked accounts.

Use the pwdAccountLockedTime attribute to verify if the account is locked.

#idsldapsearch -D <AdminDN> -w <AdminPW> -b <Base DN for User subtree>
 -s sub "(pwdAccountLockedTime=*)" dn

5. To query for accounts whose password must be changed.

Use the pwdReset attribute to list the accounts for which the password must be changed because the password was reset.

#idsldapsearch -D <AdminDN> -w <AdminPW> -b <Base DN for User subtree>
 -s sub "(pwdReset=TRUE)" dn

6. Set non expiring passwords.

Use the pwdChangedTime attribute to prevent the password of an account from expiring. Set the pwdChangedTime attribute to a date far in the future when setting the userPassword attribute. The following example sets the time to midnight, January 1, 2200.

#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: uid=wasadmin,cn=users,o=ibm 
changetype: modify 
replace: pwdChangedTime 
pwdChangedTime: 22000101000000Z

7. Unlock an account.

Use the pwdAccountLockedTime and pwdFailureTime attributes to unlock an account which has been locked due to excessive login failures. Such accounts can be unlocked by removing the pwdAccountLockedTime and pwdFailureTime attributes.

#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn:  <DN of the locked account>
changetype: modify 
delete: pwdAccountLockedTime 
-
delete: pwdFailureTime

8. Unlock an expired account.

Use the pwdChangedTime,pwdExpirationWarned and pwdGraceUseTime attributes to unlock an expired account. Such accounts can be unlocked by changing the pwdChangedTime and clearing the pwdExpirationWarned and pwdGraceUseTime attributes.

#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: <DN of the locked account>
changetype: modify 
replace: pwdChangedTime 
pwdChangedTime: yyyymmddhhss.Z 
-
delete: pwdExpirationWarned 
- 
delete: pwdGraceUseTime

9. Reset the "password must be changed" status.

Use the pwdReset attribute to clear the "password must be changed" status by deleting and adding the pwdReset attribute.

#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: <UserDN> 
changetype: modify 
delete: pwdReset  


#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: <UserDN> 
changetype: modify 
replace: pwdReset 
pwdReset: TRUE

10. Administrative locking and unlocking of account.

Use the ibm-pwdAccountLocked attribute for administrative locking and unlocking of account. An account can be administratively locked by setting the ibm-pwdAccountLocked operational attribute to TRUE. Similarly, an account can be administratively unlocked by setting the ibm-pwdAccountLocked operational attribute to FALSE.

#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: <UserDN to be locked> 
changetype: modify 
replace: ibm-pwdAccountLocked 
ibm-pwdAccountLocked: TRUE 
 
#idsldapmodify -D <AdminDN> -w <AdminPW> -k
dn: <UserDN to be locked> 
changetype: modify 
replace: ibm-pwdAccountLocked
ibm-pwdAccountLocked: FALSE

Unlocking an account in this way does not affect the state of the account with respect to being locked due to excessive password failures or an expired password. The user setting this attribute must have permission to write the ibm-pwdAccountLocked attribute, which is defined as being in the CRITICAL access class.

If the account is locked because the attribute ibm-pwdAccountLocked is set to TRUE and if the administrator clears this attribute (sets it to FALSE) and uses the administrative control (-k option), then the account is completely unlocked. The pwdAccountLockedTime and pwdFailureTime attributes are also cleared and reset.


Common Errors and Their Solutions

This section list the most common errors encountered by the users while working with passwords and password policy. This section also describes the solution to the errors mentioned.

  • Authentication error: Either the user name or password (or both) is incorrect, or the password has expired. The login failed because the specified user name or password is incorrect, or the password might have expired. Attempt to log in again by specifying the correct user name and password. If you still receive an error, then Check if the account has expired or if it has been locked.
  • Password policy rule violated. Verify the input given. The specified input violates at least one of the password policy rules. Following are the password policy rules :
    1. pwdMinLength should be greater than pwdMinOtherChars + passwordAlphaChars
    2. pwdMinLength should be greater than pwdMinDiffChars
    3. pwdMaxAge should be greater than pwdMinAge
    4. pwdMaxAge should be greater than pwdExpireWarning
    5. pwdAllowUserChange has to be TRUE, if pwdMustChange is TRUE
  • The password policy entry DN of entry is in use and cannot be renamed or deleted. The password policy entry is referenced by other entries as either an individual password policy or a group password policy and, therefore, cannot be renamed or deleted. Make sure the password policy entry to be deleted or renamed is not referenced by any other entries.
  • The password policy entry DN of entry referenced by entry DN of entry is not valid. OR The DN of the password policy entry DN of entry referenced by entry DN of entry cannot be found. The DN of the password policy entry specified for the user or group entry is not valid. The DN of the password policy entry must be specified in accordance with DN grammar or the DN of the password policy entry specified for the user or group entry does not exist. The password policy entry specified for the user or group entry must be created first.

TDS password policy adaption for TAM, WAS and other products

Some of our customers, such as WAS, who are unable to parse pwdPolicyResponse control in a LDAP response, require more information which can help them to distinguish between the various password policy errors and incorrect password. Other customers, such as TAM, who are able to parse pwdPolicyResponse control, also require detailed messages which are more granular than what TDS has been providing.

To satisfy both kinds of customers, a common field in a LDAP response protocol is used to provide more information. An error message in text form will be put into the error message field in the LDAPResult protocol sequence, in case an error has happened during a password policy related operation.

Sample IETF Bind protocol
LDAPResult  :: = SEQUENCE {
         resultCode       ENUMERATED {
                          success (0),
                       ...}
         matchedDN     LDAPDN,
         errorMessage  LDAPString,
         referral      [3] Referral OPTIONAL  }



                            
BindResponse  :: = [APPLICATION 1] SEQUENCE {
          COMPONENTS OF LDAPResult,
          ...}



LDAPMessage  :: = SEQUENCE {
          MessageID       MessageID,
          protocolOp        CHOICE {
                            bindResponse  BindResponse,
                            addResponse  AddResponse,
                                  ...},
          controls        b [0] Controls OPTIONAL }

The following table lists the messages that will be sent in addition to the supported resultCode and the possible error code in the passwordPolicyResponse (embedded in the control field of a response). Customers, such as TAM, after parsing the resultCode and error code in the passwordPolicyResponse control, may continue parsing the response protocol to get more information about the possible failure of an operation.

Table 1.List of the additional messages in the passwordPolicyResponse for TAM.
resultCodeError code in passwordPolicyResponseError messages in text form
constraintViolation (19)invalidPasswordSyntax(5)Failed passwordMinAlphaChars policy.

Failed passwordMinOtherChars policy.

Failed passwordMaxRepeatedChars policy.

Failed passwordMinDiffChars policy.

The following table lists the resultCode and messages that will be sent if the client does not know how to parse a passwordPolicyResponse control. Customers, such as WAS, after getting an unsuccessful resultCode for a password policy related operation, may continue to parse the response protocol to get more information about the possible failure. The error text messages chosen here are consistent with the messages that are currently used by TDS CLI utilities.

Table 2.List of the additional messages in the passwordPolicyResponse for WAS
OperationresultCodeError message in text form
Bind - no remaining grace logins leftLDAP_INVALID_CREDENTIALS (49)Error, Password has expired
Bind LDAP_UNWILLING_TO_PERFORM (53)Error, Account is locked
ModifyLDAP_UNWILLING_TO_PERFORM (53)Error, Must supply old password
ModifyLDAP_UNWILLING_TO_PERFORM (53)Error, Password must be changed after reset
ModifyLDAP_UNWILLING_TO_PERFORM (53)Error, Password may not be modified
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password too young
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password too short
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password alpha characters too few
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password other characters too few
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password repeated characters too many
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password different characters too few
ModifyLDAP_CONSTRAINT_VIOLATION (19)Error, Password in History
AddLDAP_UNWILLING_TO_PERFORM (53)Error, Password must be changed after reset
ComparecompareFalse (5)Error, Account is locked
ComparecompareFalse (5)Error, Password has expired

Tips for Administrators

Below are the few points that must be kept in mind while working with Password Policy attributes. These points would help the administrator in maintaining the Password policy effectively :

  • Assigning global policy to a user as an individual or a group policy should avoided.
    To improve performance, during server startup time, a flag will be set if password policy entries (except for the global password policy) exist in DIT and references to password policy entries are defined (i.e., both the pwdGrpPolicyDN table and pwdIndPolicyDN table are not empty). If the flag is set, then a user's effective password policy will be evaluated by searching the user's individual and group policies; otherwise, no searches will be attempted and the global policy, if it is turned ON, will be used as the user's effective policy. Keeping this in mind, assigning global policy to a user as an individual or a group policy should be avoided as it may affect the performance of the server.
  • Bind performance may be degraded.
    Prior to TDS 6.1 release, for each directory update or search operation, a user's group membership evaluation takes place prior to the operation and after the user has successfully bound. This "lazy group evaluation" improves bind performance significantly. However, with this feature, in order to authenticate a user during bind time, the user's group password policy has to be determined. To determine a user's group policy, group membership has to be resolved. The "lazy group evaluation" scheme can no longer apply and, therefore, bind performance may be degraded.
  • All the group entries need to be resided in each backend servers.
    In a distributed directory environment, a backend server may not be able to locate all the group entries to which a user belongs locally on the server. Without the group entries, information such as the password policy DN of a group cannot be found, and therefore, a user's effective password policy cannot be evaluated. In this release, in order to support distributed directory environments, all the group entries need to be resided in each backend servers to ensure the correct evaluation of a user's/group's effective password policy.
  • Permissions to update the password policy attributes.
    Password policy related operational attributes, such as pwdChangedTime, pwdAccountLockedTime, pwdExpirationWarned, pwdReset, pwdFailureTime, pwdHistroy and pwdGraceUseTime can be updated by master server and administrative users such as directory administrator, local administration group member and global administration group member using administrative control. With this control, the same set of users are also allowed to update the attributes - ibm-pwdGroupPolicyDN and ibm-pwdIndividualPolicyDN.
  • Replicating password policy operational attributes.
    The user-related elements of the password policy are stored in the entries as operational attributes. These attributes are subject to modifications even on a read-only replica, so replicating these attributes must be carefully considered.
    1. pwdChangedTime The pwdChangedTime attribute must be replicated on all replicas, to enable expiration of the password.
    2. pwdReset The pwdReset attribute must be replicated on all replicas, to deny access to operations other than bind and modify password.
    3. pwdHistory The pwdHistory attribute must be replicated to writable replicas. This attribute does not need to be replicated to a read-only replica, as the password is never directly modified on this server.
    4. pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime, pwdGraceUseTime The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and pwdGraceUseTime
      • Attributes must be replicated to writable replicas, making the password policy global for all servers.
      • When the user entry is replicated to a read-only replica, these attributes must not be replicated. This means that the number of failures, the number of grace logins and the locking take place on each replicated server. There are times when the values of pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and pwdGraceUseTime are replicated.
      • If the user's password is reset, thereby clearing some of these attributes, this action is replicated to the read-only replicas.
      • If an administrator on the master server uses the administrative control to overwrite the values of these attributes on the master server, this forced write of the operational attributes is also replicated to read-write and read-only replicas.
    5. ibm-pwdAccountLocked When the ibm-pwdAccountLocked attribute is set or cleared on the master server, this attribute is also replicated to the replicas. When this attribute is cleared while using the administrative control on the operation, the pwdAccountLockedTime attribute is also cleared so that the account is totally unlocked when this attribute is set to FALSE.
  • Forcing an add or update for an entry.
    When an administrative user updates or adds an entry, specifying a password policy operational attribute as one of the attributes to be changed or in the case of a new entry, the administrative user specifies a value for one or more of the operational attributes, then the administrative user is performing a forced add/update for the entry. A forced add/update of an entry means that the normal password policy processing is not performed for that entry. When the administrator is performing a forced add/update to an entry, the administrator has the intention to set all of the password policy attributes as the entry requires. Do not force an add unless all of the normal password policy operational attributes have been given an appropriate value, such as pwdReset and pwdChangedTime. If pwdChangedTime is not given a value on a forced add, then this attribute is not set until the user first attempts to bind to the server, or until another forced update creates a time for this attribute.

    If any of the password policy attributes need to be specifically set on an add operation, the new entry should be created first and a separate modify operation should be used to set any other password policy attribute. If the userPassword attribute is being modified on the modify operation, then any password policy attributes that are to be force updated must be updated separate from the userPassword modification operation. This ensures that all of the proper password policy changes that occur on an add or modify operation are performed.


Reference

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Tivoli, Security
ArticleID=322655
ArticleTitle=Tivoli Directory Server 6.1 password policy : enhancements, configuration and troubleshooting
publish-date=09292008