介绍
LDAP或轻量级目录访问协议是一种开放协议，用于存储和检索来自分层目录结构的数据。通常用于存储有关组织及其资产和用户的信息，LDAP是定义任何类型的实体及其质量的灵活解决方案。 对于许多用户，LDAP看起来很难理解，因为它依赖于特殊术语，使用一些不常见的缩写，并且经常被实现为更大的交互部分系统的组件。在本指南中，我们将向您介绍一些LDAP基础知识，以便您拥有使用该技术的良好基础。
什么是目录服务？
目录服务用于以键值类型格式存储，组织和呈现数据。通常，目录针对查找，搜索和读操作优化写操作，因此它们对于经常引用但很少更改的数据非常有效。 存储在目录服务中的数据在本质上通常是描述性的，并且用于定义实体的质量。将在目录服务中良好表示的物理对象的示例是地址簿。每个人都可以通过目录中的条目来表示，键值对描述他们的联系信息，营业地点等。目录服务在许多场景中是有用的，在这些场景中您想要定性的描述性信息。
什么是LDAP？
LDAP或轻量级目录访问协议是定义可以访问目录服务的方法的通信协议。更广泛地说，LDAP形式化目录服务中的数据应该被表示给用户的方式，定义用于在目录服务内创建数据条目的组件的需求，并且概述了使用不同的原始元素来组成条目的方式。 由于LDAP是开放协议，因此有许多不同的实现可用。 OpenLDAP项目是最受支持的开源变体之一。
基本LDAP数据组件
我们在上面讨论了LDAP是一种用于与目录数据库通信以查询，添加或修改信息的协议。然而，这个简单的定义表示支持该协议的系统的复杂性。 LDAP向用户显示数据的方式非常依赖于一些定义的结构组件之间的交互和关系。
属性
在LDAP系统中的数据本身主要存储在称为
属性的元素。属性基本上是键值对。与一些其他系统不同，键具有预定义的名称，由选择用于输入的objectClasses决定（我们稍后将讨论这一点）。此外，属性中的数据必须匹配属性的初始定义中定义的类型。 设置属性的值是通过以冒号和空格分隔的属性名称和属性值完成的。 称为属性的一个例子
mail ，它定义了一个电子邮件地址应该是这样的：
mail: admin@example.com
当引用属性及其数据时（不设置属性时），两边将以等号连接：
mail=example.com
属性值包含要在LDAP系统中存储和访问的大多数实际数据。 LDAP中的其他元素用于结构，组织等。
条目
属性本身不是很有用。具有意义，就必须与什么
有关 。 在LDAP，您使用的
条目中的属性。条目基本上是用于描述某事物的名称下的属性的集合。 例如，您可以为系统中的用户或清单中的每个项目输入一个条目。这大致类似于关系数据库系统中的行或地址簿中的单个页面（这里的属性将表示每个模型中的各个字段）。虽然属性定义了某物的质量或特性，但条目通过简单地在名称下收集这些属性来描述物品本身。 LDIF（LDAP数据交换格式）中显示的示例条目如下所示：
dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
objectclass: person
sn: Ellingwood
cn: Justin Ellingwood
上述示例可以是LDAP系统中的有效条目。
DIT
当您开始熟悉LDAP时，很容易识别由属性定义的数据仅表示对象的可用信息的一部分。其余的是在LDAP系统中找到条目的位置以及这意味着的关系。 例如，如果可能有用户和库存项目的条目，那么某人如何能够告诉他们？区分不同类型的条目的一种方式是通过建立关系和组。这主要是创建条目时放置条目的函数。条目都添加到LDAP系统在树上叫
数据信息树木或树枝
DITS。 DIT表示类似于文件系统的组织结构，其中每个条目（除了顶级条目之外）只有一个父条目，并且在其下面可以具有任何数量的子条目。由于LDAP树中的条目可以表示任何内容，因此一些条目将主要用于组织目的，类似于文件系统中的目录。 这样，您可能有一个“人员”条目和一个“inventoryItems”条目。您的实际数据条目可以创建为这些的孩子，以更好地区分它们的类型。您的组织条目可以任意定义，以最好地表示您的数据。 在最后一节中的示例项中，我们看到的DIT的一个指示
dn行：
dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
此行称为条目的可分辨名称（稍后将对此进行说明），用于标识条目。它的功能类似于返回DIT根目录的完整路径。在这种情况下，我们有称为条目
sn=Ellingwood ，我们创建。 直接父称为条目
ou=people这可能是被用作描述人的条目的容器。 从派生此项的父母
digitalocean.com域名，其功能是作为我们的DIT的根。
定义LDAP数据组件
在最后一节中，我们讨论了如何在LDAP系统中表示数据。然而，我们还必须谈论如何定义存储数据的组件。例如，我们提到数据必须匹配为每个属性定义的类型。这些定义来自哪里？让我们从复杂性的底部开始，并努力工作。
属性定义
属性使用相当复杂的语法来定义。它们必须指明属性的名称，可用于引用属性的任何其他名称，可以输入的数据的类型以及各种其他元数据。此元数据可以描述属性，告诉LDAP如何排序或比较属性的值，并告诉它如何与其他属性相关。 例如，这是对的定义
name属性：
attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
在
'name'为属性的名称。第一行中的数字是分配给属性的全局唯一OID（对象ID），以将其与每个其他属性区分开。条目的其余部分定义如何在搜索期间比较条目以及具有指示在哪里找到属性的数据类型要求的信息的指针。 属性定义的一个重要部分是属性是否可以在条目中被多次定义。例如，定义可以定义每个条目仅定义一个姓氏，但是“侄子”的属性可以允许在单个条目中多次定义该属性。属性是默认情况下，多值，并且必须包含
SINGLE-VALUE标志，如果他们可能只是每个条目设置一次。 属性定义比使用和设置属性复杂得多。幸运的是，在大多数情况下，你不必定义自己的属性，因为最常见的属性包含在大多数LDAP实现中，而其他可以轻松导入。
ObjectClass定义
属性被称为
对象类的实体内收集。 ObjectClasses只是关联属性的分组，在描述一个特定的事情时是有用的。例如，“person”是一个objectClass。 项获得通过设置称为一个特殊的属性使用一个对象类的属性能力的
objectClass ，命名对象类要使用。 事实上，
objectClass是您可以在项中设置不指定一个进一步的对象类的唯一属性。 所以，如果你正在创建一个条目来形容一个人，包括
objectClass person （或任何由人产生的更具体的个人objectClasses的-我们将讨论这个版本），您可以使用所有对象类中的属性：
dn: . . .
objectClass: person
然后，您可以在条目中设置这些属性：
- cn：通用名
- description ：入门的人读的说明
- seeAlso：参考相关条目
- sn：姓
- telephoneNumber：一个电话号码
- userPassword ：一个用户密码
该
objectClass属性可以多次使用，如果你需要从不同的对象类的属性，但也有决定什么是可以接受的规则。 ObjectClasses被定义为几种“类型”之一。 两种主要类型的对象类的是
结构性的或
辅助 。 条目
必须恰好一个结构类，但可以具有用于增强提供给类的属性零个或多个辅助类。结构对象类用于创建和定义条目，而辅助对象类通过额外属性添加附加功能。 对象类定义确定是否所需要他们提供的属性（由a指示
MUST规范）或可选的（由一个指示
MAY规范）。 多个对象类可以提供相同的属性和属性的
MAY和
MUST分类可能会有所不同对象类为对象类。 作为一个例子，在
person的objectClass的定义如下：
objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
这被定义为结构对象类，意味着它可以用于创建条目。创建
必须设置入口
surname和
commonname属性，并可以选择设置
userPassword ，
telephoneNumber ，
seeAlso ，或
description属性。
模式
对象类定义和属性定义，反过来，在称作
模式构建体组合在一起。与传统的关系数据库不同，LDAP中的模式只是相关objectClasses和属性的集合。单个DIT可以具有许多不同的模式，以便它可以创建所需的条目和属性。 模式通常会包含其他属性定义，并可能需要在其他模式中定义的属性。例如，
person是我们上面所讨论的对象类要求
surname或
sn属性来使用任何条目设置
person对象类。如果这些定义未在LDAP服务器本身内定义，则可以使用包含这些定义的模式将这些定义添加到服务器的词汇表中。 模式的格式基本上只是上述条目的组合，如下所示：
. . .
objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )
attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )
. . .
数据组织
我们已经涵盖了用于在LDAP系统中构造条目的常见元素，并讨论了如何在系统中定义这些构建块。但是，我们还没有详细讨论如何在LDAP DIT中组织和组织信息本身。
将条目放置在DIT中
DIT仅仅是描述现有条目的关系的层次。创建后，每个新条目必须通过将其自身作为现有条目的子代“挂钩”到现有DIT。这创建了一个树状结构，用于定义关系和分配含义。 DIT的顶部是最宽泛的分类，每个后续节点在某种程度上是后代的。通常，最顶部条目简单地用作指示使用DIT的组织的标签。这些条目可以不管对象类所需的，但通常他们使用域组件构建（
dc=example,dc=com与相关的LDAP管理信息
example.com ），位置（
l=new_york,c=us对于一个组织或在纽约段），或组织段（
ou=marketing,o=Example_Co ）。 用于组织（像使用文件夹）项经常使用的organizationalUnit对象类，它允许使用称为简单的描述属性标签
ou= 。 这些通常用于顶层的DIT条目下的一般类别（之类的东西
ou=people ，
ou=groups ，和
ou=inventory是常见的）。 LDAP被优化用于沿着树而不是在树中上下查找信息，因此通常最好保持DIT层级相当浅，具有通常的组织分支和通过分配特定属性指示的进一步细分。
命名和引用DIT中的条目
我们通过属性引用条目。这意味着每个条目必须具有在DIT层次结构中其级别上无歧义的一个属性或一组属性。属性此属性或者组称为条目的
相对可分辨名称或
RDN，它的功能就像一个文件名。 要明确地引用条目，您使用条目的RDN与其所有父条目的RDN组合。这个RDN链会回到DIT层次结构的顶部，并为所讨论的条目提供一个明确的路径。我们称这条产业链的RDN条目的
专有名称或
DN的。您必须在创建期间指定条目的DN，以便LDAP系统知道在哪里放置新条目，并且可以确保条目的RDN没有被另一个条目使用。 作为一个类比，您可以将RDN视为相对文件或目录名称，就像您在文件系统中看到的那样。另一方面，DN更类似于绝对路径。一个重要的区别是，LDAP的DN包含在
左侧的最具体的值，而文件路径包含在
右手侧的最具体的信息。 DN使用逗号分隔RDN值。 例如，对于一个名为John Smith本人的记项可能被放置在一个“人”项下的组织下
example.com 。由于组织中可能有多个John Smith，因此用户ID可能是条目的RDN的更好选择。条目可能指定如下：
dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1
我们不得不使用
inetOrgPerson对象类来获得访问
uid在这种情况下属性（我们仍然可以访问所有的定义属性的
person对象类，我们将在下一节中看到）。
LDAP继承
当谈到它时，LDAP系统中的数据彼此之间的关系大部分是层次，继承和嵌套的问题。 LDAP最初似乎不寻常的许多人，因为它在其设计中实现一些面向对象的概念。这主要来自于我们之前讨论的类的使用，以及继承的可用性，我们现在将讨论它们。
ObjectClass继承
每个objectClass是描述该类型的对象的特性的类。 然而，与简单继承不同，LDAP中的对象可以并且通常是多个类的实例（一些编程语言通过多重继承提供类似的功能）。这是可能的，因为LDAP对类的概念只是它必须或可能具有的属性的集合。这允许一个条目（虽然只有一个被指定的多个类
STRUCTURAL的objectClass可以和必须存在），导致在对象只是具有访问与最严格的MUST或者可声明采取优先属性的合并的集合。 在其定义中，objectClass可以标识从其继承其属性的父objectClass。这是通过使用
SUP随后对象类要继承。 例如，
organizationalPerson对象类是这样开始的：
objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
. . .
继对象类
SUP标识符是父对象类。 家长必须共享所定义的对象类的类型对象类的（如
STRUCTURAL或
AUXILIARY ）。子objectClass自动继承父级的属性和属性要求。 当在一个条目中分配一个objectClass时，你只需要指定一个继承链的最特定的后代，就可以一直访问这些属性。在最后一节中，我们使用这个指定
inetOrgPerson为我们的约翰·史密斯进入的唯一对象类同时还具有访问在定义的属性
person和
organizationalPerson对象类。 在
inetOrgPerson继承层次是这样的：
inetOrgPerson -> organizationalPerson -> person -> top
几乎所有objectClass继承树以一个特殊的objectClass结尾，称为“top”。这是一个抽象的objectClass，其唯一的目的是要求设置objectClass本身。它用于指示继承链的顶部。
属性继承
以类似的方式，属性本身可以在定义期间列出父属性。然后，该属性将继承在父属性中设置的属性。 这通常用于制作更具体的一般属性版本。例如，surname是一种名称，可以使用所有相同的方法来比较和检查相等性。它可以继承这些质量以获得“名称”属性的一般形式。事实上，实际的姓名定义可能只包含一个指向父属性的指针。 这是有用的，因为它允许创建对于人们解释元素有用的特定属性，即使其一般形式保持不变。所述的遗传
surname属性我们这里讨论有助于人姓和更一般的名称进行区分，但比该值的含义外，还有一个姓氏和名字到LDAP系统之间的差别不大。
LDAP协议变体
我们在开始时提到LDAP实际上只是定义用于处理目录服务的通信接口的协议。这通常被称为LDAP或ldap协议。 值得一提的是，您可能会看到一些常规格式的变体：
- ldap://：这是基本的LDAP协议，允许结构化访问目录服务。
- ldaps://：该变体是用来表示通过SSL / TLS的LDAP。正常的LDAP流量不加密，虽然大多数LDAP实现支持这一点。这种加密LDAP连接的方法实际上已被弃用，建议使用STARTTLS加密。如果您通过不安全的网络操作LDAP，强烈建议使用加密。
- ldapi://：这是用来表示在一个IPC LDAP。这通常用于与管理目的的本地LDAP系统安全连接。它通过内部套接字进行通信，而不是使用暴露的网络端口。
所有三种格式都使用LDAP协议，但是最后两个格式指示有关如何使用LDAP协议的其他信息。
结论
您应该非常了解LDAP协议以及LDAP实施向用户表示数据的方式。了解系统的元素如何相互关联以及它们获取属性的方式，使得管理和使用LDAP系统更简单，更可预测。
