Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

B.2. Identity Management Replicas

本指南描述了 Red Hat Enterprise Linux 中身份管理的常见复制问题。
其他资源：
  • 有关如何测试复制是否正常工作的建议，请参阅 第 4.6 节 “测试新副本”。
  • 有关如何解决复制冲突的建议，请参阅 Red Hat Enterprise Linux 6 Identity Management Guide 中的 解决 复制 冲突。详情请参阅目录服务器 管理指南中的保证命名冲突
  • 目录服务器 repl-monitor 脚本显示复制的状态，这有助于对复制问题进行故障排除。如需更多信息，请参阅目录服务器 管理指南中的 监控 复制拓扑。
  • 要验证两个目录服务器实例是否已同步，请参阅 目录服务器管理指南。

B.2.1. 对 AD 用户进行身份验证，以防出现新的副本失败

在 Identity Management - Active Directory 信任设置中安装新副本后，尝试根据 IdM 副本验证 Active Directory(AD)用户失败。

这意味着：

副本既不是信任控制器，也不是信任代理。因此，它无法提供来自 AD 信任的信息。

解决此问题：

将副本配置为信任代理。请参阅 Windows 集成指南中的 信任控制器和信任代理。

B.2.2. 目录服务器日志中使用 SASL、GSS-API 和 Kerberos 错误启动副本

当副本启动时，一系列 SASL bind 错误记录在 Directory Server(DS)日志中。错误状态表示 GSS-API 连接失败，因为它找不到凭证缓存： 
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
另外，可能会出现其他消息表示服务器无法获取主机主体的 Kerberos 凭证： 
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)

这意味着：

IdM 使用 GSS-API 进行 Kerberos 连接。DS 实例将 Kerberos 凭据缓存保留在内存中。当 DS 进程结束时（如 IdM 副本停止时），凭据缓存将被销毁。
当副本重启时，DS 会在 KDC 服务器启动前启动。鉴于此启动顺序，当 DS 启动时，Kerberos 凭据尚未保存在凭据缓存中，这就是导致错误的原因。
初始失败后，DS 重新尝试在 KDC 启动后建立 GSS-API 连接。第二次尝试会成功，并确保副本按预期工作。
只要成功建立 GSS-API 连接并且副本可以正常工作，您可以忽略描述的启动错误。以下消息显示连接成功： 
Replication bind with GSSAPI auth resumed

B.2.3. DNS Forward 记录与反向地址不匹配

在配置新副本时，安装会失败，并显示一系列证书错误，后跟 DNS 转发记录与反向地址不匹配的 DNS 错误。 
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer
ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444
Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)

...

ipa: DEBUG: Created connection context.ldap2_21534032
ipa: DEBUG: Destroyed connection context.ldap2_21534032
The DNS forward record replica.example.com. does not match the reverse address replica.example.org

这意味着：

多个主机名用于单个 PTR 记录。DNS 标准允许这样的配置，但会导致 IdM 副本安装失败。

解决此问题：

验证 DNS 配置，如 “验证转发和反向 DNS 配置”一节 所述。

B.2.4. 序列号未找到错误

注意
此解决方案适用于域级别 0。详情请查看 第 7 章 显示和提升域级别。
指出没有找到证书序列号的错误会出现在复制的服务器上： 
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

这意味着：

两个副本之间的证书复制协议已被删除，但仍存在数据复制协议。两个副本仍然发出证书，但证书的相关信息不再被复制。
示例情况：
  1. 副本 A 向主机签发证书。
  2. 证书不会复制到副本 B，因为副本没有建立证书复制协议。
  3. 用户尝试使用副本 B 来管理主机。
  4. 副本 B 返回一个错误，它无法验证主机的证书序列号。这是因为，副本 B 在其数据目录中具有主机的信息，但它在其证书目录中没有主机证书。

