Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories
Extracted elements (29)
Knowledge information (referral objects) was introduced to generalize server-linking beyond the X.500 use case, enabling arbitrary LDAP directories to link services together without requiring a full X.500 DSA topology. Other forms of knowledge information (e.g., superior references, replication) are left to future documents.
The ManageDsaIT control is designed to allow clients to interrogate and update referral and other special DSEs as normal entries. Its name and semantics are intentionally analogous to the ManageDsaIT service option in X.511(97).
The ref attribute is marked as operational (USAGE distributedOperation) so it is only returned in search responses when explicitly requested, keeping referral objects invisible to ordinary clients in the absence of ManageDsaIT.
The ref attribute values SHOULD NOT be used as a relative name-component of an entry's DN. The handling of LDAP URLs with absent or empty DN parts or with explicit scope specifiers in the ref attribute itself is not defined by this specification.
Unlike the examples in RFC 2251 section 4.5.3.1, LDAP URLs returned in SearchResultReference messages MUST contain an explicit scope specifier as required by this specification.
During search continuation, for each referral object within the requested scope (regardless of the search filter), the server SHOULD return a SearchResultReference constructed from the URI component of the ref attribute values, with an explicit scope specifier added if the URI is an LDAP URL.
For LDAP URL referrals returned in response to a search base object request, the server MUST provide an explicit scope specifier in the LDAP URL before returning it, and the DN part MUST be modified to refer to the appropriate target.
For modifyDN operations, if the newSuperior is a referral object or subordinate to one, the server SHOULD return affectsMultipleDSAs. If the newRDN already exists as a referral object, the server SHOULD return affectsMultipleDSAs instead of entryAlreadyExists.
For non-search target object processing (Case 2), when the target is a referral object, the server SHOULD return the URI value in the ref attribute, with the DN part modified to refer to the appropriate target in the referenced server. The DN part SHOULD NOT be trimmed even when identical.
For non-search target object processing, the DN part of any returned LDAP URL MUST be modified to refer to the appropriate target in the referenced server. Critical extensions MUST NOT be trimmed or modified. Scope, filter, or attribute list SHOULD be trimmed from LDAP URLs before returning.
For search base object processing (Case 4), where the target is not held but the nearest naming context contains a referral object it is subordinate to, the server SHOULD return a referral response constructed from the URI portion of the ref value.
If a referral object has multiple ref values, all DNs contained within the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid configuring naming loops using referrals.
If alias dereferencing was necessary in finding the referral object during a search base lookup, the DN part of the returned URI MUST be replaced with the base DN as modified by alias dereferencing, per RFC 2251 section 4.1.11.
If the LDAP URL's DN part is absent or empty in a ref value used for search continuation, the DN part must be modified to contain the DN of the referral object.
If the URI in a ref attribute value refers to an LDAP server, it MUST be in the form of an LDAP URL [RFC2255]. The LDAP URL SHOULD NOT contain an explicit scope specifier, filter, attribute description list, or any extensions, and SHOULD contain a non-empty DN.
Named references MUST be treated as normal entries if the request includes the ManageDsaIT control.
Servers SHOULD NOT return a referral result code if the bind name (or authentication/authorization identity) is (or is subordinate to) a referral object; instead they MAY use the knowledge information or process the request normally (e.g., return invalidCredentials).
The referential integrity of a URI in the ref attribute SHOULD NOT be validated by the server holding or returning it, whether as an attribute value or as part of a referral or search reference response.
The referral object class SHOULD be used in conjunction with the extensibleObject object class to support the naming attributes used in the entry's Distinguished Name.
Values placed in the ref attribute MUST conform to the labeledURI specification [RFC2079], which defines a URI optionally followed by whitespace and a label.
When returning a referral result or search continuation, the server MUST NOT return the separator or label portions of ref attribute values as part of the reference; only the URI part of each value is used.
When the ManageDsaIT control is present in a request, the server SHALL NOT generate a referral or continuation reference based on information held in referral objects; it SHALL treat the referral object as a normal entry. The server remains free to return referrals for other reasons.
A named subordinate reference is constructed by instantiating a referral object in the referencing server with ref attribute values pointing to the corresponding subtree in the referenced server. Typically the DN of the referral object and the referenced object are the same, and the referenced object is a context prefix.
The ManageDsaIT control (OID 2.16.840.1.113730.3.4.2) may be included in add, compare, delete, modify, modifyDN, search, or applicable extended operations. Its criticality may be TRUE or absent; it has no control value. It causes all DSEs including referral objects to be treated as normal entries.
The 'ref' attribute type (OID 2.16.840.1.113730.3.1.34) has directoryString syntax with caseExactMatch equality, is multi-valued, and has USAGE distributedOperation. Values must conform to the labeledURI format: a URI optionally followed by whitespace and a label.
The 'referral' object class (OID 2.16.840.1.113730.3.2.6) is a STRUCTURAL object class with a mandatory 'ref' attribute, used to represent a named subordinate reference (knowledge DSE) in an LDAP directory. It is analogous to X.500 subordinate knowledge (subr) DSEs.
The schema and control defined here can be used to link LDAP and other servers together. The topology information (referral objects and ref attribute values) should be protected from unauthorized modification, and if not public, from unauthorized disclosure as well.
For non-search target object operations, the server evaluates four cases: (1) target not in any naming context — return noSuchObject or superior referral; (2) target is a referral object — return ref URI; (3) target absent, nearest naming context has no covering referral — return noSuchObject; (4) target absent but covered by a referral object — return referral response based on ref URI.
For search base object processing the same four-case logic applies as for non-search targets, but returned LDAP URLs MUST include an explicit scope specifier matching the client's requested scope (base, one, or sub).