适用范围 SUSE Linux Enterprise Server 15 SP3

6 389 LDAP Directory Server #

轻量级目录访问协议 (LDAP) 是设计用来访问和维护信息目录的协议。LDAP 可用于执行多种任务，例如用户和组管理、系统配置管理和地址管理。在 SUSE Linux Enterprise Server 15.3 中，LDAP 服务由取代了 OpenLDAP 的 389 Directory Server 提供。

理想情况下，中心服务器会将数据储存在一个目录中，并使用明确定义的协议将其分发到所有客户端。结构化数据使各种应用程序都能对其进行访问。中心储存库减少了必要的管理工作。利用 LDAP 这样的标准化开放协议可以确保尽可能多的客户端应用程序都能访问这些信息。

这里所说的目录实际上是指一种经过优化能够快速有效地读取和搜索的数据库。储存在此目录中的数据类型往往会长期保留，且不会经常更改。这样，便可以针对高性能的并发读取优化 LDAP 服务，而传统数据库的优化目的是在短时间内接受大量的数据写入。

6.1 LDAP 目录树的结构 #

本节介绍 LDAP 目录树的布局，并提供 LDAP 相关的基本术语。如果您熟悉 LDAP，请继续阅读第 6.2.1 节 “设置新的 389 Directory Server 实例”。

LDAP 目录具有树形结构。目录中的所有项（称为对象）在此层次结构中都有确定的位置。此层次结构称为目录信息树 (DIT)。所需项的完整路径（可以明确标识该项）称为判别名 (DN)。树中的对象由其相对判别名 (RDN) 标识。判别名是基于项路径中的所有项的 RDN 构建的。

LDAP 目录树中的关系在下例中尤为明显，如图 6.1 “LDAP 目录的结构”所示。

图 6.1︰ LDAP 目录的结构 #

完整的图是一个虚构的目录信息树。其中描述了三个层次上的项。每个项对应于图中的一个框。在本例中，虚构的雇员 Geeko Linux 的完整有效判别名为 cn=Geeko Linux,ou=doc,dc=example,dc=com。该名称是通过将 RDN cn=Geeko linux 添加到前一项的 DN ou=doc,dc=example,dc=com 而构成的。

可储存在 DIT 中的对象类型是按照纲要全局确定的。对象类型由对象类决定。对象类确定必须或可以指派给相关对象的属性。纲要包含 LDAP 服务器可以使用的所有对象类和属性。属性是结构化数据类型。其语法、顺序和其他行为由纲要定义。LDAP 服务器会提供一组可在各种环境中工作的核心纲要。如果您需要使用自定义纲要，可以将其上载到 LDAP 服务器。

表 6.1 “常用对象类和属性”提供了示例中所用 00core.ldif 和 06inetorgperson.ldif 中的对象类的简单概述，包括必需的属性（必需属性）和有效的属性值。安装 389 Directory Server 后，可在 usr/share/dirsrv/schema 中找到这些信息。

表 6.1︰常用对象类和属性 #

对象类	含义	示例项	必需属性
`域`	域的名称组成部分	示例	displayName
`organizationalUnit`	组织单元	doc	ou
`nsPerson`	内部网或因特网中与个人相关的数据	Geeko Linux	cn

例 6.1 “CN=schema 的摘录”显示了某个纲要指令的摘录及其解释。

例 6.1︰ CN=schema 的摘录 #

attributetype (1.2.840.113556.1.2.102 NAME 'memberOf' 1
       DESC 'Group that the entry belongs to' 2
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 3
       X-ORIGIN 'Netscape Delegated Administrator') 4

