web-dev-qa-db-ja.com

「GSSException Defective Tokenが検出されました」-Kerberosを使用してWindowsで実行されているTomcatに対して認証しようとする場合

Windows 2012で実行している場合、Java Webコンテナー（TomcatとJettyの両方を試しました）への認証に苦労しています。

Negotiate認証スキームを試行するたびにエラーが発生します：org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

再現手順

Windows Server 2012または2016インスタンスのセットアップから始めて、Active Directoryドメインサービスをインストールします。

私の例では、次のものを作成しました。

  • NETBIOSドメイン：NICKIS

  • DNSドメイン：nickis.life

Active Directoryでkerberosサブジェクトユーザーを作成する

重要：名、姓、氏名が同じであることを確認してください！

私の場合の新しいユーザーは次のとおりです。

[〜＃〜] dn [〜＃〜]= _CN=kerberos500,CN=Users,DC=nickis,DC=life_

login + domain= _[email protected]_

NETBIOS\samAccountName= _NICKIS\kerberos500_

Windows Active Directoryサーバーからsetspnコマンドを実行します

_setspn -A HTTP/[email protected] kerberos500
_

出力例：

_C:\Users\Administrator>setspn -A HTTP/nickis.life kerberos500
Checking domain DC=nickis,DC=life 
Registering ServicePrincipalNames for CN=kerberos500,CN=Users,DC=nickis,DC=life
        HTTP/kerberos500.nickis.life
Updated object
_

Windows Active Directoryサーバーからktpassコマンドを実行します

_ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass XXXXpasswordforkerberos500userXXXX -crypto DES-CBC-MD5 -pType KRB5_NT_PRINCIPAL +DesOnly
_

出力例：

_C:\Users\Administrator>ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass xxxxxxxx -crypto DES-CBC-MD5 -pType KRB5_NT_PRINCIPAL +DesOnly
Targeting domain controller: WIN-OVV6VHBGIB8.nickis.life
Using legacy password setting method
Successfully mapped HTTP/kerberos500.nickis.life to kerberos500.
Key created.
Output keytab to c:\Users\Administrator\kerberos500.keytab:
Keytab version: 0x502
keysize 71 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0xcd07200bea625d20)
Account kerberos500 has been set for DES-only encryption.
_

この時点で、キータブファイルが作成されています。

_c:\Users\Administrator\kerberos500.keytab
_

ユーザープリンシパル：

_HTTP/[email protected]
_

これらは、GSSApiに提供してKerberosでシングルサインオンを取得するために必要な2つの入力です。

そこで、これらの入力を、HadoopセキュリティモジュールのWebコンテナのKerberosセキュリティレルムにデプロイしました。

カールテストカールを使ってテストしようとして失敗しました：

_curl --negotiate -u : http://nickis.life:8080/my/webapp_

Internet ExplorerテストInternet Explorerを使用してみました。 Internet Explorerの信頼できる役割に_nickis.life_ドメインを追加しました。次に、Internet Explorerでサイトを起動します。 http://nickis.life:808

いずれにしても、以下のエラーが表示されます。

_org.Apache.hadoop.security.authentication.client.AuthenticationException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.Java:398) ~[hadoop-auth-2.7.1.jar:?]

...

Caused by: org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at Sun.security.jgss.GSSHeader.<init>(Unknown Source) ~[?:1.8.0_131]
    at Sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) ~[?:1.8.0_131]
    at Sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source) ~[?:1.8.0_131]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler$2.run(KerberosAuthenticationHandler.Java:365) ~[hadoop-auth-2.7.1.jar:?]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler$2.run(KerberosAuthenticationHandler.Java:347) ~[hadoop-auth-2.7.1.jar:?]
    at Java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_131]
    at javax.security.auth.Subject.doAs(Unknown Source) ~[?:1.8.0_131]
    at org.Apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.Java:347) ~[hadoop-auth-2.7.1.jar:?]
_

私は困惑しています。注：私はあちこちでいくつかのリンクを見つけましたが、ここで要約したように、それらのいずれも従った手順に含まれていませんでした。

誰も私がここで間違っていることをトレースできますか？

