pam_env.conf 可用于定义每次调用 pam_env 模块时为用户设置的标准化环境。它允许您使用以下语法预设环境变量：

VARIABLE  [DEFAULT=VALUE]  [OVERRIDE=VALUE]

有关如何使用 pam_env 的典型示例是 DISPLAY 变量的调整，每当发生远程登录时，该变量就会改变。例 2.6 “pam_env.conf”中显示了这一点。

REMOTEHOST  DEFAULT=localhost          OVERRIDE=@{PAM_RHOST}
DISPLAY     DEFAULT=${REMOTEHOST}:0.0  OVERRIDE=${DISPLAY}

第一行将 REMOTEHOST 变量的值设置为 localhost，每当 pam_env 不能确定任何其他值时就会使用该值。DISPLAY 变量又包含 REMOTEHOST 的值。在 /etc/security/pam_env.conf 的注释中可以找到详细信息。

pam_mount 用于在登录期间挂载用户主目录，以及在注销期间从中心文件服务器用来存放所有用户主目录的环境中卸载这些主目录。使用此方法就无需挂载一个完整的 /home 目录（通过该目录可访问所有用户主目录），而是仅挂载即将登录的用户的主目录。

安装 pam_mount 后，/etc/security 中会提供 pam_mount.conf.xml 的模板。在手册页 man 5 pam_mount.conf 中可以找到元素的说明。

可以使用 YaST 完成此功能的基本配置。选择网络设置 › Windows 域成员资格 › 专家设置以添加文件服务器。请参见Book “储存管理指南”, Chapter 20 “Samba”, Section 20.5 “配置客户端”。

注意：LUKS2 支持

cryptsetup 2.0 中已添加了 LUKS2 支持；从 SUSE Linux Enterprise Server 12 SP3 开始，SUSE Linux Enterprise Server 在 pam_mount 中包含了 LUKS2 支持。

可以在 pam_limits 模块将会读取的 limits.conf 中基于用户或组设置系统限制。该文件可让您设置硬限制（即不能超出的限制）和软限制（即可以暂时超出的限制）。有关语法和选项的详细信息，请参见 /etc/security/limits.conf 中的注释。

要使用 YaST 管理 NIS 服务器功能，请以 root 身份运行 zypper in yast2-nis-server 命令来安装 yast2-nis-server 软件包。要为网络配置 NIS 主服务器，请按如下所示继续：

要在网络中配置其他 NIS 从属服务器，请按如下所示继续：

运行某个 YaST 身份验证模块后，您可以使用以下命令检查 SSSD 是否正在运行：

# systemctl status sssd
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Thu 2015-10-23 11:03:43 CEST; 5s ago
   [...]

为了允许用户在身份验证后端不可用时登录，SSSD 将使用其缓存，即使缓存已失效。这种情况会一直持续到后端再次可用。

要使缓存失效，请运行 sss_cache -E（命令 sss_cache 是软件包 sssd-tools 的一部分）。

要去除 SSSD 缓存，请运行：

