Oracle® Fusion Middleware

Oracle Enterprise Data Qualityの保護

12c (12.2.1.2.0)

E88270-01(原本部品番号:E78155-02)

2016年11月

Oracle Fusion Middleware Oracle Enterprise Data Qualityの保護, 12c (12.2.1.2.0)

E88270-01

Copyright © 2015, 2016 Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 EDQセキュリティについて

- 1.1 EDQセキュリティの概要

- 1.1.1 認証

- 1.1.2 認可

- 1.1.3 暗号化

- 1.1.4 監査

- 1.2 EDQユーザー・グループ

- 1.3 EDQ権限

- 1.3.1 アプリケーション権限

- 1.3.2 機能権限

- 1.3.3 動的権限(ケース管理)

- 1.3.4 プロジェクト権限

- 1.4 デフォルトのEDQグループおよび権限

- 1.5 デフォルトの管理者ユーザー・アカウント

- 1.6 外部グループのEDQグループへのマップ

- 1.7 このガイドで使用される用語

2 推奨されるセキュリティ設定の適用

- 2.1 WebLogicでのSSLの構成

- 2.2 TomcatでのSSLの構成

- 2.3 プロセッサ・セキュリティ

- 2.3.1 デフォルト権限

- 2.3.2 スクリプトへの追加権限の付与

- 2.4 LDAP接続の暗号化

- 2.5 データベース接続の暗号化

- 2.6 同時ログインの制限

- 2.7 FTP/SFTPアクセスの無効化

- 2.8 FTP/SFTPからの構成領域の除外

- 2.9 サービス統合のための最低限の権限を持つアカウント

- 2.10 JNDIデータソースの保護

3 ユーザー認証

- 3.1 EDQ login.propertiesファイル

- 3.1.1 login.propertiesでの静的グループ・マッピング

- 3.2 WebLogicインストール

- 3.3 内部レルムの有効化

- 3.4 Tomcatインストール

4 WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

- 4.1 セキュリティ・レルム、プロバイダおよび制御フラグの理解

- 4.2 LDAPを使用するためのWebLogicの構成

- 4.2.1 前提条件

- 4.2.2 Active Directoryとの統合

- 4.2.3 WebLogic構成

- 4.2.4 EDQ構成

- 4.2.4.1 ユーザー・グループ

- 4.2.4.2 権限

- 4.2.5 グループのフィルタ

- 4.2.6 SSLを使用したLDAPへの接続

5 EDQでの外部ユーザー管理(LDAP)の直接構成

- 5.1 EDQとLDAPとの統合

- 5.1.1 前提条件

- 5.1.2 Active Directoryとの統合

A Windows統合認証(Kerberos)をサポートするためのEDQの構成

- A.1 ローカル・システム・アカウントを使用したWindowsサービスとしてのEDQの実行

- A.2 UNIXでのEDQの実行

- A.2.1 keytabとは

- A.2.2 既存のツールを使用したkeytabの作成

- A.2.3 winktabを使用したkeytabの作成

- A.2.4 UNIX Kerberos構成の確認

- A.2.5 Java暗号化

- A.2.6 login.propertiesの変更

- A.3 Kerberos共有ライブラリ

B Oracle Access Manager (OAM)でのシングル・サインオンの構成

- B.1 前提条件

- B.2 OAM構成

- B.3 WebLogicプラグイン構成

- B.4 WebLogic構成

はじめに

このガイドでは、Oracle Enterprise Data Qualityのセキュリティ機能および管理について説明します。

対象読者

このガイドの対象読者は、EDQをOracleセキュリティ標準に確実に適合させようとしている熟練した管理者、Java開発者、デプロイ担当者およびアプリケーション・マネージャです。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracle Supportへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareのドキュメント・セットにある次のドキュメントを参照してください。

EDQドキュメント・ライブラリ

次の出版物がEDQのインストールと使用のために提供されています。

- 『Oracle Fusion Middleware Enterprise Data Qualityリリース・ノート』

- Oracle Fusion Middleware Enterprise Data Qualityのインストールと構成

- 『Oracle Fusion Middleware Enterprise Data Qualityの管理』

- 『Oracle Fusion Middleware Enterprise Data Qualityの理解』

- Oracle Fusion Middleware Enterprise Data Qualityの外部システムとの統合

- Oracle Fusion Middleware Enterprise Data Qualityの保護

- Oracle Enterprise Data Qualityアドレス検証サーバーのインストレーションおよびアップグレード・ガイド

- Oracle Enterprise Data Qualityアドレス検証サーバー・リリース・ノート

次の場所で、これらのガイドおよびすべてのOracle製品ドキュメントの最新バージョンを検索してください。

https://docs.oracle.com

オンライン・ヘルプ

オンライン・ヘルプは、すべてのOracle Fusion Middlewareユーザー・アプリケーションに提供されています。各アプリケーションで、[F1]キーを押すか、「ヘルプ」アイコンをクリックすることで表示できます。ディレクタのプロジェクト・ブラウザの主なノードには、ヘルプ・ページに統合されたリンクが含まれます。それらにアクセスするには、ノードを選択して[F1]を押すか、またはプロジェクト・ブラウザでオブジェクトを右クリックして「ヘルプ」を選択します。ディレクタ・ツール・パレットのEDQプロセッサには、統合されたヘルプ・トピックも含まれます。これにアクセスするには、キャンバスでプロセッサを右クリックして「プロセッサ・ヘルプ」を選択するか、キャンバスかツール・パレットでプロセッサを左クリックして[F1]を押します。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 EDQセキュリティについて

この章では、Enterprise Data Quality (EDQ)で使用される主要なセキュリティの概念について説明します。次の項が含まれます:

- EDQセキュリティの概要

- EDQユーザー・グループ

- EDQ権限

- デフォルトのEDQグループおよび権限

- デフォルトの管理者ユーザー・アカウント

- 外部グループのEDQグループへのマップ

- このガイドで使用される用語

1.1 EDQセキュリティの概要

EDQ内のセキュリティが適用されるのは、アプリケーションにアクセスする場合(権限のあるユーザーのみをアクセス可能とし、アプリケーション内のデータを確実に保護するため)と、異常な事態を識別する目的でユーザー・アクションを監査する場合です。このガイドの内容は次のとおりです。

- セキュアなアクセス制御の提供

- 安定時およびトランスポート時のデータの保護。

- ユーザー・アクティビティの安全なロギングおよびトレースを保証するための適切なセキュリティ監査機能の提供。

詳細は、『Oracle Enterprise Data Qualityの理解』のOracle Enterprise Data Qualityの概要に関する項を参照してください。

1.1.1 認証

EDQのユーザーおよびグループの詳細は、その独自の内部ディレクトリ内に格納するか、Microsoft Active Directoryなどの外部LDAPサーバーから取得することができます。外部認証ソースを使用すると、EDQでは、他のシステムとユーザー資格証明を共有し、ユーザーが記憶して管理する必要のあるパスワードの数を削減しながら、ユーザーとグループの管理におけるオーバーヘッドを排除できます。

1.1.2 認可

認可によって、認証に成功したユーザーが実行できることを制御します。ユーザーの認可は、ユーザーのモデルと、グループに関連付けられた権限に基づきます。ユーザーは、1つ以上のグループのメンバーであり(直接割当て、または外部グループの内部グループへのマップによって割当て)、そのグループに関連付けられた権限に従って認可されます。

1.1.3 暗号化

WebLogicおよびTomcatサーバーの両方で、HTTPSがサポートされ、送信中に読取りまたは変更できないようにクライアントとEDQ間のトラフィックを暗号化する必要があります。HTTPSを選択できない環境では、EDQによって、クライアントとサーバー間で送信されるパスワードが暗号化されます。

1.1.4 監査

EDQでは、Oracle Fusion Middleware監査フレームワークを使用したユーザー・アクションの監査がサポートされます。また、ファイルに監査情報を書き込むようにEDQを構成できます。

1.2 EDQユーザー・グループ

EDQに対するすべての権限は、ユーザー・グループ(内部グループ)に付与された権限のセットを使用して割り当てられます。WebLogic、Active Directory、代替LDAPプロバイダなどでユーザーが外部的に管理される場合、そのディレクトリの外部グループをこれらの内部グループにマップすることで権限が付与されます。その後、外部グループのユーザーには、外部グループのマップ先となる1つ以上の任意のグループに基づいて権限が割り当てられます。ユーザーがEDQの内部レルムで管理される場合、それらのユーザーは、1つ以上の内部グループの直接メンバーとなるため、関連する権限が割り当てられます。

1.3 EDQ権限

EDQには、次に示すとおり、4つの権限タイプがあります。権限は、EDQユーザー・グループ(これらはさらに外部ユーザー・グループにマップされます)を介してユーザーに付与されます。

1.3.1 アプリケーション権限

これらは、EDQユーザー・アプリケーション(ディレクタ、サーバー・コンソール、ケース管理など)へのログイン・アクセス権をユーザーのグループに付与(または拒否)する単純な権限です。

1.3.2 機能権限

これらは、システムの特定の機能(ディレクタで参照データ・セットを変更する機能や、ケース管理でケースの状態またはアラートを変更する機能など)にアクセスするための権限です。

1.3.3 動的権限(ケース管理)

これらの権限は、ケース管理の管理での構成に従って、ケース管理ワークフロー内で動的に作成されます。動的権限は、特定のケースやアラートへのアクセス、またはケースのコメントや添付ファイルへのアクセスを制限するために使用されます。

1.3.4 プロジェクト権限

デフォルトでは、ディレクタで作成されるプロジェクトには、すべてのユーザー・グループがアクセスできます。ただし、より小規模なグループのセットにプロジェクトを制限することもできます。この場合、プロジェクトへのアクセス権を持っているグループ以外のユーザーは、誰もそのプロジェクトを参照または使用できません。

注意:
ディレクタでプロジェクトを追加できるユーザーには、自動的にすべてのプロジェクトに対するアクセス権が付与されます。

1.4 デフォルトのEDQグループおよび権限

次に、デフォルトのグループおよびその権限のサマリーを示します。各グループに付与されている正確な権限セットの詳細を参照するには、管理者としてログインした後に、EDQ Launchpadの「管理」→「グループ」オプションからグループを選択し、「編集」ボタンをクリックします。

