LDAP是轻量级目录访问协议，源于X.500标准但简化了实现，使用TCP/IP堆栈。它定义了访问目录服务的操作，如搜索、修改和身份验证。LDAP目录服务在现代网络中广泛用于身份验证和用户信息存储，其命名模型基于目录信息树，安全模型支持身份验证和访问控制。LDAP的最新版本是v3，具有可扩展性和向后兼容性。
导读：
LDAP的发展历史
LDAP（Light-weight Directory Access Protocol）是在国际电报电话咨询委员会（CCITT）和国际标准化组织（ISO）联合开发的许多标准的基础上建立的。CCITT现在称为国际电信联盟（ITU）。ITU和ISO的目标是定义一个通用的目录标准，尽可能包括最广泛的目录服务。所开发的标准将构成面向CCITT和ITU开发的开放系统互连（OSI）网络模型的目录服务。
当开发该目录标准时，标准委员会中的ITU和ISO成员考虑问题的优先顺序不同。大部分ITU成员是全国性的电话运营商，他们希望获得将提供电话号码和电子邮件地址目录服务的标准。相反，ISO成员最感兴趣的是提供面向OSI应用程序的命名服务。最终的标准X.500是一个既复杂又全面的标准，很难实施，而且成本高昂，需要运行复杂的OSI网络协议。
X.500的出现
该标准旨在拥有一个分布全球的目录，并且带有标准访问接口。X.500目录标准极其复杂。
作为其设计操作平台的OSI网络协议也比现在通常使用的传输控制协议，Internet 协议（TCP/IP）套件复杂得多。
X.500标准最初由CCITT于1990 年作为《X.500蓝皮书建议》发布并由ISO于1991年作为《ISO / IEC 9594：目录》发布。从那时起，X.500已经得到发展和增强，并在1993年和1997年两次更新。
X.500拥有四个核心组件模块：
信息模块，信息模块定义了目录存储信息的方式。X.500在“属性”中存储信息，它是“对象类”的成员。每个属性都有语法定义、搜索规则和排序规则。
命名模型，命名模型定义引用每个条目的方式。在LDAP目录中，条目被组织在一个称为目录信息树（DIT）”的层次树中。
功能模型，功能模型是目录客户端与目录进行通信的方法。在X.500中，称为“目录用户代理（DUA）”的客户端使用称为“目录访问协议（DAP）”的复杂协议，与称为“目录系统代理（DSA）”的目录服务器进行通信。DAP 在OSI 网络协议堆栈上运行。
安全模型，安全模型提供了根据目录进行身份验证的方法，以及授权客户端访问目录的方法。
X.500中的大部分特性已经被转移给LDAP。
到LDAP的过渡
X.500接受和实施的主要问题是其过于复杂，并且实施和管理相关成本非常高。为了提高X.500目录的可接受性，Internet工程任务组（IETF）决定定义新的访问协议。该协议更简单，不依赖于OSI堆栈，而使用TCP/IP堆栈。这产生了两个新协议：目录辅助服务（Directory Assistance Service，DAS）和有效实施X.500的目录接口（Directory Interface to X.500 Implemented Efficiently，DIXIE）。
DAS和DIXIE的问题是它们是针对与X.500的某一具体实施配合工作而设计的。LDAP由IETF开发，用于消除这一限制。LDAP使用TCP/IP作为其网络传输协议，与目录实施无关，并使用DAP中的一小部分操作。
LDAP旨在作为访问X.500目录的轻型方法。然而，随着时间的推移，情况越来越明显，对X.500 目录服务器的访问大部分是通过LDAP协议进行的。当这一情况变得清晰时，目录服务器被设计和实施成只能通过LDAP访问。这些服务器不再有X.500目录服务器中的复杂性，其实施和管理费用也更低。其副作用是，LDAP服务器还拥有比X.500目录服务器更出色的性能。
LDAP的当前版本是LDAP v3。LDAP v1没有作为标准发布。LDAP v2于1995年3月公布，并在三个RFC中进行了定义：RFC 1777、RFC 1778和RFC 1779。LDAP v2在RFC 3494中停止作为标准使用。
IETF中的目录访问、搜索和索引（ASID）工作组开发了LDAP v3。LDAP v3对LDAP v2的增强包括：
使用面向所有文本字符串属性的UTF-8，以便支持扩展的字符集。
目录保留以便自己使用的可操作属性（例如，当其他属性被修改时记录日期和时间）。
检索，允许服务器将客户端导向可能拥有该客户端所请求的信息的其他服务器。当客户端进行的操作不能得到本地服务，并且LDAP服务器知道其他LDAP服务器可以处理此操作时，LDAP服务器可以将索引返回到LDAP客户端。
目录中发布的架构，允许客户端发现服务器所支持的对象类和属性。这是通过根对象（rootDSE）上的对象提供，供客户端使用。
使用了X.500（93）架构的主要部分。注意X.500（93）是指1993年发布的X.500版本。在OSI社区中使用这种方法来指标准的版本。
扩展搜索操作，允许对结果分页和分类，以及客户端定义的搜索和分类控制。
通过简单身份验证和安全层（SASL）机制实现的更强的安全性。
现在支持扩展操作和控制，使LDAP v3能够在不改变标准协议的情况下进行扩展。
LDAP v3可向后兼容LDAP v2。LDAP v3服务器的一个要求是LDAP v2客户端要能够与之连接。LDAP v3作为操作系统、网络操作系统、目录服务、应用程序（比如：电子邮件服务器）和客户端应用程序的组成部分而得到广泛实施。
LDAP目录服务概述
LDAP是目录访问协议的一个标准。它定义与目录服务进行通信所使用的操作，如何找到目录中的实体，如何描述实体属性，以及许多安全特性。这些安全特性可用于对目录进行身份验证，控制对目录中的实体的访问。
LDAP标准中没有定义在目录服务器上存储信息的方式。为实施LDAP服务器，使用了许多不同的技术。这些技术包括简单的平面文件、索引文件和相关数据库。无论使用什么技术来实施目录，从LDAP客户端对目录的所有访问都使用相同的标准协议：LDAP。为此，尽管存在不同的内容结构，这些目录都被称为LDAP目录服务器。
下面的关键方面描述了LDAP协议的特征：
该协议直接通过TCP和UDP传送。TCP用于面向连接的传输（已经确认接收到数据），而UDP用于无连接的传输（未确认是否发送或接收数据）。
大多数协议数据元素可以被编码成二进制字符串（例如，可分辨名称）。
可以将到其他服务器的索引返回客户端。
SASL机制可以与LDAP共同使用，以提供相关的安全服务。
通过使用国际标准化组织（ISO）10646 字符集，可以使属性值和可分辨名称适用于在国际上使用。
该协议可以扩展，以支持新的操作，可以使用控制能力来扩展现有操作。
架构通过供客户端使用的根对象上的属性来发布。
LDAP中定义的组件模型与X.500中定义的组件模型相同。
信息模型
目录必须有一种存储条目相关信息的方法。条目是目录的基本单位。信息模型提供描述条目属性所必需的数据结构和数据类型。每个属性都有一个名称以及单个值或多个值。这些值必须符合为该特殊属性定义的特定语法。属性语法的示例包括Unicode字符串、二进制和整数。除此之外，目录还要求可能通过其属性值来搜索特定条目。为了改善这一点，可以定义每个属性的匹配规则。这些规则指定：
搜索将如何匹配属性中包含的值。
属性如何排序的定义。
与条目相关的属性和特征在条目的对象类中定义。架构中拥有对象类和属性的定义。LDAP目录服务器中使用了三类对象类定义：
结构对象类，结构对象类表示实际的对象（比如：人）。一个实体必须属于一个且只属于一个结构对象类。
辅助对象类，辅助对象类用于扩展结构对象类。它本身没有什么任何意义。
抽象对象类，抽象对象类只用作派生类的祖先。
命名模型
命名模型定义提及每个条目的方式。在LDAP目录中，条目被组织在称为目录信息树（DIT）的层次树中。树中的每个节点都是一个条目，该条目可能存储信息，也可能是其他条目的容器。有两种方法提及树中的条目：使用其相对可分辨名称（RDN）或其可分辨名称（DN）。RDN 在目录中是唯一的，而DN是全局唯一的。
属性的RDN可能是对象的公用名（cn），如此处所示：
cn="Michael Allen"
当只使用一个属性不能确保唯一性时，还可以由多个属性值构成RDN；例如：
cn="Michael Allen"+ou="Engineering"
本例中的加号（+）表明该RDN是多值的。当组织中有两名员工都叫“Michael Allen”时，多值RDN的实用性显而易见。如果他们属于两个不同的部门，可以使用由部门唯一限定的RDN，如本例中“组织单位（ou）”属性所定义。
Michael Allen的条目的DN可能是：
cn="Michael Allen",dc="example",dc="com"
在这种情况下，对象不只在本地目录中，而且在全局中被唯一定义。“域组件（dc）”属性值用于唯一定义目录服务器的DNS域名。
在LDAP中，目录的命名上下文能够以地理或域名格式来定义。地理格式是X.500中定位目录的主要方法，LDAP服务器中也仍然使用该方法。然而，通常使用DLAP服务器的域名作为其命名上下文，因为域名在Internet上是全局唯一的。
功能模型
功能模型是目录客户端用来与目录进行通信的方法。这就是LDAP协议。LDAP提供以下操作：
询问 －－ 搜索目录
修改 －－ 更新、添加或删除目录中的条目
身份验证和控制 －－ 对目录进行身份验证（绑定操作）
安全模型
安全模型为根据目录进行身份验证以及授权客户端控制对目录的访问提供了方法。安全模型包括两个组件：
使用LDAP的身份验证绑定
对目录中的对象的访问控制
对LDAP的身份验证将在本节后面的“使用LDAP进行网络身份验证”部分中介绍。当通过身份验证后，客户端只能像目录的访问控制列表（Access Control List，ACL）中定义的那样使用LDAP目录。ACL在LDAP目录中的实施是依赖于实施的。
LDAP交换格式
LDAP目录可以使用标准注释来交换数据和架构定义。该注释称为LDAP交换格式（LDIF）。LDIF拥有一个简单的文本文件格式，其中包括：
使用空行分隔，表示单一实体的条目
以#字符开头的注释
向属性的值的分配
教授如何使用LDIF剖析程序解释条目的指导
下例中提供了显示个人实体定义的示例LDIF文件。该LDIF文件可用于在LDAP目录中创建一个实体。
# This is a comment
dn:cn=Michael Allen,cn=Users,dc=example,dc=com
objectClass:person
cn:Michael Allen
sn:Reid
telephoneNumber:555-0100
最后一行是空行。该文件使用DN定义实体：
cn=Michael Allen,cn=Users,dc=example,dc=com
该条目是对象类person的成员。对象类person包含许多属性，包括人员的公用名（cn）、姓氏（sn）和电话号码（telephoneNumber）。
LDIF还可以用于定义LDAP目录的架构。要想实现这一切，可以使用LDIF文件中称为LDIF指令的特定条目来创建对象类及其属性。对于每个属性，LDIF都有指令来支持定义语法、搜索匹配规则和排序规则。
LDAP对象标识符
LDAP使用对象标识符（OID）来唯一引用属性、语法、对象类和扩展控件。OID是一系列句点分隔的整数（或字符串标识符），并由Internet编号分配机构（IANA）分配。LDAP OID与许多网络管理员所熟悉的简单网络管理协议（SNMP）管理信息库（MIB）所用的OID是一样的。
OID必须是唯一的；如果您需要为自己的组织建立自定义架构，应从IANA获取专用企业编号。当有了专用企业编号之后，就可以创建自己的架构，而不会与现有的任何标准或专用架构冲突。
有关OID的详细信息，请访问IANA网站：http://www.iana.org/numbers.html。您应在“E”下查找企业编号条目。
相关的RFC
以下RFC描述LDAP协议、LDAP内标准属性的表示法，以及LDAP和X.500之间的关系。如果需要了解特定标准的细节，您只需阅读相应的RFC即可。
RFC 1777，“轻型目录访问协议”
RFC 1778，“标准属性语法的字符串表示法”
RFC 1779，“可分辨名称的字符串表示法”
RFC 2247，“在LDAP / X.500可分辨名称中使用域”
RFC 2251，“轻量级目录访问协议（v3）”
RFC 2252，“属性语法定义”
RFC 2253，“可分辨名称的UTF-8字符串表示法”
RFC 2254，“LDAP搜索筛选器的字符串表示法”
RFC 2255，“The LDAP URL格式”
RFC 2256，“面向与LDAP v3共同使用的X.500（96）用户架构概述”
使用LDAP进行网络身份验证
LDAP身份验证涉及绑定到LDAP服务器上的实体。根据接受还是拒绝该实体的凭据来确定绑定操作的成败。如果绑定成功，则实体通过身份验证；如果失败，则实体没有通过身份验证。
要想使用LDAP对UNIX和Linux登录或服务进行身份验证，需要与LDAP可插入式身份验证模块（PAM）结合使用。与设计作为身份验证机制的Kerberos不同，LDAP身份验证是为保护目录事务专门设计的。将LDAP身份验证用于除LDAP目录访问之外的其他目的，可能导致性能问题。这是因为LDAP目录服务不是为处理大量身份验证请求而设计的，而非常适用于进行目录事务处理。
LDAP浏览器软件
（本文引用自：http://www.microsoft.com/china/technet/itsolutions/migration/unix/usecdirw/01wsdsu.mspx）
本文转自
http://outdoego.blog.163.com/blog/static/16930182200791424925705/
LDAP的发展历史
LDAP（Light-weight Directory Access Protocol）是在国际电报电话咨询委员会（CCITT）和国际标准化组织（ISO）联合开发的许多标准的基础上建立的。CCITT现在称为国际电信联盟（ITU）。ITU和ISO的目标是定义一个通用的目录标准，尽可能包括最广泛的目录服务。所开发的标准将构成面向CCITT和ITU开发的开放系统互连（OSI）网络模型的目录服务。
当开发该目录标准时，标准委员会中的ITU和ISO成员考虑问题的优先顺序不同。大部分ITU成员是全国性的电话运营商，他们希望获得将提供电话号码和电子邮件地址目录服务的标准。相反，ISO成员最感兴趣的是提供面向OSI应用程序的命名服务。最终的标准X.500是一个既复杂又全面的标准，很难实施，而且成本高昂，需要运行复杂的OSI网络协议。
X.500的出现
该标准旨在拥有一个分布全球的目录，并且带有标准访问接口。X.500目录标准极其复杂。
作为其设计操作平台的OSI网络协议也比现在通常使用的传输控制协议，Internet 协议（TCP/IP）套件复杂得多。
X.500标准最初由CCITT于1990 年作为《X.500蓝皮书建议》发布并由ISO于1991年作为《ISO / IEC 9594：目录》发布。从那时起，X.500已经得到发展和增强，并在1993年和1997年两次更新。
X.500拥有四个核心组件模块：
信息模块，信息模块定义了目录存储信息的方式。X.500在“属性”中存储信息，它是“对象类”的成员。每个属性都有语法定义、搜索规则和排序规则。
命名模型，命名模型定义引用每个条目的方式。在LDAP目录中，条目被组织在一个称为目录信息树（DIT）”的层次树中。
功能模型，功能模型是目录客户端与目录进行通信的方法。在X.500中，称为“目录用户代理（DUA）”的客户端使用称为“目录访问协议（DAP）”的复杂协议，与称为“目录系统代理（DSA）”的目录服务器进行通信。DAP 在OSI 网络协议堆栈上运行。
安全模型，安全模型提供了根据目录进行身份验证的方法，以及授权客户端访问目录的方法。
X.500中的大部分特性已经被转移给LDAP。
到LDAP的过渡
X.500接受和实施的主要问题是其过于复杂，并且实施和管理相关成本非常高。为了提高X.500目录的可接受性，Internet工程任务组（IETF）决定定义新的访问协议。该协议更简单，不依赖于OSI堆栈，而使用TCP/IP堆栈。这产生了两个新协议：目录辅助服务（Directory Assistance Service，DAS）和有效实施X.500的目录接口（Directory Interface to X.500 Implemented Efficiently，DIXIE）。
DAS和DIXIE的问题是它们是针对与X.500的某一具体实施配合工作而设计的。LDAP由IETF开发，用于消除这一限制。LDAP使用TCP/IP作为其网络传输协议，与目录实施无关，并使用DAP中的一小部分操作。
LDAP旨在作为访问X.500目录的轻型方法。然而，随着时间的推移，情况越来越明显，对X.500 目录服务器的访问大部分是通过LDAP协议进行的。当这一情况变得清晰时，目录服务器被设计和实施成只能通过LDAP访问。这些服务器不再有X.500目录服务器中的复杂性，其实施和管理费用也更低。其副作用是，LDAP服务器还拥有比X.500目录服务器更出色的性能。
LDAP的当前版本是LDAP v3。LDAP v1没有作为标准发布。LDAP v2于1995年3月公布，并在三个RFC中进行了定义：RFC 1777、RFC 1778和RFC 1779。LDAP v2在RFC 3494中停止作为标准使用。
IETF中的目录访问、搜索和索引（ASID）工作组开发了LDAP v3。LDAP v3对LDAP v2的增强包括：
使用面向所有文本字符串属性的UTF-8，以便支持扩展的字符集。
目录保留以便自己使用的可操作属性（例如，当其他属性被修改时记录日期和时间）。
检索，允许服务器将客户端导向可能拥有该客户端所请求的信息的其他服务器。当客户端进行的操作不能得到本地服务，并且LDAP服务器知道其他LDAP服务器可以处理此操作时，LDAP服务器可以将索引返回到LDAP客户端。
目录中发布的架构，允许客户端发现服务器所支持的对象类和属性。这是通过根对象（rootDSE）上的对象提供，供客户端使用。
使用了X.500（93）架构的主要部分。注意X.500（93）是指1993年发布的X.500版本。在OSI社区中使用这种方法来指标准的版本。
扩展搜索操作，允许对结果分页和分类，以及客户端定义的搜索和分类控制。
通过简单身份验证和安全层（SASL）机制实现的更强的安全性。
现在支持扩展操作和控制，使LDAP v3能够在不改变标准协议的情况下进行扩展。
LDAP v3可向后兼容LDAP v2。LDAP v3服务器的一个要求是LDAP v2客户端要能够与之连接。LDAP v3作为操作系统、网络操作系统、目录服务、应用程序（比如：电子邮件服务器）和客户端应用程序的组成部分而得到广泛实施。
LDAP目录服务概述
LDAP是目录访问协议的一个标准。它定义与目录服务进行通信所使用的操作，如何找到目录中的实体，如何描述实体属性，以及许多安全特性。这些安全特性可用于对目录进行身份验证，控制对目录中的实体的访问。
LDAP标准中没有定义在目录服务器上存储信息的方式。为实施LDAP服务器，使用了许多不同的技术。这些技术包括简单的平面文件、索引文件和相关数据库。无论使用什么技术来实施目录，从LDAP客户端对目录的所有访问都使用相同的标准协议：LDAP。为此，尽管存在不同的内容结构，这些目录都被称为LDAP目录服务器。
下面的关键方面描述了LDAP协议的特征：
该协议直接通过TCP和UDP传送。TCP用于面向连接的传输（已经确认接收到数据），而UDP用于无连接的传输（未确认是否发送或接收数据）。
大多数协议数据元素可以被编码成二进制字符串（例如，可分辨名称）。
可以将到其他服务器的索引返回客户端。
SASL机制可以与LDAP共同使用，以提供相关的安全服务。
通过使用国际标准化组织（ISO）10646 字符集，可以使属性值和可分辨名称适用于在国际上使用。
该协议可以扩展，以支持新的操作，可以使用控制能力来扩展现有操作。
架构通过供客户端使用的根对象上的属性来发布。
LDAP中定义的组件模型与X.500中定义的组件模型相同。
信息模型
目录必须有一种存储条目相关信息的方法。条目是目录的基本单位。信息模型提供描述条目属性所必需的数据结构和数据类型。每个属性都有一个名称以及单个值或多个值。这些值必须符合为该特殊属性定义的特定语法。属性语法的示例包括Unicode字符串、二进制和整数。除此之外，目录还要求可能通过其属性值来搜索特定条目。为了改善这一点，可以定义每个属性的匹配规则。这些规则指定：
搜索将如何匹配属性中包含的值。
属性如何排序的定义。
与条目相关的属性和特征在条目的对象类中定义。架构中拥有对象类和属性的定义。LDAP目录服务器中使用了三类对象类定义：
结构对象类，结构对象类表示实际的对象（比如：人）。一个实体必须属于一个且只属于一个结构对象类。
辅助对象类，辅助对象类用于扩展结构对象类。它本身没有什么任何意义。
抽象对象类，抽象对象类只用作派生类的祖先。
命名模型
命名模型定义提及每个条目的方式。在LDAP目录中，条目被组织在称为目录信息树（DIT）的层次树中。树中的每个节点都是一个条目，该条目可能存储信息，也可能是其他条目的容器。有两种方法提及树中的条目：使用其相对可分辨名称（RDN）或其可分辨名称（DN）。RDN 在目录中是唯一的，而DN是全局唯一的。
属性的RDN可能是对象的公用名（cn），如此处所示：
cn="Michael Allen"
当只使用一个属性不能确保唯一性时，还可以由多个属性值构成RDN；例如：
cn="Michael Allen"+ou="Engineering"
本例中的加号（+）表明该RDN是多值的。当组织中有两名员工都叫“Michael Allen”时，多值RDN的实用性显而易见。如果他们属于两个不同的部门，可以使用由部门唯一限定的RDN，如本例中“组织单位（ou）”属性所定义。
Michael Allen的条目的DN可能是：
cn="Michael Allen",dc="example",dc="com"
在这种情况下，对象不只在本地目录中，而且在全局中被唯一定义。“域组件（dc）”属性值用于唯一定义目录服务器的DNS域名。
在LDAP中，目录的命名上下文能够以地理或域名格式来定义。地理格式是X.500中定位目录的主要方法，LDAP服务器中也仍然使用该方法。然而，通常使用DLAP服务器的域名作为其命名上下文，因为域名在Internet上是全局唯一的。
功能模型
功能模型是目录客户端用来与目录进行通信的方法。这就是LDAP协议。LDAP提供以下操作：
询问 －－ 搜索目录
修改 －－ 更新、添加或删除目录中的条目
身份验证和控制 －－ 对目录进行身份验证（绑定操作）
安全模型
安全模型为根据目录进行身份验证以及授权客户端控制对目录的访问提供了方法。安全模型包括两个组件：
使用LDAP的身份验证绑定
对目录中的对象的访问控制
对LDAP的身份验证将在本节后面的“使用LDAP进行网络身份验证”部分中介绍。当通过身份验证后，客户端只能像目录的访问控制列表（Access Control List，ACL）中定义的那样使用LDAP目录。ACL在LDAP目录中的实施是依赖于实施的。
LDAP交换格式
LDAP目录可以使用标准注释来交换数据和架构定义。该注释称为LDAP交换格式（LDIF）。LDIF拥有一个简单的文本文件格式，其中包括：
使用空行分隔，表示单一实体的条目
以#字符开头的注释
向属性的值的分配
教授如何使用LDIF剖析程序解释条目的指导
下例中提供了显示个人实体定义的示例LDIF文件。该LDIF文件可用于在LDAP目录中创建一个实体。
# This is a comment
dn:cn=Michael Allen,cn=Users,dc=example,dc=com
objectClass:person
cn:Michael Allen
sn:Reid
telephoneNumber:555-0100
最后一行是空行。该文件使用DN定义实体：
cn=Michael Allen,cn=Users,dc=example,dc=com
该条目是对象类person的成员。对象类person包含许多属性，包括人员的公用名（cn）、姓氏（sn）和电话号码（telephoneNumber）。
LDIF还可以用于定义LDAP目录的架构。要想实现这一切，可以使用LDIF文件中称为LDIF指令的特定条目来创建对象类及其属性。对于每个属性，LDIF都有指令来支持定义语法、搜索匹配规则和排序规则。
LDAP对象标识符
LDAP使用对象标识符（OID）来唯一引用属性、语法、对象类和扩展控件。OID是一系列句点分隔的整数（或字符串标识符），并由Internet编号分配机构（IANA）分配。LDAP OID与许多网络管理员所熟悉的简单网络管理协议（SNMP）管理信息库（MIB）所用的OID是一样的。
OID必须是唯一的；如果您需要为自己的组织建立自定义架构，应从IANA获取专用企业编号。当有了专用企业编号之后，就可以创建自己的架构，而不会与现有的任何标准或专用架构冲突。
有关OID的详细信息，请访问IANA网站：http://www.iana.org/numbers.html。您应在“E”下查找企业编号条目。
相关的RFC
以下RFC描述LDAP协议、LDAP内标准属性的表示法，以及LDAP和X.500之间的关系。如果需要了解特定标准的细节，您只需阅读相应的RFC即可。
RFC 1777，“轻型目录访问协议”
RFC 1778，“标准属性语法的字符串表示法”
RFC 1779，“可分辨名称的字符串表示法”
RFC 2247，“在LDAP / X.500可分辨名称中使用域”
RFC 2251，“轻量级目录访问协议（v3）”
RFC 2252，“属性语法定义”
RFC 2253，“可分辨名称的UTF-8字符串表示法”
RFC 2254，“LDAP搜索筛选器的字符串表示法”
RFC 2255，“The LDAP URL格式”
RFC 2256，“面向与LDAP v3共同使用的X.500（96）用户架构概述”
使用LDAP进行网络身份验证
LDAP身份验证涉及绑定到LDAP服务器上的实体。根据接受还是拒绝该实体的凭据来确定绑定操作的成败。如果绑定成功，则实体通过身份验证；如果失败，则实体没有通过身份验证。
要想使用LDAP对UNIX和Linux登录或服务进行身份验证，需要与LDAP可插入式身份验证模块（PAM）结合使用。与设计作为身份验证机制的Kerberos不同，LDAP身份验证是为保护目录事务专门设计的。将LDAP身份验证用于除LDAP目录访问之外的其他目的，可能导致性能问题。这是因为LDAP目录服务不是为处理大量身份验证请求而设计的，而非常适用于进行目录事务处理。
LDAP浏览器软件
（本文引用自：http://www.microsoft.com/china/technet/itsolutions/migration/unix/usecdirw/01wsdsu.mspx）
本文转自
http://outdoego.blog.163.com/blog/static/16930182200791424925705/
扫一扫
889
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
