管理コンソールを使用した認証メカニズムとしての Kerberos の構成

管理コンソールを使用して、Kerberos をアプリケーション・サーバー用の認証メカニズムとして構成することができます。必要な情報を入力し、構成に適用すると、Kerberos のサービス・プリンシパル名は <サービス名>/<完全修飾ホスト名>@KerberosRealm として形成され、着信する Kerberos トークン要求の検査に使用されます。

始める前に

このバージョンの WebSphere® Application Server における Kerberos 認証メカニズムを理解するために、 セキュリティーのための Kerberos (KRB5) 認証メカニズムのサポートをお読みください。 管理コンソールを使用して Kerberos を認証メカニズムとして構成する前に、 以下のステップを完了する必要があります。

  • Kerberos 構成ファイル krb5.ini または krb5.conf がない場合は、createkrbConfigFile コマンド・タスクを使用して、Kerberos 構成ファイルを作成します。 詳しくは、『Kerberos 構成ファイルの作成』を参照してください。
  • WebSphere アプリケーション・サーバーが実行される それぞれのマシンごとに、Kerberos サービス・プリンシパル名 (SPN) <service name>/<完全修飾ホスト名 >@KerberosRealm が含まれる Kerberos キータブ・ファイル krb5.keytab がなければなりません。サービス名は任意の名前でかまいません。デフォルト値は WAS です。

    例えば、2 つのアプリケーション・サーバー・マシン host1.austin.ibm.com および host2.austin.ibm.com がある場合、Kerberos キータブ・ファイルには <service_name>/host1.austin.ibm.com および <service_name>/host2.austin.ibm.com SPN およびそれらの Kerberos キーが含まれている必要があります。

    Kerberos は、セッションごとに 1 つのみキータブ・ファイルをロードし、使用します。例えば、Kerberos を構成し、新しいキータブ・ファイルを以前のキータブ・ファイルと同じ名前および同じ場所で使用する場合は、まずサーバーを再始動して新しいキータブ・ファイルが使用されるようにする必要があります。

    初めて Kerberos を構成するときに、不注意で誤ったキータブ・ファイルを 使用した場合は、Kerberos の構成を解除し、サーバーを再始動してから、 新しいキータブ・ファイルで Kerberos を再構成する必要があります。ただし、SP3 の Java™ SE Development Kit (JDK) をインストールしている場合は該当しません。

最初に、グローバルとアプリケーションのセキュリティーを有効にする必要があります。

Kerberos がグローバル・セキュリティーで構成されているものの、 別の Kerberos レルムを使用するドメイン上では Simple and Protected GSS-API Negotiation (SPNEGO) を構成する必要がある場合は、まず Java ktab -m コマンドを使用して、既存のキータブ・ファイルを 1 つのキータブ・ファイルにマージします。 そのマージしたキータブ・ファイルを使用して、Kerberos と SPNEGO を グローバル・セキュリティーおよびドメイン・セキュリティーで構成します。

