web-dev-qa-db-ja.com

MIT KerberosとActive Directoryの間にレルム間の信頼を設定する場合、「KDCは暗号化タイプをサポートしていません」

現在、専用のKrberos 5レルム(MIT、Solaris 11では_krb5-config --version_が返す:Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3))を使用して、一連のSolarisマシンとLinuxマシンがある環境を設定しています。別のレルム用のActive Directory(Windows 2003)サーバーもあります。

私の目標は、すべてのユーザーをADサーバーに置き、MITベースのレルムにHost/nnn、nfs/nnn、cifs/nnnプリンシパルを置くことです。これら2つのレルムの間にクロスドメイン信頼を設定しようとしています。

以下を想定します。

  • Unixレルム:EXAMPLE.COM
  • ADレルム:AD.EXAMPLE.COM

Microsoftのドキュメント に従って、ADのレルム間の信頼を双方向の信頼で設定しました。

レルム間の認証は一方向でしか機能しないということが起こります。 ADからUnixへの動作:

_# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
[email protected]: kvno = 1
_

しかし、その逆は行われず、エラーメッセージが表示されます:KDCは、adtest @ AD.EXAMPLE.COMの資格情報を取得する際に暗号化タイプをサポートしていません

_# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
kvno: KDC has no support for encryption type while getting credentials for [email protected]
_

私はいろいろな種類のものを試したことに注意してください。それらのいくつかは:

  • Unix側のレルム間キーを_rc4-hmac_のみを使用するように構成しました。その結果、kvnoの呼び出しでもMicrosoft側でKDCを見つけることができなくなりました。
  • _default_tkt_enctypes_の使用を強制する_default_tgs_enctypes_および_rc4-hmac_エントリを追加しました。これは、ADに対するログイン認証を機能させるために必要でした。

これの原因は何ですか?実際に何が起こっているのかをどうやって理解できますか?特に、KDCがサポートしていない、どの暗号化タイプを使用しようとしているのかを正確に知ることは非常に役立ちます。エラーを送信したKDCを知ることも役立ちます。

完全を期すために、ここに_krb5.conf_ファイルの内容を示します。

_[libdefaults]
    default_realm = EXAMPLE.COM
    allow_weak_crypto = true
        verify_ap_req_nofail = false
        default_tkt_enctypes = rc4-hmac
        default_tgs_enctypes = rc4-hmac

[realms]
    EXAMPLE.COM = {
        kdc = unix-server.example.com
        admin_server = unix-server.example.com
    }
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        admin_server = ad-server.ad.example.com
    }

[domain_realm]
    .example.com = EXAMPLE.COM
    .ad.example.com = AD.EXAMPLE.COM

[capaths]
    EXAMPLE.COM = {
        AD.EXAMPLE.COM = .
    }
    AD.EXAMPLE.COM = {
        EXAMPLE.COM = .
    }

[logging]
    default = FILE:/var/krb5/kdc.log
    kdc = FILE:/var/krb5/kdc.log
    kdc_rotate = {
        period = 1d
        versions = 10
    }

[appdefaults]
    kinit = {
        renewable = true
        forwardable = true
    }
_
5

私は問題を解決しました。他の誰かが同じ問題に直面した場合に備えて、ここに返信を投稿しています。

解決策は非常に簡単でした。レルム間認証プリンシパルがrc4-hmacタイプの単一のエンコードタイプで作成されていることを確認する必要がありました。

addprinc -e rc4-hmac krbtgt/[email protected]
addprinc -e rc4-hmac krbtgt/[email protected]

私の知る限り、MIT KDCはADサーバーにチケットを送信するときに最も安全なエンコードタイプを使用します。ADサーバーはそのエンコードを処理できないため、暗号化タイプがサポートされていないというエラーが表示されます。プリンシパルに対して単一のエンコードタイプを使用するだけで、MITサーバーはADサーバーと通信するときにそのタイプを使用します。

3

ジャーナルのエラーをチェックして解決しました。エラーは述べました:
-ログは、火曜日2018-05-22 13:03:55 UTCに始まり、月曜日2018-06-18 10:41:01 UTCに終わります。 -
6月18日10:40:55 nlxxp1 realmd [1609]:*解決:_ldap._tcp.local.domain
Jun 18 10:40:55 nlxxp1 realmd [1609]:* LDAP DSEルックアップの実行:10.x.x.1
Jun 18 10:40:55 nlxxp1 realmd [1609]:* LDAP DSEルックアップの実行:10.x.x.30
Jun 18 10:40:55 nlxxp1 realmd [1609]:* LDAP DSEルックアップの実行:10.x.x.60
6月18日10:40:55 nlxxp1 realmd [1609]:*正常に検出されました:local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]:*パッケージがインストールされていると想定
6月18 10:41:00 nlxxp1 realmd [1609]:* LANG = C/usr/sbin/adcli join --verbose --domain local.domain --domain-realm LOCAL.DOMAIN --domain-コントローラ10.xx1 --login-type user --login-user localuser --stdin-password
Jun 18 10:41:00 nlxxp1 realmd [1609]:*ドメイン名を使用:local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]:* fqdnから計算されたコンピューターアカウント名:NLXXP1
Jun 18 10:41:00 nlxxp1 realmd [1609]:*ドメインレルムの使用:local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]:*ドメインコントローラへのnetlogon pingの送信:cldap://10.x.x.1
Jun 18 10:41:01 nlxxp1 realmd [1609]:*受信したNetLogon情報:dc.local.domain
Jun 18 10:41:01 nlxxp1 realmd [1609]:* krb5.confスニペットを/var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0Bに書き出しました
6月18日10:41:01 nlxxp1 realmd [1609]:!次のように認証できませんでした:[email protected]:KDCは暗号化タイプをサポートしていません
Jun 18 10:41:01 nlxxp1 realmd [1609]:adcli:could n't connect to local.domain domain:could n't authentication as:[email protected]:KDC does not support for encryption type
6月18日10:41:01 nlxxp1 realmd [1609]:!ドメインに参加できませんでした

私のドメインは、2003 DCと混合ドメインです。
DNSに入り、2003の_ldap._tcp.local.domainレコードを変更した後DC(私はそれに重いウェイト400を与えました)、新しい(2012R2 DC)サーバーをドメインに参加させることができました。

使用した暗号化タイプは2003 DCでサポートされていなかったと思います。

0