LDAP配置

LDAP 中的访问控制列表
本节介绍Senior Level Linux Professional (LPIC-3) 301 考试的303.2 主题的内容。

此主题的权值是2。

在本节中，学习如何：
∙计划LDAP 访问控制列表
∙了解访问控制语法
∙授予和撤消LDAP 访问权限
LDAP 树中可以存储各种数据，包括电话号码、出生日期和工资表信息。

其中一些数据可能是公开的，一些数据可能只能由由特定的人访问。

根据用户的不同，同样的信息可能有不同的限制。

例如，也许只有记录的所有者和管理员可以更改电话号码，但是每个人都可以读取这些号码。

访问控制列表(ACL) 处理这些限制的配置。

计划LDA P 访问控制列表
在开始编写配置之前，应该确定要实现的目标。

树的哪部分包含敏感信息？哪些属性需要保护，保护其不被谁访问？如何使用树？
ACL 的组件
ACL 条目提供三条信息：
1.ACL 指定what条目和属性
2.ACL 应用于who
3.授予的access级别
指定 “what” 子句时，可以选择根据对象的区分名（distinguished name ，DN ）、LDAP 风格的查询筛选器、属性列表或以上三者的组合来进行筛选。

最简单的子句允许一切内容，但也可以有很多限制。

根据 DN 筛选允许您指定精确匹配，比如
ou=People,dc=ertw,dc=com 或正则表达式 （参阅 “正则表达式”）
查询筛选器可以匹配特定的 objectClass 或其他属性。

属性列表中的属性名称用逗号分隔。

更复杂的匹配条件可以是 “身份是管理员的
ou=People,dc=ertw,dc=com 下的所有密码条目”。

可以灵活地确定将 ACL 应用于 who 。

用户一般由绑定到树上的 DN 来识别，这称为 bindDN 。

每个 LDAP 条目可以具有一个
userPassword 属性，用于对特定的用户进行身份验证。

在一些上下
文中，您可以将当前登录的用户称为自己， 这有利于允许用户编辑自己的详细信息。

如果用户没有绑定，则被视为匿名用户。

默认情况下，匿名用户可以读取树，所以您必须决定是否需要更改此行为。

可以通过 IP 地址或
用于连接的方法（比如明文和加密的方法）来对匿名用户（或任何用户）进行分割。

一旦确定了 what 和 who ，必须确定访问级别。

访问权限可以是无 一直到写 访问。

还可以指定用户可以验证条目，但不可以读取；或可以允许用户读取、搜索和比较访问。

无论如何配置您的 ACL ，任何已配置的 rootDN 用户可以完全控制其数据库。

不可以对此进行更改，除非将 rootDN 配置从 slapd.conf 中移除。

了解访问控制语法
ACL 的基本格式使用 Backus-Naur Form 表示，也就是：
access to <what> [ by <who> [ <access> ] [ <control> ] ]+
描述 what
what 描述 ACL 强制的属性和条目。

实现此目标的 BNF 表示法如清单 1 所示。

清单 1. ACL 的 what 部分的 BNF 描述
清单 1 的一些元素在此处没有定义，例如DN 和正则表达式。

区分名的形式是已知的，正则表达式最好在BNF 之外研究。

清单 1 显示了ACL 的 what 部分的描述可以是星号字符(*)（它可以匹配一切内容），或者是DN、LDAP 筛选器、属性列表的组合。

后者可以使用三个组件中的一个或多个，因为它们分别被方括号括起来。

清单 2 显示了与DN 匹配的三个what 子句
清单 2. 三个示例what 子句
第一个示例仅与ou=people,dc=ertw,dc=com条目匹配。

如果使用此ACL，则它不与任何子条目匹配，例如cn=Sean Walberg,ou=people,dc=ertw,dc=com，也不与父条目匹配。

第二个示例与第一个相似，但是它使用正则表达式，并使用美元符号($) 字符锚定（anchor）搜索字符串。

锚与字符串的位置匹配，而不是与字符串的一部分匹配。

