2 Network Working Group J. Sermersheim
3 Internet-Draft Novell, Inc
4 Expires: April 24, 2005 L. Poitou
9 Password Policy for LDAP Directories
10 draft-behera-ldap-password-policy-08.txt
14 This document is an Internet-Draft and is subject to all provisions
15 of section 3 of RFC 3667. By submitting this Internet-Draft, each
16 author represents that any applicable patent or other IPR claims of
17 which he or she is aware have been or will be disclosed, and any of
18 which he or she become aware will be disclosed, in accordance with
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
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 April 24, 2005.
41 Copyright (C) The Internet Society (2004).
45 Password policy as described in this document is a set of rules that
46 controls how passwords are used and administered in Lightweight
47 Directory Access Protocol (LDAP) based directories. In order to
48 improve the security of LDAP directories and make it difficult for
49 password cracking programs to break into directories, it is desirable
50 to enforce a set of rules on password usage. These rules are made to
54 Sermersheim & Poitou Expires April 24, 2005 [Page 1]
56 Internet-Draft Password Policy for LDAP Directories October 2004
59 ensure that users change their passwords periodically, passwords meet
60 construction requirements, the re-use of old password is restricted,
61 and users are locked out after a certain number of failed attempts.
65 Technical discussion of this document will take place on the IETF
66 LDAP Extensions mailing list <ldapext@ietf.org>. Please send
67 editorial comments directly to the authors.
71 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 3. Application of password policy . . . . . . . . . . . . . . . . 6
74 4. Articles of password policy . . . . . . . . . . . . . . . . . 7
75 4.1 Password Usage Policy . . . . . . . . . . . . . . . . . . . . 7
76 4.2 Password Modification Policy . . . . . . . . . . . . . . . . . 7
77 4.3 Restriction of the Password Policy . . . . . . . . . . . . . . 10
78 5. Schema used for Password Policy . . . . . . . . . . . . . . . 11
79 5.1 The pwdPolicy Object Class . . . . . . . . . . . . . . . . . . 11
80 5.2 Attribute Types used in the pwdPolicy ObjectClass . . . . . . 11
81 5.3 Attribute Types for Password Policy State Information . . . . 16
82 6. Controls used for Password Policy . . . . . . . . . . . . . . 20
83 6.1 Request Control . . . . . . . . . . . . . . . . . . . . . . . 20
84 6.2 Response Control . . . . . . . . . . . . . . . . . . . . . . . 20
85 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . . 22
86 7.1 Locked Account Check . . . . . . . . . . . . . . . . . . . . . 22
87 7.2 Password Must be Changed Now Check . . . . . . . . . . . . . . 22
88 7.3 Password Expiration Check . . . . . . . . . . . . . . . . . . 22
89 7.4 Remaining Grace AuthN Check . . . . . . . . . . . . . . . . . 22
90 7.5 Time Before Expiration Check . . . . . . . . . . . . . . . . . 23
91 7.6 Intruder Detection Check . . . . . . . . . . . . . . . . . . . 23
92 7.7 Password Too Young Check . . . . . . . . . . . . . . . . . . . 23
93 8. Server Policy Enforcement Points . . . . . . . . . . . . . . . 24
94 8.1 Password-based Authentication . . . . . . . . . . . . . . . . 24
95 8.2 Password Update Operations . . . . . . . . . . . . . . . . . . 26
96 8.3 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 29
97 9. Client Policy Enforcement Points . . . . . . . . . . . . . . . 30
98 9.1 Bind Operation . . . . . . . . . . . . . . . . . . . . . . . . 30
99 9.2 Modify Operations . . . . . . . . . . . . . . . . . . . . . . 30
100 9.3 Add Operation . . . . . . . . . . . . . . . . . . . . . . . . 31
101 9.4 Compare Operation . . . . . . . . . . . . . . . . . . . . . . 32
102 9.5 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 32
103 10. Administration of the Password Policy . . . . . . . . . . . . 33
104 11. Password Policy and Replication . . . . . . . . . . . . . . . 34
105 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
106 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36
110 Sermersheim & Poitou Expires April 24, 2005 [Page 2]
112 Internet-Draft Password Policy for LDAP Directories October 2004
115 14. Normative References . . . . . . . . . . . . . . . . . . . . . 36
116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
117 Intellectual Property and Copyright Statements . . . . . . . . 38
166 Sermersheim & Poitou Expires April 24, 2005 [Page 3]
168 Internet-Draft Password Policy for LDAP Directories October 2004
173 LDAP-based directory services are currently accepted by many
174 organizations as the access protocol for directories. The ability to
175 ensure the secure read and update access to directory information
176 throughout the network is essential to the successful deployment.
177 Most LDAP implementations support many authentication schemes - the
178 most basic and widely used is the simple authentication i.e., user DN
179 and password. In this case, many LDAP servers have implemented some
180 kind of policy related to the password used to authenticate. Among
181 other things, this policy includes:
183 o Whether and when passwords expire.
184 o Whether failed bind attempts cause the account to be locked.
185 o If and how users are able to change their passwords.
187 In order to achieve greater security protection and ensure
188 interoperability in a heterogeneous environment, LDAP needs to
189 standardize on a common password policy model. This is critical to
190 the successful deployment of LDAP directories.
222 Sermersheim & Poitou Expires April 24, 2005 [Page 4]
224 Internet-Draft Password Policy for LDAP Directories October 2004
229 Imperative keywords defined in [RFC2119] are used in this document,
230 and carry the meanings described there.
232 All Basic Encoding Rules (BER) [X690] encodings follow the
233 conventions found in Section 5.1 of [RFC2251].
235 The term "password administrator" refers to a user that has
236 sufficient access control privileges to modify users' passwords. The
237 term "password policy administrator" refers to a user that has
238 sufficient access control privileges to modify the pwdPolicy object
239 defined in this document. The access control that is used to
240 determine whether an identity is a password administrator or password
241 policy administrator is beyond the scope of this document, but
242 typically implies that the password administrator has 'write'
243 privileges to the password attribute.
278 Sermersheim & Poitou Expires April 24, 2005 [Page 5]
280 Internet-Draft Password Policy for LDAP Directories October 2004
283 3. Application of password policy
285 The password policy defined in this document can be applied to any
286 attribute holding a user's password used for an authenticated LDAP
287 bind operation. In this document, the term "user" represents any
288 LDAP client application that has an identity in the directory.
290 This policy is typically applied to the userPassword attribute in the
291 case of the LDAP simple authentication method [RFC2251] or the case
292 of password based SASL [RFC2222] authentication such as CRAM-MD5
293 [RFC2195] and DIGEST-MD5 [RFC2831].
295 The policy described in this document assumes that the password
296 attribute holds a single value. No considerations are made for
297 directories or systems that allow a user to maintain multi-valued
300 Server implementations MAY institute internal policy whereby certain
301 identities (such as directory administrators) are not forced to
302 comply with any of password policy. In this case, the password for a
303 directory administrator never expires; the account is never locked,
334 Sermersheim & Poitou Expires April 24, 2005 [Page 6]
336 Internet-Draft Password Policy for LDAP Directories October 2004
339 4. Articles of password policy
341 The following sections explain in general terms each aspect of the
342 password policy defined in this document as well as the need for
343 each. These policies are subdivided into the general groups of
344 password usage and password modification. Implementation details are
345 presented in Section 8 and Section 9.
347 4.1 Password Usage Policy
349 This section describes policy enforced when a password is used to
350 authenticate. The general focus of this policy is to minimize the
351 threat of intruders once a password is in use.
353 4.1.1 Password Guessing Limit
355 In order to prevent intruders from guessing a user's password, a
356 mechanism exists to track the number of failed authentication
357 attempts, and take action when a limit is reached. This policy
358 consists of five parts:
360 o A configurable limit on failed authentication attempts.
361 o A counter to track the number of failed authentication attempts.
362 o A timeframe in which the limit of consecutive failed
363 authentication attempts must happen before action is taken.
364 o The action to be taken when the limit is reached. The action will
365 either be nothing, or the account will be locked.
366 o An amount of time the account is locked (if it is to be locked).
367 This can be indefinite.
369 4.2 Password Modification Policy
371 This section describes policy enforced while users are modifying
372 passwords. The general focus of this policy is to ensure that when
373 users add or change their passwords, the security and effectiveness
374 of their passwords is maximized. In this document, the term "modify
375 password operation" refers to any operation that is used to add or
376 modify a password attribute. Often this is done by updating the
377 password attribute during an add or modify operation, but MAY be done
378 by other means such as an extended operation.
380 4.2.1 Password Expiration, Expiration Warning, and Grace
383 One of the key properties of a password is the fact that it is not
384 well known. If a password is frequently changed, the chances of that
385 user's account being broken into are minimized.
390 Sermersheim & Poitou Expires April 24, 2005 [Page 7]
392 Internet-Draft Password Policy for LDAP Directories October 2004
395 Password policy administrators may deploy a password policy that
396 causes passwords to expire after a given amount of time - thus
397 forcing users to change their passwords periodically.
399 As a side effect, there needs to be a way in which users are made
400 aware of this need to change their password before actually being
401 locked out of their accounts. One or both of the following methods
404 o A warning may be returned to the user sometime before his password
405 is due to expire. If the user fails to heed this warning before
406 the expiration time, his account will be locked.
407 o The user may bind to the directory a preset number of times after
408 her password has expired. If she fails to change her password
409 during one of her 'grace' authentications, her account will be
412 4.2.2 Password History
414 When the Password Expiration policy is used, an additional mechanism
415 may be employed to prevent users from simply re-using a previous
416 password (as this would effectively circumvent the expiration
419 In order to do this; a history of used passwords is kept. The
420 password policy administrator sets the number of passwords to be
421 stored at any given time. Passwords are stored in this history
422 whenever the password is changed. Users aren't allowed to specify
423 any passwords that are in the history list while changing passwords.
425 4.2.3 Password Minimum Age
427 Users may circumvent the Password History mechanism by quickly
428 performing a series of password changes. If they change their
429 password enough times, their 'favorite' password will be pushed out
432 This process may be made less attractive to users by employing a
433 minimum age for passwords. If users are forced to wait 24 hours
434 between password changes, they may be less likely to cycle through a
435 history of 10 passwords.
437 4.2.4 Password Quality and Minimum length
439 In order to prevent users from creating or updating passwords that
440 are easy to guess, a password quality policy may be employed. This
441 policy consists of two general mechanisms - ensuring that passwords
442 conform to a defined quality criterion and ensuring that they are of
446 Sermersheim & Poitou Expires April 24, 2005 [Page 8]
448 Internet-Draft Password Policy for LDAP Directories October 2004
453 Forcing a password to comply with the quality policy may imply a
454 variety of things including:
456 o Disallowing trivial or well-known words make up the password.
457 o Forcing a certain number of digits be used.
458 o Disallowing anagrams of the user's name.
460 The implementation of this policy meets with the following problems:
462 o If the password to be added or updated is encrypted by the client
463 before being sent, the server has no way of enforcing this policy.
464 Therefore, the onus of enforcing this policy falls upon client
466 o There are no specific definitions of what 'quality checking'
467 means. This can lead to unexpected behavior in a heterogeneous
470 4.2.5 User Defined Passwords
472 In some cases, it is desirable to disallow users from adding and
473 updating their own passwords. This policy makes this functionality
476 This implies that certain other policy, such as password expiration
479 4.2.6 Password Change after Reset
481 This policy forces the user to update her password after it has been
482 set for the first time, or has been reset by a password
485 This is needed in scenarios where a password administrator has set or
486 reset the password to a well-known value.
488 4.2.7 Safe Modification
490 As directories become more commonly used, it will not be unusual for
491 clients to connect to a directory and leave the connection open for
492 an extended period. This opens up the possibility for an intruder to
493 make modifications to a user's password while that user's computer is
494 connected but unattended.
496 This policy forces the user to prove his identity by specifying the
497 old password during a password modify operation.
502 Sermersheim & Poitou Expires April 24, 2005 [Page 9]
504 Internet-Draft Password Policy for LDAP Directories October 2004
507 {TODO: This allows a dictionary attack unless we specify that this is
508 also subject to intruder detection}
510 4.3 Restriction of the Password Policy
512 The password policy defined in this document can apply to any
513 attribute containing a password. Password policy state information
514 is held in the user's entry, and applies to a password attribute, not
515 a particular password attribute value. Thus the server SHOULD
516 enforce that the password attribute subject to password policy,
517 contains one and only one password value.
558 Sermersheim & Poitou Expires April 24, 2005 [Page 10]
560 Internet-Draft Password Policy for LDAP Directories October 2004
563 5. Schema used for Password Policy
565 The schema elements defined here fall into two general categories. A
566 password policy object class is defined which contains a set of
567 administrative password policy attributes, and a set of operational
568 attributes are defined that hold general password policy state
569 information for each user.
571 5.1 The pwdPolicy Object Class
573 This object class contains the attributes defining a password policy
574 in effect for a set of users. Section 10 describes the
575 administration of this object, and the relationship between it and
578 ( 1.3.6.1.4.1.42.2.27.8.2.1
582 MUST ( pwdAttribute )
583 MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
584 pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout
585 $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
586 pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
588 5.2 Attribute Types used in the pwdPolicy ObjectClass
590 Following are the attribute types used by the pwdPolicy object class.
594 This holds the name of the attribute to which the password policy is
595 applied. For example, the password policy may be applied to the
596 userPassword attribute.
598 ( 1.3.6.1.4.1.42.2.27.8.1.1
600 EQUALITY objectIdentifierMatch
601 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
605 This attribute holds the number of seconds that must elapse between
606 modifications to the password. If this attribute is not present, 0
609 ( 1.3.6.1.4.1.42.2.27.8.1.2
614 Sermersheim & Poitou Expires April 24, 2005 [Page 11]
616 Internet-Draft Password Policy for LDAP Directories October 2004
620 EQUALITY integerMatch
621 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
626 This attribute holds the number of seconds after which a modified
627 password will expire.
629 If this attribute is not present, or if the value is 0 the password
630 does not expire. If not 0, the value must be greater than or equal
631 to the value of the pwdMinAge.
633 ( 1.3.6.1.4.1.42.2.27.8.1.3
635 EQUALITY integerMatch
636 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
641 This attribute specifies the maximum number of used passwords stored
642 in the pwdHistory attribute.
644 If this attribute is not present, or if the value is 0, used
645 passwords are not stored in the pwdHistory attribute and thus may be
648 ( 1.3.6.1.4.1.42.2.27.8.1.4
650 EQUALITY integerMatch
651 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
654 5.2.5 pwdCheckQuality
656 {TODO: Consider changing the syntax to OID. Each OID will list a
657 quality rule (like min len, # of special characters, etc). These
658 rules can be specified outsid ethis document.}
660 {TODO: Note that even though this is meant to be a check that happens
661 during password modification, it may also be allowed to happen during
662 authN. This is useful for situations where the password is encrypted
663 when modified, but decrypted when used to authN.}
665 This attribute indicates how the password quality will be verified
666 while being modified or added. If this attribute is not present, or
670 Sermersheim & Poitou Expires April 24, 2005 [Page 12]
672 Internet-Draft Password Policy for LDAP Directories October 2004
675 if the value is '0', quality checking will not be enforced. A value
676 of '1' indicates that the server will check the quality, and if the
677 server is unable to check it (due to a hashed password or other
678 reasons) it will be accepted. A value of '2' indicates that the
679 server will check the quality, and if the server is unable to verify
680 it, it will return an error refusing the password.
682 ( 1.3.6.1.4.1.42.2.27.8.1.5
683 NAME 'pwdCheckQuality'
684 EQUALITY integerMatch
685 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
690 When quality checking is enabled, this attribute holds the minimum
691 number of characters that must be used in a password. If this
692 attribute is not present, no minimum password length will be
693 enforced. If the server is unable to check the length (due to a
694 hashed password or otherwise), the server will, depending on the
695 value of the pwdCheckQuality attribute, either accept the password
696 without checking it ('0' or '1') or refuse it ('2').
698 ( 1.3.6.1.4.1.42.2.27.8.1.6
700 EQUALITY integerMatch
701 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
704 5.2.7 pwdExpireWarning
706 This attribute specifies the maximum number of seconds before a
707 password is due to expire that expiration warning messages will be
708 returned to an authenticating user.
710 If this attribute is not present, or if the value is 0 no warnings
711 will be returned. If not 0, the value must be smaller than the value
712 of the pwdMaxAge attribute.
714 ( 1.3.6.1.4.1.42.2.27.8.1.7
715 NAME 'pwdExpireWarning'
716 EQUALITY integerMatch
717 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
720 5.2.8 pwdGraceAuthNLimit
722 This attribute specifies the number of times an expired password can
726 Sermersheim & Poitou Expires April 24, 2005 [Page 13]
728 Internet-Draft Password Policy for LDAP Directories October 2004
731 be used to authenticate. If this attribute is not present or if the
732 value is 0, authentication will fail.
734 ( 1.3.6.1.4.1.42.2.27.8.1.8
735 NAME 'pwdGraceAuthNLimit'
736 EQUALITY integerMatch
737 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
742 This attribute indicates, when its value is "TRUE", that the password
743 may not be used to authenticate after a specified number of
744 consecutive failed bind attempts. The maximum number of consecutive
745 failed bind attempts is specified in pwdMaxFailure.
747 If this attribute is not present, or if the value is "FALSE", the
748 password may be used to authenticate when the number of failed bind
749 attempts has been reached.
751 ( 1.3.6.1.4.1.42.2.27.8.1.9
753 EQUALITY booleanMatch
754 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
757 5.2.10 pwdLockoutDuration
759 This attribute holds the number of seconds that the password cannot
760 be used to authenticate due to too many failed bind attempts. If
761 this attribute is not present, or if the value is 0 the password
762 cannot be used to authenticate until reset by a password
765 ( 1.3.6.1.4.1.42.2.27.8.1.10
766 NAME 'pwdLockoutDuration'
767 EQUALITY integerMatch
768 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
773 This attribute specifies the number of consecutive failed bind
774 attempts after which the password may not be used to authenticate.
775 If this attribute is not present, or if the value is 0, this policy
776 is not checked, and the value of pwdLockout will be ignored.
782 Sermersheim & Poitou Expires April 24, 2005 [Page 14]
784 Internet-Draft Password Policy for LDAP Directories October 2004
787 ( 1.3.6.1.4.1.42.2.27.8.1.11
789 EQUALITY integerMatch
790 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
793 5.2.12 pwdFailureCountInterval
795 This attribute holds the number of seconds after which the password
796 failures are purged from the failure counter, even though no
797 successful authentication occurred.
799 If this attribute is not present, or if its value is 0, the failure
800 counter is only reset by a successful authentication.
802 ( 1.3.6.1.4.1.42.2.27.8.1.12
803 NAME 'pwdFailureCountInterval'
804 EQUALITY integerMatch
805 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
810 This attribute specifies with a value of "TRUE" that users must
811 change their passwords when they first bind to the directory after a
812 password is set or reset by a password administrator. If this
813 attribute is not present, or if the value is "FALSE", users are not
814 required to change their password upon binding after the password
815 administrator sets or resets the password. This attribute is not set
816 due to any actions specified by this document, it is typically set by
817 a password administrator after resetting a user's password.
819 ( 1.3.6.1.4.1.42.2.27.8.1.13
821 EQUALITY booleanMatch
822 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
825 5.2.14 pwdAllowUserChange
827 This attribute indicates whether users can change their own
828 passwords, although the change operation is still subject to access
829 control. If this attribute is not present, a value of "TRUE" is
830 assumed. This attribute is intended to be used in the absense of an
831 access control mechanism.
833 ( 1.3.6.1.4.1.42.2.27.8.1.14
838 Sermersheim & Poitou Expires April 24, 2005 [Page 15]
840 Internet-Draft Password Policy for LDAP Directories October 2004
843 NAME 'pwdAllowUserChange'
844 EQUALITY booleanMatch
845 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
850 This attribute specifies whether or not the existing password must be
851 sent along with the new password when being changed. If this
852 attribute is not present, a "FALSE" value is assumed.
854 ( 1.3.6.1.4.1.42.2.27.8.1.15
856 EQUALITY booleanMatch
857 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
860 5.3 Attribute Types for Password Policy State Information
862 Password policy state information must be maintained for each user.
863 The information is located in each user entry as a set of operational
864 attributes. These operational attributes are: pwdChangedTime,
865 pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
866 pwdReset, pwdPolicySubEntry.
868 5.3.1 Password Policy State Attribute Option
870 Since the password policy could apply to several attributes used to
871 store passwords, each of the above operational attributes must have
872 an option to specify which pwdAttribute it applies to. The password
873 policy option is defined as the following:
875 pwd-<passwordAttribute>
877 where passwordAttribute a string following the OID syntax
878 (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
879 (short name) MUST be used.
881 For example, if the pwdPolicy object has for pwdAttribute
882 "userPassword" then the pwdChangedTime operational attribute, in a
885 pwdChangedTime;pwd-userPassword: 20000103121520Z
887 This attribute option follows sub-typing semantics. If a client
888 requests a password policy state attribute to be returned in a search
889 operation, and does not specify an option, all subtypes of that
890 policy state attribute are returned.
894 Sermersheim & Poitou Expires April 24, 2005 [Page 16]
896 Internet-Draft Password Policy for LDAP Directories October 2004
901 This attribute specifies the last time the entry's password was
902 changed. This is used by the password expiration policy. If this
903 attribute does not exist, the password will never expire.
905 ( 1.3.6.1.4.1.42.2.27.8.1.16
906 NAME 'pwdChangedTime'
907 DESC 'The time the password was last changed'
908 EQUALITY generalizedTimeMatch
909 ORDERING generalizedTimeOrderingMatch
910 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
912 USAGE directoryOperation )
914 5.3.3 pwdAccountLockedTime
916 This attribute holds the time that the user's account was locked. A
917 locked account means that the password may no longer be used to
918 authenticate. A 000001010000Z value means that the account has been
919 locked permanently, and that only a password administrator can unlock
922 ( 1.3.6.1.4.1.42.2.27.8.1.17
923 NAME 'pwdAccountLockedTime'
924 DESC 'The time an user account was locked'
925 EQUALITY generalizedTimeMatch
926 ORDERING generalizedTimeOrderingMatch
927 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
929 USAGE directoryOperation )
933 This attribute holds the timestamps of the consecutive authentication
936 ( 1.3.6.1.4.1.42.2.27.8.1.19
937 NAME 'pwdFailureTime'
938 DESC 'The timestamps of the last consecutive authentication
940 EQUALITY generalizedTimeMatch
941 ORDERING generalizedTimeOrderingMatch
942 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
943 USAGE directoryOperation )
950 Sermersheim & Poitou Expires April 24, 2005 [Page 17]
952 Internet-Draft Password Policy for LDAP Directories October 2004
957 This attribute holds a history of previously used passwords. Values
958 of this attribute are transmitted in string format as given by the
961 pwdHistory = time "#" syntaxOID "#" length "#" data
963 time = <generalizedTimeString as specified in 6.14
966 syntaxOID = numericoid ; the string representation of the
967 ; dotted-decimal OID that defines the
968 ; syntax used to store the password.
969 ; numericoid is described in 4.1
972 length = numericstring ; the number of octets in data.
973 ; numericstring is described in 4.1
976 data = <octets representing the password in the format
977 specified by syntaxOID>.
979 This format allows the server to store, and transmit a history of
980 passwords that have been used. In order for equality matching to
981 function properly, the time field needs to adhere to a consistent
982 format. For this purpose, the time field MUST be in GMT format.
984 ( 1.3.6.1.4.1.42.2.27.8.1.20
986 DESC 'The history of user s passwords'
987 EQUALITY octetStringMatch
988 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
989 USAGE directoryOperation )
991 5.3.6 pwdGraceUseTime
993 This attribute holds the timestamps of grace authentications after a
994 password has expired.
996 ( 1.3.6.1.4.1.42.2.27.8.1.21
997 NAME 'pwdGraceUseTime'
998 DESC 'The timestamps of the grace authentication after the
999 password has expired'
1000 EQUALITY generalizedTimeMatch
1001 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1006 Sermersheim & Poitou Expires April 24, 2005 [Page 18]
1008 Internet-Draft Password Policy for LDAP Directories October 2004
1011 USAGE directoryOperation )
1015 This attribute holds a flag to indicate (when TRUE) that the password
1016 has been updated by the password administrator and must be changed by
1017 the user on first authentication.
1019 ( 1.3.6.1.4.1.42.2.27.8.1.22
1021 DESC 'The indication that the password has been reset'
1022 EQUALITY booleanMatch
1023 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1025 USAGE directoryOperation )
1027 5.3.8 pwdPolicySubentry
1029 This attribute points to the pwdPolicy subentry in effect for this
1032 ( 1.3.6.1.4.1.42.2.27.8.1.23
1033 NAME 'pwdPolicySubentry'
1034 DESC 'The pwdPolicy subentry in effect for this object'
1035 EQUALITY distinguishedNameMatch
1036 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1038 USAGE directoryOperation )
1062 Sermersheim & Poitou Expires April 24, 2005 [Page 19]
1064 Internet-Draft Password Policy for LDAP Directories October 2004
1067 6. Controls used for Password Policy
1069 This section details the controls used while enforcing password
1070 policy. A request control is defined that is sent by a client with a
1071 request operation in order to elicit a response control. The
1072 response control contains various warnings and errors associated with
1077 This control MAY be sent with any LDAP request message in order to
1078 convey to the server that this client is aware of, and can process
1079 the response control described in this document. When a server
1080 receives this control, it will return the response control when
1081 appropriate and with the proper data.
1083 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
1084 be TRUE or FALSE. There is no controlValue.
1086 6.2 Response Control
1088 If the client has sent a passwordPolicyRequest control, the server
1089 (when solicited by the inclusion of the request control) sends this
1090 control with the following operation responses: bindResponse,
1091 modifyResponse, addResponse, compareResponse and possibly
1092 extendedResponse, to inform of various conditions, and MAY be sent
1093 with other operations (in the case of the changeAfterReset error).
1094 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
1095 the BER encoding of the following type:
1097 PasswordPolicyResponseValue ::= SEQUENCE {
1098 warning [0] CHOICE {
1099 timeBeforeExpiration [0] INTEGER (0 .. maxInt),
1100 graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
1101 error [1] ENUMERATED {
1102 passwordExpired (0),
1104 changeAfterReset (2),
1105 passwordModNotAllowed (3),
1106 mustSupplyOldPassword (4),
1107 insufficientPasswordQuality (5),
1108 passwordTooShort (6),
1109 passwordTooYoung (7),
1110 passwordInHistory (8) } OPTIONAL }
1112 The timeBeforeExpiration warning specifies the number of seconds
1113 before a password will expire. The graceAuthNsRemaining warning
1114 specifies the remaining number of times a user will be allowed to
1118 Sermersheim & Poitou Expires April 24, 2005 [Page 20]
1120 Internet-Draft Password Policy for LDAP Directories October 2004
1123 authenticate with an expired password. The passwordExpired error
1124 signifies that the password has expired and must be reset. The
1125 changeAfterReset error signifies that the password must be changed
1126 before the user will be allowed to perform any operation other than
1127 bind and modify. The passwordModNotAllowed error is set when a user
1128 is restricted from changing her password. The
1129 insufficientPasswordQuality error is set when a password doesn't pass
1130 quality checking. The passwordTooYoung error is set if the age of
1131 the password to be modified is not yet old enough.
1133 Typically, only either a warning or an error will be encoded though
1134 there may be exceptions. For example, if the user is required to
1135 change a password after the password administrator set it, and the
1136 password will expire in a short amount of time, the control may
1137 include the timeBeforeExpiration warning and the changeAfterReset
1174 Sermersheim & Poitou Expires April 24, 2005 [Page 21]
1176 Internet-Draft Password Policy for LDAP Directories October 2004
1179 7. Policy Decision Points
1181 Following are a number of procedures used to make policy decisions.
1182 These procedures are typically performed by the server while
1183 processing an operation.
1185 The following sections contain detailed instructions that refer to
1186 attributes of the pwdPolicy object class. When doing so, the
1187 attribute of the pwdPolicy object that governs the entry being
1188 discussed is implied.
1190 7.1 Locked Account Check
1192 A status of true is returned to indicate that the account is locked
1193 if any of these conditions are met:
1195 o The value of the pwdAccountLockedTime attribute is 000001010000Z.
1196 o The current time is less than the value of the
1197 pwdAccountLockedTime attribute added to the value of the
1200 Otherwise a status of false is returned.
1202 7.2 Password Must be Changed Now Check
1204 A status of true is returned to indicate that the account is locked
1205 if all of these conditions are met:
1207 The pwdMustChange attribute is set to TRUE.
1208 The pwdReset attribute is set to TRUE.
1210 Otherwise a status of false is returned.
1212 7.3 Password Expiration Check
1214 A status of true is returned indicating that the password has expired
1215 if the value of the pwdExpireWarning attribute is 0, and the current
1216 time minus the value of pwdChangedTime is greater than the value of
1219 Otherwise, a status of false is returned.
1221 7.4 Remaining Grace AuthN Check
1223 If the pwdGraceUseTime attribute is present, the number of values in
1224 that attribute subtracted from the value of pwdGraceAuthNLimit is
1225 returned. Otherwise zero is returned. A positive result specifies
1226 the number of remaining grace authentications.
1230 Sermersheim & Poitou Expires April 24, 2005 [Page 22]
1232 Internet-Draft Password Policy for LDAP Directories October 2004
1235 7.5 Time Before Expiration Check
1237 If the pwdExpireWarning attribute is not present a zero status is
1238 returned. Otherwise the following steps are followed:
1240 Subtract the time stored in pwdChangedTime from the current time to
1241 arrive at the password's age. If the password's age is greater than
1242 than the value of the pwdMaxAge attribute, a zero status is returned.
1243 Subtract the value of the pwdExpireWarning attribute from the value
1244 of the pwdMaxAge attribute to arrive at the warning age. If the
1245 password's age is equal to or greater than the warning age, the value
1246 of pwdMaxAge minus the password's age is returned.
1248 7.6 Intruder Detection Check
1250 A status of true indicating that an intruder has been detected is
1251 returned if the following conditions are met:
1253 The pwdLockout attribute is TRUE.
1254 The number of values in the pwdFailureTime attribute that are
1255 younger than pwdFailureCountInterval is greater or equal to the
1256 pwdMaxFailure attribute.
1258 Otherwise a status of false is returned.
1260 While performing this check, values of pwdFailureTime that are old by
1261 more than pwdFailureCountInterval are purged and not counted.
1263 7.7 Password Too Young Check
1265 A status of true indicating that not enough time has passed since the
1266 password was last updated is returned if:
1268 The value of pwdMinAge is non-zero and pwdChangedTime is present.
1269 The value of pwdMinAge is greater than the current time minus the
1270 value of pwdChangedTime.
1272 Otherwise a false status is returned.
1286 Sermersheim & Poitou Expires April 24, 2005 [Page 23]
1288 Internet-Draft Password Policy for LDAP Directories October 2004
1291 8. Server Policy Enforcement Points
1293 The server SHOULD enforce that the password attribute subject to a
1294 password policy as defined in this document, contains one and only
1297 The scenarios in the following operations assume that the client has
1298 attached a passwordPolicyRequest control to the request message of
1299 the operation. In the event that the passwordPolicyRequest control
1300 was not sent, no passwordPolicyResponse control is returned. All
1301 other instructions remain the same.
1303 For successfuly completed operations, unless otherwise stated, no
1304 passwordPolicyResponse control is returned.
1306 8.1 Password-based Authentication
1308 This section contains the policy enforcement rules and policy data
1309 updates used while validating a password. Operations that validate
1310 passwords include, but are not limited to, the Bind operation where
1311 the simple choice specifies a password, and the compare operation
1312 where the attribute being compared holds a password.
1314 8.1.1 Fail if the account is locked
1316 If the account is locked as specified in Section 7.1, the server
1317 fails the operation with an appropriate resultCode (i.e.
1318 invalidCredentials (49) in the case of a bind operation, compareFalse
1319 (5) in the case of a compare operation, etc.). The server MAY set
1320 the error: accountLocked (1) in the passwordPolicyResponse in the
1321 controls field of the message.
1323 8.1.2 AuthN Passed Procedures
1325 If the authentication process indicates that the password validated,
1326 these procedures are followed in order:
1328 8.1.2.1 Policy state updates
1330 Delete the pwdFailureTime and pwdAccountLockedTime attributes.
1332 8.1.2.2 Password must be changed now
1334 If the decision in Section 7.2 returns true, the server sends to the
1335 client a response with an appropriate successful resultCode (i.e.
1336 success (0), compareTrue (6), etc.), and includes the
1337 passwordPolicyResponse in the controls field of the bindResponse
1338 message with the warning: changeAfterReset specified.
1342 Sermersheim & Poitou Expires April 24, 2005 [Page 24]
1344 Internet-Draft Password Policy for LDAP Directories October 2004
1347 For bind, the server MUST then disallow all operations issued by this
1348 user except modify password, bind, unbind, abandon and StartTLS
1351 8.1.2.3 Expired password
1353 If the password has expired as per Section 7.3, the server either
1354 returns a success or failure based on the state of grace
1357 8.1.2.3.1 Remaining Grace Authentications
1359 If there are remaining grace authentications as per Section 7.4, the
1360 server adds a new value with the current time in pwdGraceUseTime.
1361 Then it sends to the client a response with an appropriate successful
1362 resultCode (i.e. success (0), compareTrue (6), etc.), and includes
1363 the passwordPolicyResponse in the controls field of the response
1364 message with the warning: graceAuthNsRemaining choice set to the
1365 number of grace authentications left.
1367 Implementor's note: The system time of the host machine may be more
1368 granular than is needed to ensure unique values of this attribute.
1369 It is recommended that a mechanism is used to ensure unique
1370 generalized time values. The fractional seconds field may be used
1373 8.1.2.3.2 No Remaining Grace Authentications
1375 If there are no remaining grace authentications, the server fails the
1376 operation with an appropriate resultCode (invalidCredentials (49),
1377 compareFalse (5), etc.), and includes the passwordPolicyResponse in
1378 the controls field of the bindResponse message with the error:
1379 passwordExpired (0) set.
1381 8.1.2.4 Expiration Warning
1383 If the result of Section 7.5 is a positive number, the server sends
1384 to the client a response with an appropriate successful resultCode
1385 (i.e. success (0), compareTrue (6), etc.), and includes the
1386 passwordPolicyResponse in the controls field of the bindResponse
1387 message with the warning: timeBeforeExiration set to the value as
1388 described above. Otherwise, the server sends a successful response,
1389 and omits the passwordPolicyResponse.
1391 8.1.2.5 AuthN Failed Procedures
1393 If the authentication process indicates that the password failed
1394 validation due to invalid credentials, these procedures are followed:
1398 Sermersheim & Poitou Expires April 24, 2005 [Page 25]
1400 Internet-Draft Password Policy for LDAP Directories October 2004
1403 8.1.2.5.1 Policy state update
1405 Add the current time as a value of the pwdFailureTime attribute.
1407 Implementor's note: The system time of the host machine may be more
1408 granular than is needed to ensure unique values of this attribute.
1409 It is recommended that a mechanism is used to ensure unique
1410 generalized time values. The fractional seconds field may be used
1413 8.1.2.5.2 Lock on intruder detection
1415 If the check in Section 7.6 returns a true state, the server locks
1416 the account by setting the value of the pwdAccountLockedTime
1417 attribute to the current time. After locking the account, the server
1418 fails the operation with an appropriate resultCode
1419 (invalidCredentials (49), compareFalse (5), etc.), and includes the
1420 passwordPolicyResponse in the controls field of the message with the
1421 error: accountLocked (1).
1423 8.2 Password Update Operations
1425 Because the password is stored in an attribute, various operations
1426 (like add and modify) may be used to create or update a password.
1427 But some alternate mechanisms have been defined or may be defined,
1428 such as the LDAP Password Modify Extended Operation [RFC3062].
1430 While processing a password update, the server performs the following
1433 8.2.1 Safe Modification
1435 If pwdSafeModify is set to TRUE and if there is an existing password
1436 value, the server ensures that the password update operation includes
1437 the user's existing password.
1439 When the LDAP modify operation is used to modify a password, this is
1440 done by specifying both a delete action and an add or replace action,
1441 where the delete action is first, and specifies the existing
1442 password, and the add or replace action specifies the new password.
1443 Other password update operations SHOULD employ a similar mechanism.
1444 Otherwise this policy will fail.
1446 If the existing password is not specified, the server does not
1447 process the operation and sends the appropriate response message to
1448 the client with the resultCode: insufficientAccessRights (50), and
1449 includes the passwordPolicyResponse in the controls field of the
1450 response message with the error: mustSupplyOldPassword (4).
1454 Sermersheim & Poitou Expires April 24, 2005 [Page 26]
1456 Internet-Draft Password Policy for LDAP Directories October 2004
1459 8.2.2 Change After Reset
1461 If the decision in Section 7.2 returns true, the server ensures that
1462 the password update operation contains no modifications other than
1463 the modification of the password attribute. If other modifications
1464 exist, the server sends a response message to the client with the
1465 resultCode: insufficientAccessRights (50), and includes the
1466 passwordPolicyResponse in the controls field of the response message
1467 with the error: changeAfterReset (2).
1471 Check to see whether the bound identity has sufficient rights to
1472 update the password. If the bound identity is a user changing its
1473 own password, this MAY be done by checking the pwdAllowUserChange
1474 attribute or using an access control mechanism. The determination of
1475 this is implementation specific. If the user is not allowed to
1476 update her password, the server sends a response message to the
1477 client with the resultCode: insufficientAccessRights (50), and
1478 includes the passwordPolicyResponse in the controls field of the
1479 response message with the error: passwordModNotAllowed (3).
1481 8.2.4 Too Early to Update
1483 If the check in Section 7.7 results in a true status The server sends
1484 a response message to the client with the resultCode:
1485 constraintViolation (19), and includes the passwordPolicyResponse in
1486 the controls field of the response message with the error:
1487 passwordTooYoung (7).
1489 8.2.5 Password Quality
1491 Check the value of the pwdCheckQuality attribute. If the value is
1492 non-zero, the server:
1494 o Ensure that the password meets the quality criteria enforced by
1495 the server. This enforcement is implementation specific.
1496 If the server is unable to check the quality (due to a hashed
1497 password or otherwise), the value of pwdCheckQuality is evaluated.
1498 If the value is 1, operation continues. If the value is 2, the
1499 server sends a response message to the client with the resultCode:
1500 constraintViolation (19), and includes the passwordPolicyResponse
1501 in the controls field of the response message with the error:
1502 insufficientPasswordQuality (5).
1503 If the server is able to check the password quality, and the check
1504 fails, the server sends a response message to the client with the
1505 resultCode: constraintViolation (19), and includes the
1506 passwordPolicyResponse in the controls field of the response
1510 Sermersheim & Poitou Expires April 24, 2005 [Page 27]
1512 Internet-Draft Password Policy for LDAP Directories October 2004
1515 message with the error: insufficientPasswordQuality (5).
1516 o checks the value of the pwdMinLength attribute. If the value is
1517 non-zero, it ensures that the new password is of at least the
1519 If the server is unable to check the length (due to a hashed
1520 password or otherwise), the value of pwdCheckQuality is evaluated.
1521 If the value is 1, operation continues. If the value is 2, the
1522 server sends a response message to the client with the resultCode:
1523 constraintViolation (19), and includes the passwordPolicyResponse
1524 in the controls field of the response message with the error:
1525 passwordTooShort (6).
1526 If the server is able to check the password length, and the check
1527 fails, the server sends a response message to the client with the
1528 resultCode: constraintViolation (19), and includes the
1529 passwordPolicyResponse in the controls field of the response
1530 message with the error: passwordTooShort (6).
1534 If pwdInHistory is present and its value is non-zero, the server
1535 checks whether this password exists in the entry's pwdHistory
1536 attribute or in the current password attribute. If the password does
1537 exist in the pwdHistory attribute or in the current password
1538 attribute, the server sends a response message to the client with the
1539 resultCode: constraintViolation (19), and includes the
1540 passwordPolicyResponse in the controls field of the response message
1541 with the error: passwordInHistory (8).
1543 8.2.7 Policy State Updates
1545 If the steps have completed without causing an error condition, the
1546 server performs the following steps in order to update the necessary
1547 password policy state attributes:
1549 If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
1550 updates the pwdChangedTime attribute on the entry to the current
1553 If the value of pwdInHistory is non-zero, the server adds the
1554 previous password (if one existed) to the pwdHistory attribute. If
1555 the number of attributes held in the pwdHistory attribute exceeds the
1556 value of pwdInHistory, the server removes the oldest excess
1559 If the value the pwdMustChange is TRUE and the modification is
1560 performed by a password administrator, then the pwdReset attribute is
1561 set to TRUE. Otherwise, the pwdReset is removed from the user's
1566 Sermersheim & Poitou Expires April 24, 2005 [Page 28]
1568 Internet-Draft Password Policy for LDAP Directories October 2004
1571 The pwdFailureTime, pwdGraceUseTime and pwdExpirationWarned
1572 attributes is removed from the user's entry if they exist.
1574 8.3 Other Operations
1576 For operations other than bind, password update, unbind, abandon or
1577 StartTLS, if the decision in Section 7.2 returns true, the server
1578 sends a response message to the client with the resultCode:
1579 insufficientAccessRights (50), and includes the
1580 passwordPolicyResponse in the controls field of the response message
1581 with the error: changeAfterReset (2).
1622 Sermersheim & Poitou Expires April 24, 2005 [Page 29]
1624 Internet-Draft Password Policy for LDAP Directories October 2004
1627 9. Client Policy Enforcement Points
1629 These sections illustrate possible scenarios for each LDAP operation
1630 and define the types of responses that identify those scenarios.
1632 The scenarios in the following operations assume that the client
1633 attached a passwordPolicyRequest control to the request message of
1634 the operation, and thus may receive a passwordPolicyResponse control
1635 in the response message. In the event that the passwordPolicyRequest
1636 control was not sent, no passwordPolicyResponse control is returned.
1637 All other instructions remain the same.
1641 For every bind response received, the client checks the resultCode of
1642 the bindResponse and checks for a passwordPolicyResponse control to
1643 determine if any of the following conditions are true and MAY prompt
1644 the user accordingly.
1646 o bindResponse.resultCode = insufficientAccessRights (50),
1647 passwordPolicyResponse.error = accountLocked (1): The password
1648 failure limit has been reached and the account is locked. The
1649 user needs to retry later or contact the password administrator to
1651 o bindResponse.resultCode = success (0),
1652 passwordPolicyResponse.error = changeAfterReset (2): The user is
1653 binding for the first time after the password administrator set
1654 the password. In this scenario, the client SHOULD prompt the user
1655 to change his password immediately.
1656 o bindResponse.resultCode = success (0),
1657 passwordPolicyResponse.warning = graceAuthNsRemaining: The
1658 password has expired but there are remaining grace
1659 authentications. The user needs to change it.
1660 o bindResponse.resultCode = invalidCredentials (49),
1661 passwordPolicyResponse.error = passwordExpired (0): The password
1662 has expired and there are no more grace authentications. The user
1663 contacts the password administrator in order to have its password
1665 o bindResponse.resultCode = success (0),
1666 passwordPolicyResponse.warning = timeBeforeExpiration: The user's
1667 password will expire in n number of seconds.
1669 9.2 Modify Operations
1671 9.2.1 Modify Request
1673 If the application or client encrypts the password prior to sending
1674 it in a password modification operation (whether done through
1678 Sermersheim & Poitou Expires April 24, 2005 [Page 30]
1680 Internet-Draft Password Policy for LDAP Directories October 2004
1683 modifyRequest or another password modification mechanism), it SHOULD
1684 check the values of the pwdMinLength, and pwdCheckQuality attributes
1685 and SHOULD enforce these policies.
1687 9.2.2 Modify Response
1689 If the modifyRequest operation was used to change the password, or if
1690 another mechanism is used --such as an extendedRequest-- the
1691 modifyResponse or other appropriate response MAY contain information
1692 pertinent to password policy. The client checks the resultCode of
1693 the response and checks for a passwordPolicyResponse control to
1694 determine if any of the following conditions are true and optionally
1695 notify the user of the condition.
1697 o <pwdModResponse>.resultCode = insufficientAccessRights (50),
1698 passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
1699 attempted to change her password without specifying the old
1700 password but the password policy requires this.
1701 o <pwdModResponse>.resultCode = insufficientAccessRights (50),
1702 passwordPolicyResponse.error = changeAfterReset (2): The user must
1703 change her password before submitting any other LDAP requests.
1704 o <pwdModResponse>.resultCode = insufficientAccessRights (50),
1705 passwordPolicyResponse.error = passwordModNotAllowed (3): The user
1706 doesn't have sufficient rights to change his password.
1707 o <pwdModResponse>.resultCode = constraintViolation (19),
1708 passwordPolicyResponse.error = passwordTooYoung (7): It is too
1709 soon after the last password modification to change the password.
1710 o <pwdModResponse>.resultCode = constraintViolation (19),
1711 passwordPolicyResponse.error = insufficientPasswordQuality (5):
1712 The password failed quality checking.
1713 o <pwdModResponse>.resultCode = constraintViolation (19),
1714 passwordPolicyResponse.error = passwordTooShort (6): The length of
1715 the password is too short.
1716 o <pwdModResponse>.resultCode = constraintViolation (19),
1717 passwordPolicyResponse.error = passwordInHistory (8): The password
1718 has already been used; the user must choose a different one.
1722 If a password is specified in an addRequest, the client checks the
1723 resultCode of the addResponse and checks for a passwordPolicyResponse
1724 control to determine if any of the following conditions are true and
1725 may prompt the user accordingly.
1727 o addResponse.resultCode = insufficientAccessRights (50),
1728 passwordPolicyResponse.error = passwordModNotAllowed (3): The user
1729 doesn't have sufficient rights to add this password.
1734 Sermersheim & Poitou Expires April 24, 2005 [Page 31]
1736 Internet-Draft Password Policy for LDAP Directories October 2004
1739 o addResponse.resultCode = constraintViolation (19),
1740 passwordPolicyResponse.error = insufficientPasswordQuality (5):
1741 The password failed quality checking.
1742 o addResponse.resultCode = constraintViolation (19),
1743 passwordPolicyResponse.error = passwordTooShort (6): The length of
1744 the password is too short.
1746 9.4 Compare Operation
1748 When a compare operation is used to compare a password, the client
1749 checks the resultCode of the compareResponse and checks for a
1750 passwordPolicyResponse to determine if any of the following
1751 conditions are true and MAY prompt the user accordingly. These
1752 conditions assume that the result of the comparison was true.
1754 o compareResponse.resultCode = compareFalse (5),
1755 passwordPolicyResponse.error = accountLocked (1): The password
1756 failure limit has been reached and the account is locked. The
1757 user needs to retry later or contact the password administrator to
1759 o compareResponse.resultCode = compareTrue (6),
1760 passwordPolicyResponse.warning = graceAuthNsRemaining: The
1761 password has expired but there are remaining grace
1762 authentications. The user needs to change it.
1763 o compareResponse.resultCode = compareFalse (5),
1764 passwordPolicyResponse.error = passwordExpired (0): The password
1765 has expired and there are no more grace authentications. The user
1766 must contact the password administrator to reset the password.
1767 o compareResponse.resultCode = compareTrue (6),
1768 passwordPolicyResponse.warning = timeBeforeExpiration: The user's
1769 password will expire in n number of seconds.
1771 9.5 Other Operations
1773 For operations other than bind, unbind, abandon or StartTLS, the
1774 client checks the following result code and control to determine if
1775 the user needs to change the password immediately.
1777 o <Response>.resultCode = insufficientAccessRights (50),
1778 passwordPolicyResponse.error = : changeAfterReset (2)
1790 Sermersheim & Poitou Expires April 24, 2005 [Page 32]
1792 Internet-Draft Password Policy for LDAP Directories October 2004
1795 10. Administration of the Password Policy
1797 {TODO: Need to define an administrativeRole (need OID). Need to
1798 describe whether pwdPolicy admin areas can overlap}
1800 A password policy is defined for a particular subtree of the DIT by
1801 adding to an LDAP subentry whose immediate superior is the root of
1802 the subtree, the pwdPolicy auxiliary object class. The scope of the
1803 password policy is defined by the SubtreeSpecification attribute of
1804 the LDAP subentry as specified in [RFC3672].
1806 It is possible to define password policies for different password
1807 attributes within the same pwdPolicy entry, by specifying multiple
1808 values of the pwdAttribute. But password policies could also be in
1809 separate sub entries as long as they are contained under the same
1812 Modifying the password policy MUST NOT result in any change in users'
1813 entries to which the policy applies.
1815 It SHOULD be possible to overwrite the password policy for one user
1816 by defining a new policy in a subentry of the user entry.
1818 Each object that is controlled by password policy advertises the
1819 subentry that is being used to control its policy in its
1820 pwdPolicySubentry attribute. Clients wishing to examine or manage
1821 password policy for an object may interrogate the pwdPolicySubentry
1822 for that object in order to arrive at the proper pwdPolicy subentry.
1846 Sermersheim & Poitou Expires April 24, 2005 [Page 33]
1848 Internet-Draft Password Policy for LDAP Directories October 2004
1851 11. Password Policy and Replication
1853 The pwdPolicy object defines the password policy for a portion of the
1854 DIT and MUST be replicated on all the replicas of this subtree, as
1855 any subentry would be, in order to have a consistent policy among all
1858 The elements of the password policy that are related to the users are
1859 stored in the entry themselves as operational attributes. As these
1860 attributes are subject to modifications even on a read-only replica,
1861 replicating them must be carefully considered.
1863 The pwdChangedTime attribute MUST be replicated on all replicas, to
1864 allow expiration of the password.
1866 The pwdReset attribute MUST be replicated on all replicas, to deny
1867 access to operations other than bind and modify password.
1869 The pwdHistory attribute MUST be replicated to writable replicas. It
1870 doesn't have to be replicated to a read-only replica, since the
1871 password will never be directly modified on this server.
1873 The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and
1874 pwdGraceUseTime attributes MUST be replicated to writable replicas,
1875 making the password policy global for all servers. When the user
1876 entry is replicated to a read-only replica, these attributes SHOULD
1877 NOT be replicated. This means that the number of failures, of grace
1878 authentications and the locking will take place on each replicated
1879 server. For example, the effective number of failed attempts on a
1880 user password will be N x M (where N is the number of servers and M
1881 the value of pwdMaxFailure attribute). Replicating these attributes
1882 to a read-only replica MAY reduce the number of tries globally but
1883 MAY also introduce some inconstancies in the way the password policy
1886 Servers participating in a loosely consistent multi-master
1887 replication agreement SHOULD employ a mechanism which ensures
1888 uniqueness of values when populating the attributes pwdFailureTime
1889 and pwdGraceUseTime. The method of achieving this is a local matter
1890 and may consist of using a single authoritative source for the
1891 generation of unique time values, or may consist of the use of the
1892 fractional seconds part to hold a replica identifier.
1902 Sermersheim & Poitou Expires April 24, 2005 [Page 34]
1904 Internet-Draft Password Policy for LDAP Directories October 2004
1907 12. Security Considerations
1909 This document defines a set of rules to implement in an LDAP server,
1910 in order to mitigate some of the security risks associated with the
1911 use of passwords and to make it difficult for password cracking
1912 programs to break into directories.
1914 Authentication with a password MUST follow the recommendations made
1917 Modifications of passwords SHOULD only occur when the connection is
1918 protected with confidentiality and secure authentication.
1920 Access controls SHOULD be used to restrict access to the password
1921 policy attributes. The attributes defined to maintain the password
1922 policy state information SHOULD only be modifiable by the password
1923 administrator or higher authority. The pwdHistory attribute MUST be
1924 subject to the same level of access control as the attrbute holding
1927 As it is possible to define a password policy for one specific user
1928 by adding a subentry immediately under the user's entry, Access
1929 Controls SHOULD be used to restrict the use of the pwdPolicy object
1930 class or the LDAP subentry object class.
1932 When the intruder detection password policy is enforced, the LDAP
1933 directory is subject to a denial of service attack. A malicious user
1934 could deliberately lock out one specific user's account (or all of
1935 them) by sending bind requests with wrong passwords. There is no way
1936 to protect against this kind of attack. The LDAP directory server
1937 SHOULD log as much information as it can (such as client IP address)
1938 whenever an account is locked, in order to be able to identify the
1939 origin of the attack. Denying anonymous access to the LDAP directory
1940 is also a way to restrict this kind of attack.
1942 Returning certain status codes (such as passwordPolicyResponse.error
1943 = accountLocked) allows a denial of service attacker to know that it
1944 has successfully denied service to an account. Servers SHOULD
1945 implement additional checks which return the same status when it is
1946 sensed that some number of failed authentication requests has occured
1947 on a single connection, or from a client address. Server
1948 implementors are encouraged to invent other checks similar to this in
1949 order to thwart this type of DoS attack.
1958 Sermersheim & Poitou Expires April 24, 2005 [Page 35]
1960 Internet-Draft Password Policy for LDAP Directories October 2004
1965 This document is based in part on prior work done by Valerie Chu from
1966 Netscape Communications Corp, published as
1967 draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
1968 participated in early revisions of this document.
1970 14 Normative References
1972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1973 Requirement Levels", BCP 14, RFC 2119, March 1997.
1975 [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
1976 AUTHorize Extension for Simple Challenge/Response", RFC
1977 2195, September 1997.
1979 [RFC2222] Myers, J., "Simple Authentication and Security Layer
1980 (SASL)", RFC 2222, October 1997.
1982 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
1983 Access Protocol (v3)", RFC 2251, December 1997.
1985 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
1986 "Lightweight Directory Access Protocol (v3): Attribute
1987 Syntax Definitions", RFC 2252, December 1997.
1989 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
1990 "Authentication Methods for LDAP", RFC 2829, May 2000.
1992 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
1993 SASL Mechanism", RFC 2831, May 2000.
1995 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
1996 RFC 3062, February 2001.
1998 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
1999 Considerations for the Lightweight Directory Access
2000 Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2002 [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
2003 Access Protocol (LDAP)", RFC 3672, December 2003.
2005 [X680] International Telecommunications Union, "Abstract Syntax
2006 Notation One (ASN.1): Specification of basic notation",
2007 ITU-T Recommendation X.680, July 2002.
2009 [X690] International Telecommunications Union, "Information
2010 Technology - ASN.1 encoding rules: Specification of Basic
2014 Sermersheim & Poitou Expires April 24, 2005 [Page 36]
2016 Internet-Draft Password Policy for LDAP Directories October 2004
2019 Encoding Rules (BER), Canonical Encoding Rules (CER) and
2020 Distinguished Encoding Rules (DER)", ITU-T Recommendation
2028 1800 South Novell Place
2032 Phone: +1 801 861-3088
2033 EMail: jimse@novell.com
2038 180, Avenue de l'Europe
2039 Zirst de Montbonnot, 38334 Saint Ismier cedex
2042 Phone: +33 476 188 212
2043 EMail: ludovic.poitou@sun.com
2070 Sermersheim & Poitou Expires April 24, 2005 [Page 37]
2072 Internet-Draft Password Policy for LDAP Directories October 2004
2075 Intellectual Property Statement
2077 The IETF takes no position regarding the validity or scope of any
2078 Intellectual Property Rights or other rights that might be claimed to
2079 pertain to the implementation or use of the technology described in
2080 this document or the extent to which any license under such rights
2081 might or might not be available; nor does it represent that it has
2082 made any independent effort to identify any such rights. Information
2083 on the procedures with respect to rights in RFC documents can be
2084 found in BCP 78 and BCP 79.
2086 Copies of IPR disclosures made to the IETF Secretariat and any
2087 assurances of licenses to be made available, or the result of an
2088 attempt made to obtain a general license or permission for the use of
2089 such proprietary rights by implementers or users of this
2090 specification can be obtained from the IETF on-line IPR repository at
2091 http://www.ietf.org/ipr.
2093 The IETF invites any interested party to bring to its attention any
2094 copyrights, patents or patent applications, or other proprietary
2095 rights that may cover technology that may be required to implement
2096 this standard. Please address the information to the IETF at
2100 Disclaimer of Validity
2102 This document and the information contained herein are provided on an
2103 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2104 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2105 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2106 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2107 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2108 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2113 Copyright (C) The Internet Society (2004). This document is subject
2114 to the rights, licenses and restrictions contained in BCP 78, and
2115 except as set forth therein, the authors retain all their rights.
2120 Funding for the RFC Editor function is currently provided by the
2126 Sermersheim & Poitou Expires April 24, 2005 [Page 38]