Update gnulib files.
[shishi.git] / doc / specifications / draft-skibbie-krb-kdc-ldap-schema-01.txt
blob9bcf3290b81a3c5f2d324ce99a9615f03daa95f2
1 INTERNET-DRAFT                               Donna Skibbie
2 Kerberos Working Group                       IBM
3 Intended Category:  Standards Track          Jonathan Trostle
4 Expires 2 Sept 2001                          Cisco
5                                              John Griffith
6                                              Entegrity Solutions
7                                              2 March 2001
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-
24 Drafts.
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
30 in progress."
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.
40 2. Abstract
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
53 used to store keys.
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].
61 3. Overview
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
71 Kerberos KDC.
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::           --------------------          -------------
83       ::
84       ::
85       ::
86       ::
87      n::
88  -------------------                           ------------:
89  : Any DN with     :                           : Any DN    :
90  : KrbPrincipal    : 1     optional          1 : with      :
91  : and (optionally):-------------------------->: KrbPolicy :
92  : KrbPolicy       :                           :           :
93  -------------------                           -------------
94       1:
95        :
96       1:
97  :---------------------
98  : DN: cn=KrbLog, ... :
99  : KrbLog             :
100  :                    :
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.)
137 3.1 Realm 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
152 the realm.
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
180 in the realm entry:
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
217 Kerberos principal
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
231   objectclass: Person
232   cn: Alice Smith
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
257 directory.
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
272 alice@PURCHASING.
274   DN: cn=Alice Smith, cn=users, ou=Austin
275   objectclass: Person
276   cn: Alice Smith
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,
283 ou=Austin
285   DN: cn=alice@PURCHASING, krbRealmName=PURCHASING, ou=Austin
286   objectclass: Person
287   cn: alice@PURCHASING
288   sn: alice@PURCHASING
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
300   objectclass: Person
301   cn: bob@PAYROLL
302   sn: bob@PAYROLL
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
310   objectclass: Person
311   cn: Bob Jones
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
340   objectclass: KrbLog
341   <KrbLog attributes>
345 4. Syntaxes
347 The KDC LDAP schema uses the following syntaxes in attribute type
348 definitions:
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
359 NAME 'Interval'
360 DESC 'Large integer.  Use for 64-bit values.
365 5. Attribute Types
367 The KDC LDAP schema uses the attribute types listed in this
368 section and RFC 2256.
372 5.1 New Attribute Types
375 krbAdmAclDB-oid
376 NAME 'krbAdmAclDB'
377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
378 SINGLE-VALUE
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)
389 SINGLE-VALUE
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.'
402 EQUALITY dnMatch
406 krbAliasedObjectName-oid
407 NAME 'krbAliasedObjectName'
408 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
409 SINGLE-VALUE
410 DESC 'Forward reference to the entry for which this entry is an
411 alias.'
412 EQUALITY dnMatch
416 krbAttributes-oid
417 NAME 'krbAttributes'
418 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
419 SINGLE-VALUE
420 DESC "A value containing one or more flags.  The following flags
421 are available:
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'
437 krbCreatorsName-oid
438 NAME 'krbCreatorsName'
439 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
440 SINGLE-VALUE
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.'
447 EQUALITY dnMatch
451 krbCreateTimestamp-oid
452 NAME 'krbCreateTimestamp'
453 SYNTAX 1.2.840.113556.1.4.906 (interval)
454 SINGLE-VALUE
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.  '
463 krbCurKeyVersion-oid
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:
475   ENCTYPE_NULL 00
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
483 support of DCE)
484   ENCTYPE_UNKNOWN 99'
488 krbExtraData-oid
489 NAME 'krbExtraData'
490 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
491 SINGLE-VALUE
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'
499 krbHintAliases-oid
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.'
504 EQUALITY dnMatch
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.'
513 EQUALITY dnMatch
517 krbKeyType-oid
518 NAME 'krbKeyType'
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:
522 0  1  2  3  4
523 +--+--+--+--+
524 | enc |salt |
525 |type |type |
526 +--+--+--+--+
527 where
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
537 salt type value.'
541 krbModifiersName-oid
542 NAME 'krbModifiersName'
543 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
544 SINGLE-VALUE
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.'
552 EQUALITY dnMatch
556 krbModifyTimestamp-oid
557 NAME 'krbModifyTimestamp'
558 SYNTAX 1.2.840.113556.1.4.906 (interval)
559 SINGLE-VALUE
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)
570 SINGLE-VALUE
571 DESC 'True if multiple versions of a key for each encryption type
572 can be stored for this account.'
576 krbPolicyName-oid
577 NAME 'krbPolicyName'
578 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
579 SINGLE-VALUE
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
590 krbPolicyObject-oid
591 NAME 'krbPolicyObject'
592 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN)
593 SINGLE-VALUE
594 DESC 'Forward reference to an entry containing policy
595 information.'
596 EQUALITY dnMatch
600 krbPrincipalName-oid
601 NAME 'krbPrincipalName'
602 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string)
603 SINGLE-VALUE
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
614 krbPrincipalType-oid
615 NAME 'krbPrincipalType'
616 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
617 SINGLE-VALUE
618 DESC 'Value defining the type of a principal.  The available
619 principal type values are:
620 0 = KRB5_NT_UNKNOWN
621 1 = KRB5_NT_PRINCIPAL
622 2 = KRB5_NT_SRV_INST
623 3 = KRB5_NT_SRV_HST
624 4 = KRB5_NT_SRV_XHST
625 5 = KRB5_NT_UID'
629 krbPrincSubTree-oid
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.'
634 EQUALITY dnMatch
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.'
643 EQUALITY dnMatch
647 krbRealmName-oid
648 NAME 'krbRealmName'
649 SYNTAX 1.3.6. 11.4.1.1466.115.121.1.15 (directory string)
650 SINGLE-VALUE
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)
660 SINGLE-VALUE
661 DESC 'One of the following values indicating which set of
662 attributes to use for those attributes that have the same logical
663 meaning:
664 01 -- Use the set of attributes from the Netscape or IBM/Tivoli
665 schema (default)
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
669 defined:
670 -------------------------------------
671 Netscape or            Microsoft
672 IBM/Tivoli             Schema
673 Schema
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
690 values are:
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
707 kadmin APIs.'
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.
716 EQUALITY dnMatch
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.'
732 1.3.18.0.2.4.465
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
744 user's password.'
749 5.3 Attribute Types Defined in the Microsoft Active Directory
750 Schema
753 1.2.840.113556.1.4.159
754 NAME 'accountExpires'
755 SYNTAX 1.2.840.113556.1.4.906 (interval)
756 SINGLE-VALUE
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)
767 SINGLE-VALUE
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
781 NAME 'badPwdCount'
782 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
783 SINGLE-VALUE
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
791 should be used.'
795 1.2.840.113556.1.4.52
796 NAME 'lastLogon'
797 SYNTAX 1.2.840.113556.1.4.906 (interval)
798 SINGLE-VALUE
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)
814 SINGLE-VALUE
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
817 the history list.'
821 1.2.840.113556.1.4.96
822 NAME 'pwdLastSet'
823 SYNTAX 1.2.840.113556.1.4.906 (interval)
824 SINGLE-VALUE
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
836 NAME 'maxPwdAge'
837 SYNTAX 1.2.840.113556.1.4.906 (interval)
838 SINGLE-VALUE
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
845 NAME 'maxRenewAge'
846 SYNTAX 1.2.840.113556.1.4.906 (interval)
847 SINGLE-VALUE
848 DESC 'Value indicating the maximum renewable lifetime, in seconds,
849 of a Kerberos ticket.'
853 1.2.840.113556.1.4.77
854 NAME 'maxTicketAge'
855 SYNTAX 1.2.840.113556.1.4.906 (interval)
856 SINGLE-VALUE
857 DESC 'A value indicating the maximum lifetime, in seconds,
858 of a Kerberos ticket.'
862 1.2.840.113556.1.4.78
863 NAME 'minPwdAge'
864 SYNTAX 1.2.840.113556.1.4.906 (interval)
865 SINGLE-VALUE
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
872 NAME 'minPwdLength'
873 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
874 SINGLE-VALUE
875 DESC 'A value indicating the minimum number of characters that
876 must
877 be typed in for a password.'
881 1.2.840.113556.1.4.8
882 NAME 'userAccountControl'
883 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer)
884 SINGLE-VALUE
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
901 1.3.18.0.2.4.463
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
909 1.3.18.0.2.4.485
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.'
917 1.3.18.0.2.4.499
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)
928 SINGLE-VALUE
929 DESC 'The date when a security account expires.'
933 1.3.6.1.4.1.4228.1.4
934 NAME 'secAcctValid'
935 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean)
936 SINGLE-VALUE
937 DESC 'A boolean value indicating whether a security account is
938 valid.'
943 6. Object Classes
945 The KDC LDAP schema uses the object classes listed in this
946 section.
949 KrbAlias-oid
950 NAME 'KrbAlias'
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.'
967 SUP top
968 Auxiliary
969 MAY (krbAliasedObjectName krbHintAliases)
973 KrbLog-oid
974 NAME 'KrbLog'
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
990 must be "cn=KrbLog".
991 SUP top
992 Structural
993 MUST ( cn )
994 MAY ( badPasswordTime $ badPwdCount $ lastLogon)
998 KrbPolicy-oid
999 NAME 'KrbPolicy'
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.)'
1015 SUP top
1016 Auxiliary
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)
1026 KrbPrincipal-oid
1027 NAME 'KrbPrincipal'
1028 DESC 'An auxiliary class for use in configuring an entry to
1029 represent a Kerberos principal.
1030 SUP top
1031 Auxiliary
1032 MUST (krbPrincipalName)
1033 MAY (krbCurKeyVersion $ krbCreatorsName $ krbCreateTimestamp $
1034 krbExtraData $ krbModifiersName $ krbModifyTimestamp $
1035 krbPolicyObject $ krbPrincipalType $ krbTaggedDataList $
1036 pwdLastSet)
1040 KrbRealm-oid
1041 NAME 'KrbRealm'
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".'
1046 SUP top
1047 Structural
1048 MUST ( krbPrincSubTree $ krbRealmName )
1052 KrbRealmExt-oid
1053 NAME 'KrbRealmExt'
1054 DESC 'An auxiliary object class for use in configuring additional
1055 attributes in an entry representing a Kerberos realm.'
1056 SUP KrbPolicy
1057 Auxiliary
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
1081      following reasons:
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
1093      directory servers.
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
1107      than the Kerberos.)
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
1126 schema
1127 * Administrators of LDAP servers and backend databases with access
1128 to KDC attributes
1132 7.1.  Security Considerations for Administrators of the KDC LDAP
1133 Schema
1135 All administrators of the KDC LDAP schema must be trusted and are
1136 responsible for:
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
1175 LDAP Schema
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
1221 for:
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
1227 protocol.
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
1247 server is:
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
1253                                  OpenLDAP source
1255     LDAP server (SLAPD):  12K of ported/analyzed code from
1256                           OpenLDAP source
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
1274 required.
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.
1283 8. Acknowledgments
1285 The authors wish to thank the members of The Open Group Directory
1286 Interoperability Forum for their contributions to this document.
1290 9. Expiration Date
1292 This draft expires September 2, 2001.
1296 10. Bibliography
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
1319 2829, May 2000.
1321 [8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
1322 Mechanism", RFC 2831, May 2000.
1326 11. Authors' Addresses
1328 Donna Skibbie
1329 IBM Corporation
1330 1140 Burnet Road
1331 Austin, TX  78758
1332 Phone:  (512) 838-3896
1333 Email:  donnas@us.ibm.com
1335 Jonathan Trostle
1336 Cisco Systems
1337 170 W. Tasman Dr.
1338 San Jose, CA  95134
1339 E-mail: jtrostle@cisco.com
1341 John Griffith
1342 Entegrity Solutions Corporation
1343 32 DW Highway
1344 Merrimack, NH  03054
1345 Email: john.griffith@entegrity.com