8.13. 身份管理
RHEL 9 Kerberos 客户端无法针对 Heimdal KDC 使用 PKINIT 验证用户
在 RHEL 9 Kerberos 客户端中 IdM 用户的 PKINIT 验证过程中，RHEL 9 或者更早的 Kerberos 分发中心(KDC)使用 SHA-1 备份签名算法，因为 Kerberos 客户端不支持 supportedCMSTypes 字段。但是，RHEL 9 中弃用了 SHA-1 算法，因此用户身份验证会失败。
要临时解决这个问题，使用以下命令在 RHEL 9 客户端上启用对 SHA-1 算法的支持：
# update-crypto-policies --set DEFAULT:SHA1
因此，PKINIT 身份验证在 Kerberos 客户端和 Heimdal KDC 之间正常工作。
有关支持的备份签名算法的详情，请参阅 CMS Algorithm 标识符的 Kerberos 加密类型。
另请参阅 如果 RHEL 9 Kerberos 代理与非 RHEL 9 Kerberos 代理进行通信，则用户的 PKINIT 身份验证会失败。
如果 RHEL 9 Kerberos 代理与非 RHEL 9 Kerberos 代理进行通信，则用户的 PKINIT 身份验证会失败
如果 RHEL 9 Kerberos 代理与您环境中的其他非 RHEL 9 Kerberos 代理进行交互，则用户的初始验证(PKINIT)验证的公钥加密会失败。要临时解决这个问题，请执行以下操作之一：
将 RHEL 9 代理的加密策略设为
DEFAULT:SHA1以允许 SHA-1 签名的验证：# update-crypto-policies --set DEFAULT:SHA1
更新非 RHEL 9 代理，以确保它不会使用 SHA-1 算法为 CMS 数据签名。为此，将 Kerberos 软件包更新为使用 SHA-256 而不是 SHA-1 的版本：
- CentOS 9 流: 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
无论没打补丁的代理是 Kerberos 客户端还是 Kerberos 发布中心(KDC)，您都必须执行这些操作中的一个。
因此，用户的 PKINIT 身份验证可以正常工作。
请注意，对于其他操作系统，是 krb5-1.20 版本确保代理使用 SHA-256 而不是 SHA-1 为 CMS 数据签名。
另请参阅 必须在 RHEL 9 客户端上设置 DEFAULT:SHA1 子策略，以便 PKINIT 能够对旧的 RHEL KDC 和 AD KDC 工作。
必须在 RHEL 9 客户端上设置 DEFAULT:SHA1 子策略，以便 PKINIT 能够对旧的 RHEL KDC 和 AD KDC 工作
RHEL 9 中已弃用了 SHA-1 摘要算法，对初始验证的公共密钥加密的 CMS 消息现在使用更强大的 SHA-256 算法进行签名。
从 RHEL 7.9 和 RHEL 8.7 开始，虽然默认使用 SHA-256 ，但 RHEL 7.8 和 RHEL 8.6 及其早期版本上的旧 Kerberos 密钥分发中心(KDC)仍使用 SHA-1 摘要算法来签名 CMS 信息。活动目录(AD) KDC 也是如此。
因此，RHEL 9 Kerberos 客户端无法使用 PKINIT 针对以下情况验证用户：
- 在 RHEL 7.8 及更早版本上运行的 KDC
- 在 RHEL 8.6 和更早版本上运行的 KDC
- AD KDC
要临时解决这个问题，使用以下命令在 RHEL 9 系统上启用对 SHA-1 算法的支持：
# update-crypto-policies --set DEFAULT:SHA1
另请参阅 RHEL 9 Kerberos 客户端无法针对 Heimdal KDC 使用 PKINIT 验证用户。
当以引用模式启动时，目录服务器会意外终止
由于一个程序错误，全局引用模式无法在 Directory Server 中工作。如果您以 dirsrv 用户身份使用 refer 选项启动 ns-slapd 进程，则目录服务器会忽略端口设置并意外终止。尝试以 root 用户身份运行进程会更改 SELinux 标签，并可以防止服务以后以正常模式启动。没有可用的临时解决方案。
在 Directory 服务器中为后缀配置引用失败
如果您在 Directory 服务器中设置了后端引用，使用 dsconf <instance_name> backend suffix set --state referral 命令设置后端状态会失败，并显示以下错误：
Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state
因此，为后缀配置引用会失败。要临时解决这个问题：
手动设置
nsslapd-referral参数：# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsslapd-referral nsslapd-referral: ldap://remote_server:389/dc=example,dc=com
设置后端状态：
# dsconf <instance_name> backend suffix set --state referral
因此，您可以使用临时解决方案为后缀配置引用。
dsconf 实用程序没有为 entryUUID 插件创建修复任务的选项
dsconf 实用程序没有提供为 entryUUID 插件创建修复任务的选项。因此，管理员无法使用 dsconf 创建任务来自动将 entryUUID 属性添加到现有条目。作为临时解决方案，请手动创建任务：
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=entryuuid_fixup___<time_stamp__,cn=entryuuid task,cn=tasks,cn=config objectClass: top objectClass: extensibleObject basedn: __<fixup base tree>__ cn: entryuuid_fixup___<time_stamp>__ filter: __<filtered_entry>__
创建了任务后，Directory 服务器会修复缺少或无效 entryUUID 属性的条目。
将对 ldap_id_use_start_tls 选项使用默认值时的潜在风险
当不使用 TLS 进行身份查找的情况下使用 ldap:// 时，可能会对攻击向量构成风险。特别是中间人(MITM)攻击，例如，其可以通过更改LDAP 搜索中返回的对象的 UID 或 GID 来允许攻击者冒充用户。
目前，用于强制 TLS 的 ldap_id_use_start_tls SSSD 配置选项，默认为 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)
