Lightweight Directory Access Protocol (LDAP 轻量级目录访问协议)

abka

已于 2023-12-13 18:24:19 修改

阅读量1.1k

点赞数 22

分类专栏：名词解释文章标签： ldap

于 2023-12-13 18:23:26 首次发布

本文链接：https://blog.csdn.net/asdcls/article/details/134966415

版权

名词解释专栏收录该内容

4 篇文章 0 订阅

订阅专栏

The Lightweight Directory Access Protocol (LDAP /ˈɛldæp/) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.[1] Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network.[2] As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

轻量级目录访问协议 （LDAP /ˈɛldæp/）是一种开放的、供应商中立的行业标准应用程序协议，用于通过 Internet 协议（IP）网络访问和维护分布式目录信息服务。[1] 目录服务允许在整个网络中共享有关用户、系统、网络、服务和应用程序的信息，从而在开发 Intranet 和 Internet 应用程序方面发挥着重要作用。[2] 例如，目录服务可以提供任何有组织的记录集，通常具有层次结构，例如公司电子邮件目录。同样，电话簿是带有地址和电话号码的订户列表。

LDAP is specified in a series of Internet Engineering Task Force (IETF) Standard Track publications called Request for Comments (RFCs), using the description language ASN.1. The latest specification is Version 3, published as RFC 4511 [3] (a road map to the technical specifications is provided by RFC4510).

LDAP 在一系列称为“征求意见稿（RFC）”的 Internet 工程任务组（IETF）标准跟踪出版物中指定，使用描述语言 ASN.1。最新的规范是第3版，以RFC 4511 [3]的形式发布（技术规范的路线图由RFC4510提供）。

A common use of LDAP is to provide a central place to store usernames and passwords. This allows many different applications and services to connect to the LDAP server to validate users.[4]

LDAP 的一个常见用途是提供一个中心位置来存储用户名和密码。这允许许多不同的应用程序和服务连接到LDAP服务器以验证用户。[4]

LDAP is based on a simpler subset of the standards contained within the X.500 standard. Because of this relationship, LDAP is sometimes called X.500-lite.[5]

LDAP 基于 X.500 标准中包含的更简单的标准子集。由于这种关系，LDAP 有时被称为 X.500-lite。[5]

History

Telecommunication companies' understanding of directory requirements were well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification,[6] a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.

历史

电信公司在制作和管理电话簿约70年后，对目录要求的理解得到了很好的发展。这些公司将目录服务的概念引入信息技术和计算机网络，他们的投入最终形成了全面的X.500规范，[6]这是国际电信联盟（ITU）在1980年代制定的一套协议。

X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.

传统上，X.500 目录服务是通过 X.500 目录访问协议（DAP）访问的，这需要开放系统互连（OSI）协议栈。LDAP 最初旨在成为一种轻量级的替代协议，用于通过更简单（现在广泛使用）的 TCP/IP 协议栈访问 X.500 目录服务。这种目录访问模型是从 DIXIE 和目录辅助服务协议中借来的。

The protocol was originally created[7] by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of Performance Systems International, circa 1993, as a successor[8] to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the IETF.

该协议最初由密歇根大学的 Tim Howes、Isode Limited 的 Steve Kille、Nexor 的 Colin Robbins 和 Performance Systems International 的 Wengyik Yeong 于 1993 年左右创建[7]，作为 DIXIE 和 DAS 的继任者[8].Critical Angle Inc. 的 Mark Wahl、Tim Howes 和 Steve Kille 于 1996 年开始在互联网工程任务组（IETF）的支持下开发新版本的 LDAP，即 LDAPv3。LDAPv3 于 1997 年首次发布，取代了 LDAPv2，增加了对可扩展性的支持，集成了简单身份验证和安全层，并更好地将协议与 1993 年版的 X.500 保持一致。LDAPv3 规范本身的进一步发展以及向 LDAPv3 添加功能的众多扩展已通过 IETF 实现。

In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the Internet due to its relatively modest bandwidth usage.

在LDAP的早期工程阶段，它被称为轻量级目录浏览协议（LDBP）。随着协议范围的扩展，它已重命名，超出了目录浏览和搜索的范围，包括目录更新功能。它被命名为轻量级，因为它不像其 DAP 前身那样网络密集，因此由于其带宽使用相对适中，更容易通过 Internet 实现。

LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP). It is also used as the basis for Microsoft's Active Directory.

LDAP 影响了后续的 Internet 协议，包括 X.500 的更高版本、XML 启用目录（XED）、目录服务标记语言（DSML）、服务提供标记语言（SPML）和服务定位协议（SLP）。它也被用作Microsoft Active Directory的基础。

Protocol overview

A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS (LDAP over TLS/SSL, see below).[9] The client then sends an operation request to the server, and a server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER).

协议概述

