LDAP概念、体系结构和设计.docxVIP

概念和体系结构本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.1 主题的内容。这个主题的权值为 3。 在本节中，学习： LDAP 和 X.500 技术规范 属性定义 目录名称空间 区别名 LDAP Data Interchange 格式 元目录 changetype 操作 LPIC-3 考试主要针对 Lightweight Directory Access Protocol（LDAP）的使用。因此，第一个目标是了解 LDAP 是什么、它的作用是什么以及这个概念背后的一些基本术语。了解了这些知识之后，就能够开始设计自己的目录并将应用程序与目录集成起来。LDAP 是什么？在讨论 LDAP 之前，先回顾一下目录的概念。目录的典型例子是电话簿，电话簿中按照字母表次序列出人名以及他们的电话号码和地址。每个人（或家庭）代表一个对象，电话号码和地址是这个对象的属性。一些对象是企业而不是个人，这些对象可能有传真号码或营业时间等属性。与印刷的目录不同，计算机目录本质上是层次化的，允许将对象放在其他对象下面，形成父-子关系。例如，可以扩展电话目录，让它包含代表城市地区的对象，每个个人和企业对象分别归入对应的地区对象。这些地区对象归入城市对象，城市对象进一步归入州或省对象，依此类推，形成图 1 这样的层次结构。这种结构会使印刷的目录更难使用，因为需要知道人名和地理位置才能进行查询，但是计算机可以对信息进行排序和搜索目录的不同部分，所以这不是个问题。图 1. 一个示例目录看一下图 1，Simpson 的记录表明的信息不仅仅是地址和电话号码。您还知道他处于 Springfield 城的东部。这个结构称为树。在这里，树的根是 Springfield 对象，其他对象代表分支的不同级别。这种基于目录的数据存储方式与您熟悉的关系数据库很不一样。为了比较这两种模型，图 2 显示在采用关系数据库模型的情况下电话数据的样子。图 2. 采用关系形式的目录数据在关系模型中，每种类型的数据是一个单独的表，允许存储不同类型的信息。每个表还有一个指向父表的链接，这样就能够保存对象之间的关系。注意，如果要添加更多的信息字段，就必须修改表的结构。请记住，目录模型没有对数据在磁盘上的存储方式施加任何限制。实际上，OpenLDAP 支持许多种后端，包括平面文件和 Structured Query Language（SQL）数据库。表在磁盘上的布局机制在很大程度上是对用户隐藏的。例如，Active Directory 提供一个 LDAP 接口来操作它的专有后端。LDAP 的历史LDAP 是在 Request for Comments（RFC）1487 中提出的，它作为一种访问 X.500 目录的轻量方式，替代比较复杂的 Directory Access Protocol（参见 参考资料 中这个 RFC 和相关 RFC 的链接）。X.500 是来自 International Telecommunication Union（ITU，以前称为 CCITT）的一组标准，指定了如何实现目录。您可能熟悉 X.509 标准，这个标准构成大多数 Public Key Infrastructure（PKI）和 Secure Sockets Layer（SSL）证书的核心。在此之后，LDAP 发展到了第 3 版，在 RFC 4511 中定义。最初，连接 X.500 数据库需要按照真正的 ITU 方式使用 Open Systems Interconnection（OSI）协议簇，这要求理解大量的协议文档。LDAP 使基于 Internet Protocol（IP）的网络能够连接相同的目录，而且所需的开发周期比使用 OSI 协议时短得多。最终，IP 网络的流行导致 LDAP 服务器的出现，这些服务器只支持必要的 X.500 概念。尽管 LDAP 和 IP 战胜了 X.500 和 OSI，但是目录数据的底层组织仍然符合 X.500。本教程中讨论的一些概念（比如区分名和对象标识符）都来自 X.500。X.500 是一种创建全局目录系统的方法，主要用来协助用于电子邮件的 X.400 系列标准。通过一些处理，LDAP 也可以用作全局目录，但是它主要在企业的内部使用。命名和属性在 LDAP 系统中，名称是非常重要的。名称使我们能够访问和搜索记录，而且名称常常暗示出记录在 LDAP 树中的位置。图 3 显示一个典型的 LDAP 树。图 3. 一个显示用户的典型 LDAP 树树的顶部（即根）是一个称为 dc=ertw,dc=com 的实体。dc 是 domain component 的简写。因为 ertw 在顶级域 .com 下面，所以它们被分成两个不同的单元。在使用 X.500 命名法时，用一个逗号连接名称的各个成分，新的成分添加在左边。从技术上说，也可以将根命名为 dc=，但是为了保持互操作性，最好将域名的各个成分分隔开（实际上，RFC 2247 建议采用分隔的域名成分）。dc=ertw,dc=com 惟一地标识树中的这个实体。按照 X.500 的说法，这称为区分名（distinguished name，DN）。DN 很像关系数据库中的主键，因为在树中只有一个实体具有给定的 DN。最顶部条目的 DN 称为 根 DN（Root DN）。在根 DN 下面是一个 DN 为 ou=people,dc=ertw,dc=com 的对象。ou 表示 organizational unit，可以确定它处于根 DN 下面，因为 ou 直接出现在根 DN 的左边。也可以将 ou=people 称为相对区分名（relative distinguished name，RDN），因为它在它的层次上是惟一的。按照递归术语来说，一个实体的 DN 就是它的 RDN 加上父实体的 DN。为了消除冗余，大多数 LDAP 浏览器只显示 RDN。沿着树向下移动到 cn=Sean Walberg,ou=people,dc=ertw,dc=com，就会发现一个人的记录。cn 表示 common name。但是，记录包含一些采用属性（attribute） 形式的额外信息。属性提供关于实体的额外信息。实际上，可以看到 DN 最左边的成分是重复的；在本例中，它是 cn 属性。从另一个角度来看，一个实体的 RDN 由这个实体的一个或多个属性组成。尽管 mail 和 description 很容易理解，但是 objectClass 的意义就不这么明显了。对象类是与某个实体类型对应的一组属性。一个对象类可能包含人的属性，另一个对象类包含 UNIX 帐户的属性。通过将两个对象类分配给一个实体，就可以存储两组属性。每个对象类有一个对象标识符（object identifier，OID），OID 惟一地标识它。对象类还指定属性，以及哪些属性是必需的，哪些是可选的。必需属性必须有数据，才能保存这个实体。对象类还标识保存的数据类型以及是否允许同名的多个属性。例如，一个人只能有一个职员编号，但是可以有多个名字（比如 Bob、Robert 和 Rob）。并非只有最底层的对象能够有相关联的对象类。称为容器（container） 的对象也有对象类和属性。people ou 是 organizationalUnit 类型的，它有一个描述属性和 ou=people，这些组成了 RDN。树的根是 dcObject 和 organization 类型的。根据对象中和对象下面的内容，可以知道将哪些对象类分配给对象。更多细节参见 模式 一节。根 DN 还定义树的名称空间（namespace），或者按照更技术性的说法，Directory Information Tree（DIT）。以 dc=ibm,dc=com 结尾的实体处于 图 3 所示的名称空间外边，而 Sean Walberg 的记录属于这个名称空间。但是要记住，一个 LDAP 服务器可能包含多个名称空间。一个有点儿抽象的概念称为根 DSE（Root DSE），它包含服务器上可用的所有名称空间的相关信息。DSE 表示 DSA-Specific Entry，DSA 表示 Directory System Agent（也就是 LDAP 服务器）。图 4 总结了与 LDAP 树相关联的术语。图 4. LDAP 术语最后，LDAP 树可以与其他树或数据源进行同步。例如，树的一个分支可能来自一个安全系统，另一个分支来自一个客户数据库，其他数据存储在 LDAP 服务器中。这称为元目录（meta-directory），可以作为单点登录等用途的单一数据源。LDIF 文件数据可以按照两种方式之一进入 LDAP 服务器。可以使用 LDAP 协议通过网络装载数据，也可以通过 LDAP Data Interchange Format（LDIF）格式的文件将数据导入服务器。在任何时候都可以使用 LDIF，比如在创建最初的树时，或者在以后某个时间批量添加数据或修改数据时。搜索的输出也可以保存为 LDIF 格式，这样可以方便解析或导入另一个服务器。LDIF 的完整规范在 RFC 2849 中（见 参考资料 中的链接）。添加记录清单 1 给出生成图 3 所示的树的 LDIF。清单 1. 一个填充树的简单 LDIF 文件 # This is a commentdn: dc=ertw,dc=comdc: ertwdescription: This is my company the description continues on the next line indented by one spaceobjectClass: dcObjectobjectClass: organizationo: ERTW.COMdn: ou=people,dc=ertw,dc=comou: peopledescription: Container for usersobjectclass: organizationalunitdn: cn=Sean Walberg,ou=people,dc=ertw,dc=comobjectclass: inetOrgPersoncn: Sean Walbergcn: Sean A. Walbergsn: Walberghomephone: 555-111-2222mail: description: Watch out for this guyou: Engineering 在讨论 LDIF 文件的细节之前，要注意属性名是不区分大小写的。也就是说，objectclass 与 objectClass 和 OBJECTCLASS 相同。许多人喜欢将每个单词的首字母大写，但是第一个单词除外，比如 objectClass、homePhone 和 thisIsAReallyLongAttribute。LDIF 的第一行是一个 UNIX 风格的注释，这种注释的前面是一个 hash 符号（#）。LDIF 文件是标准的 ASCII 文件，可以由人进行编辑，所以注释可能有帮助。LDAP 服务器会忽略注释。LDIF 文件中的记录由一个空行分隔，记录包含由冒号（:）分隔的属性和值的列表。记录以 dn 属性开头，这个属性标识记录的区分名。因此，图 1 显示三个记录，它们的 RDN 分别是 dc=ertw、ou=people 和 cn=Sean Walberg。选择属性现在，属性名可能会引起困扰。如何选择将哪个对象类分配给一个记录？如何查明哪些属性是可用的？如何知道 o 代表 organization？简单地说，解决这些问题的方法都是模式（在后面 模式 一节中讨论）。模式描述属性的意义。模式还将属性映射到对象类。在记录中添加一个对象类之后，就可以使用对象类中的属性。最后，要了解如何使用 LDAP 树。如果打算依靠树对 UNIX 帐户进行身份验证，用户最好有一个对象类，这个对象类为他们提供系统寻找的 userid 属性。看一下 图 1，可以看到第一个记录是树的根。首先出现的是区分名。然后是冒号分隔的所有属性和值的列表。值中的冒号不需要任何特殊处理。LDAP 工具知道第一个冒号是属性和值的分隔符。如果需要为一个属性定义两个值，那么只需在单独的两行上列出它们。例如，根对象定义了两个对象类。每个记录必须定义至少一个对象类。对象类进而要求某些属性必须存在。对于根对象，dcObject 对象类要求定义一个 domain component（即 dc）属性，organization 对象类要求定义一个 organization（即 o）属性。因为对象必须有一个与 RDN 对应的属性和值，所以需要通过 dcObject 对象类导入 dc 属性。对于有效的记录，o 属性并不是必需的。根对象上还使用 description 描述这个公司。这里的目的是演示换行格式。如果值需要跨越多行，那么每个新行应该以一个空格开头。请记住，指定多个属性：值对会定义这个属性的多个实例。图 1 中的第二个记录定义一个 organizationalUnit，这是人员对象的容器。第三个记录定义一个类型为 inetOrgPerson 的用户，这个类型提供了定义组织人员的常用属性。注意，定义了两个 cn 属性；一个也用在记录的 DN 中。第二个包含中间名的首字母，它用来帮助搜索，但是其格式首先必须满足 RDN 的定义条件。在用户记录中还有一个 ou 属性，它并不对应于这个用户所属的 organizationalUnit。总是能够通过解析 DN 找到用户对象所属的容器。这个 ou 属性引用用户定义的某些东西，在这个示例中是一个部门。服务器并不保证引用完整性，但是应用程序可以搜索 ou=Engineering,ou=Groups,dc=ertw,dc=com 这样的有效 DN。对添加记录的 LDIF 文件的惟一限制是，必须从根开始按次序构建树。图 1 显示先构建根对象，然后是一个 ou，然后是 ou 中的一个用户。构建了这个结构之后，就可以在 people 容器中直接添加用户，但是如果要使用一个新容器，就必须先创建它。添加对象所需的 LDIF 相当简单。如果必须修改或删除对象，格式就会更复杂。LDIF 定义一个 changetype，它可以是以下操作之一： add：添加一个项目（默认）。 delete 删除 DN 指定的项目。 modrdn 修改当前容器中指定对象的名称，或者将这个对象移动到树的其他部分。 moddn 与 modrdn 同义。 modify 修改当前 DN 中的属性。 删除用户删除一个项目是最简单的情况，只需要 dn 和 changetype。清单 2 显示如何删除一个用户。清单 2. 用 LDIF 删除一个用户 dn: cn=Fred Smith,ou=people,dc=ertw,dc=comchangetype: delete操作 DN操作对象的 DN 稍微复杂一点儿。尽管有两个命令 moddn 和 modrdn，但是它们的作用是相同的！这个操作由三个部分组成：1. 指定新的 RDN（DN 最左边的成分）。 2. 决定记录中新的 RDN 是否应该替换旧的 RDN，还是应该保留旧的 RDN。 3. （可选）通过指定新的父 DN，将记录转移到树的其他部分。 假设 Jane Smith 要将她的姓名改为 Jane Doe。首先需要修改她的 cn 属性来反映姓名的变化。因为新的姓名是引用她的主要方式，而且姓名是 DN 的组成部分，所以需要执行 moddn 操作（如果姓名不是 DN 的组成部分，那么这只是个属性修改，属性修改在下一节中讨论）。 第二个问题是，除了 cn: Jane Doe 之外，是否应该保留 cn: Jane Smith，这样就可以用这两个姓名搜索她。清单 3 给出执行这一修改的 LDIF。清单 3. 修改用户 RDN 的 LDIF # Specify the record to operate ondn: cn=Jane Smith,ou=people,dc=ertw,dc=comchangetype: moddn# Specify the new RDN, including the attributenewrdn: cn=Jane Doe# Should the old RDN (cn=Jane Smith) be deleted? 1/0, Default = 1 (yes)deleteoldrdn: 0清单 3 首先识别出 Jane 的记录，然后执行 moddn 操作。指定新的 RDN，它仍然使用 common name 类型，但是使用新的名称。最后，deleteoldrdn 指示服务器保留旧的名称。注意，newrdn 是 moddn 操作中惟一的必有选项，但是如果省略 deleteoldrdn，这个操作就会删除原来的 RDN。RFC 2849 指出，deleteoldrdn 是一个必需元素。如果要将新的 Jane Doe 转移到树的其他部分，比如转移到 ou=managers,dc=ertw,dc=com，那么 LDIF 必须指定这个新位置，见清单 4。清单 4. 将记录转移到树的其他部分 dn: cn=Jane Doe,ou=people,dc=ertw,dc=comchangetype: modrdnnewrdn: cn=Jane Doedeleteoldrdn: 0newsuperior: ou=managers,dc=ertw,dc=com奇怪的是，尽管必须指定新的 RDN，即使它与旧的 RDN 相同；而且 OpenLDAP 解析器现在要求有 deleteoldrdn，尽管在 RDN 保持不变的情况下它是没有意义的。在它们后面是 newsuperior，这是树中新的父节点的 DN。关于 modrdn 操作要注意的最后一点是次序问题，这与大多数其他 LDIF 格式不一样。changetype 之后是 newrdn，然后是 deleteoldrdn 和可选的 newsuperior。修改属性最后一种 changetype 操作是 modify，它用来修改记录的属性。通过前面对 moddn 的讨论可以看出，modify 显然不应该应用于记录的 DN 或 RDN。清单 5 演示对单个记录的几个修改。清单 5. 通过 LDIF 修改记录 dn: cn=Sean Walberg,dc=ertw,dc=comchangetype: modifyreplace: homePhonehomePhone: 555-222-3333-changetype: modifyadd: titletitle: network guy-changetype: modifydelete: mail-执行 modify 操作的 LDIF 看起来与其他 LDIF 很相似。首先是记录的 DN，然后是 changetype。在此之后是 replace:、add: 或 delete:，然后是属性。对于 delete，这些信息就够了。其他操作需要属性:值对。每个修改后面是空行上的一个连字符（-），最后一个修改也是如此。对于人和计算机来说，LDIF 的格式都很容易理解。LDIF 对于导入和导出大量数据是很有用的工具。目录设计本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.2 主题的内容。这个主题的权值为 2。在本节中，学习： 定义 LDAP 目录内容 目录的组织 如何计划适当的 Directory Information Trees 判断 LDAP 是否合适与其他任何工具一样，并非每种解决方案都适合使用 LDAP。在选用 LDAP 之前，必须问自己一些问题： 修改记录的频率有多高？主要是哪些修改？ 哪些系统要使用这些数据？ 对这些数据执行的查询是什么类型的？ 这些信息在本质上是否是层次化的？ LDAP 数据库面对的操作以读操作为主。人们每年只修改个人信息几次，但是查询属性的次数要多得多，比如将拥有一个文件的 UserID 解析为可打印的用户名。常常为 LDAP 数据编制索引来帮助服务器搜索数据，这意味着对底层数据的每个修改会导致对索引的多个修改。而且，LDAP 没有提供对树进行大量更新的简便方法，只能执行搜索，然后修改各个 DN。LDAP 规范没有定义关系数据库中常见的事务概念。事务确保其中的所有操作都成功，否则就将数据回滚到事务之前的状态（个别服务器可能会实现事务，但这不是规范的要求）。由于更新数据方面的这些限制和缺少事务概念，对于银行交易这样的场景，LDAP 不是合适的选择。了解数据的用户（即消费者）也很重要。如果没有消费者使用 LDAP，那么 LDAP 可能不合适。但是，LDAP 是一种极其简单的协议，大多数平台上的大多数语言都可以实现 LDAP。由于只定义了很少的操作，很容易将它集成到现有的应用程序中。LDAP 提供了搜索功能，但是无法与关系数据库的搜索功能相比。LDAP 服务器可能使用 SQL 存储底层数据，但是用户接触不到这个层次，无法使用 SQL。因此，用户只能使用 LDAP 服务器支持的搜索过滤器。本系列后续的文章会详细讨论这些过滤器，目前只需知道这些过滤器的功能很有限。可以执行一些强大的搜索，比如 “告诉我住在 Washington 的所有职员和住在 Texas 的超过 40 岁的职员”。但是，没有与 SQL GROUP BY 等效的语句。LDAP 最适合查找型的操作，比如 “告诉我 UID 为 4131 的职员的用户名” 和 “告诉我 Jim Smith 的所有下属的名字”。最后，要存储的信息在本质上应该是层次化的。可以在 LDAP 服务器上存储平面的数据列表，但是这可能会浪费资源。如果您回答了以上问题，而且断定 LDAP 就是正确的解决方案，就该设计目录树了。组织您的树首先要记住的一点是，谁都不希望以后对树进行重新组织。所以我们的目标是，对对象进行划分，让树的每个分支包含相似类型的对象，尽可能减少不得不移动对象的情况。这有两个原因。首先，移动对象是一种会引起争议的操作。第二，移动对象很麻烦，需要修改对象的 DN，然后必须更新引用这个对象的所有对象。根 DN树的根应该代表您的公司。RFC 2247 主张使用 dc 属性和 dc=example,dc=com 格式将公司的主域名映射为 DN。您的公司可能有许多互联网域名，但是其中应该有一个是首选的。另一种常见做法是在 local 顶级域名（TLD）下选择一个当前在互联网上还不存在的域名。Microsoft 一直建议对他们的 Active Directory 实现使用这个 TLD，尽管它不是保留的 TLD。如果不希望在根 DN 中使用域名，那么只需给一个对象设置 objectclass: organization，这会提供根 DN o=My Corporation。填充结构决定将什么放在 DIT 的下一级上比较困难。设计人员常常希望用一系列嵌套的 organizationalUnit 对象描述公司的组织结构，但是公司经常会重组，这会破坏第一条规则（尽可能不移动对象）。所以，应该考虑用属性存储公司的组织结构信息。根据 LDAP 服务器的用途和您选择的对象命名方式，可以把所有用户放在一个树中，也可以根据角色将他们分开。例如，可以为职员创建一个容器，为客户创建另一个容器，也可以把他们放在一个容器中。这个决策取决于您的意图和管理树的方式。如果销售部门负责管理客户列表，系统管理员负责管理职员列表，那么创建两个容器可能更合适。图 5 显示的 DIT 就划分为客户和用户两部分。模式本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.3 主题的内容。这个主题的权值为 3。 在本节中，学习： LDAP 模式概念 如何创建和修改模式 属性和对象类语法 到目前为止，我们几次提到了模式，但是还没有全面解释这个概念。模式（schema）是对象类及其属性的集合。模式文件以 LDAP 服务器可以理解的一种文本格式包含一个或多个对象类和属性。将模式文件导入 LDAP 服务器的配置，然后就可以在对象中使用对象类和属性。如果可用的模式无法满足需要，还可以创建自己的模式或者扩展现有的模式。LDAP 模式概念从技术上说，模式是一种对对象类和属性进行打包的机制。但是，对象类的分组并不是随机的。模式一般根据应用进行组织，比如核心、X.500 兼容性、UNIX 网络服务、发送邮件等等。如果需要将一个应用程序与 LDAP 集成，一般必须在 LDAP 服务器中添加一个模式。本系列中的一个后续教程会详细讨论 OpenLDAP 的配置，现在只需知道添加模式的方法是使用 include /path/to/file.schema。在重新启动服务器之后，新模式就会生效了。在装载模式之后，就可以将新的对象类应用于相关的对象。这可以通过 LDIF 文件或 LDAP API 完成。应用对象类就提供了更多属性。创建和修改模式模式文件的格式相当简单。清单 6 显示的模式包含 inetOrgPerson 对象类以及它的一些属性。清单 6. inetOrgPerson 定义的一部分 attributetype ( 2.16.840.1.113741 NAME displayName DESC RFC2798: preferred name to be used when displaying entries EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX .4.1.14.15 SINGLE-VALUE )attributetype ( 0.9.2342.19200300 NAME jpegPhoto DESC RFC2798: a JPEG image SYNTAX .4.1.14.28 )objectclass ( 2.16.840.1.1137 NAME inetOrgPerson DESC RFC2798: Internet Organizational Person SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) 在模式文件中空行并不重要，主要用来提高对人的可读性。第一个定义是一个 attributetype，这表示一个属性。属性定义放在圆括号中。首先是一串由点号分隔的数字，称为对象 ID（object ID，OID），这是一组全局惟一的数字。OID 也是层次化的，所以如果您被分配了 1.1 树，就可以创建 1.1.1 或 .4.5.6 这样的 OID，而不需要注册。注册 OID不能随便选择一组数字作为 OID，因为不知道您选择的值是否已经或将会在其他地方使用。OID 必须是惟一的。一些服务器允许指定惟一的文本性 OID（比如 mycompany.1.2），但是这无法保证兼容性。可以在本地使用 1.1 名称空间下的任何名称，但是这不保证其惟一性。最好的解决方案是注册自己的 OID。这可以通过多种方式实现，取决于您是一个国家、电信运营商或其他组织。幸运的是，Internet Assigned Numbers Authority（IANA）允许免费申请 ..1 之下的分支。OID 后面是一系列关键字，每个关键字后面有一个值。首先，属性的 NAME 定义人使用的名称，比如在 LDIF 文件中使用或者在通过 LDAP API 检索信息时使用。有时候可能会看到 NAME ( foo bar ) 形式的名称，这意味着 foo 和 bar 都是可接受的。但是，服务器把第一个名称作为属性的主要名称。DESC 提供属性的描述。这帮助您在浏览模式文件时理解属性的意义。EQUALITY、SUBSTR 和 ORDERING（这里没有显示）需要一个匹配规则（matching rule）。它们分别定义如何比较、搜索和排序字符串。caseIgnoreMatch 是不区分大小写的匹配，caseIgnoreSubstringsMatch 也属于不区分大小写的匹配。参考资料 中列出的 Web 站点定义了所有标准匹配规则。与 LDAP 中的大多数东西一样，服务器可以为自己的属性定义匹配方法，所以无法提供完整的匹配规则列表。属性的 SYNTAX 通过引用 OID 定义数据的格式。RFC 2252 列出标准语法及其 OID。如果 OID 后面紧跟着一个放在花括号（）中的数字，这就表示数据的最大长度。.4.1.14.15 表示 DirectoryString 是一个 UTF-8 字符串。最后是 SINGLE-VALUE 关键字，它没有参数，指定只允许 displayName 的一个实例。jpegPhoto 属性的定义非常短：只有 OID、名称和描述以及 JPEG 对象（这是二进制数据的编码字符串）的语法。对图像进行搜索或排序是不可行的，而且多个图像可以放在一个记录中。然后，按照相似的方法定义一个对象类。定义的开头是 objectclass 关键字，然后是圆括号、对象类的 OID 和定义。NAME 和 DESC 的意义与前面一样。SUP 定义父对象类，也就是说这个对象类继承 SUP 关键字指定的对象类。因此，inetOrgPerson 包含 organizationalPerson 的属性。STRUCTURAL 关键字定义这是一个结构对象类，可以作为对象的主类型。其他选项是 AUXILIARY（这在现有对象中添加属性）和 ABSTRACT（这与结构对象类相似，但是不能直接使用）。抽象对象类必须由另一个对象类继承，然后可以使用继承的对象类。top 对象类是抽象的。大多数其他结构对象类都继承它，包括 person，person 是 organizationalPerson 的父类，organizationalPerson 进而由 inetOrgPerson 继承。MAY 和 MUST 关键字分别定义使用这个对象类的记录允许使用的属性和必须具备的属性。如果缺少任何必需属性，记录就无法保存。每个属性由美元符号（$）分隔，即使换行了，也不能省略美元符号。最好不要修改结构对象类或者现有的广泛使用的辅助对象类。因为这些对象类是众所周知的，如果以后改用其他服务器，这种修改可能导致不兼容。最好的解决方案是定义自己的辅助对象类，创建一个本地模式，并将它应用于自己的记录。例如，如果您的组织是一所大学，希望存储学生的属性，那么可以考虑创建一个学生对象类，这个对象类继承 organizationalPerson 或 inetOrgPerson，并添加自己的属性。然后可以创建辅助对象类来添加课程表等属性。了解要使用哪些模式学习了如何创建模式之后，您很可能迫不及待地根据自己的环境创建自己的模式。这肯定可以满足您当前的需要，但是随着在 LDAP 树中添加更多功能以及集成其他系统，这很可能在以后造成许多困难。最好的方法是尽可能坚持使用标准的对象类和属性，只在必要的情况下进行扩展。OpenLDAP 通常将它的模式文件存储在 /etc/openldap/schema 中，文件扩展名是 .schema。表 3 列出默认的模式及其用途。表 3. OpenLDAP 附带的模式文件名用途corba.schema它定义的对象类和属性用来跨多台机器处理 Common Object Request Broker Architecture（CORBA）对象引用。core.schema它定义许多常用的属性和对象类。这个模式包含 organizationalUnit、top、dcObject 和 organizationalRole。在寻找合适的对象类和属性时，应该首先查看 core.schema。cosine.schema它定义的对象类和属性来自 X.500 规范。尽管其中的一些对象类和属性是有用的，但是在 core 和 inetorgperson 等其他模式中常常有更好的替代品。dyngroup.schema它定义由 Netscape Enterprise Server 使用的一组试验性对象。inetorgperson.schema它定义 inetOrgPerson 对象（扩展 core.schema 中的对象）。java.schema与 corba.schema 相似，这个模式定义的一系列对象类和属性用于在 LDAP 树中查找 Java 类。misc.schema它实现的对象类用于在树中查找邮件。最好查阅自己的电子邮件服务器文档，了解服务器使用哪个模式。nis.schema如果用 LDAP 进行身份验证，就要使用这个模式。nis.schema 定义 posixAccount，其中提供的属性用于在用户对象中存储身份验证数据。它还提供各种映射类型，用来处理组、网络、服务和 Network Information System（NIS）等网络身份验证机制所用的其他文件。openldap.schema它主要用于演示，提供了一些基本对象。ppolicy.schema它提供的一组对象用来在 LDAP 中实现密码策略，比如口令老化（aging）。注意，其中一些对象由传统的 UNIX 影子机制处理，已经包含 nis.schema 中。另外，RFC 4519 解释了一些常用属性。找到自己需要的属性之后，就可以查看模式文件，判断需要将哪些文件包含在 LDAP 配置中，以及必须在记录中使用哪些对象类。结束语在本教程中，学习了 LDAP 的概念、体系结构和设计。LDAP 的设计目的是以简单的方式通过 IP 连接 X.500 目录。目录以层次化方式存储数据，其结构就像是树。树中的记录由区分名来标识，并具有许多属性-值对，包括一个或多个对象类，它们定义可以在记录中存储哪些数据。LDAP 本身是指用来搜索和修改树的协议。但是在实践中，LDAP 这个词也用于所有相关事物，比如 LDAP 服务器、LDAP 数据等等。常常用 LDIF 导入和导出 LDAP 数据，LDIF 是一种表示 LDAP 数据的文本格式。LDIF 文件指定一些 changetype 操作，比如 add、delete、modrdn、moddn 和 modify。可以通过这些操作在树中添加条目、删除条目或移动数据，以及修改数据属性。正确地设计树对于 LDAP 服务器的长期运行非常重要。正确的设计可以减少所需的修改操作，使数据保持一致性，便于其他应用程序搜索。通过选用常用的属性，可以确保 LDAP 数据的其他消费者能够理解属性的意义，减少必需的转换。LDAP 模式指定在服务器中可以使用哪些属性。模式包含属性的定义，包括惟一标识它们的 OID、关于数据如何存储和排序的指示以及对属性作用的文字描述。对象类将属性进行分组，它们可以定义为结构、辅助和抽象三种类型。结构对象类定义记录，所以一个记录只能有一个结构对象类。辅助对象类添加用于特殊用途的属性，可以添加到任何记录中。抽象对象类必须被继承，不能直接使用。图 5. 为用户和客户提供单独分支的 LDAP 树图 5 所示的结构将职员和客户分开了。所有职员位于同一个组织单元（organizational unit，OU）中，但是客户按照地区进行进一步划分。在这种情况下，不同的人员就可以管理各自地区的客户。如果打算用 LDAP 对 UNIX 资源进行验证，那么必须决定将这些信息存储在哪里。前面已经处理了用户帐户，但是还需要存储组和其他映射，比如主机、服务、网络和别名。把哪些信息存储在 LDAP 中，哪些存储在本地文件中，以及是否需要集中地更新它们，这些都由您自己决定。最简单的方法是将每个映射存储在一个单独的 organizationalUnit 中。当配置 UNIX 系统来读取这些信息时，需要指定容器的 DN 和过滤器。如果在用户 OU 中存储组，就必须编写一些过滤器。如果要对职员 OU 做任何结构性修改，还必须调整这些过滤器。决定对象类到目前为止，讨论一直集中在 LDAP 树的布局上，基本目标是避免以后被迫修改对象的名称。决定了树的布局之后，必须决定使用哪些对象类。对于树中同一分支下的对象，可以分配不同的对象类，但是这几乎肯定会在以后造成维护困难。更糟糕的是，如果在对象类分配方面犯了错误，那么不一定能够在对象上添加更多的对象类。LDAP 模式定义两种对象类：结构的（structural） 和辅助的（auxiliary）。结构对象类常常从其他对象类继承属性，继承链是从一个称为 top 的对象类开始的。可以认为，结构对象类定义对象的 “身份”，而辅助对象类添加属性。organizationalUnit 是一个结构对象类，inetOrgPerson 也是。请再看一下 清单 1，顶级条目有两个对象类：dcObject 和 anization 是结构对象类。dcObject 起辅助作用，它定义了 dc 属性。可能导致问题的原因是，一个条目只能有一个结构对象类。有时候，会在同一个记录中看到 inetOrgPerson、organizationalPerson、person 和 top，但是它们都是同一个继承树的组成部分。inetOrgPerson 和 account 都是结构的，而且不属于同一个继承树，因此不能一起使用。一些 LDAP 服务器允许这么做，但是这种行为最终可能会改变并导致问题。第三种对象类称为抽象（abstract）对象类。它很像结构对象类，但是必须继承它，然后才能使用。top 就是这种对象类。有一些通用的结构对象类： inetOrgPerson：定义一个人，包括一些联系信息。 organizationalRole：与人很相似，但是它定义一个角色，比如 IT Helpdesk 或 Fire Warden。 organizationalUnit：一个一般性容器，可以描述一个部门，也可以用来分隔 LDAP 树的各个部分，比如组、人和服务器。 organization：一个公司或其他组织。 groupOfNames：存储一个或多个 DN，它们引用一个组的成员。尽管对于 UNIX 组不一定有用，但是对会议邀请和其他简单情况有帮助。 应该坚持对人和组织使用这些对象类，这样比较安全。大多数扩展（比如身份验证）使用辅助属性。如果有疑问，可以参考模式。最后一个设计问题是选择 DN。对于大多数分支，这相当容易，因为没有出现重复的可能性。UNIX 组名和 ID 是惟一的，所以可以将 cn 用作组的 RDN。但是，如果有两个职员都叫作 Fred Smith，那该怎么办？DN 必须是惟一的，而他们两人的 DN 都是 cn=Fred Smith,ou=People,dc=e