次に、ログイン実行時に発生する可能性のある問題、およびその解決方法に関する提案を示します。
java.security.krb5.kdx
およびjava.security.krb5.realm
を介して指定されます。前のリリースでは、Kerberos構成値への変更は、アプリケーションが再起動されたときにのみ有効になりました。Krb5LoginModule
のエントリに、新しいブール型オプションrefreshKrb5Config
を指定できます。このオプションがtrue
に設定されている場合は、Krb5LoginModule
のloginメソッドが呼び出される前に、構成値がリフレッシュされます。refreshKrb5Config
をtrue.
に設定する必要があります。この値を設定しないと、予期しない結果が発生することがあります。原因: JAASログイン構成ファイルの処理で問題が発生しました。原因は、ファイル内の構文エラーと考えられます。
解決法: 構成ファイルに誤りがないか、注意深く確認します。ログイン構成ファイルに必要な構文の詳細は、「JAASログイン構成ファイル」を参照してください。
原因1: 入力されたパスワードが無効です。
解決法1: パスワードを確認します。
原因2: 鍵の取得にキー・タブを使用している場合(JAASログイン構成ファイルのKrb5LoginModuleエントリで、useKeyTab
オプションをtrue
に設定するなど)、キー・タブの更新後に鍵が変更された可能性があります。
解決法2: Kerberosドキュメントを参照して新規keytabを生成し、そのキー・タブを使用します。
原因3: クロック・スキュー - KDC上の時間とクライアント上の時間が大きく異なる場合(通常は5分)、エラーが返されることがあります。
解決法3: クロックを同期させます(またはシステム管理者に同期を依頼)。
原因4: Kerberosレルム名がすべて大文字になっていません。
解決法4: Kerberosレルム名をすべて大文字にします。注: すべて大文字のレルム名を使用するよう推奨されています。詳細については、このチュートリアルの「レルム名とホスト名の命名規則」セクションを参照してください。
原因: KerberosはKDCのクロックとクライアントのクロックがほぼ同期していることを要求します。デフォルトは5分以内です。同期していない場合、エラーが発生します。
解決法: クロックを同期させます(またはシステム管理者に同期を依頼)。
原因: Kerberos構成ファイルkrb5.conf
内で、ユーザー名の一部を構成するデフォルト・レルムが指定されていません(Kerberos構成ファイルを使用する場合)。または、デフォルト・レルムが、java.security.krb5.realm
システム・プロパティで指定されていません。
解決法: Kerberos構成ファイル内(使用する場合)にデフォルト・レルムを指定するエントリが含まれているかどうかを確認します。または、java.security.krb5.realm
システム・プロパティ値にデフォルト・レルムを直接指定し、Kerberosによる認証時にこれをユーザー名に含めます。
解決法: Kerberos KDCが起動済みで、稼動中であることを確認します。
原因: 有効なKerberos資格の取得が行われていない場合、このエラーが発生します。特に、基盤となるメカニズムで資格の取得を行う予定であったのに、javax.security.auth.useSubjectCredsOnly
システム・プロパティ値をfalse
に設定すること(たとえば、実行コマンドに-Djavax.security.auth.useSubjectCredsOnly=false
を含めて)を忘れてしまった場合、このエラーが発生します。
解決法: JAASを使って認証を実行するアプリケーションやラッパー・プログラム(このシリーズのチュートリアルで使用したLoginユーティリティなど)ではなく、基盤となるメカニズムで資格の取得を行う場合、javax.security.auth.useSubjectCredsOnly
システム・プロパティ値を確実にfalse
に設定します。
原因: チュートリアルのサンプル実行コマンドは、java.security.krb5.realm
およびjava.security.krb5.kdc
システム・プロパティの値を設定することにより、デフォルトのKerberosレルムおよびKDCを指定します。必要に応じて、かわりに、Kerberos構成ファイルkrb5.conf
を使用できます。そのファイルには、デフォルトのレルムおよびKDCに関する情報が含まれます。krb5.conf
ファイルを使用するには、システム・プロパティjava.security.krb5.conf
を使用して(realm
およびkdc
プロパティの代わりに)ファイルの位置を指定するか、これらのプロパティのがいずれも設定しない場合、デフォルト位置でkrb5.conf
ファイルの検出が試みられます。ファイルが見つからない場合、「Could not load configuration file <krb5.conf> (No such file or directory)」というエラーが表示されます。
解決法: Kerberos構成ファイルkrb5.conf
が、利用可能かつ読取り可能であることを確認します。krb5.conf
ファイルの位置指定方法、および位置を明示的に指定しない場合のデフォルト検索位置については、「Kerberos要件」を参照してください。
原因1: 使用するKDCが、要求された暗号化タイプをサポートしません。
解決法1: SunのKerberos実装では、暗号化タイプとして、des-cbc-md5
、des-cbc-crc
、およびdes3-cbc-sha1
をサポートしています。
アプリケーションでは、Kerberos構成ファイルkrb5.conf
で次のタグを指定することにより、適当な暗号化タイプを選択できます。
[libdefaults] default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1指定しない場合のデフォルト値は次のとおりです。
des-cbc-md5 des-cbc-crc des3-cbc-sha1
原因2: この例外は、いくつかのWindowsプラットフォームでネイティブ・チケット・キャッシュを使用するとスローされます。Microsoftは新機能を追加しており、その機能ではTicket Granting Tickets (TGT)のセッション鍵がエクスポートされなくなっています。そのため、Windowsで取得したネイティブTGTは、「空の」セッション鍵とnullのETypeを持つことになります。このエラーが発生するプラットフォームは、Windows Server 2003、Windows 2000 Server Service Pack 4 (SP4)、Windows XP SP2などです。
解決法2: Windowsのレジストリをアップデートして、この新機能を無効にする必要があります。レジストリ・キーallowtgtsessionkey
を追加し、正しく設定して、KerberosのTicket Granting Ticketでセッション鍵が送信されるようにしてください。
Windows Server 2003とWindows 2000 SP4の場合に必要とされるレジストリ設定を次に示します。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value Name: allowtgtsessionkey Value Type: REG_DWORD Value: 0x01 ( default is 0 )デフォルトでは値が0に設定されています。「0x01」に設定することにより、セッション鍵をTGTに含めることができます。
Windows XP SP2のレジストリ設定の位置を次に示します。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\ Value Name: allowtgtsessionkey Value Type: REG_DWORD Value: 0x01
原因: KDCにより、クライアントが認識不可能な応答が返されました。
解決法: krb5.conf
ファイルの構成パラメータすべてが適正に設定されていることを確認し、KDCベンダー提供のガイドを参照してください。
sun.security.krb5.debug
を「true」に設定することで、デバッグ・モードを有効にできます。この設定により、プログラムがKerberos V5プロトコルを実行する様子を確認できます。直面している問題についての情報をフィードバックする場合は、完全なデバッグ出力を含めていただけると非常に助かります。