4 Network Working Group J. Sermersheim
5 Internet-Draft Novell, Inc
6 Intended status: Standards Track L. Poitou
7 Expires: February 10, 2010 Sun Microsystems
13 Password Policy for LDAP Directories
14 draft-behera-ldap-password-policy-10.txt
18 This Internet-Draft is submitted to IETF in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on February 10, 2010.
41 Copyright (c) 2009 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents in effect on the date of
46 publication of this document (http://trustee.ietf.org/license-info).
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document.
55 Sermersheim, et al. Expires February 10, 2010 [Page 1]
57 Internet-Draft Password Policy for LDAP Directories August 2009
62 Password policy as described in this document is a set of rules that
63 controls how passwords are used and administered in Lightweight
64 Directory Access Protocol (LDAP) based directories. In order to
65 improve the security of LDAP directories and make it difficult for
66 password cracking programs to break into directories, it is desirable
67 to enforce a set of rules on password usage. These rules are made to
68 ensure that users change their passwords periodically, passwords meet
69 construction requirements, the re-use of old password is restricted,
70 and to deter password guessing attacks.
111 Sermersheim, et al. Expires February 10, 2010 [Page 2]
113 Internet-Draft Password Policy for LDAP Directories August 2009
118 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
119 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5
120 3. Application of Password Policy . . . . . . . . . . . . . . . 6
121 4. Articles of Password Policy . . . . . . . . . . . . . . . . 7
122 4.1. Password Usage Policy . . . . . . . . . . . . . . . . . . . 7
123 4.2. Password Modification Policy . . . . . . . . . . . . . . . . 8
124 4.3. Restriction of the Password Policy . . . . . . . . . . . . . 10
125 5. Schema used for Password Policy . . . . . . . . . . . . . . 12
126 5.1. The pwdPolicy Object Class . . . . . . . . . . . . . . . . . 12
127 5.2. Attribute Types used in the pwdPolicy ObjectClass . . . . . 12
128 5.3. Attribute Types for Password Policy State Information . . . 18
129 6. Controls used for Password Policy . . . . . . . . . . . . . 24
130 6.1. Request Control . . . . . . . . . . . . . . . . . . . . . . 24
131 6.2. Response Control . . . . . . . . . . . . . . . . . . . . . . 24
132 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . 26
133 7.1. Locked Account Check . . . . . . . . . . . . . . . . . . . . 26
134 7.2. Password Must be Changed Now Check . . . . . . . . . . . . . 26
135 7.3. Password Expiration Check . . . . . . . . . . . . . . . . . 27
136 7.4. Remaining Grace AuthN Check . . . . . . . . . . . . . . . . 27
137 7.5. Time Before Expiration Check . . . . . . . . . . . . . . . . 27
138 7.6. Intruder Lockout Check . . . . . . . . . . . . . . . . . . . 27
139 7.7. Intruder Delay Check . . . . . . . . . . . . . . . . . . . . 27
140 7.8. Password Too Young Check . . . . . . . . . . . . . . . . . . 28
141 8. Server Policy Enforcement Points . . . . . . . . . . . . . . 29
142 8.1. Password-based Authentication . . . . . . . . . . . . . . . 29
143 8.2. Password Update Operations . . . . . . . . . . . . . . . . . 31
144 8.3. Other Operations . . . . . . . . . . . . . . . . . . . . . . 34
145 9. Client Policy Enforcement Points . . . . . . . . . . . . . . 35
146 9.1. Bind Operation . . . . . . . . . . . . . . . . . . . . . . . 35
147 9.2. Modify Operations . . . . . . . . . . . . . . . . . . . . . 36
148 9.3. Add Operation . . . . . . . . . . . . . . . . . . . . . . . 37
149 9.4. Compare Operation . . . . . . . . . . . . . . . . . . . . . 37
150 9.5. Other Operations . . . . . . . . . . . . . . . . . . . . . . 38
151 10. Administration of the Password Policy . . . . . . . . . . . 39
152 11. Password Policy and Replication . . . . . . . . . . . . . . 40
153 12. Security Considerations . . . . . . . . . . . . . . . . . . 42
154 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
155 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 44
156 15. Normative References . . . . . . . . . . . . . . . . . . . . 45
157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
167 Sermersheim, et al. Expires February 10, 2010 [Page 3]
169 Internet-Draft Password Policy for LDAP Directories August 2009
174 LDAP-based directory services are currently accepted by many
175 organizations as the access protocol for directories. The ability to
176 ensure the secure read and update access to directory information
177 throughout the network is essential to the successful deployment.
178 Most LDAP implementations support many authentication schemes - the
179 most basic and widely used is the simple authentication i.e., user DN
180 and password. In this case, many LDAP servers have implemented some
181 kind of policy related to the password used to authenticate. Among
182 other things, this policy includes:
184 o Whether and when passwords expire.
186 o Whether failed bind attempts cause the account to be locked.
188 o If and how users are able to change their passwords.
190 In order to achieve greater security protection and ensure
191 interoperability in a heterogeneous environment, LDAP needs to
192 standardize on a common password policy model. This is critical to
193 the successful deployment of LDAP directories.
223 Sermersheim, et al. Expires February 10, 2010 [Page 4]
225 Internet-Draft Password Policy for LDAP Directories August 2009
230 Imperative keywords defined in [RFC2119] are used in this document,
231 and carry the meanings described there.
233 All ASN.1 [X.680] Basic Encoding Rules (BER) [X.690] encodings follow
234 the conventions found in Section 5.1 of [RFC4511].
236 The term "password administrator" refers to a user that has
237 sufficient access control privileges to modify users' passwords. The
238 term "password policy administrator" refers to a user that has
239 sufficient access control privileges to modify the pwdPolicy object
240 defined in this document. The access control that is used to
241 determine whether an identity is a password administrator or password
242 policy administrator is beyond the scope of this document, but
243 typically implies that the password administrator has 'write'
244 privileges to the password attribute.
279 Sermersheim, et al. Expires February 10, 2010 [Page 5]
281 Internet-Draft Password Policy for LDAP Directories August 2009
284 3. Application of Password Policy
286 The password policy defined in this document can be applied to any
287 attribute holding a user's password used for an authenticated LDAP
288 bind operation. In this document, the term "user" represents any
289 LDAP client application that has an identity in the directory.
291 This policy is typically applied to the userPassword attribute in the
292 case of the LDAP simple authentication method [RFC4511] or the case
293 of password based SASL [RFC4422] authentication such as CRAM-MD5
294 [RFC2195] and DIGEST-MD5 [RFC2831].
296 The policy described in this document assumes that the password
297 attribute holds a single value. No considerations are made for
298 directories or systems that allow a user to maintain multi-valued
301 Server implementations MAY institute internal policy whereby certain
302 identities (such as directory administrators) are not forced to
303 comply with any of password policy. In this case, the password for a
304 directory administrator never expires; the account is never locked,
335 Sermersheim, et al. Expires February 10, 2010 [Page 6]
337 Internet-Draft Password Policy for LDAP Directories August 2009
340 4. Articles of Password Policy
342 The following sections explain in general terms each aspect of the
343 password policy defined in this document as well as the need for
344 each. These policies are subdivided into the general groups of
345 password usage and password modification. Implementation details are
346 presented in Section 8 and Section 9.
348 4.1. Password Usage Policy
350 This section describes policy enforced when a password is used to
351 authenticate. The general focus of this policy is to minimize the
352 threat of intruders once a password is in use.
354 4.1.1. Password Validity Policy
356 These mechanisms allow account usage to be controlled independent of
357 any password expiration policies. The policy defines the absolute
358 period of time for which an account may be used. This allows an
359 administrator to define an absolute starting time after which a
360 password becomes valid, and an absolute ending time after which the
361 password is disabled.
363 A mechanism is also provided to define the period of time for which
364 an account may remain unused before being disabled.
366 4.1.2. Password Guessing Limit
368 In order to prevent intruders from guessing a user's password, a
369 mechanism exists to track the number of consecutive failed
370 authentication attempts, and take action when a limit is reached.
371 This policy consists of several parts:
373 o A counter to track the number of failed authentication attempts.
375 o The amount of time to delay on the first authentication failure.
377 o The maximum amount of time to delay on subsequent failures.
379 o A timeframe in which the limit of consecutive failed
380 authentication attempts must happen before action is taken.
382 o A configurable limit on failed authentication attempts.
384 o The action to be taken when the limit is reached. The action will
385 either be nothing, or the account will be locked.
391 Sermersheim, et al. Expires February 10, 2010 [Page 7]
393 Internet-Draft Password Policy for LDAP Directories August 2009
396 o An amount of time the account is locked (if it is to be locked).
397 This can be indefinite.
399 Note that using the account lock feature provides an easy avenue for
400 Denial-of-Service (DoS) attacks on user accounts. While some sites'
401 policies require accounts to be locked, this feature is discouraged
402 in favor of delaying each failed login attempt.
404 The delay time will be doubled on each subsequent failure, until it
405 reaches the maximum time configured.
407 [TBD: we could also provide a syntax for configuring a backoff
408 algorithm. E.g. "+<int>" for linearly incrementing delay, "x<int>"
409 for constant multiplier, "^<int> for geometric. But it's probably
410 overkill to add a calculator language to the server.]
412 4.2. Password Modification Policy
414 This section describes policy enforced while users are modifying
415 passwords. The general focus of this policy is to ensure that when
416 users add or change their passwords, the security and effectiveness
417 of their passwords is maximized. In this document, the term "modify
418 password operation" refers to any operation that is used to add or
419 modify a password attribute. Often this is done by updating the
420 password attribute during an add or modify operation, but MAY be done
421 by other means such as an extended operation.
423 4.2.1. Password Expiration, Expiration Warning, and Grace
426 One of the key properties of a password is the fact that it is not
427 well known. If a password is frequently changed, the chances of that
428 user's account being broken into are minimized.
430 Password policy administrators may deploy a password policy that
431 causes passwords to expire after a given amount of time - thus
432 forcing users to change their passwords periodically.
434 As a side effect, there needs to be a way in which users are made
435 aware of this need to change their password before actually being
436 locked out of their accounts. One or both of the following methods
439 o A warning may be returned to the user sometime before his password
440 is due to expire. If the user fails to heed this warning before
441 the expiration time, his account will be locked.
447 Sermersheim, et al. Expires February 10, 2010 [Page 8]
449 Internet-Draft Password Policy for LDAP Directories August 2009
452 o The user may bind to the directory a preset number of times after
453 her password has expired. If she fails to change her password
454 during one of her 'grace' authentications, her account will be
457 4.2.2. Password History
459 When the Password Expiration policy is used, an additional mechanism
460 may be employed to prevent users from simply re-using a previous
461 password (as this would effectively circumvent the expiration
464 In order to do this; a history of used passwords is kept. The
465 password policy administrator sets the number of passwords to be
466 stored at any given time. Passwords are stored in this history
467 whenever the password is changed. Users aren't allowed to specify
468 any passwords that are in the history list while changing passwords.
470 4.2.3. Password Minimum Age
472 Users may circumvent the Password History mechanism by quickly
473 performing a series of password changes. If they change their
474 password enough times, their 'favorite' password will be pushed out
477 This process may be made less attractive to users by employing a
478 minimum age for passwords. If users are forced to wait 24 hours
479 between password changes, they may be less likely to cycle through a
480 history of 10 passwords.
482 4.2.4. Password Quality and Minimum length
484 In order to prevent users from creating or updating passwords that
485 are easy to guess, a password quality policy may be employed. This
486 policy consists of two general mechanisms - ensuring that passwords
487 conform to a defined quality criterion and ensuring that they are of
490 Forcing a password to comply with the quality policy may imply a
491 variety of things including:
493 o Disallowing trivial or well-known words make up the password.
495 o Forcing a certain number of digits be used.
497 o Disallowing anagrams of the user's name.
499 The implementation of this policy meets with the following problems:
503 Sermersheim, et al. Expires February 10, 2010 [Page 9]
505 Internet-Draft Password Policy for LDAP Directories August 2009
508 o If the password to be added or updated is encrypted by the client
509 before being sent, the server has no way of enforcing this policy.
510 Therefore, the onus of enforcing this policy falls upon client
513 o There are no specific definitions of what 'quality checking'
514 means. This can lead to unexpected behavior in a heterogeneous
517 4.2.5. User Defined Passwords
519 In some cases, it is desirable to disallow users from adding and
520 updating their own passwords. This policy makes this functionality
523 4.2.6. Password Change after Reset
525 This policy forces the user to update her password after it has been
526 set for the first time, or has been reset by a password
529 This is needed in scenarios where a password administrator has set or
530 reset the password to a well-known value.
532 4.2.7. Safe Modification
534 As directories become more commonly used, it will not be unusual for
535 clients to connect to a directory and leave the connection open for
536 an extended period. This opens up the possibility for an intruder to
537 make modifications to a user's password while that user's computer is
538 connected but unattended.
540 This policy forces the user to prove his identity by specifying the
541 old password during a password modify operation.
543 {TODO: This allows a dictionary attack unless we specify that this is
544 also subject to intruder detection. One solution is to require users
545 to authN prior to changing password. Another solution is to perform
546 intruder detection checks when the password for a non-authenticated
547 identity is being updated}
549 4.3. Restriction of the Password Policy
551 The password policy defined in this document can apply to any
552 attribute containing a password. Password policy state information
553 is held in the user's entry, and applies to a password attribute, not
554 a particular password attribute value. Thus the server SHOULD
555 enforce that the password attribute subject to password policy,
559 Sermersheim, et al. Expires February 10, 2010 [Page 10]
561 Internet-Draft Password Policy for LDAP Directories August 2009
564 contains one and only one password value.
615 Sermersheim, et al. Expires February 10, 2010 [Page 11]
617 Internet-Draft Password Policy for LDAP Directories August 2009
620 5. Schema used for Password Policy
622 The schema elements defined here fall into two general categories. A
623 password policy object class is defined which contains a set of
624 administrative password policy attributes, and a set of operational
625 attributes are defined that hold general password policy state
626 information for each user.
628 5.1. The pwdPolicy Object Class
630 This object class contains the attributes defining a password policy
631 in effect for a set of users. Section 10 describes the
632 administration of this object, and the relationship between it and
635 ( 1.3.6.1.4.1.42.2.27.8.2.1
639 MUST ( pwdAttribute )
640 MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
641 pwdMinLength $ pwdMaxLength $ pwdExpireWarning $
642 pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
643 pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
644 pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
645 pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )
647 5.2. Attribute Types used in the pwdPolicy ObjectClass
649 Following are the attribute types used by the pwdPolicy object class.
653 This holds the name of the attribute to which the password policy is
654 applied. For example, the password policy may be applied to the
655 userPassword attribute.
657 ( 1.3.6.1.4.1.42.2.27.8.1.1
659 EQUALITY objectIdentifierMatch
660 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
664 This attribute holds the number of seconds that must elapse between
665 modifications to the password. If this attribute is not present, 0
671 Sermersheim, et al. Expires February 10, 2010 [Page 12]
673 Internet-Draft Password Policy for LDAP Directories August 2009
676 ( 1.3.6.1.4.1.42.2.27.8.1.2
678 EQUALITY integerMatch
679 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
684 This attribute holds the number of seconds after which a modified
685 password will expire.
687 If this attribute is not present, or if the value is 0 the password
688 does not expire. If not 0, the value must be greater than or equal
689 to the value of the pwdMinAge.
691 ( 1.3.6.1.4.1.42.2.27.8.1.3
693 EQUALITY integerMatch
694 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
699 This attribute specifies the maximum number of used passwords stored
700 in the pwdHistory attribute.
702 If this attribute is not present, or if the value is 0, used
703 passwords are not stored in the pwdHistory attribute and thus may be
706 ( 1.3.6.1.4.1.42.2.27.8.1.4
708 EQUALITY integerMatch
709 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
712 5.2.5. pwdCheckQuality
714 {TODO: Consider changing the syntax to OID. Each OID will list a
715 quality rule (like min len, # of special characters, etc). These
716 rules can be specified outside this document.}
718 {TODO: Note that even though this is meant to be a check that happens
719 during password modification, it may also be allowed to happen during
720 authN. This is useful for situations where the password is encrypted
721 when modified, but decrypted when used to authN.}
723 This attribute indicates how the password quality will be verified
727 Sermersheim, et al. Expires February 10, 2010 [Page 13]
729 Internet-Draft Password Policy for LDAP Directories August 2009
732 while being modified or added. If this attribute is not present, or
733 if the value is '0', quality checking will not be enforced. A value
734 of '1' indicates that the server will check the quality, and if the
735 server is unable to check it (due to a hashed password or other
736 reasons) it will be accepted. A value of '2' indicates that the
737 server will check the quality, and if the server is unable to verify
738 it, it will return an error refusing the password.
740 ( 1.3.6.1.4.1.42.2.27.8.1.5
741 NAME 'pwdCheckQuality'
742 EQUALITY integerMatch
743 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
748 When quality checking is enabled, this attribute holds the minimum
749 number of characters that must be used in a password. If this
750 attribute is not present, no minimum password length will be
751 enforced. If the server is unable to check the length (due to a
752 hashed password or otherwise), the server will, depending on the
753 value of the pwdCheckQuality attribute, either accept the password
754 without checking it ('0' or '1') or refuse it ('2').
756 ( 1.3.6.1.4.1.42.2.27.8.1.6
758 EQUALITY integerMatch
759 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
764 When quality checking is enabled, this attribute holds the maximum
765 number of characters that may be used in a password. If this
766 attribute is not present, no maximum password length will be
767 enforced. If the server is unable to check the length (due to a
768 hashed password or otherwise), the server will, depending on the
769 value of the pwdCheckQuality attribute, either accept the password
770 without checking it ('0' or '1') or refuse it ('2').
772 ( 1.3.6.1.4.1.42.2.27.8.1.31
774 EQUALITY integerMatch
775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
783 Sermersheim, et al. Expires February 10, 2010 [Page 14]
785 Internet-Draft Password Policy for LDAP Directories August 2009
788 5.2.8. pwdExpireWarning
790 This attribute specifies the maximum number of seconds before a
791 password is due to expire that expiration warning messages will be
792 returned to an authenticating user.
794 If this attribute is not present, or if the value is 0 no warnings
795 will be returned. If not 0, the value must be smaller than the value
796 of the pwdMaxAge attribute.
798 ( 1.3.6.1.4.1.42.2.27.8.1.7
799 NAME 'pwdExpireWarning'
800 EQUALITY integerMatch
801 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
804 5.2.9. pwdGraceAuthNLimit
806 This attribute specifies the number of times an expired password can
807 be used to authenticate. If this attribute is not present or if the
808 value is 0, authentication will fail.
810 ( 1.3.6.1.4.1.42.2.27.8.1.8
811 NAME 'pwdGraceAuthNLimit'
812 EQUALITY integerMatch
813 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
816 5.2.10. pwdGraceExpiry
818 This attribute specifies the number of seconds the grace
819 authentications are valid. If this attribute is not present or if
820 the value is 0, there is no time limit on the grace authentications.
822 ( 1.3.6.1.4.1.42.2.27.8.1.30
823 NAME 'pwdGraceExpire'
824 EQUALITY integerMatch
825 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
830 This attribute indicates, when its value is "TRUE", that the password
831 may not be used to authenticate after a specified number of
832 consecutive failed bind attempts. The maximum number of consecutive
833 failed bind attempts is specified in pwdMaxFailure.
835 If this attribute is not present, or if the value is "FALSE", the
839 Sermersheim, et al. Expires February 10, 2010 [Page 15]
841 Internet-Draft Password Policy for LDAP Directories August 2009
844 password may be used to authenticate when the number of failed bind
845 attempts has been reached.
847 ( 1.3.6.1.4.1.42.2.27.8.1.9
849 EQUALITY booleanMatch
850 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
853 5.2.12. pwdLockoutDuration
855 This attribute holds the number of seconds that the password cannot
856 be used to authenticate due to too many failed bind attempts. If
857 this attribute is not present, or if the value is 0 the password
858 cannot be used to authenticate until reset by a password
861 ( 1.3.6.1.4.1.42.2.27.8.1.10
862 NAME 'pwdLockoutDuration'
863 EQUALITY integerMatch
864 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
867 5.2.13. pwdMaxFailure
869 This attribute specifies the number of consecutive failed bind
870 attempts after which the password may not be used to authenticate.
871 If this attribute is not present, or if the value is 0, this policy
872 is not checked, and the value of pwdLockout will be ignored.
874 ( 1.3.6.1.4.1.42.2.27.8.1.11
876 EQUALITY integerMatch
877 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
880 5.2.14. pwdFailureCountInterval
882 This attribute holds the number of seconds after which the password
883 failures are purged from the failure counter, even though no
884 successful authentication occurred.
886 If this attribute is not present, or if its value is 0, the failure
887 counter is only reset by a successful authentication.
895 Sermersheim, et al. Expires February 10, 2010 [Page 16]
897 Internet-Draft Password Policy for LDAP Directories August 2009
900 ( 1.3.6.1.4.1.42.2.27.8.1.12
901 NAME 'pwdFailureCountInterval'
902 EQUALITY integerMatch
903 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
906 5.2.15. pwdMustChange
908 This attribute specifies with a value of "TRUE" that users must
909 change their passwords when they first bind to the directory after a
910 password is set or reset by a password administrator. If this
911 attribute is not present, or if the value is "FALSE", users are not
912 required to change their password upon binding after the password
913 administrator sets or resets the password. This attribute is not set
914 due to any actions specified by this document, it is typically set by
915 a password administrator after resetting a user's password.
917 ( 1.3.6.1.4.1.42.2.27.8.1.13
919 EQUALITY booleanMatch
920 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
923 5.2.16. pwdAllowUserChange
925 This attribute indicates whether users can change their own
926 passwords, although the change operation is still subject to access
927 control. If this attribute is not present, a value of "TRUE" is
928 assumed. This attribute is intended to be used in the absence of an
929 access control mechanism.
931 ( 1.3.6.1.4.1.42.2.27.8.1.14
932 NAME 'pwdAllowUserChange'
933 EQUALITY booleanMatch
934 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
937 5.2.17. pwdSafeModify
939 This attribute specifies whether or not the existing password must be
940 sent along with the new password when being changed. If this
941 attribute is not present, a "FALSE" value is assumed.
943 ( 1.3.6.1.4.1.42.2.27.8.1.15
945 EQUALITY booleanMatch
946 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
951 Sermersheim, et al. Expires February 10, 2010 [Page 17]
953 Internet-Draft Password Policy for LDAP Directories August 2009
958 This attribute specifies the number of seconds to delay responding to
959 the first failed authentication attempt. If this attribute is not
960 set or is 0, no delays will be used. pwdMaxDelay must also be
961 specified if pwdMinDelay is set.
963 ( 1.3.6.1.4.1.42.2.27.8.1.24
965 EQUALITY integerMatch
966 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
971 This attribute specifies the maximum number of seconds to delay when
972 responding to a failed authentication attempt. The time specified in
973 pwdMinDelay is used as the starting time and is then doubled on each
974 failure until the delay time is greater than or equal to pwdMaxDelay
975 (or a successful authentication occurs, which resets the failure
976 counter). pwdMinDelay must be specified if pwdMaxDelay is set.
978 ( 1.3.6.1.4.1.42.2.27.8.1.25
980 EQUALITY integerMatch
981 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
986 This attribute specifies the number of seconds an account may remain
987 unused before it becomes locked. If this attribute is not set or is
988 0, no check is performed.
990 ( 1.3.6.1.4.1.42.2.27.8.1.26
992 EQUALITY integerMatch
993 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
996 5.3. Attribute Types for Password Policy State Information
998 Password policy state information must be maintained for each user.
999 The information is located in each user entry as a set of operational
1000 attributes. These operational attributes are: pwdChangedTime,
1001 pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
1002 pwdReset, pwdPolicySubEntry, pwdStartTime, pwdEndTime,
1007 Sermersheim, et al. Expires February 10, 2010 [Page 18]
1009 Internet-Draft Password Policy for LDAP Directories August 2009
1012 5.3.1. Password Policy State Attribute Option
1014 Since the password policy could apply to several attributes used to
1015 store passwords, each of the above operational attributes must have
1016 an option to specify which pwdAttribute it applies to. The password
1017 policy option is defined as the following:
1019 pwd-<passwordAttribute>
1021 where passwordAttribute a string following the OID syntax
1022 (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
1023 (short name) MUST be used.
1025 For example, if the pwdPolicy object has for pwdAttribute
1026 "userPassword" then the pwdChangedTime operational attribute, in a
1027 user entry, will be:
1029 pwdChangedTime;pwd-userPassword: 20000103121520Z
1031 This attribute option follows sub-typing semantics. If a client
1032 requests a password policy state attribute to be returned in a search
1033 operation, and does not specify an option, all subtypes of that
1034 policy state attribute are returned.
1036 5.3.2. pwdChangedTime
1038 This attribute specifies the last time the entry's password was
1039 changed. This is used by the password expiration policy. If this
1040 attribute does not exist, the password will never expire.
1042 ( 1.3.6.1.4.1.42.2.27.8.1.16
1043 NAME 'pwdChangedTime'
1044 DESC 'The time the password was last changed'
1045 EQUALITY generalizedTimeMatch
1046 ORDERING generalizedTimeOrderingMatch
1047 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1049 NO-USER-MODIFICATION
1050 USAGE directoryOperation )
1052 5.3.3. pwdAccountLockedTime
1054 This attribute holds the time that the user's account was locked. A
1055 locked account means that the password may no longer be used to
1056 authenticate. A 000001010000Z value means that the account has been
1057 locked permanently, and that only a password administrator can unlock
1063 Sermersheim, et al. Expires February 10, 2010 [Page 19]
1065 Internet-Draft Password Policy for LDAP Directories August 2009
1068 ( 1.3.6.1.4.1.42.2.27.8.1.17
1069 NAME 'pwdAccountLockedTime'
1070 DESC 'The time an user account was locked'
1071 EQUALITY generalizedTimeMatch
1072 ORDERING generalizedTimeOrderingMatch
1073 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1075 NO-USER-MODIFICATION
1076 USAGE directoryOperation )
1078 5.3.4. pwdFailureTime
1080 This attribute holds the timestamps of the consecutive authentication
1083 ( 1.3.6.1.4.1.42.2.27.8.1.19
1084 NAME 'pwdFailureTime'
1085 DESC 'The timestamps of the last consecutive authentication
1087 EQUALITY generalizedTimeMatch
1088 ORDERING generalizedTimeOrderingMatch
1089 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1090 NO-USER-MODIFICATION
1091 USAGE directoryOperation )
1095 This attribute holds a history of previously used passwords. Values
1096 of this attribute are transmitted in string format as given by the
1099 pwdHistory = time "#" syntaxOID "#" length "#" data
1101 time = GeneralizedTime
1103 syntaxOID = numericoid ; the string representation of the
1104 ; dotted-decimal OID that defines the
1105 ; syntax used to store the password.
1107 length = number ; the number of octets in data.
1109 data = <octets representing the password in the format
1110 specified by syntaxOID>.
1112 GeneralizedTime is specified in 3.3.13 of [RFC4517]. numericoid and
1113 number are specified in 1.4 of [RFC4512].
1115 This format allows the server to store, and transmit a history of
1119 Sermersheim, et al. Expires February 10, 2010 [Page 20]
1121 Internet-Draft Password Policy for LDAP Directories August 2009
1124 passwords that have been used. In order for equality matching to
1125 function properly, the time field needs to adhere to a consistent
1126 format. For this purpose, the time field MUST be in GMT format.
1128 ( 1.3.6.1.4.1.42.2.27.8.1.20
1130 DESC 'The history of user s passwords'
1131 EQUALITY octetStringMatch
1132 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
1133 NO-USER-MODIFICATION
1134 USAGE directoryOperation )
1136 5.3.6. pwdGraceUseTime
1138 This attribute holds the timestamps of grace authentications after a
1139 password has expired.
1141 ( 1.3.6.1.4.1.42.2.27.8.1.21
1142 NAME 'pwdGraceUseTime'
1143 DESC 'The timestamps of the grace authentication after the
1144 password has expired'
1145 EQUALITY generalizedTimeMatch
1146 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1147 NO-USER-MODIFICATION
1148 USAGE directoryOperation )
1152 This attribute holds a flag to indicate (when TRUE) that the password
1153 has been updated by the password administrator and must be changed by
1156 ( 1.3.6.1.4.1.42.2.27.8.1.22
1158 DESC 'The indication that the password has been reset'
1159 EQUALITY booleanMatch
1160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1162 USAGE directoryOperation )
1164 5.3.8. pwdPolicySubentry
1166 This attribute points to the pwdPolicy subentry in effect for this
1175 Sermersheim, et al. Expires February 10, 2010 [Page 21]
1177 Internet-Draft Password Policy for LDAP Directories August 2009
1180 ( 1.3.6.1.4.1.42.2.27.8.1.23
1181 NAME 'pwdPolicySubentry'
1182 DESC 'The pwdPolicy subentry in effect for this object'
1183 EQUALITY distinguishedNameMatch
1184 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1186 NO-USER-MODIFICATION
1187 USAGE directoryOperation )
1191 This attribute specifies the time the entry's password becomes valid
1192 for authentication. Authentication attempts made before this time
1193 will fail. If this attribute does not exist, then no restriction
1196 ( 1.3.6.1.4.1.42.2.27.8.1.27
1198 DESC 'The time the password becomes enabled'
1199 EQUALITY generalizedTimeMatch
1200 ORDERING generalizedTimeOrderingMatch
1201 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1203 NO-USER-MODIFICATION
1204 USAGE directoryOperation )
1208 This attribute specifies the time the entry's password becomes
1209 invalid for authentication. Authentication attempts made after this
1210 time will fail, regardless of expiration or grace settings. If this
1211 attribute does not exist, then this restriction does not apply.
1213 ( 1.3.6.1.4.1.42.2.27.8.1.28
1215 DESC 'The time the password becomes disabled'
1216 EQUALITY generalizedTimeMatch
1217 ORDERING generalizedTimeOrderingMatch
1218 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1220 NO-USER-MODIFICATION
1221 USAGE directoryOperation )
1223 Note that pwdStartTime may be set to a time greater than or equal to
1224 pwdEndTime; this simply disables the account.
1231 Sermersheim, et al. Expires February 10, 2010 [Page 22]
1233 Internet-Draft Password Policy for LDAP Directories August 2009
1236 5.3.11. pwdLastSuccess
1238 This attribute holds the timestamp of the last successful
1241 ( 1.3.6.1.4.1.42.2.27.8.1.29
1242 NAME 'pwdLastSuccess'
1243 DESC 'The timestamp of the last successful authentication'
1244 EQUALITY generalizedTimeMatch
1245 ORDERING generalizedTimeOrderingMatch
1246 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1248 NO-USER-MODIFICATION
1249 USAGE directoryOperation )
1287 Sermersheim, et al. Expires February 10, 2010 [Page 23]
1289 Internet-Draft Password Policy for LDAP Directories August 2009
1292 6. Controls used for Password Policy
1294 This section details the controls used while enforcing password
1295 policy. A request control is defined that is sent by a client with a
1296 request operation in order to elicit a response control. The
1297 response control contains various warnings and errors associated with
1300 {TODO: add a note about advertisement and discovery}
1302 6.1. Request Control
1304 This control MAY be sent with any LDAP request message in order to
1305 convey to the server that this client is aware of, and can process
1306 the response control described in this document. When a server
1307 receives this control, it will return the response control when
1308 appropriate and with the proper data.
1310 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
1311 be TRUE or FALSE. There is no controlValue.
1313 6.2. Response Control
1315 If the client has sent a passwordPolicyRequest control, the server
1316 (when solicited by the inclusion of the request control) sends this
1317 control with the following operation responses: bindResponse,
1318 modifyResponse, addResponse, compareResponse and possibly
1319 extendedResponse, to inform of various conditions, and MAY be sent
1320 with other operations (in the case of the changeAfterReset error).
1321 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
1322 the BER encoding of the following type:
1324 PasswordPolicyResponseValue ::= SEQUENCE {
1325 warning [0] CHOICE {
1326 timeBeforeExpiration [0] INTEGER (0 .. maxInt),
1327 graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
1328 error [1] ENUMERATED {
1329 passwordExpired (0),
1331 changeAfterReset (2),
1332 passwordModNotAllowed (3),
1333 mustSupplyOldPassword (4),
1334 insufficientPasswordQuality (5),
1335 passwordTooShort (6),
1336 passwordTooYoung (7),
1337 passwordInHistory (8) } OPTIONAL }
1339 The timeBeforeExpiration warning specifies the number of seconds
1343 Sermersheim, et al. Expires February 10, 2010 [Page 24]
1345 Internet-Draft Password Policy for LDAP Directories August 2009
1348 before a password will expire. The graceAuthNsRemaining warning
1349 specifies the remaining number of times a user will be allowed to
1350 authenticate with an expired password. The passwordExpired error
1351 signifies that the password has expired and must be reset. The
1352 changeAfterReset error signifies that the password must be changed
1353 before the user will be allowed to perform any operation other than
1354 bind and modify. The passwordModNotAllowed error is set when a user
1355 is restricted from changing her password. The
1356 insufficientPasswordQuality error is set when a password doesn't pass
1357 quality checking. The passwordTooYoung error is set if the age of
1358 the password to be modified is not yet old enough.
1360 Typically, only either a warning or an error will be encoded though
1361 there may be exceptions. For example, if the user is required to
1362 change a password after the password administrator set it, and the
1363 password will expire in a short amount of time, the control may
1364 include the timeBeforeExpiration warning and the changeAfterReset
1399 Sermersheim, et al. Expires February 10, 2010 [Page 25]
1401 Internet-Draft Password Policy for LDAP Directories August 2009
1404 7. Policy Decision Points
1406 Following are a number of procedures used to make policy decisions.
1407 These procedures are typically performed by the server while
1408 processing an operation.
1410 The following sections contain detailed instructions that refer to
1411 attributes of the pwdPolicy object class. When doing so, the
1412 attribute of the pwdPolicy object that governs the entry being
1413 discussed is implied.
1415 7.1. Locked Account Check
1417 A status of true is returned to indicate that the account is locked
1418 if any of these conditions are met:
1420 o The value of the pwdAccountLockedTime attribute is 000001010000Z.
1422 o The current time is less than the value of the pwdStartTime
1425 o The current time is greater than or equal to the value of the
1426 pwdEndTime attribute.
1428 o The current time is greater than or equal to the value of the
1429 pwdLastSuccess attribute added to the value of the pwdMaxIdle
1432 o The current time is less than the value of the
1433 pwdAccountLockedTime attribute added to the value of the
1436 Otherwise a status of false is returned.
1438 7.2. Password Must be Changed Now Check
1440 A status of true is returned to indicate that the password must be
1441 changed if all of these conditions are met:
1443 o The pwdMustChange attribute is set to TRUE.
1445 o The pwdReset attribute is set to TRUE.
1447 Otherwise a status of false is returned.
1455 Sermersheim, et al. Expires February 10, 2010 [Page 26]
1457 Internet-Draft Password Policy for LDAP Directories August 2009
1460 7.3. Password Expiration Check
1462 A status of true is returned indicating that the password has expired
1463 if the current time minus the value of pwdChangedTime is greater than
1464 the value of the pwdMaxAge.
1466 Otherwise, a status of false is returned.
1468 7.4. Remaining Grace AuthN Check
1470 If the pwdGraceUseTime attribute is present, the number of values in
1471 that attribute subtracted from the value of pwdGraceAuthNLimit is
1472 returned. Otherwise zero is returned. A positive result specifies
1473 the number of remaining grace authentications.
1475 7.5. Time Before Expiration Check
1477 If the pwdExpireWarning attribute is not present a zero status is
1478 returned. Otherwise the following steps are followed:
1480 Subtract the time stored in pwdChangedTime from the current time to
1481 arrive at the password's age. If the password's age is greater than
1482 than the value of the pwdMaxAge attribute, a zero status is returned.
1483 Subtract the value of the pwdExpireWarning attribute from the value
1484 of the pwdMaxAge attribute to arrive at the warning age. If the
1485 password's age is equal to or greater than the warning age, the value
1486 of pwdMaxAge minus the password's age is returned.
1488 7.6. Intruder Lockout Check
1490 A status of true indicating that an intruder has been detected is
1491 returned if the following conditions are met:
1493 o The pwdLockout attribute is TRUE.
1495 o The number of values in the pwdFailureTime attribute that are
1496 younger than pwdFailureCountInterval is greater or equal to the
1497 pwdMaxFailure attribute.
1499 Otherwise a status of false is returned.
1501 While performing this check, values of pwdFailureTime that are old by
1502 more than pwdFailureCountInterval are purged and not counted.
1504 7.7. Intruder Delay Check
1506 If the pwdMinDelay attribute is 0 or not set, zero is returned.
1511 Sermersheim, et al. Expires February 10, 2010 [Page 27]
1513 Internet-Draft Password Policy for LDAP Directories August 2009
1516 Otherwise, a delay time is computed based on the number of values in
1517 the pwdFailureTime attribute. If the computed value is greater than
1518 the pwdMaxDelay attribute, the pwdMaxDelay value is returned.
1520 While performing this check, values of pwdFailureTime that are old by
1521 more than pwdFailureCountInterval are purged and not counted.
1523 7.8. Password Too Young Check
1525 If the Section 7.2 check returned true then this check will return
1526 false, to allow the password to be changed.
1528 A status of true indicating that not enough time has passed since the
1529 password was last updated is returned if:
1531 o The value of pwdMinAge is non-zero and pwdChangedTime is present.
1533 o The value of pwdMinAge is greater than the current time minus the
1534 value of pwdChangedTime.
1536 Otherwise a false status is returned.
1567 Sermersheim, et al. Expires February 10, 2010 [Page 28]
1569 Internet-Draft Password Policy for LDAP Directories August 2009
1572 8. Server Policy Enforcement Points
1574 The server SHOULD enforce that the password attribute subject to a
1575 password policy as defined in this document, contains one and only
1578 Note: The case where a single password value is stored in multiple
1579 formats simultaneously is still considered to be only one password
1582 The scenarios in the following operations assume that the client has
1583 attached a passwordPolicyRequest control to the request message of
1584 the operation. In the event that the passwordPolicyRequest control
1585 was not sent, no passwordPolicyResponse control is returned. All
1586 other instructions remain the same.
1588 For successfully completed operations, unless otherwise stated, no
1589 passwordPolicyResponse control is returned.
1591 8.1. Password-based Authentication
1593 This section contains the policy enforcement rules and policy data
1594 updates used while validating a password. Operations that validate
1595 passwords include, but are not limited to, the Bind operation where
1596 the simple choice specifies a password, and the Compare operation
1597 where the attribute being compared holds a password. Note that while
1598 the Compare operation does not authenticate a user to the LDAP
1599 server, it may be used by an external application for purposes of
1602 8.1.1. Fail if the account is locked
1604 If the account is locked as specified in Section 7.1, the server
1605 fails the operation with an appropriate resultCode (i.e.
1606 invalidCredentials (49) in the case of a bind operation, compareFalse
1607 (5) in the case of a compare operation, etc.). The server MAY set
1608 the error: accountLocked (1) in the passwordPolicyResponse in the
1609 controls field of the message.
1611 8.1.2. Validated Password Procedures
1613 If the validation operation indicates that the password validated,
1614 these procedures are followed in order:
1616 8.1.2.1. Policy state updates
1618 Delete the pwdFailureTime and pwdAccountLockedTime attributes.
1623 Sermersheim, et al. Expires February 10, 2010 [Page 29]
1625 Internet-Draft Password Policy for LDAP Directories August 2009
1628 Set the value of the pwdLastSuccess attribute to the current time.
1630 Note: setting pwdLastSuccess is optional, but it is required if the
1631 policy has pwdMaxIdle defined.
1633 8.1.2.2. Password must be changed now
1635 If the decision in Section 7.2 returns true, the server sends to the
1636 client a response with an appropriate successful resultCode (i.e.
1637 success (0), compareTrue (6), etc.), and includes the
1638 passwordPolicyResponse in the controls field of the bindResponse
1639 message with the warning: changeAfterReset specified.
1641 For bind, the server MUST then disallow all operations issued by this
1642 user except modify password, bind, unbind, abandon and StartTLS
1645 8.1.2.3. Expired password
1647 If the password has expired as per Section 7.3, the server either
1648 returns a success or failure based on the state of grace
1651 8.1.2.3.1. Remaining Grace Authentications
1653 If there are remaining grace authentications as per Section 7.4, the
1654 server adds a new value with the current time in pwdGraceUseTime.
1655 Then it sends to the client a response with an appropriate successful
1656 resultCode (i.e. success (0), compareTrue (6), etc.), and includes
1657 the passwordPolicyResponse in the controls field of the response
1658 message with the warning: graceAuthNsRemaining choice set to the
1659 number of grace authentications left.
1661 Implementor's note: The system time of the host machine may be more
1662 granular than is needed to ensure unique values of this attribute.
1663 It is recommended that a mechanism is used to ensure unique
1664 generalized time values. The fractional seconds field may be used
1667 8.1.2.3.2. No Remaining Grace Authentications
1669 If there are no remaining grace authentications, the server fails the
1670 operation with an appropriate resultCode (invalidCredentials (49),
1671 compareFalse (5), etc.), and includes the passwordPolicyResponse in
1672 the controls field of the bindResponse message with the error:
1673 passwordExpired (0) set.
1679 Sermersheim, et al. Expires February 10, 2010 [Page 30]
1681 Internet-Draft Password Policy for LDAP Directories August 2009
1684 8.1.2.4. Expiration Warning
1686 If the result of Section 7.5 is a positive number, the server sends
1687 to the client a response with an appropriate successful resultCode
1688 (i.e. success (0), compareTrue (6), etc.), and includes the
1689 passwordPolicyResponse in the controls field of the bindResponse
1690 message with the warning: timeBeforeExiration set to the value as
1691 described above. Otherwise, the server sends a successful response,
1692 and omits the passwordPolicyResponse.
1694 8.1.3. AuthN Failed Procedures
1696 If the authentication process indicates that the password failed
1697 validation due to invalid credentials, these procedures are followed:
1699 8.1.3.1. Policy state update
1701 Add the current time as a value of the pwdFailureTime attribute.
1703 Implementor's note: The system time of the host machine may be more
1704 granular than is needed to ensure unique values of this attribute.
1705 It is recommended that a mechanism is used to ensure unique
1706 generalized time values. The fractional seconds field may be used
1709 8.1.3.2. Handle Intruder Detection
1711 If the check in Section 7.6 returns a true state, the server locks
1712 the account by setting the value of the pwdAccountLockedTime
1713 attribute to the current time. After locking the account, the server
1714 fails the operation with an appropriate resultCode
1715 (invalidCredentials (49), compareFalse (5), etc.), and includes the
1716 passwordPolicyResponse in the controls field of the message with the
1717 error: accountLocked (1).
1719 If the check in Section 7.7 returns a non-zero value, the server
1720 waits that number of seconds before sending the authentication
1721 response back to the client.
1723 8.2. Password Update Operations
1725 Because the password is stored in an attribute, various operations
1726 (like add and modify) may be used to create or update a password.
1727 But some alternate mechanisms have been defined or may be defined,
1728 such as the LDAP Password Modify Extended Operation [RFC3062].
1730 While processing a password update, the server performs the following
1735 Sermersheim, et al. Expires February 10, 2010 [Page 31]
1737 Internet-Draft Password Policy for LDAP Directories August 2009
1740 8.2.1. Safe Modification
1742 If pwdSafeModify is set to TRUE and if there is an existing password
1743 value, the server ensures that the password update operation includes
1744 the user's existing password.
1746 When the LDAP modify operation is used to modify a password, this is
1747 done by specifying both a delete action and an add or replace action,
1748 where the delete action specifies the existing password, and the add
1749 or replace action specifies the new password. Other password update
1750 operations SHOULD employ a similar mechanism. Otherwise this policy
1753 If the existing password is not specified, the server does not
1754 process the operation and sends the appropriate response message to
1755 the client with the resultCode: insufficientAccessRights (50), and
1756 includes the passwordPolicyResponse in the controls field of the
1757 response message with the error: mustSupplyOldPassword (4).
1759 8.2.2. Change After Reset
1761 If the decision in Section 7.2 returns true, the server ensures that
1762 the password update operation contains no modifications other than
1763 the modification of the password attribute. If other modifications
1764 exist, the server sends a response message to the client with the
1765 resultCode: insufficientAccessRights (50), and includes the
1766 passwordPolicyResponse in the controls field of the response message
1767 with the error: changeAfterReset (2).
1771 Check to see whether the bound identity has sufficient rights to
1772 update the password. If the bound identity is a user changing its
1773 own password, this MAY be done by checking the pwdAllowUserChange
1774 attribute or using an access control mechanism. The determination of
1775 this is implementation specific. If the user is not allowed to
1776 update her password, the server sends a response message to the
1777 client with the resultCode: insufficientAccessRights (50), and
1778 includes the passwordPolicyResponse in the controls field of the
1779 response message with the error: passwordModNotAllowed (3).
1781 8.2.4. Too Early to Update
1783 If the check in Section 7.8 results in a true status The server sends
1784 a response message to the client with the resultCode:
1785 constraintViolation (19), and includes the passwordPolicyResponse in
1786 the controls field of the response message with the error:
1787 passwordTooYoung (7).
1791 Sermersheim, et al. Expires February 10, 2010 [Page 32]
1793 Internet-Draft Password Policy for LDAP Directories August 2009
1796 8.2.5. Password Quality
1798 Check the value of the pwdCheckQuality attribute. If the value is
1799 non-zero, the server:
1801 o Ensure that the password meets the quality criteria enforced by
1802 the server. This enforcement is implementation specific. If the
1803 server is unable to check the quality (due to a hashed password or
1804 otherwise), the value of pwdCheckQuality is evaluated. If the
1805 value is 1, operation continues. If the value is 2, the server
1806 sends a response message to the client with the resultCode:
1807 constraintViolation (19), and includes the passwordPolicyResponse
1808 in the controls field of the response message with the error:
1809 insufficientPasswordQuality (5). If the server is able to check
1810 the password quality, and the check fails, the server sends a
1811 response message to the client with the resultCode:
1812 constraintViolation (19), and includes the passwordPolicyResponse
1813 in the controls field of the response message with the error:
1814 insufficientPasswordQuality (5).
1816 o checks the value of the pwdMinLength attribute. If the value is
1817 non-zero, it ensures that the new password is of at least the
1818 minimum length. If the server is unable to check the length (due
1819 to a hashed password or otherwise), the value of pwdCheckQuality
1820 is evaluated. If the value is 1, operation continues. If the
1821 value is 2, the server sends a response message to the client with
1822 the resultCode: constraintViolation (19), and includes the
1823 passwordPolicyResponse in the controls field of the response
1824 message with the error: passwordTooShort (6). If the server is
1825 able to check the password length, and the check fails, the server
1826 sends a response message to the client with the resultCode:
1827 constraintViolation (19), and includes the passwordPolicyResponse
1828 in the controls field of the response message with the error:
1829 passwordTooShort (6).
1831 8.2.6. Invalid Reuse
1833 If pwdInHistory is present and its value is non-zero, the server
1834 checks whether this password exists in the entry's pwdHistory
1835 attribute or in the current password attribute. If the password does
1836 exist in the pwdHistory attribute or in the current password
1837 attribute, the server sends a response message to the client with the
1838 resultCode: constraintViolation (19), and includes the
1839 passwordPolicyResponse in the controls field of the response message
1840 with the error: passwordInHistory (8).
1847 Sermersheim, et al. Expires February 10, 2010 [Page 33]
1849 Internet-Draft Password Policy for LDAP Directories August 2009
1852 8.2.7. Policy State Updates
1854 If the steps have completed without causing an error condition, the
1855 server performs the following steps in order to update the necessary
1856 password policy state attributes:
1858 If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
1859 updates the pwdChangedTime attribute on the entry to the current
1862 If the value of pwdInHistory is non-zero, the server adds the
1863 previous password (if one existed) to the pwdHistory attribute. If
1864 the number of attributes held in the pwdHistory attribute exceeds the
1865 value of pwdInHistory, the server removes the oldest excess
1868 If the value the pwdMustChange is TRUE and the modification is
1869 performed by a password administrator, then the pwdReset attribute is
1870 set to TRUE. Otherwise, the pwdReset is removed from the user's
1873 The pwdFailureTime and pwdGraceUseTime attributes is removed from the
1874 user's entry if they exist.
1876 8.3. Other Operations
1878 For operations other than bind, password update, unbind, abandon or
1879 StartTLS, if the decision in Section 7.2 returns true, the server
1880 sends a response message to the client with the resultCode:
1881 insufficientAccessRights (50), and includes the
1882 passwordPolicyResponse in the controls field of the response message
1883 with the error: changeAfterReset (2).
1903 Sermersheim, et al. Expires February 10, 2010 [Page 34]
1905 Internet-Draft Password Policy for LDAP Directories August 2009
1908 9. Client Policy Enforcement Points
1910 These sections illustrate possible scenarios for each LDAP operation
1911 and define the types of responses that identify those scenarios.
1913 The scenarios in the following operations assume that the client
1914 attached a passwordPolicyRequest control to the request message of
1915 the operation, and thus may receive a passwordPolicyResponse control
1916 in the response message. In the event that the passwordPolicyRequest
1917 control was not sent, no passwordPolicyResponse control is returned.
1918 All other instructions remain the same.
1922 For every bind response received, the client checks the resultCode of
1923 the bindResponse and checks for a passwordPolicyResponse control to
1924 determine if any of the following conditions are true and MAY prompt
1925 the user accordingly.
1927 o bindResponse.resultCode = insufficientAccessRights (50),
1928 passwordPolicyResponse.error = accountLocked (1): The password
1929 failure limit has been reached and the account is locked. The
1930 user needs to retry later or contact the password administrator to
1933 o bindResponse.resultCode = success (0),
1934 passwordPolicyResponse.error = changeAfterReset (2): The user is
1935 binding for the first time after the password administrator set
1936 the password. In this scenario, the client SHOULD prompt the user
1937 to change his password immediately.
1939 o bindResponse.resultCode = success (0),
1940 passwordPolicyResponse.warning = graceAuthNsRemaining: The
1941 password has expired but there are remaining grace
1942 authentications. The user needs to change it.
1944 o bindResponse.resultCode = invalidCredentials (49),
1945 passwordPolicyResponse.error = passwordExpired (0): The password
1946 has expired and there are no more grace authentications. The user
1947 contacts the password administrator in order to have its password
1950 o bindResponse.resultCode = success (0),
1951 passwordPolicyResponse.warning = timeBeforeExpiration: The user's
1952 password will expire in n number of seconds.
1959 Sermersheim, et al. Expires February 10, 2010 [Page 35]
1961 Internet-Draft Password Policy for LDAP Directories August 2009
1964 9.2. Modify Operations
1966 9.2.1. Modify Request
1968 If the application or client encrypts the password prior to sending
1969 it in a password modification operation (whether done through
1970 modifyRequest or another password modification mechanism), it SHOULD
1971 check the values of the pwdMinLength, and pwdCheckQuality attributes
1972 and SHOULD enforce these policies.
1974 9.2.2. Modify Response
1976 If the modifyRequest operation was used to change the password, or if
1977 another mechanism is used --such as an extendedRequest-- the
1978 modifyResponse or other appropriate response MAY contain information
1979 pertinent to password policy. The client checks the resultCode of
1980 the response and checks for a passwordPolicyResponse control to
1981 determine if any of the following conditions are true and optionally
1982 notify the user of the condition.
1984 o pwdModResponse.resultCode = insufficientAccessRights (50),
1985 passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
1986 attempted to change her password without specifying the old
1987 password but the password policy requires this.
1989 o pwdModResponse.resultCode = insufficientAccessRights (50),
1990 passwordPolicyResponse.error = changeAfterReset (2): The user must
1991 change her password before submitting any other LDAP requests.
1993 o pwdModResponse.resultCode = insufficientAccessRights (50),
1994 passwordPolicyResponse.error = passwordModNotAllowed (3): The user
1995 doesn't have sufficient rights to change his password.
1997 o pwdModResponse.resultCode = constraintViolation (19),
1998 passwordPolicyResponse.error = passwordTooYoung (7): It is too
1999 soon after the last password modification to change the password.
2001 o pwdModResponse.resultCode = constraintViolation (19),
2002 passwordPolicyResponse.error = insufficientPasswordQuality (5):
2003 The password failed quality checking.
2005 o pwdModResponse.resultCode = constraintViolation (19),
2006 passwordPolicyResponse.error = passwordTooShort (6): The length of
2007 the password is too short.
2009 o pwdModResponse.resultCode = constraintViolation (19),
2010 passwordPolicyResponse.error = passwordInHistory (8): The password
2011 has already been used; the user must choose a different one.
2015 Sermersheim, et al. Expires February 10, 2010 [Page 36]
2017 Internet-Draft Password Policy for LDAP Directories August 2009
2022 If a password is specified in an addRequest, the client checks the
2023 resultCode of the addResponse and checks for a passwordPolicyResponse
2024 control to determine if any of the following conditions are true and
2025 may prompt the user accordingly.
2027 o addResponse.resultCode = insufficientAccessRights (50),
2028 passwordPolicyResponse.error = passwordModNotAllowed (3): The user
2029 doesn't have sufficient rights to add this password.
2031 o addResponse.resultCode = constraintViolation (19),
2032 passwordPolicyResponse.error = insufficientPasswordQuality (5):
2033 The password failed quality checking.
2035 o addResponse.resultCode = constraintViolation (19),
2036 passwordPolicyResponse.error = passwordTooShort (6): The length of
2037 the password is too short.
2039 9.4. Compare Operation
2041 When a compare operation is used to compare a password, the client
2042 checks the resultCode of the compareResponse and checks for a
2043 passwordPolicyResponse to determine if any of the following
2044 conditions are true and MAY prompt the user accordingly. These
2045 conditions assume that the result of the comparison was true.
2047 o compareResponse.resultCode = compareFalse (5),
2048 passwordPolicyResponse.error = accountLocked (1): The password
2049 failure limit has been reached and the account is locked. The
2050 user needs to retry later or contact the password administrator to
2053 o compareResponse.resultCode = compareTrue (6),
2054 passwordPolicyResponse.warning = graceAuthNsRemaining: The
2055 password has expired but there are remaining grace
2056 authentications. The user needs to change it.
2058 o compareResponse.resultCode = compareFalse (5),
2059 passwordPolicyResponse.error = passwordExpired (0): The password
2060 has expired and there are no more grace authentications. The user
2061 must contact the password administrator to reset the password.
2063 o compareResponse.resultCode = compareTrue (6),
2064 passwordPolicyResponse.warning = timeBeforeExpiration: The user's
2065 password will expire in n number of seconds.
2071 Sermersheim, et al. Expires February 10, 2010 [Page 37]
2073 Internet-Draft Password Policy for LDAP Directories August 2009
2076 9.5. Other Operations
2078 For operations other than bind, unbind, abandon or StartTLS, the
2079 client checks the result code and control to determine if any other
2082 o <Response>.resultCode = insufficientAccessRights (50),
2083 passwordPolicyResponse.error = accountLocked (1) : The password
2084 failure limit has been reached and the account is locked. The
2085 user needs to retry later or contact the password administrator to
2088 o <Response>.resultCode = insufficientAccessRights (50),
2089 passwordPolicyResponse.error = changeAfterReset (2) : The user
2090 needs to change the password immediately.
2127 Sermersheim, et al. Expires February 10, 2010 [Page 38]
2129 Internet-Draft Password Policy for LDAP Directories August 2009
2132 10. Administration of the Password Policy
2134 {TODO: Need to define an administrativeRole (need OID). Need to
2135 describe whether pwdPolicy admin areas can overlap}
2137 A password policy is defined for a particular subtree of the DIT by
2138 adding to an LDAP subentry whose immediate superior is the root of
2139 the subtree, the pwdPolicy auxiliary object class. The scope of the
2140 password policy is defined by the SubtreeSpecification attribute of
2141 the LDAP subentry as specified in [RFC3672].
2143 It is possible to define password policies for different password
2144 attributes within the same pwdPolicy entry, by specifying multiple
2145 values of the pwdAttribute. But password policies could also be in
2146 separate sub entries as long as they are contained under the same
2149 Only one policy may be in effect for a given password attribute in
2150 any entry. If multiple policies exist which overlap in the range of
2151 entries affected, the resulting behavior is undefined.
2153 Modifying the password policy MUST NOT result in any change in users'
2154 entries to which the policy applies.
2156 It SHOULD be possible to overwrite the password policy for one user
2157 by defining a new policy in a subentry of the user entry.
2159 Each object that is controlled by password policy advertises the
2160 subentry that is being used to control its policy in its
2161 pwdPolicySubentry attribute. Clients wishing to examine or manage
2162 password policy for an object may interrogate the pwdPolicySubentry
2163 for that object in order to arrive at the proper pwdPolicy subentry.
2183 Sermersheim, et al. Expires February 10, 2010 [Page 39]
2185 Internet-Draft Password Policy for LDAP Directories August 2009
2188 11. Password Policy and Replication
2190 {TODO: This section needs to be changed to highlight the pitfalls of
2191 replication, suggest some implementation choices to overcome those
2192 pitfalls, but remove prescriptive language relating to the update of
2195 The pwdPolicy object defines the password policy for a portion of the
2196 DIT and MUST be replicated on all the replicas of this subtree, as
2197 any subentry would be, in order to have a consistent policy among all
2200 The elements of the password policy that are related to the users are
2201 stored in the entry themselves as operational attributes. As these
2202 attributes are subject to modifications even on a read-only replica,
2203 replicating them must be carefully considered.
2205 The pwdChangedTime attribute MUST be replicated on all replicas, to
2206 allow expiration of the password.
2208 The pwdReset attribute MUST be replicated on all replicas, to deny
2209 access to operations other than bind and modify password.
2211 The pwdHistory attribute MUST be replicated to writable replicas. It
2212 doesn't have to be replicated to a read-only replica, since the
2213 password will never be directly modified on this server.
2215 The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
2216 attributes SHOULD be replicated to writable replicas, making the
2217 password policy global for all servers. When the user entry is
2218 replicated to a read-only replica, these attributes SHOULD NOT be
2219 replicated. This means that the number of failures, of grace
2220 authentications and the locking will take place on each replicated
2221 server. For example, the effective number of failed attempts on a
2222 user password will be N x M (where N is the number of servers and M
2223 the value of pwdMaxFailure attribute). Replicating these attributes
2224 to a read-only replica MAY reduce the number of tries globally but
2225 MAY also introduce some inconstancies in the way the password policy
2228 Note: there are some situations where global replication of these
2229 state attributes may not be desired. For example, if two clusters of
2230 replicas are geographically remote and joined by a slow network link,
2231 and their users only login from one of the two locations, it may be
2232 unnecessary to propagate all of the state changes from one cluster to
2233 the other. Servers SHOULD allow administrators to control which
2234 attributes are replicated on a case-by-case basis.
2239 Sermersheim, et al. Expires February 10, 2010 [Page 40]
2241 Internet-Draft Password Policy for LDAP Directories August 2009
2244 Servers participating in a loosely consistent multi-master
2245 replication agreement SHOULD employ a mechanism which ensures
2246 uniqueness of values when populating the attributes pwdFailureTime
2247 and pwdGraceUseTime. The method of achieving this is a local matter
2248 and may consist of using a single authoritative source for the
2249 generation of unique time values, or may consist of the use of the
2250 fractional seconds part to hold a replica identifier.
2295 Sermersheim, et al. Expires February 10, 2010 [Page 41]
2297 Internet-Draft Password Policy for LDAP Directories August 2009
2300 12. Security Considerations
2302 This document defines a set of rules to implement in an LDAP server,
2303 in order to mitigate some of the security risks associated with the
2304 use of passwords and to make it difficult for password cracking
2305 programs to break into directories.
2307 Authentication with a password MUST follow the recommendations made
2310 Modifications of passwords SHOULD only occur when the connection is
2311 protected with confidentiality and secure authentication.
2313 Access controls SHOULD be used to restrict access to the password
2314 policy attributes. The attributes defined to maintain the password
2315 policy state information SHOULD only be modifiable by the password
2316 administrator or higher authority. The pwdHistory attribute MUST be
2317 subject to the same level of access control as the attrbute holding
2320 As it is possible to define a password policy for one specific user
2321 by adding a subentry immediately under the user's entry, Access
2322 Controls SHOULD be used to restrict the use of the pwdPolicy object
2323 class or the LDAP subentry object class.
2325 When the intruder detection password policy is enforced, the LDAP
2326 directory is subject to a denial of service attack. A malicious user
2327 could deliberately lock out one specific user's account (or all of
2328 them) by sending bind requests with wrong passwords. There is no way
2329 to protect against this kind of attack. The LDAP directory server
2330 SHOULD log as much information as it can (such as client IP address)
2331 whenever an account is locked, in order to be able to identify the
2332 origin of the attack. Denying anonymous access to the LDAP directory
2333 is also a way to restrict this kind of attack. Using the login delay
2334 instead of the lockout mechanism will also help avoid this denial of
2337 Returning certain status codes (such as passwordPolicyResponse.error
2338 = accountLocked) allows a denial of service attacker to know that it
2339 has successfully denied service to an account. Servers SHOULD
2340 implement additional checks which return the same status when it is
2341 sensed that some number of failed authentication requests has occured
2342 on a single connection, or from a client address. Server
2343 implementors are encouraged to invent other checks similar to this in
2344 order to thwart this type of DoS attack.
2351 Sermersheim, et al. Expires February 10, 2010 [Page 42]
2353 Internet-Draft Password Policy for LDAP Directories August 2009
2356 13. IANA Considerations
2407 Sermersheim, et al. Expires February 10, 2010 [Page 43]
2409 Internet-Draft Password Policy for LDAP Directories August 2009
2414 This document is based in part on prior work done by Valerie Chu from
2415 Netscape Communications Corp, published as
2416 draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
2417 participated in early revisions of this document.
2463 Sermersheim, et al. Expires February 10, 2010 [Page 44]
2465 Internet-Draft Password Policy for LDAP Directories August 2009
2468 15. Normative References
2470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2471 Requirement Levels", BCP 14, RFC 2119, March 1997.
2473 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
2474 AUTHorize Extension for Simple Challenge/Response",
2475 RFC 2195, September 1997.
2477 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
2478 SASL Mechanism", RFC 2831, May 2000.
2480 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
2481 RFC 3062, February 2001.
2483 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2484 Considerations for the Lightweight Directory Access
2485 Protocol (LDAP)", RFC 3383, September 2002.
2487 [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
2488 Access Protocol (LDAP)", RFC 3672, December 2003.
2490 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
2491 Security Layer (SASL)", RFC 4422, June 2006.
2493 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
2494 (LDAP): The Protocol", RFC 4511, June 2006.
2496 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
2497 (LDAP): Directory Information Models", RFC 4512,
2500 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
2501 (LDAP): Authentication Methods and Security Mechanisms",
2502 RFC 4513, June 2006.
2504 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
2505 Syntaxes and Matching Rules", RFC 4517, June 2006.
2507 [X.680] International Telecommunications Union, "Abstract Syntax
2508 Notation One (ASN.1): Specification of basic notation",
2509 ITU-T Recommendation X.680, July 2002.
2511 [X.690] International Telecommunications Union, "Information
2512 Technology - ASN.1 encoding rules: Specification of Basic
2513 Encoding Rules (BER), Canonical Encoding Rules (CER) and
2514 Distinguished Encoding Rules (DER)", ITU-T
2515 Recommendation X.690, July 2002.
2519 Sermersheim, et al. Expires February 10, 2010 [Page 45]
2521 Internet-Draft Password Policy for LDAP Directories August 2009
2528 1800 South Novell Place
2532 Phone: +1 801 861-3088
2533 Email: jimse@novell.com
2538 180, Avenue de l'Europe
2539 Zirst de Montbonnot, Saint Ismier cedex 38334
2542 Phone: +33 476 188 212
2543 Email: ludovic.poitou@sun.com
2548 18740 Oxnard Street, Suite 313A
2549 Tarzana, California 91356
2552 Phone: +1 818 757-7087
2553 Email: hyc@symas.com
2575 Sermersheim, et al. Expires February 10, 2010 [Page 46]