9.11. 身份管理
必须在 RHEL 9 客户端上设置 DEFAULT:SHA1 子策略，以使 PKINIT 能够针对 AD KDC 工作
RHEL 9 中已弃用了 SHA-1 摘要算法，对初始验证的公共密钥加密的 CMS 消息现在使用更强大的 SHA-256 算法进行签名。
但是，Active Directory (AD) Kerberos Distribution Center (KDC) 仍然使用 SHA-1 摘要算法为 CMS 信息签名。因此，RHEL 9 Kerberos 客户端无法通过对 AD KDC 使用 PKINIT 来验证用户。
要临时解决这个问题，使用以下命令在 RHEL 9 系统上启用对 SHA-1 算法的支持：
# update-crypto-policies --set DEFAULT:SHA1
如果 RHEL 9 Kerberos 代理与非 RHEL 9 的非AD Kerberos 代理通信，则用户的 PKINIT 身份验证会失败
如果 RHEL 9 Kerberos 代理（客户端或 Kerberos 分发中心(KDC) 与不是 Active Directory (AD) 代理的非 RHEL-9 Kerberos 代理交互，则用户的 PKINIT 身份验证会失败。要临时解决这个问题，请执行以下操作之一：
将 RHEL 9 代理的 crypto-policy 设置为
DEFAULT:SHA1以允许验证 SHA-1 签名：# update-crypto-policies --set DEFAULT:SHA1
更新非 RHEL-9 和非 AD 代理，以确保它不使用 SHA-1 算法为 CMS 数据签名。因此，将您的 Kerberos 客户端或 KDC 软件包更新至使用 SHA-256 而不是 SHA-1 的版本：
- CentOS 9 Stream: krb5-1.19.1-15
- RHEL 8.7: krb5-1.18.2-17
- RHEL 7.9: krb5-1.15.1-53
- Fedora Rawhide/36: krb5-1.19.2-7
- Fedora 35/34：krb5-1.19.2-3
因此，用户的 PKINIT 身份验证可以正常工作。
请注意，对于其他操作系统，这是 krb5-1.20 版本，可确保代理使用 SHA-256 而不是 SHA-1 为 CMS 数据进行签名。
另请参阅 必须在 RHEL 9 客户端上设置 DEFAULT:SHA1 子策略，以使 PKINIT 能够针对 AD KDC 工作。
AD 信任的 FIPS 支持需要 AD-SUPPORT 加密子策略
Active Directory(AD)使用 AES SHA-1 HMAC 加密类型，默认情况下在 RHEL 9 上不允许 FIPS 模式。如果要使用带有 AD 信任的 RHEL 9 IdM 主机，请在安装 IdM 软件前支持 AES SHA-1 HMAC 加密类型。
由于 FIPS 合规性是一个涉及技术和机构协议的过程，因此，请在启用 AD-SUPPORT 子策略前咨询 FIPS 审核员，以允许采取技术措施支持 AES SHA-1 HMAC 加密类型，然后安装 RHEL IdM：
# update-crypto-policies --set FIPS:AD-SUPPORT
Heimdal 客户端无法针对 RHEL 9 KDC 使用 PKINIT 来验证用户
默认情况下，Heimdal Kerberos 客户端通过使用 Modular Exponential (MODP) Diffie-Hellman Group 2 用于互联网密钥交换 (IKE) 启动 IdM 用户的 PKINIT 身份验证。但是，RHEL 9 上的 MIT Kerberos 分配中心 (KDC) 仅支持 MODP 组 14 和 16。
因此，pre-autentication 请求会失败并显示 krb5_get_init_creds: PREAUTH_FAILED 错误，在 RHEL MIT KDC 中 不接受 Key 参数。
要临时解决这个问题，请确保 Heimdal 客户端使用 MODP Group 14。将客户端配置文件的 libdefaults 部分中的 pkinit_dh_min_bits 参数设置为 1759：
[libdefaults] pkinit_dh_min_bits = 1759
因此，Heimdal 客户端可以针对 RHEL MIT KDC 完成 PKINIT 预验证。
FIPS 模式下的 IdM 不支持使用 NTLMSSP 协议来建立双向跨林信任
在活动目录(AD)和启用了 FIPS 模式的身份管理(IdM)之间建立双向跨林信任会失败，因为新技术局域网管理器安全支持提供程序 (NTLMSSP)身份验证不符合 FIPS。FIPS 模式下的 IdM 不接受在尝试验证时 AD 域控制器使用的 RC4 NTLM 哈希。
Jira:RHEL-12154[1]
迁移的 IdM 用户可能会因为不匹的域 SID 而无法登录
如果您使用 ipa migrate-ds 脚本将用户从一个 IdM 部署迁移到另一个，则这些用户可能会在使用 IdM 服务时有问题，因为它们之前存在的安全标识符(SID)没有当前 IdM 环境的域 SID。例如，这些用户可以使用 kinit 工具检索 Kerberos 票据，但不能登录。要临时解决这个问题，请参阅以下知识库文章： Migrated IdM 用户因为不匹配的域 SID 而无法登录。
Jira:RHELPLAN-109613[1]
对 ldap_id_use_start_tls 选项使用默认值时的潜在风险
当使用没有 TLS 的 ldap:// 进行身份查找时，可能会对攻击向量构成风险。特别是中间人(MITM)攻击，例如，攻击者可以通过更改 LDAP 搜索中返回的对象的 UID 或 GID 来冒充用户。
目前，强制 TLS 的 SSSD 配置选项 ldap_id_use_start_tls 默认为 false。确保您的设置在可信环境中操作，并决定对 id_provider = ldap 使用未加密的通信是否是安全的。注意 id_provider = ad 和 id_provider = ipa 不受影响，因为它们使用 SASL 和 GSSAPI 保护的加密连接。
如果使用未加密的通信不安全，请在 /etc/sssd/sssd.conf 文件中将 ldap_id_use_start_tls 选项设置为 true 来强制使用 TLS。计划在以后的 RHEL 版本中更改的默认行为。
Jira:RHELPLAN-155168[1]
将 FIPS 模式下的 RHEL 9 副本添加到用 RHEL 8.6 或更早版本初始化的 FIPS 模式下的 IdM 部署会失败
略旨在遵守 FIPS 140-3 的默认 RHEL 9 FIPS 加密策不允许使用 AES HMAC-SHA1 加密类型的密钥派生功能，如 5.1 章节 RFC3961 所定义的。
当在 FIPS 模式下将 RHEL 9 身份管理(IdM)副本添加到 FIPS 模式下的 RHEL 8 IdM 环境（其中，第一个服务器安装在 RHEL 8.6 系统或更早的版本上）中时，这个约束是一个阻止因素。这是因为在 RHEL 9 和之前的 RHEL 版本之间没有通用的加密类型，它们通常使用 AES HMAC-SHA1 加密类型，但不使用 AES HMAC-SHA2 加密类型。
您可以通过在服务器上输入以下命令来查看 IdM 主密钥的加密类型：
# kadmin.local getprinc K/M | grep -E '^Key:'
要临时解决这个问题，在 RHEL 9 副本上启用 AES HMAC-SHA1 ：
update-crypto-policies --set FIPS:AD-SUPPORT
- WARNING
- 这个临时解决方案可能会违反 FIPS 合规性。
因此，向 IdM 部署添加 RHEL 9 副本可以正确进行。
请注意，目前有一个正在进行的工作来提供一个在 RHEL 7 和 RHEL 8 服务器上生成缺少的 AES HMAC-SHA2 加密的 Kerberos 密钥的流程。这将在 RHEL 9 副本上取得 FIPS 140-3 合规性。但是，这个过程将无法完全自动化，因为 Kerberos 密钥加密的设计无法将现有的密钥转换为不同的加密类型。唯一的方法是要求用户更新其密码。
SSSD 可正确注册 DNS 名称
在以前的版本中，如果 DNS 被错误建立，第一次尝试注册 DNS 名称时，SSSD 总是失败。要临时解决这个问题，这个更新提供了一个新的参数 dns_resolver_use_search_list。设置 dns_resolver_use_search_list = false，以避免使用 DNS 搜索列表。
Bugzilla:1608496[1]
使用 RHEL 9.2 及更新的 IdM 服务器在 FIPS 模式下安装 RHEL 7 IdM 客户端由于 EMS 强制而失败
对于启用了 FIPS 的 RHEL 9.2 及更新系统上的 TLS 1.2 连接，TLS Extended Master Secret (EMS)扩展(RFC 7627)现在是强制的。这符合 FIPS-140-3 要求。但是，RHEL 7.9 及较低版本中提供的 openssl 版本不支持 EMS。因此，使用在 RHEL 9.2 及更新版本上运行的启用了 FIPS 的 IdM 服务器安装 RHEL 7 身份管理(IdM)客户端会失败。
如果在安装 IdM 客户端前将主机升级到 RHEL 8 不是一个选项，请通过在 FIPS 加密策略之上应用 NO-ENFORCE-EMS 子策略，删除 RHEL 9 服务器上 EMS 使用的要求来临时解决此问题：
# update-crypto-policies --set FIPS:NO-ENFORCE-EMS
请注意，这个删除不符合 FIPS 140-3 要求。因此，您可以建立并接受不使用 EMS 的 TLS 1.2 连接，RHEL 7 IdM 客户端的安装可以成功。
在线备份和在线自动成员重建任务可能获得两个锁，从而导致死锁
如果在线备份和在线成员性重建任务尝试以相反的顺序获取相同的两个锁，则可能会导致无法恢复的死锁，需要您停止和重启服务器。要临时解决这个问题，请不要并行启动在线备份和在线自动成员重建任务。
Jira:RHELDOCS-18065[1]
