SPNEGO のトラブルシューティングのヒント
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用することにより、WebSphere® Application Server の保護されているリソースに対する HTTP 要求を安全にネゴシエーションし、認証することができます。WebSphere Application Server 用の Web 認証サービスとして Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) を使用しているときに、問題が発生する場合があります。
SPNEGO の問題とそれぞれの問題に対する可能な解決策
- Kerberos プリンシパル名を解決できない
- WebSphere Application Server と Active Directory (AD) ドメイン・コントローラーの時刻が 5 分以内で同期化されない
- メカニズム 1.3.6.1.5.5.2 に名前を作成するためのファクトリーを使用できない
- SPNEGO トークンのデコード中および検証中に、Kerberos エラーを受け取る
- シングル・サインオンが行われない
- RC4-HMAC 暗号化を用いたサインオン (SSO) を使用できない
- SPNEGO シングル・サインオン (SSO) を使用して保護されている URL へのアクセス時の問題
- JGSS トレースが使用不可になっている場合でも、いくつかの KRB_DBG_KDC メッセージが SystemOut.log に出力される
- ktpass がユーザー ID を見つけられない
- チケット要求内の無効なオプションが原因で、クレデンシャル委任が動作しない場合がある
- ブラウザーの構成が適切であるにもかかわらず、クレデンシャルに関するチャレンジがユーザーに対して表示される
- Novell クライアントを使用しているユーザーを SPNEGO を使用して認証できない
- いくつかのキャッシング・プロキシー・サーバーを使用して SPNEGO サイトにアクセスすると、SPNEGO 認証の問題が発生することがある
- 仮想私設網 (VPN) ソフトウェアとファイアウォールが SPNEGO 操作を妨げている可能性がある
- SPNEGO で保護されたアプリケーションへのアクセス時に発生する可能性のあるブラウザー問題
- Internet Explorer 6.0 で発生する可能性のあるブラウザー問題
- NTLMTokenReceivedPage プロパティーまたは SpnegoNotSupportedPage プロパティーに対して定義されているエラー・ページが http:// URL からロードされる
- クライアント・ブラウザーでシングル・サインオン (SSO) を試行したが、認証に失敗する
- Microsoft Windows バージョン 7 および Internet Explorer バージョン 8 では、DES 暗号化タイプはデフォルトで使用不可になります。
- 無制限ポリシーの確立および AES256 暗号化の使用
Kerberos プリンシパル名を解決できない
以下のトレース例に示しているように、Kerberos プリンシパル名を解決できない場合があります。
[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken > Negotiation (GSS): Begin handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS u No message text associated with key Error.getting.the.Token,
.GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
major.string:.Invalid.credentials
minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException,
major code: 13, minor code: 0
major string: Invalid credentials
minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS u No message text associated with key SpnegoTAI.exits.due.to.an.exception.
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI E SpnegoTAI exits due to an exception.
この場合、サーバーのホスト・ファイルにサーバーの IP アドレスを追加してください。アプリケーション・サーバーをリサイクルして、新規のホスト・ファイルをロードする必要もあります。
WebSphere Application Server と Active Directory (AD) ドメイン・コントローラーの時刻が 5 分以内で同期化されない
[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken > Negotiation (GSS): Begin handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI > Server response token as follows...
0000: 6082014f 06062b06 01050502 a1820143 `?.O..+.....¡?.C
0010: 3082013f a0030a01 01a10b06 092a8648 0?.? ....¡...*?H
0020: 82f71201 0202a282 01290482 01256082 ?÷....¢?.).?.%`?
0030: 01210609 2a864886 f7120102 0203007e .!..*?H?÷......~
0040: 82011030 82010ca0 03020105 a1030201 ?..0?.. ....¡...
0050: 1ea41118 0f323030 33313131 31303634 .¤...20031111064
0060: 3430395a a5050203 0a3548a6 03020125 409Z¥....5H¦...%
0070: a90b1b09 4a57434d 442e434f 4daa2630 ©.....IBM.NETª&0
0080: 24a00302 0100a11d 301b1b04 48545450 $ ....¡.0...HTTP
0090: 1b136a6f 686e7761 6e67352e 6a77636d ..backendrc4.ibm
00a0: 642e636f 6dab81ab 1b81a86f 72672e69 .net.«?«.?¨org.i
00b0: 6574662e 6a677373 2e475353 45786365 etf.jgss.GSSExce
00c0: 7074696f 6e2c206d 616a6f72 20636f64 ption, major cod
00d0: 653a2031 302c206d 696e6f72 20636f64 e: 10, minor cod
00e0: 653a2033 370a096d 616a6f72 20737472 e: 37..major str
00f0: 696e673a 20446566 65637469 76652074 ing: Defective t
0100: 6f6b656e 0a096d69 6e6f7220 73747269 oken..minor stri
0110: 6e673a20 436c6965 6e742074 696d6520 ng: Client time
0120: 54756573 6461792c 204e6f76 656d6265 Tuesday, Novembe
0130: 72203131 2c203230 30332061 7420313a r 11, 2003 at 1:
0140: 33353a30 3120414d 20746f6f 20736b65 35:01 AM too ske
0150: 776564 wed
この問題は、以下の 2 つの方法のうちのいずれかを使用して解決できます。推奨する方法は、WebSphere のシステム時刻を 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 E com.ibm.issw.spnegoTAI.ServerCredential initialize() 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).
.
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
SPNEGO トークンのデコード中および検証中に、Kerberos エラーを受け取る
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 が複数回 Active Directory に定義された。または、同じように定義された SPN を持つ別のユーザー ID (同じ名前か、ポートが SPN の一部として定義されているところが異なっている場合もあります) が原因で発生することもあります。
- 暗号化タイプが DES の場合、サービス・ユーザー ID に関連付けられているパスワードが、RC4-HMAC 暗号化のためだけに存在することがあります。新規のユーザー ID が作成された場合、SPN が定義されている場合、およびキータブが +DesOnly オプションを使用して生成された場合に、このようなことが発生します。この SPN に対して生成されたサービス・チケットは、キータブで見つかった秘密と一致しない秘密を使用して暗号化されています。
- 古いバージョンの Microsoft ktpass ツールが使用されている。このツールの古いバージョンは間違ったキータブ・ファイルを作成するため、このエラーが発生することがあります。Windows Server 2003 をドメイン・コントローラーとして使用している場合は、Windows Server 2003 SP 2 に含まれるバージョンの ktpass.exe (具体的には、バージョン 5.2.3790.2825) を使用してください。
キータブ・ファイルに問題がある場合は、そのファイルを修正してください。複数の SPN 定義に問題がある場合は、余分な SPN または競合している SPN を除去し、その SPN が AD に登録されていないことを確認してから、その SPN を再度追加しください。詳しくは、Kerberos サービス・プリンシパル名とキータブ・ファイルの作成を参照してください。SPN と衝突する SPN が定義されているエントリーが他にないか、LDAP ブラウザーを使用して Active Directory を検索する必要がある場合があります。
setspn -l userid
以下が戻されます。Cannot find account userid
ユーザー ID とキータブが DES-CBC-MD5 対応のものである場合は、ユーザー ID を作成した後、そのユーザー ID のパスワードを変更して、キータブ・ファイルを作成します。 Windows Server 2003 を使用している場合は、ktpass を最新バージョンにアップグレードしてください。
シングル・サインオンが行われない
Client sent back a non-SPNEGO authentication header, SpnegoTAI exits
- クライアントが正しく構成されていません。
- クライアントがサポートされているブラウザーを使用していません。例えば、Internet Explorer 5.5 SP1 のユーザーは、SPNEGO 以外の認証ヘッダーで応答します。
- ユーザーが AD ドメイン、またはトラステッド・ドメインにログインしていないか、または使用されているクライアントで統合 Windows 認証がサポートされていません。この場合、TAI は正常に動作しています。
- ユーザーが、クライアントが実行されているのと同じマシン (ローカル・ホスト) で定義されているサービスにアクセスしています。Internet Explorer では URL のホスト名が、提供された完全修飾名ではなく、http://localhost<someURL> に解決されます。
- Active Directory に SPN が見つかりません。SPN は、HTTP/server.realm.com というフォーマットをしている必要があります。SPN を追加するためのコマンドは、以下のとおりです。
setspn -a HTTP/server.realm.com userid
SPN が誤って HTTP/server.realm.com@REALM.COM のように @REALM.COM が付加されて定義されている場合は、そのユーザーを削除して定義し直し、次に SPN を再定義してください。
- ホスト名が HOST レコードとしてではなく、DNS 別名として解決されています。 ホスト名を HOST レコードに変更してください。
- ServicePrincipalName を保持している AD 内のアカウントが、ユーザーがログインした AD ドメインからはリモートである AD ドメイン内にあり、これらのドメインが Windows 2003 のドメインではありません。これらのドメインを Windows 2003 にマイグレーションするか、SSO を ServicePrincipalName ユーザー ID と同じドメイン内のユーザーに限定します。
RC4-HMAC 暗号化を用いたサインオン (SSO) を使用できない
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Checksum error; received checksum does not match computed checksum
- Windows 2003 より前のバージョン用の KDC では、RC4-HMAC 暗号化はサポートされません。
これが問題であることを確認するには、例外がスローされた上のトレースを調べてください。着信チケットの内容がトレース内に表示されます。この着信チケットは暗号化されていますが、サービスの SPN 名は読み取り可能です。Windows 2003 より前のバージョン用の KDC を使用しており、システムが RC4-HMAC を使用するように構成されている場合は、期待していた HTTP/hostname.realm@REALM ではなく、userid@REALM のチケットを表すストリングが表示されます。例えば、以下に、Windows 2003 より前のバージョン用の 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 に Windows Server 2003 を使用します。 忘れずに SPN とキータブ・ファイルを再生成してください。
- RC-HMAC 暗号化は、クレデンシャル委任フィーチャーが使用されている場合は動作しません。この問題が発生しているかどうかを判別するには、JGSS トレースおよび Krb5 トレースを使用可能にします。SPN 名が正しい場合は、以下のようなメッセージが表示されることがあります。
[JGSS_DBG_CTX] Successfully decrypted ticket [JGSS_DBG_CTX] Put authz info in cache [JGSS_DBG_CTX] Session key type = rc4-hmac … [JGSS_DBG_CTX] Successfully decrypted authenticator [JGSS_DBG_CTX] Error authenticating request. Reporting to client … Major code = 11, Minor code = 0 org.ietf.jgss.GSSException, major code: 11, minor code: 0 major string: General failure, unspecified at GSSAPI level minor string: Kerberos error converting KRBCred: com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0 message: Checksum error; received checksum does not match computed checksum
これは、SPNEGO トークンに含まれている委任クレデンシャルが、適切な鍵を使用して暗号化されなかったことを示しています。
APAR IY76826 を入手してください。これにより、ibmjgssprovider.jar が、Microsoft で定義された RC4 暗号化委任クレデンシャルを受け入れることができるバージョンで置き換えられます。
- ktpass を使用してキータブ・ファイルを生成する際に使用されたパスワードが、サービス・アカウントに割り当てられているパスワードに一致しない。このパスワードが変更された場合は、このパスワードが同じパスワードにリセットされた場合でも、鍵を再生成して再配布する必要があります。さらに、以下の例のように、ktpass ツールによって、一致しないパスワードを用いてキータブ・ファイルが生成されることがあります。
- ktpass に入力されたパスワードがサービス・アカウントのパスワードに一致している場合は、作成されたキータブ・ファイルは動作しません。
- ktpass に入力されたパスワードがサービス・アカウントのパスワードに一致せず、長さが 6 文字以下の場合、ktpass が停止し、キータブ・ファイルは作成されません。
- ktpass に入力されたパスワードがサービス・アカウントのパスワードに一致せず、長さが 7 文字以上の場合、ktpass は停止しません。その代わりに、ktpass では、無効な鍵を含むキータブ・ファイルが作成されます。この鍵を使用して SPNEGO トークンを暗号化解除すると、上にリストしたチェックサム・エラーが発生します。
サービス・アカウントにはヌル以外のパスワードを使用し、ktpass を呼び出す場合は、そのパスワードを使用してください。
- 一部の Windows2003 Server 環境では、ktpass バージョン 1830 (Support Tools SP1 に含まれる) によってエラーが生成されることがあります。このエラーを回避するには、同ツールの SP2 バージョンを使用してください。
キータブ・ファイルを生成するには、ktpass の Support Tools SP2 バージョンを使用します。
チケット要求内の無効なオプションが原因で、クレデンシャル委任が動作しない場合がある
com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request
Kerberos 構成ファイルが正しく構成されていません。renewable と proxiable がどちらも true に設定されていないことを確認してください。
SPNEGO シングル・サインオン (SSO) を使用して保護されている URL へのアクセス時の問題
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 トークンは、Windows Kerberos トークンのラッパーです。Windows は、Kerberos トークンにユーザーの PAC 情報を含めています。ユーザーが属しているセキュリティー・グループが増えると、それだけ多くの PAC 情報が Kerberos トークンに挿入され、SPNEGO が大きくなっていきます。IBM HTTP Server 2.0 (および Apache 2.0 と IBM HTTP Server 6.0) では、受け入れ可能な HTTP ヘッダーのサイズが 8 K に制限されています。数多くのグループを持ち、ユーザーが多くのグループのメンバーとなっている Windows ドメインでは、ユーザーの SPNEGO トークンのサイズが 8K の制限を超える可能性があります。
可能であれば、ユーザーがメンバーとなっているセキュリティー・グループの数を減らしてください。 IBM HTTP Server 2.0.47 累積フィックス PK01070 により、Microsoft の制限である 12K 以上の HTTP ヘッダー・サイズを使用できます。
修正を適用した後、httpd.conf ファイルで LimitRequestFieldSize パラメーターを指定して、許容ヘッダーのサイズをデフォルトの 8192 から増やしてください。
JGSS トレースが使用不可になっている場合でも、いくつかの KRB_DBG_KDC メッセージが SystemOut.log に出力される
ほとんどの JGSS トレースは、com.ibm.security.jgss.debug プロパティーによって制御されますが、 小さなメッセージ・セットは com.ibm.security.krb5.Krb5Debug プロパティーによって制御されます。 krb5 プロパティーのデフォルト値では、SystemOut.log にいくつかのメッセージを出力するように指定されています。
すべての KRB_DBG_KDC メッセージを SystemOut.log から除去するには、JVM プロパティーを -Dcom.ibm.security.krb5.Krb5Debug=none に設定します。
ktpass がユーザー ID を見つけられない
DsCrackNames returned 0x2 in the name entry for server3
Failed getting target domain for specified user.
Active Directory フォレストでは、ktpass.exe によって使用されるユーザー ID 検索は、使用されるデフォルトのドメイン名を持っていません。これは、ドメイン・コントローラーがフォレスト内にない場合には発生しません。
この問題を解決するには、オプション -mapUser userid を指定する代わりに -mapUser userid@domain を使用してください。例えば、–mapUser server3@WIBM.NET を指定します。
どのユーザー ID に対してもクレデンシャル委任が動作しない
> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() unable to get Delegate Credential
< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: No delegated credentials were found for user: nauser@NA.IBM.NET
この場合、SPN が関連付けられているドメイン・アカウントに対して、プロパティー「アカウントは委任に対して信頼されている」が定義されていません。
この問題に対処するには、ドメイン・アカウントでプロパティー「アカウントは委任に対して信頼されている」が定義されていることを確認します。
ブラウザーの構成が適切であるにもかかわらず、クレデンシャルに関するチャレンジがユーザーに対して表示される
< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Exit
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Handshake finished, sending 200 :SC_OK
< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: An unexpected exception occurred when trying to create a LoginContext. The LoginModule alias is system.WEB_INBOUND
and the exception is...
- WebSphere が使用しているレジストリーが、Active Directory ドメイン LDAP でもグローバル・カタログでもなく、何か他の仮想レジストリー (例えば、ファイル・ベースのカスタム・ユーザー・レジストリー) である。
- カスタムの IClientToServerUseridMapper 実装がユーザー名を変更したが、そのユーザー名のマップ先の名前がレジストリーに存在していない名前であった。
- WebSphere LDAP ユーザー・フィルター・プロパティーによるマップ先の属性が間違っている。
この問題を解決するには、TAI によって WebSphere Application Server に対して表明されるユーザーが、WebSphere レジストリー内に構成されていることを確認します。
Novell クライアントを使用しているユーザーを SPNEGO を使用して認証できない
Novell クライアントを使用しているユーザーを SPNEGO を使用して認証できない場合、「NTLM トークンを受信しました (An NTLM token is received)」というメッセージを受け取ることがあります。
このユーザーは Novell クライアントにはログインしたと思われますが、Windows Kerberos ログインを実行しませんでした (これを確認するには、Kerbtray ユーティリティーを使用します)。ユーザーが Windows ドメインにログオン済みで、Kerberos チケットを持っている場合、このユーザーは SPNEGO 認証を利用できません。
この問題を解決するには、Novell クライアントを除去し、デフォルトの Windows ドメイン・ログインを使用してください。
いくつかのキャッシング・プロキシー・サーバーを使用して SPNEGO サイトにアクセスすると、SPNEGO 認証の問題が発生することがある
いくつかのキャッシング・プロキシー・サーバーを使用して SPNEGO サイトにアクセスする場合は、SPNEGO を使用して認証できないことがあります。「SPNEGO 認証はこのクライアントではサポートされていません (SPNEGO authentication not supported on this client)」というメッセージが表示されることがあります。
キャッシング・プロキシーが、HTTP 401 Authenticate Negotiate 応答で返されるホスト名を変更している可能性があります。
この問題が発生する場合は、プロキシー・ベンダーに連絡し、可能な解決策を問い合わせてください。
仮想私設網 (VPN) ソフトウェアとファイアウォールが SPNEGO 操作を妨げている可能性がある
VPN ソフトウェアとファイアウォールが、SPNEGO 操作を妨げているという問題に発生することがあります。
これらの問題を解決するには、VPN またはファイアウォール (あるいはその両方) のベンダーに連絡し、必要と思われる構成変更を行ってください。
SPNEGO で保護されたアプリケーションへのアクセス時に発生する可能性のあるブラウザー問題
あるパスワード (例えば passwordA) を使用してドメイン・マシンにログオンし、次に元のパスワードを変更して 2 番目のドメイン・マシンにログオンした場合 (例えば、2 番目のドメイン・マシンのパスワードを passwordB に変更)、ブラウザー問題が生じることがあります。
元のドメイン・マシンに戻ると、Negotiate チャレンジに対する SPNEGO/Kerberos 応答または NTLM 応答を取得できないことがあります。2 回試行すると、ブラウザーは HTTP 404 エラー・メッセージを表示します。
この問題を解決するには、元のドメイン・マシンからログオフし、新しいパスワード (passwordB) でログオンし直します。
Internet Explorer 6.0 で発生する可能性のあるブラウザー問題
WebSphere Application Server が SPNEGO を用いて構成されており、要求に対するフォールバックが使用可能になっている場合は、Internet Explorer 6.0 がフォーム・ログイン・ページへのログインに失敗することがあります。
- アプリケーション認証メカニズムへのフォールバックを許可します」オプションが選択されていれば、これを選択解除します。 パネルで、「
- Internet Explorer バージョン 7.0 にアップグレードします。
- 異なる認証ページを使用するよう Internet Explorer バージョン 6.0 を構成します。問題は、フォーム・ログイン認証を設定する場合と基本認証の違いにあります。
NTLMTokenReceivedPage プロパティーまたは SpnegoNotSupportedPage プロパティーに対して定義されているエラー・ページが http:// URL からロードされる
Could not load the SPNEGO not supported content, going with the default content.
Exception received: java.net.ProtocolException: Server redirected too many times (20)
この問題は、ロードされたファイルが自動リダイレクトを実行する場合に発生します。 Web サーバーからファイルをロードし、かつ自動リダイレクトも使用することはできません。
この問題を解決するには、コンテンツを http:// U からではなく、file:/// URL からロードします。
クライアント・ブラウザーでシングル・サインオン (SSO) を試行したが、認証に失敗する
Microsoft Internet Security Acceleration Server で SPNEGO トークンを使用する場合に、クライアント・ブラウザーのシングル・サインオン (SSO) 試行で WebSphere Application Server での認証に失敗する場合にエラーが発生することがあります。
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO
ENTRY Negotiate
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO
Client sent back a non-SPNEGO authentication header
クライアント・ブラウザーと WebSphere Application Server の間に Microsoft Internet Security Acceleration Server (ISA) が存在する場合に、ISA が クライアント・ブラウザー要求の SPNEGO 認証ヘッダーを インターセプトすることがあります。ISA は SPNEGO オブジェクト ID (OID) を Kerberos OID に 変換します。SPNEGO OID が変換されて 存在しなくなったため、WebSphere Application Server での認証は失敗します。
この問題の修正方法について詳しくは、Microsoft Corporation のサポート・サイトにある「ユーザーは、Web サイトが SPNEGO 認証パッケージのみを受け入れる場合、ISA Server 2006 で公開されている Web サイトにアクセスできません。」というトピックを参照してください。
Microsoft Windows バージョン 7 および Internet Explorer バージョン 8 では、DES 暗号化タイプはデフォルトで使用不可になります。
Client sent back a non-SPNEGO authentication header....
暗号化タイプは RC4-HMAC または AES に変更することをお勧めします。それでも、DES 暗号化タイプを使用し続けたい場合は、 Windows 7 の資料を参照して、DES 暗号化タイプを使用可能にする方法を確認してください。
以下に、暗号化タイプを DES から RC4 に変更する方法の例を示します。
- SPN にマップするのに使用する Microsoft Active
Directory アカウントで「このアカウントに DES 暗号化タイプを使用する」ボックスがチェックされていないことを
確認してください。Microsoft Active Directory
マシンで、次のようにします。
- とクリックします。
- SPN にマップするのに使用する Microsoft Active Directory アカウントをクリックします。
- このアカウントを選択して、「このアカウントに DES 暗号化タイプを使用する」 ボックスがチェックされていないことを確認します。
- SPN にマップするのに使用する Microsoft Active Directory アカウントのパスワードをリセットします。パスワードは同じパスワードにリセットできます。
- RC4 暗号化タイプで keytab を再生成します。
- 新しい keytab ファイルを WebSphere Application Server サーバーにコピーします。
- Kerberos 構成 (krb5.ini/krb5.conf) ファイルを更新して、
RC4 を default_tkt_enctypes 属性および default_tgs_enctypes
属性の最初にリストします。以下に例を示します。.
default_tkt_enctypes = rc4-hmac des-cbc-md5 default_tgs_enctypes = rc4-hmac des-cbc-md5
- WebSphere Application Server サーバーをすべて停止し、再始動します。
無制限ポリシーの確立および AES256 暗号化の使用
- アプリケーション・サーバーを停止します。
- 新規ポリシー・ファイルをダウンロードし、インストールします。重要: お客様の国で、暗号化ソフトウェアに関して、その輸入、所有、使用、他国への再輸出に関する制限が設けられている場合があります。 無制限ポリシー・ファイルをダウンロードあるいは使用する前に、暗号化ソフトウェアの輸入、所有、使用、および再輸出に関する自国の法律、規定、および政策を確認して、コンプライアンスを保証してください。
- 該当する SDK レベルをクリックします。
- ページをスクロールダウンして、「IBM SDK policy files」をクリックします。 SDK Web サイト用の無制限 JCE ポリシー・ファイルが表示されます。
- 「Sign in」をクリックして、IBM.com ID とパスワードを入力します。
- 「unrestricted JCE policy files for SDK」を選択し、「継続」をクリックします。
- 使用許諾書を読み、「I Agree」をクリックして先へ進みます。
- ZIP ファイルに圧縮された、制限されていない管轄権ポリシー・ファイルを解凍します。ZIP ファイルには、 US_export_policy.jar ファイルと local_policy.jar ファイルが含まれています。
- WebSphere Application Server インストールで、$JAVA_HOME/lib/security ディレクトリーに移動し、既存の US_export_policy.jar ファイルおよび local_policy.jar ファイルをバックアップします。
- US_export_policy.jar ファイル local_policy.jar フ ァイルを IBM.com Web サイトからダウンロードした 2 つのファイルと置き換えます。
注: これらのファイルを置き換える前にバックアップを取ってください。 使用されるパスは WAS_Install/java/jre/lib/security などです。 - アプリケーション・サーバーを始動します。