1 INTERNET-DRAFT Donna Skibbie
2 Kerberos Working Group IBM
3 Intended Category: Standards Track Jonathan Trostle
4 Expires 2 Sept 2001 Cisco
11 Kerberos KDC LDAP Schema
12 draft-skibbie-krb-kdc-ldap-schema-01.txt
16 1. Status Of This Memo
18 This document is an Internet-Draft and is in full conformance
19 with all provisions of Section 10 of RFC 2026 [1].
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
26 Internet-Drafts are draft documents valid for a maximum of six
27 months and may be updated, replaced, or obsoleted by other
28 documents at any time. It is inappropriate to use Internet-
29 Drafts as reference material or to cite them other than as "work
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
42 This document defines a schema for storing attributes (with
43 the exception of key attributes) used by implementations of
44 Kerberos Version 5 Key Distribution Center (KDC) service in
45 a directory that implements the Lightweight Directory Access
46 Protocol (LDAP) Version 3. The directory must implement the
47 LDAP Version 3 protocol as defined in RFC 2251 [2], RFC 2252 [3],
48 RFC 2253 [4], and RFC 2256 [5]. The schema defined in this
49 document is referred to as the "KDC LDAP schema." The KDC
50 LDAP schema includes definitions for attributes defining a
51 realm, a realm policy, principals, and principal policies.
52 The KDC LDAP schema does NOT include definitions for attributes
55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
57 this document are to be interpreted as described in RFC 2119 [6].
63 The KDC LDAP schema is designed to meet four objectives. The
64 first objective is to use LDAP schema definitions defined in RFC
65 2252, RFC 2256, and existing LDAP implementations. The second
66 objective is to provide a way of sharing common security
67 attributes, such as password policy attributes, with non-Kerberos
68 applications. The third objective is to provide a way of
69 protecting sensitive information. The fourth objective is to
70 promote inter-operability between different implementations of the
73 The following figure illustrates the KDC LDAP schema:
75 -------------------- -------------
76 : DN:KrbRealmName= : : Any DN :
77 : <realm name>, ...: : with :
78 ----------- : KrbRealm, : optional : KrbPolicy :
79 :Any DN :<------: KrbRealmExt, :--------->: :
80 : : n 1: and (optionally) : 1 1 : :
81 ----------- : KrbPolicy : : :
82 1:: -------------------- -------------
88 ------------------- ------------:
89 : Any DN with : : Any DN :
90 : KrbPrincipal : 1 optional 1 : with :
91 : and (optionally):-------------------------->: KrbPolicy :
93 ------------------- -------------
97 :---------------------
98 : DN: cn=KrbLog, ... :
101 :--------------------:
103 The figure uses the following notations:
105 * Each box represents an LDAP directory entry used by a KDC.
106 The information in each box indicates whether the KDC
107 requires the entry to be assigned a special LDAP
108 distinguished name (DN) or contain KDC attributes, or both.
109 For example, the box in the top middle represents an entry
110 that must contain a DN with a relative distinguished name
111 (RDN) of "krbRealmName=<realm name>" (for example,
112 "krbRealmName=REALM1.COM, ou=Austin") and be configured with
113 KrbRealm, KrbRealmExt, and (optionally) KrbPolicy attributes.
115 * The vertical line between the KrbPrincipal and KrbLog
116 entries represents a parent-child directory information tree
117 (DIT) association between the DNs of these two entries. (For
118 example, if the KrbPrincipal entry DN is "cn=Alice Smith,
119 cn=Managers, ou=Austin", the KrbLog entry DN must be
120 "cn=KrbLog, cn=Alice Smith, cn=Managers, ou=Austin".)
122 * The double vertical line between the entry at the top left
123 corner and the KrbPrincipal entry represents an ancestor-
124 child DIT association between the DNs of these two entries.
125 (For example, if the DN of the top left corner entry is
126 "ou=Austin", the DN of the KrbPrincipal entry could be
127 "cn=Alice Smith, cn=Managers, ou=Austin".)
129 * Each arrow represents an optional forward reference between
130 two entries. (For example, the arrow from the KrbPrincipal
131 entry to the KrbPolicy entry indicates that the KrbPrincipal
132 entry optionally can be configured with an attribute
133 containing the DN of the KrbPolicy entry.)
139 The attributes defining a realm are included in the KrbRealm
140 structural object class and the KrbRealmExt auxiliary object
141 class. These attributes must be stored in an entry that is
142 referred to as the "realm entry." The RDN of the realm entry must
143 be "krbRealmName=<realm_name>", where realm name is the name of
144 the realm. The following attributes are required:
146 * krbRealmName--The name of the realm
148 * krbPrincSubTree--The DN of each entry representing a sub-tree
149 under which principals in the realm reside. This attribute allows
150 the identity who configures the realm entry to determine which
151 sub-trees can be trusted to contain entries defining principals in
154 * krbKdcServiceObject--The DN of each entry representing a KDC
155 service in the realm.
157 The following is an example of a realm entry:
159 DN: krbRealmName=PAYROLL, ou=Austin
160 objectclass: KrbRealm
161 krbRealmName: Payroll
162 krbPrincSubTree: cn=users, ou=Austin
163 objectclass: KrbRealmExt
164 krbKdcServiceObject: serviceName=serverA, dc=payroll, ou=Austin
165 krbKdcServiceObject: serviceName=serverB, dc=payroll, ou=Austin
166 <additional KrbRealmExt attributes>
170 3.2 Realm Policy Attributes
172 The attributes defining the policy for the realm are included in
173 the KrbPolicy auxiliary object class. These attributes must be
174 stored in the realm entry, an entry referenced by the
175 krbPolicyObject attribute of the realm entry, or both entries.
176 If the same policy attribute is stored in both entries, the
177 policy attribute in the realm entry takes precedence.
179 The following is an example with the policy attributes configured
182 DN: krbRealmName=PAYROLL, ou=Austin
183 objectclass: KrbRealm
184 objectclass: KrbRealmExt
185 <KrbRealm and KrbRealmExt attributes>
186 objectclass: KrbPolicy
187 <KrbPolicy attributes>
189 The following is an example with the policy attributes configured
190 in a referenced entry:
192 DN: krbRealmName=PAYROLL, ou=Austin
193 objectclass: KrbRealm
194 objectclass: KrbRealmExt
195 <KrbRealm and KrbRealmExt attributes>
196 krbPolicyObject: cn=MyPolicy, ou=Austin
198 DN: cn=MyPolicy, ou=Austin
199 objectclass: PasswordPolicy
200 <PasswordPolicy attributes>
201 objectclass: KrbPolicy
202 <KrbPolicy attributes>
206 3.3 Principal Entries
208 The attributes defining each principal in the realm are included
209 in the KrbPrincipal auxiliary object class. These attributes can
210 be stored in any entry that meets the following requirements:
212 * The entry must reside under a sub-tree listed in the
213 krbPrincSubTree attribute of the entry representing the realm in
214 which the principal will reside
216 * The entry must not already be configured to represent a
219 The entry where the KrbPrincipal attributes are stored is
220 referred to as a "principal entry." A principal entry must
221 contain the krbPrincipalName attribute. This attribute contains
222 the Kerberos identity of the principal in the format
223 "<principal>@<realm>", where <principal> is the name of the
224 principal and <realm> is the name of the realm. The Kerberos
225 principal identity must be unique within the realm.
227 The following is an example of a person entry configured
228 as a principal entry:
230 DN: cn=Alice Smith, cn=users, ou=Austin
233 <additional Person attributes>
234 objectclass: KrbPrincipal
235 krbPrincipalName: alice@PAYROLL
236 <additional KrbPrincipal attributes>
240 3.4 Principals Associated with Other Entries (Optional)
242 The schema provides an optional way of associating a principal
243 entry with another entry through the use of aliases. This
244 association is ignored by the KDC, but can be used by higher-
245 level applications to associate a principal with a target entry
246 and to verify that the target entry accepts this association.
248 There are three reasons why it might be necessary to configure
249 alias associations. One reason is to allow an entry already
250 configured with a principal identity to be associated with other
251 principal identities. Another reason is to allow an entry
252 configured in a remote part of the directory to be associated
253 with a principal identity configured in a local part of the
254 directory. A third reason is to allow an entry configured in a
255 less secure part of the directory to be associated with a
256 principal identity configured in more secure part of the
259 The association is configured by doing both of the following:
261 * adding the krbAliasedObjectName attribute from the KrbAlias
262 auxiliary object class to the principal entry and configuring
263 krbAliasedObjectName to reference the target entry
265 * adding krbHintAliases attribute from the KrbAlias auxiliary
266 object class to the target entry and configuring krbHintAliases
267 attribute to reference the principal entry.
269 The following is an example in which the Alice Smith person
270 entry, which already is configured as the principal identity of
271 alice@PAYROLL, is associated with a second principal identity of
274 DN: cn=Alice Smith, cn=users, ou=Austin
277 <additional Person attributes>
278 objectclass: KrbPrincipal
279 krbPrincipalName: alice@PAYROLL
280 <additional KrbPrincipal attributes>
281 objectclass: KrbAlias
282 krbHintAliases: cn=alice@PURCHASING, krbRealmName=PURCHASING,
285 DN: cn=alice@PURCHASING, krbRealmName=PURCHASING, ou=Austin
289 objectclass: KrbPrincipal
290 krbPrincipalName: alice@PURCHASING
291 <additional KrbPrincipal attributes>
292 objectclass: KrbAlias
293 krbAliasedObjectName: cn=Alice Smith, cn=users, ou=Austin
295 The following is an example of an association between a principal
296 entry for bob@PAYROLL and a person entry for Bob Jones that
297 exists in a remote or more secure part of the directory:
299 DN: cn=bob@PAYROLL, cn=users, ou=Austin
303 objectclass: KrbPrincipal
304 krbPrincipalName: bob@PAYROLL
305 <additional KrbPrincipal attributes>
306 objectclass: KrbAlias
307 krbAliasedObjectName: cn=Bob Jones, ou=Raleigh
309 DN: cn=Bob Jones, ou=Raleigh
312 <additional Person attributes>
313 objectclass: KrbAlias
314 krbHintAliases: cn=bob@PAYROLL, cn=users, ou=Austin
317 3.6 Principal Policy Attributes
319 The attributes defining the policy for the principal are included
320 in the KrbPolicy auxiliary object class. These attributes must be
321 stored in the principal entry, an entry referenced by the
322 krbPolicyObject of the principal entry, or both entries. If the
323 same policy attribute is stored in both entries, the policy
324 attribute in the principal entry takes precedence.
327 3.5 Principal Log (KrbLog) Entries
329 The attributes defining a login activity record for a principal
330 are included in the KrbLog structural object class. These
331 attributes must be stored in the KrbLog entry that resides
332 directly below the principal entry. The RDN of this entry must
333 be "cn=KrbLog". The creator of this entry must be a DN that
334 represents a KDC service in the realm (a DN listed in the
335 krbKdcServiceObject attribute of the realm entry)
337 The following is an example of a KrbLog entry.
339 DN: cn=KrbLog, cn=Alice Smith, cn=users, ou=Austin
347 The KDC LDAP schema uses the following syntaxes in attribute type
350 * Syntaxes listed in RFC 2252
352 * The interval syntax
354 The interval syntax is defined in the Microsoft Active Directory
355 schema. The definition is as follows:
358 1.2.840.113556.1.4.906
360 DESC 'Large integer. Use for 64-bit values.
367 The KDC LDAP schema uses the attribute types listed in this
368 section and RFC 2256.
372 5.1 New Attribute Types
377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
379 DESC 'The location of an ACL database for a Kerberos
380 administration services, The location must be specified as in
381 URL format; i.e., FILE://path/filename.'
382 EQUALITY caseExactMatch
386 krbAdmKeyLocation-oid
387 NAME 'krbAdmKeyLocation'
388 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
390 DESC 'The location of a keytab file containing the key used by
391 the Kerberos administration services, The location must be
392 specified as in URL format; i.e., FILE://path/filename.'
393 EQUALITY caseExactMatch
397 krbAdmServiceObject-oid
398 NAME 'krbAdmServiceObject'
399 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
400 DESC 'A set of references to entries, with each entry
401 representing a Kerberos administration service in the realm.'
406 krbAliasedObjectName-oid
407 NAME 'krbAliasedObjectName'
408 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
410 DESC 'Forward reference to the entry for which this entry is an
418 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
420 DESC "A value containing one or more flags. The following flags
422 KRB5_KDB_NEW_PRINC = 0x00008000
423 KRB5_KDB_PWCHANGE_SERVICE = 0x00002000
424 KRB5_KDB_REQUIRES_HW_AUTH = 0x00000100
425 KRB5_KDB_REQUIRES_PWCHANGE = 0x00000200
426 KRB5_KDB_SUPPORT_DESMD5 = 0x00004000
427 KRB5_KDB_DISALLOW_DUP_SKEY = 0x00000020
428 KRB5_KDB_DISALLOW_POSTDATED = 0x00000001
429 KRB5_KDB_DIALLOW_PROXIABLE = 0x00000010
430 KRB5_KDB_DISALLOW_RENEWABLE = 0x00000008
431 KRB5_KDB_DIALLOW_TGT_BASED = 0x00000004
432 USER_TO_USER = 0x00010000
433 KRB5_KDB_DISALLOW_SVR = 0x00001000'
438 NAME 'krbCreatorsName'
439 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
441 DESC 'The identity that first added KrbPrincipal attributes to a
442 principal entry. It is the responsibility of this identity to
443 add the krbCreatorsName attribute to the principal entry. If a
444 principal entry does not contain a krbCreatorsName attribute, the
445 LDAP system-controlled creatorsName attribute is assumed to
446 contain the correct creator identity.'
451 krbCreateTimestamp-oid
452 NAME 'krbCreateTimestamp'
453 SYNTAX 1.2.840.113556.1.4.906 (interval)
455 DESC 'The date and time when the identity stored in the
456 krbCreatorsName attribute first added the KrbPrincipal attributes
457 to a principal entry. It is the responsibility of the identity
458 named in the krbCreatorsName attribute to add the
459 krbCreateTimestamp attribute to the principal entry. '
464 NAME 'krbCurKeyVersion'
465 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
466 DESC 'A value indicating the current version of a key.'
470 krbEncTypeSupport-oid
471 NAME 'krbEncTypeSupport'
472 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
473 DESC 'A set of supported encryption type values. See krbKeyType
474 for encryption type values. The available values are:
476 ENCTYPE_DES_CBC_CRC 01 (DES cbc mode with CRC-32)
477 ENCTYPE_DES_CBC_MD4 02 (DES cbc mode with RSA-MD4)
478 ENCTYPE_DES_CBC_MD5 03 (DES cbc mode with RSA-MD5)
479 ENCTYPE_DES_CBC_RAW 04 (DES cbc mode raw)
480 ENCTYPE_DES3_CBC_SHA 05 (DES-3 cbc mode with NIST-SHA)
481 ENCTYPE_DES3_CBC_RAW 06 (DES-3 cbc mode raw)
482 ENCTYPE_RSA_PRIVKEY 91 (RSA private key; required for
490 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
492 DESC 'Extra data that is associated with a Kerberos principal and
493 that has an application-specific meaning. This attribute is
494 provided to support the Kerberos kadmin APIs.'
495 EQUALITY 'caseExactMatch'
500 NAME 'krbHintAliases'
501 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
502 DESC 'A set of backward references to entries that can serve as
503 aliases for this entry.'
508 krbKdcServiceObject-oid
509 NAME 'krbKdcServiceObject'
510 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
511 DESC 'A set of references to entries, with each entry
512 representing a KDC service in the realm.'
519 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (IA5String)
520 DESC 'A set of key types. Each key type is specified in
521 the following format:
528 "enc type" is two decimal characters indicating the encryption
529 type of the key. See krbEncTypeSupport for a list of available
530 encryption type values.
531 "salt type" is two decimal characters indicating
532 the salt type of the key. See krbSaltTypeSupport for a list of
533 available salt type values.
534 For example, "0199" indicates a key that is generated with DES
535 encryption and no salt. As another example, "0500" indicates that
536 a key that is generated using triple DES encryption and a normal
542 NAME 'krbModifiersName'
543 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
545 DESC 'The last modifier of any KDC attribute associated with a
546 principal entry. It is the responsibility of the identity that
547 modifies any attributes associated with a principal entry to add
548 or update the krbModifiersName attribute. If a principal entry
549 does not contain a krbModifiersName attribute, the LDAP system-
550 controlled modifiersName attribute of this entry is used to get
551 the identity that last modified the principal entry.'
556 krbModifyTimestamp-oid
557 NAME 'krbModifyTimestamp'
558 SYNTAX 1.2.840.113556.1.4.906 (interval)
560 DESC 'The date and time when the identity specified in the
561 krbModifiersName attribute made the last modification. It is the
562 responsibility of the identity that made the modification to add
563 or update the krbModifyTimestamp attribute. '
567 krbMultKeyVersionsOK-oid
568 NAME 'krbMultKeyVersionsOK'
569 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean)
571 DESC 'True if multiple versions of a key for each encryption type
572 can be stored for this account.'
578 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
580 DESC 'Name for a Kerberos policy in the form <policy>@<realm>.
581 <policy> is the name of a policy and must be unique within
582 the realm. <realm> is the name of the realm. The realm
583 name must conform to the rules described in RFC 1510 and
584 must be the same as the realm name specified in the
585 krbRealmName attribute of the realm entry.'
586 EQUALITY caseExactMatch
591 NAME 'krbPolicyObject'
592 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
594 DESC 'Forward reference to an entry containing policy
601 NAME 'krbPrincipalName'
602 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
604 DESC 'Kerberos principal identity for a user in the form
605 <principal>@<realm>. <principal> is the name of the principal
606 and must conform to the rules described in RFC 1510. <realm> is
607 the realm name. The realm name must conform to the rules
608 described in RFC 1510 and must be the same as the realm name
609 specified in the krbRealmName attribute of the realm entry.'
610 EQUALITY caseExactMatch
615 NAME 'krbPrincipalType'
616 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
618 DESC 'Value defining the type of a principal. The available
619 principal type values are:
621 1 = KRB5_NT_PRINCIPAL
630 NAME 'krbPrincSubTree
631 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
632 DESC 'A set of forward references to an entry that starts a sub-
633 tree where principals in the realm are configured.'
638 krbPwdServiceObject-oid
639 NAME 'krbPwdServiceObject'
640 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
641 DESC 'A set of references to entries, with each entry
642 representing a password service in the realm.'
649 SYNTAX 1.3.6. 11.4.1.1466.115.121.1.15 (directory string)
651 DESC 'Name of a security realm. The realm name must
652 conform to the rules listed in RFC 1510.'
653 EQUALITY caseExactMatch
657 krbRedundancyPolicy-oid
658 NAME 'krbRedundancyPolicy'
659 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
661 DESC 'One of the following values indicating which set of
662 attributes to use for those attributes that have the same logical
664 01 -- Use the set of attributes from the Netscape or IBM/Tivoli
666 02 -- Use the set of attributes from the Microsoft schema. The
667 following table lists the sets of attributes that have the same
668 logical meanings and the schema's in which these attributes are
670 -------------------------------------
671 Netscape or Microsoft
674 -------------------------------------
675 passwordExpireTime computed from pwdLastSet and maxPwdAge
676 passwordMaxAge maxPwdAge
677 passwordMinAge minPwdAge
678 passwordMinLength minPwdLength
679 secAcctExpires accountExpires
680 secAcctValid userAccountControl (!ACCOUNT_DISABLE)
685 krbSaltTypeSupport-oid
686 NAME 'krbSaltTypeSupport'
687 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
688 DESC 'A set of values defining the supported salt types. See the
689 krbKeyType attribute for a list of salt types. The available
691 KRB5_KDB_SALTTYPE_NORMAL = 0
692 KRB5_KDB_SALTTYPE_V4 = 1
693 KRB5_KDB_SALTTYPE_NOREALM = 2
694 KRB5_KDB_SALTTYPE_ONLYREALM = 3
695 KRB5_KDB_SALTTYPE_SPECIAL = 4
696 KRB5_KDB_SALTTYPE_AFS3 = 5
697 KRB5_KDB_NO_SALT_VALUE = 99'
701 krbTaggedDataList-oid
702 NAME 'krbTaggedDataList'
703 SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 (binary)
704 DESC 'Set of tagged data structures that is associated with a
705 Kerberos principal and that is defined by a Kerberos kadmin
706 application. This attribute is provided to support the Kerberos
711 krbTrustedAdmObject-oid
712 NAME 'krbTrustedAdmObject'
713 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
714 DESC 'A set of forward references to trusted administration tools.
721 5.2 Attribute Types Defined in the Netscape Schema
724 2.16.840.1.113730.3.1.97
725 NAME 'passwordMaxAge'
726 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
727 DESC 'Specifies, in seconds, the period of time passwords can be
728 used before they expire.'
733 NAME 'passwordMinAge'
734 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
735 DESC 'Specifies, in seconds, the period of time a password must
736 be in effect before a user can change it.'
740 2.16.840.1.113730.3.1.99
741 NAME 'passwordMinLength'
742 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
743 DESC 'Specifies the minimum number of characters required for a
749 5.3 Attribute Types Defined in the Microsoft Active Directory
753 1.2.840.113556.1.4.159
754 NAME 'accountExpires'
755 SYNTAX 1.2.840.113556.1.4.906 (interval)
757 DESC 'A value indicating when the account will expire. The value
758 is stored as a large integer that represents the number of seconds
759 elapsed since 00:00:00, January 1, 1970. A value of TIMEQ_FOREVER
760 (-1) indicates that the account never expires.'
764 1.2.840.113556.1.4.49
765 NAME 'badPasswordTime'
766 SYNTAX 1.2.840.113556.1.4.906 (interval)
768 DESC 'A value indicating the last time the user tried to log onto
769 the account using an incorrect password. The value is stored as
770 a large integer that represents the number of seconds elapsed
771 since 00:00:00, January 1, 1970. A value of zero (0) means the
772 last password time is unknown. Each KDC server in the realm
773 maintains its own badPasswordTime attribute. To get an accurate
774 value for the user's last bad password time in the realm, the
775 badPasswordTime attribute of each KDC server must be queried, and
776 the largest value should be used.'
780 1.2.840.113556.1.4.12
782 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
784 DESC 'A value indicating the number of times the user tried
785 to log on to the account using an incorrect password.
786 A value of zero (0) indicates that the value is unknown.
787 Each KDC server in the realm maintains its own badPwdCount
788 attribute.To get an accurate value for the user's total bad
789 password attempts in the realm, the badPwdCount attribute of each
790 KDC server in the realm must be queried, and the sum of the values
795 1.2.840.113556.1.4.52
797 SYNTAX 1.2.840.113556.1.4.906 (interval)
799 DESC 'A value indicating when the last logon occurred.
800 The value is stored as a large integer that represents
801 the number of seconds elapsed since 00:00:00, January 1, 1970.
802 A value of zero (0) means that the last logon time is
803 unknown. Each KDC server maintains its own lastLogon attribute.
804 To get an accurate value for the user's last logon in
805 the domain, the lastLogon attribute of each KDC server in the
806 realm must be queried, and the largest value should be used.'
811 1.2.840.113556.1.4.95
812 NAME 'pwdHistoryLength'
813 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
815 DESC 'A value indicating the number of previous passwords saved
816 in the history list. The user cannot reuse a password that is in
821 1.2.840.113556.1.4.96
823 SYNTAX 1.2.840.113556.1.4.906 (interval)
825 DESC 'A value indicating when the user last set the password.
826 The value is stored as a large integer that represents
827 the number of seconds elapsed since 00:00:00, January 1, 1970.
828 The system uses the value of this property and the maxPwdAge
829 property of the domain containing the user object to calculate
830 the password expiration date (sum of pwdLastSet for the user and
831 maxPwdAge of the user's domain).'
835 1.2.840.113556.1.4.74
837 SYNTAX 1.2.840.113556.1.4.906 (interval)
839 DESC 'A value indicating the maximum amount of time, in seconds,
840 after which the password must be changed by the owner.'
844 1.2.840.113556.1.4.75
846 SYNTAX 1.2.840.113556.1.4.906 (interval)
848 DESC 'Value indicating the maximum renewable lifetime, in seconds,
849 of a Kerberos ticket.'
853 1.2.840.113556.1.4.77
855 SYNTAX 1.2.840.113556.1.4.906 (interval)
857 DESC 'A value indicating the maximum lifetime, in seconds,
858 of a Kerberos ticket.'
862 1.2.840.113556.1.4.78
864 SYNTAX 1.2.840.113556.1.4.906 (interval)
866 DESC 'A value indicating the minimum amount of time, in seconds,
867 before the password is allowed to be changed.'
871 1.2.840.113556.1.4.79
873 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
875 DESC 'A value indicating the minimum number of characters that
877 be typed in for a password.'
882 NAME 'userAccountControl'
883 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
885 DESC 'A value containing one or more attributes that apply to an
886 account. Each attribute is set with a flag. Refer to the
887 Microsoft Active Directory documentation for a complete list of
888 flags. The following flags are used in this KDC LDAP schema:
889 UF_ACCOUNT_DISABLE = 0x0001
890 UF_DONT_EXPIRE_PASSWD = 0x10000
891 UF_TRUSTED_FOR_DELEGATION = 0x80000
892 UF_USE_DES_KEY_ONLY = 0x200000
893 UF_DONT_REQUIRE_PREAUTH = 0x400000'
898 5.4 Attribute Types Defined in the IBM/Tivoli Schema
902 NAME 'passwordDictFiles'
903 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
904 DESC 'Password dictionary files.'
905 EQUALITY caseExactMatch
910 NAME 'passwordExpireTime'
911 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime)
912 DESC ' Defines, in YYYYMMDDHHMMSS format, the date and time when
913 a user password expires.'
918 NAME 'passwordMinDiffChars'
919 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
920 DESC 'Specifies the minimum number of different (unique)
921 characters required for a user's password.'
925 1.3.6.1.4.1.4228.1.12
926 NAME 'secAcctExpires'
927 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime)
929 DESC 'The date when a security account expires.'
935 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean)
937 DESC 'A boolean value indicating whether a security account is
945 The KDC LDAP schema uses the object classes listed in this
951 DESC 'An auxiliary object class for use in configuring an
952 association between an entry containing security identity
953 information and another entry. The krbAliasedObjectName is
954 configured in the entry with a security identity information and
955 contains a forward reference to a target entry. The
956 krbHintAliases attribute is configured in the target entry and
957 contains a backward reference to the entry with the security
958 identity information. Kerberos ignores the forward and backward
959 references. However, higher level applications can use these
960 references to associate a security identity with a target entry
961 and then verify that the target entry allows this association.
962 For example, a higher level application can use the forward
963 reference to associate an entry representing a Kerberos principal
964 with an entry representing a person, and then use the backward
965 reference to determine whether the entry representing the person
966 allows this association.'
969 MAY (krbAliasedObjectName krbHintAliases)
975 DESC 'A structural object class for use in configuring an entry
976 to represent a Kerberos login activity record for an associated
977 Kerberos principal. The entry representing the Kerberos login
978 activity record must reside directly below the entry representing
979 the associated Kerberos principal and must have a creator
980 identity that is a KDC service in the realm. (The DN recorded by
981 LDAP in the creatorsName attribute of the entry representing the
982 Kerberos login activity record must be listed in the
983 krbKdcServiceObject attribute of the entry representing the
984 realm.) The relationship between the entry representing the
985 Kerberos login activity record and the entry representing the
986 associated Kerberos principal is one-to-many. This is because
987 multiple KrbLog entries can be crreated for a single principal
988 with each KrbLog entry maintained by a different KDC service.
989 The RDN of the entry representing the Kerberos login activity
994 MAY ( badPasswordTime $ badPwdCount $ lastLogon)
1000 DESC ' An auxiliary object class for use in configuring Kerberos
1001 policy attributes for an associated Kerberos principal or
1002 Kerberos realm. The Kerberos policy attributes can reside in the
1003 entry representing the Kerberos principal or realm, the entry
1004 referenced by the krbPolicyObject attribute of the entry
1005 representing the Kerberos principal or realm, or both. If the
1006 same policy attribute is configured in both entries, the policy
1007 attribute from the entry representing the principal or realm is
1008 used. Some Kerberos policy values can be configured using one of
1009 two sets of attributes. For these attributes, the
1010 krbRedundancyPolicy attribute in the entry representing the realm
1011 determines which set of attributes to use. (For example, the
1012 maximum password lifetime value can be stored in the maxPwdAge or
1013 passwordMaxAge attribute. The krbRedundancyPolicy attribute
1014 determines which of these two attributes to use.)'
1017 MAY ( accountExpires $ krbAttributes $ krbPolicyName $ maxPwdAge
1018 $ maxRenewAge $ maxTicketAge $ minPwdAge $ minPwdLength $
1019 krbMultKeyVersionsOK $ passwordExpireTime $ passwordDictFiles
1020 $ passwordMaxAge $ passwordMinAge $ passwordMinDiffChars $
1021 passwordMinLength $ pwdHistoryLength $ secAcctExpires $
1022 secAcctValid $ userAccountControl)
1028 DESC 'An auxiliary class for use in configuring an entry to
1029 represent a Kerberos principal.
1032 MUST (krbPrincipalName)
1033 MAY (krbCurKeyVersion $ krbCreatorsName $ krbCreateTimestamp $
1034 krbExtraData $ krbModifiersName $ krbModifyTimestamp $
1035 krbPolicyObject $ krbPrincipalType $ krbTaggedDataList $
1042 DESC A structural object class for use in configuring an entry
1043 to represent a Kerberos realm. The RDN of this entry must
1044 contain a string that indicates the contents of the krbRealmName
1045 attribute; for example, "krbRealmName=COM.XYZ".'
1048 MUST ( krbPrincSubTree $ krbRealmName )
1054 DESC 'An auxiliary object class for use in configuring additional
1055 attributes in an entry representing a Kerberos realm.'
1058 MAY ( krbAdmAclDB $ krbAdmServiceObject $ krbEncTypeSupport $
1059 krbKdcServiceObject $ krbKeyType $ krbPolicyObject $
1060 krbPwdServiceObject $ krbRedundancyPolicy $
1061 krbSaltTypeSupport $ krbTrustedAdmObject )
1066 7. Security Considerations
1068 ---------------------------------------------------
1069 AUTHENTICATION DISCLOSURE:
1071 This document describes a directory access protocol
1072 that provides both read and update access. Update
1073 access and read access to sensitive information requires
1074 secure authentication, but this document does
1075 not mandate implementation of any satisfactory
1076 authentication mechanisms.
1078 In accordance with RFC 2026, section 4.4.1, this
1079 specification is being considered by IESG as a
1080 proposed standard despite this limitation, for the
1082 a. to encourage implementation and interoperability
1083 testing of these protocols (with or without update
1084 access) before they are deployed, and
1085 b. to encourage deployment and use of these
1086 protocols in read-only applications. (e.g.
1087 applications where LDAPv3 is used as a query language
1088 for directories which are updated by some secure
1089 mechanism other than LDAP), and
1090 c. to avoid delaying the advancement and deployment
1091 of other Internet standards-track protocols which
1092 require the ability to query, but not update, LDAPv3
1095 Readers are hereby warned that until mandatory
1096 authentication mechanisms that are as strong or stronger
1097 than Kerberos are standardized, clients and servers
1098 written according to this specification which make
1099 make use of update functionality or the reading
1100 of private information are UNLIKELY TO
1101 INTER-OPERATE, or MAY INTER-OPERATE ONLY IF AUTHENTICATION
1102 IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. (RFC 2829 [7]
1103 mandates that LDAP servers supporting authentication
1104 based on user ID and password implement the digest
1105 authentication protocol defined in RFC 2831 [8],
1106 but this mechanism is considered to be weaker
1109 Implementers are hereby discouraged from deploying
1110 LDAPv3 clients or servers that implement the update
1111 functionality or the reading of sensitive information
1112 until a Proposed Standard for a strong mandatory
1113 authentication mechanism in LDAPv3 has been approved
1114 and published as an RFC.
1116 ------------------------------------------------------------
1119 The following entities must be trusted to protect KDC attributes
1120 as described in this section:
1122 * Administrators of the KDC LDAP schema
1123 * KDC services that use the KDC LDAP schema
1124 * LDAP client libraries used to access the KDC LDAP schema
1125 * LDAP servers and backend databases with access to the KDC LDAP
1127 * Administrators of LDAP servers and backend databases with access
1132 7.1. Security Considerations for Administrators of the KDC LDAP
1135 All administrators of the KDC LDAP schema must be trusted and are
1138 * Ensuring that KDC attributes are configured in LDAP locations
1139 that can be accessed only by LDAP servers that comply with the
1140 security considerations described in "Section 7.4. Security
1141 Considerations for LDAP Servers and Backend Databases with Access
1142 to the KDC LDAP Schema".
1144 * If LDAP client libraries are used to access the attributes in
1145 the schema, ensuring that these libraries comply with the security
1146 considerations described in "Section 7.3. Security Considerations
1147 for LDAP Client Libraries Used to Access the KDC LDAP Schema"
1149 * Ensuring that KDC attributes are transmitted securely to and
1150 from the LDAP server. If KDC attributes are transmitted over the
1151 network, they must be transmitted using a security protocol with
1152 client and server authentication and data integrity.
1154 * Protecting the realm entry so that only trusted identities can
1155 modify, delete, or add attributes in the entry; only trusted
1156 identities can rename or delete the entry; only trusted identities
1157 can insert new entries under the entry; and only trusted
1158 identities can read the values in the krbKdcServiceObject
1159 and krbTrustedAdmObject attributes.
1161 * Protecting each LDAP sub-tree referenced by krbPrincSubTree so
1162 that only trusted identities can add, modify, or delete KDC
1163 attributes residing under the sub-tree.
1165 * Protecting each LDAP entry referenced by krbPolicyObject so that
1166 so that only trusted identities can add, modify, or delete
1167 attributes in the entry.
1169 * Before retrieving attributes from a KrbLog entry, verifying that
1170 the entry was created by a KDC service in the realm.
1174 7.2. Security Considerations for KDC Servers that Use the KDC
1177 All KDC servers that use the KDC LDAP schema must be trusted and
1178 are responsible for:
1180 * Using LDAP client routines that comply with the security
1181 considerations described in "Section 7.3. Security Considerations
1182 for LDAP Client Libraries Used to Access the KDC LDAP Schema."
1184 * Transmitting KDC attributes securely to and from LDAP. If KDC
1185 attributes are transmitted over the network, they must be
1186 transmitted using a security protocol with client and server
1187 authentication and data integrity.
1189 * When creating a KrbLog entry, protecting this entry so that only
1190 a KDC service in the realm can modify, delete, and insert this
1191 entry; and only a KDC service or a trusted identity in the realm
1192 can delete or rename this entry.
1194 * Before retrieving attributes from a KrbLog entry, verifying that
1195 the entry was created by KDC service in the realm.
1199 7.3. Security Considerations for LDAP Client Libraries Used to
1200 Access the KDC LDAP Schema
1202 All LDAP client libraries used to access the KDC LDAP schema must
1203 be trusted and are responsible for protecting this information
1204 from other identities on the same machine.
1206 If a trusted LDAP client library cannot be obtained, it would be
1207 possible to develop a trusted LDAP client library, which could be
1208 used by KDC servers, administrators of the KDC LDAP schema, and
1209 administrators of LDAP servers that access the KDC LDAP schema.
1210 The estimated lines of code required to develop such a library is
1211 included in the estimated lines of code required to develop the
1212 libraries used by a trusted LDAP server. (See the next section.)
1216 7.4. Security Considerations for LDAP Servers and Backend
1217 Databases that Can Access the KDC LDAP Schema
1219 All LDAP servers and backend databases of LDAP servers that have
1220 access to the KDC LDAP schema must be trusted and are responsible
1223 * If remote access is supported, providing a security protocol for
1224 transmitting attributes over the network. The protocol must
1225 support client and server authentication and data integrity, and
1226 must be as strong or stronger than the Kerberos authentication
1229 * Providing a way to protect attributes from unauthorized access.
1231 * Providing a way to audit access to attributes.
1233 * Replicating attributes only to other trusted LDAP servers and
1234 backend databases, and replicating these attributes in a secure
1235 manner. If KDC attributes are transmitted over the network
1236 to a replica, they must be transmitted using a security protocol
1237 with client and server authentication and data integrity.
1239 * If Kerberos is used to authenticate the KDC to the LDAP server, then
1240 the LDAP server secret key may not be accessible over the network.
1242 If it is impossible to obtain an LDAP server that meets the level
1243 of trust described in this section, it would be possible to
1244 develop a trusted LDAP server that reads and writes KDC attributes
1245 to a small trusted database, such as a database used by a legacy
1246 KDC. The estimated lines of code required to develop such an LDAP
1249 Backend routines for storing KDC
1250 attributes in a trusted database: 4K of new code
1252 LDAP libraries and includes: 25K of ported/analyzed code from
1255 LDAP server (SLAPD): 12K of ported/analyzed code from
1257 LDAP replication server (SLURPD): 2K of ported/analyzed code
1258 from OpenLDAP source
1262 7.5. Security Considerations for Administrators that Manage LDAP
1263 Servers and Backend Database with Access to the KDC LDAP Schema
1265 The administrator of each LDAP server and backend database with
1266 access to attributes in the KDC LDAP schema is responsible for:
1268 * If LDAP client libraries are used to access the attributes in
1269 the schema, ensuring that these libraries comply with the security
1270 considerations described in "Section 7.3. Security Considerations
1271 for LDAP Client Libraries Used to Access the KDC LDAP Schema."
1273 * Enabling auditing of LDAP servers and backend databases when
1276 * Ensuring that the LDAP servers will not allow a client to
1277 authenticate its identity to the LDAP server using an
1278 authentication protocol that is weaker than the Kerberos
1279 authentication protocol.
1285 The authors wish to thank the members of The Open Group Directory
1286 Interoperability Forum for their contributions to this document.
1292 This draft expires September 2, 2001.
1298 [1] Bradner, S., "The Internet Standards Process -- Revision 3",
1299 BCP 9, RFC 2026, October 1996.
1301 [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
1302 Access Protocol (v3)", RFC 2251, December 1997.
1304 [3] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
1305 X.500 Directory Access Protocol (v3): Attribute Syntax
1306 Definitions", RFC 2252, December 1997.
1308 [4] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
1309 Access Protocol (v3): UTF-8 String Representation of
1310 Distinguished Names", RFC 2253, December 1997.
1312 [5] Wahl, M., "A Summary of the X.500(96) User Schema for use
1313 with LDAPv3", RFC 2256, December 1997.
1315 [6] J. Kohl, C. Neuman. The Kerberos Network Authentication
1316 Service (V5), Request for Comments 1510.
1318 [7] Wahl, M. Authentication Methods for LDAP, Request for Comments
1321 [8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
1322 Mechanism", RFC 2831, May 2000.
1326 11. Authors' Addresses
1332 Phone: (512) 838-3896
1333 Email: donnas@us.ibm.com
1339 E-mail: jtrostle@cisco.com
1342 Entegrity Solutions Corporation
1345 Email: john.griffith@entegrity.com