更新：

  • ドメインが_fusionis.life_に設定されたADサーバーがあり、ADサーバーは_WIN-OVV6VHBGIB8.fusionis.life_です
  • Tomcatサーバーをドメイン内の別のWindowsマシンに移動しました。 _DESKTOP-VTPBE99.fusionis.life_
  • _dnsmgmt.msc_を開き、ホストが_DESKTOP-VTPBE99.fusionis.life_ボックスのIPに設定された「kerberos500.nickis.life」で「前方参照ゾーン」を追加しました。
  • ADアカウントを削除して再作成し、チケットの回答の1つで提案されているようにキータブを再生成しました。

C:\Users\Administrator>ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass xxxxxxxxx -crypto ALL -pType KRB5_NT_PRINCIPAL Targeting domain controller: WIN-OVV6VHBGIB8.fusionis.life Using legacy password setting method Successfully mapped HTTP/kerberos500.nickis.life to kerberos500. Key created. Key created. Key created. Key created. Key created. Output keytab to c:\Users\Administrator\kerberos500.keytab: Keytab version: 0x502 keysize 67 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x04e30b9183ba8389) keysize 67 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x04e30b9183ba8389) keysize 75 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0xe39a141de38abd8750bf9c0bf49fd1c5) keysize 91 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0xe368a1b060cfe4816f522c1c5f62ca07fe201ed96c6d018054dfbd5b86251892) keysize 75 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x1b1a548fa2893a78c6f4c7f9c482b614)

今、私は新しいエラーを取得しています...

GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)

更新：

最終的に解決しました。 _fusionis.life_が_nickis.life_と同じホスト上にある必要があるため、この最終エラーが発生しました。

javawindowsactive-directorykerberosgssapi
10
Nicholas DiPiazza

エラー「Defective token detected」は、おそらく ntlm トークンが検出されたことを意味します。 kerberos が失敗した場合-それ以外の場合にWebサーバーから指示されない場合、それはNegotiateのメカニズムが一般的なWebブラウザー内で使用します。 windows オペレーティングシステムでは、IE上のWebブラウザ（および正しく構成されている場合はFirefox））は、基本的に、Kerberosを実行しない場合、 NTLMトークンを送信します。そして、サーバーは「ノーウェイ」と応答します。NTLMについても知らないので、送信したものを欠陥品と呼んでいます。初めてこれを設定しているようですので、 Kerberosが失敗したときのフォールバックメカニズム（NTLMなど）を構成するため、そのエラーメッセージを表示します。Kerberosが失敗する理由を理解することでこれを解決します。これらの2つの項目を解決したとしても、暗号化に関連して失敗し続ける可能性のある3番目の理由と4番目の理由があります。

  1. HTTPサービスの spn は、ブラウザが入力したURLと一致しません。これらは一致する必要があります。一致しない場合、Kerberosは失敗します。動作させるには、ブラウザで http://kerberos500.nickis.life:808 ではなく、 http://nickis.life:808 を使用する必要があります。私はあなたの keytab 作成構文で見たものに基づいて言っています。その中で、SPNをHTTP/[email protected]のようにコーディングしました。そのため、 http://kerberos500.nickis.life:808 を使用する必要があります。 http://nickis.life:808 にアクセスするように指示すると、ブラウザはWebサービスにアクセスする方法を知りません。そのトップURLを使用すると、ブラウザーは、Active Directoryで実行されているWebサービスを見つける必要があると想定します domaincontroller （nickis.lifeを持つものはすべて、ドメインコントローラーで実行されると想定されます）。セキュリティ上の理由から、DCはWebサーバーを実行しないでください。
  2. 以下を追加する必要があります http://kerberos500.nickis.life IE settings。または、*。nickis.lifeも機能します（実際に信頼済みサイトと呼ばれている場合は、信頼済みロールと呼びます）。
  3. Kerberos暗号化タイプをDES-CBC-MD5に制限しています。 Windows Server 2008 Active Directory R2以降、DESはデフォルトで無効になっています。DESは、古く、一般的に安全性の低い暗号化タイプです。または、さらに良いことに、AES256。以下の私の例に従ってキータブを再生成することで、それを修正できます。
  4. ADユーザーアカウントkerberos500で、[アカウント]タブに移動し、一番下までスクロールして、DES、AES 128、およびAES 256のすべてのボックスをオンにします。ダイアログボックスを終了します。上記のすべてを行った場合でも、これらのボックスをオンにする必要があります。そうしないと、Kerberos認証が失敗します。