美元符号与字符串的结尾部分匹配，因此第二个示例与以ou=people,dc=ertw,dc=com结尾的任何条目匹配，包括cn=Sean
Walberg,ou=people,dc=ertw,dc=com。

注意，如果没有锚，搜索字符串可以位于目标内的任何位置，例如ou=people,dc=ertw,dc=com,o=MegaCorp。

清单 2 中的第三个示例显示另一个锚，^，它与字符串的开始部分匹配。

第三个示例也使用另一个正则表达式.*。

句点与任何一个字符匹配，星号与0 个或多个前导字符匹配。

因此.*与一个或多个字符的任何字符串匹配。

总之，第三个示例与以cn=Sean开始、以dc=com结尾的任何条目匹配。

还可以根据LDAP 查询进行筛选，这对objectClass上的搜索最有帮助。

例如，
filter=(objectClass=posixAccount)的 what 子句仅与具有posixAccount的objectClass的条目匹配。

要复习objectClass，请查看此系列的第一篇教程，LPI 301 考试准备：概念、体系结构和设计。

what 子句的最后一个选项是指定属性。

最常见的用法是限制谁可以查看私有属性，尤其是密码。

使用attrs=userPassword匹配密码属性。

一旦确定了要匹配的的条目和属性，就必须描述规则将应用于谁。

描述who
访问将根据在客户机绑定到树时提供的DN 来应用到用户。

DN 通常可以在树上找到，但也可能是slapd.conf 中提供的rootDN。

清单 3 显示ACL 的 who 部分的BNF 表示法。