> sudo systemctl stop sssd
> sudo rm -f /var/lib/sss/db/*
> sudo systemctl start sssd

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

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

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

389 Directory Server 由三个主要命令控制：

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

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

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

例 5.2 显示了一个可用于创建新 389 Directory Server 实例的示例配置文件。您可以复制并按原样使用此文件。

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

> dsctl -l
slapd-LDAP1

可以使用 dscreate 命令为新 389 Directory Server 实例自动创建模板。这会创建一个模板，您可以按原样使用该模板进行测试。对于生产系统，请检查该模板并根据您自己的要求进行更改。默认值在模板文件中都有说明，并已注释掉。要进行更改，请取消注释默认值并输入您自己的值。所有选项都有详细的说明。

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

> dscreate create-template

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

> dscreate create-template 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

它会自动从您的现有环境配置某些选项，例如系统的完全限定域名（在模板中名为 full_machine_name）。按原样使用此文件来创建一个新实例：

> sudo dscreate from-file TEMPLATE.txt

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

> sudo dsctl localhost status
Instance "localhost" is running

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

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

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

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

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

suffix = dc=LDAP1,dc=COM

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

> sudo dsctl LDAP1 remove --do-it

以下示例使用 LDAP1 作为实例名称。使用 systemd 管理 389 Directory Server 实例。获取实例的状态：

> 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

启动、停止和重启动 LDAP 服务器：

> sudo systemctl start dirsrv@LDAP1.service
> sudo systemctl stop dirsrv@LDAP1.service
> sudo systemctl restart dirsrv@LDAP1.service

有关使用 systemctl 的详细信息，请参见Book “管理指南”, Chapter 19 “systemd 守护程序”。

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

> sudo dsctl LDAP1 status
> sudo dsctl LDAP1 stop
> sudo dsctl LDAP1 restart
> sudo dsctl LDAP1 start

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

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

# /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

重要：sudoers.ldap 中的新求反功能

在低于 1.9.9 的 sudo 版本中，sudoers.ldap 中的求反对于 sudoUser、sudoRunAsUser 或 sudoRunAsGroup 属性不起作用。例如：

 # does not match all but joe
# instead, it does not match anyone
sudoUser: !joe

# does not match all but joe
# instead, it matches everyone including Joe
sudoUser: ALL
sudoUser: !joe

在 sudo 1.9.9 和更高版本中，为 sudoUser 属性启用了求反。有关更多信息，请参见man 5 sudoers.ldap。

LDAP 服务器配置位于 /etc/dirsrv/slapd-INSTANCE_NAME 目录中。此目录包含证书、密钥和 dse.ldif 文件。使用 tar 命令创建此目录的压缩备份：

> sudo tar caf \
config_slapd-INSTANCE_NAME-$(date +%Y-%m-%d_%H-%M-%S).tar.gz \
/etc/dirsrv/slapd-INSTANCE_NAME/

注意：可忽略的 tar 错误消息

运行 tar 时，您可能会看到可忽略的信息性消息 tar: Removing leading `/' from member names。

要恢复以前的配置，请将其解压缩到同一目录：

dsctl 命令可创建脱机备份。关闭服务器:

> sudo dsctl INSTANCE_NAME stop
Instance "INSTANCE_NAME" has been stopped

然后使用您的实例名称创建备份。以下示例在 /var/lib/dirsrv/slapd-INSTANCE_NAME/bak/INSTANCE_NAME-DATE 中创建备份存档：

> sudo dsctl INSTANCE_NAME db2bak
db2bak successful

例如，在名为 ldap1 的测试实例上，该命令如下所示：

/var/lib/dirsrv/slapd-ldap1/bak/ldap1-2021_10_25_13_03_17

从此备份进行恢复，并命名包含备份存档的目录：

> sudo dsctl INSTANCE_NAME bak2db \
/var/lib/dirsrv/slapd-INSTANCE_NAME/bak/INSTANCE_NAME-DATE/
bak2db successful

然后启动服务器：

> sudo dsctl INSTANCE_NAME start
Instance "INSTANCE_NAME" has been started

您还可以创建 LDIF 备份：

> sudo dsctl INSTANCE_NAME db2ldif --replication userRoot
ldiffile: /var/lib/dirsrv/slapd-INSTANCE_NAME/ldif/INSTANCE_NAME-userRoot-DATE.ldif
db2ldif successful

使用存档名称恢复 LDIF 备份，然后启动服务器：

> sudo dsctl ldif2db userRoot \
/var/lib/dirsrv/slapd-INSTANCE_NAME/ldif/INSTANCE_NAME-userRoot-DATE.ldif
> sudo dsctl INSTANCE_NAME start

使用 dsconf 创建 LDAP 数据库的联机备份：

> sudo dsconf INSTANCE_NAME backup create
The backup create task has finished successfully

此命令会创建 /var/lib/dirsrv/slapd-INSTANCE_NAME/bak/INSTANCE_NAME-DATE。

恢复该数据库：

> sudo dsconf INSTANCE_NAME backup restore \
/var/lib/dirsrv/slapd-INSTANCE_NAME/bak/INSTANCE_NAME-DATE

以下示例演示如何列出现有的用户和组。这些示例使用实例名称 LDAP1。请将此名称替换为您的实例名称：

> sudo dsidm LDAP1 user list
> sudo dsidm LDAP1 group list

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

> sudo dsidm LDAP1 user get USER

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

> sudo dsidm LDAP1 group get GROUP

列出组的成员：

> sudo dsidm LDAP1 group members GROUP

在以下示例中，我们将创建一个用户，即 wilber。示例服务器实例名为 LDAP1，该实例的后缀为 dc=LDAP1,dc=COM。

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

使用 dsidm 命令可以删除用户、从组中去除用户，以及删除组。以下示例从 server_admins 组中去除示例用户 wilber：

> sudo dsidm LDAP1 group remove_member SERVER_ADMINS \
uid=wilber,ou=people,dc=LDAP1,dc=COM

删除用户：

> sudo dsidm LDAP1 user delete \
uid=wilber,ou=people,dc=LDAP1,dc=COM

删除组:

> sudo dsidm LDAP1 group delete SERVER_ADMINS

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

先决条件:

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

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

这会生成几个类似于以下示例的文件：

> sudo ls /root/slapd.d/*

/root/slapd.d/cn=config.ldif

/root/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 备份文件：

> sudo slapcat -f /etc/openldap/slapd.conf -b dc=LDAP1,dc=COM \
-l /root/LDAP1-COM.ldif

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

> sudo openldap_to_ds LDAP1\
/root/slapd.d /root/LDAP1-COM.ldif.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'

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

> sudo openldap_to_ds LDAP1 /root/slapd.d /root/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 实例的集成。

重要：制定回滚计划

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

由于部署的可变性，很难提供成功进行生产迁移的通用方法。在全面测试迁移过程并确认结果正常后，以下常规步骤将有助于：

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

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

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

389 DS 管理复制的方式不同于其他数据库。复制是异步的，但最终会保持一致。也就是说：

由于 LDAP 属于“小规模写入”，这些因素意味着所有服务器至少符合已知一致状态的公共基线。在此基线的基础上只会发生轻微的变化，因此延迟复制的上述许多特征在日常使用中不会被察觉到。

在设计复制拓扑时请考虑以下因素。

这些因素都会影响您创建拓扑的方式。（有关拓扑示例，请参见第 5.10.3 节 “复制拓扑示例”。）

以下章节提供了使用两到六个 389 Directory Server 节点的复制拓扑示例。拓扑中支持的最大提供者复本数量为 20 个。操作经验表明，实现高效复制的最佳数量最多为 8 个。

5.10.3.1 两个复本 #

 

例 5.4︰ 两个提供者复本 #

 

┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘

例 5.4 “两个提供者复本”中有两个复本（S1 和 S2），它们在彼此之间双向复制，因此它们既是提供者也是使用者。S1 和 S2 可位于不同的数据中心，也可位于同一个数据中心。客户端可以使用 LDAP URI、负载平衡器或 DNS SRV 记录在服务器之间进行平衡。这是可实现高可用性的最简单拓扑。每个服务器需要能够提供 100% 的客户端负载，以防其他服务器出于任何原因脱机。双节点复制一般不足以实现横向读取缩放，因为如果另一个节点脱机，单个节点将处理所有读取请求。

注意：默认拓扑

应将双节点拓扑视为默认拓扑，因为它最容易管理。随着时间的推移，您可以根据需要扩展拓扑。

┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘
   ▲            ▲
   │            │
   ▼            ▼
┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │
└────┘       └────┘

                  ┌────┐       ┌────┐
                  │ S1 │◀─────▶│ S2 │
                  └────┘       └────┘
                     ▲            ▲
                     │            │
   ┌────────────┬────┴────────────┴─────┬────────────┐
   │            │                       │            │
   ▼            ▼                       ▼            ▼
┌────┐       ┌────┐                  ┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │                  │ S5 │◀─────▶│ S6 │
└────┘       └────┘                  └────┘       └────┘

             ┌────┐       ┌────┐
             │ S1 │◀─────▶│ S2 │
             └────┘       └────┘
                │            │
                │            │
   ┌────────────┼────────────┼────────────┐
   │            │            │            │
   ▼            ▼            ▼            ▼
┌────┐       ┌────┐       ┌────┐       ┌────┐
│ S3 │       │ S4 │       │ S5 │       │ S6 │
└────┘       └────┘       └────┘       └────┘

在示例拓扑中可以看到，389 DS 可以在拓扑中充当多个角色。以下列表阐明了术语。

第一个示例使用单个只读服务器设置双节点双向复制，这是一个极简的起点示例。在以下示例中，两个读写节点的主机名分别为 RW1 和 RW2，只读服务器为 RO1。（使用您自己的主机名。）

所有服务器应有一个后缀相同的后端。只有一个服务器 (RW1) 需要数据库的初始副本。

5.10.5.1 配置双节点复制 #

 

以下命令使用主机名 RW1 和 RW2 在双节点设置 (例 5.4 “两个提供者复本”) 中配置读写复本。（使用您自己的主机名。）

警告：创建强复制管理者口令

在安全性和访问权限方面，应以等同于目录管理者的方式来对待复制管理者，应为其创建强口令。

如果您为每个服务器创建不同的复制管理者口令，请务必跟踪哪个口令属于哪个服务器。例如，在 RW1 的复制协议中配置出站连接时，需要将复制管理者口令设置为 RW2 复制管理者口令。

首先配置 RW1：

> sudo dsconf INSTANCE-NAME replication create-manager
> sudo dsconf INSTANCE-NAME replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 1 --bind-dn "cn=replication manager,cn=config"

配置 RW2：

> sudo dsconf INSTANCE-NAME replication create-manager
> sudo dsconf INSTANCE-NAME replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 2 --bind-dn "cn=replication manager,cn=config"

这会创建 RW1 和 RW2 中所需的复制元数据。请注意两个服务器的 replica-id 的差异。这还会创建复制管理者帐户，该帐户拥有复制权限，可以在两个节点之间进行身份验证。

RW1 和 RW2 现在都已配置为包含复制元数据。下一步是为从 RW1 流向 RW2 的出站数据创建第一个协议。

> sudo dsconf INSTANCE-NAME repl-agmt create \
--suffix dc=example,dc=com \
--host=RW2 --port=636 --conn-protocol LDAPS --bind-dn "cn=replication manager,cn=config" \
--bind-passwd PASSWORD --bind-method SIMPLE RW1_to_RW2

只有在完全同步数据库之后，数据才会从 RW1 流向 RW2，这称为初始化或重新初始化。这会重置 RW2 上的所有数据库内容，以便与 RW1 的内容匹配。运行以下命令来触发数据重新初始化：

> sudo dsconf INSTANCE-NAME repl-agmt init \
--suffix dc=example,dc=com RW1_to_RW2

在 RW1 上运行以下命令来检查状态：

> sudo dsconf INSTANCE-NAME repl-agmt init-status \
--suffix dc=example,dc=com RW1_to_RW2

此命令完成后，您应会看到消息 Agreement successfully initialized。如果收到错误消息，请检查错误日志。否则，应会在 RW2 上看到与 RW1 中相同的内容。

最后，为了将这种复制设置为双向复制，请配置一个从 RW2 出站复制到 RW1 的复制协议：

> sudo dsconf INSTANCE-NAME repl-agmt create \
--suffix dc=example,dc=com \
--host=RW1 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd PASSWORD \
--bind-method SIMPLE RW2_to_RW1

现在，在 RW1 或 RW2 上做出的更改将复制到另一个节点。使用以下命令检查任一服务器上的复制状态：

> sudo dsconf INSTANCE-NAME repl-agmt status \
--suffix dc=example,dc=com \
--bind-dn "cn=replication manager,cn=config" \
--bind-passwd PASSWORD RW2_to_RW1

5.10.5.2 配置只读节点 #

 

要创建只读节点，首先请创建复制管理者帐户和元数据。示例服务器的主机名为 RO3：

警告：创建强复制管理者口令

在安全性和访问权限方面，应以等同于目录管理者的方式来对待复制管理者，应为其创建强口令。

如果您为每个服务器创建不同的复制管理者口令，请务必跟踪哪个口令属于哪个服务器。例如，在 RW1 的复制协议中配置出站连接时，需要将复制管理者口令设置为 RW2 复制管理者口令。

> sudo dsconf INSTANCE_NAME replication create-manager
> sudo  dsconf INSTANCE_NAME \
replication enable --suffix dc=EXAMPLE,dc=COM \
--role consumer --bind-dn "cn=replication manager,cn=config"

对于只读复本，请不要提供复本 ID，并将角色设置为 consumer。这会为所有只读复本分配一个特殊的只读复本 ID。创建只读复本后，将 RW1 和 RW2 中的复制协议添加到只读实例。以下示例在 RW1 上运行：

> sudo dsconf INSTANCE_NAME \
repl-agmt create --suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd PASSWORD
--bind-method SIMPLE RW1_to_RO3

以下示例在 RW2 上配置 RW2 与 RO3 之间的复制协议：

> sudo dsconf INSTANCE_NAME repl-agmt create \
--suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd PASSWORD \
--bind-method SIMPLE RW2_to_RO3

完成这些步骤后，可以使用 RW1 或 RW2 在 RO3 上执行数据库初始化。以下示例从 RW2 初始化 RO3：

> sudo dsconf INSTANCE_NAME repl-agmt init
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

dsconf 命令包括一个监视选项。您可以直接在复本上或者从其他主机检查每个复本的状态。以下示例命令在 RW1 上运行，检查两个远程复本的状态，然后检查 RW1 自身的状态：

> sudo dsconf -D "cn=Directory Manager" ldap://RW2 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RO3 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RW1 replication monitor

dsctl 命令有一个 healthcheck 选项。以下示例在本地 389 DS 实例上运行复制状态检查：

> sudo dsctl INSTANCE_NAME healthcheck --check replication

使用 -v（详细程度）选项查看状态检查所检查的内容：

> sudo dsctl -v INSTANCE_NAME healthcheck --check replication

不结合任何选项运行 dsctl INSTANCE_NAME healthcheck，以执行一般性的状态检查。

运行以下命令查看状态检查执行的检查列表：

> sudo dsctl INSTANCE_NAME healthcheck --list-checks
config:hr_timestamp
config:passwordscheme
backends:userroot:cl_trimming
backends:userroot:mappingtree
backends:userroot:search
backends:userroot:virt_attrs
encryption:check_tls_version
fschecks:file_perms
[...]

可以运行一项或多项独立检查：

> sudo dsctl INSTANCE_NAME healthcheck \
--check monitor-disk-space:disk_space tls:certificate_expiration

启用复制后，需要调整 389 Directory Server 备份策略（请参见第 5.4 节 “备份和恢复 389 Directory Server”了解如何创建备份）。如果使用 db2ldif，则必须添加 --replication 标志，以确保备份复制元数据。应备份拓扑中的所有服务器。从备份恢复时，请先恢复拓扑的单个节点，然后将所有其他节点重新初始化为新实例。

可以在维护时段暂停复制，或者在所需的任何时间停止复制。拓扑的节点最多只能在不超过更改日志限制的最大天数内保持脱机（请参见第 5.10.9 节 “ 更改日志 max-age”）。

使用 repl-agmt 命令暂停复制。以下示例在 RW2 上运行：

> sudo dsconf INSTANCE_NAME repl-agmt disable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

以下示例重新启用复制：

> sudo dsconf INSTANCE_NAME repl-agmt enable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

复本可以在更改日志 max-age 选项定义的最大时长内保持脱机。max-age 定义更改日志中任何项的最长期限。系统会自动去除超过 max-age 值的任何项目。

复本恢复联机后，将与其他复本同步。如果脱机时间超过 max-age 值，则复本需要重新初始化，并且会拒绝接受更改或拒绝向其他节点提供更改，因为这些更改可能不一致。以下示例将 max-age 设置为七天：

> sudo dsconf INSTANCE_NAME \
replication set-changelog --max-age 7d \
--suffix dc=EXAMPLE,dc=COM

要去除复本，首先请屏蔽节点，以防止任何传入的更改或读取。然后，找到与要去除的节点建立了传入复制协议的所有服务器并将其去除。以下示例去除 RW2。首先禁用 RW1 上的出站复制协议：

> sudo dsconf INSTANCE_NAME repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW1_to_RW2

在要去除的复本（在以下示例中为 RW2）上，去除所有出站协议：

> sudo dsconf INSTANCE_NAME repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1
> sudo dsconf INSTANCE_NAME repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

停止 RW2 上的实例：

> sudo systemctl stop dirsrv@INSTANCE_NAME.service

然后运行 cleanallruv 命令以从拓扑中去除复本 ID。以下示例在 RW1 上运行：

> sudo dsconf INSTANCE_NAME repl-tasks cleanallruv \
--suffix dc=EXAMPLE,dc=COM --replica-id 2
> sudo dsconf INSTANCE_NAME repl-tasks list-cleanruv-tasks

由于同步的工作方式，此过程只涉及一个 389 Directory Server 和 Active Directory 服务器。Active Directory 服务器必须是完整的域控制器，而不是只读域控制器 (RODC)。在已同步的 DC 上不需要全局目录，因为 389 DS 仅复制域中单个林的内容。

必须首先选择数据流的方向。有三个选项：从 AD 流向 389 DS、从 389 DS 流向 AD，或双向。

注意：不同步口令

无法在 389 DS 与 Active Directory 之间同步口令。这种情况将来可能会有改变，到时会支持从 Active Directory 到 389 DS 的口令流。

您的拓扑如下图所示。389 Directory Server 和 Active Directory 拓扑可能不同，但最重要的因素是 389 DS 与 Active Directory 之间只存在单个连接。请务必在 389 DS 和 AD 的灾难恢复与备份计划中考虑到这一点，以确保仅正确恢复这些拓扑之间的单个复制连接。

┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │◀ ─ ─ ─ ▶│   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘
    ▲               ▲                  ▲             ▲
    │               │                  │             │
    ▼               ▼                  ▼             ▼
┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │         │   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘

需要一个拥有“Replicating Directory Changes”权限的安全组。例如，假设您已创建一个名为 Directory Server Sync 的组，可以按照 How to grant the 'Replicating Directory Changes' permission for the Microsoft Metadirectory Services ADMA service account (https://docs.microsoft.com/en-US/troubleshoot/windows-server/windows-security/grant-replicating-directory-changes-permission-adma-service) 中的步骤设置此权限。

警告：需要强安全性

应该将此组的成员安全性视为与域管理员的安全性同等重要。此组的成员能够从 Active Directory 环境中读取敏感内容，因此您应该为这些帐户使用随机生成的强服务帐户口令，并认真审计此组的成员资格。

还应该创建一个服务帐户作为此组的成员。

您的 Active Directory 环境必须为 LDAPS 配置证书，以确保 389 DS 与 AD 之间的身份验证是安全的。无法将身份验证和通用安全服务 API/Kerberos (GSSAPI/KRB) 结合使用。

必须事先使用组织单位 (OU) 为 389 Directory Server 配置一个后端数据库，以便将项同步到其中。

必须为 389 Directory Server 配置一个复本 ID，使该服务器类似于一个读写复本。（有关设置复制的细节，请参见第 5.10 节 “设置复制”）。

以下示例命令在 389 Directory Server 上运行，它将创建从 Active Directory 到 389 Directory Server 的复制协议：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt create --suffix dc=example,dc=com \
  --host AD-HOSTNAME --port 636 --conn-protocol LDAPS \
  --bind-dn "cn=SERVICE-ACCOUNT,cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --bind-passwd "PASSWORD" --win-subtree "cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --ds-subtree ou=AD,dc=EXAMPLE,dc=COM --one-way-sync fromWindows \
  --sync-users=on --sync-groups=on --move-action delete \
  --win-domain AD-DOMAIN adsync_agreement

创建该协议后，必须执行初始重新同步：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt init --suffix dc=example,dc=com adsync_agreement

使用以下命令检查初始化状态：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt init-status --suffix dc=example,dc=com adsync_agreement

注意：某些项不会同步

在某些情况下，即使初始化状态报告为成功，某个项也可能不会同步。检查 /var/log/dirsrv/slapd-INSTANCE-NAME/errors 中的 389 DS 日志文件。

使用以下命令检查协议状态：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt status --suffix dc=example,dc=com adsync_agreement

对 Active Directory 或 389 Directory Server 拓扑执行维护时，可以使用以下命令来暂停协议：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt disable --suffix dc=example,dc=com adsync_agreement

使用以下命令恢复协议：

> sudo dsconf INSTANCE-NAME repl-winsync-agmt enable --suffix dc=example,dc=com adsync_agreement

在首次接触 Kerberos 时，您的操作与在常规网络系统进行的任何登录过程类似。输入您的用户名。这一信息和票据授权服务的名称被发送到身份验证服务器 (Kerberos)。如果身份验证服务器知道您的身份，它会生成一个随机会话密钥，供以后在客户端和票据授权服务器之间使用。身份验证服务器现在将为票据授权服务器准备一个票据。该票据包含以下信息 － 仅认证服务器和票据授权服务器知道的、由会话密钥加密的所有信息：

随后，还是以加密形式将此票据与会话密钥一起发送回客户端，但这次使用的是客户端的私用密钥。只有 Kerberos 和客户端知道此私用密钥，因为它是从您的用户口令派生的。由于客户端已经收到了此响应，计算机将提示您输入口令。此口令被转换为一个密钥，利用它可解密身份验证服务器所发送的包。然后“拆封”此包，并将口令和密钥从工作站的内存中删除。只要没有超过为用于获取其他票据的那个票据指定的有效期，工作站就能证明您的身份。

要从网络中的任何服务器请求服务，客户端应用程序都需要向服务器证明其身份。因此，此应用程序生成一个身份验证器。身份验证器包含以下部分：

所有这些信息都使用客户端为这个特殊服务器接收到的会话密钥进行了加密。用于服务器的身份验证器和票据会被发送到该服务器。该服务器使用自身的会话密钥副本来解密身份验证器，而身份验证器为它提供与请求其服务的客户端相关的全部所需信息，然后服务器将这些信息与票据中包含的信息进行对比。服务器将检查票据和身份验证器是否来自同一客户端。

如果在服务器端没有采取任何安全措施，则这个阶段的过程将成为重放攻击的理想目标。某些人可能试图重发先前从网络上窃取的请求。为防止出现这种情况，服务器将不接受具有先前已收到过的时间戳和票据的任何请求。忽略时间戳与接收请求时的时间相差太大的请求。

Kerberos 身份验证可以双向使用。它不仅可以验证客户端是否为它所声称的客户端，服务器本身也应能够向请求其服务的客户端身份验证自己。因此，它本身会发送身份验证器。它将在客户端的身份验证器中接收的校验和加 1，然后使用它和客户端共享的会话密钥对其加密。客户端将此响应作为对服务器的真实性的校验，然后它们开始协作。

票据每次仅供一个服务器使用。因此，每当您请求另一个服务时，就需要获取一个新票据。Kerberos 实施了一种机制来获取用于各个服务器的票据。这种服务被称为“票据授权服务”。票据授权服务与前面提到的任何服务一样，也使用已介绍过的相同访问协议。当应用程序需要一个尚未请求过的票据时，就会联系票据授权服务器。此请求包含以下部分：

与任何其他服务器一样，票据授权服务器现在将检查票据授权票据和身份验证器。如果确定它们有效，票据授权服务器将构建一个将在原始客户端和新服务器之间使用的新会话密钥。然后构建用于新服务器的票据，其中包含以下信息：

新票据具有一个有效期，该有效期是票据授权票据的剩余有效期，或服务的默认有效期。系统将指派这两个值中较小的一个。客户端会接收票据授权服务发送的此票据和会话密钥。但这一次，响应已通过原始票据授权票据附带的会话密钥加密。当联系新服务时，客户端可以解密此响应而不需要用户的口令。因此，Kerberos 无需烦扰用户就能获取客户端的一个又一个票据。

任何 Kerberos 环境都必须符合以下要求才能完全正常运行：

下图描绘了一个简单的示例网络，其中仅包含构建 Kerberos 基础架构至少所需的组件。根据您的部署大小和拓扑，您的设置可能与此不同。

图 6.1︰ Kerberos 网络拓扑 #

 

提示：配置子网路由

对于类似于图 6.1 “Kerberos 网络拓扑”中所示的设置，需在两个子网（192.168.1.0/24 和 192.168.2.0/24）之间配置路由。有关使用 YaST 配置路由的详细信息，请参见Book “管理指南”, Chapter 23 “基本网络知识”, Section 23.4.1.5 “配置路由”。

Kerberos 安装的域称为领域，通过一个名称（如 EXAMPLE.COM 或简单的 ACCOUNTING）来标识。Kerberos 区分大小写，因此 example.com 与 EXAMPLE.COM 是不同的领域。您可根据自己的偏好选择使用大小写。但通常的做法是使用大写领域名。

使用您的 DNS 域名（或子域，如 ACCOUNTING.EXAMPLE.COM）也是个不错的选择。如下所示，如果将 Kerberos 客户端配置为通过 DNS 来查找 KDC 和其他 Kerberos 服务，则系统管理员的工作就轻松多了。要做到这一点，将领域名设为 DNS 域名的子域会很有帮助。

与 DNS 名称空间不同，Kerberos 是不分级的。因此，如果您有一个名为 EXAMPLE.COM 的领域，该领域包含名为 DEVELOPMENT 和 ACCOUNTING 的两个“子领域”，这些从属领域不会从 EXAMPLE.COM 继承主体。相反，您拥有的是三个独立的领域，并需要为每个领域配置跨领域的身份验证，使一个领域中的用户能够与另一个领域中的服务器或其他用户交互。

为了便于说明，假设您只为整个组织设置一个领域。在本章剩余部分中，将在所有示例中使用领域名 EXAMPLE.COM。

要使用 Kerberos，首先需要一台用作密钥分发中心（或简称 KDC）的计算机。这台计算机将存储整个 Kerberos 用户数据库，其中包含口令和所有信息。

KDC 是安全基础设施中最重要的部分 － 如果有人侵入，则 Kerberos 保护的所有用户帐户和基础架构都会受到损害。能够访问 Kerberos 数据库的攻击者可以冒充数据库中的任何主体。所以应尽可能提高此计算机的安全性：

要成功使用 Kerberos，应确保您的组织内的所有系统时钟都在给定范围内同步。这一点非常重要，因为 Kerberos 需要防范重放的身份凭证。攻击者可能会在网络上获取 Kerberos 身份凭证，并再使用它们来攻击服务器。Kerberos 采取多种保护措施进行防范。其中之一是在它们的票据中放入时间戳。如果服务器收到的票据的时间戳与当前时间不同，就会拒绝此票据。

Kerberos 在比较时间戳时允许一定的偏差。但计算机时钟的走时可能不准确 — 在一周内快或慢半个小时并不罕见。因此，应对网络上的所有主机进行配置，使它们的时钟与中央时间源同步。

要实现此目的，一种简单的方法就是在一台计算机上安装 NTP 时间服务器，并使所有客户端的时钟与该服务器同步。为此，请在所有这些计算机上以客户端的身份运行 NTP 守护程序 chronyd。KDC 本身也需要与公用时间源同步。由于在此计算机上运行 NTP 守护程序会有安全风险，通过 cron 作业运行 chronyd -q 执行此操作是个不错的选择。要将您的机器配置成 NTP 客户端，如Book “管理指南”, Chapter 38 “使用 NTP 同步时间”, Section 38.1 “使用 YaST 配置 NTP 客户端”中概述的那样继续操作。

另一种保护时间服务并仍旧使用 NTP 守护程序的做法是，将一个硬件参考时钟挂接到专用的 NTP 服务器，并将另一个硬件参考时钟挂接到 KDC。

也可以调整 Kerberos 在检查时间戳时所允许的最大偏差。此值（称为时钟偏差）可以在 krb5.conf 文件中进行设置，请参见第 6.5.6.3 节 “调整时钟偏差”。

本节介绍 KDC 的初始配置和安装，包括创建管理主体。此过程包括几个步骤：

[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 default_realm = example.com
 ticket_lifetime = 24h
 renew_lifetime = 7d

[realms]
  example.com = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }

 [logging]
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 default = SYSLOG:NOTICE:DAEMON

[domain_realm]
 .example.com = example.com
 example.com = example.com

> sudo kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/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:  1
Re-enter KDC database master key to verify:  2

> kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

> kadmin.local

kadmin> ank suzanne

suzanne@EXAMPLE.COM's Password: 1
Verifying password: 2

> sudo systemctl start krb5kdc
sudo systemctl start kadmind

> sudo systemctl enable krb5kdc kadmind

当已部署好支持基础架构（DNS、NTP）且已配置并启动 KDC 时，请配置客户端计算机。要配置 Kerberos 客户端，请使用下面所述的两种手动方法之一。

在配置 Kerberos 时，可以采用两种方法 — 在 /etc/krb5.conf 文件中进行静态配置或通过 DNS 进行动态配置。采用 DNS 配置时，Kerberos 应用程序会尝试使用 DNS 记录查找 KDC 服务。采用静态配置时，将您的 KDC 服务器的主机名添加到 krb5.conf（并在移动 KDC 或以其他方式重配置领域时更新文件）。

基于 DNS 的配置通常比较灵活，而且每台计算机的配置工作量也少得多，但要求您的领域名与您的 DNS 域相同或是它的子域。通过 DNS 配置 Kerberos 也会产生安全问题：攻击者能够通过 DNS 严重破坏您的基础架构（通过使名称服务器无效、窃取 DNS 记录等）。但这最多只会造成拒绝服务攻击。除非在 krb5.conf 中输入 IP 地址而非主机名，否则静态配置也会发生相同的情况。

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

[domain_realm]
.example.com = EXAMPLE.COM
www.example.org = EXAMPLE.COM

_kerberos.www.example.org.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

为了无需直接访问 KDC 控制台即可从 Kerberos 数据库添加和去除主体，请编辑 /var/lib/kerberos/krb5kdc/kadm5.acl 以告知 Kerberos 管理服务器要允许哪些主体执行哪些操作。ACL（访问控制列表）文件可让您以精确的控制度指定特权。有关细节，请使用 man 8 kadmind 来参考手册页。

目前请通过在该文件中插入以下一行向您自己授予管理数据库的特权：

suzanne/admin              *

请将用户名 suzanne 替换为您自己的用户名。重启动 kadmind 以使更改生效。

您现在应该能够使用 kadmin 工具远程执行 Kerberos 管理任务。首先，为您的 admin 角色获得一个票据，并在连接到 kadmin 服务器时使用此票据：

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

使用 getprivs 命令校验您有哪些特权。上面的列表中列出了全部特权。

例如，修改主体 suzanne：

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:

kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" suzanne
Principal "suzanne@EXAMPLE.COM" modified.
kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (suzanne/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

这将票据的最长生命周期更改为 8 小时。有关 kadmin 命令和可用选项的详细信息，请参见 krb5-doc 软件包或 man 8 kadmin 手册页。

到目前为止，我们仅讨论了用户身份凭证。但与 Keberos 兼容的服务也需要向客户端用户验证自己的身份。因此，对于领域中提供的每个服务，Kerberos 数据库中必须存在特殊的服务主体。例如，如果 ldap.example.com 提供 LDAP 服务，则您需要一个服务主体 ldap/ldap.example.com@EXAMPLE.COM，使此服务向所有客户端验证身份。

服务主体的命名约定为 SERVICE/HOSTNAME@REALM，其中 HOSTNAME 是主机的完全限定主机名。

有效的服务描述符为：

服务主体类似于用户主体，但存在一些重大差别。用户主体与服务主体之间的主要差别在于，前者的密钥受口令保护。当用户从 KDC 获取票据授权票据时，他们需要键入其口令，以使 Kerberos 能够解密该票据。如果系统管理员大约每 8 小时就必须为 SSH 守护程序获取一次新的票据，将会很不方便。

实际上，用来解密服务主体的初始票据的密钥是由管理员从 KDC 一次性提取的，并存储在名为 keytab 的本地文件中。SSH 守护程序等服务将读取此密钥并在需要时使用它来自动获取新票据。默认的 keytab 文件位于 /etc/krb5.keytab 中。

要为 jupiter.example.com 创建主机服务主体，请在您的 kadmin 会话期间输入以下命令：

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

-randkey 标志没有为新主体设置口令，而是指示 kadmin 生成一个随机密钥。之所以在这里使用这个标志，是因为此主体不需要用户交互。它是计算机的一个服务器帐户。

最后，抽取密钥并将其存储在本地 keytab 文件 /etc/krb5.keytab 中。这个文件由超级用户拥有，所以您必须是 root 用户才能在 kadmin shell 中执行以下命令：

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

完成后，应确保使用 kdestroy 销毁通过上述 kinit 获得的 admin 票据。

警告：不完整的配置会锁定用户

不完整的 Kerberos 配置可能会将您（包括 root 用户）锁定在系统之外。要防止出现这种情况，请在根据下面所述将 pam_krb5 模块添加到现有的 PAM 配置文件之后，将 ignore_unknown_principals 指令添加到 pam_krb5 模块。

> sudo pam-config --add --krb5-ignore_unknown_principals

这会指示 pam_krb5 模块忽略错误，如不忽略，帐户阶段将会失败。

SUSE® Linux Enterprise Server 随附了一个名为 pam_krb5 的 PAM 模块，该模块支持 Kerberos 登录和口令更新。su 等控制台登录应用程序以及 GDM 等图形登录应用程序可以使用此模块。也就是说，在希望用户输入口令后由身份验证应用程序代表其获取初始 Kerberos 票据的所有场合，都可以使用此模块。要为 Kerberos 配置 PAM 支持，请使用下面的命令：

> sudo pam-config --add --krb5

上述命令将 pam_krb5 模块添加到现有的 PAM 配置文件，并确保以正确的顺序调用该模块。要精细调整 pam_krb5 的使用方式，请编辑文件 /etc/krb5.conf 并将默认应用程序添加到 PAM。有关细节，请使用 man 5 pam_krb5 来参考手册页。

pam_krb5 模块的设计特意不用于接受 Kerberos 票据作为部分用户身份验证的网络服务。这一点很特别，后面将会讨论。

OpenSSH 在协议版本 1 和 2 中均支持 Kerberos 身份验证。在版本 1 中，会通过特殊协议消息传输 Kerberos 票据。版本 2 不再直接使用 Kerberos，而是依赖于 GSSAPI，即通用安全服务 API.这是一种不特定于 Kerberos 的编程接口 － 其设计目的是隐藏基础身份验证系统的特性，无论它是 Kerberos、公共密钥认证系统（如 SPKM）还是其他系统。但是，包含的 GSSAPI 库仅支持 Kerberos。

要将 sshd 与 Kerberos 身份验证配合使用，请编辑 /etc/ssh/sshd_config 并设置以下选项：

# These are for protocol version 1
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

然后使用 sudo systemctl restart sshd 重启动 SSH 守护程序。

要将 Kerberos 认证与协议版本 2 一起使用，需要在客户端也启用它。请在系统范围的配置文件 /etc/ssh/ssh_config 中执行此操作，或者通过编辑 ~/.ssh/config 在每个用户的级别执行此操作。在这两种情况下，都请添加选项 GSSAPIAuthentication yes。

您现在应该能够使用 Kerberos 身份验证进行连接。使用 klist 校验您是否拥有有效票据，然后连接到 SSH 服务器。要强制使用 SSH 协议版本 1，请在命令行上指定选项 -1。

提示：更多信息

/usr/share/doc/packages/openssh/README.kerberos 文件更详细地介绍了 OpenSSH 和 Kerberos 的交互。

提示：协议版本 2 的其他指令

支持 GSSAPIKeyExchange 机制 (RFC 4462)。此指令指定如何交换主机密钥。有关详细信息，请参见 sshd_config 手册页 (man sshd_config)。

Kerberos 提供身份验证，而 LDAP 则用于授权和标识。这两个服务可以配合工作。

为建立安全连接，389 Directory Server 支持以不同的方式加密数据：SSL/TLS 连接、启动 TLS 连接和 SASL 身份验证。简单身份验证和安全层 (SASL) 是用于进行身份验证的网络协议。在 SUSE Linux Enterprise Server 中使用的 SASL 实现是 cyrus-sasl。Kerberos 身份验证是通过 cyrus-sasl-gssapi 软件包提供的 GSS-API（常规安全服务 API）执行的。389 Directory Server 通过 GSS-API 使用 Kerberos 票据对会话进行身份验证和加密数据。

借助 SASL 框架，您可以使用不同的机制向服务器验证用户的身份。在 Kerberos 中，身份验证永远是相互的。这表示您不仅向 389 Directory Server 验证了您自己的身份，389 Directory Server 本身也向您验证了它的身份。具体而言，这表示您是与所需的服务器而不是攻击者设置的随机服务进行通讯。

为了使 Kerberos 能够绑定到 389 Directory Server，请创建一个主体 ldap/ldap.example.com 并将其添加到 keytab。389 Directory Server 用来进行身份验证的身份凭证将由 keytab 提供给其他服务器。389 Directory Server 通过 KRB5_KTNAME 环境变量指派 keytab。

> kinit suzanne@EXAMPLE.COM

> ldapwhoami -Y GSSAPI -H ldap://ldapkdc.example.com
dn: uid=testuser,ou=People,dc=example,dc=com
    

sec=sys 与 Kerberos 安全性级别之间的一个可以察觉到的行为差异与组成员资格相关。在 Unix 和 Linux 中，每个文件系统访问请求都来自某个进程，该进程由特定的用户拥有，并具有特定的组拥有者和多个补充组。对文件的访问权限因拥有者和组而异。

在每个请求中，使用 sec=sys 将 user-id、group-id 以及最多包含 16 个补充组的列表发送到服务器。

如果某个用户是 16 个以上的补充组的成员，超额的组将会丢失，并且在正常情况下用户本应可以访问的文件可能无法通过 NFS 访问。因此，使用 NFS 的大多数站点会通过某种方法将所有用户限制为最多 16 个补充组。

如果用户运行 newgrp 命令或运行 set-group-id 程序，并且该命令或程序可以更改用户所属的组列表，则这些更改会立即生效，并提供 NFS 上的不同访问权限。

使用 Kerberos 时，请求中不会发送组信息。只会标识用户（使用 Kerberos “主体”），服务器将执行查找来确定该主体的用户 ID 和组列表。这意味着，如果用户是 16 个以上的组的成员，则会使用这些组成员资格来确定文件访问权限。但也意味着，如果用户在客户端上更改 group-id，服务器将不会注意到这种更改，并且在确定访问权限时也不会将其纳入考量。

通常，在提供对更多组的访问方面所做的改进能够带来真正的好处，而无法更改组所带来的损失不会被注意到，因为这种做法不太常用。不过，考虑使用 Kerberos 的站点管理员应该了解这种差异，并确保它不会造成问题。

利用 Kerberos 提高安全性需要使用额外的 CPU 资源来加密和解密消息。需要多少额外的 CPU 资源以及差异是否明显取决于所用的硬件和应用程序。如果服务器或客户端已用尽了可用的 CPU 资源，在从 sec=sys 切换到 Kerberos 时，可能会出现相当严重的性能下降。如果还有富余的 CPU 容量，则这种过渡可能不会导致任何吞吐量变化。确定使用 Kerberos 所造成的影响大小的唯一方式是在硬件上测试您的负载。

可以减轻负载的配置选项同时也会降低提供的保护质量。sec=krb5 产生的负载应该明显低于 sec=krb5p，但如前所述，它不能带来强大的安全性。类似地，您可以调整可供 Kerberos 从中选择的口令列表，而这可能会改变 CPU 的要求。但是，默认值是经过精心选择的，如未同样经过谨慎考虑，不应更改这些值。

将 NFS 配置为使用 Kerberos 时可能存在的另一个性能问题涉及到 Kerberos 身份验证服务器（称为 KDC 或密钥分发中心）的可用性。

使用 NFS 会增大此类服务器的负载，程度与对任何其他服务使用 Kerberos 时所增大的负载相同。每当给定的用户（Kerberos 主体）与服务建立会话时（例如，通过访问特定 NFS 服务器导出的文件），客户端就需要与 KDC 协商。协商会话密钥后，客户端与服务器在许多个小时内（此时段取决于 Kerberos 配置的细节，具体而言取决于 ticket_lifetime 设置）无需进一步的帮助即可通讯。

最有可能影响 Kerberos KDC 服务器供应的因素是可用性和峰值用量。

与其他核心服务（例如 DNS、LDAP）或类似的名称查找服务一样，使用两个距离每个客户端都比较“近”的服务器能够在资源有限时提供较佳的可用性。Kerberos 允许使用多个具有灵活模型的 KDC 服务器来进行数据库传播，因此，在校园、建筑物甚至机柜周围按需排布服务器的工作相当简单。确保每个客户端都查找附近的 Kerberos 服务器的最佳机制是对每个建筑物（或类似设施）使用水平分割 DNS 来从 DNS 服务器获取不同的细节。如果这种方法不可行，也可采用在不同的位置管理不同的 /etc/krb5.conf 文件这种替代做法。

由于对 Kerberos KDC 的访问并不频繁，只有在高峰时间，负载才可能会成为一个问题。如果数千人都在 9:00 到 9:05 登录，则服务器每分钟收到的请求数就会比在午夜收到的要多得多。Kerberos 服务器上的负载可能会超过 LDAP 服务器，但不会有数量级的差异。较为合理的准则是采用供应 LDAP 复本的相同方式来供应 Kerberos 复本，然后监视性能以确定需求是否超过容量。

Kerberos KDC 的一个不容易分发的服务是更新处理，例如口令更改和新用户的创建。这些操作必须在单个主 KDC 上进行。

这些更新不太可能会以很高的频率发生，因而不会产生任何繁重负载，但可能出现可用性方面的问题。创建新用户或更改口令可能很麻烦，并且世界另一端的主 KDC 有时会暂时不可用。

如果组织分布于不同地理位置并且其政策规定在每个站点本地处理管理任务，创建多个 Kerberos 域（为每个管理中心创建一个）可能会是比较好的做法。这样每个域都会有位于本地的自己的主 KDC。通过在域之间设置信任关系，一个域中的用户仍可访问另一个域中的资源。

要安排多个域，最轻松的方式是使用一个全局域（例如 EXAMPLE.COM）和本地域（例如 ASIA.EXAMPLE.COM、EUROPE.EXAMPLE.COM）。如果全局域配置为信任每个本地域，并且每个本地域配置为信任全局域，则任何一对域之间都将具有完全可传递的信任，并且任何主体都可以与任何服务建立安全连接。如何确保对资源（例如该服务提供的文件）的适当访问权限取决于所用的用户名查找服务，以及 NFS 文件服务器的功能，这不在本文档的范畴内。

在域加入过程中，服务器和客户端确立安全关系。在客户端上，需要执行以下任务来加入 Windows 域控制器提供的现有 LDAP 和 Kerberos SSO 环境。整个加入过程由 YaST 域成员资格模块来处理，该模块可以在安装过程中运行或在已安装系统中运行：

客户端引导过程中，将启动 winbind 守护程序并检索计算机帐户的初始 Kerberos 票据。winbindd 自动刷新计算机票据以保持其有效。为了跟踪当前的帐户策略，winbindd 定期查询域控制器。

GNOME 的登录管理器 (GDM) 已经过扩展，允许处理 Active Directory 域登录。用户可以选择登录其计算机已加入的主域或主域的域控制器已经与之确立信任关系的可信域之一。

如第 7.2 节 “有关 Linux Active Directory 支持的背景信息”中所述，用户身份验证由多个 PAM 模块调解。如果出现错误，错误代码将转换为用户易于理解的错误消息，这些消息是 PAM 通过任意支持的方法（GDM、控制台和 SSH）在登录时提供的：

在成功的身份验证期间，客户端从 Active Directory 的 Kerberos 服务器中获得票据授权票据 (TGT) 并将其存储在用户的身份凭证缓存中。它还可以在后台续订 TGT，而无需用户的交互。

SUSE Linux Enterprise Server 对 Active Directory 用户提供本地主目录支持。如果按第 7.3 节 “为 Active Directory 配置 Linux 客户端”中所述通过 YaST 进行了配置，当 Windows/Active Directory 用户首次登录到 Linux 客户端时，系统会创建用户主目录。这些主目录的外观与标准的 Linux 用户主目录相同，可独立于 Active Directory 域控制器工作。

使用本地用户主目录可以访问此计算机上的用户数据（即使 Active Directory 服务器断开连接），前提是 Linux 客户端已配置为执行脱机身份验证。

公司环境中的用户必须能够成为漫游用户（例如，切换网络，甚至在断开连接的情况下工作一段时间）。为使用户能够登录断开连接的计算机，已经将大量的缓存集成到 winbind 守护程序。winbind 守护程序即使在脱机状态下都可强制实施口令策略。它跟踪失败的登录尝试次数并根据 Active Directory 中配置的策略做出反应。脱机支持默认处于禁用状态，必须在 YaST 域成员资格模块中显式启用。

当域控制器变成不可用状态时，用户仍可使用断开连接之前获得的有效 Kerberos 票据访问网络资源（不包括 Active Directory 服务器本身），这与在 Windows 中一样。域控制器联机时才能处理口令更改。与 Active Directory 服务器断开连接时，用户无法访问存储在此服务器上的任何数据。当工作站与网络完全断开连接并于稍后再次连接到公司网络时，SUSE Linux Enterprise Server 会在用户锁定再解锁桌面（例如使用桌面屏幕保护程序）时获得新的 Kerberos 票据。

YaST 包含多个可连接 Active Directory 的模块：

YaST 模块用户登录管理支持在 Active Directory 上进行身份验证。此外，它还支持以下相关身份验证和标识提供程序：

要使用 SSSD 以及 YaST 的用户登录管理模块加入 Active Directory 域，请执行以下操作：