默认情况下，客户端通过连接到称为目录系统代理（DSA）的 LDAP 服务器来启动 LDAP 会话，该服务器位于 TCP 和 UDP 端口 389 上，或 LDAPS 的端口 636（基于 TLS/SSL 的 LDAP，见下文）。[9] 然后，客户端向服务器发送操作请求，服务器发送响应作为回报。除了一些例外，客户端在发送下一个请求之前不需要等待响应，服务器可以按任何顺序发送响应。所有信息都使用基本编码规则（BER）进行传输。

The client may request the following operations:

StartTLS – use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
Bind – authenticate and specify LDAP protocol version
Search – search for and/or retrieve directory entries
Compare – test if a named entry contains a given attribute value
Add a new entry
Delete an entry
Modify an entry
Modify Distinguished Name (DN) – move or rename an entry
Abandon – abort a previous request
Extended Operation – generic operation used to define other operations
Unbind – close the connection (not the inverse of Bind)

客户端可以请求以下操作：

StartTLS – 使用 LDAPv3 传输层安全性（TLS）扩展实现安全连接
绑定 – 验证并指定 LDAP 协议版本
搜索 – 搜索和/或检索目录条目
比较 – 测试命名条目是否包含给定的属性值
添加新条目
删除条目
修改条目
修改可分辨名称（DN） – 移动或重命名条目
放弃 – 中止之前的请求
扩展操作 – 用于定义其他操作的通用操作
Unbind – 关闭连接（不是 Bind 的逆连接）

In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before the connection is timed out.

此外，服务器可能会发送“未经请求的通知”，这些通知不是对任何请求的响应，例如在连接超时之前。

A common alternative method of securing LDAP communication is using an SSL tunnel. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.[10]

保护 LDAP 通信的常用替代方法是使用 SSL 隧道。LDAP over SSL 的默认端口为 636。LDAP over SSL 的使用在 LDAP 版本 2 （LDAPv2）中很常见，但从未在任何正式规范中标准化。此用法已随 LDAPv2 一起弃用，LDAPv2 已于 2003 年正式停用。[注10]

Directory structure

The protocol provides an interface with directories that follow the 1993 edition of the X.500 model:

An entry consists of a set of attributes.
An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e.g. if were the DN, then would be the RDN)./foo/bar/myfile.txtmyfile.txt

目录结构

该协议提供了一个接口，其中包含遵循 1993 年版 X.500 模型的目录：

条目由一组属性组成。
属性具有名称（属性类型或属性描述）以及一个或多个值。这些属性在架构中定义（见下文）。
每个条目都有一个唯一标识符：其可分辨名称 （DN）。这包括其相对可分辨名称（RDN），该名称由条目中的某些属性构造而成，后跟父条目的 DN。将 DN 视为完整文件路径，将 RDN 视为其父文件夹中的相对文件名（例如，如果是 DN，则为 RDN）。/foo/bar/myfile.txtmyfile.txt

A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.

DN 可能会在条目的生命周期内更改，例如，当条目在树中移动时。为了可靠且明确地标识条目，可以在条目的操作属性集中提供 UUID。

An entry can look like this when represented in LDAP Data Interchange Format (LDIF), a plain text format (as opposed a binary protocol such as LDAP itself):

当以 LDAP 数据交换格式（LDIF）表示时，条目可能如下所示，LDIF（一种纯文本格式，而不是 LDAP 本身等二进制协议）：

 dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1232
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

"dn" is the distinguished name of the entry; it is neither an attribute nor a part of the entry. "" is the entry's RDN (Relative Distinguished Name), and "" is the DN of the parent entry, where "" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "" for common name, "" for domain component, "" for email address, and "" for surname. cn=John Doedc=example,dc=comdccndcmailsn

"dn“是条目的可分辨名称;它既不是属性，也不是条目的一部分。“” 是条目的 RDN（相对可分辨名称），“” 是父条目的 DN，其中 “” 表示“域组件”。其他行显示条目中的属性。属性名称通常是助记符字符串，例如“”表示公用名，“”表示域组件，“”表示电子邮件地址，“”表示姓氏。cn=John Doedc=example,dc=comdccndcmailsn

A server holds a subtree starting from a specific entry, e.g. "" and its children. Servers may also hold references to other servers, so an attempt to access "" could return a referral or continuation reference to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client. dc=example,dc=comou=department,dc=example,dc=com

服务器包含从特定条目开始的子树，例如“”及其子项。服务器还可能包含对其他服务器的引用，因此尝试访问 “” 可能会返回对包含目录树该部分的服务器的引用或延续引用。然后，客户端可以联系其他服务器。某些服务器还支持链接，这意味着服务器会联系其他服务器并将结果返回给客户端。dc=example,dc=comou=department,dc=example,dc=com

LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.

