11.11. 身份管理
在 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 属性的条目。
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-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 哈希。
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 填充加密会被阻止。因此，身份管理(IdM) Vault 无法正常工作，因为 IdM 目前正在使用 PKCS1v15 填充来用传输证书包装会话密钥。
升级后，没有 SID 的用户无法登录到 IdM
将 IdM 副本升级到 RHEL 9.2 后，IdM Kerberos 分发中心(KDC)可能无法向没有为其账户分配安全标识符(SID)的用户发出票据授予票据(TGT)。因此，用户无法登录到其帐户。
要临时解决这个问题，请以 IdM 管理员身份在拓扑中的另一个 IdM 副本上运行以下命令来生成 SID：
# ipa config-mod --enable-sid --add-sids
之后，如果用户仍然无法登录，请检查目录服务器错误日志。您可能需要调整 ID 范围，来包含用户 POSIX 身份。
如需更多信息，请参阅 升级到 RHEL9 时，IDM 用户无法再登录 知识库解决方案。
Jira:RHELPLAN-157939
迁移的 IdM 用户可能会因为不匹的域 SID 而无法登录
如果您使用 ipa migrate-ds 脚本将用户从一个 IdM 部署迁移到另一个，则这些用户可能会在使用 IdM 服务时有问题，因为它们之前存在的安全标识符(SID)没有当前 IdM 环境的域 SID。例如，这些用户可以使用 kinit 工具检索 Kerberos 票据，但不能登录。要临时解决这个问题，请参阅以下知识库文章： Migrated IdM 用户因为不匹配的域 SID 而无法登录。
Jira:RHELPLAN-109613
由于生成用户 PAC 的加密类型不兼容，MIT krb5 用户无法获取 AD TGT
在 MIT krb5 1.20 以及后续的软件包中，默认在所有 Kerberos 票据中都包括特权属性证书(PAC)。MIT Kerberos 分发中心(KDC)选择可用的最强的加密类型，来在 PAC 中生成 KDC 校验和，这目前是 RFC8009 中定义的 AES HMAC-SHA2 加密类型。但是，活动目录(AD)不支持这个 RFC。因此，在 AD-MIT 跨领域设置中，MIT krb5 用户无法获取 AD 票据授予票据(TGT)，因为 MIT KDC 生成的跨领域 TGT 在 PAC 中包含不兼容的 KDC 校验和类型。
要临时解决这个问题，对于 /var/kerberos/krb5kdc/kdc.conf 配置文件的 [realms] 部分中的 MIT 领域，请将 disable_pac 参数设为 true。因此，MIT KDC 会生成没有 PAC 的票据，这意味着 AD 会跳过失败的校验和验证，MIT krb5 用户可以获取 AD TGT。
对 ldap_id_use_start_tls 选项使用默认值时的潜在风险
当对身份查询使用没有 TLS 的 ldap:// 时，可能会对攻击向量构成风险。特别是中间人(MITM)攻击，例如，它可能允许攻击者通过更改 LDAP 搜索中返回的对象的 UID 或 GID 来冒充用户。
目前，SSSD 配置选项强制 TLS 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
将 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
当以引用模式启动时，目录服务器会意外终止
由于一个程序错误，全局引用模式无法在 Directory Server 中工作。如果您以 dirsrv 用户身份使用 refer 选项启动 ns-slapd 进程，则目录服务器会忽略端口设置并意外终止。尝试以 root 用户身份运行进程会更改 SELinux 标签，并可以防止服务以后以正常模式启动。没有可用的临时解决方案。
目录服务器只能从 /var/lib/dirsrv/slapd-instance_name/ldif/ 导入 LDIF 文件
从 RHEL 8.3 开始，红帽目录服务器(MQTTS)使用自己的私有目录，并且为 LDAP 服务默认启用 PrivateTmp systemd 指令。因此，RHDS 只能从 /var/lib/dirsrv/slapd-instance_name/ldif/ 目录导入 LDIF 文件。如果 LDIF 文件存储在不同的目录中，如 /var/tmp、/tmp 或 /root，则导入会失败，并显示类似如下的错误：
Could not open LDIF file "/tmp/example.ldif", errno 2 (No such file or directory)
要临时解决这个问题，请完成以下步骤：
将 LDIF 文件移到
/var/lib/dirsrv/slapd-instance_name/ldif/目录中：# mv /tmp/example.ldif /var/lib/dirsrv/slapd-instance_name__/ldif/设置允许
dirsrv用户读文件的权限：# chown dirsrv /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif恢复 SELinux 上下文：
# restorecon -Rv /var/lib/dirsrv/slapd-instance_name/ldif/
如需更多信息，请参阅 LDAP 服务无法访问主机 /tmp 和 /var/tmp 目录下的文件。
因为 EMS 强制，使用 RHEL 9.2+ IdM 服务器在 FIPS 模式下安装 RHEL 7 IdM 客户端会失败
对于启用了 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 客户端的安装可以成功。
