☰

KDC 在对 OpenLDAP 进行身份验证时不支持加密类型

tag-icon • tag-icon openldap kerberos
KDC 在对 OpenLDAP 进行身份验证时不支持加密类型

多年来，我一直在运行 Kerberos / LDAP 身份验证服务器。Kerberos 数据存储在 LDAP 中。现在，我有了第二个站点，并想将服务器镜像到新站点。这基本上可行，但有一个奇怪的副作用。每台服务器都运行着一个 KDC 和一个 LDAP。KDC 使用本地 ldapi:/// 与 LDAP 通信。

如果我使用原始 KDC ，krb1.example.com我可以向主 LDAP 和副本进行身份验证。如果我使用复制的 KDC krb2.example.com，我仍然可以向主 LDAP 进行身份验证，但尝试副本时，我得到的

SASL/GSSAPI 身份验证已开始
ldap_sasl_interactive_bind_s：本地错误（-2）
        附加信息：SASL(-1)：通用故障：GSSAPI 错误：未指定的 GSS 故障。次要代码可能提供更多信息（KDC 不支持加密类型）

这很奇怪，因为krb2实际上是 LXC 容器上的克隆krb1，即配置对于复制所需的更改是相同的。但更令人费解的是，在尝试查询任一 LDAP 服务器后查看票证缓存。使用来自krb1

root@krb2:/# klist -e
票证缓存：FILE:/tmp/krb5_cc_0.tkt
默认主体：[电子邮件保护]

有效起始到期服务主体
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/[电子邮件保护]
        续订至 2022 年 2 月 5 日 01:05:26，Etype（skey，tkt）：aes256-cts-hmac-sha1-96，aes256-cts-hmac-sha1-96
04.02.2022 01:05:42 04.02.2022 11:05:29 ldap/[电子邮件保护]
        续订至 2022 年 2 月 5 日 01:05:26，Etype（skey，tkt）：aes256-cts-hmac-sha1-96，aes256-cts-hmac-sha1-96
04.02.2022 01:05:53 04.02.2022 11:05:29 ldap/[电子邮件保护]
        续订至 2022 年 2 月 5 日 01:05:26，Etype（skey，tkt）：aes256-cts-hmac-sha1-96，aes256-cts-hmac-sha1-96

来自krb2：

root@krb2:/# klist -e
票证缓存：FILE:/tmp/krb5_cc_0.tkt
默认主体：[电子邮件保护]

有效起始到期服务主体
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/[电子邮件保护]
        续订至 2022 年 2 月 5 日 00:53:41，Etype（skey，tkt）：aes256-cts-hmac-sha1-96，aes256-cts-hmac-sha1-96
04.02.2022 00:53:47 04.02.2022 10:53:45 ldap/[电子邮件保护]
        续订至 2022 年 2 月 5 日 00:53:41，Etype（skey，tkt）：aes256-cts-hmac-sha1-96，aes256-cts-hmac-sha1-96

由于错误，没有条目ldap/krb2.example.com。但显然所需的加密类型没有区别。那么，为什么它会抱怨呢？

目前，两个 LDAP 服务器都引用krb1。但由于 LDAP 复制，所有密钥都应该相同，即来自 的密钥krb1应该与来自 的密钥相同krb2，不是吗？如果来自 的密钥krb1适用于两个 LDAP 服务器，那么为什么来自副本服务器的密钥仅适用于主 LDAP？

supported_enctypes两者中的领域/etc/krb5kdc/kdc.conf都是supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3。 两者中都没有 enctype 指令/etc/krb5.conf。 两个 LDAP 中都没有ssf使用配置。两个 LDAP 中都存在 的krbPrincipalName条目krb2。

即使我从 获取 TGT krb2，然后将 切换krb5.conf到krb1获取服务票证，我也可以通过 进行 LDAP 身份验证krb2。

OpenLDAP 的版本是 2.4.47，两台机器上的 Kerberos 版本都是 1.17（当前 Debian 稳定版）。

更新：事实证明，复制是不完整的，即krbPrincipalKey没有（可靠地）复制。我检查了slapd调试输出：

2 月 9 日 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND authcid="sync/[电子邮件保护]“ authzid =“ dn：uid = sync / krb2.example.com，cn = example.com，cn = gssapi，[电子邮件保护]“
2 月 9 日 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND dn="cn=admin,dc=example,dc=com" mech=GSSAPI sasl_ssf=256 ssf=256

因此，synprov显然绑定为cn=admin,dc=example,dc=com，这是预期的。但是，如果我这样做

root@krb1:~# ldapsearch -b'cn=KERBEROS,dc=example,dc=com'-D'cn=admin,dc=example,dc=com'-Wx'krbPrincipalName=ldap/[电子邮件保护]‘

然后我明白了krbPrincipalKey。那么为什么它没有被复制呢？

我使用 options重新slapd启动，我知道这应该会同步整个数据库。但由于有些条目有密钥，有些没有，我不相信这是真的。krb2-c rid=1,csn=0

答案1

slapcat该问题已由主数据库解决，并slapadd从消费者数据库开始解决。

感谢用户1686指出需要检查的事项，让我打破了循环思维。

问题的原因是 LDAP 中的某些 Kerberos 主体没有krbPrincipalKey属性。ldap/krb2.example.com就是其中之一。这get_principal在kadmin.local每个服务器上使用时都很明显。由于使用了不适当的绑定 DN 和与之关联的 ACL，因此产生了混淆。此外，我相信我使用了选项slapd在启动时重新获取整个数据库，但这并没有发生。

一些让我陷入困境的陷阱：由于启用 TLS-Y EXTERNAL不起作用，我使用特殊的 Kerberos 主体进行数据库维护。我的主体cn=config无权访问存储在主数据库中的凭据，而我不再知道这一点。因此，比较两个 LDAP 的条目得出了相同的结果。虽然实际的复制主体有权访问凭据，但我最初可能使用了其他绑定 DN，即在我为复制设置 Kerberos 之前。因此，在此期间创建的条目是在没有凭据的情况下复制的，并且syncprov以后不会修复此问题。

相关内容