LDAP 很少定义任何排序：服务器可以按任何顺序返回属性的值、条目中的属性以及搜索操作找到的条目。这源于正式定义 - 条目被定义为一组属性，而属性是一组值，并且不需要对集合进行排序。

Operations

Add

The ADD operation inserts a new entry into the directory-server database.[11] If the distinguished name in the add request already exists in the directory, then the server will not add a duplicate entry but will set the result code in the add result to decimal 68, "entryAlreadyExists".[12]

操作

添加

ADD 操作将一个新条目插入到目录服务器数据库中。[11] 如果目录中已经存在添加请求中的可分辨名称，则服务器不会添加重复的条目，而是将添加结果中的结果代码设置为十进制 68，“entryAlreadyExists”。[注12]

LDAP-compliant servers will never dereference the distinguished name transmitted in the add request when attempting to locate the entry, that is, distinguished names are never de-aliased.
LDAP-compliant servers will ensure that the distinguished name and all attributes conform to naming standards.
The entry to be added must not exist, and the immediate superior must exist.

当尝试查找条目时，符合 LDAP 的服务器永远不会取消引用添加请求中传输的可分辨名称，也就是说，永远不会取消可分辨名称的别名。
符合 LDAP 的服务器将确保可分辨名称和所有属性符合命名标准。
要添加的条目不得存在，直属上级必须存在。

dn: uid=user,ou=people,dc=example,dc=com
changetype: add
objectClass:top
objectClass:person
uid: user
sn: last-name
cn: common-name
userPassword: password

In the above example, must not exist, and must exist.

在上面的例子中，必须不存在，并且必须存在。uid=user,ou=people,dc=example,dc=comou=people,dc=example,dc=com

uid=user,ou=people,dc=example,dc=comou=people,dc=example,dc=com

Bind (authenticate)

When an LDAP session is created, that is, when an LDAP client connects to the server, the authentication state of the session is set to anonymous. The BIND operation establishes the authentication state for a session.

绑定（身份验证）

创建LDAP会话时，即LDAP客户端连接到服务器时，会话的身份验证状态 设置为匿名。BIND 操作为会话建立身份验证状态。

Simple BIND and SASL PLAIN can send the user's DN and password in plaintext, so the connections utilizing either Simple or SASL PLAIN should be encrypted using Transport Layer Security (TLS). The server typically checks the password against the attribute in the named entry. Anonymous BIND (with empty DN and password) resets the connection to anonymous state. userPassword

Simple BIND 和 SASL PLAIN 可以明文形式发送用户的 DN 和密码，因此使用 Simple 或 SASL PLAIN 的连接应使用传输层安全性（TLS）进行加密。服务器通常会根据命名条目中的属性检查密码。匿名 BIND（DN 和密码为空）将连接重置为匿名状态。userPassword

SASL (Simple Authentication and Security Layer) BIND provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.[13]

SASL（Simple Authentication and Security Layer）BIND 通过广泛的机制，例如Kerberos或与TLS一起发送的客户端证书。[注13]

BIND also sets the LDAP protocol version by sending a version number in the form of an integer. If the client requests a version that the server does not support, the server must set the result code in the BIND response to the code for a protocol error. Normally clients should use LDAPv3, which is the default in the protocol but not always in LDAP libraries.

BIND 还通过以整数形式发送版本号来设置 LDAP 协议版本。如果客户端请求服务器不支持的版本，则服务器必须将 BIND 响应中的结果代码设置为协议错误的代码。通常，客户端应使用 LDAPv3，即默认值在协议中，但并不总是在 LDAP 库中。

BIND had to be the first operation in a session in LDAPv2, but is not required as of LDAPv3. In LDAPv3, each successful BIND request changes the authentication state of the session and each unsuccessful BIND request resets the authentication state of the session.

BIND 必须是 LDAPv2 会话中的第一个操作，但从 LDAPv3 开始不是必需的。在 LDAPv3 中，每个成功的 BIND 请求会更改会话的身份验证状态，并且每个不成功的 BIND 请求都会重置身份验证状态的会话。

Delete

To delete an entry, an LDAP client transmits a properly formed delete request to the server.[14]

删除

要删除条目，LDAP 客户端会向服务器传输格式正确的删除请求。[注14]

A delete request must contain the distinguished name of the entry to be deleted
Request controls may also be attached to the delete request
Servers do not dereference aliases when processing a delete request
Only leaf entries (entries with no subordinates) may be deleted by a delete request. Some servers support an operational attribute whose value indicates whether an entry has any subordinate entries, and some servers support an operational attribute [15] indicating the number of entries subordinate to the entry containing the attribute.hasSubordinatesnumSubordinatesnumSubordinates
Some servers support the subtree delete request control permitting deletion of the DN and all objects subordinate to the DN, subject to access controls. Delete requests are subject to access controls, that is, whether a connection with a given authentication state will be permitted to delete a given entry is governed by server-specific access control mechanisms.

