搜索

9.11. 身份管理

download PDF

MIT Kerberos 不支持 PKINIT 的 ECC 证书

MIT Kerberos 不对评论文档实施 RFC5349 请求,它描述了公钥 Cryptography 中的 elliptic-curve 加密 (ECC) 支持。因此,RHEL 使用的 MIT krb5-pkinit 软件包不支持 ECC 证书。如需更多信息,请参阅 Kerberos (PKINIT)对公共密钥加密加密支持(ECC) 支持。

Jira:RHEL-4902

必须在 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

Bugzilla:2060798

如果 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 工作

Jira:RHEL-4875

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

Bugzilla:2057471

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 预验证。

Jira:RHEL-4889

FIPS 模式下的 IdM 不支持使用 NTLMSSP 协议来建立双向跨林信任

在活动目录(AD)和启用了 FIPS 模式的身份管理(IdM)之间建立双向跨林信任会失败,因为新技术局域网管理器安全支持提供程序 (NTLMSSP)身份验证不符合 FIPS。FIPS 模式下的 IdM 不接受在尝试验证时 AD 域控制器使用的 RC4 NTLM 哈希。

Jira:RHEL-12154[1]

升级后,没有 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[1]

迁移的 IdM 用户可能会因为不匹的域 SID 而无法登录

如果您使用 ipa migrate-ds 脚本将用户从一个 IdM 部署迁移到另一个,则这些用户可能会在使用 IdM 服务时有问题,因为它们之前存在的安全标识符(SID)没有当前 IdM 环境的域 SID。例如,这些用户可以使用 kinit 工具检索 Kerberos 票据,但不能登录。要临时解决这个问题,请参阅以下知识库文章: Migrated IdM 用户因为不匹配的域 SID 而无法登录

Jira:RHELPLAN-109613[1]

由于生成用户 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。

Bugzilla:2016312

ldap_id_use_start_tls 选项使用默认值时的潜在风险

当使用没有 TLS 的 ldap:// 进行身份查找时,可能会对攻击向量构成风险。特别是中间人(MITM)攻击,例如,攻击者可以通过更改 LDAP 搜索中返回的对象的 UID 或 GID 来冒充用户。

目前,强制 TLS 的 SSSD 配置选项 ldap_id_use_start_tls 默认为 false。确保您的设置在可信环境中操作,并决定对 id_provider = ldap 使用未加密的通信是否是安全的。注意 id_provider = adid_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 密钥加密的设计无法将现有的密钥转换为不同的加密类型。唯一的方法是要求用户更新其密码。

Jira:RHEL-4888

SSSD 可正确注册 DNS 名称

在以前的版本中,如果 DNS 被错误建立,第一次尝试注册 DNS 名称时,SSSD 总是失败。要临时解决这个问题,这个更新提供了一个新的参数 dns_resolver_use_search_list。设置 dns_resolver_use_search_list = false,以避免使用 DNS 搜索列表。

Bugzilla:1608496[1]

由于 EMS 强制,使用 RHEL 9.2 及更新的 IdM 服务器安装 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 客户端的安装可以成功。

Jira:RHEL-4955

nsslapd-numlisteners 属性值超过 2 时,目录服务器会失败

如果 nsslapd-numlisteners 属性值大于 2,则目录服务器可能会关闭侦听文件描述符,而不是接受的文件描述符。因此,在一段时间后,Directory 服务器会停止侦听某些端口并失败。

要临时解决这个问题,请将 nsslapd-numlisteners 属性值设置为 1

Jira:RHEL-17178[1]

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.