-
Network Working Group J. Sermersheim
Internet-Draft Novell, Inc
-Expires: January 18, 2006 L. Poitou
- Sun Microsystems
- July 17, 2005
+Intended status: Standards Track L. Poitou
+Expires: February 10, 2010 Sun Microsystems
+ H. Chu, Ed.
+ Symas Corp.
+ August 9, 2009
Password Policy for LDAP Directories
- draft-behera-ldap-password-policy-09.txt
+ draft-behera-ldap-password-policy-10.txt
Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on January 18, 2006.
+ This Internet-Draft will expire on February 10, 2010.
Copyright Notice
- Copyright (C) The Internet Society (2005).
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 1]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
Abstract
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
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 1]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
construction requirements, the re-use of old password is restricted,
- and users are locked out after a certain number of failed attempts.
+ and to deter password guessing attacks.
-Discussion Forum
- Technical discussion of this document will take place on the IETF
- LDAP Extensions mailing list <ldapext@ietf.org>. Please send
- editorial comments directly to the authors.
-
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 2]
+Sermersheim, et al. Expires February 10, 2010 [Page 2]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
Table of Contents
- 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. Application of password policy . . . . . . . . . . . . . . . . 6
- 4. Articles of password policy . . . . . . . . . . . . . . . . . 7
- 4.1 Password Usage Policy . . . . . . . . . . . . . . . . . . . . 7
- 4.2 Password Modification Policy . . . . . . . . . . . . . . . . . 7
- 4.3 Restriction of the Password Policy . . . . . . . . . . . . . . 10
- 5. Schema used for Password Policy . . . . . . . . . . . . . . . 11
- 5.1 The pwdPolicy Object Class . . . . . . . . . . . . . . . . . . 11
- 5.2 Attribute Types used in the pwdPolicy ObjectClass . . . . . . 11
- 5.3 Attribute Types for Password Policy State Information . . . . 16
- 6. Controls used for Password Policy . . . . . . . . . . . . . . 21
- 6.1 Request Control . . . . . . . . . . . . . . . . . . . . . . . 21
- 6.2 Response Control . . . . . . . . . . . . . . . . . . . . . . . 21
- 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . . 23
- 7.1 Locked Account Check . . . . . . . . . . . . . . . . . . . . . 23
- 7.2 Password Must be Changed Now Check . . . . . . . . . . . . . . 23
- 7.3 Password Expiration Check . . . . . . . . . . . . . . . . . . 23
- 7.4 Remaining Grace AuthN Check . . . . . . . . . . . . . . . . . 23
- 7.5 Time Before Expiration Check . . . . . . . . . . . . . . . . . 24
- 7.6 Intruder Detection Check . . . . . . . . . . . . . . . . . . . 24
- 7.7 Password Too Young Check . . . . . . . . . . . . . . . . . . . 24
- 8. Server Policy Enforcement Points . . . . . . . . . . . . . . . 25
- 8.1 Password-based Authentication . . . . . . . . . . . . . . . . 25
- 8.2 Password Update Operations . . . . . . . . . . . . . . . . . . 27
- 8.3 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 30
- 9. Client Policy Enforcement Points . . . . . . . . . . . . . . . 31
- 9.1 Bind Operation . . . . . . . . . . . . . . . . . . . . . . . . 31
- 9.2 Modify Operations . . . . . . . . . . . . . . . . . . . . . . 32
- 9.3 Add Operation . . . . . . . . . . . . . . . . . . . . . . . . 33
- 9.4 Compare Operation . . . . . . . . . . . . . . . . . . . . . . 33
- 9.5 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 34
- 10. Administration of the Password Policy . . . . . . . . . . . . 35
- 11. Password Policy and Replication . . . . . . . . . . . . . . . 36
- 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
- 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
- 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 39
- 15. Normative References . . . . . . . . . . . . . . . . . . . . . 39
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
- Intellectual Property and Copyright Statements . . . . . . . . 41
-
-
-
-
-
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 3]
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Application of Password Policy . . . . . . . . . . . . . . . 6
+ 4. Articles of Password Policy . . . . . . . . . . . . . . . . 7
+ 4.1. Password Usage Policy . . . . . . . . . . . . . . . . . . . 7
+ 4.2. Password Modification Policy . . . . . . . . . . . . . . . . 8
+ 4.3. Restriction of the Password Policy . . . . . . . . . . . . . 10
+ 5. Schema used for Password Policy . . . . . . . . . . . . . . 12
+ 5.1. The pwdPolicy Object Class . . . . . . . . . . . . . . . . . 12
+ 5.2. Attribute Types used in the pwdPolicy ObjectClass . . . . . 12
+ 5.3. Attribute Types for Password Policy State Information . . . 18
+ 6. Controls used for Password Policy . . . . . . . . . . . . . 24
+ 6.1. Request Control . . . . . . . . . . . . . . . . . . . . . . 24
+ 6.2. Response Control . . . . . . . . . . . . . . . . . . . . . . 24
+ 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . 26
+ 7.1. Locked Account Check . . . . . . . . . . . . . . . . . . . . 26
+ 7.2. Password Must be Changed Now Check . . . . . . . . . . . . . 26
+ 7.3. Password Expiration Check . . . . . . . . . . . . . . . . . 27
+ 7.4. Remaining Grace AuthN Check . . . . . . . . . . . . . . . . 27
+ 7.5. Time Before Expiration Check . . . . . . . . . . . . . . . . 27
+ 7.6. Intruder Lockout Check . . . . . . . . . . . . . . . . . . . 27
+ 7.7. Intruder Delay Check . . . . . . . . . . . . . . . . . . . . 27
+ 7.8. Password Too Young Check . . . . . . . . . . . . . . . . . . 28
+ 8. Server Policy Enforcement Points . . . . . . . . . . . . . . 29
+ 8.1. Password-based Authentication . . . . . . . . . . . . . . . 29
+ 8.2. Password Update Operations . . . . . . . . . . . . . . . . . 31
+ 8.3. Other Operations . . . . . . . . . . . . . . . . . . . . . . 34
+ 9. Client Policy Enforcement Points . . . . . . . . . . . . . . 35
+ 9.1. Bind Operation . . . . . . . . . . . . . . . . . . . . . . . 35
+ 9.2. Modify Operations . . . . . . . . . . . . . . . . . . . . . 36
+ 9.3. Add Operation . . . . . . . . . . . . . . . . . . . . . . . 37
+ 9.4. Compare Operation . . . . . . . . . . . . . . . . . . . . . 37
+ 9.5. Other Operations . . . . . . . . . . . . . . . . . . . . . . 38
+ 10. Administration of the Password Policy . . . . . . . . . . . 39
+ 11. Password Policy and Replication . . . . . . . . . . . . . . 40
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . 42
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
+ 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 44
+ 15. Normative References . . . . . . . . . . . . . . . . . . . . 45
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
+
+
+
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 3]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
1. Overview
-Sermersheim & Poitou Expires January 18, 2006 [Page 4]
+Sermersheim, et al. Expires February 10, 2010 [Page 4]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
2. Conventions
Imperative keywords defined in [RFC2119] are used in this document,
and carry the meanings described there.
- All Basic Encoding Rules (BER) [X690] encodings follow the
- conventions found in Section 5.1 of [RFC2251].
+ All ASN.1 [X.680] Basic Encoding Rules (BER) [X.690] encodings follow
+ the conventions found in Section 5.1 of [RFC4511].
The term "password administrator" refers to a user that has
sufficient access control privileges to modify users' passwords. The
-Sermersheim & Poitou Expires January 18, 2006 [Page 5]
+Sermersheim, et al. Expires February 10, 2010 [Page 5]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-3. Application of password policy
+3. 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
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 [RFC2251] or the case
- of password based SASL [RFC2222] authentication such as CRAM-MD5
+ case of the LDAP simple authentication method [RFC4511] or the case
+ of password based SASL [RFC4422] authentication such as CRAM-MD5
[RFC2195] and DIGEST-MD5 [RFC2831].
The policy described in this document assumes that the password
-Sermersheim & Poitou Expires January 18, 2006 [Page 6]
+Sermersheim, et al. Expires February 10, 2010 [Page 6]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-4. Articles of password policy
+4. 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
password usage and password modification. Implementation details are
presented in Section 8 and Section 9.
-4.1 Password Usage Policy
+4.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.
-4.1.1 Password Guessing Limit
+4.1.1. Password Validity Policy
+
+ These mechanisms allow account usage to be controlled independent of
+ any password expiration policies. The policy defines the absolute
+ period of time for which an account may be used. This allows an
+ administrator to define an absolute starting time after which a
+ password becomes valid, and an absolute ending time after which the
+ password is disabled.
+
+ A mechanism is also provided to define the period of time for which
+ an account may remain unused before being disabled.
+
+4.1.2. Password Guessing Limit
In order to prevent intruders from guessing a user's password, a
mechanism exists to track the number of consecutive failed
authentication attempts, and take action when a limit is reached.
- This policy consists of five parts:
-
- o A configurable limit on failed authentication attempts.
+ This policy consists of several parts:
o A counter to track the number of failed authentication attempts.
+ o The amount of time to delay on the first authentication failure.
+
+ o The maximum amount of time to delay on subsequent failures.
+
o A timeframe in which the limit of consecutive failed
authentication attempts must happen before action is taken.
+ o A configurable limit on failed authentication attempts.
+
o The action to be taken when the limit is reached. The action will
either be nothing, or the account will be locked.
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 7]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
o An amount of time the account is locked (if it is to be locked).
This can be indefinite.
+ Note that using the account lock feature provides an easy avenue for
+ Denial-of-Service (DoS) attacks on user accounts. While some sites'
+ policies require accounts to be locked, this feature is discouraged
+ in favor of delaying each failed login attempt.
+
+ The delay time will be doubled on each subsequent failure, until it
+ reaches the maximum time configured.
+
+ [TBD: we could also provide a syntax for configuring a backoff
+ algorithm. E.g. "+<int>" for linearly incrementing delay, "x<int>"
+ for constant multiplier, "^<int> for geometric. But it's probably
+ overkill to add a calculator language to the server.]
-4.2 Password Modification Policy
+4.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
password attribute during an add or modify operation, but MAY be done
by other means such as an extended operation.
-
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 7]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
-4.2.1 Password Expiration, Expiration Warning, and Grace
- Authentications
+4.2.1. Password Expiration, Expiration Warning, and Grace
+ Authentications
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
is due to expire. If the user fails to heed this warning before
the expiration time, his account will be locked.
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 8]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
o 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' authentications, her account will be
locked.
-
-4.2.2 Password History
+4.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
whenever the password is changed. Users aren't allowed to specify
any passwords that are in the history list while changing passwords.
-4.2.3 Password Minimum Age
+4.2.3. Password Minimum Age
Users may circumvent the Password History mechanism by quickly
performing a series of password changes. If they change their
This process may be made less attractive to users by employing a
minimum age for passwords. If users are forced to wait 24 hours
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 8]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
between password changes, they may be less likely to cycle through a
history of 10 passwords.
-4.2.4 Password Quality and Minimum length
+4.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
The implementation of this policy meets with the following problems:
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 9]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
o 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
means. This can lead to unexpected behavior in a heterogeneous
environment.
-
-4.2.5 User Defined Passwords
+4.2.5. User Defined Passwords
In some cases, it is desirable to disallow users from adding and
updating their own passwords. This policy makes this functionality
possible.
-4.2.6 Password Change after Reset
+4.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 a password
This is needed in scenarios where a password administrator has set or
reset the password to a well-known value.
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 9]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
-4.2.7 Safe Modification
+4.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
intruder detection checks when the password for a non-authenticated
identity is being updated}
-4.3 Restriction of the Password Policy
+4.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,
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 10]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
contains one and only one password value.
-Sermersheim & Poitou Expires January 18, 2006 [Page 10]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 11]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
5. Schema used for Password Policy
attributes are defined that hold general password policy state
information for each user.
-5.1 The pwdPolicy Object Class
+5.1. The pwdPolicy Object Class
This object class contains the attributes defining a password policy
in effect for a set of users. Section 10 describes the
administration 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 $ pwdGraceAuthNLimit $ pwdLockout
- $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
- pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
-
+ ( 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 $ pwdMaxLength $ pwdExpireWarning $
+ pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
+ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
+ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
+ pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )
-5.2 Attribute Types used in the pwdPolicy ObjectClass
+5.2. Attribute Types used in the pwdPolicy ObjectClass
Following are the attribute types used by the pwdPolicy object class.
-5.2.1 pwdAttribute
+5.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 )
+ ( 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 )
-
-5.2.2 pwdMinAge
+5.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
-Sermersheim & Poitou Expires January 18, 2006 [Page 11]
+Sermersheim, et al. Expires February 10, 2010 [Page 12]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
+Internet-Draft Password Policy for LDAP Directories August 2009
- ( 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 )
+ ( 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 )
-5.2.3 pwdMaxAge
+5.2.3. pwdMaxAge
This attribute holds the number of seconds after which a modified
password will expire.
does not expire. If not 0, the value must be greater than or equal
to the value of the pwdMinAge.
- ( 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 )
-
+ ( 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 )
-5.2.4 pwdInHistory
+5.2.4. pwdInHistory
This attribute specifies the maximum number of used passwords stored
in the pwdHistory attribute.
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 )
+ ( 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 )
-
-5.2.5 pwdCheckQuality
+5.2.5. pwdCheckQuality
{TODO: Consider changing the syntax to OID. Each OID will list a
quality rule (like min len, # of special characters, etc). These
{TODO: Note that even though this is meant to be a check that happens
during password modification, it may also be allowed to happen during
authN. This is useful for situations where the password is encrypted
+ when modified, but decrypted when used to authN.}
+ This attribute indicates how the password quality will be verified
-Sermersheim & Poitou Expires January 18, 2006 [Page 12]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Sermersheim, et al. Expires February 10, 2010 [Page 13]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
- when modified, but decrypted when used to authN.}
- 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 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 )
-
+ ( 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 )
-5.2.6 pwdMinLength
+5.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
value of the pwdCheckQuality attribute, either accept the password
without checking it ('0' or '1') or refuse it ('2').
- ( 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 )
+ ( 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 )
+5.2.7. pwdMaxLength
-5.2.7 pwdExpireWarning
+ When quality checking is enabled, this attribute holds the maximum
+ number of characters that may be used in a password. If this
+ attribute is not present, no maximum 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').
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.31
+ NAME 'pwdMaxLength'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
- 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 returned. 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
-Sermersheim & Poitou Expires January 18, 2006 [Page 13]
+Sermersheim, et al. Expires February 10, 2010 [Page 14]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- SINGLE-VALUE )
+5.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 returned. 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 )
-5.2.8 pwdGraceAuthNLimit
+5.2.9. pwdGraceAuthNLimit
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 'pwdGraceAuthNLimit'
- EQUALITY integerMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- SINGLE-VALUE )
+ ( 1.3.6.1.4.1.42.2.27.8.1.8
+ NAME 'pwdGraceAuthNLimit'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+5.2.10. pwdGraceExpiry
-5.2.9 pwdLockout
+ This attribute specifies the number of seconds the grace
+ authentications are valid. If this attribute is not present or if
+ the value is 0, there is no time limit on the grace authentications.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.30
+ NAME 'pwdGraceExpire'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+5.2.11. pwdLockout
This attribute indicates, when its value is "TRUE", that the password
may not be used to authenticate after a specified number of
failed bind attempts is specified in pwdMaxFailure.
If this attribute is not present, or if the value is "FALSE", the
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 15]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
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 )
+ ( 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 )
-
-5.2.10 pwdLockoutDuration
+5.2.12. pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
cannot be used to authenticate until reset by a password
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 )
-
+ ( 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 )
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 14]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
-5.2.11 pwdMaxFailure
+5.2.13. 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 )
+ ( 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 )
-
-5.2.12 pwdFailureCountInterval
+5.2.14. pwdFailureCountInterval
This attribute holds the number of seconds after which the password
failures are purged from the failure counter, even though no
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 )
-5.2.13 pwdMustChange
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 16]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+ ( 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 )
+
+5.2.15. pwdMustChange
This attribute specifies with a value of "TRUE" that users must
change their passwords when they first bind to the directory after a
due to any actions specified by this document, it is typically set by
a password administrator after resetting a user's password.
- ( 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 )
+ ( 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 )
+5.2.16. 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. This attribute is intended to be used in the absence of an
+ access control mechanism.
+
+ ( 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 )
+
+5.2.17. pwdSafeModify
+
+ This attribute specifies whether or not the existing password must be
+ sent along with the new password when being changed. 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 )
-Sermersheim & Poitou Expires January 18, 2006 [Page 15]
+Sermersheim, et al. Expires February 10, 2010 [Page 17]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-5.2.14 pwdAllowUserChange
+5.2.18. pwdMinDelay
- 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. This attribute is intended to be used in the absense of an
- access control mechanism.
+ This attribute specifies the number of seconds to delay responding to
+ the first failed authentication attempt. If this attribute is not
+ set or is 0, no delays will be used. pwdMaxDelay must also be
+ specified if pwdMinDelay is set.
- ( 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 )
+ ( 1.3.6.1.4.1.42.2.27.8.1.24
+ NAME 'pwdMinDelay'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+5.2.19. pwdMaxDelay
-5.2.15 pwdSafeModify
+ This attribute specifies the maximum number of seconds to delay when
+ responding to a failed authentication attempt. The time specified in
+ pwdMinDelay is used as the starting time and is then doubled on each
+ failure until the delay time is greater than or equal to pwdMaxDelay
+ (or a successful authentication occurs, which resets the failure
+ counter). pwdMinDelay must be specified if pwdMaxDelay is set.
- This attribute specifies whether or not the existing password must be
- sent along with the new password when being changed. If this
- attribute is not present, a "FALSE" value is assumed.
+ ( 1.3.6.1.4.1.42.2.27.8.1.25
+ NAME 'pwdMaxDelay'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+5.2.20. pwdMaxIdle
- ( 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 )
+ This attribute specifies the number of seconds an account may remain
+ unused before it becomes locked. If this attribute is not set or is
+ 0, no check is performed.
+ ( 1.3.6.1.4.1.42.2.27.8.1.26
+ NAME 'pwdMaxIdle'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
-5.3 Attribute Types for Password Policy State Information
+5.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, pwdFailureTime, pwdHistory, pwdGraceUseTime,
- pwdReset, pwdPolicySubEntry.
+ pwdReset, pwdPolicySubEntry, pwdStartTime, pwdEndTime,
+ pwdLastSuccess.
-5.3.1 Password Policy State Attribute Option
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 18]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+5.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
(1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
(short name) MUST be used.
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 16]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
For example, if the pwdPolicy object has for pwdAttribute
"userPassword" then the pwdChangedTime operational attribute, in a
user entry, will be:
operation, and does not specify an option, all subtypes of that
policy state attribute are returned.
-5.3.2 pwdChangedTime
+5.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'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
+ ( 1.3.6.1.4.1.42.2.27.8.1.16
+ NAME 'pwdChangedTime'
+ DESC 'The time the password was last changed'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-5.3.3 pwdAccountLockedTime
+5.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
locked permanently, and that only a password 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'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 17]
+Sermersheim, et al. Expires February 10, 2010 [Page 19]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.17
+ NAME 'pwdAccountLockedTime'
+ DESC 'The time an user account was locked'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-5.3.4 pwdFailureTime
+5.3.4. 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'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- NO-USER-MODIFICATION
- USAGE directoryOperation )
+ ( 1.3.6.1.4.1.42.2.27.8.1.19
+ NAME 'pwdFailureTime'
+ DESC 'The timestamps of the last consecutive authentication
+ failures'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-
-5.3.5 pwdHistory
+5.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 ABNF:
- pwdHistory = time "#" syntaxOID "#" length "#" data
+ pwdHistory = time "#" syntaxOID "#" length "#" data
- time = <generalizedTimeString as specified in 6.14
- of [RFC2252]>
+ time = GeneralizedTime
- 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].
+ syntaxOID = numericoid ; the string representation of the
+ ; dotted-decimal OID that defines the
+ ; syntax used to store the password.
- length = numericstring ; the number of octets in data.
- ; numericstring is described in 4.1
- ; of [RFC2252].
+ length = number ; the number of octets in data.
- data = <octets representing the password in the format
- specified by syntaxOID>.
+ 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.
+ GeneralizedTime is specified in 3.3.13 of [RFC4517]. numericoid and
+ number are specified in 1.4 of [RFC4512].
- ( 1.3.6.1.4.1.42.2.27.8.1.20
- NAME 'pwdHistory'
- DESC 'The history of user s passwords'
+ This format allows the server to store, and transmit a history of
-Sermersheim & Poitou Expires January 18, 2006 [Page 18]
+Sermersheim, et al. Expires February 10, 2010 [Page 20]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
- EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
- NO-USER-MODIFICATION
- USAGE directoryOperation )
+ 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'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-5.3.6 pwdGraceUseTime
+5.3.6. pwdGraceUseTime
This attribute holds the timestamps of grace authentications after a
password has expired.
- ( 1.3.6.1.4.1.42.2.27.8.1.21
- NAME 'pwdGraceUseTime'
- DESC 'The timestamps of the grace authentication after the
- password has expired'
- EQUALITY generalizedTimeMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
+ ( 1.3.6.1.4.1.42.2.27.8.1.21
+ NAME 'pwdGraceUseTime'
+ DESC 'The timestamps of the grace authentication after the
+ password has expired'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-5.3.7 pwdReset
+5.3.7. pwdReset
This attribute holds a flag to indicate (when TRUE) that the password
has been updated by the password administrator and must be changed by
the user.
- ( 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 )
+ ( 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 )
-
-5.3.8 pwdPolicySubentry
+5.3.8. pwdPolicySubentry
This attribute points to the pwdPolicy subentry in effect for this
object.
- ( 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
- NO-USER-MODIFICATION
-Sermersheim & Poitou Expires January 18, 2006 [Page 19]
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 21]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
- USAGE directoryOperation )
+ ( 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
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+5.3.9. pwdStartTime
+ This attribute specifies the time the entry's password becomes valid
+ for authentication. Authentication attempts made before this time
+ will fail. If this attribute does not exist, then no restriction
+ applies.
+ ( 1.3.6.1.4.1.42.2.27.8.1.27
+ NAME 'pwdStartTime'
+ DESC 'The time the password becomes enabled'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+5.3.10. pwdEndTime
+ This attribute specifies the time the entry's password becomes
+ invalid for authentication. Authentication attempts made after this
+ time will fail, regardless of expiration or grace settings. If this
+ attribute does not exist, then this restriction does not apply.
+ ( 1.3.6.1.4.1.42.2.27.8.1.28
+ NAME 'pwdEndTime'
+ DESC 'The time the password becomes disabled'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+ Note that pwdStartTime may be set to a time greater than or equal to
+ pwdEndTime; this simply disables the account.
+Sermersheim, et al. Expires February 10, 2010 [Page 22]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+5.3.11. pwdLastSuccess
+ This attribute holds the timestamp of the last successful
+ authentication.
+ ( 1.3.6.1.4.1.42.2.27.8.1.29
+ NAME 'pwdLastSuccess'
+ DESC 'The timestamp of the last successful authentication'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
-Sermersheim & Poitou Expires January 18, 2006 [Page 20]
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 23]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
6. Controls used for Password Policy
{TODO: add a note about advertisement and discovery}
-6.1 Request Control
+6.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 controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
be TRUE or FALSE. There is no controlValue.
-6.2 Response Control
+6.2. Response Control
If the client has sent a passwordPolicyRequest control, the server
(when solicited by the inclusion of the request control) sends this
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
the BER encoding of the following type:
- PasswordPolicyResponseValue ::= SEQUENCE {
- warning [0] CHOICE {
- timeBeforeExpiration [0] INTEGER (0 .. maxInt),
- graceAuthNsRemaining [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 }
+ PasswordPolicyResponseValue ::= SEQUENCE {
+ warning [0] CHOICE {
+ timeBeforeExpiration [0] INTEGER (0 .. maxInt),
+ graceAuthNsRemaining [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
-Sermersheim & Poitou Expires January 18, 2006 [Page 21]
+Sermersheim, et al. Expires February 10, 2010 [Page 24]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
before a password will expire. The graceAuthNsRemaining warning
-Sermersheim & Poitou Expires January 18, 2006 [Page 22]
+Sermersheim, et al. Expires February 10, 2010 [Page 25]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
7. Policy Decision Points
attribute of the pwdPolicy object that governs the entry being
discussed is implied.
-7.1 Locked Account Check
+7.1. Locked Account Check
A status of true is returned to indicate that the account is locked
if any of these conditions are met:
o The value of the pwdAccountLockedTime attribute is 000001010000Z.
+ o The current time is less than the value of the pwdStartTime
+ attribute.
+
+ o The current time is greater than or equal to the value of the
+ pwdEndTime attribute.
+
+ o The current time is greater than or equal to the value of the
+ pwdLastSuccess attribute added to the value of the pwdMaxIdle
+ attribute.
+
o The current time is less than the value of the
pwdAccountLockedTime attribute added to the value of the
pwdLockoutDuration.
Otherwise a status of false is returned.
-7.2 Password Must be Changed Now Check
+7.2. Password Must be Changed Now Check
- A status of true is returned to indicate that the account is locked
- if all of these conditions are met:
+ A status of true is returned to indicate that the password must be
+ changed if all of these conditions are met:
- The pwdMustChange attribute is set to TRUE.
+ o The pwdMustChange attribute is set to TRUE.
- The pwdReset attribute is set to TRUE.
+ o The pwdReset attribute is set to TRUE.
Otherwise a status of false is returned.
-7.3 Password Expiration Check
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 26]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+7.3. Password Expiration Check
A status of true is returned indicating that the password has expired
if the current time minus the value of pwdChangedTime is greater than
Otherwise, a status of false is returned.
-7.4 Remaining Grace AuthN Check
+7.4. Remaining Grace AuthN Check
If the pwdGraceUseTime attribute is present, the number of values in
that attribute subtracted from the value of pwdGraceAuthNLimit is
returned. Otherwise zero is returned. A positive result specifies
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 23]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
the number of remaining grace authentications.
-7.5 Time Before Expiration Check
+7.5. Time Before Expiration Check
If the pwdExpireWarning attribute is not present a zero status is
returned. Otherwise the following steps are followed:
password's age is equal to or greater than the warning age, the value
of pwdMaxAge minus the password's age is returned.
-7.6 Intruder Detection Check
+7.6. Intruder Lockout Check
A status of true indicating that an intruder has been detected is
returned if the following conditions are met:
- The pwdLockout attribute is TRUE.
+ o The pwdLockout attribute is TRUE.
- The number of values in the pwdFailureTime attribute that are
+ o The number of values in the pwdFailureTime attribute that are
younger than pwdFailureCountInterval is greater or equal to the
pwdMaxFailure attribute.
While performing this check, values of pwdFailureTime that are old by
more than pwdFailureCountInterval are purged and not counted.
-7.7 Password Too Young Check
+7.7. Intruder Delay Check
+
+ If the pwdMinDelay attribute is 0 or not set, zero is returned.
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 27]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+ Otherwise, a delay time is computed based on the number of values in
+ the pwdFailureTime attribute. If the computed value is greater than
+ the pwdMaxDelay attribute, the pwdMaxDelay value is returned.
+
+ While performing this check, values of pwdFailureTime that are old by
+ more than pwdFailureCountInterval are purged and not counted.
+
+7.8. Password Too Young Check
+
+ If the Section 7.2 check returned true then this check will return
+ false, to allow the password to be changed.
A status of true indicating that not enough time has passed since the
password was last updated is returned if:
- The value of pwdMinAge is non-zero and pwdChangedTime is present.
+ o The value of pwdMinAge is non-zero and pwdChangedTime is present.
- The value of pwdMinAge is greater than the current time minus the
+ o The value of pwdMinAge is greater than the current time minus the
value of pwdChangedTime.
Otherwise a false status is returned.
-Sermersheim & Poitou Expires January 18, 2006 [Page 24]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 28]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
8. Server Policy Enforcement Points
password policy as defined in this document, contains one and only
one password value.
+ Note: The case where a single password value is stored in multiple
+ formats simultaneously is still considered to be only one password
+ value.
+
The scenarios in the following operations assume that the client has
attached a passwordPolicyRequest control to the request message of
the operation. In the event that the passwordPolicyRequest control
was not sent, no passwordPolicyResponse control is returned. All
other instructions remain the same.
- For successfuly completed operations, unless otherwise stated, no
+ For successfully completed operations, unless otherwise stated, no
passwordPolicyResponse control is returned.
-8.1 Password-based Authentication
+8.1. Password-based Authentication
This section contains the policy enforcement rules and policy data
updates used while validating a password. Operations that validate
passwords include, but are not limited to, the Bind operation where
- the simple choice specifies a password, and the compare operation
+ the simple choice specifies a password, and the Compare operation
where the attribute being compared holds a password. Note that while
- the compare operation does not authenticate a user to the LDAP
+ the Compare operation does not authenticate a user to the LDAP
server, it may be used by an external application for purposes of
authentication.
-8.1.1 Fail if the account is locked
+8.1.1. Fail if the account is locked
If the account is locked as specified in Section 7.1, the server
fails the operation with an appropriate resultCode (i.e.
the error: accountLocked (1) in the passwordPolicyResponse in the
controls field of the message.
-8.1.2 Validated Password Procedures
+8.1.2. Validated Password Procedures
If the validation operation indicates that the password validated,
these procedures are followed in order:
-8.1.2.1 Policy state updates
+8.1.2.1. Policy state updates
Delete the pwdFailureTime and pwdAccountLockedTime attributes.
-8.1.2.2 Password must be changed now
-
- If the decision in Section 7.2 returns true, the server sends to the
- client a response with an appropriate successful resultCode (i.e.
-Sermersheim & Poitou Expires January 18, 2006 [Page 25]
+Sermersheim, et al. Expires February 10, 2010 [Page 29]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
+ Set the value of the pwdLastSuccess attribute to the current time.
+
+ Note: setting pwdLastSuccess is optional, but it is required if the
+ policy has pwdMaxIdle defined.
+
+8.1.2.2. Password must be changed now
+
+ If the decision in Section 7.2 returns true, the server sends to the
+ client a response with an appropriate successful resultCode (i.e.
success (0), compareTrue (6), etc.), and includes the
passwordPolicyResponse in the controls field of the bindResponse
message with the warning: changeAfterReset specified.
user except modify password, bind, unbind, abandon and StartTLS
extended operation.
-8.1.2.3 Expired password
+8.1.2.3. Expired password
If the password has expired as per Section 7.3, the server either
returns a success or failure based on the state of grace
authentications.
-8.1.2.3.1 Remaining Grace Authentications
+8.1.2.3.1. Remaining Grace Authentications
If there are remaining grace authentications as per Section 7.4, the
server adds a new value with the current time in pwdGraceUseTime.
generalized time values. The fractional seconds field may be used
for this purpose.
-8.1.2.3.2 No Remaining Grace Authentications
+8.1.2.3.2. No Remaining Grace Authentications
If there are no remaining grace authentications, the server fails the
operation with an appropriate resultCode (invalidCredentials (49),
the controls field of the bindResponse message with the error:
passwordExpired (0) set.
-8.1.2.4 Expiration Warning
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 30]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+8.1.2.4. Expiration Warning
If the result of Section 7.5 is a positive number, the server sends
to the client a response with an appropriate successful resultCode
described above. Otherwise, the server sends a successful response,
and omits the passwordPolicyResponse.
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 26]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
-8.1.2.5 AuthN Failed Procedures
+8.1.3. AuthN Failed Procedures
If the authentication process indicates that the password failed
validation due to invalid credentials, these procedures are followed:
-8.1.2.5.1 Policy state update
+8.1.3.1. Policy state update
Add the current time as a value of the pwdFailureTime attribute.
generalized time values. The fractional seconds field may be used
for this purpose.
-8.1.2.5.2 Lock on intruder detection
+8.1.3.2. Handle Intruder Detection
If the check in Section 7.6 returns a true state, the server locks
the account by setting the value of the pwdAccountLockedTime
passwordPolicyResponse in the controls field of the message with the
error: accountLocked (1).
-8.2 Password Update Operations
+ If the check in Section 7.7 returns a non-zero value, the server
+ waits that number of seconds before sending the authentication
+ response back to the client.
+
+8.2. Password Update Operations
Because the password is stored in an attribute, various operations
(like add and modify) may be used to create or update a password.
While processing a password update, the server performs the following
steps:
-8.2.1 Safe Modification
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 31]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+8.2.1. Safe Modification
If pwdSafeModify is set to TRUE and if there is an existing password
value, the server ensures that the password update operation includes
operations SHOULD employ a similar mechanism. Otherwise this policy
will fail.
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 27]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
If the existing password is not specified, the server does not
process the operation and sends the appropriate response message to
the client with the resultCode: insufficientAccessRights (50), and
includes the passwordPolicyResponse in the controls field of the
response message with the error: mustSupplyOldPassword (4).
-8.2.2 Change After Reset
+8.2.2. Change After Reset
If the decision in Section 7.2 returns true, the server ensures that
the password update operation contains no modifications other than
passwordPolicyResponse in the controls field of the response message
with the error: changeAfterReset (2).
-8.2.3 Rights Check
+8.2.3. Rights Check
Check to see whether the bound identity has sufficient rights to
update the password. If the bound identity is a user changing its
includes the passwordPolicyResponse in the controls field of the
response message with the error: passwordModNotAllowed (3).
-8.2.4 Too Early to Update
+8.2.4. Too Early to Update
- If the check in Section 7.7 results in a true status The server sends
+ If the check in Section 7.8 results in a true status The server sends
a response message to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyResponse in
the controls field of the response message with the error:
passwordTooYoung (7).
-8.2.5 Password Quality
- Check the value of the pwdCheckQuality attribute. If the value is
- non-zero, the server:
-
- o 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 continues. If the value is 2, the
- server sends a response message to the client with the resultCode:
- constraintViolation (19), and includes the passwordPolicyResponse
+Sermersheim, et al. Expires February 10, 2010 [Page 32]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
-Sermersheim & Poitou Expires January 18, 2006 [Page 28]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+8.2.5. Password Quality
+ Check the value of the pwdCheckQuality attribute. If the value is
+ non-zero, the server:
+ o 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 continues. If the value is 2, the server
+ sends a response message to the client with the resultCode:
+ constraintViolation (19), and includes 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 sends a
+ response message to the client with the resultCode:
+ constraintViolation (19), and includes 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 sends a response message to the client with the
- resultCode: constraintViolation (19), and includes the
- passwordPolicyResponse in the controls field of the response
- message with the error: insufficientPasswordQuality (5).
o checks the value of the pwdMinLength attribute. If the value is
non-zero, it ensures 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 continues. If the value is 2, the
- server sends a response message to the client with the resultCode:
+ 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 continues. If the
+ value is 2, the server sends a response message to the client with
+ the resultCode: constraintViolation (19), and includes 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
+ sends a response message to the client with the resultCode:
constraintViolation (19), and includes 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 sends a response message to the client with the
- resultCode: constraintViolation (19), and includes the
- passwordPolicyResponse in the controls field of the response
- message with the error: passwordTooShort (6).
-
-8.2.6 Invalid Reuse
+8.2.6. Invalid Reuse
If pwdInHistory is present and its value is non-zero, the server
checks whether this password exists in the entry's pwdHistory
passwordPolicyResponse in the controls field of the response message
with the error: passwordInHistory (8).
-8.2.7 Policy State Updates
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 33]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
+8.2.7. Policy State Updates
If the steps have completed without causing an error condition, the
server performs the following steps in order to update the necessary
If the value of pwdInHistory is non-zero, the server adds the
previous password (if one existed) to the pwdHistory attribute. If
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 29]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
the number of attributes held in the pwdHistory attribute exceeds the
value of pwdInHistory, the server removes the oldest excess
passwords.
The pwdFailureTime and pwdGraceUseTime attributes is removed from the
user's entry if they exist.
-8.3 Other Operations
+8.3. Other Operations
For operations other than bind, password update, unbind, abandon or
StartTLS, if the decision in Section 7.2 returns true, the server
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 30]
+Sermersheim, et al. Expires February 10, 2010 [Page 34]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
9. Client Policy Enforcement Points
control was not sent, no passwordPolicyResponse control is returned.
All other instructions remain the same.
-9.1 Bind Operation
+9.1. Bind Operation
For every bind response received, the client checks the resultCode of
the bindResponse and checks for a passwordPolicyResponse control to
-Sermersheim & Poitou Expires January 18, 2006 [Page 31]
+Sermersheim, et al. Expires February 10, 2010 [Page 35]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-9.2 Modify Operations
+9.2. Modify Operations
-9.2.1 Modify Request
+9.2.1. Modify Request
If the application or client encrypts the password prior to sending
it in a password modification operation (whether done through
check the values of the pwdMinLength, and pwdCheckQuality attributes
and SHOULD enforce these policies.
-9.2.2 Modify Response
+9.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
determine if any of the following conditions are true and optionally
notify the user of the condition.
- o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
attempted to change her password without specifying the old
password but the password policy requires this.
- o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = changeAfterReset (2): The user must
change her password before submitting any other LDAP requests.
- o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = passwordModNotAllowed (3): The user
doesn't have sufficient rights to change his password.
- o <pwdModResponse>.resultCode = constraintViolation (19),
+ o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordTooYoung (7): It is too
soon after the last password modification to change the password.
- o <pwdModResponse>.resultCode = constraintViolation (19),
+ o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = insufficientPasswordQuality (5):
The password failed quality checking.
- o <pwdModResponse>.resultCode = constraintViolation (19),
+ o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordTooShort (6): The length of
the password is too short.
- o <pwdModResponse>.resultCode = constraintViolation (19),
+ o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordInHistory (8): The password
has already been used; the user must choose a different one.
-Sermersheim & Poitou Expires January 18, 2006 [Page 32]
+Sermersheim, et al. Expires February 10, 2010 [Page 36]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-9.3 Add Operation
+9.3. Add Operation
If a password is specified in an addRequest, the client checks the
resultCode of the addResponse and checks for a passwordPolicyResponse
passwordPolicyResponse.error = passwordTooShort (6): The length of
the password is too short.
-
-9.4 Compare Operation
+9.4. Compare Operation
When a compare operation is used to compare a password, the client
checks the resultCode of the compareResponse and checks for a
-Sermersheim & Poitou Expires January 18, 2006 [Page 33]
+
+Sermersheim, et al. Expires February 10, 2010 [Page 37]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
-9.5 Other Operations
+9.5. Other Operations
For operations other than bind, unbind, abandon or StartTLS, the
- client checks the following result code and control to determine if
- the user needs to change the password immediately.
+ client checks the result code and control to determine if any other
+ actions are needed.
o <Response>.resultCode = insufficientAccessRights (50),
- passwordPolicyResponse.error = : changeAfterReset (2)
-
-
-
-
-
-
+ passwordPolicyResponse.error = accountLocked (1) : The password
+ failure limit has been reached and the account is locked. The
+ user needs to retry later or contact the password administrator to
+ reset the password.
+ o <Response>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = changeAfterReset (2) : The user
+ needs to change the password immediately.
-Sermersheim & Poitou Expires January 18, 2006 [Page 34]
+Sermersheim, et al. Expires February 10, 2010 [Page 38]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
10. Administration of the Password Policy
separate sub entries as long as they are contained under the same
LDAP subentry.
+ Only one policy may be in effect for a given password attribute in
+ any entry. If multiple policies exist which overlap in the range of
+ entries affected, the resulting behavior is undefined.
+
Modifying the password policy MUST NOT result in any change in users'
entries to which the policy applies.
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 35]
+Sermersheim, et al. Expires February 10, 2010 [Page 39]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
11. Password Policy and Replication
- {TODO: This section needs to be changed to highlight the pitfals of
- replication, sugest some implementation choices to overcome those
- pitfals, but remove prescriptive language relating to the update of
+ {TODO: This section needs to be changed to highlight the pitfalls of
+ replication, suggest some implementation choices to overcome those
+ pitfalls, but remove prescriptive language relating to the update of
state information}
The pwdPolicy object defines the password policy for a portion of the
password will never be directly modified on this server.
The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
- attributes MUST be replicated to writable replicas, making the
+ attributes SHOULD 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
MAY also introduce some inconstancies in the way the password policy
is applied.
+ Note: there are some situations where global replication of these
+ state attributes may not be desired. For example, if two clusters of
+ replicas are geographically remote and joined by a slow network link,
+ and their users only login from one of the two locations, it may be
+ unnecessary to propagate all of the state changes from one cluster to
+ the other. Servers SHOULD allow administrators to control which
+ attributes are replicated on a case-by-case basis.
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 40]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
Servers participating in a loosely consistent multi-master
replication agreement SHOULD employ a mechanism which ensures
uniqueness of values when populating the attributes pwdFailureTime
-Sermersheim & Poitou Expires January 18, 2006 [Page 36]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 41]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
12. Security Considerations
programs to break into directories.
Authentication with a password MUST follow the recommendations made
- in [RFC2829].
+ in [RFC4513].
Modifications of passwords SHOULD only occur when the connection is
protected with confidentiality and secure authentication.
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.
+ is also a way to restrict this kind of attack. Using the login delay
+ instead of the lockout mechanism will also help avoid this denial of
+ service.
Returning certain status codes (such as passwordPolicyResponse.error
= accountLocked) allows a denial of service attacker to know that it
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 37]
+Sermersheim, et al. Expires February 10, 2010 [Page 42]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
13. IANA Considerations
-Sermersheim & Poitou Expires January 18, 2006 [Page 38]
+Sermersheim, et al. Expires February 10, 2010 [Page 43]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
+Internet-Draft Password Policy for LDAP Directories August 2009
14. Acknowledgement
draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
participated in early revisions of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, et al. Expires February 10, 2010 [Page 44]
+\f
+Internet-Draft Password Policy for LDAP Directories August 2009
+
+
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
- [RFC2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+ Protocol (LDAP)", RFC 3383, September 2002.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
Access Protocol (LDAP)", RFC 3672, December 2003.
- [X680] International Telecommunications Union, "Abstract Syntax
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
+ Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512,
+ June 2006.
+
+ [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+ [X.680] International Telecommunications Union, "Abstract Syntax
Notation One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, July 2002.
- [X690] International Telecommunications Union, "Information
+ [X.690] International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", ITU-T
+ Recommendation X.690, July 2002.
-Sermersheim & Poitou Expires January 18, 2006 [Page 39]
+Sermersheim, et al. Expires February 10, 2010 [Page 45]
\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
- Encoding Rules (BER), Canonical Encoding Rules (CER) and
- Distinguished Encoding Rules (DER)", ITU-T Recommendation
- X.690, July 2002.
+Internet-Draft Password Policy for LDAP Directories August 2009
Authors' Addresses
Novell, Inc
1800 South Novell Place
Provo, Utah 84606
- USA
+ US
Phone: +1 801 861-3088
Email: jimse@novell.com
Ludovic Poitou
Sun Microsystems
180, Avenue de l'Europe
- Zirst de Montbonnot, 38334 Saint Ismier cedex
- France
+ Zirst de Montbonnot, Saint Ismier cedex 38334
+ FR
Phone: +33 476 188 212
Email: ludovic.poitou@sun.com
+ Howard Chu (editor)
+ Symas Corp.
+ 18740 Oxnard Street, Suite 313A
+ Tarzana, California 91356
+ US
+ Phone: +1 818 757-7087
+ Email: hyc@symas.com
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 40]
-\f
-Internet-Draft Password Policy for LDAP Directories July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Sermersheim & Poitou Expires January 18, 2006 [Page 41]
+Sermersheim, et al. Expires February 10, 2010 [Page 46]
\f
-
projects / openldap / commitdiff