删除请求必须包含要删除的条目的可分辨名称
请求控件也可以附加到删除请求
服务器在处理删除请求时不会取消引用别名
只有叶条目（没有从属条目的条目）可以通过删除请求删除。一些服务器支持操作属性，其值指示条目是否具有任何从属条目，而某些服务器支持操作属性 [15]，该属性指示从属于包含该属性的条目的条目数。hasSubordinatesnumSubordinatesnumSubordinates
某些服务器支持子树删除请求控制，允许删除 DN 和 DN 从属的所有对象，但受访问控制的约束。删除请求受访问控制的约束，也就是说，是否允许具有给定身份验证状态的连接删除给定条目由特定于服务器的访问控制机制控制。

Search and compare

The Search operation is used to both search for and read entries. Its parameters are:

搜索和比较

搜索操作用于搜索和读取条目。其参数为：

baseObject

The name of the base object entry (or possibly the root) relative to which the search is to be performed.

base对象

要执行搜索的基对象条目（也可能是根）的名称。

scope

What elements below the baseObject to search. This can be (search just the named entry, typically used to read one entry), (entries immediately below the base DN), or (the entire subtree starting at the base DN).BaseObjectsingleLevelwholeSubtree

范围

要搜索 baseObject 下的哪些元素。这可以是（仅搜索命名条目，通常用于读取一个条目）、（紧挨着基本 DN 的条目）或（从基本 DN 开始的整个子树）。BaseObjectsingleLevelwholeSubtree

filter

Criteria to use in selecting elements within scope. For example, the filter will select "persons" (elements of objectClass ) where the matching rules for and determine whether the values for those attributes match the filter assertion. Note that a common misconception is that LDAP data is case-sensitive, whereas in fact matching rules and ordering rules determine matching, comparisons, and relative value relationships. If the example filters were required to match the case of the attribute value, an extensible match filter must be used, for example, (&(objectClass=person)(|(givenName=John)(mail=john*)))persongivenNamemail(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

滤波器

在选择范围内的元素时要使用的标准。例如，过滤器将选择“persons”（objectClass 的元素）其中的匹配规则，并确定这些属性的值是否与过滤器断言匹配。请注意，一个常见的误解是 LDAP 数据区分大小写，而实际上匹配规则和排序规则决定了匹配、比较和相对值关系。如果需要示例筛选器来匹配属性值的大小写，则必须使用可扩展的匹配筛选器，例如：(&(objectClass=person)(|(givenName=John)(mail=john*)))persongivenNamemail(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))

derefAliases

Whether and how to follow alias entries (entries that refer to other entries),

deref别名

是否以及如何关注别名条目（引用其他条目的条目），

attributes

Which attributes to return in result entries.

属性

要在结果条目中返回的属性。

sizeLimit, timeLimit

Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit.

sizeLimit、timeLimit

要返回的最大条目数，以及允许运行搜索的最长时间。但是，这些值不能覆盖服务器对大小限制和时间限制施加的任何限制。

typesOnly

Return attribute types only, not attribute values.

仅类型

仅返回属性类型，而不返回属性值。

The server returns the matching entries and potentially continuation references. These may be returned in any order. The final result will include the result code.

The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.

服务器返回匹配的条目和可能的延续引用。这些可以按任何顺序返回。最终结果将包括结果代码。

比较操作采用 DN、属性名称和属性值，并检查命名条目是否包含具有该值的属性。

Modify

The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries.[16] Attempts to modify entries that do not exist will fail. MODIFY requests are subject to access controls as implemented by the server.

修改

LDAP 客户机使用 MODIFY 操作来请求 LDAP 服务器对现有条目进行更改。[16] 尝试修改不存在的条目将失败。MODIFY 请求受服务器实施的访问控制的约束。

The MODIFY operation requires that the distinguished name (DN) of the entry be specified, and a sequence of changes. Each change in the sequence must be one of:

add (add a new value, which must not already exist in the attribute)
delete (delete an existing value)
replace (replace an existing value with a new value)

MODIFY 操作要求指定条目的可分辨名称（DN）以及一系列更改。序列中的每个更改必须是以下项之一：

add（添加一个新值，该值不能存在于属性中）
delete（删除现有值）
replace（用新值替换现有值）

LDIF example of adding a value to an attribute:

向属性添加值的 LDIF 示例：

dn: dc=example,dc=com
changetype: modify
add: cn
cn: the-new-cn-value-to-be-added
-

To replace the value of an existing attribute, use the keyword. If the attribute is multi-valued, the client must specify the value of the attribute to update. replace

To delete an attribute from an entry, use the keyword and the changetype designator . If the attribute is multi-valued, the client must specify the value of the attribute to delete. deletemodify

