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
<draft-behera-ldap-password-policy-00.txt>
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
( <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 chne
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]