构建基于 LDAP 的地址簿
本教程向您演示了如何创建一个基于 LDAP 的后端来存储多个应用程序可以方便共享的联系人信息。同时，我们提供了 LDAP 基础知识的概述，并向您介绍了一个预先构建的联系人管理工具，该工具将帮助您着手使用这一开放技术。
预备知识
读者应基本掌握一般管理任务方面的知识及其概念。包括诸如设置权限、管理用户账户、移动和复制文件、创建符号链接等任务。
要执行本教程中的示例，您必需正确安装和配置 Linux 系统和下列软件：
Red Hat Linux 7.3。操作系统特定的说明是基于 Red Hat Linux 7.3 的。 因为 Red Hat Linux 很受欢迎并且大多数管理员／用户至少熟悉它的系统布局和一些约定，所以我们选择它。
OpenLDAP。OpenLDAP 用作 LDAP 目录服务器。 OpenLDAP 是基于开放标准的开放源码，可以免费下载。然而，在很大程度上，我们所讨论的结构、布局和管理任务可很容易地转移到商用目录服务器，如 IBM 的 SecureWay Server 和 Netscape 的 Directory Server 产品。
LDAP入门
概述：
首字母缩略 LDAP 代表轻量级目录访问协议（Lightweight Directory Access Protocol）。与某些计算机术语不同，术语 LDAP 的自我描述性真是令人惊异。
LDAP 是一种部分基于 X.500 目录标准的开放标准，但更简单、更精练且可扩展性更好 — 与某些其它通信协议相比，它是轻量级的。LDAP 标准的规范是以一系列 RFC（或注释请求，Request For Comment）的形式编排的。有关与 LDAP 相关的 RFC 的更多信息，请参阅参考资料中列出的 LDAPman RFC 页面。
信息被集中存储在服务器上的 LDAP 目录中。LDAP 目录是一种数据库；然而，它不是关系数据库。它的目录或数据库的结构与 UNIX 文件系统非常相似：数据按层次存储；有“根”或“基本 DN”（专有名称，Distinguished Name）；目录被进一步细分成组织单元（Organization Units 或 OU）；在这些 OU 中是包含数据的项。这种树-叶结构不仅使 LDAP 变得可扩展，而且当进行简单的搜索或查询时，比传统的关系数据库更快。
通过使用 LDAP 协议，客户机将查询发送给 LDAP 服务器（从技术上讲，LDAP 没有“读”功能；客户机通过将搜索请求发送给服务器来“读”目录项）。服务器检查客户机权限（即，客户机有权访问数据库吗？可以读被请求的树吗？可以将信息写入数据库吗？可以删除项吗？），然后返回请求信息。几乎所有的现代编程语言都有 LDAP API，这意味着几乎任何一个软件都可以支持 LDAP。
遗憾的是，术语 LDAP 经常在没有上下文的情况下或在不适当的上下文中使用。而目前又有多种使用该术语的方法（LDAP 协议、LDAP 服务器或 LDAP 客户机），那些不熟悉 LDAP 世界的人很可能会被搞糊涂。出于本教程的目的，我已经做了所有努力以确保说明了上下文或者使上下文明显有别于相关的讨论。
为什么使用LADP
在过去两三年中，LDAP 实现已经从相对不为人知的技术变成“当今的热门主题”。其突然受欢迎的原因可以大致概括为两个词：可扩展性和灵活性。
LDAP 协议既是跨平台的也是基于标准的。这意味着几乎在任何计算机平台上运行的任何应用程序都可以从 LDAP 目录获取信息。另外，无论什么服务器操作系统、文件系统或平台对于客户机都是无关紧要的。
LDAP 目录几乎可以存储所有类型的数据：电子邮件地址、DNS 信息、NIS 映射、安全性密钥、联系人信息列表和计算机名等。如果需要专门的组织单元或项，则可以根据具体实现来定制控制给定字段可以保存哪种信息的规则（称为模式，稍后将详细讨论）。
大多数 LDAP 服务器的安装和配置相对比较简单，并且可以在很少或没有维护的情况下运行多年，而且很容易为特定类型的访问而进行最优化。
可以容易地配置 LDAP 目录来复制部分或所有目录树（使用推(push)或拉(pull)方法）。这可以使系统管理员不必担心出现单点故障的情况。
可以通过 ACL（访问控制表，Access Control List）来控制对目录的访问。例如，管理员可以根据给定组或位置中的成员资格来限制谁可以看到哪些内容，或者给予特殊用户在其自己记录中修改所选字段的能力。ACL 提供极其细粒度的访问控制，而且 ACL 将这种控制与 LDAP 安装结合在一起，而不是与请求信息的客户机结合在一起。此外，可以容易地将 LDAP 与大多数现有的安全性层和／或认证系统（例如 SSL、Kerberos 和 PAM 等）集成在一起。
LDAP目录结构：基本DN
目前为止，我们已经讨论了什么是 LDAP、它（在高级别上）是如何工作的、LDAP 目录的一般结构以及为什么 LDAP 实现如此受欢迎。现在，应该更深入地研究项本身的各种组件了。正如上一页所提到的那样，LDAP 目录树的“根”或顶部是基本 DN。基本 DN 通常有两种形式：organization=（例如，o=syroidmanor.com），或者从组织的 DNS 域组件派生的 DN（dc=syroidmanor,dc=com）。
对于大多数安装，后者是首选格式，只因为它将两个截然不同的组件分隔开。如果将来您的公司决定与另一家公司合并，那么不必修改现有结构；然后，基本 DN 变成 dc=com 和 com 树的两个公司分支（当然，如果 syroidmanor.com 与 syroidmanor.com 合并，这样就不会有多大帮助）。
所有这些都给我们带来了两个非常重要的提示：(1) 成功的 LDAP 实现的 99% 在于为您的组织预先规划一个可扩展且有效的结构，(2) 从某种程度上讲，每个 LDAP 安装都是唯一的；换句话说，对于结构布局没有一成不变的规则。
下图显示了“dc”（与“organization”相对比）LDAP 目录结构的示例。
[myimg]http://bbs.chinaunix.net/forum/uploadfile/dctree.jpg[/myimg]
LDAP目录结构：组织单元
在目录基本 DN 的下面是容器或组织单元（OU），它们从逻辑上对您的数据进行分隔或分组。这里的选项通常由您业务或安装的组织结构确定。另外，第二层 OU 可用来进一步分隔数据。例如，国际企业可以使用下列结构：
dc=foobar,dc=com
ou=customers
ou=northamerica
ou=southamerica
ou=asia
ou=europe
ou=employees
ou=group
ou=projects
ou=accounting
ou=resource
ou=service
一般的经验方法可以使您的组织结构尽可能地保持简单，并且不危及将来的可扩展性。还要紧记一点，您将结构容器嵌套得越深，它返回查询所用的时间就越长。
LDAP目录结构：个别项
在 LDAP 结构的组织单元下面是实际的项。下面是以 LDIF 格式显示的示例（填充 LDAP 目录中有更多 LDIF 格式的示例）。
dn: cn=Tom Syroid, ou=employee, dc=syroidmanor, dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Tom Syroid
cn: Thomas Syroid
sn: Syroid
givenName: Tom
initials: TMS
title: Project Manager
uid: tsyroid
mail: tom@syroidmanor.com
telephoneNumber: 306 555 1212
mobile: 306 555 1999
roomNumber: 115
employeeNumber: 33
employeeType: full time
首先，请注意下列事实：
项只是存储属性的地方。
属性是可用来将一种类型的信息存储在目录中的容器。
每个属性都有一种类型和一个或多个值。
所以，cn: Tom Syroid 是项的一个属性，cn 是类型，与该类型相关联的值是“Tom Syroid”和“Thomas Syroid”。
现在，让我们仔细研究上述项的属性。第一行包含项的 DN 或“专有名称”。LDAP 目录中的每个项都有唯一的 DN，每个 DN 都由两部分组成 —“相对专有名称”（或 RDN）和对 LDAP 目录结构中存储记录的位置的引用。几乎存储在 LDAP 目录中的所有数据都有一个唯一名称，这个名称通常存储在 cn 属性中。在上面的示例中，用于唯一标识或区别记录的 cn 值是“Tom Syroid”。注：也可以使用“Thomas Syroid”，只要提供的 dn 对于数据库中的所有其它项是唯一的即可。后面的 ou 和 dc 值指向目录结构中记录的位置。
对象类
对象类由 LDAP 目录使用来定义给定类型的对象可以有哪些属性。对象类还定义项必须有什么属性，以及项可以有什么属性。所有对象类都从其父对象类继承需求，然后添加它们自己的需求。下面是一个对象类示例：
objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
对象类有五个组件：OID（对象标识）、唯一名称、父对象（SUP）、任何需要的属性（MUST）和允许的属性列表（MAY）。OID 是由 LDAP 目录的内部数据库机制使用的数据标识符。从概念上讲，它们与 IP 地址相似，因为每个对象类都必须有一个唯一数字。并且象 DNS 和 IP 之间的关系那样，由创建它们的个人进行注册，并由这些人“拥有”。有关注册 OID 的更多信息，请参阅 Internet Assigned Numbers Authority（或 IANA）。
您需要一个 OID 号来创建您自己的对象类吗？答案取决于您的目录服务器软件 — 有的允许而有的不允许。有关详细信息，请查看 LDAP 文档。有关已定义的对象类及其属性的更多信息，请查看 LDAPman 模式参考页面或极其有用的 LDAP 模式查看器网站
您或许会问什么是模式？模式只是按照相似性进行分组的对象类集合。例如，inetOrgPerson 模式包含 departmentNumber、employeeType、givenName、homePhone 和 manager 等的对象类。inetOrgPerson 模式还继承了其它“父”模式的许多对象类。
小结
本章以很短的篇幅讨论了许多基础知识。虽然在安装和配置 LDAP 服务器（下一章主题）之前不需要了解这些所讨论的内容，但至少大致掌握一下 LDAP 目录服务背后的基本概念可帮助管理员更好地理解 LDAP 操作后面的原理。有关 LDAP 结构、对象类和属性的更多信息，请参考 OpenLDAP Administrator's Guide 和许多可从 www.openldap.org 获得的 FAQ