解决此问题：

  1. 使用 ipa-csreplica-manage connect 命令在两个副本之间启用证书服务器复制。请参阅 第 D.3.3 节 “创建和删除复制协议”。
  2. 重新初始化其中一个副本以同步它们。请参阅 第 D.3.5 节 “重新初始化副本”。
    警告
    重新初始化的 会使用另一个副本中的数据覆盖重新初始化的副本中的数据。某些信息可能会丢失。

B.2.5. 清理副本更新向量(RUV)错误

注意
此解决方案适用于域级别 0。详情请查看 第 7 章 显示和提升域级别。
从 IdM 拓扑中删除副本后，过时的 RUV 记录现在出现在一个或多个剩余副本中。
可能的原因：
  • 副本已被删除且没有正确删除其复制协议，如 “删除复制协议”一节 所述。
  • 当另一个副本离线时，副本已被删除。

这意味着：

其他副本仍期望从删除的副本接收更新。
注意
第 D.3.6 节 “删除副本” 中描述了删除副本的正确步骤。

解决此问题：

清理副本中预期接收更新的 RUV 记录。
  1. 使用 ipa-replica-manage list-ruv 命令列出过时的 RUV 的详细信息。该命令显示副本 ID： 
    # ipa-replica-manage list-ruv
server1.example.com:389: 6
server2.example.com:389: 5
server3.example.com:389: 4
server4.example.com:389: 12
  2. 使用 ipa-replica-manage clean-ruv replica_ID 命令清除损坏的 RUV。该命令将删除与指定副本关联的所有 RUV。
    为每个带有过时 RUV 的副本重复该命令。例如： 
    # ipa-replica-manage clean-ruv 6
# ipa-replica-manage clean-ruv 5
# ipa-replica-manage clean-ruv 4
# ipa-replica-manage clean-ruv 12
    警告
    使用 ipa-replica-manage clean-ruv 时要非常小心。针对有效的副本 ID 运行 命令将破坏与复制数据库中该副本关联的所有数据。
    如果发生了这种情况，请重新初始化另一个副本的副本，如 第 D.3.5 节 “重新初始化副本” 所述。
  3. 再次运行 ipa-replica-manage list-ruv。
    • 如果命令不再显示任何损坏的 RUV，则成功清理了记录。
    • 如果命令仍显示损坏的 RUV，请使用此任务手动清除它们： 
      dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: replica_ID
replica-force-cleaning: no
cn: clean replica_ID
如果您不确定在哪个副本上清理 RUV：
  1. 搜索所有服务器以获取活动副本 ID。制作未损坏且可靠的副本 ID 列表。
    要查找有效副本的 ID，请在拓扑中运行这个 LDAP 查询： 
    # ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
  2. 在每个服务器上运行 ipa-replica-manage list-ruv。请注意，任何不在未损坏副本 ID 列表中的副本 ID。
  3. 为每个损坏的副本 ID 运行 ipa-replica-manage clean-ruv replica_ID。

B.2.6. 恢复丢失的 CA 服务器

注意
此解决方案适用于域级别 0。详情请查看 第 7 章 显示和提升域级别。
您只安装了一台 CA 服务器。此服务器出现故障，现已丢失。

这意味着：

IdM 域的 CA 配置不再可用。

解决此问题：

如果您有原始 CA 服务器的备份，您可以恢复服务器并在副本上安装 CA。
  1. 从备份中恢复 CA 服务器.详情请查看 第 9.2 节 “恢复备份”。
    这使得 CA 服务器可供副本使用。
  2. 删除初始服务器和副本之间的复制协议，以避免复制冲突。请参阅 第 D.3.3 节 “创建和删除复制协议”。
  3. 在副本上安装 CA。请参阅 第 6.5.2 节 “将副本提升到主 CA 服务器”。
  4. 停用原始 CA 服务器。请参阅 第 D.3.6 节 “删除副本”。
如果您没有原始 CA 服务器的备份，则 CA 配置会在服务器出现故障且无法恢复时丢失。