表1-1 様々なユーザー・グループの権限

グループ

サマリー

機能権限

アプリケーション権限

管理者

すべての機能権限と管理権限を持つパワー・ユーザー

すべて

動的ケース管理権限は自動的に管理者に付与されません

すべて

データ・スチュワード

ディレクタおよびダッシュボードへのレビュー・アクセス権を持ち、すべての結果のレビュー、問題の解決、および手動照合とマージ済出力決定を実行する権限を付与されているが、処理ロジックを作成または変更する権限は持たないユーザー

ディレクタに対する読取り専用権限

一致レビューに対する完全な権限

ダッシュボード

ディレクタ

一致レビュー

問題マネージャ

ケース管理

サーバー・コンソール

エグゼクティブ

ダッシュボード結果のみに対するアクセス権を持つユーザー

ダッシュボード: ダッシュボードの表示

ダッシュボード

一致レビューア

一致レビュー・アプリケーション、ケース管理アプリケーションおよびダッシュボードのみに対するアクセス権を持つユーザー

基本的なケース管理権限(一括更新はなく、他のユーザーに割り当てられたケースは参照できません)

ダッシュボード: ダッシュボードの表示

一致レビュー

問題マネージャ

ケース管理

ダッシュボード

レビュー・マネージャ

ケース管理アプリケーションへのアクセス権を持ち、ケース管理を構成し、ケースとアラートの一括編集を実行する権限を付与されたユーザー。

完全なケース管理権限(監査証跡アクティビティの削除と編集を除く)

ケース管理

ダッシュボード

データ・アナリスト

ディレクタで処理ロジックを作成および変更する権限を持つが、管理権限を持たないユーザー

ディレクタに対する完全なアクセス権(システム・レベル(クロス・プロジェクト)構成を変更し、ユーザー・データ・ストアにアクセスする権限を除く)。

ディレクタ

サーバー・コンソール

一致レビュー

ケース管理

問題マネージャ

1.5 デフォルトの管理者ユーザー・アカウント

WebLogic ServerへのEDQのインストール時に、weblogic管理者ユーザー・アカウント(通常、ドメインの作成時に選択したパスワードを持つ'weblogic'です)は、WebLogicの管理者グループのメンバーとなり、これは「EDQホーム」構成ディレクトリのデフォルトのlogin.propertiesファイルを介してEDQの管理者グループにマップされます。これにより、weblogicユーザーと、WebLogic管理者グループの他のユーザーに、EDQへの管理アクセス権が付与されます。

注意:
このマッピングは固定的で、初期アクセス権の付与のみを目的としているため、実際に必要な権限は、外部グループを内部グループにマップすることで設定できます(1.6項「外部グループのEDQグループへのマップ」を参照してください)

TomcatへのEDQのインストール時には、'dnadmin'というデフォルトの内部管理者ユーザー・アカウントが作成されます。このユーザーの初期パスワードも'dnadmin'ですが、初回のログイン後によりセキュアなパスワードに変更する必要があります。これらのインストールでは、デフォルトで管理権限を持つユーザー・アカウントは1つのみであり、システムにアクセスできなくなる可能性があるため、そのユーザーを削除したり、パスワードを忘れることがないように注意してください。

1.6 外部グループのEDQグループへのマップ

外部グループは、EDQ Launchpadの管理ページから内部EDQグループにマップします。外部グループには、マップ先のすべてのEDQグループのすべての権限が付与されます。

外部グループを内部EDQグループにマップするには、次の手順を実行します。

1. 管理者としてEDQ Launchpadにログインします。

2. 「管理」ドロップダウン・リンクをクリックし、「外部グループ」をクリックします。

3. 外部レルムの名前(デフォルト・システムでは'ORACLE')を展開し、グループをクリックしてそのマッピングを編集します。

4. 外部グループに割り当てるEDQグループを選択し、「保存」をクリックして変更内容を保存します。

最適な権限割当てを確保するには、内部EDQグループに正確にマップできる外部グループをドメインに作成することが有益で、推奨されます。

注意:
多数の外部グループが存在するインストールでは、ローカルのlogin.propertiesファイルにオプション・フィルタを指定して、この画面で使用できるグループのリストを絞り込むことができます。詳細は、4.2.5項「グループのフィルタ」
を参照してください。

1.7 このガイドで使用される用語

このガイドで使用される用語は次のとおりです。

- AD - Active Directory

- 証明書 - 通常はX.509証明書を指します

- Kerberos - ネットワーク認証プロトコル

- LDAP - Lightweight Directory Access Protocol

- OID - Oracle Internet Directory

- OPSS - Oracle Platform Security Services

- SSL - Security Sockets Layerの略称で、アプリケーション・トラフィックをトランスポートできる暗号化された接続用のプロトコル。TLSで置換されましたが、SSLはまだ一般的な用語として使用されています。

- TLS - Transport Layer Securityの略称で、SSLの後継。

- WLS - WebLogic Server

- X.509証明書 - 指定されたエンティティ(個人、組織、サーバーまたはその他のエンティティ)が公開鍵に一致する秘密鍵を持っていることを証明するために信頼できる機関(認証局)から発行される証明書。

2 推奨されるセキュリティ設定の適用

この章では、EDQ環境を保護するためのヒントについて説明します。

この章の内容は以下のとおりです。

- WebLogicでのSSLの構成

- TomcatでのSSLの構成

- プロセッサ・セキュリティ

- LDAP接続の暗号化

- データベース接続の暗号化

- 同時ログインの制限

- FTP/SFTPアクセスの無効化

- FTP/SFTPからの構成領域の除外

- サービス統合のための最低限の権限を持つアカウント

- JNDIデータソースの保護

2.1 WebLogicでのSSLの構成

WebLogic ServerでのSSLの構成手順は、次のWebLogicのドキュメントを参照してください。

WebLogic ServerでのSSL構成の概要

2.2 TomcatでのSSLの構成

Tomcatで暗号化された接続を有効化するには、次の手順を使用してHTTPSコネクタを構成する必要があります。

1. Tomcatインストールでserver.xmlファイルを検索します(通常、これはTomcatディレクトリ内のconf/server.xmlです)。これには、デフォルトで次のようなセクションが含まれます。

<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation that requires the JSSE
style configuration. When using the APR/native implementation, the
OpenSSL style configuration is required as described in the APR/native
documentation -->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->

2. 前後のXMLコメント文字を削除してConnector要素を有効にします。

3. 必要に応じてHTTPSのポート値を設定します。デフォルトは8443であるため、異なる値を使用する場合は、HTTPコネクタのredirectPort値も一致するように変更してください。
1024未満のポートを使用する場合、OSによっては、サーバーで特別な権限が必要になることに注意してください。

4. サーバーの鍵と証明書を生成し、信頼できる認証局からの署名をその証明書に付与します。自己署名証明書も使用できますが、それらが認識されるためには、クライアント・マシンにインストールする必要があります。

注意:
証明書は、Javaキーストア(JKS形式)に格納されるか、PKCS#12ファイルとして格納されます。PKCS#12ファイルを操作するための多くのツールが使用できるため、一定の場合には後者の方が推奨されます。

5. 次のようにpathtokeystorefile、keystorepasswordおよびkeystoretypeを参照先の情報に置き換えて、connector要素を更新します。

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="pathtokeystorefile"
keystorePass="keystorepassword"
keystoreType="keystoretype"
/>

6. 必要に応じてkeystoreType値をJKSまたはPKCS12に設定します。キーストアに複数の証明書が含まれる場合、keyAlias属性を使用して別名を設定します。

7. 一部のTomcatディストリビューションには、Apache Portable Runtime (APR)ネイティブ・ライブラリが含まれます。この場合、証明書は、Apache HTTPD mod_sslスタイル属性を使用して構成する必要があります。次に例を示します。

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false"
SSLCertificateFile="pathtocrtfile"
SSLCertificateKeyFile="pathtokeyfile" />

Tomcatの詳細は、次の場所にある『Apache Tomcat Configuration Reference』を参照してください

http://tomcat.apache.org/tomcat-8.0-doc/config/http.html

mod_sslの詳細は、次の場所にある『Apache Module mod_ssl』を参照してください

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

2.3 プロセッサ・セキュリティ

EDQ 12.2.1.2では、EDQプロセッサのセキュリティ・レベルを向上するために使用可能なセキュリティ制御をオプションで使用できるようになりました(スクリプト・プロセッサのセキュアでない使用をブロックするなど)。下位互換性を確保するため、プロセッサ・セキュリティはデフォルトでオフになっていますが、次の行を[EDQローカル・ホーム]/director.propertiesに追加することで有効にできます。

processor.security= off/low/medium/high

プロセッサ・セキュリティ・オプションは、Javaセキュリティ・マネージャの使用と連携して動作します。Javaセキュリティ・マネージャの使用は、サーバーで指定されたJavaオプション(-Djava.security.manager)によって制御されます。これは、EDQサーバーの起動グループのJavaオプションを設定するsetStartupEnv.shスクリプトで指定されるため、WebLogic ServerにEDQを新規インストールすると、デフォルトで有効になります。他のインストールでは、手動で指定する必要があります。

次に、様々なprocessor.security設定ごとのセキュリティ・レベルをまとめます。

- Off:
セキュリティ制限は適用されません。

- Low
次の制限が適用されます。

- プロセスで直接使用するためのツール・パレットからのスクリプト・プロセッサの使用は、システムでJavaセキュリティ・マネージャが実行されていない場合、無効になります。

- システムでJavaセキュリティ・マネージャが実行されている場合、スクリプト・プロセッサは使用できますが、データ処理に制限された、デフォルト権限のごく一部のみが付与されます。スクリプトは、アプリケーションの外部でネットワーク接続を行ったり、コマンドを発行することができません。

注意:
jarにパッケージ化されたJavaプロセッサおよびスクリプトは、制限なしで実行されますが、jarにpermissions要素が含まれる場合、それらの権限のみがプロセッサに付与されます。

- Medium:
Lowと同じ制限が適用されますが、jarにパッケージ化されたJavaプロセッサおよびスクリプトには、非常に制限された権限セットが付与されます。プロセッサに必要な追加の権限は、permissions要素にリストする必要があります。

