Sun JavaTM System Directory Server Enterprise Edition 提供了一个浏览器界面和一些命令行工具，用于在复制环境下管理多个服务器、实例和后缀。本章提供了有关目录服务器管理工具的概述信息。
本章包含以下主题：
目录服务器管理概述此文档集的其他指南中提供了有关目录服务器管理框架的信息。
DSCC 和命令行的适用环境Directory Server Enterprise Edition 提供了两个用于管理目录服务器和目录代理服务器的用户界面：浏览器界面和命令行界面，浏览器界面即目录服务控制中心 (Directory Service Control Certer, DSCC)。
确定是否可以使用 DSCC 执行某个过程
本指南中的大多数过程都可以使用命令行或 DSCC 执行。本指南中的过程将说明如何使用命令行完成过程。在大多数情况下，可以使用 DSCC 执行相同的任务。如果可以使用 DSCC 执行某个过程，将在此过程的开头部分提供相关声明。
DSCC 联机帮助提供了有关如何使用 DSCC 执行本指南中过程的详细说明。
DSCC 的适用环境
与使用命令行相比，使用 DSCC 可以更轻松地执行某些操作和任务，如以下部分所述。一般来说，最好使用 DSCC 执行必须应用于多个服务器的命令。
查看服务器和后缀复制状态
DSCC 将显示一些表，这些表包含已在 DSCC 中注册的所有服务器实例、已配置的所有后缀以及每个后缀的状态。
服务器表位于“目录服务器”选项卡上，它显示服务器的操作状态。有关服务器的可能状态的完整列表，请参见目录服务器联机帮助。
后缀表位于“后缀”选项卡上，它显示复制状态信息，如条目数量以及所有丢失更改的数量和存留期。有关此表中显示的信息的详细信息，请参见目录服务器联机帮助。
管理服务器组
服务器组可帮助您监视和配置服务器。可以创建组并为这些组指定服务器。例如，可以按地理位置或功能对服务器进行分组。如果您有大量服务器，则可以对“目录服务器”选项卡上显示的服务器进行过滤，以便只显示组中的服务器。还可以将某个服务器的服务器配置（例如索引或缓存设置）复制到组中的所有其他服务器。有关如何设置和使用服务器组的说明，请参见目录服务器联机帮助。
复制配置设置
DSCC 允许您将现有服务器、后缀或复制协议的配置设置复制到一个或多个其他的服务器、后缀或复制协议。有关如何执行上述各项任务的信息，请参见目录服务器联机帮助。
配置复制
使用 DSCC 可以便捷地设置复制拓扑。只需创建服务器实例，然后使用 DSCC 提供的步骤指定每个服务器的角色即可。DSCC 将自动创建复制协议。有关如何使用 DSCC 配置复制的详细信息，请参见目录服务器联机帮助。
目录服务控制中心界面目录服务控制中心 (Directory Service Control Center, DSCC) 是一个用户界面，允许您使用浏览器管理目录服务器和目录代理服务器。
要配置 DSCC，请参见配置 DSCC。有关使用 DSCC 的信息，请参见以下部分。
DSCC 的管理用户
DSCC 有少数管理登录。
-
操作系统用户。创建服务器实例，是唯一有权使用 dsadm 命令在服务器实例上运行操作系统命令的用户。在某些情况下，DSCC可能会要求提供操作系统用户密码。此用户必须具有密码，并且必须能够创建目录服务器实例。
-
目录管理员。服务器的 LDAP 超级用户。默认 DN 为 cn=Directory Manager。
-
目录管理者。管理目录服务器。此用户与目录管理员具有相同的权限，但受访问控制、密码策略和验证要求的约束。可以根据需要创建任意数量的目录管理者。
-
目录服务管理员。通过 DSCC 管理多台计算机上的服务器配置和数据。对于已在 DSCC 中注册的每个服务器，此用户与目录管理员具有相同的权限，并且是目录管理者组的成员。
访问 DSCC
DSCC 选项卡描述
可以使用 DSCC 中的选项卡浏览界面。
“日常任务”选项卡
“日常任务”选项卡（请参见图 1–2）是打开 DSCC 时看到的第一个界面。它包含指向常用管理任务（如搜索目录数据、检查日志和管理服务器）的链接。
“目录服务器”选项卡
“目录服务器”选项卡（请参见图 1–3）列出已在 DSCC 中注册的所有目录服务器。将为每个服务器显示服务器状态和实例路径，实例路径指出实例所在的位置。
单击服务器名称时将出现另一个窗口，其中显示了只与该服务器相关的一组其他选项卡。
“代理服务器”选项卡
“代理服务器”选项卡列出已在 DSCC 中注册的所有目录代理服务器。将为每个服务器显示服务器状态和服务器实例路径，实例路径指出实例所在的位置。
单击服务器名称时将出现另一个窗口，其中显示了只与该服务器相关的一组其他选项卡。
“服务器组”选项卡
“服务器组”选项卡允许您将服务器指定给组，从而使服务器管理更加轻松。如果您有大量服务器，则可以通过使用过滤器只显示特定组中的服务器。还可以将某个服务器中的服务器配置（例如索引或缓存设置）复制到组中的所有其他服务器。
“设置”选项卡
此选项卡显示 DSCC 端口号，并允许您创建和删除目录服务管理员。
DSCC 联机帮助
联机帮助可提供以下内容：
-
当前所用页面的上下文有关帮助。
-
有关使用 DSCC 执行管理和配置过程的一般帮助。
可以在大多数页面中通过单击屏幕右上角的“帮助”按钮来访问帮助。在向导中，可以通过单击“帮助”选项卡访问帮助。还可以从“日常任务”选项卡访问联机帮助。
目录服务器命令行工具在 DSCC 上执行的大多数任务都可以使用命令行工具来执行。这些工具允许您从命令行直接管理目录服务器，并可使用脚本管理服务器。
主要的目录服务器命令包括 dsadm 和 dsconf。可以使用这些命令执行备份、导出到 LDIF 和管理证书等操作。有关这些命令的信息，请参见 dsadm(1M) 和 dsconf(1M) 手册页。
本部分包含以下与目录服务器命令行工具有关的信息：
目录服务器命令的位置
目录服务器命令行工具位于默认的安装目录中：
install-path/ds6/bin
安装目录取决于操作系统。默认路径和命令位置中列出了所有操作系统的安装路径。
为 dsconf 设置环境变量
dsconf 命令需要使用某些选项，可以使用环境变量来预设这些选项。如果在使用命令时未指定选项，或者未设置环境变量，则使用默认设置。可为以下选项配置环境变量：
- -D user DN
-
用户绑定 DN。环境变量：LDAP_ADMIN_USER。默认：cn=Directory Manager。
- -w password-file
-
用户绑定 DN 的密码文件。环境变量：LDAP_ADMIN_PWF。默认：提示输入密码。
- -h host
-
主机名。环境变量：DIRSERV_HOST。默认：localhost。
- -p LDAP-port
-
LDAP 端口号。环境变量：DIRSERV_PORT. 默认：389。
- -e, --unsecured
-
指定 dsconf 应默认打开一个不受限制的连接。环境变量：DIRSERV_UNSECURED。如果未设置此变量，dsconf 将默认打开一个安全连接。
有关详细信息，请参见 dsconf(1M) 手册页。
dsadm 和 dsconf 的比较
下表显示 dsadm 和 dsconf 命令的比较。
表 1–1 dsadm 和 dsconf 命令的比较|
|
dsadm 命令 |
dsconf 命令 |
|---|---|---|
|
描述 |
必须直接在本地主机上运行的管理命令。例如：
|
可以从远程主机运行的管理命令。例如：
|
|
注释 |
必须停止服务器（dsadm stop 和 dsadm info 命令除外）。 服务器由服务器实例路径 (instance-path) 标识。 您必须具有服务器实例路径的操作系统访问权限。 |
服务器必须正在运行。 服务器由主机名 (-h) 端口 ( -p) 或 LDAPS 安全端口 (-P) 标识。 如果未指定端口号，dsconf 将使用默认端口（对于 LDAP 来说为 389）。 您必须具有配置数据的 LDAP 访问权限，例如，具有 cn=admin,cn=Administrators,cn=config 用户身份。 |
获取有关使用 dsadm 和 dsconf 的帮助信息
有关如何使用 dsadm 和 dsconf 命令的完整信息，请参见 dsadm(1M) 和 dsconf(1M) 手册页。
$ dsadm --help
$ dsconf --help
$ dsadm subcommand --help
$ dsconf subcommand --help
使用 dsconf 修改配置属性
可以使用很多 dsconf 子命令来查看和修改配置属性。
$ dsconf help-properties
$ dsconf help-properties | grep -i referral
SER referral-url rw M LDAP_URL | undefined
Referrals returned to clients requesting a DN not stored in this
Directory Server (Default: undefined)
SUF referral-mode rw disabled|enabled|only-on-write
Specifies how referrals are used for requests involving the suffix
(Default: disabled)
SUF referral-url rw M LDAP_URL | undefined
Server(s) to which updates are referred (Default: undefined)
SUF repl-rewrite-referrals-enabled rw on|off
Specifies whether automatic referrals are overwritten (Default: off)$ dsconf help-properties -v | grep -i referral-mode SUF referral-mode rw disabled|enabled|only-on-write nsslapd-state Specifies how referrals are used for requests involving the suffix (Default: disabled)
有关单个属性的详细信息，请参见该属性的手册页。这些手册页位于《Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference》中。
使用 dsconf 设置多值属性
某些目录服务器属性可以使用多个值。用于指定这些值的语法如下：
$ dsconf set-container-prop -h host -p port container-name \ property:value1 property:value2
例如，要为服务器设置多个加密密码，请使用以下命令：
$ dsconf set-server-prop -h host1 -p 1389 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \ ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
要在已包含值的多值属性中添加值，请使用以下语法：
$ dsconf set-container-prop -h host -p port container-name property+:value
要从已包含值的多值属性中删除值，请使用以下语法：
$ dsconf set-container-prop -h host -p port container-name property-:value
例如，在前面介绍的方案中，要将 SHA 加密密码添加到密码列表中，请运行以下命令：
$ dsconf set-server-prop -h host1 -p 1389 \ ssl-cipher-family+:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
要从列表中删除 MD5 密码，请运行以下命令：
$ dsconf set-server-prop -h host1 -p 1389 ssl-cipher-family-:SSL_RSA_WITH_RC4_128_MD5
手册页
手册页提供了对目录服务器中使用的所有命令和属性的描述。此外，手册页还显示了如何在部署中使用命令的一些有用示例。
传统工具
为了提供向后兼容性，还在常规目录服务器工具中提供了传统工具。这些工具虽然仍旧存在，但已经过时。
第 2 章 目录服务器实例和后缀本章介绍如何创建和管理目录服务器实例和后缀。许多其他的目录管理任务也是在后缀级别进行配置的，但这些内容将在本书的其他章节进行介绍。
本章包含以下主题：
快速创建服务器实例和后缀的过程本章包含有关如何创建服务器实例和后缀的详细信息。如果需要快速创建目录服务器实例和后缀并导入一些示例数据，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide》中的“Server Instance Creation”。
创建和删除目录服务器实例本部分说明如何创建和删除目录服务器实例。
创建目录服务器实例
必须先使用命令行工具或目录服务控制中心 (Directory Service Control Center, DSCC) 浏览器界面创建目录服务器实例，然后才能对数据进行管理。在 DSCC 中，目录服务器实例通常简称为“目录服务器”。
创建目录服务器实例时，目录服务器所需的文件和目录将在您指定的 instance-path 中创建。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
如果使用 DSCC 创建新的服务器实例，则可以选择复制现有服务器中的部分或全部服务器配置设置。
删除目录服务器实例
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
启动、停止和重新启动目录服务器实例要从命令行启动、停止或重新启动服务器，请分别使用 dsadm start、dsadm stop 和 dsadm restart 命令。
注 –
如果停止和重新启动的目录服务器实例在内存中配置了较大缓存以存储条目，则此缓存需要花费一些时间进行重新填充。当缓存再次填满时，实例的响应速度将会变慢。
这些命令必须由创建目录服务器的相同 UID 和 GID 运行，或由超级用户运行。例如，如果目录服务器以 user1 身份运行，则应该以 user1 身份运行 start、stop 和 restart 实用程序。
注 –
在 Solaris 上，基于角色的访问控制允许您以非超级用户身份运行目录服务器。
启动、停止和重新启动目录服务器
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。但是，这不适用于启用和禁用服务管理的步骤。在启动和停止目录服务器时，必须通过命令行启用和禁用服务管理。
$ dsadm start instance-path
$ dsadm start /local/ds
$ dsadm stop instance-path
$ dsadm stop /local/ds
$ dsadm restart instance-path
$ dsadm restart /local/ds创建后缀
创建目录服务器实例之后，必须为服务器的目录信息树 (Directory Information Tree, DIT) 创建一个或多个后缀。DIT 由服务器中的所有条目组成，这些条目使用各自的标识名 (Distinguished Name, DN) 进行标识。DN 的分层特性可创建分支和叶条目，从而以树的形式组织数据。DIT 是以后缀和子后缀的形式进行定义和管理的。DSCC 提供了用于创建和管理所有这些元素的控件。此外，也可以使用命令行工具。
正如以下过程中所介绍的一样，您可以使用 dsconf create-suffix 命令在目录中创建后缀配置。由于在内部以相同方式管理根后缀和子后缀，因此从命令行创建这些后缀的过程几乎相同。此过程介绍了只与必需选项一起使用的 dsconf create-suffix 命令。有关此命令的其他选项的详细信息，请参见 dsconf(1M) 手册页或运行以下命令：
$ dsconf create-suffix --help
任何管理用户都可以创建配置条目。但是，后缀的顶级条目必须由目录管理员创建，或以目录管理者身份（如 cn=admin,cn=Administrators,cn=config）创建。
创建后缀
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
如果使用 DSCC 创建新后缀，您可以选择复制现有后缀中的部分或全部后缀配置设置。
禁用或启用后缀有时可能需要禁用后缀以进行维护，或出于安全原因禁用后缀内容。如果禁用后缀，服务器将无法读取或写入后缀内容以响应任何客户端操作。禁用后缀时，您将不再具有该后缀的访问权限，并且引用模式将自动设置为禁用。
禁用后缀然后再启用后缀
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
设置引用并将后缀设置为只读如果要限制对后缀的访问权限而不完全禁用后缀，则可以修改访问权限以允许只读访问。在这种情况下，必须定义对其他服务器的引用以执行写入操作。此外，还可以同时拒绝读取和写入访问，然后为后缀上的所有操作定义引用。
引用还可用于临时将客户端应用程序指向其他服务器。例如，备份后缀内容时，可能要添加对其他后缀的引用。
如果后缀是复制环境中的使用方，则复制机制将确定引用设置的值。尽管可以手动修改引用设置，但引用在下次复制更新时将被覆盖。有关设置复制引用的信息，请参见执行高级使用方配置。
引用是已标记的 URL，即 LDAP URL，其后可接空格字符和标签。例如：
ldap://phonebook.example.com:389/
或者：
ldap://phonebook.example.com:389/ou=All%20People,dc=example,dc=com
由于空格字符非常重要，因此对于引用的 URL 部分中的任何空格字符，都必须使用 %20 进行转义。
设置引用以使后缀变为只读状态
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
删除后缀删除后缀时，将从 DIT 中删除其整个分支。
注 –
删除后缀时，将从目录中永久地删除该后缀的所有数据条目。此外，还将删除所有后缀配置信息，包括其复制配置。
您无法删除父后缀，但将其子后缀保留在 DIT 中作为新的根后缀。如果要删除包含子后缀的整个分支，则必须同时删除已删除的父后缀的子后缀及其可能的子后缀。
删除后缀
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
压缩后缀Directory Server 6.2 支持脱机后缀压缩。此发行版中不支持联机压缩。如果有可用的存储空间，则压缩后缀将重新组织数据库键，从而可减小数据库大小。
脱机压缩后缀
在执行此任务之前，请停止服务器并备份数据库。
第 3 章 目录服务器配置本章介绍如何配置目录服务器。您可以使用 dsconf 命令（请参见 dsconf(1M) 手册页）。
还可以使用目录服务控制中心 (Directory Service Control Center, DSCC)，此为首选方法。DSCC 将在配置过程中执行附加检查，这可以减少错误。此外，DSCC 还允许您将一个服务器实例的配置复制到另一个服务器实例中。有关使用 DSCC 的详细信息，请参见 DSCC 联机帮助。
显示目录服务器实例的配置要显示目录服务器实例的配置，请运行 dsconf info。
$ dsconf info -h host -p port Instance path : instance path Global State : read-write Host Name : host Port : port Secure port : secure port Total entries : 20844 Suffixes : suffix-DN Dest. Servers : host:port On-Going Tasks : import Finished Tasks : backup
上面的输出假定已创建了后缀以及与目标服务器之间的复制协议。它还显示正在进行的导入操作以及完成的备份操作。
使用 DSCC 修改配置修改配置的推荐方法是使用 DSCC。此浏览器界面提供了基于任务的控件，可帮助您快速有效地设置配置。使用 DSCC 可以修改一个服务器上的配置设置，然后将该配置设置复制到其他服务器中。此外，DSCC 界面还为您管理配置的复杂性和相互依赖性。可以在 DSCC 联机帮助中找到使用 DSCC 修改配置的详细过程。
从命令行修改配置可以通过编写使用命令行工具的脚本来自动完成配置任务。
可以通过命令行使用 dsconf 命令来修改配置。此命令使用 LDAP 修改 cn=config 子树。有关 dsconf 的详细信息，请参见目录服务器命令行工具。
对于无法使用 dsconf 执行的任何任务，都可以使用 ldapmodify 命令。
注 –
如果要使用 dsconf set-server-prop 命令修改服务器配置属性，您需要了解可以修改的属性以及这些属性的默认值。可使用以下命令显示所有属性的帮助信息：
$ dsconf help-properties -v
可以搜索所需项的属性帮助。例如，在 UNIX 平台上，可键入以下内容来搜索内存缓存属性：
$ dsconf help-properties -v | grep cache
有关 cn=config 中的配置条目的详细信息以及所有配置条目和属性的完整描述（包括允许值的范围），请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
修改 文件目录服务器将所有配置信息存储在以下文件中：
instance-path/config/dse.ldif
注意 –
通过直接编辑 dse.ldif 文件的内容来修改配置很容易出错，因此不推荐使用此方法。但是，如果选择手动编辑此文件，请在编辑文件之前停止服务器，并在完成编辑后重新启动该服务器。
dse.ldif 文件使用 LDAP 数据交换格式 (LDAP Data Interchange Format, LDIF)。LDIF 是条目、属性及其值的文本表示形式，它是 RFC 2849 (http://www.ietf.org/rfc/rfc2849) 中描述的一种标准格式。
dse.ldif 文件中的目录服务器配置由以下内容组成：
-
cn=config 条目的属性和值。
-
位于 cn=config 下的子树中的所有条目及其属性和值。
-
根条目 ("") 和 cn=monitor 条目的对象类和访问控制指令。这些条目的其他属性由服务器生成。
只有拥有目录服务器实例的系统用户才具有读取和写入文件的权限。
目录服务器允许通过 LDAP 读取和写入所有配置设置。默认情况下，具有授权的任何人都可以读取目录的 cn=config 分支，但只有目录管理员 (cn=Directory Manager) 和 cn=Administrators,cn=config 下的管理用户才能写入该分支。管理用户可以查看和修改配置条目，就像任何其他目录条目一样。
不要在 cn=config 条目下创建非配置条目，因为这些条目将存储在 dse.ldif 文件中，而不像常规条目那样存储在高伸缩性的数据库中。因此，如果在 cn=config 下面存储了很多条目（尤其是可能经常更新的条目），性能可能会出现下降。但是，将复制管理员（提供方绑定 DN）等特殊用户条目存储在 cn=config 下可能非常有用，因为这样可以集中配置信息。
目录服务器包含默认的管理用户，即目录管理员和 cn=admin,cn=Administrators,cn=config 用户。这两个用户具有相同的访问权限，但 cn=admin,cn=Administrators,cn=config 受 ACI 控制。
本部分说明如何创建具有超级用户权限的管理用户，以及如何配置目录管理员。
创建具有超级用户权限的管理用户
如果要创建与 cn=admin,cn=Administrators,cn=config 具有相同权限的新管理用户，请在 cn=Administrators,cn=config 组中创建新用户。此组中的所有用户都受全局 ACI 控制，此 ACI 允许具有与目录管理员相同的访问权限。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
配置目录管理员
目录管理员是具有特权的服务器管理员，与 UNIX 系统上的超级用户类似。访问控制不适用于目录管理员。
大多数管理任务都不需要使用目录管理员。您可以使用 cn=admin,cn=Administrators,cn=config 用户或者在 cn=Administrators,cn=config 下创建的任何其他用户。需要使用目录管理员的任务只包括更改根 ACI 和复制故障排除任务（如修复复制和搜索逻辑删除）。
可以更改目录管理员的 DN 和密码，以及创建可供自动读取密码的文件。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
$ dsconf get-server-prop -h host -p port root-dn root-dn:cn=Directory Manager
$ dsconf set-server-prop -h host -p port root-pwd-file:new-root-dn-password-file
$ dsconf set-server-prop -h host1 -p 1389 root-dn:"cn=New Directory Manager"
$ dsconf set-server-prop -h host -p port root-pwd:new-root-dn-password
$ echo password > /tmp/pwd.txt
$ dsconf set-server-prop -h host -p port root-pwd-file:/tmp/pwd.txt
$ rm /tmp/pwd.txt保护配置信息
根目录服务器条目（使用零长度 DN "" 执行基本对象搜索时返回的条目）以及 cn=config、cn=monitor 和 cn=schema 下的子树包含由目录服务器自动生成的访问控制指令 (Access Control Instruction, ACI)。这些 ACI 用于确定目录条目的用户权限。如果用于评估目的，则这些 ACI 已经足够。但是对于任何生产部署，您都需要评估访问控制要求并设计您自己的访问控制。
如果出于安全考虑，您要隐藏一个或多个其他子树并保护您的配置信息，则必须在 DIT 上放置其他 ACI 。
-
将 ACI 属性放在位于要隐藏的子树基部的条目中。
-
将 ACI 放在 namingContexts 属性上的根 DSE 条目中。名为 namingContexts 的根 DSE 条目属性包含每个目录服务器数据库的基 DN 列表。
-
将 ACI 放在 cn=config 和 cn=monitor 子树上。子树 DN 也存储在 cn=config 和 cn=monitor 下的映射树条目中。
有关创建 ACI 的详细信息，请参见第 6 章，目录服务器访问控制。
配置 DSCC本部分提供了以下有关配置 DSCC 的信息：
更改 Common Agent Container 端口号
默认的 Common Agent Container 端口号为 11162。Common Agent Container 将 DSCC 代理端口定义为 jmxmp-connector-port。如果出于管理考虑，需要为 DSCC 代理和 Common Agent Container 使用其他端口号，请使用以下过程：
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
重置目录服务管理员密码
要重置目录服务管理员密码，请使用 DSCC，如以下过程所述。
延长 DSCC 会话自动超时延迟
经过一段时间之后，您的 DSCC 会话将会超时，并且您将从 DSCC 中注销。请使用以下过程延长超时延迟。请注意，此过程将延长 DSCC 及 Sun Java Web Console 中所有其他应用程序的超时时间。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
配置 DSCC 的故障转移
DSCC 会显示已在 DSCC 中注册的服务器。
如果安装有 DSCC 的计算机出现故障，您可以在其他计算机上安装 DSCC，然后重新注册您的服务器。但这么做可能会花费很多时间。如果要通过 DSCC 立即访问服务器，则可以配置 DSCC 故障转移。
要配置 DSCC 故障转移，请考虑以下注意事项：
-
已注册的服务器的所有信息都存储在 DSCC 注册表中。此注册表为目录服务器实例。可以使用管理命令 dsadm 和 dsconf 管理此注册表。
-
DSCC 注册表具有以下默认特性：
- 服务器实例
-
Solaris — /var/opt/SUNWdsee/dscc6/dcc/ads
Linux 和 HP-UX — /var/opt/sun/dscc6/dcc/ads
Windows — C:\Program Files\Sun\DSEE\var\dscc6\dcc\ads
- 后缀
-
cn=dscc
- 端口
-
LDAP 3998、LDAPS 3999
-
在两台或多台计算机上安装 DSCC 之后，可以设置 DSCC 注册表后缀之间的复制。可以使用第 10 章，目录服务器复制中所述的复制命令行过程。或者，要获取设置简单复制配置的示例，请参见 dsconf(1M) 手册页。
设置复制之后，可以从不同计算机访问 DSCC 中注册的相同服务器。例如，如果设置了 host1 和 host2 上 DSCC 注册表后缀之间的复制，则可以在 https://host1:6789 或 https://host2:6789 上使用 DSCC 管理相同的服务器。如果主机发生故障，则可以从其他主机访问 DSCC。
DSCC 故障排除
更改目录服务器端口号可以使用 DSCC 或 dsconf set-server-prop 命令来修改用户目录服务器的 LDAP 端口号或 LDAP 安全端口号。
如果更改端口号，请注意以下事项：
-
如果设置了非特权端口号，并将目录服务器安装到其他用户可以访问的计算机上，则该端口号可能存在被其他应用程序占用的危险。换句话说，其他应用程序可能会绑定到相同的地址/端口对。此恶意应用程序可能会接着处理针对目录服务器的请求。也就是说，此恶意应用程序可用于捕获验证过程中使用的密码，从而更改客户端请求或服务器响应，或者产生拒绝服务攻击。为了避免此类安全风险，请使用 listen-address 或 secure-listen-address 属性来指定目录服务器侦听的接口（地址）。
如果使用命令行更改端口号，请注意以下事项：
-
如果在其他服务器上定义的复制协议中引用了目录服务器，则必须更新此复制协议以使用新的端口号。
-
如果以前使用过 DSCC 管理服务器，则更改端口号后将暂时无法查看此服务器。要再次查看此服务器，必须先取消注册此服务器，然后在 DSCC 中使用新端口号对其进行重新注册。
修改端口号、启用端口和禁用端口
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
注 –
进行修改后，必须重新启动服务器以使更改生效。
$ dsconf get-server-prop -h host -p port port-type
$ dsconf get-server-prop -h host1 -p 2501 ldap-secure-port Enter "cn=Directory Manager" password: ldap-secure-port : 2511
$ dsconf set-server-prop -h host -p port port-type:new-port
$ dsconf set-server-prop -h host1 -p 1389 ldap-port:1390
$ dsconf set-server-prop -h host1 -p 1389 dsml-secure-port:2250
$ dsconf set-server-prop -h host -p port port-type:disabled
$ dsconf set-server-prop -h host1 -p 1389 dsml-secure-port:disabled配置 DSML
除了处理通过轻量目录访问协议 (Lightweight Directory Access Protocol, LDAP) 发送的请求之外，目录服务器还响应以目录服务标记语言版本 2 (Directory Service Markup Language version 2, DSMLv2) 发送的请求。DSML 是供客户端对目录操作进行编码的另一种方法。服务器将使用所有相同的访问控制和安全功能，以处理任何其他请求的方式来处理 DSML 请求。DSML 处理允许许多其他类型的客户端访问您的目录内容。
目录服务器支持通过超文本传输协议 (Hypertext Transfer Protocol, HTTP/1.1) 使用 DSMLv2，并将简单对象访问协议 (Simple Object Access Protocol, SOAP) 版本 1.1 用作编程协议来传输 DSML 内容。有关这些协议的详细信息以及 DSML 请求示例，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中的第 10 章 “Directory Server DSMLv2”。
本部分包含以下主题：
启用 DSML-over-HTTP 服务
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
接下来的操作
根据定义的参数和属性值，DSML 客户端可以使用以下 URL 将请求发送到此服务器：
http://host:DSML-port/ relative-URL
https://host:secure-DSML-port /relative-URL
注 –
可以使用 dsml-relative-root-url 属性读取和设置 relative-URL。
禁用 DSML-over-HTTP 服务
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置 DSML 安全性
可以配置接受 DSML 请求时所需的安全级别。要执行此操作，必须配置 DSML 客户端验证。
$ dsconf set-server-prop -h host -p port dsml-client-auth-mode:dsml-mode
DSML 标识映射
执行无证书的基本验证时，目录服务器将使用标识映射机制来确定接受 DSML 请求时要使用的绑定 DN。此机制将从 HTTP 请求的“授权”头中提取信息，以确定要用于绑定的标识。
DSML/HTTP 的默认标识映射由服务器配置中的以下条目指定。
dn: cn=default,cn=HTTP-BASIC,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
cn: default
dsSearchBaseDN: ou=people
dsSearchFilter: (uid=${Authorization})
此配置表明，服务器应该使用 HTTP 用户 ID 作为目录服务器后缀中所存储的 DN 的 uid 值。例如，如果 HTTP 用户为 bjensen，服务器将尝试使用 DN uid=bjensen,ou=people 执行绑定。
因此，要使映射正常工作，您必须完成 dsSearchBaseDN 的值。例如，可以将 dsSearchBaseDN 的值更改为 ou=people,dc=example,dc=com。这样，如果 HTTP 用户为 bjensen，服务器将尝试使用 DN uid=bjensen,ou=people,dc=example,dc=com 执行绑定。
dn: cn=default,cn=HTTP-BASIC,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
cn: default
dsSearchBaseDN: ou=people,dc=example,dc=com
dsSearchFilter: (uid=${Authorization})
在映射条目属性 dsSearchFilter 中，可以使用 ${header } 格式的占位符，其中 header 是 HTTP 头的名称。
以下是 DSML 映射中最常用的头。
- ${Authorization}
-
此字符串将由 HTTP“授权”头中包含的用户名替换。“授权”头同时包含用户名及其密码，但在此占位符中只替换用户名。
- ${From}
-
此字符串将由 HTTP“发件人”头中可能包含的电子邮件地址替换。
- ${host}
-
此字符串将由 DSML 请求 URL 中的主机名和端口号（即服务器的主机名和端口号）替换。
要使 DSML 请求执行其他类型的标识映射，请为 HTTP 头定义新的标识映射。
为 HTTP 头定义新的标识映射
将服务器设置为只读目录中的每个后缀均可单独设为只读模式，并可返回特定的引用（如果已定义）。目录服务器也为应用于所有后缀并可返回全局引用（如果已定义）的服务器提供了只读模式。
服务器只读模式旨在允许管理员在执行特定任务（如为后缀重新编制索引）时阻止对目录内容执行修改操作。因此，服务器只读模式不适用于以下配置分支：
-
cn=config
-
cn=monitor
-
cn=schema
启用只读模式后，还会中断后缀上的复制操作。主副本不再有任何要复制的更改，但它还会继续复制启用只读模式前所做的全部更改。在禁用只读模式之前，使用方副本不会收到更新。多主复制环境中的主服务器没有任何要复制的更改，并且无法从其他主服务器接收更新。
启用或禁用服务器只读模式
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置内存本部分提供有关管理不同类型内存的信息。有关不同类型缓存的描述以及有关缓存调整的信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中的第 5 章 “Directory Server Data Caching”。
填充缓存
填充缓存是指将数据填入缓存中，以使后续的目录服务器行为能反映出正常的操作性能，而不是提升的性能。如果希望在执行基准测试时获得可再现的结果，或者要测量和分析潜在的优化，则填充缓存非常有用。
请尽量避免主动填充缓存。在测量性能之前，让客户端与目录服务器之间的一般或典型交互操作来填充缓存。
可以在 http://www.slamd.com 找到用于填充数据库缓存的工具。
修改数据库缓存
注意 –
修改缓存可能会严重影响服务器性能。修改缓存时请谨慎操作。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
监视数据库缓存
安装时的默认缓存级别适合于测试环境，而不适用于生产环境。进行调整时，您可能需要监视服务器的数据库缓存。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
监视条目缓存
进行调整时，您可能需要检查一个或多个后缀的条目缓存。可使用以下过程查看条目缓存级别。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
修改条目缓存
注意 –
修改缓存可能会严重影响服务器性能。修改缓存时请谨慎操作。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置堆内存阈值
如果要限制 nsslapd 进程所使用的堆内存量，可以设置动态内存占用的阈值。当目录服务器在资源共享或资源稀少的计算机上运行时，可能需要设置此阈值。
注 –
只能在 Solaris 和 Linux 平台上设置此阈值。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
注 –
默认情况下，heap-high-threshold-size 和 heap-low-threshold-size 属性为 undefined。
为每个客户端帐户设置资源限制
您可以控制每个客户端帐户在服务器上的搜索操作资源限制。可以在帐户的操作属性中设置这些限制，然后目录服务器会基于客户端用于绑定到目录的帐户来实施这些限制。
可以设置以下限制：
-
浏览限制指定搜索操作可检查的最大条目数。
-
大小限制指定响应搜索操作时返回的最大条目数。
-
时间限制指定处理搜索操作所花费的最长时间。
-
空闲超时指定在断开连接之前客户端连接可以保持空闲状态的最长时间。
注 –
默认情况下，目录管理员使用资源时可以不受限制。
在特定用户帐户上设置的资源限制优先于在服务器范围的配置中设置的资源限制。本部分提供了有关为每个帐户设置资源限制的信息。
本部分中提供的示例直接在条目的属性中设置资源限制。还可以使用服务类 (Class of Service, CoS) 机制设置帐户的资源限制。为客户端应用程序检索条目时，CoS 机制将生成计算后的属性。有关定义 CoS 的详细信息，请参见服务类。
配置堆内存阈值
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
第 4 章 目录服务器条目本章讨论如何管理目录中的数据条目。此外，还介绍如何设置引用以及如何加密属性值。
规划目录部署时，您需要根据特性对目录将包含的数据类型进行分类。在创建条目和修改默认模式之前，请先阅读《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中的相关章节。
除非定义了相应的访问控制指令 (Access Control Instruction, ACI)，否则将无法修改目录。有关详细信息，请参见第 6 章，目录服务器访问控制。
本章包含以下主题：
管理条目管理条目的最佳方式取决于环境：
-
如果主要将 DSCC 用于管理，并且只需搜索或修改少量条目，请使用 DSCC。有关 DSCC 的详细信息，请参见目录服务控制中心界面。
-
如果不在目录服务器上执行任何管理任务，并且只需搜索或修改少量条目，请使用目录编辑器。有关目录编辑器的信息，请参见《Sun Java System Directory Editor 1 2005Q1 Installation and Configuration Guide》。
-
如果要搜索或修改大量条目，请使用命令行实用程序 ldapmodify 和 ldapdelete。
使用 DSCC 管理条目
DSCC 允许您查看条目的所有可读属性以及编辑其可写属性。此外，您还可以添加和删除属性、设置多值属性，以及管理条目的对象类。有关如何使用 DSCC 管理条目的详细信息，请参见 DSCC 联机帮助。有关 DSCC 的一般性信息，请参见目录服务控制中心界面。
使用目录编辑器管理条目
目录编辑器是一种易于使用的目录编辑工具，允许管理员和最终用户搜索、创建和编辑数据。此数据采用用户、组和容器的形式。
使用 ldapmodify 和 ldapdelete 管理条目
ldapmodify 和 ldapdelete 命令行实用程序提供了用于添加、编辑和删除目录内容的完整功能。可以使用这些实用程序管理服务器的配置条目和用户条目中的数据。还可以使用这些实用程序编写脚本，以便对一个或多个目录执行批量管理。
本书中的过程几乎都使用了 ldapmodify 和 ldapdelete 命令。以下部分介绍执行这些过程所需的基本操作。有关 ldapmodify 和 ldapdelete 命令的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
命令行实用程序的输入始终采用 LDIF 格式，可以直接从命令行或通过输入文件提供此输入。以下部分提供了与 LDIF 输入有关的信息，后续部分将介绍适用于每种修改类型的 LDIF 输入。
以下部分介绍这些基本操作：
使用 ldapmodify 添加条目
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
可以使用 ldapmodify 的 -a 选项向目录中添加一个或多个条目。以下示例将创建包含用户的结构条目，然后再创建用户条目：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries dn: uid=bjensen,ou=People,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson uid: bjensen givenName: Barbara sn: Jensen cn: Babs Jensen telephoneNumber: (408) 555-3922 facsimileTelephoneNumber: (408) 555-4000 mail: bjensen@example.com userPassword: secret
-D 和 -w 选项分别提供用户的绑定 DN 和密码（该用户具有创建这些条目的权限）。-a 选项表示将添加 LDIF 中的所有条目。然后将按 DN 和属性值列出每个条目，各条目之间以空行分隔。ldapmodify 实用程序将在输入每个条目后创建该条目，并会报告任何错误。
-
条目 DN。
-
对象类列表。
-
一个或多个命名属性。此属性是 DN 中使用的属性，它不一定属于必需属性。
-
所有对象类的必需属性列表。
-
要包含的所有允许的属性。
按照约定，条目的 LDIF 将列出以下属性：
键入 userPassword 属性值时，请提供明文形式的密码。服务器将对此值进行加密，并且只存储加密的值。请务必限制读取权限以保护 LDIF 文件中出现的明文密码。
还可以使用另一种形式的 LDIF，它不要求在命令行中使用 -a 选项。此形式的优点是可以合并条目添加语句和条目修改语句，如以下示例所示。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: ou=People,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries dn: uid=bjensen,ou=People,dc=example,dc=com changetype: add objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson uid: bjensen givenName: Barbara sn: Jensen cn: Barbara Jensen telephoneNumber: (408) 555-3922 facsimileTelephoneNumber: (408) 555-4000 mail: bjensen@example.com userPassword: secret
changetype: add 关键字表示应该使用所有后续属性创建具有给定 DN 的条目。所有其他选项和 LDIF 约定都与本部分前面的叙述相同。
在这两个示例中，都可以使用 -f filename 选项从文件（而非终端输入）中读取 LDIF。LDIF 文件所包含的格式必须与终端输入使用的格式相同，这取决于您是否使用 -a 选项。
使用 ldapmodify 修改条目
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
可以使用 changetype: modify 关键字在现有条目中添加、替换或删除属性及属性值。指定 changetype: modify 时，还必须提供一个或多个更改操作，以表明将如何修改条目。以下示例中显示了三种可能的 LDIF 更改操作：
dn: entryDN changetype: modify add: attribute attribute: value... - replace: attribute attribute: newValue... - delete: attribute [attribute: value] ...
可以使用独占一行的连字符 (-) 分隔相同条目上的操作，并可使用空行来分隔不同条目上的操作组。还可以为每个操作提供多个 attribute: value 对。
添加属性值
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
以下示例显示如何使用相同的 add LDIF 语法向现有多值属性和尚未存在的属性中添加值：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: cn cn: Babs Jensen - add: mobile mobile: (408) 555-7844
如果存在以下任一情况，则此操作可能会失败，并且服务器将返回错误：
-
属性中已存在给定的值。
-
值与为属性定义的语法不符。
-
条目的对象类不需要或不允许使用该属性类型。
-
属性类型不是多值类型，并且属性中已存在某个值。
使用二进制属性子类型
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
attribute;binary 子类型表示属性值必须作为二进制数据通过 LDAP 进行传输，而不考虑属性值的实际语法。此子类型适用于没有 LDAP 字符串表示的复杂语法，如 userCertificate。不应将二进制子类型用于其他目的。
在 ldapmodify 命令中使用时，可以将相应的子类型添加到任何 LDIF 语句的属性名称中。
要输入二进制值，可以在 LDIF 文本中直接键入或从其他文件读取。以下示例显示了用于从文件读取二进制值的 LDIF 语法：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: version: 1 dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: userCertificate;binary userCertificate;binary:< file:///local/cert-file
要使用 :< 语法指定文件名，必须将 version: 1 行作为 LDIF 语句的开头。当 ldapmodify 处理此语句时，它会将属性设置为从给定文件的全部内容中读取的值。
添加具有语言子类型的属性
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
属性的语言和发音子类型可指定本地化的值。为属性指定语言子类型时，该子类型将添加到属性名称中，如下所示：
attribute;lang-CC
其中 attribute 是现有属性类型，而 cc 是用于指定语言的双字母国家/地区代码。您还可以将发音子类型添加到语言子类型中，以便为本地化的值指定一个语音值。在本案例中，属性名称如下所示：
attribute;lang-CC;phonetic
要对具有子类型的属性执行操作，必须明确匹配其子类型。例如，如果要修改具有 lang-fr 语言子类型的属性值，则必须在修改操作中包含 lang-fr，如下所示：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: homePostalAddress;lang-fr homePostalAddress;lang-fr: 34, rue de la Paix
注 –
如果属性值包含非 ASCII 字符，则这些字符必须为 UTF-8 编码的字符。
修改属性值
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
以下示例说明如何通过使用 LDIF 中的 replace 语法更改属性值：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify replace: sn sn: Morris - replace: cn cn: Barbara Morris cn: Babs Morris
将删除指定属性的所有当前值，并添加所有给定值。
更改属性值之后，您可以使用 ldapsearch 命令验证此更改。
属性值中的结尾空格
修改属性值时，请勿不小心在值的末尾包含空格。结尾空格可能会导致值以 base-64 编码格式显示（如 34xy57eg）。
如果属性值的末尾是空格，则此空格将作为属性值的一部分进行编码。在使用 DSCC 或 ldapsearch 命令验证更改时，所显示的值可能是纯文本，也可能是 base-64 编码的文本。这取决于您所使用的目录服务器客户端。
删除属性值
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
以下示例说明如何完整地删除属性，以及如何仅删除多值属性的一个值：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify delete: facsimileTelephoneNumber - delete: cn cn: Babs Morris
使用 delete 语法时如果不指定 attribute: value 对，将删除该属性的所有值。如果指定 attribute: value 对，则只会删除该值。
修改多值属性的一个值
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
要使用 ldapmodify 命令修改多值属性的一个值，必须执行以下示例中显示的两个操作：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify delete: mobile mobile: (408) 555-7845 - add: mobile mobile: (408) 555-5487
使用 ldapdelete 删除条目
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
可以使用 ldapdelete 命令行实用程序从目录中删除条目。此实用程序将绑定到目录服务器，并根据条目 DN 删除一个或多个条目。必须提供具有删除指定条目的权限的绑定 DN。
您无法删除具有子条目的条目。LDAP 协议不允许出现子条目不再具有父条目的情形。例如，您无法删除组织单位条目，除非先删除了属于该组织单位的所有条目。
以下示例仅显示组织单位的一个条目。可以先后删除此条目及其父条目。
$ ldapdelete -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: uid=bjensen,ou=People,dc=example,dc=com ou=People,dc=example,dc=com
使用 ldapmodify 删除条目
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使用 ldapmodify 实用程序时，还可以使用 changetype: delete 关键字删除条目。使用 ldapdelete 时的所有限制此时同样适用，如上一部分所述。使用 LDIF 语法删除条目的优点在于，您可以在单个 LDIF 文件中执行混合操作。
以下示例执行与上一示例相同的删除操作：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: uid=bjensen,ou=People,dc=example,dc=com changetype: delete dn: ou=People,dc=example,dc=com changetype: delete
使用 ldapsearch 搜索条目
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
可以使用 ldapsearch 命令行实用程序查找和检索目录条目。请注意，ldapsearch 实用程序不是 Solaris 平台提供的实用程序，而是 Directory Server Resource Kit 的一部分。
有关使用 ldapsearch、ldapsearch 常用选项、接受的格式以及示例的详细信息，请参阅《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
使用 ldapmodify 移动或重命名条目
以下过程将使用修改 DN 操作。在开始此操作之前，请确保您已经熟悉使用修改 DN 操作的准则和限制部分的内容。
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
注 –
在修改作为组 uniquemember 的条目 DN 时，必须启用引用完整性插件。引用完整性可确保在移动条目时调整组成员。有关如何启用和配置引用完整性插件的信息，请参见配置引用完整性插件。
$ dsconf set-server-prop -h host -p port moddn-enabled:on
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=Contractors,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 0 newsuperior: ou=People,dc=example,dc=com
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bbjensen,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 1
$ dsconf set-server-prop -h host -p port db-lock-count:value
使用修改 DN 操作的准则和限制
使用修改 DN 操作时（如上一部分所述），请遵循以下部分介绍的准则。
使用修改 DN 操作的一般准则
-
不要使用修改 DN 操作将条目从一个后缀移动到另一个后缀中，也不要使用该操作重命名或移动根后缀。
-
确保正在运行 Directory Server 5.2 2005Q1 或更高版本。无法在 Directory Server 5.2 2005Q1 之前的目录服务器版本上使用修改 DN 操作。
-
不要在应用程序中使用 entryid 操作属性，因为该属性仅供内部使用。移动条目后，条目的 entryid 属性可能发生更改。
-
为服务器上的所有后缀全局启用修改 DN 操作，或者为要运行修改 DN 操作的每个后缀单独启用该操作。默认情况下，修改 DN 操作处于禁用状态。
-
在要运行修改 DN 操作的每个后缀上扩展 ACI 权限。导入访问权限允许将条目导入指定 DN。导出访问权限允许从指定 DN 导出条目。
-
在执行修改 DN 操作之前，请确保该操作不会中断客户端验证。如果移动引用客户端证书的条目，则客户端验证将会中断。请在移动条目后对证书进行验证。
-
在执行修改 DN 操作之前，请确保该操作不会中断应用程序。重命名或移动条目可能会影响多个后缀，或更改条目的以下特性：
-
条目的已过滤角色的范围。
-
条目的嵌套角色（此处的嵌套角色包含过滤角色）。
-
条目的动态组成员身份。
-
协同使用修改 DN 操作和复制时的准则
注意 –
使用修改 DN 操作时如果不符合以下要求，可能会中断复制并破坏目录服务。
启用 MODDN 时无法启动复制会话设置引用
可以使用引用通知客户端应用程序应该联系哪个服务器（如果无法在本地获取此信息）。引用是指向远程后缀或条目的指针，目录服务器将其代替结果返回给客户端。然后，客户端必须在引用中所指定的远程服务器上再次执行操作。
在以下三种情况下将发生重定向：
-
客户端应用程序请求本地服务器上不存在的条目，并且服务器已被配置为返回默认引用。
-
出于维护或安全原因已禁用整个后缀。
服务器将返回该后缀所定义的引用。设置引用并将后缀设置为只读中介绍了后缀级别的引用。客户端请求写入操作时，后缀的只读副本也会将引用返回给主服务器。
-
客户端专门访问智能引用。
智能引用是您创建的一个条目。服务器将返回智能引用所定义的引用。
在任何情况下，引用都是一个 LDAP URL，其中包含主机名、端口号以及其他服务器上的 DN（可选）。例如 ldap://east.example.com:389。
以下部分介绍设置目录默认引用以及创建和定义智能引用的过程。
设置默认引用
客户端应用程序在某个 DN 上提交操作时，如果由目录服务器维护的任何后缀都不包含该 DN，则会将默认引用返回给该客户端应用程序。服务器将返回定义的所有引用，但不会定义返回引用的顺序。
设置默认引用
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
设置智能引用
智能引用允许您将目录条目或目录树映射到特定的 LDAP URL。使用智能引用时，可以将客户端应用程序引用到特定服务器或特定服务器上的特定条目。
智能引用通常指向另一个服务器上具有相同 DN 的实际条目。但是，您可以将智能引用定义为指向相同服务器或不同服务器上的任何条目。例如，您可以将具有以下 DN 的条目定义为智能引用：
uid=bjensen,ou=People,dc=example,dc=com
该智能引用指向服务器 east.example.com 上的另一个条目：
cn=Babs Jensen,ou=Sales,o=east,dc=example,dc=com
目录使用智能引用的方式应符合 RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt) 的 4.1.10 部分所指定的标准。
创建和修改智能引用
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
检查有效的属性语法只要执行以下操作，目录服务器都允许您检查属性的完整性：
-
使用 dsadm import 或 dsconf import 导入数据。
-
使用 LDAP 或 DSML 来添加条目、修改条目或修改条目 DN。
检查可确保属性值符合 IETF 建议。所有不符合的属性都将被拒绝并记录到错误日志中。日志消息包含连接和操作 ID（如果适用）。
默认情况下，服务器将自动检查上述操作的语法。如果要关闭语法检查，请使用以下过程。
注 –
语法检查与模式检查有所不同。有关模式检查的信息，请参见管理模式检查。
关闭自动语法检查
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
跟踪对目录条目的修改默认情况下，服务器会为新创建或已修改的条目维护一些特殊属性，如 LDAP v3 规范中所指定的那样。这些特殊属性存储在后缀中的条目上，其中包括：
-
creatorsName — 最初创建条目的用户的 DN。
-
createTimestamp — 创建条目时的时间戳（GMT 格式）。
-
modifiersName — 最后修改条目的用户的 DN。
-
modifyTimestamp — 修改条目时的时间戳（GMT 格式）。
关闭条目修改跟踪
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
注意 –
关闭条目修改跟踪会导致不兼容的数据。由于许多应用程序都依赖于这些属性，并且禁用此功能只会使性能略为提高，因此建议您不要关闭条目修改跟踪。
加密属性值
属性加密可保护存储在目录中的敏感数据。属性加密允许您指定以加密格式存储条目的某些属性。这可防止读取存储在数据库文件、备份文件和导出的 LDIF 文件中的数据。
使用此功能，将属性值存储到目录服务器数据库之前会对其进行加密，并在返回给客户端之前解密回原始值。您必须使用访问控制来阻止没有权限的客户端访问此类属性，并在客户端和目录服务器之间传输属性值时使用 SSL 对属性值进行加密。有关一般情况下的数据安全性和特殊情况下的属性加密的结构性概述，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
只有在服务器上配置和启用 SSL 之后，属性加密才处于活动状态。但在默认情况下，任何属性都未加密。属性加密是在后缀级别上配置的，这意味着会在后缀包含该属性的每个条目中加密该属性。如果您要在整个目录中加密属性，则必须在每个后缀中为该属性启用加密。
注意 –
属性加密将影响与后缀关联的所有数据和索引文件。如果修改现有后缀的加密配置，则必须先导出该后缀的内容，再更改配置，然后重新导入内容。DSCC 可以帮助您执行这些步骤。有关使用 DSCC 的详细信息，请参见目录服务控制中心界面。
为了更加安全，在为任何属性启用加密时，都应手动删除可能仍包含未加密值的数据库缓存文件和数据库日志文件。配置属性加密中介绍了删除这些文件的过程。
在新后缀中装入或创建数据之前，应该启用所有加密属性。
如果选择加密被某些条目用作命名属性的属性，则 DN 中显示的值将不会被加密。存储在条目中的值将被加密。
即使可以在配置加密时选择 userPassword 属性，也不会实际提高安全性，除非需要以明文形式存储密码。DIGEST-MD5 SASL 验证就是这种情况。如果密码已在密码策略中定义了加密机制，则进一步加密只能使安全性略为提高，且反而会影响每个绑定操作的性能。
在存储时，加密的属性前会加上一个表示所用加密算法的密码标记。使用 DES 加密算法的加密属性将显示为如下形式：
{CKM_DES_CBC}3hakc&jla+=snda%当您考虑到数据加密而联机导入数据时，就已经提供了用于通过服务器验证的密钥数据库密码，系统不会再出现此提示。如果要脱机导入数据，目录服务器会先提示您输入密码，然后才允许您加密要导入的数据。解密数据（此操作需要更高的安全性）时，无论联机还是脱机执行导出操作，目录服务器都会自动提示您输入密钥数据库密码。这可进一步提高安全性。
注 –
只要证书或私钥不发生更改，服务器将继续生成相同的密钥。因此，如果两个服务器实例使用相同的证书，则可以将数据从一个服务器实例传输到另一个服务器实例（先导出然后再导入）。
属性加密和性能
虽然属性加密提供了增强的数据安全性，但也会影响系统性能。请仔细考虑哪些属性需要加密，并且只加密您认为特别敏感的那些属性。
由于可以通过索引文件直接访问敏感数据，因此必须加密与加密属性相对应的索引键，以确保属性受到完整保护。如果索引已对目录服务器性能造成影响（尚未包括加密索引键所造成的影响），请在第一次将数据导入或添加到数据库之前配置属性加密。此过程可确保对加密属性的索引就像从头开始编制一样。
属性加密使用注意事项
执行属性加密功能时请考虑以下事项：
-
一般而言，在修改属性加密配置时，最佳做法是先导出数据，再更改配置，然后导入新配置的数据。
这可确保整体考虑所有配置更改，而不会丢失任何功能。否则，某些功能可能会丢失，从而破坏数据的安全性。
-
在现有数据库上修改属性加密配置可能会对系统性能造成严重影响。
例如，假定您有一个包含现有数据的数据库实例。该数据库包含以前存储的具有 mySensitiveAttribute 属性的条目。此属性的值以明文形式存储在数据库和索引文件中。如果您以后决定加密 mySensitiveAttribute 属性，则必须导出该数据库实例中的所有数据，然后将其重新导入数据库，以确保服务器使用属性加密配置更新数据库和索引文件。如果一开始就对属性进行加密，则可避免由此造成的性能影响。
-
以解密格式导出数据时，如果使用错误的密码，则导出将被拒绝。
作为一种安全措施，服务器会在用户以解密格式导出数据时提示用户输入密码。如果用户提供了错误的密码，服务器将拒绝解密导出操作。可以直接输入密码，也可以提供密码所在文件的路径。请注意，此文件与 SSL 密码文件具有相同的语法。请参见配置证书数据库密码。
-
可以对加密算法进行更改，但如果更改过程有误，则结果可能会丢失索引功能。
要更改用于加密数据的算法，请导出数据，再修改属性加密配置，然后导入数据。如果不按此过程操作，则根据初始加密算法创建的索引将不再有效。
由于加密的属性前添加了表示所用加密算法的密码标记，内部服务器操作将负责导入数据。因此，目录服务器允许您在更改算法前以加密格式导出数据。
-
更改服务器的 SSL 证书将导致您无法解密已加密的数据。
属性加密功能会使用服务器的 SSL 证书生成自己的密钥，以用于执行加密和解密操作。因此，解密已加密的数据时需要使用 SSL 证书。如果更改证书之前未解密数据，将无法解密数据。要避免出现这种情况，请以解密格式导出数据，再更改证书，然后重新导入数据。
-
要以加密格式传输数据，也就是说，要将数据从一个服务器实例导出，然后再导入另一个服务器实例，则这两个服务器实例必须使用相同的证书。
配置属性加密
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
$ dsconf create-encrypted-attr -h host -p port suffix-DN attr-name cipher-name
$ dsconf create-encrypted-attr -h host1 -p 1389 dc=example,dc=com uid rc4
$ dsconf delete-encrypted-attr -h host -p port suffix-DN attr-name第 5 章 目录服务器安全性
目录服务器支持多种可通过网络提供安全可靠通信的机制。LDAPS 是在安全套接字层 (Secure Sockets Layer, SSL) 之上运行的标准 LDAP 协议。LDAPS 可加密数据，并可选择使用证书进行验证。本章中提及的术语 SSL 表示受支持的协议 SSL2、SSL3 和 TLS 1.0。
目录服务器还支持启动传输层安全 (Start Transport Layer Security, Start TLS) 扩展操作，以便在最初未加密的 LDAP 连接上启用 TLS。
此外，目录服务器还支持通过简单验证和安全层 (Simple Authentication and Security Layer, SASL) 执行通用安全服务 API (Generic Security Service API, GSSAPI)。GSSAPI 允许您在 Solaris 操作系统 (Solaris OS) 上使用 Kerberos V5 安全协议。标识映射机制接着会将 Kerberos 主体与目录中的标识进行关联。
有关其他安全性信息，请参见 NSS Web 站点，网址为 http://www.mozilla.org/projects/security/pki/nss/ 。
本章提供了通过 SSL 配置安全性的过程。有关 ACI 的信息，请参见第 6 章，目录服务器访问控制。有关用户访问权限和密码的信息，请参见第 7 章，目录服务器密码策略。
本章包含以下主题：
在目录服务器中使用 SSL安全套接字层 (Secure Sockets Layer, SSL) 在目录服务器和客户端之间提供加密通信和可选验证。可以通过 LDAP 使用 SSL，也可以将 SSL 与 DSML-over-HTTP 结合使用。默认情况下通过 LDAP 启用 SSL，但如果使用 DSML-over-HTTP，则可以轻松地启用 SSL。此外，还可以将复制配置为使用 SSL 在服务器之间进行安全通信。
如果在简单验证（绑定 DN 和密码）中使用 SSL，将对服务器所接收和发送的所有数据进行加密。加密可保证保密性和数据完整性。客户端可以选择使用证书，通过简单验证和安全层 (Simple Authentication and Security Layer,SASL) 进行目录服务器验证或第三方安全机制验证。基于证书的验证使用公钥密码学，以防止伪造和模拟客户端或服务器。
目录服务器可以在单独的端口上同时进行 SSL 通信和非 SSL 通信。出于安全考虑，您还可以将所有通信限制为使用 LDAP 安全端口。客户端验证也是可以配置的。可以将客户端验证设置为必需或允许。此设置用于确定您所执行的安全级别。
SSL 可支持 Start TLS 扩展操作，从而为常规 LDAP 连接提供安全性。客户端可以绑定到标准 LDAP 端口，然后使用传输层安全协议保护连接。Start TLS 操作允许客户端具有更大的灵活性，并且有助于简化端口分配。
SSL 提供的加密机制也可用于属性加密。启用 SSL 允许您在后缀上配置属性加密，以便在目录中存储数据时保护数据。有关详细信息，请参见加密属性值。
为了获取额外的安全性，您可以通过访问控制指令 (Access Control Instruction, ACI) 设置对目录内容的访问控制。ACI 需要特定的验证方法，并可确保只能通过安全通道传输数据。通过设置 ACI，可以弥补使用 SSL 和证书的不足之处。有关详细信息，请参见第 6 章，目录服务器访问控制。
默认情况下通过 LDAP 启用 SSL，如果使用 DSML-over-HTTP，则可以轻松地启用 SSL。此外，您可能需要对 SSL 配置的某些方面进行修改，如以下部分所述。
管理证书本部分介绍如何在目录服务器中管理 SSL 证书。
要在目录服务器上运行 SSL，您必须使用自签名证书或公钥基础结构 (Public Key Infrastructure, PKI) 解决方案。
PKI 解决方案需要使用外部证书颁发机构 (Certificate Authority, CA)。要使用 PKI 解决方案，您需要包含公钥和私钥的 CA 签名服务器证书。此证书特定于一个目录服务器。此外还需要一个包含公钥的可信 CA 证书。可信 CA 证书可确保来自 CA 的所有服务器证书都是可信的。此证书有时称为 CA 根密钥或根证书。
注 –
如果将证书用于测试目的，您可能要使用自签名的证书。但是在生产中，使用自签名证书不太安全。在生产中，应使用可信的证书颁发机构 (Certificate Authority, CA) 证书。
本部分中的过程使用 dsadm 和 dsconf 命令。有关这些命令的信息，请参见 dsadm(1M) 和 dsconf(1M) 手册页。
本部分提供了以下有关在目录服务器上配置证书的信息：
查看默认的自签名证书
首次创建目录服务器实例时，它将包含默认的自签名证书。自签名证书是一个公钥/私钥对，其中的公钥由私钥进行签名。自签名证书的有效期为三个月。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
管理自签名证书
创建目录服务器实例时，将自动提供默认的自签名证书。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
请求 CA 签名的服务器证书
此过程介绍如何请求和安装用于目录服务器的 CA 签名服务器证书。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
添加 CA 签名的服务器证书和可信的 CA 证书
此过程介绍如何安装用于目录服务器的 CA 签名服务器证书和可信 CA 证书。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
$ dsadm add-cert --ca instance-path cert-alias cert-file
$ dsadm add-cert --ca /local/ds server-cert /local/safeplace/serv-cert-file
$ dsadm add-cert --ca -C instance-path cert-alias cert-file
$ dsadm add-cert --ca -C /local/ds CA-cert /local/safeplace/ca-cert-file
$ dsadm list-certs instance-path
$ dsadm list-certs /local/ds1
Enter the certificate database password:
Alias Valid from Expires on Self- Issued by Issued to
signed?
----------- ---------- ---------- ------- ----------------- -----------------
serverCert 2000/11/10 2011/02/10 n CN=CA-Signed Cert, CN=Test Cert,
18:13 18:13 OU=CA,O=com dc=example,dc=com
defaultCert 2006/05/18 2006/08/18 y CN=host1,CN=DS, Same as issuer
16:28 16:28 dc=example,dc=com
2 certificates found$ dsadm list-certs -C instance-path
$ dsadm list-certs -C /local/ds1
Enter the certificate database password:
Alias Valid from Expires on Self- Issued by Issued to
signed?
------- ---------- ---------- ------- ----------------- --------------
CA-cert 2000/11/10 2011/02/10 y CN=Trusted CA Cert, Same as issuer
18:12 18:12 OU=CA,O=com
1 certificate found$ dsadm show-cert instance-path cert-alias
$ dsadm show-cert /local/ds1 "Server-Cert"
Enter the certificate database password:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer:
"CN=Server-Cert,O=Sun,C=US"
Validity:
Not Before: Fri Nov 10 18:12:20 2000
Not After : Thu Feb 10 18:12:20 2011
Subject:
"CN=CA Server Cert,OU=ICNC,O=Sun,C=FR"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
bd:76:fc:29:ca:06:45:df:cd:1b:f1:ce:bb:cc:3a:f7:
77:63:5a:82:69:56:5f:3d:3a:1c:02:98:72:44:36:e4:
68:8c:22:2b:f0:a2:cb:15:7a:c4:c6:44:0d:97:2d:13:
b7:e3:bf:4e:be:b5:6a:df:ce:c4:c3:a4:8a:1d:fa:cf:
99:dc:4a:17:61:e0:37:2b:7f:90:cb:31:02:97:e4:30:
93:5d:91:f7:ef:b0:5a:c7:d4:de:d8:0e:b8:06:06:23:
ed:5f:33:f3:f8:7e:09:c5:de:a5:32:2a:1b:6a:75:c5:
0b:e3:a5:f2:7a:df:3e:3d:93:bf:ca:1f:d9:8d:24:ed
Exponent: 65537 (0x10001)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
85:92:42:1e:e3:04:4d:e5:a8:79:12:7d:72:c0:bf:45:
ea:c8:f8:af:f5:95:f0:f5:83:23:15:0b:02:73:82:24:
3d:de:1e:95:04:fb:b5:08:17:04:1c:9d:9c:9b:bd:c7:
e6:57:6c:64:38:8b:df:a2:67:f0:39:f9:70:e9:07:1f:
33:48:ea:2c:18:1d:f0:30:d8:ca:e1:29:ec:be:a3:43:
6f:df:03:d5:43:94:8f:ec:ea:9a:02:82:99:5a:54:c9:
e4:1f:8c:ae:e2:e8:3d:50:20:46:e2:c8:44:a6:32:4e:
51:48:15:d6:44:8c:e6:d2:0d:5f:77:9b:62:80:1e:30
Fingerprint (MD5):
D9:FB:74:9F:C3:EC:5A:89:8F:2C:37:47:2F:1B:D8:8F
Fingerprint (SHA1):
2E:CA:B8:BE:B6:A0:8C:84:0D:62:57:85:C6:73:14:DE:67:4E:09:56
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
User
Trusted Client CA
Email Flags:
User
Object Signing Flags:
User
续订过期的 CA 签名服务器证书
CA 签名服务器证书（公钥和私钥）过期时，可以使用此过程续订证书。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
导出和导入 CA 签名的服务器证书
在某些情况下，您可能需要导出证书的公钥和私钥，以便日后可以导入该证书。例如，您可能希望其他服务器使用该证书。
此过程中的命令可用于包含通配符的证书（如 "cn=*,o=example"）。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置证书数据库密码
默认情况下，目录服务器通过存储的密码在内部管理 SSL 证书数据库密码。在管理证书时，用户无需键入证书密码或指定密码文件。此选项不太安全，因为只是隐藏了密码，而不会对密码进行加密。
但是，如果要对证书使用进行更多控制，则可以配置服务器，以提示用户在命令行中输入密码。在这种情况下，对于除 autostart、 backup、 disable-service、enable-service、info、 reindex、 restore 和 stop 之外的所有 dsadm 子命令，用户都必须键入证书数据库密码。证书数据库位于目录 instance-path/alias 中。
将服务器配置为提示用户输入证书密码
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
备份和恢复目录服务器的证书数据库
备份目录服务器实例时，将会备份目录服务器配置和证书。备份的证书存储在 archive-path/alias 目录中。
有关如何备份和恢复目录服务器的信息，请参见创建备份以用于灾难恢复。
配置 SSL 通信本部分包含与禁用和启用 SSL 有关的过程。
禁用非安全通信
创建服务器实例时，默认情况下将创建 LDAP 端口和安全 LDAP 端口 (LDAPS)。但是，在某些情况下可能需要禁用非 SSL 通信，以便服务器只通过 SSL 进行通信。
SSL 连接是使用默认自签名证书启用的。如果需要，您可以安装自己的证书。有关在启动服务器后管理证书和禁用 SSL 的说明，请参见第 5 章，目录服务器安全性。有关证书、证书数据库以及获取 CA 签名服务器证书的概述，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
禁用 LDAP 端口
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
选择加密密码
密码是用于加密和解密数据的算法。一般而言，密码在加密期间所使用的位数越多，加密就越严密或越安全。SSL 的密码也由所使用的消息验证类型进行标识。消息验证是计算校验和（用于保证数据完整性）的另一种算法。
当客户端初始化与服务器的 SSL 连接时，客户端和服务器必须就用于加密信息的密码达成一致。在任何双向加密过程中，双方都必须使用相同的密码。所使用的密码取决于服务器所保存的密码列表的当前顺序。服务器将选择客户端所提供的与列表中的密码相匹配的第一个密码。目录服务器的默认密码值为 all，表示基础 SSL 库支持的所有已知的安全密码。但是，您可以修改此值以便只接受特定密码。
选择加密密码
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置凭证级别和验证方法应用于客户端的安全模型是通过凭证级别和验证方法的组合定义的。
目录服务器支持以下凭证级别：
-
匿名。允许匿名访问目录的特定部分意味着具有目录访问权限的任何人都具有读取访问权限。
如果使用匿名凭证级别，则必须允许对所有 LDAP 命名条目和属性进行读取访问。
注意 –不允许对目录进行匿名写入访问，因为任何人都可能会更改其具有写入访问权限的 DIT 中的信息，其中包括其他用户的密码或其自己的身份。
-
代理。客户端使用代理帐户进行验证或绑定到目录。
此代理帐户可以是允许绑定到目录的任何条目。代理帐户需要具有足够的访问权限才能对目录执行命名服务功能。您必须使用代理凭证级别在每个客户端上配置 proxyDN 和 proxyPassword。加密的 proxyPassword 存储在本地客户端中。
-
代理匿名。定义了多个凭证级别的多值条目。
分配了代理匿名级别的客户端先尝试使用其代理身份进行验证。如果客户端由于任何原因（例如，用户锁定或密码过期）而无法以代理用户身份进行验证，客户端将使用匿名访问。这可能会导致提供不同级别的服务，具体取决于目录的配置方式。
客户端验证是服务器用于验证客户端标识的一种机制。
可使用以下任一方式执行客户端验证：
-
通过提供 DN 和密码。
-
通过客户端提供的证书。
基于证书的验证使用通过 SSL 协议获取的客户端证书来查找用户的标识条目。在基于证书的验证中，客户端将发送用于指定外部机制的 SASL 绑定请求。绑定请求依赖于已建立的 SSL 验证机制。
-
通过基于 SASL 的机制。
-
在所有操作系统上，通过 DIGEST-MD5 进行 SASL 验证。
-
在 Solaris 操作系统上，通过 GSSAPI 机制（允许通过 Kerberos V5 进行客户端验证）进行 SASL 验证。
使用上述两种 SASL 机制中的任何一种时，还必须将服务器配置为执行标识映射。SASL 凭证称为主体。每种机制都必须具有特定的映射，以便通过主体的内容来确定绑定 DN。当主体映射到单个用户条目，并且 SASL 机制确认该用户的标识有效时，该用户的 DN 即为连接的绑定 DN。
-
-
通过 SSL 客户端验证模式。
如果希望所有客户端都在 SSL 层上获得授权，请使用 SSL 客户端验证。客户端应用程序通过将其 SSL 证书发送到服务器来进行验证。您可以使用 SSL-client-auth-mode 标志指定服务器允许、请求还是禁止 SSL 客户端验证。默认情况下，服务器允许客户端进行验证。
本部分提供了以下有关在目录服务器上配置两种 SASL 机制的信息。
有关配置安全性的详细信息，请参见将 LDAP 客户端配置为使用安全性。
在目录服务器中设置 SASL 加密级别
在配置 SASL 机制之前，必须指定是否需要加密。SASL 加密的要求由强度安全系数 (Strength Security Factor, SSF) 的最大值和最小值进行设置。
属性 dsSaslMinSSF(5dsat) 和 dsSaslMaxSSF(5dsat) 表示加密密钥的长度，这些属性存储在 cn=SASL, cn=security, cn=config 中。
服务器允许任何级别的加密，包括不加密。这意味着目录服务器接受大于 256 的 dsSaslMinSSF 和 dsSaslMaxSSF 值。但目前没有任何 SASL 机制支持大于 128 的 SSF。目录服务器会对这些值进行调整，使其不高于 SSF 可用的最大值 (128)。因此，实际的最大 SSF 可能低于配置的最大值，这取决于可用的基础机制。
SASL 安全系数验证依赖于以下两个主要因素：服务器和客户端应用程序所请求的最小系数和最大系数，以及基础安全组件提供的可用加密机制。概括来说，服务器和客户端将尝试使用最大的可用安全系数，该系数小于或等于两者设置的最大系数，但大于或等于两者设置的最小系数。
目录服务器的默认最小 SASL 安全系数 dsSaslMinSSF 为 0，表示没有任何保护。实际的最小值取决于客户端设置，除非您更改目录服务器的最小值。实际上，应该将最小值设置为实际希望服务器和客户端使用的最低级别。如果服务器和客户端无法协商出符合最低要求的机制，则不会建立连接。
要求 SASL 加密
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
不允许 SASL 加密
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
通过 DIGEST-MD5 进行 SASL 验证
DIGEST-MD5 机制通过比较客户端发送的散列值与用户密码的散列值来验证客户端。但是，由于此机制必须读取用户密码，因此要通过 DIGEST-MD5 进行验证的所有用户在目录中都必须具有 {CLEAR} 密码。在目录中存储 {CLEAR} 密码时，必须确保通过 ACI 正确限制对密码值的访问权限，如第 6 章，目录服务器访问控制中所述。此外，还需要在后缀中配置属性加密，如加密属性值中所述。
配置 DIGEST-MD5 机制
以下过程介绍如何将目录服务器配置为使用 DIGEST-MD5。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
DIGEST-MD5 标识映射
SASL 机制的标识映射尝试将 SASL 标识的凭证与目录中的用户条目进行匹配。如果映射找不到与 SASL 标识相对应的 DN，则验证将会失败。有关此机制的完整描述，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
SASL 标识是称为主体的字符串，以特定于每种机制的格式表示用户。在 DIGEST-MD5 中，客户端应创建包含 dn: 前缀和 LDAP DN 的主体，或者创建包含 u: 前缀（后跟由客户端确定的任何文本）的主体。在映射期间，客户端发送的主体可用于 ${Principal} 占位符中。
服务器配置中的以下条目是 DIGEST-MD5 的默认标识映射：
dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: \$1此标识映射假定主体的 dn 字段包含目录中现有用户的精确 DN。
定义您自己的 DIGEST-MD5 标识映射
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
通过 GSSAPI 进行 SASL 验证（仅适用于 Solaris 操作系统）
通过 SASL 执行的通用安全服务 API (Generic Security Service API , GSSAPI) 允许您使用第三方安全系统（如 Kerberos V5）对客户端进行验证。GSSAPI 库仅适用于 Solaris 操作系统 SPARC® 平台。Sun 建议您在 Sun Enterprise Authentication MechanismTM 1.0.1 服务器上安装 Kerberos V5 实现。
服务器使用 GSSAPI 验证用户的标识。然后，SASL 机制将应用 GSSAPI 映射规则获取 DN，该 DN 为此连接期间所有操作的绑定 DN。
配置 Kerberos 系统
可以按照制造商的说明来配置 Kerberos 软件。如果您使用的是 Sun Enterprise Authentication Mechanism 1.0.1 服务器，请使用此过程。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
配置 GSSAPI 机制
以下过程介绍如何在 Solaris 操作系统上将目录服务器配置为使用 GSSAPI：
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
GSSAPI 标识映射
SASL 机制的标识映射尝试将 SASL 标识的凭证与目录中的用户条目进行匹配。如果映射找不到与 SASL 标识相对应的 DN，则验证将会失败。
SASL 标识是称为主体的字符串，以特定于每种机制的格式表示用户。在使用 GSSAPI 的 Kerberos 中，主体为 uid [/instance][@ realm] 格式的标识。uid 可以包含后跟领域（通常为域名）的实例标识符，实例标识符和领域都是可选的。例如，以下字符串都是有效的用户主体：
bjensen bjensen/Sales bjensen@EXAMPLE.COM bjensen/Sales@EXAMPLE.COM
最初，在目录中未定义任何 GSSAPI 映射。可以根据客户端定义所用主体的方式，定义默认映射以及所需的任何自定义映射。
定义 GSSAPI 的标识映射
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
将 LDAP 客户端配置为使用安全性以下部分介绍如何在要与目录服务器建立安全连接的 LDAP 客户端中配置和使用 SSL。在 SSL 连接中，服务器会将其证书发送到客户端。客户端必须先通过信任服务器证书来验证该服务器。然后，客户端可以选择初始化一种客户端验证机制，方法是为两种 SASL 机制中的某种机制发送自身的证书或信息。SASL 机制包括 DIGEST-MD5 和使用 Kerberos V5 的 GSSAPI。
以下部分使用 ldapsearch 工具作为启用了 SSL 的 LDAP 客户端示例。
要在其他 LDAP 客户端上配置 SSL 连接，请参见随应用程序提供的文档。
注 –
某些客户端应用程序实现 SSL，但不验证服务器是否具有可信证书。这些客户端应用程序使用 SSL 协议提供数据加密，但无法保证保密性，也不能防止身份模拟。
以下部分介绍如何配置 LDAP 客户端以使用安全性：
在客户端中使用 SASL DIGEST-MD5
在客户端中使用 DIGEST-MD5 机制时，您不必安装用户证书。但是，如果要使用加密的 SSL 连接，则仍须信任服务器证书，如管理证书中所述。
指定领域
领域定义用于从中选择验证标识的名称空间。在 DIGEST-MD5 验证中，您必须通过特定领域的验证。
目录服务器使用计算机的全限定主机名作为 DIGEST-MD5 的默认领域。服务器使用 nsslapd-localhost 配置属性中包含的主机名的小写值。
如果未指定领域，将使用服务器提供的默认领域。
指定环境变量
在 UNIX 环境中，必须设置 SASL-PATH 环境变量，以便 LDAP 工具可以找到 DIGEST-MD5 库。DIGEST-MD5 库是由 SASL 插件动态装入的共享库。请按如下方式设置 SASL_PATH 环境变量：
export SASL_PATH=SASL-library
此路径假定目录服务器安装在调用 LDAP 工具的相同主机上。
ldapsearch 命令的示例
可以在不使用 SSL 的情况下执行 DIGEST-MD5 客户端验证。以下示例使用默认的 DIGEST-MD5 标识映射来确定绑定 DN：
$ ldapsearch -h host1 -p 1389 \ -o mech=DIGEST-MD5 [ \ -o realm="example.com"] \ -o authid="dn:uid=bjensen,dc=example,dc=com" \ -w - \ -o authzid="dn:uid=bjensen,dc=example,dc=com" \ -o secProp="minssf=56,maxssf=256,noplain" \ -b "dc=example,dc=com" "(givenname=Richard)"
上述示例说明如何使用 -o（小写字母 o）选项指定 SASL 选项。领域是可选的，但如果指定，则必须是服务器主机的全限定域名。authid 和 authzid 必须同时存在且完全相同，但不会使用适用于代理操作的 authzid。 -w 选项适用于 authid。
authid 的值是标识映射中使用的主体。authid 应包含 dn: 前缀后跟目录中的有效用户 DN，或者包含 u: 前缀后跟由客户端确定的任何字符串。authid 的这种用法允许您使用DIGEST-MD5 标识映射中显示的映射。
最常用的配置是使用 SSL 连接通过 LDAPS 安全端口提供加密，以及使用 DIGEST-MD5 提供客户端验证。以下示例将通过 SSL 执行相同的操作：
$ ldapsearch -h host1 -P 1636 \ -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \ -N "cert-example" -w - \ -o mech=DIGEST-MD5 [-o realm="example.com"] \ -o authid="dn:uid=bjensen,dc=example,dc=com" \ -o authzid="dn:uid=bjensen,dc=example,dc=com" \ -o secProp="minssf=0,maxssf=0,noplain" \ -b "dc=example,dc=com" "(givenname=Richard)"
在此示例中，由于操作是通过 SSL 执行的，因此 ldapsearch 命令需要使用 -N 和 -w 选项。但是，这些选项不会用于客户端验证。服务器将执行 authid 值中主体的其他 DIGEST-MD5 标识映射。
在客户端中使用 Kerberos SASL GSSAPI
在客户端中使用 GSSAPI 机制时，不必安装用户证书，但必须配置 Kerberos V5 安全系统。此外，如果要使用加密的 SSL 连接，则必须信任服务器证书，如管理证书中所述。
在主机上配置 Configure Kerberos V5
必须在将要运行 LDAP 客户端的主机上配置 Kerberos V5。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
指定用于 Kerberos 验证的 SASL 选项
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
使用 GSSAPI 和 SASL 进行 Kerberos 验证的示例配置
为目录服务器配置 Kerberos 的过程可能非常复杂。应该首先参考 Kerberos 文档。
要获取更多帮助，请通过以下示例过程了解应该执行哪些步骤。但是请注意，此过程仅仅是一个示例。您必须对过程进行相应修改，使其符合您自己的配置和环境。
可以在《System Administration Guide: Security Services》中找到有关在 Solaris 操作系统中配置和使用 Kerberos 的其他信息。本指南是 Solaris 文档集的一部分。您还可以参考手册页。
此示例的假设
此示例过程介绍如何将一台计算机配置为密钥分发中心 (Key Distribution Center, KDC)，并将另一台计算机配置为运行目录服务器。此过程的结果是用户可以通过 GSSAPI 执行 Kerberos 验证。
可以在同一台计算机上同时运行 KDC 和目录服务器。如果选择在同一台计算机上同时运行 KDC 和目录服务器，请使用相同的过程，但可以在目录服务器计算机的步骤中省略已对 KDC 计算机执行的部分。
此过程对于所使用的环境进行了许多假设。使用示例过程时，请根据您的环境适当地修改值。这些假设如下：
-
此系统已安装全新的 Solaris 9 软件和最新的推荐修补程序簇。如果未安装相应的 Solaris 修补程序，则目录服务器的 Kerberos 验证可能会失败。
请注意，尽管此处介绍的过程与适用于 Solaris 10 的过程大体相同，但仍存在一些差别。配置文件格式存在细微差别，某些命令的输出也可能不同。
-
运行 Kerberos 守护进程的计算机具有全限定域名 kdc.example.com。必须将计算机配置为使用 DNS 作为命名服务。此配置为 Kerberos 的必需配置。如果使用其他命名服务（如 file），则某些操作可能会失败。
-
运行目录服务器的计算机具有全限定域名 directory.example.com。必须将此计算机也配置为使用 DNS 作为命名服务。
-
目录服务器计算机作为通过 Kerberos 进行目录服务器验证的客户端系统。可以从任何能够与目录服务器和 Kerberos 守护进程进行通信的系统中执行此验证。但是，此示例所需的全部组件都是随目录服务器提供的，并从该系统中执行验证。
-
目录服务器中的用户具有 uid= username,ou=People,dc=example,dc=com 格式的 DN。相应的 Kerberos 主体为 username@EXAMPLE.COM。如果使用其他命名模式，则必须使用不同的 GSSAPI 标识映射。
所有计算机：编辑 Kerberos 客户端配置文件
/etc/krb5/krb5.conf 配置文件提供 Kerberos 客户端与 KDC 通信时所需的信息。
在 KDC 计算机、目录服务器计算机以及将使用 Kerberos 进行目录服务器验证的任何客户机上编辑 /etc/krb5/krb5.conf 配置文件。
-
将出现的每个 "___default_realm___" 替换为 "EXAMPLE.COM"。
-
将出现的每个 "___master_kdc___" 替换为 "kdc.example.com"。
-
删除包含 "___slave_kdcs___" 的行，因为只有一个 Kerberos 服务器。
-
将 "___domain_mapping___" 替换为 ".example.com = EXAMPLE.COM"（注意 .example.com 开头处的句点）。
已更新的 /etc/krb5/krb5.conf 配置文件应该与以下示例内容类似。
示例 5–1 已编辑的 Kerberos 客户端配置文件 /etc/krb5/krb5.conf
#pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
gkadmin = {
help_url =
http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
}所有计算机：编辑管理服务器 ACL 配置文件
在 /etc/krb5/kadm5.acl 配置文件中将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
示例 5–2 已编辑的管理服务器 ACL 配置文件
# # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # # pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" */admin@EXAMPLE.COM *
KDC 计算机：编辑 KDC 服务器配置文件
编辑 /etc/krb5/kdc.conf 文件，将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
示例 5–3 已编辑的 KDC 服务器配置文件 /etc/krb5/kdc.conf
# Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)kdc.conf 1.2 02/02/14 SMI"
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
}KDC 计算机：创建 KDC 数据库
$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’, master key name ’K/M@EXAMPLE.COM’ You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: password Re-enter KDC database master key to verify: password $
KDC 计算机：创建管理主体和密钥表
使用以下命令创建管理用户，此用户具有 kws/admin@EXAMPLE.COM 主体以及管理守护进程将要使用的服务密钥。
$ /usr/sbin/kadmin.local kadmin.local: add_principal kws/admin Enter password for principal "kws/admin@EXAMPLE.COM": secret Re-enter password for principal "kws/admin@EXAMPLE.COM": secret Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com Entry for principal kadmin/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com Entry for principal changepw/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw Entry for principal kadmin/changepw with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: quit$
KDC 计算机：启动 Kerberos 守护进程
运行以下命令来启动 KDC 和管理守护进程：
$ /etc/init.d/kdc start $ /etc/init.d/kdc.master start $
KDC 进程在进程列表中将显示为 /usr/lib/krb5/krb5kdc。管理守护进程将显示为 /usr/lib/krb5/kadmind。
请注意，在 Solaris 10 操作系统中，守护进程由服务管理工具 (Service Management Facility, SMF) 框架进行管理。在 Solaris 10 操作系统上启动守护进程：
$ svcadm disable network/security/krb5kdc $ svcadm enable network/security/krb5kdc $ svcadm disable network/security/kadmin $ svcadm enable network/security/kadmin $
KDC 计算机：为 KDC 和目录服务器计算机添加主机主体
使用以下一系列命令将主机主体添加到 KDC 和目录服务器计算机的 Kerberos 数据库。某些 Kerberos 实用程序（如 klist）将使用主机主体。
$ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal -randkey host/kdc.example.com Principal "host/kdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/kdc.example.com Entry for principal host/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: add_principal -randkey host/directory.example.com Principal "host/directory.example.com@EXAMPLE.COM" created. kadmin: ktadd host/directory.example.com Entry for principal host/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: quit $
KDC 计算机：为目录服务器添加 LDAP 主体
目录服务器必须有自身的主体，才能检验正在进行验证的用户所持有的 Kerberos 票证是否有效。目前已将目录服务器固定编码 (hard coded) 为需要 ldap/fqdn@realm 格式的主体，其中 fqdn 是目录服务器的全限定域名，而 realm 是 Kerberos 领域。fqdn 必须与安装目录服务器时提供的全限定名称相匹配。在此案例中，目录服务器的主体应该为 ldap/directory.example.com@EXAMPLE.COM。
使用以下一系列命令为目录服务器创建 LDAP 主体：
$ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal -randkey ldap/directory.example.com Principal "ldap/directory.example.com@EXAMPLE.COM" created. kadmin: quit $
KDC 计算机：向 KDC 添加测试用户
要执行 Kerberos 验证，Kerberos 数据库中必须存在要进行验证的用户。在此示例中，用户具有用户名 kerberos-test，这意味着 Kerberos 主体为 kerberos-test@EXAMPLE.COM。
使用此示例中的一系列命令创建用户：
$ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal kerberos-test Enter password for principal "kerberos-test@EXAMPLE.COM": secret Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret Principal "kerberos-test@EXAMPLE.COM" created. kadmin: quit $
目录服务器计算机：安装目录服务器
安装 Directory Server 6.0 和最新的修补程序。以下为示例设置。
|
变量类型 |
示例值 |
|---|---|
|
全限定计算机名 |
directory.example.com |
|
安装目录 |
/opt/SUNWdsee |
|
实例路径 |
/local/ds |
|
服务器用户 |
unixuser |
|
服务器组 |
unixgroup |
|
服务器端口 |
389 |
|
后缀 
|
dc=example,dc=com |
目录服务器计算机：将目录服务器配置为启用 GSSAPI
首先，创建文件 /data/ds/shared/bin/gssapi.ldif 以定义目录服务器应使用的映射，并基于主体标识要进行验证的 Kerberos 用户。请创建与以下示例内容相同的文件内容。
示例 5–4 gssapi.ldif 文件内容
dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com
dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so然后，使用 ldapmodify 命令更新目录服务器，以启用具有相应映射的 GSSAPI，如以下示例所示：
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif adding new entry cn=GSSAPI,cn=identity mapping,cn=config adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config modifying entry cn=SASL,cn=security,cn=config $
目录服务器计算机：创建目录服务器密钥表
如前面所述，要通过 GSSAPI 验证 Kerberos 用户，目录服务器在 KDC 中必须具有自身的主体。要使验证正常工作，主体信息必须包含在目录服务器计算机上的 Kerberos 密钥表中。用于运行目录服务器的用户帐户必须能够读取包含此信息的文件。
使用以下一系列命令通过正确的属性创建密钥表文件：
$ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: ktadd -k //local/ds/config/ldap.keytab ldap/directory.example.com Entry for principal ldap/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/local/ds/config/ldap.keytab. kadmin: quit $
在此自定义密钥表上更改权限和所有权。使得用于运行目录服务器的用户帐户成为此密钥表的所有者，并且只有该用户可以读取此密钥表：
$ chown unixuser:unixgroup /local/ds/config /ldap.keytab $ chmod 600 /local/ds/config/ldap.keytab $
默认情况下，目录服务器会尝试使用文件 /etc/kerb5/krb5.keytab 中的标准 Kerberos 密钥表。但是，允许目录服务器用户读取此文件可能会构成安全威胁，因此为目录服务器创建了自定义密钥表。
将目录服务器配置为使用新的自定义密钥表。可以通过设置 KRB5_KTNAME 环境变量完成此操作。
最后，重新启动目录服务器以使更改生效：
$ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds
目录服务器计算机：将测试用户添加到目录服务器中
要使 Kerberos 用户通过目录服务器的验证，该用户必须具有与其 Kerberos 主体相对应的目录条目。
在前面的步骤中，已使用主体 kerberos-test@EXAMPLE.COM 将测试用户添加到 Kerberos 数据库。由于向目录中添加了标识映射配置，因此该用户的相应目录条目必须具有 DN uid=kerberos-test,ou=People,dc=example,dc=com。
向目录添加用户之前，必须先创建包含以下内容的文件 testuser.ldif。
示例 5–5 新的 testuser.ldif 文件
dn: uid=kerberos-test,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: kerberos-test givenName: Kerberos sn: Test cn: Kerberos Test description: An account for testing Kerberos authentication through GSSAPI
然后，使用 ldapmodify 将此条目添加到服务器：
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif adding new entry uid=kerberos-test,ou=People,dc=example,dc=com $
目录服务器计算机：以测试用户的身份获取 Kerberos 票证
Kerberos 数据库、目录服务器和 KDC 中都存在测试用户。因此，现在能够以测试用户身份通过目录服务器的验证（使用 GSSAPI 和 Kerberos）。
首先，使用 kinit 命令为用户获取 Kerberos 票证，如以下示例所示：
$ kinit kerberos-test Password for kerberos-test@EXAMPLE.COM: secret $
然后，使用 klist 命令查看与此票证有关的信息：
$ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM
Valid starting Expires Service principal
Sat Jul 24 00:24:15 2004 Sat Jul 24 08:24:15 2004 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until Sat Jul 31 00:24:15 2004
$
客户机：通过 GSSAPI 进行目录服务器验证
最后一步是使用 GSSAPI 进行目录服务器验证。随目录服务器提供的 ldapsearch 实用程序支持 SASL 验证，包括 GSSAPI、DIGEST-MD5 和 EXTERNAL 机制。但是，要使用 GSSAPI 进行绑定，您必须向客户端提供 SASL 库所在的路径。通过将 SASL_PATH 环境变量设置为 lib/sasl 目录可以提供此路径：
$ SASL_PATH=SASL-library $ export SASL_PATH $
要实际使用 ldapsearch 在目录服务器上执行基于 Kerberos 的验证，必须包含 -o mech=GSSAPI 和 -o authzid=principal 参数。
此外，还必须指定全限定主机名（此处显示为 -h directory.example.com），该主机名必须与服务器 cn=config 上的 nsslapd-localhost 属性值相匹配。此处必须使用 -h 选项，因为 GSSAPI 验证过程需要客户端提供的主机名，以便与服务器提供的主机名进行匹配。
以下示例将在 dc=example,dc=com 条目被验证为之前创建的 Kerberos 测试用户帐户时检索此条目：
$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \ -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)" version: 1 dn: dc=example,dc=com dc: example objectClass: top objectClass: domain $
检查目录服务器访问日志，以确认是否按预期方式处理验证：
$ tail -12 /local/ds/logs/access
[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP
connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl
version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97
nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1
etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$此示例表明绑定过程分为三个步骤。前两步返回 LDAP 结果 14（正在进行 SASL 绑定），第三步显示绑定已成功完成。method=sasl 和 mech=GSSAPI 标记表明绑定使用了 GSSAPI SASL 机制。成功绑定响应末尾的 dn="uid=kerberos-test,ou=people,dc=example,dc=com" 表明绑定是由正确的用户执行的。
让渡验证让渡验证 (Pass-through authentication, PTA) 是一种机制，此机制将按照绑定 DN 过滤绑定请求。一个目录服务器（委托方）收到绑定请求后，可以基于过滤器查询另一个目录服务器（被委托方）以验证绑定请求。作为此功能的一部分，对于未必存储在本地数据库中的条目，PTA 插件允许委托方目录服务器接受基于密码的简单绑定操作。
DSCC 也可使用 PTA 插件与服务器进行专用通信。在 DSCC 中注册服务器实例时，将启用 PTA 插件，并将 DSCC URL 作为参数进行添加。
$ dsconf get-plugin-prop -h host -p port "Pass Through Authentication" enabled argument argument : ldap://DSCC_URL:DSCC_PORT/cn=dscc enabled : on
注 –
请尽量避免针对个人使用而修改 PTA 插件。修改 PTA 插件可能会导致 DSCC 出现访问问题。
如果无法避免修改 PTA 插件，则必须执行以下操作：
-
继续将 enabled 属性设置为 on。
-
在参数中保留 DSCC URL，但您可以向 argument 属性添加其他值。
如果 PTA 插件已被禁用，或者已从参数中删除 DSCC URL，则服务器实例在 DSCC 中将显示为 inaccessible。如果发生这种情况，DSCC 将自动为您提供用于重置 PTA 插件的选项。
第 6 章 目录服务器访问控制对目录访问的控制是创建安全目录不可或缺的一部分。本章介绍访问控制指令 (Access Control Instruction, ACI)，这些指令用于确定要为访问目录的用户授予哪些权限。
请在目录部署的规划阶段定义符合总体安全策略的访问控制策略。有关规划访问控制策略的提示，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》。
有关 ACI 的其他信息（包括 ACI 语法和绑定规则），请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》。
本章包含以下主题：
创建、查看和修改 ACI可以通过使用目录服务控制中心 (Directory Service Control Center, DSCC) 或命令行创建 ACI。无论选择哪种方法，查看并复制现有 ACI 值通常比从头创建新 ACI 更容易。
可以在 DSCC 中查看和修改 aci 属性值。有关如何通过 DSCC 修改 ACI 的信息，请参见 DSCC 联机帮助。
创建、修改和删除 ACI
要使用命令行创建 ACI，应首先使用 LDIF 语句在文件中创建 ACI。然后通过使用 ldapmodify 命令将 ACI 添加到您的目录树中。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
查看 ACI 属性值
ACI 作为条目的一个或多个 aci 属性值进行存储。aci 属性为多值操作属性，可由目录用户读取和修改。因此，ACI 属性自身应受 ACI 保护。管理用户通常具有 aci 属性的完全访问权限。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
查看根级别的 ACI
创建后缀时，将在顶级或根级别上创建一些默认 ACI。这些 ACI 允许默认管理用户 cn=admin,cn=Administrators,cn=config 具有与目录管理员相同的目录数据访问权限。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
访问控制使用示例本部分中的示例说明了一家虚构的 ISP 公司 Example.com 如何实现其访问控制策略。
此外，您也可以在随安装提供的示例 LDIF 文件 (install_path/ds6/ldif/Example.ldif) 中找到 ACI 示例。
所有示例都说明如何使用 LDIF 文件执行给定任务。下图以图形方式显示了 example.com 目录信息树。
Example.com 提供了 Web 托管服务和 Internet 访问。Example.com 的部分 Web 托管服务用于托管客户端公司的目录。Example.com 实际上托管并部分管理两家中型公司（Company333 和 Company999）的目录。此外，Example.com 还提供对大量单个订户的 Internet 访问。
Example.com 希望制定以下访问规则：
授予匿名访问权限
大多数目录都配置为至少允许您匿名访问一个后缀，以进行读取、搜索或比较。如果要运行公司人员目录（如可供员工搜索的电话薄），则可能需要设置这些权限。Example.com 内部即为这种情况，如ACI "Anonymous Example.com"中所示。
作为 ISP，Example.com 还要创建允许所有人访问的公共电话薄，以提供其所有订户的联系信息。相关内容如ACI "Anonymous World"中所述。
ACI "Anonymous Example.com"
在 LDIF 中，要为 Example.com 员工授予对整个 Example.com 树的读取、搜索和比较权限，可编写以下语句：
aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous example"; allow (read, search, compare) userdn= "ldap:///anyone") ;)
本示例假定将 aci 添加到 dc=example,dc=com 条目中。请注意，userPassword 属性被排除在 ACI 范围之外。
注 –
请使用与密码属性保护示例中所用的相同语法来保护保密属性和不应显示的属性，即 (targetattr !="attribute-name ")。
ACI "Anonymous World"
在 LDIF 中，要为所有人授予对单个订户子树的读取和搜索访问权限，但不允许访问未列出订户的信息，可编写以下语句：
aci: (targetfilter= "(!(unlistedSubscriber=yes))") (targetattr="homePostalAddress || homePhone || mail") (version 3.0; acl "Anonymous World"; allow (read, search) userdn="ldap:///anyone";)
此示例假定 ACI 已添加到 ou=subscribers,dc=example, dc=com 条目中。此示例还假定每个订户条目都具有 unlistedSubscriber 属性（设置为 yes 或 no）。目标定义将根据此属性的值过滤掉未列出的订户。有关过滤器定义的详细信息，请参阅使用过滤设置目标。
授予对个人条目的写入访问权限
许多目录管理者都允许内部用户更改其自身条目中的部分（而非全部）属性。Example.com 的目录管理者允许用户更改自身的密码、家庭电话号码和家庭地址，但不允许更改其他内容。相关内容如ACI "Write Example.com"中所述。
Example.com 还有一条策略，即，如果订户建立到目录的 SSL 连接，则允许订户在 Example.com 树中更新自身的个人信息。相关内容如ACI "Write Subscribers"中所述。
ACI "Write Example.com"
注 –
通过设置此权限，还可以为用户授予删除属性值的权限。
在 LDIF 中，要为 Example.com 员工授予更新其家庭电话号码和家庭地址的权限，可编写以下语句：
aci: (targetattr="homePhone || homePostalAddress")(version 3.0; acl "Write Example.com"; allow (write) userdn="ldap:///self" ;)
此示例假定 ACI 已添加到 ou=People,dc=example,dc=com 条目中。
ACI "Write Subscribers"
注 –
通过设置此权限，还可以为用户授予删除属性值的权限。
在 LDIF 中，要为 Example.com 订户授予更新其家庭电话号码的权限，可编写以下语句：
aci: (targetattr="homePhone") (version 3.0; acl "Write Subscribers"; allow (write) userdn= "ldap://self" and authmethod="ssl";)
此示例假定 aci 已添加到 ou=subscribers,dc=example, dc=com 条目中，并且用户必须使用 SSL 进行绑定。
请注意，Example.com 订户对其家庭地址没有写入访问权限，因为他们可能会删除该属性。家庭地址是 Example.com 寄发帐单时所需的重要业务信息。
授予对特定级别的访问权限
可以通过设置 ACI 的范围来影响目录树中的不同级别，以便对您所允许的访问权限级别进行微调。可将目标 ACI 范围设置为以下任一选项：
- base
-
条目自身
- onelevel
-
条目自身及其下一级的所有条目
- subtree
-
条目自身及其下面的所有条目（不限制深度）
ACI "Read Example.com only"
在 LDIF 中，要为 Example.com 订户授予读取 dc=example,dc=com 条目的权限（以获取公司联系信息），但不允许访问该条目下的任何条目，可编写以下语句：
aci: (targetscope="base") (targetattr="*")(version 3.0; acl "Read Example.com only"; allow (read,search,compare) userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)
此示例假定 ACI 已添加到 dc=example, dc=com 条目中。
限制对重要角色的访问权限
您可以在目录中使用角色定义，以标识对业务至关重要的功能，如网络和目录管理。
例如，您可以通过标识系统管理员的某个子集来创建超级管理员 (superAdmin) 角色，这些管理员于每周特定日期的特定时间在全球公司站点上可用。或者，您也可以创建急救员 (First Aid) 角色，其中包括特定站点中所有受过急救培训的工作人员。有关创建角色定义的信息，请参见管理角色。
当某个角色在重要的公司或业务功能方面可提供任何种类的用户特权时，应考虑限制对该角色的访问权限。例如，在 Example.com 中，员工可以向自身条目中添加除超级管理员 (superAdmin) 角色之外的任何角色，如以下示例所示。
ACI "Roles"
在 LDIF 中，要为 Example.com 员工授予在自身条目中添加除超级管理员 (superAdmin) 之外的任何角色的权限，可编写以下语句：
aci: (targetattr="*") (targattrfilters="add=nsRoleDN: (nsRoleDN !="cn=superAdmin, dc=example, dc=com")") (version 3.0; acl "Roles"; allow (write) userdn= "ldap:///self" ;)
此示例假定 ACI 已添加到 ou=People,dc=example, dc=com 条目中。
为角色授予对整个后缀的完全访问权限
有时，针对某个后缀为特定用户授予与目录管理员相同的权限是非常有用的。在 Example.com 中，Kirsten Vaughan 是目录服务器管理员。她具有超级管理员 (superAdmin) 角色。此角色具有以下优点：
-
由于可以强制以自身标识进行绑定的管理员使用强验证（如 SSL），因此更加安全
-
由于只有少数人知道目录管理员密码，因此更加安全
-
可通过日志记录提高可追溯性
注 –
将 Kirsten Vaughan 添加到 cn=Administrators,cn=config 组还会为她授予与目录管理员相同的权限。
要使用户对整个服务器具有与目录管理员相同的权限，请执行创建具有超级用户权限的管理用户中的过程。
ACI "Full Access"
在 LDIF 中，要为管理员 Kirsten Vaughan 授予与目录管理员相同的权限，请使用以下语句：
aci: (targetattr="*") (version 3.0; acl "Full Access"; allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com" and authmethod="ssl" ;)
此示例假定 ACI 已添加到根条目 ""（无文本）中。
为组授予对后缀的完全访问权限
大多数目录都有用于标识特定公司功能的组。可以为组授予对部分或全部目录的访问权限。通过将访问权限应用于组，可以避免单独为每个成员设置访问权限。可以通过将用户添加到组来为这些用户授予访问权限。
例如，在创建目录服务器实例时，默认情况下将创建一个管理员组 cn=Administrators,cn=config，此组具有目录的完全访问权限。
在 Example.com 中，人力资源组对目录的 ou=People 分支具有完全访问权限，这样他们可以更新员工目录，如ACI "HR"中所示。
ACI "HR"
在 LDIF 中，要为人力资源组授予对目录员工分支的所有权限，请使用以下语句：
aci: (targetattr="*") (version 3.0; acl "HR"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)
此示例假定 ACI 已添加到以下条目中：
ou=People,dc=example,dc=com
授予添加和删除组条目的权限
某些组织允许员工在树中创建条目，以提高员工的工作效率，并鼓励员工为公司活力注入一己之力。例如，在 Example.com 中，Social Committee 由网球、游泳、滑雪和角色扮演等各种俱乐部组成。
任何 Example.com 员工都可以创建代表新俱乐部的组条目，如ACI "Create Group"中所示。
任何 Example.com 员工都可以成为其中某个组的成员，如允许用户在组中添加或删除自身中所示。
只有组的所有者才能修改或删除组条目，如ACI "Delete Group"中所示。
ACI "Create Group"
在 LDIF 中，要为 Example.com 员工授予在 ou=Social Committee 分支下创建组条目的权限，可编写以下语句：
aci: (targetattr="*") (targattrfilters="add=objectClass: (|(objectClass=groupOfNames)(objectClass=top))") (version 3.0; acl "Create Group"; allow (read,search,add) userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") and dns="*.Example.com";)
此示例假定 ACI 已添加到 ou=Social Committee,dc=example,dc=com 条目中。
注 –
-
此 ACI 不授予写入权限，这意味着条目创建者无法修改条目。
-
由于服务器在后台添加值 top，因此需要在 targattrfilters 关键字中指定 objectClass=top。
-
ACI 将客户机限制在 example.com 域中。
ACI "Delete Group"
在 LDIF 中，要为 Example.com 员工授予相应权限，以修改或删除其所属组（在 ou=Social Committee 分支下）的组条目，可编写以下语句：
aci: (targetattr = "*") (targattrfilters="del=objectClass: (objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (write,delete) userattr="owner#GROUPDN";)
此示例假定 aci 已添加到 ou=Social Committee,dc=example,dc=com 条目中。
请注意，使用 DSCC 创建此 ACI 不是有效方式，因为您必须使用手动编辑模式创建目标过滤器，并检查组的所有权。
允许用户在组中添加或删除自身
许多目录都设置了允许用户在组中（如邮件列表）添加或删除自身的 ACI。
在 Example.com 中，员工可以将自身添加到 ou=Social Committee 子树下的任何组条目中，如ACI "Group Members"中所示。
ACI "Group Members"
在 LDIF 中，要为 Example.com 员工授予将自身添加到组的权限，可编写以下语句：
aci: (targettattr="member")(version 3.0; acl "Group Members"; allow (selfwrite) (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)
此示例假定 ACI 已添加到 ou=Social Committee, dc=example,dc=com 条目中。
为组或角色授予条件访问权限
在许多情况下，当您为组或角色授予对目录的访问特权时，必须确保入侵者无法模拟特权用户使用这些特权。因此，在许多情况下，为组或角色授予重要访问权限的访问控制规则通常与许多条件相关联。
例如，Example.com 为其每个托管公司（Company333 和 Company999）创建了一个目录管理者角色。Example.com 希望这两家公司能够管理各自的数据并实现各自的访问控制规则，同时又能确保数据不受侵犯。
因此，如果满足以下条件，Company333 和 Company999 将对其各自的目录树分支具有完全权限。
-
使用证书通过 SSL 对连接进行验证。
-
在星期一至星期四的 8:00 至 18:00 之间请求访问。
-
从每个公司的指定 IP 地址请求访问。
这些条件将在每个公司的某个 ACI（ACI "Company333" 和 ACI "Company999"）中列出。由于两个 ACI 的内容相同，因此以下示例只使用 "Company333" ACI。
ACI "Company333"
在 LDIF 中，要在满足上述条件的情况下为 Company333 授予对其目录分支的完全访问权限，可编写以下语句：
aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all) (roledn="ldap:///cn=DirectoryAdmin,ou=Company333, ou=corporate clients,dc=example,dc=com") and (authmethod="ssl") and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and timeofday <= "1800") and (ip="255.255.123.234"); )
此示例假定 ACI 已添加到 ou=Company333,ou=corporate clients,dc=example,dc=com 条目中。
拒绝访问
如果您已经允许对后缀的大部分进行访问，则您可能希望在现有的 ACI 下拒绝对后缀的较小部分进行访问。
注 –
应尽可能避免拒绝访问，因为它可能会导致意外或复杂的访问控制行为。可以结合使用作用域、属性列表、目标过滤器等来限制访问权限。
此外，删除拒绝访问 ACI 不会删除权限，但会扩展其他 ACI 所设置的权限。
当目录服务器评估访问权限时，它将首先读取 deny 权限，然后再读取 allow 权限。
在后面的示例中，Example.com 希望所有订户都能读取自身条目下的帐单信息，如连接时间或帐户余额。Example.com 也明确希望拒绝对该信息的写入访问权限。读取访问权限将在ACI "Billing Info Read"中进行介绍。拒绝访问权限将在ACI "Billing Info Deny"中进行介绍。
ACI "Billing Info Read"
在 LDIF 中，要为订户授予读取自身条目中的帐单信息的权限，可编写以下语句：
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn="ldap:///self";)
此示例假定已在模式中创建了相关属性，并且 ACI 已添加到 ou=subscribers,dc=example,dc=com 条目中。
ACI "Billing Info Deny"
在 LDIF 中，要拒绝订户修改自身条目中的帐单信息的权限，可编写以下语句：
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn="ldap:///self";)
此示例假定已在模式中创建了相关属性，并且 ACI 已添加到 ou=subscribers,dc=example,dc=com 条目中。
代理授权
代理授权方法是一种特殊形式的验证。通过代理授权，可为使用自身标识绑定到目录的用户授予其他用户的权限。
要将目录服务器配置为允许代理请求，必须执行以下操作：
-
为管理员授予与其他用户相同的代理权限。
-
为普通用户授予访问控制策略中所定义的一般访问权限。
注 –
您可以将代理权限授予除目录管理员之外的任何目录用户。此外，您无法将目录管理员的 DN 用作代理 DN。授予代理权限时应特别小心，因为授予此权限可将任何 DN（目录管理员 DN 除外）指定为代理 DN。如果目录服务器在同一操作中收到多个代理验证控制，则会向客户端应用程序返回错误，并且操作尝试将会失败。
示例代理授权
对于 LDAP 数据，Example.com 希望绑定为 MoneyWizAcctSoftware 的客户端应用程序具有与帐户管理员相同的访问权限。
将应用以下参数：
-
客户端应用程序的绑定 DN 为 uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com。
-
客户端应用程序请求访问权限的目标子树为 ou=Accounting,dc=example,dc=com。
-
目录中存在对 ou=Accounting,dc=example,dc=com 子树具有访问权限的帐户管理员。
要使客户端应用程序获取对帐户子树的访问权限（通过使用与帐户管理员相同的访问权限），必须满足以下条件：
aci: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)
aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware"; allow (proxy) userdn= "ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)
正确使用此 ACI 之后，MoneyWizAcctSoftware 客户端应用程序即可绑定到目录，然后发送需要代理 DN 访问权限的 LDAP 命令，如 ldapsearch 或 ldapmodify。
在此示例中，如果客户端要执行 ldapsearch 命令，则此命令将包括以下控制：
$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \ -y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...
请注意，客户端以自身标识进行绑定，但被授予代理条目的特权。客户端不需要代理条目的密码。
使用过滤设置目标
如果要设置允许访问目录中大量条目的访问控制，则可以使用过滤器设置目标。
在 LDIF 中，要通过过滤器允许人力资源部门的所有用户访问员工条目，可编写以下语句：
aci: (targetattr="*") (targetfilter=(objectClass=employee)) (version 3.0; acl "HR access to employees"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)
此示例假定 ACI 已添加到 ou=People,dc=example,dc=com 条目中。
注 –
由于搜索过滤器不直接指出要管理访问权限的对象的名称，因此在允许或拒绝对象的访问权限时，请勿弄错对象。如果不慎允许或拒绝了错误对象的访问权限，则随着目录变得越来越复杂，风险将会越来越大。此外，使用过滤器时，您可能难以对目录中的访问控制问题进行故障排除。
为包含逗号的 DN 定义权限
需要在 LDIF ACI 语句中对包含逗号的 DN 进行特殊处理。在 ACI 语句的目标和绑定规则部分，必须使用单个反斜杠 (\) 来转义逗号。以下示例对此语法进行了说明：
dn: o=Example.com Bolivia\, S.A. objectClass: top objectClass: organization aci: (target="ldap:///o=Example.com Bolivia\,S.A.") (targetattr="*") (version 3.0; acl "aci 2"; allow (all) groupdn = "ldap:///cn=Directory Administrators, o=Example.com Bolivia\, S.A.";)查看有效权限
维护目录中条目的访问策略时，您需要了解所定义的 ACI 对安全性的影响。目录服务器允许您评估现有 ACI，方法是查看 ACI 针对给定条目为给定用户授予的有效权限。
目录服务器会对“获得有效的权限”控制做出响应，可在搜索操作中包含此控制。对此控制的响应是在搜索结果中返回有关条目和属性的有效权限信息。此额外信息包括每个条目及其每个属性的读写权限。可以为用于搜索的绑定 DN 或任意 DN 请求这些权限。此功能允许管理员测试目录用户的权限。
有效权限功能依赖于 LDAP 控制。必须确保用于绑定到远程服务器的代理标识也可以访问这些有效权限属性。
限制对“获得有效的权限”控制的访问权限
查看有效权限的操作是一种目录操作，必需对该操作进行保护和适当地限制。
要限制对有效权限信息的访问权限，请修改 getEffectiveRights 属性的默认 ACI。然后为 getEffectiveRightsInfo 属性创建新的 ACI。
例如，以下 ACI 只允许目录管理者组的成员获得有效权限：
aci: (targetattr != "aci")(version 3.0; acl "getEffectiveRights"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
要获取有效权限信息，您必需具有使用有效权限控制的访问控制权限，并且具有对 aclRights 属性的读取权限。这种双层访问控制提供了可在必要时进一步微调的基本安全性。与代理类似，如果您对某个条目中的 aclRights 属性具有读取访问权限，则可以请求任何人对于该条目及其属性的权限信息。这表明管理资源的用户可以确定具有该资源权限的人员，即使此用户实际上并不管理具有这些权限的人员。
如果请求权限信息的用户没有使用有效权限控制的权限，则此操作将会失败，并返回错误消息。但是，如果请求权限信息的用户具有使用此控制的权限，但没有读取 aclRights 属性的权限，则 aclRights 属性不会出现在返回的条目中。此行为反映了目录服务器的常规搜索行为。
使用“获得有效的权限”控制
通过在 ldapsearch 命令中使用 -J "1.3.6.1.4.1.42.2.27.9.5.2" 选项可指定“获得有效的权限”控制。默认情况下，此控制将在搜索结果中返回绑定 DN 对条目和属性的有效权限。
可使用以下选项更改默认行为：
-
-c "dn: bind DN " — 搜索结果将显示使用给定 DN 进行绑定的用户的有效权限。此选项允许管理员检查其他用户的有效权限。选项 -c "dn:" 显示匿名验证的有效权限。
-
-X "attributeName ... " — 搜索结果还包括对指定属性的有效权限。使用此选项可指定不在搜索结果中显示的属性。例如，可以使用此选项确定用户是否有权添加当前不在条目中的属性。
-
使用 -c 和/或 -X 选项时，将自动包含 OID 为“获得有效的权限”控制的 -J 选项，无需另行指定 。如果为有效权限控制指定 NULL 值，则会检索当前用户的权限。此外，还会检索当前 ldapsearch 操作所返回的属性和条目的权限。
接下来您必须选择要查看的信息类型。可以选择简单权限，也可以选择说明如何授予或拒绝这些权限的详细日志记录信息。通过分别添加 aclRights 或 aclRightsInfo 作为要在搜索结果中返回的属性，可以确定信息类型。您可以同时请求两个属性，以接收所有的有效权限信息，但实际上简单权限会在详细的日志记录信息中重复这些信息。
注 –
aclRights 和 aclRightsInfo 属性的行为与虚拟操作属性类似。这些属性并未存储在目录中，如果未经明确请求，将不会返回这些属性。它们是由目录服务器在响应“获得有效的权限”控制时生成的。
因此，这些属性无法用在任何类型的过滤器或搜索操作中。
有效权限功能继承了影响访问控制的其他参数。这些参数包括时间、验证方法、计算机地址和名称。
以下示例说明用户 Carla Fuente 如何查看她在目录中的权限。在结果中，1 表示授予权限，0 表示拒绝权限。
$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2 -h host1.Example.com -p 389 \ -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \ "(objectclass=*)" aclRights Enter bind password: dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
此结果为 Carla Fuente 显示了她在目录中至少具有读取权限的条目，并表明她可以修改自身的条目。有效权限控制不会避开普通访问权限，因此用户看不到他们没有读取权限的条目。在以下示例中，目录管理员可以看到 Carla Fuente 没有读取权限的条目：
$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \ -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \ "(objectclass=*)" aclRights Enter bind password: dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Directory Administrators, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=Special Users,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
在前面的输出中，目录管理员可以看出 Carla Fuente 甚至无法查看目录树的 Special Users 和 Directory Administrators 分支。在以下示例中，目录管理员可以看出 Carla Fuente 无法修改其自身条目中的 mail 和 manager 属性：
$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
-c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
"(uid=cfuente)" aclRights "*"
Enter bind password:
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@Example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0高级访问控制：使用宏 ACI
使用重复目录树结构的组织可以通过宏来优化目录中所使用的 ACI 的数量。如果减少目录树中的 ACI 数，将更容易管理访问控制策略。此外，还会提高 ACI 内存使用的效率。
宏是一种占位符，用于在 ACI 中表示 DN 或 DN 的一部分。可以使用宏来表示 ACI 目标部分和/或绑定规则部分中的 DN。实际上，当目录服务器收到传入的 LDAP 操作时，将根据 LDAP 操作的目标资源对 ACI 宏进行匹配。进行匹配的目的是为了找出匹配的子串（如果有）。如果存在匹配项，将使用匹配的子串扩展绑定规则端的宏，并通过评估已扩展的绑定规则来确定对资源的访问权限。
本部分包含宏 ACI 的示例和有关宏 ACI 语法的信息。
宏 ACI 示例
使用示例说明宏 ACI 的优点及其工作方式最为清楚。图 6–1 显示了一个目录树，在此目录树中，使用宏 ACI 可有效减少总体的 ACI 数。
请注意，在此图例中，相同的树结构 (ou=groups,ou=people) 具有重复的子域模式。此模式在整个树中也是重复的，因为 Example.com 目录树存储两个后缀 dc=hostedCompany2,dc=example,dc=com 和 dc=hostedCompany3,dc=example,dc=com（图中未显示）。
目录树中的 ACI 也具有重复的模式。例如，以下 ACI 位于 dc=hostedCompany1,dc=example,dc=com 节点上：
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain))(version 3.0; acl "Domain access"; allow (read,search) groupdn= "ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1, dc=example,dc=com";)
此 ACI 为 domainAdmins 组授予对 dc=hostedCompany1,dc=example,dc=com 树中任何条目的读取和搜索权限。
图 6–1 宏 ACI 的示例目录树
以下 ACI 位于 dc=hostedCompany1,dc=example,dc=com 节点上：
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)
以下 ACI 位于 dc=subdomain1,dc=hostedCompany1, dc=example,dc=com 节点上：
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1, dc=example,dc=com";)
以下 ACI 位于 dc=hostedCompany2,dc=example,dc=com 节点上：
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)
以下 ACI 位于 dc=subdomain1,dc=hostedCompany2, dc=example,dc=com 节点上：
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2, dc=example,dc=com";)
在上述四个 ACI 中，唯一的不同之处是在 groupdn 关键字中指定的 DN。通过为 DN 使用宏，可以在树的根部（即 dc=example,dc=com 节点上）使用一个 ACI 替换这些 ACI。此宏 ACI 如下所示：
aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
请注意，此时需要使用之前未使用的关键字 target。
在上述示例中，ACI 的数量从四个减少到一个。但其真正的好处取决于您在整个目录树中的重复模式数。
宏 ACI 语法
为了简便起见，本部分将用于提供绑定凭证的 ACI 关键字（如 userdn、roledn、groupdn 和 userattr）统称为 ACI 的主题。主题可确定应用 ACI 的对象。
下表显示可用于替换特定 ACI 关键字的宏。
表 6–1 宏 ACI 关键字|
宏 |
描述 |
ACI 关键字 |
|---|---|---|
|
($dn) |
用于在目标中进行匹配，并在主题中直接替换。 |
target、targetfilter、userdn、roledn、groupdn、userattr |
|
[$dn] |
用于替换在主题的子树中使用的多个 RDN。 |
targetfilter、userdn、roledn、groupdn、userattr |
|
($attr.attrName) |
用于将目标条目中的 attributeName 属性值替换到主题中。 |
userdn、roledn、groupdn、userattr |
宏 ACI 关键字具有以下限制：
-
在主题中使用 ($dn) 和 [$dn] 宏时，必须定义包含 ($dn) 宏的目标。
-
可以在主题中结合使用 ($dn) 宏（而非 [$dn] 宏）和 ($attr.attrName) 宏。
匹配目标中的 ($dn)
ACI 目标中的 ($dn) 宏通过比较自身与 LDAP 请求的目标条目来确定替换值。例如，您的 LDAP 请求将以下条目作为目标：
cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com
此外，您还具有按如下方式定义目标的 ACI：
(target="ldap:///ou=Groups,($dn),dc=example,dc=com")
($dn) 宏与 "dc=subdomain1, dc=hostedCompany1" 相匹配。因此会将此子串用作 ACI 主题中的替换值。
在主题中替换 ($dn)
在 ACI 的主题中，($dn) 宏将被替换为目标中匹配的整个子串。例如：
groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"
此主题将变为：
groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"
扩展宏之后，目录服务器将在完成普通进程后评估 ACI，以确定是否授予访问权限。
注 –
与标准 ACI 不同，使用宏替换的 ACI 不一定会授予对目标条目的子条目的访问权限。这是因为当目标为子 DN 时，替换可能不会在主题字符串中创建有效 DN。
在主题中替换 [$dn]
[$dn] 的替换机制与 ($dn) 略有不同。将对目标资源的 DN 进行多次检查，每次都舍弃最左侧的 RDN 部分，直到找到匹配项为止。
例如，假定您的 LDAP 请求将 cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com 子树作为目标，并具有以下 ACI：
aci: (targetattr="*") (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn], dc=example,dc=com";)
-
服务器验证目标中的 ($dn) 是否与 dc=subdomain1,dc=hostedCompany1 相匹配。
-
服务器将主题中的 [$dn] 替换为 dc=subdomain1,dc=hostedCompany1。
得到的主题为 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"。如果因为绑定 DN 是该组的成员而授予访问权限，则宏扩展将停止，并对此 ACI 进行评估。如果绑定 DN 不是其成员，则此过程将继续。
-
服务器将主题中的 [$dn] 替换为 dc=hostedCompany1。
得到的主题为 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com"。再次将绑定 DN 作为此组的成员进行测试，如果是其成员，则对此 ACI 进行完全评估。如果此绑定 DN 不是其成员，宏扩展将在最后一个具有匹配值的 RDN 处停止，并且对此 ACI 的评估将结束。
服务器将按如下方式继续操作，以扩展此 ACI：
[$dn] 宏的优点在于它提供了一种灵活的方法，可以为域级别管理员授予对目录树中所有子域的访问权限。因此，[$dn] 宏在表示域之间的层次关系方面非常有用。
例如，请考虑以下 ACI：
aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn= "ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
此 ACI 为 cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com 的成员授予对 dc=hostedCompany1 下所有子域的访问权限。因此，属于该组的管理员可以访问 ou=people,dc=subdomain1.1,dc=subdomain1 等子树。
但同时将拒绝 cn=DomainAdmins,ou=Groups, dc=subdomain1.1 的成员访问 ou=people,dc=subdomain1, dc=hostedCompany1 和 ou=people,dc=hostedCompany1 节点。
($attr.attrName ) 的宏匹配
将始终在 DN 的主题部分使用 ($attr.attrname) 宏。例如，您可以定义以下 roledn：
roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1,dc=example,dc=com"
现在假定服务器收到了将以下条目作为目标的 LDAP 操作：
dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com cn: Babs Jensen sn: Jensen ou: Sales ...
为了评估 ACI 的 roledn 部分，服务器会读取存储在目标条目中的 ou 属性值。然后，服务器将在主题中替换此值以扩展宏。在此示例中，roledn 将按如下方式扩展：
roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"
然后目录服务器将根据普通 ACI 评估算法来评估此 ACI。
如果宏中指定的属性为多值属性，将依次使用每个值来扩展宏。将使用提供成功匹配的第一个值。
记录访问控制信息要获取错误日志中的访问控制信息，必须设置相应的日志级别。
设置 ACI 的日志记录
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
通过 TCP 包装控制客户端-主机访问可以使用 TCP 包装器，控制在 TCP 级别接受或拒绝连接的主机或 IP 地址。可以通过 TCP 包装限制客户端-主机访问。这样，您可以对目录服务器的初始 TCP 连接使用非主机式保护。
虽然可以为目录服务器设置 TCP 包装，但 TCP 包装可能会导致性能显著下降，特别是在拒绝服务攻击期间。要获取最佳性能，可以使用在目录服务器外部维护的基于主机的防火墙，或者使用 IP 端口过滤。
启用 TCP 包装
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
禁用 TCP 包装
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
第 7 章 目录服务器密码策略用户连接到目录服务器时，系统将对该用户进行验证。根据验证期间建立的标识，目录可以为用户授予访问权限和资源限制。本章中的帐户一般指用户条目。帐户还反映用户在目录上执行操作的权限。在本章的密码策略讨论中，每个帐户都与用户条目和密码相关联。
本章还将介绍帐户激活（密码策略的一个方面）。目录管理者可以直接对帐户进行锁定和解除锁定，此操作独立于密码策略。
本章不包含验证方法。某些验证方法（如 SASL GSSAPI 和基于客户端 SSL 证书的验证）不需要使用密码。本章中与密码策略有关的信息不适用于此类验证方法。有关配置验证机制的说明，请参见第 5 章，目录服务器安全性。
本章也没有介绍 Directory Server 6.2 与以前目录服务器版本之间的密码策略兼容性。创建 Directory Server 6.2 实例时，密码策略实现默认为 Directory Server 5 兼容模式，以便于从早期版本进行升级。要充分利用本章中介绍的密码策略功能，您需要更改密码策略兼容性模式。有关设置密码兼容性模式的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide》中的“Password Policy Compatibility”。
本章包含以下主题：
密码策略和工作单本部分介绍密码策略设置，并提供一个工作单，以帮助您定义符合要求的密码策略。
注 –
要使用默认的密码策略，请参见管理默认密码策略。
密码策略设置
在目录服务器中指定密码策略时，需要修改或创建包含对象类 pwdPolicy(5dsoc) 的条目。
为特定类型的用户定义密码策略时，需要考虑以下注意事项：
本章的后续部分将介绍如何处理密码策略的这些方面。可以使用用于定义密码策略的工作单阐明要实现的每种密码策略。
帐户锁定策略
本部分介绍用于管理帐户锁定的策略属性。
目录服务器帐户一般指用户条目，以及用户在目录上执行操作的权限。每个帐户都与绑定 DN 和用户密码相关联。当入侵者看上去要尝试破解密码时，您希望目录服务器锁定帐户。锁定可阻止入侵者使用帐户进行绑定。锁定还可阻止入侵者继续进行攻击。
作为管理员，您还可以手动停用某个帐户或共享某个角色的所有用户的帐户。有关说明，请参见手动锁定帐户。但是，密码策略的一个重要部分就是指定目录服务器在什么情况下锁定帐户，而不需要您的干预。
首先，您必须指定目录服务器可以在发生太多失败绑定时使用 pwdLockout(5dsat) 自动锁定帐户。目录服务器会跟踪尝试绑定到帐户的连续失败次数。可以使用 pwdMaxFailure(5dsat) 指定在目录服务器锁定帐户之前所允许的连续失败次数。
目录服务器将严格按照密码策略锁定帐户。此操作完全为机械性操作。帐户锁定的原因可能不是入侵者对帐户发动攻击，而是用户键入了错误的密码。因此，可以使用 pwdFailureCountInterval(5dsat) 指定目录服务器在清除失败尝试记录之前等待下一次尝试的时间。可以使用 pwdLockoutDuration(5dsat) 指定在目录服务器自动对帐户解除锁定之前锁定持续的时间。如果用户并非出于恶意而犯下了合理错误，管理员无需介入帐户解除锁定。
如果在复制拓扑中复制用户数据，则会将锁定属性与其他条目数据一起复制。pwdIsLockoutPrioritized(5dsat) 属性的默认设置为 TRUE，因此将以较高的优先级复制锁定属性的更新。这样，用户只能对任何单个副本连续进行 pwdMaxFailure 次失败的绑定尝试，超过之后将被锁定；对于其他副本，被锁定之前的绑定尝试次数可能更少一些。有关如何确保用户在整个复制拓扑中被锁定之前恰好进行 pwdMaxFailure 次尝试的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中的“Preventing Authentication by Using Global Account Lockout”。
密码更改策略
本部分介绍用于管理密码更改的策略属性。
在许多部署中，目录服务器是标识数据的系统信息库。用户应该可以更改自己的密码（由 pwdAllowUserChange(5dsat) 指定），因此您无需更改密码。
允许用户更改自己的密码之后，您可能还希望控制用户可以在哪些情况下更改密码。可以使用 pwdSafeModify(5dsat) 指定要更改密码的用户必须首先提供正确的现有密码，然后才能替换密码。有关如何修改密码的示例，请参见当 pwdSafeModify 为 TRUE 时从命令行修改密码。可以使用 pwdInHistory(5dsat) 指定目录服务器记住的密码个数，以阻止用户重复使用相同的密码。也可以通过设置 pwdMinAge(5dsat) 来阻止用户过于频繁地更改密码。
在许多情况下，您（管理员）或者您管理的应用程序会在目录中创建用户条目。您可以指定在用户首次绑定到新帐户时要更改的用户密码值。您可能还必须重置用户密码，重置密码后，用户在下次使用该帐户时应该更改密码。目录服务器具有特定属性 pwdMustChange(5dsat)，可以使用该属性指示当其他用户重置密码值后，用户是否必须更改密码。
还可以指定当目录管理者通过设置 passwordRootdnMayBypassModsChecks(5dsat) 更改密码时，可以不必遵循策略。
密码内容策略
本部分介绍用于管理密码内容的策略属性。
虽然一般不会在目录搜索中返回密码值，但攻击者仍有可能获取对目录数据库的访问权限。因此，密码值一般以某种受支持的散列格式（使用 passwordStorageScheme(5dsat) 指定）存储。
还可以通过设置 pwdCheckQuality(5dsat) 来强制检查密码是否满足最低密码质量的定义。然后，服务器会检查密码是否与任何 cn、givenName、mail、ou、sn 或 uid 属性值不匹配。密码与其中任何属性之间的比较不区分大小写。
可以在设置了 pwdCheckQuality(5dsat) 的情况下进行其他检查。可以通过设置 pwdMinLength(5dsat) 来强制密码至少包含指定数目的字符。此外，启用严格密码检查插件时，目录服务器还会检查密码是否不包含该插件所使用的字典文件中的字符串。服务器也会检查密码是否包含不同类型字符的正确组合。
可以使用 dsconf set-server-prop 命令启用严格密码检查。可以使用 pwd-strong-check-enabled 属性打开插件，然后重新启动服务器以使更改生效。可以使用 pwd-strong-check-require-charset 属性指定密码所需的字符集。pwd-strong-check-require-charset 属性使用以下值的掩码：
- lower
-
新密码必须包含小写字符。
- upper
-
新密码必须包含大写字符。
- digit
-
新密码必须包含数字。
- special
-
新密码必须包含特殊字符。
- any-two
-
新密码必须至少包含上述字符集中的两种，每种至少包含一个字符。
- any-three
-
新密码必须至少包含上述字符集中的三种，每种至少包含一个字符。
pwd-strong-check-require-charset 属性的默认设置为 lower && upper && digit && special。
密码过期策略
本部分介绍用于管理密码过期的策略属性。
要确保用户定期更改密码，可以通过设置 pwdMaxAge(5dsat)，将目录服务器配置为当密码达到特定存留期后将密码设置为过期。
必须通知用户其密码即将过期。可以将目录服务器配置为返回一个警告，指明用于绑定的密码即将过期。可以使用 pwdExpireWarning(5dsat) 定义在过期之前多久将会在客户端进行绑定时返回警告。请注意，客户端应用程序将收到该警告。用户不会直接收到警告。客户端应用程序在收到密码即将过期的警告时必须通知最终用户。
通过设置 pwdGraceAuthNLimit(5dsat)，可允许用户使用过期密码进行一次或多次绑定尝试。因此，未能及时更改密码的用户仍可以进行绑定以更改密码。请注意，当用户使用宽限登录进行绑定时，该用户可以执行任何操作。宽限登录的工作方式就像密码尚未过期一样。
每次修改条目上的密码时，目录服务器都会更新操作属性 pwdChangedTime(5dsat)。因此，如果您准备启用密码过期，则已超过存留期限的用户密码会在您启用密码过期后立即过期。如果您不希望发生这种情况，请使用警告和宽限登录。
跟踪上次验证时间的策略
本部分介绍密码策略属性 pwdKeepLastAuthTime(5dsat) 的使用。
设置 pwdKeepLastAuthTime 之后，目录服务器将在每次用户验证时跟踪上次成功绑定的时间。此时间记录在用户条目的 pwdLastAuthTime(5dsat) 操作属性上。
由于此行为会为每次成功的绑定操作添加更新，因此在默认情况下不会激活 pwdKeepLastAuthTime 功能。您必须明确打开此功能才能在部署中使用。
用于定义密码策略的工作单
此工作单旨在帮助您通过命令行界面或使用目录服务控制中心 (Directory Service Control Center, DSCC) 定义要实现的密码策略。请为每个密码策略使用一个工作单。
记录密码策略条目的 DN 之后，请记录与每个策略范围中的属性设置有关的决策。另外，请记录使用这些设置的理由。
|
密码策略工作单 |
|---|
|
密码策略条目标识名 |
|
dn: cn= |
|
策略范围 |
属性 |
在此处填写您的设置 |
在此处填写使用这些设置的理由 |
|---|---|---|---|
|
帐户锁定 | |||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
密码更改 |
|
|
|
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
密码内容 |
|
|
|
|
|
|
||
|
密码过期 |
|
|
|
|
|
|
||
|
|
|
||
|
跟踪上次验证时间 |
|
|
注 –
将 pwdCheckQuality 属性设置为 2 时，服务器可以执行其他检查。如果还启用了密码检查插件，则该插件的设置将影响对新密码值执行哪些检查。
管理默认密码策略
默认密码策略将应用于目录实例中未定义专用策略的所有用户。但是，默认密码策略不会应用于目录管理员。有关策略范围的详细信息，请参见应用哪个密码策略。
默认密码策略是可以使用 dsconf 命令进行配置的策略。还可以通过读取 cn=Password Policy,cn=config 查看默认密码策略。
本部分显示了每个策略范围的策略属性以及相关的 dsconf 服务器属性。此外，还介绍了如何查看和更改默认密码策略设置。
密码策略属性和 dsconf 服务器属性之间的关联
下表显示了每个密码策略范围的密码策略属性和相关的 dsconf 服务器属性。
|
策略范围 |
策略属性 |
dsconf 服务器属性 |
|---|---|---|
|
帐户锁定 |
pwdFailureCountInterval |
pwd-failure-count-interval |
|
pwdLockout |
pwd-lockout-enabled |
|
|
pwdLockoutDuration |
pwd-lockout-duration |
|
|
pwdMaxFailure |
pwd-max-failure-count |
|
|
密码更改 |
passwordRootdnMayBypassModsChecks |
pwd-root-dn-bypass-enabled |
|
pwdAllowUserChange |
pwd-user-change-enabled |
|
|
pwdInHistory |
pwd-max-history-count |
|
|
pwdMinAge |
pwd-min-age |
|
|
pwdMustChange |
pwd-must-change-enabled |
|
|
pwdSafeModify |
pwd-safe-modify-enabled |
|
|
密码内容 |
pwdCheckQuality |
pwd-check-enabled、pwd-accept-hashed-password-enabled、pwd-strong-check-dictionary-path、pwd-strong-check-enabled、pwd-strong-check-require-charset |
|
pwdMinLength |
pwd-min-length |
|
|
passwordStorageScheme |
pwd-storage-scheme |
|
|
密码过期 |
pwdExpireWarning |
pwd-expire-warning-delay |
|
pwdGraceAuthNLimit |
pwd-grace-login-limit |
|
|
pwdMaxAge |
pwd-max-age |
|
|
跟踪上次验证时间 |
pwdKeepLastAuthTime |
pwd-keep-last-auth-time-enabled |
注 –
与 pwdCheckQuality 相关的属性可用于配置密码检查插件。因此，这五种属性适用于整个服务器实例，从而也适用于包含 pwdCheckQuality: 2 的其他密码策略。
查看默认密码策略设置
可以使用 dsconf 命令查看默认密码策略设置。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
更改默认密码策略设置
可以通过使用 dsconf 命令设置服务器属性来更改默认密码策略。
注 –
在完成此过程之前，请阅读并完成用于定义密码策略的工作单。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
管理专用密码策略专用密码策略是在 pwdPolicy(5dsoc) 条目中定义的。可以在目录树中的任意位置定义策略，通常在使用策略所管理的帐户复制的子树中定义。策略的 DN 采用 cn=policy name,subtree 格式。
定义密码策略之后，可以通过在所需的用户条目中设置 pwdPolicySubentry(5dsat) 属性来指定该密码策略。
本部分包含以下主题：
应用哪个密码策略
目录服务器允许您配置多个密码策略。本部分介绍默认密码策略和专用密码策略。本部分还介绍当多个密码策略可应用于给定帐户时应执行哪个策略。
首次创建目录服务器实例时，该实例有一个默认密码策略。默认密码策略在配置条目 cn=PasswordPolicy,cn=config 中表示。默认密码策略将应用于目录中除目录管理员之外的所有帐户。
与所有目录服务器密码策略一样，cn=PasswordPolicy,cn=config 包含对象类 pwdPolicy(5dsoc) 和对象类 sunPwdPolicy(5dsoc)。
注 –
创建目录服务器实例时，密码策略属性仍处于 Directory Server 5 兼容模式，以便从早期版本进行升级。在 Directory Server 5 兼容模式下，目录服务器还会处理具有对象类 passwordPolicy(5dsoc) 的密码策略条目。
在升级完成后，可以在完整功能模式下使用新的密码策略，如《Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide》中所述。管理上的变化对目录应用程序没有任何影响。
本章介绍使用新密码策略功能的密码策略配置。
可以更改默认密码策略以覆盖默认设置。可以使用 dsconf(1M) 命令设置默认密码策略的服务器属性。通常，此类服务器属性的名称都以 pwd- 前缀开头。更改此类属性的设置时，将覆盖实例的默认密码策略。但是，复制操作不会复制对副本所做的更改。对默认密码策略所做的更改是实例配置的一部分，而不是目录数据的一部分。
除了配置默认密码策略以外，还可以配置专用密码策略。专用密码策略是由目录树中的条目定义的。专用密码策略条目与默认密码策略具有相同的对象类 pwdPolicy(5dsoc)，因此将使用相同的策略属性。由于专用密码策略是常规的目录条目，因此策略条目的复制方式与常规目录条目的复制方式相同。
用户条目可通过操作属性 pwdPolicySubentry(5dsat) 的值来引用专用密码策略。用户条目引用专用密码策略时，该专用密码策略将覆盖实例的默认密码策略。在许多部署中，您需要指定用户角色。通过设置 pwdPolicySubentry 值，可以将角色配置为与服务类 (Class of Service, CoS) 一起使用，以确定应用于用户帐户的密码策略。要覆盖由角色设置的密码策略，请直接在该用户的条目上更改 pwdPolicySubentry 值。
下面对本部分内容进行一下总结：最初将应用默认密码策略。 您可以更改默认密码策略以覆盖默认值。然后，您可以创建专用密码策略条目以覆盖默认密码策略。使用角色和 CoS 指定密码策略时，可以通过为单个条目指定密码策略来覆盖 CoS 指定的策略。
创建密码策略
可以使用与创建和修改其他目录条目相同的方式来创建和修改专用密码策略。以下过程说明如何使用文本编辑器在 LDIF 中编写密码策略条目。接下来，可以在 ldapmodify 命令中使用 -a 选项将该密码策略条目添加到目录。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
开始之前
如果没有特殊说明，此处显示的示例数据均来自 Example.ldif。
另请参见
要指定您所定义的策略将要管理的用户帐户，请参见为单个帐户指定密码策略或使用角色和 CoS 指定密码策略。
为单个帐户指定密码策略
此过程将为单个用户帐户指定现有的密码策略。
注 –
要完成此过程，您必须具有要指定的专用密码策略。请参见创建密码策略。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
如果没有特殊说明，此处显示的示例数据均来自 Example.ldif。
使用角色和 CoS 指定密码策略
此过程通过应用角色和服务类 (Class of Service, CoS) 为一组用户指定现有的专用密码策略。有关角色和 CoS 的详细信息，请参见第 9 章，目录服务器组、角色和 CoS。
注 –
要完成此过程，您必须具有要指定的专用密码策略。请参见创建密码策略。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
如果没有特殊说明，此处显示的示例数据均来自 Example.ldif。
设置首次登录密码策略
在许多部署中，应用于新帐户的密码策略与应用于已建帐户的密码策略不同。本部分介绍首次登录密码策略。此策略为用户提供三天时间使用新建帐户并设置新密码，之后将锁定该帐户。对于已重置密码的用户而言，此策略的工作方式相同。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
示例 7–1 检查密码策略指定
请添加与所添加的角色相符的新用户。添加用户是为了验证新用户是否遵循新的密码策略，而现有用户不会遵循该策略。
$ cat quentin.ldif dn: uid=qcubbins,ou=People,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: qcubbins givenName: Quentin sn: Cubbins cn: Quentin Cubbins mail: quentin.cubbins@example.com userPassword: ch4ngeM3! description: New account $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f quentin.ldif Enter bind password: adding new entry uid=qcubbins,ou=People,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - \ -b dc=example,dc=com uid=qcubbins nsrole pwdPolicySubentry Enter bind password: version: 1 dn: uid=qcubbins,ou=People,dc=example,dc=com nsrole: cn=first login role,ou=people,dc=example,dc=com pwdPolicySubentry: cn=First Login,dc=example,dc=com $ ldapsearch -b dc=example,dc=com uid=bjensen nsrole pwdPolicySubentry version: 1 dn: uid=bjensen, ou=People, dc=example,dc=com $
请注意，Barbara Jensen 的现有帐户由默认密码策略管理。但是，Quentin Cubbins 的新帐户将由您定义的密码策略管理。
当 为 时从命令行修改密码
用户的密码策略将 pwdSafeModify 设置为 TRUE 时，必须同时提供旧密码和新密码才能更改密码。命令 dsconf set-server-prop pwd-safe-modify-enabled:on 对默认密码策略具有相同的效果。
可以使用 ldappasswd(1) 命令更改密码。此命令支持安全密码修改。此命令将执行 RFC 3062（）
可以使用 ldapmodify(1) 命令更改密码。此时向 ldapmodify 命令传递的 LDIF 应如下所示：
dn: DN of user whose password you are changing changetype: modify delete: userPassword userPassword: old password - add: userPassword userPassword: new password
还可以使用 LDAP 密码修改扩展操作。使用密码修改扩展操作重置密码中介绍了如何设置扩展操作支持。
重置已过期的密码密码策略执行密码过期时，某些用户可能未及时更改密码。本部分说明如何更改已过期的密码。
注 –
每次修改条目上的密码时，目录服务器都会更新操作属性 pwdChangedTime(5dsat)。因此，如果您准备启用密码过期，则已超过存留期限的用户密码会在您启用密码过期后立即过期。如果您不希望发生这种情况，请使用警告和宽限登录。
本部分包含使用密码修改扩展操作重置密码以及在密码过期时允许宽限验证的过程。
本部分介绍的机制可供管理员使用，或者供处理用户与目录之间实际交互的应用程序使用。通常，您需要依赖于应用程序来确保最终用户使用机制的方式实际上与预期相同。
使用密码修改扩展操作重置密码
密码过期时用户帐户将被锁定。重置密码时，将对帐户解除锁定。其他用户（如管理员）可以重置密码。重置密码后，目录服务器将对用户帐户解除锁定。目录服务器提供 RFC 3062（）支持。可以使用扩展操作允许目录管理者或目录应用程序通过密码重置对帐户解除锁定。
允许使用密码修改扩展操作时应特别谨慎，如以下过程所示。请仅为您所信任的管理员和应用程序授予访问权限。请勿以明文形式在网络中传送密码。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
在密码过期时允许宽限验证
此过程介绍如何为用户提供宽限验证，以允许用户更改已过期的密码。
宽限验证应该由处理密码策略请求和响应控制的应用程序进行管理。此过程说明了一个简单示例，即如何在应用程序中使用此类控制。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
设置帐户属性以下部分介绍了如何设置帐户的浏览限制、大小限制、时间限制以及空闲超时。
设置帐户的浏览限制
设置帐户的大小限制
设置帐户的时间限制
设置帐户的空闲超时
手动锁定帐户目录服务器允许您将密码策略配置为在进行指定次数的失败绑定尝试后锁定帐户。有关详细信息，请参见帐户锁定策略。本部分介绍目录管理员可以使用的手动帐户锁定和激活工具。
目录管理员可以在不使用锁定持续时间计时器的情况下管理帐户锁定。在手动重置密码之前，锁定的帐户将保持锁定状态。目录管理员还可以无限期地停用某些帐户。
本部分说明如何检查帐户状态、停用帐户以及重新激活帐户。
检查帐户状态
请按以下所述检查帐户状态。
注 –
您必须以目录管理员身份进行绑定。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
停用帐户
请按以下所述停用帐户或角色。
注 –
您必须以目录管理员身份进行绑定。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
重新激活帐户
请按以下所述对帐户或角色解除锁定。
注 –
您必须以目录管理员身份进行绑定。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
第 8 章 目录服务器备份和恢复目录服务器所管理的数据通常是批量导入的。Directory Server Enterprise Edition 提供了用于导入和导出整个后缀的工具。此外，它还提供了用于同时备份所有后缀以及从备份恢复所有数据的工具。
在开始执行任何备份或恢复操作之前，请确保设计一个符合您自身要求的备份和恢复策略。有关不同备份选项、要考虑的注意事项以及规划备份和恢复策略的准则的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中的“Designing Backup and Restore Policies”。
本章包含以下主题：
二进制备份本部分介绍如何执行目录数据的二进制备份。除了本部分介绍的二进制备份过程之外，您还可以创建二进制副本，用于初始化复制拓扑中的后缀。请参见使用二制进副本初始化复制后缀。
仅备份目录数据
二进制数据备份可保存目录数据的副本，以备将来数据库文件损坏或被删除时使用。此操作不会备份配置数据。如果您要备份整个目录服务器以用于灾难恢复，请参见灾难恢复。
注意 –
切勿在备份操作期间停止服务器。
执行备份的频率必须高于清除延迟。清除延迟由 nsDS5ReplicaPurgeDelay 属性指定，它是以秒为单位的时间段，系统将在该时间段过后对更改日志执行内部清除操作。默认的清除延迟为 604800 秒（1 周）。更改日志用于维护更新记录（此更新可能已被复制或尚未复制）。
如果执行备份的频率低于清除延迟，则更改日志可能会在备份前就已被清除。因此，如果使用备份恢复数据，更改将会丢失。
默认情况下，本部分介绍的所有备份过程都会将服务器文件的副本存储在相同的主机上。您应该将备份复制并存储到不同的计算机或文件系统中，以获得更高的安全性。
备份目录数据
必须停止目录服务器才能运行 dsadm backup 命令。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
备份 dse.ldif 文件
恢复服务器时，dse.ldif 配置文件必须包含与备份服务器时相同的配置信息。
备份文件系统
此过程将使用冻结模式功能。冻结模式允许您停止磁盘上的数据库更新，以便安全地实施文件系统快照。可以将冻结模式作为一种附加措施，以确保执行可靠的备份。
正在执行文件系统备份时，服务器不能在磁盘上写入用户数据。如果确定在某个时间范围内不会进行更新，请在此时间段进行备份。如果您无法确定是否会发生更新，请在备份前将服务器置于冻结模式。
在冻结模式下，服务器将继续在访问日志和错误日志中写入数据。在单服务器拓扑中，冻结模式下收到的操作将导致返回 LDAP 错误。对于处于脱机状态的数据库，所记录的错误消息为标准错误。在复制拓扑中将返回引用。为了使冻结模式正确工作，不应该在数据库上运行其他任务。
请注意，在冻结模式下，服务器数据库比只读模式更稳定。与冻结模式不同，只读模式允许创建任务和修改配置条目。打开冻结模式后，所有已配置的数据库都将处于脱机状态。所有正在进行的内部操作都将获得数据库即将进入脱机状态的通知。将完成正在进行的 LDAP 操作，并会刷新数据库环境。后续的传入操作（包括搜索用户数据）将被拒绝，直到关闭冻结模式时为止。但是，在冻结模式下仍可搜索配置参数。
备份文件系统
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
备份到 LDIF备份到 LDIF 允许您将目录数据备份到格式化的 LDIF 文件。
导出到 LDIF
可以通过使用 LDIF 导出后缀内容来备份目录数据。执行以下操作时，导出数据非常有用：
-
在您的服务器中备份数据
-
将数据复制到其他目录服务器
-
将数据导出到其他应用程序
-
更改目录拓扑后重新填充后缀
导出操作不会导出配置信息 ( cn=config)。
注意 –
不要在执行导出操作期间停止服务器。
将后缀导出到 LDIF
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
二进制恢复以下过程介绍如何在目录中恢复后缀。必须已经使用仅备份目录数据中所述的过程备份了服务器。在恢复复制协议中所涉及的后缀之前，请先阅读恢复复制的后缀。
注意 –
不要在执行恢复操作期间停止服务器。由于恢复服务器会覆盖所有现有的数据库文件，因此自备份以来对数据所做的所有修改都会丢失。
恢复服务器
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
恢复 dse.ldif 配置文件
目录服务器将在下面的目录中创建 dse.ldif 文件的两个备份副本：
instance-path/config
dse.ldif.startOK 文件将在服务器启动时记录 dse.ldif 文件的副本。dse.ldif.bak 文件包含最近对 dse.ldif 文件所做更改的备份。请将包含最近更改的文件复制到您的目录中。
恢复 dse.ldif 配置文件
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
从 LDIF 文件导入数据可以使用以下方法将数据导入到目录服务器后缀中：
-
从 LDIF 文件初始化后缀。此操作将删除后缀中的当前数据，并将其替换为该 LDIF 文件的内容。
-
使用 LDIF 文件执行批量的 ldapadd、ldapmodify 或 ldapdelete 操作。这样您可以在目录的任何后缀中批量添加、修改和删除条目。
下表显示了初始化后缀与批量添加、修改和删除条目之间的区别。
表 8–1 比较初始化后缀和批量导入数据|
比较范围 |
初始化后缀 |
批量添加、修改和删除条目 |
|---|---|---|
|
覆盖内容 |
覆盖 内容 |
不覆盖内容 |
|
仅添加 |
添加、修改和删除 |
|
|
性能 |
快 |
较慢 |
|
对服务器故障的响应 |
响应能力极差（发生故障后会丢失所有更改） |
响应能力最强（将保留故障发生以前的所有更改） |
|
LDIF 文件位置 |
客户端本地或服务器本地 |
在客户机上 |
|
导入配置信息 (cn=config) |
导入配置信息 |
不导入配置信息 |
|
命令 |
服务器为本地服务器并且已停止时： dsadm import 服务器为远程服务器并且正在运行时： dsconf import |
ldapmodify -B |
初始化后缀
初始化后缀会使用 LDIF 文件（仅包含用于添加的条目）的内容覆盖后缀中的现有数据。
要初始化后缀，您必须以目录管理员或管理者身份通过验证。
服务器正在运行时，只有目录管理员和管理者才能导入包含根条目的 LDIF 文件。出于安全考虑，只有这些用户才能访问后缀的根条目，例如 dc=example,dc=com.。
在恢复复制协议中所涉及的后缀之前，请先阅读恢复复制的后缀。
初始化后缀
注 –
您所导入的所有 LDIF 文件都必须使用 UTF-8 字符集编码。
在初始化后缀时，LDIF 文件必须包含相应后缀的根条目和所有目录树节点。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
批量添加、修改和删除条目
执行 ldapmodify 操作时，可以批量添加、修改或删除条目。这些条目是在 LDIF 文件指定的，该文件包含用于修改或删除现有条目的更新语句。此操作不会删除已经存在的条目。
目录服务器所管理的任何后缀都有可能成为更改条目的目标。与添加条目的任何其他操作一样，服务器在导入新条目时会为所有新条目编制索引。
ldapmodify 命令通过 LDAP 导入 LDIF 文件，并执行该文件中包含的所有操作。使用此命令，可以同时修改所有目录后缀中的数据。
在恢复复制协议中所涉及的后缀之前，请参见恢复复制的后缀。
批量添加、修改和删除条目
注 –
您所导入的所有 LDIF 文件都必须使用 UTF-8 字符集编码。
导入 LDIF 文件时，目录中必须存在父条目，或者必须先从该文件中添加父条目。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
恢复复制的后缀对于在提供方服务器和使用方服务器之间复制的后缀，在恢复之前需要注意一些特殊事项。请尽可能通过复制机制（而不是通过从备份恢复后缀）来更新后缀。
恢复提供方或集线器实例时，服务器配置必须与创建备份时的配置相同。要确保这一点，请在恢复目录服务器数据之前先恢复 dse.ldif 文件。请参见恢复 dse.ldif 配置文件。
本部分介绍如何、何时恢复副本，以及如何确保副本在恢复后与其他副本同步。要初始化副本，请参见初始化副本。
如果您有大型的复制后缀并要添加许多条目，同时要确保正确添加复制更新，请参见逐渐向大型复制后缀添加大量条目。
本部分包含与以下内容有关的信息：
在单主方案中恢复提供方
作为单主提供方的后缀包含整个复制拓扑的授权数据。因此，恢复此后缀等同于重新初始化整个拓扑中的所有数据。只有在使用要恢复的备份内容重新初始化所有数据时，才应恢复单主提供方。
如果单主数据由于错误而无法恢复，请考虑使用某个使用方上的数据，因为它可能包含比备份还新的更新。在这种情况下，您需要将使用方副本中的数据导出到 LDIF 文件，然后从该 LDIF 文件重新初始化主服务器。
无论您在主副本上恢复备份还是导入 LDIF 文件，都必须重新初始化从此副本接收更新的所有集线器和使用方副本。在提供方服务器的日志文件中将记录一条消息，以提醒您必须对使用方进行重新初始化。
在多主方案中恢复提供方
在多主复制中，其他每个主服务器都包含复制数据的授权副本。您无法恢复旧的备份，因为该备份对于当前的副本内容可能已经过时。如有可能，应允许复制机制使用其他主服务器的内容来更新主服务器。
如果无法执行此操作，请使用以下任一方法恢复多主副本：
无论您以何种方式恢复或重新初始化，主副本在初始化后都仍然保持只读模式。此行为可使副本与其他主服务器进行同步，以便您在同步后允许执行写入操作，如在多主方案中恢复主服务器中所述。
在已恢复或重新初始化的主服务器上允许执行写入操作之前一致所有副本的好处在于，所有集线器或使用方服务器都不需要重新初始化。
恢复集线器
本部分仅适用于复制机制无法自动更新集线器副本的情况。数据库文件损坏或复制中断时间过长都属于这种情况。在这些情况下，您需要使用以下任一方法恢复或重新初始化集线器副本：
-
最简单的方法不是恢复备份，而是从某个主副本重新初始化集线器。这可以确保将最新数据发送到集线器，并且该数据可用于复制。请参见初始化后缀。
-
对于具有数百万条目的副本，较快的做法是创建二进制副本，以恢复来自其他集线器复制后缀的较新备份。请参见使用二制进副本初始化复制后缀。如果没有需要复制的其他集线器副本，请按照上一条的描述重新初始化集线器，或者按照下一条的描述恢复集线器（如有可能）。
-
如果集线器备份的存留期不长于其他任何提供方（集线器或主副本）上更改日志内容的最长存留期，则可使用该备份恢复此集线器。恢复集线器之后，提供方将使用其更改日志中自保存该备份以来进行的所有修改来更新此集线器。
注 –
无论您以何种方式恢复或重新初始化集线器副本，接下来都必须重新初始化此集线器的所有使用方，包括所有其他级别的集线器。
恢复专用使用方
本部分仅适用于复制机制无法自动更新专用使用方副本的情况。数据库文件损坏或复制中断时间过长都属于这种情况。在这些情况下，您需要使用以下任一方法恢复或重新初始化使用方：
-
最简单的方法不是恢复备份，而是从某个提供方（主服务器或集线器副本）重新初始化使用方。这可以确保将最新数据发送到使用方，并且该数据可用于复制。请参见从 LDIF 进行副本初始化。
-
对于具有数百万条目的副本，较快的做法是创建二进制副本，以恢复来自其他使用方复制后缀的较新备份。请参见使用二制进副本初始化复制后缀。如果没有需要复制的其他使用方，请按照上一条的描述重新初始化副本，或者按照下一条的描述恢复副本（如有可能）。
-
如果使用方备份的存留期不长于其他任何提供方（集线器或主副本）上更改日志内容的最长存留期，则可使用该备份恢复此使用方。恢复使用方之后，提供方将使用其更改日志中自保存该备份以来进行的所有修改来更新此使用方。
在多主方案中恢复主服务器
使用多主复制时，其他主服务器可能会在给定主服务器恢复期间处理更改操作。因此，完成恢复操作之后，新的主服务器还必须接收恢复数据中未包含的较新更新。由于恢复主服务器可能需要大量时间，因此挂起的更新数也可能十分庞大。
为了一致这些挂起的更新，新恢复的主服务器将自动设置为只读模式，以便在恢复后执行客户端操作。此情况仅在通过以下方式恢复主服务器时适用：使用命令行从 LDIF 文件导入数据，或者使用备份执行二进制复制。
因此，在完成恢复操作之后，多主配置中的主服务器将处理复制更新并允许执行读取操作，但是对于来自客户端的所有写入操作将返回引用。
要在允许更新前验证新的主服务器是否与其他主服务器完全同步，请在已初始化的主服务器上手动启用更新。
注 –
由于主副本会因为上述新行为而发送引用，因此等待执行写入操作的客户端可能会达到配置的跳数限制。您可能需要提高客户端的跳数限制配置，以使其能够访问可用的主服务器。如果已初始化或重新初始化所有主副本，则所有写入操作都会失败，因为所有副本都不会接受客户端更新。
在任何情况下，都应密切监视已初始化的主服务器，并适当地设置引用属性，以尽可能提高服务器的响应能力。
通过命令行开始接受更新
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
可以在脚本中使用以下命令，以便自动执行多主副本的初始化过程：
灾难恢复如果要备份或恢复目录服务器以用于灾难恢复，请使用以下过程。
创建备份以用于灾难恢复
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
进行灾难恢复
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
第 9 章 目录服务器组、角色和 CoS管理代表用户的条目时，除了在目录中使用数据的分层结构之外，通常还需要创建共享公用属性值的组。目录服务器通过组、角色和服务类 (Class of Service, CoS) 提供了高级条目管理功能。
本章包含以下主题：
关于组、角色和服务类组、角色和 CoS 的定义如下：
-
组是指定其他条目（成员列表或成员过滤器）的条目。对于由成员列表构成的组，目录服务器将在每个用户条目上生成 isMemberOf 属性值。因此，用户条目上的 isMemberOf 属性将显示该条目所属的所有组。
-
角色可以提供与组相同的功能，并且还会通过某种机制在每个角色成员上生成 nsrole 属性。
-
CoS 会生成已计算属性，它允许条目共享公用属性值，而不必在每个条目中存储属性。
无法使用 isMemberOf 属性使静态组的所有成员自动继承公用的已计算属性值。
目录服务器可以基于角色、组和 CoS 已计算属性的值来执行搜索。任何操作中使用的过滤字符串都可以包含 nsRole 属性或由 CoS 定义生成的任何属性。还可以使用过滤字符串对此属性的值执行任何比较操作。但是无法为 CoS 已计算属性编制索引。因此，涉及 CoS 已生成属性的任何搜索都可能会消耗大量资源（从时间和内存上）。
为了充分利用角色、组和服务类所提供的功能，请在目录部署的规划阶段确定分组策略。有关这些功能及其如何简化拓扑的描述，请参阅《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中的“Grouping Directory Data and Managing Attributes”。
要想更深入地了解角色和组的工作方式，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中的第 8 章 “Directory Server Groups and Roles”。有关 CoS 的详细描述，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中的第 9 章 “Directory Server Class of Service”。
管理组通过使用组，您可以关联条目以简化管理。例如，使用组可以更轻松地定义访问控制指令 (Access Control Instruction, ACI)。组定义是一些特殊条目，可以在静态列表中指定其成员，也可以提供用于定义一组动态条目的过滤器。
无论组定义条目的位置如何，组的可能成员范围都是整个目录。为了简化管理，所有组定义条目通常都存储在一个位置，一般是根后缀下的 ou=Groups。
组可以分为静态组和动态组两种类型。
创建新的静态组
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
创建新的动态组
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
管理角色角色是一种备用组机制，在设计上可以使应用程序使用起来更加轻松有效。虽然角色的定义和管理方式与组类似，但是每个成员条目中生成的角色属性将自动表示条目的角色。例如，应用程序可以读取条目的角色，而不必选择组并浏览成员列表。
默认情况下，角色的范围被限定为定义该范围时所在的子树。但是，您可以扩展嵌套角色的范围。可以允许范围嵌套其他子树中的角色，并包含位于目录中任意位置的成员。有关详细信息，请参见扩展角色的范围和嵌套角色定义的示例。
本部分介绍如何安全地使用角色，以及如何从命令行管理角色。
安全地使用角色
要安全地使用角色，必须设置访问控制指令 (Access Control Instruction, ACI) 以保护相应的属性。例如，用户 A 具有受管理角色 MR。受管理角色相当于静态组，通过将 nsRoleDN 属性添加到每个成员条目来为该条目明确指定角色。已通过命令行使用帐户去活锁定了 MR 角色。这意味着用户 A 无法绑定到服务器，因为该用户 nsAccountLock 属性的计算结果为 "true"。但是，假定该用户已经绑定，并发现自己现在因 MR 角色而被锁定。如果没有相应的 ACI 来阻止用户具有 nsRoleDN 属性的写入访问权限，则该用户可以从自己的条目中删除 nsRoleDN 属性并解除锁定。
要阻止用户删除 nsRoleDN 属性，必须应用 ACI。使用过滤角色时，必须保护过滤器中可阻止用户通过修改属性放弃过滤角色的部分。应禁止用户添加、删除或修改过滤角色所使用的属性。同理，如果已计算过滤属性的值，则必须保护可以修改过滤属性值的所有属性。由于嵌套角色可以包含过滤角色和受管理角色，因此对于嵌套角色中包含的每个角色，都应考虑上述几点。
有关设置 ACI 以获得安全性的详细说明，请参见第 6 章，目录服务器访问控制。
从命令行管理角色
角色是在目录管理者可以通过命令行实用程序访问的条目中定义的。创建角色之后，可按以下方式为角色指定成员：
-
受管理角色的成员在条目中具有 nsRoleDN 属性。
-
过滤角色的成员是与 nsRoleFilter 属性中所指定的过滤器相匹配的条目。
-
嵌套角色的成员是嵌套角色定义条目的 nsRoleDN 属性中所指定的角色的成员。
所有角色定义都是从 LDAPsubentry 和 nsRoleDefinition 对象类继承来的。以下示例显示了特定于每类角色的其他对象类和关联属性。
受管理角色定义的示例
要为所有营销人员创建角色，请使用以下 ldapmodify 命令：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsSimpleRoleDefinition objectclass: nsManagedRoleDefinition cn: Marketing description: managed role for marketing staff
请注意，nsManagedRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsSimpleRoleDefinition 对象类继承来的。
通过更新营销人员 Bob 的条目，可以为该成员指定角色，如下所示：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Bob Arnold,ou=marketing,ou=People,dc=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com
nsRoleDN 属性指示该条目是受管理角色的成员。受管理角色由角色定义的 DN 标识。要允许用户修改自己的 nsRoleDN 属性，但阻止用户添加或删除 nsManagedDisabledRole，请添加以下 ACI：
aci: (targetattr="nsRoleDN")(targattrfilters="add=nsRoleDN: (!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example, dc=com)") (version3.0;aci "allow mod of nsRoleDN by self except for critical values"; allow(write) userdn="ldap:///self";)
过滤角色定义的示例
要为销售经理设置过滤角色（假定这些销售经理都具有 isManager 属性），请使用以下ldapmodify 命令：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerFilter nsRoleFilter: (isManager=True) Description: filtered role for sales managers
请注意，nsFilteredRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类继承来的。nsRoleFilter 属性会指定一个过滤器，用于查找 ou=sales 组织中拥有下属的所有员工，例如：
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)" dn: cn=Carla Fuentes,ou=sales,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE... nsRole: cn=ManagerFilter,ou=sales,ou=People, dc=example,dc=com
注 –
过滤角色的过滤字符串可以基于任何属性，由 CoS 机制生成的已计算属性除外。
如果过滤角色成员是用户条目，您可以选择限制他们在角色中添加或删除自身的能力。可以使用 ACI 保护过滤属性。
嵌套角色定义的示例
嵌套在嵌套角色中的角色是通过 nsRoleDN 属性指定的。可以使用以下命令创建一个角色，该角色同时包含前面示例中所创建的营销人员和销售经理角色的成员：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=MarketingSales,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com nsRoleScopeDN: ou=sales,ou=People,dc=example,dc=com
请注意，nsNestedRoleDefinition 对象类是从 LDAPsubentry、nsRoleDefinition 和 nsComplexRoleDefinition 对象类继承来的。nsRoleDN 属性包含营销受管理角色和销售经理过滤角色的 DN。前面示例中的用户 Bob 和 Carla 都将成为此新嵌套角色的成员。
此过滤器的范围包括默认范围（该过滤器所在的子树），以及任何 nsRoleScopeDN 属性值下的子树。在本案例中，ManagerFilter 位于 ou=sales,ou=People,dc=example,dc=com 子树中。必须将此子树添加到该范围。
扩展角色的范围
目录服务器提供了一个属性，该属性允许将角色的范围扩展到角色定义条目的子树之外。此单值属性 nsRoleScopeDN 包含要添加到现有角色的范围的 DN。只能将 nsRoleScopeDN 属性添加到嵌套角色。请参见嵌套角色定义的示例。
扩展角色的范围
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
nsRoleScopeDN 属性允许您扩展某个子树中的角色范围，以包含另一个子树中的条目。例如，假定 example.com 目录树中有两个主要子树：o=eng,dc=example,dc=com（工程子树）和 o=sales,dc=example,dc=com（销售子树）。工程子树中的用户需要访问由销售子树中的角色 (SalesAppManagedRole ) 管理的销售应用程序。要扩展该角色的范围，请执行以下操作：
服务类为客户端应用程序检索到条目时，服务类 (Class of Service, CoS) 机制会生成已计算属性，这可以简化条目管理并降低存储要求。CoS 机制允许在条目之间共享属性，并且与组和角色一样，CoS 也依赖于帮助应用程序条目。
注 –
任何搜索操作都可以测试 CoS 已生成属性是否存在，或者比较属性值。可以在客户端搜索操作的任何过滤字符串中使用已计算属性的名称，过滤角色中使用的内部过滤器除外。
安全地使用 CoS
以下部分介绍每个 CoS 条目中数据读保护和写保护的一般准则。第 6 章，目录服务器访问控制中介绍了定义单个访问控制指令 (Access Control Instruction, ACI) 的详细过程。
保护 CoS 定义条目
虽然 CoS 定义条目不包含已生成属性的值，但它提供了用于查找该值的信息。读取 CoS 定义条目可了解如何查找包含该值的模板条目。对此条目执行写入操作可修改已计算属性的生成方式。
因此，应该为 CoS 定义条目定义读取 ACI 和写入 ACI。
保护 CoS 模板条目
CoS 模板条目包含 CoS 已生成属性的值。因此，模板中的 CoS 属性至少要受到 ACI 的读取和更新保护。
-
如果使用指针 CoS，应禁止重命名单个模板条目。在大多数情况下，最简单的做法就是保护整个模板条目。
-
如果使用传统 CoS，所有模板条目都具有定义条目中所指定的公用父条目。如果父条目中只存储了模板，则对父条目的访问控制将保护这些模板。但是，如果父条目下的其他条目需要访问权限，则必须单个保护模板条目。
-
如果使用间接 CoS，则模板可以是目录中的任何条目，包括仍需访问的用户条目。根据需要，您可以在整个目录中控制对 CoS 属性的访问，或确保 CoS 属性在用作模板的每个条目中都是安全的。
保护 CoS 的目标条目
CoS 定义范围中的所有条目（将为这些条目生成 CoS 已计算属性）都会参与属性值的计算。
默认情况下，当目标条目中已存在 CoS 属性时，CoS 机制不会覆盖此值。如果不希望如此，可以将 CoS 定义为覆盖目标条目，或保护所有潜在目标条目中的 CoS 属性。
间接 CoS 和传统 CoS 还依赖于目标条目中的说明符属性。此属性用于指定要使用的模板条目的 DN 或 RDN。应该使用 ACI 在整个 CoS 范围内全局保护此属性，或者在需要保护的每个目标条目上单独保护此属性。
保护其他相关性
可以根据其他已生成的 CoS 属性和角色来定义 CoS 已计算属性。您必须了解并保护这些相关性，以确保 CoS 已计算属性受到保护。
例如，目标条目中的 CoS 说明符属性可能是 nsRole。因此，角色定义也必须受 ACI 保护。
通常，计算已计算属性值时所用的任何属性或条目都应具有提供读取和写入访问控制的 ACI。因此，应合理规划或简化复杂的相关性，以降低后续访问控制实现的复杂性。将其他已计算属性上的相关性降至最低可提高目录性能并减少维护操作。
从命令行管理 CoS
由于所有配置信息和模板数据都作为条目存储在目录中，因此可以使用 LDAP 命令行工具配置和管理 CoS 定义。本部分说明如何从命令行创建 CoS 定义条目和 CoS 模板条目。
从命令行创建 CoS 定义条目
所有 CoS 定义条目都具有 LDAPsubentry 对象类，并且是从 cosSuperDefinition 对象类继承来的。此外，每种类型的 CoS 都从特定对象类继承而来，并包含相应属性。下表列出了与每种类型的 CoS 定义条目相关联的对象类和属性。
表 9–1 CoS 定义条目中的对象类和属性|
CoS 类型 |
CoS 定义条目 |
|---|---|
|
指针 CoS |
objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDN: DN cosAttribute: attributeName override merge |
|
间接 CoS |
objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: attributeName cosAttribute: attributeName override merge |
|
传统 CoS |
objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDN: DN cosSpecifier: attributeName cosAttribute: attributeName override merge |
cosAttribute 始终为多值属性。每个值都定义一个由 CoS 机制生成的属性。
可以在 CoS 定义条目中使用以下属性。有关其中每个属性的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference》中的各个属性。
表 9–2 CoS 定义条目属性|
属性 |
在 CoS 定义条目中的用途 |
|---|---|
|
cosAttribute attributeName override merge |
定义要生成值的已计算属性的名称。此属性为多值属性，每个值代表将通过模板生成值的属性的名称。override 和 merge 限定符指定在此表后面所述的特殊情况下如何计算 CoS 属性值。 attributeName 不能包含任何子类型。带有子类型的属性名称将被忽略，但会处理 cosAttribute 的其他值。 |
|
cosIndirectSpecifier attributeName |
定义目标条目中属性的名称，间接 CoS 将使用此属性的值标识模板条目。已命名的属性称为说明符，并且必须包含每个目标条目中的完整 DN 字符串。此属性为单值属性，但 attributeName 可以是多值属性，以指定多个模板。 |
|
cosSpecifier attributeName |
定义目标条目中属性的名称，传统 CoS 将使用此属性的值标识模板条目。已命名的属性称为说明符，并且必须包含可以在模板条目 RDN 中找到的字符串。此属性为单值属性，但 attributeName 可以是多值属性，以指定多个模板。 |
|
cosTemplateDN DN |
提供模板条目的完整 DN（对于指针 CoS 定义）或基 DN（对于传统 CoS）。此属性为单值属性。 |
注 –
无法通过将 isMemberOf 属性用作 CosSpecifier，来使静态组的所有成员自动继承公用的已计算属性值。
cosAttribute 属性允许 CoS 属性名称后面有两个限定符，即 override 限定符和 merge 限定符。
override 限定符描述当条目中已实际存在 CoS 动态生成属性时的行为。override 可为以下任一选项：
-
default（或无限定符）- 表示当属性类型与已计算属性相同时，服务器不会覆盖条目中存储的实际属性值。
-
override - 表示服务器始终返回由 CoS 生成的值，即使条目中已存在某个值。
-
operational - 表示只有在搜索中明确请求时才会返回属性。操作属性不必通过模式检查即可返回。operational 限定符与 override 限定符具有相同的行为。
只有在模式中也将某个属性定义为操作属性时，该属性才能成为操作属性。例如，如果 CoS 生成一个 description 属性值，则无法使用 operational 限定符，因为 description 属性在模式中未标记为操作属性。
merge 限定符要么不使用，要么为 merge-schemes 形式。此限定符允许 CoS 已计算属性成为多值属性，这些值可以来自多个模板或多个 CoS 定义 。有关详细信息，请参见多值 CoS 属性。
覆盖实际的属性值
可以创建包含 override 限定符的指针 CoS 定义条目，如下所示：
dn: cn=pointerCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=exampleUS,cn=data cosAttribute: postalCode override
此指针 CoS 定义条目表示条目与生成 postalCode 属性值的模板条目 cn=exampleUS,cn=data 相关联。override 限定符表示此值优先于 postalCode 属性值（如果目标条目中存在该属性）。
注 –
如果 CoS 属性是使用 operational 或 override 限定符定义的，则无法对 CoS 范围内任何条目中的“实际”属性值执行写入操作。
多值 CoS 属性
指定 merge-schemes 限定符时，CoS 已生成属性在以下两种情况下可以成为多值属性：
-
使用间接或传统 CoS 时，目标条目中的说明符属性可以为多值属性。在这种情况下，每个值都确定一个模板，并且每个模板中的值都是生成值的一部分。
-
多个任意类型的 CoS 定义条目可以在 cosAttribute 中包含相同的属性名称。在这种情况下，如果所有定义都包含 merge-schemes 限定符，则生成的属性将包含由每个定义计算的所有值。
这两种情况可以同时发生，并定义更多的值。但是，重复的值只会在生成的属性中返回一次。
如果不使用 merge-schemes 限定符，模板条目的 cosPriority 属性将用于确定已生成属性在所有模板中的单一值。下一部分将介绍此方案。
merge-schemes 限定符永远不会将目标中定义的“实际”值与通过模板生成的值进行合并。merge 限定符独立于 override 限定符。所有配对情况都可能出现，并且每种情况表示的行为是互补的。 此外，还可以在属性名称后按任意顺序指定这些限定符。
注 –
如果同一属性具有多个 CoS 定义，则这些定义必须具有相同的 override 和 merge 限定符。如果 CoS 定义中存在不同的限定符对，将从所有定义中任意选择一种组合。
CoS 属性优先级
如果存在多个 CoS 定义或多值说明符，但未使用 merge-schemes 限定符，目录服务器将使用优先级属性选择用于定义已计算属性单一值的单一模板。
cosPriority 属性表示纳入考虑的所有模板中某一特定模板的全局优先级。优先级为零代表最高优先级。不包含 cosPriority 属性的模板被视为优先级最低。如果两个或两个以上的模板提供一个属性值，但却具有相同的优先级或没有优先级，此时将任意选择一个值。
使用 merge-schemes 限定符时不会考虑模板优先级。在合并时，纳入考虑的所有模板将定义一个值，而不管这些模板定义的优先级如何。cosPriority 属性是在 CoS 模板条目上定义的，如以下部分所述。
注 –
cosPriority 属性不能具有负值。此外，由间接 CoS 生成的属性不支持优先级。不要在间接 CoS 定义的模板条目中使用 cosPriority。
从命令行创建 CoS 模板条目
使用指针 CoS 或传统 CoS 时，模板条目包含 LDAPsubentry 和 cosTemplate 对象类。必须专门为 CoS 定义创建此条目。如果将 CoS 模板条目作为 LDAPsubentry 对象类的实例，可以不受配置条目的限制而执行一般搜索。
间接 CoS 机制的模板是目录中任意的现有条目。不必提前对目标进行标识或为其提供 LDAPsubentry 对象类，但目标必须具有辅助 cosTemplate 对象类。只有将 CoS 评估为生成已计算属性及其值时，才会访问间接 CoS 模板。
CoS 模板条目必须始终包含 CoS 在目标条目上生成的属性和值。属性名称在 CoS 定义条目的 cosAttribute 属性中指定。
以下示例显示了指针 CoS（生成 postalCode 属性）最高优先级的模板条目：
dn: cn=ZipTemplate,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalCode: 95054 cosPriority: 0
以下部分提供了模板条目示例以及每种类型的 CoS 定义条目示例。
指针 CoS 的示例
以下命令创建一个指针 CoS 定义条目，它具有 cosPointerDefinition 对象类。此定义条目使用在上一部分示例中介绍的 CoS 模板条目，以便在 ou=People,dc=example,dc=com 树的所有条目之间共享公用的邮政编码。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=pointerCoS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com cosAttribute: postalCode
CoS 模板条目 (cn=ZipTemplate,ou=People,dc=example,dc=com ) 可将 postalCode 属性中存储的值提供给位于 ou=People,dc=example,dc=com 后缀下的所有条目。如果在同一子树中搜索没有邮政编码的任何条目，您将会看到已生成属性的值：
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... postalCode: 95054
间接 CoS 的示例
间接 CoS 命名 cosIndirectSpecifier 属性中的某个属性，以查找特定于每个目标的模板。间接 CoS 的模板条目可以是目录中的任何条目，包括其他用户条目。此间接 CoS 示例使用目标条目的 manager 属性标识 CoS 模板条目。模板条目是经理的用户条目。经理的用户条目包含要生成的属性的值。在本案例中，该值为 departmentNumber 的值。
以下命令将创建间接 CoS 定义条目，此条目包含 cosIndirectDefinition 对象类：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=generateDeptNum,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
接下来，将 cosTemplate 对象类添加到模板条目，并确保这些条目定义要生成的属性。在此示例中，所有经理条目都是模板：
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Carla Fuentes,ou=People,dc=example,dc=com changetype: modify add: objectclass objectclass: cosTemplate - add: departmentNumber departmentNumber: 318842
使用此 CoS，包含 manager 属性的目标条目（位于 ou=People,dc=example,dc=com 下的条目）将自动包含经理的部门编号。将在目标条目上计算 departmentNumber 属性，因为服务器中不存在该属性。但是，departmentNumber 属性将作为目标条目的一部分返回。例如，如果将 Babs Jensen 的经理定义为 Carla Fuentes，其部门编号如下所示：
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... manager: cn=Carla Fuentes,ou=People,dc=example,dc=com departmentNumber: 318842
传统 CoS 的示例
此示例说明如何使用传统 CoS 生成邮政地址。生成的值是在模板条目中指定的，该模板条目的位置由 CoS 定义中的 cosTemplateDN 和目标条目中的 cosSpecifier 属性值共同确定。以下命令使用 cosClassicDefinition 对象类创建定义条目：
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: ou=People,dc=example,dc=com cosSpecifier: building cosAttribute: postalAddress
使用相同的命令，可以创建提供每栋大楼邮政地址的模板条目：
dn: cn=B07,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalAddres: 7 Old Oak Street, Anytown, CA 95054
使用此 CoS，包含 building 属性的目标条目（位于 ou=People,dc=example,dc=com 下的条目）将自动包含相应的邮政地址。CoS 机制将搜索在 RDN 中具有说明符属性值的模板条目。在此示例中，如果将 Babs Jensen 分配到大楼 B07，则生成的通讯地址如下：
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... building: B07 postalAddress: 7 Old Oak Street, Anytown, CA 95054
创建基于角色的属性
您可以创建传统 CoS 模式，以便为基于条目角色的条目生成属性值。例如，可以使用基于角色的属性将服务器浏览限制设置为逐个条目浏览。
要创建基于角色的属性，请将 nsRole 属性作为传统 CoS 的 CoS 定义条目中的 cosSpecifier。由于 nsRole 属性可以是多值属性，因此可以定义具有多个可能模板条目的 CoS 模式。在确定要使用的模板条目时，为了避免出现模棱两可的情况，可以在 CoS 模板条目中包含cosPriority 属性。
例如，可以创建一个允许经理角色成员超过标准邮箱配额的 CoS。该经理角色如下：
dn: cn=ManagerRole,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerRole nsRoleFilter: (isManager=True) Description: filtered role for managers
传统 CoS 定义条目的创建方式如下：
dn: cn=generateManagerQuota,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=managerCOS,ou=People,dc=example,dc=com cosSpecifier: nsRole cosAttribute: mailboxquota override
CoS 模板名称必须是 cosTemplateDn 和 nsRole 值（角色的 DN）的组合。例如：
dn:cn="cn=ManagerRole,ou=People,dc=example,dc=com",\ cn=managerCOS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate mailboxquota: 1000000
CoS 模板条目提供了 mailboxquota 属性值。附加的限定符 override 指示 CoS 覆盖目标条目中的任何现有 mailboxquota 属性值。属于该角色的目标条目将具有由该角色和 CoS 生成的已计算属性，例如：
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -\ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)" dn: cn=Carla Fuentes,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE...nsRole: cn=ManagerRole,ou=People,dc=example,dc=com mailboxquota: 1000000
注 –
角色条目和 CoS 定义条目应位于目录树中的相同位置，以便在其范围中具有相同的目标条目。CoS 目标条目也应位于相同的位置，以便于查找和维护。
监视 CoS 插件
目录服务器允许您对 CoS 插件的某些方面进行监视。CoS 监视属性存储在 cn=monitor,cn=Class of Service,cn=plugins,cn=config 条目中。有关此条目下每个属性及其所提供信息的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference》。
设置 CoS 日志记录
强制目录服务器在多个适用的定义条目之间进行任意区分时，目录服务器将记录警告消息。此类警告消息使用以下格式：
Definition /defDN1/ and definition /defDN2/ compete to provide attribute '/type/' at priority /level/
当强制目录服务器在多个可能适用的定义条目之间进行任意区分时，您也可以将该服务器配置为记录信息性消息。要执行此操作，请将错误日志设置为包含来自插件的消息。
注 –
由于设置其他日志级别可能会导致日志记录负载过重，因此您可能不希望在生产服务器上设置日志记录。
信息性消息的内容使用以下格式：
Definition /defDN1/ and definition /defDN2/ potentially compete to provide attribute '/type/' at priority /level/
然后，您可以选择是否通过在定义条目上适当设置 CoS 优先级来解决这种 CoS 不确定性问题。
维护引用完整性引用完整性是一种插件机制，可确保条目之间的关系得到维护。有些类型的属性（如组成员身份属性）包含其他条目的 DN。使用引用完整性可确保在删除条目时同时删除包含该条目 DN 的所有属性。
例如，如果从目录中删除用户条目并启用了引用完整性，则服务器也会从该用户所属的所有组中删除该用户。如果未启用引用完整性，则必须由管理员从组中手动删除该用户。如果您要将目录服务器与依赖于目录进行用户和组管理的其他 Sun Java System 产品集成，则此功能十分重要。
引用完整性的工作方式
启用引用完整性插件之后，它将在删除、重命名或移动操作后立即对指定属性执行完整性更新。默认情况下，引用完整性插件处于禁用状态。
只要删除、重命名或移动目录中的用户或组条目，该操作都会记录到引用完整性日志文件中：
instance-path/logs/referint
在指定时间（称为更新时间间隔）过后，服务器将对已启用引用完整性的所有属性执行搜索，并将搜索结果中的条目与日志文件中存在的已删除或已修改条目的 DN 进行匹配。如果日志文件显示条目已被删除，则会删除相应的属性。如果日志文件显示条目已被更改，则会根据更改情况修改相应的属性值。
如果启用了引用完整性插件的默认配置，则在执行删除、重命名或移动操作后，它将立即对 member、uniquemember、owner、seeAlso 和 nsroledn 属性执行完整性更新。但是，您也可以根据自己的需求配置引用完整性插件的行为。可以配置以下行为：
-
在不同文件中记录引用完整性更新。
-
修改更新时间间隔。
如果要减小引用完整性更新对系统的影响，您可能需要增大更新的时间间隔。
-
选择要应用引用完整性的属性。
如果使用或定义包含 DN 值的属性，您可能希望引用完整性插件监视这些属性。
配置引用完整性插件
注 –
必须为引用完整性插件使用的所有数据库中的所有属性编制索引。需要在所有数据库的配置中创建这些索引。启用追溯更改日志后，必须为 cn=changelog 后缀编制索引。有关信息，请参见第 12 章，目录服务器索引。
某些限制与在复制环境下使用引用完整性插件相关。有关这些限制的列表，请参见复制和引用完整性。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
$ dsconf set-server-prop -h host -p port ref-integrity-attr:attribute-name \ ref-integrity-attr:attribute-name
$ dsconf set-server-prop -h host -p port ref-integrity-attr+:attribute-name
$ dsconf set-server-prop -h host -p port ref-integrity-check-delay:duration
$ dsconf set-server-prop -h host -p port ref-integrity-enabled:on第 10 章 目录服务器复制
复制是一种机制，通过此机制可将某个目录服务器中的目录内容自动复制到一个或多个其他目录服务器。所有写入操作都将自动映射到其他目录服务器。有关复制概念、复制方案以及如何在目录部署中规划复制的完整描述，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》。
在复制拓扑中，通常会将服务器上的某个后缀复制到服务器上的其他后缀，或者从其他后缀复制某个后缀。因此，可以交替使用副本、复制的后缀和复制的服务器等术语。
本章介绍通过命令行设置各种复制方案时所执行的任务，其中包含以下主题：
规划复制部署可以使用任意数量的主服务器配置复制部署。部署中不要求包含集线器或使用方。本章包含为集线器和使用方配置复制的过程，但这些过程是可选的。
开始配置复制之前，您需要清楚地了解在组织中部署复制的方式。您必须了解《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中所述的复制概念。此外，您还必须使用《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中提供的设计准则仔细规划未来的复制配置。
用于配置和管理复制的推荐界面配置和管理复制的最简便方法是使用目录服务控制中心 (Directory Service Control Center, DSCC)。使用 DSCC 可以自动配置复制。您可以选择设置复制拓扑所需的自动化级别，例如，是否要在复制配置期间初始化后缀。DSCC 还提供了错误检查功能。此外，DSCC 还提供复制拓扑的图形视图。
DSCC 联机帮助提供了使用 DSCC 设置复制的过程。
注 –
只有在无法使用 DSCC 配置复制时，才需使用本章提供的命令行过程。
配置复制的步骤摘要
配置复制的步骤摘要假定您要复制单个后缀。如果要复制多个后缀，则可以在每个服务器上并行配置这些后缀。换句话说，您可以重复每个步骤以便在多个后缀上配置复制。
本章的其余部分包含有关如何配置复制的详细说明。
配置复制的步骤摘要
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
要配置任何复制拓扑，请执行以下过程中所述的常规步骤。
在专用使用方上启用复制专用使用方是复制后缀的只读副本。专用使用方从绑定为复制管理员的服务器接收更新以进行更改。配置使用方服务器的过程包括准备空后缀以保存复制后缀，以及在该后缀上启用复制。可选的高级配置可包括设置引用、更改清除延迟和修改属性。
以下部分说明如何在服务器上配置一个专用使用方复制后缀。请在将要包含专用使用方复制后缀的每个服务器上重复所有过程。
为使用方副本创建后缀
启用使用方副本
创建空后缀之后，您需要启用使用方复制后缀。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
执行高级使用方配置
如果要为使用方复制后缀配置高级功能，请立即执行此操作。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
在集线器上启用复制集线器副本既作为使用方又作为主服务器，可进一步将复制数据分配给更多的使用方。集线器副本接收来自提供方的复制更新，并将复制更新发送到使用方。这些副本不接受修改，但会返回对主服务器的引用。
配置集线器服务器的过程包括准备空后缀以保存复制后缀，以及在该后缀上启用复制。可选的高级配置可包括选择不同复制管理员、设置引用、设置清除延迟，以及修改更改日志参数。
以下部分说明如何配置一个集线器服务器。请在将要包含集线器复制后缀的每个服务器上重复所有过程。
为集线器副本创建后缀
启用集线器副本
如果您有集线器副本，请立即启用。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
在集线器副本上修改更改日志设置
对于高级集线器配置，您可能需要修改的参数与更改日志相关。作为提供方，集线器服务器需要更改日志。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
在主副本上启用复制主副本包含数据的主拷贝，并在将更新传播到所有其他副本之前集中所有修改。主服务器会记录所有更改、检查使用方的状态，并在必要时向使用方发送更新。在多主复制中，主副本还会从其他主服务器接收更新。
配置主服务器的过程包括定义包含主副本的后缀、启用主副本，以及在必要时为其配置高级复制。
以下部分说明如何配置一个主服务器。请在将要包含主服务器复制后缀的每个服务器上重复所有过程。
为主副本创建后缀
启用主副本
在主服务器上启用复制时，您必须指定复制 ID。复制 ID 用于区分更新语句的所有者，以及解决多主复制中可能发生的冲突。因此，复制 ID 对于此后缀的所有主副本必须是唯一的。复制 ID 一旦设置便不得更改。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
修改主副本上的更改日志设置
如果是高级主服务器配置，您可能需要修改更改日志设置。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置复制管理员本部分介绍如何配置非默认的复制管理员，以及如何设置默认的复制管理员密码。
使用非默认复制管理员
复制管理员是一个用户，提供方在发送复制更新时将使用此用户绑定到使用方服务器。包含接收更新的后缀的所有服务器都必须至少有一个复制管理员条目。
目录服务器有一个默认的复制管理员条目，您可以在每个服务器上使用此条目（特别是在简单复制方案中）：cn=replication manager,cn=replication,cn=config。复制机制将自动使用此用户配置使用方副本，从而简化了副本部署。
如果您的复制方案比较复杂，则可能需要多个复制管理员，并且针对每个复制后缀需要使用不同的密码。可以使用一个或多个新的复制管理员替换现有的默认复制管理员。
注意 –
请勿在服务器上使用复制管理员的 DN 和密码进行绑定或执行操作。复制管理员仅用于复制机制。任何其他用途可能都需要重新初始化副本。
请勿将目录管理员用作复制管理员。由于 cn=admin,cn=Administrators,cn=config 条目用于执行其他管理任务，因此也不得将此用户或管理员组中的任何其他用户用作复制管理员。
为每个使用方选择了复制管理员之后，请务必记住所选择或所创建的复制管理员 DN。稍后在提供方上创建与此使用方之间的复制协议时，需要使用此 DN 及其密码。
设置非默认复制管理员
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
更改默认的复制管理员密码
创建和更改复制协议复制协议是提供方上的一组参数，用于配置和控制将更新发送到给定使用方的方式。必须在向使用方发送更新的提供方复制后缀上创建复制协议。您必须在提供方上为每个要更新的使用方创建复制协议。
创建复制协议
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
如果使用 DSCC 创建新的复制协议，则可以选择复制现有复制协议中的部分或全部复制协议配置设置。
更改复制协议目标
此过程更改现有复制协议所指向的远程副本。现有协议的后缀 DN 和配置保持不变。
部分复制默认情况下，复制操作会将复制后缀中的所有条目复制到使用方副本中。使用部分复制功能，您可以选择要使用的后缀，以及要包括或排除的属性。部分复制是在复制协议中配置的，允许您为主服务器的每个使用方复制后缀定义属性集。您可以控制要分配的数据，并可更有效地使用复制带宽和使用方资源。
例如，如果要减小复制带宽，则可以选择不复制 photo、jpegPhoto 和 audio 之类的属性，因为这些属性通常具有较大的值。因此，在使用方上将无法使用这些属性。另外一种情况是，您可以选择只将 uid 和 userpassword 属性复制到专用于执行验证的使用方服务器。
部分复制的注意事项
注 –
部分复制无法用于 Directory Server 5.2 之前版本的产品中。配置部分复制协议时，主副本和使用方副本必须至少使用 Directory Server 5.2。
启用或修改部分属性需要您重新初始化使用方副本。因此，您需要在部署之前确定部分复制需求，并在首次初始化复制后缀之前定义属性集。
如果某些复杂功能（如 ACI、角色和 CoS）依赖于特定属性，则您在复制小型属性集时需要特别谨慎。此外，不复制 ACI、角色或 CoS 机制的说明符或过滤器中所提到的其他属性可能会对数据安全性造成威胁。不复制这些属性可能还会导致在搜索中返回不同的属性集。管理要排除的属性列表比管理要包含的属性列表更加安全，并且更不容易出现人为错误。
如果您所复制的属性集不允许所有复制条目遵循模式，则需要在使用方服务器中关闭模式检查。复制不符合模式的条目不会引发错误，因为复制机制将避开使用方上的模式检查。但是，使用方将包含不符合模式的条目，并且需要关闭模式检查，以便向客户端显示一致状态。
将在主副本与集线器和专用使用方之间的复制协议中配置部分复制。不支持在多主复制环境中的两个主副本之间配置部分复制。此外，如果多个主服务器与同一副本之间具有多个复制协议，则所有这些协议都必须复制相同的属性集。
配置部分复制
要配置部分复制，必须先指定后缀，再确定要在该后缀上包含属性还是排除属性，然后选择要包含或排除的属性。如果选择在后缀上排除属性，将自动包含所有其他属性。同样，如果选择在后缀上包含某些属性，将自动排除所有其他属性。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
复制优先级指定复制优先级为可选操作。可以创建复制规则，以指定使用高优先级复制某些更改（如更新用户密码）。复制规则中指定的任何更改都将以高优先级进行复制，而所有其他更改都将以普通优先级进行复制。
注 –
只需在主服务器上创建复制优先级规则。不必为集线器和使用方进行配置。
配置复制优先级
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
$ dsconf create-repl-priority -h host -p port suffix-DN priority-name property:value
$ dsconf create-repl-priority -h host2 -p 1389 dc=example,dc=com pw-rule \ attr:userPassword
$ dsconf list-repl-priorities -h host2 -p 1389 -v初始化副本
创建复制协议并已配置两个副本之后，必须先初始化使用方复制后缀，然后才能开始复制。在初始化期间，您实际将提供方复制后缀中的数据复制到使用方复制后缀。
此外，某些错误条件或配置更改也需要重新初始化副本。例如，如果由于任何原因从备份恢复了单个主服务器复制后缀中的数据，则需要对它所更新的所有副本进行重新初始化。
进行重新初始化时，将在使用方上删除复制后缀的内容，并将其替换为主服务器上的后缀内容。这可确保副本保持同步，并且可以恢复复制更新。本部分介绍的所有初始化方法都会自动重新生成使用方副本的索引，以便使用方能以最佳方式响应客户端读取请求。
使用多主复制时，如果使用方已经由拓扑中的其他主服务器进行了更新，则可能不需要进行重新初始化。
从远程（提供方）服务器初始化复制后缀
可以使用现有的复制协议从远程服务器初始化后缀。请尽可能使用此方法进行初始化，因为它要比其他方法简单。仅当存在大量数据使得导入操作耗时过长时，才应使用其他方法。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使用 DSCC 以联机方式对复制后缀进行初始化是初始化或重新初始化使用方的简便方法。但是，如果要初始化大量条目，则此过程可能会非常耗时。在这种情况下，使用命令行以脱机方式初始化使用方可能会更加有效。
从 LDIF 进行副本初始化
从 LDIF 初始化复制后缀
此过程介绍从 LDIF 文件初始化复制后缀时所使用的一般步骤。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使用 DSCC 以联机方式对复制后缀进行初始化是初始化或重新初始化使用方的简便方法。但是，如果要初始化大量条目，则此过程可能会非常耗时。在这种情况下，使用命令行以脱机方式初始化使用方可能会更加有效。
将复制后缀导出到 LDIF
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
为部分复制过滤 LDIF 文件
使用 DSCC 时，对配置了部分复制的副本进行初始化的过程是不可视的。在初始化期间只会将选定属性发送给使用方。
如果已经配置了部分复制，应该在将导出的 LDIF 文件复制到使用方服务器之前过滤出所有未使用的属性。为此，目录服务器提供了 fildif 工具。此工具将过滤给定的 LDIF 文件，以便只保留复制协议中定义的属性集所允许的属性。
此工具将读取服务器配置以确定属性集定义。要读取配置文件，必须以超级用户身份或拥有此过程和文件（由 nsslapd-localuser 属性指定）的用户身份运行 fildif 工具。例如，以下命令将过滤前面示例中从 dc=example,dc=com 后缀导出的文件：
$ fildif -i /local/ds1/ldif/example_master.ldif \ -o /local/ds1/ldif/filtered.ldif -b "cn=host2.example.com:1389, \ cn=replica,cn=\\"dc=example,dc=com\\",cn=mapping tree,cn=config" -p /local/ds1
有关 fildif 命令的位置，请参见命令位置。
-i 和 -o 选项分别是输入和输出文件。-b 选项是定义部分复制的复制协议的 DN。可使用以下命令查找此 DN：
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement) (nsDS5ReplicaPort=replica-port) \ (nsDS5ReplicaHost=replica-host))" dn
例如：
$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement) \ (nsDS5ReplicaPort=2090)(nsDS5ReplicaHost=host2))" dn Enter bind password: version: 1 dn: cn=host2:1389,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config
有关 fildif 工具的完整命令行语法，请参见 fildif(1) 手册页。
接下来，可以使用由 fildif 生成的 filtered.ldif 文件初始化此复制协议中的使用方。将此文件传送到使用方服务器并进行导入，如从 LDIF 文件导入数据中所述。
使用二制进副本初始化复制后缀
二进制副本允许您使用一个服务器中的二进制备份文件克隆整个服务器，以便将相同的目录内容恢复到另一个服务器上。使用二进制副本，您可以通过主服务器或集线器服务器的二进制副本初始化或重新初始化任何服务器，或者通过其他使用方服务器的二进制副本初始化或重新初始化使用方。
注 –
此高级过程将与目录服务器的数据库文件进行交互，因此只有经验丰富的管理员才应该使用。
由于对此功能进行了某些限制，因此对于包含很大数据库文件的副本（例如，包含数百万条目的副本），此功能非常实用和省时。
将二进制副本用于复制的限制
由于二进制副本将一台计算机上的数据库文件移动到另一台计算机上，因此该机制应遵循以下严格限制：
-
两台计算机必须运行相同的操作系统，包括所有服务包 (service pack) 或修补程序。
-
两台计算机必须共享相同的处理器体系结构。例如，可以在两台 UltraSPARC® T1 处理器之间执行二进制副本，但无法在一台 UltraSPARC T1 处理器和一台 AMD Opteron 处理器之间执行二进制副本。
-
两台计算机必须都是大端字节序或都是小端字节序。
-
两台计算机必须以相同方式映射内存。例如，可以在两个 64 位系统上的服务器实例之间执行二进制副本，但无法在 32 位系统上的一个服务器实例和 64 位系统上的另一个服务器实例之间执行二进制副本。
-
两台计算机必须安装相同版本的目录服务器，包括二进制格式（32 位或 64 位）、服务包 (service pack) 和修补程序级别。
-
两个服务器必须具有划分为相同后缀的相同目录树。所有后缀的数据库文件都必须一起复制。无法复制单个后缀。
-
每个后缀必须在两个服务器上配置相同的索引，包括 VLV（Virtual List View，虚拟列表视图）索引。这些后缀的数据库必须具有相同的名称。
-
每个服务器都必须将相同的后缀配置为副本。
-
如果配置部分复制，则必须在所有服务器上进行完全相同的配置。
-
不得在任一服务器上使用属性加密。
-
如果启用属性值唯一性插件，则它在两个服务器上必须具有相同的配置，而且必须在新副本上重新配置该插件，如以下过程所述。
以下过程介绍执行二进制副本的其他方法：不需要停止服务器的二进制副本，以及使用最少磁盘空间的二进制副本。
创建用于初始化服务器的二进制副本
本部分介绍如何创建用于初始化服务器的二进制副本，以及如何创建使用最少磁盘空间的二进制副本。
创建用于初始化服务器的二进制副本
可以使用此过程执行用于初始化复制服务器的二进制副本 ，因为它使用标准备份功能创建服务器数据库文件的副本。执行标准备份可确保所有数据库文件处于一致状态，而无需停止服务器。
此过程具有某些限制。由于备份和恢复操作将在同一台计算机上创建数据库文件的副本，因此在每台计算机上，这些文件所需的磁盘空间量都会加倍。此外，如果目录中包含数千兆字节的数据，则对这些文件执行实际的复制操作可能会耗费大量时间。
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
使用需要最少磁盘空间的二进制副本初始化服务器
此过程将使用较少的磁盘空间和时间，因为它不创建数据库文件的备份副本。但是，它需要停止要克隆的服务器，以确保数据库文件处于一致状态。
注意 –
不得使用此过程对已经加入多主复制方案的主服务器进行重新初始化。它只能用于重新初始化使用方服务器或初始化新的主服务器。要重新初始化现有的主副本，请使用联机初始化、导入 LDIF 文件或执行创建用于初始化服务器的二进制副本中的过程。
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
在级联复制中初始化副本
如果使用级联复制，请终始按照以下过程所示的顺序初始化副本。
在级联复制中初始化副本
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
为复制后缀编制索引索引不会自动从一个服务器实例复制到另一个服务器实例。要为保存复制后缀的所有服务器实例编制属性索引，请执行以下任一操作。
逐渐向大型复制后缀添加大量条目如果您有包含大量条目的目录，并且要添加大量条目，请不要使用 ldapmodify -a，因为这样做会消耗大量时间。通过在 dsconf import 命令中使用用于在复制拓扑中添加条目的选项，可以逐渐添加新条目。导出这些条目时，将生成包含附加内容和复制元数据的 LDIF 文件。然后，可以将生成的此 LDIF 文件导入其他副本中。生成的 LDIF 文件可确保复制在您要添加数据的副本之间始终保持同步。
向大型复制后缀添加大量条目
开始之前
此过程将生成大型 LDIF 文件。在运行第一个 dsconf import 命令之前，请确保具有足够的磁盘空间用于生成的 LDIF 文件。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
注意 –
可以使用此过程分以多次传递的方式初始化包含大量条目的服务器。但是，如果其中一次导入失败，则可能会丢失整个数据库。请务必在每次导入之前备份数据。
复制和引用完整性
如果要在复制中使用引用完整性插件，则必须在所有主服务器中启用该插件。不必在集线器服务器或使用方服务器上启用此插件。
以下限制与在复制环境中使用引用完整性插件有关：
-
必须在包含主副本的所有服务器上启用此插件。
-
必须在每个主服务器上使用相同配置启用此插件。
-
在只包含集线器或使用方副本的服务器上启用此插件不起作用。
有关配置引用完整性插件的信息，请参见配置引用完整性插件。
通过 SSL 执行复制可以对复制中涉及的目录服务器进行配置，以便所有复制操作都通过 SSL 连接执行。
配置使用 SSL 的复制操作
此过程显示的示例命令用于在包含两个主服务器的复制拓扑上设置复制。
注 –
此示例显示了一个简单复制配置（使用自签名证书）。在生产环境中设置通过 SSL 执行的复制时，如果改用由证书颁发机构颁发的可信证书将会更加安全。
如果提供方服务器证书是仅适用于服务器的 SSL 证书（无法在 SSL 握手时作为客户端），将无法通过 SSL 执行复制。
虽然通过 SSL 执行的复制是安全的，仍会使用简单绑定和密码对复制管理员进行验证。可以使用基于客户端的验证来完全保护复制，但这需要更复杂的设置。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
通过 WAN 执行复制目录服务器允许您执行所有形式的复制，包括通过广域网 (Wide Area Network, WAN) 连接的计算机之间的多主复制。此复制允许提供方服务器在初始化和更新使用方时，在具有较高时延和较低带宽的网络上以最佳方式使用带宽。
注 –
对通过 WAN 复制的复制拓扑进行部署和故障排除时，必须检查网络速度、时延和数据包丢失情况。上述任一方面的网络问题都可能会导致复制延迟。
此外，复制数据传输速率将始终低于可用物理介质所允许的速率（在带宽方面）。如果副本之间的更新量无法实际符合可用带宽，则调整操作将无法阻止各个副本在较重的更新负载下产生差异。复制延迟和更新性能由许多因素决定，包括但不限于以下因素：修改率、条目大小、服务器硬件、错误率、平均时延和平均带宽。
如果您的环境中存在复制方面的问题，请与 Sun 服务提供商联系。
默认情况下，复制机制的内部参数针对 WAN 进行了优化。但是，如果由于以上因素导致您的复制速度很慢，则可能需要根据经验调整窗口大小和组大小参数。您还可以安排复制以避开高峰网络时间，从而改善整个网络的使用情况。最后，目录服务器还支持复制数据压缩，以优化带宽使用。
配置网络参数
窗口和组网络参数确定了复制机制如何对条目进行分组，以便通过网络更有效地发送这些条目。这些参数会影响提供方和使用方交换复制更新消息和确认的方式。可以在每个复制协议中配置这些参数，以便您根据每个使用方的特定网络条件调整复制性能。
请监视您所做的任何修改的效果，并相应地调整这些参数。有关说明，请参见获取复制状态。您不必中断复制来修改窗口大小和组大小参数。
配置窗口大小
窗口大小（默认值为 10）表示在无需使用方立即确认的情况下可以发送的更新消息的最大数目。
与发送每条消息后等待确认相比，快速连续地发送多个消息效率更高。使用适当的窗口大小，可以缩短副本等待复制更新或确认到达所花费的时间。
如果使用方副本落后于提供方，请将窗口大小调整为比默认值更大的值（如 100），并在进一步调整之前再次检查复制性能。当复制更新速率很高而使得更新之间的时间较短时，甚至由局域网 (Local Area Network, LAN) 连接的副本都能从较大的窗口大小中获益。
配置窗口大小
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置组大小
组大小（默认值为 1）表示可以绑到单个更新消息中的数据修改的最大数目。如果网络连接似乎要妨碍复制，请将组大小调整为比默认值更大的值（如 10），然后重新检查复制性能。
增加组大小时，请确保满足以下条件：
-
将窗口大小设置为远大于组大小。
-
窗口大小除以组大小所得到的值远大于使用方 cn=config 下的 nsslapd-maxThreadsPerConn 值（通常为后者的两倍）。
将组大小设置为大于 1 时，提供方在将更新发送给使用方之前不会等待填充组。
配置组大小
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
安排复制操作
如果没有必要立即实现副本之间的同步，则可以在网络使用率较低的时段安排复制。当可用的网络资源较多时，完成数据复制的过程应明显加快。
可以将复制安排在一天中的特定时间（基于每天或每周）开始和结束。可以通过每个使用方的复制协议独立为每个使用方执行此操作。新的计划将立即生效，这会导致相应使用方的下一个数据复制出现延迟，直到此计划允许的第一个复制完成为止。
安排复制操作
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
配置复制压缩
要减小复制所使用的带宽，可以将复制配置为在更新使用方时压缩所发送的数据。复制机制使用 Zlib 压缩库。提供方和使用方都必须在 Solaris 或 Linux 平台上运行才能启用压缩。
应该根据经验测试并选择压缩级别，以便在 WAN 环境中使用预期复制时获得最佳结果。请勿在网络带宽很高的 LAN 中设置此参数，因为压缩和解压缩计算会降低复制速度。
配置复制压缩
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
修改复制拓扑本部分从以下几个方面介绍如何管理现有复制拓扑：
更改复制管理员
可以编辑复制协议以更改用于绑定到使用方服务器的复制管理员标识。为了避免复制中断，应该在使用方上定义新的复制管理员条目或证书条目，然后再修改复制协议。但是，如果复制由于绑定失败而中断，复制机制将在您更正错误时自动发送所有必要的更新，此过程将在复制恢复设置的限制下完成。有关过程，请参见使用非默认复制管理员。
管理复制协议
可以禁用、启用或删除复制协议。
禁用复制协议。
禁用复制协议时，主服务器将停止向指定的使用方发送更新。到该服务器的复制将会停止，但协议中的所有设置将被保留。您可以稍后通过重新启用此协议来恢复复制。有关在复制中断后恢复复制机制的信息，请参见启用复制协议。
禁用复制协议
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
启用复制协议
启用复制协议将恢复与指定使用方之间的复制。但是，如果复制中断的时间已超过复制恢复设置所允许的时间，并且使用方未被其他提供方更新，则必须对该使用方进行重新初始化。复制恢复设置包括此提供方更改日志的最大大小和最大存留期，以及使用方的清除延迟（请参见执行高级使用方配置）。
如果中断时间很短并且复制可以恢复，则主服务器将在重新启用协议时自动更新使用方。
启用复制协议
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
删除复制协议
删除复制协议将停止到相应使用方的复制，并将删除有关此协议的所有配置信息。如果日后要恢复复制，请禁用此协议，如禁用复制协议。中所述。
删除复制协议
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
对副本进行升级或降级
对副本进行升级或降级将更改该副本在复制拓扑中的角色。专用使用方可升级为集线器，而集线器可升级为主服务器。主服务器可降级为集线器，而集线器也可降级为专用使用方。但是，主服务器不能直接降级为使用方，同样，使用方也不能直接升级为主服务器。
多主复制机制中所允许的升级和降级功能使得拓扑非常灵活。以前由使用方副本提供服务的站点可能会增大，并且需要具有多个副本的集线器来处理负载。如果负载包括许多副本内容修改，则集线器可以变为主服务器以允许更快速的本地更改，然后可以将这些更改复制到位于其他站点的其他主服务器中。
对副本进行升级或降级时，请注意以下几点：
-
如果升级使用方，使用方将变为集线器。如果升级集线器，集线器将变为主服务器。无法直接将服务器从使用方升级为主服务器。必须首先将使用方升级为集线器，然后再将集线器升级为主服务器。同样，将主服务器降级为使用方时，必须先将主服务器降级为集线器，然后再将集线器降级为使用方。
-
将主服务器降级为集线器时，副本将变为只读副本，并被配置为将引用发送给其余的主服务器。新的集线器将保留其所有使用方，无论这些使用方是集线器还是专用使用方。
-
将单个主服务器降级为集线器将创建无主副本的拓扑。假定您要定义新的主服务器，目录服务器将允许您执行此操作。但是，最好将新的主服务器添加为多主服务器并允许对其进行初始化，然后再对其他主服务器进行降级。
-
将集线器降级为使用方之前，必须禁用或删除出入集线器的所有复制协议。如果不执行此操作，则降级操作将会失败，并出现以下错误：LDAP_OPERATIONS_ERROR “无法在启用某些协议的情况下将集线器降级为只读副本”。
如果集线器的使用方未被其他集线器或主服务器更新，将不再对它们进行更新。您应该在其余的集线器或主服务器上创建新协议，以便更新这些使用方。
-
将使用方升级为集线器时，将启用其更改日志，并且您可以定义与这些使用方之间的新协议。
-
将集线器升级为主服务器时，副本将接受修改请求，并且您可以定义与其他主服务器、集线器或专用使用方之间的新协议。
对副本进行升级或降级
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
禁用复制后缀
禁用复制后缀会将该后缀从复制拓扑中删除。根据该后缀的角色（主服务器、集线器或使用方），它将不再接受更新或发送更新。禁用提供方服务器上的后缀将删除所有复制协议，如果再次启用该副本，则必须重新创建这些协议。
禁用复制后缀
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使复制后缀保持同步
停止复制所使用的目录服务器以进行常规维护之后，当服务器重新处于联机状态时，必须确保立即通过复制对该服务器进行更新。对于多主环境中的主服务器，目录信息需要由多主服务器集中的其他主服务器进行更新。在其他情况下，当集线器服务器或专用使用方服务器进入脱机状态以进行维护之后，如果这些服务器重新处于联机状态，则需要通过主服务器对其进行更新。
本部分介绍复制重试算法，并说明如何在不等待下次重试的情况下强制执行复制更新。
注 –
只有在已经设置复制并且已经初始化使用方时，才能使用本部分介绍的过程。
复制重试算法
如果源副本未成功复制到目标，它将定期以递增的时间间隔进行重试。重试时间间隔取决于错误类型。
请注意，即使您已将复制协议配置为始终保持源副本和目标副本同步，但这还不足以立即更新脱机时间已超过五分钟的副本。
强制执行复制更新
如果复制已停止，您可以对目标后缀强制执行复制更新。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
将主副本移到新计算机上
在某些情况下，可能需要将主副本移到其他计算机上。如果不需要使用相同的主机名和端口号，请使用 dsconf change-repl-dest 更改远程副本的主机名和端口号。有关详细信息，请参见更改复制协议目标。
如果需要保留相同的主机名和端口号，则必须从现有拓扑中删除主服务器，然后将主服务器重新添加到拓扑中。
使用 DSCC 执行这些任务则要简便得多，因为 DSCC 负责处理所有受影响的复制协议。但是，如果使用 DSCC，则不能指定主服务器最初在拓扑中具有的相同副本 ID。要使用相同的副本 ID，必须使用命令行来执行这些任务，如下所示。
从现有复制拓扑中删除主服务器
开始之前
确保已复制了主服务器中的所有更改。
在现有复制拓扑中添加主服务器
使用 Directory Server 6.2 之前的版本进行复制本部分提供有关如何使用 Directory Server 6.2 之前的版本配置复制的信息。
在 Directory Server 6.2 与 Directory Server 5.1 或 5.2 之间进行复制
Directory Server 5.1、5.2 和 6.2 在复制配置方面是互相兼容的，但以下情况除外：
-
Directory Server 6.2 之前的版本不支持复制优先级。如果在 6.2 主副本上配置复制优先级，则此复制优先级将被传送到运行 Directory Server 6.2 的使用方，但不会传送到任何运行以前版本的目录服务器的使用方。
-
包含 Directory Server 5.1 或 5.2 主服务器的复制拓扑不允许使用任意数量的主服务器。尽管 Directory Server 6.2 允许在复制拓扑中使用任意数量的主服务器，但如果您的复制拓扑中包含任何 Directory Server 5.2 主服务器，则此数量将被限制为四个。DirectoryServer 5.1 不支持多主复制。
追溯更改日志由 LDAP 客户端使用，用于确定目录服务器数据的更改历史记录。追溯更改日志与目录服务器更改日志存储在不同的数据库中，位于 cn=changelog 后缀下。
可以在单独的服务上或复制拓扑中的每个服务器上启用追溯更改日志。在服务器上启用追溯更改日志时，默认情况下将记录该服务器上所有后缀的更新。可以将追溯更改日志配置为只记录指定后缀的更新。
有关追溯更改日志中的条目属性的信息，请参见 changeLogEntry(5dsoc) 手册页。
有关修改追溯更改日志的详细信息，请参见 dsconf(1M) 手册页。
本部分说明使用追溯更改日志的各种方法。
启用追溯更改日志
要使用追溯更改日志，必须先启用该日志。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
将追溯更改日志配置为记录指定后缀的更新
在服务器上启用追溯更改日志时，默认情况下将记录该服务器上所有后缀的更新。此过程介绍如何将追溯更改日志配置为只记录指定后缀的更新。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
将追溯更改日志配置为记录已删除条目的属性
此过程介绍如何将追溯更改日志配置为在删除条目时记录该条目的指定属性。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
修整追溯更改日志
在指定的一段时间过后，可以自动删除追溯更改日志中的条目。要配置一段时间，使条目在此时间段后自动删除，请确保已启用追溯更改日志，然后设置 cn=Retro Changelog Plugin, cn=plugins, cn=config 条目中的 nsslapd-changelogmaxage 配置属性。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
$ dsconf get-server-prop -h host -p port retro-cl-enabled
$ dsconf set-server-prop -h host -p port retro-cl-enabled:on
$ dsconf set-server-prop -h host -p port retro-cl-max-age:duration
$ dsconf set-server-prop -h host 2 -p 1389 retro-cl-max-age:2d
访问控制和追溯更改日志
追溯更改日志支持搜索操作。它针对特定搜索（包含以下格式的过滤器）进行了优化：
(&(changeNumber>=X)(changeNumber<=Y))
作为一般规则，请勿对追溯更改日志条目执行添加或修改操作。可以删除条目以修整日志大小。只有在修改默认访问控制策略时，才需要对追溯更改日志执行修改操作。
创建追溯更改日志时，默认情况下将应用以下访问控制规则：
-
为所有经过验证的用户（userdn=anyone，不要与 userdn=all 的匿名访问相混淆）授予追溯更改日志顶级条目 cn=changelog 的读取、搜索和比较权限。
-
不授予写入和删除访问权限，但暗中授予目录管理员的除外。
不为匿名用户授予读取访问权限，因为追溯更改日志条目可能包含对敏感信息（如密码）的修改。如果不希望经过验证的用户查看追溯更改日志的内容，您可能需要进一步限制对内容的访问权限。
要修改应用于追溯更改日志的默认访问控制策略，请修改 cn=changelog 条目的 aci 属性。请参见第 6 章，目录服务器访问控制。
获取复制状态可以使用 DSCC 或命令行工具获取复制状态。
在 DSCC 中获取复制状态
可以使用“后缀”选项卡以图形方式查看复制，包括复制协议和复制延迟。有关详细信息，请参见 DSCC 联机帮助。
此外，还可以使用 DSCC 查看复制拓扑，如下图所示。
图 10–1 样例复制拓扑
获取复制状态 使用命令行
如果无法使用 DSCC，请使用命令行工具获取有关复制部署的信息。
手册页提供了完整的命令行语法以及这些工具的使用示例。
要查找这些命令所在的目录，请参见命令位置。
解决常见复制冲突多主复制使用宽松的一致性复制模型。这意味着可以在不同服务器上同时修改相同条目。在两个服务器之间发送更新时，必须解决所有冲突的更改。大多数情况下系统都可以自动解决冲突。例如，将使用最近的更改解决与每个服务器上的更改相关联的时间戳。但是，某些更改冲突需要手动介入才能解决。
本部分包含以下主题：
使用 DSCC 解决复制冲突
解决复制冲突的最简单方法是使用 DSCC。有关信息，请参见 DSCC 联机帮助。
使用命令行解决复制冲突
可以使用命令行解决复制冲突。存在更改冲突（无法由复制过程自动解决）的条目将包含操作属性 nsds5ReplConflict 作为冲突标记。
要查找存在冲突的条目，请定期搜索包含此属性的条目。例如，您可以使用以下 ldapsearch 命令查找存在冲突的条目：
$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config \ -w - -b "dc=example,dc=com" "(nsds5ReplConflict=*)"
请注意，默认情况下将为 nsds5ReplConflict 编制索引。
解决命名冲突
如果在服务器相互复制更改之前创建具有相同 DN 的条目，则可能会在不同的主服务器上创建这些条目。在复制时，冲突解决机制将自动对所创建的第二个条目进行重命名。
存在 DN 命名冲突的条目将通过以下方式进行重命名：在该条目的 DN 中包含其唯一标识符（由操作属性 nsuniqueid 提供）。
例如，如果在两个主服务器上同时创建条目 uid=bjensen,ou=People,dc=example,dc=com，则复制之后这两个主服务器上都将具有以下两个条目：
-
uid=bjensen,ou=People,dc=example,dc=com
-
nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com
必须为第二个条目提供有用的 DN。您可以删除冲突的条目，然后使用不冲突的名称再次添加该条目。但是，重命名条目将确保其内容不会发生更改。重命名过程取决于命名属性是单值属性还是多值属性。请参见以下过程。
对包含多值命名属性的冲突条目进行重命名
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使用单值命名属性重命名冲突条目
如果重复条目中的命名属性是单值属性，例如 dc（domain component，域组件），则不能简单地将此条目重命名为同一属性的其他值。您必须为此条目提供一个临时名称。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
解决孤立条目冲突
复制删除操作时，如果使用方服务器发现要删除的条目具有子条目，则冲突解决过程将创建紧附条目，以免目录中出现孤立条目。
同样，复制添加操作时，如果使用方服务器找不到父条目，则冲突解决过程将创建代表父条目的紧附条目，以免新条目成为孤立条目。
紧附条目是包含对象类 glue 和 extensibleObject 的临时条目。可以使用多种方法创建紧附条目：
-
如果冲突解决过程发现已删除条目具有匹配的唯一标识符，则紧附条目就是该条目的再生条目。它还包含 glue 对象类和 nsds5ReplConflict 属性。
在这种情况下，可以修改紧附条目以删除 glue 对象类和 nsds5ReplConflict 属性（以便使此条目保持为普通条目），或者删除紧附条目及其子条目。
-
服务器创建具有 glue 和 extensibleObject 对象类的最小条目。
在这种情况下，必须修改此条目使其成为有意义的条目，或者删除此条目及其所有子条目。
解决潜在的互操作性问题
如果需要与依赖于属性唯一性的应用程序（如邮件服务器）进行交互操作，您可能需要限制对包含 nsds5ReplConflict 属性的条目的访问权限。如果不限制对这些条目的访问权限，则只需要一个属性的应用程序将同时获得原始条目和包含 nsds5ReplConflict 的冲突解决条目，并且操作将会失败。
要限制访问权限，需要使用以下命令修改授予匿名读取访问权限的默认 ACI。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: dc=example,dc=com changetype: modify delete: aci aci: (target ="ldap:///dc=example,dc=com") (targetattr !="userPassword" (version 3.0;acl "Anonymous read-search access"; allow (read, search, compare)(userdn = "ldap:///anyone");) - add: aci aci: (target="ldap:///dc=example,dc=com") (targetattr!="userPassword") (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");) ^D
新的 ACI 可阻止在搜索结果中返回包含 nsds5ReplConflict 属性的条目。
第 11 章 目录服务器模式目录服务器提供一个包含大量对象类和属性的标准模式。虽然标准对象类和属性应该能满足您的大多数要求，但您可能仍需通过创建新的对象类和属性来扩展模式。有关标准模式的概述以及如何设计满足部署要求的模式的相关说明，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》。如何设计满足部署要求的模式的相关说明
本章介绍如何管理模式，其中包含以下主题：
管理模式检查打开模式检查时，目录服务器可确保所有导入、添加和修改操作都符合当前定义的目录模式。
-
每个条目的对象类和属性都符合模式。
-
条目包含其所有已定义的对象类的所有必需属性。
-
条目只包含其对象类所允许的属性。
注 –
修改条目时，目录服务器将对整个条目（而不仅仅是要修改的属性）执行模式检查。因此，如果条目中的任何对象类或属性不符合模式，操作都可能会失败。
但是，模式检查不会验证属性值在语法方面的有效性。
默认情况下将打开模式检查。通常都在打开模式检查的情况下运行目录服务器。许多客户端应用程序都假定，打开模式检查即表明所有条目都符合模式。但是，打开模式检查不会使目录服务器验证目录中的现有内容。保证所有目录内容都符合模式的唯一方法是，在添加任何条目或重新初始化所有条目之前打开模式检查。
在某些情况下可能需要关闭模式检查，例如，为了加快已知符合模式的 LDIF 文件的导入速度。但这样做存在风险，因为可能会导入不符合模式的条目。如果模式检查处于关闭状态，则不会检测到不符合模式的导入条目。
有关在复制环境中使用模式检查的详细信息，请参见复制目录模式。
解决模式遵循性问题
当某个条目不符合模式时，可能无法搜索此条目，并且对此条目的修改操作可能会失败。请执行以下过程中的步骤来更正此问题。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
开始之前
为了避免日后需要解决模式遵循性问题，请在部署之前规划模式，以尽可能减少模式更改。有关详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》。
关于自定义模式如果标准模式无法满足您的目录需求，则可以扩展标准模式。自定义模式时应遵循以下准则：
-
尽可能重新使用现有的模式元素。
-
尽可能减少为每个对象类定义的必需属性的数量。
-
不要针对同一用途定义多个对象类或属性。
-
使模式尽可能简单。
自定义模式时，不要修改、删除或替换标准模式中属性或对象类的任何现有定义。否则，可能会导致与其他目录和 LDAP 客户端应用程序的兼容性问题。
不要修改任何目录服务器内部操作属性。但是，您可以创建自己的操作变量以用于外部应用程序。
应始终定义对象类，而不要使用 objectClass: extensibleObject。目录服务器不会对具有对象类 extensibleObject 的条目执行模式检查，因此不会限制或检查该条目中存在的属性。目录服务器无法检测到应用程序中的拼写错误，例如，将 givenName 属性类型写成 giveName。此外，目录服务器还必须假定 extensibleObject 条目所有其他未定义的属性都是多值属性，并且使用区分大小写的字符串语法。而且，某些应用程序依赖于具有特定对象类的条目。通常，如果您的应用程序要求扩展对象类，请不要放弃模式管理，而应创建一个包含该应用程序所需属性的辅助对象类。
本部分包含有关默认目录模式以及创建自定义属性和对象类的信息。
默认目录服务器模式
instance-path/config/schema/ 目录中存储的一组文件对目录服务器随附的模式进行了介绍。
此目录包含目录服务器和相关产品的所有通用模式。LDAP v3 标准用户和组织模式位于 00core.ldif 文件中。此目录的早期版本所使用的配置模式位于 50ns-directory.ldif 文件中。
注 –
当服务器正在运行时，不要修改此目录中的文件。
对象标识符
必须为每个 LDAP 对象类或属性指定唯一的名称和对象标识符 (object identifier, OID)。定义模式时，您需要一个在组织中具有唯一性的 OID。一个 OID 即可满足您的所有模式需求。然后，您可以在该 OID 上为您的属性和对象类添加新的分支。
获取和指定模式中的 OID 时，您需要执行以下操作：
-
从互联网号码分配机构 (Internet Assigned Numbers Authority, IANA) 或国家组织为您的组织获取 OID。
在某些国家/地区，已经为公司指定了 OID。如果您的组织还没有 OID，则可以从 IANA 获取 OID。
-
创建一个 OID 注册表，以便可以跟踪 OID 分配。
OID 注册表是由您维护的列表，它提供目录模式中所使用的 OID 及 OID 描述。OLD 注册表可确保任何 OID 都不会用于多种用途。
-
在 OID 树中创建分支以容纳模式元素。
在 OID 分支或目录模式下至少创建两个分支，OID.1 用于属性，OID.2 用于对象类。如果您要定义自己的匹配规则或控制，则可以根据需要添加新的分支（如 OID.3）。
命名属性和对象类
创建新属性和对象类的名称时，应使用有意义的名称，以使模式更易于使用。
通过在自定义元素上包含唯一的前缀，可以避免在自定义模式元素和现有模式元素之间出现命名冲突。例如，Example.com 公司可以在其每个自定义模式元素之前添加前缀 Example。它还可以添加一个名为 ExamplePerson 的特殊对象类，以便在目录中标识 Example.com 员工。
请注意，在 LDAP 中，属性类型名称和对象类名称区分大小写。应用程序应将其视为区分大小写的字符串。
定义新对象类
如果现有对象类不支持需要在目录条目中存储的所有信息，则可以添加新的对象类。
可以使用两种方法创建新对象类：
确定如何实现新对象类时，请考虑以下事项。
-
多个 STRUCTURAL 对象类将导致需要创建和维护更多的模式元素。
通常，元素的数量始终很少，并且几乎不需要维护。但是，如果您计划向模式中添加两个或三个以上的对象类，则使用单个对象类可能会更容易一些。
-
多个 STRUCTURAL 对象类要求在设计数据时更加仔细和严格。
严格的数据设计将迫使您考虑放置每份数据的对象类结构。此限制可能很有用，但也可能带来麻烦。
-
如果要将数据放在多种类型的对象类结构上，则单个 AUXILIARY 对象类可简化数据设计。
例如，假定您要将 preferredOS 同时放在个人条目和组条目上。您可能只想创建一个对象类以允许此属性。
-
设计与实际对象和组元素相关、且可构成合理分类的对象类。
-
避免为新对象类设置必需属性。
必需属性可能会使模式缺乏灵活性。创建新对象类时，请设置允许属性，而不要设置必需属性。
定义新对象类之后，您需要确定该对象类允许和需要哪些属性，以及该对象类是从哪个或哪些对象类继承而来的。
定义新属性
如果现有属性不支持需要在目录条目中存储的所有信息，则可以添加新的属性。请尽可能使用标准属性。请搜索默认目录模式中已存在的属性，并使用与新对象类关联的那些属性。
例如，除了 person、organizationalPerson 或 inetOrgPerson 对象类所支持的信息之外，您可能还想在个人条目上存储更多信息。如果要在目录中存储生日，标准目录服务器模式内却不存在任何属性。您可以创建一个名为 dateOfBirth 的新属性。通过定义允许此属性的新辅助类，可以将此属性用于表示人员的条目上。
创建自定义模式文件
创建自定义模式文件时（特别是使用复制时），请注意以下事项：
[00-99] filename.ldif通过 LDAP 管理属性类型
本部分介绍如何通过 LDAP 创建、查看和删除属性类型。
创建属性类型
cn=schema 条目具有多值属性 attributeTypes，该属性包含目录模式中每个属性类型的定义。可以使用 ldapmodify(1) 命令添加这些定义。
新的属性类型定义以及您对用户定义的属性类型所做的更改都保存在 99user.ldif 文件中。
对于每个属性类型定义，至少要提供一个 OID 以定义新的属性类型。请考虑至少为新属性类型使用以下元素：
-
属性 OID。 与属性的对象标识符相对应。OID 是一个字符串，通常是点分十进制数字，可以唯一地标识模式对象。
为了严格遵循 LDAP v3，您必须提供有效的数字 OID。要了解 OID 的详细信息，或者为您的企业请求前缀，请向互联网号码分配机构 (Internet Assigned Number Authority, IANA) 发送电子邮件（地址为 iana@iana.org），或访问 IANA Web 站点。
-
属性名称。与属性的唯一名称相对应。也称为其属性类型。属性名称必须以字母开头，并且只能包含 ASCII 字母、数字和连字符。
属性名称可以包含大写字母，但任何 LDAP 客户端都不会根据大小写来区分属性。根据 RFC 4512 的 2.5 节，必须以不区分大小写的方式处理属性名称。
您可以选择为属性类型添加备用属性名称（也称为别名）。
-
属性描述。用于介绍属性用途的简短描述性文本。
-
语法。由 OID 引用，用于描述属性将包含的数据。
RFC 4517 中列出了属性语法及其 OID。
-
允许的值数。默认情况下属性可以具有多个值，但您可能希望将属性限制为单值属性。
创建属性类型
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–1 创建属性类型
以下示例将使用 ldapmodify 命令添加具有目录字符串语法的新属性类型：
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogURL.ldif Enter bind password: modifying entry cn=schema $
在生产环境中，应该提供一个唯一的有效 OID，而不是 1.2.3.4.5.6.7。
查看属性类型
cn=schema 条目具有多值属性 attributeTypes，该属性包含目录模式中每个属性类型的定义。可以使用 ldapsearch(1) 命令读取这些定义。
查看属性类型
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–2 查看属性类型
以下命令显示所有属性类型的定义：
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes
-T 选项可阻止 ldapsearch 命令折叠 LDIF 行，以便您更容易地使用 grep 或 sed 等命令处理输出。这样，如果您通过 grep 命令输送此命令的输出，则可以只查看目录模式中用户定义的扩展部分。例如：
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes | grep "user defined" attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
删除属性类型
cn=schema 条目具有多值属性 attributeTypes，该属性包含目录模式中每个属性类型的定义。可以使用 ldapmodify(1) 命令删除具有 X-ORIGIN 'user defined' 的定义。
由于模式是由 LDAP 视图在 cn=schema 中定义的，因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是，您只能删除 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器不会删除其他定义。
对用户定义属性所做的更改将保存在 99user.ldif 文件中。
删除属性类型
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–3 删除属性类型
以下命令将删除在示例 11–1 中创建的属性类型：
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) ^D
请注意，必须包括由目录服务器添加的 X-ORIGIN 'user defined'（用于将此模式定义归类为扩展）。
通过 LDAP 管理对象类
本部分介绍如何通过 LDAP 创建、查看和删除对象类。
创建对象类
cn=schema 条目具有多值属性 objectClasses，该属性包含目录模式中每个对象类的定义。可以使用 ldapmodify(1) 命令添加这些定义。
新的对象类定义以及您对用户定义的对象类所做的更改都保存在 99user.ldif 文件中。
如果您要创建继承其他对象类的多个对象类，则必须先创建父对象类。如果新对象类使用自定义属性，还必须首先定义这些属性。
至少要为每个对象类定义提供一个 OID。请考虑至少为新对象类使用以下元素：
-
对象类 OID。与对象类的对象标识符相对应。OID 是一个字符串，通常是点分十进制数字，可以唯一地标识模式对象。
为了严格遵循 LDAP v3，您必须提供有效的数字 OID。要了解 OID 的详细信息，或者为您的企业请求前缀，请向互联网号码分配机构 (Internet Assigned Number Authority, IANA) 发送电子邮件（地址为 iana@iana.org），或访问 IANA Web 站点。
-
对象类名称。与对象类的唯一名称相对应。
-
父对象类。此对象类从中继承属性的现有对象类。
如果您不希望此对象类继承其他特定对象类，请使用 top。
通常，如果要为用户条目添加新属性，则父对象类将是 inetOrgPerson 对象类。如果要为公司条目添加新属性，则父对象类通常为 organization 或 organizationalUnit。如果要为组条目添加新属性，则父对象类通常是 groupOfNames 或 groupOfUniqueNames。
-
必需属性。列出并定义此对象类必须具有的属性。
-
允许的属性。列出并定义此对象类可以具有的其他属性。
创建对象类
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–4 创建对象类
以下示例使用 ldapmodify 命令添加新对象类：
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif Enter bind password: modifying entry cn=schema $
在生产环境中，应该提供唯一的有效 OID，而不是 1.2.3.4.5.6.8。
查看对象类
cn=schema 条目具有多值属性 objectClasses，该属性包含目录模式中每个对象类的定义。可以使用 ldapsearch(1) 命令读取这些定义。
查看对象类
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–5 查看对象类
以下命令显示所有对象类的定义：
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses
-T 选项可阻止 ldapsearch 命令折叠 LDIF 行，以便您更容易地使用 grep 或 sed 等命令处理输出。这样，如果您通过 grep 命令输送此命令的输出，则可以只查看目录模式中用户定义的扩展部分。例如：
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined" objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) $
删除对象类
cn=schema 条目具有多值属性 objectClasses，该属性包含目录模式中每个对象类的定义。可以使用 ldapmodify(1) 命令删除具有 X-ORIGIN 'user defined' 的定义。
由于模式是由 LDAP 视图在 cn=schema 中定义的，因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是，您只能删除 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器不会删除其他定义。
对用户定义元素所做的更改将保存在 99user.ldif 文件中。
删除对象类
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
示例 11–6 删除对象类
以下命令将删除在示例 11–4 中创建的对象类：
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) ^D
请注意，必须包括由目录服务器添加的 X-ORIGIN 'user defined'（用于将此模式定义归类为扩展）。
扩展目录服务器模式
向模式中添加新属性时，必须创建新对象类以包含这些新属性。可以直接将属性添加到已包含您所需要的大多数属性的现有对象类中，这种方法看起来比较方便，但却会影响与 LDAP 客户端之间的互操作性。
目录服务器与现有 LDAP 客户端之间的互操作性依赖于标准 LDAP 模式。如果更改标准模式，您在升级服务器时也会遇到困难。同理，您也不能删除标准模式元素。
目录服务器模式存储在 cn=schema 条目的属性中。与配置条目一样，此条目也是模式的 LDAP 视图，在服务器启动期间将从文件中读取此视图。
用于扩展目录服务器模式的方法取决于您是否要控制存储模式扩展时所使用的文件名。此外，还取决于您是否要通过复制将更改发送给使用方。请参见下表，以便根据您的具体情况确定要执行的过程。
表 11–1 扩展模式的方法|
任务 |
说明 |
|---|---|
|
您不使用复制。您打算通过添加自定义模式文件扩展模式。 | |
|
您打算通过 LDAP 扩展模式。 | |
|
您使用复制。您打算在所有服务器上保留自定义模式文件的文件名。 | |
|
您使用复制。您打算通过在主副本上添加自定义模式文件来扩展模式。然后通过复制机制将模式扩展复制到使用方服务器。 |
有关对象类、属性和目录模式的详细信息以及扩展模式所应遵循的准则，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide》中的“Designing a Directory Schema”。有关标准属性和对象类的信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference》。
本部分提供扩展目录模式时可使用的各种方法的相关信息。
使用自定义模式文件扩展模式
模式文件是位于 instance-path/config/schema/ 中的 LDIF 文件。instance-path 与目录服务器实例所在的文件系统目录相对应。例如，此实例可能位于 /local/ds/ 中。这些文件可定义供目录服务器以及依赖于目录服务器的所有服务器使用的标准模式。《Sun Java System Directory Server Enterprise Edition 6.2 Reference》和《Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference》中介绍了这些文件和标准模式。
服务器只在启动时读取模式文件一次。这些 LDIF 文件的内容将被添加到 cn=schema 中模式的内存 LDIF 视图。由于模式定义的顺序非常重要，因此模式文件名称都以数字开头，并按字母数字顺序装入。只有在安装期间定义的系统用户才能对此目录中的模式文件执行写入操作。
在 LDIF 文件中直接定义模式时，不要在 X-ORIGIN 字段中使用 'user defined' 值。此值是为特定的模式元素保留的，这些元素通过 cn=schema 的 LDAP 视图进行定义，并出现在 99user.ldif 文件中。
99user.ldif 文件包含其他 ACI，用于 cn=schema 条目和所有已从命令行或使用 DSCC 添加的模式定义。添加新的模式定义时，将覆盖 99user.ldif 文件。如果要修改此文件，则必须立即重新启动服务器，以确保更改是最新的。
不要修改在其他模式文件中定义的标准模式。但是，您可以添加新文件，以定义新的属性和对象类。例如，要在许多服务器中定义新的模式元素，则可以在名为 98mySchema.ldif 的文件中定义这些元素，并将此文件复制到所有服务器上的模式目录中。然后，应重新启动所有服务器以装入新的模式文件。
使用自定义模式文件扩展模式
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
通过 LDAP 扩展模式
由于模式是由 LDAP 视图在 cn=schema 中定义的，因此您可以使用 ldapsearch 和 ldapmodify 实用程序联机查看和修改模式。但是，您只能修改 X-ORIGIN 字段值为 'user defined' 的模式元素。服务器将拒绝对其他定义所做的任何修改。
新的元素定义以及您对用户定义元素所做的更改都保存在 99user.ldif 文件中。
通过 LDAP 扩展模式
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
开始之前
从命令行修改模式定义容易出错，因为必须准确键入较长的值。但是，您可以在需要更新目录模式的脚本中使用此功能。
另请参见
要修改其中某个值，您必须先删除特定的值，然后将此值作为新值进行添加。由于属性为多值属性，因此必须执行此过程。有关详细信息，请参见修改多值属性的一个值。
使用模式文件和复制扩展模式
有关自定义模式文件的信息，请参见使用自定义模式文件扩展模式。以下过程介绍如何使用复制机制将模式扩展传播到拓扑中的所有服务器。
使用模式文件和复制扩展模式
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
复制目录模式在两个服务器之间配置一个或多个后缀的复制时，也会自动复制模式定义。模式定义的自动复制可确保所有副本都具有完整、相同的模式，此模式用于定义可以复制到使用方的所有对象类和属性。因此，主服务器也将包含主服务器模式。
但模式复制不是即时完成的，即使通过 LDAP 修改模式时也是如此。模式复制会在更新目录数据时触发，或者在修改模式后启动第一个复制会话时触发。
要在所有副本上执行模式，至少要在所有服务器上启用模式检查。由于在执行 LDAP 操作的主服务器上执行模式检查，因此更新使用方时不需要检查模式。为了提高性能，复制机制将避开使用方副本上的模式检查。
注 –
不要在集线器和专用使用方上关闭模式检查。模式检查不会影响使用方的性能。应始终打开模式检查，以表明副本内容符合其模式。
在使用方初始化期间，主服务器自动将模式复制到其使用方。只要通过 DSCC 或命令行工具修改模式，主服务器还会自动复制此模式。默认情况下将复制整个模式。将在使用方上创建其尚不存在的所有其他模式元素，并将这些元素存储在 99user.ldif 文件中。
例如，假定在启动主服务器时，该服务器包含 98mySchema.ldif 文件中的模式定义。此外，还假定您接下来将定义与其他服务器（主服务器、集线器或专用使用方）之间的复制协议。当您随后从此主服务器初始化副本时，复制的模式将包含 98mySchema.ldif 中的定义，但这些定义将存储在副本服务器上的 99user.ldif 中。
在使用方初始化期间复制模式之后，修改主服务器 cn=schema 中的模式还会将整个模式复制到使用方。因此，通过命令行实用程序或 DSCC 对主服务器模式所做的任何修改都将复制到使用方。这些修改存储在主服务器上的 99user.ldif 中，并且通过上述机制，这些修改还会存储在使用方上的 99user.ldif 中。
请考虑以下有关在复制环境中维护模式一致性的准则：
-
不要修改使用方服务器上的模式。
对使用方服务器上的模式所做的修改可能会导致复制错误。这是因为使用方上的模式差异可能会导致来自提供方的更新不符合使用方上的模式。
-
在多主复制环境中，请修改单个主服务器上的模式。
修改两个主服务器上的模式时，最近更新的主服务器会将其模式版本传播到使用方。这样，使用方上的模式可能与其他主服务器上的模式不一致。
配置部分复制时，还应考虑以下准则：
-
由于在部分复制配置中由提供方发送模式，因此部分使用方副本上的模式是主副本模式的副本。因此，模式与所应用的部分复制配置可能不相符。
-
通常，目录服务器会按照模式中的定义复制每个条目的所有必需属性，以免发生模式违规错误。将部分复制配置为过滤掉必需属性时，必须禁用模式检查。
-
如果对部分复制启用模式检查，可能无法以脱机方式初始化副本。如果过滤掉必需属性，目录服务器将不允许您从 LDIF 装入数据。
-
如果在部分使用方副本上禁用了模式检查，则部分使用方副本所在的整个服务器实例都不会执行模式检查。因此，应避免将同一服务器实例上的提供方副本配置为部分使用方。
限制模式复制
默认情况下，只要复制机制复制模式，它都会将整个模式发送到其使用方。在以下两种情况下不希望将整个模式发送到使用方：
-
使用 DSCC 或从命令行对 cn=schema 所做的修改仅限于用户定义的模式元素，所有标准模式都不会更改。如果您经常修改模式，则每次发送大量未更改的模式元素时都会对性能造成影响。您可以只复制用户定义的模式元素，以提高复制和服务器性能。
-
当目录服务器上的主服务器复制到 Directory Server 5.1 上的使用方时，这些版本的配置属性模式将有所不同，因而会产生冲突。在这种情况下，您只能复制用户定义的模式元素。
注 –
目录服务器使用 11rfc2307.ldif 模式文件。此模式文件符合 RFC 2307。
DirectoryServer 5.2 以前的目录服务器版本使用 10rfc2307.ldif 模式文件。
限制模式复制
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
第 12 章 目录服务器索引与书籍索引类似，目录服务器索引通过将搜索字符串与目录内容引用相关联，可以加快搜索速度。
本章包含以下主题：
管理索引本部分介绍如何管理特定属性的索引。本部分包含有关创建、修改和删除索引的信息。有关特定于虚拟列表视图 (Virtual List View, VLV) 操作的过程，请参见管理浏览索引。
列出索引
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
创建索引
注 –
您无法创建新的系统索引，而只能维护由目录服务器内部定义的现有系统索引。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
修改索引
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
生成索引
此过程将生成索引文件，以便可以搜索新索引或已修改的索引。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
$ dsconf reindex -h host -p port [-t attr] suffix-DN
$ dsconf reindex -h host -p port -t preferredLanguage dc=example,dc=com
$ dsadm reindex -t attr instance-path suffix-DN
$ dsadm reindex -t preferredLanguage /local/ds dc=example,dc=com
删除索引
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
更改索引列表阈值
搜索速度缓慢可能是因为系统索引列表大小超过了索引列表阈值。索引列表阈值是每个索引键的最大值数。要确定是否已超过索引列表阈值大小，请检查访问日志。访问日志 RESULT 消息末尾的 notes=U 标志表明执行了未编制索引的搜索。前面的 SRCH 消息（属于同一个连接和操作）指定已使用的搜索过滤器。以下两行示例将跟踪一个未编制索引的搜索 cn=Smith，该搜索将返回 10,000 个条目。已从这些消息中删除了时间戳。
conn=2 op=1 SRCH base="o=example.com" scope=0 filter="(cn=Smith)" conn=2 op=1 RESULT err=0 tag=101 nentries=10000 notes=U
如果您的系统经常超过索引列表阈值，请考虑增加阈值以提高性能。以下过程将使用 dsconf set-server-prop 命令修改 all-ids-threshold 属性。有关调整索引和 all-ids-threshold 属性的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.2 Reference》中的“Tuning Indexes for Performance”。
更改索引列表阈值
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
dsconf set-server-prop -h host -p port all-ids-threshold:value
dsconf set-suffix-prop -h host -p port suffix-DN all-ids-threshold:value
dsconf set-index-prop -h host -p port suffix-DN all-ids-threshold:value
dsconf set-index-prop -h host -p port suffix-DN all-ids-threshold search-type:value
重新编制后缀的索引
如果索引文件已损坏，则必须重新编制后缀的索引，以便在相应的数据库目录中重新创建索引文件。您可以在目录服务器运行期间重新编制后缀的索引，也可以通过重新初始化后缀来重新编制后缀的索引。
在目录服务器运行期间重新编制后缀的索引
重新编制后缀的索引时，服务器将检查此后缀包含的所有条目，并重新创建索引文件。在重新编制索引期间后缀内容处于只读状态。由于服务器必须扫描整个后缀来查找要编制索引的每个属性，因此如果后缀包含数百万条目，则完成此过程可能需要几个小时的时间。时间长度还取决于您配置的索引。此外，在重新编制后缀的索引时，索引将不可用，并且服务器性能将受到影响。
在后缀上重新编制全部索引
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
通过重新初始化重新编制后缀的索引
重新初始化后缀时将会导入新内容，这意味着此后缀的内容将被替换，并将创建新的索引文件。重新初始化后缀可能比为多个属性重新编制索引更快，因为在装入条目时将为所有属性并行编制索引。但是请注意，后缀在重新初始化期间不可用。
通过重新初始化为后缀重新编制索引
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
管理浏览索引浏览索引是一种特殊索引，仅用于请求服务器端结果排序的搜索操作。《Sun Java System Directory Server Enterprise Edition 6.2 Reference》说明了浏览索引在目录服务器中的工作方式。
用于客户端搜索的浏览索引
必须手动定义用于客户端搜索结果排序的自定义浏览索引。要创建浏览索引，也称为虚拟列表视图 (Virtual List View, VLV) 索引，请使用以下过程。本部分还包括添加或修改浏览索引条目以及重新生成浏览索引的过程。
创建浏览索引
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
添加或修改浏览索引条目
浏览索引专用于给定基条目及其子树上的给定搜索。浏览索引配置在包含条目的后缀的数据库配置中进行定义。
$ ldapmodify -a -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=people_browsing_index, cn=database-name, cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: vlvSearch cn: Browsing ou=People vlvBase: ou=People,dc=example,dc=com vlvScope: 1 vlvFilter: (objectclass=inetOrgPerson) dn: cn=Sort rev employeenumber, cn=people_browsing_index, cn=database-name,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: vlvIndex cn: Sort rev employeenumber vlvSort: -employeenumber ^D
$ ldapmodify -a -h host -p port -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Sort sn givenname uid, cn=people_browsing_index, cn=database-name,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: vlvIndex cn: Sort sn givenname uid vlvSort: sn givenname uid ^D
重新生成浏览索引
第 13 章 目录服务器属性值唯一性UID 唯一性插件可确保给定属性的值在目录或子树的所有条目中是唯一的。如果某个操作尝试添加包含给定属性现有值的条目，此插件将会停止该操作。如果某个操作添加目录中已存在的值，或者将属性值修改为目录中已存在的值，此插件也会停止该操作。
默认情况下将禁用 UID 唯一性插件。启用此插件时，默认情况下可确保 uid 属性的唯一性。您可以创建此插件的新实例，以便在其他属性上实现属性值唯一性。UID 唯一性插件可确保单个服务器上的属性值唯一性。
本章包含以下主题：
属性值唯一性概述UID 唯一性插件是预操作插件。在服务器执行目录更新之前，它将检查 LDAP 添加、修改和修改 DN 操作。此插件可确定操作是否会导致两个条目具有相同的属性值。如果相同，服务器将终止此操作，并向客户端返回错误 19 LDAP_CONSTRAINT_VIOLATION。
可以对此插件进行配置，以便在目录的一个或多个子树中或特定对象类的条目之间实现唯一性。此配置可确定要实现属性值唯一性的条目集。
如果要实现其他属性的唯一性，则可以定义多个 UID 唯一性插件的实例。请为每个必须具有唯一值的属性定义一个插件实例。还可以为同一属性定义多个插件实例，以便在多个条目集中“分别”实现唯一性。给定的属性值在每个子树集中只允许一次。
在现有目录上启用属性唯一性时，服务器不会检查现有条目间的唯一性。只有在添加条目或者添加或修改属性时才实现唯一性。
默认情况下将禁用 UID 唯一性插件，因为此插件会影响多主复制。使用复制时可以启用 UID 唯一性插件，但您应该了解将唯一性插件用于复制中描述的内容。
实现 和其他属性的唯一性本部分说明如何为 uid 属性启用和配置默认唯一性插件，以及如何实现任何其他属性的唯一性。
实现 uid 属性的唯一性
此过程说明如何使用 dsconf 命令启用和配置 UID 唯一性插件。此插件配置条目的 DN 为 cn=uid uniqueness,cn=plugins,cn=config。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
使用 DSCC 时，不得修改默认的 UID 唯一性插件以实现其他属性的唯一性。如果不需要使用 UID 唯一性插件，请将此插件保留为禁用状态，并为其他属性创建新的插件实例，如实现其他属性的唯一性中所述。
$ dsconf enable-plugin -h host -p port "uid uniqueness"
$ dsconf set-plugin-prop -h host -p port "uid uniqueness" argument:uid argument:subtreeBaseDN
$ dsconf set-plugin-prop -h host1 -p 1389 "uid uniqueness" argument:uid \ argument:dc=People,dc=example,dc=com
$ dsconf set-plugin-prop -h host -p port "uid uniqueness" argument:uid \ argument:subtreeBaseDN argument:subtreeBaseDN
$ dsconf set-plugin-prop -h host -p port "uid uniqueness" argument:attribute=uid \ argument:markerObjectClass=baseObjectClass argument:entryObjectClass=baseObjectClass
$ dsconf set-plugin-prop -h host -p port "uid uniqueness" argument+:argument-value
实现其他属性的唯一性
UID 唯一性插件可用于实现任何属性的唯一性。您必须在目录的 cn=plugins,cn=config 下创建新条目，以创建此插件的新实例。
无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。
$ dsconf create-plugin -h host -p port -H lib-path -F init-func \ -Y type plugin-name
$ dsconf create-plugin -h host1 -p 1389 -H /opt/SUNWdsee/ds6/lib/uid-plugin.so \ -F NSUniqueAttr_Init -Y preoperation "mail uniqueness"
$ dsconf set-plugin-prop -h host -p port plugin-name property:value
$ dsconf set-plugin-prop -h host1 -p 1389 "mail uniqueness" \ desc:"Enforce unique attribute values..." version:6.0 \ vendor:"Sun Microsystems, Inc." depends-on-type:database
$ dsconf enable-plugin -h host -p port plugin-name
$ dsconf set-plugin-prop -h host -p port plugin-name argument:attribute-name \ argument:subtreeBaseDN argument:subtreeBaseDN...
$ dsconf set-plugin-prop -h host -p port plugin-name argument+:argument-value
$ dsconf set-plugin-prop -h host -p port plugin-name argument:attribute=attribute-name \ argument:markerObjectClass=baseObjectClass argument:requiredObjectClass=entryObjectClass将唯一性插件用于复制
将更新作为复制操作的一部分执行时，UID 唯一性插件不会对属性值执行任何检查。这不会影响单主复制，但此插件无法为多主复制自动实现属性唯一性。
单主复制方案
由于客户端应用程序所做的全部修改都在主副本上执行， 因此应该在主服务器上启用 UID 唯一性插件。应该将此插件配置为在复制的后缀中实现唯一性。由于主服务器可确保必需属性的值是唯一的，因此您不必在使用方服务器上启用此插件。
在单个主服务器的使用方上启用 UID 唯一性插件不会影响复制或普通的服务器操作。但是，它可能会导致性能略微下降。
多主复制方案
UID 唯一性插件不适用于多主复制方案。由于多主复制使用宽松的一致性复制模型，因此即使在两个服务器上都启用了此插件，也不会检测到同时在这两个服务器上添加相同属性值的操作。
但是，如果要执行唯一性检查的属性是命名属性，并且在所有主服务器上的相同子树中为同一属性启用了 UID 唯一性插件，则可以使用此唯一性插件。
满足上述条件时，在复制时会将一致性冲突报告为命名冲突。命名冲突必须手动解决。有关详细信息，请参见解决常见复制冲突。
第 14 章 目录服务器日志记录本章介绍如何管理目录服务器日志。
本章包含以下主题：
日志分析工具Directory Server Resource Kit 提供了日志分析工具 logconv，使用该工具可以分析目录服务器访问日志。日志分析工具可提取使用情况统计信息。此外，它还可以统计重要事件发生的次数。有关此工具的详细信息，请参见 logconv(1) 手册页。
查看目录服务器日志可以在服务器上的默认 instance-path/logs 文件中直接查看日志。如果修改了默认路径，可以使用 dsconf 命令来查找日志文件位置，如下所示：
$ dsconf get-log-prop -h host -p port log-type path
或者，也可以通过目录服务控制中心 (Directory Service Control Center, DSCC) 查看日志文件。使用 DSCC 可查看日志条目并对其进行排序。
下图显示了 DSCC 中的目录服务器访问日志样例。
图 14–1 DSCC 访问日志
跟踪目录服务器日志
可以使用 dsadm 命令来显示目录服务器日志中指定数量的行，或者显示晚于指定期限的日志条目。此示例跟踪错误日志。要跟踪访问日志，请使用 show-access-log 而不是 show-error-log。
配置目录服务器日志可以对日志文件的许多方面进行修改。以下提供了一些示例：
-
起用审计日志
与访问日志和错误日志不同，默认情况下不启用审计日志。有关信息，请参见启用审计日志。
-
常规设置
-
启用或禁用日志记录
-
启用或禁用日志缓冲
-
日志文件位置
-
详细日志记录
-
日志级别
-
-
日志轮转设置。
-
定期创建新日志
-
创建新日志文件前的最大日志文件大小
-
-
日志删除设置
-
删除前的最大文件存留期
-
删除前的最大文件大小
-
删除前的最小可用磁盘空间
-
以下过程介绍如何修改日志配置以及如何启用审计日志。
修改日志配置
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
启用审计日志
与访问日志和错误日志不同，默认情况下不启用审计日志。在查看审计日志之前，必须先启用审计日志。
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
手动轮转目录服务器日志如果日志变得很大，则可以随时手动轮转日志。轮转将备份现有日志文件并创建新的日志文件。
手动轮转日志文件
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
第 15 章 目录服务器监视本章介绍如何在目录服务器中设置和管理监视。
本章包含以下主题：
为目录服务器设置 SNMP本部分介绍如何将服务器设置为通过 SNMP 进行监视。
设置 SNMP
对于此过程的某些部分，可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。此过程的其他部分只能使用命令行完成。
启用 Java ES MF 监视如果使用 Sun Java ES 管理框架 (Java ES Management Framework, Java ES MF) 进行监视，则必须启用 Java ES MF 插件。
有关管理 Java ES MF 的详细信息，请参见《Sun Java Enterprise System 5 Monitoring Guide》。
启用 Java ES MF 监视
可使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。
Java ES MF 监视故障排除 使用 监视服务器可以通过 DSCC 获取服务器状态、复制状态、资源使用情况以及其他监视信息。
此外，还可以通过对以下条目执行搜索操作，从任何 LDAP 客户端监视目录服务器的当前活动：
