From 3faab3e6dd2c804ae81a910275339f6ce8237e77 Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Sat, 22 Jul 2006 19:26:52 +0000 Subject: r17189: Add the new LDAP rfc series (This used to be commit d3f8b813b33d1338e62f099017a1d4a32745e7a2) --- source4/ldap_server/devdocs/rfc4510.txt | 395 ++++ source4/ldap_server/devdocs/rfc4511.txt | 3811 +++++++++++++++++++++++++++++++ source4/ldap_server/devdocs/rfc4512.txt | 2915 +++++++++++++++++++++++ source4/ldap_server/devdocs/rfc4513.txt | 1907 ++++++++++++++++ source4/ldap_server/devdocs/rfc4514.txt | 843 +++++++ source4/ldap_server/devdocs/rfc4515.txt | 675 ++++++ source4/ldap_server/devdocs/rfc4516.txt | 843 +++++++ source4/ldap_server/devdocs/rfc4517.txt | 2971 ++++++++++++++++++++++++ source4/ldap_server/devdocs/rfc4518.txt | 787 +++++++ source4/ldap_server/devdocs/rfc4519.txt | 1963 ++++++++++++++++ source4/ldap_server/devdocs/rfc4520.txt | 1067 +++++++++ source4/ldap_server/devdocs/rfc4521.txt | 899 ++++++++ source4/ldap_server/devdocs/rfc4522.txt | 451 ++++ source4/ldap_server/devdocs/rfc4523.txt | 1347 +++++++++++ source4/ldap_server/devdocs/rfc4524.txt | 1403 ++++++++++++ source4/ldap_server/devdocs/rfc4525.txt | 339 +++ source4/ldap_server/devdocs/rfc4526.txt | 283 +++ source4/ldap_server/devdocs/rfc4527.txt | 451 ++++ source4/ldap_server/devdocs/rfc4528.txt | 339 +++ source4/ldap_server/devdocs/rfc4529.txt | 339 +++ source4/ldap_server/devdocs/rfc4530.txt | 451 ++++ source4/ldap_server/devdocs/rfc4531.txt | 507 ++++ source4/ldap_server/devdocs/rfc4532.txt | 395 ++++ source4/ldap_server/devdocs/rfc4533.txt | 1795 +++++++++++++++ 24 files changed, 27176 insertions(+) create mode 100644 source4/ldap_server/devdocs/rfc4510.txt create mode 100644 source4/ldap_server/devdocs/rfc4511.txt create mode 100644 source4/ldap_server/devdocs/rfc4512.txt create mode 100644 source4/ldap_server/devdocs/rfc4513.txt create mode 100644 source4/ldap_server/devdocs/rfc4514.txt create mode 100644 source4/ldap_server/devdocs/rfc4515.txt create mode 100644 source4/ldap_server/devdocs/rfc4516.txt create mode 100644 source4/ldap_server/devdocs/rfc4517.txt create mode 100644 source4/ldap_server/devdocs/rfc4518.txt create mode 100644 source4/ldap_server/devdocs/rfc4519.txt create mode 100644 source4/ldap_server/devdocs/rfc4520.txt create mode 100644 source4/ldap_server/devdocs/rfc4521.txt create mode 100644 source4/ldap_server/devdocs/rfc4522.txt create mode 100644 source4/ldap_server/devdocs/rfc4523.txt create mode 100644 source4/ldap_server/devdocs/rfc4524.txt create mode 100644 source4/ldap_server/devdocs/rfc4525.txt create mode 100644 source4/ldap_server/devdocs/rfc4526.txt create mode 100644 source4/ldap_server/devdocs/rfc4527.txt create mode 100644 source4/ldap_server/devdocs/rfc4528.txt create mode 100644 source4/ldap_server/devdocs/rfc4529.txt create mode 100644 source4/ldap_server/devdocs/rfc4530.txt create mode 100644 source4/ldap_server/devdocs/rfc4531.txt create mode 100644 source4/ldap_server/devdocs/rfc4532.txt create mode 100644 source4/ldap_server/devdocs/rfc4533.txt (limited to 'source4/ldap_server') diff --git a/source4/ldap_server/devdocs/rfc4510.txt b/source4/ldap_server/devdocs/rfc4510.txt new file mode 100644 index 0000000000..8ba41d1d93 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4510.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. Zeilenga, Ed. +Request for Comments: 4510 OpenLDAP Foundation +Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006 + 2256, 2829, 2830, 3377, 3771 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Technical Specification Road Map + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an Internet + protocol for accessing distributed directory services that act in + accordance with X.500 data and service models. This document + provides a road map of the LDAP Technical Specification. + +1. The LDAP Technical Specification + + The technical specification detailing version 3 of the Lightweight + Directory Access Protocol (LDAP), an Internet Protocol, consists of + this document and the following documents: + + LDAP: The Protocol [RFC4511] + LDAP: Directory Information Models [RFC4512] + LDAP: Authentication Methods and Security Mechanisms [RFC4513] + LDAP: String Representation of Distinguished Names [RFC4514] + LDAP: String Representation of Search Filters [RFC4515] + LDAP: Uniform Resource Locator [RFC4516] + LDAP: Syntaxes and Matching Rules [RFC4517] + LDAP: Internationalized String Preparation [RFC4518] + LDAP: Schema for User Applications [RFC4519] + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4510 LDAP: TS Road Map June 2006 + + + The terms "LDAP" and "LDAPv3" are commonly used to refer informally + to the protocol specified by this technical specification. The LDAP + suite, as defined here, should be formally identified in other + documents by a normative reference to this document. + + LDAP is an extensible protocol. Extensions to LDAP may be specified + in other documents. Nomenclature denoting such combinations of + LDAP-plus-extensions is not defined by this document but may be + defined in some future document(s). Extensions are expected to be + truly optional. Considerations for the LDAP extensions described in + BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP + Technical Specification. + + IANA (Internet Assigned Numbers Authority) considerations for LDAP + described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision + of the LDAP technical specification. + +1.1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. Relationship to X.500 + + This technical specification defines LDAP in terms of [X.500] as an + X.500 access mechanism. An LDAP server MUST act in accordance with + the X.500 (1993) series of International Telecommunication Union - + Telecommunication Standardization (ITU-T) Recommendations when + providing the service. However, it is not required that an LDAP + server make use of any X.500 protocols in providing this service. + For example, LDAP can be mapped onto any other directory system so + long as the X.500 data and service models [X.501][X.511], as used in + LDAP, are not violated in the LDAP interface. + + This technical specification explicitly incorporates portions of + X.500(93). Later revisions of X.500 do not automatically apply to + this technical specification. + +3. Relationship to Obsolete Specifications + + This technical specification, as defined in Section 1, obsoletes + entirely the previously defined LDAP technical specification defined + in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and + 3377 itself). The technical specification was significantly + reorganized. + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4510 LDAP: TS Road Map June 2006 + + + This document replaces RFC 3377 as well as Section 3.3 of RFC 2251. + [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256. + [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and + all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions + of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and + portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256. + [RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516] + replaces RFC 2255. + + [RFC4518] is new to this revision of the LDAP technical + specification. + + Each document of this specification contains appendices summarizing + changes to all sections of the specifications they replace. Appendix + A.1 of this document details changes made to RFC 3377. Appendix A.2 + of this document details changes made to Section 3.3 of RFC 2251. + + Additionally, portions of this technical specification update and/or + replace a number of other documents not listed above. These + relationships are discussed in the documents detailing these portions + of this technical specification. + +4. Security Considerations + + LDAP security considerations are discussed in each document + comprising the technical specification. + +5. Acknowledgements + + This document is based largely on RFC 3377 by J. Hodges and R. + Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The + document also borrows from RFC 2251 by M. Wahl, T. Howes, and S. + Kille, a product of the ASID Working Group. + + This document is a product of the IETF LDAPBIS Working Group. + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4510 LDAP: TS Road Map June 2006 + + +6. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): String Representation of Search + Filters", RFC 4515, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Internationalized String Preparation", RFC + 4518, June 2006. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP + 118, RFC 4521, June 2006. + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4510 LDAP: TS Road Map June 2006 + + + [X.500] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Overview of concepts, models and + services", X.500(1993) (also ISO/IEC 9594-1:1994). + + [X.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models", X.501(1993) (also ISO/IEC 9594- + 2:1994). + + [X.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993) + (also ISO/IEC 9594-3:1993). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4510 LDAP: TS Road Map June 2006 + + +Appendix A. Changes to Previous Documents + + This appendix outlines changes this document makes relative to the + documents it replaces (in whole or in part). + +A.1. Changes to RFC 3377 + + This document is nearly a complete rewrite of RFC 3377 as much of the + material of RFC 3377 is no longer applicable. The changes include + redefining the terms "LDAP" and "LDAPv3" to refer to this revision of + the technical specification. + +A.2. Changes to Section 3.3 of RFC 2251 + + The section was modified slightly (the word "document" was replaced + with "technical specification") to clarify that it applies to the + entire LDAP technical specification. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4510 LDAP: TS Road Map June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 7] + diff --git a/source4/ldap_server/devdocs/rfc4511.txt b/source4/ldap_server/devdocs/rfc4511.txt new file mode 100644 index 0000000000..8041f30544 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4511.txt @@ -0,0 +1,3811 @@ + + + + + + +Network Working Group J. Sermersheim, Ed. +Request for Comments: 4511 Novell, Inc. +Obsoletes: 2251, 2830, 3771 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): The Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes the protocol elements, along with their + semantics and encodings, of the Lightweight Directory Access Protocol + (LDAP). LDAP provides access to distributed directory services that + act in accordance with X.500 data and service models. These protocol + elements are based on those described in the X.500 Directory Access + Protocol (DAP). + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other LDAP Specifications ..................3 + 2. Conventions .....................................................3 + 3. Protocol Model ..................................................4 + 3.1. Operation and LDAP Message Layer Relationship ..............5 + 4. Elements of Protocol ............................................5 + 4.1. Common Elements ............................................5 + 4.1.1. Message Envelope ....................................6 + 4.1.2. String Types ........................................7 + 4.1.3. Distinguished Name and Relative Distinguished Name ..8 + 4.1.4. Attribute Descriptions ..............................8 + 4.1.5. Attribute Value .....................................8 + 4.1.6. Attribute Value Assertion ...........................9 + 4.1.7. Attribute and PartialAttribute ......................9 + 4.1.8. Matching Rule Identifier ...........................10 + 4.1.9. Result Message .....................................10 + 4.1.10. Referral ..........................................12 + + + +Sermersheim Standards Track [Page 1] + +RFC 4511 LDAPv3 June 2006 + + + 4.1.11. Controls ..........................................14 + 4.2. Bind Operation ............................................16 + 4.2.1. Processing of the Bind Request .....................17 + 4.2.2. Bind Response ......................................18 + 4.3. Unbind Operation ..........................................18 + 4.4. Unsolicited Notification ..................................19 + 4.4.1. Notice of Disconnection ............................19 + 4.5. Search Operation ..........................................20 + 4.5.1. Search Request .....................................20 + 4.5.2. Search Result ......................................27 + 4.5.3. Continuation References in the Search Result .......28 + 4.6. Modify Operation ..........................................31 + 4.7. Add Operation .............................................33 + 4.8. Delete Operation ..........................................34 + 4.9. Modify DN Operation .......................................34 + 4.10. Compare Operation ........................................36 + 4.11. Abandon Operation ........................................36 + 4.12. Extended Operation .......................................37 + 4.13. IntermediateResponse Message .............................39 + 4.13.1. Usage with LDAP ExtendedRequest and + ExtendedResponse ..................................40 + 4.13.2. Usage with LDAP Request Controls ..................40 + 4.14. StartTLS Operation .......................................40 + 4.14.1. StartTLS Request ..................................40 + 4.14.2. StartTLS Response .................................41 + 4.14.3. Removal of the TLS Layer ..........................41 + 5. Protocol Encoding, Connection, and Transfer ....................42 + 5.1. Protocol Encoding .........................................42 + 5.2. Transmission Control Protocol (TCP) .......................43 + 5.3. Termination of the LDAP session ...........................43 + 6. Security Considerations ........................................43 + 7. Acknowledgements ...............................................45 + 8. Normative References ...........................................46 + 9. Informative References .........................................48 + 10. IANA Considerations ...........................................48 + Appendix A. LDAP Result Codes .....................................49 + A.1. Non-Error Result Codes ....................................49 + A.2. Result Codes ..............................................49 + Appendix B. Complete ASN.1 Definition .............................54 + Appendix C. Changes ...............................................60 + C.1. Changes Made to RFC 2251 ..................................60 + C.2. Changes Made to RFC 2830 ..................................66 + C.3. Changes Made to RFC 3771 ..................................66 + + + + + + + + +Sermersheim Standards Track [Page 2] + +RFC 4511 LDAPv3 June 2006 + + +1. Introduction + + The Directory is "a collection of open systems cooperating to provide + directory services" [X.500]. A directory user, which may be a human + or other entity, accesses the Directory through a client (or + Directory User Agent (DUA)). The client, on behalf of the directory + user, interacts with one or more servers (or Directory System Agents + (DSA)). Clients interact with servers using a directory access + protocol. + + This document details the protocol elements of the Lightweight + Directory Access Protocol (LDAP), along with their semantics. + Following the description of protocol elements, it describes the way + in which the protocol elements are encoded and transferred. + +1.1. Relationship to Other LDAP Specifications + + This document is an integral part of the LDAP Technical Specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document, together with [RFC4510], [RFC4513], and [RFC4512], + obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by + [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by + [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, + 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) + are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted + by this document. Appendix C.1 summarizes substantive changes in the + remainder. + + This document obsoletes RFC 2830, Sections 2 and 4. The remainder of + RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes + substantive changes to the remaining sections. + + This document also obsoletes RFC 3771 in entirety. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are + to be interpreted as described in [RFC2119]. + + Character names in this document use the notation for code points and + names from the Unicode Standard [Unicode]. For example, the letter + "a" may be represented as either or . + + + + + + +Sermersheim Standards Track [Page 3] + +RFC 4511 LDAPv3 June 2006 + + + Note: a glossary of terms used in Unicode can be found in [Glossary]. + Information on the Unicode character encoding model can be found in + [CharModel]. + + The term "transport connection" refers to the underlying transport + services used to carry the protocol exchange, as well as associations + established by these services. + + The term "TLS layer" refers to Transport Layer Security (TLS) + services used in providing security services, as well as associations + established by these services. + + The term "SASL layer" refers to Simply Authentication and Security + Layer (SASL) services used in providing security services, as well as + associations established by these services. + + The term "LDAP message layer" refers to the LDAP Message Protocol + Data Unit (PDU) services used in providing directory services, as + well as associations established by these services. + + The term "LDAP session" refers to combined services (transport + connection, TLS layer, SASL layer, LDAP message layer) and their + associations. + + See the table in Section 5 for an illustration of these four terms. + +3. Protocol Model + + The general model adopted by this protocol is one of clients + performing protocol operations against servers. In this model, a + client transmits a protocol request describing the operation to be + performed to a server. The server is then responsible for performing + the necessary operation(s) in the Directory. Upon completion of an + operation, the server typically returns a response containing + appropriate data to the requesting client. + + Protocol operations are generally independent of one another. Each + operation is processed as an atomic action, leaving the directory in + a consistent state. + + Although servers are required to return responses whenever such + responses are defined in the protocol, there is no requirement for + synchronous behavior on the part of either clients or servers. + Requests and responses for multiple operations generally may be + exchanged between a client and server in any order. If required, + synchronous behavior may be controlled by client applications. + + + + + +Sermersheim Standards Track [Page 4] + +RFC 4511 LDAPv3 June 2006 + + + The core protocol operations defined in this document can be mapped + to a subset of the X.500 (1993) Directory Abstract Service [X.511]. + However, there is not a one-to-one mapping between LDAP operations + and X.500 Directory Access Protocol (DAP) operations. Server + implementations acting as a gateway to X.500 directories may need to + make multiple DAP requests to service a single LDAP request. + +3.1. Operation and LDAP Message Layer Relationship + + Protocol operations are exchanged at the LDAP message layer. When + the transport connection is closed, any uncompleted operations at the + LDAP message layer are abandoned (when possible) or are completed + without transmission of the response (when abandoning them is not + possible). Also, when the transport connection is closed, the client + MUST NOT assume that any uncompleted update operations have succeeded + or failed. + +4. Elements of Protocol + + The protocol is described using Abstract Syntax Notation One + ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding + Rules ([BER]). Section 5 specifies how the protocol elements are + encoded and transferred. + + In order to support future extensions to this protocol, extensibility + is implied where it is allowed per ASN.1 (i.e., sequence, set, + choice, and enumerated types are extensible). In addition, ellipses + (...) have been supplied in ASN.1 types that are explicitly + extensible as discussed in [RFC4520]. Because of the implied + extensibility, clients and servers MUST (unless otherwise specified) + ignore trailing SEQUENCE components whose tags they do not recognize. + + Changes to the protocol other than through the extension mechanisms + described here require a different version number. A client + indicates the version it is using as part of the BindRequest, + described in Section 4.2. If a client has not sent a Bind, the + server MUST assume the client is using version 3 or later. + + Clients may attempt to determine the protocol versions a server + supports by reading the 'supportedLDAPVersion' attribute from the + root DSE (DSA-Specific Entry) [RFC4512]. + +4.1. Common Elements + + This section describes the LDAPMessage envelope Protocol Data Unit + (PDU) format, as well as data type definitions, which are used in the + protocol operations. + + + + +Sermersheim Standards Track [Page 5] + +RFC 4511 LDAPv3 June 2006 + + +4.1.1. Message Envelope + + For the purposes of protocol exchanges, all protocol operations are + encapsulated in a common envelope, the LDAPMessage, which is defined + as follows: + + LDAPMessage ::= SEQUENCE { + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse, + ..., + intermediateResponse IntermediateResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + The ASN.1 type Controls is defined in Section 4.1.11. + + The function of the LDAPMessage is to provide an envelope containing + common fields required in all protocol exchanges. At this time, the + only common fields are the messageID and the controls. + + If the server receives an LDAPMessage from the client in which the + LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot + be parsed, the tag of the protocolOp is not recognized as a request, + or the encoding structures or lengths of data fields are found to be + incorrect, then the server SHOULD return the Notice of Disconnection + + + +Sermersheim Standards Track [Page 6] + +RFC 4511 LDAPv3 June 2006 + + + described in Section 4.4.1, with the resultCode set to protocolError, + and MUST immediately terminate the LDAP session as described in + Section 5.3. + + In other cases where the client or server cannot parse an LDAP PDU, + it SHOULD abruptly terminate the LDAP session (Section 5.3) where + further communication (including providing notice) would be + pernicious. Otherwise, server implementations MUST return an + appropriate response to the request, with the resultCode set to + protocolError. + +4.1.1.1. MessageID + + All LDAPMessage envelopes encapsulating responses contain the + messageID value of the corresponding request LDAPMessage. + + The messageID of a request MUST have a non-zero value different from + the messageID of any other request in progress in the same LDAP + session. The zero value is reserved for the unsolicited notification + message. + + Typical clients increment a counter for each request. + + A client MUST NOT send a request with the same messageID as an + earlier request in the same LDAP session unless it can be determined + that the server is no longer servicing the earlier request (e.g., + after the final response is received, or a subsequent Bind + completes). Otherwise, the behavior is undefined. For this purpose, + note that Abandon and successfully abandoned operations do not send + responses. + +4.1.2. String Types + + The LDAPString is a notational convenience to indicate that, although + strings of LDAPString type encode as ASN.1 OCTET STRING types, the + [ISO10646] character set (a superset of [Unicode]) is used, encoded + following the UTF-8 [RFC3629] algorithm. Note that Unicode + characters U+0000 through U+007F are the same as ASCII 0 through 127, + respectively, and have the same single octet UTF-8 encoding. Other + Unicode characters have a multiple octet UTF-8 encoding. + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- [ISO10646] characters + + The LDAPOID is a notational convenience to indicate that the + permitted value of this string is a (UTF-8 encoded) dotted-decimal + representation of an OBJECT IDENTIFIER. Although an LDAPOID is + + + + +Sermersheim Standards Track [Page 7] + +RFC 4511 LDAPv3 June 2006 + + + encoded as an OCTET STRING, values are limited to the definition of + given in Section 1.4 of [RFC4512]. + + LDAPOID ::= OCTET STRING -- Constrained to + -- [RFC4512] + + For example, + + 1.3.6.1.4.1.1466.1.2.3 + +4.1.3. Distinguished Name and Relative Distinguished Name + + An LDAPDN is defined to be the representation of a Distinguished Name + (DN) after encoding according to the specification in [RFC4514]. + + LDAPDN ::= LDAPString + -- Constrained to [RFC4514] + + A RelativeLDAPDN is defined to be the representation of a Relative + Distinguished Name (RDN) after encoding according to the + specification in [RFC4514]. + + RelativeLDAPDN ::= LDAPString + -- Constrained to [RFC4514] + +4.1.4. Attribute Descriptions + + The definition and encoding rules for attribute descriptions are + defined in Section 2.5 of [RFC4512]. Briefly, an attribute + description is an attribute type and zero or more options. + + AttributeDescription ::= LDAPString + -- Constrained to + -- [RFC4512] + +4.1.5. Attribute Value + + A field of type AttributeValue is an OCTET STRING containing an + encoded attribute value. The attribute value is encoded according to + the LDAP-specific encoding definition of its corresponding syntax. + The LDAP-specific encoding definitions for different syntaxes and + attribute types may be found in other documents and in particular + [RFC4517]. + + AttributeValue ::= OCTET STRING + + + + + + +Sermersheim Standards Track [Page 8] + +RFC 4511 LDAPv3 June 2006 + + + Note that there is no defined limit on the size of this encoding; + thus, protocol values may include multi-megabyte attribute values + (e.g., photographs). + + Attribute values may be defined that have arbitrary and non-printable + syntax. Implementations MUST NOT display or attempt to decode an + attribute value if its syntax is not known. The implementation may + attempt to discover the subschema of the source entry and to retrieve + the descriptions of 'attributeTypes' from it [RFC4512]. + + Clients MUST only send attribute values in a request that are valid + according to the syntax defined for the attributes. + +4.1.6. Attribute Value Assertion + + The AttributeValueAssertion (AVA) type definition is similar to the + one in the X.500 Directory standards. It contains an attribute + description and a matching rule ([RFC4512], Section 4.1.3) assertion + value suitable for that type. Elements of this type are typically + used to assert that the value in assertionValue matches a value of an + attribute. + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + AssertionValue ::= OCTET STRING + + The syntax of the AssertionValue depends on the context of the LDAP + operation being performed. For example, the syntax of the EQUALITY + matching rule for an attribute is used when performing a Compare + operation. Often this is the same syntax used for values of the + attribute type, but in some cases the assertion syntax differs from + the value syntax. See objectIdentiferFirstComponentMatch in + [RFC4517] for an example. + +4.1.7. Attribute and PartialAttribute + + Attributes and partial attributes consist of an attribute description + and attribute values. A PartialAttribute allows zero values, while + Attribute requires at least one value. + + PartialAttribute ::= SEQUENCE { + type AttributeDescription, + vals SET OF value AttributeValue } + + + + + + +Sermersheim Standards Track [Page 9] + +RFC 4511 LDAPv3 June 2006 + + + Attribute ::= PartialAttribute(WITH COMPONENTS { + ..., + vals (SIZE(1..MAX))}) + + No two of the attribute values may be equivalent as described by + Section 2.2 of [RFC4512]. The set of attribute values is unordered. + Implementations MUST NOT rely upon the ordering being repeatable. + +4.1.8. Matching Rule Identifier + + Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching + rule is identified in the protocol by the printable representation of + either its or one of its short name descriptors + [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'. + + MatchingRuleId ::= LDAPString + +4.1.9. Result Message + + The LDAPResult is the construct used in this protocol to return + success or failure indications from servers to clients. To various + requests, servers will return responses containing the elements found + in LDAPResult to indicate the final status of the protocol operation + request. + + LDAPResult ::= SEQUENCE { + resultCode ENUMERATED { + success (0), + operationsError (1), + protocolError (2), + timeLimitExceeded (3), + sizeLimitExceeded (4), + compareFalse (5), + compareTrue (6), + authMethodNotSupported (7), + strongerAuthRequired (8), + -- 9 reserved -- + referral (10), + adminLimitExceeded (11), + unavailableCriticalExtension (12), + confidentialityRequired (13), + saslBindInProgress (14), + noSuchAttribute (16), + undefinedAttributeType (17), + inappropriateMatching (18), + constraintViolation (19), + attributeOrValueExists (20), + invalidAttributeSyntax (21), + + + +Sermersheim Standards Track [Page 10] + +RFC 4511 LDAPv3 June 2006 + + + -- 22-31 unused -- + noSuchObject (32), + aliasProblem (33), + invalidDNSyntax (34), + -- 35 reserved for undefined isLeaf -- + aliasDereferencingProblem (36), + -- 37-47 unused -- + inappropriateAuthentication (48), + invalidCredentials (49), + insufficientAccessRights (50), + busy (51), + unavailable (52), + unwillingToPerform (53), + loopDetect (54), + -- 55-63 unused -- + namingViolation (64), + objectClassViolation (65), + notAllowedOnNonLeaf (66), + notAllowedOnRDN (67), + entryAlreadyExists (68), + objectClassModsProhibited (69), + -- 70 reserved for CLDAP -- + affectsMultipleDSAs (71), + -- 72-79 unused -- + other (80), + ... }, + matchedDN LDAPDN, + diagnosticMessage LDAPString, + referral [3] Referral OPTIONAL } + + The resultCode enumeration is extensible as defined in Section 3.8 of + [RFC4520]. The meanings of the listed result codes are given in + Appendix A. If a server detects multiple errors for an operation, + only one result code is returned. The server should return the + result code that best indicates the nature of the error encountered. + Servers may return substituted result codes to prevent unauthorized + disclosures. + + The diagnosticMessage field of this construct may, at the server's + option, be used to return a string containing a textual, human- + readable diagnostic message (terminal control and page formatting + characters should be avoided). As this diagnostic message is not + standardized, implementations MUST NOT rely on the values returned. + Diagnostic messages typically supplement the resultCode with + additional information. If the server chooses not to return a + textual diagnostic, the diagnosticMessage field MUST be empty. + + + + + +Sermersheim Standards Track [Page 11] + +RFC 4511 LDAPv3 June 2006 + + + For certain result codes (typically, but not restricted to + noSuchObject, aliasProblem, invalidDNSyntax, and + aliasDereferencingProblem), the matchedDN field is set (subject to + access controls) to the name of the last entry (object or alias) used + in finding the target (or base) object. This will be a truncated + form of the provided name or, if an alias was dereferenced while + attempting to locate the entry, of the resulting name. Otherwise, + the matchedDN field is empty. + +4.1.10. Referral + + The referral result code indicates that the contacted server cannot + or will not perform the operation and that one or more other servers + may be able to. Reasons for this include: + + - The target entry of the request is not held locally, but the server + has knowledge of its possible existence elsewhere. + + - The operation is restricted on this server -- perhaps due to a + read-only copy of an entry to be modified. + + The referral field is present in an LDAPResult if the resultCode is + set to referral, and it is absent with all other result codes. It + contains one or more references to one or more servers or services + that may be accessed via LDAP or other protocols. Referrals can be + returned in response to any operation request (except Unbind and + Abandon, which do not have responses). At least one URI MUST be + present in the Referral. + + During a Search operation, after the baseObject is located, and + entries are being evaluated, the referral is not returned. Instead, + continuation references, described in Section 4.5.3, are returned + when other servers would need to be contacted to complete the + operation. + + Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI + + URI ::= LDAPString -- limited to characters permitted in + -- URIs + + If the client wishes to progress the operation, it contacts one of + the supported services found in the referral. If multiple URIs are + present, the client assumes that any supported URI may be used to + progress the operation. + + Clients that follow referrals MUST ensure that they do not loop + between servers. They MUST NOT repeatedly contact the same server + for the same request with the same parameters. Some clients use a + + + +Sermersheim Standards Track [Page 12] + +RFC 4511 LDAPv3 June 2006 + + + counter that is incremented each time referral handling occurs for an + operation, and these kinds of clients MUST be able to handle at least + ten nested referrals while progressing the operation. + + A URI for a server implementing LDAP and accessible via TCP/IP (v4 or + v6) [RFC793][RFC791] is written as an LDAP URL according to + [RFC4516]. + + Referral values that are LDAP URLs follow these rules: + + - If an alias was dereferenced, the part of the LDAP URL MUST be + present, with the new target object name. + + - It is RECOMMENDED that the part be present to avoid ambiguity. + + - If the part is present, the client uses this name in its next + request to progress the operation, and if it is not present the + client uses the same name as in the original request. + + - Some servers (e.g., participating in distributed indexing) may + provide a different filter in a URL of a referral for a Search + operation. + + - If the part of the LDAP URL is present, the client uses + this filter in its next request to progress this Search, and if it + is not present the client uses the same filter as it used for that + Search. + + - For Search, it is RECOMMENDED that the part be present to + avoid ambiguity. + + - If the part is missing, the scope of the original Search is + used by the client to progress the operation. + + - Other aspects of the new request may be the same as or different + from the request that generated the referral. + + Other kinds of URIs may be returned. The syntax and semantics of + such URIs is left to future specifications. Clients may ignore URIs + that they do not support. + + UTF-8 encoded characters appearing in the string representation of a + DN, search filter, or other fields of the referral value may not be + legal for URIs (e.g., spaces) and MUST be escaped using the % method + in [RFC3986]. + + + + + + +Sermersheim Standards Track [Page 13] + +RFC 4511 LDAPv3 June 2006 + + +4.1.11. Controls + + Controls provide a mechanism whereby the semantics and arguments of + existing LDAP operations may be extended. One or more controls may + be attached to a single LDAP message. A control only affects the + semantics of the message it is attached to. + + Controls sent by clients are termed 'request controls', and those + sent by servers are termed 'response controls'. + + Controls ::= SEQUENCE OF control Control + + Control ::= SEQUENCE { + controlType LDAPOID, + criticality BOOLEAN DEFAULT FALSE, + controlValue OCTET STRING OPTIONAL } + + The controlType field is the dotted-decimal representation of an + OBJECT IDENTIFIER that uniquely identifies the control. This + provides unambiguous naming of controls. Often, response control(s) + solicited by a request control share controlType values with the + request control. + + The criticality field only has meaning in controls attached to + request messages (except UnbindRequest). For controls attached to + response messages and the UnbindRequest, the criticality field SHOULD + be FALSE, and MUST be ignored by the receiving protocol peer. A + value of TRUE indicates that it is unacceptable to perform the + operation without applying the semantics of the control. + Specifically, the criticality field is applied as follows: + + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and if the criticality + field is TRUE, the server MUST NOT perform the operation, and for + operations that have a response message, it MUST return with the + resultCode set to unavailableCriticalExtension. + + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and if the criticality + field is FALSE, the server MUST ignore the control. + + - Regardless of criticality, if a control is applied to an + operation, it is applied consistently and impartially to the + entire operation. + + + + + +Sermersheim Standards Track [Page 14] + +RFC 4511 LDAPv3 June 2006 + + + The controlValue may contain information associated with the + controlType. Its format is defined by the specification of the + control. Implementations MUST be prepared to handle arbitrary + contents of the controlValue octet string, including zero bytes. It + is absent only if there is no value information that is associated + with a control of its type. When a controlValue is defined in terms + of ASN.1, and BER-encoded according to Section 5.1, it also follows + the extensibility rules in Section 4. + + Servers list the controlType of request controls they recognize in + the 'supportedControl' attribute in the root DSE (Section 5.1 of + [RFC4512]). + + Controls SHOULD NOT be combined unless the semantics of the + combination has been specified. The semantics of control + combinations, if specified, are generally found in the control + specification most recently published. When a combination of + controls is encountered whose semantics are invalid, not specified + (or not known), the message is considered not well-formed; thus, the + operation fails with protocolError. Controls with a criticality of + FALSE may be ignored in order to arrive at a valid combination. + Additionally, unless order-dependent semantics are given in a + specification, the order of a combination of controls in the SEQUENCE + is ignored. Where the order is to be ignored but cannot be ignored + by the server, the message is considered not well-formed, and the + operation fails with protocolError. Again, controls with a + criticality of FALSE may be ignored in order to arrive at a valid + combination. + + This document does not specify any controls. Controls may be + specified in other documents. Documents detailing control extensions + are to provide for each control: + + - the OBJECT IDENTIFIER assigned to the control, + + - direction as to what value the sender should provide for the + criticality field (note: the semantics of the criticality field are + defined above should not be altered by the control's + specification), + + - whether the controlValue field is present, and if so, the format of + its contents, + + - the semantics of the control, and + + - optionally, semantics regarding the combination of the control with + other controls. + + + + +Sermersheim Standards Track [Page 15] + +RFC 4511 LDAPv3 June 2006 + + +4.2. Bind Operation + + The function of the Bind operation is to allow authentication + information to be exchanged between the client and server. The Bind + operation should be thought of as the "authenticate" operation. + Operational, authentication, and security-related semantics of this + operation are given in [RFC4513]. + + The Bind request is defined as follows: + + BindRequest ::= [APPLICATION 0] SEQUENCE { + version INTEGER (1 .. 127), + name LDAPDN, + authentication AuthenticationChoice } + + AuthenticationChoice ::= CHOICE { + simple [0] OCTET STRING, + -- 1 and 2 reserved + sasl [3] SaslCredentials, + ... } + + SaslCredentials ::= SEQUENCE { + mechanism LDAPString, + credentials OCTET STRING OPTIONAL } + + Fields of the BindRequest are: + + - version: A version number indicating the version of the protocol to + be used at the LDAP message layer. This document describes version + 3 of the protocol. There is no version negotiation. The client + sets this field to the version it desires. If the server does not + support the specified version, it MUST respond with a BindResponse + where the resultCode is set to protocolError. + + - name: If not empty, the name of the Directory object that the + client wishes to bind as. This field may take on a null value (a + zero-length string) for the purposes of anonymous binds ([RFC4513], + Section 5.1) or when using SASL [RFC4422] authentication + ([RFC4513], Section 5.2). Where the server attempts to locate the + named object, it SHALL NOT perform alias dereferencing. + + - authentication: Information used in authentication. This type is + extensible as defined in Section 3.7 of [RFC4520]. Servers that do + not support a choice supplied by a client return a BindResponse + with the resultCode set to authMethodNotSupported. + + + + + + +Sermersheim Standards Track [Page 16] + +RFC 4511 LDAPv3 June 2006 + + + Textual passwords (consisting of a character sequence with a known + character set and encoding) transferred to the server using the + simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629] + encoded [Unicode]. Prior to transfer, clients SHOULD prepare text + passwords as "query" strings by applying the SASLprep [RFC4013] + profile of the stringprep [RFC3454] algorithm. Passwords + consisting of other data (such as random octets) MUST NOT be + altered. The determination of whether a password is textual is a + local client matter. + +4.2.1. Processing of the Bind Request + + Before processing a BindRequest, all uncompleted operations MUST + either complete or be abandoned. The server may either wait for the + uncompleted operations to complete, or abandon them. The server then + proceeds to authenticate the client in either a single-step or + multi-step Bind process. Each step requires the server to return a + BindResponse to indicate the status of authentication. + + After sending a BindRequest, clients MUST NOT send further LDAP PDUs + until receiving the BindResponse. Similarly, servers SHOULD NOT + process or respond to requests received while processing a + BindRequest. + + If the client did not bind before sending a request and receives an + operationsError to that request, it may then send a BindRequest. If + this also fails or the client chooses not to bind on the existing + LDAP session, it may terminate the LDAP session, re-establish it, and + begin again by first sending a BindRequest. This will aid in + interoperating with servers implementing other versions of LDAP. + + Clients may send multiple Bind requests to change the authentication + and/or security associations or to complete a multi-stage Bind + process. Authentication from earlier binds is subsequently ignored. + + For some SASL authentication mechanisms, it may be necessary for the + client to invoke the BindRequest multiple times ([RFC4513], Section + 5.2). Clients MUST NOT invoke operations between two Bind requests + made as part of a multi-stage Bind. + + A client may abort a SASL bind negotiation by sending a BindRequest + with a different value in the mechanism field of SaslCredentials, or + an AuthenticationChoice other than sasl. + + + + + + + + +Sermersheim Standards Track [Page 17] + +RFC 4511 LDAPv3 June 2006 + + + If the client sends a BindRequest with the sasl mechanism field as an + empty string, the server MUST return a BindResponse with the + resultCode set to authMethodNotSupported. This will allow the client + to abort a negotiation if it wishes to try again with the same SASL + mechanism. + +4.2.2. Bind Response + + The Bind response is defined as follows. + + BindResponse ::= [APPLICATION 1] SEQUENCE { + COMPONENTS OF LDAPResult, + serverSaslCreds [7] OCTET STRING OPTIONAL } + + BindResponse consists simply of an indication from the server of the + status of the client's request for authentication. + + A successful Bind operation is indicated by a BindResponse with a + resultCode set to success. Otherwise, an appropriate result code is + set in the BindResponse. For BindResponse, the protocolError result + code may be used to indicate that the version number supplied by the + client is unsupported. + + If the client receives a BindResponse where the resultCode is set to + protocolError, it is to assume that the server does not support this + version of LDAP. While the client may be able proceed with another + version of this protocol (which may or may not require closing and + re-establishing the transport connection), how to proceed with + another version of this protocol is beyond the scope of this + document. Clients that are unable or unwilling to proceed SHOULD + terminate the LDAP session. + + The serverSaslCreds field is used as part of a SASL-defined bind + mechanism to allow the client to authenticate the server to which it + is communicating, or to perform "challenge-response" authentication. + If the client bound with the simple choice, or the SASL mechanism + does not require the server to return information to the client, then + this field SHALL NOT be included in the BindResponse. + +4.3. Unbind Operation + + The function of the Unbind operation is to terminate an LDAP session. + The Unbind operation is not the antithesis of the Bind operation as + the name implies. The naming of these operations are historical. + The Unbind operation should be thought of as the "quit" operation. + + + + + + +Sermersheim Standards Track [Page 18] + +RFC 4511 LDAPv3 June 2006 + + + The Unbind operation is defined as follows: + + UnbindRequest ::= [APPLICATION 2] NULL + + The client, upon transmission of the UnbindRequest, and the server, + upon receipt of the UnbindRequest, are to gracefully terminate the + LDAP session as described in Section 5.3. Uncompleted operations are + handled as specified in Section 3.1. + +4.4. Unsolicited Notification + + An unsolicited notification is an LDAPMessage sent from the server to + the client that is not in response to any LDAPMessage received by the + server. It is used to signal an extraordinary condition in the + server or in the LDAP session between the client and the server. The + notification is of an advisory nature, and the server will not expect + any response to be returned from the client. + + The unsolicited notification is structured as an LDAPMessage in which + the messageID is zero and protocolOp is set to the extendedResp + choice using the ExtendedResponse type (See Section 4.12). The + responseName field of the ExtendedResponse always contains an LDAPOID + that is unique for this notification. + + One unsolicited notification (Notice of Disconnection) is defined in + this document. The specification of an unsolicited notification + consists of: + + - the OBJECT IDENTIFIER assigned to the notification (to be specified + in the responseName, + + - the format of the contents of the responseValue (if any), + + - the circumstances which will cause the notification to be sent, and + + - the semantics of the message. + +4.4.1. Notice of Disconnection + + This notification may be used by the server to advise the client that + the server is about to terminate the LDAP session on its own + initiative. This notification is intended to assist clients in + distinguishing between an exceptional server condition and a + transient network failure. Note that this notification is not a + response to an Unbind requested by the client. Uncompleted + operations are handled as specified in Section 3.1. + + + + + +Sermersheim Standards Track [Page 19] + +RFC 4511 LDAPv3 June 2006 + + + The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field + is absent, and the resultCode is used to indicate the reason for the + disconnection. When the strongerAuthRequired resultCode is returned + with this message, it indicates that the server has detected that an + established security association between the client and server has + unexpectedly failed or been compromised. + + Upon transmission of the Notice of Disconnection, the server + gracefully terminates the LDAP session as described in Section 5.3. + +4.5. Search Operation + + The Search operation is used to request a server to return, subject + to access controls and other restrictions, a set of entries matching + a complex search criterion. This can be used to read attributes from + a single entry, from entries immediately subordinate to a particular + entry, or from a whole subtree of entries. + +4.5.1. Search Request + + The Search request is defined as follows: + + SearchRequest ::= [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + singleLevel (1), + wholeSubtree (2), + ... }, + derefAliases ENUMERATED { + neverDerefAliases (0), + derefInSearching (1), + derefFindingBaseObj (2), + derefAlways (3) }, + sizeLimit INTEGER (0 .. maxInt), + timeLimit INTEGER (0 .. maxInt), + typesOnly BOOLEAN, + filter Filter, + attributes AttributeSelection } + + AttributeSelection ::= SEQUENCE OF selector LDAPString + -- The LDAPString is constrained to + -- in Section 4.5.1.8 + + Filter ::= CHOICE { + and [0] SET SIZE (1..MAX) OF filter Filter, + or [1] SET SIZE (1..MAX) OF filter Filter, + not [2] Filter, + + + +Sermersheim Standards Track [Page 20] + +RFC 4511 LDAPv3 June 2006 + + + equalityMatch [3] AttributeValueAssertion, + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeDescription, + approxMatch [8] AttributeValueAssertion, + extensibleMatch [9] MatchingRuleAssertion, + ... } + + SubstringFilter ::= SEQUENCE { + type AttributeDescription, + substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { + initial [0] AssertionValue, -- can occur at most once + any [1] AssertionValue, + final [2] AssertionValue } -- can occur at most once + } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + Note that an X.500 "list"-like operation can be emulated by the + client requesting a singleLevel Search operation with a filter + checking for the presence of the 'objectClass' attribute, and that an + X.500 "read"-like operation can be emulated by a baseObject Search + operation with the same filter. A server that provides a gateway to + X.500 is not required to use the Read or List operations, although it + may choose to do so, and if it does, it must provide the same + semantics as the X.500 Search operation. + +4.5.1.1. SearchRequest.baseObject + + The name of the base object entry (or possibly the root) relative to + which the Search is to be performed. + +4.5.1.2. SearchRequest.scope + + Specifies the scope of the Search to be performed. The semantics (as + described in [X.511]) of the defined values of this field are: + + baseObject: The scope is constrained to the entry named by + baseObject. + + singleLevel: The scope is constrained to the immediate + subordinates of the entry named by baseObject. + + + + +Sermersheim Standards Track [Page 21] + +RFC 4511 LDAPv3 June 2006 + + + wholeSubtree: The scope is constrained to the entry named by + baseObject and to all its subordinates. + +4.5.1.3. SearchRequest.derefAliases + + An indicator as to whether or not alias entries (as defined in + [RFC4512]) are to be dereferenced during stages of the Search + operation. + + The act of dereferencing an alias includes recursively dereferencing + aliases that refer to aliases. + + Servers MUST detect looping while dereferencing aliases in order to + prevent denial-of-service attacks of this nature. + + The semantics of the defined values of this field are: + + neverDerefAliases: Do not dereference aliases in searching or in + locating the base object of the Search. + + derefInSearching: While searching subordinates of the base object, + dereference any alias within the search scope. Dereferenced + objects become the vertices of further search scopes where the + Search operation is also applied. If the search scope is + wholeSubtree, the Search continues in the subtree(s) of any + dereferenced object. If the search scope is singleLevel, the + search is applied to any dereferenced objects and is not applied + to their subordinates. Servers SHOULD eliminate duplicate entries + that arise due to alias dereferencing while searching. + + derefFindingBaseObj: Dereference aliases in locating the base + object of the Search, but not when searching subordinates of the + base object. + + derefAlways: Dereference aliases both in searching and in locating + the base object of the Search. + +4.5.1.4. SearchRequest.sizeLimit + + A size limit that restricts the maximum number of entries to be + returned as a result of the Search. A value of zero in this field + indicates that no client-requested size limit restrictions are in + effect for the Search. Servers may also enforce a maximum number of + entries to return. + + + + + + + +Sermersheim Standards Track [Page 22] + +RFC 4511 LDAPv3 June 2006 + + +4.5.1.5. SearchRequest.timeLimit + + A time limit that restricts the maximum time (in seconds) allowed for + a Search. A value of zero in this field indicates that no client- + requested time limit restrictions are in effect for the Search. + Servers may also enforce a maximum time limit for the Search. + +4.5.1.6. SearchRequest.typesOnly + + An indicator as to whether Search results are to contain both + attribute descriptions and values, or just attribute descriptions. + Setting this field to TRUE causes only attribute descriptions (and + not values) to be returned. Setting this field to FALSE causes both + attribute descriptions and values to be returned. + +4.5.1.7. SearchRequest.filter + + A filter that defines the conditions that must be fulfilled in order + for the Search to match a given entry. + + The 'and', 'or', and 'not' choices can be used to form combinations + of filters. At least one filter element MUST be present in an 'and' + or 'or' choice. The others match against individual attribute values + of entries in the scope of the Search. (Implementor's note: the + 'not' filter is an example of a tagged choice in an implicitly-tagged + module. In BER this is treated as if the tag were explicit.) + + A server MUST evaluate filters according to the three-valued logic of + [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to + "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for + a particular entry, then the attributes of that entry are returned as + part of the Search result (subject to any applicable access control + restrictions). If the filter evaluates to FALSE or Undefined, then + the entry is ignored for the Search. + + A filter of the "and" choice is TRUE if all the filters in the SET OF + evaluate to TRUE, FALSE if at least one filter is FALSE, and + Undefined otherwise. A filter of the "or" choice is FALSE if all the + filters in the SET OF evaluate to FALSE, TRUE if at least one filter + is TRUE, and Undefined otherwise. A filter of the 'not' choice is + TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and + Undefined if it is Undefined. + + A filter item evaluates to Undefined when the server would not be + able to determine whether the assertion value matches an entry. + Examples include: + + + + + +Sermersheim Standards Track [Page 23] + +RFC 4511 LDAPv3 June 2006 + + + - An attribute description in an equalityMatch, substrings, + greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter + is not recognized by the server. + + - The attribute type does not define the appropriate matching rule. + + - A MatchingRuleId in the extensibleMatch is not recognized by the + server or is not valid for the attribute type. + + - The type of filtering requested is not implemented. + + - The assertion value is invalid. + + For example, if a server did not recognize the attribute type + shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), + and (shoeSize<=12) would each evaluate to Undefined. + + Servers MUST NOT return errors if attribute descriptions or matching + rule ids are not recognized, assertion values are invalid, or the + assertion syntax is not supported. More details of filter processing + are given in Clause 7.8 of [X.511]. + +4.5.1.7.1. SearchRequest.filter.equalityMatch + + The matching rule for an equalityMatch filter is defined by the + EQUALITY matching rule for the attribute type or subtype. The filter + is TRUE when the EQUALITY rule returns TRUE as applied to the + attribute or subtype and the asserted value. + +4.5.1.7.2. SearchRequest.filter.substrings + + There SHALL be at most one 'initial' and at most one 'final' in the + 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL + be the first element of 'substrings'. If 'final' is present, it + SHALL be the last element of 'substrings'. + + The matching rule for an AssertionValue in a substrings filter item + is defined by the SUBSTR matching rule for the attribute type or + subtype. The filter is TRUE when the SUBSTR rule returns TRUE as + applied to the attribute or subtype and the asserted value. + + Note that the AssertionValue in a substrings filter item conforms to + the assertion syntax of the EQUALITY matching rule for the attribute + type rather than to the assertion syntax of the SUBSTR matching rule + for the attribute type. Conceptually, the entire SubstringFilter is + converted into an assertion value of the substrings matching rule + prior to applying the rule. + + + + +Sermersheim Standards Track [Page 24] + +RFC 4511 LDAPv3 June 2006 + + +4.5.1.7.3. SearchRequest.filter.greaterOrEqual + + The matching rule for a greaterOrEqual filter is defined by the + ORDERING matching rule for the attribute type or subtype. The filter + is TRUE when the ORDERING rule returns FALSE as applied to the + attribute or subtype and the asserted value. + +4.5.1.7.4. SearchRequest.filter.lessOrEqual + + The matching rules for a lessOrEqual filter are defined by the + ORDERING and EQUALITY matching rules for the attribute type or + subtype. The filter is TRUE when either the ORDERING or EQUALITY + rule returns TRUE as applied to the attribute or subtype and the + asserted value. + +4.5.1.7.5. SearchRequest.filter.present + + A present filter is TRUE when there is an attribute or subtype of the + specified attribute description present in an entry, FALSE when no + attribute or subtype of the specified attribute description is + present in an entry, and Undefined otherwise. + +4.5.1.7.6. SearchRequest.filter.approxMatch + + An approxMatch filter is TRUE when there is a value of the attribute + type or subtype for which some locally-defined approximate matching + algorithm (e.g., spelling variations, phonetic match, etc.) returns + TRUE. If a value matches for equality, it also satisfies an + approximate match. If approximate matching is not supported for the + attribute, this filter item should be treated as an equalityMatch. + +4.5.1.7.7. SearchRequest.filter.extensibleMatch + + The fields of the extensibleMatch filter item are evaluated as + follows: + + - If the matchingRule field is absent, the type field MUST be + present, and an equality match is performed for that type. + + - If the type field is absent and the matchingRule is present, the + matchValue is compared against all attributes in an entry that + support that matchingRule. + + - If the type field is present and the matchingRule is present, the + matchValue is compared against the specified attribute type and its + subtypes. + + + + + +Sermersheim Standards Track [Page 25] + +RFC 4511 LDAPv3 June 2006 + + + - If the dnAttributes field is set to TRUE, the match is additionally + applied against all the AttributeValueAssertions in an entry's + distinguished name, and it evaluates to TRUE if there is at least + one attribute or subtype in the distinguished name for which the + filter item evaluates to TRUE. The dnAttributes field is present + to alleviate the need for multiple versions of generic matching + rules (such as word matching), where one applies to entries and + another applies to entries and DN attributes as well. + + The matchingRule used for evaluation determines the syntax for the + assertion value. Once the matchingRule and attribute(s) have been + determined, the filter item evaluates to TRUE if it matches at least + one attribute type or subtype in the entry, FALSE if it does not + match any attribute type or subtype in the entry, and Undefined if + the matchingRule is not recognized, the matchingRule is unsuitable + for use with the specified type, or the assertionValue is invalid. + +4.5.1.8. SearchRequest.attributes + + A selection list of the attributes to be returned from each entry + that matches the search filter. Attributes that are subtypes of + listed attributes are implicitly included. LDAPString values of this + field are constrained to the following Augmented Backus-Naur Form + (ABNF) [RFC4234]: + + attributeSelector = attributedescription / selectorspecial + + selectorspecial = noattrs / alluserattrs + + noattrs = %x31.2E.31 ; "1.1" + + alluserattrs = %x2A ; asterisk ("*") + + The production is defined in Section 2.5 of + [RFC4512]. + + There are three special cases that may appear in the attributes + selection list: + + 1. An empty list with no attributes requests the return of all + user attributes. + + 2. A list containing "*" (with zero or more attribute + descriptions) requests the return of all user attributes in + addition to other listed (operational) attributes. + + + + + + +Sermersheim Standards Track [Page 26] + +RFC 4511 LDAPv3 June 2006 + + + 3. A list containing only the OID "1.1" indicates that no + attributes are to be returned. If "1.1" is provided with other + attributeSelector values, the "1.1" attributeSelector is + ignored. This OID was chosen because it does not (and can not) + correspond to any attribute in use. + + Client implementors should note that even if all user attributes are + requested, some attributes and/or attribute values of the entry may + not be included in Search results due to access controls or other + restrictions. Furthermore, servers will not return operational + attributes, such as objectClasses or attributeTypes, unless they are + listed by name. Operational attributes are described in [RFC4512]. + + Attributes are returned at most once in an entry. If an attribute + description is named more than once in the list, the subsequent names + are ignored. If an attribute description in the list is not + recognized, it is ignored by the server. + +4.5.2. Search Result + + The results of the Search operation are returned as zero or more + SearchResultEntry and/or SearchResultReference messages, followed by + a single SearchResultDone message. + + SearchResultEntry ::= [APPLICATION 4] SEQUENCE { + objectName LDAPDN, + attributes PartialAttributeList } + + PartialAttributeList ::= SEQUENCE OF + partialAttribute PartialAttribute + + SearchResultReference ::= [APPLICATION 19] SEQUENCE + SIZE (1..MAX) OF uri URI + + SearchResultDone ::= [APPLICATION 5] LDAPResult + + Each SearchResultEntry represents an entry found during the Search. + Each SearchResultReference represents an area not yet explored during + the Search. The SearchResultEntry and SearchResultReference messages + may come in any order. Following all the SearchResultReference and + SearchResultEntry responses, the server returns a SearchResultDone + response, which contains an indication of success or details any + errors that have occurred. + + Each entry returned in a SearchResultEntry will contain all + appropriate attributes as specified in the attributes field of the + Search Request, subject to access control and other administrative + policy. Note that the PartialAttributeList may hold zero elements. + + + +Sermersheim Standards Track [Page 27] + +RFC 4511 LDAPv3 June 2006 + + + This may happen when none of the attributes of an entry were + requested or could be returned. Note also that the partialAttribute + vals set may hold zero elements. This may happen when typesOnly is + requested, access controls prevent the return of values, or other + reasons. + + Some attributes may be constructed by the server and appear in a + SearchResultEntry attribute list, although they are not stored + attributes of an entry. Clients SHOULD NOT assume that all + attributes can be modified, even if this is permitted by access + control. + + If the server's schema defines short names [RFC4512] for an attribute + type, then the server SHOULD use one of those names in attribute + descriptions for that attribute type (in preference to using the + [RFC4512] format of the attribute type's object + identifier). The server SHOULD NOT use the short name if that name + is known by the server to be ambiguous, or if it is otherwise likely + to cause interoperability problems. + +4.5.3. Continuation References in the Search Result + + If the server was able to locate the entry referred to by the + baseObject but was unable or unwilling to search one or more non- + local entries, the server may return one or more + SearchResultReference messages, each containing a reference to + another set of servers for continuing the operation. A server MUST + NOT return any SearchResultReference messages if it has not located + the baseObject and thus has not searched any entries. In this case, + it would return a SearchResultDone containing either a referral or + noSuchObject result code (depending on the server's knowledge of the + entry named in the baseObject). + + If a server holds a copy or partial copy of the subordinate naming + context (Section 5 of [RFC4512]), it may use the search filter to + determine whether or not to return a SearchResultReference response. + Otherwise, SearchResultReference responses are always returned when + in scope. + + The SearchResultReference is of the same data type as the Referral. + + If the client wishes to progress the Search, it issues a new Search + operation for each SearchResultReference that is returned. If + multiple URIs are present, the client assumes that any supported URI + may be used to progress the operation. + + + + + + +Sermersheim Standards Track [Page 28] + +RFC 4511 LDAPv3 June 2006 + + + Clients that follow search continuation references MUST ensure that + they do not loop between servers. They MUST NOT repeatedly contact + the same server for the same request with the same parameters. Some + clients use a counter that is incremented each time search result + reference handling occurs for an operation, and these kinds of + clients MUST be able to handle at least ten nested referrals while + progressing the operation. + + Note that the Abandon operation described in Section 4.11 applies + only to a particular operation sent at the LDAP message layer between + a client and server. The client must individually abandon subsequent + Search operations it wishes to. + + A URI for a server implementing LDAP and accessible via TCP/IP (v4 or + v6) [RFC793][RFC791] is written as an LDAP URL according to + [RFC4516]. + + SearchResultReference values that are LDAP URLs follow these rules: + + - The part of the LDAP URL MUST be present, with the new target + object name. The client uses this name when following the + reference. + + - Some servers (e.g., participating in distributed indexing) may + provide a different filter in the LDAP URL. + + - If the part of the LDAP URL is present, the client uses + this filter in its next request to progress this Search, and if it + is not present the client uses the same filter as it used for that + Search. + + - If the originating search scope was singleLevel, the part + of the LDAP URL will be "base". + + - It is RECOMMENDED that the part be present to avoid + ambiguity. In the absence of a part, the scope of the + original Search request is assumed. + + - Other aspects of the new Search request may be the same as or + different from the Search request that generated the + SearchResultReference. + + - The name of an unexplored subtree in a SearchResultReference need + not be subordinate to the base object. + + Other kinds of URIs may be returned. The syntax and semantics of + such URIs is left to future specifications. Clients may ignore URIs + that they do not support. + + + +Sermersheim Standards Track [Page 29] + +RFC 4511 LDAPv3 June 2006 + + + UTF-8-encoded characters appearing in the string representation of a + DN, search filter, or other fields of the referral value may not be + legal for URIs (e.g., spaces) and MUST be escaped using the % method + in [RFC3986]. + +4.5.3.1. Examples + + For example, suppose the contacted server (hosta) holds the entry + and the entry . It + knows that both LDAP servers (hostb) and (hostc) hold + (one is the master and the other server + a shadow), and that LDAP-capable server (hostd) holds the subtree + . If a wholeSubtree Search of + is requested to the contacted server, it may + return the following: + + SearchResultEntry for DC=Example,DC=NET + SearchResultEntry for CN=Manager,DC=Example,DC=NET + SearchResultReference { + ldap://hostb/OU=People,DC=Example,DC=NET??sub + ldap://hostc/OU=People,DC=Example,DC=NET??sub } + SearchResultReference { + ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } + SearchResultDone (success) + + Client implementors should note that when following a + SearchResultReference, additional SearchResultReference may be + generated. Continuing the example, if the client contacted the + server (hostb) and issued the Search request for the subtree + , the server might respond as follows: + + SearchResultEntry for OU=People,DC=Example,DC=NET + SearchResultReference { + ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } + SearchResultReference { + ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } + SearchResultDone (success) + + Similarly, if a singleLevel Search of is + requested to the contacted server, it may return the following: + + SearchResultEntry for CN=Manager,DC=Example,DC=NET + SearchResultReference { + ldap://hostb/OU=People,DC=Example,DC=NET??base + ldap://hostc/OU=People,DC=Example,DC=NET??base } + SearchResultReference { + ldap://hostd/OU=Roles,DC=Example,DC=NET??base } + SearchResultDone (success) + + + +Sermersheim Standards Track [Page 30] + +RFC 4511 LDAPv3 June 2006 + + + If the contacted server does not hold the base object for the Search, + but has knowledge of its possible location, then it may return a + referral to the client. In this case, if the client requests a + subtree Search of to hosta, the server returns a + SearchResultDone containing a referral. + + SearchResultDone (referral) { + ldap://hostg/DC=Example,DC=ORG??sub } + +4.6. Modify Operation + + The Modify operation allows a client to request that a modification + of an entry be performed on its behalf by a server. The Modify + Request is defined as follows: + + ModifyRequest ::= [APPLICATION 6] SEQUENCE { + object LDAPDN, + changes SEQUENCE OF change SEQUENCE { + operation ENUMERATED { + add (0), + delete (1), + replace (2), + ... }, + modification PartialAttribute } } + + Fields of the Modify Request are: + + - object: The value of this field contains the name of the entry to + be modified. The server SHALL NOT perform any alias dereferencing + in determining the object to be modified. + + - changes: A list of modifications to be performed on the entry. The + entire list of modifications MUST be performed in the order they + are listed as a single atomic operation. While individual + modifications may violate certain aspects of the directory schema + (such as the object class definition and Directory Information Tree + (DIT) content rule), the resulting entry after the entire list of + modifications is performed MUST conform to the requirements of the + directory model and controlling schema [RFC4512]. + + - operation: Used to specify the type of modification being + performed. Each operation type acts on the following + modification. The values of this field have the following + semantics, respectively: + + add: add values listed to the modification attribute, + creating the attribute if necessary. + + + + +Sermersheim Standards Track [Page 31] + +RFC 4511 LDAPv3 June 2006 + + + delete: delete values listed from the modification attribute. + If no values are listed, or if all current values of the + attribute are listed, the entire attribute is removed. + + replace: replace all existing values of the modification + attribute with the new values listed, creating the attribute + if it did not already exist. A replace with no value will + delete the entire attribute if it exists, and it is ignored + if the attribute does not exist. + + - modification: A PartialAttribute (which may have an empty SET + of vals) used to hold the attribute type or attribute type and + values being modified. + + Upon receipt of a Modify Request, the server attempts to perform the + necessary modifications to the DIT and returns the result in a Modify + Response, defined as follows: + + ModifyResponse ::= [APPLICATION 7] LDAPResult + + The server will return to the client a single Modify Response + indicating either the successful completion of the DIT modification, + or the reason that the modification failed. Due to the requirement + for atomicity in applying the list of modifications in the Modify + Request, the client may expect that no modifications of the DIT have + been performed if the Modify Response received indicates any sort of + error, and that all requested modifications have been performed if + the Modify Response indicates successful completion of the Modify + operation. Whether or not the modification was applied cannot be + determined by the client if the Modify Response was not received + (e.g., the LDAP session was terminated or the Modify operation was + abandoned). + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. The Modify operation cannot + be used to remove from an entry any of its distinguished values, + i.e., those values which form the entry's relative distinguished + name. An attempt to do so will result in the server returning the + notAllowedOnRDN result code. The Modify DN operation described in + Section 4.9 is used to rename an entry. + + For attribute types that specify no equality matching, the rules in + Section 2.5.1 of [RFC4512] are followed. + + Note that due to the simplifications made in LDAP, there is not a + direct mapping of the changes in an LDAP ModifyRequest onto the + changes of a DAP ModifyEntry operation, and different implementations + + + + +Sermersheim Standards Track [Page 32] + +RFC 4511 LDAPv3 June 2006 + + + of LDAP-DAP gateways may use different means of representing the + change. If successful, the final effect of the operations on the + entry MUST be identical. + +4.7. Add Operation + + The Add operation allows a client to request the addition of an entry + into the Directory. The Add Request is defined as follows: + + AddRequest ::= [APPLICATION 8] SEQUENCE { + entry LDAPDN, + attributes AttributeList } + + AttributeList ::= SEQUENCE OF attribute Attribute + + Fields of the Add Request are: + + - entry: the name of the entry to be added. The server SHALL NOT + dereference any aliases in locating the entry to be added. + + - attributes: the list of attributes that, along with those from the + RDN, make up the content of the entry being added. Clients MAY or + MAY NOT include the RDN attribute(s) in this list. Clients MUST + NOT supply NO-USER-MODIFICATION attributes such as the + createTimestamp or creatorsName attributes, since the server + maintains these automatically. + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. For attribute types that + specify no equality matching, the rules in Section 2.5.1 of [RFC4512] + are followed (this applies to the naming attribute in addition to any + multi-valued attributes being added). + + The entry named in the entry field of the AddRequest MUST NOT exist + for the AddRequest to succeed. The immediate superior (parent) of an + object or alias entry to be added MUST exist. For example, if the + client attempted to add , the + entry did not exist, and the entry did + exist, then the server would return the noSuchObject result code with + the matchedDN field containing . + + Upon receipt of an Add Request, a server will attempt to add the + requested entry. The result of the Add attempt will be returned to + the client in the Add Response, defined as follows: + + AddResponse ::= [APPLICATION 9] LDAPResult + + + + + +Sermersheim Standards Track [Page 33] + +RFC 4511 LDAPv3 June 2006 + + + A response of success indicates that the new entry has been added to + the Directory. + +4.8. Delete Operation + + The Delete operation allows a client to request the removal of an + entry from the Directory. The Delete Request is defined as follows: + + DelRequest ::= [APPLICATION 10] LDAPDN + + The Delete Request consists of the name of the entry to be deleted. + The server SHALL NOT dereference aliases while resolving the name of + the target entry to be removed. + + Only leaf entries (those with no subordinate entries) can be deleted + with this operation. + + Upon receipt of a Delete Request, a server will attempt to perform + the entry removal requested and return the result in the Delete + Response defined as follows: + + DelResponse ::= [APPLICATION 11] LDAPResult + +4.9. Modify DN Operation + + The Modify DN operation allows a client to change the Relative + Distinguished Name (RDN) of an entry in the Directory and/or to move + a subtree of entries to a new location in the Directory. The Modify + DN Request is defined as follows: + + ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { + entry LDAPDN, + newrdn RelativeLDAPDN, + deleteoldrdn BOOLEAN, + newSuperior [0] LDAPDN OPTIONAL } + + Fields of the Modify DN Request are: + + - entry: the name of the entry to be changed. This entry may or may + not have subordinate entries. + + - newrdn: the new RDN of the entry. The value of the old RDN is + supplied when moving the entry to a new superior without changing + its RDN. Attribute values of the new RDN not matching any + attribute value of the entry are added to the entry, and an + appropriate error is returned if this fails. + + + + + +Sermersheim Standards Track [Page 34] + +RFC 4511 LDAPv3 June 2006 + + + - deleteoldrdn: a boolean field that controls whether the old RDN + attribute values are to be retained as attributes of the entry or + deleted from the entry. + + - newSuperior: if present, this is the name of an existing object + entry that becomes the immediate superior (parent) of the + existing entry. + + The server SHALL NOT dereference any aliases in locating the objects + named in entry or newSuperior. + + Upon receipt of a ModifyDNRequest, a server will attempt to perform + the name change and return the result in the Modify DN Response, + defined as follows: + + ModifyDNResponse ::= [APPLICATION 13] LDAPResult + + For example, if the entry named in the entry field was , the newrdn field was , and the + newSuperior field was absent, then this operation would attempt to + rename the entry as . If there was + already an entry with that name, the operation would fail with the + entryAlreadyExists result code. + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. For attribute types that + specify no equality matching, the rules in Section 2.5.1 of [RFC4512] + are followed (this pertains to newrdn and deleteoldrdn). + + The object named in newSuperior MUST exist. For example, if the + client attempted to add , the + entry did not exist, and the entry did + exist, then the server would return the noSuchObject result code with + the matchedDN field containing . + + If the deleteoldrdn field is TRUE, the attribute values forming the + old RDN (but not the new RDN) are deleted from the entry. If the + deleteoldrdn field is FALSE, the attribute values forming the old RDN + will be retained as non-distinguished attribute values of the entry. + + Note that X.500 restricts the ModifyDN operation to affect only + entries that are contained within a single server. If the LDAP + server is mapped onto DAP, then this restriction will apply, and the + affectsMultipleDSAs result code will be returned if this error + occurred. In general, clients MUST NOT expect to be able to perform + arbitrary movements of entries and subtrees between servers or + between naming contexts. + + + + +Sermersheim Standards Track [Page 35] + +RFC 4511 LDAPv3 June 2006 + + +4.10. Compare Operation + + The Compare operation allows a client to compare an assertion value + with the values of a particular attribute in a particular entry in + the Directory. The Compare Request is defined as follows: + + CompareRequest ::= [APPLICATION 14] SEQUENCE { + entry LDAPDN, + ava AttributeValueAssertion } + + Fields of the Compare Request are: + + - entry: the name of the entry to be compared. The server SHALL NOT + dereference any aliases in locating the entry to be compared. + + - ava: holds the attribute value assertion to be compared. + + Upon receipt of a Compare Request, a server will attempt to perform + the requested comparison and return the result in the Compare + Response, defined as follows: + + CompareResponse ::= [APPLICATION 15] LDAPResult + + The resultCode is set to compareTrue, compareFalse, or an appropriate + error. compareTrue indicates that the assertion value in the ava + field matches a value of the attribute or subtype according to the + attribute's EQUALITY matching rule. compareFalse indicates that the + assertion value in the ava field and the values of the attribute or + subtype did not match. Other result codes indicate either that the + result of the comparison was Undefined (Section 4.5.1.7), or that + some error occurred. + + Note that some directory systems may establish access controls that + permit the values of certain attributes (such as userPassword) to be + compared but not interrogated by other means. + +4.11. Abandon Operation + + The function of the Abandon operation is to allow a client to request + that the server abandon an uncompleted operation. The Abandon + Request is defined as follows: + + AbandonRequest ::= [APPLICATION 16] MessageID + + The MessageID is that of an operation that was requested earlier at + this LDAP message layer. The Abandon request itself has its own + MessageID. This is distinct from the MessageID of the earlier + operation being abandoned. + + + +Sermersheim Standards Track [Page 36] + +RFC 4511 LDAPv3 June 2006 + + + There is no response defined in the Abandon operation. Upon receipt + of an AbandonRequest, the server MAY abandon the operation identified + by the MessageID. Since the client cannot tell the difference + between a successfully abandoned operation and an uncompleted + operation, the application of the Abandon operation is limited to + uses where the client does not require an indication of its outcome. + + Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. + + In the event that a server receives an Abandon Request on a Search + operation in the midst of transmitting responses to the Search, that + server MUST cease transmitting entry responses to the abandoned + request immediately, and it MUST NOT send the SearchResultDone. Of + course, the server MUST ensure that only properly encoded LDAPMessage + PDUs are transmitted. + + The ability to abandon other (particularly update) operations is at + the discretion of the server. + + Clients should not send Abandon requests for the same operation + multiple times, and they MUST also be prepared to receive results + from operations they have abandoned (since these might have been in + transit when the Abandon was requested or might not be able to be + abandoned). + + Servers MUST discard Abandon requests for messageIDs they do not + recognize, for operations that cannot be abandoned, and for + operations that have already been abandoned. + +4.12. Extended Operation + + The Extended operation allows additional operations to be defined for + services not already available in the protocol; for example, to Add + operations to install transport layer security (see Section 4.14). + + The Extended operation allows clients to make requests and receive + responses with predefined syntaxes and semantics. These may be + defined in RFCs or be private to particular implementations. + + Each Extended operation consists of an Extended request and an + Extended response. + + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } + + + + + + +Sermersheim Standards Track [Page 37] + +RFC 4511 LDAPv3 June 2006 + + + The requestName is a dotted-decimal representation of the unique + OBJECT IDENTIFIER corresponding to the request. The requestValue is + information in a form defined by that request, encapsulated inside an + OCTET STRING. + + The server will respond to this with an LDAPMessage containing an + ExtendedResponse. + + ExtendedResponse ::= [APPLICATION 24] SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] LDAPOID OPTIONAL, + responseValue [11] OCTET STRING OPTIONAL } + + The responseName field, when present, contains an LDAPOID that is + unique for this extended operation or response. This field is + optional (even when the extension specification defines an LDAPOID + for use in this field). The field will be absent whenever the server + is unable or unwilling to determine the appropriate LDAPOID to + return, for instance, when the requestName cannot be parsed or its + value is not recognized. + + Where the requestName is not recognized, the server returns + protocolError. (The server may return protocolError in other cases.) + + The requestValue and responseValue fields contain information + associated with the operation. The format of these fields is defined + by the specification of the Extended operation. Implementations MUST + be prepared to handle arbitrary contents of these fields, including + zero bytes. Values that are defined in terms of ASN.1 and BER- + encoded according to Section 5.1 also follow the extensibility rules + in Section 4. + + Servers list the requestName of Extended Requests they recognize in + the 'supportedExtension' attribute in the root DSE (Section 5.1 of + [RFC4512]). + + Extended operations may be specified in other documents. The + specification of an Extended operation consists of: + + - the OBJECT IDENTIFIER assigned to the requestName, + + - the OBJECT IDENTIFIER (if any) assigned to the responseName (note + that the same OBJECT IDENTIFIER may be used for both the + requestName and responseName), + + + + + + + +Sermersheim Standards Track [Page 38] + +RFC 4511 LDAPv3 June 2006 + + + - the format of the contents of the requestValue and responseValue + (if any), and + + - the semantics of the operation. + +4.13. IntermediateResponse Message + + While the Search operation provides a mechanism to return multiple + response messages for a single Search request, other operations, by + nature, do not provide for multiple response messages. + + The IntermediateResponse message provides a general mechanism for + defining single-request/multiple-response operations in LDAP. This + message is intended to be used in conjunction with the Extended + operation to define new single-request/multiple-response operations + or in conjunction with a control when extending existing LDAP + operations in a way that requires them to return Intermediate + response information. + + It is intended that the definitions and descriptions of Extended + operations and controls that make use of the IntermediateResponse + message will define the circumstances when an IntermediateResponse + message can be sent by a server and the associated meaning of an + IntermediateResponse message sent in a particular circumstance. + + IntermediateResponse ::= [APPLICATION 25] SEQUENCE { + responseName [0] LDAPOID OPTIONAL, + responseValue [1] OCTET STRING OPTIONAL } + + IntermediateResponse messages SHALL NOT be returned to the client + unless the client issues a request that specifically solicits their + return. This document defines two forms of solicitation: Extended + operation and request control. IntermediateResponse messages are + specified in documents describing the manner in which they are + solicited (i.e., in the Extended operation or request control + specification that uses them). These specifications include: + + - the OBJECT IDENTIFIER (if any) assigned to the responseName, + + - the format of the contents of the responseValue (if any), and + + - the semantics associated with the IntermediateResponse message. + + Extensions that allow the return of multiple types of + IntermediateResponse messages SHALL identify those types using unique + responseName values (note that one of these may specify no value). + + + + + +Sermersheim Standards Track [Page 39] + +RFC 4511 LDAPv3 June 2006 + + + Sections 4.13.1 and 4.13.2 describe additional requirements on the + inclusion of responseName and responseValue in IntermediateResponse + messages. + +4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse + + A single-request/multiple-response operation may be defined using a + single ExtendedRequest message to solicit zero or more + IntermediateResponse messages of one or more kinds, followed by an + ExtendedResponse message. + +4.13.2. Usage with LDAP Request Controls + + A control's semantics may include the return of zero or more + IntermediateResponse messages prior to returning the final result + code for the operation. One or more kinds of IntermediateResponse + messages may be sent in response to a request control. + + All IntermediateResponse messages associated with request controls + SHALL include a responseName. This requirement ensures that the + client can correctly identify the source of IntermediateResponse + messages when: + + - two or more controls using IntermediateResponse messages are + included in a request for any LDAP operation or + + - one or more controls using IntermediateResponse messages are + included in a request with an LDAP Extended operation that uses + IntermediateResponse messages. + +4.14. StartTLS Operation + + The Start Transport Layer Security (StartTLS) operation's purpose is + to initiate installation of a TLS layer. The StartTLS operation is + defined using the Extended operation mechanism described in Section + 4.12. + +4.14.1. StartTLS Request + + A client requests TLS establishment by transmitting a StartTLS + request message to the server. The StartTLS request is defined in + terms of an ExtendedRequest. The requestName is + "1.3.6.1.4.1.1466.20037", and the requestValue field is always + absent. + + + + + + + +Sermersheim Standards Track [Page 40] + +RFC 4511 LDAPv3 June 2006 + + + The client MUST NOT send any LDAP PDUs at this LDAP message layer + following this request until it receives a StartTLS Extended response + and, in the case of a successful response, completes TLS + negotiations. + + Detected sequencing problems (particularly those detailed in Section + 3.1.1 of [RFC4513]) result in the resultCode being set to + operationsError. + + If the server does not support TLS (whether by design or by current + configuration), it returns with the resultCode set to protocolError + as described in Section 4.12. + +4.14.2. StartTLS Response + + When a StartTLS request is received, servers supporting the operation + MUST return a StartTLS response message to the requestor. The + responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section + 4.12). The responseValue is always absent. + + If the server is willing and able to negotiate TLS, it returns the + StartTLS response with the resultCode set to success. Upon client + receipt of a successful StartTLS response, protocol peers may + commence with TLS negotiation as discussed in Section 3 of [RFC4513]. + + If the server is otherwise unwilling or unable to perform this + operation, the server is to return an appropriate result code + indicating the nature of the problem. For example, if the TLS + subsystem is not presently available, the server may indicate this by + returning with the resultCode set to unavailable. In cases where a + non-success result code is returned, the LDAP session is left without + a TLS layer. + +4.14.3. Removal of the TLS Layer + + Either the client or server MAY remove the TLS layer and leave the + LDAP message layer intact by sending and receiving a TLS closure + alert. + + The initiating protocol peer sends the TLS closure alert and MUST + wait until it receives a TLS closure alert from the other peer before + sending further LDAP PDUs. + + When a protocol peer receives the initial TLS closure alert, it may + choose to allow the LDAP message layer to remain intact. In this + case, it MUST immediately transmit a TLS closure alert. Following + this, it MAY send and receive LDAP PDUs. + + + + +Sermersheim Standards Track [Page 41] + +RFC 4511 LDAPv3 June 2006 + + + Protocol peers MAY terminate the LDAP session after sending or + receiving a TLS closure alert. + +5. Protocol Encoding, Connection, and Transfer + + This protocol is designed to run over connection-oriented, reliable + transports, where the data stream is divided into octets (8-bit + units), with each octet and each bit being significant. + + One underlying service, LDAP over TCP, is defined in Section 5.2. + This service is generally applicable to applications providing or + consuming X.500-based directory services on the Internet. This + specification was generally written with the TCP mapping in mind. + Specifications detailing other mappings may encounter various + obstacles. + + Implementations of LDAP over TCP MUST implement the mapping as + described in Section 5.2. + + This table illustrates the relationship among the different layers + involved in an exchange between two protocol peers: + + +----------------------+ + | LDAP message layer | + +----------------------+ > LDAP PDUs + +----------------------+ < data + | SASL layer | + +----------------------+ > SASL-protected data + +----------------------+ < data + | TLS layer | + Application +----------------------+ > TLS-protected data + ------------+----------------------+ < data + Transport | transport connection | + +----------------------+ + +5.1. Protocol Encoding + + The protocol elements of LDAP SHALL be encoded for exchange using the + Basic Encoding Rules [BER] of [ASN.1] with the following + restrictions: + + - Only the definite form of length encoding is used. + + - OCTET STRING values are encoded in the primitive form only. + + - If the value of a BOOLEAN type is true, the encoding of the value + octet is set to hex "FF". + + + + +Sermersheim Standards Track [Page 42] + +RFC 4511 LDAPv3 June 2006 + + + - If a value of a type is its default value, it is absent. Only some + BOOLEAN and INTEGER types have default values in this protocol + definition. + + These restrictions are meant to ease the overhead of encoding and + decoding certain elements in BER. + + These restrictions do not apply to ASN.1 types encapsulated inside of + OCTET STRING values, such as attribute values, unless otherwise + stated. + +5.2. Transmission Control Protocol (TCP) + + The encoded LDAPMessage PDUs are mapped directly onto the TCP + [RFC793] bytestream using the BER-based encoding described in Section + 5.1. It is recommended that server implementations running over the + TCP provide a protocol listener on the Internet Assigned Numbers + Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may + instead provide a listener on a different port number. Clients MUST + support contacting servers on any valid TCP port. + +5.3. Termination of the LDAP session + + Termination of the LDAP session is typically initiated by the client + sending an UnbindRequest (Section 4.3), or by the server sending a + Notice of Disconnection (Section 4.4.1). In these cases, each + protocol peer gracefully terminates the LDAP session by ceasing + exchanges at the LDAP message layer, tearing down any SASL layer, + tearing down any TLS layer, and closing the transport connection. + + A protocol peer may determine that the continuation of any + communication would be pernicious, and in this case, it may abruptly + terminate the session by ceasing communication and closing the + transport connection. + + In either case, when the LDAP session is terminated, uncompleted + operations are handled as specified in Section 3.1. + +6. Security Considerations + + This version of the protocol provides facilities for simple + authentication using a cleartext password, as well as any SASL + [RFC4422] mechanism. Installing SASL and/or TLS layers can provide + integrity and other data security services. + + It is also permitted that the server can return its credentials to + the client, if it chooses to do so. + + + + +Sermersheim Standards Track [Page 43] + +RFC 4511 LDAPv3 June 2006 + + + Use of cleartext password is strongly discouraged where the + underlying transport service cannot guarantee confidentiality and may + result in disclosure of the password to unauthorized parties. + + Servers are encouraged to prevent directory modifications by clients + that have authenticated anonymously [RFC4513]. + + Security considerations for authentication methods, SASL mechanisms, + and TLS are described in [RFC4513]. + + Note that SASL authentication exchanges do not provide data + confidentiality or integrity protection for the version or name + fields of the BindRequest or the resultCode, diagnosticMessage, or + referral fields of the BindResponse, nor for any information + contained in controls attached to Bind requests or responses. Thus, + information contained in these fields SHOULD NOT be relied on unless + it is otherwise protected (such as by establishing protections at the + transport layer). + + Implementors should note that various security factors (including + authentication and authorization information and data security + services) may change during the course of the LDAP session or even + during the performance of a particular operation. For instance, + credentials could expire, authorization identities or access controls + could change, or the underlying security layer(s) could be replaced + or terminated. Implementations should be robust in the handling of + changing security factors. + + In some cases, it may be appropriate to continue the operation even + in light of security factor changes. For instance, it may be + appropriate to continue an Abandon operation regardless of the + change, or to continue an operation when the change upgraded (or + maintained) the security factor. In other cases, it may be + appropriate to fail or alter the processing of the operation. For + instance, if confidential protections were removed, it would be + appropriate either to fail a request to return sensitive data or, + minimally, to exclude the return of sensitive data. + + Implementations that cache attributes and entries obtained via LDAP + MUST ensure that access controls are maintained if that information + is to be provided to multiple clients, since servers may have access + control policies that prevent the return of entries or attributes in + Search results except to particular authenticated clients. For + example, caches could serve result information only to the client + whose request caused it to be in the cache. + + + + + + +Sermersheim Standards Track [Page 44] + +RFC 4511 LDAPv3 June 2006 + + + Servers may return referrals or Search result references that + redirect clients to peer servers. It is possible for a rogue + application to inject such referrals into the data stream in an + attempt to redirect a client to a rogue server. Clients are advised + to be aware of this and possibly reject referrals when + confidentiality measures are not in place. Clients are advised to + reject referrals from the StartTLS operation. + + The matchedDN and diagnosticMessage fields, as well as some + resultCode values (e.g., attributeOrValueExists and + entryAlreadyExists), could disclose the presence or absence of + specific data in the directory that is subject to access and other + administrative controls. Server implementations should restrict + access to protected information equally under both normal and error + conditions. + + Protocol peers MUST be prepared to handle invalid and arbitrary- + length protocol encodings. Invalid protocol encodings include: BER + encoding exceptions, format string and UTF-8 encoding exceptions, + overflow exceptions, integer value exceptions, and binary mode on/off + flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides + excellent examples of these exceptions and test cases used to + discover flaws. + + In the event that a protocol peer senses an attack that in its nature + could cause damage due to further communication at any layer in the + LDAP session, the protocol peer should abruptly terminate the LDAP + session as described in Section 5.3. + +7. Acknowledgements + + This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve + Kille. RFC 2251 was a product of the IETF ASID Working Group. + + It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and + Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group. + + It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. + RFC 3771 was an individual submission to the IETF. + + This document is a product of the IETF LDAPBIS Working Group. + Significant contributors of technical review and content include Kurt + Zeilenga, Steven Legg, and Hallvard Furuseth. + + + + + + + + +Sermersheim Standards Track [Page 45] + +RFC 4511 LDAPv3 June 2006 + + +8. Normative References + + [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- + 1:2002 "Information Technology - Abstract Syntax + Notation One (ASN.1): Specification of basic notation". + + [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, + "Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", 2002. + + [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC + 10646-1 : 1993. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3454] Hoffman P. and M. Blanchet, "Preparation of + Internationalized Strings ('stringprep')", RFC 3454, + December 2002. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version + 1.1", RFC 4346, March 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + June 2006. + + + +Sermersheim Standards Track [Page 46] + +RFC 4511 LDAPv3 June 2006 + + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [Unicode] The Unicode Consortium, "The Unicode Standard, Version + 3.2.0" is defined by "The Unicode Standard, Version + 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- + 61633-5), as amended by the "Unicode Standard Annex + #27: Unicode 3.1" + (http://www.unicode.org/reports/tr27/) and by the + "Unicode Standard Annex #28: Unicode 3.2" + (http://www.unicode.org/reports/tr28/). + + [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, + Models and Service", 1993. + + [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service + Definition", 1993. + + + + + + + + + +Sermersheim Standards Track [Page 47] + +RFC 4511 LDAPv3 June 2006 + + +9. Informative References + + [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report + #17, Character Encoding Model", UTR17, + , August + 2000. + + [Glossary] The Unicode Consortium, "Unicode Glossary", + . + + [PortReg] IANA, "Port Numbers", + . + + [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" + . + +10. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + result code registry to indicate that this document provides the + definitive technical specification for result codes 0-36, 48-54, 64- + 70, 80-90. It is also noted that one resultCode value + (strongAuthRequired) has been renamed (to strongerAuthRequired). + + The IANA has also updated the LDAP Protocol Mechanism registry to + indicate that this document and [RFC4513] provides the definitive + technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) + Extended operation. + + IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the + ASN.1 module defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Jim Sermersheim + Specification: RFC 4511 + Author/Change Controller: IESG + Comments: + Identifies the LDAP ASN.1 module + + + + + + + + + + + +Sermersheim Standards Track [Page 48] + +RFC 4511 LDAPv3 June 2006 + + +Appendix A. LDAP Result Codes + + This normative appendix details additional considerations regarding + LDAP result codes and provides a brief, general description of each + LDAP result code enumerated in Section 4.1.9. + + Additional result codes MAY be defined for use with extensions + [RFC4520]. Client implementations SHALL treat any result code that + they do not recognize as an unknown error condition. + + The descriptions provided here do not fully account for result code + substitutions used to prevent unauthorized disclosures (such as + substitution of noSuchObject for insufficientAccessRights, or + invalidCredentials for insufficientAccessRights). + +A.1. Non-Error Result Codes + + These result codes (called "non-error" result codes) do not indicate + an error condition: + + success (0), + compareFalse (5), + compareTrue (6), + referral (10), and + saslBindInProgress (14). + + The success, compareTrue, and compareFalse result codes indicate + successful completion (and, hence, are referred to as "successful" + result codes). + + The referral and saslBindInProgress result codes indicate the client + needs to take additional action to complete the operation. + +A.2. Result Codes + + Existing LDAP result codes are described as follows: + + success (0) + Indicates the successful completion of an operation. Note: + this code is not used with the Compare operation. See + compareFalse (5) and compareTrue (6). + + + + + + + + + + +Sermersheim Standards Track [Page 49] + +RFC 4511 LDAPv3 June 2006 + + + operationsError (1) + Indicates that the operation is not properly sequenced with + relation to other operations (of same or different type). + + For example, this code is returned if the client attempts to + StartTLS [RFC4346] while there are other uncompleted operations + or if a TLS layer was already installed. + + protocolError (2) + Indicates the server received data that is not well-formed. + + For Bind operation only, this code is also used to indicate + that the server does not support the requested protocol + version. + + For Extended operations only, this code is also used to + indicate that the server does not support (by design or + configuration) the Extended operation associated with the + requestName. + + For request operations specifying multiple controls, this may + be used to indicate that the server cannot ignore the order + of the controls as specified, or that the combination of the + specified controls is invalid or unspecified. + + timeLimitExceeded (3) + Indicates that the time limit specified by the client was + exceeded before the operation could be completed. + + sizeLimitExceeded (4) + Indicates that the size limit specified by the client was + exceeded before the operation could be completed. + + compareFalse (5) + Indicates that the Compare operation has successfully + completed and the assertion has evaluated to FALSE or + Undefined. + + compareTrue (6) + Indicates that the Compare operation has successfully + completed and the assertion has evaluated to TRUE. + + authMethodNotSupported (7) + Indicates that the authentication method or mechanism is not + supported. + + + + + + +Sermersheim Standards Track [Page 50] + +RFC 4511 LDAPv3 June 2006 + + + strongerAuthRequired (8) + Indicates the server requires strong(er) authentication in + order to complete the operation. + + When used with the Notice of Disconnection operation, this + code indicates that the server has detected that an + established security association between the client and + server has unexpectedly failed or been compromised. + + referral (10) + Indicates that a referral needs to be chased to complete the + operation (see Section 4.1.10). + + adminLimitExceeded (11) + Indicates that an administrative limit has been exceeded. + + unavailableCriticalExtension (12) + Indicates a critical control is unrecognized (see Section + 4.1.11). + + confidentialityRequired (13) + Indicates that data confidentiality protections are required. + + saslBindInProgress (14) + Indicates the server requires the client to send a new bind + request, with the same SASL mechanism, to continue the + authentication process (see Section 4.2). + + noSuchAttribute (16) + Indicates that the named entry does not contain the specified + attribute or attribute value. + + undefinedAttributeType (17) + Indicates that a request field contains an unrecognized + attribute description. + + inappropriateMatching (18) + Indicates that an attempt was made (e.g., in an assertion) to + use a matching rule not defined for the attribute type + concerned. + + constraintViolation (19) + Indicates that the client supplied an attribute value that + does not conform to the constraints placed upon it by the + data model. + + For example, this code is returned when multiple values are + supplied to an attribute that has a SINGLE-VALUE constraint. + + + +Sermersheim Standards Track [Page 51] + +RFC 4511 LDAPv3 June 2006 + + + attributeOrValueExists (20) + Indicates that the client supplied an attribute or value to + be added to an entry, but the attribute or value already + exists. + + invalidAttributeSyntax (21) + Indicates that a purported attribute value does not conform + to the syntax of the attribute. + + noSuchObject (32) + Indicates that the object does not exist in the DIT. + + aliasProblem (33) + Indicates that an alias problem has occurred. For example, + the code may used to indicate an alias has been dereferenced + that names no object. + + invalidDNSyntax (34) + Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search + base, target entry, ModifyDN newrdn, etc.) of a request does + not conform to the required syntax or contains attribute + values that do not conform to the syntax of the attribute's + type. + + aliasDereferencingProblem (36) + Indicates that a problem occurred while dereferencing an + alias. Typically, an alias was encountered in a situation + where it was not allowed or where access was denied. + + inappropriateAuthentication (48) + Indicates the server requires the client that had attempted + to bind anonymously or without supplying credentials to + provide some form of credentials. + + invalidCredentials (49) + Indicates that the provided credentials (e.g., the user's name + and password) are invalid. + + insufficientAccessRights (50) + Indicates that the client does not have sufficient access + rights to perform the operation. + + busy (51) + Indicates that the server is too busy to service the + operation. + + + + + + +Sermersheim Standards Track [Page 52] + +RFC 4511 LDAPv3 June 2006 + + + unavailable (52) + Indicates that the server is shutting down or a subsystem + necessary to complete the operation is offline. + + unwillingToPerform (53) + Indicates that the server is unwilling to perform the + operation. + + loopDetect (54) + Indicates that the server has detected an internal loop (e.g., + while dereferencing aliases or chaining an operation). + + namingViolation (64) + Indicates that the entry's name violates naming restrictions. + + objectClassViolation (65) + Indicates that the entry violates object class restrictions. + + notAllowedOnNonLeaf (66) + Indicates that the operation is inappropriately acting upon a + non-leaf entry. + + notAllowedOnRDN (67) + Indicates that the operation is inappropriately attempting to + remove a value that forms the entry's relative distinguished + name. + + entryAlreadyExists (68) + Indicates that the request cannot be fulfilled (added, moved, + or renamed) as the target entry already exists. + + objectClassModsProhibited (69) + Indicates that an attempt to modify the object class(es) of + an entry's 'objectClass' attribute is prohibited. + + For example, this code is returned when a client attempts to + modify the structural object class of an entry. + + affectsMultipleDSAs (71) + Indicates that the operation cannot be performed as it would + affect multiple servers (DSAs). + + other (80) + Indicates the server has encountered an internal error. + + + + + + + +Sermersheim Standards Track [Page 53] + +RFC 4511 LDAPv3 June 2006 + + +Appendix B. Complete ASN.1 Definition + + This appendix is normative. + + Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18} + -- Copyright (C) The Internet Society (2006). This version of + -- this ASN.1 module is part of RFC 4511; see the RFC itself + -- for full legal notices. + DEFINITIONS + IMPLICIT TAGS + EXTENSIBILITY IMPLIED ::= + + BEGIN + + LDAPMessage ::= SEQUENCE { + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse, + ..., + intermediateResponse IntermediateResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- [ISO10646] characters + + + + +Sermersheim Standards Track [Page 54] + +RFC 4511 LDAPv3 June 2006 + + + LDAPOID ::= OCTET STRING -- Constrained to + -- [RFC4512] + + LDAPDN ::= LDAPString -- Constrained to + -- [RFC4514] + + RelativeLDAPDN ::= LDAPString -- Constrained to + -- [RFC4514] + + AttributeDescription ::= LDAPString + -- Constrained to + -- [RFC4512] + + AttributeValue ::= OCTET STRING + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + AssertionValue ::= OCTET STRING + + PartialAttribute ::= SEQUENCE { + type AttributeDescription, + vals SET OF value AttributeValue } + + Attribute ::= PartialAttribute(WITH COMPONENTS { + ..., + vals (SIZE(1..MAX))}) + + MatchingRuleId ::= LDAPString + + LDAPResult ::= SEQUENCE { + resultCode ENUMERATED { + success (0), + operationsError (1), + protocolError (2), + timeLimitExceeded (3), + sizeLimitExceeded (4), + compareFalse (5), + compareTrue (6), + authMethodNotSupported (7), + strongerAuthRequired (8), + -- 9 reserved -- + referral (10), + adminLimitExceeded (11), + unavailableCriticalExtension (12), + confidentialityRequired (13), + saslBindInProgress (14), + + + +Sermersheim Standards Track [Page 55] + +RFC 4511 LDAPv3 June 2006 + + + noSuchAttribute (16), + undefinedAttributeType (17), + inappropriateMatching (18), + constraintViolation (19), + attributeOrValueExists (20), + invalidAttributeSyntax (21), + -- 22-31 unused -- + noSuchObject (32), + aliasProblem (33), + invalidDNSyntax (34), + -- 35 reserved for undefined isLeaf -- + aliasDereferencingProblem (36), + -- 37-47 unused -- + inappropriateAuthentication (48), + invalidCredentials (49), + insufficientAccessRights (50), + busy (51), + unavailable (52), + unwillingToPerform (53), + loopDetect (54), + -- 55-63 unused -- + namingViolation (64), + objectClassViolation (65), + notAllowedOnNonLeaf (66), + notAllowedOnRDN (67), + entryAlreadyExists (68), + objectClassModsProhibited (69), + -- 70 reserved for CLDAP -- + affectsMultipleDSAs (71), + -- 72-79 unused -- + other (80), + ... }, + matchedDN LDAPDN, + diagnosticMessage LDAPString, + referral [3] Referral OPTIONAL } + + Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI + + URI ::= LDAPString -- limited to characters permitted in + -- URIs + + Controls ::= SEQUENCE OF control Control + + Control ::= SEQUENCE { + controlType LDAPOID, + criticality BOOLEAN DEFAULT FALSE, + controlValue OCTET STRING OPTIONAL } + + + + +Sermersheim Standards Track [Page 56] + +RFC 4511 LDAPv3 June 2006 + + + BindRequest ::= [APPLICATION 0] SEQUENCE { + version INTEGER (1 .. 127), + name LDAPDN, + authentication AuthenticationChoice } + + AuthenticationChoice ::= CHOICE { + simple [0] OCTET STRING, + -- 1 and 2 reserved + sasl [3] SaslCredentials, + ... } + + SaslCredentials ::= SEQUENCE { + mechanism LDAPString, + credentials OCTET STRING OPTIONAL } + + BindResponse ::= [APPLICATION 1] SEQUENCE { + COMPONENTS OF LDAPResult, + serverSaslCreds [7] OCTET STRING OPTIONAL } + + UnbindRequest ::= [APPLICATION 2] NULL + + SearchRequest ::= [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + singleLevel (1), + wholeSubtree (2), + ... }, + derefAliases ENUMERATED { + neverDerefAliases (0), + derefInSearching (1), + derefFindingBaseObj (2), + derefAlways (3) }, + sizeLimit INTEGER (0 .. maxInt), + timeLimit INTEGER (0 .. maxInt), + typesOnly BOOLEAN, + filter Filter, + attributes AttributeSelection } + + AttributeSelection ::= SEQUENCE OF selector LDAPString + -- The LDAPString is constrained to + -- in Section 4.5.1.8 + + Filter ::= CHOICE { + and [0] SET SIZE (1..MAX) OF filter Filter, + or [1] SET SIZE (1..MAX) OF filter Filter, + not [2] Filter, + equalityMatch [3] AttributeValueAssertion, + + + +Sermersheim Standards Track [Page 57] + +RFC 4511 LDAPv3 June 2006 + + + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeDescription, + approxMatch [8] AttributeValueAssertion, + extensibleMatch [9] MatchingRuleAssertion, + ... } + + SubstringFilter ::= SEQUENCE { + type AttributeDescription, + substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { + initial [0] AssertionValue, -- can occur at most once + any [1] AssertionValue, + final [2] AssertionValue } -- can occur at most once + } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + SearchResultEntry ::= [APPLICATION 4] SEQUENCE { + objectName LDAPDN, + attributes PartialAttributeList } + + PartialAttributeList ::= SEQUENCE OF + partialAttribute PartialAttribute + + SearchResultReference ::= [APPLICATION 19] SEQUENCE + SIZE (1..MAX) OF uri URI + + SearchResultDone ::= [APPLICATION 5] LDAPResult + + ModifyRequest ::= [APPLICATION 6] SEQUENCE { + object LDAPDN, + changes SEQUENCE OF change SEQUENCE { + operation ENUMERATED { + add (0), + delete (1), + replace (2), + ... }, + modification PartialAttribute } } + + ModifyResponse ::= [APPLICATION 7] LDAPResult + + + + + + +Sermersheim Standards Track [Page 58] + +RFC 4511 LDAPv3 June 2006 + + + AddRequest ::= [APPLICATION 8] SEQUENCE { + entry LDAPDN, + attributes AttributeList } + + AttributeList ::= SEQUENCE OF attribute Attribute + + AddResponse ::= [APPLICATION 9] LDAPResult + + DelRequest ::= [APPLICATION 10] LDAPDN + + DelResponse ::= [APPLICATION 11] LDAPResult + + ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { + entry LDAPDN, + newrdn RelativeLDAPDN, + deleteoldrdn BOOLEAN, + newSuperior [0] LDAPDN OPTIONAL } + + ModifyDNResponse ::= [APPLICATION 13] LDAPResult + + CompareRequest ::= [APPLICATION 14] SEQUENCE { + entry LDAPDN, + ava AttributeValueAssertion } + + CompareResponse ::= [APPLICATION 15] LDAPResult + + AbandonRequest ::= [APPLICATION 16] MessageID + + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } + + ExtendedResponse ::= [APPLICATION 24] SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] LDAPOID OPTIONAL, + responseValue [11] OCTET STRING OPTIONAL } + + IntermediateResponse ::= [APPLICATION 25] SEQUENCE { + responseName [0] LDAPOID OPTIONAL, + responseValue [1] OCTET STRING OPTIONAL } + + END + + + + + + + + + +Sermersheim Standards Track [Page 59] + +RFC 4511 LDAPv3 June 2006 + + +Appendix C. Changes + + This appendix is non-normative. + + This appendix summarizes substantive changes made to RFC 2251, RFC + 2830, and RFC 3771. + +C.1. Changes Made to RFC 2251 + + This section summarizes the substantive changes made to Sections 1, + 2, 3.1, and 4, and the remainder of RFC 2251. Readers should + consult [RFC4512] and [RFC4513] for summaries of changes to other + sections. + +C.1.1. Section 1 (Status of this Memo) + + - Removed IESG note. Post publication of RFC 2251, mandatory LDAP + authentication mechanisms have been standardized which are + sufficient to remove this note. See [RFC4513] for authentication + mechanisms. + +C.1.2. Section 3.1 (Protocol Model) and others + + - Removed notes giving history between LDAP v1, v2, and v3. Instead, + added sufficient language so that this document can stand on its + own. + +C.1.3. Section 4 (Elements of Protocol) + + - Clarified where the extensibility features of ASN.1 apply to the + protocol. This change affected various ASN.1 types by the + inclusion of ellipses (...) to certain elements. + - Removed the requirement that servers that implement version 3 or + later MUST provide the 'supportedLDAPVersion' attribute. This + statement provided no interoperability advantages. + +C.1.4. Section 4.1.1 (Message Envelope) + + - There was a mandatory requirement for the server to return a + Notice of Disconnection and drop the transport connection when a + PDU is malformed in a certain way. This has been updated such that + the server SHOULD return the Notice of Disconnection, and it MUST + terminate the LDAP Session. + +C.1.5. Section 4.1.1.1 (Message ID) + + - Required that the messageID of requests MUST be non-zero as the + zero is reserved for Notice of Disconnection. + + + +Sermersheim Standards Track [Page 60] + +RFC 4511 LDAPv3 June 2006 + + + - Specified when it is and isn't appropriate to return an already + used messageID. RFC 2251 accidentally imposed synchronous server + behavior in its wording of this. + +C.1.6. Section 4.1.2 (String Types) + + - Stated that LDAPOID is constrained to from [RFC4512]. + +C.1.7. Section 4.1.5.1 (Binary Option) and others + + - Removed the Binary Option from the specification. There are + numerous interoperability problems associated with this method of + alternate attribute type encoding. Work to specify a suitable + replacement is ongoing. + +C.1.8. Section 4.1.8 (Attribute) + + - Combined the definitions of PartialAttribute and Attribute here, + and defined Attribute in terms of PartialAttribute. + +C.1.9. Section 4.1.10 (Result Message) + + - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to + be sent for non-error results. + - Moved some language into Appendix A, and referred the reader there. + - Allowed matchedDN to be present for other result codes than those + listed in RFC 2251. + - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to + clarify that this code may often be returned to indicate that a + stronger authentication is needed to perform a given operation. + +C.1.10. Section 4.1.11 (Referral) + + - Defined referrals in terms of URIs rather than URLs. + - Removed the requirement that all referral URIs MUST be equally + capable of progressing the operation. The statement was ambiguous + and provided no instructions on how to carry it out. + - Added the requirement that clients MUST NOT loop between servers. + - Clarified the instructions for using LDAPURLs in referrals, and in + doing so added a recommendation that the scope part be present. + - Removed imperatives which required clients to use URLs in specific + ways to progress an operation. These did nothing for + interoperability. + + + + + + + + +Sermersheim Standards Track [Page 61] + +RFC 4511 LDAPv3 June 2006 + + +C.1.11. Section 4.1.12 (Controls) + + - Specified how control values defined in terms of ASN.1 are to be + encoded. + - Noted that the criticality field is only applied to request + messages (except UnbindRequest), and must be ignored when present + on response messages and UnbindRequest. + - Specified that non-critical controls may be ignored at the + server's discretion. There was confusion in the original wording + which led some to believe that recognized controls may not be + ignored as long as they were associated with a proper request. + - Added language regarding combinations of controls and the ordering + of controls on a message. + - Specified that when the semantics of the combination of controls + is undefined or unknown, it results in a protocolError. + - Changed "The server MUST be prepared" to "Implementations MUST be + prepared" in paragraph 8 to reflect that both client and server + implementations must be able to handle this (as both parse + controls). + +C.1.12. Section 4.2 (Bind Operation) + + - Mandated that servers return protocolError when the version is not + supported. + - Disambiguated behavior when the simple authentication is used, the + name is empty, and the password is non-empty. + - Required servers to not dereference aliases for Bind. This was + added for consistency with other operations and to help ensure + data consistency. + - Required that textual passwords be transferred as UTF-8 encoded + Unicode, and added recommendations on string preparation. This was + to help ensure interoperability of passwords being sent from + different clients. + +C.1.13. Section 4.2.1 (Sequencing of the Bind Request) + + - This section was largely reorganized for readability, and language + was added to clarify the authentication state of failed and + abandoned Bind operations. + - Removed: "If a SASL transfer encryption or integrity mechanism has + been negotiated, that mechanism does not support the changing of + credentials from one identity to another, then the client MUST + instead establish a new connection." + If there are dependencies between multiple negotiations of a + particular SASL mechanism, the technical specification for that + SASL mechanism details how applications are to deal with them. + LDAP should not require any special handling. + - Dropped MUST imperative in paragraph 3 to align with [RFC2119]. + + + +Sermersheim Standards Track [Page 62] + +RFC 4511 LDAPv3 June 2006 + + + - Mandated that clients not send non-Bind operations while a Bind is + in progress, and suggested that servers not process them if they + are received. This is needed to ensure proper sequencing of the + Bind in relationship to other operations. + +C.1.14. Section 4.2.3 (Bind Response) + + - Moved most error-related text to Appendix A, and added text + regarding certain errors used in conjunction with the Bind + operation. + - Prohibited the server from specifying serverSaslCreds when not + appropriate. + +C.1.15. Section 4.3 (Unbind Operation) + + - Specified that both peers are to cease transmission and terminate + the LDAP session for the Unbind operation. + +C.1.16. Section 4.4 (Unsolicited Notification) + + - Added instructions for future specifications of Unsolicited + Notifications. + +C.1.17. Section 4.5.1 (Search Request) + + - SearchRequest attributes is now defined as an AttributeSelection + type rather than AttributeDescriptionList, and an ABNF is + provided. + - SearchRequest attributes may contain duplicate attribute + descriptions. This was previously prohibited. Now servers are + instructed to ignore subsequent names when they are duplicated. + This was relaxed in order to allow different short names and also + OIDs to be requested for an attribute. + - The present search filter now evaluates to Undefined when the + specified attribute is not known to the server. It used to + evaluate to FALSE, which caused behavior inconsistent with what + most would expect, especially when the 'not' operator was used. + - The Filter choice SubstringFilter substrings type is now defined + with a lower bound of 1. + - The SubstringFilter substrings 'initial, 'any', and 'final' types + are now AssertionValue rather than LDAPString. Also, added + imperatives stating that 'initial' (if present) must be listed + first, and 'final' (if present) must be listed last. + - Disambiguated the semantics of the derefAliases choices. There was + question as to whether derefInSearching applied to the base object + in a wholeSubtree Search. + - Added instructions for equalityMatch, substrings, greaterOrEqual, + lessOrEqual, and approxMatch. + + + +Sermersheim Standards Track [Page 63] + +RFC 4511 LDAPv3 June 2006 + + + +C.1.18. Section 4.5.2 (Search Result) + + - Recommended that servers not use attribute short names when it + knows they are ambiguous or may cause interoperability problems. + - Removed all mention of ExtendedResponse due to lack of + implementation. + +C.1.19. Section 4.5.3 (Continuation References in the Search Result) + + - Made changes similar to those made to Section 4.1.11. + +C.1.20. Section 4.5.3.1 (Example) + + - Fixed examples to adhere to changes made to Section 4.5.3. + +C.1.21. Section 4.6 (Modify Operation) + + - Replaced AttributeTypeAndValues with Attribute as they are + equivalent. + - Specified the types of modification changes that might + temporarily violate schema. Some readers were under the impression + that any temporary schema violation was allowed. + +C.1.22. Section 4.7 (Add Operation) + + - Aligned Add operation with X.511 in that the attributes of the RDN + are used in conjunction with the listed attributes to create the + entry. Previously, Add required that the distinguished values be + present in the listed attributes. + - Removed requirement that the objectClass attribute MUST be + specified as some DSE types do not require this attribute. + Instead, generic wording was added, requiring the added entry to + adhere to the data model. + - Removed recommendation regarding placement of objects. This is + covered in the data model document. + +C.1.23. Section 4.9 (Modify DN Operation) + + - Required servers to not dereference aliases for Modify DN. This + was added for consistency with other operations and to help ensure + data consistency. + - Allow Modify DN to fail when moving between naming contexts. + - Specified what happens when the attributes of the newrdn are not + present on the entry. + + + + + + +Sermersheim Standards Track [Page 64] + +RFC 4511 LDAPv3 June 2006 + + +C.1.24. Section 4.10 (Compare Operation) + + - Specified that compareFalse means that the Compare took place and + the result is false. There was confusion that led people to + believe that an Undefined match resulted in compareFalse. + - Required servers to not dereference aliases for Compare. This was + added for consistency with other operations and to help ensure + data consistency. + +C.1.25. Section 4.11 (Abandon Operation) + + - Explained that since Abandon returns no response, clients should + not use it if they need to know the outcome. + - Specified that Abandon and Unbind cannot be abandoned. + +C.1.26. Section 4.12 (Extended Operation) + + - Specified how values of Extended operations defined in terms of + ASN.1 are to be encoded. + - Added instructions on what Extended operation specifications + consist of. + - Added a recommendation that servers advertise supported Extended + operations. + +C.1.27. Section 5.2 (Transfer Protocols) + + - Moved referral-specific instructions into referral-related + sections. + +C.1.28. Section 7 (Security Considerations) + + - Reworded notes regarding SASL not protecting certain aspects of + the LDAP Bind messages. + - Noted that Servers are encouraged to prevent directory + modifications by clients that have authenticated anonymously + [RFC4513]. + - Added a note regarding the possibility of changes to security + factors (authentication, authorization, and data confidentiality). + - Warned against following referrals that may have been injected in + the data stream. + - Noted that servers should protect information equally, whether in + an error condition or not, and mentioned matchedDN, + diagnosticMessage, and resultCodes specifically. + - Added a note regarding malformed and long encodings. + + + + + + + +Sermersheim Standards Track [Page 65] + +RFC 4511 LDAPv3 June 2006 + + +C.1.29. Appendix A (Complete ASN.1 Definition) + + - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. + - Removed AttributeType. It is not used. + +C.2. Changes Made to RFC 2830 + + This section summarizes the substantive changes made to Sections of + RFC 2830. Readers should consult [RFC4513] for summaries of changes + to other sections. + +C.2.1. Section 2.3 (Response other than "success") + + - Removed wording indicating that referrals can be returned from + StartTLS. + - Removed requirement that only a narrow set of result codes can be + returned. Some result codes are required in certain scenarios, but + any other may be returned if appropriate. + - Removed requirement that the ExtendedResponse.responseName MUST be + present. There are circumstances where this is impossible, and + requiring this is at odds with language in Section 4.12. + +C.2.1. Section 4 (Closing a TLS Connection) + + - Reworded most of this section to align with definitions of the + LDAP protocol layers. + - Removed instructions on abrupt closure as this is covered in other + areas of the document (specifically, Section 5.3) + +C.3. Changes Made to RFC 3771 + + - Rewrote to fit into this document. In general, semantics were + preserved. Supporting and background language seen as redundant + due to its presence in this document was omitted. + + - Specified that Intermediate responses to a request may be of + different types, and one of the response types may be specified to + have no response value. + + + + + + + + + + + + + +Sermersheim Standards Track [Page 66] + +RFC 4511 LDAPv3 June 2006 + + +Editor's Address + + Jim Sermersheim + Novell, Inc. + 1800 South Novell Place + Provo, Utah 84606, USA + + Phone: +1 801 861-3088 + EMail: jimse@novell.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim Standards Track [Page 67] + +RFC 4511 LDAPv3 June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Sermersheim Standards Track [Page 68] + diff --git a/source4/ldap_server/devdocs/rfc4512.txt b/source4/ldap_server/devdocs/rfc4512.txt new file mode 100644 index 0000000000..f45a3f3e73 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4512.txt @@ -0,0 +1,2915 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4512 OpenLDAP Foundation +Obsoletes: 2251, 2252, 2256, 3674 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Directory Information Models + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an Internet + protocol for accessing distributed directory services that act in + accordance with X.500 data and service models. This document + describes the X.500 Directory Information Models, as used in LDAP. + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4512 LDAP Models June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other LDAP Specifications ..................3 + 1.2. Relationship to X.501 ......................................4 + 1.3. Conventions ................................................4 + 1.4. Common ABNF Productions ....................................4 + 2. Model of Directory User Information .............................6 + 2.1. The Directory Information Tree .............................7 + 2.2. Structure of an Entry ......................................7 + 2.3. Naming of Entries ..........................................8 + 2.4. Object Classes .............................................9 + 2.5. Attribute Descriptions ....................................12 + 2.6. Alias Entries .............................................16 + 3. Directory Administrative and Operational Information ...........17 + 3.1. Subtrees ..................................................17 + 3.2. Subentries ................................................18 + 3.3. The 'objectClass' attribute ...............................18 + 3.4. Operational Attributes ....................................19 + 4. Directory Schema ...............................................22 + 4.1. Schema Definitions ........................................23 + 4.2. Subschema Subentries ......................................32 + 4.3. 'extensibleObject' object class ...........................35 + 4.4. Subschema Discovery .......................................35 + 5. DSA (Server) Informational Model ...............................36 + 5.1. Server-Specific Data Requirements .........................36 + 6. Other Considerations ...........................................40 + 6.1. Preservation of User Information ..........................40 + 6.2. Short Names ...............................................41 + 6.3. Cache and Shadowing .......................................41 + 7. Implementation Guidelines ......................................42 + 7.1. Server Guidelines .........................................42 + 7.2. Client Guidelines .........................................42 + 8. Security Considerations ........................................43 + 9. IANA Considerations ............................................43 + 10. Acknowledgements ..............................................44 + 11. Normative References ..........................................45 + Appendix A. Changes ...............................................47 + A.1. Changes to RFC 2251 .......................................47 + A.2. Changes to RFC 2252 .......................................49 + A.3. Changes to RFC 2256 .......................................50 + A.4. Changes to RFC 3674 .......................................51 + + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4512 LDAP Models June 2006 + + +1. Introduction + + This document discusses the X.500 Directory Information Models + [X.501], as used by the Lightweight Directory Access Protocol (LDAP) + [RFC4510]. + + The Directory is "a collection of open systems cooperating to provide + directory services" [X.500]. The information held in the Directory + is collectively known as the Directory Information Base (DIB). A + Directory user, which may be a human or other entity, accesses the + Directory through a client (or Directory User Agent (DUA)). The + client, on behalf of the directory user, interacts with one or more + servers (or Directory System Agents (DSA)). A server holds a + fragment of the DIB. + + The DIB contains two classes of information: + + 1) user information (e.g., information provided and administrated + by users). Section 2 describes the Model of User Information. + + 2) administrative and operational information (e.g., information + used to administer and/or operate the directory). Section 3 + describes the model of Directory Administrative and Operational + Information. + + These two models, referred to as the generic Directory Information + Models, describe how information is represented in the Directory. + These generic models provide a framework for other information + models. Section 4 discusses the subschema information model and + subschema discovery. Section 5 discusses the DSA (Server) + Informational Model. + + Other X.500 information models (such as access control distribution + knowledge and replication knowledge information models) may be + adapted for use in LDAP. Specification of how these models apply to + LDAP is left to future documents. + +1.1. Relationship to Other LDAP Specifications + + This document is a integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as + portions of Sections 4 and 6. Appendix A.1 summarizes changes to + these sections. The remainder of RFC 2251 is obsoleted by the + [RFC4511], [RFC4513], and [RFC4510] documents. + + + + +Zeilenga Standards Track [Page 3] + +RFC 4512 LDAP Models June 2006 + + + This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 + summarizes changes to these sections. The remainder of RFC 2252 is + obsoleted by [RFC4517]. + + This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2. + Appendix A.3 summarizes changes to these sections. The remainder of + RFC 2256 is obsoleted by [RFC4519] and [RFC4517]. + + This document obsoletes RFC 3674 in its entirety. Appendix A.4 + summarizes changes since RFC 3674. + +1.2. Relationship to X.501 + + This document includes material, with and without adaptation, from + [X.501] as necessary to describe this protocol. These adaptations + (and any other differences herein) apply to this protocol, and only + this protocol. + +1.3. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + + Schema definitions are provided using LDAP description formats (as + defined in Section 4.1). Definitions provided here are formatted + (line wrapped) for readability. Matching rules and LDAP syntaxes + referenced in these definitions are specified in [RFC4517]. + +1.4. Common ABNF Productions + + A number of syntaxes in this document are described using Augmented + Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a + number of syntaxes defined in other documents) rely on the following + common productions: + + keystring = leadkeychar *keychar + leadkeychar = ALPHA + keychar = ALPHA / DIGIT / HYPHEN + number = DIGIT / ( LDIGIT 1*DIGIT ) + + ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" + DIGIT = %x30 / LDIGIT ; "0"-"9" + LDIGIT = %x31-39 ; "1"-"9" + HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" + + SP = 1*SPACE ; one or more " " + WSP = 0*SPACE ; zero or more " " + + + +Zeilenga Standards Track [Page 4] + +RFC 4512 LDAP Models June 2006 + + + NULL = %x00 ; null (0) + SPACE = %x20 ; space (" ") + DQUOTE = %x22 ; quote (""") + SHARP = %x23 ; octothorpe (or sharp sign) ("#") + DOLLAR = %x24 ; dollar sign ("$") + SQUOTE = %x27 ; single quote ("'") + LPAREN = %x28 ; left paren ("(") + RPAREN = %x29 ; right paren (")") + PLUS = %x2B ; plus sign ("+") + COMMA = %x2C ; comma (",") + HYPHEN = %x2D ; hyphen ("-") + DOT = %x2E ; period (".") + SEMI = %x3B ; semicolon (";") + LANGLE = %x3C ; left angle bracket ("<") + EQUALS = %x3D ; equals sign ("=") + RANGLE = %x3E ; right angle bracket (">") + ESC = %x5C ; backslash ("\") + USCORE = %x5F ; underscore ("_") + LCURLY = %x7B ; left curly brace "{" + RCURLY = %x7D ; right curly brace "}" + + ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character + UTF8 = UTF1 / UTFMB + UTFMB = UTF2 / UTF3 / UTF4 + UTF0 = %x80-BF + UTF1 = %x00-7F + UTF2 = %xC2-DF UTF0 + UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / + %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) + UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / + %xF4 %x80-8F 2(UTF0) + + OCTET = %x00-FF ; Any octet (8-bit data unit) + + Object identifiers (OIDs) [X.680] are represented in LDAP using a + dot-decimal format conforming to the ABNF: + + numericoid = number 1*( DOT number ) + + Short names, also known as descriptors, are used as more readable + aliases for object identifiers. Short names are case insensitive and + conform to the ABNF: + + descr = keystring + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4512 LDAP Models June 2006 + + + Where either an object identifier or a short name may be specified, + the following production is used: + + oid = descr / numericoid + + While the form is generally preferred when the usage is + restricted to short names referring to object identifiers that + identify like kinds of objects (e.g., attribute type descriptions, + matching rule descriptions, object class descriptions), the + form should be used when the object identifiers may + identify multiple kinds of objects or when an unambiguous short name + (descriptor) is not available. + + Implementations SHOULD treat short names (descriptors) used in an + ambiguous manner (as discussed above) as unrecognized. + + Short Names (descriptors) are discussed further in Section 6.2. + +2. Model of Directory User Information + + As [X.501] states: + + The purpose of the Directory is to hold, and provide access to, + information about objects of interest (objects) in some 'world'. + An object can be anything which is identifiable (can be named). + + An object class is an identified family of objects, or conceivable + objects, which share certain characteristics. Every object + belongs to at least one class. An object class may be a subclass + of other object classes, in which case the members of the former + class, the subclass, are also considered to be members of the + latter classes, the superclasses. There may be subclasses of + subclasses, etc., to an arbitrary depth. + + A directory entry, a named collection of information, is the basic + unit of information held in the Directory. There are multiple kinds + of directory entries. + + An object entry represents a particular object. An alias entry + provides alternative naming. A subentry holds administrative and/or + operational information. + + The set of entries representing the DIB are organized hierarchically + in a tree structure known as the Directory Information Tree (DIT). + + Section 2.1 describes the Directory Information Tree. + Section 2.2 discusses the structure of entries. + Section 2.3 discusses naming of entries. + + + +Zeilenga Standards Track [Page 6] + +RFC 4512 LDAP Models June 2006 + + + Section 2.4 discusses object classes. + Section 2.5 discusses attribute descriptions. + Section 2.6 discusses alias entries. + +2.1. The Directory Information Tree + + As noted above, the DIB is composed of a set of entries organized + hierarchically in a tree structure known as the Directory Information + Tree (DIT); specifically, a tree where vertices are the entries. + + The arcs between vertices define relations between entries. If an + arc exists from X to Y, then the entry at X is the immediate superior + of Y, and Y is the immediate subordinate of X. An entry's superiors + are the entry's immediate superior and its superiors. An entry's + subordinates are all of its immediate subordinates and their + subordinates. + + Similarly, the superior/subordinate relationship between object + entries can be used to derive a relation between the objects they + represent. DIT structure rules can be used to govern relationships + between objects. + + Note: An entry's immediate superior is also known as the entry's + parent, and an entry's immediate subordinate is also known as + the entry's child. Entries that have the same parent are known + as siblings. + +2.2. Structure of an Entry + + An entry consists of a set of attributes that hold information about + the object that the entry represents. Some attributes represent user + information and are called user attributes. Other attributes + represent operational and/or administrative information and are + called operational attributes. + + An attribute is an attribute description (a type and zero or more + options) with one or more associated values. An attribute is often + referred to by its attribute description. For example, the + 'givenName' attribute is the attribute that consists of the attribute + description 'givenName' (the 'givenName' attribute type [RFC4519] and + zero options) and one or more associated values. + + The attribute type governs whether the attribute can have multiple + values, the syntax and matching rules used to construct and compare + values of that attribute, and other functions. Options indicate + subtypes and other functions. + + Attribute values conform to the defined syntax of the attribute type. + + + +Zeilenga Standards Track [Page 7] + +RFC 4512 LDAP Models June 2006 + + + No two values of an attribute may be equivalent. Two values are + considered equivalent if and only if they would match according to + the equality matching rule of the attribute type. Or, if the + attribute type is defined with no equality matching rule, two values + are equivalent if and only if they are identical. (See 2.5.1 for + other restrictions.) + + For example, a 'givenName' attribute can have more than one value, + they must be Directory Strings, and they are case insensitive. A + 'givenName' attribute cannot hold both "John" and "JOHN", as these + are equivalent values per the equality matching rule of the attribute + type. + + Additionally, no attribute is to have a value that is not equivalent + to itself. For example, the 'givenName' attribute cannot have as a + value a directory string that includes the REPLACEMENT CHARACTER + (U+FFFD) code point, as matching involving that directory string is + Undefined per this attribute's equality matching rule. + + When an attribute is used for naming of the entry, one and only one + value of the attribute is used in forming the Relative Distinguished + Name. This value is known as a distinguished value. + +2.3. Naming of Entries + +2.3.1. Relative Distinguished Names + + Each entry is named relative to its immediate superior. This + relative name, known as its Relative Distinguished Name (RDN) + [X.501], is composed of an unordered set of one or more attribute + value assertions (AVA) consisting of an attribute description with + zero options and an attribute value. These AVAs are chosen to match + attribute values (each a distinguished value) of the entry. + + An entry's relative distinguished name must be unique among all + immediate subordinates of the entry's immediate superior (i.e., all + siblings). + + The following are examples of string representations of RDNs + [RFC4514]: + + UID=12345 + OU=Engineering + CN=Kurt Zeilenga+L=Redwood Shores + + The last is an example of a multi-valued RDN; that is, an RDN + composed of multiple AVAs. + + + + +Zeilenga Standards Track [Page 8] + +RFC 4512 LDAP Models June 2006 + + +2.3.2. Distinguished Names + + An entry's fully qualified name, known as its Distinguished Name (DN) + [X.501], is the concatenation of its RDN and its immediate superior's + DN. A Distinguished Name unambiguously refers to an entry in the + tree. The following are examples of string representations of DNs + [RFC4514]: + + UID=nobody@example.com,DC=example,DC=com + CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US + +2.3.3. Alias Names + + An alias, or alias name, is "an name for an object, provided by the + use of alias entries" [X.501]. Alias entries are described in + Section 2.6. + +2.4. Object Classes + + An object class is "an identified family of objects (or conceivable + objects) that share certain characteristics" [X.501]. + + As defined in [X.501]: + + Object classes are used in the Directory for a number of purposes: + + - describing and categorizing objects and the entries that + correspond to these objects; + + - where appropriate, controlling the operation of the Directory; + + - regulating, in conjunction with DIT structure rule + specifications, the position of entries in the DIT; + + - regulating, in conjunction with DIT content rule + specifications, the attributes that are contained in entries; + + - identifying classes of entry that are to be associated with a + particular policy by the appropriate administrative authority. + + An object class (a subclass) may be derived from an object class + (its direct superclass) which is itself derived from an even more + generic object class. For structural object classes, this process + stops at the most generic object class, 'top' (defined in Section + 2.4.1). An ordered set of superclasses up to the most superior + object class of an object class is its superclass chain. + + + + + +Zeilenga Standards Track [Page 9] + +RFC 4512 LDAP Models June 2006 + + + An object class may be derived from two or more direct + superclasses (superclasses not part of the same superclass chain). + This feature of subclassing is termed multiple inheritance. + + Each object class identifies the set of attributes required to be + present in entries belonging to the class and the set of attributes + allowed to be present in entries belonging to the class. As an entry + of a class must meet the requirements of each class it belongs to, it + can be said that an object class inherits the sets of allowed and + required attributes from its superclasses. A subclass can identify + an attribute allowed by its superclass as being required. If an + attribute is a member of both sets, it is required to be present. + + Each object class is defined to be one of three kinds of object + classes: Abstract, Structural, or Auxiliary. + + Each object class is identified by an object identifier (OID) and, + optionally, one or more short names (descriptors). + +2.4.1. Abstract Object Classes + + An abstract object class, as the name implies, provides a base of + characteristics from which other object classes can be defined to + inherit from. An entry cannot belong to an abstract object class + unless it belongs to a structural or auxiliary class that inherits + from that abstract class. + + Abstract object classes cannot derive from structural or auxiliary + object classes. + + All structural object classes derive (directly or indirectly) from + the 'top' abstract object class. Auxiliary object classes do not + necessarily derive from 'top'. + + The following is the object class definition (see Section 4.1.1) for + the 'top' object class: + + ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) + + All entries belong to the 'top' abstract object class. + + + + + + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4512 LDAP Models June 2006 + + +2.4.2. Structural Object Classes + + As stated in [X.501]: + + An object class defined for use in the structural specification of + the DIT is termed a structural object class. Structural object + classes are used in the definition of the structure of the names + of the objects for compliant entries. + + An object or alias entry is characterized by precisely one + structural object class superclass chain which has a single + structural object class as the most subordinate object class. + This structural object class is referred to as the structural + object class of the entry. + + Structural object classes are related to associated entries: + + - an entry conforming to a structural object class shall + represent the real-world object constrained by the object + class; + + - DIT structure rules only refer to structural object classes; + the structural object class of an entry is used to specify the + position of the entry in the DIT; + + - the structural object class of an entry is used, along with an + associated DIT content rule, to control the content of an + entry. + + The structural object class of an entry shall not be changed. + + Each structural object class is a (direct or indirect) subclass of + the 'top' abstract object class. + + Structural object classes cannot subclass auxiliary object classes. + + Each entry is said to belong to its structural object class as well + as all classes in its structural object class's superclass chain. + +2.4.3. Auxiliary Object Classes + + Auxiliary object classes are used to augment the characteristics of + entries. They are commonly used to augment the sets of attributes + required and allowed to be present in an entry. They can be used to + describe entries or classes of entries. + + Auxiliary object classes cannot subclass structural object classes. + + + + +Zeilenga Standards Track [Page 11] + +RFC 4512 LDAP Models June 2006 + + + An entry can belong to any subset of the set of auxiliary object + classes allowed by the DIT content rule associated with the + structural object class of the entry. If no DIT content rule is + associated with the structural object class of the entry, the entry + cannot belong to any auxiliary object class. + + The set of auxiliary object classes that an entry belongs to can + change over time. + +2.5. Attribute Descriptions + + An attribute description is composed of an attribute type (see + Section 2.5.1) and a set of zero or more attribute options (see + Section 2.5.2). + + An attribute description is represented by the ABNF: + + attributedescription = attributetype options + attributetype = oid + options = *( SEMI option ) + option = 1*keychar + + where identifies the attribute type and each