この違いを説明すると、'low'レベルでは、すべての権限が付与され、permissions要素で権限を制限するのに対し、'medium'レベルでは、権限は制限され、permissions要素で権限を拡張するということになります。どちらのレベルでも、permissions要素を持つプロセッサは、まったく同じ権限セットで実行されます。

- High:
'medium'と同じ制限が適用されますが、Oracle EDQ証明書または承認済パートナに付与された証明書によって署名されたプロセッサのみが、プロセッサに追加の権限を付与するpermissions要素を含むことができます。

未署名のjarにpermissions要素が検出されると、そのjarのプロセッサは拒否され、プロセッサ・パレットに表示されません。

2.3.1 デフォルト権限

プロセッサ・セキュリティ・セットがmediumまたはhighに設定された状態で実行されると、プロセッサに付与された権限により、次のシステム・プロパティを読み取ることができます。

- java.version

- java.vendor

- java.vendor.url

- java.class.version

- os.name

- os.version

- os.arch

- file.separator

- path.separator

- line.separator

- java.specification.version

- java.specification.vendor

- java.specification.name

- java.vm.specification.version

- java.vm.specification.vendor

- java.vm.specification.name

- java.vm.version

- java.vm.vendor

- java.vm.name

他の権限は付与されません。

2.3.2 スクリプトへの追加権限の付与

インストールはセキュアなスクリプトで実行できますが、ユーザーもアドホック・スクリプトで追加操作を実行できます。典型的な例は、Webサービス・コールの実行です。この追加機能を実現するため、システムでは、アドホック・スクリプト用の追加権限がリストされた構成ファイルがサポートされます。

追加権限ファイルは、ローカル構成ディレクトリのsecurity/permissionsフォルダにあります。スクリプト・プロセッサでは、ファイル名はscriptprocessor.xmlで、スクリプト一致ガジェットでは、ファイル名はscriptgadget.xmlです。ファイルのXML形式は次のとおりです。

<permissions>
<permission type="permissionclass" [name="targetname" [action="action"]]/>
…
</permissions>

権限クラスは、任意のJava権限クラスの完全名です。name属性は、権限にターゲット名が含まれる場合に指定します(クラスには2つまたは3つの引数のコンストラクタがあります)。actionは、権限にアクションが含まれる場合に指定します(クラスには3つの引数のコンストラクタがあります)。

たとえば、ファイル/etc/hostsを読み取る権限を付与するには、次のようにします。

<permission type="java.io.FilePermssion" name="file:/etc/hosts" action="read"/>

システム・プロパティは、${…}置換を使用してnameに含めることができます。標準のシステム・プロパティとともに、次の追加プロパティを使用できます。

- rootdir: Webアプリケーションのルートの場所。

- webinfdir: WebアプリケーションのWEB-INFディレクトリの場所。

- config.path: 構成ディレクトリのパス。そのnameに${config.path}を使用するpermissionsエントリは、パス内の各場所のエントリで置換されます。

2.4 LDAP接続の暗号化

EDQからLDAPディレクトリへの接続は、SSL/TLS接続レイヤーを使用するか、接続の確立後に暗号化をネゴシエーションすることで(StartTLS)暗号化できます。

2.5 データベース接続の暗号化

TLSを介した接続のためのJDBC URL構文は、使用されているデータベース・ドライバに応じて異なります。Oracle Databaseへの接続は、次のプロパティをデータソースの接続プール構成に追加することで暗号化できます。

oracle.net.encryption_client = REQUIRED

詳細は、http://docs.oracle.com/database/121/JJDBC/clntsec.htm#JJDBC28296を参照してください

2.6 同時ログインの制限

個々のユーザーによる同時ログインの数は、login.propertiesに制限を指定できます。この制限は、アプリケーションごとの同時ログインです。つまり、sessionlimitが1の場合、あるユーザーは、同時にディレクタ、サーバー・コンソール、ケース管理にログインできますが、どれにも2回ログインすることはできません。

これは、グローバルに構成するか、レルム単位で構成することができます。すべてのレルムでグローバルにこれを設定するには、次の行を使用します。

sessionlimit = 1

レルムごとに異なる設定を使用するには、次のようにパラメータの前にレルム名を指定します。

internal.sessionlimit = 1

注意:
前述の行を使用すると、内部レルム(ユーザーがEDQ自体で設定および管理されるという意味)の同時ログインも制限できます。

<external realm name>.sessionlimit = 1

2.7 FTP/SFTPアクセスの無効化

最適なセキュリティのため、不要な環境では、EDQへのFTP/SFTPアクセスを無効にする必要があります。標準のFTPは、ローカル構成フォルダ内のdirector.propertiesに次の行を追加して無効にできます。

launch.ftpserver = 0

SFTP/SCPは、同じファイル内の次の行を使用して無効にできます。

launch.sshd = 0

2.8 FTP/SFTPからの構成領域の除外

管理者以外のユーザーがFTP/SFTPにアクセスできる場合、次のようにSFTPサーバーから構成フォルダに対するアクセス権を削除することをお薦めします。

1. まだ存在しない場合、oedq.local.home内にextras/ftpserver/confおよびextras/sshd/confフォルダを作成します。

2. ファイルextras/ftpserver/conf/ftpserver.xmlおよびextras/sshd/conf/sshd.xmlを、oedq.home構成ディレクトリからoedq.local.homeの対応するサブフォルダにコピーします。

3. 前の手順の2つのファイルそれぞれで、次の行をコメント・アウトします。

<!-- Configuration area -->
<ref bean="configspaces"/>
<!-- Command areas -->
<ref bean="commandspaces"/>

最初の参照は構成ディレクトリを示し、2番目の参照は外部タスクで使用されるコマンド領域を示します。

4. アプリケーション・サーバーを再起動します。これで、FTPおよびSFTPサーバーに認識される場所は、ランディング領域のみとなります。

2.9 サービス統合のための最低限の権限を持つアカウント

Siebelがバッチ・ジョブ用にEDQと統合されている場合、EDQジョブを開始するには、ユーザー・アカウントに管理(JMX)ポートに接続する権限も必要です。これは、「システム/システム管理」機能権限によって制御されます。また、メッセージング・システムへの接続が、「システム/メッセージング・システムへの接続」としてリストされている必要があります。セクションでOracle Data Integrator (ODI)を参照する必要もあります。ODI統合に使用するEDQアカウントには、同じ権限が必要です(実際には、現在、「メッセージング・システムへの接続」は必要ありませんが、将来のことを考慮して含めておくことをお薦めします)。そのため、次のようなものが必要です。

SiebelやOracle Data Integratorなどのリモート・システムによって使用されるEDQアカウントには、EDQシステムに対する最低限の権限セットが必要です。具体的には、アカウントは次の権限のみを持つカスタム・グループに属している必要があり、ユーザー・アプリケーションにログインしたり、他の機能を実行するためのアクセス権は付与しません。

- システム/メッセージング・システムへの接続 - EDQ WebサービスおよびJMSと通信する権限を付与します。

- システム/システム管理 - EDQ管理(JMX)ポートに接続してジョブを開始できる権限を付与します。

- コールを可能にする必要があるサービス・インタフェース(Webサービスまたはジョブ)を含む任意のプロジェクトに対する権限。

2.10 JNDIデータソースの保護

特定の手順を実行しないかぎり、EDQのユーザーは、既存のデータソースのJNDI名に対する参照を使用してデータ・ストアを設定し、これらのスキーマの(機密情報を含む可能性のある)データにアクセスできます。EDQのJNDIデータソースを保護するには、次のようにdirector.propertiesに名前(または名前に一致する正規表現)を指定します。

protected.jndi.datasources = <space separated list of JNDI names>

次に例を示します。

protected.jndi.datasources = jdbc/edqconfig jdbc/edqresults

プロパティは正規表現の空白区切りのリストであるため、次の方法も使用できます。

protected.jndi.datasources = jdbc/edq.*

注意:
この値をローカルのdirector.propertiesに設定する場合、必ずベース・プロパティ・ファイルのデフォルト設定を含めてください。この設定により、WebLogicの内部データソースとEDQデータソースの両方に対するアクセスを防止します。

3 ユーザー認証

この章では、EDQでのユーザーの認証方法について説明します。

この章の内容は次のとおりです。

- EDQ login.propertiesファイル

- WebLogicインストール

- 内部レルムの有効化

- Tomcatインストール

3.1 EDQ login.propertiesファイル

EDQのユーザー認証は、EDQ構成領域のsecurity/login.propertiesというファイルを使用して構成します。このファイルは、'home'構成ディレクトリまたは'local'構成ディレクトリ(あるいはその両方)に存在します。両方に存在する場合、'local'ディレクトリの値が優先される形で設定がマージされます。ファイルを変更する必要がある場合は、必ず'local'ディレクトリのバージョンを編集してください。

EDQの'home'構成領域には、LDAP統合の複数のタイプに応じた設定例を含むファイルsecurity/login.properties.templateがあります。

login.propertiesファイルでは、複数のレルムを定義します。各レルムは、ユーザーから独立したストアです。ファイルはグローバル設定から始まり、次に各レルムの設定が続きます。標準のグローバル設定は次のとおりです。

realms = realm1, realm2, …
gss    = false

realmsプロパティでは、このインストールで構成するレルムのリストを定義します。名前は任意ですが、特別なレルム名'internal'は、EDQ内部ユーザー・ストアを指定します(ユーザーdnadminなど)。

'gss'設定は、拡張Kerberosスタイルの認証をオフにします。

グローバル設定の次に、レルム固有のプロパティのブロックが続きます(それぞれグローバル・リストのレルム名が接頭辞になります)。たとえば、内部レルムとLDAPレルムを使用する構成は、次のようになります。

realms                                = internal, corpldap
gss                  = false
corpldap.realm       = EXAMPLE.COM
corpldap.ldap.server = dc1.example.com
…

これらの設定の詳細は、この後で説明します。

login.propertiesで複数のレルムを定義すると、EDQのログイン画面(WebコンソールおよびUI)に、ユーザー名とパスワードに関連付けられたレルムのドロップダウン・セレクタが表示されます。

3.1.1 login.propertiesでの静的グループ・マッピング

