Skip to content
Snippets Groups Projects
draft-behera-ldap-password-policy-xx.txt 76.1 KiB
Newer Older
Kurt Zeilenga's avatar
Kurt Zeilenga committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000


Internet-Draft                                                P. Behera
draft behera-ldap-password-policy-07.txt                      L. Poitou
Intended Category: Proposed Standard                   Sun Microsystems
Expires: August 2004                                     J. Sermersheim
                                                                 Novell

                                                          February 2004
 
 
                  Password Policy for LDAP Directories 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 2026.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet- Drafts as 
   reference material or to cite them other than as "work in progress." 
     
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   Technical discussions of this draft are held on the LDAPEXT Working 
   Group mailing list at ietf-ldapext@netscape.com. Editorial comments 
   may be sent to the authors listed in Section 13. 
    
   Copyright (C) The Internet Society (2004). All rights Reserved. 
    
   Please see the Copyright Section near the end of this document for 
   more information. 
    
    
    
Conventions 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 
   are to be interpreted as described in RFC 2119 [RFC-2119]. 
    

 
Behera, et. al.        Expires August 15, 2004                  Page 1

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
    
1. Abstract 
    
   Password policy as described in this document is a set of rules that 
   controls how passwords are used and administered in LDAP 
   directories. In order to improve the security of LDAP directories 
   and make it difficult for password cracking programs to break into 
   directories, it is desirable to enforce a set of rules on password 
   usage.  These rules are made to ensure that users change their 
   passwords periodically, passwords meet construction requirements, 
   the re-use of old password is restricted, and users are locked out 
   after a certain number of failed attempts. 
    
    
    
2. Overview 
    
   LDAP-based directory services are currently accepted by many 
   organizations as the access protocol for directories. The ability to 
   ensure the secure read and update access to directory information 
   throughout the network is essential to the successful deployment.  
   Most LDAP implementations support many authentication schemes - the 
   most basic and widely used is the simple authentication i.e., user 
   DN and password. In this case, many LDAP servers have implemented 
   some kind of policy related to the password used to authenticate. 
   Among other things, this policy includes: 
    
   - Whether and when passwords expire. 
   - Whether failed bind attempts cause the account to be locked. 
   - If and how users are able to change their passwords. 
    
   In order to achieve greater security protection and ensure 
   interoperability in a heterogeneous environment, LDAP needs to 
   standardize on a common password policy model. This is critical to 
   the successful deployment of LDAP directories. 
    
2.1. Application of password policy 
    
   The password policy defined in this document can be applied to any 
   attribute holding a user's password used for an authenticated LDAP 
   bind operation. In this document, the term "user" represents any 
   LDAP client application that has an identity in the directory. 
    
   This policy is typically applied to the userPassword attribute in 
   the case of the LDAP simple authentication method [RFC-2251] or the 
   case of password based SASL [RFC-2222] authentication such as CRAM-
   MD5 [RFC-2195] and DIGEST-MD5 [RFC-Digest]. 
    
    

 
Behera, et. al.        Expires August 15, 2004                  Page 2

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   The policy described in this document assumes that the password 
   attribute holds a single value. No considerations are made for 
   directories or systems that allow a user to maintain multi-valued 
   password attributes. 
    
   Server implementations MAY institute internal policy whereby certain 
   identities (such as directory administrators) are not forced to 
   comply with any of password policy. In this case, the password for a 
   directory administrator never expires; the account is never locked, 
   etc.  
    
   The term "directory administrator" refers to a user that has 
   sufficient access control privileges to modify users' passwords, and 
   the pwdPolicy object defined in this document. The access control 
   that is used to determine whether an identity is a directory 
   administrator is beyond the scope of this document, but typically 
   implies that the administrator has 'write' privileges to the 
   password attribute. 
    
3. Articles of password policy 
    
   The following sections explain in general terms each aspect of the 
   password policy defined in this document as well as the need for 
   each. These policies are subdivided into the general groups of 
   password usage and password modification. Implementation details are 
   presented in Sections 6 and 7. 
    
3.1. Password Usage Policy 
 
   This section describes policy enforced when a password is used to 
   authenticate. The general focus of this policy is to minimize the 
   threat of intruders once a password is in use. 
    