清单 3. 匹配ACL 的who 部分的BNF 表示法
<who> ::= * | [anonymous | users | self[.<selfstyle>]
| dn[.<basic-style>]=<regex> |
dn.<scope-style>=<DN>]
[dnattr=<attrname>]
[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
[peername[.<peernamestyle>]=<peername>]
[sockname[.<style>]=<sockname>]
[domain[.<domainstyle>[,<modifier>]]=<domain>]
[ssf=<n>]
[transport_ssf=<n>]
[tls_ssf=<n>]
[sasl_ssf=<n>]
<style> ::= {exact|regex|expand}
<selfstyle> ::= {level{<n>}}
<dnstyle> ::= {{exact|base(object)}|regex
|one(level)|sub(tree)|children|level{<n>}}
<groupstyle> ::= {exact|expand}
<peernamestyle> ::= {<style>|ip|path}
<domainstyle> ::= {exact|regex|sub(tree)}
<modifier> ::= ={expand}
与ACL 的 what 部分中一样，星号匹配一切内容。

要想获得更特定的功能，还有许多选项。

OpenLDAP 定义anonymous、users和self三种快捷方式。

这些快捷方法分别与未注册用户、已验证用户和当前登录用户匹配。

后面的self通常用于允许登录用户编辑自己的配置文件的组件。

这基于DN 的精确匹配；如果将用户的信息分割在不同的条目中，则self关键字仅适用于与用户绑定的条目。

有关self关键字的一个有趣的特性是：还可以使用level关键字将ACL 应用于用户条目的父条目或子条目。

使用self.level{1}匹配用户的条目和父条目，而self.level{-1}匹配用户的条目和任何直接附加的子条目。

继续讨论DN，可以分别使用dn.exact="DN"和dn.regex="regex"执行正则表达式或精确匹配。

稍后一个示例将显示如何使用正则表达式动态地将what 和 who 捆绑到一起。

可以使用dnattr关键字保护任意条目，此关键字还需要属性名称。

如果请求者的DN 出现在目标的特定属性中，则与ACL 匹配。

例如，如果将dnattr=manager添加到您的ACL 中，然后将manager: cn=Joe Blow,ou=people,dc=ertw,dc=com添加到 Fred Smith 的条目中，ACL 将在Joe Blow 访问Fred Smith 的条目时进行匹配。

group 关键字与 dnattr 类似，除了参数表示在树中其他地方定义的组，而非条目中的属性。

默认情况下，
此组具有 groupOfNames 的 objectClass ，其成员在 member 属性中引用。

使用 peername 、 sockname 和 domain 关键字匹配客户机连接的属性。

peername 表示客户机的 IP 地址，例如 peernameip=127.0.0.1。

sockname 用于命名管道上的连接，并不常用。

domain 匹配与 IP 地址相关的主机名，它容易被假冒。

最后一组选项表示连接的 Security Strength Factor (SSF)，它是连接安全级别的 OpenLDAP 术语。

当涉及到用于连接 OpenLDAP 的安全机制时，比如 Transport Layer Security (TLS) 和 Simple Authentication and Security Layer (SASL)，这些选项将变得更加清楚。

前面所有的项可以一起使用。

例如，可以仅允许来自特定 IP 地址范围的特定管理员对具有特定加密级别的密码字段进行写访问。

也可以不这么严格，例如仅要求有效登录，或甚至接受每个人，而不考虑身份验证。

描述 access
一旦已经确定谁在访问树，以及他们准备访问什么内容，就必须指定访问的级别。

清单 4 显示 ACL 的 access 部分的 BNF 表示法。

清单 4. 描述 access 子句格式的 BNF 表示法
使用 level 格式指定访问时，每个后续的级别都包括其前面的级别。

也就是说， read 访问级别包括
search 、 compare 、auth 和 disclose 访问级别。

none 和 disclose 两者都拒绝任何访问，但一些可
能泄漏有关树内容的信息的错误消息会在 none 下移除，在 disclose 下允许。

还可以使用 priv 格式按照允许的 LDAP 操作指定访问级别。

这些选项与 level 格式的运行机制相反，这里的 w 代表 write ，0 代表 none 。

当使用 priv 格式指定 access 时，与使用 level 时的情况一样没有隐含的进展。

如果想提供完全访问，则必须使用 wrscx 。

在字母前的 =/+/- 符号表示如果应用多个规则，那么指定的访问如何与当前的访问级别合并。

使用 =，则忽略所有先前定义的访问，要使用的值跟在等号后面。

使用 + 和 - 分别在当前级别中添加或减少访问。

了解控制
默认情况下，OpenLDAP 采用首次匹配法来应用访问列表。

OpenLDAP 查找与 what 子句匹配的第一个 ACL 条目，并在此条目中查找与 who 部分匹配的第一个条目。

这与在描述访问级别之后放置关键字
stop 一样。

其他两个选项是 continue 和 break 。

如果使用
continue ，则在与 who 部分匹配的下一
行中搜索当前
ACL 条目。

如果使用 break ，则当前 ACL 条目的处理停止，但是 OpenLDAP 查找下一个与 who 子句匹配的 ACL 条目。

回页首
组合 what 、who 和 access
现在已经看到 ACL 的三个（四个，如果将 control 算上的话）部分，可以将其放到一个策略中。

清单 5 显示了典型的 ACL 列表，允许已注册的用户读取树并允许用户更新自己的密码（但不能读取）。

清单 5. 简单的 ACL 设置
第一个子句匹配尝试访问 userPassword 字段的任何用户。

授予用户对自己的条目的写权限和身份验证权限，这是通过等号强制执行的。

授予匿名用户身份验证权限。

当用户绑定到树上时，它就是匿名用户；因此，匿名用户需要 auth 权限，这样他们才能登录成为正常的有权限的用户。

如果要请求的信息不是密码，则考虑第二个 ACL 条目。

另外，用户对自己的条目（由于第一个 ACL 条目，userPassword 字段除外）具有完全的控制，而所有经过验证的用户对树的其余部分具有读访问。

清单 6 显示了使用正则表达式将 what 和 who 子句捆绑到一起的 ACL 条目。

清单 6.
应用正则表达式
清单 6 允许用户编辑树的
ou=addressbook,dc=ertw,dc=com 部分下的相应记录。

[^,]+ 匹配逗号之前的一切内容，但不包括逗号，对于第一个圆括号集合，圆括号将匹配的文本保存到 $1 中，对于下一个，保存到 $2 中，依此类推直到包括 $9。

who 子句重新使用用户的名称来确定谁可以访问条目。

如果用户的名称与要访问的条目名称相同，则授予用户写访问。

否则，就授予验证的用户读访问。

回页首
实际问题
由于首次匹配行为，应该将比较具体的ACL 条目置于列表的顶部；否则，先前的ACL 很有可能导致列表中较低的ACL 被忽略。

这种技术还可以用于授予和撤销特定用户的访问。

仅将您特定的ACL 子句放在列表顶部。

保持您的ACL 尽量简单。

这样做可以减少错误的可能性，还可以改善性能。

每次对树执行操作时必须解析ACL。

LDAP 复制
本节介绍Senior Level Linux Professional (LPIC-3) 301 考试的303.3 主题的内容。

本主题的权值是5。

在本节中，将完成以下任务：
∙了解复制概念
∙配置OpenLDAP 复制
∙执行和管理slurpd
∙分析复制日志文件
∙了解副本中心（replica hub）
∙配置LDAP 参考
∙配置LDAP 同步复制
有时候，您的需求可能不仅是一个服务器。

您的组织可能依赖LDAP，以至于您的LDAP 服务器损失是不可接受的，或者您的查询量太高了，以至于必须将您的查询分割到多个服务器上。

甚至可能是二者的组合；但是在任何情况下，您都需要使用多个服务器。

使用多个服务器，可以将您的树分隔到不同的服务器上，但是这将导致可靠性下降——更不要说难以平衡您的查询了。

理想情况是，每个服务器都有树的相同副本。

任何写操作都将以实时方式传播到其他服务器，从而其他所有服务器都保持更新。

此操作称为复制。

这种称为多主体（multi-master）的场景十分复杂，因为数据没有一个清晰的所有者。

还常常会形成主从关系。

LDAP 查询可以针对所有服务器进行。

这可以扩展为副本中心场景，其中一个从服务器从主服务器复制数据，然后再依次复制到其他一些从服务器上。

OpenLDAP 提供两种方法来完成复制。

第一种方法是通过slurpd，这个单独的后台程序监视主服务器上的更改并将更改应用到从服务器。

第二种方法是使用slapd 的LDAP 同步复制引擎，称为syncrepl。

slurpd 方法现在已经过时了；人们都使用syncrepl。

这两种方法都将在本节中介绍。

基于slurpd 的复制
基于slurpd 的复制是推式复制，原因在于主服务器将任何更改都推给从服务器。

如果客户机试图更新从服务器，则从服务器配置并发送一个转介（referral）到客户机，而将客户机指向主服务器。

客户机重新向主服务器发送请。

Slurpd 是从slapd.conf 中配置的独立后台程序。

slurpd 复制模型内的数据流
主服务器处理来自客户机的所有写操作，并拥有权威的数据源。

对主服务器树的任何更改都将写入复制日志中，它由slurpd 监视。

slurpd 注意到复制日志中的更改时，就会将更改推至所有从服务器。

图1 显示了典型的slurpd 行为。

图 1. slurpd 复制模型中的数据流
过程如下：
1.客户机发送更新请求，此请求正好被从服务器接收。

2.从服务器知道写操作只能来自其复制伙伴，因此将转介发送回客户机，将其指向主服务器。

3.客户机将更新请求重新发送给主服务器。

4.主服务器执行更新并将更改写入复制日志中。

5.slurpd，也在主服务器上运行，注意到复制日志中的更改。

6.slurpd 将更改发送给从服务器。

这样，从服务器可以在几乎没有延迟的情况下与主服务器保持更新。

如果发生任何中断，或者从服务器上发生错误，slurpd 始终知道哪个从服务器需要哪些更新。

配置slurpd
配置基于slurpd 的复制需要下列步骤：
1.创建副本帐户，slurpd 用其对从服务器副本进行验证。

2.使用从服务器的名称配置主服务器。

3.将从服务器配置为副本，包括任何需要的ACL。

4.将数据库从主服务器复制到从服务器。

创建副本很简单；惟一的要求是帐户必须拥有userPassword属性中的密码。

可以使用inetOrgPerson objectClass，就像属于人们的大多数帐户一样，或者可以使用更一般的objectClass，比如添加了simpleSecurityObject辅助objectClass的account。

回忆第一篇教程，结构化的objectClasses 定义条目（因此每个条目仅可以使用一个），然而辅助objectClasses将属性添加到任何条目，而不考虑结构化的objectClass。

清单7 显示要添加副本帐户的LDIF 代码。

清单7. 副本帐户的LDIF 代码
清单7 显示了一个稀疏条目——只有用户名、密码和描述，这对于复制已经足够了。

描述是可选项，但建议在文档中使用。

记住密码；下一步将需要它！
主服务器现在必须配置来将所有更改存储在复制日志中，而且副本必须配置，以便slurpd 可以工作。

必须记住，slurpd 从slapd.conf 读取其配置，且slurpd 将更新推至从服务器。

这将帮助您记住在何处配置复制以及验证凭证属于主服务器。

从服务器可以验证凭证，因为帐户是树的一部分。

清单8 显示了在主服务器上启用复制的配置。

清单8. slurpd 复制的主服务器配置
复制配置在数据库模式中执行，所以一定要确保replica命令位于第一个database配置之后的某个位置。

replica接受key=value形式的几个参数。

uri键使用统一资源标识符(URI) 格式指定从服务器的名称或IP 地址，在从服务器的名称前面加上前缀ldap://。

指定从服务器的名称之后，可以通过suffix选项有选择地配置要复制的数据库名称。

默认情况下，复制所有的数据库。

最后一个要求是提供验证信息，以便slurpd 可以连接到指定的uri。

对于简单验证，只需要binddn、bindmethod和credentials（以前分配的userPassword）。

最后一个难题是告诉slapd 在何处存储其复制日志。

您需要提供完整路径，因为相对文件名不起作用。

不要担心创建文件，因为slapd 将为您创建；但是指定的路径必须可由运行 slapd 和 slurpd 的用户进行写操作。

在从服务器上，必须配置复制帐户，还要告诉从服务器对于任何写操作都应该将转介返回给主服务器。

清单9 显示了此配置。

清单9. 从服务器的配置
updatedn引用以前在主服务器上创建的帐户，slurpd 将使用此帐户将更新推至从服务器。

updateref是另一个LDAP URI，它指向主机。

清单10 显示了在加载前面的配置之后，客户机尝试更新从服务器并接收转介。

清单10. 客户机在尝试更新从服务器之后接收转介
OpenLDAP 命令行客户机不遵循转介，但其他 LDAP 库遵循。

如果您正在复制的环境中使用LDAP，应该验证您的应用程序是否正确遵循转介。

最后一个难题是确保主服务器和从服务器都以相同的数据库开始。

为此，请执行下列步骤：
1.关闭主服务器。

2.关闭从服务器。

3.将所有数据库从主服务器复制到从服务器。

4.启动主服务器和从服务器。

5.启动slurpd。

两个服务器都必须关闭才能复制数据库，以确保没有任何更改并且所有数据都已写入磁盘。

至关重要的一
点是两个服务器具有相同的数据集；否则它们以后可能不同步。

基于slurpd 的复制本质上是在从服务器上再现发生在主服务器上的所有事务，因此任何差别都可能导致问题。

根据您的发行版和启动脚本，slurpd 可以使用 slapd 自动启动。

如果没有自动启动，通过在命令行运行slurpd来启动。

现在，应该可以进行复制了。

在主服务器上创建帐户并测试。

如果尝试更新从服务器，还可以测试从服务
器是否传回转介。

监视复制
了解如何监视复制非常重要，因为可能发生错误，从而导致数据不同步。

监视中的一些技能还有助于调试。

slurpd 将自己的文件存储在/var/lib/ldap/replica（这与由 slapd 生成的复制日志是分开的）中。

此
目录中包含slurpd 自己的复制日志和任何拒绝文件。

如果slurpd 尝试将更新发送到失败的从服务器上，数据将存储在以从服务器名称命名的文件中，其扩展名为 .rej。

在文件内部是组成条目的LDIF 代码，以
及从服务器返回的错误，比如ERROR: Already exists。

清单 11 显示了具有不同错误的 .rej 文件的
内容。

清单11. 复制拒绝文件
time: 1203798375.0
dn: sendmailMTAKey=testing,ou=aliases,dc=ertw,dc=com
changetype: add
objectClass: sendmailMTAAliasObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: external
sendmailMTAKey: testing
sendmailMTAAliasValue:********************
structuralObjectClass: sendmailMTAAliasObject
entryUUID: 5375b66c-7699-102c-822b-fbf5b7bc4860
creatorsName: cn=root,dc=ertw,dc=com
createTimestamp: 20080223202615Z
entryCSN: 20080223202615Z#000000#00#000000
modifiersName: cn=root,dc=ertw,dc=com
modifyTimestamp: 20080223202615Z
清单 11 的拒绝文件以文本错误 ("ERROR: Invalid DN syntax: invalid DN") 开始，其余部分类似于 LDIF 。

注意，第一个属性是 replica ，这是不能处理更新的副本名称，第二个属性是 time ，它是错误发生的时间（使用的是 UNIX 时间戳格式）。

接下来的几个属性来自被拒绝的条目。

最后 7 个属性称为操作属性，它们不属于最初的更改，LDAP 服务器添加这些属性，以进行内部跟踪。

条目还具有一个通用惟一标识符（universally unique identifier ，UUID ）以及有关何时、谁更改记录的一些信息。

在清单 11 中，错误很可能来自从服务器上缺少的模式。

从服务器不理解 sendmailMTAKey 属性是什么，因此条目的 DN 是无效的。

从服务器必须更新其模式，然后复制才能继续。

要修复被拒绝的条目，必须使用树评估错误并修复底层的问题。

一旦知道被拒绝的条目将能够正常应用，则使用 slurpd 的单触发模式（one-shot mode ），并使用命令 slurpd -r /path/to/rejection.rej -o 来应用更新。

-r 参数告诉 slurpd 从给定的复制日志中读取，-o 导致 slurpd 使用单触发模式，这意味着它在处理日志后退出，而不是执行默认行为 —— 等待将更多的条目添加到日志中。

如果复制根本没有进行，最好的方法是从主服务器开始，然后处理从服务器。

首先，关闭 slurpd 并且对树进行更改。

然后，检查复制日志是否在增长；如果没有增长，则主服务器设置不正确。

接下来，启动 slurpd ，并在命令行上传递
-d 255。

这将在 slurpd 处理日志时跟踪其行为。

查找错误，尤其是与打开文件和访问控制有关的错误。

最后，在从服务器上，使用 loglevel auth sync 检查复制发生时的任何错误（slapd 使用 local4 工具记录到 syslog 中，所以您可能需要将 local4.* /var/log/slapd.log 添加到 /etc/syslog.conf 中）。

回页首
LDAP Sync 复制
slurpd 对于复制问题是最直接的解决方案，但是它有一些缺点。

关闭主服务器以同步从服务器通常会不方便，在最坏的情况下还可能影响服务。

slurpd 的推式体系结构也存在不足。

slurpd 基本上运行良好，但是必须创建一些更好的东西。

RFC 4533 概述了LDAP Content Synchronization Operation，它是由LDAP Sync 复制引擎在OpenLDAP 中实现的，称为syncrepl。

syncrepl 构建为一个覆盖，插入在 slapd 核心和后端数据库之间。

对树的所有写入由 syncrepl 引擎跟踪，而不需要单独的服务器实例。

除了复制机制和角色（下文将介绍）之外，其概念与slurpd 相似。

对副本的写操作被拒绝，并将转介传回给主服务器。

syncrepl 从服务器启动，现在将其命名为消费者。

主服务器角色称为提供者。

在syncrepl 中，消费者连接到提供者以更新树。

在最基本的refreshOnly模式中，消费者接收自上一次刷新以来的所有更改条目，请求cookie 跟踪上一次同步的更改，然后断开连接。

在下一次连接时，将cookie 呈现给提供者，它仅发送自上一次同步之后更改的条目。

另一个syncrepl 模式称为refreshAndPersist，像refreshOnly 操作一样启动；但是不会断开连接，消费者保持连接以接收任何更新。

在最初刷新后发生的任何更改都会立即通过连接由提供者发送到消费者。

配置syncrepl
清单12 显示了两个syncrepl 模式（refreshOnly 和refreshAndPersist）的提供者的配置。

清单12. syncrepl 的提供者配置
清单12 的第一行启用syncprov 覆盖。

必须针对数据库配置覆盖；因此，此配置必须位于database配置行之后。

下面两行是可选项，但是它们可以改进可靠性。

syncprov-checkpoint 100 10告诉服务器每100 次写操作或每隔10 分钟将contextCSN的值存储到磁盘中。

contextCSN是以前提到的cookie 的一部分，它可以帮助消费者找到自上一个复制周期之后的某个位置。

syncprov-sessionlog 100将写操作记录到磁盘，这还有助于刷新周期。

有关配置提供者的详细信息，请参见slapo-syncprov(5)手册页。

清单13 显示了复制对的消费者一方
清单13. refreshOnly 模式中的syncrepl 的消费者配置
像slurpd 中的replica命令一样，syncrepl命令需要updateref、尝试复制的树的信息，以及将要使用的验证凭证。

这时，凭证在消费者一方执行，并需要提供者上的足够权限来读取正被复制的树部分。

在消费者上对数据库的更新以rootdn身份运行。

清单13 中特定于syncrepl 的项目是rid、provider、type和interval。

rid将此消费者标识给主服务器。

消费者必须是具有介于 1 到999 之间的惟一ID。

provider是指向提供者的LDAP URI。

type指定只想通过refreshOnly进行定期同步，且interval是每小时。

interval以DD:hh:mm:ss 格式指定。

使用空数据库启动消费者，它将从提供者那里复制数据并每小时更新一次。

转换到refreshAndPersist 模式十分简单。

在清单13 中，移除interval，并将type更改为refreshAndPersist
syncrepl 筛选
值得注意的是，您不必复制整个LDAP 树。

您可以使用下列命令来筛选复制的数据。

表 3. 筛选复制流量的命令
与syncrepl的其他选项一样，这些选项以key=value的形式输入
在本节中，学习如何执行下列操作：
∙使用SSL 和TLS 保护目录
∙配置和生成客户机/服务器证书
∙了解防火墙注意事项
∙配置未验证的访问方法
∙配置用户/密码验证方法
到目前为止，对slapd 的所有访问都是使用明文密码通过未加密通道进行的。

这称为简单验证。

本节探讨如何对客户机-服务器连接进行加密。

使用SSL 和TLS 保护通信
作为保护Web 交易的协议，您可能对Secure Sockets Layer (SSL) 和Transport Layer Security (TLS) 很熟悉。

无论何时浏览https 类型URI，都要使用SSL 或TLS。

TLS 是SSLv3 的改进，在一些情况下它还向后兼容SSL。

由于它们共同的传统和兼容性，通常将其统称为SSL。

SSL 使用X.509 证书，它是由可信任第三方（称为Certificate Authority (CA)）进行了数字签名的一块标准格式的数据。

有效的数字签名意味着已签名的数据没有被篡改。

如果要签名的数据发生了更改，即使是一位，那么签名将不会通过验证。

独立的参与方，例如客户机和服务器，可以验证签名，因为它们都基于对CA 的信任。

在服务器的证书内具有有关服务器所有权的信息，包括它在Internet 上的名称。

因此可以确信您正连接到正确的服务器，因为您连接到的服务器名称与证书中的名称完全匹配，而且在签名前您已经信任CA 来对其进行验证。

证书还包括服务器的公钥，公钥可以用来加密数据，从而只有密钥的所有者可以将其解密。