11.13. 身份管理
MIT Kerberos 不支持 PKINIT 的 ECC 证书
MIT Kerberos 不对评论文档实施 RFC5349 请求，它描述了公钥 Cryptography 中的 elliptic-curve 加密 (ECC) 支持。因此，RHEL 使用的 MIT krb5-pkinit 软件包不支持 ECC 证书。如需更多信息，请参阅 Kerberos (PKINIT)对公共密钥加密加密支持(ECC) 支持。
在 RHEL 9 客户端上必须将 DEFAULT:SHA1 子策略设置为 PKINIT 来针对 AD KDC 工作
现在，RHEL 9 中弃用了 SHA-1 摘要算法，对公共密钥 Cryptography for Public Key Cryptography 的 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-polices --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 工作。
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 哈希。
IdM 到 AD 跨域 TGS 请求失败
IdM Kerberos 票据中的 Privilege Attribute 证书(PAC) 信息现在使用 AES SHA-2 HMAC 加密进行签名，这是 Active Directory (AD) 不支持的。
因此，IdM 到 AD 跨域 TGS 请求（即双向信任设置）失败，并显示以下错误：
"Generic error (see e-text) while getting credentials for <service principal>"
IdM Vault 加密和解密在 FIPS 模式中失败
如果启用了 FIPS 模式，则 OpenSSL RSA-PKCS1v15 填充加密会被阻止。IPvquetly, Identity Management (IdM) Vault 无法正常工作，因为 IdM 目前使用 PKCS1v15 padding 来使用传输证书嵌套会话密钥。
迁移的 IdM 用户可能会因为不匹配域 SID 而无法登录
如果您使用 ipa migrate-ds 脚本将用户从一个 IdM 部署迁移到另一个，则这些用户可能会在使用 IdM 服务时有问题，因为它们之前存在的安全标识符(SID)没有当前 IdM 环境的域 SID。例如，这些用户可以使用 kinit 工具检索 Kerberos 票据，但不能登录。要临时解决这个问题，请参阅以下知识库文章： Migrated IdM 用户因为不匹配的域 SID 而无法登录。
(JIRA:RHELPLAN-109613)
当以引用模式启动时，目录服务器会意外终止
由于一个程序错误，全局引用模式无法在 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)
