LDAP
| 互联网协议套件 |
|---|
| 应用层 |
| 传输层 |
| 互联网层 |
| 链路层 |
在轻量级目录访问协议（LDAP / ɛ升d æ p /）是一个开放的，厂商中立的行业标准应用协议，用于访问和维护分布式目录信息服务上的互联网协议（IP）网络。[1] 目录服务通过允许在整个网络中共享有关用户、系统、网络、服务和应用程序的信息，在开发Intranet和 Internet 应用程序方面发挥着重要作用。[2] 例如，目录服务可以提供任何有组织的记录集，通常具有层次结构，例如公司电子邮件目录。类似地，电话簿是具有地址和电话号码的订户列表。
LDAP 在一系列名为Request for Comments (RFC)的Internet 工程任务组(IETF) 标准跟踪出版物中指定，使用描述语言ASN.1。最新的规范是版本 3，发布为 RFC 4511 [3]（技术规范的路线图由RFC4510提供）。
LDAP 的一个常见用途是提供一个中央位置来存储用户名和密码。这允许许多不同的应用程序和服务连接到 LDAP 服务器以验证用户。[4]
LDAP 基于包含在X.500标准中的标准的一个更简单的子集。由于这种关系，LDAP 有时称为 X.500-lite。[5]
内容
历史[编辑]
经过大约 70 年的电话簿制作和管理，电信公司对目录要求的理解得到了很好的发展。这些公司将目录服务的概念引入到信息技术和计算机网络中，他们的投入最终形成了全面的X.500规范，[6]是国际电信联盟(ITU) 在 1980 年代制定的一套协议。
X.500 目录服务传统上是通过 X.500目录访问协议(DAP)访问的，这需要开放系统互连(OSI)协议栈。LDAP 最初旨在成为一种轻量级替代协议，用于通过更简单（现在广泛使用）的TCP/IP协议栈访问 X.500 目录服务。这种目录访问模型是从DIXIE和目录协助服务协议中借来的。
该协议最初创建[7]由蒂姆·豪斯的中密歇根大学，史蒂夫Kille ISODE有限公司，科林·罗宾斯的Nexor和Wengyik永的性能系统国际，大约1993年，作为继任者[8] ，以DIXIE和DAS。Critical Angle Inc. 的 Mark Wahl、Tim Howes 和 Steve Kille 于 1996 年在Internet 工程任务组(IETF)的支持下开始研究新版本的 LDAP，即 LDAPv3 。LDAPv3 于 1997 年首次发布，取代了 LDAPv2 并增加了对可扩展性的支持，集成了简单的身份验证和安全层，并更好地将协议与 1993 版的 X.500 保持一致。IETF对 LDAPv3 规范本身以及向 LDAPv3 添加功能的众多扩展进行了进一步开发。
在 LDAP 的早期工程阶段，它被称为轻量级目录浏览协议，或LDBP。随着协议范围扩展到目录浏览和搜索之外，它被重命名，以包括目录更新功能。它被赋予轻量级名称，因为它不像它的 DAP 前身那样网络密集，因此由于其相对适度的带宽使用，更容易在 Internet 上实施。
LDAP 影响了随后的 Internet 协议，包括 X.500、XML 启用目录(XED)、目录服务标记语言(DSML)、服务供应标记语言(SPML) 和服务位置协议(SLP) 的更高版本。它也可以用来作为依据微软的Active Directory中。
协议概述[编辑]
客户端通过连接到 LDAP 服务器（称为目录系统代理(DSA)）来启动 LDAP 会话，默认情况下在TCP和UDP 端口389 或 LDAPS 的端口 636（LDAP over TLS/SSL，见下文）。[9]客户端然后向服务器发送操作请求，服务器返回响应。除了一些例外，客户端在发送下一个请求之前不需要等待响应，服务器可以以任何顺序发送响应。所有信息都使用基本编码规则(BER)传输。
客户端可以请求以下操作：
- StartTLS – 使用 LDAPv3传输层安全(TLS) 扩展进行安全连接
- 绑定 -验证并指定 LDAP 协议版本
- 搜索 – 搜索和/或检索目录条目
- 比较 - 测试命名条目是否包含给定的属性值
- 添加新条目
- 删除条目
- 修改条目
- 修改专有名称 (DN) – 移动或重命名条目
- 放弃 - 中止先前的请求
- 扩展操作——用于定义其他操作的通用操作
- 解除绑定 - 关闭连接（不是绑定的逆操作）
此外，服务器可能会发送不是对任何请求的响应的“主动通知”，例如在连接超时之前。
保护 LDAP 通信的常用替代方法是使用SSL 隧道。LDAP over SSL 的默认端口是 636。LDAP over SSL 的使用在 LDAP 版本 2 (LDAPv2) 中很常见，但它从未在任何正式规范中标准化。这种用法已与 LDAPv2 一起被弃用，后者于 2003 年正式停用。[10]
目录结构[编辑]
该协议提供了一个包含遵循 1993 版X.500模型的目录的接口：
- 一个条目由一组属性组成。
- 属性具有名称（属性类型或属性描述）和一个或多个值。属性在模式中定义（见下文）。
- 每个条目都有一个唯一标识符：其专有名称(DN)。这包括其相对可分辨名称(RDN)，由条目中的某些属性构成，后跟父条目的 DN。将 DN 视为完整文件路径，将 RDN 视为其父文件夹中的相对文件名（例如，如果
/foo/bar/myfile.txt是 DN，myfile.txt则将是 RDN）。
DN 可能会在条目的生命周期内发生变化，例如，当条目在树中移动时。为了可靠且明确地标识条目，可以在条目的操作属性集中提供UUID。
当以LDAP 数据交换格式(LDIF)表示时，条目可能如下所示（LDAP 本身是一个二进制协议）：
dn：cn=John Doe,dc=example,dc=com cn：John Doe givenName：John sn：Doe 电话号码：+1 888 555 6789 电话号码：+1 888 555 1232 邮件：john@example.com 经理：cn=Barbara Doe,dc=example,dc=com objectClass：inetOrgPerson objectClass：organizationalPerson objectClass：person objectClass：top“ dn”是条目的可分辨名称；它既不是属性也不是条目的一部分。“ cn=John Doe”是条目的RDN（Relative Distinguished Name），“ dc=example,dc=com”是父条目的DN，其中“ dc”表示'域组件'。其他行显示条目中的属性。属性名称通常是助记符字符串，例如“ cn”代表通用名称，“ dc”代表域组件，“ mail”代表电子邮件地址，“ sn”代表姓氏。
服务器拥有从特定条目开始的子树，例如“ dc=example,dc=com”及其子项。服务器也可能保存对其他服务器的引用，因此尝试访问“ ou=department,dc=example,dc=com”可能会返回对保存目录树该部分的服务器的引用或继续引用。然后客户端可以联系其他服务器。一些服务器还支持链接，这意味着服务器联系其他服务器并将结果返回给客户端。
LDAP 很少定义任何排序：服务器可以以任何顺序返回属性值、条目中的属性以及搜索操作找到的条目。这遵循正式的定义——一个条目被定义为一组属性，一个属性是一组值，并且不需要对集合进行排序。
操作[编辑]
添加[编辑]
ADD 操作将一个新条目插入到目录服务器数据库中。[11]如果添加请求中的专有名称在目录中已经存在，那么服务器不会添加重复的条目，而是将添加结果中的结果代码设置为十进制68，“entryAlreadyExists”。[12]
- LDAP 兼容服务器在尝试定位条目时绝不会取消引用添加请求中传输的专有名称，也就是说，专有名称永远不会消除别名。
- LDAP 兼容服务器将确保专有名称和所有属性符合命名标准。
- 要添加的条目必须不存在，并且必须存在直接上级。
在上面的例子中，uid=user,ou=people,dc=example,dc=com必须不存在，并且ou=people,dc=example,dc=com必须存在。
绑定（验证）[编辑]
创建LDAP会话时，即LDAP客户端连接服务器时，会话的认证状态设置为匿名。BIND 操作为会话建立身份验证状态。
Simple BIND 和 SASL PLAIN 可以以明文形式发送用户的 DN 和密码，因此使用 Simple 或 SASL PLAIN 的连接应使用传输层安全性(TLS)进行加密。服务器通常userPassword 根据命名条目中的属性检查密码。匿名 BIND（具有空 DN 和密码）将连接重置为匿名状态。
SASL（简单身份验证和安全层）BIND 通过广泛的机制提供身份验证服务，例如Kerberos或使用 TLS 发送的客户端证书。[13]
BIND 还通过以整数形式发送版本号来设置 LDAP 协议版本。如果客户端请求服务器不支持的版本，则服务器必须将 BIND 响应中的结果代码设置为协议错误代码。通常客户端应该使用 LDAPv3，这是协议中的默认值，但并非总是在 LDAP 库中。
BIND 必须是 LDAPv2 会话中的第一个操作，但从 LDAPv3 开始不需要。在 LDAPv3 中，每个成功的 BIND 请求都会更改会话的身份验证状态，每个不成功的 BIND 请求都会重置会话的身份验证状态。
删除[编辑]
要删除条目，LDAP 客户端向服务器发送格式正确的删除请求。[14]
- 删除请求必须包含要删除的条目的专有名称
- 请求控制也可以附加到删除请求
- 服务器在处理删除请求时不会取消引用别名
- 删除请求只能删除叶条目（没有下级的条目）。一些服务器支持一个操作属性
hasSubordinates，该属性的值表明一个条目是否有任何从属条目，而一些服务器支持一个操作属性numSubordinates[15]，表明从属于包含该numSubordinates属性的条目的条目数。 - 一些服务器支持子树删除请求控制，允许删除 DN 和从属于该 DN 的所有对象，但受访问控制的约束。删除请求受访问控制的约束，即是否允许具有给定身份验证状态的连接删除给定条目由特定于服务器的访问控制机制控制。
搜索和比较[编辑]
搜索操作用于搜索和读取条目。它的参数是：
- 基础对象
- 相对于要执行搜索的基础对象条目（或可能是根）的名称。
- 范围
- 要搜索的 baseObject 下方的哪些元素。这可以是
BaseObject（仅搜索命名条目，通常用于读取一个条目）、singleLevel（紧接在基本 DN 下方的条目）或wholeSubtree（从基本 DN 开始的整个子树）。 - 筛选
- 用于选择范围内元素的标准。例如，过滤器
(&(objectClass=person)(|(givenName=John)(mail=john*)))将选择“persons”（objectClass 的元素person），其中匹配规则givenName并mail确定这些属性的值是否与过滤器断言匹配。请注意，一个常见的误解是 LDAP 数据区分大小写，而实际上匹配规则和排序规则决定了匹配、比较和相对值关系。如果需要示例过滤器来匹配属性值的大小写，则必须使用可扩展的匹配过滤器，例如，(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*))) - 解引用别名
- 是否以及如何跟随别名条目（引用其他条目的条目），
- 属性
- 在结果条目中返回哪些属性。
- 大小限制，时间限制
- 要返回的最大条目数，以及允许搜索运行的最长时间。但是，这些值不能覆盖服务器对大小限制和时间限制的任何限制。
- 仅限类型
- 仅返回属性类型，不返回属性值。
服务器返回匹配的条目和潜在的延续引用。这些可以按任何顺序返回。最终结果将包含结果代码。
比较操作采用 DN、属性名称和属性值，并检查命名条目是否包含具有该值的属性。
修改[编辑]
LDAP 客户端使用 MODIFY 操作来请求 LDAP 服务器对现有条目进行更改。[16]尝试修改不存在的条目将失败。修改请求受服务器实施的访问控制的约束。
MODIFY 操作要求指定条目的专有名称 (DN)，以及一系列更改。序列中的每个更改都必须是以下之一：
- 添加（添加一个新值，该值不能已经存在于属性中）
- 删除（删除现有值）
- 替换（用新值替换现有值）
向属性添加值的LDIF示例：
dn: dc=example,dc=com changetype: 修改 add: cn cn: the-new-cn-value-to-be- added -要替换现有属性的值，请使用replace关键字。如果属性是多值的，客户端必须指定要更新的属性值。
要从条目中删除属性，请使用关键字delete和 changetype 指示符modify。如果属性是多值的，客户端必须指定要删除的属性的值。
还有一个 Modify-Increment 扩展[17]，它允许将可增加的属性值增加指定的数量。下面的示例使用LDIF增量employeeNumber由5：
当 LDAP 服务器处于复制拓扑中时，LDAP 客户端应考虑使用读取后控制来验证更新，而不是在更新后进行搜索。[18]读后控制的设计使得应用程序无需在更新后发出搜索请求 - 由于复制最终一致性模型，仅出于检查更新是否有效而检索条目是不好的形式。LDAP 客户端不应假定它为每个请求连接到同一目录服务器，因为架构师可能已在 LDAP 客户端和服务器之间放置了负载平衡器或 LDAP 代理或两者。
修改 DN [编辑]
修改 DN（移动/重命名条目）采用新的 RDN（相对可分辨名称）、可选的新父代的 DN，以及指示是否删除条目中与旧 RDN 匹配的值的标志。服务器可以支持整个目录子树的重命名。
更新操作是原子的：其他操作将看到新条目或旧条目。另一方面，LDAP 没有定义多个操作的事务：如果您读取一个条目然后修改它，另一个客户端可能在此期间更新了该条目。不过，服务器可能会实现支持这一点的扩展[19]。
扩展操作[编辑]
扩展操作是一个通用的 LDAP 操作，它可以定义不属于原始协议规范一部分的新操作。StartTLS 是最重要的扩展之一。其他示例包括取消和密码修改。
StartTLS [编辑]
StartTLS 操作在连接上建立传输层安全性（SSL的后代）。它可以提供数据机密性（保护数据不被第三方观察）和/或数据完整性保护（保护数据不被篡改）。在 TLS 协商期间，服务器发送其X.509证书以证明其身份。客户端还可以发送证书来证明其身份。这样做之后，客户端就可以使用SASL/外部的。通过使用 SASL/EXTERNAL，客户端请求服务器从较低级别（例如 TLS）提供的凭据中获取其身份。虽然从技术上讲，服务器可以使用在任何较低级别建立的任何身份信息，但通常服务器将使用由 TLS 建立的身份信息。
服务器还经常在单独的端口上支持非标准的“LDAPS”（“Secure LDAP”，通常称为“LDAP over SSL”）协议，默认为 636。LDAPS 与 LDAP 有两个不同之处：1）在连接时，客户端和服务器在传输任何 LDAP 消息之前建立 TLS（没有 StartTLS 操作）和 2）LDAPS 连接必须在 TLS 关闭时关闭。
一些“LDAPS”客户端库只加密通信；他们不会根据提供的证书中的名称检查主机名。[20]
放弃[编辑]
Abandon 操作请求服务器中止由消息 ID 命名的操作。服务器不需要接受请求。Abandon 和成功放弃的操作都不发送响应。类似的 Cancel 扩展操作确实会发送响应，但并非所有实现都支持这一点。
解除绑定[编辑]
Unbind 操作会放弃所有未完成的操作并关闭连接。它没有反应。该名称具有历史渊源，并不与 Bind 操作相反。[21]
客户端可以通过简单地关闭连接来中止会话，但他们应该使用 Unbind。[22] Unbind 允许服务器优雅地关闭连接并释放资源，否则它会保留一段时间直到发现客户端放弃连接。它还指示服务器取消可以取消的操作，并且不对无法取消的操作发送响应。[23]
URI 方案[编辑]
存在LDAP统一资源标识符 (URI)方案，客户端在不同程度上支持该方案，并且服务器在引用和继续引用中返回（请参阅 RFC 4516）：
ldap://host:port/DN?attributes?scope?filter?extensions下面描述的大多数组件都是可选的。
- host是要搜索的 LDAP 服务器的FQDN或 IP 地址。
- port是LDAP 服务器的网络端口（默认端口 389）。
- DN是用作搜索基础的专有名称。
- attributes是以逗号分隔的要检索的属性列表。
- scope指定搜索范围，可以是“base”（默认）、“one”或“sub”。
- filter是一个搜索过滤器。例如，
(objectClass=*)如 RFC 4515 中所定义。 - extensions是对 LDAP URL 格式的扩展。
例如，“ ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com”指的是 John Doe 的条目中的所有用户属性ldap.example.com，而“ ldap:///dc=example,dc=com??sub?(givenName=John)”在默认服务器中搜索条目（注意三斜线，省略主机，和双问号，省略属性）。与其他 URL 一样，特殊字符必须进行百分比编码。
ldapsLDAP over SSL有一个类似的非标准URI 方案。这不应与带有 TLS 的 LDAP 混淆，后者是通过使用标准ldap方案的 StartTLS 操作实现的。
架构[编辑]
子树中条目的内容由目录模式、一组关于目录信息树 (DIT) 结构的定义和约束管理。
目录服务器的架构定义了一组规则，用于管理服务器可以保存的信息种类。它有许多元素，包括：
- 属性语法 - 提供有关可以存储在属性中的信息种类的信息。
- 匹配规则 - 提供有关如何与属性值进行比较的信息。
- 匹配规则使用 - 指示哪些属性类型可以与特定匹配规则结合使用。
- 属性类型——定义一个对象标识符(OID) 和一组可能引用给定属性的名称，并将该属性与语法和一组匹配规则相关联。
- 对象类 - 定义命名的属性集合并将它们分类为必需和可选属性集。
- Name Forms - 为条目的 RDN 中应包含的属性集定义规则。
- 内容规则 - 定义有关可与条目结合使用的对象类和属性的附加约束。
- 结构规则 - 定义管理给定条目可能具有的从属条目种类的规则。
属性是负责在目录中存储信息的元素，模式定义了可以在条目中使用哪些属性的规则、这些属性可能具有的值类型以及客户端如何与这些值交互。
客户端可以通过检索适当的子模式子条目来了解服务器支持的模式元素。
模式定义了对象类。每个条目都必须有一个 objectClass 属性，其中包含模式中定义的命名类。条目类的模式定义定义了条目可以代表什么类型的对象——例如个人、组织或域。对象类定义还定义了必须包含值的属性列表和可能包含值的属性列表。
例如，代表一个人的条目可能属于“top”和“person”类。“person”类的成员资格要求条目包含“sn”和“cn”属性，并允许条目还包含“userPassword”、“telephoneNumber”和其他属性。由于条目可能有多个 ObjectClasses 值，每个条目都有一个由它所代表的对象类的联合形成的可选和强制属性集的复合体。ObjectClasses 可以被继承，并且单个条目可以具有多个 ObjectClasses 值，这些值定义了条目本身的可用和所需属性。，分别代表 LDAP 对象类和 LDAP 条目。
目录服务器可以在条目的 subschemaSubentry 操作属性给定的基本 DN 上发布控制条目的目录模式。（操作属性描述目录的操作而不是用户信息，并且仅在明确请求时从搜索中返回。）
除了提供的架构元素之外，服务器管理员还可以添加其他架构条目。代表组织内个人的模式称为白页模式。
变化[编辑]
许多服务器操作留给实施者或管理员来决定。因此，可以设置服务器以支持多种场景。
例如，未指定服务器中的数据存储 - 服务器可能使用平面文件、数据库，或者只是到其他服务器的网关。访问控制不是标准化的，尽管已经有相关工作并且有常用模型。用户的密码可能存储在他们的条目中或其他地方。服务器可以根据需要拒绝执行操作，并施加各种限制。
LDAP 的大多数部分都是可扩展的。示例： 可以定义新操作。 控件可以修改请求和响应，例如请求排序的搜索结果。可以定义新的搜索范围和绑定方法。属性可以有可以修改其语义的选项。
其他数据模型[编辑]
随着 LDAP 的发展势头强劲，供应商已将其作为其他服务的访问协议提供。然后，实现重新转换数据以模拟 LDAP/X.500 模型，但遵循该模型的程度各不相同。例如，有通过 LDAP访问SQL数据库的软件，尽管 LDAP 并不容易做到这一点。[24] X.500 服务器也可能支持 LDAP。
同样，以前保存在其他类型数据存储中的数据有时会移动到 LDAP 目录。例如，Unix 用户和组信息可以存储在 LDAP 中并通过PAM和NSS模块访问。LDAP 经常被其他服务用于身份验证和/或授权（给定的已验证用户可以对什么服务执行什么操作）。例如，在 Active Directory 中，Kerberos 用于身份验证步骤，而 LDAP 用于授权步骤。
这种数据模型的一个例子是 GLUE 模式[25]，它用于基于 LDAP 的分布式信息系统，使用户、应用程序和服务能够发现网格基础设施中存在哪些服务以及有关其结构和状态的更多信息。
用法[编辑]
LDAP 服务器可能会针对无法自行完成的请求返回对其他服务器的引用。这需要 LDAP 条目的命名结构，以便可以找到保存给定专有名称 (DN) 的服务器，该概念在 X.500 目录中定义并且也在 LDAP 中使用。为组织定位 LDAP 服务器的另一种方法是 DNS服务器记录(SRV)。
具有域 example.org 的组织可以使用顶级 LDAP DN dc=example,dc=org（其中dc表示域组件）。如果 LDAP 服务器也命名为 ldap.example.org，则组织的顶级 LDAP URL 变为ldap://ldap.example.org/dc=example,dc=org。
X.500 [2008] 和 LDAPv3 中主要使用两种常见的命名方式。这些记录在 ITU 规范和 IETF RFC 中。原始形式以顶级对象为国家对象，如c=US, c=FR。领域组件模型使用上述模型。基于国家/地区的命名示例可以是l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR，或者在美国：cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US。
另见[编辑]
参考文献[编辑]
- "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. 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)
- ^ RFC4511 的修改部分
- ^ Zeilenga, K. LDAP 修改增量扩展。doi：10.17487/RFC4525。RFC 4525。
- ^ Zeilenga, K.轻量级目录访问协议 (LDAP) 读取条目控制。IETF。doi：10.17487/RFC4527。RFC 4527。
- ^ INTERNET-DRAFT LDAP 交易草案-zeilenga-ldap-txn-15.txt
- ^ Shibboleth 安全警报 20120227
- ^ Tools.ietf.org
- ^ Tools.ietf.org
- ^ Tools.ietf.org
- ^ Openldap.org
- ^ 开放网格论坛：项目主页
备注[编辑]
- ITU-T 建议书 X.680，“抽象语法表示法一 (ASN.1) - 基本表示法规范”，1994
- 基本编码规则(BER) - ITU-T Rec. X.690，“ASN.1 编码规则规范：基本、规范和特殊编码规则”，1994
- RFC 3641 - ASN.1 类型的通用字符串编码规则(GSER)
- RFC 4346 - TLS协议版本 1.1
- RFC 4422 - 简单身份验证和安全层 ( SASL )
- 在 IANA 注册的 SASL 机制
进一步阅读[编辑]
- 阿尔基尔斯，B（2003 年）。LDAP 目录解释：介绍和分析。Addison-Wesley Professional。国际标准书号 978-0-201-78792-4.
- 卡特，G（2003 年）。LDAP 系统管理。奥莱利媒体。国际标准书号 978-1-56592-491-8.
- 唐利，C (2002)。LDAP 编程、管理和集成。曼宁出版社。国际标准书号 978-1-930110-40-3.
- 豪斯，T; 史密斯，M；好，G (2003)。了解和部署 LDAP 目录服务。Addison-Wesley Professional。国际标准书号 978-0-672-32316-4.
- 罗顿，J（1999 年）。Internet 邮件程序员指南：SMTP、POP、IMAP 和 LDAP。爱思唯尔。国际标准书号 978-1-55558-212-8.
- 沃格迈尔，R (2003)。LDAP 基础知识：如何安装、运行和管理 LDAP 服务。奥尔巴赫出版社。国际标准书号 978-0-8493-1346-2.
外部链接[编辑]
- 公共 LDAP 服务器列表（2013）：“Ldapwiki：公共 LDAP 服务器”。ldapwiki.com。2013 年。检索2020-01-18。