3.1.1. Password Guessing limit 
    
   In order to prevent intruders from guessing a user's password, a 
   mechanism exists to track the number of failed authentication 
   attempts, and take action when a limit is reached. 
    
   This policy consists of five parts: 
    
   -  A configurable limit on failed authentication attempts.  
    
   -  A counter to track the number of failed authentication attempts. 
    
   -  A timeframe in which the limit of consecutive failed 
      authentication attempts must happen before action is taken. 
    


 
Behera, et. al.        Expires August 15, 2004                  Page 3

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   -  The action to be taken when the limit is reached. The action will 
      either be nothing, or the account will be locked. 
    
   -  An amount of time the account is locked (if it is to be locked). 
      This can be indefinite. 
    
3.2. Password Modification Policy 
    
   This section describes policy enforced while users are modifying 
   passwords. The general focus of this policy is to ensure that when 
   users add or change their passwords, the security and effectiveness 
   of their passwords is maximized. In this document, the term "modify 
   password operation" refers to any operation that is used to add or 
   modify a password attribute. Often this is done by updating the 
   userPassword attribute during an add or modify operation, but MAY be 
   done by other means such as an extended operation. 
    
    
3.2.1. Password Expiration, Expiration Warning, and Grace binds 
    
   One of the key properties of a password is the fact that it is not 
   well known. If a password is frequently changed, the chances of that 
   user's account being broken into are minimized. 
     
   Directory administrators may deploy a password policy that causes 
   passwords to expire after a given amount of time - thus forcing 
   users to change their passwords periodically. 
    
   As a side effect, there needs to be a way in which users are made 
   aware of this need to change their password before actually being 
   locked out of their accounts. One or both of the following methods 
   handle this: 
    
   -  The user is sent a warning sometime before his password is due to 
      expire. If the user fails to heed this warning before the 
      expiration time, his account will be locked. 
    
   -  The user may bind to the directory a preset number of times after 
      her password has expired. If she fails to change her password 
      during one of her 'grace' binds, her account will be locked. 
    
3.2.2. Password History 
 
   When the Password Expiration policy is used, an additional mechanism 
   may be employed to prevent users from simply re-using a previous 
   password (as this would effectively circumvent the expiration 
   policy). 
    


 
Behera, et. al.        Expires August 15, 2004                  Page 4

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   In order to do this; a history of used passwords is kept. The 
   directory administrator sets the number of passwords to be stored at 
   any given time. Passwords are stored in this history whenever the 
   password is changed. Users aren't allowed to specify any passwords 
   that are in the history list while changing passwords. 
 
3.2.3. Password Minimum Age 
    
   Users may circumvent the Password History mechanism by quickly 
   performing a series of password changes. If they change their 
   password enough times, their 'favorite' password will be pushed out 
   of the history list. 
    
   This process may be made less attractive to users by employing a 
   minimum age for passwords. If users are forced to wait 24 hours 
   between password changes, they may be less likely to cycle through a 
   history of 10 passwords. 
    
3.2.4. Password Quality and Minimum length 
    
   In order to prevent users from creating or updating passwords that 
   are easy to guess, a password quality policy may be employed. This 
   policy consists of two general mechanisms - ensuring that passwords 
   conform to a defined quality criteria and ensuring that they are of 
   a minimum length. 
    
   Forcing a password to comply with the quality policy may imply a 
   variety of things including: 
    
   -  Disallowing trivial or well-known words make up the password. 
    
   -  Forcing a certain number of digits be used. 
    
   -  Disallowing anagrams of the user's name. 
    
   The implementation of this policy meets with the following problems: 
    
   -  If the password to be added or updated is encrypted by the client 
      before being sent, the server has no way of enforcing this 
      policy. Therefore, the onus of enforcing this policy falls upon 
      client implementations. 
    
   -  There are no specific definitions of what 'quality checking' 
      means. This can lead to unexpected behavior in a heterogeneous 
      environment.  
    
3.2.5. User Defined Passwords 
    


 
Behera, et. al.        Expires August 15, 2004                  Page 5

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   In some cases, it is desirable to disallow users from adding and 
   updating their own passwords. This policy makes this functionality 
   possible.  
    
   This implies that certain other policy, such as password expiration 
   is not enforced.  
    
