2 Internet-Draft D. Byrne, IBM
3 LDAP Extensions WG L. Poitou, Sun
4 Intended Category: Standards Track E. Stokes, IBM
5 Expires: 20 October 1998
9 Use of Aliases within LDAP
10 <draft-byrne-ldap-alias-00.txt>
14 This document is an Internet Draft. Internet Drafts are
15 working documents of the Internet Engineering Task Force
16 (IETF), its Areas, and its Working Groups. Note that other
17 groups may also distribute working documents as Internet
20 Internet Drafts are draft documents valid for a maximum of six
21 months. Internet Drafts may be updated, replaced, or obsoleted
22 by other documents at any time. It is not appropriate to use
23 Internet Drafts as reference material or to cite them other
24 than as a "working draft" or "work in progress."
26 To view the entire list of current Internet-Drafts, please
27 check the "1id-abstracts.txt" listing contained in the
28 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
29 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
30 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
31 Coast), or ftp.isi.edu (US West Coast).
33 Comments and suggestions on this document are encouraged.
34 Comments on this document should be sent to the LDAPEXT
35 working group discussion list:
37 ietf-ldapext@netscape.com
41 This document describes the suggested behavior for aliases for
42 LDAPv3 and above to improve LDAP server interoperability .
44 The key words "MUST", "SHOULD", and "MAY" used in this
45 document are to be interpreted as described in [Bradner97].
51 Aliases may be used within LDAP to reference entries anywhere
52 within the directory tree. Conceptually, an alias is simply a
53 pointer to the DIT entry it represents. It does not contain
54 additional information about that entry; only the location of
57 The behavior of the alias object within LDAP is not well-
58 defined, both in creation of the alias object and the behavior
59 when dereferencing the alias.
61 For successful interoperability, the expected behavior of
62 servers when encountering alias objects SHOULD be consistent.
64 Additionally, it MUST be possible to use aliases without
65 changing the LDAPv3 schema as defined in [Wahl] and without
66 adding server-dependent data.
74 The alias objectclass definitions presented in the LDAPv3
75 Schema [Wahl] are the basis for aliasing within ldap. The
76 alias objectclass is a Structural objectclass with a single
77 required attribute; the single valued aliasObjectName.
79 This definition of the alias objectclass does not allow for
80 any attribute other than 'aliasedObjectName' to be used as the
81 naming attribute within the RDN. The resulting dn for the
82 alias object must therefore be of the form
83 "aliasedObjectName=<dn>, <rdn>, <rdn>..." This is not a
84 user-friendly name for a directory entry, and quite possibly
85 corrupts the naming hierarchy within the directory tree.
87 In order to remain true the concept of an alias; that it is
88 merely a pointer to another entry, an entry of objectclass
89 alias SHOULD NOT be combined with any other objectclass. If
90 multiple objectclasses are combined, it becomes possible to
91 add information to the alias entry without violating the
94 While not explicitly specified as either a 'required' or
95 'may', any naming attribute MUST be allowed to form the RDN of
96 the alias. Restricting the possible naming attributes would
97 potentially corrupt the hierarchy. For example, it would be
98 impossible to distinguish between a person alias and an
101 2.2 AliasObject Objectclass
103 In order to create an alias object which can be appropriately
104 named to that which it represents, the definition of the alias
105 object MUST be expanded. A new objectclass must be defined
106 which inherits from the current definition of alias but
107 extends the attributes allowed within the RDN.
109 ( 1.3.6.1.4.1.42.2.27.1.2.1
111 DESC objectclass for all alias objects
116 The '*' allows any naming attribute to be used in forming the
119 For example, the following is a correct LDIF:
120 dn: cn=John Doe, ou=myOrg, c=US
122 objectclass: aliasObject
123 aliasedObjectName: cn=President, ou=myOrg, c=US
126 To prevent the alias from containing extra information about
127 the object, the naming attribute SHOULD contain only a single
130 For example, the following is not a correct LDIF:
131 dn: cn=John Doe, ou=myOrg, c=US
133 objectclass: aliasObject
134 aliasedObjectName: cn=President, ou=myOrg, c=US
138 Similarly, the following would not be a correct LDIF file
139 because it adds extra information to the alias object.
141 dn: cn=John Doe, ou=myOrg, c=US
143 objectclass: aliasObject
144 aliasedObjectName: cn=President, ou=myOrg, c=US
148 The naming attribute used to form the RDN of the object SHOULD
149 reflect the naming attribute of the referenced object.
150 However, there are some cases where the naming attribute MAY
153 Within the X.501 [ITU-T], the attribute used to described the
154 aliased object is 'aliasedEntryName'. Since the OID for
155 'aliasedEntryName' and 'aliasedObjectName' are the same for
156 both X.500 and LDAP, LDAP servers SHOULD treat the
157 'aliasedEntryName' as a synonym for 'aliasedObjectName'.
162 In general alias objects SHOULD NOT be dereferenced during any
163 operation other than search unless requested to do so by the
166 Since an alias points to another section of the tree, it MUST
167 NOT be possible to add an object under an alias object; alias
168 objects MUST always be leaf nodes.
170 During the dereferencing of aliases, a loop is detected if the
171 server visits the same alias entry more than once. In this
172 case a data integrity error has occurred and the server MUST
173 return an error of 'aliasProblem'
175 If an alias is dereferenced, and the resulting directory entry
176 does not exists, a data integrity problem has occurred, and
177 the server MUST return an error code of
178 'aliasDereferencingProblem'
180 If the base entry for an ldapsearch is an alias, and alias
181 dereferencing is set to either derefFindBaseObj, or
182 derefAlways, the base entry MUST be dereferenced before the
183 search is performed. The new base for the search will become
184 the entry to which the alias resolves. The search is then
187 If multiple aliases are chained, the alias for the first
188 object MUST resolve to the last entry in the chain. For
189 example, A, B, and C are alias objects. If A points to B which
190 points to C which points to D, A resolves to D when
191 dereferencing the alias.
193 If an alias is dereferenced as part of a search, the alias
194 entry itself SHOULD NOT be returned as part of the search.
196 If an alias matches the search filter, and dereferencing is
197 set to 'searching' or 'always', the dereferenced object SHOULD
198 be returned, even if it does not match the filter.
200 If the alias is not dereferenced during the search, and it
201 matches the filter, then it SHOULD be returned within the
204 Each directory object matching a filter SHOULD be returned
205 only once during a search. If an entry is found twice because
206 of aliases pointing to a part of the tree already searched,
207 the entry SHOULD NOT be returned to the client a second time.
211 Using the following LDIF, the scenarios would return the
212 expected information as follows:
218 dn: ou=Area1, c=myCountry
220 aliasedObjectName: o=myCorporation, c=myCountry
222 objectclass:aliasObject
224 dn: o=myCorporation, c=myCountry
226 objectclass:organization
228 dn: cn=President, o=myCorporation, c=myCountry
230 aliasObjectName: cn=John Doe, o=myCorporation, c=myCountry
232 objectclass: aliasObject
234 dn: cn=John Doe, o=myCorporation, c=myCountry
241 ou = Area1 -----> o = myCorporation
243 cn=President ---> cn = John Doe
245 Performing a base search of 'ou = Area1, c=myCountry' with a
246 filter of 'objectclass=aliasObject'
247 NeverDerefAlias would return 'ou=Area1, c=myCountry'
248 DerefFinding would return 'cn=President, o=myCorporation,
250 DerefSearching would return 'o=myCorporation,
252 DerefAlways would return 'cn=John Doe, o=myCorporation,
255 Performing a one level search of 'c=myCountry' with a filter
257 NeverDerefAlias would return 'ou=Area1, c=myCountry'
258 DerefFinding would return 'ou=Area1, c=myCountry'
259 DerefSearching would return 'o=myCorporation,
261 DerefAlways would return ' o=myCorporation, c=myCountry'
263 Performing a full tree search of 'c=myCountry' with a filter
264 of ' cn = President '
265 NeverDerefAlias would return 'cn=President, o=myCorporation,
267 DerefFinding would return 'cn=President, o=myCorporation,
269 DerefSearching would return 'cn=John Doe, o=myCorporation,
271 DerefAlways would return 'cn=John Doe, o=myCorporation,
275 6. Security Considerations
277 Permissions to dereferencing an alias, adding, deleting or
278 returning alias entries are decided by the directory server's
279 ACL administration policy.
284 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
285 Access Protocol (v3)", RFC 2251, December 1997.
287 [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
288 Directory Access Protocol (v3)": Attribute Syntax Definitions,
289 RFC 2252, December 1997.
291 [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
292 Indicate Requirement Levels", RFC 2119.
294 [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993
305 mail-to: djbyrne@us.ibm.com
306 phone: +1 512 838 1930
310 32, Chemin du vieux Chene
313 Phone: +33.(0)4.76.41.42.12
314 email: ludovic.poitou@france.sun.com
321 mail-to: stokes@austin.ibm.com
322 phone: +1 512 838 3725