B.2. Identity Management Replicas
本指南描述了 Red Hat Enterprise Linux 中身份管理的常见复制问题。
其他资源:
- 有关如何测试复制是否正常工作的建议,请参阅 第 4.6 节 “测试新副本”。
- 目录服务器
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)
这意味着:
两个副本之间的证书复制协议已被删除,但仍存在数据复制协议。两个副本仍然发出证书,但证书的相关信息不再被复制。
示例情况:
- 副本 A 向主机签发证书。
- 证书不会复制到副本 B,因为副本没有建立证书复制协议。
- 用户尝试使用副本 B 来管理主机。
- 副本 B 返回一个错误,它无法验证主机的证书序列号。这是因为,副本 B 在其数据目录中具有主机的信息,但它在其证书目录中没有主机证书。
解决此问题:
- 使用 ipa-csreplica-manage connect 命令在两个副本之间启用证书服务器复制。请参阅 第 D.3.3 节 “创建和删除复制协议”。
- 重新初始化其中一个副本以同步它们。请参阅 第 D.3.5 节 “重新初始化副本”。警告重新初始化的 会使用另一个副本中的数据覆盖重新初始化的副本中的数据。某些信息可能会丢失。
B.2.5. 清理副本更新向量(RUV)错误
注意
此解决方案适用于域级别
0。
详情请查看 第 7 章 显示和提升域级别。
从 IdM 拓扑中删除副本后,过时的 RUV 记录现在出现在一个或多个剩余副本中。
可能的原因:
- 副本已被删除且没有正确删除其复制协议,如 “删除复制协议”一节 所述。
- 当另一个副本离线时,副本已被删除。
这意味着:
其他副本仍期望从删除的副本接收更新。
注意
第 D.3.6 节 “删除副本” 中描述了删除副本的正确步骤。
解决此问题:
清理副本中预期接收更新的 RUV 记录。
- 使用 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
- 使用 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 节 “重新初始化副本” 所述。 - 再次运行 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:
- 搜索所有服务器以获取活动副本 ID。制作未损坏且可靠的副本 ID 列表。要查找有效副本的 ID,请在拓扑中运行这个 LDAP 查询:
# ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
- 在每个服务器上运行 ipa-replica-manage list-ruv。请注意,任何不在未损坏副本 ID 列表中的副本 ID。
- 为每个损坏的副本 ID 运行 ipa-replica-manage clean-ruv replica_ID。
B.2.6. 恢复丢失的 CA 服务器
注意
此解决方案适用于域级别
0。
详情请查看 第 7 章 显示和提升域级别。
您只安装了一台 CA 服务器。此服务器出现故障,现已丢失。
这意味着:
IdM 域的 CA 配置不再可用。
解决此问题:
如果您有原始 CA 服务器的备份,您可以恢复服务器并在副本上安装 CA。
- 从备份中恢复 CA 服务器.详情请查看 第 9.2 节 “恢复备份”。这使得 CA 服务器可供副本使用。
- 删除初始服务器和副本之间的复制协议,以避免复制冲突。请参阅 第 D.3.3 节 “创建和删除复制协议”。
- 在副本上安装 CA。请参阅 第 6.5.2 节 “将副本提升到主 CA 服务器”。
- 停用原始 CA 服务器。请参阅 第 D.3.6 节 “删除副本”。
如果您没有原始 CA 服务器的备份,则 CA 配置会在服务器出现故障且无法恢复时丢失。