介绍
LDAP(Lightweight Directory Access Protocol)是一个用于存储和从等级目录结构中获取数据的开放协议,通常用于存储有关组织及其资产和用户的信息,LDAP是定义任何类型的实体及其属性的灵活解决方案。
对于许多用户来说,LDAP可能很难理解,因为它依赖于特殊的术语,使用一些不寻常的缩写,并且通常作为一个更大的互动部件系统的组成部分实施。
什么是 Directory 服务?
一个目录服务用于存储、组织和呈现数据以关键值类型格式. 通常,目录是针对搜索、搜索和读取操作的优化,所以它们对于经常引用但不经常更改的数据非常有效。
存储在目录服务中的数据通常具有描述性质,并用于定义实体的品质. 一个在目录服务中表现良好的物理对象的例子是地址簿. 每个人都可以被目录中的条目所代表,关键值对描述他们的联系信息,业务位置等。
LDAP是什么?
LDAP,或轻量级目录访问协议,是一种通信协议,它定义了目录服务可以访问的方法。更广泛地说,LDAP塑造了目录服务中的数据应该向用户呈现的方式,定义了用于创建目录服务中的数据输入的组件的要求,并概述了不同原始元素用于组成输入的方式。
由于LDAP是一个开放的协议,所以有许多不同的实现可用,OpenLDAP项目是最受支持的开源版本之一。
LDAP数据基本组件
我们在上面讨论了LDAP是如何用来与目录数据库进行通信以查询、添加或修改信息的协议,但是,这个简单的定义错误地表示了支持该协议的系统的复杂性。
属性
LDAP系统中的数据本身主要存储在称为 属性的元素中。属性基本上是关键值对,与其他一些系统不同的是,密钥有预定义的名称,这些名称是由所选入的对象命令(我们将稍微讨论)。
设置一个属性的值是用属性名称和属性值分隔一个 kolon和一个空间完成的,一个名为邮件的属性,定义电子邮件地址的示例将看起来如下:
1mail: [email protected]
当引用属性及其数据时(当不设置时),相反,两个侧面被一个等级符号连接在一起:
1mail=example.com
属性值包含您想要存储和访问 LDAP 系统中的实际数据的大部分,LDAP 中的其他元素用于结构、组织等。
入口
属性本身并不非常有用. 要有意义,它们必须与某些东西相关联。 在LDAP中,你使用一个 entry中的属性. 一个条目基本上是用来描述某些东西的名字下的属性集合。
例如,您可以为系统中的用户或库存中的每个项目创建一个条目,这大致类似于关系数据库系统中的行或地址簿中的单页(这里的属性代表了这些模型中的各个领域)。
在LDIF(LDAP Data Interchange Format)中显示的示例条目将看起来像这样:
1dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
2objectclass: person
3sn: Ellingwood
4cn: Justin Ellingwood
上面的例子可能是LDAP系统中的有效条目。
说
当你开始熟悉LDAP时,很容易认识到,属性定义的数据仅代表对一个对象的可用信息的一部分。
例如,如果有可能有用户和库存项目的条目,那么如何可以将它们分开? 区分不同类型的条目的一种方法是建立关系和组。
DIT 代表一个类似于文件系统的组织结构,每个条目(除了顶级条目)都有一个准确的家长条目,并且可能有任何数量的儿童条目,因为 LDAP 树中的条目可以代表任何东西,有些条目主要用于组织目的,类似于文件系统中的目录。
这样,你可能会有一个人的条目和一个库存项目的条目。 你的实际数据条目可以被创建为这些条目的子女,以便更好地区分它们的类型。
在最后一节的示例输入中,我们在dn行中看到DIT的一个标志:
1dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
这个行被称为输入的杰出名称(稍后再说)并被用来识别输入. 它作为一个完整的路径返回DIT的根源。 在这种情况下,我们有一个名为sn=Ellingwood的输入,我们正在创建一个直接的家长是名为ou=people的输入,这可能是用于描述人们的输入的容器。 这个输入的父母来自digitalocean.com域名,它作为我们的DIT的根源。
LDAP数据组件的定义
在最后一节中,我们讨论了如何在LDAP系统中表示数据,但我们也必须谈论如何定义存储数据的组件,例如,我们提到数据必须匹配每个属性定义的类型。
属性定义
属性是用相当相关的语法定义的,它们必须表示属性的名称,可以用来参考属性的任何其他名称,可以输入的数据类型以及各种其他元数据。
例如,这是名称属性的定义:
1attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'
2 EQUALITY caseIgnoreMatch
3 SUBSTR caseIgnoreSubstringsMatch
4 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
名称是属性的名称。第一个行中的数字是一个全球独特的OID(对象ID),分配给属性,以使其与其他所有属性区分开来。
属性定义的一个重要部分是,属性是否可以在一个条目中定义多次,例如,该定义可能定义一个姓氏只能在每个条目中定义一次,但一个属性niece可能允许该属性在一个条目中定义多次。
属性定义比使用和设置属性要复杂得多. 幸运的是,在大多数情况下,您不必定义自己的属性,因为最常见的属性包含在大多数LDAP实现中,而其他属性可以轻松导入。
对象定义
属性被收集到名为 objectClasses的实体中。ObjectClasses只是对某一特定事物的描述有用的相关属性的组合。
输入可以通过设置一个名为objectClass的特殊属性来使用objectClass的属性,命名您想要使用的objectClass。
因此,如果您正在创建一个记录来描述一个人,包括objectClass person(或更具体的人物objectClass 由人衍生,我们将在稍后讨论)允许您使用该objectClass 中的所有属性:
1dn: . . .
2objectClass: person
然后你将有能力在输入中设置这些属性:
- cn: 通用名称
- 描述:人文可读的条目描述
- seeAlso: 参考相关条目
- sn: 姓名
- telephoneNumber: 电话号码
- userPassword: 用户密码
如果您需要来自不同objectClass的属性,则可以多次使用objectClass属性,但有规则决定什么是可接受的。
两个主要类型的 ObjectClass 是 **结构性 ** 或 **辅助性 **. 输入 ** 必须有完全一个结构类,但可能有零或多个辅助类用于增加类可用的属性. 一个结构性 objectClass 用于创建和定义输入,而辅助性 objectClass 通过额外的属性添加额外的功能。
ObjectClass 定义决定它们提供的属性是否是必需的(由MUST规格表示)或可选的(由MAY规格表示)。
例如,人对象类是这样定义的:
1objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
2 MUST ( sn $ cn )
3 MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
这被定义为结构对象类,这意味着它可以用来创建一个条目。创建的条目必须设置姓氏和共同姓氏属性,并且可以选择设置用户密码,电话号码,参见或描述属性。
方案
ObjectClass 定义和属性定义相反,被组合到一个称为 schema的构造中。与传统的关系数据库不同,LDAP 中的方案只是相关的对象类和属性的集合。
方案通常会包含额外的属性定义,并可能需要在其他方案中定义的属性。例如,我们上面讨论的人对象类要求为使用人对象类的任何条目设置姓名或sn属性。
一个方案的格式基本上只是上述条目的组合,如下:
1. . .
2
3objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
4 MUST ( sn $ cn )
5 MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
6
7attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
8 DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )
9
10attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
11 DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )
12
13. . .
数据组织
我们已经涵盖了用于构建LDAP系统中的条目的常见元素,并谈到了这些构建块如何在系统中定义,但是,我们还没有谈到信息本身是如何在LDAP DIT中组织和结构化的。
将入口置于此
DIT只是描述现有条目之间的关系的层次结构,在创建时,每个新的条目必须插入现有条目,将自己定位为现有条目的子女。
DIT的顶部是每个随后的节点以某种方式下降的最广泛的分类。 通常,最顶部的条目只是用作标签,表示DIT用于的组织。 这些条目可以是任何所需的objectClass,但通常它们是使用域组件(dc=example,dc=com为与 example.com相关的LDAP管理信息),地点(l=new_york,c=us为纽约的一个组织或部分)或组织细分(ou=marketing,o=Example_Co)构建的。
用于组织的条目(如文件夹)通常使用组织单位对象类,允许使用一个简单的描述性属性标签称为ou= 这些条目通常用于顶级DIT条目下的一般类别(诸如ou=people,ou=groups和ou=inventory是常见的)。
在 DIT 中命名和引用条目
我们用其属性指向条目,这意味着每个条目必须有一个属性或属性组,在 DIT 层次上是明确的,这个属性或属性组被称为条目的 相对区别名称或 ** RDN**,它就像一个文件名。
要明确地参考一个条目,您使用该条目的 RDN 与其所有母条目的 RDN 结合使用。 RDN 链将返回 DIT 等级的顶部,并为该条目提供一个明确的路径。我们称此条目的 RDN 链为该条目的 区别名称或 DN。在创建过程中,您必须指定一个条目的 DN,以便LDAP 系统知道该条目的位置,并确保该条目的 RDN 不再被另一个条目使用。
作为一个类比,你可以认为RDN作为一个相对的文件或目录名称,正如你在一个文件系统中所看到的那样. 另一方面,DN更类似于绝对路径. 一个重要的区别是LDAP DNs包含最具体的值在 left-hand 侧,而文件路径包含最具体的信息在 right-hand 侧。
例如,一个名叫约翰·史密斯的人物的条目可能被放置在一个组织的人条目下,example.com。由于组织中可能有多个约翰·史密斯,用户 ID 可能对该条目的 RDN 是一个更好的选择。
1dn: uid=jsmith1,ou=People,dc=example,dc=com
2objectClass: inetOrgPerson
3cn: John Smith
4sn: Smith
5uid: jsmith1
我们不得不使用inetOrgPersonobjectClass来访问这个实例中的uid属性(我们仍然可以访问人objectClass中定义的所有属性,正如我们将在下一节中看到的那样)。
LDAP 继承
当涉及到这一点时,LDAP系统中的数据与彼此有关的大部分方式都是关于等级、继承和嵌套的问题。LDAP最初对许多人来说似乎不寻常,因为它在其设计中实施了一些面向对象的概念。
对象 遗产
每个objectClass 是描述该类型的对象的特性的一类。
然而,与简单的继承不同的是,LDAP中的对象可以并且往往是多个类的实例(有些编程语言通过多个继承提供类似的功能)。这可能是因为LDAP对一个类的概念只是它必须或可能具有的属性集合。
在其定义中,objectClass 可以识别一个主体objectClass 从中继承其属性。
1objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
2 . . .
继SUP标识符之后的 objectClass 是母体 objectClass. 母体必须共享被定义的 objectClass 类型(例如,STRUCTURAL 或 AUXILIARY)。
在分配一个 objectClass 时,您只需要指定一个继承链中最具体的后代才能访问所有属性. 在最后一节中,我们使用此项来指定inetOrgPerson作为我们 John Smith 条目的唯一对象Class,同时仍然可以访问人和组织人对象类中定义的属性。
1inetOrgPerson -> organizationalPerson -> person -> top
几乎所有的objectClass继承树都以一个特殊的objectClass命名为顶部结束,这是一个抽象的objectClass,其唯一的目的是要求objectClass本身设置。
属性继承
类似的方式,属性本身可以在定义过程中列出父母属性,属性将继承在父母属性中设置的属性。
例如,姓氏是姓氏类型,可以使用所有相同的方法来比较和检查平等性. 它可以继承这些属性以获得姓氏属性的一般形式。
这是有用的,因为它允许创建一个特定的属性,这对解释元素的人有用,即使它的总体形式保持不变。我们在这里讨论的姓氏属性的继承有助于人们区分姓氏和更一般的姓氏,但除了值的含义,在LDAP系统中姓氏和姓氏之间差异很小。
LDAP 协议变量
我们在开始时提到LDAP实际上只是定义与目录服务工作的通信接口的协议,这通常被称为LDAP或ldap协议。
值得一提的是,您可能会在常规格式中看到一些变体:
- ldap://:这是基本的LDAP协议,允许对目录服务进行结构化访问
- ldaps://:这种变体被用来表示LDAP通过SSL/TLS。正常的LDAP流量不加密,尽管大多数LDAP实现都支持这一点。这种加密方法实际上是贬值的,而建议使用STARTTLS加密。如果您在不安全的网络上运行LDAP,则强烈建议进行加密
- ldapi://:这被用来表示LDAP通过IPC。这通常用于安全地连接到本地的LDAP系统用于管理目的。它通过内部接口进行通信,而不是使用暴露的网络端口。
所有三种格式都使用LDAP协议,但最后两种格式提供有关如何使用该协议的额外信息。
结论
您应该对 LDAP 协议和 LDAP 实现对用户的数据的表现方式有相当好的理解,了解系统元素是如何相互关联的,以及它们的属性在何处,使得管理和使用 LDAP 系统更简单、更可预测。