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 域成员资格 › 专家设置以添加文件服务器。

注意：LUKS2 支持

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

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

要将 U2F 密钥与您的帐户关联，请按以下步骤操作：

建议使用备份 U2F 设备，可以通过运行以下命令来设置：

为了提高安全性，可以将输出文件从默认位置移到需要 sudo 权限才能修改文件的目录。例如，将其移到 /etc 目录中。为此，请执行以下步骤：

注意：将 u2f_keys 放到非默认位置

如果将输出文件移到默认目录 ($HOME/.config/Yubico/u2f_keys) 以外的目录，则需要在 /etc/pam.d/login 文件中添加相应路径（如第 2.7.2 节 “更新 PAM 配置”所述）。

创建 U2F 密钥配置后，需要调整系统上的 PAM 配置。

运行某个 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 列出所有实例：

> sudo dsctl -l
slapd-LDAP1

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

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

> sudo dscreate create-template

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

> sudo 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.6 节 “管理 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

389 Directory Server 不支持以下插件：

不支持将以下各项作为 dse.ldif 中 nsslapd-rootpwstoragescheme 或 passwordStorageScheme 设置的配置值，也不支持作为帐户策略对象中 passwordStorageScheme 的值：

注意

如果 nsslapd-enable-upgrade-hash 设置为 on（默认为 on），支持包含这些值的数据库导入项。

由于 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 部署中，常会使用 saslauthd 来进行用户的直通身份验证。身份验证过程涉及以下组件：

 ┌─────────────────┐
 │                 │
 │   LDAP client   │
 │                 │
 └─────────────────┘
          │
      binds to
          │
          ▼
 ┌─────────────────┐
 │    OpenLDAP     │
 │     server      │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │    saslauthd    │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │  External auth  │
 │                 │
 └─────────────────┘

为了检查配置的正确性以及以后进行故障排除，务必要了解以下信息：

有关使用 OpenLDAP 的直通身份验证的详细信息，请参见官方 OpenLDAP 管理指南。

  ┌─────────────────┐
  │                 │
  │   LDAP client   │
  │                 │
  └─────────────────┘
           │
       binds to
           │
           ▼
  ┌─────────────────┐
  │     389-DS      │
  │     server      │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │  pam saslauthd  │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │    saslauthd    │
  │                 │
  └─────────────────┘
           │
           │
           ▼
  ┌─────────────────┐
  │                 │
  │  External auth  │
  │                 │
  └─────────────────┘

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

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

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

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

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

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

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

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

5.11.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.11.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.11.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.5 节 “备份和恢复 389 Directory Server”了解如何创建备份）。如果使用 db2ldif，则必须添加 --replication 标志，以确保备份复制元数据。应备份拓扑中的所有服务器。从备份恢复时，请先恢复拓扑的单个节点，然后将所有其他节点重新初始化为新实例。

可以在维护时段暂停复制，或者在所需的任何时间停止复制。拓扑的节点最多只能在不超过更改日志限制的最大天数内保持脱机（请参见第 5.11.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 时存在以下复制限制：

由于同步的工作方式，此过程只涉及一个 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.11 节 “设置复制”）。

以下示例命令在 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 无需烦扰用户就能获取客户端的一个又一个票据。

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 Desktop 对 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 Desktop 会在用户锁定然后解锁桌面（例如使用桌面屏幕保护程序）时获得新的 Kerberos 票据。

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

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

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

要使用 winbind 以及 YaST 的 Windows 域成员资格模块加入 Active Directory 域，请执行以下操作：

加入 Active Directory 域之后，使用桌面上的显示管理器或控制台从工作站登录到该域。

重要：域名

如果域名以 .local 结尾，可能无法成功加入域。以 .local 结尾的名称可能导致与多播 DNS (MDNS) 相冲突，在 MDNS 中，.local 是为链路本地主机名预留的。

注意：只有管理员能够注册计算机

只有域管理员帐户（例如 Administrator）能够将 SUSE Linux Enterprise Desktop 加入 Active Directory。

要检查您是否已成功在 Active Directory 域中注册，请使用以下命令：

要对 Active Directory 服务器进行 GNOME 客户端计算机身份验证，请执行以下操作：

如果已进行相应的配置，SUSE Linux Enterprise Desktop 会在已经过身份验证的每个用户通过 Active Directory 首次登录时，在本地计算机上创建一个用户主目录。这样，您便可以获享 SUSE Linux Enterprise Desktop 的 Active Directory 支持，同时确保您的 Linux 计算机完全正常运行且任您操控。

除了使用图形前端登录到 Active Directory 客户端计算机以外，您还可以使用基于文本的控制台登录，甚至是使用 SSH 远程登录。

要从控制台登录到 Active Directory 客户端，请在 login: 提示符处输入 DOMAIN_NAME\USER_NAME，并提供口令。

要使用 SSH 远程登录到 Active Directory 客户端计算机，请执行以下操作：

Windows 服务器角色 Certification Authority、Certificate Enrollment Policy Web Service、Certificate Enrollment Web Service 和 Network Device Enrollment Service 必须全部已在 Active Directory 服务器上安装并配置。

按照以下 Microsoft 文档中的说明配置组策略自动注册：https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-autoenrollment#configure-server-certificate-auto-enrollment。

按照以下过程所述的步骤在客户端上启用证书。

证书安装在 /var/lib/samba/certs 中，私用密钥安装在 /var/lib/samba/private/certs 中。

有关详细信息，请参见man samba-gpupdate。