There is also a Modify-Increment extension[17] which allows an incrementable attribute value to be incremented by a specified amount. The following example using LDIF increments by : employeeNumber5

若要替换现有属性的值，请使用关键字。如果属性是多值的，则客户端必须指定要更新的属性的值。replace

若要从条目中删除属性，请使用关键字和 changetype 指示符。如果属性是多值的，则客户端必须指定要删除的属性的值。deletemodify

还有一个Modify-Increment扩展[17]，它允许将可增量的属性值递增指定量。以下示例使用 LDIF 递增：employeeNumber5

dn: uid=user.0,ou=people,dc=example,dc=com
changetype: modify
increment: employeeNumber
employeeNumber: 5
-

When LDAP servers are in a replicated topology, LDAP clients should consider using the post-read control to verify updates instead of a search after an update.[18] The post-read control is designed so that applications need not issue a search request after an update – it is bad form to retrieve an entry for the sole purpose of checking that an update worked because of the replication eventual consistency model. An LDAP client should not assume that it connects to the same directory server for each request because architects may have placed load-balancers or LDAP proxies or both between LDAP clients and servers.

当 LDAP 服务器位于复制拓扑中时，LDAP 客户端应考虑使用读取后控件来验证更新，而不是在更新后进行搜索。[18] 读取后控件的设计使应用程序不需要在更新后发出搜索请求 - 仅为了检查更新是否正常工作而检索条目是不好的形式，因为复制最终一致性模型。LDAP 客户端不应假定它为每个请求连接到同一目录服务器，因为架构师可能在 LDAP 客户端和服务器之间放置了负载平衡器或 LDAP 代理或两者兼而有之。

Modify DN

Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag that indicates whether to delete the value(s) in the entry that match the old RDN. The server may support renaming of entire directory subtrees.

An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions[19] that support this, though.

修改DN

修改 DN（移动/重命名条目）采用新的 RDN（相对可分辨名称）、（可选）新父级的 DN 以及指示是否删除条目中与旧 RDN 匹配的值的标志。服务器可能支持重命名整个目录子树。

更新操作是原子的：其他操作将看到新条目或旧条目。另一方面，LDAP 没有定义多个操作的事务：如果您读取一个条目，然后对其进行修改，则另一个客户端可能在此期间更新了该条目。不过，服务器可能会实现支持这一点的扩展[19]。

Extended operations

The Extended Operation is a generic LDAP operation that can define new operations that were not part of the original protocol specification. StartTLS is one of the most significant extensions. Other examples include Cancel and Password Modify.[20]

扩展操作

扩展操作是一种通用的 LDAP 操作，可以定义不属于原始协议规范的新操作。StartTLS 是最重要的扩展之一。其他示例包括“取消”和“密码修改”。[注20]

StartTLS

The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.

StartTLS

StartTLS 操作在连接上建立传输层安全性（SSL 的后代）。它可以提供数据机密性（保护数据不被第三方观察）和/或数据完整性保护（保护数据不被篡改）。在 TLS 协商期间，服务器发送其 X.509 证书以证明其身份。客户端还可以发送证书来证明其身份。执行此操作后，客户端可以使用 SASL/EXTERNAL。通过使用 SASL/EXTERNAL，客户端请求服务器从较低级别（如 TLS）提供的凭据派生其标识。尽管从技术上讲，服务器可以使用在任何较低级别建立的任何身份信息，但通常服务器将使用 TLS 建立的身份信息。

Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways: 1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and 2) the LDAPS connection must be closed upon TLS closure.

服务器通常还支持单独端口上的非标准“LDAPS”（“安全 LDAP”，通常称为“LDAP over SSL”）协议，默认为 636。LDAPS 与 LDAP 在两个方面有所不同： 1）连接后，客户端和服务器在传输任何 LDAP 消息之前建立 TLS（没有 StartTLS 操作）和 2）在 TLS 关闭时，必须关闭 LDAPS 连接。

Some "LDAPS" client libraries only encrypt communication; they do not check the host name against the name in the supplied certificate.[21]

某些“LDAPS”客户端库仅加密通信;它们不会根据提供的证书中的名称检查主机名。[注21]

Abandon

The Abandon operation requests that the server abort an operation named by a message ID. The server need not honor the request. Neither Abandon nor a successfully abandoned operation send a response. A similar Cancel extended operation does send responses, but not all implementations support this.

放弃

Abandon 操作请求服务器中止由消息 ID 命名的操作。服务器不需要接受请求。“放弃”操作和成功放弃的操作都不会发送响应。类似的 Cancel 扩展操作会发送响应，但并非所有实现都支持此功能。

Unbind

The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin, and is not the opposite of the Bind operation.[22]

解绑

Unbind 操作将放弃任何未完成的操作并关闭连接。它没有响应。该名称起源于历史，与 Bind 操作并不相反。[注22]

