Ubuntu Server 22.04 上的 OpenLDAP 和 Kerberos 伺服器； Krb5 沒有創建 /var/lib/krb5kdc/principal

Question

我在 Ubuntu Server 22.04 上有一個現有的 openldap 伺服器，並嘗試按照本指南使用它設定一個 kerberos 伺服器：https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend

帳戶已建立並經過測試，它們工作正常（我透過 cn 引用它們，但它們有一個 uid；我只是先在 apache 目錄 studio 中建立它們）。我已經完成了“dpkg-reconfigure krb5-config”並編輯了 /etc/krb5.conf 以新增我的伺服器和領域。該文件中沒有但我在其他地方看到的一件事是創建一個“[domain_realm]”部分並將我的網域添加到其中，我已經這樣做了，但沒有幫助。我創建了一個日誌記錄部分，它需要修改 systemd 服務以允許寫入 /var/log/kerberos，但這很好。然後，我運行列出的“kdb5_ldap_util”命令，輸入密碼後，它似乎已成功完成。我儲存了 kdc-service 和 kadmin-service 密碼，成功完成。我創建了 kadm.acl 文件，這很好，然後當我嘗試啟動服務時，我在 krb5kdc.log 中得到以下內容：

krb5kdc[712216](Error): Cannot find master key record in database - while fetching master keys list for realm SUBDOMAIN.DOMAIN.COM

如果我然後運行“kadmin.local”，我會得到以下資訊：

Authenticating as principal root/[email protected] with password.
kadmin.local: Cannot find master key record in database while initializing kadmin.local interface

事實證明，檔案 /var/lib/krb5kdc/principal 永遠不會被創建。我不確定這裡還要解決什麼問題，但此時我陷入困境，任何指導將不勝感激。下面的配置文件，更改了網域和子域：

/etc/krb5.conf：

[libdefaults]
        default_realm = SUBDOMAIN.DOMAIN.COM

# The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
        fcc-mit-ticketflags = true

[logging]
        kdc = FILE:/var/log/kerberos/krb5kdc.log
        admin_server = FILE:/var/log/kerberos/kadmin.log
        default = FILE:/var/log/kerberos/krb5lib.log

[realms]
        SUBDOMAIN.DOMAIN.COM = {
                kdc = hostname.subdomain.domain.com
                admin_server = hostname.subdomain.domain.com
                default_domain = subdomain.domain.com
                database_module = openldap_ldapconf
        }

[domain_realm]
        .subdomain.domain.com = SUBDOMAIN.DOMAIN.COM
        subdomain.domain.com = SUBDOMAIN.DOMAIN.COM

[dbdefaults]
        ldap_kerberos_container_dn = cn=krbContainer,dc=subdomain,dc=domain,dc=com

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap

                # if either of these is false, then the ldap_kdc_dn needs to
                # have write access
                disable_last_success = true
                disable_lockout  = true

                # this object needs to have read rights on
                # the realm container, principal container and realm sub-trees
                ldap_kdc_dn = "cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                # this object needs to have read and write rights on
                # the realm container, principal container and realm sub-trees
                ldap_kadmind_dn = "cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldapi:///
                ldap_conns_per_server = 5
        }

/etc/krb5kdc/kadm5.acl：

*/[email protected] *

/etc/krb5kdc/kdc.conf：

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    SUBDOMAIN.DOMAIN.COM = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        #supported_enctypes = aes256-cts:normal aes128-cts:normal
        default_principal_flags = +preauth
    }

編輯：根據 user1686 的評論，我現在可以看到我的帳戶有潛在的存取問題。我對這件事有點不知所措，但使用“slapcat -b cn=config”我有以下 olcAccess 規則：

olcAccess: {0}to * by dn="cn=admin,dc=subdomain,dc=domain,dc=com" manage by dn="cn=surfrock66,ou=accounts,dc=subdomain,dc=domain,dc=com" manage by dn="cn=ldapbinduser,ou=accounts,dc=subdomain,dc=domain,dc=com" read by * break
olcAccess: {1}to dn.children="ou=accounts,dc=subdomain,dc=domain,dc=com" attrs=userPassword,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by self write by anonymous auth
olcAccess: {2}to attrs=krbPrincipalKey by anonymous auth by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by self write by * none
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=subdomain,dc=domain,dc=com" by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by * none
olcAccess: {4}to dn.subtree="dc=subdomain,dc=domain,dc=com" by self read