3.2.6. Password Change After Reset 
    
   This policy forces the user to update her password after it has been 
   set for the first time, or has been reset by the directory 
   administrator. 
    
   This is needed in scenarios where a directory administrator has set 
   or reset the password to a well-known value. 
 
3.2.7. Safe modification 
    
   As directories become more commonly used, it will not be unusual for 
   clients to connect to a directory and leave the connection open for 
   an extended period. This opens up the possibility for an intruder to 
   make modifications to a user's password while that user's computer 
   is connected but unattended. 
    
   This policy forces the user to prove his identity by specifying the 
   old password during a password modify operation. 
    
3.3. Restriction of the Password Policy 
    
   The password policy defined in this document can apply to any 
   attribute containing a password. Password policy state information 
   is held in the user's entry, and applies to a password attribute, 
   not a particular password attribute value. Thus the server SHOULD 
   enforce that the password attribute subject to password policy, 
   contains one and only one password value. 
    
    
4. Schema used for Password Policy 
    
   The schema elements defined here fall into two general categories. A 
   password policy object class is defined which contains a set of 
   administrative password policy attributes, and a set of operational 
   attributes are defined that hold general password policy state 
   information for each user. 
    
4.1. The pwdPolicy Object Class 
    
   This object class contains the attributes defining a password policy 
   in effect for a set of users. Section 8 describes the administration 

 
Behera, et. al.        Expires August 15, 2004                  Page 6

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   of this object, and the relationship between it and particular 
   objects. 
    
   (  1.3.6.1.4.1.42.2.27.8.2.1 
      NAME 'pwdPolicy'  
      SUP top 
      AUXILIARY  
      MUST ( pwdAttribute ) 
      MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ 
      pwdMinLength $ pwdExpireWarning $ pwdGraceLoginLimit $ pwdLockout 
      $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ 
      pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) 
    
4.2. Attribute Types used in the pwdPolicy ObjectClass 
    
   Following are the attribute types used by the pwdPolicy object 
   class. 
    
4.2.1. pwdAttribute 
    
   This holds the name of the attribute to which the password policy is 
   applied. For example, the password policy may be applied to the 
   userPassword attribute. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.1 
      NAME 'pwdAttribute' 
      EQUALITY objectIdentifierMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 
    
4.2.2. pwdMinAge  
    
   This attribute holds the number of seconds that must elapse between 
   modifications to the password. If this attribute is not present, 0 
   seconds is assumed. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.2 
      NAME 'pwdMinAge' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.3. pwdMaxAge 
    
   This attribute holds the number of seconds after which a modified 
   password will expire. 
    
   If this attribute is not present, or if the value is 0 the password 
   does not expire. If not 0, the value must be greater than or equal 
   to the value of the pwdMinAge. 

 
Behera, et. al.        Expires August 15, 2004                  Page 7

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
    
   (  1.3.6.1.4.1.42.2.27.8.1.3 
      NAME 'pwdMaxAge' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
      SINGLE-VALUE ) 
    
4.2.4. pwdInHistory 
    
   This attribute specifies the maximum number of used passwords stored 
   in the pwdHistory attribute. 
    
   If this attribute is not present, or if the value is 0, used 
   passwords are not stored in the pwdHistory attribute and thus may be 
   reused. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.4 
      NAME 'pwdInHistory' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
      SINGLE-VALUE ) 
    
4.2.5. pwdCheckQuality 
    
   This attribute indicates how the password quality will be verified 
   while being modified or added. If this attribute is not present, or 
   if the value is '0', quality checking will not be enforced. A value 
   of '1' indicates that the server will check the quality, and if the 
   server is unable to check it (due to a hashed password or other 
   reasons) it will be accepted. A value of '2' indicates that the 
   server will check the quality, and if the server is unable to verify 
   it, it will return an error refusing the password. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.5 
      NAME 'pwdCheckQuality' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.6. pwdMinLength 
    
   When quality checking is enabled, this attribute holds the minimum 
   number of characters that must be used in a password. If this 
   attribute is not present, no minimum password length will be 
   enforced. If the server is unable to check the length (due to a 
   hashed password or otherwise), the server will, depending on the 
   value of the pwdCheckQuality attribute, either accept the password 
   without checking it ('0' or '1') or refuse it ('2'). 
    

 