手順

  1. 管理コンソールで、「セキュリティー」>「グローバル・セキュリティー」とクリックします。
  2. 「認証」で、「Kerberos 構成」をクリックします。
  3. Kerberos サービス名を入力します。 規約により、Kerberos サービス・プリンシパルは 3 つの 部分 (プライマリー、インスタンス、および Kerberos レルム名) に分かれています。Kerberos サービス・プリンシパル名のフォーマットは、<service_Name>/<fully_qualified hostName>@KERBEROS_REALM です。 サービス名は、Kerberos サービス・プリンシパル名の最初の部分です。例えば、WAS/test.austin.ibm.com@AUSTIN.IBM.COM では、サービス名は WAS です。この例では、キー・タブ・ファイルには、Kerberos サービス・プリンシパル名である WAS/test.austin.ibm.com@AUSTIN.IBM.COM、およびその鍵が必要です。

  4. Kerberos 構成ファイル名を入力するか、または「参照」をクリックして場所を指定します。 Kerberos クライアント構成ファイル krb5.conf または krb5.ini には、対象となるレルム用の鍵配布センター (KDC) のロケーションを含む、Kerberos の構成情報が入っています。 krb5.conf ファイルは、krb5.ini ファイルを使用する Windows オペレーティング・システムを除き、すべてのプラットフォームのデフォルト・ファイル名です。
    注: Kerberos 構成ファイル名および Kerberos キータブ・ファイル名のパスは、絶対パスにする必要はありません。 代わりに、WebSphere 変数をパスに使用することができます。 混合プラットフォーム環境の場合は、Kerberos 構成ファイルに ${CONF_OR_INI} 変数を使用できます。セキュリティー構成によって、この変数が、Windowsプラットフォームの場合は ini に、Windows 以外のプラットフォームの場合は conf に展開されます。例えば、以下のようになります。
    ${WAS_INSTALL_ROOT}\etc\krb5\krb5.${CFG_OR_INI}
  5. オプション: Kerberos キータブ・ファイル名を入力するか、または「参照」をクリックして場所を指定します。 Kerberos キータブ・ファイルには 1 つ以上の Kerberos サービス・プリンシパル名およびキーがあります。デフォルトのキータブ・ファイルは krb5.keytab です。ホストでは、Kerberos キータブ・ファイルをローカル・ディスクに保管し、 許可ユーザーのみが読み取れるようにして、このファイルを保護することが重要です。詳しくは、Kerberos サービス・プリンシパル名とキータブ・ファイルの作成を参照してください。このパラメーターを指定しない場合は、Kerberos 構成ファイルにあるデフォルトの keytab が使用されます。
    注: Kerberos 構成ファイル名および Kerberos キータブ・ファイル名のパスは、絶対パスにする必要はありません。 代わりに、WebSphere 変数をパスに使用することができます。
    ${WAS_INSTALL_ROOT}\etc\krb5\krb5.keytab
  6. Kerberos レルム名」フィールドで、Kerberos レルムの名前を入力します。 ほとんどの場合、レルムはドメイン・ネームを大文字にしたものです。このパラメーターを指定しない場合は、Kerberos 構成ファイルにあるデフォルトの Kerberos レルム名が使用されます。

    例えば、ドメイン名が test.austin.ibm.com のマシンの Kerberos レルム名は、AUSTIN.IBM.COM です。

    注: Microsoft の KDC の Kerberos レルム名は、 大文字のドメイン・コントローラー名です。
  7. オプション: プリンシパル名から Kerberos レルムをトリム (Trim Kerberos realm from principal name)」 がデフォルトで選択されます。Kerberos プリンシパル名のサフィックスを保存するには、このオプションをクリアします。 このオプションは、Kerberos レルム名に先行する「@」で始まるプリンシパル・ユーザー名のサフィックスを、Kerberos ログイン・モジュールが除去するかどうかを指定します。 この属性が true に設定されている場合、プリンシパル・ユーザー名のサフィックスは除去されます。 この属性が false に設定されている場合、 プリンシパル名のサフィックスは保持されます。使用されるデフォルト値は true です。

  8. オプション: Kerberos クレデンシャルの委任を使用可能にする (Enable delegation of Kerberos credentials)」は、デフォルトで選択されています。 このオプションは、Kerberos 委任クレデンシャルをクライアント要求から抜き出すかどうかを指定します。クライアントが Kerberos 委任クレデンシャルを要求の一部として送信している場合、クライアントのプリンシパル名とクライアントの委任 Kerberos チケットを使用して Kerberos 認証トークン (KRBAuthnToken) が作成されます。KRBAuthnToken は、クライアント・サブジェクトに保管されます。その KRBAuthnToken が、セキュリティー属性の伝搬の一部としてダウンストリーム・サーバーに伝搬されます。カスタマー・アプリケーションでバックエンド・リソースまたはダウンストリーム・サーバーでの認証に GSSCredential が必要な場合、com.ibm.wsspi.wssecurity.platform.token.KRBAuthnToken.getGSSCredential() メソッドを使用して KRBAuthnToken から GSSCredential を取得して、サブジェクト内に配置する必要があります。

    このオプションにチェック・マークを付けない場合、KRBAuthnToken には、Kerberos プリンシパル名のみが入ります。

    注: このパラメーターが true で、クライアントの GSS 委任クレデンシャルをランタイム環境が抽出できない場合、警告メッセージが表示されます。
  9. OK」をクリックします。

タスクの結果

適用」または「OK」を選択すると、 Kerberos 認証は自動的にテストされます。Kerberos 構成が完了しなかった場合は、認証が失敗したことを示す メッセージが表示されます。

これで、WebSphere Application Server 用の認証メカニズムとして、Kerberos が構成および保存されました。

次のタスク

SPNEGO を使用可能にするには、関連構成から 「SPNEGO Web 認証の使用可能化 (SPNEGO web authentication enablement)」をクリックします。

SPNEGO Web 認証と Kerberos 認証は、同じ Kerberos クライアント構成とキータブ・ファイルを使用します。

管理コンソールへの認証を試みる場合は、そのアプリケーション・サーバーに関連付けられている KDC 内に存在する管理ユーザー ID を使用します。管理コンソールとは関連付けられていない異なる KDC 内にある管理ユーザー IDを使用すると、ログイン・プロセスは失敗し、次のエラー・メッセージがログ・ファイルに追加されます。
SECJ9200E: No Kerberos credential found in subject credential set.
例えば、クライアントが アプリケーション・サーバーとは別の KDC に関連付けられている可能性があります。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_kerb_auth_mech
ファイル名:tsec_kerb_auth_mech.html