Lightweight Directory Access Protocol (LDAP): The Protocol
obsoletes
Extracted elements (30)
ASN.1 extensibility is implied where allowed by ASN.1 (SEQUENCE, SET, CHOICE, and enumerated types), and explicit ellipses (...) mark explicitly extensible types. This design allows forward-compatible protocol extensions without incrementing the version number, avoiding the need for version negotiation on each new extension.
The Unbind operation is not the antithesis of the Bind operation despite its name; it functions as the 'quit' operation that terminates the LDAP session. The naming is historical and carried over from earlier LDAP versions, as noted non-normatively in Section 4.3.
If a client has not sent a Bind before sending requests, the server MUST assume the client is using version 3 or later. If a server does not support the version in a BindRequest, it MUST respond with a BindResponse where resultCode is protocolError. Clients receiving protocolError from a Bind are to assume the server does not support that version.
There is not a one-to-one mapping between LDAP operations and X.500 DAP operations; server implementations acting as X.500 gateways may need to make multiple DAP requests per LDAP request. The X.500 restriction that ModifyDN affects only entries within a single server applies in gateway scenarios, returning affectsMultipleDSAs if violated.
A server MUST evaluate search filters according to the three-valued logic of X.511 Clause 7.8.1: a filter evaluates to TRUE, FALSE, or Undefined. Only entries for which the filter evaluates to TRUE are returned in the Search result; entries matching FALSE or Undefined are ignored.
After sending a BindRequest, clients MUST NOT send further LDAP PDUs until receiving the BindResponse. Before processing a BindRequest, all uncompleted operations MUST either complete or be abandoned. Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage SASL Bind.
Clients and servers MUST (unless otherwise specified) ignore trailing SEQUENCE components whose tags they do not recognize. Changes to the protocol other than through defined extension mechanisms require a different version number.
Clients that follow referrals MUST ensure they do not loop between servers and MUST NOT repeatedly contact the same server for the same request with the same parameters. Counter-based clients MUST be able to handle at least ten nested referrals while progressing the operation.
If a server does not recognize a control type or is unwilling to apply it, and criticality is TRUE, the server MUST NOT perform the operation and MUST return unavailableCriticalExtension. If criticality is FALSE, the server MUST ignore the unrecognized control and proceed.
If the server receives an LDAPMessage in which the SEQUENCE tag, messageID, or protocolOp tag cannot be recognized, or encoding lengths are incorrect, the server SHOULD return a Notice of Disconnection with protocolError and MUST immediately terminate the LDAP session.
Implementations MUST NOT display or attempt to decode an attribute value if its syntax is not known. Clients MUST only send attribute values in a request that are valid according to the syntax defined for the attributes. Implementations MUST be prepared to handle arbitrary contents of controlValue and Extended operation value fields, including zero bytes.
Only leaf entries (those with no subordinate entries) can be deleted with the Delete operation. Clients MUST NOT supply NO-USER-MODIFICATION attributes (e.g., createTimestamp) in an Add Request, as these are maintained automatically by the server.
Servers MUST detect looping while dereferencing aliases during Search operations in order to prevent denial-of-service attacks. Servers SHOULD also eliminate duplicate entries that arise due to alias dereferencing while searching.
Servers MUST NOT return errors if attribute descriptions or matching rule IDs are not recognized, assertion values are invalid, or assertion syntax is not supported in search filters; such filter items evaluate to Undefined rather than causing an error.
Textual passwords transferred using the simple AuthenticationChoice SHALL be transferred as UTF-8 encoded Unicode. Prior to transfer, clients SHOULD prepare text passwords as 'query' strings by applying the SASLprep (RFC 4013) profile of the stringprep (RFC 3454) algorithm.
The entire list of modifications in a ModifyRequest MUST be performed in the listed order as a single atomic operation. If the Modify Response indicates any error, the client may expect that no modifications of the DIT have been performed.
The messageID of a request MUST have a non-zero value different from the messageID of any other request in progress in the same LDAP session. The zero value is reserved for unsolicited notifications. A client MUST NOT reuse a messageID until it can be determined the server is no longer servicing the earlier request.
When a server receives an Abandon Request on a Search operation while transmitting responses, the server MUST cease transmitting entry responses immediately and MUST NOT send the SearchResultDone. Abandon, Bind, Unbind, and StartTLS operations cannot themselves be abandoned.
A Referral result (resultCode 10) contains one or more URIs (Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI) pointing to other servers that may be able to complete the operation. At least one URI MUST be present. Referrals may be returned for any operation except Unbind and Abandon.
Controls extend existing LDAP operation semantics. Each Control is a SEQUENCE of controlType (LDAPOID), criticality BOOLEAN (default FALSE), and optional controlValue OCTET STRING. Request controls are sent by clients; response controls are sent by servers.
LDAPResult is the standard response construct containing a resultCode ENUMERATED (30+ values including success(0), referral(10), protocolError(2), unavailableCriticalExtension(12), etc.), a matchedDN LDAPDN, a diagnosticMessage LDAPString, and an optional referral field.
The Bind operation (BindRequest APPLICATION 0) carries a version INTEGER (1..127), a name LDAPDN, and an AuthenticationChoice of simple (OCTET STRING password) or sasl (SaslCredentials with mechanism LDAPString and optional credentials OCTET STRING). BindResponse includes optional serverSaslCreds for mutual authentication.
The Extended operation (ExtendedRequest APPLICATION 23) carries a requestName LDAPOID and optional requestValue OCTET STRING. ExtendedResponse (APPLICATION 24) includes LDAPResult components plus optional responseName [10] LDAPOID and responseValue [11] OCTET STRING. Recognized extensions are listed in the root DSE 'supportedExtension' attribute.
The IntermediateResponse message (APPLICATION 25) provides a general mechanism for single-request/multiple-response operations, intended for use with Extended operations or request controls that require intermediate results before the final response.
The Notice of Disconnection is an unsolicited notification with responseName OID 1.3.6.1.4.1.1466.20036 and messageID zero, sent by the server before terminating the LDAP session on its own initiative. It assists clients in distinguishing exceptional server conditions from transient network failures.
The StartTLS Extended operation (Section 4.14) enables installation of a TLS layer on an existing LDAP connection. The StartTLS request uses requestName 1.3.6.1.4.1.1466.20037. After a successful response, all subsequent LDAP messages are protected by TLS until the TLS layer is removed.
LDAP simple Bind transmits credentials that may be intercepted unless a TLS or SASL confidentiality layer is in place. Servers may return substituted result codes to prevent unauthorized disclosure of directory topology. The Notice of Disconnection with strongerAuthRequired indicates an established security association has unexpectedly failed or been compromised.
When the transport connection is closed, the client MUST NOT assume that any uncompleted update operations have succeeded or failed. Servers acting as gateways to X.500 may need to make multiple DAP requests, increasing the attack surface for confused-deputy attacks.
All LDAP protocol operations are encapsulated in LDAPMessage, an ASN.1 SEQUENCE containing a messageID (INTEGER 0..2147483647), a protocolOp CHOICE covering all 19+ operation types, and an optional Controls field tagged [0]. The protocol is transferred using a subset of ASN.1 Basic Encoding Rules (BER).
SearchRequest (APPLICATION 3) contains baseObject LDAPDN, scope ENUMERATED (baseObject/singleLevel/wholeSubtree), derefAliases ENUMERATED, sizeLimit INTEGER, timeLimit INTEGER, typesOnly BOOLEAN, a Filter CHOICE, and an AttributeSelection SEQUENCE OF LDAPString. Filter supports and/or/not/equalityMatch/substrings/greaterOrEqual/lessOrEqual/present/approxMatch/extensibleMatch choices.