Clients can abort a session by simply closing the connection, but they should use Unbind.[23] Unbind allows the server to gracefully close the connection and free resources that it would otherwise keep for some time until discovering the client had abandoned the connection. It also instructs the server to cancel operations that can be canceled, and to not send responses for operations that cannot be canceled.[24]

客户端只需关闭连接即可中止会话，但应使用取消绑定。[23] Unbind 允许服务器优雅地关闭连接并释放资源，否则它会保留一段时间，直到发现客户端已经放弃了连接。它还指示服务器取消可以取消的操作，并且不发送无法取消的操作的响应。[注24]

URI scheme

An LDAP uniform resource identifier (URI) scheme exists, which clients support in varying degrees, and servers return in referrals and continuation references (see RFC 4516):

URI方案

存在 LDAP 统一资源标识符（URI）方案，客户端在不同程度上支持该方案，服务器在引用和延续引用中返回（请参阅 RFC 4516）：

ldap://host:port/DN?attributes?scope?filter?extensions

Most of the components described below are optional.

host is the FQDN or IP address of the LDAP server to search.
port is the network port (default port 389) of the LDAP server.
DN is the distinguished name to use as the search base.
attributes is a comma-separated list of attributes to retrieve.
scope specifies the search scope and can be "base" (the default), "one" or "sub".
filter is a search filter. For example, as defined in RFC 4515.(objectClass=*)
extensions are extensions to the LDAP URL format.

下面描述的大多数组件都是可选的。

host 是要搜索的 LDAP 服务器的 FQDN 或 IP 地址。
port 是 LDAP 服务器的网络端口（默认端口 389）。
DN 是用作搜索库的可分辨名称。
attributes 是要检索的属性的逗号分隔列表。
scope 指定搜索范围，可以是“base”（默认值）、“one”或“sub”。
filter 是一个搜索过滤器。例如，如 RFC 4515 中定义。(objectClass=*)
扩展是 LDAP URL 格式的扩展。

For example, "" refers to all user attributes in John Doe's entry in , while "" searches for the entry in the default server (note the triple slash, omitting the host, and the double question mark, omitting the attributes). As in other URLs, special characters must be percent-encoded. ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comldap.example.comldap:///dc=example,dc=com??sub?(givenName=John)

例如，“” 表示中 John Doe 条目中的所有用户属性，而 “” 在默认服务器中搜索该条目（请注意三斜杠，省略主机，双问号，省略属性）。与其他 URL 一样，特殊字符必须进行百分比编码。

There is a similar non-standard URI scheme for LDAP over SSL. This should not be confused with LDAP with TLS, which is achieved using the StartTLS operation using the standard scheme. ldapsldap

对于基于 SSL 的 LDAP，也有类似的非标准 URI 方案。这不应与带有 TLS 的 LDAP 混淆，后者是使用标准方案的 StartTLS 操作实现的。ldapsldap

Schema

The contents of the entries in a subtree are governed by a directory schema, a set of definitions and constraints concerning the structure of the directory information tree (DIT).

架构

子树中条目的内容由目录架构控制，目录架构是一组与目录信息树（DIT）结构有关的定义和约束。

The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:

Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
Matching Rules—Provide information about how to make comparisons against attribute values.
Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
Attribute Types—Define an object identifier (OID) and a set of names that may refer to a given attribute, and associates that attribute with a syntax and set of matching rules.
Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.
Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.

Directory Server 的模式定义了一组规则，这些规则控制服务器可以保存的信息类型。它有许多元素，包括：

属性语法 - 提供有关可存储在属性中的信息类型的信息。
匹配规则 - 提供有关如何与属性值进行比较的信息。
匹配规则用途 - 指示哪些属性类型可以与特定匹配规则结合使用。
属性类型 - 定义对象标识符（OID）和一组可能引用给定属性的名称，并将该属性与语法和一组匹配规则相关联。
对象类 - 定义属性的命名集合，并将它们分类为必需属性和可选属性集。
名称表单 - 为条目的 RDN 中应包含的属性集定义规则。
内容规则（Content Rules） - 定义有关可与条目结合使用的对象类和属性的附加约束。
结构规则（Structure Rule） - 定义用于控制给定条目可能具有的从属条目类型的规则。

Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.

Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.

属性是负责在目录中存储信息的元素，架构定义了可以在条目中使用哪些属性的规则、这些属性可能具有的值的种类以及客户端如何与这些值进行交互。

客户端可以通过检索适当的子架构子条目来了解服务器支持的架构元素。

The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.

架构定义对象类。每个条目都必须具有一个 objectClass 属性，其中包含架构中定义的命名类。条目类的架构定义定义了条目可能表示的对象类型 - 例如个人、组织或域。对象类定义还定义必须包含值的属性列表和可能包含值的属性列表。

For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values that define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class definition and an instance in Object-oriented programming, representing LDAP objectClass and LDAP entry, respectively.