Behera, et. al.        Expires August 15, 2004                  Page 8

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   (  1.3.6.1.4.1.42.2.27.8.1.6 
      NAME 'pwdMinLength' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
      SINGLE-VALUE ) 
    
4.2.7. pwdExpireWarning 
    
   This attribute specifies the maximum number of seconds before a 
   password is due to expire that expiration warning messages will be 
   returned to an authenticating user. If this attribute is not 
   present, or if the value is 0 no warnings will be sent. If not 0, 
   the value must be smaller than the value of the pwdMaxAge attribute. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.7 
      NAME 'pwdExpireWarning' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.8. pwdGraceLoginLimit 
    
   This attribute specifies the number of times an expired password can 
   be used to authenticate. If this attribute is not present or if the 
   value is 0, authentication will fail. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.8 
      NAME 'pwdGraceLoginLimit' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.9. pwdLockout 
    
   This attribute indicates, when its value is "TRUE", that the 
   password may not be used to authenticate after a specified number of 
   consecutive failed bind attempts. The maximum number of consecutive 
   failed bind attempts is specified in pwdMaxFailure. 
    
   If this attribute is not present, or if the value is "FALSE", the 
   password may be used to authenticate when the number of failed bind 
   attempts has been reached. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.9 
      NAME 'pwdLockout' 
      EQUALITY booleanMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7  
      SINGLE-VALUE ) 

    
 
Behera, et. al.        Expires August 15, 2004                  Page 9

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
4.2.10. pwdLockoutDuration 
    
   This attribute holds the number of seconds that the password cannot 
   be used to authenticate due to too many failed bind attempts. If 
   this attribute is not present, or if the value is 0 the password 
   cannot be used to authenticate until reset by an administrator. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.10 
      NAME 'pwdLockoutDuration' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.11. pwdMaxFailure 
    
   This attribute specifies the number of consecutive failed bind 
   attempts after which the password may not be used to authenticate. 
   If this attribute is not present, or if the value is 0, this policy 
   is not checked, and the value of pwdLockout will be ignored. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.11 
      NAME 'pwdMaxFailure' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.12. pwdFailureCountInterval 
    
   This attribute holds the number of seconds after which the password 
   failures are purged from the failure counter, even though no 
   successful authentication occurred. 
    
   If this attribute is not present, or if its value is 0, the failure 
   counter is only reset by a successful authentication. 
     
   (  1.3.6.1.4.1.42.2.27.8.1.12 
      NAME 'pwdFailureCountInterval' 
      EQUALITY integerMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27  
      SINGLE-VALUE ) 
    
4.2.13. pwdMustChange 
    
   This attribute specifies with a value of "TRUE" that users must 
   change their passwords when they first bind to the directory after a 
   password is set or reset by the administrator. If this attribute is 
   not present, or if the value is "FALSE", users are not required to 
   change their password upon binding after the administrator sets or 
   resets the password. 

 
Behera, et. al.        Expires August 15, 2004                 Page 10

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
    
   (  1.3.6.1.4.1.42.2.27.8.1.13 
      NAME 'pwdMustChange' 
      EQUALITY booleanMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7  
      SINGLE-VALUE ) 
    
4.2.14. pwdAllowUserChange 
    
   This attribute indicates whether users can change their own 
   passwords, although the change operation is still subject to access 
   control. If this attribute is not present, a value of "TRUE" is 
   assumed. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.14 
      NAME 'pwdAllowUserChange' 
      EQUALITY booleanMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7  
      SINGLE-VALUE ) 
    
4.2.15. pwdSafeModify 
    
   This attribute specifies whether or not the existing password must 
   be sent when changing a password. If this attribute is not present, 
   a "FALSE" value is assumed. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.15 
      NAME 'pwdSafeModify' 
      EQUALITY booleanMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7  
      SINGLE-VALUE ) 
    
