INTERNET-DRAFT Donna Skibbie Kerberos Working Group IBM Intended Category: Standards Track Jonathan Trostle Expires 2 Sept 2001 Cisco John Griffith Entegrity Solutions 2 March 2001 Kerberos KDC LDAP Schema draft-skibbie-krb-kdc-ldap-schema-01.txt 1. Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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. 2. Abstract This document defines a schema for storing attributes (with the exception of key attributes) used by implementations of Kerberos Version 5 Key Distribution Center (KDC) service in a directory that implements the Lightweight Directory Access Protocol (LDAP) Version 3. The directory must implement the LDAP Version 3 protocol as defined in RFC 2251 [2], RFC 2252 [3], RFC 2253 [4], and RFC 2256 [5]. The schema defined in this document is referred to as the "KDC LDAP schema." The KDC LDAP schema includes definitions for attributes defining a realm, a realm policy, principals, and principal policies. The KDC LDAP schema does NOT include definitions for attributes used to store keys. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. 3. Overview The KDC LDAP schema is designed to meet four objectives. The first objective is to use LDAP schema definitions defined in RFC 2252, RFC 2256, and existing LDAP implementations. The second objective is to provide a way of sharing common security attributes, such as password policy attributes, with non-Kerberos applications. The third objective is to provide a way of protecting sensitive information. The fourth objective is to promote inter-operability between different implementations of the Kerberos KDC. The following figure illustrates the KDC LDAP schema: -------------------- ------------- : DN:KrbRealmName= : : Any DN : : , ...: : with : ----------- : KrbRealm, : optional : KrbPolicy : :Any DN :<------: KrbRealmExt, :--------->: : : : n 1: and (optionally) : 1 1 : : ----------- : KrbPolicy : : : 1:: -------------------- ------------- :: :: :: :: n:: ------------------- ------------: : Any DN with : : Any DN : : KrbPrincipal : 1 optional 1 : with : : and (optionally):-------------------------->: KrbPolicy : : KrbPolicy : : : ------------------- ------------- 1: : 1: :--------------------- : DN: cn=KrbLog, ... : : KrbLog : : : :--------------------: The figure uses the following notations: * Each box represents an LDAP directory entry used by a KDC. The information in each box indicates whether the KDC requires the entry to be assigned a special LDAP distinguished name (DN) or contain KDC attributes, or both. For example, the box in the top middle represents an entry that must contain a DN with a relative distinguished name (RDN) of "krbRealmName=" (for example, "krbRealmName=REALM1.COM, ou=Austin") and be configured with KrbRealm, KrbRealmExt, and (optionally) KrbPolicy attributes. * The vertical line between the KrbPrincipal and KrbLog entries represents a parent-child directory information tree (DIT) association between the DNs of these two entries. (For example, if the KrbPrincipal entry DN is "cn=Alice Smith, cn=Managers, ou=Austin", the KrbLog entry DN must be "cn=KrbLog, cn=Alice Smith, cn=Managers, ou=Austin".) * The double vertical line between the entry at the top left corner and the KrbPrincipal entry represents an ancestor- child DIT association between the DNs of these two entries. (For example, if the DN of the top left corner entry is "ou=Austin", the DN of the KrbPrincipal entry could be "cn=Alice Smith, cn=Managers, ou=Austin".) * Each arrow represents an optional forward reference between two entries. (For example, the arrow from the KrbPrincipal entry to the KrbPolicy entry indicates that the KrbPrincipal entry optionally can be configured with an attribute containing the DN of the KrbPolicy entry.) 3.1 Realm Entry The attributes defining a realm are included in the KrbRealm structural object class and the KrbRealmExt auxiliary object class. These attributes must be stored in an entry that is referred to as the "realm entry." The RDN of the realm entry must be "krbRealmName=", where realm name is the name of the realm. The following attributes are required: * krbRealmName--The name of the realm * krbPrincSubTree--The DN of each entry representing a sub-tree under which principals in the realm reside. This attribute allows the identity who configures the realm entry to determine which sub-trees can be trusted to contain entries defining principals in the realm. * krbKdcServiceObject--The DN of each entry representing a KDC service in the realm. The following is an example of a realm entry: DN: krbRealmName=PAYROLL, ou=Austin objectclass: KrbRealm krbRealmName: Payroll krbPrincSubTree: cn=users, ou=Austin objectclass: KrbRealmExt krbKdcServiceObject: serviceName=serverA, dc=payroll, ou=Austin krbKdcServiceObject: serviceName=serverB, dc=payroll, ou=Austin 3.2 Realm Policy Attributes The attributes defining the policy for the realm are included in the KrbPolicy auxiliary object class. These attributes must be stored in the realm entry, an entry referenced by the krbPolicyObject attribute of the realm entry, or both entries. If the same policy attribute is stored in both entries, the policy attribute in the realm entry takes precedence. The following is an example with the policy attributes configured in the realm entry: DN: krbRealmName=PAYROLL, ou=Austin objectclass: KrbRealm objectclass: KrbRealmExt objectclass: KrbPolicy The following is an example with the policy attributes configured in a referenced entry: DN: krbRealmName=PAYROLL, ou=Austin objectclass: KrbRealm objectclass: KrbRealmExt krbPolicyObject: cn=MyPolicy, ou=Austin DN: cn=MyPolicy, ou=Austin objectclass: PasswordPolicy objectclass: KrbPolicy 3.3 Principal Entries The attributes defining each principal in the realm are included in the KrbPrincipal auxiliary object class. These attributes can be stored in any entry that meets the following requirements: * The entry must reside under a sub-tree listed in the krbPrincSubTree attribute of the entry representing the realm in which the principal will reside * The entry must not already be configured to represent a Kerberos principal The entry where the KrbPrincipal attributes are stored is referred to as a "principal entry." A principal entry must contain the krbPrincipalName attribute. This attribute contains the Kerberos identity of the principal in the format "@", where is the name of the principal and is the name of the realm. The Kerberos principal identity must be unique within the realm. The following is an example of a person entry configured as a principal entry: DN: cn=Alice Smith, cn=users, ou=Austin objectclass: Person cn: Alice Smith objectclass: KrbPrincipal krbPrincipalName: alice@PAYROLL 3.4 Principals Associated with Other Entries (Optional) The schema provides an optional way of associating a principal entry with another entry through the use of aliases. This association is ignored by the KDC, but can be used by higher- level applications to associate a principal with a target entry and to verify that the target entry accepts this association. There are three reasons why it might be necessary to configure alias associations. One reason is to allow an entry already configured with a principal identity to be associated with other principal identities. Another reason is to allow an entry configured in a remote part of the directory to be associated with a principal identity configured in a local part of the directory. A third reason is to allow an entry configured in a less secure part of the directory to be associated with a principal identity configured in more secure part of the directory. The association is configured by doing both of the following: * adding the krbAliasedObjectName attribute from the KrbAlias auxiliary object class to the principal entry and configuring krbAliasedObjectName to reference the target entry * adding krbHintAliases attribute from the KrbAlias auxiliary object class to the target entry and configuring krbHintAliases attribute to reference the principal entry. The following is an example in which the Alice Smith person entry, which already is configured as the principal identity of alice@PAYROLL, is associated with a second principal identity of alice@PURCHASING. DN: cn=Alice Smith, cn=users, ou=Austin objectclass: Person cn: Alice Smith objectclass: KrbPrincipal krbPrincipalName: alice@PAYROLL objectclass: KrbAlias krbHintAliases: cn=alice@PURCHASING, krbRealmName=PURCHASING, ou=Austin DN: cn=alice@PURCHASING, krbRealmName=PURCHASING, ou=Austin objectclass: Person cn: alice@PURCHASING sn: alice@PURCHASING objectclass: KrbPrincipal krbPrincipalName: alice@PURCHASING objectclass: KrbAlias krbAliasedObjectName: cn=Alice Smith, cn=users, ou=Austin The following is an example of an association between a principal entry for bob@PAYROLL and a person entry for Bob Jones that exists in a remote or more secure part of the directory: DN: cn=bob@PAYROLL, cn=users, ou=Austin objectclass: Person cn: bob@PAYROLL sn: bob@PAYROLL objectclass: KrbPrincipal krbPrincipalName: bob@PAYROLL objectclass: KrbAlias krbAliasedObjectName: cn=Bob Jones, ou=Raleigh DN: cn=Bob Jones, ou=Raleigh objectclass: Person cn: Bob Jones objectclass: KrbAlias krbHintAliases: cn=bob@PAYROLL, cn=users, ou=Austin 3.6 Principal Policy Attributes The attributes defining the policy for the principal are included in the KrbPolicy auxiliary object class. These attributes must be stored in the principal entry, an entry referenced by the krbPolicyObject of the principal entry, or both entries. If the same policy attribute is stored in both entries, the policy attribute in the principal entry takes precedence. 3.5 Principal Log (KrbLog) Entries The attributes defining a login activity record for a principal are included in the KrbLog structural object class. These attributes must be stored in the KrbLog entry that resides directly below the principal entry. The RDN of this entry must be "cn=KrbLog". The creator of this entry must be a DN that represents a KDC service in the realm (a DN listed in the krbKdcServiceObject attribute of the realm entry) The following is an example of a KrbLog entry. DN: cn=KrbLog, cn=Alice Smith, cn=users, ou=Austin objectclass: KrbLog 4. Syntaxes The KDC LDAP schema uses the following syntaxes in attribute type definitions: * Syntaxes listed in RFC 2252 * The interval syntax The interval syntax is defined in the Microsoft Active Directory schema. The definition is as follows: ( 1.2.840.113556.1.4.906 NAME 'Interval' DESC 'Large integer. Use for 64-bit values. ) 5. Attribute Types The KDC LDAP schema uses the attribute types listed in this section and RFC 2256. 5.1 New Attribute Types ( krbAdmAclDB-oid NAME 'krbAdmAclDB' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'The location of an ACL database for a Kerberos administration services, The location must be specified as in URL format; i.e., FILE://path/filename.' EQUALITY caseExactMatch ) ( krbAdmKeyLocation-oid NAME 'krbAdmKeyLocation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'The location of a keytab file containing the key used by the Kerberos administration services, The location must be specified as in URL format; i.e., FILE://path/filename.' EQUALITY caseExactMatch ) ( krbAdmServiceObject-oid NAME 'krbAdmServiceObject' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of references to entries, with each entry representing a Kerberos administration service in the realm.' EQUALITY dnMatch ) ( krbAliasedObjectName-oid NAME 'krbAliasedObjectName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) SINGLE-VALUE DESC 'Forward reference to the entry for which this entry is an alias.' EQUALITY dnMatch ) ( krbAttributes-oid NAME 'krbAttributes' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC "A value containing one or more flags. The following flags are available: KRB5_KDB_NEW_PRINC = 0x00008000 KRB5_KDB_PWCHANGE_SERVICE = 0x00002000 KRB5_KDB_REQUIRES_HW_AUTH = 0x00000100 KRB5_KDB_REQUIRES_PWCHANGE = 0x00000200 KRB5_KDB_SUPPORT_DESMD5 = 0x00004000 KRB5_KDB_DISALLOW_DUP_SKEY = 0x00000020 KRB5_KDB_DISALLOW_POSTDATED = 0x00000001 KRB5_KDB_DIALLOW_PROXIABLE = 0x00000010 KRB5_KDB_DISALLOW_RENEWABLE = 0x00000008 KRB5_KDB_DIALLOW_TGT_BASED = 0x00000004 USER_TO_USER = 0x00010000 KRB5_KDB_DISALLOW_SVR = 0x00001000' ) ( krbCreatorsName-oid NAME 'krbCreatorsName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) SINGLE-VALUE DESC 'The identity that first added KrbPrincipal attributes to a principal entry. It is the responsibility of this identity to add the krbCreatorsName attribute to the principal entry. If a principal entry does not contain a krbCreatorsName attribute, the LDAP system-controlled creatorsName attribute is assumed to contain the correct creator identity.' EQUALITY dnMatch ) ( krbCreateTimestamp-oid NAME 'krbCreateTimestamp' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'The date and time when the identity stored in the krbCreatorsName attribute first added the KrbPrincipal attributes to a principal entry. It is the responsibility of the identity named in the krbCreatorsName attribute to add the krbCreateTimestamp attribute to the principal entry. ' ) ( krbCurKeyVersion-oid NAME 'krbCurKeyVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'A value indicating the current version of a key.' ) ( krbEncTypeSupport-oid NAME 'krbEncTypeSupport' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'A set of supported encryption type values. See krbKeyType for encryption type values. The available values are: ENCTYPE_NULL 00 ENCTYPE_DES_CBC_CRC 01 (DES cbc mode with CRC-32) ENCTYPE_DES_CBC_MD4 02 (DES cbc mode with RSA-MD4) ENCTYPE_DES_CBC_MD5 03 (DES cbc mode with RSA-MD5) ENCTYPE_DES_CBC_RAW 04 (DES cbc mode raw) ENCTYPE_DES3_CBC_SHA 05 (DES-3 cbc mode with NIST-SHA) ENCTYPE_DES3_CBC_RAW 06 (DES-3 cbc mode raw) ENCTYPE_RSA_PRIVKEY 91 (RSA private key; required for support of DCE) ENCTYPE_UNKNOWN 99' ) ( krbExtraData-oid NAME 'krbExtraData' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'Extra data that is associated with a Kerberos principal and that has an application-specific meaning. This attribute is provided to support the Kerberos kadmin APIs.' EQUALITY 'caseExactMatch' ) ( krbHintAliases-oid NAME 'krbHintAliases' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of backward references to entries that can serve as aliases for this entry.' EQUALITY dnMatch ) ( krbKdcServiceObject-oid NAME 'krbKdcServiceObject' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of references to entries, with each entry representing a KDC service in the realm.' EQUALITY dnMatch ) ( krbKeyType-oid NAME 'krbKeyType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (IA5String) DESC 'A set of key types. Each key type is specified in the following format: 0 1 2 3 4 +--+--+--+--+ | enc |salt | |type |type | +--+--+--+--+ where "enc type" is two decimal characters indicating the encryption type of the key. See krbEncTypeSupport for a list of available encryption type values. "salt type" is two decimal characters indicating the salt type of the key. See krbSaltTypeSupport for a list of available salt type values. For example, "0199" indicates a key that is generated with DES encryption and no salt. As another example, "0500" indicates that a key that is generated using triple DES encryption and a normal salt type value.' ) ( krbModifiersName-oid NAME 'krbModifiersName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) SINGLE-VALUE DESC 'The last modifier of any KDC attribute associated with a principal entry. It is the responsibility of the identity that modifies any attributes associated with a principal entry to add or update the krbModifiersName attribute. If a principal entry does not contain a krbModifiersName attribute, the LDAP system- controlled modifiersName attribute of this entry is used to get the identity that last modified the principal entry.' EQUALITY dnMatch ) ( krbModifyTimestamp-oid NAME 'krbModifyTimestamp' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'The date and time when the identity specified in the krbModifiersName attribute made the last modification. It is the responsibility of the identity that made the modification to add or update the krbModifyTimestamp attribute. ' ) ( krbMultKeyVersionsOK-oid NAME 'krbMultKeyVersionsOK' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean) SINGLE-VALUE DESC 'True if multiple versions of a key for each encryption type can be stored for this account.' ) ( krbPolicyName-oid NAME 'krbPolicyName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'Name for a Kerberos policy in the form @. is the name of a policy and must be unique within the realm. is the name of the realm. The realm name must conform to the rules described in RFC 1510 and must be the same as the realm name specified in the krbRealmName attribute of the realm entry.' EQUALITY caseExactMatch ) ( krbPolicyObject-oid NAME 'krbPolicyObject' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) SINGLE-VALUE DESC 'Forward reference to an entry containing policy information.' EQUALITY dnMatch ) ( krbPrincipalName-oid NAME 'krbPrincipalName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'Kerberos principal identity for a user in the form @. is the name of the principal and must conform to the rules described in RFC 1510. is the realm name. The realm name must conform to the rules described in RFC 1510 and must be the same as the realm name specified in the krbRealmName attribute of the realm entry.' EQUALITY caseExactMatch ) ( krbPrincipalType-oid NAME 'krbPrincipalType' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'Value defining the type of a principal. The available principal type values are: 0 = KRB5_NT_UNKNOWN 1 = KRB5_NT_PRINCIPAL 2 = KRB5_NT_SRV_INST 3 = KRB5_NT_SRV_HST 4 = KRB5_NT_SRV_XHST 5 = KRB5_NT_UID' ) ( krbPrincSubTree-oid NAME 'krbPrincSubTree SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of forward references to an entry that starts a sub- tree where principals in the realm are configured.' EQUALITY dnMatch ) ( krbPwdServiceObject-oid NAME 'krbPwdServiceObject' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of references to entries, with each entry representing a password service in the realm.' EQUALITY dnMatch ) ( krbRealmName-oid NAME 'krbRealmName' SYNTAX 1.3.6. 11.4.1.1466.115.121.1.15 (directory string) SINGLE-VALUE DESC 'Name of a security realm. The realm name must conform to the rules listed in RFC 1510.' EQUALITY caseExactMatch ) ( krbRedundancyPolicy-oid NAME 'krbRedundancyPolicy' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'One of the following values indicating which set of attributes to use for those attributes that have the same logical meaning: 01 -- Use the set of attributes from the Netscape or IBM/Tivoli schema (default) 02 -- Use the set of attributes from the Microsoft schema. The following table lists the sets of attributes that have the same logical meanings and the schema's in which these attributes are defined: ------------------------------------- Netscape or Microsoft IBM/Tivoli Schema Schema ------------------------------------- passwordExpireTime computed from pwdLastSet and maxPwdAge passwordMaxAge maxPwdAge passwordMinAge minPwdAge passwordMinLength minPwdLength secAcctExpires accountExpires secAcctValid userAccountControl (!ACCOUNT_DISABLE) ' ) ( krbSaltTypeSupport-oid NAME 'krbSaltTypeSupport' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'A set of values defining the supported salt types. See the krbKeyType attribute for a list of salt types. The available values are: KRB5_KDB_SALTTYPE_NORMAL = 0 KRB5_KDB_SALTTYPE_V4 = 1 KRB5_KDB_SALTTYPE_NOREALM = 2 KRB5_KDB_SALTTYPE_ONLYREALM = 3 KRB5_KDB_SALTTYPE_SPECIAL = 4 KRB5_KDB_SALTTYPE_AFS3 = 5 KRB5_KDB_NO_SALT_VALUE = 99' ) ( krbTaggedDataList-oid NAME 'krbTaggedDataList' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 (binary) DESC 'Set of tagged data structures that is associated with a Kerberos principal and that is defined by a Kerberos kadmin application. This attribute is provided to support the Kerberos kadmin APIs.' ) ( krbTrustedAdmObject-oid NAME 'krbTrustedAdmObject' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 (DN) DESC 'A set of forward references to trusted administration tools. ' EQUALITY dnMatch ) 5.2 Attribute Types Defined in the Netscape Schema ( 2.16.840.1.113730.3.1.97 NAME 'passwordMaxAge' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'Specifies, in seconds, the period of time passwords can be used before they expire.' ) ( 1.3.18.0.2.4.465 NAME 'passwordMinAge' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'Specifies, in seconds, the period of time a password must be in effect before a user can change it.' ) ( 2.16.840.1.113730.3.1.99 NAME 'passwordMinLength' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'Specifies the minimum number of characters required for a user's password.' ) 5.3 Attribute Types Defined in the Microsoft Active Directory Schema ( 1.2.840.113556.1.4.159 NAME 'accountExpires' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating when the account will expire. The value is stored as a large integer that represents the number of seconds elapsed since 00:00:00, January 1, 1970. A value of TIMEQ_FOREVER (-1) indicates that the account never expires.' ) ( 1.2.840.113556.1.4.49 NAME 'badPasswordTime' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating the last time the user tried to log onto the account using an incorrect password. The value is stored as a large integer that represents the number of seconds elapsed since 00:00:00, January 1, 1970. A value of zero (0) means the last password time is unknown. Each KDC server in the realm maintains its own badPasswordTime attribute. To get an accurate value for the user's last bad password time in the realm, the badPasswordTime attribute of each KDC server must be queried, and the largest value should be used.' ) ( 1.2.840.113556.1.4.12 NAME 'badPwdCount' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value indicating the number of times the user tried to log on to the account using an incorrect password. A value of zero (0) indicates that the value is unknown. Each KDC server in the realm maintains its own badPwdCount attribute.To get an accurate value for the user's total bad password attempts in the realm, the badPwdCount attribute of each KDC server in the realm must be queried, and the sum of the values should be used.' ) ( 1.2.840.113556.1.4.52 NAME 'lastLogon' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating when the last logon occurred. The value is stored as a large integer that represents the number of seconds elapsed since 00:00:00, January 1, 1970. A value of zero (0) means that the last logon time is unknown. Each KDC server maintains its own lastLogon attribute. To get an accurate value for the user's last logon in the domain, the lastLogon attribute of each KDC server in the realm must be queried, and the largest value should be used.' ) ( 1.2.840.113556.1.4.95 NAME 'pwdHistoryLength' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value indicating the number of previous passwords saved in the history list. The user cannot reuse a password that is in the history list.' ) ( 1.2.840.113556.1.4.96 NAME 'pwdLastSet' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating when the user last set the password. The value is stored as a large integer that represents the number of seconds elapsed since 00:00:00, January 1, 1970. The system uses the value of this property and the maxPwdAge property of the domain containing the user object to calculate the password expiration date (sum of pwdLastSet for the user and maxPwdAge of the user's domain).' ) ( 1.2.840.113556.1.4.74 NAME 'maxPwdAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating the maximum amount of time, in seconds, after which the password must be changed by the owner.' ) ( 1.2.840.113556.1.4.75 NAME 'maxRenewAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'Value indicating the maximum renewable lifetime, in seconds, of a Kerberos ticket.' ) ( 1.2.840.113556.1.4.77 NAME 'maxTicketAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating the maximum lifetime, in seconds, of a Kerberos ticket.' ) ( 1.2.840.113556.1.4.78 NAME 'minPwdAge' SYNTAX 1.2.840.113556.1.4.906 (interval) SINGLE-VALUE DESC 'A value indicating the minimum amount of time, in seconds, before the password is allowed to be changed.' ) ( 1.2.840.113556.1.4.79 NAME 'minPwdLength' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value indicating the minimum number of characters that must be typed in for a password.' ) ( 1.2.840.113556.1.4.8 NAME 'userAccountControl' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) SINGLE-VALUE DESC 'A value containing one or more attributes that apply to an account. Each attribute is set with a flag. Refer to the Microsoft Active Directory documentation for a complete list of flags. The following flags are used in this KDC LDAP schema: UF_ACCOUNT_DISABLE = 0x0001 UF_DONT_EXPIRE_PASSWD = 0x10000 UF_TRUSTED_FOR_DELEGATION = 0x80000 UF_USE_DES_KEY_ONLY = 0x200000 UF_DONT_REQUIRE_PREAUTH = 0x400000' ) 5.4 Attribute Types Defined in the IBM/Tivoli Schema ( 1.3.18.0.2.4.463 NAME 'passwordDictFiles' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (directory string) DESC 'Password dictionary files.' EQUALITY caseExactMatch ) ( 1.3.18.0.2.4.485 NAME 'passwordExpireTime' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime) DESC ' Defines, in YYYYMMDDHHMMSS format, the date and time when a user password expires.' ) ( 1.3.18.0.2.4.499 NAME 'passwordMinDiffChars' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 (integer) DESC 'Specifies the minimum number of different (unique) characters required for a user's password.' ) ( 1.3.6.1.4.1.4228.1.12 NAME 'secAcctExpires' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 (generalizedTime) SINGLE-VALUE DESC 'The date when a security account expires.' ) ( 1.3.6.1.4.1.4228.1.4 NAME 'secAcctValid' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (boolean) SINGLE-VALUE DESC 'A boolean value indicating whether a security account is valid.' ) 6. Object Classes The KDC LDAP schema uses the object classes listed in this section. ( KrbAlias-oid NAME 'KrbAlias' DESC 'An auxiliary object class for use in configuring an association between an entry containing security identity information and another entry. The krbAliasedObjectName is configured in the entry with a security identity information and contains a forward reference to a target entry. The krbHintAliases attribute is configured in the target entry and contains a backward reference to the entry with the security identity information. Kerberos ignores the forward and backward references. However, higher level applications can use these references to associate a security identity with a target entry and then verify that the target entry allows this association. For example, a higher level application can use the forward reference to associate an entry representing a Kerberos principal with an entry representing a person, and then use the backward reference to determine whether the entry representing the person allows this association.' SUP top Auxiliary MAY (krbAliasedObjectName krbHintAliases) ) ( KrbLog-oid NAME 'KrbLog' DESC 'A structural object class for use in configuring an entry to represent a Kerberos login activity record for an associated Kerberos principal. The entry representing the Kerberos login activity record must reside directly below the entry representing the associated Kerberos principal and must have a creator identity that is a KDC service in the realm. (The DN recorded by LDAP in the creatorsName attribute of the entry representing the Kerberos login activity record must be listed in the krbKdcServiceObject attribute of the entry representing the realm.) The relationship between the entry representing the Kerberos login activity record and the entry representing the associated Kerberos principal is one-to-many. This is because multiple KrbLog entries can be crreated for a single principal with each KrbLog entry maintained by a different KDC service. The RDN of the entry representing the Kerberos login activity must be "cn=KrbLog". SUP top Structural MUST ( cn ) MAY ( badPasswordTime $ badPwdCount $ lastLogon) ) ( KrbPolicy-oid NAME 'KrbPolicy' DESC ' An auxiliary object class for use in configuring Kerberos policy attributes for an associated Kerberos principal or Kerberos realm. The Kerberos policy attributes can reside in the entry representing the Kerberos principal or realm, the entry referenced by the krbPolicyObject attribute of the entry representing the Kerberos principal or realm, or both. If the same policy attribute is configured in both entries, the policy attribute from the entry representing the principal or realm is used. Some Kerberos policy values can be configured using one of two sets of attributes. For these attributes, the krbRedundancyPolicy attribute in the entry representing the realm determines which set of attributes to use. (For example, the maximum password lifetime value can be stored in the maxPwdAge or passwordMaxAge attribute. The krbRedundancyPolicy attribute determines which of these two attributes to use.)' SUP top Auxiliary MAY ( accountExpires $ krbAttributes $ krbPolicyName $ maxPwdAge $ maxRenewAge $ maxTicketAge $ minPwdAge $ minPwdLength $ krbMultKeyVersionsOK $ passwordExpireTime $ passwordDictFiles $ passwordMaxAge $ passwordMinAge $ passwordMinDiffChars $ passwordMinLength $ pwdHistoryLength $ secAcctExpires $ secAcctValid $ userAccountControl) ) ( KrbPrincipal-oid NAME 'KrbPrincipal' DESC 'An auxiliary class for use in configuring an entry to represent a Kerberos principal. SUP top Auxiliary MUST (krbPrincipalName) MAY (krbCurKeyVersion $ krbCreatorsName $ krbCreateTimestamp $ krbExtraData $ krbModifiersName $ krbModifyTimestamp $ krbPolicyObject $ krbPrincipalType $ krbTaggedDataList $ pwdLastSet) ) ( KrbRealm-oid NAME 'KrbRealm' DESC A structural object class for use in configuring an entry to represent a Kerberos realm. The RDN of this entry must contain a string that indicates the contents of the krbRealmName attribute; for example, "krbRealmName=COM.XYZ".' SUP top Structural MUST ( krbPrincSubTree $ krbRealmName ) ) ( KrbRealmExt-oid NAME 'KrbRealmExt' DESC 'An auxiliary object class for use in configuring additional attributes in an entry representing a Kerberos realm.' SUP KrbPolicy Auxiliary MAY ( krbAdmAclDB $ krbAdmServiceObject $ krbEncTypeSupport $ krbKdcServiceObject $ krbKeyType $ krbPolicyObject $ krbPwdServiceObject $ krbRedundancyPolicy $ krbSaltTypeSupport $ krbTrustedAdmObject ) ) 7. Security Considerations --------------------------------------------------- AUTHENTICATION DISCLOSURE: This document describes a directory access protocol that provides both read and update access. Update access and read access to sensitive information requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms. In accordance with RFC 2026, section 4.4.1, this specification is being considered by IESG as a proposed standard despite this limitation, for the following reasons: a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers. Readers are hereby warned that until mandatory authentication mechanisms that are as strong or stronger than Kerberos are standardized, clients and servers written according to this specification which make make use of update functionality or the reading of private information are UNLIKELY TO INTER-OPERATE, or MAY INTER-OPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. (RFC 2829 [7] mandates that LDAP servers supporting authentication based on user ID and password implement the digest authentication protocol defined in RFC 2831 [8], but this mechanism is considered to be weaker than the Kerberos.) Implementers are hereby discouraged from deploying LDAPv3 clients or servers that implement the update functionality or the reading of sensitive information until a Proposed Standard for a strong mandatory authentication mechanism in LDAPv3 has been approved and published as an RFC. ------------------------------------------------------------ The following entities must be trusted to protect KDC attributes as described in this section: * Administrators of the KDC LDAP schema * KDC services that use the KDC LDAP schema * LDAP client libraries used to access the KDC LDAP schema * LDAP servers and backend databases with access to the KDC LDAP schema * Administrators of LDAP servers and backend databases with access to KDC attributes 7.1. Security Considerations for Administrators of the KDC LDAP Schema All administrators of the KDC LDAP schema must be trusted and are responsible for: * Ensuring that KDC attributes are configured in LDAP locations that can be accessed only by LDAP servers that comply with the security considerations described in "Section 7.4. Security Considerations for LDAP Servers and Backend Databases with Access to the KDC LDAP Schema". * If LDAP client libraries are used to access the attributes in the schema, ensuring that these libraries comply with the security considerations described in "Section 7.3. Security Considerations for LDAP Client Libraries Used to Access the KDC LDAP Schema" * Ensuring that KDC attributes are transmitted securely to and from the LDAP server. If KDC attributes are transmitted over the network, they must be transmitted using a security protocol with client and server authentication and data integrity. * Protecting the realm entry so that only trusted identities can modify, delete, or add attributes in the entry; only trusted identities can rename or delete the entry; only trusted identities can insert new entries under the entry; and only trusted identities can read the values in the krbKdcServiceObject and krbTrustedAdmObject attributes. * Protecting each LDAP sub-tree referenced by krbPrincSubTree so that only trusted identities can add, modify, or delete KDC attributes residing under the sub-tree. * Protecting each LDAP entry referenced by krbPolicyObject so that so that only trusted identities can add, modify, or delete attributes in the entry. * Before retrieving attributes from a KrbLog entry, verifying that the entry was created by a KDC service in the realm. 7.2. Security Considerations for KDC Servers that Use the KDC LDAP Schema All KDC servers that use the KDC LDAP schema must be trusted and are responsible for: * Using LDAP client routines that comply with the security considerations described in "Section 7.3. Security Considerations for LDAP Client Libraries Used to Access the KDC LDAP Schema." * Transmitting KDC attributes securely to and from LDAP. If KDC attributes are transmitted over the network, they must be transmitted using a security protocol with client and server authentication and data integrity. * When creating a KrbLog entry, protecting this entry so that only a KDC service in the realm can modify, delete, and insert this entry; and only a KDC service or a trusted identity in the realm can delete or rename this entry. * Before retrieving attributes from a KrbLog entry, verifying that the entry was created by KDC service in the realm. 7.3. Security Considerations for LDAP Client Libraries Used to Access the KDC LDAP Schema All LDAP client libraries used to access the KDC LDAP schema must be trusted and are responsible for protecting this information from other identities on the same machine. If a trusted LDAP client library cannot be obtained, it would be possible to develop a trusted LDAP client library, which could be used by KDC servers, administrators of the KDC LDAP schema, and administrators of LDAP servers that access the KDC LDAP schema. The estimated lines of code required to develop such a library is included in the estimated lines of code required to develop the libraries used by a trusted LDAP server. (See the next section.) 7.4. Security Considerations for LDAP Servers and Backend Databases that Can Access the KDC LDAP Schema All LDAP servers and backend databases of LDAP servers that have access to the KDC LDAP schema must be trusted and are responsible for: * If remote access is supported, providing a security protocol for transmitting attributes over the network. The protocol must support client and server authentication and data integrity, and must be as strong or stronger than the Kerberos authentication protocol. * Providing a way to protect attributes from unauthorized access. * Providing a way to audit access to attributes. * Replicating attributes only to other trusted LDAP servers and backend databases, and replicating these attributes in a secure manner. If KDC attributes are transmitted over the network to a replica, they must be transmitted using a security protocol with client and server authentication and data integrity. * If Kerberos is used to authenticate the KDC to the LDAP server, then the LDAP server secret key may not be accessible over the network. If it is impossible to obtain an LDAP server that meets the level of trust described in this section, it would be possible to develop a trusted LDAP server that reads and writes KDC attributes to a small trusted database, such as a database used by a legacy KDC. The estimated lines of code required to develop such an LDAP server is: Backend routines for storing KDC attributes in a trusted database: 4K of new code LDAP libraries and includes: 25K of ported/analyzed code from OpenLDAP source LDAP server (SLAPD): 12K of ported/analyzed code from OpenLDAP source LDAP replication server (SLURPD): 2K of ported/analyzed code from OpenLDAP source 7.5. Security Considerations for Administrators that Manage LDAP Servers and Backend Database with Access to the KDC LDAP Schema The administrator of each LDAP server and backend database with access to attributes in the KDC LDAP schema is responsible for: * If LDAP client libraries are used to access the attributes in the schema, ensuring that these libraries comply with the security considerations described in "Section 7.3. Security Considerations for LDAP Client Libraries Used to Access the KDC LDAP Schema." * Enabling auditing of LDAP servers and backend databases when required. * Ensuring that the LDAP servers will not allow a client to authenticate its identity to the LDAP server using an authentication protocol that is weaker than the Kerberos authentication protocol. 8. Acknowledgments The authors wish to thank the members of The Open Group Directory Interoperability Forum for their contributions to this document. 9. Expiration Date This draft expires September 2, 2001. 10. Bibliography [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [3] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight X.500 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [4] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [5] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [6] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5), Request for Comments 1510. [7] Wahl, M. Authentication Methods for LDAP, Request for Comments 2829, May 2000. [8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. 11. Authors' Addresses Donna Skibbie IBM Corporation 1140 Burnet Road Austin, TX 78758 Phone: (512) 838-3896 Email: donnas@us.ibm.com Jonathan Trostle Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 E-mail: jtrostle@cisco.com John Griffith Entegrity Solutions Corporation 32 DW Highway Merrimack, NH 03054 Email: john.griffith@entegrity.com