P.Behera Internet Draft V. Chu Expires in Six months Netscape Intended Category: Proposed Standard L. Poitou Expires: 20 April 2000 Sun Microsystems J. Sermersheim Novell 20 October 1999 Password Policy for LDAP Directories 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract Password policy is a set of rules that controls how passwords are used in LDAP directories. 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 attempts. 3. Overview LDAP-based directory services currently are accepted by many organizations as the access protocol for directories. The ability to ensure the secure read and update access to directory information throughout the network is essential to the successful deployment. Most LDAP implementations support many Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 1] Internet-Draft Password Policy 20 October 1999 authentication schemes - the most basic and widely used is the simple authentication i.e., user DN and password. In order to achieve greater security protection and ensure interoperability in a heterogeneous environment, LDAP needs to standardize on a password policy model, and it is critical to the successful deployment of LDAP directories. Specifically, the password policy defines: 1. The maximum length of time that a given password is valid. 2. The minimum length of time required between password changes. 3. The amount of time before a user's password is due to expire that the user will be sent a warning message. 4. Whether users can reuse passwords. 5. The minimum number of characters a password must contain. 6. Whether the password syntax is checked before a new password is saved. 7. Whether users are allowed to change their own passwords. 8. Whether passwords must be changed after the administrator resets them. 9. Whether users will be locked out of the directory after a given number of failed bind attempts. 10. How long users will be locked out of the directory after a given number of failed bind attempts. 11. The length of time before the password failure counter, which keeps track of the number of failed password attempts, is reset. 12. The number of times users are allowed to bind with an expired password in order to reset their password. 13. Whether users can change their password without specifying the old password The password policy defined in this document is applied to the userPassword attribute values only in case of the LDAP simple authentication method [RFC-2251], the password based SASL mechanisms such as CRAM-MD5 [RFC-2195] and HTTP-Digest [RFC- 2222], add, modify, and compare operations. In this document, the term "user" represents any application which is an LDAP client using the directory to retrieve or store information. Directory administrators are not forced to comply with any of password policy. 4. New Attribute Types and Object Classes 4.1 The pwdPolicy Object Class ( NAME 'pwdPolicy' AUXILIARY SUP top DESC 'Password Policy object class to hold password policy information' Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 2] Internet-Draft Password Policy 20 October 1999 MAY (pwdMaxAge $ pwdMinLength $ pwdInHistory $ pwdAllowUserChange $ pwdCheckSyntax $ pwdExpireWarning $ pwdLockout $ pwdMaxFailure $ pwdLockoutDuration $ pwdMustChange $ pwdDefaultStorageScheme $ pwdMinAge $ pwdFailureCountResetTime $ pwdGraceLoginLimit $ pwdSafeModify ) ) 4.2 Attribute types used by the pwdPolicy Object Class ( pwdSchema.1.0 NAME 'pwdMaxAge' DESC'the number of seconds after which user passwords will expire. A value of 0 means the password never expires.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.1 NAME 'pwdMinLength' DESC'the minimum number of characters that must be used in a passwordÆ EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.2 NAME 'pwdInHistory' DESC'the number of passwords the directory server stores in history. A value of 0 means passwords can be reused' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.3 NAME 'pwdAllowUserChange' DESC'a flag which indicates whether users can change their passwords' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.4 NAME 'pwdCheckSyntax' DESC'a flag which indicates whether the password syntax will be checked before the password is saved' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 3] Internet-Draft Password Policy 20 October 1999 USAGE directoryOperation ) ( pwdSchema.1.5 NAME 'pwdExpireWarning' DESC'the maximum number of seconds before a password is due to expire that a warning message is to the user. A value of 0 means no warning will be sentÆ EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.6 NAME 'pwdLockout' DESC'a flag which indicates whether users will be locked out of the directory after a given number of consecutive failed bind attempts' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation) ( pwdSchema.1.7 NAME 'pwdMaxFailure' DESC'the number of consecutive failed bind attempts after which a user will be locked out of the directory' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.8 NAME 'pwdLockoutDuration' DESC'the number of seconds that users will be locked out of the directory after an account lockout. A value of 0 means the account will be locked until reset' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.9 NAME 'pwdMustChange' DESC'a flag which indicates whether users must change their passwords when they first bind to the directory server' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.10 NAME 'pwdDefaultStorageScheme' Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 4] Internet-Draft Password Policy 20 October 1999 DESC'the type of hash algorithm used to store directory server passwords' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation ) The description of password storage scheme can be found in [RFC- 2307]. One additional storage scheme not mentioned there is "CLEARTEXT". ( pwdSchema.1.11 NAME 'pwdMinAge' DESC'the number of seconds that must elapse before a user can change their password again' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.12 NAME 'pwdFailureCountResetTime' DESC'the number of seconds after which the password failure counter will be reset.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.13 NAME 'pwdGraceLoginLimit' DESC'the number of times an expired password can be used to access an account' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) ( pwdSchema.1.14 NAME 'pwdSafeModify' DESC'whether the existing password must be sent when changing a password' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) 4.3 The pwdInfObject Object Class The pwdInfObject object class holds the password policy state information for each user. For example, how many consecutive bad Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 5] Internet-Draft Password Policy 20 October 1999 password attempts a user made. The information is located in each user entry. The description of pwdInfObject object class: ( NAME 'pwdInfObject' AUXILIARY SUP top DESC'Password object class to hold password policy information in each entryÆ MAY ( pwdExpirationTime $ pwdExpWarned $ pwdRetryCount $ pwdRetryCountResetTime $ pwdAccountUnlockTime $ pwdHistory $ pwdAllowChangeTime $ pwdGraceLeft ) ) 4.4 Attribute types used by the pwdInfObject Object Class ( pwdInfObject.1.1 NAME 'pwdExpirationTime' DESC'the time the entry's password expires. A 0 means that the password has expired. If this attribute does not exist, the password will never expire' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE USAGE directoryOperation) ( pwdInfObject.1.2 NAME 'pwdExpWarned' DESC'a flag which indicates whether a password expiration warning has already been sent to the client. This prevents the server from sending multiple warning messages' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation) ( pwdInfObject.1.3 NAME 'pwdRetryCount' DESC 'the count of consecutive failed login attempts' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation) ( pwdInfObject.1.4 NAME 'pwdRetryCountResetTime' DESC 'the time to reset the pwdRetryCount' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE USAGE directoryOperation) Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 6] Internet-Draft Password Policy 20 October 1999 ( pwdInfObject.1.5 NAME 'pwdAccountUnlockTime' DESC'the time that the user can bind again after an account lockout. A 0 value means that an administrator must unlock the account. The absence of this attribute means that the account has not been locked' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE USAGE directoryOperation) ( pwdInfObject.1.6 NAME 'pwdHistory' DESC 'the history of user's passwords' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 EQUALITY octetStringMatch USAGE directoryOperation) Values of this attribute are transmitted in string format as given by the following BNF: pwdHistory = time "{" hashMethod "}" data time = hashMethod = data = , controlValue: A BER encoding of the following ASN.1: pwdExpirationTimeInSecs ::= Integer criticality: false If the account's password is expired, and there are remaining grace logins, the server should send bindResponse with the resultCode: LDAP_SUCCESS, and should include the remaining grace logins control in the controls field of the bindResponse message: controlType: , controlValue: A BER encoding of the following ASN.1: graceLoginsLeft ::= Integer criticality: false 6. Password Minimum Age This policy defines the number of seconds that must pass before a user can change the password again. This policy can be used in conjunction with the password history policy to prevent users from quickly cycling through passwords in history so that they can reuse the old password. A value of zero indicates that the user can change the password immediately. During modify password operation, the server should check if the user is allowed to change password at this time. If not, the server should send the LDAP_CONSTRAINT_VIOLATION result code back to the client and an error message to indicate that the password cannot be changed before the password minimum age. 7. Password History The pwdInHistory attributes control how many passwords the directory server stores in history. A value of zero indicates no history of password is maintained and in that case a user can Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 8] Internet-Draft Password Policy 20 October 1999 reuse the same password. During modify password operation, the server should check for password history. If the new password matches one of the old passwords in history, the server should send modifyResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the new password is in history and choose another password. 8. Password Syntax and Minimum length The pwdCheckSyntax attribute indicates whether the password syntax will be checked before a new password is saved. If this policy is on, the directory server should check that the new password meets the password minimum length requirement and that the string does not contain any trivial words such as the user's name, user id and so on. The mechanisms used to determine syntax are implementation dependent and not described in this document. The pwdMinLength attribute defines the minimum number of characters that must be used in a password. During modify or add password operation, the server should check for password syntax. If password check syntax is on and the new password fails the syntax check, the server should send modifyResponse or addResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the new password failed the syntax check and the user should choose another password. If the client is sending an encrypted password as the new password then it becomes the client responsibility to make sure that the password meets the minimum length and other constraints. 9. User Defined Passwords This policy defines whether the users can change their own passwords. During modify password operation, the server should check if the user is allowed to change password. If not, the server should send to the client the LDAP_UNWILLING_TO_PERFORM result code and an error message to indicate that the user is not allowed to change the password. Note that the userPassword attribute may be protected via ACLs also and the user must have necessary privilege to modify the userPassword attribute values. 10. Password Change After Reset This policy forces the user to select a new password on first bind or after password reset. After a bind operation succeeds with authentication, the server should check if the password change after reset policy is on. If so, and this is the first login, the server should send bindResponse with the resultCode: LDAP_SUCCESS, and should include the password expired control in the controls field of the bindResponse message: Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 9] Internet-Draft Password Policy 20 October 1999 controlType: , criticality: false After that, for any operation issued by the user other than modify password, bind, unbind, or abandon the server should send the response message with the resultCode: LDAP_UNWILLING_TO_PERFORM, and should include the password expired control in the controls field of the response message: controlType: , criticality: false 11. Password Guessing limit This policy enforces the limit of number of tries the client has to get the password right. The user will be locked out of the directory after a given number of consecutive failed bind attempts to the directory. This policy protects the directory from automated guessing attacks. The server keeps a failure counter in the pwdRetryCount attribute in each entry. The server should increment the failure counter when a bind operation fails with the LDAP_INVALID_CREDENTIALS error code. The server should clear the failure counter when a bind operation succeeds with authentication, the account password is reset by administrator, or when the failure counter reset time is reached. During the bind operation, the server should check for password guessing limit. If password guessing limit policy is on and the password guessing limit is reached, the server should send bindResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the password failure limit is reached. 12. Server Implementation 12.1 Password policy initialization The pwdPolicy object class holds the password policy settings for a set of user accounts. During the server initial startup, password policy should be assigned a set of initial values. Only the directory administrators should modify the settings. The server should preserve the settings over server restart. An example of a password policy is shown below. - User may change password - Do not need to change password first time logon - Use SHA as the password hash algorithm - No password syntax check - Password minimum length: 6 - Password expires in 100 days - No password minimum age - Send warning one day before password expires - Six passwords in history Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 10] Internet-Draft Password Policy 20 October 1999 - No account lockout - Lock account for 60 minutes - Reset retry count after 10 minutes - Allow 1 grace login - Force users to pass old password when modifying password In ldif format: pwdChange: TRUE pwdMustChange: FALSE pwdStorageScheme: SHA pwdCheckSyntax: FALSE pwdMinLength: 6 pwdMaxAge: 8640000 pwdMinAge: 0 pwdWarning: 86400 pwdInHistory: 6 pwdLockout: FALSE pwdMaxFailure: 3 pwdLockoutDuration: 3600 pwdResetFailureCount: 600 pwdGraceLoginLimit: 1 pwdSafeModify: TRUE 12.2 Bind Operations 12.2.1 During bind operations The server should check if the user account is locked or, if the password guessing limit policy is on and the guessing limit is reached. If so, the server should send bindResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the password failure limit is reached. Otherwise the server should continue the bind operation. 12.2.2 After Bind Operation succeeds with authentication The server should 1. Clear the password failure counter. 2. Check if the password change after reset policy is on and this is the first login. If so, the server should disallow all operations issued by this user except modify password, bind, unbind, and abandon. The server should send a bindResponse with the resultCode: LDAP_SUCCESS, and should include the password expired control in the controls field of the bindResponse message. controlType: , criticality: false 3. Check for password expiration. If the account's password has expired, the server should check the remaining grace logins. Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 11] Internet-Draft Password Policy 20 October 1999 3.1. If there are remaining grace logins, the server should decrement the number of grace logins and send a bindResponse with the resultCode: LDAP_SUCCESS, and should include the remaining grace logins control in the controls field of the bindResponse message: controlType: , controlValue: A BER encoding of the following ASN.1 graceLoginsLeft ::= Integer criticality: false 3.2. If there are no remaining grace logins, the server should send bindResponse with the resultCode LDAP_INVALID_CREDENTIALS long with an error message to inform the client that the password has expired. 4. Check if the password is going to expire sooner than the password warning duration, the server should send bindResponse with the resultCode: LDAP_SUCCESS, and should include the password expiring control in the controls field of the bindResponse message: controlType: , controlValue: A BER encoding of the following ASN.1 pwdExpirationTimeInSecs ::= Integer criticality: false 12.2.3 After bind operations fails with LDAP_INVALID_CREDENTIALS The server should 1. Check if it is time to reset the password failure counter. If so, set the failure counter to 1 and re-calculate the next failure counter reset time. Otherwise, increment the failure counter. 2. Check if failure counter exceeds the allowed maximum value. If so, the server should lock the user account. 12.3. Add Password Operation A password is added using the ldapModify request, either while creating a new entry or while modifying an existing entry that has no password. 12.3.1. During the add password operation The server should 1. Check for password syntax. If password check syntax is on and the new password fails the syntax check, the server should Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 12] Internet-Draft Password Policy 20 October 1999 send addResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the new password failed the syntax check, the user should choose another password. 2. Evaluate the hash of the password value. If the password is cleartext, check the pwdStorageScheme attribute. If the passwordStorageScheme is other than "CLEARTEXT", hash the password with the appropriate mechanism prior to storing. 3. Calculate and add pwdExpirationTime and pwdAllowChangeTime attribute to the entry if password expiration policy (pwdMaxAge) and password minimum age (pwdMinAge) policies are on respectively. 12.4. Modify Password Operations Passwords are changed using the ldapModify operation to modify the value of the userPassword attribute. If the pwdSafeModify password policy attribute is set, the server must require that the ldapModify request consists of both a delete action which specifies the existing password, as well as an add action which specifies the new password. 12.4.1. During the modify password operation The server should 1. Check if the user is allowed to change password. If not, the server should send to the client the LDAP_UNWILLING_TO_PERFORM result code and an error message to indicate that the user is not allowed to change the password. 2. Check the pwdSafeModify attribute. If set, make sure that the modify operation contains a delete action and that the delete action specifies the existing password. 3. Check for password minimum age, password minimum length, password history, and password syntax. If the checking fails, the server should send modifyResponse back to the client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an appropriate error message. 4. Evaluate the hash of the password value. If the password is cleartext, check the pwdStorageScheme attribute. If the pwdStorageScheme is other than "CLEARTEXT", hash the password with the appropriate mechanism prior to storing. 5. If this is the first login and if there are any modification being made other than userPassword, the server should send the response message with the resultCode: Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 13] Internet-Draft Password Policy 20 October 1999 LDAP_UNWILLING_TO_PERFORM, and should include the password expired control in the controls field of the response message controlType: , criticality: false 12.4.2. After the password modify operation succeeds The server should 1. Update password history in the user's entry, if the pwdInHistory is a positive value. 2. Update pwdExpirationTime in the user's entry, if the pwdMaxAge is a positive value. 3. Update pwdAllowChangeTime in the user's entry, if the pwdMinAge is on. 4. Reset the pwdGraceLeft attribute to the value held by the pwdGraceLoginLimit attribute in the pwdPolicy object in effect for this entry. 5. Remove the pwdRetryCount and pwdRetryCountResetTime attributes from the user's entry if they exist. 12.5 Compare Operation The compare operation may be used to compare a userPassword. This might be performed when a client wishes to verify that user's supplied password is correct. An example of this is an LDAP PAM redirector or an LDAP HTTP authentication redirector. It is desirable to use this rather than performing a bind operation in order to reduce possible overhead involved in performing a bind. ACLs may be used to restrict this comparison from being made. If a server supports this behavior, it MUST comply with the following. Otherwise the password policy described in this document may be circumvented. 12.5.1 During a compare operation on the userPassword attribute The server should 1. Check the pwdAccountUnlockTime attribute. If it exists, return LDAP_UNWILLING_TO_PERFORM to indicate that the account is locked. 2. If ACLs permit, compare the password. 3. If the password compares true, the server should clear the failure counter. If it compares false, it should check to see Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 14] Internet-Draft Password Policy 20 October 1999 if it's time to reset the failure counter, if so, set the failure counter to 1, otherwise increment the failure counter. If the failure counter exceeds the allowed maximum value, the server MUST lock the user account. 13. Client Implementation 13.1. Bind Response For every bind response received, the client needs to parse the bind result code, error message, and controls to determine if any of the following conditions are true and prompt the user accordingly. 1. The user needs to change password first time logon. The user should be prompted to change the password immediately. resultCode: LDAP_SUCCESS, with the control controlType: , criticality: false 2. This is a warning message that the server sends to a user to indicate the time in seconds before the user's password expires. resultCode: LDAP_SUCCESS, with the control controlType: , controlValue: A BER encoding of the following ASN.1 pwdExpirationTimeInSecs ::= Integer criticality: false 3. The password failure limit has been reached. The user needs to retry later or contact the directory administrator to reset the password. resultCode: LDAP_CONSTRAINT_VIOLATION, with an appropriate error message. For example: errorMessage: "exceed password retry limit" 4. The password has expired but there are remaining grace logins. The user needs to change it. resultCode: LDAP_SUCCESS, with the control controlType: controlValue: A BER encoding of the following ASN.1 graceLoginsLeft ::= Integer criticality: false 5. The password has expired and there are no more grace logins. The user needs to contact the directory administrator to reset the password. Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 15] Internet-Draft Password Policy 20 October 1999 resultCode: LDAP_INVALID_CREDENTIALS, with an appropriate error message. For example: errorMessage: "password expired" 13.2 Modify Responses For the modify response received for the change password request, the client needs to check the result code and error message to determine if it failed the password checking, and either let the user retry or quit. 1. The user defined password policy is disabled. Either the user is not allowed to change passwords, or the user must specify the old password when changing passwords. resultCode: LDAP_UNWILLING_TO_PERFORM, with an appropriate error message. For example: errorMessage: "user not allowed to change password" 2. The new password failed the password syntax checking, or the current password has not reached the minimum password age, or the new password is in history. resultCode: LDAP_CONSTRAINT_VIOLATION, with an appropriate error message. For example: errorMessage: "invalid password syntax" errorMessage: "password in history" errorMessage: "trivial password" errorMessage: "within minimum password age" 3. User must supply the old password if the pwdSafeModify is on. The user must specify the old password when changing passwords. resultCode: LDAP_UNWILLING_TO_PERFORM, with an appropriate error message. For example: errorMessage: "must specify old password" 13.3 Add Responses For the add response received for the add entry request, the client needs to check the result code and error message to determine if it failed the password checking, and either let the user retry or quit. 1. The new password failed the password syntax checking. resultCode: LDAP CONSTRAINT_VIOLATION, with an appropriate error message. For example: errorMessage: "invalid password syntax" errorMessage: "trivial password" Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 16] Internet-Draft Password Policy 20 October 1999 13.4 Other Responses For operations other than bind, unbind, abandon, or search, the client needs to check the following result code and control to determine if the user needs to change the password immediately. 1. The user needs to change password. The user should be prompted to change the password immediately. resultCode: LDAP_UNWILLING_TO_PERFORM, with the control controlType: criticality: false 14. Association between Users and Password Policy We have so far described two new objectclasses; one contains the password policy and the other contains password-related information in a userÆs entry. We need an association between the password policy and users. Association via DIT or groups or any other method can be used. To make this policy work in a heterogeneous environment we need to describe a mechanism for the association. This work is still under investigation. 15. Password Policy and Replication The pwdPolicyObject defines the password policy for a set of users of the directory and must be replicated on all the replicas. The pwdInfObject class holds information related to password policy in the userÆs entry. Some of the attributes have to be replicated on all servers, for the consistency of passwords and the policy. This is the case for pwdHistory, pwdExpirationTime, pwdAllowChangeTime which changes along with the userPassword. The other attributes may change each time the user binds to a server. It is up to the administrator to decide to replicate them or not. If they are replicated, it means that the retry counter, the grace login counter and the account locking are applied on the whole set of servers, but that the replication updates will be very important and may lead to conflicts in a multi-master environment. If theyÆre not replicated, it means that the limits apply on each server and therefore, a user can try to bind N times on each server. As long as the number of retries and the number of server are low, this can be an acceptable policy. 16. Security Considerations Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 17] Internet-Draft Password Policy 20 October 1999 The password policy defined in this document is applied to the LDAP simple authentication method [RFC-2251] and the password based SASL mechanisms such as CRAM-MD5 [RFC-2195] and HTTP-Digest [RFC-2222]. 17. Bibliography [RFC-2251]Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, August 1997. [RFC-2252]Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC-2307]L. Howard, "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998. [RFC-2119]S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 18. Authors' Addresses Prasanta Behera Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA +1 650 937-4948 prasanta@netscape.com Valerie Chu Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043 USA +1 650 937-3443 vchu@netscape.com Ludovic Poitou Sun Microsystems Inc. 32 Chemin du vieux chŠne 38240 Meylan France +33 476 414 212 ludovic.poitou@france.sun.com Jim Sermersheim Novell, Inc. 122 East 1700 South Provo, Utah 84606, USA +1 801 861-3088 jimse@novell.com Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 18]