4.3. Attribute Types for Password Policy State Information 
    
   Password policy state information must be maintained for each user. 
   The information is located in each user entry as a set of 
   operational attributes. These operational attributes are: 
   pwdChangedTime, pwdAccountLockedTime, pwdExpirationWarned, 
   pwdFailureTime, pwdHistory, pwdGraceUseTime, pwdReset, 
   pwdPolicySubEntry. 
    
4.3.1. Password Policy State Attribute Option 
    
   Since the password policy could apply to several attributes used to 
   store passwords, each of the above operational attributes must have 
   an option to specify which pwdAttribute is applies to.  
   The password policy option is defined as the following: 
        pwd-<passwordAttribute> 
    

 
Behera, et. al.        Expires August 15, 2004                 Page 11

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
        where passwordAttribute a string following the OID syntax 
        (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor 
        (short name) MUST be used. 
    
   For example, if the pwdPolicy object has for pwdAttribute 
   "userPassword" then the pwdChangedTime operational attribute, in a 
   user entry, will be: 
   pwdChangedTime;pwd-userPassword: 20000103121520Z 
    
   This attribute option follows sub-typing semantics. If a client 
   requests a password policy state attribute to be returned in a 
   search operation, and does not specify an option, all subtypes of 
   that policy state attribute are returned. 
    
         
4.3.2. pwdChangedTime 
    
   This attribute specifies the last time the entry's password was 
   changed. This is used by the password expiration policy. If this 
   attribute does not exist, the password will never expire. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.16 
      NAME 'pwdChangedTime' 
      DESC 'The time the password was last changed' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
      EQUALITY generalizedTimeMatch 
      ORDERING generalizedTimeOrderingMatch 
      SINGLE-VALUE 
      USAGE directoryOperation) 
    
4.3.3. pwdAccountLockedTime 
    
   This attribute holds the time that the user's account was locked. A 
   locked account means that the password may no longer be used to 
   authenticate. A 0 value means that the account has been locked 
   permanently, and that only an administrator can unlock the account. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.17 
      NAME 'pwdAccountLockedTime' 
      DESC 'The time an user account was locked' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
      EQUALITY generalizedTimeMatch 
      ORDERING generalizedTimeOrderingMatch 
      SINGLE-VALUE 
      USAGE directoryOperation) 
     
4.3.4. pwdExpirationWarned 
 


 
Behera, et. al.        Expires August 15, 2004                 Page 12

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   This attribute contains the time when the password expiration 
   warning was first sent to the client. The password will expire in 
   the pwdExpireWarning time. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.18 
      NAME 'pwdExpirationWarned' 
      DESC 'The time the user was first warned about the coming 
              expiration of the password' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
      EQUALITY generalizedTimeMatch 
      ORDERING generalizedTimeOrderingMatch 
      SINGLE-VALUE 
      USAGE directoryOperation ) 
    
4.3.5. pwdFailureTime 
    
   This attribute holds the timestamps of the consecutive 
   authentication failures. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.19 
      NAME 'pwdFailureTime' 
      DESC 'The timestamps of the last consecutive authentication 
              failures' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
      EQUALITY generalizedTimeMatch 
      ORDERING generalizedTimeOrderingMatch 
      USAGE directoryOperation ) 
    
    
4.3.6. pwdHistory 
    
   This attribute holds a history of previously used passwords. 
    
   Values of this attribute are transmitted in string format as given 
   by the following ABNF: 
    
   pwdHistory = time "#" syntaxOID "#" length "#" data 
    
   time         = <generalizedTimeString as specified in 6.14 of 
                  [RFC2252]> 
    
   syntaxOID    = numericoid     ; the string representation of the  
                                 ; dotted-decimal OID that defines the 
                                 ; syntax used to store the password. 
                                 ; numericoid is described in 4.1 of 
                                 ; [RFC2252]. 
      
   length       = numericstring  ; the number of octets in data. 
                                 ; numericstring is described in 4.1 of 

 
Behera, et. al.        Expires August 15, 2004                 Page 13

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
                                 ; [RFC2252]. 
    
   data         = <octets representing the password in the format      
                specified by syntaxOID>. 
    
   This format allows the server to store, and transmit a history of 
   passwords that have been used. In order for equality matching to 
   function properly, the time field needs to adhere to a consistent 
   format. For this purpose, the time field MUST be in GMT format. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.20 
      NAME 'pwdHistory' 
      DESC 'The history of user s passwords' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 
      EQUALITY octetStringMatch 
      USAGE directoryOperation) 
    
