Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
obsoletes
- rfc-2255 — The LDAP URL Format
Extracted elements (19)
References to RFC 2396 were replaced with RFC 3986, which allows literal IPv6 addresses to be used inside the `<host>` portion of the URL. As a consequence, '[' and ']' must now be percent-encoded when they appear in LDAP URL data, since RFC 3986 added them to the Reserved character set.
The extension criticality mechanism (prefixing with '!') closely mirrors the approach specified in RFC 4511 for LDAP controls, providing consistent semantics across the LDAP protocol for handling unrecognized or unimplemented extensions.
Other documents MAY specify different defaulting rules for absent LDAP URL fields; for example, RFC 4511 Section 4.1.10 specifies a different rule for determining the correct DN when it is absent in a referral URL.
The "Bindname Extension" defined in RFC 2255 was removed in RFC 4516 due to lack of known implementations. The examples section uses a hypothetical "e-bindname" extension for illustrative purposes only.
A generated LDAP URL MUST consist only of characters from the `<reserved>`, `<unreserved>`, or `<pct-encoded>` productions defined in RFC 3986.
An octet MUST be percent-encoded if it is not in the RFC 3986 reserved or unreserved sets, if it is the single reserved character '?' occurring inside a `<dn>`, `<filter>`, or other LDAP URL element, or if it is a comma ',' occurring inside an `<exvalue>`.
If an extension is not implemented and is not marked critical, the implementation MUST ignore the extension.
If an LDAP URL extension is implemented (understood and usable), the implementation MUST make use of it.
Implementations SHOULD accept other valid UTF-8 strings (RFC 3629) as input LDAP URL data, even though generated URLs must use only the restricted character set.
Use of the descriptor (`<descr>`) form for extension types SHOULD be restricted to registered object identifier descriptive names; see RFC 4520 for registration details.
Default field values when absent: `<port>` defaults to TCP 389; `<dn>` defaults to the zero-length DN ""; `<scope>` defaults to "base"; `<filter>` defaults to "(objectClass=*)"; `<attributes>` defaults to all user attributes; `<extensions>` defaults to none.
The `<extensions>` component is a comma-separated list of `[!]extype[=exvalue]` pairs providing an extensibility mechanism. An extension prefixed with '!' (ASCII 0x21) is critical; without the prefix it is non-critical.
The `<scope>` component specifies the LDAP search scope: "base" for a base object search, "one" for a one-level search, or "sub" for a subtree search. If absent, "base" is assumed.
A client SHOULD have a user-configurable policy controlling which servers it will establish LDAP sessions with and which security mechanisms to use, and SHOULD NOT establish sessions inconsistent with this policy. Clients processing URLs automatically face heightened risk due to the variety of servers encountered.
Following an LDAP URL may cause unexpected results such as retrieval of large amounts of data or initiation of a long-lived search. The security implications of resolving an LDAP URL are the same as those of resolving an LDAP search query.
If a client reuses an existing LDAP session when resolving one or more LDAP URLs, it MUST ensure that the session is compatible with the URL and that no security policies are violated.
In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous LDAP session. Sending any authentication information may violate a user's privacy requirements.
Reusable passwords sent to the server should not be used in URL processing unless explicitly permitted by policy, as they may reveal easily-abused information to the remote server or eavesdroppers. If the URL represents a referral for an update operation, strong authentication SHOULD be used.
An LDAP URL follows the ABNF: `ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]]`. The scheme is the literal string "ldap"; each component is separated by '?' (QUESTION, 0x3F).