objectclass (2.16.840.1.113730.3.2.333 NAME 'nsPerson' 5
       DESC 'A representation of a person in a directory server' 6
       SUP top STRUCTURAL 7
       MUST ( displayName $ cn ) 8
       MAY ( userPassword $ seeAlso $ description $ legalName $ mail \
             $ preferredLanguage ) 9
       X-ORIGIN '389 Directory Server Project'
  ...

1	属性的名称、其唯一对象标识符（OID，数字格式）和属性的缩写。
2	通过 `DESC` 对该属性提供的简要说明。在此还可以指出定义所基于的相应 RFC。
3	可保存在该属性中的数据类型。在本例中，它是一个不区分大小写的目录字符串。
4	纲要元素（例如项目的名称）的来源。
5	对象类 `nsPerson` 的定义以 OID 以及该对象类的名称开头（与属性的定义类似）。
6	对象类的简要说明。
7	`SUP top` 项指示此对象类不从属于另一个对象类。
8	`MUST` 列出必须对 `nsPerson` 类型的对象使用的所有属性类型。
9	`MAY` 列出可选择对此对象类使用的所有属性类型。

6.2 安装 389 Directory Server #

使用以下命令进行安装：

tux > sudo zypper install 389-ds

此命令将安装 389-ds 和 lib389 packages.安装后，按照第 6.2.1 节中所述设置服务器。

6.2.1 设置新的 389 Directory Server 实例 #

您需使用 dscreate 命令来创建新的 389 Directory Server 实例，并使用 dsctl 命令彻底去除这些实例。

可以基于自定义配置文件以及基于自动生成的模板文件这两种方式来配置和创建新实例。对于测试实例，您可以使用自动生成的模板，而无需进行任何更改，不过，对于生产系统，则必须仔细检查该模板并进行任何必要的更改。

然后，您需要设置管理身份凭证，管理用户和组，并配置身份服务。

执行以下步骤可设置一个用于测试和开发的简单实例，并在其中填充少量的示例项。

389 目录服务器由三个主要命令控制：

dsctl: 管理本地实例，需要 root 权限。要求您连接到运行目录服务器实例的终端。用于启动、停止和备份数据库以及进行其他操作。
dsconf: 用于管理和配置服务器的主要工具。可通过实例的外部接口管理其配置。这样，您便可以在该实例上远程更改配置。
dsidm: 用于身份管理（管理用户、组、口令等）。权限由访问控制授予，因此，举例而言，用户可以重设置自己的口令或更改自己帐户的细节。

6.2.2 使用自定义配置文件创建 389 Directory Server 实例 #

您可以基于一个简单的自定义配置文件创建新的 389 Directory Server 实例。此文件必须采用 INF 格式，您可以对其随意命名。

默认实例名称为 localhost。创建实例后，便无法更改实例名称。您最好创建自己的实例名称，而不要使用默认名称，这样可避免混淆并更容易理解实例的工作方式。

例 6.2 显示了一个可用于创建新 389 Directory Server 实例的示例配置文件。您可以复制并使用此文件，不过，请务必创建您自己的口令。

将下面的示例文件 ldap1.inf 复制到您的主目录：

例 6.2︰最小 389 Directory Server 实例的配置文件 #

# ldap1.inf
        
[general]
config_version = 2 1

[slapd]
root_password = password2
self_sign_cert = True 3
instance_name = ldap1

[backend-userroot]
sample_entries = yes 4
suffix = dc=ldap1,dc=com

1	此行为必需的指令，指示这是版本 2 的 INF 设置文件。
2	为 LDAP 用户 `cn=Directory Manager` 创建 `root_password`。此用户用于连接（绑定）到目录。
3	在 `/etc/dirsrv/slapd-instance-name` 中创建自我签名的服务器证书。
4	在新实例中填充示例用户和组项。

要根据例 6.2 创建 389 Directory Server 实例，请运行以下命令：
```
tux > sudo dscreate -v from-file ldap1.inf | tee ldap1-output.txt
```
这会显示创建实例期间发生的所有活动，将所有消息储存在 ldap1-output.txt 中，并在大约一分钟内创建一个正常工作的 LDAP 服务器。详细输出包含大量有用的信息。如果您不想保存这些信息，请删除该命令的 | tee ldap1-output.txt 部分。
如果 dscreate 命令失败，会显示消息告诉您原因。更正所有问题后，去除该实例（参见步骤 5）并创建新实例。
成功安装后，系统会报告“已完成 ldap1 的安装”。检查新服务器的状态：
```
tux > sudo dsctl ldap1 status
Instance "ldap1" is running
```
以下命令可用于彻底去除实例。第一条命令执行试运行，而不会去除实例。当您确定要去除时，请结合 --do-it 选项使用第二条命令：
```
tux > sudo dsctl ldap1 remove
Not removing: if you are sure, add --do-it

tux > sudo dsctl ldap1 remove --do-it
```
此命令还会去除未完整安装的或已损坏的实例。您可以放心地按所需的频率创建和去除实例。

如果您忘记了实例的名称，可使用 dsctl 列出所有实例：

tux > /usr/sbin/dsctl -l
slapd-ldap1

6.2.3 基于模板创建 389 Directory Server 实例 #

您可以使用 dscreate 命令为新 389 Directory Server 实例自动创建模板。这会创建一个无需进行任何更改即可使用的模板，您也可以根据自己的要求更改此模板。所有默认值在模板文件中都有说明，并已注释掉。要进行更改，请取消注释默认值并输入您自己的值。所有选项都有详细的说明。

下面的示例会将模板输出到 stdout：

tux > dscreate create-template

这有助于快速检查模板，但是，您必须创建一个文件用于创建新 389 Directory Server 实例。您可以对此文件随意命名：

tux > dscreate create-template ldap1-template.txt

下面是新文件中的代码段：

# full_machine_name (str)
# Description: Sets the fully qualified hostname (FQDN) of this system. When 
# installing this instance with GSSAPI authentication behind a load balancer, set 
# this parameter to the FQDN of the load balancer and, additionally, set 
# "strict_host_checking" to "false".
# Default value: ldapserver1.test.net
;full_machine_name = ldapserver1.test.net

# selinux (bool)
# Description: Enables SELinux detection and integration during the installation 
# of this instance. If set to "True", dscreate auto-detects whether SELinux is 
# enabled. Set this parameter only to "False" in a development environment.
# Default value: True 
;selinux = True

从中可以了解它是如何根据现有环境自动配置默认值的。按原样使用此文件来创建一个新实例：

tux > sudo dscreate from-file ldap1-template.txt

这会创建一个名为 localhost 的新实例，并在创建后自动启动该实例：

tux > sudo dsctl localhost status
Instance "localhost" is running

使用默认值会创建一个完全可正常运行的实例，不过您也可以更改某些值。

创建实例后，便无法更改实例名称。您最好创建自己的实例名称，而不要使用默认名称，这样可避免混淆并更容易理解实例的工作方式。为此，请取消注释 ;instance_name = localhost 行，并将 localhost 更改为所需的名称。在以下示例中，实例名称为 ldap1。

另一项有用的更改是在新实例中填充示例用户和组。取消注释 ;sample_entries = no，并将 no 更改为 yes。

通过取消注释 ;root_password 并将默认口令替换为您自己的口令来设置口令。

模板不会创建默认后缀，因此您应在 suffix 行中配置自己的后缀，如下例所示：

suffix = dc=ldap1,dc=com

可以使用 dsctl 彻底去除任何实例，然后重新开始创建：

tux > sudo dsctl ldap1 remove --do-it

6.2.4 停止和启动 389 Directory Server #

使用 systemd 管理 389 Directory Server 实例。获取服务器状态：

tux > systemctl status --no-pager --full dirsrv@ldap1.service       
   ● dirsrv@ldap1.service - 389 Directory Server ldap1.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-03-11 08:55:28 PST; 2h 7min ago
    Process: 4451 ExecStartPre=/usr/lib/dirsrv/ds_systemd_ask_password_acl /etc/dirsrv/slapd-ldap1/dse.ldif (code=exited, status=0/SUCCESS)
   Main PID: 4456 (ns-slapd)
     Status: "slapd started: Ready to process requests"
      Tasks: 26
     CGroup: /system.slice/system-dirsrv.slice/dirsrv@ldap1.service
             └─4456 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-ldap1 -i /run/dirsrv/slapd-ldap1.pid

启动和停止服务器：

tux > sudo systemctl start dirsrv@ldap1.service
tux > sudo systemctl stop dirsrv@ldap1.service

有关使用 systemctl 的详细信息，请参见第 15 章 “systemd 守护程序”。

dsctl 命令还可启动和停止服务器：

tux > sudo dsctl ldap1 status
tux > sudo dsctl ldap1 stop
tux > sudo dsctl ldap1 restart
tux > sudo dsctl ldap1 start

6.2.5 配置用于本地管理的管理员身份凭证 #

要对 389 Directory Server 进行本地管理，您可以在 /root 目录中创建一个 .dsrc 配置文件，这样 root 和 sudo 用户管理服务器时就不必每运行一条命令都要键入连接细节。例 6.3 显示了在服务器上进行本地管理的示例，其中使用了 ldap1 和 com 作为基本 DN。

创建 /root/.dsrc 文件后，请尝试运行几条管理命令，例如创建新用户（参见第 6.4 节 “管理 LDAP 用户和组”）。

例 6.3︰用于本地管理的 .dsrc 文件 #

# /root/.dsrc file for administering the ldap1 instance
         
[ldap1] 1

uri = ldapi://%%2fvar%%2frun%%2fslapd-ldap1.socket 2
basedn = dc=ldap1,dc=com
binddn = cn=Directory Manager

此处必须指定确切的实例名称。

ldapi 将检测尝试登录到服务器的用户的 UID 和 GID。如果 UID/GID 为 0/0 或 dirsrv:dirsrv，则 ldapi 会将该用户绑定为目录服务器根 DN，即 cn=Directory Manager。

在 URI 中，斜杠将替换为 %%2f，因此在本示例中，路径为 /var/run/slapd-ldap1.socket。

6.3 防火墙配置 #

389 Directory Server 的默认 TCP 端口为 389 和 636。TCP 端口 389 用于建立未加密连接，以及用于 STARTTLS。端口 636 用于通过 TLS 建立加密连接。

firewalld 是 SUSE Linux Enterprise 的默认防火墙管理器。以下规则会激活 ldap 和 ldaps 防火墙服务：

tux > sudo firewall-cmd --add-service=ldap --zone=internal
tux > sudo firewall-cmd --add-service=ldaps --zone=internal
tux > sudo firewall-cmd --runtime-to-permanent

请将 zone 替换为您服务器的相应区域。有关使用 TLS 保护连接的信息，请参见第 6.8 节 “使用 TSL 的 CA 证书”；有关 firewalld 的信息，请参见第 24.3 节 “防火墙基础知识”。

6.4 管理 LDAP 用户和组 #

通过 dsidm 命令来创建并管理用户和组。该命令以交互方式运行，或者，您也可以在命令行上运行，并在一条命令中输入所有选项。

列出现有的用户和组：

tux > sudo dsidm ldap1 user list
tux > sudo dsidm ldap1 group list

列出有关单个用户的所有信息：

tux > sudo dsidm ldap1 user get username

列出有关单个组的所有信息：

tux > sudo dsidm ldap1 group get groupname

列出组的成员：

tux > sudo dsidm ldap1 group members demo_group

在下面的示例中，我们通过命令行参数指定相应数据来添加两个用户：wilber 和 geeko。示例服务器实例名为 ldap1，该实例的后缀为 dc=ldap1,dc=com。

过程 6.1︰创建 LDAP 用户 #

LDAP 用户是已经存在的用户。他们应具有 Linux 系统帐户、Linux 登录名和主目录。将这些用户添加到您的 LDAP 服务器可集中管理您网络中的用户。您需要输入准确的用户数据，这些信息可通过以下方式来获取：访问存放这些用户帐户的计算机，然后运行 id 命令，如以下针对 Wilber Fox 的命令示例所示：

tux > id geeko
uid=1001(wilber) gid=101(users) groups=101(users)

创建 LDAP 用户 wilber：

tux > sudo dsidm ldap1 user create --uid wilber \
  --cn wilber --displayName 'Wilber Fox' --uidNumber 1001 --gidNumber 101 \
  --homeDirectory /home/wilber

通过查询新用户的判别名（目录对象的完全限定名称，能够确保唯一）进行校验：
```
tux > sudo dsidm ldap1 user get wilber
dn: uid=wilber,ou=people,dc=ldap1,dc=com
[...]
```
执行更改用户口令等操作时需要用到判别名。
为新用户 wilber 创建口令：
1. ```
tux > sudo dsidm ldap1 account reset_password \
  uid=wilber,ou=people,dc=ldap1,dc=com
```
2. 输入 wilber 的新口令两次。
  如果操作成功，您将看到以下消息：
```
reset password for uid=wilber,ou=people,dc=ldap1,dc=com
```
  使用相同的命令更改现有口令。

创建用户 geeko：

tux > sudo dsidm ldap1 user create --uid geeko\
  --cn geeko --displayName 'Suzanne Geeko' \
  --uidNumber 1002 --gidNumber 102 --homeDirectory /home/geeko
  
tux > sudo dsidm ldap1 account reset_password \
  uid=geeko,ou=people,dc=ldap1,dc=com

校验用户的口令是否有效：

tux > ldapwhoami -D uid=geeko,ou=people,dc=ldap1,dc=com -W
Enter LDAP Password: 
dn: uid=geeko,ou=people,dc=ldap1,dc=com

以下示例会删除用户 wilber：

tux > sudo dsidm ldap1 user delete 
   Enter dn to delete : uid=wilber,ou=people,dc=ldap1,dc=com
   Deleting nsUserAccount uid=wilber,ou=people,dc=ldap1,dc=com :
   Type 'Yes I am sure' to continue: Yes I am sure
   Successfully deleted uid=wilber,ou=people,dc=ldap1,dc=com

过程 6.2︰创建 LDAP 组并将用户指派到其中 #

在以下示例中，我们将创建 server_admins 组，并将 wilber 用户指派到此组。示例服务器实例名为 ldap1，该实例的后缀为 dc=ldap1,dc=com。

创建组：

tux > sudo dsidm ldap1 group create

系统会提示您输入组名。输入所选的组名：

Enter value for cn : server_admins

将用户 wilber 添加到该组：

tux > sudo dsidm ldap1 group add_member server_admins uid=wilber,ou=people,dc=ldap1,dc=com
added member: uid=wilber,ou=people,dc=ldap1,dc=com

6.5 设置 SSSD #

SSSD（系统安全服务守护程序）是一个与远程身份提供者通讯并允许 pam 和 nsswitch 使用该数据的守护程序。SSSD 可以有多个后端，可缓存用户和组并提供 SSH 密钥分发等功能。

在单独的服务器上安装 sssd 和 sssd-ldap 软件包：
```
tux > sudo zypper in sssd sssd-ldap
```
禁用并停止 nscd 守护程序，因为它与 sssd 相冲突：
```
tux > sudo systemctl disable nscd && systemctl stop nscd
```
创建 SSSD 配置，并仅允许我们在过程 6.2 中创建的 server_admins 组的成员登录：
提示
需要启用 memberOf 插件，以使客户端能够登录和授权（参见第 6.6 节 “管理模块”）。
```
tux > sudo dsidm localhost client_config sssd.conf server_admins
```
查看输出并将其粘贴（或重定向）到 /etc/sssd/sssd.conf。必要时，请根据需要编辑配置文件。

要在您的客户端上配置证书，请将 LDAP 服务器中的 ca.crt 复制到您的客户端：

tux > sudo mkdir -p /etc/openldap/certs
cp [...]>/ca.crt /etc/openldap/certs/
/usr/bin/c_rehash /etc/openldap/certs

启用并启动 SSSD：

tux > sudo systemctl enable sssd
systemctl start sssd

为确保 SSSD 成为 PAM 和 NSS 的一部分，请遵照 https://www.port389.org/docs/389ds/howto/howto-sssd.html 上“Configure PAM (SUSE)”（配置 PAM (SUSE)）和“Configure NSS (SUSE)”（配置 NSS (SUSE)）章节中的说明操作。
您的用户必须拥有自己的 SSH 密钥对，并可通过 SSH 访问您的 SSSD 服务器。如果所有设置均正确无误，wilber 可以通过与安装并配置了 SSSD 的计算机所建立的 SSH 连接访问 389 目录服务器实例。但 geeko 做不到这一点，因为 geeko 不属于我们在过程 6.2 中配置的 server_admins 组。

6.6 管理模块 #

使用以下命令可列出所有已启用和已禁用的可用模块：

tux > sudo dsconf -D "cn=Directory Manager" ldap//:ldapserver1 plug-in list
    Enter password for cn=Directory Manager on ldap://ldapserver1: 
7-bit check
Account Policy Plugin
Account Usability Plugin
ACL Plugin
ACL preoperation
[...]

例如，下面指出了如何启用第 6.5 节 “设置 SSSD”中提到的 MemberOf 插件：

tux > sudo dsconf -D "cn=Directory Manager" ldap://ldapserver1 plugin memberof enable

请注意，插件名称区分大小写，与列出插件时显示的名称不同。启用插件后，需要重启动服务器。要避免重启动服务器，请将 nsslapd-dynamic-plugins 参数设置为 on：

tux > sudo dsconf -D "cn=Directory Manager" ldap://ldapserver1 config replace nsslapd-dynamic-plugins=on
  Enter password for cn=Directory Manager on ldap://ldapserver1: 
Successfully replaced "nsslapd-dynamic-plugins"

6.7 从 OpenLDAP 迁移到 389 Directory Server #

从 SUSE Linux Enterprise 15.3 开始，OpenLDAP 已弃用且不再受支持，它已由 389 Directory Server 取代。SUSE 提供了 openldap_to_ds 实用程序用于帮助迁移，该实用程序包含在 389 Directory Server 软件包中。

openldap_to_ds 实用程序旨在将尽可能多的迁移工作自动化。但是，每个 LDAP 部署各不相同，因此我们无法编写出适合所有情况的工具。您可能需要执行一些手动步骤，并在尝试进行生产迁移之前全面测试您的迁移过程。

6.7.1 测试从 OpenLDAP 迁移 #

OpenLDAP 与 389 Directory Server 的差异相当大，可能需要对迁移进行反复测试和调整。执行快速迁移测试可能会很有帮助，这样可大致了解需要执行哪些步骤才能确保迁移成功。

先决条件:

一个正在运行的 389 Directory Server 实例。
一个采用动态 ldif 格式的 OpenLDAP slapd 配置文件或目录。
OpenLDAP 数据库的 ldif 文件备份。

如果您的 slapd 配置不是动态 ldif 格式，请使用 slaptest 创建动态副本。创建 slapd.d 目录，然后运行以下命令：

tux > sudo slaptest -f /etc/openldap/slapd.conf -F /root/slapd.d

这会生成类似于以下示例的内容：

tux > sudo ls  slapd.d/*
slapd.d/cn=config.ldif

slapd.d/cn=config:
cn=module{0}.ldif  cn=schema.ldif                 olcDatabase={0}config.ldif
cn=schema          olcDatabase={-1}frontend.ldif  olcDatabase={1}mdb.ldif

为每个后缀创建一个 ldif 文件。在以下示例中，后缀为 dc=ldap1,dc=com。如果您使用的是 /etc/openldap/slapd.conf 格式，请运行以下命令创建 ldif 备份文件：

tux > sudo slapcat -f /etc/openldap/slapd.conf -b dc=ldap1,dc=com -l /root/ldap1-com.ldif

对于 /etc/openldap/slapd.d 格式，请使用以下命令：

tux > sudo slapcat -f /etc/openldap/slapd.conf -b dc=ldap1,dc=com -l /root/ldap1-com.ldif

使用 openldap_to_ds 分析配置和文件，并显示迁移计划而不更改任何内容：

tux > sudo openldap_to_ds ldap1 /root/slapd.d ldap1-com.ldif

这会执行试运行，但不更改任何内容。输出如下所示：

Examining OpenLDAP Configuration ...
Completed OpenLDAP Configuration Parsing.
Examining Ldifs ...
Completed Ldif Metadata Parsing.
The following migration steps will be performed:
 * Schema Skip Unsupported Attribute -> otherMailbox (0.9.2342.19200300.100.1.22)
 * Schema Skip Unsupported Attribute -> dSAQuality (0.9.2342.19200300.100.1.49)
 * Schema Skip Unsupported Attribute -> singleLevelQuality (0.9.2342.19200300.100.1.50)
 * Schema Skip Unsupported Attribute -> subtreeMinimumQuality (0.9.2342.19200300.100.1.51)
 * Schema Skip Unsupported Attribute -> subtreeMaximumQuality (0.9.2342.19200300.100.1.52)
 * Schema Create Attribute -> suseDefaultBase (SUSE.YaST.ModuleConfig.Attr:2)
 * Schema Create Attribute -> suseNextUniqueId (SUSE.YaST.ModuleConfig.Attr:3)
[...]
 * Schema Create ObjectClass -> suseDhcpConfiguration (SUSE.YaST.ModuleConfig.OC:10)
 * Schema Create ObjectClass -> suseMailConfiguration (SUSE.YaST.ModuleConfig.OC:11)
 * Database Reindex -> dc=example,dc=com
 * Database Import Ldif -> dc=example,dc=com from example.ldif - excluding entry attributes = [{'structuralobjectclass', 'entrycsn'}]
No actions taken. To apply migration plan, use '--confirm'

以下示例会执行迁移，其输出与试运行后的输出不同：

tux > sudo openldap_to_ds ldap1 /root/slapd.d ldap1-com.ldif --confirm
Starting Migration ... This may take some time ...
migration: 1 / 40 complete ...
migration: 2 / 40 complete ...
migration: 3 / 40 complete ...
[...]
Index task index_all_05252021_120216 completed successfully
post: 39 / 40 complete ...
post: 40 / 40 complete ...
🎉 Migration complete!
----------------------
You should now review your instance configuration and data:
 * [ ] - Create/Migrate Database Access Controls (ACI)
 * [ ] - Enable and Verify TLS (LDAPS) Operation
 * [ ] - Schedule Automatic Backups
 * [ ] - Verify Accounts Can Bind Correctly
 * [ ] - Review Schema Inconistent ObjectClass -> pilotOrganization (0.9.2342.19200300.100.4.20)
 * [ ] - Review Database Imported Content is Correct -> dc=ldap1,dc=com

迁移完成后，openldap_to_ds 会创建必须完成的迁移后任务核对清单。最好记录所有迁移后步骤，以便可以在后期生产过程中再现这些步骤。然后测试客户端和应用程序与迁移后 389 Directory Server 实例的集成。

重要：制定回滚计划

必须制定一个回滚计划，以防发生任何失败。此计划应该定义成功迁移的要素、用于确定哪些方面正常以及哪些方面需要修复的测试、至关重要的步骤、可以推迟的事项、如何确定何时撤消更改、如何在尽量减少服务中断的情况下撤消更改，以及其他哪些团队需要参与迁移。

由于部署的可变性，很难提供成功进行生产迁移的通用方法。一旦您全面测试了迁移过程并确认可以获得较好的结果，就可以采取一些有用的常规步骤：

在做出更改之前的 48 小时将所有主机名/DNS TTL 减少至 5 分钟，以便能够快速回滚到现有的 OpenLDAP 部署。
暂停所有数据同步和传入数据进程，以确保 OpenLDAP 环境中的数据在迁移过程中不会更改。
在迁移之前准备好所有要部署 389 Directory Server 的主机。
准备好测试迁移文档。

6.7.2 规划迁移 #

由于 OpenLDAP 如同一个“零件箱”且高度可自定义，因此无法制定出放之四海皆准的迁移计划。有必要针对 OpenLDAP 和其他集成评估您的当前环境和配置。这包括但不限于：

复制拓扑。
高可用性和负载平衡器配置。
外部数据流（IGA、HR、AD 等）。
配置的叠加组件（389 Directory Server 中的插件）。
客户端配置和预期的服务器功能。
自定义纲要。
TLS 配置。

规划 389 Directory Server 部署的最终大致结果。此项规划包含的内容与上面的列表相同，不过需要将叠加组件替换为插件。评估当前环境并规划您的 389 Directory Server 环境将会是什么样之后，便可以制定迁移计划。建议构建与 OpenLDAP 环境并行的 389 Directory Server 环境，以便可以在两者之间切换。

从 OpenLDAP 迁移到 389 Directory Server 属于单向迁移。两者之间的差异相当大，因此它们不可互操作，并且不存在从 389 Directory Server 到 OpenLDAP 的迁移路径。下表重点指出了两者的主要相似和不同之处。

功能	OpenLDAP	389 Directory Server	兼容
双向复制	SyncREPL	特定于 389 Directory Server 的系统	否
MemberOf	叠加组件	插件	是，仅限简单配置
外部身份验证	代理	-	否
Active Directory 同步	-	Winsync 插件	否
内置纲要	OLDAP 纲要	389 Directory Server 纲要	是，受迁移工具支持
自定义纲要	OLDAP 纲要	389 Directory Server 纲要	是，受迁移工具支持
数据库导入	LDIF	LDIF	是，受迁移工具支持
口令哈希	不确定	不确定	是，支持除 Argon2 以外的所有格式
从 OpenLDAP 复制到 389 Directory Server	-	-	不提供用于复制到 389 Directory Server 的机制
基于时间的一次性口令 (TOTP)	TOTP 叠加组件	-	否，将来可能受支持
entryUUID	OpenLDAP 的组成部分	插件	是

6.8 使用 TSL 的 CA 证书 #

您可以使用以下命令行工具管理 389 目录服务器的 CA 证书：certutil、openssl 和 pk12util。

如要进行测试，您可以使用 dscreate 创建一个自我签名证书。该证书储存在 /etc/dirsrv/slapd-localhost/ca.crt 中。如要进行远程管理，需将该证书复制到某个可读取的位置。对于生产环境，请联系您的组织所选的 CA 机构，并请求服务器证书、客户端证书和根证书。

在执行以下过程之前，请确保符合下述要求：

您拥有可用于建立 TLS 连接的服务器证书和私用密钥。
已设置 NSS（网络安全服务）数据库（例如，使用 certutil 命令设置）。

在可将现有私用密钥和证书导入 NSS（网络安全服务）数据库之前，需要创建私用密钥和服务器证书的捆绑包。这会生成一个 *.p12 文件。

重要：*.p12 文件和友好名称

在创建 PKCS12 捆绑包时，必须将 *.p12 文件中的友好名称进行编码。

请务必使用 Server-Cert 作为友好名称，否则 TLS 连接将会失败，因为 389 目录服务器只会搜索此字符串。

请注意，将 *.p12 文件导入 NSS 数据库后，就无法更改该友好名称。

使用下面的命令可创建包含所需友好名称的 PKCS12 捆绑包：
```
root # openssl pkcs12 -export -in SERVER.crt \
  -inkey SERVER.key -out SERVER.p12 \
  -name Server-Cert
```
请将 SERVER.crt 替换为服务器证书，将 SERVER.key 替换为要捆绑的私用密钥。使用 -out 指定 *.p12 文件的名称。使用 -name 设置要使用的友好名称：Server-Cert。
在可将该文件导入 NSS 数据库之前，需获取该文件的口令。为此，请使用下面的命令：
```
pk12util -i PATH_TO_SERVER.p12 -d sql:PATH_TO_NSS_DB -n Server-cert -W SERVER.p12_PASSWORD
```
然后，您便可在 PATH_TO_NSS_DB 目录下的 pwdfile.txt 文件中找到该口令。
现在，将 SERVER.p12 文件导入 NSS 数据库：
```
pk12util -i SERVER.p12 -d PATH_TO_NSS_DB
```

6.9 更多信息 #

有关 389 目录服务器的详细信息，请参见 https://www.port389.org/docs/389ds/documentation.html 中的上游文档。