4.3.7. pwdGraceUseTime 
    
   This attribute holds the timestamps of grace login once a password 
   has expired. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.21 
      NAME 'pwdGraceUseTime' 
      DESC 'The timestamps of the grace login once the password has 
      expired' 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
      EQUALITY generalizedTimeMatch 
       
      USAGE directoryOperation) 
    
4.3.8. pwdReset 
    
   This attribute holds a flag to indicate (when TRUE) that the 
   password has been reset and therefore must be changed by the user on 
   first authentication. 
    
   (  1.3.6.1.4.1.42.2.27.8.1.22 
      NAME 'pwdReset' 
      DESC 'The indication that the password has been reset' 
      EQUALITY booleanMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
      SINGLE-VALUE 
      USAGE directoryOperation) 
    
4.3.9. pwdPolicySubentry 
    
   This attribute points to the pwdPolicy subentry in effect for this 
   object. 
 

Behera, et. al.        Expires August 15, 2004                 Page 14

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
    
   (  1.3.6.1.4.1.42.2.27.8.1.23 
      NAME 'pwdPolicySubentry' 
      DESC 'The pwdPolicy subentry in effect for this object' 
      EQUALITY distinguishedNameMatch 
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
      SINGLE-VALUE 
      USAGE directoryOperation) 
    
5. Controls used for Password Policy 
 
   This section details the controls used while enforcing password 
   policy. A request control is defined that is sent by a client with a 
   request operation in order to elicit a response control. The 
   response control contains various warnings and errors associated 
   with password policy. 
    
5.1. Request Control 
    
   This control MAY be sent with any LDAP request message in order to 
   convey to the server that this client is aware of, and can process 
   the response control described in this document. When a server 
   receives this control, it will return the response control when 
   appropriate and with the proper data. 
    
   The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality 
   MUST be FALSE. There is no controlValue. 
    
   passwordPolicyRequest 
    
   controlType: 1.3.6.1.4.1.42.2.27.8.5.1 
   criticality: FALSE 
   controlValue:                 None 
    
5.2. Response Control 
    
   If the client has sent a passwordPolicyRequest control, the server 
   sends this control with the following operation responses: 
   bindResponse, modifyResponse, addResponse, compareResponse and 
   possibly extendedResponse, to inform of various conditions, and MAY 
   be sent with other operations (in the case of the changeAfterReset 
   error). 
    
   passwordPolicyResponse 
    
   controlType:  1.3.6.1.4.1.42.2.27.8.5.1 
   criticality: FALSE 
   controlValue:                 an OCTET STRING, whose value is the BER encoding of the 
                following type: 

 
Behera, et. al.        Expires August 15, 2004                 Page 15

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
    
   PasswordPolicyResponseValue ::= SEQUENCE { 
      warning   [0] CHOICE { 
          timeBeforeExpiration  [0] INTEGER (0 .. maxInt), 
          graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } OPTIONAL  
      error     [1] ENUMERATED { 
          passwordExpired               (0), 
          accountLocked         (1), 
          changeAfterReset              (2), 
          passwordModNotAllowed (3), 
          mustSupplyOldPassword (4), 
          insufficientPasswordQuality   (5), 
          passwordTooShort              (6), 
          passwordTooYoung              (7), 
          passwordInHistory             (8) } OPTIONAL } 
    
   The timeBeforeExpiration warning specifies the number of seconds 
   before a password will expire. The graceLoginsRemaining warning 
   specifies the remaining number of times a user will be allowed to 
   authenticate with an expired password. The passwordExpired error 
   signifies that the password has expired and must be reset. The 
   changeAfterReset error signifies that the password must be changed 
   before the user will be allowed to perform any operation other than 
   bind and modify. The passwordModNotAllowed error is set when a user 
   is restricted from changing her password. The 
   insufficientPasswordQuality error is set when a password doesn't 
   pass quality checking. The passwordTooYoung error is set if the age 
   of the password to be modified is not yet old enough. 
    
   Typically, only either a warning or an error will be encoded though 
   there may be exceptions. For example, if the user is required to 
   change a password after the administrator set it, and the password 
   will expire in a short amount of time, the control may include the 
   timeBeforeExpiration warning and the changeAfterReset error.  
    
 
