ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド
11g リリース2 (11.1.2.1)
B71694-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

13 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、Oracleのベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章の構成は、次のとおりです。

13.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

手順

IDMHOST1およびIDMHOST2上で、第2章「導入と計画」で説明されているエンタープライズ・デプロイメント・トポロジの各種コンポーネントに対して、この章に記載されている手順を実行する必要があります。

コンポーネント固有の章に記載されている情報を使用して、VPとIPのペアごとにこの章の手順を繰返し実行する必要があります。

推奨事項

エンタープライズ・デプロイメント・トポロジでのノード・マネージャの構成についての主要な推奨事項は、次の2つです。

  1. ノード・マネージャのログ・ファイルをデフォルトの場所(ノード・マネージャが配置されているミドルウェア・ホーム)とは異なる場所に置くことをお薦めします。詳細は、第13.2項「ノード・マネージャのログの場所の変更」を参照してください。

  2. また、ノード・マネージャとドメイン内のサーバー間の通信についてホスト名検証を使用することもお薦めします。これには、ドメインで使用される各種アドレスの証明書を使用する必要があります。この章では、ホスト名検証用にホストで証明書を構成する手順について説明します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。


注意:

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字および数字が不規則に連なるパスワードを使用します。


13.2 ノード・マネージャのログの場所の変更

IAM_MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.propertiesにあるノード・マネージャのプロパティ・ファイルを編集します。次の行を使用して、ログ・ファイルの新しい場所を追加します。

LogFile=ORACLE_BASE/config/nodemanager.log

Oracleのベスト・プラクティスは、管理ディレクトリの内部で、MW_HOMEディレクトリの外部である場所を使用することです。

変更を有効にするために、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを再起動します。

13.3 ノード・マネージャのホスト名検証証明書の有効化

この項では、ノード・マネージャと管理サーバーとの通信で使用するホスト名検証証明書を設定する方法について説明します。これには次の手順が含まれます。

13.3.1 utils.CertGenユーティリティを使用した自己署名証明書の作成

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアとトラスト・キーストアを理想的に保持するディレクトリは、フェイルオーバーからアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。

  1. 証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。

  2. アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。かわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comとVIP.mycompany.comの証明書を構成します。すなわち、HOSTで物理ホスト名(HOST)と仮想ホスト名(VIP)の両方を使用することを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

  1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。

    cd WL_HOME/server/bin
    . ./setWLSEnv.sh
    

    CLASSPATH環境変数が設定されていることを確認します。

    echo $CLASSPATH
    
  2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリの下にcertsというディレクトリを作成します。証明書はWebLogicドメイン間で共有できることに注意してください。

    cd ASERVER_HOME
    mkdir certs
    

    注意:

    サーバーが(手動またはサーバーの移行により)フェイルオーバーした際にフェイルオーバー・ノードから適切な証明書にアクセスできるように、キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセス可能な共有記憶域に存在している必要があります。各種目的(HTTPの起動用のSSL設定など)で使用する証明書には、中央ストアまたは共有ストアを使用することをお薦めします。


  3. ディレクトリを今しがた作成したディレクトリに変更します。

    cd certs
    
  4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST.mycompany.comおよびVIP.mycompany.comの両方に対する証明書を作成します。

    構文(すべて1行に記述):

    java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name 
    [export | domestic] [Host_Name]

    次に例を示します。

    java utils.CertGen Key_Passphrase IDMHOST1.mycompany.com_cert IDMHOST1.mycompany.com_key domestic IDMHOST1.mycompany.com
    
    java utils.CertGen Key_Passphrase IDMHOST2.mycompany.com_cert IDMHOST2.mycompany.com_key domestic IDMHOST2.mycompany.com
    
    java utils.CertGen Key_Passphrase ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com
    

13.3.2 utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

次の手順に従って、IDMHOST1にアイデンティティ・キーストアを作成します。

  1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ASERVER_HOME/certs)とします。


    注意:

    アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。


  2. IDMHOST1.mycompany.comIDMHOST2.mycompany.comおよびADMINVHN.mycompany.comの証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

    構文(すべて1行に記述):

    java utils.ImportPrivateKey Keystore_File Keystore_Password 
    Certificate_Alias_to_Use Private_Key_Passphrase
    Certificate_File
    Private_Key_File

    [Keystore_Type]

    次に例を示します。

    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityIDMHOST1 Key_Passphrase ASERVER_HOME/certs/IDMHOST1.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST1.mycompany.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityIDMHOST2 Key_Passphrase ASERVER_HOME/certs/IDMHOST2.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST2.mycompany.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityADMINVHN Key_Passphrase ASERVER_HOME/certs/ADMINVHN.mycompany.com_cert.pem ASERVER_HOME/certs/ADMINVHN.mycompany.com_key.pem
    

