Network Deployment セルにスタンドアロンの Base アプリケーション・サーバーを追加して、
その構成を 1 か所に集中させるように決定する場合があります。
ご使用の Base アプリケーション・サーバーが、
現在セキュリティーを使用して構成されている場合は、いくつかの考慮事項があります。
ノードをセルに追加する場合の主要な問題は、Base アプリケーション・サーバーとデプロイメント・マネージャーのユーザー・レジストリーが同じものであるかどうかということです。
セルにノードを追加する場合、新規統合ノードは自動的に既存の Network Deployment セルのユーザー・レジストリー (ローカル OS、LDAP、または Custom)、認証メカニズム (LTPA)、および許可設定 (WebSphere バインディングまたは System Authorization Facility (SAF) EJBROLE プロファイル) を継承します。
分散セキュリティーでは、セル内のすべてのサーバーが同じユーザー・レジストリーと認証メカニズムを使用しなければなりません。
ユーザー・レジストリーの変更からリカバリーするには、アプリケーションを変更して、
ユーザーおよびグループの役割へのマッピングが新しいユーザー・レジストリーに関して正しくなるようにする必要があります。
役割へのユーザーおよびグループの割り当て
の項目を参照してください。
もう 1 つの重要な考慮事項は、Secure
Sockets Layer (SSL) 公開鍵インフラストラクチャーです。
デプロイメント・マネージャーを使用して addNode を実行する前に、
addNode コマンドが SSL クライアントとしてデプロイメント・マネージャーと通信できることを確認してください。
この通信のためには、sas.client.props ファイルで構成される addNode トラストストアに、鍵ストアに入っていて、
管理コンソールで指定されるデプロイメント・マネージャー個人証明書の署名者証明書が含まれている必要があります。
addNode コマンドをセキュリティーを介して実行する際に考慮する必要がある問題を以下に示します。
- addNode コマンドなどのシステム管理コマンドを実行する場合は、
その操作を実行するための管理クレデンシャルを明示的に指定する必要があります。
addNode コマンドは、ユーザー ID とパスワードを指定するのに、それぞれ -username パラメーターと -password パラメーターを受け入れます。
指定するユーザー ID とパスワードは、管理ユーザーのものである必要があります。
管理ユーザーとは、例えば、管理者の特権を持っているか、
ユーザー・レジストリーで構成されている管理ユーザー ID を持っているコンソール・ユーザーのメンバーです。
以下に、addNode コマンドの例を示します。
addNode CELL_HOST 8879
-includeapps -username user -password pass.
-includeapps パラメーターはオプションですが、このオプションはサーバー・アプリケーションをデプロイメント・マネージャーに組み込もうとします。
WebSphere Application Server が使用するユーザー・レジストリーと、
デプロイメント・マネージャーが使用するユーザー・レジストリーが同一でなければ、
addNode コマンドは失敗します。
この問題を解決するには、ユーザー・レジストリーを同一にするか、セキュリティーをオフにします。
ユーザー・レジストリーを変更する場合は、
役割にマップするユーザーと、役割にマップするグループが正しいことを確認することに注意してください。
addNode 構文の詳細については、
addNode コマンド
を参照してください。
注: また、z/OS カスタマイズ・ダイアログを使用して addNode コマンドを実行することができます。
z/OS カスタマイズ・ダイアログまたはコマンド行を使用して、セキュリティーを使用可能な状態で addNode コマンドを実行する場合、権限のあるユーザー ID を使用し、-user および -password オプションを指定する必要があります。
- 管理コンソールを使用したセキュア・リモート・ノードの追加は、サポートされていません。
リモート・ノード上のセキュリティーを使用不可にしてからこの操作を実行するか、
あるいは addNode スクリプトを使用してコマンド行から操作を実行してください。
- addNode コマンドを実行する前に、
ノード上のトラストストア・ファイルが、デプロイメント・マネージャーにより所有される
鍵ストア・ファイルおよび System Authorization Facility (SAF) 鍵リングと通信すること (またはその逆) を確認してください。
ノード・エージェント・プロセスで使用したものと同じ認証局を使用して
デプロイメント・マネージャーの証明書を生成した場合、問題は発生しません。以下の SSL 構成には、
相互運用可能な鍵ストアおよびトラストストアが含まれる必要があります。
- 「システム管理」>「デプロイメント・マネージャー」>「HTTP トランスポート」>「sslportno」>「SSL」を使用して管理コンソールで指定されるシステム SSL レパートリー
- SOAP が指定されている場合の該当する JMX コネクターの SSL レパートリー
(「システム管理」>「dmgr」>「管理サービス」>「JMX
コネクター」>「SOAPConnector」>「カスタム・プロパティー」>「sslConfig」)
- NodeAgent で指定されている SSL レパートリー (「システム管理」>「ノード・エージェント」>
「NodeAgent Server」>「管理サービス」>「JMX
コネクター」>「SOAPConnector」>「カスタム・プロパティー」>「sslConfig」)
注: WebSphere Application Server for z/OS は、z/OS カスタマイズ・ダイアログを使用して、セキュリティー・ドメイン名を定義します。
異なるセキュリティー・ドメインを定義するデプロイメント・マネージャー構成にノードを追加する場合、注意してください。
- add node コマンドを
使用して、前のリリースのクライアントと
6.1 デプロイメント・マネージャーを統合する場合、
ハンドシェークを正常に行うために、
まずクライアントが署名者を取得する必要があります、
詳しくは、クライアント検索のための安全なインストールに関する項目の
『前のリリースからの署名者の取得』を参照してください。
- addNode コマンドを実行すると、アプリケーション・サーバーは新しい SSL ドメインに入ります。
そこには、鍵ストア・ファイルおよびトラストストア・ファイルを指す SSL 構成が含まれている場合がありますが、これらのファイルは、同一ドメイン内の別のサーバーとの相互運用には対応していません。
どのサーバーとどのサーバーが相互通信するのかを考えて、それらのサーバーがトラストストア・ファイル内で信頼されていることを確認してください。
分散サーバー間のセキュリティー相互作用を正しく理解すれば、セキュア通信に関する問題は大幅に削減できます。
追加機能を管理する必要があるため、セキュリティーはますます複雑になっています。
インフラストラクチャーの計画段階で、セキュリティーについて十分に検討する必要があります。
本書は、本質的なセキュリティー相互作用に起因する問題を削減するために役立ちます。
WebSphere Application Server Network Deployment 環境に関連するセキュリティーに問題がある場合は、
セキュリティー構成のトラブルシューティング
を参照して、その問題に関する追加情報を確認してください。サーバーが分散されているために、問題の解決にトレースが必要な場合、
問題を再現する間、すべてのサーバー上で同時にトレースを収集する必要が頻繁に発生します。
このトレースは、発生する問題のタイプによって、動的に使用することも、静的に使用することもできます。