Network Working Group M. Wahl
Request for Comments: 2251 Critical Angle Inc.
Category: Standards Track T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997
Network Working Group M. Wahl
Request for Comments: 2251 Critical Angle Inc.
Category: Standards Track T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997
Lightweight Directory Access Protocol (v3)
轻量级目录访问协议（v3）
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
IESG Note
IESG注释
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
本文档描述了一个目录访问协议，该协议提供读取和更新访问。更新访问需要安全身份验证，但本文档并不要求实现任何令人满意的身份验证机制。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
根据RFC 2026第4.4.1节，IESG批准本规范作为拟定标准，尽管存在此限制，原因如下：
a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and
a. 鼓励在部署这些协议之前实施和互操作性测试（有或没有更新访问），以及
b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and
b. 鼓励在只读应用程序中部署和使用这些协议。（例如，使用LDAPv3作为目录查询语言的应用程序，这些目录由LDAP以外的安全机制更新），以及
c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.
c. 为避免延迟其他Internet标准的推进和部署，跟踪协议需要能够查询但不更新LDAPv3目录服务器。
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
在此警告读者，在强制性身份验证机制标准化之前，根据本规范编写的使用更新功能的客户端和服务器不太可能互操作，或者只有在身份验证降低到不可接受的弱级别时才可能互操作。
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
在此不鼓励实施者部署实现更新功能的LDAPv3客户端或服务器，直到LDAPv3中的强制性身份验证建议标准获得批准并作为RFC发布。
Table of Contents
目录
1. Status of this Memo .................................... 1
Copyright Notice ....................................... 1
IESG Note .............................................. 1
2. Abstract ............................................... 3
3. Models ................................................. 4
3.1. Protocol Model ........................................ 4
3.2. Data Model ............................................ 5
3.2.1. Attributes of Entries ............................... 5
3.2.2. Subschema Entries and Subentries .................... 7
3.3. Relationship to X.500 ................................. 8
3.4. Server-specific Data Requirements ..................... 8
4. Elements of Protocol ................................... 9
4.1. Common Elements ....................................... 9
4.1.1. Message Envelope .................................... 9
4.1.1.1. Message ID ........................................ 11
4.1.2. String Types ........................................ 11
4.1.3. Distinguished Name and Relative Distinguished Name .. 11
4.1.4. Attribute Type ...................................... 12
4.1.5. Attribute Description ............................... 13
4.1.5.1. Binary Option ..................................... 14
4.1.6. Attribute Value ..................................... 14
4.1.7. Attribute Value Assertion ........................... 15
4.1.8. Attribute ........................................... 15
4.1.9. Matching Rule Identifier ............................ 15
4.1.10. Result Message ..................................... 16
4.1.11. Referral ........................................... 18
4.1.12. Controls ........................................... 19
4.2. Bind Operation ........................................ 20
4.2.1. Sequencing of the Bind Request ...................... 21
4.2.2. Authentication and Other Security Services .......... 22
4.2.3. Bind Response ....................................... 23
4.3. Unbind Operation ...................................... 24
4.4. Unsolicited Notification .............................. 24
4.4.1. Notice of Disconnection ............................. 24
4.5. Search Operation ...................................... 25
1. Status of this Memo .................................... 1
Copyright Notice ....................................... 1
IESG Note .............................................. 1
2. Abstract ............................................... 3
3. Models ................................................. 4
3.1. Protocol Model ........................................ 4
3.2. Data Model ............................................ 5
3.2.1. Attributes of Entries ............................... 5
3.2.2. Subschema Entries and Subentries .................... 7
3.3. Relationship to X.500 ................................. 8
3.4. Server-specific Data Requirements ..................... 8
4. Elements of Protocol ................................... 9
4.1. Common Elements ....................................... 9
4.1.1. Message Envelope .................................... 9
4.1.1.1. Message ID ........................................ 11
4.1.2. String Types ........................................ 11
4.1.3. Distinguished Name and Relative Distinguished Name .. 11
4.1.4. Attribute Type ...................................... 12
4.1.5. Attribute Description ............................... 13
4.1.5.1. Binary Option ..................................... 14
4.1.6. Attribute Value ..................................... 14
4.1.7. Attribute Value Assertion ........................... 15
4.1.8. Attribute ........................................... 15
4.1.9. Matching Rule Identifier ............................ 15
4.1.10. Result Message ..................................... 16
4.1.11. Referral ........................................... 18
4.1.12. Controls ........................................... 19
4.2. Bind Operation ........................................ 20
4.2.1. Sequencing of the Bind Request ...................... 21
4.2.2. Authentication and Other Security Services .......... 22
4.2.3. Bind Response ....................................... 23
4.3. Unbind Operation ...................................... 24
4.4. Unsolicited Notification .............................. 24
4.4.1. Notice of Disconnection ............................. 24
4.5. Search Operation ...................................... 25
4.5.1. Search Request ...................................... 25
4.5.2. Search Result ....................................... 29
4.5.3. Continuation References in the Search Result ........ 31
4.5.3.1. Example ........................................... 31
4.6. Modify Operation ...................................... 32
4.7. Add Operation ......................................... 34
4.8. Delete Operation ...................................... 35
4.9. Modify DN Operation ................................... 36
4.10. Compare Operation .................................... 37
4.11. Abandon Operation .................................... 38
4.12. Extended Operation ................................... 38
5. Protocol Element Encodings and Transfer ................ 39
5.1. Mapping Onto BER-based Transport Services ............. 39
5.2. Transfer Protocols .................................... 40
5.2.1. Transmission Control Protocol (TCP) ................. 40
6. Implementation Guidelines .............................. 40
6.1. Server Implementations ................................ 40
6.2. Client Implementations ................................ 40
7. Security Considerations ................................ 41
8. Acknowledgements ....................................... 41
9. Bibliography ........................................... 41
10. Authors' Addresses ..................................... 42
Appendix A - Complete ASN.1 Definition ..................... 44
Full Copyright Statement ................................... 50
4.5.1. Search Request ...................................... 25
4.5.2. Search Result ....................................... 29
4.5.3. Continuation References in the Search Result ........ 31
4.5.3.1. Example ........................................... 31
4.6. Modify Operation ...................................... 32
4.7. Add Operation ......................................... 34
4.8. Delete Operation ...................................... 35
4.9. Modify DN Operation ................................... 36
4.10. Compare Operation .................................... 37
4.11. Abandon Operation .................................... 38
4.12. Extended Operation ................................... 38
5. Protocol Element Encodings and Transfer ................ 39
5.1. Mapping Onto BER-based Transport Services ............. 39
5.2. Transfer Protocols .................................... 40
5.2.1. Transmission Control Protocol (TCP) ................. 40
6. Implementation Guidelines .............................. 40
6.1. Server Implementations ................................ 40
6.2. Client Implementations ................................ 40
7. Security Considerations ................................ 41
8. Acknowledgements ....................................... 41
9. Bibliography ........................................... 41
10. Authors' Addresses ..................................... 42
Appendix A - Complete ASN.1 Definition ..................... 44
Full Copyright Statement ................................... 50
The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. When used with a directory supporting the X.500 protocols, it is intended to be a complement to the X.500 DAP.
本文档中描述的协议旨在提供对支持X.500型号的目录的访问，同时不产生X.500目录访问协议（DAP）的资源需求。此协议专门针对提供对目录的读/写交互访问的管理应用程序和浏览器应用程序。当与支持X.500协议的目录一起使用时，它是对X.500 DAP的补充。
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 RFC 2119 [10].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”和“可”应按照RFC 2119[10]中的说明进行解释。
Key aspects of this version of LDAP are:
此版本LDAP的关键方面包括：
- All protocol elements of LDAPv2 (RFC 1777) are supported. The protocol is carried directly over TCP or other transport, bypassing much of the session/presentation overhead of X.500 DAP.
- 支持LDAPv2（RFC 1777）的所有协议元素。该协议直接通过TCP或其他传输进行传输，绕过了X.500 DAP的大部分会话/表示开销。
- Most protocol data elements can be encoded as ordinary strings (e.g., Distinguished Names).
- 大多数协议数据元素可以编码为普通字符串（例如，可分辨名称）。
- Referrals to other servers may be returned.
- 可能会返回对其他服务器的引用。
- SASL mechanisms may be used with LDAP to provide association security services.
- SASL机制可以与LDAP一起使用，以提供关联安全服务。
- Attribute values and Distinguished Names have been internationalized through the use of the ISO 10646 character set.
- 属性值和可分辨名称已通过使用ISO10646字符集进行国际化。
- The protocol can be extended to support new operations, and controls may be used to extend existing operations.
- 协议可以扩展以支持新的操作，控件可以用于扩展现有操作。
- Schema is published in the directory for use by clients.
- 架构发布在目录中，供客户端使用。
Interest in X.500 [1] directory technologies in the Internet has led to efforts to reduce the high cost of entry associated with use of these technologies. This document continues the efforts to define directory protocol alternatives, updating the LDAP [2] protocol specification.
人们对互联网上X.500[1]目录技术的兴趣促使人们努力降低与使用这些技术相关的高进入成本。本文档继续定义目录协议替代方案，更新LDAP[2]协议规范。
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 the operation(s), the server returns a response containing any results or errors to the requesting client.
该协议采用的通用模型是对服务器执行协议操作的客户端之一。在此模型中，客户机向服务器发送描述要执行的操作的协议请求。然后，服务器负责在目录中执行必要的操作。操作完成后，服务器将向请求客户端返回包含任何结果或错误的响应。
In keeping with the goal of easing the costs associated with use of the directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of using the directory.
为了降低与使用目录相关的成本，本协议的目标是最大限度地降低客户端的复杂性，以促进能够使用目录的应用程序的广泛部署。
Note that 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 may be exchanged between a client and server in any order, provided the client eventually receives a response for every request that requires one.
请注意，尽管在协议中定义响应时要求服务器返回响应，但客户端或服务器不需要同步行为。多个操作的请求和响应可以在客户机和服务器之间以任何顺序交换，前提是客户机最终收到每个请求的响应，而每个请求都需要一个响应。
In LDAP versions 1 and 2, no provision was made for protocol servers returning referrals to clients. However, for improved performance and distribution this version of the protocol permits servers to return to clients referrals to other servers. This allows servers to offload the work of contacting other servers to progress operations.
在LDAP版本1和2中，没有为协议服务器返回对客户端的引用做出任何规定。但是，为了提高性能和分发，此版本的协议允许服务器返回到客户端，并将其转介到其他服务器。这允许服务器卸载联系其他服务器以进行操作的工作。
Note that the core protocol operations defined in this document can be mapped to a strict subset of the X.500(1997) directory abstract service, so it can be cleanly provided by the DAP. However there is not a one-to-one mapping between LDAP protocol operations and DAP operations: server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests.
请注意，本文中定义的核心协议操作可以映射到X.500（1997）目录抽象服务的严格子集，因此DAP可以干净地提供它。但是，LDAP协议操作和DAP操作之间没有一对一的映射：充当X.500目录网关的服务器实现可能需要发出多个DAP请求。
This section provides a brief introduction to the X.500 data model, as used by LDAP.
本节简要介绍LDAP使用的X.500数据模型。
The LDAP protocol assumes there are one or more servers which jointly provide access to a Directory Information Tree (DIT). The tree is made up of entries. Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. The concatenation of the relative distinguished names of the sequence of entries from a particular entry to an immediate subordinate of the root of the tree forms that entry's Distinguished Name (DN), which is unique in the tree. An example of a Distinguished Name is
LDAP协议假定有一个或多个服务器共同提供对目录信息树（DIT）的访问。树由条目组成。条目具有名称：条目中的一个或多个属性值构成其相对可分辨名称（RDN），该名称在其所有同级中必须是唯一的。条目序列的相对可分辨名称从特定条目连接到树根的直接下级，形成该条目的可分辨名称（DN），在树中是唯一的。可分辨名称的一个示例是
CN=Steve Kille, O=Isode Limited, C=GB
CN=Steve Kille, O=Isode Limited, C=GB
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested.
某些服务器可能保存条目的缓存或卷影副本，这些副本可用于回答搜索和比较查询，但如果请求修改操作，则将返回引用或联系其他服务器。
Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
执行缓存或阴影的服务器必须确保它们不会违反原始服务器对数据设置的任何访问控制约束。
The largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries which are mastered by different servers, is termed a naming context. The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context: each server has different attribute values in the root DSE. (DSA is an X.500 term for the directory server).
最大的条目集合称为命名上下文，从特定服务器控制的条目开始，包括其所有下属及其下属，一直到不同服务器控制的条目。DIT的根目录是DSA特定条目（DSE），而不是任何命名上下文的一部分：每个服务器在根目录DSE中具有不同的属性值。（DSA是目录服务器的X.500术语）。
Entries consist of a set of attributes. An attribute is a type with one or more associated values. The attribute type is identified by a short descriptive name and an OID (object identifier). The attribute
条目由一组属性组成。属性是具有一个或多个关联值的类型。属性类型由简短的描述性名称和OID（对象标识符）标识。属性
type governs whether there can be more than one value of an attribute of that type in an entry, the syntax to which the values must conform, the kinds of matching which can be performed on values of that attribute, and other functions.
类型控制条目中该类型的属性是否可以有多个值、值必须符合的语法、可以对该属性的值执行的匹配类型以及其他函数。
An example of an attribute is "mail". There may be one or more values of this attribute, they must be IA5 (ASCII) strings, and they are case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").
属性的一个示例是“邮件”。此属性可能有一个或多个值，它们必须是IA5（ASCII）字符串，并且不区分大小写（例如。“foo@bar.com“将匹配”FOO@BAR.COM").
Schema is the collection of attribute type definitions, object class definitions and other information which a server uses to determine how to match a filter or attribute value assertion (in a compare operation) against the attributes of an entry, and whether to permit add and modify operations. The definition of schema for use with LDAP is given in [5] and [6]. Additional schema elements may be defined in other documents.
模式是属性类型定义、对象类定义和其他信息的集合，服务器使用这些信息来确定如何将筛选器或属性值断言（在比较操作中）与条目的属性相匹配，以及是否允许添加和修改操作。[5]和[6]中给出了用于LDAP的模式定义。其他模式元素可以在其他文档中定义。
Each entry MUST have an objectClass attribute. The objectClass attribute specifies the object classes of an entry, which along with the system and user schema determine the permitted attributes of an entry. Values of this attribute may be modified by clients, but the objectClass attribute cannot be removed. Servers may restrict the modifications of this attribute to prevent the basic structural class of the entry from being changed (e.g. one cannot change a person into a country). When creating an entry or adding an objectClass value to an entry, all superclasses of the named classes are implicitly added as well if not already present, and the client must supply values for any mandatory attributes of new superclasses.
每个条目必须具有objectClass属性。objectClass属性指定条目的对象类，这些对象类与系统和用户架构一起确定条目的允许属性。客户端可以修改此属性的值，但不能删除objectClass属性。服务器可能会限制此属性的修改，以防止条目的基本结构类别发生更改（例如，无法将个人更改为国家/地区）。创建条目或向条目添加objectClass值时，命名类的所有超类（如果尚未存在）也将隐式添加，并且客户端必须为新超类的任何强制属性提供值。
Some attributes, termed operational attributes, are used by servers for administering the directory system itself. They are not returned in search results unless explicitly requested by name. Attributes which are not operational, such as "mail", will have their schema and syntax constraints enforced by servers, but servers will generally not make use of their values.
服务器使用一些属性（称为操作属性）来管理目录系统本身。除非通过名称明确请求，否则它们不会在搜索结果中返回。不可操作的属性（如“邮件”）将由服务器强制实施其模式和语法约束，但服务器通常不会使用其值。
Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions, the schema controlling that entry (specified in the subschema - see below), or are operational attributes known to that server and used for administrative purposes. Note that there is a particular objectClass 'extensibleObject' defined in [5] which permits all user attributes to be present in an entry.
服务器不得允许客户端向条目添加属性，除非对象类定义、控制该条目的模式（在子模式中指定-请参见下文）允许这些属性，或者这些属性是该服务器已知并用于管理目的的操作属性。请注意，[5]中定义了一个特定的objectClass“extensibleObject”，它允许所有用户属性出现在条目中。
Entries MAY contain, among others, the following operational attributes, defined in [5]. These attributes are maintained automatically by the server and are not modifiable by clients:
除其他外，条目可能包含[5]中定义的以下操作属性。这些属性由服务器自动维护，客户端不可修改：
- creatorsName: the Distinguished Name of the user who added this entry to the directory.
- creatorsName：将此条目添加到目录的用户的可分辨名称。
- createTimestamp: the time this entry was added to the directory.
- createTimestamp：此条目添加到目录的时间。
- modifiersName: the Distinguished Name of the user who last modified this entry.
- ModifierName：上次修改此条目的用户的可分辨名称。
- modifyTimestamp: the time this entry was last modified.
- modifyTimestamp：上次修改此条目的时间。
- subschemaSubentry: the Distinguished Name of the subschema entry (or subentry) which controls the schema for this entry.
- subschemaSubentry：控制此项的模式的子模式项（或子项）的可分辨名称。
Subschema entries are used for administering information about the directory schema, in particular the object classes and attribute types supported by directory servers. A single subschema entry contains all schema definitions used by entries in a particular part of the directory tree.
子模式条目用于管理有关目录模式的信息，特别是目录服务器支持的对象类和属性类型。单个子模式条目包含目录树特定部分中的条目使用的所有模式定义。
Servers which follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms, and so these subschemas are not ordinary entries. LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. A server which masters entries and permits clients to modify these entries MUST implement and provide access to these subschema entries, so that its clients may discover the attributes and object classes which are permitted to be present. It is strongly recommended that all other servers implement this as well.
遵循X.500（93）模型的服务器应该使用X.500子模式机制实现子模式，因此这些子模式不是普通条目。LDAP客户端不应假定服务器实现X.500子模式的任何其他方面。掌握条目并允许客户端修改这些条目的服务器必须实现并提供对这些子模式条目的访问，以便其客户端可以发现允许存在的属性和对象类。强烈建议所有其他服务器也实现此功能。
The following four attributes MUST be present in all subschema entries:
以下四个属性必须出现在所有子模式条目中：
- cn: this attribute MUST be used to form the RDN of the subschema entry.
- cn：此属性必须用于形成子模式条目的RDN。
- objectClass: the attribute MUST have at least the values "top" and "subschema".
- objectClass：属性必须至少具有值“top”和“subschema”。
- objectClasses: each value of this attribute specifies an object class known to the server.
- objectClasses：此属性的每个值都指定服务器已知的对象类。
- attributeTypes: each value of this attribute specifies an attribute type known to the server.
- AttributeType：此属性的每个值都指定服务器已知的属性类型。
These are defined in [5]. Other attributes MAY be present in subschema entries, to reflect additional supported capabilities.
这些在[5]中定义。子模式条目中可能存在其他属性，以反映其他受支持的功能。
These include matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms and ldapSyntaxes.
其中包括matchingRules、matchingRuleUse、dITStructureRules、dITContentRules、nameForms和LDAPsyntax。
Servers SHOULD provide the attributes createTimestamp and modifyTimestamp in subschema entries, in order to allow clients to maintain their caches of schema information.
服务器应在子模式条目中提供属性createTimestamp和modifyTimestamp，以便允许客户端维护其模式信息缓存。
Clients MUST only retrieve attributes from a subschema entry by requesting a base object search of the entry, where the search filter is "(objectClass=subschema)". (This will allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested.)
客户机只能通过请求对子模式条目进行基本对象搜索来检索子模式条目中的属性，其中搜索筛选器为“（objectClass=subschema）”。（这将允许作为X.500（93）网关的LDAPv3服务器检测正在请求的子条目信息。）
This document 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 ITU 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, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.
本文档根据X.500将LDAP定义为X.500访问机制。提供服务时，LDAP服务器必须按照X.500（1993）系列ITU建议进行操作。但是，LDAP服务器在提供此服务时不需要使用任何X.500协议，例如，只要LDAP接口中未违反LDAP中使用的X.500数据和服务模型，LDAP就可以映射到任何其他目录系统。
An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root.
LDAP服务器必须提供有关自身的信息以及特定于每台服务器的其他信息。这表示为根DSE（DSA特定条目）中的一组属性，根DSE以零长度LDAPDN命名。如果客户端使用筛选器“（objectClass=*）”对根目录执行基本对象搜索，则可以检索这些属性，但它们受访问控制限制。如果客户端从根开始执行子树搜索，则不得包括根DSE。
Servers may allow clients to modify these attributes.
服务器可能允许客户端修改这些属性。
The following attributes of the root DSE are defined in section 5 of [5]. Additional attributes may be defined in other documents.
[5]第5节定义了根DSE的以下属性。其他属性可以在其他文档中定义。
- namingContexts: naming contexts held in the server. Naming contexts are defined in section 17 of X.501 [6].
- 命名上下文：服务器中保存的命名上下文。命名上下文在X.501[6]第17节中定义。
- subschemaSubentry: subschema entries (or subentries) known by this server.
- subschemaSubentry：此服务器已知的子模式条目（或子条目）。
- altServer: alternative servers in case this one is later unavailable.
- altServer：备用服务器，以防此服务器稍后不可用。
- supportedExtension: list of supported extended operations.
- supportedExtension：支持的扩展操作列表。
- supportedControl: list of supported controls.
- supportedControl：受支持控件的列表。
- supportedSASLMechanisms: list of supported SASL security features.
- SupportedSASL机制：支持的SASL安全功能的列表。
- supportedLDAPVersion: LDAP versions implemented by the server.
- supportedLDAPVersion：服务器实现的LDAP版本。
If the server does not master entries and does not know the locations of schema information, the subschemaSubentry attribute is not present in the root DSE. If the server masters directory entries under one or more schema rules, there may be any number of values of the subschemaSubentry attribute in the root DSE.
如果服务器不掌握条目，并且不知道模式信息的位置，则subschemaSubentry属性不存在于根DSE中。如果服务器主控一个或多个架构规则下的目录项，则根DSE中可能有任意数量的subschemaSubentry属性值。
The LDAP protocol is described using Abstract Syntax Notation 1 (ASN.1) [3], and is typically transferred using a subset of ASN.1 Basic Encoding Rules [11]. In order to support future extensions to this protocol, clients and servers MUST ignore elements of SEQUENCE encodings whose tags they do not recognize.
LDAP协议使用抽象语法符号1（ASN.1）[3]进行描述，通常使用ASN.1基本编码规则的子集进行传输[11]。为了支持该协议的未来扩展，客户机和服务器必须忽略它们无法识别其标记的序列编码元素。
Note that unlike X.500, each change to the LDAP protocol other than through the extension mechanisms will have a different version number. A client will indicate the version it supports as part of the bind request, described in section 4.2. If a client has not sent a bind, the server MUST assume that version 3 is supported in the client (since version 2 required that the client bind first).
请注意，与X.500不同的是，除了通过扩展机制之外，对LDAP协议的每次更改都会有不同的版本号。客户机将在绑定请求中指明其支持的版本，如第4.2节所述。如果客户端未发送绑定，服务器必须假定客户端支持版本3（因为版本2要求客户端首先绑定）。
Clients may determine the protocol version a server supports by reading the supportedLDAPVersion attribute from the root DSE. Servers which implement version 3 or later versions MUST provide this attribute. Servers which only implement version 2 may not provide this attribute.
客户端可以通过从根DSE读取supportedLDAPVersion属性来确定服务器支持的协议版本。实现版本3或更高版本的服务器必须提供此属性。仅实现版本2的服务器可能不提供此属性。
This section describes the LDAPMessage envelope PDU (Protocol Data Unit) format, as well as data type definitions which are used in the protocol operations.
本节介绍LDAPMessage信封PDU（协议数据单元）格式，以及协议操作中使用的数据类型定义。
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows:
出于协议交换的目的，所有协议操作都封装在一个公共信封中，即LDAPMessage，其定义如下：
LDAPMessage ::= SEQUENCE {
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 },
controls [0] Controls OPTIONAL }
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 },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
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 message ID and the controls.
LDAPMessage的功能是提供包含所有协议交换所需公共字段的信封。此时，唯一的公共字段是消息ID和控件。
If the server receives a PDU 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 MUST return the notice of disconnection described in section 4.4.1, with resultCode protocolError, and immediately close the connection. In other cases that the server cannot parse the request received by the client, the server MUST return an appropriate response to the request, with the resultCode set to protocolError.
如果服务器从客户端接收到无法识别LDAPMessage SEQUENCE标记的PDU，则无法解析messageID，无法将protocolOp的标记识别为请求，或者发现数据字段的编码结构或长度不正确，然后，服务器必须返回第4.4.1节中描述的断开连接通知以及resultCode协议错误，并立即关闭连接。在服务器无法解析客户端接收的请求的其他情况下，服务器必须返回对请求的适当响应，并将resultCode设置为protocolError。
If the client receives a PDU from the server which cannot be parsed, the client may discard the PDU, or may abruptly close the connection.
如果客户端从服务器接收到无法解析的PDU，则客户端可能会丢弃该PDU，或者可能会突然关闭连接。
The ASN.1 type Controls is defined in section 4.1.12.
ASN.1类型控制在第4.1.12节中定义。
All LDAPMessage envelopes encapsulating responses contain the messageID value of the corresponding request LDAPMessage.
封装响应的所有LDAPMessage信封都包含相应请求LDAPMessage的messageID值。
The message ID of a request MUST have a value different from the values of any other requests outstanding in the LDAP session of which this message is a part.
请求的消息ID的值必须不同于此消息所属的LDAP会话中未完成的任何其他请求的值。
A client MUST NOT send a second request with the same message ID as an earlier request on the same connection if the client has not received the final response from the earlier request. Otherwise the behavior is undefined. Typical clients increment a counter for each request.
如果客户端未收到来自早期请求的最终响应，则客户端不得在同一连接上发送与早期请求具有相同消息ID的第二个请求。否则，行为是未定义的。典型的客户端为每个请求增加一个计数器。
A client MUST NOT reuse the message id of an abandonRequest or of the abandoned operation until it has received a response from the server for another request invoked subsequent to the abandonRequest, as the abandonRequest itself does not have a response.
由于放弃请求本身没有响应，客户端在收到服务器对放弃请求之后调用的另一请求的响应之前，不得重用放弃请求或放弃操作的消息id。
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as OCTET STRING types, the ISO 10646 [13] character set (a superset of Unicode) is used, encoded following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm characters which are the same as ASCII (0x0000 through 0x007F) are represented as that same ASCII character in a single byte. The other byte values are used to form a variable-length encoding of an arbitrary character.
LDAPString是一种符号化的方便方式，用于表示虽然LDAPString类型的字符串编码为八位字符串类型，但使用ISO 10646[13]字符集（Unicode的超集），并按照UTF-8算法进行编码[14]。注意，在UTF-8算法中，与ASCII相同的字符（0x0000到0x007F）在单个字节中表示为相同的ASCII字符。其他字节值用于形成任意字符的可变长度编码。
LDAPString ::= OCTET STRING
LDAPString ::= OCTET STRING
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.
LDAPOID是一种方便的符号，用于指示此字符串的允许值是对象标识符的（UTF-8编码）点十进制表示形式。
LDAPOID ::= OCTET STRING
LDAPOID ::= OCTET STRING
For example,
例如
1.3.6.1.4.1.1466.1.2.3
1.3.6.1.4.1.1466.1.2.3
An LDAPDN and a RelativeLDAPDN are respectively defined to be the representation of a Distinguished Name and a Relative Distinguished Name after encoding according to the specification in [4], such that
LDAPDN和RelativeLDAPDN分别定义为根据[4]中的规范编码后的可分辨名称和相对可分辨名称的表示，以便
<distinguished-name> ::= <name>
<distinguished-name> ::= <name>
<relative-distinguished-name> ::= <name-component>
<relative-distinguished-name> ::= <name-component>
where <name> and <name-component> are as defined in [4].
其中，<name>和<name component>如[4]中所定义。
LDAPDN ::= LDAPString
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
Only Attribute Types can be present in a relative distinguished name component; the options of Attribute Descriptions (next section) MUST NOT be used in specifying distinguished names.
相对可分辨名称组件中只能存在属性类型；属性描述选项（下一节）不得用于指定可分辨名称。
An AttributeType takes on as its value the textual string associated with that AttributeType in its specification.
AttributeType在其规范中采用与该AttributeType关联的文本字符串作为其值。
AttributeType ::= LDAPString
AttributeType ::= LDAPString
Each attribute type has a unique OBJECT IDENTIFIER which has been assigned to it. This identifier may be written as decimal digits with components separated by periods, e.g. "2.5.4.10".
每个属性类型都有一个已分配给它的唯一对象标识符。该标识符可写成十进制数字，其组成部分由句点分隔，例如“2.5.4.10”。
A specification may also assign one or more textual names for an attribute type. These names MUST begin with a letter, and only contain ASCII letters, digit characters and hyphens. They are case insensitive. (These ASCII characters are identical to ISO 10646 characters whose UTF-8 encoding is a single byte between 0x00 and 0x7F.)
规范还可以为属性类型指定一个或多个文本名称。这些名称必须以字母开头，并且仅包含ASCII字母、数字字符和连字符。它们不区分大小写。（这些ASCII字符与ISO 10646字符相同，其UTF-8编码是0x00和0x7F之间的单个字节。）
If the server has a textual name for an attribute type, it MUST use a textual name for attributes returned in search results. The dotted-decimal OBJECT IDENTIFIER is only used if there is no textual name for an attribute type.
如果服务器具有属性类型的文本名称，则必须为搜索结果中返回的属性使用文本名称。只有当属性类型没有文本名称时，才会使用点十进制对象标识符。
Attribute type textual names are non-unique, as two different specifications (neither in standards track RFCs) may choose the same name.
属性类型文本名称是非唯一的，因为两个不同的规范（在标准跟踪RFC中都不是）可以选择相同的名称。
A server which masters or shadows entries SHOULD list all the attribute types it supports in the subschema entries, using the attributeTypes attribute. Servers which support an open-ended set of attributes SHOULD include at least the attributeTypes value for the 'objectClass' attribute. Clients MAY retrieve the attributeTypes value from subschema entries in order to obtain the OBJECT IDENTIFIER and other information associated with attribute types.
主控或隐藏条目的服务器应使用AttributeType属性在子模式条目中列出其支持的所有属性类型。支持开放式属性集的服务器应至少包含“objectClass”属性的AttributeType值。客户端可以从子模式条目中检索AttributeType值，以获取对象标识符和与属性类型相关的其他信息。
Some attribute type names which are used in this version of LDAP are described in [5]. Servers may implement additional attribute types.
[5]中描述了此版本LDAP中使用的一些属性类型名称。服务器可以实现其他属性类型。
An AttributeDescription is a superset of the definition of the AttributeType. It has the same ASN.1 definition, but allows additional options to be specified. They are also case insensitive.
AttributeDescription是AttributeType定义的超集。它具有与ASN.1相同的定义，但允许指定其他选项。它们也不区分大小写。
AttributeDescription ::= LDAPString
AttributeDescription ::= LDAPString
A value of AttributeDescription is based on the following BNF:
AttributeDescription的值基于以下BNF：
<AttributeDescription> ::= <AttributeType> [ ";" <options> ]
<AttributeDescription> ::= <AttributeType> [ ";" <options> ]
<options> ::= <option> | <option> ";" <options>
<options> ::= <option> | <option> ";" <options>
<option> ::= <opt-char> <opt-char>*
<option> ::= <opt-char> <opt-char>*
<opt-char> ::= ASCII-equivalent letters, numbers and hyphen
<opt-char> ::= ASCII-equivalent letters, numbers and hyphen
Examples of valid AttributeDescription:
有效属性描述的示例：
cn userCertificate;binary
cn用户证书；二进制的
One option, "binary", is defined in this document. Additional options may be defined in IETF standards-track and experimental RFCs. Options beginning with "x-" are reserved for private experiments. Any option could be associated with any AttributeType, although not all combinations may be supported by a server.
本文件中定义了一个选项“二进制”。其他选项可在IETF标准跟踪和实验RFC中定义。以“x-”开头的选项保留给私人实验。任何选项都可以与任何AttributeType关联，尽管服务器可能不支持所有组合。
An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. Options present in an AttributeDescription are never mutually exclusive. Implementations MUST generate the <options> list sorted in ascending order, and servers MUST treat any two AttributeDescription with the same AttributeType and options as equivalent. A server will treat an AttributeDescription with any options it does not implement as an unrecognized attribute type.
带有一个或多个选项的AttributeDescription将被视为不带任何选项的属性类型的子类型。AttributeDescription中的选项从来都不是互斥的。实现必须生成按升序排序的<options>列表，服务器必须将具有相同AttributeType和选项的任意两个AttributeDescription视为等效。服务器将使用其未实现的任何选项将AttributeDescription视为无法识别的属性类型。
The data type "AttributeDescriptionList" describes a list of 0 or more attribute types. (A list of zero elements has special significance in the Search request.)
数据类型“AttributeDescriptionList”描述了0个或更多属性类型的列表。（零元素列表在搜索请求中具有特殊意义。）
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
If the "binary" option is present in an AttributeDescription, it overrides any string-based encoding representation defined for that attribute in [5]. Instead the attribute is to be transferred as a binary value encoded using the Basic Encoding Rules [11]. The syntax of the binary value is an ASN.1 data type definition which is referenced by the "SYNTAX" part of the attribute type definition.
如果AttributeDescription中存在“binary”选项，它将覆盖[5]中为该属性定义的任何基于字符串的编码表示。相反，该属性将作为使用基本编码规则编码的二进制值进行传输[11]。二进制值的语法是ASN.1数据类型定义，由属性类型定义的“语法”部分引用。
The presence or absence of the "binary" option only affects the transfer of attribute values in protocol; servers store any particular attribute in a single format. If a client requests that a server return an attribute in the binary format, but the server cannot generate that format, the server MUST treat this attribute type as an unrecognized attribute type. Similarly, clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option.
“二进制”选项的存在或不存在仅影响协议中属性值的传输；服务器以单一格式存储任何特定属性。如果客户端请求服务器以二进制格式返回属性，但服务器无法生成该格式，则服务器必须将此属性类型视为无法识别的属性类型。类似地，如果客户机在没有二进制选项的情况下按名称请求属性，则客户机不能期望服务器返回二进制格式的属性。
This option is intended to be used with attributes whose syntax is a complex ASN.1 data type, and the structure of values of that type is needed by clients. Examples of this kind of syntax are "Certificate" and "CertificateList".
此选项用于语法为复杂ASN.1数据类型的属性，并且客户端需要该类型的值结构。这种语法的例子有“Certificate”和“CertificateList”。
A field of type AttributeValue takes on as its value either a string encoding of a AttributeValue data type, or an OCTET STRING containing an encoded binary value, depending on whether the "binary" option is present in the companion AttributeDescription to this AttributeValue.
AttributeValue类型的字段将AttributeValue数据类型的字符串编码或包含编码二进制值的八位字节字符串作为其值，具体取决于此AttributeValue的伴随AttributeDescription中是否存在“binary”选项。
The definition of string encodings for different syntaxes and types may be found in other documents, and in particular [5].
不同语法和类型的字符串编码定义可以在其他文档中找到，尤其是[5]。
AttributeValue ::= OCTET STRING
AttributeValue ::= OCTET STRING
Note that there is no defined limit on the size of this encoding; thus protocol values may include multi-megabyte attributes (e.g. photographs).
请注意，此编码的大小没有定义的限制；因此，协议值可能包括多兆字节属性（例如照片）。
Attributes may be defined which have arbitrary and non-printable syntax. Implementations MUST NEITHER simply display nor attempt to decode as ASN.1 a value if its syntax is not known. The implementation may attempt to discover the subschema of the source entry, and retrieve the values of attributeTypes from it.
可以定义具有任意和不可打印语法的属性。如果一个值的语法未知，则实现既不能简单地显示也不能尝试将其解码为ASN.1。实现可能会尝试发现源条目的子模式，并从中检索AttributeType的值。
Clients MUST NOT send attribute values in a request which are not valid according to the syntax defined for the attributes.
根据为属性定义的语法，客户端不得在请求中发送无效的属性值。
The AttributeValueAssertion type definition is similar to the one in the X.500 directory standards. It contains an attribute description and a matching rule assertion value suitable for that type.
AttributeValueAssertion类型定义类似于X.500目录标准中的定义。它包含适合该类型的属性描述和匹配规则断言值。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
AssertionValue ::= OCTET STRING
If the "binary" option is present in attributeDesc, this signals to the server that the assertionValue is a binary encoding of the assertion value.
如果attributeDesc中存在“binary”选项，则会向服务器发出信号，表明断言值是断言值的二进制编码。
For all the string-valued user attributes described in [5], the assertion value syntax is the same as the value syntax. Clients may use attribute values as assertion values in compare requests and search filters.
对于[5]中描述的所有字符串值用户属性，断言值语法与值语法相同。客户端可以在比较请求和搜索筛选器中使用属性值作为断言值。
Note however that the assertion syntax may be different from the value syntax for other attributes or for non-equality matching rules. These may have an assertion syntax which contains only part of the value. See section 20.2.1.8 of X.501 [6] for examples.
但是请注意，断言语法可能不同于其他属性或非相等匹配规则的值语法。它们可能具有仅包含部分值的断言语法。示例见X.501[6]第20.2.1.8节。
An attribute consists of a type and one or more values of that type. (Though attributes MUST have at least one value when stored, due to access control restrictions the set may be empty when transferred in protocol. This is described in section 4.5.2, concerning the PartialAttributeList type.)
属性由一个类型和该类型的一个或多个值组成。（虽然属性在存储时必须至少有一个值，但由于访问控制限制，在协议中传输时，该集可能为空。有关PartialAttributeList类型，请参见第4.5.2节。）
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon.
每个属性值在集合中都是不同的（没有重复项）。VAL集合中属性值的顺序未定义且依赖于实现，因此不能依赖。
A matching rule is a means of expressing how a server should compare an AssertionValue received in a search filter with an abstract data value. The matching rule defines the syntax of the assertion value and the process to be performed in the server.
匹配规则是一种表示服务器应如何将搜索筛选器中接收到的断言值与抽象数据值进行比较的方法。匹配规则定义了断言值的语法以及要在服务器中执行的过程。
An X.501(1993) Matching Rule is identified in the LDAP protocol by the printable representation of its OBJECT IDENTIFIER, either as one of the strings given in [5], or as decimal digits with components separated by periods, e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
LDAP协议中的X.501（1993）匹配规则通过其对象标识符的可打印表示来标识，可以是[5]中给出的字符串之一，也可以是由句点分隔的十进制数字，例如“caseIgnoreIA5Match”或“1.3.6.1.4.1.453.33”。
MatchingRuleId ::= LDAPString
MatchingRuleId ::= LDAPString
Servers which support matching rules for use in the extensibleMatch search filter MUST list the matching rules they implement in subschema entries, using the matchingRules attributes. The server SHOULD also list there, using the matchingRuleUse attribute, the attribute types with which each matching rule can be used. More information is given in section 4.4 of [5].
支持在ExtensionMatch搜索筛选器中使用的匹配规则的服务器必须使用matchingRules属性在子模式条目中列出它们实现的匹配规则。服务器还应该使用matchingRuleUse属性在那里列出每个匹配规则可以使用的属性类型。更多信息见[5]第4.4节。
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. In response to various requests servers will return responses containing fields of type LDAPResult to indicate the final status of a protocol operation request.
LDAPResult是此协议中用于将成功或失败指示从服务器返回到客户端的构造。为了响应各种请求，服务器将返回包含LDAPResult类型字段的响应，以指示协议操作请求的最终状态。
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
All the result codes with the exception of success, compareFalse and compareTrue are to be treated as meaning the operation could not be completed in its entirety.
除success、compareFalse和compareTrue外，所有结果代码均被视为意味着操作无法全部完成。
Most of the result codes are based on problem indications from X.511 error data types. Result codes from 16 to 21 indicate an AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem, codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54 indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an UpdateProblem.
大多数结果代码基于X.511错误数据类型的问题指示。结果代码16到21表示AttributeProblem，代码32、33、34和36表示NameProblem，代码48、49和50表示SecurityProblem，代码51到54表示ServiceProblem，代码64到69和71表示UpdateProblem。
If a client receives a result code which is not listed above, it is to be treated as an unknown error condition.
如果客户端收到上面未列出的结果代码，则将其视为未知错误条件。
The errorMessage field of this construct may, at the server's option, be used to return a string containing a textual, human-readable (terminal control and page formatting characters should be avoided) error diagnostic. As this error diagnostic is not standardized,
根据服务器的选择，此构造的errorMessage字段可用于返回包含文本、人类可读（应避免使用终端控件和页面格式字符）错误诊断的字符串。由于此错误诊断未标准化，
implementations MUST NOT rely on the values returned. If the server chooses not to return a textual diagnostic, the errorMessage field of the LDAPResult type MUST contain a zero length string.
实现不能依赖于返回的值。如果服务器选择不返回文本诊断，则LDAPResult类型的errorMessage字段必须包含长度为零的字符串。
For result codes of noSuchObject, aliasProblem, invalidDNSyntax and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the directory that was matched. If no aliases were dereferenced while attempting to locate the entry, this will be a truncated form of the name provided, or if aliases were dereferenced, of the resulting name, as defined in section 12.5 of X.511 [8]. The matchedDN field is to be set to a zero length string with all other result codes.
对于noSuchObject、aliasProblem、invalidDNSyntax和AliasDeReferenceProblem的结果代码，matchedDN字段设置为已匹配目录中最低条目（对象或别名）的名称。如果在尝试查找条目时未取消引用别名，则这将是所提供名称的截断形式，或者如果取消引用别名，则为结果名称的截断形式，如X.511[8]第12.5节所定义。matchedDN字段将与所有其他结果代码一起设置为零长度字符串。
The referral error indicates that the contacted server does not hold the target entry of the request. The referral field is present in an LDAPResult if the LDAPResult.resultCode field value is referral, and absent with all other result codes. It contains a reference to another server (or set of servers) which 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 URL MUST be present in the Referral.
引用错误表示联系的服务器未保存请求的目标条目。如果LDAPResult.resultCode字段值为referral，则在LDAPResult中会出现referral字段，并且与所有其他结果代码一起不存在。它包含对另一台服务器（或一组服务器）的引用，可通过LDAP或其他协议访问该服务器。可以返回转介以响应任何操作请求（取消绑定和放弃没有响应除外）。推荐中必须至少存在一个URL。
The referral is not returned for a singleLevel or wholeSubtree search in which the search scope spans multiple naming contexts, and several different servers would need to be contacted to complete the operation. Instead, continuation references, described in section 4.5.3, are returned.
对于搜索范围跨越多个命名上下文的单级或整体子树搜索，不会返回引用，并且需要联系多个不同的服务器以完成操作。相反，返回第4.5.3节所述的继续引用。
Referral ::= SEQUENCE OF LDAPURL -- one or more
Referral ::= SEQUENCE OF LDAPURL -- one or more
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
If the client wishes to progress the operation, it MUST follow the referral by contacting any one of servers. All the URLs MUST be equally capable of being used to progress the operation. (The mechanisms for how this is achieved by multiple servers are outside the scope of this document.)
如果客户端希望进行操作，则必须通过联系任何一台服务器来遵循引用。所有URL都必须同样能够用于进行操作。（多台服务器如何实现这一点的机制不在本文档的范围内。）
URLs for servers implementing the LDAP protocol are written according to [9]. If an alias was dereferenced, the <dn> part of the URL MUST be present, with the new target object name. If the <dn> part is present, the client MUST use this name in its next request to progress the operation, and if it is not present the client will use the same name as in the original request. Some servers (e.g. participating in distributed indexing) may provide a different filter in a referral for a search operation. If the filter part of the URL
实现LDAP协议的服务器的URL是根据[9]编写的。如果取消引用别名，则URL的<dn>部分必须存在，并带有新的目标对象名称。如果存在<dn>部分，客户端必须在其下一个请求中使用此名称以进行操作，如果不存在，客户端将使用与原始请求中相同的名称。某些服务器（例如，参与分布式索引）可能在搜索操作的引用中提供不同的筛选器。如果筛选器是URL的一部分
is present in an LDAPURL, the client MUST use this filter in its next request to progress this search, and if it is not present the client MUST use the same filter as it used for that search. Other aspects of the new request may be the same or different as the request which generated the referral.
存在于LDAPURL中，客户端必须在其下一个请求中使用此筛选器以进行此搜索，如果不存在此筛选器，则客户端必须使用与该搜索相同的筛选器。新请求的其他方面可能与生成转介的请求相同或不同。
Note that UTF-8 characters appearing in a DN or search filter may not be legal for URLs (e.g. spaces) and MUST be escaped using the % method in RFC 1738 [7].
请注意，DN或搜索筛选器中出现的UTF-8字符对于URL（例如空格）可能不合法，必须使用RFC 1738[7]中的%方法进行转义。
Other kinds of URLs may be returned, so long as the operation could be performed using that protocol.
只要可以使用该协议执行操作，就可以返回其他类型的URL。
A control is a way to specify extension information. Controls which are sent as part of a request apply only to that request and are not saved.
控件是指定扩展信息的一种方式。作为请求的一部分发送的控件仅适用于该请求，不会保存。
Controls ::= SEQUENCE OF Control
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
The controlType field MUST be a UTF-8 encoded dotted-decimal representation of an OBJECT IDENTIFIER which uniquely identifies the control. This prevents conflicts between control names.
controlType字段必须是唯一标识控件的对象标识符的UTF-8编码点十进制表示形式。这可以防止控件名称之间的冲突。
The criticality field is either TRUE or FALSE.
临界值字段为真或假。
If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation.
如果服务器识别控件类型，并且该类型适合于该操作，则服务器将在执行该操作时使用该控件。
If the server does not recognize the control type and the criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
如果服务器无法识别控件类型且“关键性”字段为TRUE，则服务器不得执行该操作，而必须返回resultCode unsupportedCriticalExtension。
If the control is not appropriate for the operation and criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
如果该控件不适用于操作，并且关键性字段为TRUE，则服务器不得执行该操作，而必须返回resultCode unsupportedCriticalExtension。
If the control is unrecognized or inappropriate but the criticality field is FALSE, the server MUST ignore the control.
如果控件无法识别或不适当，但关键性字段为FALSE，则服务器必须忽略该控件。
The controlValue contains any information associated with the control, and its format is defined for the control. The server 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 which is associated with a control of its type.
controlValue包含与控件关联的任何信息，其格式是为控件定义的。服务器必须准备好处理controlValue八位字节字符串的任意内容，包括零字节。只有当不存在与其类型的控件相关联的值信息时，才会缺少该值。
This document does not define any controls. Controls may be defined in other documents. The definition of a control consists of:
本文档未定义任何控件。控制措施可在其他文件中定义。控件的定义包括：
- the OBJECT IDENTIFIER assigned to the control,
- 分配给控件的对象标识符，
- whether the control is always noncritical, always critical, or critical at the client's option,
- 控制是否始终是非关键的、始终是关键的，或者由客户选择是否是关键的，
- the format of the controlValue contents of the control.
- 控件的controlValue内容的格式。
Servers list the controls which they recognize in the supportedControl attribute in the root DSE.
服务器在根DSE的supportedControl属性中列出它们识别的控件。
The function of the Bind Operation is to allow authentication information to be exchanged between the client and server.
绑定操作的功能是允许在客户端和服务器之间交换身份验证信息。
The Bind Request is defined as follows:
绑定请求定义如下：
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
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 }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
Parameters of the Bind Request are:
绑定请求的参数包括：
- version: A version number indicating the version of the protocol to be used in this protocol session. This document describes version 3 of the LDAP protocol. Note that there is no version negotiation, and the client just sets this parameter to the version it desires. If the client requests protocol version 2, a server that supports the version 2 protocol as described in [2] will not return any v3-
- 版本：一个版本号，指示要在此协议会话中使用的协议版本。本文档介绍LDAP协议的版本3。请注意，没有版本协商，客户机只是将此参数设置为所需的版本。如果客户端请求协议版本2，则支持[2]中所述版本2协议的服务器将不会返回任何v3-
specific protocol fields. (Note that not all LDAP servers will support protocol version 2, since they may be unable to generate the attribute syntaxes associated with version 2.)
特定协议字段。（请注意，并非所有LDAP服务器都支持协议版本2，因为它们可能无法生成与版本2关联的属性语法。）
- name: 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, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the LDAPDN in the credentials.
- 名称：客户端希望绑定为的目录对象的名称。为了匿名绑定的目的，当在较低层执行身份验证时，或者当使用SASL凭据和在凭据中包含LDAPDN的机制时，此字段可能采用空值（零长度字符串）。
- authentication: information used to authenticate the name, if any, provided in the Bind Request.
- 身份验证：用于对绑定请求中提供的名称（如果有）进行身份验证的信息。
Upon receipt of a Bind Request, a protocol server will authenticate the requesting client, if necessary. The server will then return a Bind Response to the client indicating the status of the authentication.
在收到绑定请求后，协议服务器将在必要时对请求客户端进行身份验证。然后，服务器将向客户端返回一个绑定响应，指示身份验证的状态。
Authorization is the use of this authentication information when performing operations. Authorization MAY be affected by factors outside of the LDAP Bind request, such as lower layer security services.
授权是在执行操作时使用此身份验证信息。授权可能受到LDAP绑定请求之外的因素的影响，例如较低层的安全服务。
For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times. If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection. Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage bind.
对于某些SASL身份验证机制，客户端可能需要多次调用BindRequest。如果在任何阶段，客户端希望中止绑定过程，它可能会解除绑定，然后断开基础连接。客户端不得在作为多级绑定的一部分发出的两个绑定请求之间调用操作。
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.
客户端可以通过在SaslCredentials的mechanism字段中发送具有不同值的BindRequest或SASL以外的AuthenticationChoice来中止SASL绑定协商。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with authMethodNotSupported as the resultCode. This will allow clients to abort a negotiation if it wishes to try again with the same SASL mechanism.
如果客户端以空字符串形式发送带有sasl机制字段的BindRequest，则服务器必须返回一个BindResponse，其中authMethodNotSupported作为resultCode。这将允许客户端在希望使用相同的SASL机制重试时中止协商。
Unlike LDAP v2, the client need not send a Bind Request in the first PDU of the connection. The client may request any operations and the server MUST treat these as unauthenticated. If the server requires that the client bind before browsing or modifying the directory, the server MAY reject a request other than binding, unbinding or an extended request with the "operationsError" result.
与LDAP v2不同，客户端不需要在连接的第一个PDU中发送绑定请求。客户端可以请求任何操作，服务器必须将这些操作视为未经验证的操作。如果服务器在浏览或修改目录之前要求客户端绑定，则服务器可能会拒绝除绑定、解除绑定或扩展请求以外的请求，并返回“operationsError”结果。
If the client did not bind before sending a request and receives an operationsError, it may then send a Bind Request. If this also fails or the client chooses not to bind on the existing connection, it will close the connection, reopen it and begin again by first sending a PDU with a Bind Request. This will aid in interoperating with servers implementing other versions of LDAP.
如果客户端在发送请求之前未绑定，并且收到operationsError，则可能会发送绑定请求。如果此操作也失败或客户端选择不绑定现有连接，它将关闭连接，重新打开连接，然后通过首先发送带有绑定请求的PDU重新开始。这将有助于与实现其他版本LDAP的服务器进行互操作。
Clients MAY send multiple bind requests on a connection to change their credentials. A subsequent bind process has the effect of abandoning all operations outstanding on the connection. (This simplifies server implementation.) Authentication from earlier binds are subsequently ignored, and so if the bind fails, the connection will be treated as anonymous. If a SASL transfer encryption or integrity mechanism has been negotiated, and that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection.
客户端可以在一个连接上发送多个绑定请求以更改其凭据。后续绑定过程的效果是放弃连接上所有未完成的操作。（这简化了服务器实现。）来自早期绑定的身份验证随后被忽略，因此如果绑定失败，连接将被视为匿名连接。如果已协商SASL传输加密或完整性机制，且该机制不支持将凭据从一个标识更改为另一个标识，则客户端必须改为建立新连接。
The simple authentication option provides minimal authentication facilities, with the contents of the authentication field consisting only of a cleartext password. Note that the use of cleartext passwords is not recommended over open networks when there is no authentication or encryption being performed by a lower layer; see the "Security Considerations" section.
简单身份验证选项提供了最低限度的身份验证功能，身份验证字段的内容仅由明文密码组成。请注意，当较低层未执行身份验证或加密时，不建议在开放网络上使用明文密码；请参阅“安全注意事项”部分。
If no authentication is to be performed, then the simple authentication option MUST be chosen, and the password be of zero length. (This is often done by LDAPv2 clients.) Typically the DN is also of zero length.
如果不执行身份验证，则必须选择简单身份验证选项，并且密码长度为零。（这通常由LDAPv2客户端完成。）通常，DN的长度也为零。
The sasl choice allows for any mechanism defined for use with SASL [12]. The mechanism field contains the name of the mechanism. The credentials field contains the arbitrary data used for authentication, inside an OCTET STRING wrapper. Note that unlike some Internet application protocols where SASL is used, LDAP is not text-based, thus no base64 transformations are performed on the credentials.
sasl选项允许定义用于sasl的任何机制[12]。“机制”字段包含机制的名称。凭据字段包含用于身份验证的任意数据，位于八位字节字符串包装器中。请注意，与使用SASL的某些Internet应用程序协议不同，LDAP不是基于文本的，因此不会对凭据执行base64转换。
If any SASL-based integrity or confidentiality services are enabled, they take effect following the transmission by the server and reception by the client of the final BindResponse with resultCode success.
如果启用了任何基于SASL的完整性或机密性服务，则这些服务将在服务器传输并在客户端接收到resultCode success的最终BindResponse后生效。
The client can request that the server use authentication information from a lower layer protocol by using the SASL EXTERNAL mechanism.
客户端可以使用SASL外部机制请求服务器使用来自较低层协议的身份验证信息。
The Bind Response is defined as follows.
绑定响应的定义如下。
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse consists simply of an indication from the server of he status of the client's request for authentication.
BindResponse只包含服务器对客户端身份验证请求状态的指示。
f the bind was successful, the resultCode will be success, therwise it will be one of:
如果绑定成功，则resultCode将成功，反之，它将是以下之一：
- operationsError: server encountered an internal error,
- operationsError:服务器遇到内部错误，
- protocolError: unrecognized version number or incorrect PDU structure,
- 协议错误：无法识别的版本号或不正确的PDU结构，
- authMethodNotSupported: unrecognized SASL mechanism name,
- authMethodNotSupported:无法识别的SASL机制名称，
- strongAuthRequired: the server requires authentication be performed with a SASL mechanism,
- strongAuthRequired:服务器要求使用SASL机制执行身份验证，
- referral: this server cannot accept this bind and the client should try another,
- 引用：此服务器无法接受此绑定，客户端应尝试另一个绑定，
- saslBindInProgress: the server requires the client to send a new bind request, with the same sasl mechanism, to continue the authentication process,
- saslBindInProgress：服务器要求客户端使用相同的sasl机制发送新的绑定请求，以继续身份验证过程，
- inappropriateAuthentication: the server requires the client which had attempted to bind anonymously or without supplying credentials to provide some form of credentials,
- 不适当的身份验证：服务器要求尝试匿名绑定或未提供凭据的客户端提供某种形式的凭据，
- invalidCredentials: the wrong password was supplied or the SASL credentials could not be processed,
- invalidCredentials:提供了错误的密码或无法处理SASL凭据，
- unavailable: the server is shutting down.
- 不可用：服务器正在关闭。
If the server does not support the client's requested protocol version, it MUST set the resultCode to protocolError.
如果服务器不支持客户端请求的协议版本，则必须将resultCode设置为protocolError。
If the client receives a BindResponse response where the resultCode was protocolError, it MUST close the connection as the server will be unwilling to accept further operations. (This is for compatibility with earlier versions of LDAP, in which the bind was always the first operation, and there was no negotiation.)
如果客户端接收到resultCode为protocolError的BindResponse响应，它必须关闭连接，因为服务器将不愿意接受进一步的操作。（这是为了与早期版本的LDAP兼容，在早期版本中，绑定始终是第一个操作，并且没有协商。）
The serverSaslCreds are 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 password choice, or the SASL mechanism does not require the server to return information to the client, then this field is not to be included in the result.
ServerSASLCLED用作SASL定义的绑定机制的一部分，以允许客户端对与其通信的服务器进行身份验证，或执行“质询-响应”身份验证。如果与密码选项绑定的客户端或SASL机制不要求服务器向客户端返回信息，则结果中不包括此字段。
The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation is defined as follows:
解除绑定操作的功能是终止协议会话。解除绑定操作的定义如下：
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest ::= [APPLICATION 2] NULL
The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded, and may close the connection.
取消绑定操作未定义响应。在传输解除绑定请求时，协议客户端可以假定协议会话终止。在接收到解除绑定的请求时，协议服务器可以假设请求客户端已终止会话，并且所有未完成的请求都可能被丢弃，并且可以关闭连接。
An unsolicited notification is an LDAPMessage sent from the server to the client which 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 connection 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.
未经请求的通知是从服务器发送到客户端的LDAPMessage，它不响应服务器接收到的任何LDAPMessage。它用于表示服务器中或客户端与服务器之间的连接中出现异常情况。通知具有咨询性质，服务器不希望从客户端返回任何响应。
The unsolicited notification is structured as an LDAPMessage in which the messageID is 0 and protocolOp is of the extendedResp form. The responseName field of the ExtendedResponse is present. The LDAPOID value MUST be unique for this notification, and not be used in any other situation.
未经请求的通知被构造为LDAPMessage，其中messageID为0，protocolOp为extendedResp格式。ExtendedResponse的responseName字段存在。LDAPOID值对于此通知必须是唯一的，并且不得在任何其他情况下使用。
One unsolicited notification is defined in this document.
本文件中定义了一个未经请求的通知。
This notification may be used by the server to advise the client that the server is about to close the connection due to an error condition. Note that this notification is NOT a response to an unbind requested by the client: the server MUST follow the procedures of section 4.3. This notification is intended to assist clients in distinguishing between an error condition and a transient network
服务器可能会使用此通知来通知客户端，由于出现错误，服务器即将关闭连接。请注意，此通知不是对客户端请求的解除绑定的响应：服务器必须遵循第4.3节的过程。此通知旨在帮助客户端区分错误条件和瞬态网络
failure. As with a connection close due to network failure, the client MUST NOT assume that any outstanding requests which modified the directory have succeeded or failed.
失败与由于网络故障而关闭的连接一样，客户端不得假定修改目录的任何未完成请求已成功或失败。
The responseName is 1.3.6.1.4.1.1466.20036, the response field is absent, and the resultCode is used to indicate the reason for the disconnection.
响应名称为1.3.6.1.4.1.1466.20036，响应字段不存在，结果代码用于指示断开的原因。
The following resultCode values are to be used in this notification:
此通知中将使用以下resultCode值：
- protocolError: The server has received data from the client in which the LDAPMessage structure could not be parsed.
- protocolError:服务器从无法解析LDAPMessage结构的客户端接收到数据。
- strongAuthRequired: The server has detected that an established underlying security association protecting communication between the client and server has unexpectedly failed or been compromised.
- strongAuthRequired:服务器已检测到保护客户端和服务器之间通信的已建立的基础安全关联意外失败或受到破坏。
- unavailable: This server will stop accepting new connections and operations on all existing connections, and be unavailable for an extended period of time. The client may make use of an alternative server.
- 不可用：此服务器将停止接受所有现有连接上的新连接和操作，并在较长时间内不可用。客户端可以使用备用服务器。
After sending this notice, the server MUST close the connection. After receiving this notice, the client MUST NOT transmit any further on the connection, and may abruptly close the connection.
发送此通知后，服务器必须关闭连接。收到此通知后，客户端不得在连接上进一步传输任何信息，并可能突然关闭连接。
The Search Operation allows a client to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately below a particular entry, or a whole subtree of entries.
搜索操作允许客户端请求由服务器代表其执行搜索。这可用于从单个条目、紧靠特定条目下方的条目或整个条目子树中读取属性。
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),
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 AttributeDescriptionList }
derefAlways（3）}，sizeLimit INTEGER（0..maxInt），timeLimit INTEGER（0..maxInt），typesOnly BOOLEAN，filter filter，attributes AttributeDescriptionList}
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
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,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
Parameters of the Search Request are:
搜索请求的参数包括：
- baseObject: An LDAPDN that is the base object entry relative to which the search is to be performed.
- baseObject：一个LDAPDN，它是要执行搜索的基础对象条目。
- scope: An indicator of the scope of the search to be performed. The semantics of the possible values of this field are identical to the semantics of the scope field in the X.511 Search Operation.
- 范围：要执行的搜索范围的指示器。此字段的可能值的语义与X.511搜索操作中范围字段的语义相同。
- derefAliases: An indicator as to how alias objects (as defined in X.501) are to be handled in searching. The semantics of the possible values of this field are:
- Derfaliases：关于如何在搜索中处理alias对象（如X.501中所定义）的指示器。此字段的可能值的语义为：
neverDerefAliases: do not dereference aliases in searching or in locating the base object of the search;
Neverderefalias：在搜索或定位搜索的基本对象时不要取消引用别名；
derefInSearching: dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search;
解引用搜索：在搜索中解引用基础对象的下属别名，但在定位搜索的基础对象时不解引用别名；
derefFindingBaseObj: dereference aliases in locating the base object of the search, but not when searching subordinates of the base object;
解除引用BaseObj：在定位搜索的基本对象时解除对别名的引用，但在搜索基本对象的从属对象时不解除对别名的引用；
derefAlways: dereference aliases both in searching and in locating the base object of the search.
取消引用别名：在搜索和定位搜索的基本对象时取消引用别名。
- sizelimit: A sizelimit that restricts the maximum number of entries to be returned as a result of the search. A value of 0 in this field indicates that no client-requested sizelimit restrictions are in effect for the search. Servers may enforce a maximum number of entries to return.
- sizelimit：限制搜索结果返回的最大条目数的sizelimit。此字段中的值为0表示没有客户端请求的sizelimit限制对搜索有效。服务器可以强制执行要返回的最大条目数。
- timelimit: A timelimit that restricts the maximum time (in seconds) allowed for a search. A value of 0 in this field indicates that no client-requested timelimit restrictions are in effect for the search.
- 时间限制：限制允许搜索的最长时间（以秒为单位）的时间限制。此字段中的值为0表示客户端请求的时间限制对搜索无效。
- typesOnly: An indicator as to whether search results will contain both attribute types and values, or just attribute types. Setting this field to TRUE causes only attribute types (no values) to be returned. Setting this field to FALSE causes both attribute types and values to be returned.
- typesOnly：关于搜索结果是同时包含属性类型和值，还是仅包含属性类型的指示器。将此字段设置为TRUE将只返回属性类型（无值）。将此字段设置为FALSE会导致返回属性类型和值。
- 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 was explicit.)
“and”、“or”和“not”选项可用于形成过滤器的组合。“和”或“或”选项中必须至少有一个滤芯。其他属性值与搜索范围内条目的单个属性值匹配。（实施者注意：'not'过滤器是隐式标记模块中标记选项的一个示例。在BER中，这被视为标记是显式的。）
A server MUST evaluate filters according to the three-valued logic of X.511(93) section 7.8.1. In summary, a filter is evaluated to either "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.
服务器必须根据X.511（93）第7.8.1节的三值逻辑评估过滤器。总之，过滤器的计算结果为“真”、“假”或“未定义”。如果特定条目的筛选结果为TRUE，则该条目的属性将作为搜索结果的一部分返回（受任何适用的访问控制限制的约束）。如果筛选器的计算结果为FALSE或Undefined，则将忽略该条目进行搜索。
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 otherwise Undefined. A filter of the "or" choice is FALSE if all of 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.
如果集合中的所有筛选器都计算为TRUE，则“and”选项的筛选器为TRUE；如果至少有一个筛选器为FALSE，则为FALSE，否则未定义。如果集合中的所有筛选器都计算为FALSE，则选择“或”的筛选器为FALSE；如果至少有一个筛选器为TRUE，则为TRUE；否则为未定义。如果被否定的筛选器为FALSE，则选择“not”的筛选器为TRUE；如果为TRUE，则为FALSE；如果未定义，则选择“Undefined”。
The present match evaluates to TRUE where there is an attribute or subtype of the specified attribute description present in an entry, and FALSE otherwise (including a presence test with an unrecognized attribute description.)
当条目中存在指定属性描述的属性或子类型时，当前匹配的计算结果为TRUE，否则为FALSE（包括具有无法识别的属性描述的存在性测试）
The extensibleMatch is new in this version of LDAP. If the matchingRule field is absent, the type field MUST be present, and the equality match is performed for that type. If the type field is absent and matchingRule is present, the matchValue is compared against all attributes in an entry which support that matchingRule, and the matchingRule determines the syntax for the assertion value (the filter item evaluates to TRUE if it matches with at least one attribute in the entry, FALSE if it does not match any attribute in the entry, and Undefined if the matchingRule is not recognized or the assertionValue cannot be parsed.) If the type field is present and matchingRule is present, the matchingRule MUST be one permitted for use with that type, otherwise the filter item is undefined. If the dnAttributes field is set to TRUE, the match is applied against all the attributes in an entry's distinguished name as well, and also evaluates to TRUE if there is at least one attribute in the distinguished name for which the filter item evaluates to TRUE. (Editors note: The dnAttributes field is present so that there does not need to be multiple versions of generic matching rules such as for word matching, one to apply to entries and another to apply to entries and dn attributes as well).
extensibleMatch在这个版本的LDAP中是新的。如果不存在matchingRule字段，则类型字段必须存在，并对该类型执行相等匹配。如果类型字段不存在且存在matchingRule，则MatchingValue将与支持该matchingRule的条目中的所有属性进行比较，matchingRule将确定断言值的语法（如果筛选器项与条目中的至少一个属性匹配，则其计算结果为TRUE；如果筛选器项与条目中的任何属性都不匹配，则其计算结果为FALSE；如果无法识别matchingRule或无法解析assertionValue，则其计算结果为Undefined。）如果存在类型字段且存在matchingRule，则matchingRule必须是允许与该类型一起使用的规则，否则筛选器项未定义。如果dnAttributes字段设置为TRUE，则匹配也将应用于条目可分辨名称中的所有属性，如果至少有一个att，则匹配也将计算为TRUE筛选器项计算结果为TRUE的可分辨名称中的属性。（编辑器注意：存在dnAttributes字段，因此不需要有多个版本的通用匹配规则，例如用于单词匹配的规则，一个应用于条目，另一个应用于条目和dn属性）。
A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. If an attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter is not recognized by the server, a matching rule id in the extensibleMatch is not recognized by the server, the assertion value cannot be parsed, or the type of filtering requested is not implemented, then the filter is Undefined. Thus for example if a server did not recognize the attribute type shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
当服务器无法确定断言值是否与条目匹配时，筛选器项的计算结果为未定义。如果服务器无法识别equalityMatch、Substring、GreaterEqual、lessOrEqual、approxMatch或ExtensionMatch筛选器中的属性描述，则服务器无法识别ExtensionMatch中的匹配规则id，无法解析断言值，或者未实现请求的筛选类型，那么过滤器是未定义的。因此，例如，如果服务器无法识别属性类型shoeSize，则过滤器（shoeSize=*）的计算结果将为FALSE，过滤器（shoeSize=12）、（shoeSize>=12）和（shoeSize<=12）的计算结果将为Undefined。
Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, or assertion values cannot be parsed. More details of filter processing are given in section 7.8 of X.511 [8].
如果无法识别属性描述或匹配规则ID，或者无法解析断言值，则服务器不得返回错误。X.511[8]第7.8节给出了滤波器处理的更多细节。
- attributes: A list of the attributes to be returned from each entry which matches the search filter. There are two special values which may be used: an empty list with no attributes, and the attribute description string "*". Both of these signify that all user attributes are to be returned. (The "*" allows the client to request all user attributes in addition to specific operational attributes).
- 属性：从与搜索筛选器匹配的每个条目返回的属性列表。可以使用两个特殊值：没有属性的空列表和属性描述字符串“*”。这两个属性都表示要返回所有用户属性。（除特定操作属性外，“*”允许客户端请求所有用户属性）。
Attributes MUST be named at most once in the list, and are returned at most once in an entry. If there are attribute descriptions in the list which are not recognized, they are ignored by the server.
属性在列表中最多只能命名一次，在条目中最多返回一次。如果列表中存在无法识别的属性描述，则服务器将忽略这些属性描述。
If the client does not want any attributes returned, it can specify a list containing only the attribute with OID "1.1". This OID was chosen arbitrarily and does not correspond to any attribute in use.
如果客户端不希望返回任何属性，则可以指定一个仅包含OID为“1.1”的属性的列表。此OID是任意选择的，与正在使用的任何属性都不对应。
Client implementors should note that even if all user attributes are requested, some attributes of the entry may not be included in search results due to access control or other restrictions. Furthermore, servers will not return operational attributes, such as objectClasses or attributeTypes, unless they are listed by name, since there may be extremely large number of values for certain operational attributes. (A list of operational attributes for use in LDAP is given in [5].)
客户机实现人员应该注意，即使请求了所有用户属性，由于访问控制或其他限制，条目的某些属性可能不会包含在搜索结果中。此外，服务器不会返回操作属性，例如ObjectClass或AttributeType，除非它们按名称列出，因为某些操作属性可能有大量的值。（LDAP中使用的操作属性列表见[5]。）
Note that an X.500 "list"-like operation can be emulated by the client requesting a one-level LDAP search operation with a filter checking for the existence of the objectClass attribute, and that an X.500 "read"-like operation can be emulated by a base object LDAP search operation with the same filter. A server which 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 must provide the same semantics as the X.500 search operation.
请注意，请求一级LDAP搜索操作的客户端可以模拟类似X.500“列表”的操作，并使用筛选器检查objectClass属性的存在性，而使用相同筛选器的基本对象LDAP搜索操作可以模拟类似X.500“读取”的操作。提供X.500网关的服务器不需要使用读取或列表操作，尽管它可以选择这样做，如果选择，则必须提供与X.500搜索操作相同的语义。
The results of the search attempted by the server upon receipt of a Search Request are returned in Search Responses, which are LDAP messages containing either SearchResultEntry, SearchResultReference, ExtendedResponse or SearchResultDone data types.
服务器在收到搜索请求时尝试的搜索结果将在搜索响应中返回，搜索响应是包含SearchResultEntry、SearchResultReference、ExtendedResponse或SearchResultOne数据类型的LDAP消息。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
属性PartialAttributeList}
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the PartialAttributeList may
-- have zero elements (if none of the attributes of that entry
-- were requested, or could be returned), and that the vals set
-- may also have zero elements (if types only was requested, or
-- all values were excluded from the result.)
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the PartialAttributeList may
-- have zero elements (if none of the attributes of that entry
-- were requested, or could be returned), and that the vals set
-- may also have zero elements (if types only was requested, or
-- all values were excluded from the result.)
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone ::= [APPLICATION 5] LDAPResult
Upon receipt of a Search Request, a server will perform the necessary search of the DIT.
在收到搜索请求后，服务器将对DIT执行必要的搜索。
If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. There may be zero or more responses containing SearchResultEntry, one for each entry found during the search. There may also be zero or more responses containing SearchResultReference, one for each area not explored by this server during the search. The SearchResultEntry and SearchResultReference PDUs may come in any order. Following all the SearchResultReference responses and all SearchResultEntry responses to be returned by the server, the server will return a response containing the SearchResultDone, which contains an indication of success, or detailing any errors that have occurred.
如果LDAP会话在面向连接的传输（如TCP）上运行，服务器将在单独的LDAP消息中向客户端返回一系列响应。可能有零个或多个包含SearchResultEntry的响应，搜索期间找到的每个条目对应一个响应。也可能有零个或多个包含SearchResultReference的响应，在搜索过程中，此服务器未搜索的每个区域对应一个响应。SearchResultEntry和SearchResultReference PDU可以以任何顺序出现。在服务器返回所有SearchResultReference响应和所有SearchResultEntry响应之后，服务器将返回一个包含SearchResultOne的响应，其中包含成功指示，或详细说明已发生的任何错误。
Each entry returned in a SearchResultEntry will contain all attributes, complete with associated values if necessary, as specified in the attributes field of the Search Request. Return of attributes is subject to access control and other administrative policy. Some attributes may be returned in binary format (indicated by the AttributeDescription in the response having the binary option present).
SearchResultEntry中返回的每个条目都将包含所有属性，如有必要，还将包含搜索请求的属性字段中指定的相关值。属性的返回受访问控制和其他管理策略的约束。某些属性可能以二进制格式返回（由存在二进制选项的响应中的AttributeDescription指示）。
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 MUST NOT assume that all attributes can be modified, even if permitted by access control.
有些属性可能由服务器构造并显示在SearchResultEntry属性列表中，尽管它们不是条目的存储属性。即使访问控制允许，客户端也不能假定所有属性都可以修改。
LDAPMessage responses of the ExtendedResponse form are reserved for returning information associated with a control requested by the client. These may be defined in future versions of this document.
ExtendedResponse表单的LDAPMessage响应保留用于返回与客户端请求的控件相关联的信息。这些可能在本文件的未来版本中定义。
If the server was able to locate the entry referred to by the baseObject but was unable to search all the entries in the scope at and under the baseObject, the server may return one or more SearchResultReference, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference if it has not located the baseObject and thus has not searched any entries; in this case it would return a SearchResultDone containing a referral resultCode.
如果服务器能够找到baseObject引用的条目，但无法搜索baseObject上和下作用域中的所有条目，则服务器可能会返回一个或多个SearchResultReference，每个都包含对另一组服务器的引用，以便继续操作。如果服务器未找到baseObject，因此未搜索任何条目，则不得返回任何SearchResultReference；在这种情况下，它将返回一个包含引用结果代码的SearchResultOne。
In the absence of indexing information provided to a server from servers holding subordinate naming contexts, SearchResultReference responses are not affected by search filters and are always returned when in scope.
如果没有从持有从属命名上下文的服务器向服务器提供索引信息，则SearchResultReference响应不受搜索筛选器的影响，并且始终在范围内返回。
The SearchResultReference is of the same data type as the Referral. URLs for servers implementing the LDAP protocol are written according to [9]. The <dn> part MUST be present in the URL, with the new target object name. The client MUST use this name in its next request. Some servers (e.g. part of a distributed index exchange system) may provide a different filter in the URLs of the SearchResultReference. If the filter part of the URL is present in an LDAP URL, the client MUST use the new filter in its next request to progress the search, and if the filter part is absent the client will use again the same filter. Other aspects of the new search request may be the same or different as the search which generated the continuation references.
SearchResultReference与引用的数据类型相同。实现LDAP协议的服务器的URL是根据[9]编写的。<dn>部分必须以新的目标对象名称出现在URL中。客户端必须在其下一个请求中使用此名称。某些服务器（例如，分布式索引交换系统的一部分）可能在SearchResultReference的URL中提供不同的过滤器。如果URL的筛选器部分存在于LDAP URL中，则客户端必须在其下一个请求中使用新筛选器来进行搜索，如果缺少筛选器部分，则客户端将再次使用相同的筛选器。新搜索请求的其他方面可能与生成延续引用的搜索相同或不同。
Other kinds of URLs may be returned so long as the operation could be performed using that protocol.
只要可以使用该协议执行操作，就可以返回其他类型的URL。
The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
SearchResultReference中未探索子树的名称不必从属于基对象。
In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Note that the abandon operation described in section 4.11 applies only to a particular operation sent on a connection between a client and server, and if the client has multiple outstanding search operations to different servers, it MUST abandon each operation individually.
为了完成搜索，客户端必须为返回的每个SearchResultReference发出新的搜索操作。请注意，第4.11节中描述的放弃操作仅适用于在客户端和服务器之间的连接上发送的特定操作，如果客户端对不同服务器有多个未完成的搜索操作，则必须单独放弃每个操作。
For example, suppose the contacted server (hosta) holds the entry
"O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
either LDAP-capable servers (hostb) or (hostc) hold
"OU=People,O=MNN,C=WW" (one is the master and the other server a
For example, suppose the contacted server (hosta) holds the entry
"O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
either LDAP-capable servers (hostb) or (hostc) hold
"OU=People,O=MNN,C=WW" (one is the master and the other server a
shadow), and that LDAP-capable server (hostd) holds the subtree "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is requested to the contacted server, it may return the following:
支持LDAP的服务器（hostd）拥有子树“OU=Roles，O=MNN，C=WW”。如果向联系的服务器请求“O=MNN，C=WW”的子树搜索，它可能会返回以下内容：
SearchResultEntry for O=MNN,C=WW
SearchResultEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
SearchResultDone (success)
SearchResultEntry for O=MNN,C=WW
SearchResultEntry for CN=Manager,O=MNN,C=WW
SearchResultReference {
ldap://hostb/OU=People,O=MNN,C=WW
ldap://hostc/OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW
}
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 for the subtree "OU=People,O=MNN,C=WW", the server might respond as follows:
客户机实现者应该注意，当遵循SearchResultReference时，可能会生成额外的SearchResultReference。继续该示例，如果客户端联系服务器（hostb）并对子树“OU=People，O=MNN，C=WW”进行搜索，则服务器可能会做出如下响应：
SearchResultEntry for OU=People,O=MNN,C=WW
SearchResultReference {
ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
}
SearchResultDone (success)
SearchResultEntry for OU=People,O=MNN,C=WW
SearchResultReference {
ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
}
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
}
SearchResultDone (success)
If the contacted server does not hold the base object for the search, then it will return a referral to the client. For example, if the client requests a subtree search of "O=XYZ,C=US" to hosta, the server may return only a SearchResultDone containing a referral.
如果联系的服务器没有保留搜索的基本对象，那么它将返回对客户端的引用。例如，如果客户端向hosta请求“O=XYZ，C=US”的子树搜索，则服务器可能只返回包含引用的SearchResultOne。
SearchResultDone (referral) {
ldap://hostg/
}
SearchResultDone (referral) {
ldap://hostg/
}
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,
modification SEQUENCE OF SEQUENCE {
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Parameters of the Modify Request are:
修改请求的参数包括：
- object: The object to be modified. The value of this field contains the DN of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified.
- 对象：要修改的对象。此字段的值包含要修改的条目的DN。服务器在确定要修改的对象时不会执行任何别名取消引用。
- modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively:
- 修改：要对条目执行的修改列表。整个条目修改列表必须按照其列出的顺序作为单个原子操作执行。虽然个别修改可能会违反目录模式，但在执行整个修改列表后生成的条目必须符合目录模式的要求。每个修改构造中的“操作”字段可能采用的值分别具有以下语义：
add: add values listed to the given attribute, creating the attribute if necessary;
添加：将列出的值添加到给定属性，必要时创建属性；
delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion;
删除：删除给定属性中列出的值，如果没有列出值，或者如果列出要删除的属性的所有当前值，则删除整个属性；
replace: replace all existing values of the given 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 is ignored if the attribute does not exist.
替换：用列出的新值替换给定属性的所有现有值，如果该属性不存在，则创建该属性。如果存在不带值的替换，则会删除整个属性，如果该属性不存在，则会忽略该替换。
The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows:
服务器在收到修改请求后尝试修改的结果将在修改响应中返回，定义如下：
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse ::= [APPLICATION 7] LDAPResult
Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT.
收到修改请求后，服务器将对DIT执行必要的修改。
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. Note that 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. If the connection fails, whether the modification occurred or not is indeterminate.
服务器将向客户端返回单个修改响应，指示DIT修改成功完成或修改失败的原因。注意，由于在修改请求中应用修改列表的原子性要求，如果收到的修改响应指示任何类型的错误，则客户可能期望未执行DIT修改，并且，如果修改响应指示修改操作成功完成，则已执行所有请求的修改。如果连接失败，修改是否发生是不确定的。
The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 4.9 is used to rename an entry.
“修改”操作不能用于从条目中删除其任何可分辨值，这些值构成条目的相对可分辨名称。尝试这样做将导致服务器返回错误notAllowedOnRDN。第4.9节中描述的修改DN操作用于重命名条目。
If an equality match filter has not been defined for an attribute type, clients MUST NOT attempt to delete individual values of that attribute from an entry using the "delete" form of a modification, and MUST instead use the "replace" form.
如果尚未为属性类型定义相等匹配筛选器，则客户端不得尝试使用修改的“删除”形式从条目中删除该属性的单个值，而必须使用“替换”形式。
Note that due to the simplifications made in LDAP, there is not a direct mapping of the modifications in an LDAP ModifyRequest onto the EntryModifications of a DAP ModifyEntry operation, and different implementations 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.
请注意，由于在LDAP中进行了简化，LDAP ModifyRequest中的修改没有直接映射到DAP ModifyEntry操作的EntryModifications，LDAP-DAP网关的不同实现可能会使用不同的方式表示更改。如果成功，操作对条目的最终效果必须相同。
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 }
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Parameters of the Add Request are:
添加请求的参数包括：
- entry: the Distinguished Name of the entry to be added. Note that the server will not dereference any aliases in locating the entry to be added.
- 条目：要添加的条目的可分辨名称。请注意，服务器在查找要添加的条目时不会取消引用任何别名。
- attributes: the list of attributes that make up the content of the entry being added. Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply the createTimestamp or creatorsName attributes, since these will be generated automatically by the server.
- 属性：组成要添加的条目内容的属性列表。客户机必须在此列表中包括可分辨值（构成条目自身RDN的值）、objectClass属性以及列出的对象类的任何强制属性的值。客户端不能提供createTimestamp或CreatorName属性，因为这些属性将由服务器自动生成。
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The parent of the entry to be added MUST exist. For example, if the client attempted to add "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the "C=US" entry did exist, then the server would return the error noSuchObject with the matchedDN field containing "C=US". If the parent entry exists but is not in a naming context held by the server, the server SHOULD return a referral to the server holding the parent entry.
AddRequest的条目字段中指定的条目必须不存在，AddRequest才能成功。要添加的项的父项必须存在。例如，如果客户端试图添加“CN=JS，O=Foo，C=US”，则“O=Foo，C=US”条目不存在，而“C=US”条目确实存在，则服务器将返回错误noSuchObject，其中matchedDN字段包含“C=US”。如果父项存在但不在服务器持有的命名上下文中，则服务器应返回对持有父项的服务器的引用。
Servers implementations SHOULD NOT restrict where entries can be located in the directory. Some servers MAY allow the administrator to restrict the classes of entries which can be added to the directory.
服务器实现不应限制目录中条目的位置。某些服务器可能允许管理员限制可添加到目录中的条目类别。
Upon receipt of an Add Request, a server will attempt to perform the add requested. The result of the add attempt will be returned to the client in the Add Response, defined as follows:
在收到添加请求后，服务器将尝试执行所请求的添加。添加尝试的结果将在添加响应中返回给客户端，定义如下：
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry is present in the directory.
成功响应表示目录中存在新条目。
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
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists of the Distinguished Name of the entry to be deleted. Note that the server will not dereference aliases while resolving the name of the target entry to be removed, and that only leaf entries (those with no subordinate entries) can be deleted with this operation.
删除请求由要删除的条目的可分辨名称组成。请注意，在解析要删除的目标项的名称时，服务器不会取消对别名的引用，并且此操作只能删除叶项（没有从属项的叶项）。
The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows:
服务器在收到删除请求后尝试删除的结果将在删除响应中返回，定义如下：
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested. The result of the delete attempt will be returned to the client in the Delete Response.
收到删除请求后，服务器将尝试执行请求的条目删除。删除尝试的结果将在删除响应中返回给客户端。
The Modify DN Operation allows a client to change the leftmost (least significant) component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory. The Modify DN Request is defined as follows:
Modify DN操作允许客户端更改目录中条目名称的最左边（最不重要）部分，或将条目子树移动到目录中的新位置。修改DN请求定义如下：
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
Parameters of the Modify DN Request are:
修改DN请求的参数为：
- entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries.
- 条目：要更改的条目的可分辨名称。此条目可能有也可能没有从属条目。
- newrdn: the RDN that will form the leftmost component of the new name of the entry.
- newrdn：将形成条目新名称最左侧组件的RDN。
- deleteoldrdn: a boolean parameter that controls whether the old RDN attribute values are to be retained as attributes of the entry, or deleted from the entry.
- deleteoldrdn：一个布尔参数，用于控制旧RDN属性值是保留为条目的属性，还是从条目中删除。
- newSuperior: if present, this is the Distinguished Name of the entry which becomes the immediate superior of the existing entry.
- newSuperior：如果存在，这是成为现有条目直接上级的条目的可分辨名称。
The result of the name change attempted by the server upon receipt of a Modify DN Request is returned in the Modify DN Response, defined as follows:
服务器在收到修改DN请求时尝试更改名称的结果将在修改DN响应中返回，定义如下：
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change. The result of the name change attempt will be returned to the client in the Modify DN Response.
收到ModifyDNRequest后，服务器将尝试执行名称更改。名称更改尝试的结果将在修改DN响应中返回给客户端。
For example, if the entry named in the "entry" parameter was "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the newSuperior parameter was absent, then this operation would
例如，如果“entry”参数中命名的条目是“cn=John Smith，c=US”，newrdn参数是“cn=John Cougar Smith”，并且不存在newSuperior参数，则此操作将失败
attempt to rename the entry to be "cn=John Cougar Smith,c=US". If there was already an entry with that name, the operation would fail with error code entryAlreadyExists.
尝试将条目重命名为“cn=John Cougar Smith，c=US”。如果已存在具有该名称的条目，则操作将失败，错误代码为entryAlreadyExists。
If the deleteoldrdn parameter is TRUE, the values forming the old RDN are deleted from the entry. If the deleteoldrdn parameter is FALSE, the values forming the old RDN will be retained as non-distinguished attribute values of the entry. The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry.
如果deleteoldrdn参数为TRUE，则从条目中删除构成旧RDN的值。如果deleteoldrdn参数为FALSE，则构成旧RDN的值将保留为条目的非可分辨属性值。如果deleteoldrdn参数的设置会导致条目中的架构不一致，则服务器可能不会执行该操作并返回错误代码。
Note that X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs 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.
请注意，X.500限制ModifyDN操作仅影响单个服务器中包含的条目。如果LDAP服务器映射到DAP，则将应用此限制，如果发生此错误，将返回resultCode affectsMultipleDSAs。通常，客户端不能期望能够在服务器之间执行条目和子树的任意移动。
The Compare Operation allows a client to compare an assertion provided with an entry in the directory. The Compare Request is defined as follows:
比较操作允许客户机将提供的断言与目录中的条目进行比较。比较请求定义如下：
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
Parameters of the Compare Request are:
比较请求的参数包括：
- entry: the name of the entry to be compared with.
- 条目：要与之进行比较的条目的名称。
- ava: the assertion with which an attribute in the entry is to be compared.
- ava：要与条目中的属性进行比较的断言。
The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows:
服务器在收到比较请求时尝试的比较结果将在比较响应中返回，定义如下：
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse ::= [APPLICATION 15] LDAPResult
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison. The result of the comparison will be returned to the client in the Compare Response. Note that errors and the result of comparison are all returned in the same construct.
收到比较请求后，服务器将尝试执行请求的比较。比较结果将在比较响应中返回给客户端。请注意，错误和比较结果都在同一构造中返回。
Note that some directory systems may establish access controls which permit the values of certain attributes (such as userPassword) to be compared but not read. In a search result, it may be that an attribute of that type would be returned, but with an empty set of values.
请注意，某些目录系统可能会建立访问控制，允许比较某些属性（如userPassword）的值，但不允许读取。在搜索结果中，可能会返回该类型的属性，但返回的值集为空。
The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows:
放弃操作的功能是允许客户端请求服务器放弃未完成的操作。放弃请求的定义如下：
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID MUST be that of a an operation which was requested earlier in this connection.
MessageID必须是在此连接中先前请求的操作的MessageID。
(The abandon request itself has its own message id. This is distinct from the id of the earlier operation being abandoned.)
（放弃请求本身有自己的消息id。这与被放弃的早期操作的id不同。）
There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identified by the Message ID in the Abandon Request has been 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 MUST NOT send the SearchResponseDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
放弃操作中未定义响应。在传输放弃操作时，客户机可能期望由放弃请求中的消息ID标识的操作已被放弃。如果服务器在发送搜索响应的过程中接收到搜索操作的放弃请求，则该服务器必须立即停止发送放弃请求的条目响应，并且不得发送SearchResponseOne。当然，服务器必须确保仅传输正确编码的LDAPMessage PDU。
Clients MUST NOT send abandon requests for the same operation multiple times, and MUST also be prepared to receive results from operations it has abandoned (since these may have been in transit when the abandon was requested).
客户端不得多次发送同一操作的放弃请求，还必须准备接收其放弃的操作的结果（因为请求放弃时这些操作可能正在传输中）。
Servers MUST discard abandon requests for message IDs they do not recognize, for operations which cannot be abandoned, and for operations which have already been abandoned.
对于无法识别的消息ID、无法放弃的操作以及已经放弃的操作，服务器必须放弃放弃请求。
An extension mechanism has been added in this version of LDAP, in order to allow additional operations to be defined for services not available elsewhere in this protocol, for instance digitally signed operations and results.
此版本的LDAP中添加了扩展机制，以便允许为本协议其他地方不可用的服务定义其他操作，例如数字签名操作和结果。
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 request MUST have a unique OBJECT IDENTIFIER assigned to it.
扩展操作允许客户端使用预定义的语法和语义发出请求和接收响应。这些可以在RFC中定义，也可以是特定实现的专用。每个请求必须分配一个唯一的对象标识符。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
requestName是对应于请求的对象标识符的点十进制表示形式。requestValue是由该请求定义的形式的信息，封装在八位字节字符串中。
The server will respond to this with an LDAPMessage containing the ExtendedResponse.
服务器将使用包含ExtendedResponse的LDAPMessage对此进行响应。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code.
如果服务器无法识别请求名称，则必须仅返回LDAPResult中的响应字段，其中包含protocolError结果代码。
One underlying service is defined here. Clients and servers SHOULD implement the mapping of LDAP over TCP described in 5.2.1.
这里定义了一个底层服务。客户端和服务器应实现5.2.1中描述的LDAP与TCP的映射。
The protocol elements of LDAP are encoded for exchange using the Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the high overhead involved in using certain elements of the BER, the following additional restrictions are placed on BER-encodings of LDAP protocol elements:
LDAP的协议元素使用ASN.1[3]的基本编码规则（BER）[11]进行编码以进行交换。但是，由于使用BER的某些元素会带来很高的开销，因此对LDAP协议元素的BER编码有以下附加限制：
(1) Only the definite form of length encoding will be used.
(1) 仅使用长度编码的确定形式。
(2) OCTET STRING values will be encoded in the primitive form only.
(2) 八位字节字符串值将仅以原语形式编码。
(3) If the value of a BOOLEAN type is true, the encoding MUST have its contents octets set to hex "FF".
(3) 如果布尔类型的值为true，则编码必须将其内容八位字节设置为hex“FF”。
(4) If a value of a type is its default value, it MUST be absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition.
(4) 如果某个类型的值是其默认值，则该值必须不存在。在此协议定义中，只有某些布尔和整数类型具有默认值。
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise noted.
除非另有说明，否则这些限制不适用于封装在八位字节字符串值（如属性值）内的ASN.1类型。
This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream.
该协议设计用于在面向连接的可靠传输上运行，八位字节中的所有8位在数据流中都是重要的。
The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It is recommended that server implementations running over the TCP MAY provide a protocol listener on the assigned port, 389. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
LDAPMessage PDU直接映射到TCP ByTestStream。建议通过TCP运行的服务器实现可以在分配的端口389上提供协议侦听器。服务器可以在不同的端口号上提供侦听器。客户端必须支持在任何有效的TCP端口上联系服务器。
This document describes an Internet protocol.
本文档描述了一种Internet协议。
The server MUST be capable of recognizing all the mandatory attribute type names and implement the syntaxes specified in [5]. Servers MAY also recognize additional attribute type names.
服务器必须能够识别所有必需的属性类型名称，并实现[5]中指定的语法。服务器还可以识别其他属性类型名称。
Clients which request 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 target entry name, scope and filter. Some clients may be using a counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle a DIT with at least ten layers of naming contexts between the root and a leaf entry.
请求转介的客户端必须确保它们不会在服务器之间循环。对于具有相同目标条目名称、作用域和筛选器的相同请求，他们不得重复联系同一服务器。某些客户端可能正在使用一个计数器，该计数器在每次操作的引用处理发生时递增，并且这些类型的客户端必须能够处理根和叶条目之间至少有十层命名上下文的DIT。
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schemas beyond those referenced in section 6.1. Different schemas can have different attribute types with the same names. The client can retrieve the subschema entries referenced by the subschemaSubentry attribute in the server's root DSE or in entries held by the server.
在没有事先与服务器达成协议的情况下，客户机不应假定服务器支持第6.1节所述模式以外的任何特定模式。不同的模式可以具有具有相同名称的不同属性类型。客户机可以在服务器的根DSE中或在服务器持有的条目中检索subschemaSubentry属性引用的子模式条目。
When used with a connection-oriented transport, this version of the protocol provides facilities for the LDAP v2 authentication mechanism, simple authentication using a cleartext password, as well as any SASL mechanism [12]. SASL allows for integrity and privacy services to be negotiated.
当与面向连接的传输一起使用时，此版本的协议为LDAP v2身份验证机制、使用明文密码的简单身份验证以及任何SASL机制提供了便利[12]。SASL允许协商完整性和隐私服务。
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
还允许服务器将其凭据返回给客户端（如果它选择这样做的话）。
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.
如果基础传输服务无法保证机密性，并且可能导致密码泄露给未经授权的方，则强烈建议不要使用明文密码。
When used with SASL, it should be noted that the name field of the BindRequest is not protected against modification. Thus if the distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field.
当与SASL一起使用时，应该注意，BindRequest的name字段不受修改的保护。因此，如果客户机的可分辨名称（LDAPDN）通过凭据协商获得同意，则它优先于未保护名称字段中的任何值。
Implementations which 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 which 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 cache.
缓存通过LDAP获得的属性和条目的实现必须确保，如果要将该信息提供给多个客户端，则必须维护访问控制，因为服务器可能具有访问控制策略，这些策略可防止搜索结果中的条目或属性返回到特定的经过身份验证的客户端。例如，缓存只能将结果信息提供给其请求导致其成为缓存的客户端。
This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes, and Steve Kille. Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged.
本文档是由杨文杰、蒂姆·豪斯和史蒂夫·基尔对RFC1777的更新。本文件中包含的设计思想基于ASID和其他IETF工作组中讨论的设计思想。我们衷心感谢这些工作组中的个人所作的贡献。
[1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.
[1] ITU-T Rec.X.500，“目录：概念、模型和服务概述”，1993年。
[2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[2] Yeong，W.，Howes，T.，和S.Kille，“轻量级目录访问协议”，RFC17771995年3月。
[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994.
[3] ITU-T Rec.X.680，“抽象语法符号一（ASN.1）-基本符号规范”，1994年。
[4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[4] Kille，S.，Wahl，M.，和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
[5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[5] Wahl，M.，Coulbeck，A.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[6] ITU-T Rec. X.501, "The Directory: Models", 1993.
[6] ITU-T Rec.X.501，“目录：模型”，1993年。
[7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[7] Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[8] ITU-T Rec.X.511，“目录：抽象服务定义”，1993年。
[9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[9] Howes，T.和M.Smith，“LDAP URL格式”，RFC2255，1997年12月。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[10] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994.
[11] ITU-T Rec.X.690，“ASN.1编码规则规范：基本、规范和区分编码规则”，1994年。
[12] Meyers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.
[12] Meyers，J.，“简单认证和安全层”，RFC2222，1997年10月。
[13] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
[13] 通用多八位编码字符集（UCS）.体系结构和基本多语言平面，ISO/IEC 10646-1:1993。
[14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[14] “UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
马克·沃尔临界角公司，美国德克萨斯州奥斯汀市布雷克巷西4815号，502-385号，邮编78759
Phone: +1 512 372-3160
EMail: M.Wahl@critical-angle.com
Phone: +1 512 372-3160
EMail: M.Wahl@critical-angle.com
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd., MS MV068 Mountain View, CA 94043 USA
蒂姆·豪斯·网景通信公司，美国加利福尼亚州山景城MV068东米德菲尔德路501号，邮编94043
Phone: +1 650 937-3419
EMail: howes@netscape.com
Phone: +1 650 937-3419
EMail: howes@netscape.com
Steve Kille Isode Limited The Dome, The Square Richmond TW9 1DT UK
Steve Kille Isode有限公司位于英国里士满TW9 1DT广场的穹顶
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
Appendix A - Complete ASN.1 Definition
附录A-完整的ASN.1定义
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::=
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::=
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 },
controls [0] Controls OPTIONAL }
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 },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
LDAPString ::= OCTET STRING
LDAPString ::= OCTET STRING
LDAPOID ::= OCTET STRING
LDAPOID ::= OCTET STRING
LDAPDN ::= LDAPString
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
AttributeType ::= LDAPString
AttributeType ::= LDAPString
AttributeDescription ::= LDAPString
AttributeDescription ::= LDAPString
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
AttributeValue ::= OCTET STRING
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
AssertionValue ::= OCTET STRING
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
MatchingRuleId ::= LDAPString
MatchingRuleId ::= LDAPString
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
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),
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongAuthRequired (8),
-- 9 reserved --
referral (10), -- new
adminLimitExceeded (11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress (14), -- new
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
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), -- new
-- 72-79 unused --
other (80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
Referral ::= SEQUENCE OF LDAPURL
Referral ::= SEQUENCE OF LDAPURL
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
Controls ::= SEQUENCE OF Control
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
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 }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult, serverSaslCreds [7] OCTET STRING OPTIONAL }
LDAPResult、serversaslcleds[7]八进制字符串的组件可选}
UnbindRequest ::= [APPLICATION 2] NULL
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 AttributeDescriptionList }
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 AttributeDescriptionList }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
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,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
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 }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone ::= [APPLICATION 5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse ::= [APPLICATION 7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse ::= [APPLICATION 9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest ::= [APPLICATION 10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
END
终止
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。