外部LDAPユーザー・ストアを使用し、EDQ内部ユーザー・ストアを使用しない場合、LDAPグループからEDQグループへのマッピングを設定しようとすると、ブートストラップ問題が発生します。これを行うには、EDQ Webコンソールを使用します(EDQ管理者ログインが必要です)。ただし、LDAPユーザーがEDQにログインするためには、LDAPグループをEDQ管理者グループにマップする必要があります。

この問題を回避するため、login.propertiesで静的グループ・マッピングを定義できます。構文は次のとおりです。

realm.xgmap = exgroup1 -> edqgroup1, exgroup2 -> edqgroup2 …

'realm'は、グローバル・レルム・リストに指定されたレルム名です。各'exgroup'は外部LDAPグループの名前で、各'edqgroup'はEDQグループの名前です。

静的マッピングは、最初の管理マッピングを設定する場合にのみ使用し、他のマッピングはEDQ Webコンソールの「外部グループ」ページで構成する必要があります。

たとえば、'EDQ-ADMINS'というLDAPグループをEDQ管理者グループにマップするには、次の行を追加します。

corpldap.xgmap = EDQ-ADMINS -> Administrators

3.2 WebLogicインストール

WebLogicへのEDQの標準インストールでは、認証にドメインの内部ユーザー・ストアを使用します。これには、ドメイン管理ユーザー(通常は'weblogic')と、他のユーザーの小規模なセットが含まれます。

EDQのデフォルト・セキュリティ構成では、WebLogic管理者グループのすべてのユーザーがEDQ管理者グループにマップされます。他のグループ・マッピングは初期定義されません。

別のユーザーを追加するには、WebLogic管理コンソールにログインし、デフォルト・セキュリティ・レルムの「ユーザーとグループ」タブに移動します。

WebLogicでユーザーを管理するかわりに、ユーザーの外部ソース(通常はActive DirectoryなどのLDAPサーバー)に統合できます。統合は、WebLogic管理コンソールで構成するか、セキュリティ構成ファイルを編集してEDQから直接構成できます。前者の方法は第4章「WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合」を、後者の方法は第5章「EDQでの外部ユーザー管理(LDAP)の直接構成」を参照してください。

'home'構成ディレクトリのデフォルトのlogin.propertiesの内容は次のとおりです。

realms     = opss
opss.realm = ORACLE
opss.label = Weblogic
opss.type  = opss
opss.xgmap = Administrators -> Administrators

この構成により、WebLogicによって提供されるOPSSライブラリが認証に使用され、WebLogic管理者グループがEDQ管理者グループにマップされます。

3.3 内部レルムの有効化

内部的にユーザーを管理するには、内部レルムを有効にする必要があります。ユーザーの内部レルムを有効にするには、次の手順を実行します。

1. ローカル構成ディレクトリにsecurityというサブディレクトリを作成します(oedq_local_home/security)。

2. login.propertiesファイルを、基本構成ディレクトリのsecurityディレクトリ(oedq_home/security)からoedq_local_home/securityにコピーします。

3. レルムのカンマ区切りのリストに'internal'を追加します。
'opss'では、WebLogicユーザーのレルムが有効化されることに注意してください。内部的にユーザーを管理するのみの場合、レルムのリストからopssを削除できます。

4. サーバーを再起動します。

これにより、ユーザーの内部レルムが有効になり、Launchpadの管理ページで内部ユーザー・アカウントを管理できます。単一のデフォルト管理者ユーザー'dnadmin'が'dnadmin'という初期パスワード付きで存在していますが、このパスワードは初回のログイン時に変更する必要があります。

複数のレルムが定義されている場合、ユーザーは、使用するレルムをログイン時に選択する必要があります。

3.4 Tomcatインストール

TomcatへのEDQのインストールでは、EDQ内部認証メカニズムを使用します。これには、完全な管理権限を持つ単一のユーザー'dnadmin'が含まれます。別のユーザーは、EDQの管理Webページを使用して追加できます。

EDQのセキュリティ構成ファイルを編集して、Active Directoryなどの外部LDAPサーバーに統合できます。これは、第5章「EDQでの外部ユーザー管理(LDAP)の直接構成」で説明します。

デフォルト設定では内部認証が使用されるため、Tomcatインストールではlogin.propertiesファイルはデフォルトで使用されません。追加設定が必要な場合、またはLDAP統合が必要な場合、'local'構成ディレクトリにsecurity/login.propertiesファイルを新規作成し、そこで変更を行ってください。

4 WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合

この章では、WeblogicおよびOPSSを使用したLDAPとの統合について説明します。次の項が含まれます:

- セキュリティ・レルム、プロバイダおよび制御フラグの理解

- LDAPを使用するためのWebLogicの構成

4.1 セキュリティ・レルム、プロバイダおよび制御フラグの理解

WebLogicドメインには、1つ以上のセキュリティ・レルムを含めることができます。各レルムでは、セキュリティ構成、ユーザーおよびグループを定義します。一度にアクティブにできるレルムは1つのみで、通常は追加のレルムを作成する利点はありません。WebLogicドメインのデフォルト・レルムの名前は、'myrealm'です。

各レルムには、複数のセキュリティ・プロバイダが含まれます。プロバイダは、ユーザー認証やユーザー・ストアを処理するオーセンティケータであるか、X.509証明書やSAMLトークンなど、リクエストに埋め込まれたデータからユーザー・アイデンティティを特定できるアイデンティティ・アサータです。OAM統合で使用されるOracle Access Managerアイデンティティ・アサータは、B.4項「WebLogic構成」で説明します。

デフォルト・セキュリティ・レルムには、1つのオーセンティケータと2つのアイデンティティ・アサータが含まれます。

DefaultAuthenticatorは、内部WebLogicストアのユーザーを処理します。

各オーセンティケータ・プロバイダには、制御フラグ設定があります。このフラグにより、ユーザーの認証においてプロバイダが果たす役割が決定されます。使用可能なフラグ値は4つありますが、重要なものは次の2つです。

REQUIRED: プロセス全体が完了するためには、このプロバイダの認証が成功する必要があります。

SUFFICIENT: 他のオーセンティケータにREQUIRED制御フラグがないかぎり、このプロバイダの認証が成功すると、プロセス全体が成功します。

DefaultAuthenticatorは、制御フラグがREQUIREDに設定されて事前構成されているため、LDAP認証プロバイダが構成されていても成功する必要があります。LDAPサポートの構成プロセスの一環として、この値をSUFFICIENTに変更します。

プロバイダの順序も重要です。複数のオーセンティケータが有効化され、適切な制御フラグで構成されている場合、オーセンティケータのいずれかによってサポートされるユーザーは、WebLogic管理コンソールにログインできます。ただし、EDQは、リストの最初のオーセンティケータのみにアクセスでき、リストでそれより下位のオーセンティケータのユーザーは、認識されません。したがって、LDAPオーセンティケータを追加する場合、それをリストの一番上に移動することが重要です。これも後で説明します。

4.2 LDAPを使用するためのWebLogicの構成

この項には、前提条件およびWebLogicの構成手順が含まれます。

4.2.1 前提条件

構成プロセスを開始する前に、次の情報を収集する必要があります。

- 使用しているLDAPサーバーのタイプ。WebLogicには、Microsoft Active Directory、OpenLDAP、Oracle Internet Directoryなど、複数のタイプのLDAPサーバーに応じたオーセンティケータがあります。直接サポートされないサーバー(AD-LDSなど)で使用できる汎用のLDAPオーセンティケータもあります。

- LDAPサーバーのホスト名およびポート。現在の環境に高可用性対応のサーバーが複数含まれる場合、構成内で複数のホストを使用できます。デフォルトのLDAPポートは389です。

- 接続して検索を実行できるLDAPユーザーのアイデンティティおよびパスワード。ユーザー・アイデンティティは、通常、完全な識別名(DN)ですが、Active Directoryでは短縮形式も使用できます。

- ユーザーとグループを検出できるLDAPツリー(ベースDN)内の場所。

- ログイン時にユーザーを識別するユーザー・レコードのLDAP属性。ほとんどのLDAPユーザー・スキーマには標準のユーザー名属性がありますが、組織ではそれ以外のものを使用できます。

- グループを識別するグループ・レコードのLDAP属性。ほとんどのインストールで、これは共通名(cn)というグループになります。

- EDQを操作するすべてのユーザーが含まれるLDAPグループの名前。グループは、EDQの問題の割当てなどに表示されるユーザーのリストをフィルタするために使用されます。このフィルタがないと、LDAPサーバーのすべてのユーザーが表示されるため、一般的には推奨されません。

4.2.2 Active Directoryとの統合

この項の残りでは、Active Directoryとの統合に関する詳細な手順について説明します。この手順は、他のタイプのLDAPサーバーとほぼ同じです。初期構成ではSSLを使用しません。

手順の説明では、次の設定を使用します。

- Active Directoryドメイン: EXAMPLE.COM

- ドメイン・コントローラ(LDAPサーバー): dc1.example.com。デフォルトの非SSLのポート389が使用されます。

- LDAPユーザー: cn=netuser,cn=users,dc=example,dc=com。このユーザーのADユーザー名が'netuser'であるとすると、netuser@example.comまたはexample\netuserも使用できます。

- ユーザー・ベースDN: dc=example,dc=com。ここでのベースとは、完全なLDAPツリーのルートです。すべてのユーザーがサブツリーに含まれる場合、cn=users,dc=example,dc=comなどを使用できます。

- グループ・ベースDN: dc=example,dc=com。同様に、適切な場合はサブツリーを使用できます。

- ユーザー名属性: sAMAccountName。これは、短いログイン名を格納する標準のAD属性です。「Active Directoryユーザーとコンピュータ」アプリケーションで、これはWindows 2000より前のログイン名として表示されます。

- グループ名属性: cn

- すべてのEDQユーザー・グループ: edqusers

4.2.3 WebLogic構成

注意:
WebLogic管理サーバーが実行されていることを確認します。構成を開始する前にEDQ管理対象サーバーを停止することをお薦めします。

WebLogicを構成するには、次の手順を実行します。

1. 管理コンソールにログインし、「セキュリティ・レルム」のmyrealmに移動して「プロバイダ」タブをクリックします。「新規」をクリックして、新しいプロバイダを追加します。ADなどの名前を入力し、「ActiveDirectoryAuthenticator」を選択します。