キータブを適切に再生成する方法：そのユーザーアカウントに関連付けられたキータブを作成する予定があるときはいつでも、setspn -aコマンドを実行してADユーザーにSPNを追加しないでください。その理由は、keytab作成コマンドがコマンドの一部としてSPNをユーザーアカウントに追加するためです。上記の私のアドバイスに従ってもシナリオが機能しない場合は、以下のようにsetspn -Dを使用してSPNを削除する必要があります。

setspn -D HTTP/[email protected] kerberos500

その後、キータブを再生成しますが、私の唯一の変更点は、すべての暗号化タイプを使用するように指示したことです。クライアントとサーバーは、認証プロセス中に最も一般的なものに同意します。

ktpass -out c:\Users\Administrator\kerberos500.keytab -princ HTTP/[email protected] -mapUser kerberos500 -mapOp set -pass XXXXpasswordforkerberos500userXXXX -crypto ALL -pType KRB5_NT_PRINCIPAL


次に、古いキータブを新しいキータブに置き換えます。キータブの追加の詳細情報については、Kerberosキータブの作成方法に関する私の技術記事の詳細をご覧ください： Kerberosキータブ–説明 。私は頻繁に戻って、このフォーラムにある質問に基づいて編集します。

ところで、HTTP/kerberos500.nickis.lifeはサービスプリンシパルであり、質問で書いたユーザープリンシパルではありません。このようなHTTPシナリオでKerberosをテストするのにWebブラウザーのみを使用し、cURLは使用しません。

上記で強調した4つのポイントすべてを真剣に検討していただければ、この問題を解決できます。

EDIT1：この回答は、kerberos500.nickis.lifeの完全修飾ドメイン名を持つホストで実行されているHTTPサービスがあることを前提としています。その名前のそのようなホストがない場合、私の答えはわずかに変わります。もしあれば教えてください。

EDIT2：http://nickis.life:808 のURLを使用して認証の目的を達成するには、既に作成したものと同じキータブを使用し続けます。

ADアカウントNICKIS\kerberos500で、[アカウント]タブに移動し、一番下までスクロールして、[このアカウントにKerberos DES暗号化タイプを使用]のチェックボックスをオンにします。

次に、グループポリシーを介してADドメインレベルでDES暗号化自体を有効にします。これを行うには、以下を実行します。

  1. グループポリシー管理コンソール（GPMC）を開きます。
  2. 既定のドメインポリシーGPOを編集します。 （代わりに新しいドメインレベルGPOを作成して編集する方が安全ですが、それはあなた次第です）。
  3. [コンピューターの構成]> [ポリシー]> [Windowsの設定]> [セキュリティの設定]> [ローカルポリシー]> [セキュリティオプション]> [ネットワークセキュリティ：Kerberosで許可される暗号化タイプを構成]に移動し、DES_CBC_MD5およびDES_CBC_MD5の両方のチェックボックスをオンにします。重要：同じグループポリシーで、RC4、AES128、およびAES256のチェックボックスもオンになっていることも確認してください。これらの暗号化タイプは、Webサイトへのチケットには使用されませんが、ドメイン内の他のすべてには使用されます。 [OK]をクリックしてダイアログボックスを終了し、GPMCを閉じます。
  4. DCサーバーとクライアントの両方で 'gpupdate/force'コマンドを実行します。
  5. クライアントで「klist purge」を実行して、すべてのKerberosチケットを削除します。
  6. Webブラウザーでキャッシュをクリアし、すべてのCookieを削除します。
  7. DCサーバーがポート8080 TCP inbound。
  8. もう一回やってみよう。

参照： Kerberos対応暗号化タイプのWindows構成

編集3：Kerberos KDC（DC）、クライアント、およびサーバーを 同じ マシンで実行しないでください。それは、他のすべてを正しく行った場合でも、「欠陥トークンエラー」を取得するための古典的なレシピです。

編集4：（OPによって検証された最終更新）：新しいktpassキータブ作成出力を見て、私はこれを見た：ターゲットドメインコントローラ：WIN-OVV6VHBGIB8.fusionis.life。現在、キータブで定義されているSPNはHTTP/kerberos500.nickis.lifeです。 ADドメイン名は定義したSPNとは異なるため、これらのドメイン間に何らかの信頼関係のセットアップがない限り、これは機能しません。信頼できない場合は、代わりにHTTP/kerberos500.fusionis.lifeのSPNを使用する必要があります。

12
T-Heron