ここで提供しているのは、Simple and Protected GSS-API Negotiation (SPNEGO) TAI の問題および例外の診断に役立つトラブルシューティングのヒントのリストです。
トレース | 使用方法 |
---|---|
com.ibm.security.jgss.debug | JGSS コードを最初から終わりまでトレースするには、この JVM カスタム・プロパティーを all に設定します。trace.log ファイル、および SystemOut.log にメッセージが出力されます。 |
com.ibm.security.krb5.Krb5Debug | Kerberos5 固有の JGSS コードを最初から終わりまでトレースするには、 この JVM カスタム・プロパティーを all に設定します。 trace.log ファイル、および SystemOut.log にメッセージが出力されます。 |
com.ibm.ws.security.spnego.* | 「管理コンソール」 > 「トラブルシューティング」 > 「ロギングおよびトレース」> 「server1」 > 「ログ詳細レベルの変更」 > 「com.ibm.ws.security.spnego.*」を使用して、このトレースをオンに設定します。 trace.log ファイルにメッセージが出力されます。 |
症状 | [2/24/06 13:12:46:093 CST] 00000060 Context 2 com.ibm.ws.security.spnego.Context begin GSSContext accepted [2/24/06 13:12:46:093 CST] 00000060 Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: An invalid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: 60820160 06062b06 01050502 a1820154 `..` ..+. .... ...T 0010: 30820150 a0030a01 01a10b06 092a8648 0..P .... .... .*.H 0020: 82f71201 0202a282 013a0482 01366082 .... .... .:.. .6`. 0030: 01320609 2a864886 f7120102 0203007e .2.. *.H. .... ...~ 0040: 82012130 82011da0 03020105 a1030201 ..!0 .... .... .... 0050: 1ea41118 0f323030 36303232 34313931 .... .200 6022 4191 0060: 3234365a a5050203 016b48a6 03020125 246Z .... .kH. ...% 0070: a9161b14 57535345 432e4155 5354494e .... WSSE C.AU STIN 0080: 2e49424d 2e434f4d aa2d302b a0030201 .IBM .COM .-0+ .... 0090: 00a12430 221b0448 5454501b 1a773230 ..$0 "..H TTP. .w20 00a0: 30337365 63646576 2e617573 74696e2e 03se cdev .aus tin. 00b0: 69626d2e 636f6dab 81aa1b81 a76f7267 ibm. com. .... .org 00c0: 2e696574 662e6a67 73732e47 53534578 .iet f.jg ss.G SSEx 00d0: 63657074 696f6e2c 206d616a 6f722063 cept ion, maj or c 00e0: 6f64653a 2031302c 206d696e 6f722063 ode: 10, min or c 00f0: 6f64653a 2033370a 096d616a 6f722073 ode: 37. .maj or s 0100: 7472696e 673a2044 65666563 74697665 trin g: D efec tive 0110: 20746f6b 656e0a09 6d696e6f 72207374 tok en.. mino r st 0120: 72696e67 3a20436c 69656e74 2074696d ring : Cl ient tim 0130: 65204672 69646179 2c204665 62727561 e Fr iday , Fe brua 0140: 72792032 342c2032 30303620 61742031 ry 2 4, 2 006 at 1 0150: 3a31323a 34352050 4d20746f 6f20736b :12: 45 P M to o sk 0160: 65776564 ewed |
ユーザー処置 | この問題を解決するには、WebSphere
Application Server のシステム時刻を、AD サーバーの
時刻と 5 分以内に同期化することをお勧めします。
ベスト・プラクティスは、タイム・サーバーを使用して、すべてのシステムを同期化しておくことです。
Kerberos 構成ファイル内に
クロック・スキュー・パラメーターを追加することもできますし、
このパラメーターを調整することもできます。
注: クロック・スキュー・パラメーターのデフォルトは 300 秒 (すなわち 5 分) です。
|
問題 | 例外の発生: メカニズム 1.3.6.1.5.5.2 の名前を作成するために 使用できるファクトリーがない。 特定のメカニズムの名前を作成する処理を行うために、 使用できるファクトリーがありません。 |
症状 | [4/8/05 22:51:24:542 EDT] 5003e481 SystemOut O [JGSS_DBG_PROV] Provider IBMJGSSProvider version 1.01 does not support mech 1.3.6.1.5.5.2 [4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent > com.ibm.ws.security.spnego.ServerCredential initialize ENTRY SPNEGO014: Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, minor code: 0 major string: Unsupported mechanism minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2 at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30) at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36) at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217) at com.ibm.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:264) |
ユーザー処置 | java.security ファイルを調べて、
このファイルに IBMSPNEGO セキュリティー・プロバイダーが含まれていることと、
そのプロバイダーが正しく定義されていることを確認してください。
java.security ファイルには、
次のような行が含まれている必要があります。
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO |
症状 | JGSS ライブラリーが SPNEGO トークンを処理しようとしたときに、
次のようなエラーが表示されます。
Error authenticating request. Reporting to client Major code = 11, Minor code = 31 org.ietf.jgss.GSSException, major code: 11, minor code: 31 major string: General failure, unspecified at GSSAPI level minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.KrbException, status code: 31 message: Integrity check on decrypted field failed |
説明 | この例外は、チケットのデコード時に、
エンコード時と異なる鍵を使用した結果、発生したものです。
この状態には、以下のようなさまざまな原因が考えられます。
|
ユーザー処置 | Kerberos キー・タブ・ファイルに
関わる問題の場合は、このファイルを修正してください。
問題が複数の SPN 定義に関わるものである場合は、余分な SPN または競合している SPN を除去し、その SPN が Active Directory に登録されていないことを確認してから、その SPN を追加します。他のエントリーで SPN と衝突する SPN が定義されていないか、Active Directory を検索する必要がある場合があります。 SPN が登録されていないことを確認するには、以下のコマンドを実行します。
setspn –l useridこのコマンドは、以下の応答を戻します。 Cannot find account userid |
症状 | トレースが使用可能になっている場合は、以下のメッセージが表示されます。
[2/27/06 14:28:04:191 CST] 00000059 SpnegoHandler < com.ibm.ws.security.spnego.SpnegoHandler handleRequest: Received a non-SPNEGO Authorization Header RETURN |
説明 | 許可確認に対して、
クライアントが SPNEGO トークンでは
なく、NT LAN マネージャー (NTLM) 応答を戻しています。
この状態は、以下のいずれかが原因で発生することがあります。
|
ユーザー処置 | SPN が誤って HTTP/server.realm.com@REALM.COM のように @REALM.COM が付加されて定義されている場合は、そのユーザーを削除して定義し直し、SPN を再定義してください。 |
症状 | 無効なオプションが検出されました。
トレースが使用可能になっている場合は、以下のメッセージが表示されます。
com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request |
説明 | Kerberos 構成ファイルが、正しく構成されていません。 |
ユーザー処置 | renewable と proxiable が、 いずれも true に設定されていないことを確認してください。 |
症状 | トレースがオンの場合に受け取る、トレース内の次のメッセージを調べてください。
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0 message: Checksum error; received checksum does not match computed checksum |
説明 | RC4-HMAC 暗号化は、Microsoft Windows 2000 Kerberos
鍵配布センター (KDC) ではサポートされていません。
この状態を確認するには、トレースを調べて、で例外がスローされている場所を特定します。
着信チケットの内容がトレース内に表示されます。この着信チケットは暗号化されていますが、サービスの SPN は読み取り可能です。Microsoft Windows 2000 KDC が使用されており、このシステムが RC4-HMAC を使用するよう構成されている場合は、(期待されていた HTTP/hostname.realm@REALM ではなく) userid@REALM のチケットを表すストリングが表示されます。
例えば、以下は、Microsoft Windows 2000 KDC から受け取ったチケットの先頭部分を示しています。
0000: 01 00 6e 82 04 7f 30 82 04 7b a0 03 02 01 05 a1 ..n...0......... 0010: 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 ................ 0020: a5 61 82 03 a1 30 82 03 9d a0 03 02 01 05 a1 0a .a...0.......... 0030: 1b 08 45 50 46 44 2e 4e 45 54 a2 18 30 16 a0 03 ...REALM.COM.0.. 0040: 02 01 01 a1 0f 30 0d 1b 0b 65 70 66 64 77 61 73 .....0...userid 0050: 75 6e 69 74 a3 82 03 6e 30 82 03 6a a0 03 02 01 .a.f...n0..j....レルムは REALM.COM です。サービス名は、userid です。同一の SPN に対して正しく形成されているチケットは、以下のようになります。 0000: 01 00 6e 82 04 56 30 82 04 52 a0 03 02 01 05 a1 ..n..V0..R...... 0010: 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 ................ 0020: 82 61 82 03 7e 30 82 03 7a a0 03 02 01 05 a1 0a .a...0..z....... 0030: 1b 08 45 50 46 44 2e 4e 45 54 a2 2a 30 28 a0 03 ..REALM.COM.0... 0040: 02 01 02 a1 21 30 1f 1b 04 48 54 54 50 1b 17 75 .....0...HTTP..u 0050: 73 31 30 6b 65 70 66 77 61 73 73 30 31 2e 65 70 serid.realm.com. 0060: 66 64 2e 6e 65 74 a3 82 03 39 30 82 03 35 a0 03 ...n.....90..5.. |
ユーザー処置 | この問題を解決するには、 単一データ暗号化規格 (DES) を使用するか、KDC に Microsoft Windows 2003 Server を使用してください。 忘れずに SPN および Kerberos キー・タブ・ファイルを再生成してください。 |
症状 | 次のメッセージを調べてください。
Bad Request Your browser sent a request that this server could not understand. Size of request header field exceeds server limit. Authorization: Negotiate YII…… |
説明 | このメッセージは、Apache/IBM HTTP Server によって生成されます。 このサーバーは、ユーザーのブラウザーから戻された許可ヘッダーが大きすぎることを示しています。(上記のエラー・メッセージ内の) Negotiate という語の後の長いストリングは、SPNEGO トークンです。この SPNEGO トークンは、Microsoft Windows Kerberos トークンのラッパーです。Microsoft Windows の Kerberos トークンには、ユーザーの PAC 情報が含まれています。ユーザーが属しているセキュリティー・グループが増えると、それだけ多くの PAC 情報が Kerberos トークンに挿入され、SPNEGO が大きくなっていきます。IBM HTTP Server 2.0 (Apache 2.0 および IBM HTTP Server 6.0 も) は、受け入れ可能な HTTP ヘッダーのサイズを 8k に制限しています。多くのグループを持ち、ユーザーのメンバーシップが多くのグループに属している Microsoft Windows ドメインでは、ユーザーの SPNEGO トークンのサイズが 8K の制限を超える場合があります。 |
ユーザー処置 | 可能であれば、ユーザーがメンバーとなっている
セキュリティー・グループの数を減らしてください。
IBM HTTP Server 2.0.47 累積修正 PK01070 では、Microsoft の制限である 12k 以上の HTTP ヘッダー・サイズを使用できます。WebSphere Application Server バージョン 6.0 のユーザーは、この修正を修正パッケージ 6.0.0.2 で入手できます。 注: Apache 以外をベースとする Web サーバーの場合は、別の解決策が必要になる場合があります。
|
症状 | JGSS トレースが使用不可に なっていても、SystemOut.log を調べて、 そこに表示されている KRB_DBG_KDC メッセージをメモしてください。 |
説明 | ほとんどの JGSS トレースは、com.ibm.security.jgss.debug プロパティーによって制御されますが、 小さなメッセージ・セットは com.ibm.security.krb5.Krb5Debug プロパティーによって制御されます。 com.ibm.security.krb5.Krb5Debug プロパティーの値がデフォルトの場合、 いくつかのメッセージが SystemOut.log に書き込まれます。 |
ユーザー処置 | すべての KRB_DBG_KDC メッセージを
SystemOut.log から除去するには、JVM
プロパティーを以下のように設定します。
-Dcom.ibm.security.krb5.Krb5Debug=none |
症状 | アプリケーションにカスタム HTTP 401 エラー・ ページが含まれている場合、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) トラスト・アソシエーション・インターセプター (TAI) で 生成された HTTP 応答ページが、ブラウザーに表示されません。 |
説明 | アプリケーションに カスタム HTTP 401 エラー・ページが含まれている 場合、SPNEGO TAI で生成された HTTP 応答ページは ブラウザーに表示されません。 代わりに、カスタム HTTP 401 エラー・ページが表示されます。 |
ユーザー処置 | HTTP 401 ページをカスタマイズして、SPNEGO を 使用するようにブラウザーを構成する方法についての 情報を含めることができます。 詳しくは、SPNEGO を使用するためのクライアント・ブラウザーの構成 およびSPNEGO TAI カスタム・プロパティー構成 を参照してください。 |
症状 | ユーザー ID/パスワードを使用した
ログイン・ステップを行っている
場合、SPNEGO TAI との相互作用中に HTTP Post パラメーターが
失われてしまいます。
「ユーザー ID/パスワードを使用したログイン・ステップを行う」 とは、Microsoft Internet Explorer が、 最初に SPNEGO トークンを使用して、応答を試みていることを意味します。 この応答が失敗すると、Microsoft Internet Explorer は、 ユーザー ID/パスワード確認によって取得する NTLM トークンを使用して、 応答を試みます。 |
||||||||||
説明 | Microsoft Internet Explorer は、ユーザーからの要求中、状態を維持します。
要求に対して「HTTP 401 Authenticate Negotiate」という応答が与えられ、ブラウザーがそれに対して、ユーザー/パスワードの要請で取得された NTLM トークンで応答した場合、そのブラウザーは要求を再処理依頼します。この 2 回目の要求に対して、リダイレクト先は同じ URL であるが、(Javascript を介して) 新しい引数が指定されている HTML ページで応答した場合、ブラウザーは POST パラメーターを再処理依頼しません。 注: この問題を回避するには、自動リダイレクトを実行しないことが重要です。ユーザーがリンクをクリックした場合、この問題は発生しません。
|
||||||||||
ユーザー処置 | ブラウザーは、認証/折衝の確認に対して、 SPNEGO トークンではなく NTLM トークンで応答します。 SPNEGO TAI は NTLM を認識するので、HTML ページとともに HTTP 403 応答を戻します。 ブラウザーが Javascript の redirTimer 関数を実行すると、 元の要求にあった GET パラメーターの POST は失われます。 SPN<id>.NTLMTokenReceivedPage プロパティーを使用することにより、適切なメッセージ・ページをユーザーに戻すことができます。(ユーザー定義プロパティーがない場合に) 戻されるデフォルト・メッセージは、以下のとおりです。
"<html><head><title>An NTLM Token was Received.</title></head>" + "<body>Your browser configuration is correct, but you have not logged into a supported Windows Domain." + "<p>Please login to the application using the normal login page.</html>"; SPN<id>.NTLMTokenReceivedPage プロパティーを使用すると、正確な応答をカスタマイズできます。戻された HTML がリダイレクトを実行しないことが重要です。 SPNEGO TAI が、出荷されているデフォルトの HTTPHeaderFilter クラスを SPN<id>.filterClass として使用するよう構成されていた場合、SPN<id>.filter を使用して、2 回目の要求を標準の WebSphere Application Server セキュリティー・メカニズムに直接送ることができます。ユーザーが経験しているのは、このような標準の認証メカニズムです。 そのような構成の例を以下に示します。必須の SPNEGO TAI プロパティーと HTML ファイルの内容が提供されています。
注: filter プロパティーが、SPNEGO TAI に対して、「noSPNEGO」というストリングを含む HTTP 要求をインターセプトしないように指示していることに注意してください。
以下に、役立つ応答を生成する場合の例を示します。
<html> <head> <title>NTLM Authentication Received </title> <script language="javascript"> var purl=""+document.location; if (purl.indexOf("noSPNEGO")<0) { if(purl.indexOf('?')>=0) purl+="&noSPNEGO"; else purl+="?noSPNEGO"; } </script> </head> <body> <p>An NTLM token was retrieved in response to the SPNEGO challenge. It is likely that you are not logged into a Windows domain.<br> Click on the following link to get the requested website. <script language="javascript"> document.write("<a href='"+purl+"'>"); document.write("Open the same page using the normal authentication mechanism."); document.write("</a><br>"); </script> You will not automatically be redirected. </body> </html> |