[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: please publish ldap password policy draft
Initial comments...
This draft proposes changes the behavior of userPassword attribute
which are incompatible with the RFC2256 defined schema rules:
5.36. userPassword
( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
Passwords are stored using an Octet String syntax and are not
encrypted.
a) compare must use octetStringMatch
b) servers cannot encrypt (or hash) the password and store
it in userPassword.
The draft relies on LDAPv3 mechanisms (controls). The
draft, however, does not state that any protocol restrictions
exist. If LDAPv2 is to be supported, the document should state
how a server should respond with the client attempts to bind
or is bound using LDAPv2.
The draft uses results not allowed by RFC2251. In particular,
constraintViolation is not allowed in a bindResponse.
Editing issues:
The draft should not be written in terms of the LDAP C API draft.
Please use names defined by RFC2251 instead of LDAP C API defines.
ie: use constraintViolation not LDAP_CONSTRAINT_VIOLATION
At 02:16 PM 10/19/99 -0700, Prasanta Behera wrote:
> 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
>
> ( <pwdSchema>
> 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:
>
> ( <pwdInfoObj OID>
> 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 = <generalizedTimeString as specified in 6.14 of [RFC2252]>
> hashMethod = <encryptionMethodString as described by the
> pwdDefaultStorageScheme attribute in this document>
> data = <String of characters representing the password in the
> format specified in hashMethod.
>
> ( pwdInfObject.1.7
> NAME 'pwdAllowChangeTime'
> DESC'the time after which the user is allowed change the
> password. This prevents a user from quickly recycling
> passwords.'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
> EQUALITY generalizedTimeMatch
> ORDERING generalizedTimeOrderingMatch SINGLE-VALUE
> USAGE directoryOperation)
>
> ( pwdInfObject.1.8
> NAME 'pwdGraceLeft'
> DESC 'the remaining number of grace logins left'
> EQUALITY integerMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
> SINGLE-VALUE
> USAGE directoryOperation)
>
> 5. Password Expiration and Expiration Warning
>
> The attributes pwdMaxAge and pwdExpireWarning are defined to
> specify when the password expires and when a warning message will
> be sent to the client respectively. The actual expiration time
>
>
> Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 7]
>
> Internet-Draft Password Policy 20 October 1999
>
> for a password will be stored in the pwdExpirationTime attribute
> of the user entry.
>
> After a bind operation succeeds with authentication and before
> any response is sent to the client, the server should check for a
> non-0 value in the pwdExpireWarning attribute. If warnings are to
> be issued, the server should check for password expiration time.
> If the account's password has expired, and there are no more
> remaining grace logins, the server should send a bindResponse
> with the resultCode LDAP_INVALID_CREDENTIALS along with an error
> message to inform the client that the password has expired. If
> the password is going to expire sooner than the password warning
> duration, the server should send a bindResponse with the
> resultCode: LDAP_SUCCESS, and should include the password
> expiring control in the controls field of the bindResponse
> message:
>
> controlType: <pwdControlType.1>,
> 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: <pwdControlType.2>,
> 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: <pwdControlType.3>,
> 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: <pwdControlType.3>,
> 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: <pwdControlType.3>,
> 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: <pwdControlType.2>,
> 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: <pwdControlType.1>,
> 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: <pwdControlType.3>,
> 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: <pwdControlType.3>,
> 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: <pwdControlTYpe.1>,
> 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: <pwdControlType.2>
> 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: <pwdControlType.3>
> 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]
>Attachment Converted: "c:\home\kurt\data files\eudora\attach\smime1.p7s"
>
----
Kurt D. Zeilenga <Kurt@OpenLDAP.org>
OpenLDAP Project <http://www.OpenLDAP.org/>