6. Server Implementation by LDAP operation 
    
   The following sections contain detailed instructions that refer to 
   attributes of the pwdPolicy object class. When doing so, the 
   attribute of the pwdPolicy object that governs the entry being 
   discussed is implied. 
    
   The server SHOULD enforce that the password attribute subject to a 
   password policy as defined in this document, contains one and only 
   one password value. 
    
   The scenarios in the following operations assume that the client has 
   attached a passwordPolicyRequest control to the request message of 
 

Behera, et. al.        Expires August 15, 2004                 Page 16

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
   the operation. In the event that the passwordPolicyRequest control 
   was not sent, no passwordPolicyRequest control is returned. All 
   other instructions remain the same. 
 
    
6.1. Bind Operation 
         
   When processing a bind request, the server MUST perform the 
   following steps: 
    
   1. Check for a locked account: 
    
      If the value of the pwdAccountLockedTime attribute is 0, or if 
      the current time is less than the value of the 
      pwdAccountLockedTime attribute added to the value of the 
      pwdLockoutDuration, the account is locked. 
       
      If the account is locked, the server MUST send a bindResponse to 
      the client with the resultCode: unwillingToPerform (53), and MUST 
      include the passwordPolicyResponse in the controls field of the 
      bindResponse message with the error: accountLocked (1). 
       
      If the account is not locked, the server MUST proceed with the 
      bind operation. 
 
   2. Check the result of the bind operation: 
       
      If the bind operation succeeds with authentication, the server 
      MUST do the following: 
 
      A.  Delete the pwdFailureTime attribute. 
 
             B.  Check whether the password must be changed now.  
       
          If the pwdMustChange attribute is set to TRUE, and if the 
          pwdReset attribute is set to TRUE, the password must be 
          changed now. 
           
          If the password must be changed now, the server MUST send a 
          bindResponse to the client with the resultCode: success (0), 
          and MUST include the passwordPolicyResponse in the controls 
          field of the bindResponse message with the warning: 
          changeAfterReset specified. 
          The server MUST then disallow all operations issued by this 
          user except modify password, bind, unbind, abandon and 
          StartTLS extended operation. 
       
          If the password does not need to be changed now, the operation 
          proceeds. 

 
Behera, et. al.        Expires August 15, 2004                 Page 17

INTERNET DRAFT           LDAP Password Policy         15 February 2004 
 
 
 
      C.  Check for password expiration 
    
          The password has expired when either of the following 
          conditions is met: 
       
          -  If the value of the pwdExpireWarning attribute is 0, the 
             server subtracts the current time from the time stored in 
             pwdChangedTime to arrive at the password's age. If the age 
             is greater than the value in the pwdMaxAge attribute, the 
             password has expired.  
       
          -  If the value of the pwdExpireWarning attribute is non-
             zero, and the pwdExpirationWarned attribute is present and 
             has a time value, the server subtracts the current time 
             from the time stored in the pwdExpirationWarned to arrive 
             at the first warning age. If the age is greater than the 
             value in the pwdExpireWarning attribute, the password has 
             expired.  
       
          If the password has expired, the server MUST check for 
          remaining grace logins. 
       
                       If the pwdGraceUseTime attribute is present, the server 
             MUST count the number of values in that attribute and 
             subtract it from the pwdGraceLoginLimit. A positive result 
             specifies the number of remaining grace logins. 
       
                       If there are remaining grace logins, the server MUST add a 
             new value with the current time in pwdGraceUseTime. Then 
             it MUST send a bindResponse with the resultCode: success 
             (0), and MUST include the passwordPolicyResponse in the 
             controls field of the bindResponse message with the 
             warning: graceLoginsRemaining choice set to the number of 
             grace logins left. 
       
                       If there are no remaining grace logins, the server MUST 
             send a bindResponse with the resultCode: 
             invalidCredentials (49), and MUST include the 
             passwordPolicyResponse in the controls field of the 
             bindResponse message with the error: passwordExpired (0) 
             set. 
          
          If the password has not expired, execution continues.