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 伺服器後查看票證記憶體。帶有來自的 TGTkrb1

root@krb2:/# klist -e
票證記憶體：FILE:/tmp/krb5_cc_0.tkt
預設主體：user@EXAMPLE.COM

有效的啟動過期服務主體
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/EXAMPLE.COM@EXAMPLE.COM
續訂至 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/krb1.example.com@EXAMPLE.COM
續訂至 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/krb2.example.com@EXAMPLE.COM
續訂至 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
預設主體：user@EXAMPLE.COM

有效的啟動過期服務主體
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
續訂至 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/krb1.example.com@EXAMPLE.COM
續訂至 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/krb2.example.com@EXAMPLE.COM" authzid="dn:uid=sync/krb2.example.com, cn=example.com,cn=gssapi,cn=auth@EXAMPLE.COM"
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

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以後不會修復此問題。

引用自：https://serverfault.com/questions/1092625