Lightweight Directory Access Protocol (v3)
obsoleted by
- rfc-4510 — Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map
- rfc-4511 — Lightweight Directory Access Protocol (LDAP): The Protocol
- rfc-4512 — Lightweight Directory Access Protocol (LDAP): Directory Information Models
- rfc-4513 — Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
updated by
Extracted elements (30)
LDAP uses SASL [RFC 2222] for extensible authentication rather than defining its own mechanisms, allowing the protocol to support any SASL mechanism including EXTERNAL (for lower-layer auth) and GSSAPI. Unlike text-based protocols using SASL, LDAP is binary so no base64 transformation of credentials is performed.
The extensibleMatch filter and the Controls/ExtendedOperation mechanisms were added in LDAPv3 to allow the protocol to be extended without version number changes. Each non-extension protocol change requires a new version number; the extension mechanisms are specifically designed to avoid this.
Unlike LDAPv2, clients need not send a Bind Request as the first PDU in LDAPv3; the server MUST treat unauthenticated requests as anonymous. This design enables read-only directory browsing without authentication while maintaining backward compatibility via the operationsError mechanism.
The IESG warns that until mandatory authentication mechanisms are standardized, LDAPv3 clients and servers using update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. Implementors are discouraged from deploying update-capable LDAPv3 implementations until a Proposed Standard for mandatory authentication is published.
A client MUST NOT send a second request with the same messageID as an outstanding request on the same connection. Additionally, a client MUST NOT reuse the message ID of an abandonRequest or the abandoned operation until a response to a subsequent request has been received.
A server MUST evaluate filters according to the three-valued logic of X.511(93) section 7.8.1: TRUE, FALSE, or Undefined. Entries matching TRUE are returned; FALSE/Undefined are ignored. Servers MUST NOT return errors if attribute descriptions or matching rule IDs are not recognized.
A server MUST NOT return any SearchResultReference if it has not located the baseObject; in that case it returns SearchResultDone with resultCode referral. To complete a distributed search, the client MUST issue a new search operation for each SearchResultReference returned.
A server that masters entries and permits client modifications MUST implement subschema entries and provide access to them. Subschema entries MUST contain cn (as RDN), objectClass (with at least 'top' and 'subschema'), objectClasses, and attributeTypes attributes. Clients MUST retrieve subschema via baseObject search with filter '(objectClass=subschema)'.
Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage SASL bind. A subsequent bind process abandons all outstanding operations; if a SASL integrity/encryption mechanism is active and does not support credential changes, the client MUST establish a new connection.
Every entry MUST have an objectClass attribute, which cannot be removed. Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions, the controlling subschema, or are operational attributes known to the server.
If the server receives a PDU where the LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the protocolOp tag is not a request, or encoding structures are incorrect, the server MUST return the Notice of Disconnection with resultCode protocolError and immediately close the connection.
Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server. Shadow servers will return referrals or contact other servers if modification operations are requested.
The entire list of modifications in a ModifyRequest MUST be performed in order as a single atomic operation. While individual modifications may transiently violate schema, the resulting entry after all modifications MUST conform to directory schema. If the connection fails, success or failure is indeterminate.
A Control is a SEQUENCE of controlType (LDAPOID), criticality (BOOLEAN DEFAULT FALSE), and optional controlValue (OCTET STRING). If a critical control is unrecognized or inappropriate, the server MUST NOT perform the operation and MUST return unsupportedCriticalExtension; non-critical unrecognized controls MUST be ignored.
An AttributeDescription extends an AttributeType with optional semicolon-separated options (e.g., 'userCertificate;binary'). Options MUST be generated sorted in ascending order, and servers MUST treat AttributeDescriptions with the same type and options as equivalent regardless of option ordering.
An unsolicited notification is an LDAPMessage with messageID 0 and protocolOp of extendedResp form, sent by the server without a corresponding client request. The Notice of Disconnection uses OID 1.3.6.1.4.1.1466.20036 and signals imminent connection close with resultCode protocolError, strongAuthRequired, or unavailable.
Search results consist of zero or more SearchResultEntry ([APPLICATION 4]) and SearchResultReference ([APPLICATION 19]) messages in any order, terminated by a single SearchResultDone ([APPLICATION 5] LDAPResult). SearchResultReference contains at least one LDAPURL and MUST include the dn part.
The 'binary' option in an AttributeDescription overrides string-based encoding and causes the attribute to be transferred as a BER-encoded binary value. If a server cannot generate binary format when requested, it MUST treat the attribute as an unrecognized type; clients MUST NOT expect binary return unless they requested it.
The BindRequest carries version (INTEGER 1..127), name (LDAPDN), and authentication as either simple (cleartext password OCTET STRING) or sasl (SaslCredentials containing mechanism name and optional credentials OCTET STRING). Version 3 is the current version described in this document.
The BindResponse includes an optional serverSaslCreds [7] OCTET STRING used in SASL challenge-response exchanges to allow the client to authenticate the server. SASL-based integrity/confidentiality services take effect after the final BindResponse with resultCode success is received by the client.
The ExtendedRequest ([APPLICATION 23]) carries a requestName (LDAPOID) and optional requestValue (OCTET STRING). The ExtendedResponse ([APPLICATION 24]) adds responseName and response fields to LDAPResult, enabling arbitrary new operations to be defined without changing the protocol version.
The Filter type is a CHOICE of and/or/not (recursive), equalityMatch, substrings (SubstringFilter with initial/any/final components), greaterOrEqual, lessOrEqual, present, approxMatch, and the new extensibleMatch (MatchingRuleAssertion with optional matchingRule, type, matchValue, and dnAttributes flag).
The LDAPResult construct carries the result of every operation: a resultCode ENUMERATED (0=success through 80=other, with new v3 codes 10=referral, 11=adminLimitExceeded, 12=unavailableCriticalExtension, 13=confidentialityRequired, 14=saslBindInProgress, 71=affectsMultipleDSAs), a matchedDN, an errorMessage, and an optional Referral.
The ModifyDNRequest carries entry (DN to rename), newrdn (new RDN), deleteoldrdn (BOOLEAN controlling whether old RDN values are removed), and optional newSuperior (DN of new parent, enabling subtree moves). Clients MUST NOT expect arbitrary cross-server entry movements to succeed.
The Referral type is a SEQUENCE OF LDAPURL with at least one URL. All URLs in a referral MUST be equally capable of progressing the operation. If a <dn> part is present, the client MUST use it in the next request; if a filter part is present in a search referral URL, the client MUST use that filter.
The root DSE (zero-length LDAPDN) MUST contain server-specific attributes including namingContexts, subschemaSubentry, altServer, supportedExtension, supportedControl, supportedSASLMechanisms, and supportedLDAPVersion. The root DSE MUST NOT be included in subtree search results starting from the root.
The SearchRequest carries baseObject (LDAPDN), scope (baseObject/singleLevel/wholeSubtree), derefAliases (4 values), sizeLimit, timeLimit, typesOnly (BOOLEAN), filter (Filter CHOICE), and attributes (AttributeDescriptionList). An empty attribute list or '*' requests all user attributes.
The simple authentication option transmits passwords in cleartext. The use of cleartext passwords is not recommended over open networks when no authentication or encryption is being performed by a lower layer. SASL mechanisms or lower-layer security (e.g., TLS) should be used instead.
All LDAPv3 protocol operations are encapsulated in a LDAPMessage SEQUENCE containing a messageID (INTEGER 0..2147483647), a protocolOp CHOICE covering all 22 operation types, and an optional Controls field tagged [0]. Encoding is BER (Basic Encoding Rules) per ASN.1.
LDAPString is an OCTET STRING encoded using UTF-8 (ISO 10646 character set). LDAPOID is an LDAPString restricted to dotted-decimal OID representations. LDAPDN and RelativeLDAPDN are LDAPStrings encoded per the DN string representation specification.