web-dev-qa-db-ja.com

Apache Kerberos認証：KDCは暗号化タイプをサポートしていません

ここで見つけたすべての解決策がうまくいかなかったので、この問題について新しいスレッドを投稿します。

キータブ経由でAD2012サーバーのKerberosで認証するようにApache2を構成しようとしています。

まず、ADで可能なすべての暗号化をアクティブにしましたmsDS-EncryptedSupportedTypes

これは私のクライアントです（debian）krb5.conf：

[logging]
default = FILE:/var/log/krb5.log

[libdefaults]
default_realm = REALM.LOCAL
kdc_timesync = 1 
ccache_type = 4 
forwardable = true
proxiable = true 
# for testing purpose only
allow_weak_crypto = true

default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
REALM.LOCAL = { 
    kdc = kdc.realm.local
    admin_server = kdc.realm.local
    default_domain = realm.local
}   

[domain_realm]
.realm.local = REALM.local
realm.local = REALM.LOCAL

これが私が使用するキータブです：

klist -kte /etc/Apache2/http.keytab

Keytab name: FILE:/etc/Apache2/http.keytab
KVNO Timestamp           Principal
---- ------------------- -------------------------------------------------------------
  14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-crc)
  14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-md5)
  14 01/01/1970 01:00:00 HTTP/[email protected] (arcfour-hmac)
  14 01/01/1970 01:00:00 HTTP/[email protected] (aes256-cts-hmac-sha1-96)
  14 01/01/1970 01:00:00 HTTP/[email protected] (aes128-cts-hmac-sha1-96)

Keytabを使用してKDCで認証すると、すべて正常に動作します。

kinit -Vkt /etc/Apache2/http.keytab HTTP/server.realm.local

Authenticated to kerberos v5

klist -e

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/[email protected]
Valid starting 
06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

ここで.htaccessを構成して、このような認証をテストします。

AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm REALM.LOCAL
Krb5KeyTab /etc/Apache2/http.keytab
KrbServiceName HTTP/server.realm.local
Require valid-user

認証しようとしたときに追加します。これはログにあります。

[デバッグ] src/mod_auth_kerb.c（1939）：[クライアント192.168.4.16] kerb_authenticate_userがユーザー（NULL）とauth_type Kerberosで入力されました

[デバッグ] src/mod_auth_kerb.c（1691）：[クライアント192.168.4.16] KRB5 GSS-APIを使用したクライアントデータの確認

[デバッグ] src/mod_auth_kerb.c（1707）：[クライアント192.168.4.16]クライアントは資格情報を委任しませんでした

[デバッグ] src/mod_auth_kerb.c（1735）：[クライアント192.168.4.16]警告：受信したトークンはNTLMのようですが、Kerberosモジュールではサポートされていません。 IE構成を確認してください。

[デバッグ] src/mod_auth_kerb.c（1138）：[クライアント192.168.4.16] GSS-API major_status：00010000、minor_status：00000000

[エラー] [クライアント192.168.4.16] gss_accept_sec_context（）が失敗しました：サポートされていないメカニズムが要求されました（、不明なエラー）

ネットワークトレースは、TGS_REQ本体がAES256で暗号化され、TGTがPA-DATAで暗号化されていることを示しました。しかし、私はそれに応じてKRB5KDC_ERR_ETYPE_NOSUPPを受け取ります。

サービスを手動で認証すると、次のようになります。

kinitユーザー名

knvo HTTP/server.realm.local @ REALM.LOCAL

klist -e

Valid starting 
06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
06/04/2017 20:35:00 07/04/2017 06:32:09 HTTP/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): des-cbc-crc, des-cbc-md5

DES暗号化がどこから来ているのかわかりません。

何が悪いのかについての洞察はありますか？どうすれば調査をさらに進めることができますか？

PDATE： DESサポート付きのADサービスアカウントが疑われます。読んだ内容では、他の暗号アルゴリズムが無効になる可能性があります。アクセスできません。今はテストできません。

active-directoryapache-2.4kerberosmitkerberos
2
Plup

これは確かに、ADでのDESサポートのアクティブ化によるものでした。これは、実際には他の暗号アルゴリズムをオーバーライドします。

そのため、サービスアカウントで無効にすると、AES256で交渉が機能します。

1
Plup