2022.12.08-08-36 PST 編輯：所以我更進一步，我做了以下事情：

addprinc ldap/[email protected]
ktadd -k /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab ldap/hostname.subdomain.domain.com
chown openldap:openldap /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab
chmod 640 /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab

我編輯了 /etc/default/slapd 並將其添加到其中：

export KRB5_KTNAME="FILE:/etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab"

當我重新啟動服務時，testaslauthd 仍然有效，但 ldapsearch -D 不起作用。我想知道是否需要在 ldap 中進行設定變更？根據我正在使用的資源之一，我建立了這個 ldif 用於配置，但最終我認為我不明白它會做什麼以及它是否正確：

dn: cn=config
changetype: modify
add: olcSaslHost
olcSaslHost: hostname.subdomain.domain.com
-
add: olcSaslRealm
olcSaslRealm: SUBDOMAIN.DOMAIN.COM
-
add: olcAuthzRegexp
olcAuthzRegexp: {0}"cn=([^/]*),cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=accounts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {1}"cn=host/([^/]*).subdomain.domain.com,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=hosts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {2}"uid=ldap/admin,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=admin,dc=subdomain,dc=domain,dc=com"

我認為這是最後缺少的一步？配置中是否有將 LDAP 指向 sasl 的內容？還是我處理這一切都是錯的？

Answer 1

principal是包含 DB2 格式的 KDC 資料庫的檔案。它不是在您的系統上創建的，因為您不使用後端db2– 您正在使用 LDAP，它取代了全部KDC 的本機儲存 – 因此本機資料庫檔案是不必要的，並且與您遇到的問題無關。

如果您按照說明運行kdb5_ldap_util create，則應該透過 LDAP 檢查它是否實際建立了必要的條目 - 至少應該有一個 的條目K/M@<realm>和另一個 的條目krbtgt/<realm>@<realm>。此錯誤訊息與「K/M」條目有關，該條目是持有資料庫 mkey（使用「主金鑰」密碼加密）的偽主體。

確保使用 KDC 的帳戶檢查 LDAP，以防萬一它沒有被授予讀取 Kerberos LDAP 物件所需的權限。 （帳戶不需要有一個uid；它們僅用作 LDAP 綁定帳戶，而不用作本機 Unix 帳戶。

由於 Ubuntu 有時使用 AppArmor，請務必檢查dmesgAVC 拒絕訊息 - 可能是不允許 KDC 讀取「service.keyfile」或存取您的 OpenLDAP 套接字。

此外，啟用statsLDAP 伺服器中的日誌等級以記錄所有查詢 – 這可能會顯示 KDC 正在不同的 DN 下查找（通常「ldap_kerberos_container_dn」將設定在其他 dbmodules 參數旁邊）。

最後，如果顯示該工具實際上並未連接到 LDAP，而是嘗試存取本機 db2 文件，那麼您的（KDC 特定設定檔）strace kadmin.local中的設定可能會，並且優先權高於 krb5.conf 全域設定。kdc.conf/var/lib/krb5kdc/kdc.conf

---

（此外，如果您是使用 db2，主體資料庫在首次啟動時仍然不會自動建立 – 這需要透過執行kdb5_util create [-s]並提供主加密金鑰來手動完成，就像您使用「kdb5_ldap_util create」為 LDAP 後端所做的那樣。

該文件中沒有但我在其他地方看到的一件事是創建一個“[domain_realm]”部分並將我的網域添加到其中，我已經這樣做了，但沒有幫助。

只有當取得未 1:1 對應到其領域的主機名稱的票證時，Kerberos 用戶端才需要這樣做（典型範例是 mit.edu → ATHENA.MIT.EDU）。它與 KDC 的啟動無關。

我建立了一個日誌記錄部分，它需要修改 systemd 服務以允許寫入 /var/log/kerberos，

如果您改為登錄，則不會SYSLOG，這可能是為 Ubuntu 編寫 systemd 服務的人的意圖。

---

因為我的儲存位於 LDAP 中，所以不是不存在嗎？

不，/etc/krb5.keytab 檔案不是 KDC 資料庫的一部分 – 它屬於主持人作為「網域成員」並儲存相當於電腦帳戶的 Kerberos 密碼。 Kerberos 領域中的每台電腦都應該有自己的 /etc/krb5.keytab，至少包含主體host/<fqdn>。