13.3.3 keytoolユーティリティを使用したトラスト・キーストアの作成

次の手順に従って、IDMHOST1やIDMHOST2などの各ホストにトラスト・キーストアを作成します。

  1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書が存在するディレクトリにコピーします。例:

    cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks
    
  2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。常にデフォルトのパスワードを変更することをお薦めします。それには、keytoolユーティリティを使用します。次に構文を示します。

    keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
    

    例:

    keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreIDMHOST1.jks -storepass changeit
    
  3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。次に構文を示します。

    keytool -import -v -noprompt -trustcacerts -alias Alias_Name 
    -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

    例:

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreIDMHOST1.jks -storepass Key_Passphrase
    

13.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

例:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ASERVER_HOME/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=Key_Passphrase
CustomIdentityAlias=appIdentityIDMHOST1
CustomIdentityPrivateKeyPassPhrase=Key_Passphrase

第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

13.3.5 共通または共有記憶域インストールの使用

共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートする方法で、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。

各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST1

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST2

注意:

各ホスト固有に割り当てられているカスタムのアイデンティティ別名を必ず指定します。たとえば、...HOST1にはappIdentity1を指定し、...HOST2にはappIdentity2を指定します。


13.3.6 カスタム・キーストアを使用するための管理対象WebLogic Serverの構成

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

  1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

  2. 「ロックして編集」をクリックします。

  3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

  4. サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. IDキーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。

  6. 構成」をクリックし、「キーストア」をクリックします。

  7. 「キーストア」フィールドで、秘密鍵とデジタル証明書の組合せおよび信頼できるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。

  8. 「ID」セクションで、IDキーストアの次の属性を定義します。

    • カスタムIDキーストア: IDキーストアへの完全修飾パス。

      ASERVER_HOME/certs/appIdentityKeyStore.jks
      
    • カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

    • カスタムIDキーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  9. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

    • カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

      ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks
      
    • カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

    • カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

  10. 保存」をクリックします。

  11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

  12. 構成」をクリックし、「SSL」をクリックします。

  13. 「ロックして編集」をクリックします。

  14. 「秘密鍵の別名」フィールドに、管理対象サーバーでリスニングするホスト名に使用した別名を入力します。例:

    • WLS_OAM1の場合は、appIdentityIDMHOST1を使用します。

    • WLS_OAM2の場合は、appIdentityIDMHOST2を使用します。

    • ADMINSERVERの場合は、appIdentityADMINVHNを使用します。

    秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

  15. 保存」をクリックします。

  16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

  17. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。

13.3.7 管理対象サーバーのホスト名検証設定の変更

前述の手順を実行した後、影響を受ける管理対象サーバーのホスト名検証をBEA Hostname Verifierに設定します。このためには、次の手順を実行します。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「チェンジ・センター」で「ロックして編集」を選択します。

  3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

  4. サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  5. 表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。

  6. 「SSL」タブを開きます。

  7. このページの「詳細」セクションを展開します。

  8. ホスト名検証をBEA Hostname Verifierに設定します。

  9. 保存」をクリックします。

  10. 変更のアクティブ化」をクリックします。

13.4 ノード・マネージャの起動

次のコマンドを実行してノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

注意:

  • ノード・マネージャが未構成で、まだ一度も起動していない場合は、第8.5.4項「ノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、Identity Managementのコンポーネントで必要な起動スクリプトを使用できるようになります。

  • ノード・マネージャの出力にある適切なストアと別名を、そのノード・マネージャで使用していることを確認します。ノード・マネージャの起動時に次の内容が出力されます。

    <Loading identity key store:
      FileName=ASERVER_HOME/certs/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>
    

    テスト構成の変更を該当のサーバーに適用して、ノード・マネージャからSSLエラーが報告されることなく、それが正常に完了していれば、ホスト名検証は機能しています。