2. 「OK」をクリックします。構成されていない新しいプロバイダがリストの一番下に追加されます。アラートにより、変更を反映するために管理サーバーを再起動する必要があることが示されます。この段階ではこれは必要ありません。構成が完了したときにサーバーを再起動してください。
新しいプロバイダをクリックし、「構成」画面で制御フラグを「SUFFICIENT」に変更します。

3. 「保存」をクリックして「プロバイダ固有」タブを選択します。ここでLDAPサーバーの情報を入力します。「接続」領域で、LDAPサーバー、ポート、ユーザー(プリンシパル)およびパスワード(資格証明)を入力します。「SSLの有効化」チェック・ボックスは選択しません。

4. 「ユーザー」領域で、「ユーザー・ベースDN」を入力し、「名前指定によるユーザー・フィルタ」および「ユーザー名属性」フィールドで'cn'をユーザー名属性に置き換えます。

5. 「グループ」領域で、「グループ・ベースDN」を入力し、グループ名属性として'cn'を使用していない場合は「名前指定によるグループ・フィルタ」で'cn'を置き換えます。

6. 残りのセクションの変更は不要です。構成を保存するには、「保存」をクリックします。
プロバイダのリストに戻り(セキュリティ・レルム/myrealm、「プロバイダ」タブ)、「DefaultAuthenticator」をクリックします。「制御フラグ」を「SUFFICIENT」に変更して「保存」をクリックします。

7. プロバイダ・リストに戻り、「並替え」をクリックします。「AD」を選択し、矢印を使用してそれをリストの一番上に移動します。

8. 「OK」をクリックして並替えを確認します。
プロバイダ・リストで、ADプロバイダが最初に表示されます。これにより、EDQがActive Directoryに対して認証可能になります。

管理サーバーを再起動して再度ログインします。「セキュリティ・レルム」のmyrealmに移動して、「ユーザーとグループ」タブをクリックします。Active Directoryからロードされたユーザーとグループが表示されます。これらが表示されない場合、管理サーバーのログでエラーを調査し、構成を再確認してください。

「ユーザーとグループ」タブの表示が極端に遅く、ログにサイズ制限エラーが記録された場合、次のようになります。

<Administration Console encountered the following error: java.lang.RuntimeException: netscape.ldap.LDAPException: error result (4); Sizelimit exceeded

この場合、Active Directoryのユーザーの数が多すぎて、管理コンソールに表示できません。EDQでこれが問題になることはありませんが、ADの「プロバイダ固有」タブにある「すべてのユーザーのフィルタ」フィールドにLDAP検索フィルタを入力して、その数を削減できます。

4.2.4 EDQ構成

この項では、EDQの構成手順について説明します。

4.2.4.1 ユーザー・グループ

EDQユーザーを含むグループを定義するには、次の手順を実行します。

1. EDQドメインをホストするサーバーにログインし、EDQの'local'構成ディレクトリに移動します。
これは、DOMAIN_HOME/config/fmwconfig/edq/oedq.local.homeにあります。

2. ローカル・セキュリティ・ディレクトリを作成し、このディレクトリにデフォルトのログイン構成をコピーします。

$ mkdir security
$ cp ../oedq.home/security/login.properties security/

3. security/login.propertiesで新しいローカル構成を編集し、次の行を追加します。

opss.prof.defaultusergroup = edqusers

4.2.4.2 権限

login.propertiesの事前定義されたグループ・マッピングによって、外部管理者グループがEDQ管理者グループにマップされます。これは、内部WebLogicユーザー・ストアを使用する場合には有効なマッピングです(内部管理者グループには、標準の'weblogic'管理コンソール・ユーザーが含まれるため)。

ただし、Active Directoryの管理者グループには、ドメイン・レベルの管理者が含まれており、このグループのユーザーはEDQを使用または管理しない可能性があります。EDQ Webコンソールを使用して外部EDQ関連グループから別のグループ・マッピングを追加するには、管理者としてEDQにログインする必要があります。これは、Active Directory管理者が使用できる場合にのみ、事前定義されたデフォルトのグループ・マッピングで可能です。他のユーザーがEDQ管理者になることを許可するには、次の2つのアプローチがあります。

- 事前定義されたマッピングを編集します。
ローカルのlogin.propertiesを編集し、xgmap行を変更して別のLDAPグループをEDQ管理者グループにマップします。たとえば、EDQ管理ユーザーを含めるためにActive Directoryで'edqadmins'というグループが作成されている場合、次のように行を編集します。

opss.xgmap = edqadmins -> Administrators

- 内部レルムを有効にします。
ローカルのlogin.propertiesを編集して次のようにrealms行を変更します。

realms = internal, opss

これにより、EDQ内部ユーザー・ストアが有効になり、ユーザー'dnadmin'としてログインし、Webコンソールを使用して必要な外部グループ・マッピングを設定できます。マッピングが完了したら、内部レルムを再度無効にすることができます。

これらの変更が完了したら、EDQ管理対象サーバーを起動してActive Directoryユーザーとしてログインできます。アプリケーション・ログインに成功するには、外部グループ・マッピングを完了させて必要な権限を付与する必要があることに注意してください。

4.2.5 グループのフィルタ

大規模な組織のLDAPストアには、数千に及ぶ別個のグループが含まれることがあり、追加フィルタがなければ、EDQ Webコンソールの外部グループのマッピング・リストにすべて表示されます。グループ・リストを管理可能なサイズにフィルタするには、LDAPグループ・フィルタをlogin.propertiesに追加します。

フィルタを追加する前に、ローカル構成領域に必ずこれのコピーを作成してください。フィルタを追加するには、次の行を編集して追加します。

opss.prof.groupfilter = LDAPGROUPFILTER

ここで、LDAPGROUPFILTERは、グループを選択するためのLDAPスタイルのフィルタです。フィルタでは、LDAP固有の属性のかわりに汎用のOPSS属性名を使用します。'name'を使用して、グループの名前を示します。フィルタでは、事前定義されたマッピングで使用されるすべてのグループを戻す必要があります。

EXAMPLE.COM設定では、EDQで使用されるすべてのグループが接頭辞'edq'で始まるため、フィルタは次のようになります。

opss.prof.groupfilter = (name=edq*)

4.2.6 SSLを使用したLDAPへの接続

SSLを使用してLDAPサーバーへの接続を保護する場合、LDAPプロバイダの「プロバイダ固有」タブにある「SSLの有効化」チェック・ボックスを選択して、SSLポート(通常は636)を入力します。

注意:
WebLogicの現在のバージョンでは、初期構成後に「プロバイダ固有」ページに変更を加える場合、LDAPパスワードを再度入力する必要があります。元のパスワードは不明瞭化されますが、このバージョンはその後保存されます。

次に、WebLogicからLDAPサーバーへの正常な接続を有効にして、ユーザーとグループのリストを表示し、LDAPユーザーとしてWebLogicにログインできるようにするには、LDAPサーバー証明書またはルートCAを、WebLogicの実行に使用されるJREのトラスト・ストアに追加する必要があります。Java keytoolコマンドを使用して、JREのcacertsファイルを更新します。keytoolのドキュメントは次の場所にあります。

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

現状で、WebLogic認証のためにEDQで使用されるOPSSライブラリは、cacertsストアを使用しません。かわりに、新しいキーストアを作成する必要があります。EDQ管理対象サーバーは停止しますが、管理サーバーは実行を継続します。WebLogicが実行されているサーバーにログインし、次の環境変数を設定します。

JAVA_HOME=java install location
WL_HOME=WLSHOME/wlserver
ORACLE_HOME=WLSHOME

その後、次を実行します。

$ WLSHOME/oracle_common/bin/libovdconfig.sh -host HOST -port PORT -userName weblogic -domainPath DOMAIN_HOME -createKeystore

ここで、WLSHOMEはWebLogicのインストール・ディレクトリ、HOSTは管理サーバーが実行されているホストの名前、PORTは管理ポート(通常は7001)、DOMAIN_HOMEはWebLogicドメインの場所です。

このコマンドにより、weblogicユーザーのパスワードと、新しいキーストアのパスワードの入力を求められます。これは任意に指定できます。

正常に完了すると、新しいキーストアが次の場所に作成されます。

DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks

Java keytoolを使用して、サーバーまたはCA証明書を新規作成したキーストアに追加します。

$ keytool -import -keystore DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks -alias ALIAS -file CERTFILE

証明書を指定するキーストアでALIASを置き換え、証明書ファイルの場所でCERTFILEを置き換えます。

このコマンドにより、キーストア・パスワードの入力を求められます(キーストアの作成時に指定したパスワードを入力します)。

EDQ管理対象サーバーを再起動すると、LDAPユーザーはログインすることができます。WebLogicとLDAP間のトラフィックは、SSLで保護されます。

5 EDQでの外部ユーザー管理(LDAP)の直接構成

この章では、EDQとLDAPとの統合について説明します。次の項が含まれます:

- EDQとLDAPとの統合

5.1 EDQとLDAPとの統合

この項には、前提条件およびEDQとLDAPとの統合手順が含まれます。

WebLogicを使用していない場合、または複数のLDAPストアを使用する場合、login.propertiesの設定を使用してEDQとLDAPを直接統合できます。これは、使用しているタイプのLDAPサーバーに対応する事前定義されたオーセンティケータがWebLogicで提供されていない場合にも便利です。たとえば、AD-LDS (Windowsで提供されている軽量LDAPサーバー)は、Active Directoryと互換性がなく、WebLogicのActiveDirectoryAuthenticatorを使用できません。

この項では、単純なLDAP統合のためにlogin.propertiesで必要な設定について説明します。Windows統合認証で使用されるKerberosサポートは、付録A「Windows統合認証(Kerberos)をサポートするためのEDQの構成」で説明します。

5.1.1 前提条件

構成プロセスを開始する前に、次の情報を収集する必要があります。

- 使用しているLDAPサーバーのタイプ。EDQには、Active Directory、Oracle Internet Directory、OpenLDAP (inetOrgPersonユーザー・スキーマを使用)、およびRFC 2307 (Posix)スタイルのユーザー・スキーマを使用するサーバーのための組込みプロファイルがあります。

