mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2024-12-21 03:10:25 +08:00
Code Issues Packages Projects Releases Wiki Activity
65026f4300
openldap/doc/drafts/draft-behera-ldap-password-policy-xx.txt
Kurt Zeilenga 9b66997e37 relevant I-Ds
2004-04-15 01:35:13 +00:00

1962 lines
76 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Internet-Draft P. Behera
draft behera-ldap-password-policy-07.txt L. Poitou
Intended Category: Proposed Standard Sun Microsystems
Expires: August 2004 J. Sermersheim
Novell
February 2004
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 RFC 2026.
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.
Technical discussions of this draft are held on the LDAPEXT Working
Group mailing list at ietf-ldapext@netscape.com. Editorial comments
may be sent to the authors listed in Section 13.
Copyright (C) The Internet Society (2004). All rights Reserved.
Please see the Copyright Section near the end of this document for
more information.
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
are to be interpreted as described in RFC 2119 [RFC-2119].
Behera, et. al. Expires August 15, 2004 Page 1
INTERNET DRAFT LDAP Password Policy 15 February 2004
1. Abstract
Password policy as described in this document is a set of rules that
controls how passwords are used and administered 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
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 a user's password used for an authenticated LDAP
bind operation. In this document, the term "user" represents any
LDAP client application that has an identity in the directory.
This policy is typically 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 DIGEST-MD5 [RFC-Digest].
Behera, et. al. Expires August 15, 2004 Page 2
INTERNET DRAFT LDAP Password Policy 15 February 2004
The policy described in this document assumes that the password
attribute holds a single value. No considerations are made for
directories or systems that allow a user to maintain multi-valued
password attributes.
Server implementations MAY institute internal policy whereby certain
identities (such as directory administrators) are not forced to
comply with any of password policy. In this case, the password for a
directory administrator never expires; the account is never locked,
etc.
The term "directory administrator" refers to a user that has
sufficient access control privileges to modify users' passwords, and
the pwdPolicy object defined in this document. The access control
that is used to determine whether an identity is a directory
administrator is beyond the scope of this document, but typically
implies that the administrator has 'write' privileges to the
password attribute.
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 when a password is used 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
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 on failed authentication attempts.
- 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.
Behera, et. al. Expires August 15, 2004 Page 3
INTERNET DRAFT LDAP Password Policy 15 February 2004
- 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. In this document, the term "modify
password operation" refers to any operation that is used to add or
modify a password attribute. Often this is done by updating the
userPassword attribute during an add or modify operation, but MAY be
done by other means such as an extended operation.
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 that 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 to prevent users from simply re-using a previous
password (as this would effectively circumvent the expiration
policy).
Behera, et. al. Expires August 15, 2004 Page 4
INTERNET DRAFT LDAP Password Policy 15 February 2004
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 Quality and Minimum length
In order to prevent users from creating or updating passwords that
are easy to guess, a password quality policy may be employed. This
policy consists of two general mechanisms - ensuring that passwords
conform to a defined quality criteria and ensuring that they are of
a minimum length.
Forcing a password to comply with the quality policy 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 'quality checking'
means. This can lead to unexpected behavior in a heterogeneous
environment.
3.2.5. User Defined Passwords
Behera, et. al. Expires August 15, 2004 Page 5
INTERNET DRAFT LDAP Password Policy 15 February 2004
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 has 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 during a password modify operation.
3.3. Restriction of the Password Policy
The password policy defined in this document can apply to any
attribute containing a password. Password policy state information
is held in the user's entry, and applies to a password attribute,
not a particular password attribute value. Thus the server SHOULD
enforce that the password attribute subject to password policy,
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 that hold general password policy state
information for each user.
4.1. The pwdPolicy Object Class
This object class contains the attributes defining a password policy
in effect for a set of users. Section 8 describes the administration
Behera, et. al. Expires August 15, 2004 Page 6
INTERNET DRAFT LDAP Password Policy 15 February 2004
of this object, and the relationship between it and particular
objects.
( 1.3.6.1.4.1.42.2.27.8.2.1
NAME 'pwdPolicy'
SUP top
AUXILIARY
MUST ( pwdAttribute )
MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
pwdMinLength $ 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.
( 1.3.6.1.4.1.42.2.27.8.1.1
NAME 'pwdAttribute'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
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.
( 1.3.6.1.4.1.42.2.27.8.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. If not 0, the value must be greater than or equal
to the value of the pwdMinAge.
Behera, et. al. Expires August 15, 2004 Page 7
INTERNET DRAFT LDAP Password Policy 15 February 2004
( 1.3.6.1.4.1.42.2.27.8.1.3
NAME 'pwdMaxAge'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.4. pwdInHistory
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.
( 1.3.6.1.4.1.42.2.27.8.1.4
NAME 'pwdInHistory'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.5. pwdCheckQuality
This attribute indicates how the password quality will be verified
while being modified or added. If this attribute is not present, or
if the value is '0', quality checking will not be enforced. A value
of '1' indicates that the server will check the quality, and if the
server is unable to check it (due to a hashed password or other
reasons) it will be accepted. A value of '2' indicates that the
server will check the quality, and if the server is unable to verify
it, it will return an error refusing the password.
( 1.3.6.1.4.1.42.2.27.8.1.5
NAME 'pwdCheckQuality'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.6. pwdMinLength
When quality checking is enabled, this attribute holds the minimum
number of characters that must be used in a password. If this
attribute is not present, no minimum password length will be
enforced. If the server is unable to check the length (due to a
hashed password or otherwise), the server will, depending on the
value of the pwdCheckQuality attribute, either accept the password
without checking it ('0' or '1') or refuse it ('2').
Behera, et. al. Expires August 15, 2004 Page 8
INTERNET DRAFT LDAP Password Policy 15 February 2004
( 1.3.6.1.4.1.42.2.27.8.1.6
NAME 'pwdMinLength'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.7. 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. If not 0,
the value must be smaller than the value of the pwdMaxAge attribute.
( 1.3.6.1.4.1.42.2.27.8.1.7
NAME 'pwdExpireWarning'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.8. pwdGraceLoginLimit
This attribute specifies the number of times an expired password can
be used to authenticate. If this attribute is not present or if the
value is 0, authentication will fail.
( 1.3.6.1.4.1.42.2.27.8.1.8
NAME 'pwdGraceLoginLimit'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.9. pwdLockout
This attribute indicates, when its value is "TRUE", that the
password may not be used to authenticate 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
password may be used to authenticate when the number of failed bind
attempts has been reached.
( 1.3.6.1.4.1.42.2.27.8.1.9
NAME 'pwdLockout'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
Behera, et. al. Expires August 15, 2004 Page 9
INTERNET DRAFT LDAP Password Policy 15 February 2004
4.2.10. pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
this attribute is not present, or if the value is 0 the password
cannot be used to authenticate until reset by an administrator.
( 1.3.6.1.4.1.42.2.27.8.1.10
NAME 'pwdLockoutDuration'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.11. pwdMaxFailure
This attribute specifies the number of consecutive failed bind
attempts after which the password may not be used to authenticate.
If this attribute is not present, or if the value is 0, this policy
is not checked, and the value of pwdLockout will be ignored.
( 1.3.6.1.4.1.42.2.27.8.1.11
NAME 'pwdMaxFailure'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.12. pwdFailureCountInterval
This attribute holds the number of seconds after which the password
failures are purged from the failure counter, even though no
successful authentication occurred.
If this attribute is not present, or if its value is 0, the failure
counter is only reset by a successful authentication.
( 1.3.6.1.4.1.42.2.27.8.1.12
NAME 'pwdFailureCountInterval'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
4.2.13. 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.
Behera, et. al. Expires August 15, 2004 Page 10
INTERNET DRAFT LDAP Password Policy 15 February 2004
( 1.3.6.1.4.1.42.2.27.8.1.13
NAME 'pwdMustChange'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
4.2.14. pwdAllowUserChange
This attribute indicates whether users can change their own
passwords, although the change operation is still subject to access
control. If this attribute is not present, a value of "TRUE" is
assumed.
( 1.3.6.1.4.1.42.2.27.8.1.14
NAME 'pwdAllowUserChange'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
4.2.15. 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.
( 1.3.6.1.4.1.42.2.27.8.1.15
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,
pwdPolicySubEntry.
4.3.1. Password Policy State Attribute Option
Since the password policy could apply to several attributes used to
store passwords, each of the above operational attributes must have
an option to specify which pwdAttribute is applies to.
The password policy option is defined as the following:
pwd-<passwordAttribute>
Behera, et. al. Expires August 15, 2004 Page 11
INTERNET DRAFT LDAP Password Policy 15 February 2004
where passwordAttribute a string following the OID syntax
(1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
(short name) MUST be used.
For example, if the pwdPolicy object has for pwdAttribute
"userPassword" then the pwdChangedTime operational attribute, in a
user entry, will be:
pwdChangedTime;pwd-userPassword: 20000103121520Z
This attribute option follows sub-typing semantics. If a client
requests a password policy state attribute to be returned in a
search operation, and does not specify an option, all subtypes of
that policy state attribute are returned.
4.3.2. pwdChangedTime
This attribute specifies the last time the entry's password was
changed. This is used by the password expiration policy. If this
attribute does not exist, the password will never expire.
( 1.3.6.1.4.1.42.2.27.8.1.16
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.3. pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 0 value means that the account has been locked
permanently, and that only an administrator can unlock the account.
( 1.3.6.1.4.1.42.2.27.8.1.17
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.4. pwdExpirationWarned
Behera, et. al. Expires August 15, 2004 Page 12
INTERNET DRAFT LDAP Password Policy 15 February 2004
This attribute contains the time when the password expiration
warning was first sent to the client. The password will expire in
the pwdExpireWarning time.
( 1.3.6.1.4.1.42.2.27.8.1.18
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.5. pwdFailureTime
This attribute holds the timestamps of the consecutive
authentication failures.
( 1.3.6.1.4.1.42.2.27.8.1.19
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 )
4.3.6. pwdHistory
This attribute holds a history of previously used passwords.
Values of this attribute are transmitted in string format as given
by the following ABNF:
pwdHistory = time "#" syntaxOID "#" length "#" data
time = <generalizedTimeString as specified in 6.14 of
[RFC2252]>
syntaxOID = numericoid ; the string representation of the
; dotted-decimal OID that defines the
; syntax used to store the password.
; numericoid is described in 4.1 of
; [RFC2252].
length = numericstring ; the number of octets in data.
; numericstring is described in 4.1 of
Behera, et. al. Expires August 15, 2004 Page 13
INTERNET DRAFT LDAP Password Policy 15 February 2004
; [RFC2252].
data = <octets representing the password in the format
specified by syntaxOID>.
This format allows the server to store, and transmit a history of
passwords that have been used. In order for equality matching to
function properly, the time field needs to adhere to a consistent
format. For this purpose, the time field MUST be in GMT format.
( 1.3.6.1.4.1.42.2.27.8.1.20
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.7. pwdGraceUseTime
This attribute holds the timestamps of grace login once a password
has expired.
( 1.3.6.1.4.1.42.2.27.8.1.21
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
USAGE directoryOperation)
4.3.8. pwdReset
This attribute holds a flag to indicate (when TRUE) that the
password has been reset and therefore must be changed by the user on
first authentication.
( 1.3.6.1.4.1.42.2.27.8.1.22
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)
4.3.9. pwdPolicySubentry
This attribute points to the pwdPolicy subentry in effect for this
object.
Behera, et. al. Expires August 15, 2004 Page 14
INTERNET DRAFT LDAP Password Policy 15 February 2004
( 1.3.6.1.4.1.42.2.27.8.1.23
NAME 'pwdPolicySubentry'
DESC 'The pwdPolicy subentry in effect for this object'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
USAGE directoryOperation)
5. Controls used for Password Policy
This section details the controls used while enforcing password
policy. A request control is defined that is sent by a client with a
request operation in order to elicit a response control. The
response control contains various warnings and errors associated
with password policy.
5.1. Request Control
This control MAY be sent with any LDAP request message in order to
convey to the server that this client is aware of, and can process
the response control described in this document. When a server
receives this control, it will return the response control when
appropriate and with the proper data.
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality
MUST be FALSE. There is no controlValue.
passwordPolicyRequest
controlType: 1.3.6.1.4.1.42.2.27.8.5.1
criticality: FALSE
controlValue: None
5.2. Response Control
If the client has sent a passwordPolicyRequest control, the server
sends this control with the following operation responses:
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).
passwordPolicyResponse
controlType: 1.3.6.1.4.1.42.2.27.8.5.1
criticality: FALSE
controlValue: an OCTET STRING, whose value is the BER encoding of the
following type:
Behera, et. al. Expires August 15, 2004 Page 15
INTERNET DRAFT LDAP Password Policy 15 February 2004
PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL
error [1] ENUMERATED {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
insufficientPasswordQuality (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) } OPTIONAL }
The timeBeforeExpiration warning specifies the number of seconds
before a password will expire. The graceLoginsRemaining warning
specifies the remaining number of times 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 error is set when a user
is restricted from changing her password. The
insufficientPasswordQuality error is set when a password doesn't
pass quality checking. The passwordTooYoung error 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
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.
The scenarios in the following operations assume that the client has
attached a passwordPolicyRequest control to the request message of
Behera, et. al. Expires August 15, 2004 Page 16
INTERNET DRAFT LDAP Password Policy 15 February 2004
the operation. In the event that the passwordPolicyRequest control
was not sent, no passwordPolicyRequest control is returned. All
other instructions remain the same.
6.1. Bind Operation
When processing a bind request, the server MUST perform the
following steps:
1. Check 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 MUST send a bindResponse to
the client with the resultCode: unwillingToPerform (53), and MUST
include the passwordPolicyResponse in the controls field of the
bindResponse message with the error: accountLocked (1).
If the account is not locked, the server MUST proceed with the
bind operation.
2. Check the result of the bind operation:
If the bind operation succeeds with authentication, the server
MUST do the following:
A. Delete the pwdFailureTime attribute.
B. Check 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 password must be
changed now.
If the password must be changed now, the server MUST send a
bindResponse to the client with the resultCode: success (0),
and MUST include the passwordPolicyResponse in the controls
field of the bindResponse message with the warning:
changeAfterReset specified.
The server MUST then disallow all operations issued by this
user except modify password, bind, unbind, abandon and
StartTLS extended operation.
If the password does not need to be changed now, the operation
proceeds.
Behera, et. al. Expires August 15, 2004 Page 17
INTERNET DRAFT LDAP Password Policy 15 February 2004
C. Check for password expiration
The password has expired when either of the following
conditions is met:
- 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-
zero, and the pwdExpirationWarned attribute is present and
has a time 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.
If the password has expired, the server MUST check for
remaining grace logins.
If the pwdGraceUseTime attribute is present, the server
MUST count the number of values in that attribute and
subtract it from the pwdGraceLoginLimit. A positive result
specifies the number of remaining grace logins.
If there are remaining grace logins, the server MUST add a
new value with the current time in pwdGraceUseTime. Then
it MUST send a bindResponse with the resultCode: success
(0), and MUST include the passwordPolicyResponse 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 MUST
send a bindResponse with the resultCode:
invalidCredentials (49), and MUST include the
passwordPolicyResponse in the controls field of the
bindResponse message with the error: passwordExpired (0)
set.
If the password has not expired, execution continues.
D. Calculates whether the time before expiration warning should
be sent.
Behera, et. al. Expires August 15, 2004 Page 18
INTERNET DRAFT LDAP Password Policy 15 February 2004
If the pwdExpireWarning attribute is present and contains a
value, the server MUST perform the following steps.
If the pwdExpirationWarned attribute is present and has a
time value, the warning time is the value of the
pwdExpirationWarned attribute plus the value of the
pwdExpireWarning attribute minus the current time.
If the pwdExpirationWarned attribute is not present, the
server MUST subtract 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 MUST set the current time as the value of the
pwdExpirationWarned attribute, and the warning time is the
value of pwdMaxAge minus the password's age.
If the warning time is a positive number, the server MUST
send a bindResponse with the resultCode: success (0), and
MUST include the passwordPolicyResponse in the controls
field of the bindResponse message with the warning:
timeBeforeExiration set to the value as described above.
If the warning time is zero, or wasn't calculated, the
server MUST send a bindResponse with the resultCode:
success (0), and MUST include the passwordPolicyResponse
with nothing in the SEQUENCE.
If the pwdExpireWarning attribute is not present, the server
MUST send a bindResponse with the resultCode: success (0),
and MUST include the passwordPolicyResponse with nothing in
the SEQUENCE.
If the bind operation fails authentication due to invalid
credentials, the server MUST do the following:
A. Add the current time as a value of the pwdFailureTime
attribute.
B. If the pwdLockout attribute is TRUE, the server MUST also do
the following:
Count 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 MUST lock the account
by setting the value of the pwdAccountLockedTime attribute
to the current time. After locking the account, the server
Behera, et. al. Expires August 15, 2004 Page 19
INTERNET DRAFT LDAP Password Policy 15 February 2004
MUST send a bindResponse to the client with the
resultCode: unwillingToPerform (53), and MUST include the
passwordPolicyResponse in the controls field of the
bindResponse message with the error: accountLocked (1).
If the number of failures is less than the pwdMaxFailure
attribute, operation proceeds.
C. Failure times that are old by more than
pwdFailureCountInterval are purged from the pwdFailureTime
attribute.
6.2. Modify Password Operation
Because the password is stored in an attribute, the modify operation
may be used to create or update a password. But some alternate
mechanisms have been defined or may be defined, such as the LDAP
Password Modify Extended Operation [RFC-3062].
While processing a password modification, the server MUST perform
the following steps:
1. Check the pwdSafeModify attribute. If set to TRUE, the server
MUST ensure that the modify password operation included the
user's existing password. When the LDAP modify operation is used
to modify a password, this is done by specifying both a delete
action and an add or replace action, where the delete action is
first, and specifies the existing password, and the add or
replace action specifies the new password. Other password modify
operations SHOULD employ a similar mechanism. Otherwise this
policy will fail.
If the existing password is not specified, the server MUST NOT
process the operation and MUST send the appropriate response
message to the client with the resultCode: unwillingToPerform
(53), and MUST include the passwordPolicyResponse in the controls
field of the response message with the error:
mustSupplyOldPassword (4).
2. Check the value of the pwdMustChange attribute. If TRUE, the
server MUST check the pwdReset attribute in the user's entry, to
see if a directory administrator has reset the password. If so,
it MUST ensure that the modify password operation contains no
Behera, et. al. Expires August 15, 2004 Page 20
INTERNET DRAFT LDAP Password Policy 15 February 2004
modifications other than the modification of the password
attribute. If other modifications exist, the server MUST send a
response message to the client with the resultCode:
unwillingToPerform (53), and MUST include the
passwordPolicyResponse in the controls field of the response
message with the error: changeAfterReset (2).
3. Check to see whether the bound identity has sufficient rights to
modify the password. If the bound identity is a user changing its
own password, this MAY be done by checking the pwdAllowUserChange
attribute or using an access control mechanism. The determination
of this is implementation specific. If the user is not allowed to
change her password, the server MUST send a response message to
the client with the resultCode: unwillingToPerform (53), and MUST
include the passwordPolicyResponse in the controls field of the
response message with the error: passwordModNotAllowed (3).
4. Check the value of the pwdMinAge attribute. If it is set to a
non-zero value, the server MUST subtract 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 MUST send a response message to the client
with the resultCode: constraintViolation (19), and MUST include
the passwordPolicyResponse in the controls field of the response
message with the error: passwordTooYoung (7).
5. Check the value of the pwdCheckQuality attribute.
If the value is non-zero, The server:
A. MUST ensure that the password meets the quality criteria
enforced by the server. This enforcement is implementation
specific.
If the server is unable to check the quality (due to a hashed
password or otherwise), the value of pwdCheckQuality is
evaluated. If the value is 1, operation MUST continue. If the
value is 2, the server MUST send a response message to the
client with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the response message with the error:
insufficientPasswordQuality (5).
If the server is able to check the password quality, and the
check fails, the server MUST send a response message to the
client with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
Behera, et. al. Expires August 15, 2004 Page 21
INTERNET DRAFT LDAP Password Policy 15 February 2004
the response message with the error:
insufficientPasswordQuality (5).
B. MUST check the value of the pwdMinLength attribute. If the
value is non-zero, it MUST ensure that the new password is of
at least the minimum length.
If the server is unable to check the length (due to a hashed
password or otherwise), the value of pwdCheckQuality is
evaluated. If the value is 1, operation MUST continue. If the
value is 2, the server MUST send a response message to the
client with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the response message with the error: passwordTooShort (6).
If the server is able to check the password length, and the
check fails, the server MUST send a response message to the
client with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the response message with the error: passwordTooShort (6).
6. Check the value of the pwdInHistory attribute. If the value is
non-zero, the server MUST check 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 MUST send a
response message to the client with the resultCode:
constraintViolation (19), and MUST include the
passwordPolicyResponse in the controls field of the response
message with the error: passwordInHistory (8).
If the steps have completed without causing an error condition, the
server MUST follow the following steps in order to update the
necessary password policy state attributes:
7. Check the value of the pwdMaxAge attribute. If the value is non-
zero, or if the value of the pwdMinAge attribute is non-zero, the
server MUST update the pwdChangedTime attribute on the entry to
the current time.
8. If the value of the pwdInHistory attribute is non-zero, the
server MUST add the previous password to the pwdHistory
attribute. If the number of attributes held in the pwdHistory
attribute exceeds the value of pwdInHistory, the server MUST
remove the oldest excess passwords.
9. Remove the pwdFailureTime, pwdReset, pwdGraceUseTime and
pwdExpirationWarned attributes from the user's entry if they
Behera, et. al. Expires August 15, 2004 Page 22
INTERNET DRAFT LDAP Password Policy 15 February 2004
exist.
The server MUST then apply the modify password operation.
6.3. Add Operation
The password MAY be set during an Add operation. If it is, the
server MUST perform the following steps while processing the add
operation. Note that these are essentially duplicates of steps 3, 5
and 7 from Section 6.2 with the exception that pwdAllowUserChange is
not checked.
1. Check 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 MUST send an addResponse to the client with
the resultCode: unwillingToPerform (53), and MUST include the
passwordPolicyResponse in the controls field of the addResponse
message with the error: passwordModNotAllowed (3).
2. Check the value of the pwdCheckQuality attribute.
If the value is non-zero, The server:
A. MUST ensure that the password meets the quality criteria
enforced by the server. This enforcement is implementation
specific.
If the server is unable to check the quality (due to a hashed
password or otherwise), the value of pwdCheckQuality MUST be
evaluated. If the value is 1, operation MUST continue. If the
value is 2, the server MUST send an addResponse to the client
with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the addResponse message with the error:
insufficientPasswordQuality (5).
If the server is able to check the password quality, and the
check fails, the server MUST send an addResponse to the client
with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the addResponse message with the error:
insufficientPasswordQuality (5).
B. MUST check the value of the pwdMinLength attribute. If the
value is non-zero, it MUST ensure that the new password is of
at least the minimum length.
Behera, et. al. Expires August 15, 2004 Page 23
INTERNET DRAFT LDAP Password Policy 15 February 2004
If the server is unable to check the length (due to a hashed
password or otherwise), the value of pwdCheckQuality MUST be
evaluated. If the value is 1, operation MUST continue. If the
value is 2, the server MUST send an addResponse to the client
with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the addResponse message with the error: passwordTooShort (6).
If the server is able to check the password length, and the
check fails, the server MUST send an addResponse to the client
with the resultCode: constraintViolation (19), and MUST
include the passwordPolicyResponse in the controls field of
the addResponse message with the error: passwordTooShort (6).
If the steps above have completed without causing an error
condition, the server MUST follow the steps below in order to update
the necessary password policy state attributes.
3. Check the value of the pwdMaxAge attribute. If the value is non-
zero, or if the value of the pwdMinAge attribute is non-zero, the
server MUST update the pwdChangedTime attribute on the entry to
the current time.
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. Access Controls SHOULD 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 MUST perform the
following steps:
1. Check 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 MUST send a compareResponse
to the client with the resultCode: compareFalse (5), and MUST
Behera, et. al. Expires August 15, 2004 Page 24
INTERNET DRAFT LDAP Password Policy 15 February 2004
include the passwordPolicyResponse in the controls field of the
compareResponse message with the error: accountLocked (1).
If the account is not locked, the server MUST proceed with the
compare operation.
2. If Access Controls permit, the server MUST proceed with compare
operation and MUST check the result.
If the result of the compare operation is true, the server MUST
do the following:
A. Delete the pwdFailureTime attribute.
B. Check for password expiration
The password has expired when either of the following
conditions is met:
- If the value of the pwdExpireWarning attribute is 0, the
server MUST subtract 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-
zero, and the pwdExpirationWarned attribute is present and
has a time value, the server MUST subtract 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.
If the password has expired, the server MUST check for
remaining grace logins.
If the pwdGraceUseTime attribute is present, the server
MUST count the number of values in that attribute and MUST
subtract it from the pwdGraceLoginLimit. A positive result
specifies the number of remaining grace logins.
If there are remaining grace logins, the server MUST add a
new value with the current time in pwdGraceUseTime. Then
it MUST send a compareResponse with the resultCode:
compareTrue (6), and MUST include the
passwordPolicyResponse in the controls field of the
compareResponse message with the warning:
graceLoginsRemaining choice set to the number of grace
logins left.
Behera, et. al. Expires August 15, 2004 Page 25
INTERNET DRAFT LDAP Password Policy 15 February 2004
If there are no remaining grace logins, the server MUST
send a compareResponse with the resultCode: compareFalse
(5), and MUST include the passwordPolicyResponse in the
controls field of the compareResponse message with the
error: passwordExpired (0) set.
If the password has not expired, execution MUST continue.
C. Calculate whether the time before expiration warning should be
sent.
If the pwdExpireWarning attribute is present and contains a
value, the server MUST perform the following steps.
If the pwdExpirationWarned attribute is present and has a
time value, the warning time is the value of the
pwdExpirationWarned attribute plus the value of the
pwdExpireWarning attribute minus the current time.
If the pwdExpirationWarned attribute is not present, the
server MUST subtract 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 MUST set the current time as the value of the
pwdExpirationWarned attribute, and the warning time is the
value of pwdMaxAge minus the password's age.
If the warning time is a positive number, the server MUST
send a compareResponse with the resultCode: compareTrue
(6), and MUST include the passwordPolicyResponse in the
controls field of the compareResponse message with the
warning: timeBeforeExiration set to the value as described
above.
If the warning time is zero, or wasn't calculated, the
server MUST send a compareResponse with the resultCode:
compareTrue (6), and MUST include the
passwordPolicyResponse with nothing in the SEQUENCE.
If the pwdExpireWarning attribute is not present, the server
MUST send a compareResponse with the resultCode: compareTrue
(6), and MUST include the passwordPolicyResponse with nothing
in the SEQUENCE.
If the result of the compare operation is false, the server MUST
do the following:
Behera, et. al. Expires August 15, 2004 Page 26
INTERNET DRAFT LDAP Password Policy 15 February 2004
A. Add the current time as a value of the pwdFailureTime
attribute.
B. If the pwdLockout attribute is TRUE, the server MUST do
the following:
Count 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 MUST lock the
account by setting the value of the
pwdAccountLockedTime attribute to the current time.
After locking the account, the server MUST send a
compareResponse to the client with the resultCode:
compareFalse (5), and MUST include the
passwordPolicyResponse in the controls field of the
compareResponse message with the error: accountLocked
(1).
If the number of failures is less than the
pwdMaxFailure attribute, operation MUST proceed.
If the pwdLockout attribute is FALSE, operation MUST
continue.
C. Failure times that are old by more than
pwdFailureCountInterval, MUST be purged from the
pwdFailureTime attribute.
D. If no errors were returned, the server MUST send a
compareResponse with the resultCode: compareTrue (6), and
MUST include the passwordPolicyResponse with nothing in
the SEQUENCE.
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.
The scenarios in the following operations assume that the client
attached a passwordPolicyRequest control to the request message of
the operation, and thus MAY receive a passwordPolicyResponse control
in the response message. In the event that the passwordPolicyRequest
control was not sent, no passwordPolicyRequest control is returned.
All other instructions remain the same.
7.1. Bind Operation
Behera, et. al. Expires August 15, 2004 Page 27
INTERNET DRAFT LDAP Password Policy 15 February 2004
For every bind response received, the client MUST check the
resultCode of the bindResponse and MUST check for a
passwordPolicyResponse to determine if any of the following
conditions are true and MAY prompt the user accordingly.
1. 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)
passwordPolicyResponse: error: accountLocked (1)
2. The user is binding for the first time after the directory
administrator set the password. In this scenario, the client
SHOULD prompt the user to change his password immediately.
resultCode: success (0)
passwordPolicyResponse: error: changeAfterReset (2)
3. The password has expired but there are remaining grace logins.
The user needs to change it.
resultCode: success (0)
passwordPolicyResponse: warning: graceLoginsRemaining
4. The password has expired and there are no more grace logins. The
user MUST contact the directory administrator in order to have
its password reset.
resultCode: invalidCredentials (49)
passwordPolicyResponse: error: passwordExpired (0)
5. The user's password will expire in n number of seconds.
resultCode: success (0)
passwordPolicyResponse: warning: timeBeforeExpiration
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, and pwdCheckQuality attributes
and SHOULD enforce these policies.
7.2.2. Modify Response
Behera, et. al. Expires August 15, 2004 Page 28
INTERNET DRAFT LDAP Password Policy 15 February 2004
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 MUST check the resultCode
of the response and MUST check for a passwordPolicyResponse 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)
passwordPolicyResponse: error: mustSupplyOldPassword (4)
2. The user MUST change her password before submitting any other
LDAP requests.
resultCode: unwillingToPerform (53)
passwordPolicyResponse: error: changeAfterReset (2)
3. The user doesn't have sufficient rights to change his password.
resultCode: unwillingToPerform (53)
passwordPolicyResponse: error: passwordModNotAllowed (3)
4. It is too soon after the last password modification to change the
password.
resultCode: constraintViolation (19)
passwordPolicyResponse: error: passwordTooYoung (7)
5. The password failed quality checking.
resultCode: constraintViolation (19)
passwordPolicyResponse: error:
insufficientPasswordQuality (5)
6. The length of the password is too short.
resultCode: constraintViolation (19)
passwordPolicyResponse: error: passwordTooShort (6)
7. The password has already been used; the user MUST choose a
different one.
resultCode: constraintViolation (19)
passwordPolicyResponse: error: passwordInHistory (8)
Behera, et. al. Expires August 15, 2004 Page 29
INTERNET DRAFT LDAP Password Policy 15 February 2004
7.3. Add Operation
If a password is specified in an addRequest, the client MUST check
the resultCode of the addResponse and MUST check for a
passwordPolicyResponse 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)
passwordPolicyResponse: error: passwordModNotAllowed (3)
2. The password failed quality checking.
resultCode: constraintViolation (19)
passwordPolicyResponse: error:
insufficientPasswordQuality (5)
3. The length of the password is too short.
resultCode: constraintViolation (19)
passwordPolicyResponse: error: passwordTooShort (6)
7.4. Compare Operation
When a compare operation is used to compare a password, the client
MUST check the resultCode of the compareResponse and MUST check for
a passwordPolicyResponse to determine if any of the following
conditions are true and MAY prompt the user accordingly. These
conditions assume that the result of the comparison was true.
1. 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: compareFalse (5)
passwordPolicyResponse: error: accountLocked (1)
2. The password has expired but there are remaining grace logins.
The user needs to change it.
resultCode: compareTrue (6)
passwordPolicyResponse: warning: graceLoginsRemaining
3. The password has expired and there are no more grace logins. The
user MUST contact the directory administrator to reset the
password.
Behera, et. al. Expires August 15, 2004 Page 30
INTERNET DRAFT LDAP Password Policy 15 February 2004
resultCode: compareFalse (5)
passwordPolicyResponse: error: passwordExpired (0)
4. The user's password will expire in n number of seconds.
resultCode: compareTrue (6)
passwordPolicyResponse: warning: timeBeforeExpiration
7.5. Other Operations
For operations other than bind, unbind, abandon, search or StartTLS,
the client MUST 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: unwillingToPerform (53)
passwordPolicyResponse: error: changeAfterReset (2)
8. Administration of a Password Policy
A password policy MUST be defined for a particular subtree of the
DIT by adding to an LDAP subentry whose immediate superior is the
root of the subtree, the pwdPolicy auxiliary object class.
The scope of the password policy is defined by the
SubtreeSpecification attribute of the LDAP subentry as specified in
RFC 3672 [RFC-3672].
It is possible to define password policies for different password
attributes within the same pwdPolicy entry, by specifying multiple
values of the pwdAttribute. But password policies could also be in
separate sub entries as long as they are contained under the same
LDAP subentry.
Modifying the password policy MUST not result in any change in
users' entries to which the policy applies.
It SHOULD be possible to overwrite the password policy for one user
by defining a new policy in a subentry of the user entry.
Each object that is controlled by password policy SHALL advertise
the subentry that is being used to control its policy in its
pwdPolicySubentry attribute. Clients wishing to examine or manage
password policy for an object, MUST interrogate the
Behera, et. al. Expires August 15, 2004 Page 31
INTERNET DRAFT LDAP Password Policy 15 February 2004
pwdPolicySubentry for that object in order to arrive at the proper
pwdPolicy subentry.
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, in order to have a consistent policy among
all replicated servers.
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).
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 mitigate some of the security risks associated with the
use of passwords and to make it difficult for password cracking
programs to break into directories.
Authentication with a password MUST follow the recommendations made
in RFC 2829 [RFC-2829].
Behera, et. al. Expires August 15, 2004 Page 32
INTERNET DRAFT LDAP Password Policy 15 February 2004
Modifications of passwords SHOULD only occur when the connection is
protected with confidentiality and secure authentication.
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.
As it is possible to define a password policy for one specific user
by adding a subentry immediately under the user's entry, Access
Controls SHOULD be used to restrict the use of the pwdPolicy object
class or the LDAP subentry object class.
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 attacks.
11. Acknowledgement
This document is based in part on prior work done by Valerie Chu
from Netscape Communications Corp, published as draft-vchu-ldap-pwd-
policy-00.txt (December 1998).
12. Normative References
[RFC-2119] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC-2195] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC-2222] J. Myers, "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[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.
Behera, et. al. Expires August 15, 2004 Page 33
INTERNET DRAFT LDAP Password Policy 15 February 2004
[RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest
Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC-3062] K. Zeilenga, "LDAP Password Modify Extended Operation",
RFC 3062, February 2001.
[RFC-3672] K. Zeilenga, S. Legg, "Subentries in the Lightweight
Directory Access Protocol (LDAP)", RFC 3672, December.
13. Authors' Addresses
Prasanta Behera
18366 Chelmsford Dr.
Cupertino, CA 95014
USA
prasantabehera@yahoo.com
Ludovic Poitou
Sun Microsystems Inc.
180, Avenue de l'Europe
Zirst de Montbonnot
38334 Saint Ismier cedex
France
+33 476 188 212
ludovic.poitou@sun.com
Jim Sermersheim
Novell, Inc.
1800 South Novell Place
Provo, Utah 84606, USA
+1 801 861-3088
jimse@novell.com
14. Copyright Notice
Copyright (C) The Internet Society (2004). 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
Behera, et. al. Expires August 15, 2004 Page 34
INTERNET DRAFT LDAP Password Policy 15 February 2004
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."
Behera, et. al. Expires August 15, 2004 Page 35
Reference in New Issue View Git Blame Copy Permalink