One document matched: draft-behera-ldap-password-policy-02.txt
Differences from draft-behera-ldap-password-policy-01.txt
Internet Draft P.Behera
draft-behera-ldap-password-policy-02.txt V. Chu
Intended Category: Proposed Standard Netscape
Expires: January 2001 L. Poitou
Sun Microsystems
J. Sermersheim
Novell
July 2000
Password Policy for LDAP Directories
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.
Copyright 2000, The Internet Society. All rights Reserved.
Please see the Copyright section near the end of this document for
more information.
1. 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 failed attempts.
2. Overview
LDAP-based directory services are currently accepted by many
organizations as the access protocol for directories. The ability to
Behera, et. al. Proposed Standard Page 1
Password Policy for LDAP Directories July 2000
ensure the secure read and update access to directory information
throughout the network is essential to the successful deployment.
Most LDAP implementations support many authentication schemes - the
most basic and widely used is the simple authentication i.e., user
DN and password. In this case, many LDAP servers have implemented
some kind of policy related to the password used to authenticate.
Among other things, this policy includes:
- Whether and when passwords expire.
- Whether failed bind attempts cause the account to be locked.
- If and how users are able to change their passwords.
In order to achieve greater security protection and ensure
interoperability in a heterogeneous environment, LDAP needs to
standardize on a common password policy model. This is critical to
the successful deployment of LDAP directories.
2.1 Application of password policy
The password policy defined in this document can be applied to any
attribute holding users' passwords which are used for authentication
by the use of the bind operation.
Typically, it is applied to the userPassword attribute in the case
of the LDAP simple authentication method [RFC-2251] or the case of
password based SASL [RFC-2222] authentication such as CRAM-MD5 [RFC-
2195] and HTTP-Digest [RFC-Digest].
The password policy also defines some constraints to be checked
during add or modify operations on these attributes.
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. In other words, the password for a directory
administrator never expires, the account is never locked, etc.
3. Articles of password policy
The following sections explain in general terms each aspect of the
password policy defined in this document as well as the need for
each. These policies are subdivided into the general groups of
password usage and password modification. Implementation details are
presented in sections 6 and 7.
3.1. Password Usage Policy
This section describes policy enforced while users are using
passwords to authenticate. The general focus of this policy is to
minimize the threat of intruders once a password is in use.
3.1.1. Password Guessing limit
Behera, et. al. Proposed Standard Page 2
Password Policy for LDAP Directories July 2000
In order to prevent intruders from guessing a user's password, a
mechanism exists to track the number of failed authentication
attempts, and take action when a limit is reached.
This policy consists of five parts:
- A configurable limit.
- A counter to track the number of failed authentication attempts.
- A timeframe in which the limit of consecutive failed
authentication attempts must happen before action is taken.
- The action to be taken when the limit is reached. The action will
either be nothing, or the account will be locked.
- An amount of time the account is locked (if it is to be locked).
This can be indefinite.
3.2. Password Modification Policy
This section describes policy enforced while users are modifying
passwords. The general focus of this policy is to ensure that when
users add or change their passwords, the security and effectiveness
of their passwords is maximized.
3.2.1. Password Expiration, Expiration Warning, and Grace binds
One of the key properties of a password is the fact that it is not
well known. If a password is frequently changed, the chances of that
user's account being broken into are minimized.
Directory administrators may deploy a password policy which causes
passwords to expire after a given amount of time - thus forcing
users to change their passwords periodically.
As a side effect, there needs to be a way in which users are made
aware of this need to change their password before actually being
locked out of their accounts. One or both of the following methods
handle this:
- The user is sent a warning sometime before his password is due to
expire. If the user fails to heed this warning before the
expiration time, his account will be locked.
- The user may bind to the directory a preset number of times after
her password has expired. If she fails to change her password
during one of her 'grace' binds, her account will be locked.
3.2.2. Password History
When the Password Expiration policy is used, an additional mechanism
may be employed in order to prevent users from simply re-using a
Behera, et. al. Proposed Standard Page 3
Password Policy for LDAP Directories July 2000
previous password (as this would effectively circumvent the
expiration policy).
In order to do this; a history of used passwords is kept. The
directory administrator sets the number of passwords to be stored at
any given time. Passwords are stored in this history whenever the
password is changed. Users aren't allowed to specify any passwords
that are in the history list while changing passwords.
3.2.3. Password Minimum Age
Users may circumvent the Password History mechanism by quickly
performing a series of password changes. If they change their
password enough times, their 'favorite' password will be pushed out
of the history list.
This process may be made less attractive to users by employing a
minimum age for passwords. If users are forced to wait 24 hours
between password changes, they may be less likely to cycle through a
history of 10 passwords.
3.2.4. Password Syntax and Minimum length
In order to prevent users from creating or updating passwords that
are easy to guess, a password syntax policy may be employed. This
policy consists of two general mechanisms - ensuring that passwords
conform to a defined syntax and ensuring that they are of a minimum
length.
Forcing a password to comply with a syntax may imply a variety of
things including:
- Disallowing trivial or well-known words make up the password.
- Forcing a certain number of digits be used.
- Disallowing anagrams of the user's name.
The implementation of this policy meets with the following problems:
- If the password to be added or updated is encrypted by the client
before being sent, the server has no way of enforcing this
policy. Therefore, the onus of enforcing this policy falls upon
client implementations.
- There are no specific definitions of what 'syntax checking'
means. This can lead to unexpected behavior in a heterogeneous
environment.
3.2.5. User Defined Passwords
Behera, et. al. Proposed Standard Page 4
Password Policy for LDAP Directories July 2000
In some cases, it is desirable to disallow users from adding and
updating their own passwords. This policy makes this functionality
possible.
This implies that certain other policy, such as password expiration
is not enforced.
3.2.6. Password Change After Reset
This policy forces the user to update her password after it has been
set for the first time, or has been reset by the directory
administrator.
This is needed in scenarios where a directory administrator set or
reset the password to a well-known value.
3.2.7 Safe modification
As directories become more commonly used, it will not be unusual for
clients to connect to a directory and leave the connection open for
an extended period. This opens up the possibility for an intruder to
make modifications to a user's password while that user's computer
is connected but unattended.
This policy forces the user to prove his identity by specifying the
old password before modifying it.
3.3 Restriction of the Password Policy
The password policy has defined in this document can apply to any
attribute containing a password. Because the state information in
the user's entry is on a per attribute basis and not per password
attribute value, the server should enforce that the password
attribute subject to the password, contains one and only one
password value.
4. Schema used for Password Policy
The schema elements defined here fall into two general categories. A
password policy object class is defined which contains a set of
administrative password policy attributes, and a set of operational
attributes are defined which hold general password policy state
information for each user.
4.1. The pwdPolicy Object Class
This object class holds password policy in effect for a set of
users. See section 9 for a discussion of how entries of this object
class are associated with users.
( pwdSchema.3.1
NAME 'pwdPolicy'
Behera, et. al. Proposed Standard Page 5
Password Policy for LDAP Directories July 2000
AUXILIARY
SUP top
MUST ( pwdAttribute )
MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckSyntax $
pwdMinLength $ pwdDefaultStorageScheme $ pwdExpireWarning $
pwdGraceLoginLimit $ pwdLockout $ pwdLockoutDuration $
pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $
pwdAllowUserChange $ pwdSafeModify ) )
4.2. Attribute Types used in the pwdPolicy ObjectClass
Following are the attribute types used by the pwdPolicy object
class.
4.2.1 pwdAttribute
This holds the name of the attribute to which the password policy is
applied. For example, the password policy may be applied to the
userPassword attribute.
( pwdSchema.1.1
NAME 'pwdAttribute'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
4.2.2 pwdMinAge
This attribute holds the number of seconds that must elapse between
modifications to the password. If this attribute is not present, 0
seconds is assumed.
( pwdSchema.1.2
NAME 'pwdMinAge'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.3 pwdMaxAge
This attribute holds the number of seconds after which a modified
password will expire.
If this attribute is not present, or if the value is 0 the password
does not expire.
( pwdSchema.1.3
NAME 'pwdMaxAge'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.4 pwdInHistory
Behera, et. al. Proposed Standard Page 6
Password Policy for LDAP Directories July 2000
This attribute specifies the maximum number of used passwords stored
in the pwdHistory attribute.
If this attribute is not present, or if the value is 0, used
passwords are not stored in the pwdHistory attribute and thus may be
reused.
( pwdSchema.1.4
NAME 'pwdInHistory'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.5 pwdCheckSyntax
This attribute indicates how the password syntax will be checked
while being modified. If this attribute is not present, or if the
value is '0', syntax checking will not be enforced. A value of '1'
indicates that the syntax will be checked if the password is not
hashed, otherwise it must be accepted. A value of '2' indicates that
the syntax will be checked if the password is not hashed, otherwise
the server must returned an error refusing the password.
( pwdSchema.1.5
NAME 'pwdCheckSyntax'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.6 pwdMinLength
This attribute holds the minimum number of characters that must be
used in a password, if syntax checking is enabled. If this attribute
is not present, no minimum password length will be enforced. If the
password is hashed, the server will, depending on the value of the
pwdCheckSyntax attribute, either accept the password without
checking it ('0' or '1') or refuse it ('2').
( pwdSchema.1.6
NAME 'pwdMinLength'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.7 pwdDefaultStorageScheme
This attribute specifies the type of hash algorithm used to store
directory server passwords. This is used when a password
modification is made and the supplied password has not been
encrypted. If this attribute is not present, or if the value is
"CLEARTEXT", the password will not be changed before it is stored.
Behera, et. al. Proposed Standard Page 7
Password Policy for LDAP Directories July 2000
The description of password storage scheme can be found in [RFC-
2307]. One additional storage scheme not mentioned there is
"CLEARTEXT".
( pwdSchema.1.7
NAME 'pwdDefaultStorageScheme'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
4.2.8 pwdExpireWarning
This attribute specifies the maximum number of seconds before a
password is due to expire that expiration warning messages will be
returned to an authenticating user. If this attribute is not
present, or if the value is 0 no warnings will be sent.
( pwdSchema.1.8
NAME 'pwdExpireWarning'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.9 pwdGraceLoginLimit
This attribute specifies the number of times an expired password can
be used to access an account. If this attribute is not present or if
the value is 0, the account cannot be accessed once the password has
expired.
( pwdSchema.1.9
NAME 'pwdGraceLoginLimit'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.10 pwdLockout
This attribute indicates, when its value is "TRUE", that users will
be locked out of the directory after a specified number of
consecutive failed bind attempts. The maximum number of consecutive
failed bind attempts is specified in pwdMaxFailure.
If this attribute is not present, or if the value is "FALSE", the
account will not be locked when the number of failed bind attempts
has been reached.
( pwdSchema.1.10
NAME 'pwdLockout'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
Behera, et. al. Proposed Standard Page 8
Password Policy for LDAP Directories July 2000
4.2.11 pwdLockoutDuration
This attribute holds the number of seconds that an account will
remain locked due to too many failed bind attempts. If this
attribute is not present, or if the value is 0 the account will be
locked until reset by an administrator.
( pwdSchema.1.11
NAME 'pwdLockoutDuration'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.12 pwdMaxFailure
This attribute specifies the number of consecutive failed bind
attempts after which a users account will be locked. If this
attribute is not present, or if the value is 0, the account will not
be locked due to failed bind attempts and the value of pwdLockout
will be ignored.
( pwdSchema.1.12
NAME 'pwdMaxFailure'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.13 pwdFailureCountInterval
This attribute holds the number of seconds after which the password
failures are purged from the failure counter.
If this attribute is not present, or if its value is 0, the failure
counter will never be purged.
( pwdSchema.1.13
NAME 'pwdFailureCountInterval'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.14 pwdMustChange
This attribute specifies with a value of "TRUE" that users must
change their passwords when they first bind to the directory after a
password is set or reset by the administrator. If this attribute is
not present, or if the value is "FALSE", users are not required to
change their password upon binding after the administrator sets or
resets the password.
( pwdSchema.1.14
NAME 'pwdMustChange'
EQUALITY booleanMatch
Behera, et. al. Proposed Standard Page 9
Password Policy for LDAP Directories July 2000
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
4.2.15 pwdAllowUserChange
This attribute indicates whether users can change their own
passwords. If this attribute is not present, a value of "TRUE" is
assumed.
( pwdSchema.1.15
NAME 'pwdAllowUserChange'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
4.2.16 pwdSafeModify
This attribute specifies whether or not the existing password must
be sent when changing a password. If this attribute is not present,
a "FALSE" value is assumed.
( pwdSchema.1.16
NAME 'pwdSafeModify'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
4.3. Attribute Types for Password Policy State Information
Password policy state information must be maintained for each user.
The information is located in each user entry as a set of
operational attributes. These operational attributes are:
pwdChangedTime, pwdAccountLockedTime, pwdExpirationWarned,
pwdFailureTime, pwdHistory, pwdGraceUseTime, pwdReset.
Since the password policy could apply to several attributes used to
store passwords, each of the above operational attributes must have
an option to tell which attribute is applies to.
The password policy option is defined as the following:
pwd-<passwordAttribute>
For example, if the pwdPolicy object has for pwdAttribute
"userPassword" then the pwdChangedTime operational attribute, in a
user entry, will be like this:
pwdChangedTime;pwd-userPassword: 20000103121520Z
4.3.1 pwdChangedTime
This attribute specifies the time the entry's password was last
changed. This is used by the password expiration policy. If this
attribute does not exist, the password will never expire.
( pwdSchema.2.1
Behera, et. al. Proposed Standard Page 10
Password Policy for LDAP Directories July 2000
NAME 'pwdChangedTime'
DESC 'The time the password was last changed'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SINGLE-VALUE
USAGE directoryOperation)
4.3.2 pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
0 value means that the account has been locked permanently, and that
only an administrator can unlock the account.
( pwdSchema.2.2
NAME 'pwdAccountLockedTime'
DESC 'The time an user account was locked'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SINGLE-VALUE
USAGE directoryOperation)
4.3.3 pwdExpirationWarned
This attribute contains the time when the password expiration
warning was first sent to the client. The password must expire in
the pwdExpireWarning time.
( pwdSchema.2.3
NAME 'pwdExpirationWarned'
DESC 'The time the user was first warned about the coming
expiration of the password'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SINGLE-VALUE
USAGE directoryOperation )
4.3.4 pwdFailureTime
This attribute holds the time stamps of the consecutive
authentication failures.
( pwdSchema.2.4
NAME 'pwdFailureTime'
DESC 'The timestamps of the last consecutive authentication
failures'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
USAGE directoryOperation )
Behera, et. al. Proposed Standard Page 11
Password Policy for LDAP Directories July 2000
4.3.5 pwdHistory
This attribute holds a history of previously used passwords.
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.
( Schema.2.5
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)
4.3.6 pwdGraceUseTime
This attribute holds the timestamps of grace login once a password
has expired.
( pwdSchema.2.6
NAME 'pwdGraceUseTime'
DESC 'The timestamps of the grace login once the password has
expired'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
EQUALITY generalizedTimeMatch
SINGLE-VALUE
USAGE directoryOperation)
4.3.7 pwdReset
This attribute holds a flag to indicate if the password has been
reset and therefore must be changed by the user on first
authentication.
( pwdSchema.2.7
NAME 'pwdReset'
DESC 'The indication that the password has been reset'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
USAGE directoryOperation)
5. Control used for Password Policy
Behera, et. al. Proposed Standard Page 12
Password Policy for LDAP Directories July 2000
This section details the control used while enforcing password
policy. This control contains various warnings and errors associated
with password policy
The server typically sends this control with the following
operations: bindResponse, modifyResponse, addResponse,
compareResponse and possibly extendedResponse, to inform of various
conditions and MAY be sent with other operations (in the case of the
changeAfterReset error).
passwordPolicyControl
controlType: <pwdControlType>
criticality: FALSE
controlValue:an OCTET STRING, whose value is the BER encoding of the
following type:
PasswordPolicyControlValue ::= SEQUENCE {
warning [0] CHOICE OPTIONAL {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceLoginsRemaining [1] INTEGER (0 .. maxInt) }
error [1] ENUMERATED OPTIONAL {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
invalidPasswordSyntax (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) }
The timeBeforeExpiration warning specifies the number of seconds
before a password will expire. The graceLoginsRemaining warning
specifies the remaining number of time a user will be allowed to
authenticate with an expired password. The passwordExpired error
signifies that the password has expired and must be reset. The
changeAfterReset error signifies that the password must be changed
before the user will be allowed to perform any operation other than
bind and modify. The passwordModNotAllowed is set when a user is
restricted from changing her password. The invalidPasswordSyntax
error is set when a password doesn't pass syntax checking. The
passwordTooYoung is set if the age of the password to be modified is
not yet old enough.
Typically, only either a warning or an error will be encoded though
there may be exceptions. For example, if the user is required to
change a password after the administrator set it, and the password
will expire in a short amount of time, the control may include the
timeBeforeExpiration warning and the changeAfterReset error.
6. Server Implementation by LDAP operation
Behera, et. al. Proposed Standard Page 13
Password Policy for LDAP Directories July 2000
The following sections contain detailed instructions that refer to
attributes of the pwdPolicy object class. When doing so, the
attribute of the pwdPolicy object that governs the entry being
discussed is implied.
The server should enforce that the password attribute subject to a
password policy as defined in this document, contains one and only
one password value.
6.1 Bind Operation
When processing a bind request, the server performs the following
steps:
1. Checks for a locked account:
If the value of the pwdAccountLockedTime attribute is 0, or if
the current time is less than the value of the
pwdAccountLockedTime attribute added to the value of the
pwdLockoutDuration, the account is locked. If the account is
locked, the server sends a bindResponse to the client with the
resultCode: unwillingToPerform (53), and includes the
passwordPolicyControl in the controls field of the bindResponse
message with the error: accountLocked (1).
2. If the account is not locked, the server proceeds with the bind
operation and checks the result:
If the bind operation succeeds with authentication, The server
does the following:
A. Deletes the pwdFailureTime attribute.
B. Checks whether the password must be changed now.
If the pwdMustChange attribute is set to TRUE, and if the
pwdReset attribute is set to TRUE, the server sends a
bindResponse to the client with the resultCode: success (0),
and includes the passwordPolicyControl in the controls field
of the bindResponse message with the warning:
changeAfterReset specified.
The server then disallows all operations issued by this user
except modify password, bind, unbind, and abandon.
C. Checks for password expiration
If the value of the pwdExpireWarning attribute is 0, the
server subtracts the current time from the time stored in
pwdChangedTime to arrive at the password's age. If the age is
greater than the value in the pwdMaxAge attribute, the
password has expired.
If the value of the pwdExpireWarning attribute is non-0, and
the pwdExpirationWarned attribute is present and has a
Behera, et. al. Proposed Standard Page 14
Password Policy for LDAP Directories July 2000
positive value, the server subtracts the current time from
the time stored in the pwdExpirationWarned to arrive at the
first warning age. If the age is greater than the value in
the pwdExpireWarning attribute, the password has expired.
In the case of an expired password, the server checks for
remaining grace logins
- The server checks the pwdGraceUseTime attribute. If
present, it counts the number of values and subtracts it
to the pwdGraceLoginLimit. A positive result means there
are that many remaining grace logins.
- If there are remaining grace logins, the server adds a new
value with the current time in pwdGraceUseTime. Then it
sends a bindResponse with the resultCode: success (0), and
includes the passwordPolicyControl in the controls field
of the bindResponse message with the warning:
graceLoginsRemaining choice set to the number of grace
logins left.
- If there are no remaining grace logins, the server sends a
bindResponse with the resultCode: invalidCredentials (49),
and includes the passwordPolicyControl in the controls
field of the bindResponse message with the error:
passwordExpired (0) set.
D. Calculates whether the time before expiration warning should
be sent. If the pwdExpirationWarned attribute is present and
has a positive value, the warning is sent with a
timeBeforeExpiration set to the value of the
pwdExpirationWarned attribute plus the value of the
pwdExpireWarning attribute minus the current time.
Otherwise, the server subtracts the current time from the time
stored in pwdChangedTime to arrive at the password's age. If
the age is greater than the value of the pwdMaxAge attribute
minus the value of the pwdExpireWarning attribute, the server
sets the current time as the value of the pwdExpirationWarned
attribute, and the warning is sent with a timeBeforeExpiration
set to the value of pwdMaxAge minus the password's age.
The server sends a bindResponse with the resultCode: success
(0), and includes the passwordPolicyControl in the controls
field of the bindResponse message with the warning:
timeBeforeExiration set to the value as described above.
If the bind operation fails authentication due to invalid
credentials and the pwdLockout attribute is TRUE, the server does
the following:
A. Adds the current time as a value of the pwdFailureTime
attribute.
Behera, et. al. Proposed Standard Page 15
Password Policy for LDAP Directories July 2000
B. Counts the number of values in the pwdFailureTime attribute
that are younger than pwdFailureCountInterval. If the number
of these failures is greater or equal to the pwdMaxFailure
attribute, the server locks the account by setting the value
of the pwdAccountLockedTime attribute to the current time.
After locking the account, the server sends a bindResponse to
the client with the resultCode: unwillingToPerform (53), and
includes the passwordPolicyControl in the controls field of
the bindResponse message with the error: accountLocked (1).
C. Failures times that are old by more than
pwdFailureCountInterval, are purged from the pwdFailureTime
attribute.
6.2. Modify Operation
Because the password is stored in an attribute, the modify operation
may be used to create or update a password. Other specifications MAY
define alternate mechanisms used to modify the password.
The following instructions are to be followed when processing any
request which includes changes to the password attribute.
While processing a password modification, the server performs the
following steps:
1. Checks the pwdSafeModify attribute. If set, the server ensures
that the modify operation contains a delete action before the add
or replace action, and that the delete action specifies the
existing password. If the delete action is not specified, the
server aborts the modification and then sends a modifyResponse to
the client with the resultCode: unwillingToPerform (53), and
includes the passwordPolicyControl in the controls field of the
modifyResponse message with the error: mustSupplyOldPassword (4).
2. Checks the value of the pwdMustChange attribute. If TRUE, the
server checks the pwdReset attribute in the user's entry, to see
if the password has been reset by a Directory Administrator. If
so, it ensures that the modify operation contains no
modifications other than the modification of the password
attribute. If other modifications exist, the server sends a
modifyResponse to the client with the resultCode:
unwillingToPerform (53), and includes the passwordPolicyControl
in the controls field of the modifyResponse message with the
error: changeAfterReset (2).
3. Checks to see whether the bound identity has sufficient rights to
modify the password. If the bound identity is a user changing her
own password, this may be done by either the use of an access
control mechanism, or by checking the pwdAllowUserChange
attribute. Otherwise an access control mechanism must be used.
The determination of this is implementation specific. If the user
is not allowed to change her password, the server sends a
Behera, et. al. Proposed Standard Page 16
Password Policy for LDAP Directories July 2000
modifyResponse to the client with the resultCode:
unwillingToPerform (53), and includes the passwordPolicyControl
in the controls field of the modifyResponse message with the
error: passwordModNotAllowed (3).
4. Checks the value of the pwdMinAge attribute. If it is set to a
non-0 value, the server subtracts the current time from the value
of the pwdChangedTime attribute to arrive at the password's age.
If the password's age is less than the value of the pwdMinAge
attribute, the password is too young to modify. In this case, the
server sends a modifyResponse to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyControl
in the controls field of the modifyResponse message with the
error: passwordTooYoung (7).
5. Checks the value of the pwdCheckSyntax attribute.
If the value is non-0, The server:
A. ensures that the password meets the syntax restrictions
enforced by the server. This enforcement is implementation
specific. If the password fails this check or the password is
hashed and the value of the pwdCheckSyntax attribute is 2,
the server sends a modifyResponse to the client with the
resultCode: constraintViolation (19), and includes the
passwordPolicyControl in the controls field of the
modifyResponse message with the error: invalidPasswordSyntax
(5).
B. Checks the value of the pwdMinLength attribute. If the value
is non-0, ensures that the new password is of at least the
minimum length. If not or if the password is hashed and the
value of the pwdCheckSyntax attribute is 2, the server sends
a modifyResponse to the client with the resultCode:
constraintViolation (19), and includes the
passwordPolicyControl in the controls field of the
modifyResponse message with the error: passwordTooShort (6).
6. Checks the value of the pwdStorageScheme attribute. If the
pwdStorageScheme is other than "CLEARTEXT", the server hashes the
password with the appropriate mechanism prior to storing.
7. Checks the value of the pwdInHistory attribute. If the value is
non-0, the server checks whether this password exists in the
entry's pwdHistory attribute or in the current password
attribute. If the password does exist in the pwdHistory attribute
or in the current password attribute, the server sends a
modifyResponse to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyControl
in the controls field of the modifyResponse message with the
error: passwordInHistory (8).
Behera, et. al. Proposed Standard Page 17
Password Policy for LDAP Directories July 2000
If these steps have completed without causing an error condition,
the server follows these steps in order to update the necessary
password policy state attributes:
8. Checks the value of the pwdMaxAge attribute. If the value is non-
0, or if the value of the pwdMinAge attribute is non-0, the
server updates the pwdChangedTime attribute on the entry to the
current time.
9. If the value of the pwdInHistory attribute is non-0, the server
adds the previous password to the pwdHistory attribute. If the
number of attributes held in the pwdHistory attribute exceeds the
value of pwdInHistory, the server removes the oldest excess
passwords.
10.Removes the pwdFailureTime, pwdReset, pwdGraceUseTime and
pwdExpirationWarned attributes from the user's entry if they
exist.
The server then applies the modify operation.
6.3 Add Operation
The password MAY be set during an Add operation. If it is, the
server performs the following steps while processing the add
operation: Note that these are essentially duplicates of steps 3, 5
and 6 from section 6.2.
1. Checks to see whether the bound identity has sufficient rights to
modify the password. This may be done by the use of an access
control mechanism. If the user is not allowed to add this
password, the server sends an addResponse to the client with the
resultCode: unwillingToPerform (53), and includes the
passwordPolicyControl in the controls field of the addResponse
message with the error: passwordModNotAllowed (3).
2. Checks the value of the pwdCheckSyntax attribute.
If the value is non-0:
A. ensures that the password meets the syntax restrictions
enforced by the server. This enforcement is implementation
specific. If the password fails this check or the password is
hashed and the value of the pwdCheckSyntax attribute is 2, the
server sends a modifyResponse to the client with the
resultCode: constraintViolation (19), and includes the
passwordPolicyControl in the controls field of the
modifyResponse message with the error: invalidPasswordSyntax
(5).
B. Checks the value of the pwdMinLength attribute. If the value
is non-0, ensures that the new password is of at least the
minimum length. If not or if the password is hashed and the
Behera, et. al. Proposed Standard Page 18
Password Policy for LDAP Directories July 2000
value of the pwdCheckSyntax attribute is 2, the server sends a
modifyResponse to the client with the resultCode:
constraintViolation (19), and includes the
passwordPolicyControl in the controls field of the
modifyResponse message with the error: passwordTooShort (6).
3. Checks the value of the pwdStorageScheme attribute. If the
pwdStorageScheme is other than "CLEARTEXT", the server hashes the
password with the appropriate mechanism prior to storing.
If these steps have completed without causing an error condition,
the server follows these steps in order to update the necessary
password policy state attributes.
4. Checks the value of the pwdMaxAge attribute. If the value is non-
0, or if the value of the pwdMinAge attribute is non-0, the
server updates the pwdChangedTime attribute on the entry to the
current time.
5. Removes the pwdGraceUseTime attribute from the user's entry if it
exists.
6.4 Compare Operation
The compare operation MAY be used to compare a password. This might
be performed when a client wishes to verify that user's supplied
password is correct. An example of this is an LDAP HTTP
authentication redirector. It may be 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.
While comparing password attributes, the server performs the
following steps:
1. Checks for a locked account:
If the value of the pwdAccountLockedTime attribute is 0, or if
the current time is less than the value of the
pwdAccountLockedTime attribute added to the value of the
pwdLockoutDuration, the account is locked. If the account is
locked, the server sends a compareResponse to the client with the
resultCode: unwillingToPerform (53), and includes the
passwordPolicyControl in the controls field of the
compareResponse message with the error: accountLocked (1).
2. If ACLs permit, the server proceeds with compare operation and
checks the result.
Behera, et. al. Proposed Standard Page 19
Password Policy for LDAP Directories July 2000
If the result of the compare operation is compareTrue, the server
does the following:
A. Deletes the pwdFailureTime attribute.
B. Checks for password expiration
If the value of the pwdExpireWarning attribute is 0, the
server subtracts the current time from the time stored in
pwdChangedTime to arrive at the password's age. If the age is
greater than the value in the pwdMaxAge attribute, the
password has expired.
If the value of the pwdExpireWarning attribute is non-0, and
the pwdExpirationWarned attribute is present and has a
positive value, the server subtracts the current time from the
time stored in the pwdExpirationWarned to arrive at the first
warning age. If the age is greater than the value in the
pwdExpireWarning attribute, the password has expired.
In the case of an expired password, the server checks for
remaining grace logins
- The server checks the pwdGraceUseTime attribute. If
present, it counts the number of values and subtracts it
to the pwdGraceLoginLimit. A positive result means there
are that many remaining grace logins.
- If there are remaining grace logins, the server adds a new
value with the current time in pwdGraceUseTime. Then it
sends a bindResponse with the resultCode: success (0), and
includes the passwordPolicyControl in the controls field
of the bindResponse message with the warning:
graceLoginsRemaining choice set to the number of grace
logins left.
- If there are no remaining grace logins, the server sends a
bindResponse with the resultCode: invalidCredentials (49),
and includes the passwordPolicyControl in the controls
field of the bindResponse message with the error:
passwordExpired (0) set.
C. Calculates whether the time before expiration warning should
be sent. If the pwdExpirationWarned attribute is present and
has a positive value, the warning is sent with a
timeBeforeExpiration set to the value of the
pwdExpirationWarned attribute plus the value of the
pwdExpireWarning attribute minus the current time.
Otherwise, the server subtracts the current time from the time
stored in pwdChangedTime to arrive at the password's age. If
the age is greater than the value of the pwdMaxAge attribute
minus the value of the pwdExpireWarning attribute, the server
sets the current time as the value of the pwdExpirationWarned
attribute, and the warning is sent with a timeBeforeExpiration
set to the value of pwdMaxAge minus the password's age.
Behera, et. al. Proposed Standard Page 20
Password Policy for LDAP Directories July 2000
The server sends a bindResponse with the resultCode: success
(0), and includes the passwordPolicyControl in the controls
field of the bindResponse message with the warning:
timeBeforeExiration set to the value as described above.
If the result of the compare operation is compareFalse, the
server does the following:
A. Adds the current time as a value of the pwdFailureTime
attribute.
B. Counts the number of values in the pwdFailureTime attribute
that are younger than pwdFailureCountInterval. If the number
of these failures is greater or equal to the pwdMaxFailure
attribute, the server locks the account by setting the value
of the pwdAccountLockedTime attribute to the current time.
After locking the account, the server sends a bindResponse to
the client with the resultCode: unwillingToPerform (53), and
includes the passwordPolicyControl in the controls field of
the bindResponse message with the error: accountLocked (1).
C. Failures times that are old by more than
pwdFailureCountInterval, are purged from the pwdFailureTime
attribute.
7. Client Implementation by LDAP operation
These sections illustrate possible scenarios for each LDAP operation
and define the types of responses that identify those scenarios.
7.1. Bind Operation
For every bind response received, the client checks the resultCode
of the bindResponse and checks for a passwordPolicyControl to
determine if any of the following conditions are true and may prompt
the user accordingly.
1. The user is binding for the first time after the directory
administrator set the password. In this scenario, the client may
prompt the user to change his password immediately.
resultCode: success (0)
passwordPolicyControl: error: changeAfterReset (2)
2. The user's password will expire in n number of seconds.
resultCode: success (0)
passwordPolicyControl: warning: timeBeforeExpiration [0] INTEGER
Behera, et. al. Proposed Standard Page 21
Password Policy for LDAP Directories July 2000
3. The password failure limit has been reached and the account is
locked. The user needs to retry later or contact the directory
administrator to reset the password.
resultCode: unwillingToPerform (53)
passwordPolicyControl: error: accountLocked (1)
4. The password has expired but there are remaining grace logins.
The user needs to change it.
resultCode: success (0)
passwordPolicyControl: warning: graceLoginsRemaining [1] INTEGER
5. The password has expired and there are no more grace logins. The
user needs to contact the directory administrator to reset the
password.
resultCode: invalidCredentials (49)
passwordPolicyControl: error: passwordExpired (0)
7.2 Modify Operations
7.2.1 Modify Request
If the application or client encrypts the password prior to sending
it in a password modification operation (whether done through
modifyRequest or another password modification mechanism), it SHOULD
check the values of the pwdMinLength, pwdCheckSyntax, and
pwdDefaultStorageScheme attributes and enforce these policies.
7.2.2 Modify Response
If the modifyRequest operation was used to change the password, or
if another mechanism is used--such as an extendedRequest--the
modifyResponse or other appropriate response may contain information
pertinent to password policy. The client checks the resultCode of
the response and checks for a passwordPolicyControl to determine if
any of the following conditions are true and optionally notify the
user of the condition.
1. The user attempted to change her password without specifying the
old password but the password policy requires this.
resultCode: unwillingToPerform (53)
passwordPolicyControl: error: mustSupplyOldPassword (4)
2. The user must change her password before submitting any other
LDAP requests.
resultCode: unwillingToPerform (53)
passwordPolicyControl: error: changeAfterReset (2)
3. The user doesn't have sufficient rights to change his password.
Behera, et. al. Proposed Standard Page 22
Password Policy for LDAP Directories July 2000
resultCode: unwillingToPerform (53)
passwordPolicyControl: error: passwordModNotAllowed (3)
4. It is too soon after the last password modification to change the
password.
resultCode: constraintViolation (19)
passwordPolicyControl: error: passwordTooYoung (7)
5. The length of the password is too short.
resultCode: constraintViolation (19)
passwordPolicyControl: error: passwordTooShort (6)
6. The password failed syntax checking.
resultCode: constraintViolation (19)
passwordPolicyControl: error: invalidPasswordSyntax (5)
7. The password has already been used; the user must choose a
different one.
resultCode: constraintViolation (19)
passwordPolicyControl: error: passwordInHistory (8)
7.3 Add Operation
If a password is specified in an addRequest, the client checks the
resultCode of the addResponse and checks for a passwordPolicyControl
to determine if any of the following conditions are true and may
prompt the user accordingly.
1. The user doesn't have sufficient rights to add this password.
resultCode: unwillingToPerform (53)
passwordPolicyControl: error: passwordModNotAllowed (3)
2. The length of the password is too short.
resultCode: constraintViolation (19)
passwordPolicyControl: error: passwordTooShort (6)
3. The password failed syntax checking.
resultCode: constraintViolation (19)
passwordPolicyControl: error: invalidPasswordSyntax (5)
7.4 Other Operations
Behera, et. al. Proposed Standard Page 23
Password Policy for LDAP Directories July 2000
For operations other than bind, unbind, abandon, or search, the
client checks 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: unwillingToPerform (53)
passwordPolicyControl: error: changeAfterReset (2)
8. Association between Users and Password Policy
A password policy should be defined as a subentry [SubEntry] of the
portion of the DIT to which it applies.
When the server need to find the password policy that applies to a
specific user and password attribute, it will try to locate the
nearest subentry of objectclass pwdPolicy whose pwdAttribute matches
the desired password attribute.
If several policies are defined in the same portion of the DIT, it
is up to the administrators to ensure that there's no conflict,
otherwise results could be undetermined.
9. Password Policy and Replication
The pwdPolicy object defines the password policy for a portion of
the DIT and must be replicated on all the replicas of this subtree,
as any subentry would be.
The elements of the password policy that are related to the users
are stored in the entry themselves as operational attributes.
As these attributes are subject to modifications even on a read-only
replica, replicating them must be carefully considered.
The pwdChangedTime attribute must be replicated on all replicas, to
allow expiration of the password.
The pwdReset attribute must be replicated on all replicas, to deny
access to operations other than bind and modify password.
The pwdHistory attribute must be replicated to writable replicas. It
doesn't have to be replicated to a read-only replica, since the
password will never be directly modified on this server.
The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and
pwdGraceUseTime attributes must be replicated to writable replicas,
making the password policy global for all servers.
When the user, entry is replicated to a read-only replica, these
attributes should not be replicated. This means that the number of
failures, of grace logins and the locking will take place on each
replicated server. For example, the effective number of failed
attempts on a user password will be N x M (where N is the number of
servers and M the value of pwdMaxFailure attribute).
Behera, et. al. Proposed Standard Page 24
Password Policy for LDAP Directories July 2000
Replicating these attributes to a read-only replica may reduce the
number of tries globally but may also introduce some inconstancies
in the way the password policy is applied.
10. Security Considerations
This document defines a set of rules to implement in an LDAP server,
in order to improve the security of LDAP directories and make it
difficult for password cracking programs to break into directories.
Access controls should be used to restrict access to the password
policy attributes, especially all the attributes defined to maintain
the Password Policy state information SHOULD not be modifiable by
anyone but the Administrator of the directory server.
When a password policy is put in place, the LDAP directory is
subject to a denial of service attack. A malicious user could
deliberately lock out one specific user's account (or all of them)
by sending bind requests with wrong passwords. There is no way to
protect against this kind of attack. The LDAP directory server
should log as much information as it can (such as client IP address)
whenever an account is locked, in order to be able to identify the
origin of the attack. Denying anonymous access to the LDAP directory
is also a way to restrict this kind of attack.
11. References
[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.
[RFC-2222] J. Myers, "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC-2195] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest
Authentication as a SASL Mechanism", RFC 2831, May 2000.
[SubEntry] Ed Reed, "LDAP Subentry schema", draft-ietf-ldup-
subentry-02.txt, March 2000.
Behera, et. al. Proposed Standard Page 25
Password Policy for LDAP Directories July 2000
12. Copyright Notice
Copyright (C) The Internet Society (2000). All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
13. Authors' Addresses
Prasanta Behera
Netscape Communications Corp.
4170 Network circle.
Santa Clara, CA 95054
USA
+1 408 276-3960
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
Behera, et. al. Proposed Standard Page 26
Password Policy for LDAP Directories July 2000
+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, et. al. Proposed Standard Page 27
| PAFTECH AB 2003-2026 | 2026-04-23 15:06:48 |