Internet-Draft D. Byrne, IBM LDAP Extensions WG L. Poitou, Sun Intended Category: Standards Track E. Stokes, IBM Expires: 20 October 1998 20 April 1998 Use of Aliases within LDAP STATUS OF THIS MEMO This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com ABSTRACT This document describes the suggested behavior for aliases for LDAPv3 and above to improve LDAP server interoperability . The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [Bradner97]. 1. Objectives Aliases may be used within LDAP to reference entries anywhere within the directory tree. Conceptually, an alias is simply a pointer to the DIT entry it represents. It does not contain additional information about that entry; only the location of the entry. The behavior of the alias object within LDAP is not well- defined, both in creation of the alias object and the behavior when dereferencing the alias. For successful interoperability, the expected behavior of servers when encountering alias objects SHOULD be consistent. Additionally, it MUST be possible to use aliases without changing the LDAPv3 schema as defined in [Wahl] and without adding server-dependent data. 2. Schema Definition 2.1 Schema Expansion The alias objectclass definitions presented in the LDAPv3 Schema [Wahl] are the basis for aliasing within ldap. The alias objectclass is a Structural objectclass with a single required attribute; the single valued aliasObjectName. This definition of the alias objectclass does not allow for any attribute other than 'aliasedObjectName' to be used as the naming attribute within the RDN. The resulting dn for the alias object must therefore be of the form "aliasedObjectName=, , ..." This is not a user-friendly name for a directory entry, and quite possibly corrupts the naming hierarchy within the directory tree. In order to remain true the concept of an alias; that it is merely a pointer to another entry, an entry of objectclass alias SHOULD NOT be combined with any other objectclass. If multiple objectclasses are combined, it becomes possible to add information to the alias entry without violating the schema rules. While not explicitly specified as either a 'required' or 'may', any naming attribute MUST be allowed to form the RDN of the alias. Restricting the possible naming attributes would potentially corrupt the hierarchy. For example, it would be impossible to distinguish between a person alias and an organisation alias. 2.2 AliasObject Objectclass In order to create an alias object which can be appropriately named to that which it represents, the definition of the alias object MUST be expanded. A new objectclass must be defined which inherits from the current definition of alias but extends the attributes allowed within the RDN. ( 1.3.6.1.4.1.42.2.27.1.2.1 NAME 'aliasObject' DESC objectclass for all alias objects SUP 'ALIAS' MAY * ) The '*' allows any naming attribute to be used in forming the RDN of the object. For example, the following is a correct LDIF: dn: cn=John Doe, ou=myOrg, c=US objectclass: alias objectclass: aliasObject aliasedObjectName: cn=President, ou=myOrg, c=US cn: John Doe To prevent the alias from containing extra information about the object, the naming attribute SHOULD contain only a single value. For example, the following is not a correct LDIF: dn: cn=John Doe, ou=myOrg, c=US objectclass: alias objectclass: aliasObject aliasedObjectName: cn=President, ou=myOrg, c=US cn: John Doe cn: Doe Similarly, the following would not be a correct LDIF file because it adds extra information to the alias object. dn: cn=John Doe, ou=myOrg, c=US objectclass: alias objectclass: aliasObject aliasedObjectName: cn=President, ou=myOrg, c=US cn: John Doe title: President The naming attribute used to form the RDN of the object SHOULD reflect the naming attribute of the referenced object. However, there are some cases where the naming attribute MAY be different. Within the X.501 [ITU-T], the attribute used to described the aliased object is 'aliasedEntryName'. Since the OID for 'aliasedEntryName' and 'aliasedObjectName' are the same for both X.500 and LDAP, LDAP servers SHOULD treat the 'aliasedEntryName' as a synonym for 'aliasedObjectName'. 3. Alias Behavior In general alias objects SHOULD NOT be dereferenced during any operation other than search unless requested to do so by the client. Since an alias points to another section of the tree, it MUST NOT be possible to add an object under an alias object; alias objects MUST always be leaf nodes. During the dereferencing of aliases, a loop is detected if the server visits the same alias entry more than once. In this case a data integrity error has occurred and the server MUST return an error of 'aliasProblem' If an alias is dereferenced, and the resulting directory entry does not exists, a data integrity problem has occurred, and the server MUST return an error code of 'aliasDereferencingProblem' If the base entry for an ldapsearch is an alias, and alias dereferencing is set to either derefFindBaseObj, or derefAlways, the base entry MUST be dereferenced before the search is performed. The new base for the search will become the entry to which the alias resolves. The search is then performed. If multiple aliases are chained, the alias for the first object MUST resolve to the last entry in the chain. For example, A, B, and C are alias objects. If A points to B which points to C which points to D, A resolves to D when dereferencing the alias. If an alias is dereferenced as part of a search, the alias entry itself SHOULD NOT be returned as part of the search. If an alias matches the search filter, and dereferencing is set to 'searching' or 'always', the dereferenced object SHOULD be returned, even if it does not match the filter. If the alias is not dereferenced during the search, and it matches the filter, then it SHOULD be returned within the search result. Each directory object matching a filter SHOULD be returned only once during a search. If an entry is found twice because of aliases pointing to a part of the tree already searched, the entry SHOULD NOT be returned to the client a second time. 4. Scenarios Using the following LDIF, the scenarios would return the expected information as follows: dn: c=myCountry c: myCountry objectclass: country dn: ou=Area1, c=myCountry ou: Area1 aliasedObjectName: o=myCorporation, c=myCountry objectclass: alias objectclass:aliasObject dn: o=myCorporation, c=myCountry ou: myCorporation objectclass:organization dn: cn=President, o=myCorporation, c=myCountry cn: President aliasObjectName: cn=John Doe, o=myCorporation, c=myCountry objectclass: alias objectclass: aliasObject dn: cn=John Doe, o=myCorporation, c=myCountry cn: John Doe objectclass: person c = myCountry / | ou = Area1 -----> o = myCorporation | \ cn=President ---> cn = John Doe Performing a base search of 'ou = Area1, c=myCountry' with a filter of 'objectclass=aliasObject' NeverDerefAlias would return 'ou=Area1, c=myCountry' DerefFinding would return 'cn=President, o=myCorporation, c=myCountry' DerefSearching would return 'o=myCorporation, c=myCountry' DerefAlways would return 'cn=John Doe, o=myCorporation, c=myCountry' Performing a one level search of 'c=myCountry' with a filter of 'ou = * ' NeverDerefAlias would return 'ou=Area1, c=myCountry' DerefFinding would return 'ou=Area1, c=myCountry' DerefSearching would return 'o=myCorporation, c=myCountry' DerefAlways would return ' o=myCorporation, c=myCountry' Performing a full tree search of 'c=myCountry' with a filter of ' cn = President ' NeverDerefAlias would return 'cn=President, o=myCorporation, c=myCountry' DerefFinding would return 'cn=President, o=myCorporation, c=myCountry' DerefSearching would return 'cn=John Doe, o=myCorporation, c=myCountry' DerefAlways would return 'cn=John Doe, o=myCorporation, c=myCountry' 6. Security Considerations Permissions to dereferencing an alias, adding, deleting or returning alias entries are decided by the directory server's ACL administration policy. 7. References [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December 1997. [Bradner97] Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119. [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993 AUTHOR(S) ADDRESS Debbie Byrne IBM 11400 Burnet Rd Austin, TX 78758 USA mail-to: djbyrne@us.ibm.com phone: +1 512 838 1930 Ludovic Poitou Sun Microsystems 32, Chemin du vieux Chene 38240 Meylan France Phone: +33.(0)4.76.41.42.12 email: ludovic.poitou@france.sun.com Ellen Stokes IBM 11400 Burnet Rd Austin, TX 78758 USA mail-to: stokes@austin.ibm.com phone: +1 512 838 3725