Newer
Older
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.