- LDAPサーバーのホスト名およびポート。現在の環境に高可用性対応のサーバーが複数含まれる場合、構成内で複数のホストを使用できます。デフォルトのLDAPポートは389です。

- 接続して検索を実行できるLDAPユーザーのアイデンティティおよびパスワード。ユーザー・アイデンティティは、通常、完全な識別名(DN)ですが、Active Directoryでは短縮形式も使用できます。

- LDAPツリーのベースDN。可能な場合、これはLDAP RootDSEのdefaultNamingContext属性から自動的に決定されますが、利用できない場合はlogin.propertiesに指定する必要があります。

- EDQを操作するすべてのユーザーが含まれるLDAPグループの名前。グループは、EDQの問題の割当てなどに表示されるユーザーのリストをフィルタするために使用されます。このフィルタがないと、LDAPサーバーのすべてのユーザーが表示されるため、一般的には推奨されません。

5.1.2 Active Directoryとの統合

この項の残りでは、Active Directoryとの統合に関する詳細な手順について説明します。この手順は、他のタイプのLDAPサーバーとほぼ同じです。初期構成ではSSLを使用しません。

手順の説明では、次の設定を使用します。

- Active Directoryドメイン: EXAMPLE.COM

- ドメイン・コントローラ(LDAPサーバー): dc1.example.com。デフォルトの非SSLのポート389が使用されます。

- LDAPユーザー: cn=netuser,cn=users,dc=example,dc=com。このユーザーのADユーザー名が'netuser'であるとすると、netuser@example.comまたはexample\netuserも使用できます。

- ベースDN: dc=example,dc=com。Active Directoryを使用する場合、これはRootDSEから自動的に決定されます。

- すべてのEDQユーザー・グループ: edqusers

注意:
login.propertiesがEDQのローカル構成領域のsecurityディレクトリに存在することを確認してください。Tomcatインストールには、デフォルトのlogin.propertiesがないため、新しい空のファイルを作成します。

- グローバル設定:
この例では、Active Directoryレルムの名前は'ad'です。

realms                    = internal, ad
gss                       = false
ldap.prof.useprimarygroup = false

レルム・リストを定義します。EDQ内部レルムは、EDQ Webコンソールで組込みの管理者ユーザー'dnadmin'を使用して外部グループ・マッピングを設定するために使用します。最終設定は、ユーザーのプライマリ・グループがグループ・メンバーシップの決定で考慮されないことを示します。Active Directoryでは、これは常にすべてのユーザーを含むドメイン・ユーザー・グループで、EDQでは使用されません。

- レルム名:

ad.realm = EXAMPLE.COM

Active Directoryドメインの名前を設定します。login.propertiesで複数のレルムを定義すると、EDQのログイン画面にそのレルムのドロップダウン・セレクタが表示されます。これに説明的なテキストを含めるには、次のように'label'プロパティを追加します。

ad.label = Example, Inc. Active directory

- LDAPサーバー設定:

ad.ldap.server = dc1.example.com
ad.ldap.auth   = simple
ad.ldap.user   = cn=netuser,cn=users,dc=example,dc=com
ad.ldap.pw     = <password for the user>

サーバー名とユーザー情報を設定します。サーバーを省略すると、EDQは、LDAPサービス・レコードのDNSルックアップによってそれを自動的に決定しようとします。EDQが実行されているサーバーが、DNSについてActive Directoryドメイン・コントローラを使用するように構成されている場合、これらのレコードは自動的に設定されます。それ以外の場合、login.propertiesにサーバーを指定します。カンマまたは空白区切りのリストを使用して、複数のサーバーを指定できます。

ad.ldap.server = dc1.example.com, dc2.example.com:2342

EDQとLDAP間の接続に対して暗号化を構成するには、次の行を追加します。

ad.ldap.security = ssl or tls

値としてsslを指定すると、LDAPサーバーのSSLポート(通常は636)に対して接続が行われます。この場合、LDAPサーバーによって使用される証明書は、EDQを実行しているJREによって信頼される必要があります。信頼できるプロバイダによって証明書が作成されていない場合、keytoolコマンドを使用して、JREのcacertsトラスト・ストアにサーバーまたはルートCA証明書を追加します。https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.htmlを参照してください

プロパティ値としてtlsを指定すると、通常の非SSL LDAPポートに対して接続が行われ、接続を切り替えてTLS暗号化を使用するようにStartTLSコマンドが発行されます。パスワードなどのすべての機密情報は、TLSへの切替え後に送信されます。この場合、EDQは、サーバー証明書に簡易チェックを適用します(これはJREに信頼される必要はありません)。内部ネットワークのスプーフィングが懸念される場合は、追加チェックにSSLを使用してください。それ以外の場合、TLSの使用によって構成が簡略化されます。

- ユーザー認証の構成:
このプロパティ・セットにより、EDQに提供されるユーザー名とパスワードのLDAPでの検証方法が定義されます。これは、2段階のプロセスです。最初に、ユーザー名によって識別されるユーザー・レコードを特定するために検索が行われます。Active Directoryでは、これを行うため、ユーザー名に一致するsAMAccountNameを持つユーザーまたはusername@DOMAINに一致するuserPrincipalNameを持つユーザーを検索します。これらのActive Directory属性は、Windowsの短いログイン名と長いログイン名を表します。

ユーザー・レコードが見つからない場合、認証は失敗します。パスワードを検証するには、次の3つの異なるメソッドがあります。

- bind: 検出されたユーザー・アイデンティティおよびパスワードを使用してLDAPへの接続を試みます。これが成功しない場合、認証は失敗します。

- password: ユーザー・レコードからハッシュ化されたパスワードを読み取り、それを指定されたパスワードと比較します。ほとんどのLDAPサーバーでは、ユーザー・パスワード値を読み取ることができないため、このメソッドはめったに適用されません。これは、Posixスタイルのユーザー・スキーマで使用されることがあります。

- compare: LDAPの比較操作を使用してパスワードを確認します。このメソッドは、Oracle Internet Directoryで使用可能で、LDAPサーバーで新しいセッションを作成することがないため、状況によっては'bind'より適切です。

デフォルト・メソッドは'bind'で、これは常にActive Directoryで使用されます。

ad.auth            = ldap
ad.auth.bindmethod = simple
ad.auth.binddn     = search: dn

'auth'プロパティでLDAPベースの認証を設定しますが、Kerberosなどの拡張メソッドを使用する場合、他の設定も可能です。'bindmethod'プロパティでは、接続メソッドを設定します('simple'は、ユーザー名とパスワードをクリア・テキストで送信します)。'binddn'プロパティでは、接続の試行で使用されるアイデンティティを設定します。ここでは、初期ユーザー検索で検出されたDN (識別名)が使用されます。

かわりのバインド・メソッドは、クリア・テキストではなくハッシュ化形式でパスワードを送信するdigest-md5です。このメソッドを使用するには、バインド・プロパティを次のように置き換えます。

ad.auth.bindmethod = digest-md5
ad.auth.binddn     = search: sAMAccountName

Windowsユーザー名は、識別名(これはdigest-md5接続では必須)のかわりに接続で使用されます。

パスワード検証にLDAP比較を使用するには、Oracle Internet Directoryで次の設定を使用します。

oid.auth        = ldap
oid.auth.method = compare

- LDAPプロファイル:
これらの設定で、使用するLDAPスキーマを定義し、ユーザー・ルックアップをカスタマイズします。

ad.ldap.profile               = adsldap
ad.ldap.prof.defaultusergroup = edqusers

'adsldap'プロファイルは、Active Directoryで使用されます。事前定義された他のプロファイルは次のとおりです。

- inetorgoidldap: Oracle Internet DirectoryとinetOrgPersonユーザー

- inetorgopenldap: OpenLDAPとinetOrgPersonユーザー

- rfc2307ldap: RFC 2307 (Posix)スタイルのユーザー・レコード

'defaultusergroup'プロパティで、すべてのEDQユーザーを含むグループを定義します。

大規模な組織のLDAPストアには、数千に及ぶ別個のグループが含まれることがあり、追加フィルタがなければ、EDQ Webコンソールの外部グループのマッピング・リストにすべて表示されます。グループ・リストを管理可能なサイズにフィルタするには、次のようにLDAPグループ・フィルタを追加します。

ad.ldap.prof.groupsearchfilter = LDAPGROUPFILTER

ここで、LDAPGROUPFILTERは、グループを選択するためのLDAPスタイルのフィルタです。フィルタでは、事前定義されたマッピングで使用されるすべてのグループを戻す必要があります。

EXAMPLE.COM設定では、EDQで使用されるすべてのグループが接頭辞'edq'で始まるため、フィルタは次のようになります。

ad.ldap.prof.groupsearchfilter = (cn=edq*)

- まとめ:
これが、Active Directory統合の例で使用される完全なlogin.propertiesです。

# EXAMPLE.COM LDAP integration
# ----------------------------

realms                        = internal, ad
gss                           = false
ldap.prof.useprimarygroup     = false

ad.realm                      = EXAMPLE.COM
ad.ldap.server                = dc1.example.com
ad.ldap.auth                  = simple
ad.ldap.user                  = cn=netuser,cn=users,dc=example,dc=com
ad.ldap.pw                    = <password for the user>
ad.auth                       = ldap
ad.auth.bindmethod            = simple
ad.auth.binddn                = search: dn

ad.ldap.profile               = adsldap
ad.ldap.prof.defaultusergroup = edqusers

- 複数のLDAPストアとの統合:
複数のLDAPストアと統合するには、複数のレルムを定義してそれぞれの設定のブロックを含めます。

realms = internal, ad1, ad2, oid
ad1.realm = …
…
ad2.realm = …
…
oid.realm = …
…

複数のドメインを持つActive Directoryフォレストを使用する場合、login.propertiesに各ドメインを個別のレルムとして定義する必要があります(EDQでは、クロスドメイン参照を作成できません)。次に例を示します。

realms = internal, aduk, asus
aduk.realm       = UK.EXAMPLE.COM
aduk.ldap.server = DC1.UK.EXAMPLE.COM
…
adus.realm       = US.EXAMPLE.COM
asus.ldap.server = DC1.US.EXAMPLE.COM
…

A Windows統合認証(Kerberos)をサポートするためのEDQの構成