例如，表示人员的条目可能属于“top”和“person”类。“person”类中的成员身份要求条目包含“sn”和“cn”属性，并允许条目还包含“userPassword”、“telephoneNumber”和其他属性。由于条目可能具有多个 ObjectClasses 值，因此每个条目都具有由它所表示的对象类的并集形成的可选属性集和必需属性集的复合体。可以继承 ObjectClasses，并且单个条目可以具有多个 ObjectClasses 值，这些值定义条目本身的可用属性和必需属性。与 objectClass 的模式平行的是面向对象编程中的类定义和实例，分别表示 LDAP objectClass 和 LDAP 条目。

Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)

Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema.

目录服务器可以在条目的 subschemaSubentry 操作属性给定的基本 DN 上发布控制条目的目录模式。（操作属性描述目录的操作，而不是用户信息，并且仅在显式请求时从搜索返回。

除了提供的架构元素之外，服务器管理员还可以添加其他架构条目。用于表示组织内各个人员的架构称为白页架构。

Variations

A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.

变化

许多服务器操作都留给实现者或管理员来决定。因此，可以设置服务器以支持各种方案。

For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there has been work on it and there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.

例如，未指定服务器中的数据存储 - 服务器可能使用平面文件、数据库，或者只是作为其他服务器的网关。访问控制不是标准化的，尽管已经进行了工作并且有常用的模型。用户的密码可能存储在他们的条目或其他地方。服务器可以根据需要拒绝执行操作，并施加各种限制。

Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have options that may modify their semantics.

LDAP 的大多数部分都是可扩展的。示例：可以定义新操作。控件可以修改请求和响应，例如请求排序的搜索结果。可以定义新的搜索范围和绑定方法。属性可以具有可以修改其语义的选项。

Other data models

As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed varies. For example, there is software to access SQL databases through LDAP, even though LDAP does not readily lend itself to this.[25] X.500 servers may support LDAP as well.

其他数据模型

随着LDAP的发展势头，供应商已将其作为其他服务的访问协议提供。然后，实现会重铸数据以模拟 LDAP/X.500 模型，但遵循该模型的程度各不相同。例如，有一些软件可以通过LDAP访问SQL数据库，即使LDAP不容易做到这一点。[25] X.500 服务器也可以支持 LDAP。

Similarly, data previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via PAM and NSS modules. LDAP is often used by other services for authentication and/or authorization (what actions a given already-authenticated user can do on what service). For example in Active Directory Kerberos is used in the authentication step, while LDAP is used in the authorization step.

同样，以前保存在其他类型的数据存储中的数据有时会移动到 LDAP 目录。例如，Unix 用户和组信息可以存储在 LDAP 中，并通过 PAM 和 NSS 模块进行访问。LDAP 通常被其他服务用于身份验证和/或授权（给定的已通过身份验证的用户可以对哪些服务执行哪些操作）。例如，在 Active Directory 中，Kerberos 用于身份验证步骤，而 LDAP 用于授权步骤。

An example of such data model is the GLUE Schema,[26] which is used in a distributed information system based on LDAP that enable users, applications and services to discover which services exist in a Grid infrastructure and further information about their structure and state.

这种数据模型的一个例子是GLUE模式[26]，它用于基于LDAP的分布式信息系统，使用户、应用程序和服务能够发现网格基础设施中存在哪些服务，以及有关其结构和状态的更多信息。

Usage

An LDAP server may return referrals to other servers for requests that it cannot fulfill itself. This requires a naming structure for LDAP entries so one can find a server holding a given distinguished name (DN), a concept defined in the X.500 Directory and also used in LDAP. Another way of locating LDAP servers for an organization is a DNS server record (SRV).

用法

LDAP 服务器可能会将引用返回到其他服务器，以处理它无法自行完成的请求。这需要LDAP条目的命名结构，以便可以找到具有给定可分辨名称（DN）的服务器，DN在X.500目录中定义，也用于LDAP。为组织查找 LDAP 服务器的另一种方法是 DNS 服务器记录（SRV）。

An organization with the domain example.org may use the top level LDAP DN (where dc means domain component). If the LDAP server is also named ldap.example.org, the organization's top level LDAP URL becomes . dc=example, dc=orgldap://ldap.example.org/dc=example,dc=org

具有域 example.org 的组织可以使用顶级 LDAP DN（其中 dc 表示域组件）。如果 LDAP 服务器也命名为 ldap.example.org，则组织的顶级 LDAP URL 将变为。dc=example, dc=orgldap://ldap.example.org/dc=example,dc=org

Primarily two common styles of naming are used in both X.500 [2008] and LDAPv3. These are documented in the ITU specifications and IETF RFCs. The original form takes the top level object as the country object, such as , . The domain component model uses the model described above. An example of country based naming could be , or in the US: . c=USc=FRl=Locality, ou=Some Organizational Unit, o=Some Organization, c=FRcn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US

