2 Internet-Draft Editor: J. Sermersheim
3 Intended Category: Standard Track Novell, Inc
4 Document: draft-ietf-ldapbis-protocol-19.txt Dec 2003
5 Obsoletes: RFC 2251, 2830
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that other
18 groups may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Distribution of this memo is unlimited. Technical discussion of this
31 document will take place on the IETF LDAP Revision Working Group
32 (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
33 editorial comments directly to the editor <jimse@novell.com>.
38 This document describes the protocol elements, along with their
39 semantics and encodings, of the Lightweight Directory Access Protocol
40 (LDAP). LDAP provides access to distributed directory services that
41 act in accordance with X.500 data and service models. These protocol
42 elements are based on those described in the X.500 Directory Access
48 1. Introduction....................................................2
49 1.1. Relationship to Obsolete Specifications.......................3
50 2. Conventions.....................................................3
51 3. Protocol Model..................................................3
52 4. Elements of Protocol............................................4
53 4.1. Common Elements...............................................4
54 4.1.1. Message Envelope............................................4
55 4.1.2. String Types................................................6
57 Sermersheim Internet-Draft - Expires Jun 2004 Page 1
\f
58 Lightweight Directory Access Protocol Version 3
60 4.1.3. Distinguished Name and Relative Distinguished Name..........6
61 4.1.4. Attribute Descriptions......................................7
62 4.1.5. Attribute Value.............................................7
63 4.1.6. Attribute Value Assertion...................................7
64 4.1.7. Attribute and PartialAttribute..............................8
65 4.1.8. Matching Rule Identifier....................................8
66 4.1.9. Result Message..............................................8
67 4.1.10. Referral..................................................10
68 4.1.11. Controls..................................................11
69 4.2. Bind Operation...............................................12
70 4.3. Unbind Operation.............................................15
71 4.4. Unsolicited Notification.....................................16
72 4.5. Search Operation.............................................17
73 4.6. Modify Operation.............................................25
74 4.7. Add Operation................................................26
75 4.8. Delete Operation.............................................27
76 4.9. Modify DN Operation..........................................28
77 4.10. Compare Operation...........................................29
78 4.11. Abandon Operation...........................................30
79 4.12. Extended Operation..........................................30
80 4.13. StartTLS Operation..........................................31
81 5. Protocol Element Encodings and Transfer........................33
82 5.1. Protocol Encoding............................................34
83 5.2. Transfer Protocols...........................................34
84 6. Security Considerations........................................34
85 7. Acknowledgements...............................................36
86 8. Normative References...........................................36
87 9. Informative References.........................................37
88 10. IANA Considerations...........................................37
89 11. Editor's Address..............................................38
90 Appendix A - LDAP Result Codes....................................39
91 A.1 Non-Error Result Codes........................................39
92 A.2 Result Codes..................................................39
93 Appendix B - Complete ASN.1 Definition............................43
94 Appendix C - Changes..............................................48
95 C.1 Changes made to made to RFC 2251:.............................48
96 C.2 Changes made to made to RFC 2830:.............................53
101 The Directory is "a collection of open systems cooperating to provide
102 directory services" [X.500]. A directory user, which may be a human
103 or other entity, accesses the Directory through a client (or
104 Directory User Agent (DUA)). The client, on behalf of the directory
105 user, interacts with one or more servers (or Directory System Agents
106 (DSA)). Clients interact with servers using a directory access
109 This document details the protocol elements of the Lightweight
110 Directory Access Protocol (LDAP), along with their semantics.
111 Following the description of protocol elements, it describes the way
112 in which the protocol elements are encoded and transferred.
115 Sermersheim Internet-Draft - Expires Jun 2004 Page 2
\f
116 Lightweight Directory Access Protocol Version 3
119 1.1. Relationship to Obsolete Specifications
121 This document is an integral part of the LDAP Technical Specification
122 [Roadmap] which obsoletes the previously defined LDAP technical
123 specification, RFC 3377, in its entirety.
125 This document obsoletes all of RFC 2251 except the following:
126 Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1,
127 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are
128 obsoleted by [Models].
129 Section 3.3 is obsoleted by [Roadmap].
130 Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth].
132 Appendix C.1 summarizes substantive changes to the remaining
135 This document also obsoletes RFC 2830, Sections 2 and 4 in entirety.
136 The remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2
137 summarizes substantive changes to the remaining sections.
142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
143 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
144 to be interpreted as described in [Keyword].
146 The terms "connection" and "LDAP connection" both refer to the
147 underlying transport protocol connection between two protocol peers.
149 The term "TLS connection" refers to a TLS-protected LDAP connection.
151 The terms "association" and "LDAP association" both refer to the
152 association of the LDAP connection and its current authentication and
158 The general model adopted by this protocol is one of clients
159 performing protocol operations against servers. In this model, a
160 client transmits a protocol request describing the operation to be
161 performed to a server. The server is then responsible for performing
162 the necessary operation(s) in the Directory. Upon completion of the
163 operation(s), the server returns a response containing an appropriate
164 result code to the requesting client.
166 Although servers are required to return responses whenever such
167 responses are defined in the protocol, there is no requirement for
168 synchronous behavior on the part of either clients or servers.
169 Requests and responses for multiple operations may be exchanged
170 between a client and server in any order, provided the client
171 eventually receives a response for every request that requires one.
173 Sermersheim Internet-Draft - Expires Jun 2004 Page 3
\f
174 Lightweight Directory Access Protocol Version 3
177 The core protocol operations defined in this document can be mapped
178 to a subset of the X.500 (1993) Directory Abstract Service. However
179 there is not a one-to-one mapping between LDAP protocol operations
180 and X.500 Directory Access Protocol (DAP) operations. Server
181 implementations acting as a gateway to X.500 directories may need to
182 make multiple DAP requests to service a single LDAP request.
185 4. Elements of Protocol
187 The LDAP protocol is described using Abstract Syntax Notation One
188 ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
189 Rules ([BER]). Section 5.1 specifies how the protocol elements are
190 encoded and transferred.
192 In order to support future Standards Track extensions to this
193 protocol, extensibility is implied where it is allowed (per ASN.1).
194 In addition, ellipses (...) have been supplied in ASN.1 types that
195 are explicitly extensible as discussed in [LDAPIANA]. Because of the
196 implied extensibility, clients and servers MUST (unless otherwise
197 specified) ignore trailing SEQUENCE components whose tags they do not
200 Changes to the LDAP protocol other than through the extension
201 mechanisms described here require a different version number. A
202 client indicates the version it is using as part of the bind request,
203 described in Section 4.2. If a client has not sent a bind, the server
204 MUST assume the client is using version 3 or later.
206 Clients may determine the protocol versions a server supports by
207 reading the supportedLDAPVersion attribute from the root DSE (DSA-
208 Specific Entry) [Models].
213 This section describes the LDAPMessage envelope Protocol Data Unit
214 (PDU) format, as well as data type definitions, which are used in the
218 4.1.1. Message Envelope
220 For the purposes of protocol exchanges, all protocol operations are
221 encapsulated in a common envelope, the LDAPMessage, which is defined
224 LDAPMessage ::= SEQUENCE {
227 bindRequest BindRequest,
228 bindResponse BindResponse,
229 unbindRequest UnbindRequest,
231 Sermersheim Internet-Draft - Expires Jun 2004 Page 4
\f
232 Lightweight Directory Access Protocol Version 3
234 searchRequest SearchRequest,
235 searchResEntry SearchResultEntry,
236 searchResDone SearchResultDone,
237 searchResRef SearchResultReference,
238 modifyRequest ModifyRequest,
239 modifyResponse ModifyResponse,
240 addRequest AddRequest,
241 addResponse AddResponse,
242 delRequest DelRequest,
243 delResponse DelResponse,
244 modDNRequest ModifyDNRequest,
245 modDNResponse ModifyDNResponse,
246 compareRequest CompareRequest,
247 compareResponse CompareResponse,
248 abandonRequest AbandonRequest,
249 extendedReq ExtendedRequest,
250 extendedResp ExtendedResponse,
252 controls [0] Controls OPTIONAL }
254 MessageID ::= INTEGER (0 .. maxInt)
256 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
258 The function of the LDAPMessage is to provide an envelope containing
259 common fields required in all protocol exchanges. At this time the
260 only common fields are the message ID and the controls.
262 If the server receives a PDU from the client in which the LDAPMessage
263 SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
264 the tag of the protocolOp is not recognized as a request, or the
265 encoding structures or lengths of data fields are found to be
266 incorrect, then the server SHOULD return the Notice of Disconnection
267 described in Section 4.4.1, with the resultCode set to protocolError,
268 and MUST immediately close the connection.
270 In other cases where the client or server cannot parse a PDU, it
271 SHOULD abruptly close the connection where further communication
272 (including providing notice) would be pernicious. Otherwise, server
273 implementations MUST return an appropriate response to the request,
274 with the resultCode set to protocolError.
276 The ASN.1 type Controls is defined in Section 4.1.11.
281 All LDAPMessage envelopes encapsulating responses contain the
282 messageID value of the corresponding request LDAPMessage.
284 The message ID of a request MUST have a non-zero value different from
285 the values of any other requests outstanding in the LDAP association
286 of which this message is a part. The zero value is reserved for the
287 unsolicited notification message.
289 Sermersheim Internet-Draft - Expires Jun 2004 Page 5
\f
290 Lightweight Directory Access Protocol Version 3
293 Typical clients increment a counter for each request.
295 A client MUST NOT send a request with the same message ID as an
296 earlier request on the same LDAP association unless it can be
297 determined that the server is no longer servicing the earlier
298 request. Otherwise the behavior is undefined. For operations that do
299 not return responses (unbind, abandon, and abandoned operations), the
300 client SHOULD assume the operation is in progress until a subsequent
301 bind request completes.
306 The LDAPString is a notational convenience to indicate that, although
307 strings of LDAPString type encode as ASN.1 OCTET STRING types, the
308 [ISO10646] character set (a superset of [Unicode]) is used, encoded
309 following the [UTF-8] algorithm. Note that Unicode characters U+0000
310 through U+007F are the same as ASCII 0 through 127, respectively, and
311 have the same single octet UTF-8 encoding. Other Unicode characters
312 have a multiple octet UTF-8 encoding.
314 LDAPString ::= OCTET STRING -- UTF-8 encoded,
315 -- [ISO10646] characters
317 The LDAPOID is a notational convenience to indicate that the
318 permitted value of this string is a (UTF-8 encoded) dotted-decimal
319 representation of an OBJECT IDENTIFIER. Although an LDAPOID is
320 encoded as an OCTET STRING, values are limited to the definition of
321 <numericoid> given in Section 1.3 of [Models].
323 LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
327 1.3.6.1.4.1.1466.1.2.3
330 4.1.3. Distinguished Name and Relative Distinguished Name
332 An LDAPDN is defined to be the representation of a Distinguished Name
333 (DN) after encoding according to the specification in [LDAPDN].
335 LDAPDN ::= LDAPString
336 -- Constrained to <distinguishedName> [LDAPDN]
338 A RelativeLDAPDN is defined to be the representation of a Relative
339 Distinguished Name (RDN) after encoding according to the
340 specification in [LDAPDN].
342 RelativeLDAPDN ::= LDAPString
343 -- Constrained to <name-component> [LDAPDN]
347 Sermersheim Internet-Draft - Expires Jun 2004 Page 6
\f
348 Lightweight Directory Access Protocol Version 3
350 4.1.4. Attribute Descriptions
352 The definition and encoding rules for attribute descriptions are
353 defined in Section 2.5 of [Models]. Briefly, an attribute description
354 is an attribute type and zero or more options.
356 AttributeDescription ::= LDAPString
357 -- Constrained to <attributedescription>
361 4.1.5. Attribute Value
363 A field of type AttributeValue is an OCTET STRING containing an
364 encoded attribute value. The attribute value is encoded according to
365 the LDAP-specific encoding definition of its corresponding syntax.
366 The LDAP-specific encoding definitions for different syntaxes and
367 attribute types may be found in other documents and in particular
370 AttributeValue ::= OCTET STRING
372 Note that there is no defined limit on the size of this encoding;
373 thus protocol values may include multi-megabyte attributes (e.g.
376 Attributes may be defined which have arbitrary and non-printable
377 syntax. Implementations MUST NOT display nor attempt to decode a
378 value if its syntax is not known. The implementation may attempt to
379 discover the subschema of the source entry, and retrieve the
380 descriptions of attributeTypes from it [Models].
382 Clients MUST NOT send attribute values in a request that are not
383 valid according to the syntax defined for the attributes.
386 4.1.6. Attribute Value Assertion
388 The AttributeValueAssertion type definition is similar to the one in
389 the X.500 Directory standards. It contains an attribute description
390 and a matching rule assertion value suitable for that type.
392 AttributeValueAssertion ::= SEQUENCE {
393 attributeDesc AttributeDescription,
394 assertionValue AssertionValue }
396 AssertionValue ::= OCTET STRING
398 The syntax of the AssertionValue depends on the context of the LDAP
399 operation being performed. For example, the syntax of the EQUALITY
400 matching rule for an attribute is used when performing a Compare
401 operation. Often this is the same syntax used for values of the
402 attribute type, but in some cases the assertion syntax differs from
405 Sermersheim Internet-Draft - Expires Jun 2004 Page 7
\f
406 Lightweight Directory Access Protocol Version 3
408 the value syntax. See objectIdentiferFirstComponentMatch in
409 [Syntaxes] for an example.
412 4.1.7. Attribute and PartialAttribute
414 Attributes and partial attributes consist of an attribute description
415 and values of that attribute description. A PartialAttribute allows
416 zero values, while Attribute requires at least one value.
418 PartialAttribute ::= SEQUENCE {
419 type AttributeDescription,
420 vals SET OF value AttributeValue }
422 Attribute ::= PartialAttribute(WITH COMPONENTS {
424 vals (SIZE(1..MAX))})
426 Each attribute value is distinct in the set (no duplicates). The set
427 of attribute values is unordered. Implementations MUST NOT rely upon
428 the ordering being repeatable.
430 4.1.8. Matching Rule Identifier
432 Matching rules are defined in 4.1.3 of [Models]. A matching rule is
433 identified in the LDAP protocol by the printable representation of
434 either its <numericoid>, or one of its short name descriptors
435 [Models], e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
437 MatchingRuleId ::= LDAPString
440 4.1.9. Result Message
442 The LDAPResult is the construct used in this protocol to return
443 success or failure indications from servers to clients. To various
444 requests, servers will return responses of LDAPResult or responses
445 containing the components of LDAPResult to indicate the final status
446 of a protocol operation request.
448 LDAPResult ::= SEQUENCE {
449 resultCode ENUMERATED {
453 timeLimitExceeded (3),
454 sizeLimitExceeded (4),
457 authMethodNotSupported (7),
458 strongAuthRequired (8),
461 adminLimitExceeded (11),
463 Sermersheim Internet-Draft - Expires Jun 2004 Page 8
\f
464 Lightweight Directory Access Protocol Version 3
466 unavailableCriticalExtension (12),
467 confidentialityRequired (13),
468 saslBindInProgress (14),
469 noSuchAttribute (16),
470 undefinedAttributeType (17),
471 inappropriateMatching (18),
472 constraintViolation (19),
473 attributeOrValueExists (20),
474 invalidAttributeSyntax (21),
478 invalidDNSyntax (34),
479 -- 35 reserved for undefined isLeaf --
480 aliasDereferencingProblem (36),
482 inappropriateAuthentication (48),
483 invalidCredentials (49),
484 insufficientAccessRights (50),
487 unwillingToPerform (53),
490 namingViolation (64),
491 objectClassViolation (65),
492 notAllowedOnNonLeaf (66),
493 notAllowedOnRDN (67),
494 entryAlreadyExists (68),
495 objectClassModsProhibited (69),
496 -- 70 reserved for CLDAP --
497 affectsMultipleDSAs (71),
501 -- 81-90 reserved for APIs --
503 diagnosticMessage LDAPString,
504 referral [3] Referral OPTIONAL }
506 The resultCode enumeration is extensible as defined in Section 3.5 of
507 [LDAPIANA]. The meanings of the result codes are given in Appendix A.
508 If a server detects multiple errors for an operation, only one result
509 code is returned. The server should return the result code that best
510 indicates the nature of the error encountered.
512 The diagnosticMessage field of this construct may, at the server's
513 option, be used to return a string containing a textual, human-
514 readable (terminal control and page formatting characters should be
515 avoided) diagnostic message. As this diagnostic message is not
516 standardized, implementations MUST NOT rely on the values returned.
517 If the server chooses not to return a textual diagnostic, the
518 diagnosticMessage field MUST be empty.
521 Sermersheim Internet-Draft - Expires Jun 2004 Page 9
\f
522 Lightweight Directory Access Protocol Version 3
524 For certain result codes (typically, but not restricted to
525 noSuchObject, aliasProblem, invalidDNSyntax and
526 aliasDereferencingProblem), the matchedDN field is set to the name of
527 the lowest entry (object or alias) in the Directory that was matched.
528 If no aliases were dereferenced while attempting to locate the entry,
529 this will be a truncated form of the name provided, or if aliases
530 were dereferenced, of the resulting name, as defined in Section 12.5
531 of [X.511]. Otherwise the matchedDN field is empty.
536 The referral result code indicates that the contacted server does not
537 hold the target entry of the request. The referral field is present
538 in an LDAPResult if the resultCode field value is referral, and
539 absent with all other result codes. It contains one or more
540 references to one or more servers or services that may be accessed
541 via LDAP or other protocols. Referrals can be returned in response to
542 any operation request (except unbind and abandon which do not have
543 responses). At least one URI MUST be present in the Referral.
545 During a search operation, after the baseObject is located, and
546 entries are being evaluated, the referral is not returned. Instead,
547 continuation references, described in Section 4.5.3, are returned
548 when the search scope spans multiple naming contexts, and several
549 different servers would need to be contacted to complete the
552 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
554 URI ::= LDAPString -- limited to characters permitted in
557 If the client wishes to progress the operation, it MUST follow the
558 referral by contacting one of the services. If multiple URIs are
559 present, the client assumes that any URI may be used to progress the
562 Clients that follow referrals MUST ensure that they do not loop
563 between servers. They MUST NOT repeatedly contact the same server for
564 the same request with the same target entry name, scope and filter.
565 Some clients use a counter that is incremented each time referral
566 handling occurs for an operation, and these kinds of clients MUST be
567 able to handle at least ten nested referrals between the root and a
570 A URI for a server implementing LDAP and accessible via [TCP]/[IP]
571 (v4 or v6) is written as an LDAP URL according to [LDAPURL].
573 When an LDAP URL is used, the following instructions are followed:
574 - If an alias was dereferenced, the <dn> part of the URL MUST be
575 present, with the new target object name. Note that UTF-8
576 characters appearing in a DN or search filter may not be legal
579 Sermersheim Internet-Draft - Expires Jun 2004 Page 10
\f
580 Lightweight Directory Access Protocol Version 3
582 for URLs (e.g. spaces) and MUST be escaped using the % method in
584 - It is RECOMMENDED that the <dn> part be present to avoid
586 - If the <dn> part is present, the client MUST use this name in
587 its next request to progress the operation, and if it is not
588 present the client will use the same name as in the original
590 - Some servers (e.g. participating in distributed indexing) may
591 provide a different filter in a URL of a referral for a search
593 - If the <filter> part of the LDAP URL is present, the client MUST
594 use this filter in its next request to progress this search, and
595 if it is not present the client MUST use the same filter as it
596 used for that search.
597 - For search, it is RECOMMENDED that the <scope> part be present
599 - If the <scope> part is missing, the scope of the original search
600 is used by the client to progress the operation.
601 - Other aspects of the new request may be the same as or different
602 from the request which generated the referral.
604 Other kinds of URIs may be returned. The syntax and semantics of such
605 URIs is left to future specifications. Clients ignore URIs that they
611 A control is a way to specify extension information for an LDAP
612 message. A control only alters the semantics of the message it is
615 Controls ::= SEQUENCE OF control Control
617 Control ::= SEQUENCE {
619 criticality BOOLEAN DEFAULT FALSE,
620 controlValue OCTET STRING OPTIONAL }
622 The controlType field is the UTF-8 encoded dotted-decimal
623 representation of an OBJECT IDENTIFIER which uniquely identifies the
624 control, or the request control and its paired response control. This
625 prevents conflicts between control names.
627 The criticality field is either TRUE or FALSE and only applies to
628 request messages that have a corresponding response message. For all
629 other messages (such as abandonRequest, unbindRequest and all
630 response messages), the criticality field SHOULD be FALSE.
632 If the server recognizes the control type and it is appropriate for
633 the operation, the server will make use of the control when
634 performing the operation.
637 Sermersheim Internet-Draft - Expires Jun 2004 Page 11
\f
638 Lightweight Directory Access Protocol Version 3
640 If the server does not recognize the control type or it is not
641 appropriate for the operation, and the criticality field is TRUE, the
642 server MUST NOT perform the operation, and for operations that have a
643 response, MUST set the resultCode to unavailableCriticalExtension.
645 If the control is unrecognized or inappropriate but the criticality
646 field is FALSE, the server MUST ignore the control.
648 The controlValue contains any information associated with the
649 control. Its format is defined by the specification of the control.
650 Implementations MUST be prepared to handle arbitrary contents of the
651 controlValue octet string, including zero bytes. It is absent only if
652 there is no value information which is associated with a control of
653 its type. controlValues that are defined in terms of ASN.1 and BER
654 encoded according to Section 5.1, also follow the extensibility rules
657 Servers list the controlType of all request controls they recognize
658 in the supportedControl attribute [Models] in the root DSE.
660 Controls SHOULD NOT be combined unless the semantics of the
661 combination has been specified. The semantics of control
662 combinations, if specified, are generally found in the control
663 specification most recently published. In the absence of combination
664 semantics, the behavior of the operation is undefined.
665 Additionally, unless order-dependent semantics are given in a
666 specification, the order of a combination of controls in the SEQUENCE
669 This document does not specify any controls. Controls may be
670 specified in other documents. The specification of a control consists
673 - the OBJECT IDENTIFIER assigned to the control,
675 - whether the control is always non critical, always critical, or
678 - whether there is information associated with the control, and if
679 so, the format of the controlValue contents,
681 - the semantics of the control, and
683 - optionally, semantics regarding the combination of the control
689 The function of the Bind Operation is to allow authentication
690 information to be exchanged between the client and server. The Bind
691 operation should be thought of as the "authenticate" operation.
692 Authentication and security-related semantics of this operation are
695 Sermersheim Internet-Draft - Expires Jun 2004 Page 12
\f
696 Lightweight Directory Access Protocol Version 3
699 The Bind Request is defined as follows:
701 BindRequest ::= [APPLICATION 0] SEQUENCE {
702 version INTEGER (1 .. 127),
704 authentication AuthenticationChoice }
706 AuthenticationChoice ::= CHOICE {
707 simple [0] OCTET STRING,
709 sasl [3] SaslCredentials,
712 SaslCredentials ::= SEQUENCE {
713 mechanism LDAPString,
714 credentials OCTET STRING OPTIONAL }
716 Parameters of the Bind Request are:
718 - version: A version number indicating the version of the protocol
719 to be used in this protocol association. This document describes
720 version 3 of the LDAP protocol. Note that there is no version
721 negotiation. The client sets this parameter to the version it
722 desires. If the server does not support the specified version, it
723 MUST respond with protocolError in the resultCode field of the
726 - name: The name of the Directory object that the client wishes to
727 bind as. This field may take on a null value (a zero length
728 string) for the purposes of anonymous binds ([AuthMeth] Section 7)
729 or when using Simple Authentication and Security Layer [SASL]
730 authentication ([AuthMeth] Section 4.3). Server behavior is
731 undefined when the name is a null value, simple authentication is
732 used, and a password is specified. The server SHALL NOT perform
733 alias dereferencing in determining the object to bind as.
735 - authentication: information used to authenticate the name, if any,
736 provided in the Bind Request. This type is extensible as defined
737 in Section 3.6 of [LDAPIANA]. Servers that do not support a choice
738 supplied by a client will return authMethodNotSupported in the
739 resultCode field of the BindResponse.
740 The simple form of an AuthenticationChoice specifies a simple
741 password to be used for authentication.
742 Textual passwords (consisting of a character sequence with a known
743 character set and encoding) SHALL be transferred as [UTF-8]
744 encoded [Unicode]. The determination of whether a password is
745 textual is a local client matter.
746 Prior to transfer, clients SHOULD prepare text passwords by
747 applying the [SASLprep] profile of the [Stringprep] algorithm.
748 Passwords consisting of other data (such as random octets) MUST
753 Sermersheim Internet-Draft - Expires Jun 2004 Page 13
\f
754 Lightweight Directory Access Protocol Version 3
756 Authorization is the use of this authentication information when
757 performing operations. Authorization MAY be affected by factors
758 outside of the LDAP Bind Request, such as those provided by lower
759 layer security services.
762 4.2.1. Processing of the Bind Request
764 Before processing a BindResponse, all outstanding operations MUST
765 either complete or be abandoned. The server may either wait for the
766 outstanding operations to complete, or abandon them. The server then
767 proceeds to authenticate the client in either a single-step, or
768 multi-step bind process. Each step requires the server to return a
769 BindResponse to indicate the status of authentication.
771 If the client did not bind before sending a request and receives an
772 operationsError to that request, it may then send a Bind Request. If
773 this also fails or the client chooses not to bind on the existing
774 connection, it may close the connection, reopen it and begin again by
775 first sending a PDU with a Bind Request. This will aid in
776 interoperating with servers implementing other versions of LDAP.
778 Clients may send multiple Bind Requests on a connection to change the
779 authentication and/or security associations or to complete a multi-
780 stage bind process. Authentication from earlier binds is subsequently
783 For some SASL authentication mechanisms, it may be necessary for the
784 client to invoke the BindRequest multiple times. This is indicated by
785 the server sending a BindResponse with the resultCode set to
786 saslBindInProgress. This indicates that the server requires the
787 client to send a new bind request, with the same sasl mechanism, to
788 continue the authentication process. If at any stage the client
789 wishes to abort the bind process it MAY unbind and then drop the
790 underlying connection. Clients MUST NOT invoke operations between two
791 Bind Requests made as part of a multi-stage bind.
793 A client may abort a SASL bind negotiation by sending a BindRequest
794 with a different value in the mechanism field of SaslCredentials, or
795 an AuthenticationChoice other than sasl.
797 If the client sends a BindRequest with the sasl mechanism field as an
798 empty string, the server MUST return a BindResponse with
799 authMethodNotSupported as the resultCode. This will allow clients to
800 abort a negotiation if it wishes to try again with the same SASL
803 A failed Bind Operation has the effect of leaving the connection in
804 an anonymous state. An abandoned Bind operation also has the effect
805 of leaving the connection in an anonymous state when (and if) the
806 server processes the abandonment of the bind. Client implementers
807 should note that the client has no way of being sure when (or if) an
808 abandon request succeeds, therefore, to arrive at a known
809 authentication state after abandoning a bind operation, clients may
811 Sermersheim Internet-Draft - Expires Jun 2004 Page 14
\f
812 Lightweight Directory Access Protocol Version 3
814 either unbind (which results in the underlying connection being
815 closed) or by issuing a bind request and then examining the
816 BindResponse returned by the server.
820 The Bind Response is defined as follows.
822 BindResponse ::= [APPLICATION 1] SEQUENCE {
823 COMPONENTS OF LDAPResult,
824 serverSaslCreds [7] OCTET STRING OPTIONAL }
826 BindResponse consists simply of an indication from the server of the
827 status of the client's request for authentication.
829 A successful bind operation is indicated by a BindResponse with a
830 resultCode set to success. Otherwise, an appropriate result code is
831 set in the BindResponse. For bind, the protocolError result code may
832 be used to indicate that the version number supplied by the client is
835 If the client receives a BindResponse response where the resultCode
836 field is protocolError, it MUST close the connection as the server
837 will be unwilling to accept further operations. (This is for
838 compatibility with earlier versions of LDAP, in which the bind was
839 always the first operation, and there was no negotiation.)
841 The serverSaslCreds are used as part of a SASL-defined bind mechanism
842 to allow the client to authenticate the server to which it is
843 communicating, or to perform "challenge-response" authentication. If
844 the client bound with the simple choice, or the SASL mechanism does
845 not require the server to return information to the client, then this
846 field SHALL NOT be included in the BindResponse.
849 4.3. Unbind Operation
851 The function of the Unbind Operation is to terminate an LDAP
852 association and connection. The Unbind operation is not the
853 antithesis of the Bind operation as the name implies. The naming of
854 these operations is historical. The Unbind operation should be
855 thought of as the "quit" operation.
857 The Unbind Operation is defined as follows:
859 UnbindRequest ::= [APPLICATION 2] NULL
861 The Unbind Operation has no response defined. Upon transmission of
862 the UnbindRequest, each protocol peer is to consider the LDAP
863 association terminated, MUST cease transmission of messages to the
864 other peer, and MUST close the connection. Any outstanding operations
865 on the server are, when possible, abandoned, and when not possible,
866 completed without transmission of the response.
869 Sermersheim Internet-Draft - Expires Jun 2004 Page 15
\f
870 Lightweight Directory Access Protocol Version 3
873 4.4. Unsolicited Notification
875 An unsolicited notification is an LDAPMessage sent from the server to
876 the client which is not in response to any LDAPMessage received by
877 the server. It is used to signal an extraordinary condition in the
878 server or in the connection between the client and the server. The
879 notification is of an advisory nature, and the server will not expect
880 any response to be returned from the client.
882 The unsolicited notification is structured as an LDAPMessage in which
883 the messageID is zero and protocolOp is of the extendedResp form. The
884 responseName field of the ExtendedResponse always contains an LDAPOID
885 which is unique for this notification.
887 One unsolicited notification (Notice of Disconnection) is defined in
888 this document. The specification of an unsolicited notification
891 - the OBJECT IDENTIFIER assigned to the notification (to be
892 specified in the responseName,
894 - the format of the contents (if any) of the responseValue,
896 - the circumstances which will cause the notification to be
899 - the semantics of the operation.
902 4.4.1. Notice of Disconnection
904 This notification may be used by the server to advise the client that
905 the server is about to close the connection due to an error
906 condition. Note that this notification is NOT a response to an unbind
907 requested by the client: the server MUST follow the procedures of
908 Section 4.3. This notification is intended to assist clients in
909 distinguishing between an error condition and a transient network
910 failure. As with a connection close due to network failure, the
911 client MUST NOT assume that any outstanding requests which modified
912 the Directory have succeeded or failed.
914 The responseName is 1.3.6.1.4.1.1466.20036, the response field is
915 absent, and the resultCode is used to indicate the reason for the
918 The following result codes have these meanings when used in this
921 - protocolError: The server has received data from the client in
922 which the LDAPMessage structure could not be parsed.
924 - strongAuthRequired: The server has detected that an established
925 security association between the client and server has
927 Sermersheim Internet-Draft - Expires Jun 2004 Page 16
\f
928 Lightweight Directory Access Protocol Version 3
930 unexpectedly failed or been compromised, or that the server now
931 requires the client to authenticate using a strong(er) mechanism.
933 - unavailable: This server will stop accepting new connections and
934 operations on all existing connections, and be unavailable for an
935 extended period of time. The client may make use of an alternative
938 Upon transmission of the UnbindRequest, each protocol peer is to
939 consider the LDAP association terminated, MUST cease transmission of
940 messages to the other peer, and MUST close the connection.
943 4.5. Search Operation
945 The Search Operation is used to request a server to return, subject
946 to access controls and other restrictions, a set of entries matching
947 a complex search criterion. This can be used to read attributes from
948 a single entry, from entries immediately subordinate to a particular
949 entry, or a whole subtree of entries.
952 4.5.1. Search Request
954 The Search Request is defined as follows:
956 SearchRequest ::= [APPLICATION 3] SEQUENCE {
962 derefAliases ENUMERATED {
963 neverDerefAliases (0),
964 derefInSearching (1),
965 derefFindingBaseObj (2),
967 sizeLimit INTEGER (0 .. maxInt),
968 timeLimit INTEGER (0 .. maxInt),
971 attributes AttributeSelection }
973 AttributeSelection ::= SEQUENCE OF selection LDAPString
974 -- constrained to <attributeSelection> below
977 and [0] SET SIZE (1..MAX) OF filter Filter,
978 or [1] SET SIZE (1..MAX) OF filter Filter,
980 equalityMatch [3] AttributeValueAssertion,
981 substrings [4] SubstringFilter,
982 greaterOrEqual [5] AttributeValueAssertion,
983 lessOrEqual [6] AttributeValueAssertion,
985 Sermersheim Internet-Draft - Expires Jun 2004 Page 17
\f
986 Lightweight Directory Access Protocol Version 3
988 present [7] AttributeDescription,
989 approxMatch [8] AttributeValueAssertion,
990 extensibleMatch [9] MatchingRuleAssertion }
992 SubstringFilter ::= SEQUENCE {
993 type AttributeDescription,
994 -- at least one must be present,
995 -- initial and final can occur at most once
996 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
997 initial [0] AssertionValue,
998 any [1] AssertionValue,
999 final [2] AssertionValue } }
1001 MatchingRuleAssertion ::= SEQUENCE {
1002 matchingRule [1] MatchingRuleId OPTIONAL,
1003 type [2] AttributeDescription OPTIONAL,
1004 matchValue [3] AssertionValue,
1005 dnAttributes [4] BOOLEAN DEFAULT FALSE }
1007 Parameters of the Search Request are:
1009 - baseObject: The name of the base object entry relative to which
1010 the search is to be performed.
1012 - scope: Specifies the scope of the search to be performed. The
1013 semantics (as described in [X.511]) of the possible values of this
1016 baseObject: The scope is constrained to the entry named by
1019 oneLevel: The scope is constrained to the immediate
1020 subordinates of the entry named by baseObject.
1022 wholeSubtree: the scope is constrained to the entry named
1023 by the baseObject, and all its subordinates.
1026 - derefAliases: An indicator as to how alias objects (as defined in
1027 [X.501]) are to be handled in searching. The semantics of the
1028 possible values of this field are:
1030 neverDerefAliases: Do not dereference aliases in searching
1031 or in locating the base object of the search.
1033 derefInSearching: While searching, dereference any alias
1034 object subordinate to the base object which is also in the
1035 search scope. The filter is applied to the dereferenced
1036 object(s). If the search scope is wholeSubtree, the search
1037 continues in the subtree of any dereferenced object.
1038 Aliases in that subtree are also dereferenced. Servers
1039 SHOULD detect looping in this process to prevent denial of
1040 service attacks and duplicate entries.
1043 Sermersheim Internet-Draft - Expires Jun 2004 Page 18
\f
1044 Lightweight Directory Access Protocol Version 3
1046 derefFindingBaseObj: Dereference aliases in locating the
1047 base object of the search, but not when searching
1048 subordinates of the base object.
1050 derefAlways: Dereference aliases both in searching and in
1051 locating the base object of the search.
1053 - sizeLimit: A size limit that restricts the maximum number of
1054 entries to be returned as a result of the search. A value of zero
1055 in this field indicates that no client-requested size limit
1056 restrictions are in effect for the search. Servers may enforce a
1057 maximum number of entries to return.
1059 - timeLimit: A time limit that restricts the maximum time (in
1060 seconds) allowed for a search. A value of zero in this field
1061 indicates that no client-requested time limit restrictions are in
1062 effect for the search. Servers may enforce a maximum time limit
1065 - typesOnly: An indicator as to whether search results are to
1066 contain both attribute descriptions and values, or just attribute
1067 descriptions. Setting this field to TRUE causes only attribute
1068 descriptions (no values) to be returned. Setting this field to
1069 FALSE causes both attribute descriptions and values to be
1072 - filter: A filter that defines the conditions that must be
1073 fulfilled in order for the search to match a given entry.
1075 The 'and', 'or' and 'not' choices can be used to form combinations
1076 of filters. At least one filter element MUST be present in an
1077 'and' or 'or' choice. The others match against individual
1078 attribute values of entries in the scope of the search.
1079 (Implementor's note: the 'not' filter is an example of a tagged
1080 choice in an implicitly-tagged module. In BER this is treated as
1081 if the tag was explicit.)
1083 A server MUST evaluate filters according to the three-valued logic
1084 of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated
1085 to either "TRUE", "FALSE" or "Undefined". If the filter evaluates
1086 to TRUE for a particular entry, then the attributes of that entry
1087 are returned as part of the search result (subject to any
1088 applicable access control restrictions). If the filter evaluates
1089 to FALSE or Undefined, then the entry is ignored for the search.
1091 A filter of the "and" choice is TRUE if all the filters in the SET
1092 OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
1093 otherwise Undefined. A filter of the "or" choice is FALSE if all
1094 of the filters in the SET OF evaluate to FALSE, TRUE if at least
1095 one filter is TRUE, and Undefined otherwise. A filter of the "not"
1096 choice is TRUE if the filter being negated is FALSE, FALSE if it
1097 is TRUE, and Undefined if it is Undefined.
1099 The present match evaluates to TRUE where there is an attribute or
1101 Sermersheim Internet-Draft - Expires Jun 2004 Page 19
\f
1102 Lightweight Directory Access Protocol Version 3
1104 subtype of the specified attribute description present in an
1105 entry, and FALSE otherwise (including a presence test with an
1106 unrecognized attribute description.)
1108 The matching rule for equalityMatch filter items is defined by the
1109 EQUALITY matching rule for the attribute type.
1111 The matching rule for AssertionValues in a substrings filter item
1112 is defined by the SUBSTR matching rule for the attribute type.
1113 Note that the AssertionValue in a substrings filter item MUST
1114 conform to the assertion syntax of the EQUALITY matching rule for
1115 the attribute type rather than the assertion syntax of the SUBSTR
1116 matching rule for the attribute type. The entire SubstringFilter
1117 is converted into an assertion value of the substrings matching
1118 rule prior to applying the rule.
1120 The matching rule for greaterOrEqual and lessOrEqual filter items
1121 is defined by the ORDERING matching rule for the attribute type.
1123 The approxMatch evaluates to TRUE when there is a value of the
1124 attribute or subtype for which some locally-defined approximate
1125 matching algorithm (e.g. spelling variations, phonetic match,
1126 etc.) returns TRUE. If an item matches for equality, it also
1127 satisfies an approximate match. If approximate matching is not
1128 supported, this filter item should be treated as an equalityMatch.
1130 An extensibleMatch is evaluated as follows:
1133 If the matchingRule field is absent, the type field MUST be
1134 present, and an equality match is performed for that type.
1137 If the type field is absent and the matchingRule is present, the
1138 matchValue is compared against all attributes in an entry which
1139 support that matchingRule. The matchingRule determines the
1140 syntax for the assertion value. The filter item evaluates to
1141 TRUE if it matches with at least one attribute in the entry,
1142 FALSE if it does not match any attribute in the entry, and
1143 Undefined if the matchingRule is not recognized or the
1144 assertionValue is invalid.
1147 If the type field is present and the matchingRule is present,
1148 the matchValue is compared against entry attributes of the
1149 specified type. In this case, the matchingRule MUST be one
1150 suitable for use with the specified type (see [Syntaxes]),
1151 otherwise the filter item is undefined.
1154 If the dnAttributes field is set to TRUE, the match is
1155 additionally applied against all the AttributeValueAssertions in
1156 an entry's distinguished name, and evaluates to TRUE if there is
1157 at least one attribute in the distinguished name for which the
1158 filter item evaluates to TRUE. The dnAttributes field is present
1159 to alleviate the need for multiple versions of generic matching
1160 rules (such as word matching), where one applies to entries and
1163 Sermersheim Internet-Draft - Expires Jun 2004 Page 20
\f
1164 Lightweight Directory Access Protocol Version 3
1166 another applies to entries and dn attributes as well.
1168 A filter item evaluates to Undefined when the server would not be
1169 able to determine whether the assertion value matches an entry. If
1170 an attribute description in an equalityMatch, substrings,
1171 greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter
1172 is not recognized by the server, a matching rule id in the
1173 extensibleMatch is not recognized by the server, the assertion
1174 value is invalid, or the type of filtering requested is not
1175 implemented, then the filter is Undefined. Thus for example if a
1176 server did not recognize the attribute type shoeSize, a filter of
1177 (shoeSize=*) would evaluate to FALSE, and the filters
1178 (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to
1181 Servers MUST NOT return errors if attribute descriptions or
1182 matching rule ids are not recognized, assertion values are
1183 invalid, or the assertion syntax is not supported. More details of
1184 filter processing are given in Section 7.8 of [X.511].
1186 - attributes: A list of the attributes to be returned from each
1187 entry which matches the search filter. LDAPString values of this
1188 field are constrained to the following Augmented Backus-Naur Form
1191 attributeSelection = noattrs /
1192 *( attributedescription / specialattr )
1194 noattrs = %x31 %x2E %x31 ; "1.1"
1196 specialattr = ASTERISK
1198 ASTERISK = %x2A ; asterisk ("*")
1200 <attributedescription> is defined in Section 2.5 of [Models].
1202 There are two special values which may be used: an empty list with
1203 no attributes, and the attribute description string "*". Both of
1204 these signify that all user attributes are to be returned. (The
1205 "*" allows the client to request all user attributes in addition
1206 to any specified operational attributes). Client implementors
1207 should note that even if all user attributes are requested, some
1208 attributes and or attribute values of the entry may not be
1209 included in search results due to access controls or other
1210 restrictions. Furthermore, servers will not return operational
1211 attributes, such as objectClasses or attributeTypes, unless they
1212 are listed by name. Operational attributes are described in
1215 Attributes MUST NOT be named more than once in the list, and are
1216 returned at most once in an entry. If there are attribute
1217 descriptions in the list which are not recognized, they are
1218 ignored by the server.
1221 Sermersheim Internet-Draft - Expires Jun 2004 Page 21
\f
1222 Lightweight Directory Access Protocol Version 3
1224 If the client does not want any attributes returned, it can
1225 specify a list containing only the attribute with OID "1.1". This
1226 OID was chosen because it does not (and can not) correspond to any
1229 Note that an X.500 "list"-like operation can be emulated by the
1230 client requesting a one-level LDAP search operation with a filter
1231 checking for the presence of the objectClass attribute, and that an
1232 X.500 "read"-like operation can be emulated by a base object LDAP
1233 search operation with the same filter. A server which provides a
1234 gateway to X.500 is not required to use the Read or List operations,
1235 although it may choose to do so, and if it does, it must provide the
1236 same semantics as the X.500 search operation.
1239 4.5.2. Search Result
1241 The results of the search operation are returned as zero or more
1242 searchResultEntry messages, zero or more SearchResultReference
1243 messages, followed by a single searchResultDone message.
1245 SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
1247 attributes PartialAttributeList }
1249 PartialAttributeList ::= SEQUENCE OF
1250 partialAttribute PartialAttribute
1251 -- Note that the PartialAttributeList may hold zero elements.
1252 -- This may happen when none of the attributes of an entry
1253 -- were requested, or could be returned.
1254 -- Note also that the partialAttribute vals set may hold zero
1255 -- elements. This may happen when typesOnly is requested, access
1256 -- controls prevent the return of values, or other reasons.
1258 SearchResultReference ::= [APPLICATION 19] SEQUENCE
1259 SIZE (1..MAX) OF uri URI
1261 SearchResultDone ::= [APPLICATION 5] LDAPResult
1263 Each SearchResultEntry represents an entry found during the search.
1264 Each SearchResultReference represents an area not yet explored during
1265 the search. The SearchResultEntry and SearchResultReference PDUs may
1266 come in any order. Following all the SearchResultReference and
1267 SearchResultEntry responses, the server returns a SearchResultDone
1268 response, which contains an indication of success, or detailing any
1269 errors that have occurred.
1271 Each entry returned in a SearchResultEntry will contain all
1272 appropriate attributes as specified in the attributes field of the
1273 Search Request. Return of attributes is subject to access control and
1274 other administrative policy.
1276 Some attributes may be constructed by the server and appear in a
1277 SearchResultEntry attribute list, although they are not stored
1279 Sermersheim Internet-Draft - Expires Jun 2004 Page 22
\f
1280 Lightweight Directory Access Protocol Version 3
1282 attributes of an entry. Clients SHOULD NOT assume that all attributes
1283 can be modified, even if permitted by access control.
1285 If the server's schema defines short names [Models] for an attribute
1286 type then the server SHOULD use one of those names in attribute
1287 descriptions for that attribute type (in preference to using the
1288 <numericoid> [Models] format of the attribute type's object
1289 identifier). The server SHOULD NOT use the short name if that name is
1290 known by the server to be ambiguous, or otherwise likely to cause
1291 interoperability problems.
1294 4.5.3. Continuation References in the Search Result
1296 If the server was able to locate the entry referred to by the
1297 baseObject but was unable to search all the entries in the scope at
1298 and subordinate to the baseObject, the server may return one or more
1299 SearchResultReference entries, each containing a reference to another
1300 set of servers for continuing the operation. A server MUST NOT return
1301 any SearchResultReference if it has not located the baseObject and
1302 thus has not searched any entries; in this case it would return a
1303 SearchResultDone containing a referral result code.
1305 If a server holds a copy or partial copy of the subordinate naming
1306 context, it may use the search filter to determine whether or not to
1307 return a SearchResultReference response. Otherwise
1308 SearchResultReference responses are always returned when in scope.
1310 The SearchResultReference is of the same data type as the Referral.
1312 A URI for a server implementing LDAP and accessible via [TCP]/[IP]
1313 (v4 or v6) is written as an LDAP URL according to [LDAPURL].
1315 In order to complete the search, the client issues a new search
1316 operation for each SearchResultReference that is returned. Note that
1317 the abandon operation described in Section 4.11 applies only to a
1318 particular operation sent on an association between a client and
1319 server. The client must abandon subsequent search operations it
1320 wishes to individually.
1322 Clients that follow search continuation references MUST ensure that
1323 they do not loop between servers. They MUST NOT repeatedly contact
1324 the same server for the same request with the same target entry name,
1325 scope and filter. Some clients use a counter that is incremented each
1326 time search result reference handling occurs for an operation, and
1327 these kinds of clients MUST be able to handle at least ten nested
1328 search result references between the root and a leaf entry.
1330 When an LDAP URL is used, the following instructions are followed:
1331 - The <dn> part of the URL MUST be present, with the new target
1332 object name. The client MUST use this name when following the
1333 referral. Note that UTF-8 characters appearing in a DN or search
1334 filter may not be legal for URLs (e.g. spaces) and MUST be
1335 escaped using the % method in [URI].
1337 Sermersheim Internet-Draft - Expires Jun 2004 Page 23
\f
1338 Lightweight Directory Access Protocol Version 3
1340 - It is RECOMMENDED that the <dn> part be present to avoid
1342 - Some servers (e.g. participating in distributed indexing) may
1343 provide a different filter in a URL of a SearchResultReference.
1344 - If the <filter> part of the URL is present, the client MUST use
1345 this filter in its next request to progress this search, and if
1346 it is not present the client MUST use the same filter as it used
1348 - If the originating search scope was singleLevel, the <scope>
1349 part of the URL will be "base".
1350 - it is RECOMMENDED that the <scope> part be present to avoid
1352 - If the <scope> part is missing, the scope of the original search
1353 is used by the client to progress the operation.
1354 - Other aspects of the new search request may be the same as or
1355 different from the search request which generated the
1356 SearchResultReference.
1357 - The name of an unexplored subtree in a SearchResultReference
1358 need not be subordinate to the base object.
1360 Other kinds of URIs may be returned. The syntax and semantics of such
1361 URIs is left to future specifications. Clients ignore URIs that they
1367 For example, suppose the contacted server (hosta) holds the entry
1368 "DC=Example,DC=NET" and the entry "CN=Manager,DC=Example,DC=NET". It
1369 knows that either LDAP-capable servers (hostb) or (hostc) hold
1370 "OU=People,DC=Example,DC=NET" (one is the master and the other server
1371 a shadow), and that LDAP-capable server (hostd) holds the subtree
1372 "OU=Roles,DC=Example,DC=NET". If a subtree search of
1373 "DC=Example,DC=NET" is requested to the contacted server, it may
1374 return the following:
1376 SearchResultEntry for DC=Example,DC=NET
1377 SearchResultEntry for CN=Manager,DC=Example,DC=NET
1378 SearchResultReference {
1379 ldap://hostb/OU=People,DC=Example,DC=NET??sub
1380 ldap://hostc/OU=People,DC=Example,DC=NET??sub }
1381 SearchResultReference {
1382 ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
1383 SearchResultDone (success)
1385 Client implementors should note that when following a
1386 SearchResultReference, additional SearchResultReference may be
1387 generated. Continuing the example, if the client contacted the server
1388 (hostb) and issued the search for the subtree
1389 "OU=People,DC=Example,DC=NET", the server might respond as follows:
1391 SearchResultEntry for OU=People,DC=Example,DC=NET
1392 SearchResultReference {
1393 ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
1395 Sermersheim Internet-Draft - Expires Jun 2004 Page 24
\f
1396 Lightweight Directory Access Protocol Version 3
1398 SearchResultReference {
1399 ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
1400 SearchResultDone (success)
1402 If the contacted server does not hold the base object for the search,
1403 then it will return a referral to the client. For example, if the
1404 client requests a subtree search of "DC=Example,DC=ORG" to hosta, the
1405 server may return only a SearchResultDone containing a referral.
1407 SearchResultDone (referral) {
1408 ldap://hostg/DC=Example,DC=ORG??sub }
1411 4.6. Modify Operation
1413 The Modify Operation allows a client to request that a modification
1414 of an entry be performed on its behalf by a server. The Modify
1415 Request is defined as follows:
1417 ModifyRequest ::= [APPLICATION 6] SEQUENCE {
1419 changes SEQUENCE OF change SEQUENCE {
1420 operation ENUMERATED {
1424 modification PartialAttribute } }
1426 Parameters of the Modify Request are:
1428 - object: The name of the object to be modified. The value of this
1429 field contains the DN of the entry to be modified. The server
1430 SHALL NOT perform any alias dereferencing in determining the
1431 object to be modified.
1433 - changes: A list of modifications to be performed on the entry. The
1434 entire list of modifications MUST be performed in the order they
1435 are listed, as a single atomic operation. While individual
1436 modifications may violate certain aspects of the directory schema
1437 (such as the object class definition and DIT content rule), the
1438 resulting entry after the entire list of modifications is
1439 performed MUST conform to the requirements of the directory
1442 - operation: Used to specify the type of modification being
1443 performed. Each operation type acts on the following
1444 modification. The values of this field have the following
1445 semantics respectively:
1447 add: add values listed to the modification attribute,
1448 creating the attribute if necessary;
1450 delete: delete values listed from the modification
1451 attribute, removing the entire attribute if no values are
1453 Sermersheim Internet-Draft - Expires Jun 2004 Page 25
\f
1454 Lightweight Directory Access Protocol Version 3
1456 listed, or if all current values of the attribute are
1457 listed for deletion;
1459 replace: replace all existing values of the modification
1460 attribute with the new values listed, creating the
1461 attribute if it did not already exist. A replace with no
1462 value will delete the entire attribute if it exists, and is
1463 ignored if the attribute does not exist.
1465 - modification: A PartialAttribute (which may have an empty SET of
1466 vals) used to hold the attribute type or attribute type and
1467 values being modified.
1469 Upon receipt of a Modify Request, the server attempts to perform the
1470 necessary modifications to the DIT and returns the result in a Modify
1471 Response, defined as follows:
1473 ModifyResponse ::= [APPLICATION 7] LDAPResult
1475 The server will return to the client a single Modify Response
1476 indicating either the successful completion of the DIT modification,
1477 or the reason that the modification failed. Note that due to the
1478 requirement for atomicity in applying the list of modifications in
1479 the Modify Request, the client may expect that no modifications of
1480 the DIT have been performed if the Modify Response received indicates
1481 any sort of error, and that all requested modifications have been
1482 performed if the Modify Response indicates successful completion of
1483 the Modify Operation. If the association changes or the connection
1484 fails, whether the modification occurred or not is indeterminate.
1486 The Modify Operation cannot be used to remove from an entry any of
1487 its distinguished values, i.e. those values which form the entry's
1488 relative distinguished name. An attempt to do so will result in the
1489 server returning the notAllowedOnRDN result code. The Modify DN
1490 Operation described in Section 4.9 is used to rename an entry.
1492 Note that due to the simplifications made in LDAP, there is not a
1493 direct mapping of the changes in an LDAP ModifyRequest onto the
1494 changes of a DAP ModifyEntry operation, and different implementations
1495 of LDAP-DAP gateways may use different means of representing the
1496 change. If successful, the final effect of the operations on the
1497 entry MUST be identical.
1502 The Add Operation allows a client to request the addition of an entry
1503 into the Directory. The Add Request is defined as follows:
1505 AddRequest ::= [APPLICATION 8] SEQUENCE {
1507 attributes AttributeList }
1509 AttributeList ::= SEQUENCE OF attribute Attribute
1511 Sermersheim Internet-Draft - Expires Jun 2004 Page 26
\f
1512 Lightweight Directory Access Protocol Version 3
1515 Parameters of the Add Request are:
1517 - entry: the name of the entry to be added. Note that the server
1518 SHALL NOT dereference any aliases in locating the entry to be
1521 - attributes: the list of attributes that make up the content of the
1522 entry being added. Clients MUST include distinguished values
1523 (those forming the entry's own RDN) in this list, the objectClass
1524 attribute, and values of any mandatory attributes of the listed
1525 object classes. Clients MUST NOT supply NO-USER-MODIFICATION
1526 attributes such as the createTimestamp or creatorsName attributes,
1527 since the server maintains these automatically.
1529 The entry named in the entry field of the AddRequest MUST NOT exist
1530 for the AddRequest to succeed. The immediate superior (parent) of an
1531 object or alias entry to be added MUST exist. For example, if the
1532 client attempted to add "CN=JS,DC=Example,DC=NET", the
1533 "DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did
1534 exist, then the server would return the noSuchObject result code with
1535 the matchedDN field containing "DC=NET". If the parent entry exists
1536 but is not in a naming context held by the server, the server SHOULD
1537 return a referral to the server holding the parent entry.
1539 Server implementations SHOULD NOT restrict where entries can be
1540 located in the Directory unless DIT structure rules are in place.
1541 Some servers allow the administrator to restrict the classes of
1542 entries which can be added to the Directory.
1544 Upon receipt of an Add Request, a server will attempt to add the
1545 requested entry. The result of the add attempt will be returned to
1546 the client in the Add Response, defined as follows:
1548 AddResponse ::= [APPLICATION 9] LDAPResult
1550 A response of success indicates that the new entry is present in the
1554 4.8. Delete Operation
1556 The Delete Operation allows a client to request the removal of an
1557 entry from the Directory. The Delete Request is defined as follows:
1559 DelRequest ::= [APPLICATION 10] LDAPDN
1561 The Delete Request consists of the name of the entry to be deleted.
1562 The server SHALL NOT dereference aliases while resolving the name of
1563 the target entry to be removed.
1565 Only leaf entries (those with no subordinate entries) can be deleted
1566 with this operation.
1569 Sermersheim Internet-Draft - Expires Jun 2004 Page 27
\f
1570 Lightweight Directory Access Protocol Version 3
1572 Upon receipt of a Delete Request, a server will attempt to perform
1573 the entry removal requested and return the result in the Delete
1574 Response defined as follows:
1576 DelResponse ::= [APPLICATION 11] LDAPResult
1579 4.9. Modify DN Operation
1581 The Modify DN Operation allows a client to change the Relative
1582 Distinguished Name (RDN) of an entry in the Directory, and/or to move
1583 a subtree of entries to a new location in the Directory. The Modify
1584 DN Request is defined as follows:
1586 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
1588 newrdn RelativeLDAPDN,
1589 deleteoldrdn BOOLEAN,
1590 newSuperior [0] LDAPDN OPTIONAL }
1592 Parameters of the Modify DN Request are:
1594 - entry: the name of the entry to be changed. This entry may or may
1595 not have subordinate entries. Note that the server SHALL NOT
1596 dereference any aliases in locating the entry to be changed.
1598 - newrdn: the new RDN of the entry.
1600 - deleteoldrdn: a boolean parameter that controls whether the old
1601 RDN attribute values are to be retained as attributes of the
1602 entry, or deleted from the entry.
1604 - newSuperior: if present, this is the name of an existing object
1605 entry which becomes the immediate superior (parent) of the
1608 Upon receipt of a ModifyDNRequest, a server will attempt to perform
1609 the name change and return the result in the Modify DN Response,
1612 ModifyDNResponse ::= [APPLICATION 13] LDAPResult
1614 For example, if the entry named in the "entry" parameter was "cn=John
1615 Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the
1616 newSuperior parameter was absent, then this operation would attempt
1617 to rename the entry to be "cn=John Cougar Smith,c=US". If there was
1618 already an entry with that name, the operation would fail with the
1619 entryAlreadyExists result code.
1621 The object named in newSuperior MUST exist. For example, if the
1622 client attempted to add "CN=JS,DC=Example,DC=NET", the
1623 "DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did
1624 exist, then the server would return the noSuchObject result code with
1625 the matchedDN field containing "DC=NET".
1627 Sermersheim Internet-Draft - Expires Jun 2004 Page 28
\f
1628 Lightweight Directory Access Protocol Version 3
1631 If the deleteoldrdn parameter is TRUE, the values forming the old RDN
1632 are deleted from the entry. If the deleteoldrdn parameter is FALSE,
1633 the values forming the old RDN will be retained as non-distinguished
1634 attribute values of the entry. The server MUST fail the operation and
1635 return an error in the result code if the setting of the deleteoldrdn
1636 parameter would cause a schema inconsistency in the entry.
1638 Note that X.500 restricts the ModifyDN operation to only affect
1639 entries that are contained within a single server. If the LDAP server
1640 is mapped onto DAP, then this restriction will apply, and the
1641 affectsMultipleDSAs result code will be returned if this error
1642 occurred. In general, clients MUST NOT expect to be able to perform
1643 arbitrary movements of entries and subtrees between servers or
1644 between naming contexts.
1647 4.10. Compare Operation
1649 The Compare Operation allows a client to compare an assertion
1650 provided with an entry in the Directory. The Compare Request is
1653 CompareRequest ::= [APPLICATION 14] SEQUENCE {
1655 ava AttributeValueAssertion }
1657 Parameters of the Compare Request are:
1659 - entry: the name of the entry to be compared. Note that the server
1660 SHALL NOT dereference any aliases in locating the entry to be
1663 - ava: the assertion with which an attribute in the entry is to be
1666 Upon receipt of a Compare Request, a server will attempt to perform
1667 the requested comparison using the EQUALITY matching rule for the
1668 attribute type and return the result in the Compare Response, defined
1671 CompareResponse ::= [APPLICATION 15] LDAPResult
1673 In the event that the attribute or subtype is not present in the
1674 entry, the resultCode field is set to noSuchAttribute. If the
1675 attribute is unknown, the resultCode is set to
1676 undefinedAttributeType. Note that errors and the result of comparison
1677 are all returned in the same construct.
1679 Note that some directory systems may establish access controls which
1680 permit the values of certain attributes (such as userPassword) to be
1681 compared but not interrogated by other means.
1685 Sermersheim Internet-Draft - Expires Jun 2004 Page 29
\f
1686 Lightweight Directory Access Protocol Version 3
1688 4.11. Abandon Operation
1690 The function of the Abandon Operation is to allow a client to request
1691 that the server abandon an outstanding operation. The Abandon Request
1692 is defined as follows:
1694 AbandonRequest ::= [APPLICATION 16] MessageID
1696 The MessageID MUST be that of an operation which was requested
1697 earlier in this LDAP association. The abandon request itself has its
1698 own message id. This is distinct from the id of the earlier operation
1701 There is no response defined in the Abandon operation. Upon receipt
1702 of an AbandonRequest, the server MAY abandon the operation identified
1703 by the MessageID. Operation responses are not sent for successfully
1704 abandoned operations, thus the application of the Abandon operation
1705 is limited to uses where the client does not require an indication of
1708 Abandon and Unbind operations cannot be abandoned. The ability to
1709 abandon other (particularly update) operations is at the discretion
1712 In the event that a server receives an Abandon Request on a Search
1713 Operation in the midst of transmitting responses to the search, that
1714 server MUST cease transmitting entry responses to the abandoned
1715 request immediately, and MUST NOT send the SearchResponseDone. Of
1716 course, the server MUST ensure that only properly encoded LDAPMessage
1717 PDUs are transmitted.
1719 Clients MUST NOT send abandon requests for the same operation
1720 multiple times, and MUST also be prepared to receive results from
1721 operations it has abandoned (since these may have been in transit
1722 when the abandon was requested, or are not able to be abandoned).
1724 Servers MUST discard abandon requests for message IDs they do not
1725 recognize, for operations which cannot be abandoned, and for
1726 operations which have already been abandoned.
1729 4.12. Extended Operation
1731 The extended operation allows additional operations to be defined for
1732 services not already available in the protocol. For example, to add
1733 operations to install transport layer security (see Section 4.13).
1735 The extended operation allows clients to make requests and receive
1736 responses with predefined syntaxes and semantics. These may be
1737 defined in RFCs or be private to particular implementations.
1739 Each extended operation consists of an extended request and an
1743 Sermersheim Internet-Draft - Expires Jun 2004 Page 30
\f
1744 Lightweight Directory Access Protocol Version 3
1746 ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
1747 requestName [0] LDAPOID,
1748 requestValue [1] OCTET STRING OPTIONAL }
1750 The requestName is a dotted-decimal representation of the unique
1751 OBJECT IDENTIFIER corresponding to the request. The requestValue is
1752 information in a form defined by that request, encapsulated inside an
1755 The server will respond to this with an LDAPMessage containing the
1758 ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
1759 COMPONENTS OF LDAPResult,
1760 responseName [10] LDAPOID OPTIONAL,
1761 responseValue [11] OCTET STRING OPTIONAL }
1763 The responseName is typically not required to be present as the
1764 syntax and semantics of the response (including the format of the
1765 responseValue) is implicitly known and associated with the request by
1768 If the requestName is not recognized by the server, the server MUST
1769 NOT provide a responseName nor a responseValue and MUST return a
1770 resultCode of protocolError.
1772 The requestValue and responseValue fields contain any information
1773 associated with the operation. The format of these fields is defined
1774 by the specification of the extended operation. Implementations MUST
1775 be prepared to handle arbitrary contents of these fields, including
1776 zero bytes. Values that are defined in terms of ASN.1 and BER encoded
1777 according to Section 5.1, also follow the extensibility rules in
1780 It is RECOMMENDED that servers list the requestName of extended
1781 operations they support in the supportedExtension attribute [Models]
1784 Extended operations may be specified in other documents. The
1785 specification of an extended operation consists of:
1787 - the OBJECT IDENTIFIER assigned to the requestName (and possibly
1790 - the format of the contents of the requestValue and responseValue
1793 - the semantics of the operation,
1796 4.13. StartTLS Operation
1801 Sermersheim Internet-Draft - Expires Jun 2004 Page 31
\f
1802 Lightweight Directory Access Protocol Version 3
1804 The Start Transport Layer Security (StartTLS) operation provides the
1805 ability to establish Transport Layer Security ([TLS]) on an LDAP
1806 connection. The StartTLS operation is defined using the extended
1807 operation mechanism described in Section 4.12.
1809 4.13.1. StartTLS Request
1811 A client requests TLS establishment by transmitting a StartTLS
1812 request PDU to the server. The StartTLS request is defined in terms
1813 of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
1814 and the requestValue field is always absent.
1816 The client MUST NOT send any PDUs on this connection following this
1817 request until it receives a StartTLS extended response.
1819 4.13.2. StartTLS Response
1821 When a StartTLS request is made, servers supporting the operation
1822 MUST return a StartTLS response PDU to the requestor. The StartTLS
1823 response responseName is also "1.3.6.1.4.1.1466.20037", and the
1824 response field is absent.
1826 The server MUST set the resultCode field to either success or one of
1827 the other values outlined in Section 4.13.2.2.
1829 4.13.2.1. "Success" Response
1831 If the StartTLS Response contains a result code of success, this
1832 indicates that the server is willing and able to negotiate TLS. Refer
1833 to Section 5.3 of [AuthMeth] for details.
1835 4.13.2.2. Response other than "success"
1837 If the ExtendedResponse contains a result code other than success,
1838 this indicates that the server is unwilling or unable to negotiate
1839 TLS. The following result codes have these meanings for this
1842 - operationsError: operations sequencing incorrect; e.g. TLS is
1843 already established.
1845 - protocolError: TLS is not supported or incorrect PDU structure.
1847 - unavailable: Some major problem with TLS, or the server is
1850 The server MUST return operationsError if the client violates any of
1851 the StartTLS extended operation sequencing requirements described in
1852 Section 5.3 of [AuthMeth].
1854 If the server does not support TLS (whether by design or by current
1855 configuration), it MUST set the resultCode field to protocolError.
1856 The client's current association is unaffected if the server does not
1858 Sermersheim Internet-Draft - Expires Jun 2004 Page 32
\f
1859 Lightweight Directory Access Protocol Version 3
1861 support TLS. The client may proceed with any LDAP operation, or it
1862 may close the connection.
1864 The server MUST return unavailable if it supports TLS but cannot
1865 establish a TLS connection for some reason, e.g. the certificate
1866 server not responding, it cannot contact its TLS implementation, or
1867 if the server is in process of shutting down. The client may retry
1868 the StartTLS operation, or it may proceed with any other LDAP
1869 operation, or it may close the LDAP connection.
1871 4.13.3. Closing a TLS Connection
1873 Two forms of TLS connection closure -- graceful and abrupt -- are
1876 4.13.3.1. Graceful Closure
1878 Either the client or server MAY terminate the TLS connection and
1879 leave the LDAP connection intact by sending and receiving a TLS
1882 The initiating protocol peer sends the TLS closure alert. If it
1883 wishes to leave the LDAP connection intact, it then MUST cease to
1884 send further PDUs and MUST ignore any received PDUs until it receives
1885 a TLS closure alert from the other peer.
1887 Once the initiating protocol peer receives a TLS closure alert from
1888 the other peer it MAY send and receive LDAP PDUs.
1890 When a protocol peer receives the initial TLS closure alert, it may
1891 choose to allow the underlying LDAP connection intact. In this case,
1892 it MUST immediately transmit a TLS closure alert. Following this, it
1893 MAY send and receive LDAP PDUs.
1895 Protocol peers MAY drop the underlying LDAP connection after sending
1896 or receiving a TLS closure alert.
1898 After the TLS connection has been closed, the server MUST NOT send
1899 responses to any request message received before the TLS closure.
1900 Thus, clients wishing to receive responses to messages sent while the
1901 TLS connection is intact MUST wait for those message responses before
1902 sending the TLS closure alert.
1904 4.13.3.2. Abrupt Closure
1906 Either the client or server MAY abruptly close the TLS connection by
1907 dropping the underlying transfer protocol connection. In this
1908 circumstance, a server MAY send the client a Notice of Disconnection
1909 before dropping the underlying LDAP connection.
1912 5. Protocol Element Encodings and Transfer
1915 Sermersheim Internet-Draft - Expires Jun 2004 Page 33
\f
1916 Lightweight Directory Access Protocol Version 3
1918 One underlying service, LDAP over TCP, is defined here. This service
1919 is generally applicable to applications providing or consuming X.500-
1920 based directory services on the Internet.
1922 Implementations of LDAP over TCP MUST implement the mapping as
1923 described in Section 5.2.1
1926 5.1. Protocol Encoding
1928 The protocol elements of LDAP SHALL be encoded for exchange using the
1929 Basic Encoding Rules [BER] of [ASN.1] with the following
1932 (1) Only the definite form of length encoding is used.
1934 (2) OCTET STRING values are encoded in the primitive form only.
1936 (3) If the value of a BOOLEAN type is true, the encoding of the
1937 value octet is set to hex "FF".
1939 (4) If a value of a type is its default value, it is absent. Only
1940 some BOOLEAN and INTEGER types have default values in this
1941 protocol definition.
1943 These restrictions are meant to ease the overhead of encoding and
1944 decoding certain elements in BER.
1946 These restrictions do not apply to ASN.1 types encapsulated inside of
1947 OCTET STRING values, such as attribute values, unless otherwise
1951 5.2. Transfer Protocols
1953 This protocol is designed to run over connection-oriented, reliable
1954 transports, with all 8 bits in an octet being significant in the data
1958 5.2.1. Transmission Control Protocol (TCP)
1960 The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
1961 bytestream using the BER-based encoding described in Section 5.1. It
1962 is recommended that server implementations running over the TCP
1963 provide a protocol listener on the assigned port, 389. Servers may
1964 instead provide a listener on a different port number. Clients MUST
1965 support contacting servers on any valid TCP port.
1968 6. Security Considerations
1970 This version of the protocol provides facilities for simple
1971 authentication using a cleartext password, as well as any [SASL]
1973 Sermersheim Internet-Draft - Expires Jun 2004 Page 34
\f
1974 Lightweight Directory Access Protocol Version 3
1976 mechanism. SASL allows for integrity and privacy services to be
1979 It is also permitted that the server can return its credentials to
1980 the client, if it chooses to do so.
1982 Use of cleartext password is strongly discouraged where the
1983 underlying transport service cannot guarantee confidentiality and may
1984 result in disclosure of the password to unauthorized parties.
1986 Servers are encouraged to prevent directory modifications by clients
1987 that have authenticated anonymously [AuthMeth].
1989 Requirements of authentication methods, SASL mechanisms, and TLS are
1990 described in [AuthMeth].
1992 It should be noted that SASL authentication exchanges do not provide
1993 data confidentiality nor integrity protection for the version or name
1994 fields of the bind request nor the resultCode, diagnosticMessage, or
1995 referral fields of the bind response nor of any information contained
1996 in controls attached to bind request or responses. Thus information
1997 contained in these fields SHOULD NOT be relied on unless otherwise
1998 protected (such as by establishing protections at the transport
2001 Server implementors should plan for the possibility of an identity
2002 associated with an LDAP connection being deleted, renamed, or
2003 modified, and take appropriate actions to prevent insecure side
2004 effects. Likewise, server implementors should plan for the
2005 possibility of an associated identity's credentials becoming invalid,
2006 or an identities privileges being changed. The way in which these
2007 issues are addressed are application
2008 and/or implementation specific.
2010 Implementations which cache attributes and entries obtained via LDAP
2011 MUST ensure that access controls are maintained if that information
2012 is to be provided to multiple clients, since servers may have access
2013 control policies which prevent the return of entries or attributes in
2014 search results except to particular authenticated clients. For
2015 example, caches could serve result information only to the client
2016 whose request caused it to be in the cache.
2018 Protocol servers may return referrals which redirect protocol clients
2019 to peer servers. It is possible for a rogue application to inject
2020 such referrals into the data stream in an attempt to redirect a
2021 client to a rogue server. Protocol clients are advised to be aware of
2022 this, and possibly reject referrals when confidentiality measures are
2023 not in place. Protocol clients are advised to reject referrals from
2024 the StartTLS operation.
2026 Protocol peers MUST be prepared to handle invalid and arbitrary
2027 length protocol encodings. A number of LDAP security advisories are
2028 available through [CERT].
2031 Sermersheim Internet-Draft - Expires Jun 2004 Page 35
\f
2032 Lightweight Directory Access Protocol Version 3
2037 This document updates RFC 2251 by Mark Wahl, Tim Howes, and Steve
2038 Kille. It also updates RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
2039 Mark Wahl. Their work along with the input of individuals of the IETF
2040 ASID, LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully
2044 8. Normative References
2046 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2047 Specifications: ABNF", RFC 2234, November 1997.
2049 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
2050 "Information Technology - Abstract Syntax Notation One
2051 (ASN.1): Specification of basic notation"
2053 [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
2054 Level Security Mechanisms ", draft-ietf-ldapbis-authmeth-
2055 xx.txt, (a work in progress).
2057 [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
2058 "Information technology - ASN.1 encoding rules:
2059 Specification of Basic Encoding Rules (BER), Canonical
2060 Encoding Rules (CER) and Distinguished Encoding Rules
2063 [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
2066 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
2067 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
2070 [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
2071 Requirement Levels", RFC 2119, March 1997.
2073 [LDAPDN] Zeilenga, K., "LDAP: String Representation of
2074 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
2077 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
2078 ldapbis-bcp64-xx.txt, (a work in progress).
2080 [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
2081 ldapbis-url-xx.txt, (a work in progress).
2083 [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
2084 ietf-ldapbis-models-xx.txt (a work in progress).
2086 [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
2087 draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
2089 Sermersheim Internet-Draft - Expires Jun 2004 Page 36
\f
2090 Lightweight Directory Access Protocol Version 3
2093 [SASL] Melnikov, A., "Simple Authentication and Security Layer",
2094 draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
2096 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
2097 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
2100 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
2101 Internationalized Strings ('stringprep')", draft-hoffman-
2102 rfc3454bis-xx.txt, a work in progress.
2104 [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
2105 Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
2108 [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
2111 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
2112 draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
2114 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
2115 3.2.0" is defined by "The Unicode Standard, Version 3.0"
2116 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
2117 as amended by the "Unicode Standard Annex #27: Unicode
2118 3.1" (http://www.unicode.org/reports/tr27/) and by the
2119 "Unicode Standard Annex #28: Unicode 3.2"
2120 (http://www.unicode.org/reports/tr28/).
2122 [URI] Berners-Lee, T., Fielding, R., and L. Masinter Uniform
2123 Resource Identifiers (URI): Generic Syntax", RFC 2396,
2126 [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode
2127 and ISO 10646", STD63 and RFC3629.
2129 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
2130 Models and Service", 1993.
2132 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
2134 [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
2138 9. Informative References
2140 [CERT] the CERT(R) Center, (http://www.cert.org)
2142 10. IANA Considerations
2147 Sermersheim Internet-Draft - Expires Jun 2004 Page 37
\f
2148 Lightweight Directory Access Protocol Version 3
2150 It is requested that the Internet Assigned Numbers Authority (IANA)
2151 update the occurrence of "RFC XXXX" in Appendix B with this RFC
2152 number at publication.
2154 11. Editor's Address
2158 1800 South Novell Place
2159 Provo, Utah 84606, USA
2205 Sermersheim Internet-Draft - Expires Jun 2004 Page 38
\f
2206 Lightweight Directory Access Protocol Version 3
2208 Appendix A - LDAP Result Codes
2210 This normative appendix details additional considerations regarding
2211 LDAP result codes and provides a brief, general description of each
2212 LDAP result code enumerated in Section 4.1.10.
2214 Additional result codes MAY be defined for use with extensions
2215 [LDAPIANA]. Client implementations SHALL treat any result code which
2216 they do not recognize as an unknown error condition.
2218 A.1 Non-Error Result Codes
2220 These result codes (called "non-error" result codes) do not indicate
2226 saslBindInProgress (14).
2228 The success, compareTrue, and compare result codes indicate
2229 successful completion (and, hence, are referred to as "successful"
2232 The referral and saslBindInProgress result codes indicate the client
2233 is required to take additional action to complete the operation
2238 Existing LDAP result codes are described as follows:
2241 Indicates the successful completion of an operation. Note:
2242 this code is not used with the compare operation. See
2243 compareTrue (5) and compareFalse (6).
2246 Indicates that the operation is not properly sequenced with
2247 relation to other operations (of same or different type).
2249 For example, this code is returned if the client attempts to
2250 StartTLS [RFC2246] while there are other operations
2251 outstanding or if TLS was already established.
2254 Indicates the server received data which has incorrect
2257 For bind operation only, this code is also used to indicate
2258 that the server does not support the requested protocol
2261 timeLimitExceeded (3)
2263 Sermersheim Internet-Draft - Expires Jun 2004 Page 39
\f
2264 Lightweight Directory Access Protocol Version 3
2266 Indicates that the time limit specified by the client was
2267 exceeded before the operation could be completed.
2269 sizeLimitExceeded (4)
2270 Indicates that the size limit specified by the client was
2271 exceeded before the operation could be completed.
2274 Indicates that the compare operation has successfully
2275 completed and the assertion has evaluated to FALSE.
2278 Indicates that the compare operation has successfully
2279 completed and the assertion has evaluated to TRUE.
2281 authMethodNotSupported (7)
2282 Indicates that the authentication method or mechanism is not
2285 strongAuthRequired (8)
2286 Indicates that the server has detected that an established
2287 security association between the client and server has
2288 unexpectedly failed or been compromised, or that the server
2289 now requires the client to authenticate using a strong(er)
2293 Indicates that a referral needs to be chased to complete the
2294 operation (see Section 4.1.11).
2296 adminLimitExceeded (11)
2297 Indicates that an administrative limit has been exceeded.
2299 unavailableCriticalExtension (12)
2300 Indicates that the server is unable or unwilling to perform a
2301 critical extension (see Section 4.1.12).
2303 confidentialityRequired (13)
2304 Indicates that data confidentiality protections are required.
2306 saslBindInProgress (14)
2307 Indicates the server requires the client to send a new bind
2308 request, with the same SASL mechanism, to continue the
2309 authentication process (see Section 4.2).
2311 noSuchAttribute (16)
2312 Indicates that the named entry does not contain the specified
2313 attribute or attribute value.
2315 undefinedAttributeType (17)
2316 Indicates that a request field contains an unrecognized
2317 attribute description.
2319 inappropriateMatching (18)
2321 Sermersheim Internet-Draft - Expires Jun 2004 Page 40
\f
2322 Lightweight Directory Access Protocol Version 3
2324 Indicates that an attempt was made, e.g. in a filter, to use
2325 a matching rule not defined for the attribute type concerned.
2327 constraintViolation (19)
2328 Indicates that the client supplied an attribute value which
2329 does not conform to the constraints placed upon it by the
2332 For example, this code is returned when multiple values are
2333 supplied to an attribute which has a SINGLE-VALUE constraint.
2335 attributeOrValueExists (20)
2336 Indicates that the client supplied an attribute or value to
2337 be added to an entry, but the attribute or value already
2340 invalidAttributeSyntax (21)
2341 Indicates that a purported attribute value does not conform
2342 to the syntax of the attribute.
2345 Indicates that the object does not exist in the DIT.
2348 Indicates that an alias problem has occurred. For example,
2349 the code may used to indicate an alias has been dereferenced
2350 which names no object.
2352 invalidDNSyntax (34)
2353 Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
2354 base, target entry, ModifyDN newrdn, etc.) of a request does
2355 not conform to the required syntax or contains attribute
2356 values which do not conform to the syntax of the attribute's
2359 aliasDereferencingProblem (36)
2360 Indicates that a problem occurred while dereferencing an
2361 alias. Typically an alias was encountered in a situation
2362 where it was not allowed or where access was denied.
2364 inappropriateAuthentication (48)
2365 Indicates the server requires the client which had attempted
2366 to bind anonymously or without supplying credentials to
2367 provide some form of credentials.
2369 invalidCredentials (49)
2370 Indicates that the provided credentials (e.g. the user's name
2371 and password) are invalid.
2373 insufficientAccessRights (50)
2374 Indicates that the client does not have sufficient access
2375 rights to perform the operation.
2379 Sermersheim Internet-Draft - Expires Jun 2004 Page 41
\f
2380 Lightweight Directory Access Protocol Version 3
2382 Indicates that the server is too busy to service the
2386 Indicates that the server is shutting down or a subsystem
2387 necessary to complete the operation is offline.
2389 unwillingToPerform (53)
2390 Indicates that the server is unwilling to perform the
2394 Indicates that the server has detected an internal loop.
2396 namingViolation (64)
2397 Indicates that the entry's name violates naming restrictions.
2399 objectClassViolation (65)
2400 Indicates that the entry violates object class restrictions.
2402 notAllowedOnNonLeaf (66)
2403 Indicates that the operation is inappropriately acting upon a
2406 notAllowedOnRDN (67)
2407 Indicates that the operation is inappropriately attempting to
2408 remove a value which forms the entry's relative distinguished
2411 entryAlreadyExists (68)
2412 Indicates that the request cannot be fulfilled (added, moved,
2413 or renamed) as the target entry already exists.
2415 objectClassModsProhibited (69)
2416 Indicates that an attempt to modify the object class(es) of
2417 an entry's objectClass attribute is prohibited.
2419 For example, this code is returned when a client attempts to
2420 modify the structural object class of an entry.
2422 affectsMultipleDSAs (71)
2423 Indicates that the operation cannot be completed as it
2424 affects multiple servers (DSAs).
2427 Indicates the server has encountered an internal error.
2437 Sermersheim Internet-Draft - Expires Jun 2004 Page 42
\f
2438 Lightweight Directory Access Protocol Version 3
2440 Appendix B - Complete ASN.1 Definition
2442 This appendix is normative.
2444 Lightweight-Directory-Access-Protocol-V3
2445 -- Copyright (C) The Internet Society (2003). This version of
2446 -- this ASN.1 module is part of RFC XXXX; see the RFC itself
2447 -- for full legal notices.
2450 EXTENSIBILITY IMPLIED ::=
2454 LDAPMessage ::= SEQUENCE {
2455 messageID MessageID,
2457 bindRequest BindRequest,
2458 bindResponse BindResponse,
2459 unbindRequest UnbindRequest,
2460 searchRequest SearchRequest,
2461 searchResEntry SearchResultEntry,
2462 searchResDone SearchResultDone,
2463 searchResRef SearchResultReference,
2464 modifyRequest ModifyRequest,
2465 modifyResponse ModifyResponse,
2466 addRequest AddRequest,
2467 addResponse AddResponse,
2468 delRequest DelRequest,
2469 delResponse DelResponse,
2470 modDNRequest ModifyDNRequest,
2471 modDNResponse ModifyDNResponse,
2472 compareRequest CompareRequest,
2473 compareResponse CompareResponse,
2474 abandonRequest AbandonRequest,
2475 extendedReq ExtendedRequest,
2476 extendedResp ExtendedResponse,
2478 controls [0] Controls OPTIONAL }
2480 MessageID ::= INTEGER (0 .. maxInt)
2482 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
2484 LDAPString ::= OCTET STRING -- UTF-8 encoded,
2485 -- [ISO10646] characters
2487 LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
2489 LDAPDN ::= LDAPString
2491 RelativeLDAPDN ::= LDAPString
2493 AttributeDescription ::= LDAPString
2495 Sermersheim Internet-Draft - Expires Jun 2004 Page 43
\f
2496 Lightweight Directory Access Protocol Version 3
2498 -- Constrained to <attributedescription>
2501 AttributeValue ::= OCTET STRING
2503 AttributeValueAssertion ::= SEQUENCE {
2504 attributeDesc AttributeDescription,
2505 assertionValue AssertionValue }
2507 AssertionValue ::= OCTET STRING
2509 PartialAttribute ::= SEQUENCE {
2510 type AttributeDescription,
2511 vals SET OF value AttributeValue }
2513 Attribute ::= PartialAttribute(WITH COMPONENTS {
2515 vals (SIZE(1..MAX))})
2517 MatchingRuleId ::= LDAPString
2519 LDAPResult ::= SEQUENCE {
2520 resultCode ENUMERATED {
2522 operationsError (1),
2524 timeLimitExceeded (3),
2525 sizeLimitExceeded (4),
2528 authMethodNotSupported (7),
2529 strongAuthRequired (8),
2532 adminLimitExceeded (11),
2533 unavailableCriticalExtension (12),
2534 confidentialityRequired (13),
2535 saslBindInProgress (14),
2536 noSuchAttribute (16),
2537 undefinedAttributeType (17),
2538 inappropriateMatching (18),
2539 constraintViolation (19),
2540 attributeOrValueExists (20),
2541 invalidAttributeSyntax (21),
2545 invalidDNSyntax (34),
2546 -- 35 reserved for undefined isLeaf --
2547 aliasDereferencingProblem (36),
2549 inappropriateAuthentication (48),
2550 invalidCredentials (49),
2551 insufficientAccessRights (50),
2553 Sermersheim Internet-Draft - Expires Jun 2004 Page 44
\f
2554 Lightweight Directory Access Protocol Version 3
2558 unwillingToPerform (53),
2561 namingViolation (64),
2562 objectClassViolation (65),
2563 notAllowedOnNonLeaf (66),
2564 notAllowedOnRDN (67),
2565 entryAlreadyExists (68),
2566 objectClassModsProhibited (69),
2567 -- 70 reserved for CLDAP --
2568 affectsMultipleDSAs (71),
2572 -- 81-90 reserved for APIs --
2574 diagnosticMessage LDAPString,
2575 referral [3] Referral OPTIONAL }
2577 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
2579 URI ::= LDAPString -- limited to characters permitted in
2582 Controls ::= SEQUENCE OF control Control
2584 Control ::= SEQUENCE {
2585 controlType LDAPOID,
2586 criticality BOOLEAN DEFAULT FALSE,
2587 controlValue OCTET STRING OPTIONAL }
2589 BindRequest ::= [APPLICATION 0] SEQUENCE {
2590 version INTEGER (1 .. 127),
2592 authentication AuthenticationChoice }
2594 AuthenticationChoice ::= CHOICE {
2595 simple [0] OCTET STRING,
2597 sasl [3] SaslCredentials,
2600 SaslCredentials ::= SEQUENCE {
2601 mechanism LDAPString,
2602 credentials OCTET STRING OPTIONAL }
2604 BindResponse ::= [APPLICATION 1] SEQUENCE {
2605 COMPONENTS OF LDAPResult,
2606 serverSaslCreds [7] OCTET STRING OPTIONAL }
2608 UnbindRequest ::= [APPLICATION 2] NULL
2611 Sermersheim Internet-Draft - Expires Jun 2004 Page 45
\f
2612 Lightweight Directory Access Protocol Version 3
2614 SearchRequest ::= [APPLICATION 3] SEQUENCE {
2620 derefAliases ENUMERATED {
2621 neverDerefAliases (0),
2622 derefInSearching (1),
2623 derefFindingBaseObj (2),
2625 sizeLimit INTEGER (0 .. maxInt),
2626 timeLimit INTEGER (0 .. maxInt),
2629 attributes AttributeSelection }
2631 AttributeSelection ::= SEQUENCE OF selection LDAPString
2634 and [0] SET SIZE (1..MAX) OF filter Filter,
2635 or [1] SET SIZE (1..MAX) OF filter Filter,
2637 equalityMatch [3] AttributeValueAssertion,
2638 substrings [4] SubstringFilter,
2639 greaterOrEqual [5] AttributeValueAssertion,
2640 lessOrEqual [6] AttributeValueAssertion,
2641 present [7] AttributeDescription,
2642 approxMatch [8] AttributeValueAssertion,
2643 extensibleMatch [9] MatchingRuleAssertion }
2645 SubstringFilter ::= SEQUENCE {
2646 type AttributeDescription,
2647 -- at least one must be present,
2648 -- initial and final can occur at most once
2649 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
2650 initial [0] AssertionValue,
2651 any [1] AssertionValue,
2652 final [2] AssertionValue } }
2654 MatchingRuleAssertion ::= SEQUENCE {
2655 matchingRule [1] MatchingRuleId OPTIONAL,
2656 type [2] AttributeDescription OPTIONAL,
2657 matchValue [3] AssertionValue,
2658 dnAttributes [4] BOOLEAN DEFAULT FALSE }
2660 SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
2662 attributes PartialAttributeList }
2664 PartialAttributeList ::= SEQUENCE OF
2665 partialAttribute PartialAttribute
2667 SearchResultReference ::= [APPLICATION 19] SEQUENCE
2669 Sermersheim Internet-Draft - Expires Jun 2004 Page 46
\f
2670 Lightweight Directory Access Protocol Version 3
2672 SIZE (1..MAX) OF uri URI
2674 SearchResultDone ::= [APPLICATION 5] LDAPResult
2676 ModifyRequest ::= [APPLICATION 6] SEQUENCE {
2678 changes SEQUENCE OF change SEQUENCE {
2679 operation ENUMERATED {
2683 modification PartialAttribute } }
2685 ModifyResponse ::= [APPLICATION 7] LDAPResult
2687 AddRequest ::= [APPLICATION 8] SEQUENCE {
2689 attributes AttributeList }
2691 AttributeList ::= SEQUENCE OF attribute Attribute
2693 AddResponse ::= [APPLICATION 9] LDAPResult
2695 DelRequest ::= [APPLICATION 10] LDAPDN
2697 DelResponse ::= [APPLICATION 11] LDAPResult
2699 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
2701 newrdn RelativeLDAPDN,
2702 deleteoldrdn BOOLEAN,
2703 newSuperior [0] LDAPDN OPTIONAL }
2705 ModifyDNResponse ::= [APPLICATION 13] LDAPResult
2707 CompareRequest ::= [APPLICATION 14] SEQUENCE {
2709 ava AttributeValueAssertion }
2711 CompareResponse ::= [APPLICATION 15] LDAPResult
2713 AbandonRequest ::= [APPLICATION 16] MessageID
2715 ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
2716 requestName [0] LDAPOID,
2717 requestValue [1] OCTET STRING OPTIONAL }
2719 ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
2720 COMPONENTS OF LDAPResult,
2721 responseName [10] LDAPOID OPTIONAL,
2722 responseValue [11] OCTET STRING OPTIONAL }
2727 Sermersheim Internet-Draft - Expires Jun 2004 Page 47
\f
2728 Lightweight Directory Access Protocol Version 3
2730 Appendix C - Changes
2732 This appendix is non-normative.
2734 This appendix summarizes substantive changes made to RFC 2251 and RFC
2738 C.1 Changes made to made to RFC 2251:
2740 This section summarizes the substantive changes made to Sections 1,
2741 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
2742 consult [Models] and [AuthMeth] for summaries of changes to other
2748 - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
2749 authentication mechanisms have been standardized which are
2750 sufficient to remove this note. See [AuthMeth] for authentication
2754 C.1.2 Section 3.1 and others
2756 - Removed notes giving history between LDAP v1, v2 and v3. Instead,
2757 added sufficient language so that this document can stand on its
2763 - Clarified where the extensibility features of ASN.1 apply to the
2764 protocol. This change also affected various ASN.1 types.
2765 - Removed the requirement that servers which implement version 3 or
2766 later MUST provide the supportedLDAPVersion attribute. This
2767 statement provided no interoperability advantages.
2772 - There was a mandatory requirement for the server to return a
2773 Notice of Disconnection and drop the connection when a PDU is
2774 malformed in a certain way. This has been clarified such that the
2775 server SHOULD return the Notice of Disconnection, and MUST drop
2779 C.1.5 Section 4.1.1.1
2781 - Clarified that the messageID of requests MUST be non-zero.
2785 Sermersheim Internet-Draft - Expires Jun 2004 Page 48
\f
2786 Lightweight Directory Access Protocol Version 3
2788 - Clarified when it is and isn't appropriate to return an already
2789 used message id. RFC 2251 accidentally imposed synchronous server
2790 behavior in its wording of this.
2795 - Stated that LDAPOID is constrained to <numericoid> from [Models].
2798 C.1.7 Section 4.1.5.1
2800 - Removed the Binary Option from the specification. There are
2801 numerous interoperability problems associated with this method of
2802 alternate attribute type encoding. Work to specify a suitable
2803 replacement is ongoing.
2808 - Removed references to the "binary" encoding as it has been removed
2809 from the specification.
2814 - Removed references to the "binary" encoding as it has been removed
2815 from the specification.
2818 C.1.10 Section 4.1.8
2820 - Combined the definitions of PartialAttribute and Attribute here,
2821 and defined Attribute in terms of PartialAttribute.
2824 C.1.11 Section 4.1.10
2826 - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
2827 be sent for non-error results.
2828 - Moved some language into Appendix A, and refer the reader there.
2829 - Allowed matchedDN to be present for other result codes than those
2833 C.1.12 Section 4.1.11
2835 - Defined referrals in terms of URIs rather than URLs.
2836 - Removed the requirement that all referral URIs MUST be equally
2837 capable of progressing the operation. The statement was ambiguous
2838 and provided no instructions on how to carry it out.
2839 - Added the requirement that clients MUST NOT loop between servers.
2840 - Clarified the instructions for using LDAPURLs in referrals, and in
2841 doing so added a recommendation that the scope part be present.
2843 Sermersheim Internet-Draft - Expires Jun 2004 Page 49
\f
2844 Lightweight Directory Access Protocol Version 3
2848 C.1.13 Section 4.1.12
2850 - Specified how control values defined in terms of ASN.1 are to be
2852 - Added language regarding combinations of controls on a message.
2853 - Changed "The server MUST be prepared" to "Implementations MUST be
2854 prepared" in the eighth paragraph to reflect that both client and
2855 server implementations must be able to handle this (as both parse
2861 - Mandated that servers return protocolError when the version is not
2863 - Clarified behavior when the simple authentication is used, the
2864 name is empty and the password is non-empty.
2865 - Required servers to not dereference aliases for bind. This was
2866 added for consistency with other operations and to help ensure
2868 - Required that textual passwords be transferred as UTF-8 encoded
2869 Unicode, and added recommendations on string preparation. This was
2870 to help ensure interoperability of passwords being sent from
2874 C.1.15 Section 4.2.1
2876 - This section was largely reorganized for readability and language
2877 was added to clarify the authentication state of failed and
2878 abandoned bind operations.
2879 - Removed: "If a SASL transfer encryption or integrity mechanism has
2880 been negotiated, that mechanism does not support the changing of
2881 credentials from one identity to another, then the client MUST
2882 instead establish a new connection."
2883 Each SASL negotiation is, generally, independent of other SASL
2884 negotiations. If there were dependencies between multiple
2885 negotiations of a particular mechanism, the mechanism technical
2886 specification should detail how applications are to deal with
2887 them. LDAP should not require any special handling. And if an LDAP
2888 client had used such a mechanism, it would have the option of
2889 using another mechanism.
2890 - Dropped MUST imperative in paragraph 3 to align with [Keywords].
2893 C.1.16 Section 4.2.3
2895 - Moved most error-related text to Appendix A, and added text
2896 regarding certain errors used in conjunction with the bind
2898 - Prohibited the server from specifying serverSaslCreds when not
2901 Sermersheim Internet-Draft - Expires Jun 2004 Page 50
\f
2902 Lightweight Directory Access Protocol Version 3
2908 - Required both peers to cease transmission and close the connection
2909 for the unbind operation.
2914 - Added instructions for future specifications of Unsolicited
2918 C.1.19 Section 4.5.1
2920 - SearchRequest attributes is now defined as an AttributeSelection
2921 type rather than AttributeDescriptionList.
2922 - The Filter choices 'and' and 'or', and the SubstringFilter
2923 substrings types are now defined with a lower bound of 1.
2924 - The SubstringFilter substrings 'initial, 'any', and 'final' types
2925 are now AssertionValue rather than LDAPString.
2926 - Clarified the semantics of the derefAliases choices.
2927 - Added instructions for equalityMatch, substrings, greaterOrEqual,
2928 lessOrEqual, and approxMatch.
2931 C.1.20 Section 4.5.2
2933 - Recommended that servers not use attribute short names when it
2934 knows they are ambiguous or may cause interoperability problems.
2935 - Removed all mention of ExtendedResponse due to lack of
2939 C.1.21 Section 4.5.3
2941 - Made changes similar to those made to Section 4.1.11.
2944 C.1.22 Section 4.5.3.1
2946 - Fixed examples to adhere to changes made to Section 4.5.3.
2951 - Removed restriction that required an equality match filter in
2952 order to perform value delete modifications. It is sufficiently
2953 documented that in absence of an equality matching rule, octet
2955 - Replaced AttributeTypeAndValues with Attribute as they are
2959 Sermersheim Internet-Draft - Expires Jun 2004 Page 51
\f
2960 Lightweight Directory Access Protocol Version 3
2962 - Clarified what type of modification changes might temporarily
2968 - Required servers to not dereference aliases for modify DN. This
2969 was added for consistency with other operations and to help ensure
2971 - Allow modify DN to fail when moving between naming contexts.
2976 - Clarified the semantics of Compare when the attribute is not
2977 present and when it is unknown.
2978 - Required servers to not dereference aliases for compare. This was
2979 added for consistency with other operations and to help ensure
2985 - Explained that since abandon returns no response, clients hould
2986 not use it if they need to know the outcome.
2987 - Specified that Abandon and Unbind cannot be abandoned.
2992 - Specified how values of extended operations defined in terms of
2993 ASN.1 are to be encoded.
2994 - Added instructions on what extended operation specifications
2996 - Added a recommendation that servers advertise supported extended
3002 - Moved referral-specific instructions into referral-related
3008 - Reworded notes regarding SASL not protecting certain aspects of
3010 - Noted that Servers are encouraged to prevent directory
3011 modifications by clients that have authenticated anonymously
3013 - Added a note regarding the scenario where an identity is changed
3014 (deleted, privileges or credentials modified, etc.).
3017 Sermersheim Internet-Draft - Expires Jun 2004 Page 52
\f
3018 Lightweight Directory Access Protocol Version 3
3020 - Warned against following referrals that may have been injected in
3022 - Added a note regarding malformed and long encodings.
3027 - Added "EXTESIBILITY IMPLIED" to ASN.1 definition.
3028 - Removed AttributeType. It is not used.
3031 C.2 Changes made to made to RFC 2830:
3033 This section summarizes the substantive changes made to Sections of
3034 RFC 2830. Readers should consult [AuthMeth] for summaries of changes
3040 - Removed wording indicating that referrals can be returned from
3044 C.2.1 Section 4.13.3.1
3046 - Reworded most of this section and added the requirement that after
3047 the TLS connection has been closed, the server MUST NOT send
3048 responses to any request message received before the TLS closure.
3075 Sermersheim Internet-Draft - Expires Jun 2004 Page 53
\f
3076 Lightweight Directory Access Protocol Version 3
3078 Intellectual Property Rights
3080 The IETF takes no position regarding the validity or scope of any
3081 intellectual property or other rights that might be claimed to
3082 pertain to the implementation or use of the technology described in
3083 this document or the extent to which any license under such rights
3084 might or might not be available; neither does it represent that it
3085 has made any effort to identify any such rights. Information on the
3086 IETF's procedures with respect to rights in standards-track and
3087 standards-related documentation can be found in BCP-11. Copies of
3088 claims of rights made available for publication and any assurances of
3089 licenses to be made available, or the result of an attempt made to
3090 obtain a general license or permission for the use of such
3091 proprietary rights by implementors or users of this specification can
3092 be obtained from the IETF Secretariat.
3094 The IETF invites any interested party to bring to its attention any
3095 copyrights, patents or patent applications, or other proprietary
3096 rights which may cover technology that may be required to practice
3097 this standard. Please address the information to the IETF Executive
3101 Full Copyright Statement
3103 Copyright (C) The Internet Society (2003). All Rights Reserved.
3105 This document and translations of it may be copied and furnished to
3106 others, and derivative works that comment on or otherwise explain it
3107 or assist in its implementation may be prepared, copied, published
3108 and distributed, in whole or in part, without restriction of any
3109 kind, provided that the above copyright notice and this paragraph are
3110 included on all such copies and derivative works. However, this
3111 document itself may not be modified in any way, such as by removing
3112 the copyright notice or references to the Internet Society or other
3113 Internet organizations, except as needed for the purpose of
3114 developing Internet standards in which case the procedures for
3115 copyrights defined in the Internet Standards process must be
3116 followed, or as required to translate it into languages other than
3119 The limited permissions granted above are perpetual and will not be
3120 revoked by the Internet Society or its successors or assigns.
3122 This document and the information contained herein is provided on an
3123 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3124 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3125 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3126 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3127 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3133 Sermersheim Internet-Draft - Expires Jun 2004 Page 54
\f
projects / openldap / blob