この付録では、KerberosおよびActive Directoryと連携するようにEDQを構成する方法について説明します。次の項で構成されています。

- ローカル・システム・アカウントを使用したWindowsサービスとしてのEDQの実行

- UNIXでのEDQの実行

- Kerberos共有ライブラリ

login.propertiesを使用したEDQとActive Directoryの統合(第5章「EDQでの外部ユーザー管理(LDAP)の直接構成」を参照)は、ユーザーがWindowsにログインすると、EDQに再度ログインする必要がなくなるシングル・サインオン(SSO)をサポートするように構成できます。これは、WebLogicとTomcatの両方でサポートされます。

SSOを有効にするには、EDQサーバーを設定して、クライアントPCからのKerberos認証を有効にする必要があります。この認証は、標準のGSSAPIトークン交換メカニズム(RFC 4121)を使用して実現します。クライアントは、ドメイン・コントローラ(DC)に接続して、サーバー・アプリケーションが提供するサービスに対するアクセスをリクエストします。DCからのレスポンスは、クライアントによってサーバーに送信されるトークンにエンコードされます。サーバーは、このトークンを検証し、クライアントに送信するための別のトークンを生成します。トークン交換は、クライアントとサーバーがセキュアなコンテキストを確立するまで継続できます。実際には、いずれの方向についても、この交換で2つ以上のトークンが必要になることはありません。

起動時に、サーバー・アプリケーションは、セキュリティ・コンテキストの半分を初期化するために使用する受入れ資格証明を設定します。

A.1 ローカル・システム・アカウントを使用したWindowsサービスとしてのEDQの実行

EDQアプリケーション・サーバーが、ローカル・システム・アカウントを使用してドメイン内のWindowsサーバーで実行されている場合、構成は非常に簡単になります。EDQは、受入れ資格証明を処理し、ユーザー・ルックアップでADに接続するために、システム・アカウントを使用します。

この構成のEXAMPLE.COMのlogin.propertiesは、次のとおりです。

# EXAMPLE.COM LDAP integration
# ----------------------------

realms                         = internal, ad
ldap.prof.useprimarygroup      = false
clientcreds                    = true

ad.realm                       = EXAMPLE.COM
ad.auth                        = ldap
ad.auth.bindmethod             = simple
ad.auth.binddn                 = search: dn

ad.ldap.profile                = adsldap
ad.ldap.prof.defaultusergroup  = edqusers
ad.ldap.prof.groupsearchfilter = (cn=edq*)

'clientcreds'設定は、Kerberos資格証明が現在のユーザーのキャッシュ(この場合はローカル・システム・アカウント)から取得されることを示します。これらの資格証明は、Active Directoryに接続し、受入れGSSAPIコンテキストを設定するために使用されます。

Active Directoryドメインのメンバーであるサーバーは、通常、DNSルックアップでドメイン・コントローラを使用します。この場合、EDQでは、自動的にLDAPサーバーのアドレスが決定されます。ドメイン・コントローラの一部が遠隔地に存在するなどの理由によりアドレスを固定する場合、次のようにldap.serverプロパティを使用します。

ad.ldap.server                 = dc1.example.com

A.2 UNIXでのEDQの実行

サーバーがUNIX上で実行されている場合、ADのアカウントを使用して受入れ資格証明を設定する必要があります。これは、Kerberosのキー表(keytab)から読み取られた暗号化アカウント・パスワードを使用して、リクエストを検証します。有効なキー表を設定することは、UNIXでSSOを構成するために不可欠な手順です。

A.2.1 keytabとは

Kerberosのキー表には、1つ以上のKerberosプリンシパルの暗号化パスワードが含まれます。DCでは、通常、異なる複数の暗号化アルゴリズム(DES3、AES、RC4など)がサポートされ、プリンシパルのエントリには、これらの各アルゴリズムの鍵が含まれます。クライアントは、DCとの通信に使用できる最適なアルゴリズムを選択します。

GSSAPIを使用してリクエストされるサービスは、サービス・プリンシパル名(SPN)によって識別されます。通常、これは、マシンのホスト名における特定のサービス・タイプに対する参照です。サービス・タイプの例は、HOST (sshなどの一般的なアクセスに対応)、HTTP (ブラウザからのSSOに対応)およびLDAP (ADドメイン・コントローラなどのLDAPサーバーに対応)です。SPNは、通常、次のように表示されます。

service/hostname

次に例を示します。

HOST/testserver.example.com

keytabの各エントリには、キー・バージョン番号(KVNO)も含まれます。このバージョン番号は、DCでプリンシパルのパスワードが変更されるたびに増分されます。認証が成功するには、keytabに正しいKVNOが含まれる必要があります。

ほとんどのUNIXシステムで、システムのKerberos keytabのデフォルトの場所は次のとおりです。

/etc/krb5.keytab

JavaのKerberos実装では、keytabのデフォルトの場所はないため、次のようにloign.propertiesで設定する必要があります。

keytab = path to keytab

絶対パスではない場合、これはlogin.propertiesを含むsecurityフォルダを基準とする相対パスです。

klistコマンドを使用すると、keytabの内容をリストできます。

klist –k [file]
klist –ke [file]
klist –keK [file]

keytabがデフォルトの場所にない場合、ファイル名を指定できます。最初の書式ではプリンシパルのみがリストされ、2番目の書式では暗号化アルゴリズムも追加され、3番目の書式では16進数でのキー値も追加されます。

次に、klist -keによる出力例を示します。

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
5 ALTAIR$@EXAMPLE.COM (des-cbc-crc)
5 ALTAIR$@EXAMPLE.COM (des-cbc-md5)
5 ALTAIR$@EXAMPLE.COM (des3-cbc-sha1)
5 ALTAIR$@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
5 ALTAIR$@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
5 ALTAIR$@EXAMPLE.COM (arcfour-hmac)
5 HOST/altair@EXAMPLE.COM (des-cbc-crc)
5 HOST/altair@EXAMPLE.COM (des-cbc-md5)
5 HOST/altair@EXAMPLE.COM (des3-cbc-sha1)
5 HOST/altair@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
5 HOST/altair@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
5 HOST/altair@EXAMPLE.COM (arcfour-hmac)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des-cbc-crc)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des-cbc-md5)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des3-cbc-sha1)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (arcfour-hmac)

標準のKerberosドメイン・コントローラ(KDC)を使用する通常のKerberosシステムでは、各SPNは、異なるパスワードを持つ個別のプリンシパルです。Active Directoryでは、SPNは、原則としてADのservicePrincipalName LDAP属性の値として格納される単一アカウントの別名です。ADでコンピュータ・アカウントが作成されると、HOSTサービスのSPNが自動的に作成されます。IISやSQLserverなどの追加サービスがサーバーにインストールされている場合、追加のSPNがアカウントに追加されます。

WindowsのsetspnコマンドをADサーバーで実行して、アカウントのSPNを管理できます。次に例を示します。

setspn -A HTTP/altair.example.com altair$

最初のコマンドでは、altairのマシン・アカウントにHTTP SPNを追加しています。(コンピュータのWindowsアカウント名は、常に$で終わります)。

A.2.2 既存のツールを使用したkeytabの作成

通常のKerberosシステムでは、Kerberos管理ツールkadminのktaddサブコマンドを使用してkeytabエントリを作成します。ADではKerberos管理サーバーが提供されないため、他のアプローチが必要です。

keytabには、アカウントの暗号化パスワードが含まれるため、メソッドごとにアカウントのパスワードを前もって把握しておくか、アカウント・パスワードを変更する権限とともにそれを実行する必要があります。

使用するメソッドは、システム構成によって異なります。既存のオプションには次のものがあります。

- Samba: システムがSambaスイートを使用するADに登録されている場合、net ads keytabコマンドを使用して、keytabを作成および更新できます。Sambaはアカウントのパスワードを設定してそれを秘密の場所に格納しているため、このような動作になります。

- ktpass: Windowsのktpassコマンドは、AD管理者がkeytabエントリを生成するために実行できます。他に代替方法がある場合は、このコマンドを使用しないでください。これは複雑で、信頼性を保証しながら使用することが非常に困難です。これにより、アカウントのパスワードが更新されるため、前のkeytabはすべて使用できなくなります。

- msktutil: これは、keytabの管理に使用できるUNIX用のオープン・ソース・アプリケーションです。

A.2.3 winktabを使用したkeytabの作成

winktabは、ADでアカウントのkeytabを作成するために使用できるJavaアプリケーションです。これは、ADに接続して、アカウントのKVNOを決定し、アカウントに関連付けられたSPNを決定します。これを管理者アカウントで実行すると、アカウント・パスワードをランダム値にリセットできます(または、アカウント・パスワードをコマンドに指定できます)。

winktabは、ADサーバーに接続可能な任意のシステムで実行できます。

マシン・アカウントのkeytabを作成してパスワードをランダム値にリセットするには、次のようにします。

java -jar stuff.jar winktab -o ktfile -domain DOMAIN -server adserver
-user aduser -pw adpw -tls machinename
To create a keytab for a machine account using a known password:
java -jar stuff.jar winktab -o ktfile -accpw accpw -domain DOMAIN -server adserver
-user aduser -pw adpw [-tls] machinename

パラメータは次のとおりです。

- ktfile: keytabはこのファイルに書き込まれます

- accpw: マシンまたはユーザー・アカウントのパスワード。単一ダッシュ(-)を使用すると、コマンドにより、echoなしでパスワードの入力を求められます

- DOMAIN: ADドメイン名

- adserver: ドメインのADサーバーのホスト名またはIPアドレス

- aduser、adpw: 問合せでサーバーへの接続に使用されるADアカウントのユーザー名とパスワード。ユーザー名の形式は次のとおりです。
user@DOMAIN

またはSHORTDOMAIN\user

パスワードとして単一ダッシュ(-)が指定されると、コマンドにより、echoなしでその入力を求められます。

アカウント・パスワードが固定(-setpwを使用)またはランダム(-setpwおよび-accpwを省略)に設定されている場合、ユーザーは管理者権限を持っている必要があります。

