本文档是OpenLDAP项目的一部分。它遵从在OpenLDAP Software Copyright Notices和OpenLDAP Public License中声明的条款。完整的notices和相关的license分别可以在附录B和C中找到。
本文档的适用范围
本文档提供了在UNIX和类UNIX系统上安装OpenLDAP 2.1的指南。它面向那些有经验但是还没有接触过LDAP目录操作的系统管理员。
本文档也用于汇集各种以二进制包发放的OpenLDAP软件或者其他放在OpenLDAP官方站点()上的其他资源，在该站点上有很多资源可用。
OpenLDAP资源列表
Resource URL
Document Catalog doc/
Frequently Asked Questions faq/
Issue Tracking System its/
Mailing Lists lists/
Software Pages software/
Support Pages support/
声明
OpenLDAP项目由志愿者组成。没有他们在时间和精力上无偿的奉献就不会有本文档。
OpenLDAP项目组也要向密歇根大学LDAP课题组致谢，他们在LDAP理论基础方面的研究对OpenLDAP项目的实现功不可没。本文档也借鉴了密歇根大学的LDAP文档：《SLAPD和SLURPD管理员指南》。
修订
对本文档的加强和修订方面的建议将通过OpenLADP项目组的Issue Tracking System ()提交。
关于本文档
本文档是通过Ian Clatworthy所开发的Simple Document Format () 文档系统制作完成的。SDF工具可从CPAN ()获得。
OpenLDAP 2.2 管理员指南
OpenLDAP 项目组 <
2004年2月25日
目录
序言
1.简要介绍OpenLDAP目录服务
1.1 什么是目录服务？
1.2 什么是LDAP？
1.3 LDAP是如何工作的？
1.4 什么是X.500？
1.5 LDAPv2和LDAPv3的区别？
1.6 什么是slapd，它能做什么？
1.7 什么是slurpd,它能做什么？
2.快速入门
3。总览 - 配置选择
3.1 本地目录服务
3.2 带有引用（Referrals）的本地目录服务
3.3 拷贝（Replicated）的目录服务
3.4 分布式（Distributed）的目录服务
4.构建和安装OpenLDAP软件
4.1 获取和解压缩
4.2 预安装（Prerequisite）
4.3 运行configure命令
4.4 生成
4.5 测试
4.6 安装
5.slapd的配置文件
5.1 配置文件格式
5.2 配置文件指令
5.3 访问控制
5.4 配置文件示列
6.运行slapd
6.1 命令行选项
6.2 启动slapd
6.3 停止slapd
7.数据库创建和维护工具
7.1 在LDAP上创建数据库
7.2 脱机创建数据库
7.3 LDIF文本的条目格式
8.方案说明
8.1 分布式的方案文件
8.2 方案的扩展
9.安全考虑
9.1 网络安全
9.2 保持数据的完整（integrity）与一致（confidentiality）
9.3 认证（authentication）方法
10.使用SASL
10.1 SASL的安全考虑
10.2 SASL认证
10.3 SASL代理认证
11.使用TLS
11.1 TLS验证
11.2 配置TLS
12.构建分布式的目录服务（Distributed Directory Service）
12.1 子确认消息（Subordinate Knowledge Infomation）
12.2 父确认消息（Superior Knowledge Infomation）
12.3 ManageDsaIT控制器（Control）
13.用slurpd进行拷贝
13.1 总览
13.2 拷贝日志
13.3 命令行选项
13.4 配置slurpd和从属的slapd实例
13.5 高级slurpd选项
14.LDAP同步拷贝
14.1 LDAP内容同步协议
14.2 Syncrepl的细节
14.3 配置Syncrepl
15.代理缓存引擎
15.1 总览
15.2 代理缓存配置
附录A.通用配置说明
附录B.OpenLDAP软件版权声明
B.1 OpenLDAP软件版权声明
B.2 附加版权声明
B.3 密西根大学版权声明
附录C.OpenLDAP公关许可证
1.OpenLDAP目录服务简介
本文档详细讲解了如何构建，配置和操作OpenLDAP来提供目录服务。其中包括配置并运行LDAP守护程序slapd以及负责LDAP的更新和复制的守护程序slurpd的细节。它既是新手的上路指南，也为经验丰富的管理员提供参考。本节将对目录服务，特别是slapd所提供的目录服务做一个简单的介绍。
1.1 什么是目录服务？
目录是在读取，浏览和搜索方面做了特殊优化的一类数据库。目录包含基于属性的，描述性的信息，并且支持高级的过滤功能。目录一般来说不支持大多数事务型数据库所支持的高吞吐量和复杂的更新操作。就算目录允许进行更新操作的话，也是要么全部，要么都不的原子操作。目录的长处在于为大量的查询和搜索操作提供快速反馈。为了保证数据的可用性和可靠性，它们在着眼于减少反应时间的同时也可能具备广泛的复制信息的能力。当目录信息被复制时，复制方与被复制方有暂时的不一致是可以的，只要它们最终仍然保持同步。
可以有多种不同的方式来提供目录服务。不同的目录所允许存储的信息是不同的，在信息如何被引用，查询，更新以及防止未经授权的访问等问题上不同的目录的处理方式也有诸多的不同。一些目录服务是本地的，只提供受限的服务（比如，单机上的finger服务）。另一些服务是大范围的（global），提供广阔得多的服务（比如面向整个因特网）。大范围的服务通常是分布式的，这也就意味着数据是分布在多台机器上的，这些机器一起来提供目录服务。典型的大范围服务定义一个统一的名称空间（namespace）来给出一个相同的数据视图（data view），而不管你相对于数据所在的位置。DNS是一个典型的大范围分布式目录服务的例子。
1.2 什么是LDAP？
LDAP是Lightweight Directory Access Protocol（轻量级目录访问协议）的缩写。正如它的名字所表明的那样，它是一个轻量级的目录访问协议，特指基于X.500的目录访问协议的缩微版本。LDAP运行在TCP/IP或者其他的面向连接的传输服务之上。LDAP完整的技术规范由 RFC2251 "The Lightweight Directory Access Protocol (v3)" 和其他几个在RFC3377中定义的文档组成。本节将从用户的角度对LDAP做一个大致的了解。
什么样的信息可以存储在目录当中？LDAP信息模型是基于条目的（entry）。一个条目就是一些具有全局唯一的标识名（Distinguished Name,简写做DN）的属性的集合。DN用于无二义性的指代一个唯一的条目。条目的每一个属性都有一个类型（type），一个或者多个值（value）。类型（type）往往是特定字符串的简写，比如用"cn"指代"common name",或者"mail"指代电子邮件地址。值（value）的语法依赖于类型（type）。比如，类型为cn的属性可能包含值Babs Jensen。类型为mail的属性可能包含值"babs@example.com"。类型为jpegPhoto的属性可能包含二进制格式的JPEG图象。
信息在目录中是如何组织的？在LDAP中，条目是按树状的层次结构组织的。传统上，这个结构往往是地理界限或者组织界限的反映。代表国家的条目位于整个目录树的顶层。之下的条目则代表各个州以及国家性的组织。再下面的条目则代表着组织单位，个人，打印机，文件，或者你所能想到的其他东西。图1.1显示了按照传统命名方式组织的LDAP目录信息树。
图1.1: LDAP目录树(传统命名方式)
目录树也可以按照因特网域名结构组织。因为它允许按照DNS对目录服务进行定位，这种命名方式正变得越来越受欢迎。图1.2显示了按照域名进行组织的一个LDAP目录树的例子。
图1.2：LDAP目录树（域名命名方式）
另外，LDAP允许你通过使用一种叫做objectClass的特殊属性来控制哪些属性是条目所必须的，哪些属性是条目可选的。objectClass属性的值是由条目所必须遵从的方案（schema）来定义的。
信息是如何被引用的？一个条目是通过它的标识名来引用的。而标识名是由相对标识名（Relative Distinguished Name或者RDN）和它的父条目名连在一起来构成的。比如，在因特网命名的例子中，Barbara Jensen条目有相对标识名uid=babs和标识名uid=babs,ou=People,dc=example,dc=com。完整的DN格式在 RFC2253，"Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names"中描述。
信息是如何被访问的？LDAP定义了一组查询和更新目录的操作。支持的操作包括从目录中添加和删除条目，更改已有的条目，更改已有条目的名字。然而，大多数情况下LDAP是用于搜索目录中的信息的。通过指定搜索过滤器，LDAP可以在目录的相关部分搜索相符的条目。满足过滤条件的每一个条目都能收到请求信息。
比如，你可能想搜索位于dc=example,dc=com目录子树下的叫Barbara Jensen的人的条目，并获取找到的每个条目的email地址。LDAP可以让你轻松的完成这一切。或者你想搜索直接位于st=California,c=US子树之下且名称中有Acme字符串，并且有一个传真号的组织的条目。LDAP也让你能轻松地完成这一切。下一节将详细描述更多的有关你能用LDAP做什么和它如何对你有用的诸多细节。
怎样保护信息不受未经授权的访问？一些目录服务不提供保护，允许信息对任何人可见。LDAP提供了一套机制来对客户进行身份确认，或者让客户证明他拥有连接到服务器的身份，这无疑为对服务器进行全方位的访问控制铺平了道路，从而确保了服务器上所包含信息的安全。LDAP也支持privacy和integrity的安全服务。
1.3 LDAP是怎样工作的？
LDAP目录服务是基于客户--服务器模式的。一个或者多个LDAP服务器包含着组成整个目录信息树（DIT）的数据。客户连接到服务器并且发出一个请求（question）。然后服务器要么以一个回答（answer）予以回应，要么给出一个指针，客户可以通过此指针获取到所需的数据（通常，该指针是指向另一个LDAP服务器）。无论客户连到哪个LDAP服务器，它看到的都是同一个目录视图（view）。这是LDAP这类全局目录服务的一个重要特征。
1.4 什么是X.500？
从技术上来说，LDAP是一个到X.500目录服务的目录访问协议，X.500是一个OSI目录协议。最初，LDAP客户通过网关（gateway）访问X.500目录服务。这个网关在客户和网关之间运行LDAP和X.500目录访问协议（Directory Access Protocol ，DAP），而X.500目录访问协议是位于网关和X.500服务器之间的。DAP是一个重量级的协议，在整个OSI协议栈上进行操作，而且需要占用大量的计算资源。LDAP被设计为在TCP/IP层上操作，以小得多的代价实现了大多数DAP的功能。
虽然LDAP可以仍旧通过网关访问X.500目录服务器，但是现在通常都是在X.500服务器上直接实现LDAP。
单独的LDAP守护程序，slapd，可以被看做是一个轻量级的X.500目录服务器。也就是说，它没有实现X.500完整的DAP协议。作为一个轻量级的目录服务器，slapd实现的仅仅是X.500模型的一个子集。
如果你已经在打算运行一个X.500的DAP服务而且你想继续这么做的话，你可以不用再阅读本指南了。本指南全都是关于通过slapd运行LDAP的，而不是运行X.500的DAP。如果你现在没有运行X.500的DAP，或者想停止运行X.500的DAP，或者还没有立即计划要运行X.500的话，请继续往下读。
从LDAP目录服务器上拷贝数据到X.500 DAP DSA是可能的。这需要LDAP/DAP网关。OpenLDAP不提供这样的网关，但是我们的拷贝守护程序可以用于拷贝数据到这样的网关。请参阅本文档的Replication with slurpd章节了解关于拷贝的信息。
1.5 LDAPv2和LDAPv3的区别？
LDAPv3 是在90年代后期开发以取代LDAPv2的。LDAPv3为LDAP添加了如下功能：
。基于SASL的强类型认证（Strong Authentication）
。基于TLS（SSL）的数据完整性和一致性保护
。通过Unicode国际化
。Referrals and Continuations
。方案发现
。可扩展性（控制，可扩展的操作，等等）
LDAPv2是历史性的（RFC3494）。因为大多数LDAPv2的实现（包括 slapd(）都没有遵从LDAPv2技术规范，在不同的LDAPv2的实现当中进行互操作是有限的。因为LDAPv2和LDAPv3有着显著的不同，同时部署LDAPv2和LDAPv3将会有大麻烦。应该避免使用LDAPv2。LDAPv2默认是不被支持了的。
1.6 什么是slapd，它能干什么？
slapd(8)是一个可在许多平台上运行的LDAP目录服务器。你可以用它来提供你自己的目录服务。你的目录可以包含相当多的你想放在里面的东西。你可以将它连接到一个全局的目录服务器上，也可以自己运行它。slapd的一些其他的有趣的功能包含如下：
LDAPv3:slapd实现了轻量级目录访问协议的第三个版本。slapd支持IPv4和IPv6还有Unix IPC上的LDAP。
Simple Authentication and Security Layer：slapd支持通过SASL的强类型认证服务。slapd的SASL实现利用了 Cyrus SASL--一个支持DIGEST-MD5,EXTERNAL,和GSSAPI在内的多种机制的软件。
Transport Layer Security:slapd通过使用TLS(或者SSL)提供privacy和integrity保护。slapd的TLS实现利用了OpenSSL。
Topology control:slapd可以被配置为限制基于网络拓扑信息之上的套接字层的访问。这个功能用到了TCP wrappers。
Access control:slapd提供了一个多样并且强大的访问控制功能，它允许你控制对你的数据库中的信息的访问。你能够通过LDAP认证信息，IP地址，域名或者其它的规则控制对条目的访问。slapd支持静态的和动态的访问控制信息。
Internationalization:slapd支持Unicode和语言标志。
Choice of database backends:slapd提供了可让你选择的多种后端数据库。这包括BDB，一种高性能的事务性后端数据库；LDBM，一种轻量级的DBM后端数据库；SHELL，一种能够和任意脚本交互的数据库接口；还有PASSWD，一种与passwd文件交互的简单数据库接口。BDB后端数据库使用了Sleepycat Berkeley DB。LDBM使用Berkeley DB或者GDBM。
Multiple database instances:slapd可以被配置为同时支持多个数据库实例。这意味着一个单一的slapd服务器能够响应LDAP树上多个不同逻辑的部分，使用相同或者不同的后端数据库。
Generic modules API:如果你要求有更多的个性化，slapd可以让你轻易的写出你自己的模块。slapd包含两个不同的部分：前端模块处理和LDAP客户的通信；另外有多个模块处理特定的任务比如数据库操作。因为这两部分是通过定义好的C API进行交互的，所以你可以写出自己的个性化的模块来以多种方式扩展slapd。而且，许多可编程的数据库模块也被提供。这允许你使用流行的编程语言将外部的数据源导入slapd当中（比如Perl,shell,SQL,和TCL）。
Threads: 为达到高性能slapd被线程化了。通过使用一个线程池，只需要有一个支持多线程的slapd进程你就可以处理所有的输入请求。这减小了在高负荷时系统的开销。
Replication: slapd可以被配置为维护一个目录信息的shadow拷贝。这种一主多属（single-master/multiple-slave）的拷贝方案在一些大数据量的环境下是很重要的，因为这种情况下单一的slapd不能提供必要的可用性和可靠性。slapd也支持尚在实验中的多主（multi-master）拷贝方案（用于强类型的ACID属性不需要的地方）。slapd支持两种拷贝方案：LDAP Sync-based和slurpd(-based拷贝方案。
Proxy Cache:slapd可以被配置为具有代理缓存功能的LDAP服务器。
Configuration:slapd是高度可配置的，通过一个简单的配置文件你就可以更改你想要改变的一切。配置选项也都有合理的默认值，无疑这会让你的工作更为轻松。
1.7 什么是slurpd，它能干什么？
slurpd(8)是一个在slapd的帮助下提供拷贝服务的守护程序。它负责将对主slapd数据库的改变分发给各个不同的slapd从属（replicas）。它免除了slapd的后顾之忧--在数据发生改变的时候某些从属也许当掉（down）了或者不可达。slurpd会自动处理失败请求的重传。slapd和slurpd通过一个将更改记入日志的简单文本文件进行通信。
查看Replication with slurpd章节以获得更多关于如何配置和运行slurpd的信息。
反过来，LDAP-Sync-based拷贝也可以用来提供拷贝服务。查看LDAP Sync Replication章节以获得更多信息。
2.快速入门
以下将对OpenLDAP 2.1做一个简单的简介，其中包括LDAP守护程序，slapd(。
它将带你领略安装和配置OpenLDAP的几个基本步骤。它应当和本文档的其他章节，手册，以及其它随发布包一起发放的资料（比如INSTALL文档）或者OpenLDAP站点上的资料（尤其是FAQ）一起使用。
如果你打算严肃地运行OpenLDAP,你应当在准备安装之前参看本文档的全部章节。
-------------------------------------------------------------------------------------------
注意：快速入门没有提及强类型身份认证，也没有提及数据的完整和保密措施。这些都将在本文档的其它章节中详细讲述
-------------------------------------------------------------------------------------------
1. 获取软件包
你可以按照OpenLDAP下载页面().上的说明获得该软件的一个拷贝。推荐新手使用最新版本。
2. 解压发布包
选择一个目录存放该软件的源代码，更改工作目录到该目录下，用下列命令解开发布包：
gunzip -c openldap-VERSION.tgz | tar xvfB -
然后进入发布包目录：
cd openldap-VERSION
你需要用你的发布版本来代替VERSION。
3. 参看文档
现在你应该先参看随发布包发布的COPYRIGHT, LICENSE, README 和 INSTALL文档。COPYRIGHT 和 LICENSE 提供了使用，复制OpenLDAP的相关信息。
你也应该参看本文档的其它章节。特别是，“构建和安装OpenLDAP软件”一节提供了预安装软件以及安装过程的细节。
4. 运行configure脚本
你需要运行configure配置脚本来配置发布包以便在你的系统上构建OpenLDAP。configure脚本可以接受很多的命令行选项来启用或者禁用某些可选的功能。通常默认值就可以了，但你可能会想改变它们。要想得到configure脚本接受的完整选项列表，需要使用--help选项：
./configure --help
考虑到你正在参考本文档，我们就假设你有足够的勇气让configure脚本去决定一切：
./configure
如果configure脚本在你系统上没有出什么差错的话，你现在就可以继续构建整个软件了。如果configure脚本出了问题的话，你可能就需要前往FAQ的安装版块寻求帮助（），或者是仔细阅读本文档的“构建和安装OpenLDAP软件”一节了。
5.构建软件
下一步是构建整个软件。这一步分为两部分，首先我们构建依赖关系，然后我们开始编译：
make depend
make
两部分都应当无差错的完成。
6. 测试构建是否正确
为了确保构建是正确的，你应当运行test套件（它仅仅会花几分钟的时间）：
make test
作用在你确定的配置之上的测试将开始运行并且所有的测试都应该通过。某些测试，比如对复制（replication）的测试，可能会被忽略。
7. 安装软件
现在你要准备安装了，这通常需要超级用户的权限：
su root -c 'make install'
所有的东西都将安装在/usr/local目录下（或者在运行configure时你指定的其它位置）。
8. 编辑配置文件
用你喜欢的编辑器编辑slapd.conf样例（通常位于/usr/local/etc/openldap/slapd.conf）使之包含下列格式的BDB数据库定义：
database bdb
suffix "dc=
,dc="
rootdn "cn=Manager,dc=,dc="
rootpw secret
directory /usr/local/var/openldap-data
一定要用你的域名的正确部分取代 和 。比如，对于example.com，用：
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /usr/local/var/openldap-data
如果你的域名包含其他的成分，比如eng.uni.edu.eu，那么用：
database bdb
suffix "dc=eng,dc=uni,dc=edu,dc=eu"
rootdn "cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu"
rootpw secret
directory /usr/local/var/openldap-data
配置slapd的相关细节可以在slapd.conf手册和本文档的”slapd的配置文件“一节当中找到。
--------------------------------------------------------------------------------------
注意：启动slapd时指定的目录需要预先存在。
--------------------------------------------------------------------------------------
1. 启动slapd
现在你需要运行下面的命令以启动LDAP服务器slapd:
su root -c /usr/local/libexec/slapd
要检查服务器是否在运行并且配置是否正确，你可以在服务器上运行ldapsearch命令。默认情况下，ldapsearch工具的位置是/usr/local/bin/ldapsearch：
ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
注意用单引号括起来的命令参数将会取消shell字符的特殊解释。这应当返回：
dn:
namingContexts: dc=example,dc=com
有关运行slapd的细节可以在slapd手册和本文档的”运行slapd“一节中找到。
2. 添加初始条目到目录中
你可以用ldapadd工具添加条目到你的LDAP目录中。ldapadd需要LDIF格式的输入。我们将通过两步来完成它:
1. 创建LDIF文件
2. 运行ldapadd
使用你喜欢的编辑器创建一个包含下面内容的LDIF文件：
dn: dc=,dc=
objectclass: dcObject
objectclass: organization
o:
dc:
dn: cn=Manager,dc=,dc=
objectclass: organizationalRole
cn: Manager
一定要用你的域名的正确部分取代 和 。应该用你所在组织的名称来代替。在你剪切和粘贴的时候一定要记得包含前导或者后跟的空格。
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: Example Company
dc: example
dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager
现在，你可以运行ldapadd来把这些条目添加到你目录当中了。
ldapadd -x -D "cn=Manager,dc=,dc=" -W -f example.ldif
一定要用你的域名的正确部分取代 和 。你将被提示输入slapd.conf中指定的”secret“。比如，对于example.com，用：
ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif
其中，example.ldif是你在上面创建的文件。
有关目录创建的其它信息可以在本文档的”数据库创建和维护工具“一节中找到。
3. 观察它是否工作
现在你将添加的条目是不是在你的目录当中。你可以用任何LDAP客户端工具来这样做，但是在我们的示例中使用的是ldapsearch工具。切记要用你的站点的正确值取代dc=example,dc=com：
ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)'
这条命令将搜索并且取得数据库中的每一个条目。
现在你可以用ldapadd或者其它的客户端工具添加更多的条目，尝试各种配置选项，数据库参数或者诸如此类的了。
注意，在默认情况下，slapd允许非超级用户拥有对每个条目的读取权限（超级用户由rootdn配置指令指定）。推荐的方式是对授权用户建立严格的访问控制。访问控制在”slapd的配置文件“章节的”访问控制“一节中讨论。我们鼓励你阅读”安全考虑“，“使用SASL”，“使用TLS”章节。
接下来的章节将给出更多关于编译，构建，运行slapd的详细信息。
3.纵览 - 配置选项
本节给出了LDAP目录服务的各种配置模式的一个纵览，以及如何让你的LDAP服务器slapd适合世界的其他地方。
3.1 本地目录服务
在这种配置模式下，你的slapd只为你的本地域提供目录服务。它不会以任何方式与别的目录服务器交互。这种配置模式如图3.1所示。
图3.1:本地配置模式
如果你是刚刚开始接触LDAP（也就是“快速入门”教你做的），或者如果你只想提供本地的目录服务而不想与外部世界发生瓜葛，那么就应该使用这种模式。只要你愿意，它可以很容易的升级到其它模式。
3.2 带有指针（Referrals）的本地目录服务
在这种配置模式下，你为你的本地域运行一个LDAP服务器，并且将它配置成为当客户的请求超出你的本地域的处理能力的时候能够返回一个指针，该指针指向一个具备处理客户请求能力的更高级的服务器的地址。你可以自己运行这一服务，也可以使用已提供给你的一个。这种配置模式如图3.2所示。
图3.2：带指针的本地模式
如果你想运行本地目录服务并且参与全局的目录，那么运行这种模式。
3.3 拷贝（Replicated）的目录服务
slurpd守护程序是用来将主slapd上的改变传播到一个或多个从属的slapd上。一个master-slave 类型的配置示例如图3.3所示。
图3.3:复制模式的目录服务
这种配置模式可以和前面的两种配置模式之一和起来使用，在前面的两种情况中，单独的slapd不能提供足够的可用性和可靠性。
3.4 分布式（Distributed）的目录服务
在这种配置模式下，本地的服务被分割成为多个更小的服务，每一个都可能被复制，并且通过上级（superior）或者下级(subordinate）指针（referral)粘合起来。
4.构建和安装OpenLDAP软件
本节详细讲解了如何构建和安装OpenLDAP，这包括slapd和slurpd。构建和安装OpenLDAP需要经过几个步骤：安装支撑软件，配置，编译，最后是安装。以下的几节将详细说明这一过程。
4.1 获取和解压缩
你可以从OpenLDAP的官方站点 或者该项目的FTP站点ftp://ftp.openldap.org/pub/OpenLDAP/ 获取到OpenLDAP的一份拷贝。
有两类包（package）可以使用。releases包含了新功能，同时对bug做了修复。尽管项目组采取了相关的的措施保证releases的稳定性，但问题往往还是会在release中出现。stable发布版是被认为稳定的最新版本。
用户可以根据他对新功能或者稳定性的要求自己选择使用的版本。
将OpenLDAP软件包下载到你的本地机器上之后，你需要将它们从存档的压缩文件中解压出来并更改你的当前工作目录到解压后的目录：
gunzip -c openldap-VERSION.tgz | tar xf -
cd openldap-VERSION
你需要用你版本号代替VERSION。
现在你应该先参看随发布包发布的COPYRIGHT, LICENSE, README 和 INSTALL文档。COPYRIGHT 和 LICENSE 提供了使用，复制OpenLDAP的相关信息。
4.2 预安装（Prerequisite）
OpenLDAP需要几个第三方软件的支持。根据你要实现的功能，你可能需要下载并安装一些相关的软件包。本节给出了通常你可能要用到的一些软件包的一些细节。需要注意的是这些第三方软件包可能还需要一些额外的软件的支持。请按照软件包中的安装说明安装好需要的每一个包。
4.2.1 传输层安全
OpenLDAP客户和服务器需要安装OpenSSL TLS库来提供传输层的安全服务。虽然一些操作系统可能把OpenSSL作为基本系统的一部分或者作为可选的组件。OpenSSL仍然需要单独安装。
OpenSSL可从 获得。
没有使用OpenSSL的OpenLDAP算不上真正的LDAPv3版本。
4.2.2 Kerberos认证服务
OpenLDAP客户和服务器可以支持基于Kerberos的认证服务。特别是，通过使用Heimdal 或者 MIT Kerberos V，OpenLDAP还可以支持SASL/GSSAPI 认证机制。如果你需要使用基于Kerberos的SASL/GSSAPI 认证，那么你需要安装Heimdal 或者 MIT Kerberos V。
Heimdal可从获得。 MIT Kerberos V可从获得。
强烈推荐使用诸如Kerberos这样的软件来提供强类型认证服务。
4.2.3 简单认证和安全层
OpenLDAP客户和服务器需要安装Cyrus的SASL库来提供简单认证和安全层服务。虽然一些操作系统可能把Cyrus SASL作为基本系统的一部分或者作为可选的组件。Cyrus SASL通常还是需要单独安装。
Cyrus SASL可从获得。Cyrus SASL 将会用到已安装的OpenSSL和Kerberos/GSSAPI 库。
不使用Cyrus SASL 的OpenLDAP算不上真正的LDAPv3版本。
4.2.2 数据库软件
OpenLDAP的首选后端数据库是BDB，要求4.2版本的Sleepycat Software Berkeley DB。如果配置安装的时候还没有安装BDB的话，你是不能用首选后端数据库构建slapd的。
你的操作系统可能把4.2版本的Berkeley DB作为基本系统的一部分或者作为可选的组件。否则的话你需要自己下载并安装它。
Berkeley DB可从获得。它有几个不同的版本可用。在写作本文档的时候，其最新版本，即4.2版本，是我们推荐使用的。如果你想使用BDB作为后端数据库的话，这个包是必须的。
slapd的LDBM支持很多种不同的数据库管理系统，包括Berkeley DB 和 GDBM。GDBM可从自由软件基金会（FSF）的站点ftp://ftp.gnu.org/pub/gnu/gdbm/获得。
4.2.5 线程
OpenLDAP可以利用线程。OpenLDAP 支持 POSIX pthreads, Mach CThreads，以及其它的一些变种。如果找不到一个合适的线程系统的话，configure会给出警告。如果这发生的话，请参照FAQ（）的Software|Installation|Platform Hints一节。
4.2.6 TCP包装器（wrapper)
如果已安装的话，slapd支持TCP包装器（IP级别的过滤控制）。对于不包含公共信息的服务器推荐使用TCP包装器或者其它的IP级别的访问过滤器（比如一些IP级别的防火墙提供的这样的功能）。
4.3 运行configure命令
现在你可能需要运行带--help参数的configure脚本。这将给出一个你在构建OpenLDAP时可做的改变的选项的清单。OpenLDAP的很多功能都可以通过这种方式起用或者禁用。
./configure --help
configure脚本也会通过查看环境变量做某些设置。这些环境变量包括：
表4.1: 环境变量
Variable Description
CC Specify alternative C Compiler
CFLAGS Specify additional compiler flags
CPPFLAGS Specify C Preprocessor flags
LDFLAGS Specify linker flags
LIBS Specify additional libraries
现在运行带有所需配置选项或者环境变量的configure脚本。
[[env] settings] ./configure [options]
作为一个示例，假设我们想安装一个以BDB为后端数据库且带有TCP包装器的OpenLDAP。默认情况下，BDB是起用的，而TCP包装器不是。所以，我们需要指定--with-wrappers 来包含对TCP包装器的支持：
./configure --with-wrappers
然而，如果所依赖的软件不是安装在系统目录下面的话，这将会失败。比如，如果TCP包装器的头文件和库文件是分别安装在/usr/local/include 和 /usr/local/lib 下面的话，configure脚本应该是像这样：
env CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" \
./configure --with-wrappers
---------------------------------------------------------------------------------------------
注意：有些shell，比如源自Bourne sh的shell，不需要使用env命令。在有些情况下，环境变量需要通过其它语法来指定。
---------------------------------------------------------------------------------------------
4.4 构建
一旦你已运行configure脚本，那么configure脚本输出的最后一行应当是：
Please "make depend" to build dependencies
如果不是上面的这行的话，则说明configure脚本失败了，你需要参看它的输出来决定是在什么地方出了点问题。除非configure完全成功了，否则你不能进入到下一步。
要构建依赖关系，运行命令：
make depend
现在构建整个系统，这一步将实际编译OpenLDAP。
make
你应当小心地检查该命令的输出来确保所有的东西都已经正确构建了。注意这个命令构建LDAP库,相应的客户端和slapd以及slurpd。
4.5 测试
一旦配置和编译都正确完成之后，你应当运行测试套件（suite）来验证构建过程是正确的。
make test
作用在你确定的配置之上的测试将开始运行并且所有的测试都应该通过。某些测试，比如对复制（replication）的测试，可能会被忽略。
4.6 安装
一旦你成功地测试了软件之后，你就要安装它了。你需要拥有对你在configure时指定的安装目录有写权限。默认情况下OpenLDAP是安装在/usr/local目录下的。如果你用--prefix配置选项改变了该设置，它将被安装在你指定的位置。
典型的，安装需要你有超级用户权限。在OpenLDAP源代码的顶层目录，键入：
su root -c 'make install'
然后会给出提示让你输入正确的密码。
你应当小心地检查该命令的输出来确保所有的东西都已经正确安装了。默认情况下你会在/usr/local/etc/openldap 目录下找到slapd的配置文件。参看“slapd的配置文件”一节以获得更多信息。
5.slapd的配置文件
一旦OpenLDAP被正确构建并安装了之后，你就得准备配置slapd以便在你的站点上使用了。slapd的运行时配置文件主要是slapd.conf，通常是安装在/usr/local/etc/openldap 目录下面。
也可以通过slapd或者slurpd的命令行选项指定另一个配置文件。本节将描述配置文件的通用格式，之后是对常用的配置文件指令的一个详细的叙述。
5.1 配置文件格式
slapd.conf文件包含三中类型的配置信息：全局的，特定后端（backend)的,特定数据库的。全局的信息首先被指定，紧接着是与特定后端相关的信息，之后是与特定数据库实例相关的信息。全局的指令可以被后端的和/或数据库的指令重写（override），而后端的指令也可以被数据库的指令重写。
空行和以“#”开头的注释行将被忽略。如果一行以空格开头，它将被认为是接着前一行的（即使前一行是注释）。
slapd.conf的通用格式如下：
# global configuration directives
# backend definition
backend
# first database definition & config directives
database
# second database definition & config directives
database
# second database definition & config directives
database
# subsequent backend & database definitions & config directives
...
一个配置指令可能会有参数。如果是这样的话，它们用空格进行分隔。如果一个参数要包含空格，那么这个参数应当用双引号“像这样”引起来。如果一个参数包含一个双引号或者一条斜线“ \”，那么这个字符应该用斜线字符“\”进行转义。
本发布版附带有一个安装在/usr/local/etc/openldap目录下的配置文件示例。包含模式（schema）定义（属性类型和对象类，attribute types and object classes）的几个文件放在/usr/local/etc/openldap/schema目录下。
5.2 配置文件指令
本节详细讲解了常用的配置指令的一些细节。要得到完整的内容，请参阅slapd.conf的手册。本节将把配置文件指令分成全局的，特定后端的，特定数据库的三类，给出每个指令及其默认值（如果有的话），并且给出它的使用示例。
5.2.1 全局指令
本节所给出的指令将作用于所有的后端和数据库，除非它们在后端和数据库的定义中被重写。需要用实际文本来替换的参数用<>表示。
5.2.1.1 access to [ by ]+
该指令允许一个或者多个请求提交者（由指定）在一定的访问级别下（由指定)访问一组指定的条目和/或属性（由指定）。参看本章节的“访问控制”一节以获得基本用法的一个总结。
----------------------------------------------------------------------------------------------------------
注意：如果不指定access指令，默认的访问控制策略，access to * by * read，将会允许所有通过验证的和匿名的用户拥有读权限。
----------------------------------------------------------------------------------------------------------
5.2.1.2 attributetype
该指令定义了一个属性类型。请参看“模式规范”一节获得有关该指令的信息。
5.2.1.3. idletimeout
指定一个等待的秒数，如果超过这个时间客户都没有请求提交就关掉与客户的连接。默认情况下，idletimeout为0，表示禁用该功能。
5.2.1.4. include
该指令指定slapd读入所给文件中的内容。被包含文件应该遵从slapd配置文件的通用格式。往往是将包含有模式定义的文件包含近来。
-----------------------------------------------------------------------------------------------------------
注意：你在使用这个指令的时候千万要小心--因为include指令对嵌套的层数没有做限制。而且也没有一种机制能够发现死循环。
-----------------------------------------------------------------------------------------------------------
5.2.1.5. loglevel
该指令指定了debug声明和统计数据应当被记入日志文件的级别(currently logged to the syslogd( LOG_LOCAL4 facility)。你必须将OpenLDAP配置为--enable-debug （默认）该指令才会工作(except for the two statistics levels, which are always enabled)。log levels是可以相加的。要想知道数字与debuglevel的对应关系，可以用-? 为参数启动slapd,你也可以参考下面的这个表。的可能值是：
表5.1: Debugging Levels
Level Description
-1 nable all debugging
0 no debugging
1 trace function calls
2 debug packet handling
4 heavy trace debugging
8 connection management
16 print out packets sent and received
32 search filter processing
64 configuration file processing
128 access control list processing
256 stats log connections/operations/results
512 stats log entries sent
1024 print communication with shell backends
2048 print entry parsing debugging
示例：
loglevel -1
这将导致大量的调试信息被记入日志文件。
默认：
loglevel 256
5.2.1.6. objectclass
该指令定义了一个对象类。请参看“模式规范”一节获得有关如何使用该指令的信息。
5.2.1.7. referral
该指令指定了一个指针，当服务器的slapd找不到一个本地的数据库来处理一个请求的时候，它把该指针回传给客户。
示例：
referral ldap://root.openldap.org
这将把非本地的请求“推”到OpenLDAP的根服务器上。“聪明的”LDAP客户会向反馈回来的指针所指的服务器重新发出请求。但是得注意大多数客户仅仅知道怎么样处理简单的LDAP的URL，其中包含主机部分和可选的DN部分。
5.2.1.8. sizelimit
该指令指定了一次搜索操作所能获得的最大条目数。
默认：
sizelimit 500
5.2.1.9. timelimit
该指令指定了slapd花在回答一个搜索请求上的最大秒数（实时）。如果在这段时间内请求没有完成，服务器端将返回一个超时给客户端。
默认：
timelimit 3600
5.2.2. 通用后端指令
本节中的指令将只应用在定义它们的后端之上。每一种后端都支持它们。后端指令作用到所有相同类型的数据库实例上面，对于具体的指令，也可能在数据库指令中被重写。
5.2.2.1. backend
该指令标志着后端声明的开始。应当是在表5.2中列出的后端类型之一。
表5.2: 后端数据库类型
Types Description
bdb Berkeley DB transactional backend
dnssrv DNS SRV backend
ldap Lightweight Directory Access Protocol (Proxy) backend
ldbm Lightweight DBM backend
meta Meta Directory backend
monitor Monitor backend
passwd Provides read-only access to passwd(5)
perl Perl Programmable backend
shell Shell (extern program) backend
sql SQL Programmable backend
示例：
backend bdb
这标志着一个新的BDB后端定义的开始。
5.2.3. 通用数据库指令
本节中的指令只会作用到定义它们的数据库上面。他们被每一种数据库支持。
5.2.3.1. database
该指令标志着数据库实例声明的开始。应该是列在表5.2中的被支持的后端类型之一。
示例：
database bdb
这标志着一个新的BDB数据库实例声明的开始。
5.2.3.2. readonly { on | off }
该指令将数据库置为“只读”模式。任何企图修改数据库的操作都将返回“无法完成”（"unwilling to perform"）错误。
默认：
readonly off
5.2.3.3. replica
replica uri=ldap[s]://[:] | host=[:]
[bindmethod={simple|kerberos|sasl}]
["binddn="]
[saslmech=]
[authcid=]
[authzid=]
[credentials=]
[srvtab=]
This directive specifies a replication site for this database. The uri= parameter specifies a scheme, a host and optionally a port where the slave slapd instance can be found. Either a domain name or IP address may be used for . If is not given, the standard LDAP port number (389 or 636) is used.
host is deprecated in favor of the uri parameter.
uri allows the replica LDAP server to be specified as an LDAP URI such as ldap://slave.example.com:389 or ldaps://slave.example.com:636.
The binddn= parameter gives the DN to bind as for updates to the slave slapd. It should be a DN which has read/write access to the slave slapd's database. It must also match the updatedn directive in the slave slapd's config file. Generally, this DN should not be the same as the rootdn of the master database. Since DNs are likely to contain embedded spaces, the entire "binddn=" string should be enclosed in double quotes.
The bindmethod is simple or kerberos or sasl, depending on whether simple password-based authentication or Kerberos authentication or SASL authentication is to be used when connecting to the slave slapd.
Simple authentication should not be used unless adequate integrity and privacy protections are in place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.
Kerberos authentication is deprecated in favor of SASL authentication mechanisms, in particular the KERBEROS_V4 and GSSAPI mechanisms. Kerberos authentication requires binddn and srvtab parameters.
SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the saslmech parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials respectively. The authzid parameter may be used to specify an authorization identity.
See the chapter entitled Replication with slurpd for more information on how to use this directive.
5.2.3.4. replogfile
This directive specifies the name of the replication log file to which slapd will log changes. The replication log is typically written by slapd and read by slurpd. Normally, this directive is only used if slurpd is being used to replicate the database. However, you can also use it to generate a transaction log, if slurpd is not running. In this case, you will need to periodically truncate the file, since it will grow indefinitely otherwise.
See the chapter entitled Replication with slurpd for more information on how to use this directive.
5.2.3.5. rootdn
该指令指定一个不受当前数据库的访问控制和操作限制的的DN。不必是一个当前数据库或者当前目录中的条目。也可能一个SASL身份证（identity）。
基于条目的示例：
rootdn "cn=Manager,dc=example,dc=com"
基于SASL的示例：
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
参看”SASL认证“一节获得更多关于SASL认证身份的信息。
5.2.3.6. rootpw
该指令用来为rootdn（当rootdn被设置为数据库中的一个条目时）设定一个密码。
示例：
rootpw secret
将密码设为RFC 2307中的格式也是可以的。slapdpasswd可以用来产生哈希密码。
示例：
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
哈希密码用命令slappasswd -s secret产生。
5.2.3.7. suffix
该指令指定了将传递给后端数据库的请求的DN的后缀。一个数据库可以有多个后缀，但是每个数据库定义中至少要有一个。
示例：
suffix "dc=example,dc=com"
只有当发出的请求是以"dc=example,dc=com"为DN的后缀的时候这个请求才可以传递给这个后端。
-----------------------------------------------------------------------------------------------------------
注意：当请求传递的对象，即后端选定之后，slapd在每个数据库定义中顺序查找suffix行。因此，如果一个数据库后缀是另一个的前缀的话，在配置文件中它必须出现在另一个之后。
Note: When the backend to pass a query to is selected, slapd looks at the suffix line(s) in each database definition in the order they appear in the file. Thus, if one database suffix is a prefix of another, it must appear after it in the config file.
-----------------------------------------------------------------------------------------------------------
5.2.3.8. syncrepl
syncrepl rid=
provider=ldap[s]://[:port]
[type=refreshOnly|refreshAndPersist]
[interval=dd:hh:mm:ss]
[searchbase=]
[filter=]
[scope=sub|one|base]
[attrs=]
[attrsonly]
[sizelimit=]
[timelimit=]
[schemachecking=on|off]
[updatedn=]
[bindmethod=simple|sasl]
[binddn=]
[saslmech=]
[authcid=]
[authzid=]
[credentials=]
[realm=]
[secprops=]
This directive specifies the current database as a replica of the master content by establishing the current slapd( as a replication consumer site running a syncrepl replication engine. The master database is located at the replication provider site specified by the provider parameter. The replica database is kept up-to-date with the master content using the LDAP Content Synchronization protocol. See draft-zeilenga-ldup-sync-xx.txt (a work in progress) for more information on the protocol.
The rid parameter is used for identification of the current syncrepl directive within the replication consumer server, where uniquely identifies the syncrepl specification described by the current syncrepl directive. is non-negative and is no more than three decimal digits in length.
The provider parameter specifies the replication provider site containing the master content as an LDAP URI. The provider parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for . Examples are ldap://provider.example.com:389 or ldaps://192.168.1.1:636. If is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located at the consumer site, whereas the replica specification is located at the provider site. syncrepl and replica directives define two independent replication mechanisms. They do not represent the replication peers of each other.
The content of the syncrepl replica is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes searchbase, scope, filter, attrs, attrsonly, sizelimit, and timelimit parameters as in the normal search specification. The syncrepl search specification has the same value syntax and the same default values as in the ldapsearch(1) client search tool.
The LDAP Content Synchronization protocol has two operation types: refreshOnly and refreshAndPersist. The operation type is specified by the type parameter. In the refreshOnly operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the interval parameter. It is set to one day by default. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd. Further updates to the master replica will generate searchResultEntry to the consumer slapd as the search responses to the persistent synchronization search.
The schema checking can be enforced at the LDAP Sync consumer site by turning on the schemachecking parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored into the replica content. Every entry in the replica should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off.
The updatedn parameter specifies the DN in the consumer site which is allowed to make changes to the replica. This DN is used locally by the syncrepl engine when updating the replica with the entries received from the provider site by using the internal operation mechanism. The update of the replica content is subject to the access control privileges of the DN. The DN should have read/write access to the replica database. Generally, this DN should not be the same as rootdn.
The binddn parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the master database.
The bindmethod is simple or sasl, depending on whether simple password-based authentication or SASL authentication is to be used when connecting to the provider slapd.
Simple authentication should not be used unless adequate integrity and privacy protections are in place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.
SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the saslmech parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials, respectively. The authzid parameter may be used to specify an authorization identity.
The realm parameter specifies a realm which a certain mechanisms authenticate the identity within. The secprops parameter specifies Cyrus SASL security properties.
The syncrepl replication mechanism is supported by the three native backends: back-bdb, back-hdb, and back-ldbm.
See the LDAP Sync Replication chapter of the admin guide for more information on how to use this directive.
5.2.3.9. updatedn
This directive is only applicable in a slave slapd. It specifies the DN allowed to make changes to the replica. This may be the DN slurpd( binds as when making changes to the replica or the DN associated with a SASL identity.
Entry-based Example:
updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the Replication with slurpd chapter for more information on how to use this directive.
5.2.3.10. updateref
This directive is only applicable in a slave slapd. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each URL is provided.
Example:
updateref ldap://master.example.net
5.2.4. BDB数据库指令
这一类指令只会作用于BDB数据库上。也就是说，它们必须跟在一个"database bdb"行之后并且出现在任何随后的"backend" 或者 "database"行之前。要想获得BDB配置指令的完整参考，请参阅slapd-bdb。
5.2.4.1. directory
该指令指定包含数据和索引的BDB文件所在的目录。
默认：
directory /usr/local/var/openldap-data
5.2.4.2. sessionlog
This directive specifies a session log store in the syncrepl replication provider server which contains information on the entries that have been scoped out of the replication content identified by . The first syncrepl search request having the same value in the cookie establishes the session log store in the provider server. The number of the entries in the session log store is limited by . Excessive entries are removed from the store in the FIFO order. Both and are non-negative integers. has no more than three decimal digits.
The LDAP Content Synchronization operation that falls into a pre-existing session can use the session log store in order to reduce the amount of synchronization traffic. If the replica is not so outdated that it can be made up-to-date by the information in the session store, the provider slapd will send the consumer slapd the identities of the scoped-out entries together with the in-scope entries added to or modified within the replication content. If the replica status is outdated too much and beyond the coverage of the history store, then the provider slapd will send the identities of the unchanged in-scope entries along with the changed in-scope entries. The consumer slapd will then remove those entries in the replica which are not identified as present in the provider content.
5.2.5. LDBM数据库指令
这一类指令只会作用于LDBM数据库上。也就是说，它们必须跟在一个"database ldbm"行之后并且出现在任何随后的"backend" 或者 "database"行之前。要想获得LDBM配置指令的完整参考，请参阅slapd-ldbm。
5.2.5.1. cachesize
该指令指定LDBM后端数据库实例在缓存中维护的条目的大小。
默认：
cachesize 1000
5.2.5.2. dbcachesize
该指令指定了与每个打开的索引文件相关联的缓存的字节大小。如果不被下层的数据库方法支持的话，该指令将会不给出任何提示地被忽略。增加这个值会占用更多的内存但是却会带来性能上的大幅提升，尤其是在修改或者建立索引的时候。
默认：
dbcachesize 100000
5.2.5.3. dbnolocking
这个选项，如果出现，将会禁止锁定数据库。启用这个选项可能会提高性能，但付出的代价是增大了数据安全的风险。
5.2.5.4. dbnosync
这个选项作用在磁盘上。当内存中的数据发生改变之后，磁盘上的数据库内容并不立即与之保持同步。启用这个选项可能会提高性能，但付出的代价是增大了数据一致性上的风险。
5.2.5.5. directory
该指令指定包含数据和索引的LDBM文件所在的目录。
默认：
directory /usr/local/var/openldap-data
5.2.5.6. index { | default} [pres,eq,approx,sub,none]
该指令指定了为所给属性所维护的索引。如果仅给出一个，默认的索引也会被维护。
示例：
index default pres,eq
index uid
index cn,sn pres,eq,sub
index objectClass eq
The first line sets the default set of indices to maintain to present and equality. The second line causes the default (pres,eq) set of indices to be maintained for the uid attribute type. The third line causes present, equality, and substring indices to be maintained for cn and sn attribute types. The fourth line causes an equality index for the objectClass attribute type.
By default, no indices are maintained. It is generally advised that minimally an equality index upon objectClass be maintained.
index objectClass eq
5.2.5.7. mode
该指令指定了新近创建的数据库索引文件所应具有的文件保护模式。
默认：
mode 0600
5.3 访问控制
对slapd的条目和属性的访问是由访问配置文件指令控制的。通用的访问控制格式是这样的：
::= access to
[by ]+
::= * |
[dn[.]= | dn.=]
[filter=] [attrs=]
::= regex | exact
::= base | one | subtree | children
::= [val[.]=] | ,
::= | entry | children
::= * | [anonymous | users | self
| dn[.]= | dn.=]
[dnattr=]
[group[/[/][.]]=]
[peername[.]=]
[sockname[.]=]
[domain[.]=]
[sockurl[.]=]
[set=]
[aci=]
::= [self]{|}
::= none | auth | compare | search | read | write
::= {=|+|-}{w|r|s|c|x|0}+
::= [stop | continue | break]
这里的选择条目和/或属性并在其上应用访问控制，则指定什么样的实体可以访问条目和属性，指定访问级别。多个 是受支持的，以允许多种实体可以有不同的访问级别访问相同的条目和属性。不是所有的访问控制选项都在这里描述；更多信息可参见slapd.access手册。
5.3.1. 控制对什么的访问（What to control access to）
决定了将要应用访问控制的条目和属性。条目通常通过两种方式选定：通过DN或者通过过滤器。下面的示例通过DN选择条目：
to *
to dn[.]=
to dn.=
第一种格式用于选择所有的条目。第二种格式用于选择标准化的DN与所给正则表达式相匹配的条目（第二种格式不会在本文档中深入讨论）。第三种格式用语选择在所请求的DN范围之内的条目。是一个标识名的字符串表示，如RFC2253中所述。
DN范围可以是以下四种之一：base, one, subtree, 或者 children。这里的base只与所给的DN相匹配，one只与父条目是所给DN的条目相匹配，subtree只与根为所给DN的子树下是所有条目相匹配，而children匹配所有位于DN之下的条目（除了以DN为标识名的条目以外）。
比如，如果目录包含以如下方式命名的条目：
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
那么：
dn.base="ou=people,o=suffix" 匹配 2;
dn.one="ou=people,o=suffix" 匹配 3, 和 5;
dn.subtree="ou=people,o=suffix" 匹配 2, 3, 4, 和 5;
dn.children="ou=people,o=suffix" 匹配 3, 4, 和 5。
条目也可以通过过滤器收集起来：
to filter=
这里的是LDAP搜索过滤器的一个字符串表示，如RFC2254所述。比如：
to filter=(objectClass=person)
注意到条目可以同时通过DN和过滤器来搜集，只需要同时把两者都包含在子句中即可：
to dn.one="ou=people,o=suffix" filter=(objectClass=person)
条目的属性通过在搜集器中包含用逗号分隔的属性名列表指定：
attrs=
一个属性的具体取值通过单个的属性名和值选取器来指定：
attrs= val[.