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 directory studio で作成しました)。「dpkg-reconfigure krb5-config」を実行し、/etc/krb5.conf を編集してサーバーとレルムを追加しました。そのドキュメントには記載されていませんが、他の場所で目にした 1 つの方法は、セクション "[domain_realm]" を作成し、そこにドメインを追加することです。これを実行しましたが、役に立ちませんでした。ログ記録セクションを作成しましたが、systemd サービスを変更して /var/log/kerberos への書き込みを許可する必要がありますが、問題ありません。次に、リストされているように「kdb5_ldap_util」コマンドを実行し、パスワードを入力すると、正常に完了したように見えます。kdc-service および kadmin-service のパスワードの stash を実行すると、正常に完了します。 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"

サービスを再起動すると、testsaslauthd は引き続き機能しますが、ldapsearch -D は機能しません。ldap で構成を変更する必要があるかどうか疑問に思っています。作業していたリソースの 1 つから、構成用に次の 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

principalDB2形式のKDCデータベースを含むファイルです。使用していないバックdb2エンド – LDAPを使用します。全てKDC のローカル ストレージ - したがって、ローカル データベース ファイルは不要であり、発生している問題とは無関係です。

kdb5_ldap_util create指示に従って実行した場合は、LDAP を介して、必要なエントリが実際に作成されたかどうかを確認する必要があります。少なくとも、 のエントリと のエントリK/M@<realm>が 1 つずつあるはずですkrbtgt/<realm>@<realm>。エラー メッセージは、データベース mkey (「マスター キー」パスワードで暗号化されている) を保持する疑似プリンシパルである「K/M」エントリに関するものです。

Kerberos LDAPオブジェクトを読み取るために必要な権限が付与されていない場合に備えて、KDCのアカウントを使用してLDAPを確認してください。（アカウントは必要uid を持つ必要があります。これらはローカル Unix アカウントとしてではなく、LDAP バインド アカウントとしてのみ使用されます。

Ubuntu は AppArmor を使用することがあるため、AVC 拒否メッセージを必ず確認してくださいdmesg。KDC が「service.keyfile」の読み取りや OpenLDAP ソケットへのアクセスを許可されていない可能性があります。

さらに、statsLDAP サーバーのログレベルを有効にして、すべてのクエリをログに記録します。これにより、たとえば、KDC が別の DN を参照していることが明らかになる可能性があります (通常、"ldap_kerberos_container_dn" は他の dbmodules パラメータの隣に設定されます)。

最後に、strace kadmin.localツールが実際には LDAP に接続しておらず、代わりにローカルの db2 ファイルにアクセスしようとしていることが示された場合は、kdc.confkrb5.conf のシステム全体の設定を上書きする設定が (KDC 固有の設定ファイル) にある可能性があります。通常、KDC 設定は krb5.conf のグローバル設定から読み込まれ/var/lib/krb5kdc/kdc.conf、その設定よりも優先されます。

---

（さらに、もしあなたがだったdb2 を使用すると、最初の起動時にプリンシパル データベースは自動的に作成されません。これは、kdb5_util create [-s]LDAP バックエンドで「kdb5_ldap_util create」を使用して行ったのと同じように、マスター暗号化キーを実行して手動で行う必要があります。

そのドキュメントには記載されていないが、他の場所で目にした方法は、「[domain_realm]」セクションを作成し、そこに自分のドメインを追加するというものです。実際に実行してみましたが、効果はありませんでした。

これは、レルムに 1:1 でマップされないホスト名のチケットを取得する場合 (典型的な例は mit.edu → ATHENA.MIT.EDU) にのみ Kerberos クライアントに必要です。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 は提供されたユーザー名とパスワード ( に相当) を使用して KDC から初期 Kerberos チケットを取得しようとしますkinit。
5. 最初のチケットが正常に取得された場合、saslauthdはさらにサービスチケット自体マシンのキータブを使用して復号化を試みます。
6. サービスチケットを取得できればそして解読され、パスワードが受け入れられました。

最後のステップは、KDC スプーフィング攻撃を防ぐために必要です。従来、Kerberos KDC はパスワードを検証せずにチケットを発行していました (パスワードが間違っていると、クライアントは受信したチケットを復号化できないということになります)。悪意のある KDC は、依然としてそのようにすることができます。プロトコル レベルでは、「事前認証」は必須ではありません。そのため、saslauthd は、チケットが正当であることを確認するために、他の Kerberos 化されたサービスと同じこと、つまりサービス キータブを使用してチケットを復号化しようとする必要があります (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 の場合、saslauthd ではなく slapd サービス自体にキータブが必要です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

OS に libsasl2 をインストールし、krb5.keytab の所有権を openldap ユーザーに付与する必要があります。

Debianの場合:

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

その後

sudo chown openldap:openldap /etc/krb5.keytab または他のキータブ

編集: ただし、同じマシン/コンテナー (複数のサーバー) 上の複数のキータブには注意してください。