The LDAP URL Format
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4516 — Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
obsoletes
- rfc-1959 — An LDAP URL Format
updated by
- rfc-3377 — Lightweight Directory Access Protocol (v3): Technical Specification
Extracted elements (22)
The extensions construct was added to provide the LDAP URL with an extensibility mechanism so that future documents can extend URL capabilities, for example to support new LDAPv3 extensions as they are defined. The critical/non-critical distinction allows graceful degradation when a client does not understand an extension.
The "X-" / "x-" prefix for extension types is reserved for bilateral agreements between communicating parties, avoiding the need for standards-track registration for private or experimental extensions.
The IESG warns that until mandatory authentication mechanisms are standardized, clients and servers implementing update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
This document replaces RFC 1959 and updates the LDAP URL format for version 3 of LDAP. It also defines an extension mechanism allowing future documents to extend LDAP URL functionality.
Any URL-illegal characters, URL special characters, and the reserved character '?' occurring inside a dn, filter, or other element of an LDAP URL MUST be escaped using the % method described in RFC 1738. A comma ',' inside an extension value MUST also be escaped using the % method.
Extension types not prefixed by "X-" or "x-" MUST be defined in this document or in other standards-track documents.
If a critical extension cannot be processed successfully by the client, the client MUST NOT process the URL. If a non-critical extension cannot be processed successfully, the client SHOULD ignore the extension.
If an extension is supported by the client, the client MUST obey the extension if the extension is critical. The client SHOULD obey supported extensions that are non-critical.
If an extension is unsupported by the client, the client MUST NOT process the URL if the extension is critical. If an unsupported extension is non-critical, the client MUST ignore the extension.
If the bindname extension is critical, the client resolving the URL MUST authenticate to the directory using the given distinguished name and an appropriate authentication method. For a NULL DN, no bind MAY be required to obtain anonymous access.
URL processing SHOULD proceed as follows: obtain a connection to the LDAP server (reusing an existing one MAY be acceptable), optionally authenticate, then perform the LDAP search. Additional fields such as sizelimit, timelimit, and deref MAY be set at the client's discretion.
An LDAP URL has the grammar: ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]]. The scheme is "ldap", scope is "base" / "one" / "sub", and extensions is a comma-separated list of ["!"] extype ["=" exvalue] pairs.
Extensions are a comma-separated list of type=value pairs; the =value portion MAY be omitted. An extension prefixed with '!' (ASCII 33) is critical; without '!' it is non-critical. Extension types prefixed by "X-" or "x-" are reserved for bilateral agreements.
If scope is omitted, a scope of "base" is assumed. If filter is omitted, a filter of "(objectClass=*)" is assumed. These are the two default values for omitted URL components.
If the attributes part is omitted, all user attributes of the entry or entries should be requested (by setting the AttributeDescriptionList to NULL, or in LDAPv3 by requesting the special attribute name "*").
The "bindname" extension carries the distinguished name of the directory entry the client should authenticate as when resolving the URL. The DN may be the NULL string to specify unauthenticated access. The extension may be critical (prefixed '!') or non-critical.
The connection used to resolve an LDAP URL MAY provide confidentiality, integrity, or other services (e.g., using TLS). Use of security services is at the client's discretion if not specified in the URL.
The default LDAP port is TCP port 389. If no hostport is given, the client must have some a priori knowledge of an appropriate LDAP server to contact.
A client SHOULD have a user-configurable policy about which servers to connect to using which security mechanisms, and SHOULD NOT make connections inconsistent with this policy. This is critical because URLs are often processed automatically without user intervention.
In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous connection. Reusable passwords sent to the server may reveal easily-abused information and should not be used in URL processing unless explicitly permitted by policy.
The LDAP URL format allows specification of an arbitrary LDAP search operation; 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 are the same as resolving an LDAP search query.
The LDAP URL uses the ldap:// scheme followed by optional hostport, a slash-delimited DN, and question-mark-delimited fields for attributes, scope, filter, and extensions. All components after the DN are optional and positionally identified by '?' separators.