主页 / server / 问题 / 1092625
Accepted
Lars Hanke
Asked: 2022-02-04 17:00:33 +0800 CST

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

  • 772

我多年来一直在运行 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 服务器后查看票证缓存。带有来自的 TGTkrb1

root@krb2:/# klist -e
票证缓存：FILE:/tmp/krb5_cc_0.tkt
默认主体：[email protected]

有效的启动过期服务主体
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/[email protected]
        续订至 05.02.2022 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/[email protected]
        续订至 05.02.2022 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/[email protected]
        续订至 05.02.2022 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
默认主体：[email protected]

有效的启动过期服务主体
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/[email protected]
        续订至 05.02.2022 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/[email protected]
        续订至 05.02.2022 00:53:41，Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

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

目前，两个 LDAP 服务器均指krb1. 但是由于 LDAP 复制，所有键都应该是相同的，即一个键 fromkrb1应该与 from 相同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。ssf两个 LDAP 中都没有使用配置。的krbPrincipalName条目krb2存在于两个 LDAP 中。

即使我从服务票证中获取 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/[email protected]" authzid="dn:uid=sync/krb2.example.com, cn=example.com,cn=gssapi,[email protected]"
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/krb2.example.com@示例.COM'

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

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

openldap kerberos

1 个回答

  1. Best Answer

    slapcat主数据库和slapadd消费者从头开始解决了这个问题。

    感谢 user1686 指出要检查的东西让我打破循环思维。

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

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

    • 0

相关问题