X.500 [2008] 和 LDAPv3 主要使用两种常见的命名样式。这些都记录在 ITU 规范和 IETF RFC 中。原始形式将顶级对象作为国家/地区对象，例如、。域组件模型使用上述模型。基于国家/地区的命名示例可以是，或者在美国：。c=USc=FRl=Locality, ou=Some Organizational Unit, o=Some Organization, c=FRcn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US

References

^ "Network Working Group RFC 4511". IETF.org. 2006-06-01. Retrieved 2014-04-04.
^ "Directory Services LDAP". Oracle.com. Retrieved 2014-04-04.
^ What is LDAP?. Gracion.com. Retrieved on 2013-07-17.
^ "Introduction to OpenLDAP Directory Services". OpenLDAP. Retrieved 1 February 2016.
^ "LDAP - Lightweight Directory Access Protocol". Webopedia.com. 4 December 1996. Retrieved 2014-04-05.
^ The X.500 series - ITU-T Rec. X.500 to X.521
^ Howes, Tim. "The Lightweight Directory Access Protocol: X.500 Lite" (PDF). Retrieved 26 December 2012.
^ "Pre-History of LDAP". Cyber Matters. 2013-04-09. Retrieved 5 October 2014.
^ "Service Name and Transport Protocol Port Number Registry". IANA. Retrieved 24 March 2021.
^ RFC3494
^ Add section of RFC4511
^ LDAP result codes
^ SASL Mechanisms at IANA
^ RFC4511: delete request
^ Boreham Draft (numSubordinates)
^ Modify Section of RFC4511
^ Zeilenga, K. LDAP Modify-Increment Extension. doi:10.17487/RFC4525. RFC 4525.
^ Zeilenga, K. Lightweight Directory Access Protocol (LDAP) Read Entry Controls. IETF. doi:10.17487/RFC4527. RFC 4527.
^ INTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15.txt
^ "What is LDAP? All You Need to Know". onelogin. Retrieved 2023-08-24.
^ Shibboleth Security alert 20120227
^ Tools.ietf.org
^ Tools.ietf.org
^ Tools.ietf.org
^ Openldap.org
^ Open Grid Forum : Project Home

参考资料

^ “网络工作组 RFC 4511”。IETF.org。2006-06-01.检索 2014-04-04.
^ “目录服务 LDAP”。Oracle.com。检索 2014-04-04.
^ 什么是 LDAP？.Gracion.com。检索 2013-07-17.
^ “OpenLDAP 目录服务简介”。OpenLDAP。已检索 2016年2月1日.
^ “LDAP - 轻量级目录访问协议”。Webopedia.com。1996年12月4日。检索 2014-04-05.
^ X.500 系列 - ITU-T X.500 至 X.521 建议书
^ “轻量级目录访问协议：X.500 Lite”（英文版本）。已检索 12月26日 2012.
^ “LDAP的史前史”。网络问题。2013-04-09.已检索 10月5日 2014.
^ “服务名称和传输协议端口号注册表”。IANA的。2021年3月24日检索。
^ RFC3494
^ 添加RFC4511部分
^ LDAP 结果代码
^ IANA 的 SASL 机制
^ RFC4511：删除请求
^ Boreham Draft （numSubordinates）
^ 修改RFC4511部分
^ Zeilenga， K. LDAP 修改增量扩展。doi：10.17487/RFC4525.RFC 4525 中。
^ Zeilenga， K. 轻量级目录访问协议（LDAP）读取条目控制。IETF的。doi：10.17487/RFC4527.RFC 4527 中。
^ 互联网草案 LDAP 交易草案-zeilenga-ldap-txn-15.txt
^ “什么是LDAP？所有你需要知道的”。OneLogin。检索 2023-08-24.
^ Shibboleth 安全警报 20120227
^ Tools.ietf.org
^ Tools.ietf.org
^ Tools.ietf.org
^ Openldap.org
^ Open Grid 论坛： Project Home

Sources

ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994
Basic encoding rules (BER) - ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994
RFC 3641 - Generic String Encoding Rules (GSER) for ASN.1 Types
RFC 4346 - The TLS Protocol Version 1.1
RFC 4422 - Simple Authentication and Security Layer (SASL)
SASL mechanisms registered at IANA

来源

ITU-T X.680建议书，“抽象语法符号一（ASN.1）——基本符号规范”，1994年
基本编码规则（BER） - ITU-T X.690建议书，“ASN.1编码规则规范：基本、规范和可分辨编码规则”，1994年
RFC 3641 - ASN.1 类型的通用字符串编码规则（GSER）
RFC 4346 - TLS 协议版本 1.1
RFC 4422 - 简单身份验证和安全层（SASL)
在 IANA 注册的 SASL 机制