我正在嘗試讓 LDAP 直通身份驗證正常工作，以便 kerberos 密碼是真實的；我發現很多文件都比較舊。我看到大多數人推薦我認為我設定的 saslauthd，但現在它正在尋找 /etc/krb5.keytab

對於 OpenLDAP，是的，通常您需要 saslauthd。

1. 當綁定到具有 的 DN 時userPassword: {SASL}foo@BAR，slapd 將使用 libsasl「密碼檢查」功能。
2. 根據配置pwcheck_方法，libsasl會聯絡saslauthd來驗證密碼。
3. saslauthd 將使用透過其選項配置的後端-a來進行實際驗證。
4. 透過-a krb5後端，saslauthd 將嘗試使用提供的使用者名稱和密碼（相當於kinit）從 KDC 取得初始 Kerberos 票證。
5. 如果成功取得初始票證，saslauthd 將另外請求自己的服務票並將嘗試使用機器的金鑰表對其進行解密。
6. 如果可以取得服務票並解密，密碼被接受。

最後一步是防止 KDC 欺騙攻擊所需要的。傳統上，Kerberos KDC 會在不驗證您的密碼的情況下頒發票證（密碼錯誤僅意味著客戶端無法解密收到的票證），而惡意KDC 仍然可以這樣做- “預身份驗證”在協議級別不是強制性的。因此，saslauthd 需要執行與任何其他 Kerberized 服務相同的操作，以驗證票證是否合法 - 嘗試使用服務金鑰表對其進行解密。 （pam_krb5 甚至 Windows 在 AD 登入期間都會執行相同的操作。）

我做了 host/hostname.fqdn@REALM 和 ldap/hostname.fqdn@REALM。我為 ldap 建立了一個金鑰表；我將 1 位使用者的通行證轉換為「{SASL}name@REALM」。在該用戶上使用testsaslauthd，我獲得了成功。對該使用者使用 ldapsearch，信用無效。我認為 ldap 沒有與 saslauthd 對話？在“Kerberos 身份驗證”下，我添加了配置：help.ubuntu.com/community/OpenLDAPServer，但是當我執行“ldapsearch -Y GSSAPI”時，我收到“GSSAPI 錯誤：沒有憑證支援...”

-Y GSSAPI是直接的Kerberos 驗證 – 完全獨立於 saslauthd 和密碼直通。也就是說，slapd 甚至不接收 Kerberos 密碼 – 它只接收 Kerberos票並根據其服務金鑰表在內部進行驗證。

1. 對於 SASL GSSAPI，slapd 服務本身（而不是 saslauthd）需要ldap/<fqdn>. （預設情況下，所有服務都會在系統/etc/krb5.keytab 中查找其密鑰，但為了安全起見，將事物分開並將slapd 的KRB5_KTNAME 設置為不同的路徑可能會更好- 這樣您就不需要讀取它存取系統密鑰表。

2. 客戶還需要知道它的目的是請求 的票證ldap/<fqdn>，因此連接到 IP 位址可能不起作用（除非它設定了正確的 rDNS） – 您應該專門連接到 ldap://<fqdn>。 （這與 TLS SNI 或 TLS 憑證中的主機名稱非常相似）。

   如果有疑問，請KRB5_TRACE=/dev/stderr在呼叫客戶端之前進行匯出，以確定它嘗試為哪個主體建立 TGS-REQ（或查看 KDC 日誌或網路擷取）。

3. 客戶必須已經擁有最初的Kerberos 票證 (krbtgt/REALM) 存在，也就是說，您必須kinit事先這樣做。如果您還沒有 TGT，Kerberos 用戶端不會問取得您的密碼 – 他們將立即無法進行身份驗證。

密碼直通僅與「簡單」綁定 ( ldapsearch -D <user_dn> -W) 和 SASL PLAIN 綁定相關。首先測試“簡單”綁定（您基本上可以忽略 SASL PLAIN）。

Answer 2

您必須在作業系統上安裝 libsasl2 並將 krb5.keytab 的所有權授予 openldap 使用者。

在 Debian 上：

sudo apt install libsasl2-2 libsasl2-modules-gssapi-mit

進而

sudo chown openldap:openldap /etc/krb5.keytab 或其他金鑰表

編輯：但要小心同一台機器/容器（具有多個伺服器）上的多個金鑰表。