- machinename: コンピュータ・アカウントの名前。内部ADアカウント名は、machinename$です。内部ADアカウント名は、sAMAccountName LDAP属性に格納されます。
ADサーバーで認証接続が要求される場合、-tlsスイッチを使用します。アカウント・パスワードがリセットされる場合はWindowsで暗号化された接続が必要になるため、パスワードがランダム値または既知の値にリセットされる場合、-tlsを使用する必要があります。

次に、わかりやすく複数の行に分割したドメインEXAMPLE.COMの例を示します。

java -jar stuff.jar winktab -o altair.keytab -setpw altair \
-domain EXAMPLE.COM -server dc1.example.com \
-user "example\Admin" -tls altair

マシン・アカウントのkeytabを作成し、パスワードを既知の値に設定して、管理者パスワードの入力を求めます。

A.2.4 UNIX Kerberos構成の確認

kinitなどのコマンドやJavaランタイムで使用されるKerberos構成は、通常、/etc/krb5.confに格納されているグローバル構成ファイルから読み取られます。これには、ドメイン・コントローラに対する参照およびDNSとKerberosドメイン間のマッピングが含まれます。次に、ドメインEXAMPLE.COMの例を示します。

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes

[realms]
EXAMPLE.COM = {
kdc = dc1.example.com:88
}

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

[realms]セクションには、各ドメインのホストまたはIP別のKDCがリストされ、[domain_realm]セクションには、DNSホスト名とKerberosドメインのマッピングが含まれます。

krb5.confは、ターゲット・ドメインの構成に応じて確認および調整する必要があります。/etcのファイルを更新できない場合、ファイルを他の場所に格納し、システム・プロパティを通じてJavaランタイムにその場所を指示します。これを行うには、EDQローカル構成ディレクトリのjvm.propertieファイルを編集または作成し、次の行を追加します。

java.security.krb5.conf  = absolute path to modified krb5.conf

A.2.5 Java暗号化

デフォルトでは、Javaランタイム環境に強度の高い暗号のサポートは付属していません。たとえば、256ビットの鍵を持つAESはサポートされません。Active DirectoryおよびKerberosでは、暗号の完全なセットがサポートされ、キー表にはJavaでサポートされないエントリが含まれる可能性があります。この場合、現在の場所で可能であれば、JCE Unlimited Strength Jurisdiction Policy Filesをインストールする必要があります。

A.2.6 login.propertiesの変更

この例では、EDQを実行しているサーバーがaltair.example.comであるとします。

- グローバル設定:

realms                    = internal, ad
spn                       = HOST/altair.example.com@EXAMPLE.COM
keytab                    = /etc/krb5.keytab
ldap.prof.useprimarygroup = false

'spn'プロパティでは、GSSAPI受入れコンテキストで使用するサービス・プリンシパルを設定します。ここに示されている値はデフォルトで、UNIXサーバーのDNSドメインがADドメインと同じ場合は省略できます。UNIXサーバーが別個のDNSドメインに存在することがあり、その場合'spn'プロパティは必須です。

'keytab'プロパティでは、Kerberosのキー表の場所を設定します。Javaではデフォルトでこれが標準の場所に設定されないため、このプロパティは常に必須です。

- LDAPサーバー設定:

ad.ldap.server = dc1.example.com
ad.ldap.spn    = "ALTAIR$@EXAMPLE.COM"

Active Directoryへの接続に使用するサーバー名とKerberosプリンシパルを設定します。プリンシパルは、実際のマシン・アカウント名を含むキー表エントリである必要があります。前述のとおり、DNSから決定できる場合は、サーバーを省略できます。

- まとめると次のようになります。
これが、Active DirectoryとKerberos統合の例で使用される完全なlogin.propertiesです。

# EXAMPLE.COM LDAP integration with Kerberos

realms                         = internal, ad
spn                            = HOST/altair.example.com@EXAMPLE.COM
ldap.prof.useprimarygroup      = false
keytab                         = /etc/krb5.keytab

ad.realm                       = EXAMPLE.COM
ad.label                       = Example, Inc. Active directory
ad.ldap.server                 = dc1.example.com
ad.ldap.spn                    = "ALTAIR$@EXAMPLE.COM"
ad.ldap.security               = tls
ad.auth                        = ldap
ad.auth.bindmethod             = simple
ad.auth.binddn                 = search: dn

ad.ldap.profile                = adsldap
ad.ldap.prof.defaultusergroup  = edqusers

ad.ldap.prof.groupsearchfilter = (cn=edq*)

このlogin.propertiesが適切に配置されると、EXAMPLE.COMドメインのWindowsユーザーは、追加の資格証明を提供せずにEDQアプリケーションにログインできます。当然、ユーザーは、EDQでアプリケーションを使用するための権限を持っている必要があります。

A.3 Kerberos共有ライブラリ

Kerberos統合に必要な共有ライブラリ(wingss.dllおよびlibunuxgss.so)は、edq.warファイル内に含まれます。EDQは共有ライブラリの場所を判別して正しいバージョンを自動的にロードできるため、ほとんどのインストールではこれで十分です。

ただし、この自動ロードはすべてのJavaランタイム環境(JRE)で動作するわけではなく、特にIBM JREでは動作しません。このようなインストールでは、ライブラリを付属のkerberos-gss.zipファイルから抽出し、ディスク上の既知の場所にコピーする必要があります。さらに、JREで検出できるように、次の環境変数に場所を追加する必要があります。

- LD_LIBRARY_PATH (Linux、Solaris)

- LIBPATH (AIX)

- PATH (Windows)

EDQインストールに付属するnative/Kerberos-gss.zipアーカイブを調査して、それに次のファイルが含まれることを確認します。

- aix/ppc/libunixgss.a

- aix/ppc64/libunixgss.a

- linux/amd64/libunixgss.so

- linux/i386/libunixgss.so

- win32/amd64/wingss.dll

- win32/x86/wingss.dll

EDQサーバーが実行されているOSの関連ライブラリを抽出し、EDQを実行しているユーザーがアクセスできるディスク上の場所にそれをコピーします。この場所は、JREでライブラリを検出できるように、前述の環境変数に追加する必要があります。

B Oracle Access Manager (OAM)でのシングル・サインオンの構成

EDQがOracle Access Managerに統合されると、ユーザーは、共通のアクセス・ページにログインし、追加のログインなしでEDQアプリケーションおよびWebコンソールに自動的にアクセスできます(当然、ユーザーは必要なEDQ権限を持っていると仮定します)。同じOAM構成を使用する複数のEDQインストールがある場合、ログインはそれぞれに対して有効です。

この項では、EDQとOAMを統合する構成手順について説明します。ここでは、OAMのインストールおよび基本構成や、Web層フロントエンド(OHS)のインストールについては説明しません。この付録の内容は次のとおりです。

- 前提条件

- OAM構成

- WebLogicプラグイン構成

- WebLogic構成

B.1 前提条件

次に、OAMをインストールするための前提条件を示します。

- OAMは、WebLogicでサポートされるアイデンティティ・ストアを使用する認証スキームで構成する必要があります(通常は、LDAP - Active DirectoryまたはOracle Internet Directory)。

- WebLogicは、同じアイデンティティ・ストアを使用するEDQを認証するように構成する必要があります。第4章「WebLogicおよびOPSSを使用した外部ユーザー管理(LDAP)の統合」を参照してください。これは、OAMの統合手順に進む前に、EDQで構成およびテストする必要があります。

- Webサーバー・フロントエンド(OHSまたはApache)をインストールして、WebgateソフトウェアとWebLogicプラグイン(mod_wl_ohs)で構成する必要があります。これらは、OHS 12リリースにバンドルされています。

B.2 OAM構成

OAMを構成するには、次の手順を実行します。

1. WebLogicで構成されたアイデンティティ・ストアを参照する認証スキーマを使用して、OAMでWebgateを作成します。
Webgateで次のHTTPリソースを作成します。

表B-1 WebgateでのHTTPSリソースの作成

リソース

ポリシー

/edq/faces/**

保護対象リソース・ポリシー

/edq/blueprints/*/jnlp

保護対象リソース・ポリシー

/edq/**

パブリック・リソース・ポリシー(または除外)

2. WebgateアーティファクトをOHSインストールにコピーして、webgate/configディレクトリに配置します。

B.3 WebLogicプラグイン構成

WebLogicプラグイン(mod_wl_ohs)がWebサーバー・フロントエンドで構成されていることを確認します。このエントリをプラグイン構成ファイル(通常はmod_wl_ohs.conf)に追加します。

<Location /edq>
SetHandler weblogic-handler
WebLogicPort managed server port
WebLogicHost hostname
</Location>

WebLogicクラスタを使用している場合、ホストとポートの設定をクラスタ定義で置き換えます。

WebLogicCluster host1:port1, host2:port2, ...

EDQサーバーに対して「WebLogicプラグインの有効化」オプションが設定されていることを確認します。これは、ドメイン、クラスタ、サーバー・テンプレートまたはサーバーの各レベルで実行できます。ドメインの場合、このオプションは、「構成」の「Webアプリケーション」タブにあります。他のアイテムの場合、このオプションは、「一般構成」タブの「詳細」領域にあります。

B.4 WebLogic構成

WebLogicを構成するには、次の手順を実行します。

1. 管理コンソールにログインし、「セキュリティ・レルム」のmyrealmに移動します。

2. 「プロバイダ」タブをクリックします。

3. 「新規」をクリックして、新しいプロバイダを追加します。

4. OAMなどの名前を入力し、「OAMIdentityAsserter」を選択します。

5. 「OK」をクリックします。
構成されていない新しいプロバイダがリストの一番下に追加されます。

注意:
この段階で管理サーバーを再起動する必要はありません。

6. 新しいプロバイダをクリックします。「構成」画面で、制御フラグを「REQUIRED」に変更します。

7. 「保存」をクリックして「プロバイダ固有」タブを選択します。
OAMの構成情報を入力します。また、OAMがWebgateセキュリティなしで構成されている場合、「アクセス・ゲート名」および「プライマリ・アクセス・サーバー」を入力します。

このタブの情報は、OAM管理者によって提供されます。

8. 「保存」をクリックして「プロバイダ」リストに戻ります。
「並替え」ボタンを使用して、OAMプロバイダをリストの一番上に移動します。

9. 管理サーバーおよびEDQ管理対象サーバーを再起動します。これで、OAM統合が完了しました。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。