Oracle® Fusion Middleware

Oracle Virtual Directory管理者ガイド

11gリリース1(11.1.1)for Windows

B55922-09(原本部品番号:E54642-01)

2015年4月

エンタープライズ・ディレクトリ・インフラストラクチャでOracle Virtual Directoryを構成および使用し、ディレクトリ・データとディレクトリ・サービスを管理する方法について説明する、ネットワーク管理者およびアーキテクト向けのドキュメント。

Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド, 11gリリース1 (11.1.1) for Windows

B55922-09

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

原本主著者: K.C. Francis

原本協力者:  Guruprasad Bhupathi、Florence Blanc-Renaud、Joseph De Menditte、Krithiga Gopalan、Mohamad Raja Gani、Lakshmi Ramadoss、Etienne Remillon、Hitaisinee TanayaおよびSatishkumar Venkatasamy

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

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

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

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 11gリリース1 (11.1.1.9)の新機能と変更機能

- 11gリリース1 (11.1.1.7)の新機能と変更機能

- 11g リリース1 (11.1.1)に関するこのドキュメントにおけるその他の大きな変更

第I部 Oracle Virtual Directoryサービスの概要

1 Oracle Virtual Directoryの概要

- 1.1 Oracle Virtual Directoryとは

- 1.1.1 概要

- 1.1.2 特徴

- 1.1.3 機能

- 1.1.4 アーキテクチャおよびトポロジ

- 1.1.5 Oracle Fusion MiddlewareにおけるOracle Virtual Directoryの位置づけ

- 1.1.6 オラクル社のディレクトリ・サービスのポートフォリオ

- 1.2 企業ディレクトリでは不十分な理由

- 1.3 企業ディレクトリ・ネットワーク環境でのOracle Virtual Directory

- 1.3.1 仮想ネームスペース・マッピング

2 Oracle Virtual Directoryのアダプタの概要

- 2.1 アダプタとは

- 2.2 LDAPアダプタの概要

- 2.2.1 LDAPアダプタのデプロイ

- 2.2.2 LDAPアダプタの読取り、書込み、名前の変更および比較のサポート

- 2.2.3 アクセス制御とLDAPアダプタ

- 2.2.4 レスポンス制御とLDAPアダプタ

- 2.3 データベース・アダプタの概要

- 2.3.1 アクセス制御とデータベース・アダプタ

- 2.3.2 JDBC Javaクラス・ライブラリ

- 2.3.3 データベース・アダプタのマッピングの概要

- 2.4 ローカル・ストア・アダプタの概要

- 2.4.1 ローカル・ストア・アダプタのデータの移行

- 2.5 結合ビュー・アダプタの概要

- 2.5.1 一般的な結合ビュー・アダプタのデプロイ

- 2.5.2 結合関係

- 2.5.2.1 Simpleジョイナ

- 2.5.2.2 条件付きSimpleジョイナ

- 2.5.2.3 OneToManyジョイナ

- 2.5.2.4 Shadowジョイナ

- 2.5.2.5 カスタム結合

- 2.6 カスタム・アダプタの概要

- 2.7 アダプタによる仮想ディレクトリ作成の概要

- 2.7.1 基本的な仮想ディレクトリの例

- 2.7.2 結合ビュー・アダプタを使用する仮想ディレクトリの例

- 2.8 アダプタ・ネームスペースの概要

- 2.9 アダプタ・テンプレートの概要

- 2.9.1 デフォルト・テンプレート

- 2.9.2 LDAPアダプタ・テンプレート

- 2.9.2.1 Active_Directory

- 2.9.2.2 CA_eTrust

- 2.9.2.3 Changelog_LDAP-TYPE

- 2.9.2.4 EUS_ActiveDirectory

- 2.9.2.5 EUS_OID

- 2.9.2.6 EUS_Sun (ODSEE)

- 2.9.2.7 EUS_eDirectory

- 2.9.2.8 General_LDAP_Directory

- 2.9.2.9 IBM_Directory

- 2.9.2.10 Novell_eDirectory

- 2.9.2.11 マッパーを使用したOAM/ADアダプタ

- 2.9.2.12 SSLおよびマッパーを使用したOAM/ADアダプタ

- 2.9.2.13 スクリプトを使用したOAM/ADアダプタ

- 2.9.2.14 マッパーを使用したOAM/ADAMアダプタ

- 2.9.2.15 SSLおよびマッパーを使用したOAM/ADAMアダプタ

- 2.9.2.16 スクリプトを使用したOAM/ADAMアダプタ

- 2.9.2.17 マッパーを使用したOAM/SunOne (ODSEE)アダプタ

- 2.9.2.18 スクリプトを使用したOAM/SunOne (ODSEE)アダプタ

- 2.9.2.19 ONames_LDAP-TYPE

- 2.9.2.20 Oracle_Internet_Directory

- 2.9.2.21 Siemens_DirX

- 2.9.2.22 SunOne_Directory (ODSEE)

- 2.9.2.23 User_LDAP-TYPE

- 2.9.3 ローカル・ストア・アダプタ・テンプレート

- 2.9.3.1 Local_Storage_Adapter

- 2.9.4 データベース・アダプタ・テンプレート

- 2.9.4.1 スクリプトを使用したOAM/DBアダプタ

3 Oracle Virtual Directoryのルーティングの概要

- 3.1 ルーティングとは

- 3.2 ルーティング設定の概要

- 3.2.1 優先度

- 3.2.2 「含めるフィルタ」および「除外するフィルタ」

- 3.2.3 DN一致

- 3.2.4 レベル

- 3.2.5 「属性フロー」設定

- 3.2.5.1 取得可能な属性

- 3.2.5.2 取得不可能な属性

- 3.2.5.3 格納可能な属性

- 3.2.5.4 格納できない属性

- 3.2.6 可視性

- 3.2.7 バインド・サポート

- 3.2.8 重要性

- 3.2.9 ビュー

- 3.2.9.1 ビューの作成および構成

- 3.2.10 「バインドを含む」および「バインドの除外」

- 3.2.10.1 例1

- 3.2.10.2 例2

4 Oracle Virtual Directoryのプラグインの概要

- 4.1 プラグインとは

- 4.1.1 ネームスペースのフィルタ処理

- 4.2 汎用目的のプラグインの概要

- 4.2.1 FA UserRoleプラグイン

- 4.2.1.1 構成パラメータ

- 4.2.2 HideEntriesByFilterプラグイン

- 4.2.2.1 構成パラメータ

- 4.2.3 ChangeUserRDNプラグイン

- 4.2.3.1 構成パラメータ

- 4.2.4 UPNBindプラグイン

- 4.2.4.1 構成パラメータ

- 4.2.5 ForkJoinプラグイン

- 4.2.5.1 構成パラメータ

- 4.2.5.2 ForkJoinプラグイン・デプロイメントの例

- 4.2.6 VirtualMemberofプラグイン

- 4.2.6.1 構成パラメータ

- 4.2.7 VirtualAttributeプラグイン

- 4.2.7.1 構成パラメータ

- 4.2.7.2 VirtualAttributeプラグイン・デプロイメントの例

- 4.2.8 Dump Transactionsプラグイン

- 4.2.8.1 構成パラメータ

- 4.2.9 DynamicTreeプラグイン

- 4.2.9.1 構成パラメータ

- 4.2.10 DynamicEntryTreeプラグイン

- 4.2.10.1 構成パラメータ

- 4.2.11 FlatTreeプラグイン

- 4.2.11.1 構成パラメータ

- 4.2.12 DynamicGroupsプラグイン

- 4.2.12.1 グループ・メンバーシップのテスト

- 4.2.12.2 構成パラメータ

- 4.2.13 Cacheプラグイン

- 4.2.13.1 構成パラメータ

- 4.2.14 ObjectClass Mapperプラグイン

- 4.2.14.1 構成パラメータ

- 4.2.15 Sub-Treeプラグイン

- 4.2.15.1 構成パラメータ

- 4.2.16 Performance Monitorプラグイン

- 4.2.16.1 構成パラメータ

- 4.2.17 UniqueEntryプラグイン

- 4.2.17.1 構成パラメータ

- 4.2.18 アダプタ・プラグイン・バージョン・プラグイン

- 4.2.19 Proxy Authorization Supportプラグイン

- 4.2.19.1 構成パラメータ

- 4.2.20 UserManagementプラグイン

- 4.2.20.1 構成パラメータ

- 4.2.21 Changelogプラグイン

- 4.2.21.1 リリース11.1.1.4.0 Changelogプラグインのデプロイ

- 4.2.21.2 前のリリースからのChangelogプラグインのデプロイ

- 4.2.21.3 構成パラメータ

- 4.2.22 Consolidated Changelogプラグイン

- 4.2.22.1 構成パラメータ

- 4.2.23 GenericMapperプラグイン

- 4.2.23.1 構成パラメータ

- 4.2.24 CoordinatorAdapterプラグイン

- 4.2.24.1 構成パラメータ

- 4.2.25 DBPasswordプラグイン

- 4.2.25.1 構成パラメータ

- 4.2.26 DNTranslatorプラグイン

- 4.2.26.1 構成パラメータ

- 4.2.27 HideGroupsAndUsersプラグイン

- 4.2.27.1 構成パラメータ

- 4.2.28 SAML XASPプラグイン

- 4.2.28.1 制約

- 4.2.28.2 構成パラメータ

- 4.3 エンタープライズ・ユーザー・セキュリティ、Real Application SecurityおよびOracle Net Servicesプラグインの概要

- 4.3.1 EUSActiveDirectoryプラグイン

- 4.3.1.1 構成パラメータ

- 4.3.2 EUSiPlanetプラグイン

- 4.3.2.1 構成パラメータ

- 4.3.3 EUSOIDプラグイン

- 4.3.3.1 構成パラメータ

- 4.3.4 EUSeDirectoryプラグイン

- 4.3.4.1 構成パラメータ

- 4.3.5 EUSMemberDNMappingプラグイン

- 4.3.5.1 構成パラメータ

- 4.3.6 EUSLockoutプラグイン

- 4.3.6.1 構成パラメータ

- 4.3.7 ONamesプラグイン

- 4.3.7.1 構成パラメータ

- 4.3.8 SubschemaSubentryプラグイン

- 4.3.8.1 構成パラメータ

- 4.3.9 Real Application Securityプラグイン

- 4.3.9.1 構成パラメータ

- 4.4 Microsoft Active Directoryのプラグインの概要

- 4.4.1 ActiveDirectory Passwordプラグイン

- 4.4.1.1 構成パラメータ

- 4.4.2 Active Directory Ranged Attributesプラグイン

- 4.4.2.1 構成パラメータ

- 4.4.3 InetADプラグイン

- 4.4.3.1 構成パラメータ

- 4.5 Oracle Access Managerプラグインの概要

- 4.5.1 OAMPolicyControlプラグイン

- 4.5.1.1 構成パラメータ

5 Oracle Virtual Directoryのマッピングの概要

- 5.1 マッピングとは

- 5.1.1 マッピングおよびカスタム・プラグインを使用する理由

- 5.1.2 概要: マッピングのデプロイ

- 5.2 マッピング・テンプレートの概要

- 5.2.1 Active_Directory_to_inetOrg

- 5.2.2 Common_Name_to_Given_Name

- 5.2.3 ConditionalPublish

- 5.2.4 DB_Groups

- 5.2.5 Map_DB_Password

6 Oracle Virtual Directoryのセキュリティの概要

- 6.1 概要

- 6.2 Oracle Virtual Directoryの認証の概要

- 6.2.1 パススルー認証

- 6.2.2 プロキシ・アカウント認証

- 6.2.3 クライアント証明書の認証

- 6.3 Oracle Virtual Directoryのアクセス制御の概要

- 6.3.1 ソース・ディレクトリのアクセス制御

- 6.3.2 Oracle Virtual Directoryのアクセス制御

- 6.3.3 アクセス制御およびグループ

- 6.3.4 Oracle Virtual Directoryのアクセス制御コンポーネント

- 6.3.4.1 概要

- 6.3.4.2 アクセス制御の有効範囲

- 6.3.4.3 アクセス制御権

- 6.3.4.4 属性のアクセス制御

- 6.3.4.5 アクセス制御の権限

- 6.3.4.6 アクセス制御のサブジェクト

- 6.3.5 Oracle Virtual Directoryのアクセス制御リストの適用

- 6.4 ウォレットおよび証明書管理の概要

7 Oracle Virtual Directoryのフォルト・トレランスの概要

- 7.1 概要

- 7.2 DNSおよびネットワークのフェイルオーバー

- 7.3 Oracle Virtual Directoryのフェイルオーバー

- 7.3.1 ローカル・ストア・アダプタのフェイルオーバー

- 7.4 プロキシ・ソースのフェイルオーバー

第II部 基本的な管理

8 Oracle Virtual Directoryの管理の開始

- 8.1 11gリリース1(11.1.1)のインストール後の作業

- 8.2 Oracle Virtual Directoryの構成および管理の基本的なタスク

- 8.3 Oracle Directory Services Managerの開始

- 8.3.1 Oracle Directory Services Managerの概要

- 8.3.1.1 サポートされているブラウザ

- 8.3.1.2 Oracle Directory Services ManagerでのJAWSスクリーン・リーダーの使用

- 8.3.1.3 Oracle Directory Services Managerとシングル・サインオンの統合の概要

- 8.3.2 SSO統合の構成

- 8.3.3 Oracle Directory Services Managerの統合のためのSSOサーバーの構成

- 8.3.4 ODSM-SSO統合用のOracle HTTP Serverの構成

- 8.3.5 Oracle Directory Services Managerの起動

- 8.3.6 Oracle Directory Services Managerからサーバーへの接続

- 8.3.6.1 Oracle Directory Services Managerからディレクトリ・サーバーへのログイン

- 8.3.6.2 SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン

- 8.3.6.3 SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続

- 8.3.7 Oracle Directory Services Managerのキー・ストアの管理

- 8.3.7.1 Oracle Directory Services Managerのキー・ストアの概要

- 8.3.7.2 Oracle Directory Services ManagerのJavaキー・ストア・パスワードの取得

- 8.3.7.3 odsm.cer Javaキーストアの内容のリスト

- 8.3.7.4 期限が切れた証明書の管理

- 8.3.7.5 信頼できる証明書の削除

- 8.3.8 Oracle Directory Services Managerセッション・タイムアウトの構成

- 8.3.9 セッションのリセット

- 8.3.10 Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成

- 8.4 Fusion Middleware Controlの開始

- 8.4.1 Oracle Virtual Directory管理のためのFusion Middleware Controlの起動

- 8.4.2 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動

- 8.4.3 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止

- 8.4.4 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの再起動

- 8.4.5 Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryの監視

- 8.5 WLSTを使用したOracle Virtual Directoryの管理の開始

- 8.6 LDAPツールの使用

9 Oracle Virtual Directoryサーバーの構成と管理

- 9.1 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーのプロパティの構成

- 9.2 Oracle Directory Services Managerを使用したOracle Virtual Directoryサーバーの設定の構成

- 9.3 WLSTを使用したOracle Virtual Directoryサーバーの設定の構成

- 9.4 Oracle Virtual Directoryサーバーに割り当てる最大ヒープ・サイズの制御

- 9.5 リモート・クライアントまたはサーバー障害が原因の孤立した接続の制御

- 9.6 Oracle Directory Services Managerを使用したOracle Virtual Directoryライブラリの管理

- 9.6.1 Oracle Virtual Directoryサーバーのライブラリの表示

- 9.6.2 Oracle Virtual Directoryサーバーへのライブラリのロード

- 9.7 syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー

- 9.7.1 オプション

- 9.7.2 例

10 Oracle Virtual Directoryサーバー・プロセスの管理

- 10.1 Oracle Process Manager and Notification Serverとは

- 10.2 デフォルトOracle Virtual Directoryイメージの概要

- 10.3 OPMNCTLを使用したOracle Virtual Directoryコンポーネントの作成

- 10.4 OPMNCTLを使用したOracleインスタンスの登録

- 10.5 OPMNCTLを使用したOracleインスタンスの登録解除

- 10.6 OPMNCTLを使用したOracleインスタンスのコンポーネント登録の更新

- 10.7 OPMNCTLを使用したOracle Virtual Directoryコンポーネントの削除

- 10.8 OPMNCTLを使用したアクティブなサーバー・インスタンス情報の表示

- 10.9 OPMNCTLを使用したOracle Virtual Directoryサーバーの起動

- 10.10 OPMNCTLを使用したOracle Virtual Directoryサーバーの停止

- 10.11 OPMNCTLを使用したOracle Virtual Directoryサーバーの再起動

11 Oracle Virtual Directoryリスナーの作成および管理

- 11.1 リスナーとは

- 11.2 デフォルトOracle Virtual Directoryリスナーの概要

- 11.2.1 Oracle Virtual DirectoryとFusion Middleware Controlとの間の通信の管理

- 11.3 権限ポートでリスニングするためのOracle Virtual Directoryの構成

- 11.4 Fusion Middleware Controlを使用したリスナーの作成および管理

- 11.4.1 LDAPリスナーの作成

- 11.4.2 HTTPリスナーの作成

- 11.4.3 Oracle Virtual DirectoryのTLSリスナーの構成

- 11.4.4 リスナーの管理

- 11.4.4.1 リスナー設定の編集

- 11.4.4.2 リスナーの削除

- 11.5 WLSTを使用したリスナーの管理

- 11.5.1 リスナー設定の更新

- 11.5.1.1 WLSTを使用した管理リスナーの設定の構成

- 11.5.1.2 WLSTを使用したLDAPリスナーの設定の構成

- 11.5.1.3 WLSTを使用したHTTPリスナーの設定の構成

- 11.5.2 リスナーの削除

- 11.6 SSLを使用したリスナーの保護

- 11.6.1 始める前に

- 11.6.2 Fusion Middleware Controlを使用したリスナーでのSSLの構成

- 11.6.3 WLSTを使用したリスナーでのSSLの構成

- 11.6.4 SSL接続の検証

- 11.6.4.1 SSL認証なしモード

- 11.6.4.2 SSLサーバー認証モード

- 11.6.4.3 SSL相互認証モード

- 11.6.5 SSL再ネゴシエーションの制御

12 Oracle Virtual Directoryのアダプタの作成および構成

- 12.1 LDAPアダプタの作成

- 12.1.1 Oracle Unified Directory向けのアダプタの作成

- 12.1.2 LDAPアダプタの構成

- 12.1.2.1 LDAPアダプタの一般設定の構成

- 12.1.2.2 アダプタのルーティングの構成

- 12.1.2.3 アダプタ・プラグインおよびマッピングの構成

- 12.1.2.4 SSLで保護されているLDAPアダプタの認証局の管理

- 12.1.3 Oracle Virtual DirectoryとOracle Internet Directoryとの間の相互認証SSL接続の構成

- 12.2 データベース・アダプタの作成

- 12.2.1 Oracle RACデータベース用のデータベース・アダプタの作成

- 12.2.2 Oracle TimesTen In-Memory Database用のデータベース・アダプタの作成

- 12.2.3 データベース・アダプタの構成

- 12.2.3.1 データベース・アダプタの一般設定の構成

- 12.2.3.2 アダプタのルーティングの構成

- 12.2.3.3 アダプタ・プラグインおよびマッピングの構成

- 12.3 ローカル・ストア・アダプタの作成

- 12.3.1 ローカル・ストア・アダプタの構成

- 12.3.1.1 ローカル・ストア・アダプタの一般設定の構成

- 12.3.1.2 アダプタのルーティングの構成

- 12.3.1.3 アダプタ・プラグインおよびマッピングの構成

- 12.4 結合ビュー・アダプタの作成

- 12.4.1 結合ビュー・アダプタの構成

- 12.4.1.1 結合ビュー・アダプタの一般設定および結合ルールの構成

- 12.4.1.2 アダプタのルーティングの構成

- 12.4.1.3 アダプタ・プラグインおよびマッピングの構成

- 12.4.2 Oracle Internet Directory用のShadow結合ビュー・アダプタの構成

13 Oracle Virtual Directoryのプラグインの管理

- 13.1 アダプタ・プラグインの管理

- 13.1.1 アダプタ・プラグインの作成

- 13.1.2 特定の操作に対してのみ実行するためのアダプタ・プラグインの構成

- 13.1.3 アダプタ・プラグインの編集

- 13.1.4 アダプタ・プラグインの削除

- 13.2 グローバル・サーバー・プラグインの管理

- 13.2.1 グローバル・サーバー・プラグインの作成

- 13.2.2 デプロイされたグローバル・サーバー・プラグインの表示

- 13.2.3 グローバル・サーバー・プラグインの編集

- 13.2.4 グローバル・サーバー・プラグインの削除

14 Oracle Virtual Directoryのマッピングの管理

- 14.1 マッピング・テンプレートを使用したマッピングの作成

- 14.1.1 デプロイされたマッピングの表示

- 14.2 サーバー・マッピングの作成およびアクティブ化

- 14.2.1 アクティブ化されたサーバー・マッピングの表示

- 14.3 アダプタへのマッピングの適用

15 Oracle Virtual Directoryのエントリおよびスキーマの管理

- 15.1 データ・ブラウザを使用したOracle Virtual Directoryエントリの管理

- 15.1.1 Oracle Virtual Directoryのデータ・ブラウザの概要

- 15.1.2 クライアント・ビュー・データ・ブラウザを使用したOracle Virtual Directoryエントリの管理

- 15.1.2.1 仮想ディレクトリ・ツリーの検索

- 15.1.2.2 Oracle Virtual Directoryエントリの表示

- 15.1.2.3 仮想ディレクトリ・ツリー・エントリの属性の変更

- 15.1.2.4 ユーザー・アカウントのロック解除

- 15.1.2.5 LDIFファイルのインポート

- 15.1.2.6 LDIFファイルのエクスポート

- 15.1.3 アダプタ・ブラウザを使用したOracle Virtual Directoryソース・エントリの管理

- 15.1.3.1 ソース・リポジトリ・エントリの表示

- 15.1.3.2 Oracle Virtual Directoryにおけるソース・リポジトリ・エントリの属性の変更

- 15.2 Oracle Directory Services Managerを使用したOracle Virtual Directoryスキーマの管理

- 15.2.1 Oracle Virtual Directoryのスキーマ属性の管理

- 15.2.1.1 スキーマ属性の検索

- 15.2.1.2 新しいスキーマ属性の作成

- 15.2.1.3 類似のスキーマ属性の作成

- 15.2.1.4 スキーマ属性の変更

- 15.2.1.5 スキーマ属性の削除

- 15.2.2 Oracle Virtual Directoryのスキーマ・オブジェクト・クラスの管理

- 15.2.2.1 スキーマ・オブジェクト・クラスの検索

- 15.2.2.2 新しいスキーマ・オブジェクト・クラスの作成

- 15.2.2.3 類似のスキーマ・オブジェクト・クラスの作成

- 15.2.2.4 スキーマ・オブジェクト・クラスの変更

- 15.2.2.5 スキーマ・オブジェクト・クラスの削除

16 Oracle Virtual Directoryのアクセス制御の構成

- 16.1 Oracle Directory Services Managerを使用したアクセス制御リストの作成

- 16.2 Oracle Directory Services Managerを使用したアクセス制御リストの管理

- 16.2.1 アクセス制御リストの更新

- 16.2.2 アクセス制御リスト・エントリの削除

17 Oracle Virtual Directoryのロギングと監査の管理

- 17.1 Oracle Virtual Directoryのロギングの管理

- 17.1.1 Oracle Enterprise Managerを使用したOracle Virtual Directoryのロギングの管理

- 17.1.2 WLSTを使用したOracle Virtual Directoryのロギングの管理

- 17.1.3 粒度の細かいロギングの管理

- 17.2 Oracle Virtual Directoryの監査の管理

- 17.2.1 Fusion Middleware Controlを使用したOracle Virtual Directoryの監査の管理

- 17.2.2 WLSTを使用したOracle Virtual Directoryの監査の管理

- 17.2.3 監査データの概要

- 17.2.3.1 IPアドレスの記録

- 17.2.3.2 監査構成管理クラス

- 17.2.3.3 監査メッセージの確認

第III部 高度な管理

18 Oracle Virtual Directoryのカスタマイズ

- 18.1 Oracle Directory Services Managerへのローカライズされた言語の設定

- 18.2 カスタム・アダプタの作成および構成

- 18.2.1 カスタム・アダプタの作成

- 18.2.2 カスタム・アダプタの構成

- 18.2.2.1 カスタム・アダプタの一般設定の構成

- 18.2.2.2 アダプタのルーティングの構成

- 18.2.2.3 アダプタ・プラグインおよびマッピングの構成

- 18.3 カスタムJavaプラグインの開発

- 18.3.1 概要

- 18.3.2 チェーン・システムの概要

- 18.3.3 プラグインの実装ポイント

- 18.3.3.1 構成、開始および停止のプラグインの実装ポイント

- 18.3.3.2 可用性のプラグインの実装ポイント

- 18.3.3.3 操作のプラグインの実装ポイント

- 18.3.4 EntrySetの作成

- 18.3.4.1 ExtensibleEntrySet

- 18.3.4.2 カスタムEntrySet

- 18.3.5 フィルタ処理の概要

- 18.3.6 クラスの概要

- 18.3.6.1 仮想サービス・インタフェース

- 18.3.6.2 グローバル・サービス・インタフェース

- 18.3.6.3 アダプタ・サービス・インタフェース

- 18.3.6.4 ジョイナ

- 18.3.6.5 ユーティリティ・クラス

- 18.3.6.6 データ・クラス

- 18.3.6.7 データ型

- 18.3.6.8 例外

- 18.4 Oracle Virtual DirectoryへのWebサービス・クライアントの接続

19 統合ディレクトリ・ソリューションに対するOracle Virtual Directoryの構成

- 19.1 Oracle Access Managerに対するOracle Virtual Directoryの構成

- 19.1.1 Oracle Access Managerのアダプタ設定の変更

- 19.2 Oracleのエンタープライズ・ユーザー・セキュリティとの統合

- 19.2.1 エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備

- 19.2.2 エンタープライズ・ユーザー・セキュリティのアダプタの構成

- 19.2.3 外部ディレクトリとOracle Virtual Directoryとの統合

- 19.2.3.1 Microsoft Active DirectoryのユーザーID

- 19.2.3.2 Microsoft Active DirectoryのユーザーIDおよびOracle Internet Directoryのメタデータ

- 19.2.3.3 Oracle Directory Server Enterprise EditionのユーザーID

- 19.2.3.4 Novell eDirectoryのユーザーID

- 19.2.3.5 Oracle Internet DirectoryのユーザーID

- 19.2.4 エンタープライズ・ユーザー・セキュリティとの統合のためのアクセス制御リストの構成

- 19.2.5 複数のエンタープライズ・ユーザー・セキュリティ・ドメインをサポートするためのOracle Virtual Directoryの構成

- 19.2.6 ユーザー・アカウントのロックアウトの有効化

- 19.2.7 統合の制限事項

- 19.3 Oracleのネット・サービスとの統合

- 19.3.1 概要

- 19.3.2 統合の開始

- 19.3.3 Microsoft Active Directoryとともに使用するための統合

- 19.3.3.1 Active Directoryの統合構成

- 19.3.3.2 Oracle Virtual Directoryの統合構成

- 19.3.4 Oracle Directory Server Enterprise Editionとともに使用するための統合

- 19.3.4.1 Oracle Directory Server Enterprise Editionの統合構成

- 19.3.4.2 Oracle Virtual Directoryの統合構成

- 19.3.5 Oracle Internet Directoryとともに使用するための統合

- 19.4 OracleのReal Application Securityとの統合

- 19.4.1 作業の前に

- 19.4.2 Real Application Securityとの統合のためのOracle Virtual Directoryの準備

- 19.4.3 Real Application Security (RAS)のLDAPアダプタの構成

- 19.4.4 RAS DBルートDN検出の有効化

- 19.4.5 外部ディレクトリとOracle Virtual Directoryとの統合

- 19.4.5.1 Active Directoryの統合構成

- 19.4.5.2 Novell eDirectoryの統合構成

- 19.4.5.3 Oracle Internet Directoryの統合構成

- 19.4.5.4 Oracle Directory Services Managerの統合構成

- 19.4.6 Real Application Security統合のためのアクセス制御リストの構成

- 19.4.7 複数のアイデンティティ・ストアをサポートするためにOracle Virtual Directoryを構成

- 19.4.8 ユーザー・アカウントのロックアウトを使用した作業

20 Oracle Communications Universal User Profile

- 20.1 Oracle Communications Universal User Profileとは

- 20.2 Oracle Communications Universal User Profileのユースケースの例およびデプロイ・シナリオ

- 20.3 Oracle Communications Universal User ProfileのDiameterアダプタ

- 20.3.1 Diameterアダプタのサポートの有効化

- 20.3.2 Diameterアダプタの作成および構成

- 20.3.2.1 SCTPトランスポートの有効化

- 20.4 LDAPスキーマへのIMS 3GPPスキーマのマッピング

第IV部 付録

A Oracle Virtual Directory 11gリリース1(11.1.1)と10gリリース(10.1.4.x)の比較

- A.1 デフォルト・スーパー・ユーザー

- A.2 プロセス管理

- A.3 構成ファイルの場所

- A.4 プラグイン・ファイルの場所

- A.5 デプロイされたマッピング・ファイルの場所

- A.6 ログ・ファイルの場所

- A.7 ローカル・ストア・アダプタのデータ・ストアの場所

- A.8 スキーマ・ファイルの場所

- A.9 Oracle Virtual Directoryサーバーのライブラリの場所

- A.10 Oracle Virtual Directoryサーバーのデバッグの有効化

- A.11 グラフィカル・ユーザー・インタフェース

- A.12 コマンドライン・ツール

- A.13 クラスパスの更新

- A.14 2つのOracle Virtual Directoryコンポーネントの同期化

- A.15 監査の構成

- A.16 監査ログの場所

- A.17 サポートされているカスタマイズ

B Oracleスタックの起動と停止

- B.1 スタックの起動

- B.2 スタックの停止

C HTTPリスナーのWebゲートウェイ・サービス

- C.1 Webゲートウェイの機能と特徴

- C.2 デモンストレーション・ディレクトリ・ブラウザ

- C.3 Webゲートウェイのアーキテクチャ

- C.3.1 DSMLサーブレット

- C.3.2 XSLTサーブレット

- C.3.3 ハンドラ

- C.4 DSMLおよびXSLT LDAPの問合せパラメータ

- C.5 Webゲートウェイ・コマンド

- C.5.1 バイナリ属性の取得コマンド

- C.5.2 フォームベースの検索コマンド

- C.5.3 フォームベースのエントリ操作コマンド

- C.5.4 HTTP POST

- C.5.5 HTTP GET

- C.6 セキュリティ・コンテキスト

- C.6.1 .htaccessファイルの要件

- C.6.2 .htaccessファイルのディレクティブ

- C.6.3 リソースの制限

- C.6.4 セキュリティ・コンテキスト・ファイルの例

- C.7 XSLスタイルシートの使用方法

- C.7.1 動的グループを作成するためのXSLTサーブレット問合せの使用

- C.7.2 メディア・タイプ属性に基づいたコンテンツ・タイプ・サーブレットの設定

- C.7.3 XSLのDocument()コマンドおよびImport/Includeコマンドのサポート

- C.7.4 XSLスタイルシートへのパラメータの受渡し

- C.7.5 XSLの例

D Oracle Virtual Directoryのトラブルシューティング

- D.1 問題と解決策

- D.1.1 Oracle Directory Services Managerを起動できない

- D.1.2 Internet Explorer 7を使用してアクセシビリティ・モードでOracle Directory Services Managerにアクセスするときにカーソルに問題がある

- D.1.3 Oracle HTTP Serverを使用したOracle Directory Services Managerのフェイルオーバーが透過的に行われない

- D.1.4 Oracle Directory Services ManagerがOracle Virtual Directory-Oracle RACデータベース構成に接続できなくなる

- D.1.5 LDAPアダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

- D.1.6 データベース・アダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

- D.1.7 Oracle Virtual DirectoryへのOPMN pingが失敗する

- D.2 Oracle Virtual Directoryの問題の診断

- D.2.1 ログ・レベルのDEBUGへの引上げ

- D.2.2 Oracle Directory Services Managerを介したOracle Virtual Directoryとの接続の問題

- D.2.3 診断ログに記録された例外の調査

- D.2.4 Dump Transactionsプラグインを使用したデータ・トランザクション・エラーに関する情報の収集

- D.2.5 本番環境における問題のトラブルシューティング

- D.2.6 Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryサーバーの監視

- D.3 追加情報

索引

例一覧

- 4-1 Dynamic Groupsプラグインが有効化されていない場合の問合せの例

- 4-2 Dynamic Groupsプラグインが有効化されている場合の問合せの例

- 4-3 Oracle Virtual Directoryを使用しているリモートLDAPサーバー上のLDAPエントリ

- 4-4 uniqueMemberの値とともに戻されるLDAPエントリ

- 4-5 Dynamic Groupsプラグインを使用したメンバーシップ・テストの例

- 4-6 Performance Monitorプラグインを使用して戻されるデータの例

- 4-7 lastChangeNumber問合せによって戻されるエントリの例

- 10-1 opmnctl createcomponentコマンド

- 11-1 file.propファイルのサンプル

- 12-1 UNIX/LinuxでのOracle TimesTenライブラリの場所の設定

- 12-2 Oracle TimesTen JDBCドライバの場所のクラスパスへの追加

- 18-1 サンプルのinitメソッド

- 18-2 ignoreOnModifyオプションの有無を確認するサンプルのメソッド

- 18-3 バインド操作の実装の例

- 18-4 サンプルのmodifyメソッド

- 18-5 ExtensibleEntrySetを使用したEntrySet作成の例

- 18-6 カスタムのEntrySetへの引渡しを行うサンプルのgetメソッド

- 18-7 カスタムのEntrySetに渡されるデータの例

- 18-8 LDAPの前置記法をSQLの表記法に変換するためのサンプルのソース・コード

- C-1 .htaccessファイルの例

- C-2 htpasswdファイルの例

- C-3 htgroupファイルの例

- C-4 XSLの例

図一覧

- 1-1 Oracle Virtual Directoryのクライアントおよび接続可能なデータ・ストア

- 1-2 異なるユーザー・グループのディレクトリの仮想化

- 1-3 Oracle Virtual Directoryのアーキテクチャ

- 1-4 分散したディレクトリ・サービス

- 1-5 サービスクラスのレプリカの索引付けの例

- 1-6 UIDに関するアプリケーション検索をルーティングするOracle Virtual Directoryの例

- 1-7 接続の確立により減少するスループット

- 1-8 組織単位に基づくトラフィックのルーティングの例

- 1-9 平面的な階層における解析の例

- 1-10 Oracle Virtual Directoryのロード・バランシングの例

- 1-11 企業ディレクトリ・ネットワーク環境でのOracle Virtual Directory

- 1-12 アプリケーション固有のローカル・ディレクトリ・ブランチの例

- 1-13 ディレクトリ・マッピングの例

- 2-1 認証用のSimple結合の例

- 2-2 OneToMany結合の例

- 2-3 アプリケーション固有データをローカルに格納するためのShadow結合の使用例

- 2-4 仮想ディレクトリ構造の例

- 2-5 サンプルの仮想ディレクトリに構成されたアダプタ

- 2-6 同じユーザー・グループのディレクトリの仮想化

- 2-7 結合間の一意の基準の指定

- 2-8 個別ディレクトリが4つあるソース・ディレクトリ・ツリー構造の例

- 2-9 2つの子が追加されたソース・ディレクトリ・ツリー構造の例

- 2-10 再設計されたソース・ディレクトリ・ツリーの例

- 2-11 オーバーラップするディレクトリ構造の例

- 3-1 仮想ディレクトリ構造の例

- 3-2 フィルタを使用したアダプタ検索の例

- 4-1 Oracle Virtual Directoryのプラグイン・フレームワーク

- 4-2 ソース・ディレクトリのディレクトリ構造の例

- 4-3 DynamicTreeプラグインを使用したOracle Virtual Directoryのディレクトリ構造

- 4-4 ソース・ディレクトリのディレクトリ構造の例

- 4-5 DynamicTreeプラグインを使用したOracle Virtual Directoryのディレクトリ構造

- 5-1 単一のアダプタおよび複数のアダプタにおけるマッピング・デプロイの例

- 6-1 Oracle Virtual Directoryの複数層のアクセス制御および認証

- 6-2 Oracle Virtual Directoryのアクセス制御の有効範囲

- 6-3 Oracle Virtual DirectoryのACLサブジェクト

- 7-1 Oracle Virtual DirectoryのLDAPアダプタとトランザクション・ロード・バランシング

- 8-1 getPortableCredential操作

- 8-2 getPortableCredential操作

- 18-1 サンプルのLDAPフィルタの図

- 18-2 フィルタのオブジェクト・モデルの例

- 18-3 OR機能の分割

表一覧

- 2-1 Changelogアダプタ・テンプレート

- 8-1 管理インタフェースのデフォルトURL

- 8-2 デフォルト・ポート

- 8-3 環境変数

- 8-4 「ホーム」ページで確認できるメトリック

- 9-1 ODSMにおける設定構成パラメータのグループ

- 9-2 ODSMにおける割当構成パラメータのグループ

- 9-3 ODSMにおけるアダプタSSL設定構成パラメータのグループ

- 9-4 Oracle Virtual Directoryサーバー構成MBeanの属性

- 11-1 LDAPリスナー構成パラメータ

- 11-2 HTTPリスナー構成パラメータ

- 11-3 LDAP匿名認証オプション

- 12-1 アダプタ・テンプレート

- 12-2 krb5.confファイルのプロパティ

- 18-1 プラグインの実装ポイント

- 19-1 LDAPアダプタのパラメータ

- 20-1 DataReference型の結果値

- 20-2 DataReference型の結果値

- D-1 Fusion Middleware Controlの「パフォーマンス・サマリー」ページのOVDのメトリック

はじめに

この『Oracle Virtual Directory管理者ガイド』には、企業ディレクトリ・インフラストラクチャにおけるOracle Virtual Directoryの使用および管理方法に関する情報が記載されています。

対象読者

『Oracle Virtual Directory管理者ガイド』は、Oracle Virtual Directory管理者およびディレクトリ・インフラストラクチャを計画しているネットワーク・アーキテクトを対象としています。このドキュメントのコマンドライン構文と例を理解するには、UNIXオペレーティング・システムまたはMicrosoft Windowsオペレーティング・システムをよく理解している必要があります。また、Lightweight Directory Access Protocol(LDAP)にも精通している必要があります。

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

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

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、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 (聴覚障害者向け)を参照してください。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

Oracleカスタマは、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 Identity Management 11gリリース1(11.1.1)のドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Fusion Middleware Identity Managementリリース・ノート

- Oracle Platform Security Servicesによるアプリケーションの保護

- Oracle Fusion Middlewareの管理

- Oracle Platform Security Servicesによるアプリケーションの保護

- Oracle Fusion Middlewareの概念の理解

- 高可用性ガイド

- Oracle HTTP Serverの管理

- Oracle Internet Directory管理者ガイド

- 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』

- Oracle Internet Directory管理者ガイド

- Oracle Platform Security Services MBeans Java APIリファレンス

- WebLogic Scripting Toolの理解

- WebLogic Scripting Toolコマンド・リファレンス

- Oracle WebLogic Serverの理解

- 『Oracle Process Manager and Notification Server管理者ガイド』

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

このガイドで説明する新機能

この項では、Oracle Fusion Middleware 11gリリース1 (11.1.1)におけるOracle Virtual Directoryの新機能と製品の重要な変更点の概要を示します。

内容は次のとおりです。

- 11gリリース1 (11.1.1.9)の新機能と変更機能

- 11gリリース1 (11.1.1.7)の新機能と変更機能

- 11g リリース1 (11.1.1)に関するこのドキュメントにおけるその他の大きな変更

機能とその使用方法の詳細は、このガイドの参照先を確認してください。

11gリリース1 (11.1.1.9)の新機能と変更機能

Oracle Virtual Directory 11gリリース1 (11.1.1.9)には、次の新しい管理機能が含まれます。

- SAML XASPプラグインは、Oracle Virtual DirectoryがSAML X.509属性共有プロファイルを使用してSAMLアイデンティティ・プロバイダから属性を取得できるようにします。
詳細は、第4.2.28項「SAML XASPプラグイン」を参照してください。

11gリリース1 (11.1.1.7)の新機能と変更機能

Oracle Virtual Directory 11gリリース1 (11.1.1.7)には、このドキュメントで次の新しい管理機能と変更された管理機能が含まれます。

- Oracle Directory Services Managerの新しいReal Application Securityアダプタ構成ウィザードにより、Real Application Security (RAS)統合のためのOracle Virtual Directoryの構成が簡素化されました。
詳細は、第19章「統合ディレクトリ・ソリューションに対するOracle Virtual Directoryの構成」を参照してください。

- Oracle Virtual Directoryは、バックエンドのLDAPサーバーのパスワード・ロックアウト・ポリシーを強化するOracle Virtual DirectoryとReal Application Securityの統合のユーザー・アカウントのロックアウト機能をサポートします。
詳細は、第19章「統合ディレクトリ・ソリューションに対するOracle Virtual Directoryの構成」を参照してください。

- VDEが追加および変更操作を特定のアダプタにリダイレクトできるようにする新しいReal Application Security (RAS)プラグイン。
詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。

- 動的フィルタおよび向上した問合せ機能のサポートを組み込むための拡張されたHideEntriesByFilterプラグイン。
詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。

- DBPasswordプラグインが追加設定なしで利用可能になり、標準的なMD2、MD5、SHA-1、SHA-256、SHA-384、SSHAおよびSHA-512のハッシュ・アルゴリズムを使用して暗号化されたパスワードをサポートします。
詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。

- Oracle Virtual DirectoryはLDAP RFC 3673をサポートします。
属性説明の「+」が属性の検索リクエストのリストに存在する場合、それはすべての操作上の属性の返還のリクエストを意味します。

- いくつかの新しい構成パラメータが、DynamicGroupsプラグインで公開されています。
詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。

11g リリース1 (11.1.1)に関するこのドキュメントにおけるその他の大きな変更

このガイドは11g リリース1 (11.1.1)でいくつかの点が更新されました。次の表に、追加または変更された項を示します。

- Oracle Virtual DirectoryリスナーにSSLを構成する前の証明書の作成に関する情報が追加されました。11.6.1項「始める前に」を参照してください。

- 第6.2項「Oracle Virtual Directoryの認証の概要」から、CRAM-MD5およびSASLバインディングに関する項が削除されました。

- 256ビット暗号用のより強力なJava Cryptography Extension (JCE)ポリシー・ファイルのインストールに関する情報が追加されました。第11.6項「SSLを使用したリスナーの保護」を参照してください。

- Oracle Unified Directoryアダプタの作成に関する情報が追加されました。第12.1.1項「Oracle Unified Directory向けのアダプタの作成」を参照してください。

- 例18-8「LDAPの前置記法をSQLの表記法に変換するためのサンプルのソース・コードシステム」が修正されました。

- 12.1.2.1項「LDAPアダプタの一般設定の構成」の「フェールオーバー・モード」項が修正されました。

- ODSMでデフォルト・セッション・タイムアウトを変更する手順が追加されました。詳細は、8.3.8項「Oracle Directory Services Managerセッション・タイムアウトの構成」を参照してください。

第I部

Oracle Virtual Directoryサービスの概要

ここでは、Oracle Virtual Directoryの概要を説明します。内容は次のとおりです。

- 第1章「Oracle Virtual Directoryの概要」

- 第2章「Oracle Virtual Directoryのアダプタの概要」

- 第3章「Oracle Virtual Directoryのルーティングの概要」

- 第4章「Oracle Virtual Directoryのプラグインの概要」

- 第5章「Oracle Virtual Directoryのマッピングの概要」

- 第6章「Oracle Virtual Directoryのセキュリティの概要」

- 第7章「Oracle Virtual Directoryのフォルト・トレランスの概要」

1 Oracle Virtual Directoryの概要

この章では、Oracle Virtual Directory、そのサービスおよびアーキテクチャについて説明します。この章の内容は次のとおりです。

- 第1.1項「Oracle Virtual Directoryとは」

- 第1.2項「企業ディレクトリでは不十分な理由」

- 第1.3項「企業ディレクトリ・ネットワーク環境でのOracle Virtual Directory」

1.1 Oracle Virtual Directoryとは

この項では、Oracle Virtual Directoryについて説明します。この項の内容は次のとおりです。

- 概要

- 特徴

- 機能

- アーキテクチャおよびトポロジ

- Oracle Fusion MiddlewareにおけるOracle Virtual Directoryの位置づけ

- オラクル社のディレクトリ・サービスのポートフォリオ

1.1.1 概要

Oracle Virtual Directoryにようこそ。これは、1つ以上のエンタープライズ・データソースを単一のディレクトリに仮想化して抽象的に表示するLDAPバージョン3対応のサービスです。Oracle Virtual Directoryでは、インフラストラクチャまたはアプリケーションを変更することなく、またはその必要性を最小限に抑えながら、LDAP対応のアプリケーションを様々なディレクトリ環境に統合できます。図1-1に示すように、Oracle Virtual DirectoryはWebアプリケーションやポータルなど、一連の各種クライアントをサポートし、ディレクトリ、データベース、およびWebサービスに接続できます。

図1-1 Oracle Virtual Directoryのクライアントおよび接続可能なデータ・ストア

図1-2は、ある企業の全従業員が使用するエンタープライズ・アプリケーションの例を示しています。アプリケーションは、3つの異なるソースのディレクトリ情報にアクセスし、各ソースには異なるユーザーのグループがあります。これは企業構造に起因しており、多くの組織で一般的です。たとえば、Active Directoryリポジトリには社内の従業員ユーザーのみが含まれ、1つの企業ディレクトリに社内の別の部署またはビジネス・パートナのユーザーが含まれます。さらに、社外契約者などその他のユーザーはリレーショナル・データベースに格納されます。図に示すように、Oracle Virtual Directoryをデプロイして、3つすべてのソースのID情報を統合できます。

図1-2 異なるユーザー・グループのディレクトリの仮想化

Oracle Virtual Directoryでは、データの場所、形式、クライアント・アプリケーションのプロトコルといった複雑さは隠されています。これはスイッチとルーターに基づくTCP/IPインターネット・ネットワーク設計に似ています。スイッチとルーターは、ネットワーク上の様々なアドレス間で接続やプロトコルを確立する方法の詳細を処理します。ルーターを使用すると全世界の情報が自分のローカル・ネットワーク上にあるように見えるのと同様に、Oracle Virtual Directoryを使用することで、多くのディレクトリが1つのローカル・リポジトリのように見えます。

1.1.2 特徴

次に、Oracle Virtual Directoryの主な特徴を示します。

製品の特徴

- LDAPv2/v3をサポート

- DSMLv2/SOAPをサポート

- HTTP/XSLTゲートウェイをサポート

- 低コストの構成および管理

- マルチバイト文字のサポートやローカライズされた言語翻訳などのグローバリゼーション機能

- TLSv1およびSSLv3のサポートによる暗号化および厳密認証

- ディレクトリのプロキシおよびファイアウォールとして機能させるためにデプロイ可能

- メモリーおよびハードウェアの最小限に抑えられた要件

- Javaがサポートされるすべてのプラットフォームで使用可能

- LDAP操作レベルで構成可能なフェイルオーバーおよびインテリジェント・ロード・バランシング

- IETFのアクセス制御実装インターネット草案に基づく粒度の細かいアクセス制御

- JNDI準拠ディレクトリおよびJDBC準拠データベースへのアクセスのサポート

- 複数ディレクトリの情報とスキーマの動的マッピング

- LDAP問合せのインテリジェント・ルーティング

- DoSに対する保護

- オーバーラップ・ネームスペースの処理

- 多様なデプロイに対応する複数タイプのアダプタ

- メタディレクトリのような拡張可能な動的結合機能

- ローカル・スキーマのサポート

- 結合ディレクトリ(Active Directoryなど)のクライアントの認証

- カスタム拡張機能をサポートする粒度の細かいプラグイン・システム

- 動的ビューを使用した情報の区分化機能

- 統合レイヤーとデータ・アクセス・レイヤー両方でWebサービスをネイティブ・サポート

ビジネス機能と利点

- 実装および管理コストを削減

- 既存のインフラストラクチャへの投資を最大限に生かし拡大

- すべてのID情報を集中管理

- セキュリティおよびコンプライアンスを強化

- 同期の必要なく複数のディレクトリを統合

- 非ディレクトリ・データに対するLDAPインタフェースを提供

- 複数のデータ・ストアのデータを結合して仮想エントリを作成

- ディレクトリ情報のアプリケーション固有のビューを提供

- WebサービスをLDAPとして公開

1.1.3 機能

今日の企業ディレクトリのニーズへの対応という課題を解決するために、Oracle Virtual Directoryには次の機能が備わっています。

データ・フェデレーションおよび変換

Oracle Virtual Directoryは、クライアント・リクエストを処理し、形式(LDAP、RDBMSなど)にかかわらず1つ以上の既存ディレクトリに動的に再ルーティングするディレクトリ・ゲートウェイとして機能することで、利害関係や企業の境界を越えたディレクトリ・サービス・アクセスを可能にします。Oracle Virtual Directoryは仮想ディレクトリ階層(ツリー)をクライアントに示してから、指定されたLDAPまたはRDBMSサーバーにツリーの階層ブランチを割り当てます。Oracle Virtual Directoryが、ディレクトリ間のセキュリティ、プロトコルおよびデータ変換の問題を処理するため、LDAPクライアントは、すべての情報が信頼できる1つのLDAPディレクトリ(Oracle Virtual Directory)から送られたと認識します。

データの所有権

データの所有権は、目立ちませんが仮想化の重要な利点の1つです。通常、組織は、特定の目的を想定してディレクトリを作成します。ある組織が所有するデータに他の組織がアクセスする場合、突き詰めるとデータの所有者およびデータの管理者は誰かという問題が発生します。別の組織が情報を使用および共有する場合には利害関係が発生します。既存データの再利用の価値は広く認識されていますが、データの再利用には整備や管理に関する多くの問題が伴います。多くの組織は、所有していると思っているデータのコピーが他の組織や外部に出ることを非常に心配します。次のような疑問が生じると考えられます。

- データの管理者は誰でしょうか。

- 誰が正確さを保証するのでしょうか。

- 誰がセキュリティと機密保持を保証するのでしょうか。

- 情報がコピーされた場合、所有する組織は、他の組織がその情報を使用および管理していることをどのように確認すればよいのでしょうか。

プロキシ・テクノロジを介した仮想化では、データは所属する場所(データの所有者)に留まるため、このような利害にからむ問題の多くは解消されます。所有者はいつでもこのデータに対するアクセスを制限または禁止できます。さらに、所有者は自由にこの情報を改訂することができるため、パートナが常に適切な最新情報を利用することを確認できます。最も重要なのは、所有者が情報を保持することにより、情報の利用を所有者が継続して監視および制御できるということです。

Oracle Virtual Directoryでは、情報をコピーしないことにより、このようなタイプのデータの所有権を実現しています。Oracle Virtual Directoryがアクセスする情報はリアルタイムで取得されるため、情報が最新かつ正確で認可されていることがコンシューマとプロバイダに保証されます。

柔軟性の高いセキュリティ・ドメイン

Oracle Virtual Directoryは、新しいセキュリティ・ドメイン・コンテキストを提供してセキュリティを強化します。新しいビジネス・アプリケーションを複数のビジネス組織にわたってデプロイする場合、複数のディレクトリ・セキュリティ・インフラストラクチャが存在するためにIDとセキュリティが複雑になることがあります。Microsoft Active Directoryの管理者が認識するように、複数のWindowsインフラストラクチャ(フォレストとも呼ばれる)があることは管理とパフォーマンスにとっては長所ですが、フォレスト間の信頼関係を自動的に結ぶ機能やフォレスト間のグローバル・カタログがないことは短所です。

Oracle Virtual Directoryは、きめ細かなアクセス制御を備えた、新しい推移的なセキュリティ・コンテキストを作成します。アクセス制御に関するすべてのIETF規格をサポートし、実装のためのIETFモデルもサポートしています。また、Oracle Virtual Directoryは、プロキシ対象のソース・ディレクトリのセキュリティ制限と適切に統合するように設計されています。これにより、複数層または複数ドメインのセキュリティ概念が実現され、管理者が最大限にセキュリティを制御できます。

Oracle Virtual Directoryは幅広い認証モデルをサポートしています。Oracle Virtual Directoryは、SSL/TLS(StartTLSを含む)および証明書ベースの認証に加えて、プロキシ・サーバー(自身の認証)によるサーバー対サーバーの認証を使用できます。また、ユーザー・コンテキストをソース・ディレクトリに渡すこともできます。Oracle Virtual Directoryとソース・ディレクトリにユーザー・コンテキストを提供することにより、両方のディレクトリはエンド・ユーザーにコンテキスト・セキュリティ制御を提供できます

セキュアなデータ公開

Oracle Virtual Directoryには、次のような複数のデータ・セキュリティ機能があります。

- SSL/TLSのサポート: Oracle Virtual Directoryは、LDAPクライアントとのセキュアな通信セッションを実現するSSL/TLS機能を提供します。これによりOracle Virtual Directoryは信頼できる転送メカニズムになり、セキュリティが向上します。

- トランザクション・クレンジング: Oracle Virtual Directoryはプロトコル変換エンジンに基づいています。つまり、すべての問合せを分解し、再コンパイルして妥当性を調べてから、信頼できるプロキシ・ディレクトリ・ソースに送ります。これにより、不正な問合せや未認証の問合せからソースLDAPサーバーを保護します。不正なリクエストを消去した後で、Oracle Virtual Directoryは次のような項目に制限を設定する機能により、悪意のある攻撃による重い負荷から限りあるリソースを保護できます。

- 1接続当たりの最大操作数

- 最大同時接続数

- 特定のサブジェクトに対する特定期間の最大合計接続数

- 特定のアドレスに対する特定期間の最大合計接続数

- アクセス制御: Oracle Virtual Directoryは独自のアクセス制御を実装し、内部プロキシ・ディレクトリ・データに対してアクセスをフィルタ処理します。

アプリケーションとディレクトリの統合

ディレクトリが役立つのは、対応するアプリケーションが必要なデータに共通の形式またはスキーマでアクセスできる場合のみです。しかし、典型的なエンタープライズ環境には、様々なスキーマ、ネームスペースおよびデータ設計を備えた無数のディレクトリ・リポジトリが含まれています。

既存のディレクトリ情報にセキュアなブリッジを提供するだけでなく、Oracle Virtual Directoryは、その場でデータを変換するメタディレクトリと同様の機能を提供します。この機能により、管理者は、異なる組織やディレクトリ・インフラストラクチャで見つかったデータの違いを簡単に標準化することができます。この結果として得られる仮想ディレクトリ・ビューには、アプリケーションが実行するために必要なすべてのディレクトリ情報が含まれます。大幅な変更や統合テクノロジをアプリケーションに組み込む必要はありません。

柔軟性の高いデプロイ・オプション

Oracle Virtual Directoryには柔軟性の高いデプロイ・オプションがあり、開発者やビジネス・アプリケーション開発者が、開発済市販アプリケーションに埋め込むことができます。また、Oracle Virtual Directoryは、企業のIT部門が、共有ディレクトリ・サービス分散ネットワークとしてデプロイすることもできます。

高可用性のサポート

Oracle Virtual Directoryには、次のような複数の高可用性機能があります。

- フォルト・トレランスとフェイルオーバー: Oracle Virtual Directoryはフォルト・トレランスを次の2つの方法で提供します。

- フォルト・トレラント構成

- フォルト・トレラント・プロキシ・ソースへのフローの管理

構成ファイルをコピーするだけ、または構成ファイルも共有することにより、複数のOracle Virtual Directoryを迅速にデプロイできます。Oracle Virtual DirectoryをラウンドロビンDNS、リダイレクタまたはクラスタ・テクノロジと組み合せると、完璧なフォルト・トレラント・ソリューションが提供されます。

プロキシ設定された各ディレクトリ・ソースについて、特定のソースの複数のホスト(レプリカ)にアクセスするようにOracle Virtual Directoryを構成できます。ホスト間のフェイルオーバーと負荷分散もインテリジェントに実行されます。柔軟な構成オプションを使用して、管理者は特定のレプリカ・ノードに与える負荷の割合を制御したり、特定のホストを読取り専用レプリカか読取り/書込みサーバー(マスター)かに指定することができます。これにより、読取り専用レプリカに書込もうとすることから生じる不要な参照を回避できます。

- ロード・バランシング: Oracle Virtual Directoryには強力なロード・バランシング機能が設計されています。これにより、プロキシLDAPディレクトリ・ソース間で負荷を分散して障害を管理することができます。
Oracle Virtual Directoryの仮想ディレクトリ・ツリー機能により、大容量のディレクトリ情報のセットを複数の個別ディレクトリ・サーバーに細分化することができます。また、独立したディレクトリ・ツリー・ブランチを結合することで、分割したデータ・セットが再び結合して1つの仮想ツリーに戻されます。

特定のソースに複数のLDAPサーバーがある場合は、Oracle Virtual Directory LDAPアダプタにより、自動的にこれらのサーバーのロード・バランシングおよびフェイルオーバーが行われます。このロード・バランシングおよびフェイルオーバーは、クライアントに対して透過的に行われるため、Oracle Virtual Directoryに接続しているクライアントにハードウェアを追加する必要も、変更を行う必要もありません。

データベース・アダプタでは、基礎となるJDBCドライバにこの機能がある場合に、ロード・バランシングおよびフェイルオーバーがサポートされます。また、Oracle Virtual DirectoryはOracle Real Application Clustersでの使用が動作保証されています。

Oracle Virtual Directoryのルーティングにも、ロード・バランシングの機能があります。ルーティングでは、最適な検索ターゲットを決定するために、検索フィルタを検索ベースに追加することができます。このロード・バランシング方法では、Oracle Virtual Directoryは問合せを適切な仮想ディレクトリ・ソースに自動的にルーティングし、数百万に及ぶディレクトリ・エントリの処理が可能になります。

注意:
Oracle Virtual Directoryの値は仮想化およびプロキシ・サービス用で、ディレクトリ・ストア用ではありません。可用性の高いディレクトリ格納システムが必要な場合には、Oracle Internet Directoryを使用することをお薦めします。

カスタムApplication Program Interface

Oracle Virtual Directoryでは、次に示す3つの主要な機能に拡張性があり、顧客およびコンサルタントは、特定のビジネスまたは技術統合のニーズに合うようにOracle Virtual Directoryの機能を拡張できます。

- Oracle Virtual Directoryプラグイン: Oracle Virtual Directoryは、Javaサーブレット・フィルタをモデルとする柔軟性の高いプラグイン・フレームワークを提供します。プラグインを使用して、カスタム・ロジックをトランザクションの一部として提供することや、カスタム・データ・ソースに接続することができます。プラグインは、グローバルに挿入することも特定のアダプタのみに挿入することも可能です。プラグインの順序は変更でき、特定のタイプのトランザクションに対しては分離することもできます。Oracle Virtual Directoryの管理ツールでは、新しいプラグインを作成するためのウィザードやすぐに使用できるサンプルが提供されます。

- カスタム・ジョイナ: Oracle Virtual Directoryの結合ビュー・アダプタは、ジョイナと呼ばれる拡張可能なモデルに基づいています。カスタム・ジョイナを開発して、様々なジョイナの動作を提供できます。ジョイナは、マッピング、結合、ハンドラ・イベントの前処理および後処理などの機能を提供します。単純なエントリ・レベルの結合を提供するカスタム・ジョイナを作成することや、ジョイナを拡張して、複雑な結合ロジック、トランザクション処理およびロールバック機能を提供することが可能です。

- Webゲートウェイ: Oracle Virtual Directoryにはカスタマイズ可能なDSML/XSLTベースのゲートウェイが組み込まれています。これにより、Apache Webサーバー・モデルに基づく基本的なWebサーバー・サポートが提供され、静的なHTMLおよびXSLTレンダリング・コンテンツがサポートされます。このゲートウェイにはディレクトリ対応インタフェースが組み込まれており、問合せ操作および変更操作が可能です。Webサーバー・セキュリティによって、このインタフェースに基づくカスタム委任管理アプリケーションの開発が可能になります。

低コスト、高価値のソリューション

従来のディレクトリ統合ソリューションは、複雑なLDAPプロビジョニングおよびレプリケーション・スキームが必要であり、同期化を実行することも必要です。このような新しいディレクトリも、維持および管理が必要な追加のディレクトリ・ソースになります。

軽量のリアルタイム・サービスであるOracle Virtual Directoryは、同期化や複製は行わずに既存のディレクトリ・インフラストラクチャを再利用することで効率を向上します。Oracle Virtual Directoryは、既存の企業ディレクトリの能力を拡張し、その価値を十分に活用します。

1.1.4 アーキテクチャおよびトポロジ

次の項では、Oracle Virtual Directoryのアーキテクチャおよびトポロジについて説明します。

Oracle Virtual Directoryのアーキテクチャ

Oracle Virtual DirectoryサーバーはJavaで記述されており、図1-3に示すように、内部は複数のレイヤーに分かれています。これらのレイヤーは論理レイヤーであり、管理者やクライアントにとって、Oracle Virtual Directoryは単一の完全なサービスです。

図1-3 Oracle Virtual Directoryのアーキテクチャ

1つ目のレイヤーは、ソケット・レベルのプロトコルが通信するOracle Virtual Directoryのリスナー・レイヤーです。Oracle Virtual Directoryには、LDAPとHTTPの2種類のリスナーがあります。どちらのリスナーでも、基本プロトコルの他にSSL/TLSがサポートされています。LDAPレイヤーには、LDAP-SASLをサポートしてデジタル証明認証に対応する機能があります。

リスナーは、検索や更新など、実行するアクションを決定するための処理を行うワーカー・スレッドにリクエストを渡します。これがLDAPあるいはDSMLリクエストのどちらの場合でも、Oracle Virtual Directoryには内部的に操作は同一に見えます。操作が決定されると、最初のレベルのセキュリティ・チェックが行われます。このチェックでは、リクエストがDoSポリシーやインバウンドのOracle Virtual Directoryレベルのアクセス制御に違反していないことが確認されます。

リクエストがインバウンドのセキュリティ要件を満たす場合、次のステップでグローバル・レベルのマッピングおよびプラグインが起動します。マッピングとプラグインには、属性の名前や値の変更など、操作を変更する機能があります。構成されたグローバル・プラグインが起動されたら、Oracle Virtual Directoryにより、リクエストを処理するアダプタが決定されます。この決定は、操作中に提供される情報に基づいて行われます。

使用されるプライマリ情報は、操作のDNです。つまり、検索における検索ベース、またはバインドや追加など、その他すべてのLDAP操作におけるエントリのDNです。Oracle Virtual Directoryは、DNを参照し、そのDNの操作をサポートできる可能性のあるアダプタを決定します。これが可能なのは、各アダプタ構成に、それが関与するLDAPネームスペースが示されているためです。複数のアダプタが受信DNネームスペースをサポートできる場合(検索のベースがdc=oracle,dc=comなど、ディレクトリ・ネームスペースのルートである場合など)、Oracle Virtual Directoryは、そのリクエストを処理できる選択された各アダプタで操作を実行します。優先順位の順序は、優先度、属性またはサポートされるLDAP検索フィルタに基づいて構成できます。

Oracle Virtual Directoryによりアダプタが選択されると、次にインバウンドのアダプタ・レベルのプラグインが起動されます。このプラグインは、特定のアダプタのみでしか動作しない点を除けばグローバル・プラグインに似ています。いずれかのプラグインが起動されると、アダプタはOracle Virtual Directoryのリクエストを、その特定のアダプタ・レベルのプロトコルへマッピングする操作に変換します。LDAPアダプタの場合は、変換がほとんど行われないことが多く、受信DNをその実際のネームスペースへマッピングする値に変換するだけです。たとえば、受信する検索がou=staff,dc=oracle,dc=comの場合、これはou=hr,o=oraclecorpにマッピングされます。ただし、データベース・アダプタを使用するJDBCなどのその他のアダプタの場合、リクエストはSQLコールに変換されます。また、カスタム・アダプタの場合は、Webサービス・コールなどの独自のプロトコルに一致するメソッドに変更されます。

操作が実行されると、結果は逆の順序でクライアントへ戻ります。非検索操作では、通常はこれ以上の処理は行われません。データが戻される検索操作では、データ上でプラグイン(任意)およびアクセス制御が処理されます。Oracle Virtual Directoryアクセス制御は、データに伴う既存のすべてのアクセス制御とともに動作し、そのかわりではなく、追加のアクセス制御として機能するように設計されています。

最後に、リスナー・レベルは、データがLDAPやDSMLエントリなどの正しい形式でクライアントに戻されたことを確認します。

Oracle Directory Services Manager

11gリリース1(11.1.1)では、Oracle Virtual DirectoryおよびOracle Internet Directoryに、Oracle Directory Services Managerという統合されたグラフィカル・ユーザー・インタフェース(GUI)があります。Oracle Directory Services Managerを使用すると、Webベースのフォームとテンプレートを使用できるため、Oracle Virtual DirectoryとOracle Internet Directoryの管理および構成が簡略化されます。

注意:
Oracle Directory Services Managerを使用するとき、Oracle Directory Services ManagerおよびOracle Virtual Directoryサーバーが同じJDKメジャー・バージョンであること、または、Oracle Virtual DirectoryがOracle Directory Services Managerよりも上位のJavaバージョンを使用していることを確認する必要があります。

このリリースの時点では、Oracle Directory Services Managerを構成してシングル・サインオン(SSO)を使用できます。SSOを使用するようにOracle Directory Services Managerを構成すると、SSOサーバーによって認証済のユーザーがSSO対応ディレクトリにエントリを持っている場合、ユーザーはログインせずにそのディレクトリに接続できるようになります。

詳細は、『Oracle Directory Services Managerの開始』を参照してください。

Fusion Middleware Control

11gリリース1(11.1.1)では、Oracle Enterprise Manager Fusion Middleware Controlから、Oracle Virtual Directoryの多くの機能を構成します。このコンソールを使用すると、1つのユーザー・インタフェースからすべてのOracle製品を構成および管理できます。

Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directory Serverおよび関連するコンポーネントとアクティビティを監視できます。Oracle Enterprise Manager Fusion Middleware Controlにより、インストール時またはその後の構成で指定するホスト名およびポートが収集されます。リソース検出サービス(RDS)によりサーバー・インスタンスと関連するコンポーネントが識別され、これらのコンポーネントに関する情報がOracle Enterprise Manager Fusion Middleware Controlに送信されます。Oracle Enterprise Manager Fusion Middleware Controlは、ネットワークのノードが停止した際の検出や、追加のノードがインストールされ、Oracle Universal Installerから構成されたかどうかの検出をRDSに依存しています。

監視機能を使用して、合計ログイン、成功したログインと失敗したログイン、平均ログイン時間、リクエスト待機時間、LDAP接続など、システム・アクティビティやパフォーマンスを把握できます。

次に、監視できる項目を示します。

- メトリック: システムの状態を監視

- 一般: 負荷、パフォーマンス、セキュリティ、ログイン、CPU使用率、およびその他のデータの高水準のロールアップ

- パフォーマンス: ディレクトリ・サーバーおよびそのホストの主要なメトリック

- レポート: 操作の成功および失敗に関するデータ

- トポロジ: Oracle HTTP Serverインスタンス、ディレクトリ・サーバー・インスタンス、シングル・サインオン・サーバー、関連するデータベースなどの情報

1.1.5 Oracle Fusion MiddlewareにおけるOracle Virtual Directoryの位置づけ

Oracle Fusion Middlewareは、Java EEおよび開発者ツールから、統合サービス、ビジネス・インテリジェンス、コラボレーションまで、幅広いツールとサービスに対応する、標準ベースのソフトウェア製品の集合体です。Oracle Fusion Middlewareは、開発、デプロイ、管理に完全なサポートを提供します。

Oracle Virtual Directoryは、スタンドアロンJava 2 Standard Edition(J2SE)プロセスとして、Oracle Fusion Middlewareの一部を構成しています。Oracle Virtual Directoryは、Oracle Fusion Middlewareフレームワークの様々な側面を活用し、次の要素とも統合しています。

- 共通監査フレームワーク

- 共通ロギング・フレームワーク

- 資格証明ストア・フレームワーク

- Oracle Enterprise Manager Fusion Middleware Control

次に、Oracle Virtual Directoryに関連するOracle Fusion Middlewareの概念と用語を説明します。

WebLogic Serverドメイン

WebLogic Server管理ドメインは、論理的に関連するJavaコンポーネントのグループです。WebLogic Serverドメインには、ドメイン内のすべてのリソースの構成および管理の中心である管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれています。

Oracle WebLogic Serverドメインは、Oracleインスタンスのピアです。両方とも、それぞれのOracleホーム以外に特別な構成を保持します。

WebLogic Serverホーム

WebLogic Serverホームには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれます。WebLogic Serverホーム・ディレクトリは、Oracleホーム・ディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造内に配置されます。

Oracleインスタンス

Oracleインスタンスには、Oracle Virtual Directoryなどの1つまたは複数のシステム・コンポーネントが含まれます。Oracleインスタンスのシステム・コンポーネントは、同じコンピュータ内に存在する必要があります。Oracleインスタンス・ディレクトリは、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルを保持します。

Oracleホーム

Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、Oracle Virtual Directoryホームは、Oracle Virtual Directoryバイナリ・ファイルおよびライブラリ・ファイルが含まれるディレクトリを保持します。Oracleホームは、ミドルウェア・ホームのディレクトリ構造内に配置されます。各Oracleホームは、複数のOracleインスタンスまたはOracle WebLogic Serverドメインと関連付けることができます。

ミドルウェア・ホーム

Middlewareホームは、Oracle WebLogic Serverホーム、および場合によっては1つ以上のOracleホームで構成されています。ミドルウェア・ホームは、ローカル・ファイルシステム、またはNFSを介してアクセスできるリモート共有ディスクに配置することができます。

関連項目:
Oracle Fusion Middlewareの詳細は、『管理者ガイド』を参照してください。

1.1.6 オラクル社のディレクトリ・サービスのポートフォリオ

オラクル社は、次のように幅広いディレクトリ・サービス・ソリューションを提供する唯一のベンダーです。

- Oracle Internet Directoryによるスケーラブルなローカルストア・ベースのディレクトリ・サーバー

- Directory Integration Platformによるメタディレクトリ

- Oracle Virtual Directoryによるディレクトリの仮想化

Oracle Internet Directoryは、LDAPサーバーにデータを格納する必要があるが、既存のディレクトリ・サーバーがない場合に使用します。Directory Integration Platformは、データベースまたは他のディレクトリ情報をOracle Internet Directoryと同期化する必要がある場合に使用します。また、Directory Integration Platformを使用して、Oracle Internet Directoryと特定のOracleアプリケーション(Oracle eBusiness Suiteなど)の間でデータを同期化することもできます。Oracle Virtual Directoryを使用すると、リアルタイムに直接データ・アクセスを介して、異機種ソースのデータを1つのディレクトリ・サービスに集約できます。

Oracle Directory Services製品は、それぞれ単独で使用することも、組み合せて使用することもできます。たとえば、Oracle Virtual DirectoryをOracle Internet Directoryと一緒に使用すると、Oracle Internet Directoryデータに対するDSMLインタフェースを提供できます。Oracle Internet Directoryを使用すると、既存のディレクトリを利用できない場合にOracle Virtual Directoryを使用して管理する情報用のスケーラブルな記憶域を提供できます。また、Directory Integration PlatformとOracle Internet DirectoryでOracle Virtual Directoryを使用すると、既存の仮想データストアにフォルト・トレランス・サポートを追加することができます。たとえば、なんらかの理由でプライマリ企業ディレクトリが使用不可になった場合に、Oracle Virtual DirectoryはOracle Internet Directoryストアを使用できます。

1.2 企業ディレクトリでは不十分な理由

この項では、ID管理構成へのデプロイ時に、従来のディレクトリ・サーバーや企業ディレクトリで発生する問題の多くについて説明します。また、Oracle Virtual Directoryでは、それらの問題がどのように解決されるかについても説明します。

概要: 従来のディレクトリ・サーバーのデメリット

現在のディレクトリ・サーバーは、特殊なデータベースとして設計されたものであり、これらのみでは、関連するすべてのアプリケーションを1つの企業ディレクトリに接続するために必要なツールを企業に提供できません。わずかな例外を除き、1つの企業ディレクトリしかない企業はありません。

アナリストによれば、ほとんどの企業に社内全体で使用されているディレクトリが複数(5つ以上)あります。複数のビジネス・パートナが使用するアプリケーションにデータを提供する目的がある場合、ディレクトリの数は、少なくともアプリケーションを使用するビジネス・パートナの分のみ増加します。オラクル社では、ほとんどの企業が社内および社外に複数層のディレクトリ・サービスを必要としていると考えています。Oracle Virtual Directoryは、データを重複させず、大規模なレプリケート・インフラストラクチャのコストを発生することもないため、この要件を実現する最適な方法の1つです。

典型的なディレクトリおよびデータベース・テクノロジでは、独立した事業単位、部署およびパートナから企業が構成されているときに発生する問題を解決することができません。現在のディレクトリ・サーバー・テクノロジでは、企業は1つの管理データ・インフラストラクチャを構築することを強制されます。これには、次の項目について、利害がからんだ長い話合いが必要になります。

- ディレクトリ・インフラストラクチャにどのデータを含めるか。

- 誰が管理するか。

- 誰が費用を負担するか。

ディレクトリのコストを誰が負担するか、またディレクトリを誰が管理するかという問題が、比較的単純なデータベース・テクノロジのデプロイを成功させるための重大な要因になります。図1-4に示すように、いくつものディレクトリ・ソースが様々な形式で様々な場所に設置されていますが、所有者も多岐にわたります。また、このような従来の企業ディレクトリには、リレーショナル・データベースや電子メール・システムといったその他のディレクトリが追加されます。

図1-4 分散したディレクトリ・サービス

データの配置に伴う問題は、Lotus DominoやMicrosoft ExchangeのようなLDAP対応アプリケーションが加わるとさらに複雑になります。このようなアプリケーションに含まれるディレクトリ情報は、スキーマの要件が異なるため、既存の企業ディレクトリにそのまま統合することはできません。

開発者は、これまでは特定の目的のためのデータベースの作成において成功を収めてきました。これは、ビジネス主導のアプリケーションに出資する個々のビジネス・マネージャが意思決定を行っているためです。現在、B2B Webサービスおよびビジネス間アプリケーションという新しいトレンドによって、ディレクトリ・サービスおよびセキュリティ・インフラストラクチャ戦略を作成するときに外部パートナのデータ・ソースを考慮する必要があることが示されています。

ディレクトリ・サービス統合レイヤーは、次のような現実的な問題への対応に必要です。

- 分散セキュリティ: 可用性および検証

- ルーティング: 様々なデータの取得方法

- 統合: 様々な形式の処理方法

- データ・レベルのフェデレーション: 信頼できるディレクトリのマージ

Oracle Virtual Directoryはこのような課題に対するオラクル社の答えです。

次の項では、従来のディレクトリ・サーバーで発生する共通の問題や、Oracle Virtual Directoryを使用してそれらの問題をどのように解決できるかを詳細に説明します。

レプリケーションの遅延

多くの場合、ディレクトリ・サービスは、長期にわたって1つの1次ノードまたはマスター・ノードと複数のレプリケーション・ノードを使用してデプロイされます。その間、ディレクトリの複数の階層を開発して、リージョン内でのレプリケーションを促進し、リージョン・ディレクトリ・ファームをサポートしていることがあります。

時間の経過につれてレプリケーションの速度が低下し、ディレクトリ・レプリカ・サーバーの情報が古いものになってしまいます。レプリケーションの速度低下の主な原因は、検索する索引の管理にあります。多くの場合、索引をみなおして数を最小限に減らすことにより、既存のインフラストラクチャの使用期間を延ばすことが可能です。

ただし、ある時点で、ディレクトリの索引付けの要求が、個々のサーバーが変更に追い付いてレプリケートできる能力を上回ります。代替策として、レプリカを目的別またはサービスクラス別のノードに分割することを検討してください。たとえば、1組のレプリカを、ユーザー検索とポリシー・サーバー・リクエストの処理専用とします。もう1組をホワイト・ページまたは電子メール検索リクエストの処理専用にします。その他のサーバーは特定のアプリケーションのニーズに合せてチューニングします。

図1-5 サービスクラスのレプリカの索引付けの例

図1-5では、索引付けの戦略が調整され、サービスクラスのレプリカを作成してレプリケーションを拡張できるようにしています。各サービスクラスは、特定のアプリケーション・クライアント用に設計された一連のディレクトリ・レプリカを定義します。

この場合、Oracle Virtual Directoryはマスター・サーバーの場所を自動的に認識し、変更されたトラフィックをそれに直接ルーティングして、不必要なディレクトリ参照操作を回避します。次の課題は、サービスクラスに基づいた正しい検索に対してアプリケーションを正しいレプリカにルーティングする方法です。

容易な方法の1つは、ディレクトリ・レプリカをアプリケーションに直接割り当てることです。ただし、アプリケーションは、特定のディレクトリ・レプリカで構成できる内容を上回る多様な検索を使用することがあるため、この戦略は機能しない場合があります。かわりに、Oracle Virtual Directory仮想ディレクトリのルーティングの組込みフィルタと除外フィルタを使用して、各検索リクエストを自動的にルーティングすることができます。これらのフィルタを使用して、各プロキシ・ノードが実行できる操作、および実行できない操作を管理者が決定できます。

図1-6 UIDに関するアプリケーション検索をルーティングするOracle Virtual Directoryの例

図1-6は、ユーザー識別名を見つけるためにアプリケーションがUIDを検索する典型的なリクエストを示しています。Oracle Virtual Directoryは検索フィルタを認識し、リクエストを適切なディレクトリ・レプリカにルーティングします。Oracle Virtual Directoryは複数のノードから選択することができ、ノード間のロード・バランシングを提供することに注意してください。これにより、複数のノードに負荷を分散でき、1つのノードに依存する必要がないためフォルト・トレランスを保証できます。

様々な検索操作(ホワイト・ページなど)またはサービスクラスの場合、Oracle Virtual Directoryは代替のディレクトリ・レプリカにルーティングできます。

どのフィルタも一致しなかった場合は、デフォルトのサーバーを指定できます。このサーバーは、低パフォーマンス・サーバーとして設定され、多目的の索引付けが行われているためにレプリケーションが遅れることがあります。

どの場合も、ユーザーが意識するのは単一のOracle Virtual Directoryのみです。実際は、フォルト・トレランスとサーバーの負荷要件に応じて同一構成の複数のOracle Virtual Directoryがデプロイされます。Oracle Virtual Directoryはデータを保持しないため、アーキテクチャは完全に並列であり、無限に拡張することができます。たとえば、必要であればアプリケーション・クライアントごとに1組のサーバーをデプロイできます。各サーバーがデータを保持せず(つまりバックアップが不要)、単純にルーターとして機能するため、インフラストラクチャ全体には各サーバーによって最小限の管理コストが加えられるだけです。

トランザクション・フェイルオーバー

多くの企業は、すでにフォルト・トレラント・インフラストラクチャをデプロイし、使用可能なディレクトリ・サーバー・ノードにLDAPトラフィックをルーティングするために、F5 BigIPなどのデバイスを使用しています。LDAPではアトミックな単一ユニット・トランザクションが提供されるため、多くの場合、アプリケーションがトランザクション障害を処理できるとみなされます。LDAP操作が失敗した場合は、アプリケーションが認識して再接続と再試行を行うと常に想定されていました。サービス・アーキテクトにとっては、これによって多くの問題が発生していました。一部のアプリケーションが無効なトランザクションを複数のディレクトリ・サーバーで繰り返したり、アプリケーションで障害が発生して再試行が必要なことを認識しないためです。

Oracle Virtual Directoryは、アプリケーションの負荷を複数のディレクトリ・サーバーに分散するために設計されたインテリジェント接続プーリング・メカニズムを利用して、このような問題に対処します。接続プーリングは個々のトランザクションを複数のサーバーに分散するため、Oracle Virtual Directoryは、トランザクションが特定のノードでタイムアウトになるか失敗したときに認識し、その操作を別のノードに送ることができます。Oracle Virtual Directoryは、問題がデータ障害(クライアントに戻される)かサービス障害かを判別します。サービス障害が発生した場合、Oracle Virtual Directoryは、使用可能な各サーバーでトランザクションを試行し、すべてのサーバーに試します。障害をクライアントに戻すのはその後です。

保護を強化するために、ローカル以外のディレクトリ・ノードをOracle Virtual Directoryのサーバー・リストに追加することでグローバル・フェイルオーバーを構成できます。このように構成すると、LDAPアダプタのLDAPサーバー構成でこれらの非ローカル・ノードには負荷パーセンテージとして0が割り当てられます。これにより、Oracle Virtual Directoryは、他のローカル・ノードを使用できない場合のみこれらのノードを使用するようになります。これにより、ローカルにトラフィックをルーティングすることができ、必要な場合には他のサイトにトラフィックを送ることも可能です。

接続の占有

多くの大規模ディレクトリ環境では、一部のアプリケーションが接続を占有し、共有しない場合があります。アプリケーションのブートストラップ時に、アプリケーションにディレクトリ・サーバーが割り当てられ(たとえば、F5 BigIPによって)、そのサーバーとの永続接続を確立します。これにより、次のような問題が発生します。

- 事実上、フォルト・トレランスとロード・バランシングが省略されます。従来のほとんどの方法では、接続に基づいたロード・バランシングとフェイルオーバーが使用されるため、接続がないアプリケーションは過負荷のディレクトリ・サーバーから容易に移動することはできません。

- 負荷が処理できないほど大きくなります。アプリケーションは1つのディレクトリのみを使用する傾向があるため、負荷要件が、割り当てられるノードの処理能力を超える場合があります。いつまでも接続が放棄されないため、管理システムが負荷を再調整する機会はありません。

仮想ディレクトリ・テクノロジは、トランザクションごとに負荷を分散する接続プーリング・メカニズムを提供することで役立ちます。Oracle Virtual Directoryは、各プロキシ・ディレクトリと最小限の数の接続を維持し、負荷の必要に応じて接続を追加します。Oracle Virtual Directoryは、単一クライアント接続の自動切替えを提供し、その操作を複数のディレクトリ・サーバーに分散します。これにより、1つのディレクトリ・サーバー・ノードが過負荷になることがないため、ディレクトリ・サービスの安定性が高まります。Oracle Virtual Directoryは接続占有クライアントとの間に1つの接続セッションを維持する一方で、インフラストラクチャ内の優良な住人として負荷分散や定期的な接続リフレッシュを行います。

アプリケーション接続の過負荷

接続を行うアプリケーションが多すぎ、TCP/IP接続とLDAPバインド・リクエストが多すぎてディレクトリ・サーバーが過負荷になると、接続占有の問題と正反対の状況が発生します。このとき、多数のディレクトリ・サーバー(LDAPバージョンおよびX.500バージョン)が、システム・リソースの不足または処理スレッドがなくなるために不安定になることがあります。多くのベンチマークによって、同時接続スレッド数が7から10の場合にほとんどのディレクトリ・サーバーがピーク・パフォーマンス・レベルに達することがわかります。この情報は、サーバーがより多くのコールに応答できる能力がある場合でも、サーバーがリクエストの処理よりも接続の確立に時間を割くようになるにつれて、図1-7に示すように、ピーク・スループットは減少することを意味します。

図1-7 接続の確立により減少するスループット

Oracle Virtual Directoryの接続プーリング・メカニズムでは、この問題は解決されません。接続占有クライアントの場合と同様に、Oracle Virtual Directoryは、プールを使用して多数のクライアントで接続を共有し、必要な場合にはユーザー・コンテキストを切り替えるために再バインドを使用します(Oracle Virtual Directoryの資格証明の引渡し設定のモードによって異なります)。Oracle Virtual Directoryは多数のクライアント接続とリクエストを処理し、プロキシ・サーバーとの減少した接続においてトランザクションを多重化します。既存の接続が再利用されるため、プロキシ・サーバーでのリソースの消費量は大幅に減少し、LDAPのトランザクション処理に集中することができます。

データの過負荷

「レプリケーションの遅延」の項で説明されているように、場合によっては、ディレクトリ・レプリケーション・スキームの最適化は、非常に大規模なディレクトリに必要な規模の確保には十分ではありません。このような場合、1000万あるいは1億にもおよぶエントリのディレクトリを作成する機能は、データを細分化して、細分化されたすべてのデータが1つのディレクトリ・ビューとして表示される仮想ビューを作成する機能(いわゆる分割統治の手法)に依存します。

Oracle Virtual Directoryは、このような仮想化を達成するためにいくつかの手段を提供します。最も単純な方法はディレクトリ階層の活用です。データを階層構造に細分化できる場合、各グループが独自の1つ以上のネームスペースを持つ複数のディレクトリ・グループが作成されます。これにより、Oracle Virtual Directoryが識別名を確認して、使用するディレクトリ・グループを判別し、トラフィックをルーティングできます。

たとえば、ある架空の電話会社が市外局番別に顧客を分けていた場合、Oracle Virtual Directoryは、図1-8に示すように市外局番を含む組織単位を確認してトラフィックをルーティングできます。すべての変更とバインドの操作では、トラフィックは識別名のみに基づいてルーティングされます。検索操作では、「レプリケーションの遅延」の項で説明されているように、検索ベースがo=BigCoであることが必要でネームスペース固有にならない場合、ルーティングの組込みフィルタと除外フィルタが使用されて、検索フィルタに基づいてトラフィックが送られます。

図1-8 組織単位に基づくトラフィックのルーティングの例

すべてのエントリが1つの親の下にある平面的な階層が望ましい場合は、一番左の識別名またはDNコンポーネントである相対識別名(RDN)を解析するか、プリフェッチ操作を使用するかを選択できます。RDNコンポーネントを解析できる場合は、図1-9に示すように、RDNを解析してルーティング決定を行うプラグインの使用によってルーティングが確立されます。

たとえば、DNがnumber=6046331751,ou=Account,o=BigCoという形式の場合、ルーティング・フィルタは、最初の3桁(この場合は604)に基づいて特定のディレクトリ・グループを選択できます。

DNがuid=jdoe,ou=Accounts,o=BigCoという形式の場合、ルーティングはハッシュ表を使用して、aからl、mからrおよびsからzで始まるアカウントがそれぞれ3つのサーバーに分かれていることを判別します。

図1-9 平面的な階層における解析の例

この場合は、標準ルーティング機能を補足するために、ルーティング・プラグイン・メカニズムを使用できます。このプラグインの目的は、データ分けの基準をユーザーが指定できるようにすることです。理想としては、選択される基準(DNの場合もフィルタとベースの場合にも)がすべてのトランザクションで使用可能であることが必要です。

別の方法はプリフェッチの使用です。データの分割が(少なくともOracle Virtual Directoryにとって)予測不可能な方法で行われた場合、Oracle Virtual Directoryは顧客固有の基準に基づいてディレクトリを検索して、正しいリポジトリを探す必要があります。たとえば、LDAPの変更操作では、変更リポジトリを探す検索を最初に実行する必要があります。バインド、削除および名前変更の操作でも同様の要件があります。LDAPの追加操作では、どのリポジトリが追加リクエストを受け取るかを判別できるように、追加リクエストに十分な情報を含める必要があります。状況によっては、サーバーがインフラストラクチャでエントリを探すために使用する特殊なマスター・ディレクトリによって、パフォーマンスのオーバーヘッドが抑えられます。

結論

図1-10に示すように、Oracle Virtual Directoryは、グローバル・ディレクトリ・サービス・デプロイの様々な局面においてフォルト・トレラント構成で使用できます。Oracle Virtual Directoryは、ロード・バランサとしてサイトのIPルーター(たとえばWebsphere Edge ServerおよびF5 BigIP)とサイトのレプリカ・サーバーの間に配置できます。Oracle Virtual Directoryは、その位置でサーバー間のトランザクション・レベルのロード・バランシングとフォルト・トレランスを提供します。ロード・バランシングに加え、Oracle Virtual Directoryは、リレーショナル・データベース・ソースの情報(JDBC経由)など、インフラストラクチャ・レベルの複数のデータ・ビューを提供できます。

図1-10 Oracle Virtual Directoryのロード・バランシングの例

特殊なディレクトリ・ビューまたはグローバル・トランザクション・フェイルオーバー機能を必要とするアプリケーションでは、Oracle Virtual Directoryをミドルウェア・コンポーネントとしてアプリケーション・サーバーに直接デプロイできます。この戦略により、サイトで障害が発生した場合に、アプリケーションが様々なロケーションを切り替えることができます。通常、この構成では、Oracle Virtual Directoryがロード・バランシングを提供するのはローカル・レベルのみですが、ローカル・サービスが失敗した場合のみ他のロケーションのノードに切り替えます。

Oracle Virtual Directoryは柔軟性が高いため、ディレクトリ設計者は、複雑で堅牢なディレクトリ・サービス・インフラストラクチャを開発することができます。統合ツールとしてのOracle Virtual Directoryは開発者を支援し、エンタープライズ・インフラストラクチャを使用する際に最も簡単な方法を活用できるようにします。情報のルーターとしてのOracle Virtual Directoryは迅速にデプロイでき、管理が容易で、非常に低いコストで運用できます。

Oracle Virtual Directoryでは、大規模デプロイを効果的に管理するために必要な機能とパフォーマンスが提供されます。企業が社内全体にわたるデータ問題の解決を模索しているとき、Oracle Virtual Directoryは最も困難な課題に対して複数のソリューションを提供します。

1.3 企業ディレクトリ・ネットワーク環境でのOracle Virtual Directory

Oracle Virtual Directoryを複数の異なる環境にデプロイして、従来のディレクトリ・ソリューションが抱えている問題を解決できます。図1-11に、イントラネットとエクストラネットの2つの異なる環境にデプロイされたOracle Virtual Directoryの例を示します。

図1-11 企業ディレクトリ・ネットワーク環境でのOracle Virtual Directory

イントラネットでのIDの例

次の手順で、図1-11に表示されているイントラネットの例におけるOracle Virtual Directoryの一連の役割を説明します。

1. 図の左下では、内部エンド・ユーザーがイントラネット・ベースのWebアプリケーションにアクセスしています。アプリケーションには、独自のインフラストラクチャの一部としてポリシー・サーバーが含まれる場合と含まれない場合があります。

2. エンド・ユーザーがアプリケーションにアクセスする際に、アプリケーションまたはポリシー・サービスにより、ユーザーのIDとパスワードが要求されます。

3. アプリケーションまたはポリシー・サービスは、LDAPのバインド・リクエストを使用して資格証明を検証するために、LDAPv3を使用してOracle Virtual Directoryにアクセスします。

4. 次にOracle Virtual Directoryは、このリクエストをローカル・ディレクトリ・サーバー・ストアにルーティングし、資格証明を検証します。検証が終わると、Oracle Virtual Directoryは確認した結果をアプリケーションに戻します。

5. その後のリクエストでは、アプリケーションは、アプリケーションのプロファイルと権限を取得できるように、Oracle Virtual Directoryにユーザーのディレクトリ・エントリを要求します。Oracle Virtual Directoryは透過的な結合を実行して、ローカル・ディレクトリ・サーバーとRDBMSの情報の属性をまとめます。収集が終わると、Oracle Virtual Directoryは結果を1つの仮想エントリにマージして、そのエントリをイントラネット・アプリケーションに戻します。

エクストラネットでのIDの例

次の手順で、図1-11に表示されているエクストラネットの例におけるOracle Virtual Directoryの一連の役割を説明します。

1. 右上では、外部の組織またはビジネス・パートナのエンド・ユーザーがエクストラネット・ベースのWebアプリケーションにアクセスしています。

2. このアプリケーションが、LDAPバインドを使用してユーザーの資格証明を確認するために、LDAPv3を使用してOracle Virtual Directoryにアクセスします。

3. Oracle Virtual Directoryは、資格証明が外部ディレクトリにマッピングされることを認識します。Oracle Virtual Directoryは、ビジネス・パートナのところにある外部Oracle Virtual DirectoryにSSL暗号化リンクを使用して接続し、独自の資格証明を使用して事業単位間の問合せを検証します。

4. ビジネス・パートナのOracle Virtual DirectoryはOracle Virtual Directoryを検証すると、リクエストを認識し、内部のLDAPv3ディレクトリに渡します。

5. Oracle Virtual Directoryは、適切なビジネス間アクセス制御を適用し、フィルタ結果をディレクトリからOracle Virtual Directoryに戻します。これで、ビジネス・パートナ・ユーザーのパスワードを検証でき、成功または失敗をアプリケーションに戻すことができます。

6. 最後に、イントラネット・アプリケーションの例と同じく、アプリケーションがユーザーのその他の属性をOracle Virtual Directoryに問い合せます。Oracle Virtual Directoryは、ビジネス・パートナ・ディレクトリのクライアント提供情報と企業データベースにローカルに格納されている情報を結び付ける結合を実行します。

例のサマリー

図1-11の例では、複雑なシナリオにそって機能を説明します。Oracle Virtual Directoryは、情報のルーターおよびジョイナとして機能し、アプリケーションまたはセキュリティ・インフラストラクチャのニーズに合せて複数のセキュアなソースの情報を仲介します。Oracle Virtual Directoryは1つのイントラネット内の情報をまとめるだけでなく、ビジネス・パートナの情報を活用することもできます。ビジネス・パートナがエクストラネット・アプリケーションを使用するときに、ホスト・ビジネスのディレクトリでのプロビジョニングや管理が必要なくなるため、この機能は特に重要です。ビジネス・パートナ・ユーザーは、自身のローカル・ディレクトリでリアル・タイムに認証されます。

また、Oracle Virtual DirectoryはLDAPプロキシ・サーバーとしても重要な役割を果します。オプションとしては、Oracle Virtual Directoryをビジネス・パートナのディレクトリのファイアウォールとして使用することもできます。Oracle Virtual Directoryは、内部ディレクトリ情報への外部からのアクセスを適切に承認および認可します。図の右下では、Oracle Virtual Directory独自のルーティング機能により、複数の内部ディレクトリまたはWindows Active Directoryフォレストにルーティングして、クライアントから情報を保護する様子が示されています。ファイアウォールとしては、Oracle Virtual Directoryは情報へのアクセスを管理および制限して、承認された外部ユーザーがアクセスできるようにします。仮想ディレクトリ・コンポーネントとしては、Oracle Virtual Directoryは、データを単純化および再構成して公開し、ビジネス・パートナが使用できるようにします。

1.3.1 仮想ネームスペース・マッピング

Oracle Virtual Directoryを使用すると、すべてのソース・ディレクトリ・ツリーに接続でき、そのツリーを新しい仮想ツリーにマッピングできます。たとえば、ソース・ディレクトリのエントリの識別名(DN)が次の場合について考えます。

cn=Jim Smith,ou=People,o=Division B, c=UK

このソース・ディレクトリ・エントリは、次のようにマッピングできます。

cn=Jim Smith,ou=People,ou=Division B, ou=People,o=AppView

この場合、Oracle Virtual Directoryは、o=Division B, c=UKの下のすべてのエントリをou=Division B, ou=People, o=AppViewにマッピングします。Oracle Virtual Directoryは、その場で変換を実行して、Division Bのユーザーがアプリケーション固有ディレクトリに含まれるようにします。

図1-12 アプリケーション固有のローカル・ディレクトリ・ブランチの例

図1-12に、アプリケーション固有のローカル・ディレクトリ・ブランチを示します。このツリーのルートはo=AppViewです。このブランチの下にローカル情報(アプリケーション・アクセス制御またはロール)を格納できます(たとえば、cn=User Group,ou=Groups,o=AppView)。

アプリケーションにアーキテクチャの制限があり、共通のpeopleブランチの下のユーザーしか検索できない場合があります。アプリケーションの要件に合せて、設計の目的を変更し、新しいディレクトリ設計をou=Peopleブランチの下のすべてのディレクトリ・ソースにマッピングするようにできます。図1-13に、これがどのように反映されるかを示します。

図1-13 ディレクトリ・マッピングの例

図1-13では、Oracle Virtual Directoryは4つのアダプタを使用するように構成されています。

- アダプタ0は、ディレクトリ・ツリーのルートを形成し、o=AppViewにマッピングされます。このアダプタは、ツリーの仮想ルート、およびアクセス制御グループなどのローカル・エントリを保持します。

- アダプタ1から3は、各ディレクトリ・ソースを新しいアプリケーション・ツリーのou=Peopleブランチの下の位置にマッピングします。

2 Oracle Virtual Directoryアダプタの概要

この章では、Oracle Virtual Directoryアダプタについて説明します。この章の内容は次のとおりです。

- 第2.1項「アダプタとは」

- 第2.2項「LDAPアダプタの概要」

- 第2.3項「データベース・アダプタの概要」

- 第2.4項「ローカル・ストア・アダプタの概要」

- 第2.5項「結合ビュー・アダプタの概要」

- 第2.6項「カスタム・アダプタの概要」

- 第2.7項「アダプタによる仮想ディレクトリ作成の概要」

- 第2.8項「アダプタ・ネームスペースの概要」

- 第2.9項「アダプタ・テンプレートの概要」

2.1 アダプタとは

複数かつ様々なデータ・リポジトリにあるデータの単一の仮想ディレクトリ・ビューを表示するには、Oracle Virtual Directoryをこれらのリポジトリに接続して、データの仮想化とリポジトリ間でのデータのルーティングを可能にする必要があります。Oracle Virtual Directoryは、アダプタを使用して基礎となるデータ・リポジトリに接続します。各アダプタは、特定の親識別名(DN)で識別されるディレクトリのネームスペースを管理します。構成できるアダプタ数に制限はありません。また、アダプタを組み合せてオーバーラップさせることにより、カスタマイズ・ディレクトリ・ツリーを作成できます。

この章の各項では、Oracle Virtual Directoryの各アダプタについて説明します。次に、Oracle Virtual Directoryが提供するアダプタのリストを示します。

- LDAPアダプタ

- データベース・アダプタ

- ローカル・ストア・アダプタ

- 結合ビュー・アダプタ

- カスタム・アダプタ

注意:
アダプタの作成および構成の詳細は、第12章「Oracle Virtual Directoryのアダプタの作成および構成」を参照してください。

2.2 LDAPアダプタの概要

LDAPアダプタは、Oracle Virtual DirectoryをLDAPv2とLDAPv3のディレクトリ、およびMicrosoft Active Directoryに接続します。LDAPアダプタでは、ディレクトリ構造とスキーマの変換がリアルタイムで自動的に行われるため、Oracle Virtual DirectoryはLDAPv2とLDAPv3およびMicrosoft Active Directoryのデータを、仮想ディレクトリのサブツリーとして表すことができます。ディレクトリの最上部で仮想サブツリーのルートとなるようLDAPアダプタを構成し、アダプタが仮想ディレクトリの情報ツリー(DIT)全体を網羅するようにできます。接続先の各LDAPソースごとに1つのLDAPアダプタが必要です。たとえば、4つのレプリカ・サーバーを持つActive Directoryのドメイン・コントローラがある場合、LDAPアダプタを1つのみデプロイし、レプリカの4つのホスト名およびポートをそれぞれリストするように構成します。

Oracle Virtual Directoryを使用すると、レプリカ全体のリクエストのロード・バランシングや、順番でのフェイルオーバーが可能になります。Oracle Virtual Directoryの管理者は、ロード・バランシングの割合を調整できます。

LDAPアダプタには、追加のフォルト・トレランスやパフォーマンスのソリューションが用意されています。これには、特定の検索基準、または可用性や操作タイプ(変更操作と問合せ操作の比較など)に従ったロード・バランシング要件に基づき、LDAP問合せのトラフィックを複数のLDAPディレクトリ・レプリカに転送する機能などがあります。たとえば、何千ものアクティブ・クライアントがある場合、Oracle Virtual Directoryは、数千の問合せを処理する安定した10または20の接続に負荷を減らします。つまり、特にビジー状態にあるクライアントの場合は、定義されたロード・バランシングの目標値に従って、ワーカー・スレッドのそれぞれに負荷を分散します。

高パフォーマンス・シナリオの場合、LDAPアダプタで、限定された一連の接続全体に複数のクライアントからの負荷を分散することによって、ソース・ディレクトリに対する接続負荷を均等にすることができます。LDAPアダプタは、Oracle Virtual Directory、ソース・ディレクトリおよびそのレプリカ間の接続プールを維持することでこれを実現します。これにより、接続処理の負荷が減少し、最大スレッド負荷を超えないようにOracle Virtual Directoryへのトラフィックが制限されて、ソース・ディレクトリの処理が高速になります。

注意:
Oracle Virtual Directoryを使用すると、SSLを使用してLDAPアダプタのインタフェースを保護できます。

これ以降の項では、次に示すLDAPアダプタの追加情報について説明します。

- LDAPアダプタのデプロイ

- LDAPアダプタの読取り、書込み、名前の変更および比較のサポート

- アクセス制御とLDAPアダプタ

- レスポンス制御とLDAPアダプタ

2.2.1 LDAPアダプタのデプロイ

LDAPアダプタは、次に示すものとしてデプロイできます。

- 単純プロキシ

- 仮想ディレクトリ・プロキシ

単純プロキシとしてのLDAPアダプタ

LDAPアダプタは、単純プロキシとして、変換を実行しないように構成できます。これにより、Oracle Virtual Directoryは、可用性およびファイアウォールの問題を解決するディレクトリ・ルーターとして機能します。LDAPアダプタを単純プロキシとして構成するには、アダプタ・ルートとアダプタ・リモート・ベースの構成パラメータを同じ値に設定します。

仮想ディレクトリ・プロキシとしてのLDAPアダプタ

それとは対照的に、あるディレクトリ・ツリーのネームスペースを別の名前に変更して単純なネームスペース・マッピングを提供することが必要な場合があります。アダプタ・ルートおよびアダプタ・リモート・ベース構成パラメータに異なる値を設定すると、暗黙的にネームスペース・マッピングが指定されます。たとえば、プロキシ・ディレクトリのベースou=People,o=Airius.comに、peopleエントリがあるとします。ローカル・ディレクトリは、Airiusエントリへのコールがローカルのpeopleフォルダに表示されるように設計されています。

アダプタ構成パラメータに次の設定を行うとします。

- アダプタ・ルート: ou=Airius,ou=People,dc=YourCompany,dc=com

- リモート・ベース: ou=People,o=Airius.com

この設定でLDAPアダプタを介して問合せを行うと、ou=People,o=Airius.comより下のすべてのエントリのDNが、指定されたDNルートou=Airius,ou=People,dc=YourCompany,dc=comの下にあるように表示されます。

デフォルトで、すべての属性は、Oracle Virtual Directoryを介してプロキシ・ディレクトリからOracle Virtual Directoryクライアントへそのままの状態で受け渡しされます。LDAPアダプタは、DN属性構成パラメータ・リストに指定されたDNを含む属性の基本的なDN変換を実行できます。DN属性パラメータ構成リスト内の属性、およびLDAPアダプタのリモート・ベースDN構成パラメータ値を含むDN値を接尾辞として持つ属性のみが変換されます。たとえば、次の例を検討してみます。

アダプタ・ルートDNはdc=emer,dc=orion,dc=com、リモート・ベースDNはou=emer,o=orion.comです。

dc=emer,dc=orion,dc=comおよびdc=amer,dc=orion,dc=comネームスペース両方にメンバーを持つ(たとえばActive Directory信頼関係のため)dc=emer,dc=orion,dc=comネームスペースのグループ・グループ・オブジェクトは、次のように変換されます。

DN: cn=Group 1, cn=groups,ou=emer,o=orion.com
objectclass: top
objectclass: group
member: cn=Jane Doe,cn=users,ou=emer,o=orion.com
member: cn=Ted Davies,cn=users,dc=amer,dc=orion,dc=com

注意:
LDAPアダプタはネームスペースの外にある値は変換できないため、dc=amer,dc=orion,dc=com値は変更されていません。
通常は、DN属性値がディレクトリ・ネームスペース内に存在するか、ディレクトリに追加される前に値が適切に変換されるため、これは一般的なシナリオではありません。

このようなシナリオが発生した場合は、カスタムのマッピング・スクリプトを使用して、アダプタのルート・ネームスペースの外にある値を変換します。また、Oracle Virtual Directoryは、リモート・ディレクトリのデータがマッピングおよびプラグインを使用してOracle Virtual Directoryに渡される際に、その場で属性を変換することもできます。

2.2.2 LDAPアダプタの読取り、書込み、名前の変更および比較のサポート

LDAPアダプタでは、読取り、追加、変更、削除および名前変更の機能が完全にサポートされます。LDAPの名前変更操作のサポートには、アダプタ間の名前変更、つまり移動の機能も含まれます。アダプタ間で行われるLDAP名前変更(すなわちmove)のLDAPv3 moddn機能では、切取りと貼付けが行われます。このトランザクションを安全に行うために、Oracle Virtual Directoryによって移動先ディレクトリへの追加が正常に行われたことが確認されるまで、元のエントリは削除されません。移動先ディレクトリでの追加が失敗した場合、操作は中断され、移動先ディレクトリからエラーが戻されます。

アダプタ間またはプロトコル間でサポートを提供するために、LDAPの比較操作は、自動的にLDAP取得またはLDAPバインド操作に変換されます。

2.2.3 アクセス制御とLDAPアダプタ

Oracle Virtual Directoryのアクセス制御は、次の2つのレベルで適用されます。

- Oracle Virtual Directoryのアクセス制御

- リモートLDAPサーバーのアクセス制御

Oracle Virtual Directoryのアクセス制御

Oracle Virtual DirectoryではIETF RFC 2820がサポートされ、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)に基づいてアクセス制御も実行されます。この草案では、RFC 2820をベンダーに中立的に実装する方法が指定されています。Oracle Virtual Directoryでは、これらの標準および草案に準拠したアクセス制御がすべてのアダプタで同様に実行されるため、一貫したセキュリティ実装が実現されます。詳細は、「Oracle Virtual Directoryのアクセス制御の概要」を参照してください。

リモートLDAPサーバーのアクセス制御

Oracle Virtual DirectoryはLDAPクライアントとして機能するため、LDAPディレクトリなどのリモート・アダプタ・ディレクトリでのアクセス制御に従う必要があります。この動作方法は、ベンダーのアクセス制御の実装によって異なります。

Oracle Virtual Directoryは、プロキシ設定されたディレクトリ・サーバーに接続すると、独自の資格証明またはバインドされているエンド・クライアントの資格証明を使用できます。

- Oracle Virtual Directoryによってソース・ディレクトリにユーザー資格証明が渡された場合は、エンドツーエンドのユーザー・コンテキスト・アクセス制御が有効になります。これにより、リモート・サーバーで、バインドされたエンド・クライアントの資格証明が認証されます。

- Oracle Virtual Directoryによって独自の資格証明が渡される場合、Oracle Virtual Directoryは、プロキシ設定されたディレクトリのサーバー資格証明に対して強制されるアクセス制御の対象となると同時に、独自のユーザー固有アクセス制御を実行する必要があります。

LDAPアダプタの資格証明の引渡し構成パラメータに設定する値に応じ、エントリがLDAPアダプタによって表されるユーザーのパスワードを使用してバインド・リクエストを処理する際に、Oracle Virtual Directoryは次のいずれかの方法で資格証明を検証できます。

- 資格証明の引渡し構成パラメータが「常時」または「バインドのみ」に設定されている場合は、Oracle Virtual Directoryにより、指定されたユーザーDNおよびパスワードが、プロキシ設定されたLDAPディレクトリに渡されます。プロキシ設定されたディレクトリは、ユーザーが入力したパスワードの妥当性の判別を行います。リモート・パスワード検証の成功または失敗は、透過的にユーザーに戻されます。

- 資格証明の引渡し構成パラメータが「なし」に設定されている場合、Oracle Virtual Directoryはアダプタで指定されたアカウントを使用してリモート・ディレクトリに接続し、暗号化されたパスワード値を取得します。

注意:
アダプタ構成で指定されたアカウントは、プロキシ設定されたディレクトリによって暗号化されたパスワード値へのアクセス権が付与されている必要があります。それ以外の場合は、バインドが失敗として処理されます。暗号化された値がOracle Virtual Directoryに戻されると、Oracle Virtual Directoryでは、ユーザーのパスワードが暗号化され、それがプロキシ設定されたサーバーから戻された暗号化済の値と比較されます。一致すると判断された場合は、Oracle Virtual Directoryによって正常なバインドが戻されます。
ユーザーが証明書のバインドを実行する場合は、資格証明の引渡し設定の「なし」が暗黙的に指定されます。この場合は、Oracle Virtual Directoryにより、リモートのLDAPプロキシからクライアントの公開鍵を取得してクライアント資格証明が確認されます。

2.2.4 レスポンス制御とLDAPアダプタ

LDAP制御を使用するLDAPクライアント・アプリケーションでの相互運用性を簡素化するために、LDAPアダプタと操作モジュールを構成して、JNDI(存在する場合)からレスポンス制御をすべての操作で取得してから、これらの制御をクライアントに戻すことができます。これらのレスポンス制御は、仮想環境で実際にどの制御がサポートされているかに関してよりよい情報を提供します。

リモートLDAPサーバーに伝播させるリクエスト制御を含めたり除外したりするには、LDAPアダプタ構成にオプションのallowServerSupportedパラメータを追加します。除外リストのリクエスト制御は、リモート・サーバーに送信されたリクエストから除外されます。

allowServerSupportedパラメータは2つの値を持ちます。

- false(デフォルト)。すべてのリクエスト制御をリモート・サーバーに渡します。

- true。リモート・サーバーのRootDSEのsupportedControlにある制御のみを渡し、リクエスト制御を含めたり除外するオプションは無視します。

2.3 データベース・アダプタの概要

データベース・アダプタは、すべての機能が備わったLDAPからJava Database Connectivity(JDBC)へのゲートウェイで、すべてのLDAP操作(追加、バインド、削除、取得、変更、名前の変更)を、プリコンパイルされた同等のSQL文コードに変換できます。データベース・アダプタは、JDBC-ODBCライブラリを介してJDBCまたはOpen Database Connectivity(ODBC)をサポートするほとんどのデータベースに接続できます。データベース・アダプタではJDBCクラス・ライブラリを使用して、LDAP検索を実行するためのデータベースへの接続を形成します。必要なデータベース・ライブラリは、一般的にはデータベース・ディストリビューションとともに提供されるか、データベース・ベンダーを介して入手できます。

データベース・アダプタの機能

次に、データベース・アダプタの機能の一部を示します。

- ソース・データベースの変更が不要。

- 表および列の柔軟なマッピング。LDAPオブジェクト・クラスを表から導出する方法が定義されているマッピングを使用して、ほぼすべてのLDAPオブジェクトをその場で構成できます。

- リクエストを簡略化するための接続プール。

- Oracle Virtual Directory内、またはRDBMSサーバーのビューを使用して実行される複数表の結合。

- プライマリ・キーとグルーピングを使用した複数の値を持つ属性のマッピング

- 単一のアダプタ接続内に複数のオブジェクト・クラスおよび階層を構成する機能。

データベース・アダプタの考慮事項

データベース・アダプタを使用する際は、次の点に注意してください。

- LDAP操作ではトランザクションがサポートされていないため、データベース・アダプタでは、一度に1つの表が変更されます。

- LDAPでは複数値の属性がサポートされていますが、データベース表でサポートされているのは各列に1つの値のみです。データベース表に複数値の属性を持つエントリを作成するには、データベース・アダプタで表を非正規化し、エントリの属性の各値に対して行を1行ずつ作成します。

- データベース・アダプタは、Oracle Virtual Directoryの資格証明のみを使用してデータベースに接続します。LDAPアダプタのように、クライアント・ユーザーの資格証明を通過させることはできません。

- データベース・アダプタでサポートされているのは通常のSQL操作のみで、デプロイ固有のストアド・プロシージャはサポートされていません。データベースのストアド・プロシージャ統合をサポートする場合は、データベース・アダプタとともにプラグインを使用することを検討してください。

- ルートのアダプタ・ネームスペースであるDNの一部を除き、エントリのDNを形成するすべてのコンポーネントがデータベース表に含まれている必要があります。

- 複数の属性が1つのデータベース列にマッピングされている場合、Oracle Virtual Directoryにより戻される属性は1つのみです。この問題は、カスタム・マッピング・スクリプトを作成することで解決できます。

- データベース表のフィールドに格納されているパスワードを検証するなど、データベース・アダプタを使用してクライアント・バインドを管理する場合は、データベースのCHAR/VARCHARフィールドにパスワードを格納し、データベース・アダプタにデータベース・パスワードのマップ・マッピングをデプロイする必要があります。

- 検索フィルタで使用された場合、データベース・アダプタで現在サポートされているのは、電話番号値の完全一致のみです。データベース・アダプタを使用して電話番号の検索をサポートしている場合は、問合せを送信する前に、プラグインを使用して入力値を正規化し、LDAP標準に準拠していないLDAPアダプタが継続して機能するようにできます。

- データベース・アダプタでは、複数値のRDNはサポートされていません。

これ以降の項では、次に示すデータベース・アダプタの追加情報について説明します。

- アクセス制御とデータベース・アダプタ

- JDBC Javaクラス・ライブラリ

- データベース・アダプタのマッピングの概要

2.3.1 アクセス制御とデータベース・アダプタ

データベース・アダプタは、Oracle Virtual Directoryの固有のアクセス制御に加えて、リモート・データベースに存在するアクセス制御にも関係します。LDAPアダプタとは異なり、認証されたユーザーの資格証明をOracle Virtual Directoryからリモート・データベースに渡すことはできません。つまり、Oracle Virtual Directoryは、JDBCクライアントとして、JDBC接続情報で指定されるアダプタのデータベース・ユーザー名によって定義される、アダプタのRDBMSサーバーが認証する機能に対して制約を受けます。すべての問合せは、データベース・ユーザー名フィールドに指定されたアカウントを使用して実行されます。

Oracle Virtual Directoryでは、データベースから戻された値をユーザーが指定した値と比較して、パスワード検証が実行されます。ハッシュまたは暗号化された形式でパスワードが格納される場合は、その値の接頭辞として適切なハッシュ修飾子({crypt}、{sha}、{ssha})を使用する必要があります。この接頭辞により、Oracle Virtual Directoryに対して、パスワードの検証時に使用するパスワード・ハッシュの比較アルゴリズムのタイプが指定されます。この接頭辞はLDAPの表記規則であるため、テキスト・ファイルには存在しない可能性があります。接頭辞を割り当てるには、アダプタ・マッピングを使用します。

Oracle Virtual Directoryでは、独自の標準ベースのLDAPセキュリティおよびアクセス制御モデルが、すべてのアダプタおよびアダプタ・タイプに同時に適用されます。

2.3.2 JDBC Javaクラス・ライブラリ

特定のJDBCドライバを使用するには、その前に「Oracle Virtual Directoryサーバーへのライブラリのロード」の説明に従って、そのドライバ・ファイルをOracle Virtual Directoryにロードする必要があります。ドライバ・ファイルは、各製造業者からダウンロードできます。ドライバの検出の詳細は、http://www.oracle.com/technetwork/index.htmlのOracle Technology Networkを参照してください。

JDBCライブラリがOracle Virtual Directoryにロードされたら、事前定義済のデータベース・タイプを選択するか、製造業者によって定義されたJDBC URLを指定して、新しいデータベース・アダプタ接続を定義できます。

データベース・アダプタでは、次のデータベースの事前定義済JDBC URLがサポートされます。

- Hypersonic

- IBM DB2

- Microsoft SQL*Server

- MySQL

- OpenBase

- Oracle

- PostgreSQL

- Sybase

- Sun ODBC-JDBC Bridge

2.3.3 データベース・アダプタのマッピングの概要

次に、データベース・アダプタの使用時に、リレーショナル・データ構造を階層ディレクトリにマッピングする際に関連する事項のリストを示します。

- エントリ名の形成

- マップされる表の索引

- 複数表への書込み

- 複数値属性

- 検索および複数行オブジェクト

- 表への書込み

- カスケード削除

- 部分文字列検索

エントリ名の形成

エントリ名の一部として使用するすべてのデータベース・フィールド(アダプタのルートであるDNの一部分を除く)は、データベース・アダプタ経由でOracle Virtual Directoryにマッピングおよび戻される表の行に含まれている必要があります。たとえば、ユーザー・オブジェクトのDNに共通名(cn)と組織単位(ou)の両方が含まれる階層(cn=Joe User,ou=Marketingなど)を作成するには、cnとouの両方がエントリの一部であることが必要です。

純粋なLDAPでは、ou属性は親エントリの一部であるため、本来は必要ありません。データベースは階層的ではないため、これによって、階層を定義するために多くの新しいメタデータを作成して管理せずに、複数レベルのDNを生成できます。

マップされる表の索引

データベース・アダプタの使用時のパフォーマンスを向上させるために、マップされるデータベース表に適切な索引を作成することをお薦めします。たとえば、employeeという表にsalaryおよびemployeenameという列があり、cn名がemployeenameにマップされるとします。パフォーマンスを向上させるには、次のようにemployeenameの関数索引を作成します。

create index upper_employee on employee (upper(employeename));

複数表への書込み

複数表の書込みは、単一のデータベース・アダプタを介して直接行うことはできません。これは、複数表の列を表示しているときには表示の更新を直接実行できないという、データベースで発生する制限と同じです。

Oracle Virtual Directoryでは、Oracle Virtual Directoryの結合ビュー・アダプタを使用することで、この制限を回避できます。複数のデータベース・アダプタを作成し(一般的に表ごとに1つ)、アダプタ間の関係を定義すると、複数の表を介して構成されたエントリへのOracle Virtual Directoryによる書込みが可能になります。

複数値属性

データベースでは、一般的に表の単一の行にある単一フィールドに複数の値を使用できません。配列タイプがサポートされる例外もありますが、これらのデータ・タイプは相対的に制限される傾向にあります。一部では、カンマやパイプ(|)などのデリミタを使用してフィールド内のデータ(アカウントのフラグなど)を区切ることで、複数の値を行に挿入するということが行われています。

従来型のデータベース設計では、複数の値を持つフィールドは、正規化して追加の表にすることが求められます。データ・ウェアハウスの一部であるデータベースでは、すべてのフィールドのすべての順列を非正規化された表に配置するという、異なる方法が採られる場合があります。

Oracle Virtual Directoryでは、通常どちらかのモデルがサポートされます。一般的にOracle Virtual Directoryでは、指定されたRDN属性を使用して複数の行がグループ化されます。Oracle Virtual Directoryのスキーマが複数値をサポートする場合、Oracle Virtual Directoryはこれらの行をグループ化して、結合エントリを形成します。

たとえば、次の例に示すような、グループ・メンバーシップの定義に使用する表があるとします。最初の列にはグループ名が記載されています。メンバーは、次のように2番目の列で定義されています。

GroupName

Member

My First Group

cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com

My First Group

cn=Alice Wing,cn=Users,dc=Oracle,dc=com

My First Group

cn=Jim Smith,cn=Users,dc=Oracle,dc=com

Administrators

cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com

Administrators

cn=Jim Smith,cn=Users,dc=Oracle,dc=com

SQLでは、各グループのメンバーを表示するSQL問合せは次のようになります。

select * from grouptable group by groupName;

データベース・アダプタを介してプロキシ設定された場合、Oracle Virtual Directoryはデータを次のように戻します。

dn: cn=My First Group,ou=Groups,dc=Yourcompany,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: My First Group
uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com
uniquemember: cn=Alice Wing,cn=Users,dc=Oracle,dc=com
uniquemember: cn=Jim Smith,cn=Users,dc=Oracle,dc=com

dn: cn=Administrators,ou=Groups,dc=Yourcompany,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: Administrators
uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com
uniquemember: cn=Jim Smith,cn=Users,dc=Oracle,dc=com

この結果では、グループ名は一意の単一値にまとめられ、グループのメンバーは複数値のuniquemember属性に結合されています。

検索および複数行オブジェクト

正規化および非正規化された表に対する検索がサポートされます。必要に応じてデータベース・レベルの結合を構成する以外は、何も行う必要はありません。最も人気のあるユースケースのために、データベース・アダプタの現在の設計では、複数値属性が検索される場合、エントリの一部として一致する行のみがアダプタによって返されることに留意してください。正規のLDAP条件では、属性のすべての値が正常に返されます。たとえば、次のような検索を行うとします。

ldapsearch -b "cn=administrators,ou=groups,dc=yourcompany,dc=com" -s
base"(uniquemember=Paul Jacobs,cn=Users,dc=Oracle,dc=com"

通常のLDAPサーバーでは、次の結果が期待されます。

dn: cn=Administrators,ou=Groups,dc=Yourcompany,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: Administrators
uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com
uniquemember: cn=Jim Smith,cn=Users,dc=Oracle,dc=com

かわりに、データベース・アダプタでは、次の結果が返されます。

dn: cn=Administrators,ou=Groups,dc=Yourcompany,dc=com
objectclass: groupofuniquenames
objectclass: top
cn: Administrators
uniquemember: cn=Paul Jacobs,cn=Users,dc=Oracle,dc=com

データベース・アダプタの結果では、他のメンバーが欠落しています。一見すると標準的でないこの動作は意図的なものであり、グループなどの大規模なデータベース・エンティティのメンバーシップをテストする際に、高性能の検索を容易に実行できるように設計されています。これらのシナリオでは、ほとんどの場合、特定の人物がメンバーであるかどうかを判断する必要があります。そのため、グループ全体が送信されるのではなく、交差グループがアダプタによって返されます。

標準のLDAP動作が期待されている場合、uniquememberフィルタ条件を(objectclass = *)置き換えるマッピングをアダプタに追加できます。グループ情報が返された後、見つかった結果がフィルタに一致していることを確認するテストを、マッピングを使用して実行できます。

注意:
DBアダプタの検索フィルタでの特定の「NOT」条件は、属性が複数の値を含んでいる場合には正しく動作しません。たとえば、LDAPエントリのデータベース属性telephonenumberに、次の3つの値が含まれているとします。

telephonenumber=44 1902 777777
telephonenumber=44 1902 888888
telephonenumber=44 1902 999999

これらの値のいずれか(たとえば、"!(telephonenumber=44 1902 999999)")を含む「NOT」フィルタを使用してLDAPエントリの検索を実行すると、telephonenumberエントリが返されてしまいます。

表への書込み

複数表オブジェクト(正規化された表)への書込みは、データベースの設計に基づいて属性をそれぞれの表に分割する結合ビュー・アダプタ経由で実行する必要があります。これが必要となるのは、データベース設計に一般的なガイドラインがある一方で、それぞれの顧客のデータベースが異なり、結合された表間の関係が大きく変わる可能性があるためです。

既存の重要な表を使用する顧客は、これらの表の更新制御の一部としてストアド・プロシージャも使用します。これらはAPIコールと類似しており、作成および呼び出される方法はそれぞれのデータベースに固有です。APIコール自体は顧客独自のものです。Oracle Virtual Directoryでは、プラグイン・システムを使用することでストアド・プロシージャをサポートします。

Oracle Virtual Directoryでは非正規化された表に直接書き込むことができます。これらの表にはそれぞれのフィールド値が格納され、エントリのRDNとして使用されるフィールドに関連するエントリで使用されます。追加、変更、削除などのすべての操作がサポートされます。

変更操作では、LDAPにおける変更-置換の動作は、既存の属性値を削除してから新しい属性値を追加する方法で行われます。この動作は、SQLの挿入、更新、および削除の複合セットではなく、1つのSQL削除および1つのSQL挿入に変換されます。対応が難しい可能性があるのは、挿入および削除によりデータベース内で他のアクションがトリガーされる正規化された表を含むデータベースです。このような場合は、変更-置換操作を処理するためのプラグインを作成する必要があります。

ほとんどの顧客は、変更に直接SQLアクセスを使用しないか、読取りのみに複数の値を使用する、または変更-追加と変更-削除のみを直接使用するため、このような問題が発生することはありません。たとえば、大規模なグループの問題を解決する顧客が、Oracle Virtual Directoryを使用してデータベースにグループを格納しているとします。グループのほとんどのメンバーシップ変更は、置換ではなく追加と削除です。

カスケード削除

「表への書込み」の説明で示した問題で、データベース・アダプタの使用時に最も注意すべき問題は、カスケード削除を使用するデータベースへの直接書込みを行うデータベースの処理が、Oracle Virtual Directoryによっていつ行われるかということです。カスケード削除では、1つの表で削除を行うと、データベースによりストアド・プロシージャがアクティブ化され、それによって他の表でも削除が発生します。カスケード削除を使用した場合、変更-置換によって、データベース・アダプタが直接処理を行う表の外側で削除がトリガーされる可能性があります。これが発生するのは、既存の値を削除するSQL DELETEおよび新規の置換値を追加するSQL INSERTを実行する単一のトランザクションが、データベースによって送信されるためです。

データベースのトリガーが単一の値を持つ表に基づいており、複数の値を持つフィールドが他の表に正規化されている場合は、これは問題になりません。変更対象のエントリに関連付けられている単一の行が表に含まれている場合の置換時に、Oracle Virtual DirectoryによってDELETE-INSERTの組合せではなくUPDATEが実行されます。

注意:
データベース・アダプタは、LDAP更新時にマップされていないデータベース列値をNULLに設定します。この制限事項は、Oracle Virtual Directoryの将来のバージョンで解消される予定です。
この制限事項に対処するには、すべての列をマップする(かつ、ルーティング・ルールを使用して検索結果に表示されないようにする)か、表を更新トリガーが設定されたビューにマップします。

部分文字列検索

アプリケーションが部分文字列検索を使用する場合、データベース・アダプタにマッピングされる属性は、VARCHARデータベース構文としてマッピングされる必要があります。これがSQLが部分文字列検索をサポートするための唯一の方法です。

2.4 ローカル・ストア・アダプタの概要

ローカル・ストア・アダプタを使用すると、可用性を高くする必要のない少量のデータをローカルのフラット・ファイルに格納できます。

次に、最も一般的なローカル・ストア・アダプタの使用方法を示します。

- クライアント・アプリケーションに表示する必要はあるが、ほとんど変更されず、可用性を高くする必要もない少量のデータを格納する必要がある場合。Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティ統合の一部としてOracle Internet Directoryをエミュレートするために、Oracle Virtual Directoryによって使用されるベース・エントリなどです。

- 開発者は、企業ディレクトリを使用するアプリケーションを作成するが、現在は企業ディレクトリ・サービスへのアクセス権がない場合に、ローカル・ストア・アダプタを使用できます。この場合、開発者はローカル・ストア・アダプタを使用して開発プロセスの一部としてテスト・エントリを格納し、アプリケーションを本番で使用できるようになったら、Oracle Internet Directoryなどの企業ディレクトリ格納システムに後から移行します。

注意:
Oracle Virtual Directoryの値は仮想化およびプロキシ・サービス用で、ディレクトリ・ストア用ではありません。可用性の高いディレクトリ格納システムが必要な場合には、Oracle Virtual Directoryのローカル・ストア・アダプタではなく、Oracle Internet Directoryを使用することをお薦めします。

- 複数のアダプタがあり、それらがすべてディレクトリ・ツリーのブランチである際に、ディレクトリ・ツリー最上位の単一のエントリを保持する場合。次に例を示します。
次の2つのLDAPアダプタが構成されているとします。

- ou=staff,dc=mycompany,dc=com

- ou=customers,dc=mycompany,dc=com

ローカル・ストア・アダプタを使用して、その他のアダプタの上にdc=mycompany,dc=comの最上位のエントリを格納できます。Oracle Virtual Directoryにはこの最上位のエントリは必要なく、大部分のLDAPクライアントに透過的ですが、一部のLDAPクライアント・アプリケーション、特にグラフィカル・ユーザー・インタフェース・デスクトップのLDAP管理クライアントでは、サーバーの最上位にエントリが指定されていないと、誤ったエラー・メッセージが戻される場合があります。

Oracle Virtual Directoryの各サーバーに複数のローカル・ストア・アダプタをデプロイできますが、ほとんどのサーバーでデプロイされるのは1つのみです。複数のローカル・ストア・アダプタをデプロイする最も一般的な理由は、バックアップおよびリカバリを考慮して、異なるファイルにディレクトリ・ツリーの異なる部分を格納することです。たとえば、ディレクトリ・ツリーの相対的に静的なブランチは、頻繁にバックアップする必要はありません。

エンタープライズ・ユーザー・セキュリティ(EUS)でOracle Virtual Directory高可用性を採用したい場合は、EUSはローカル・ストア・アダプタ内のデータのみを検索することに注意してください。EUSは実際にはこのアダプタに格納されたデータを更新しないため、EUSに関連したローカル・ストア・アダプタのレプリケーションまたは同期は構成する必要はありません。

ローカル・ストア・アダプタ(および他のアダプタ)の構成を別のOracle Virtual Directoryサーバーにコピーするには、syncovdconfigコマンドを使用します。syncovdconfigコマンドの使用方法の詳細は、第9.7項「syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー」を参照してください。

ローカル・ストア・アダプタのデータ同期では、エントリを各Oracle Virtual Directoryインスタンスのローカル・ストア・アダプタにロードするか、データを1つのインスタンスのみにロードした後、ローカル・ストア・アダプタ内のデータを同期するためにoidcmprecツールを使用します。詳細は、第2.4.1項「ローカル・ストア・アダプタ・データの移行」を参照してください。

2.4.1 ローカル・ストア・アダプタのデータの移行

Oracle Internet Directoryのoidcmprecツールを使用して、ローカル・ストア・アダプタから別のリポジトリにLDAPデータを移行できます。

注意:
ローカル・ストア・アダプタ・データの移行には、oidcmprecツールのcompareおよびreconcile操作のみサポートされています。

この項では、oidcmprecを使用したローカル・ストア・アダプタからのデータの移行の概要を説明します。

関連項目:
Oracle Internet Directoryのoidcmprecツールの詳細は、次のドキュメントを参照してください。

- Oracle Internet Directory管理者ガイド

- Oracle Identity Managementリファレンス

この項には、次のシナリオでoidcmprecを使用して、ローカル・ストア・アダプタからデータを移行する方法の例が記載されています。

- 2つのローカル・ストア・アダプタ間における最初の一方向データ移行

- 2つのローカル・ストア・アダプタ間での同期

- ローカル・ストア・アダプタからOracle Internet Directoryへのデータ移行

注意:

- oidcmprecコマンドを実行すると、ソース・ディレクトリと宛先ディレクトリの両方のレプリケーションDNパスワードを要求されます。

- Oracle Virtual Directoryでは、orclguidの変更は許可されません。oidcmprecを使用して2つのディレクトリを比較する際には、orclguidを除外することをお薦めします。

- oidcmprecツールは、宛先ソース・ディレクトリでエントリを見つけられない場合、orclguidを使用してソース・ディレクトリに対してグローバル検索を実行することで適切なエントリを見つけようと試みます。これによって、Oracle Virtual Directoryが検索される場合に問題が発生します。複数のアダプタでOracle Virtual Directoryが構成されている場合、ldapsearchesがそれらのすべてのアダプタに実行されます。それらのアダプタに非アクティブなものがあるとエラーが発生することがあります。
oidcmprecツールは、それがOracle Virtual Directoryで検索しているかどうかを検出でき、すべてのOracle Virtual DirectoryアダプタrootDNを検索します。oidcmprecツールは、最適なOracle Virtual DirectoryアダプタrootDNをldapsearchのベースDNとして使用し、それによって検索が1つのアプリケーションのみに制限されます。

- oidcmprecツールを使用して、ローカル・ストア・アダプタ内のデータを2つ目のサーバーにコピーできますが、それは1回かぎりの操作です。oidcmprecツールは、ローカル・ストア・アダプタの内容を同期した状態に保てないため、ローカル・ストア・アダプタの内容が変更されるたびにコールする必要があります。

2つのローカル・ストア・アダプタ間における最初の一方向データ移行

たとえば、次のユースケースがあるとします。2つの異なるホストmyhost1およびmyhost2で、2つのOracle Virtual Directoryサーバーが稼働しているとします。各ホストにはローカル・ストア・アダプタ(LSA)が、myhost1にはLSA1、myhost2にはLSA2となるように構成されています。LSA1のc=USの下にあるデータを、初めてLSA2に移行する必要があります。この移行を実行するには、次のコマンドを実行します。

oidcmprec operation=reconcile source=myhost1:port
destination=myhost2.port base="'c=US'" scope=subtree exclattr=orclguid
sbinddn='"cn=orcladmin"'
dbinddn='"cn=orcladmin"'

注意:
一方向のデータ移行には、oidcmprecのreconcile操作を使用することをお薦めします。

2つのローカル・ストア・アダプタ間での同期

たとえば、次のユースケースがあるとします。「2つのローカル・ストア・アダプタ間における最初の一方向データ移行」で説明されているように、あるOracle Virtual Directory(myhost1など)のローカル・ストア・アダプタ(LSA1など)から、異なるOracle Virtual Directory(myhost2など)の別のローカル・ストア・アダプタ(LSA2など)に初めてデータを移行しました。後で、2つのローカル・ストア・アダプタ間でc=USの下にあるデータを同期することが必要になるとします。ソースからc=USの下にあるすべてのデータを移行する必要はありません。かわりに、oidcmprecツールのRFC 2254に基づくタイムスタンプ・ベースのフィルタを使用して、最近変更されたデータのみを移行します。タイムスタンプ・フィルタに指定された値よりも後に変更された、ソース内のすべてのデータが宛先に移行されます。

注意:

- 2つのローカル・ストア・アダプタ間でデータの同期をとる場合、一方向データ移行のみサポートされています。つまり、最初にLSA1(ソース)のデータをLSA2(宛先)と同期させた場合、以降はLSA2のデータをLSA1と同期しないでください。

- データを移行するには、ターゲット(宛先)のOracle Virtual Directoryが稼働している必要があります。

このタイプの移行を実行するには、次のコマンドを実行します。

oidcmprec operation=reconcile source=myhost1:port
destination=myhost2.port base="'c=US'" scope=subtree
filter='("modifytimestamp>=point_in_time")' exclattr=orclguid

ローカル・ストア・アダプタからOracle Internet Directoryへのデータ移行

oidcmprecを使用して、ローカル・ストア・アダプタからOracle Internet Directoryにデータを移行することもできます。次のコマンドは、myhost1で稼働しているOracle Virtual Directoryのローカル・ストア・アダプタのc=USにあるデータを、myhost2で稼働しているOracle Internet Directoryに移行します。

oidcmprec operation=reconcile source=myhost1:OVD_port
destination=myhost2.OID_port base="'c=US'" scope=subtree exclattr=orclguid

2.5 結合ビュー・アダプタの概要

結合ビュー・アダプタは、リレーショナル・データベースの表結合のように、複数の異なるデータ・ソースを統合された1つのLDAPビューに結合します。結合ビュー・アダプタは、Oracle Virtual Directoryのその他のアダプタのように、基礎となるデータ・リポジトリには接続せず、1つ以上の既存のアダプタ上にデータをアセンブルします。結合ビュー・アダプタは、アダプタ間の結合関係(ジョイナとも呼ばれる)を定義することで、2つ以上のデータ・リポジトリを結合します。

結合ビューは動的で、プロキシ・ソース間の同期は実行しません。結合ビューの目的は、マージしたデータをLDAPクライアントにリアルタイムに提供することです。結合アダプタは、分割プロファイル(1つのエントリのデータが2つ以上のソースに分割されるケース)の問題を解決します。たとえば、結合アダプタを使用して、ユーザーのLDAPエントリと、人事管理データベース内のこのユーザーの役職をリンクさせることができます。結合アダプタは、スタッフのLDAPと顧客のLDAPなどの複数の異なるソースの検索をアプリケーションに許可する問題の解決には使用されません。この問題は、これらのソースを共通ルートの下に仮想ブランチとして見せることによって解決できます。

次に、結合ビュー・アダプタの機能の一部を示します。

- 複数のアダプタおよびオブジェクト・クラスの属性を1つの新しい仮想エントリにマージできます。

- 検索時に各アダプタが表示用の特定の属性を選択できます。

- 変更操作時に各アダプタが属性の変更を適用できます。

- ネストした結合ビュー・アダプタがサポートされます。プライマリ・アダプタまたは結合アダプタを、別の結合ビュー・アダプタにすることが可能です。

- 再帰的結合ビュー・アダプタがサポートされます。自身との結合が行われ、結合エントリがなくなると再帰的な構造も終了します。

- 各結合アダプタ・エントリが戻されると、結合ビュー・アダプタにより、結合アダプタのどのエントリが統合エントリの形成に使用されたかを示す属性値vdejoindnが追加されます。

次に、結合ビュー・アダプタの重要事項を示します。

- 結合ビュー・アダプタのプライマリ・アダプタ

- 結合ルール

- 結合ビュー・アダプタのルーティング

- 結合ビュー・アダプタの検索

- 結合ビュー・アダプタの属性の複製

結合ビュー・アダプタのプライマリ・アダプタ

各結合ビュー・アダプタでは、プライマリ・アダプタが1つのみ識別される必要があります。プライマリ・アダプタは、ディレクトリ・ツリー・エントリの作成および検索に使用されます。結合ビュー・アダプタは、プライマリ・アダプタで検出された各エントリを取得し、定義された結合関係に従って別のアダプタのエントリと結合することで動作します。エントリが結合ビュー・アダプタに存在するためには、結合ビュー・アダプタのプライマリ・アダプタに存在する必要があります。デフォルトで、プライマリ・アダプタは認証資格証明の処理に使用されます。任意の結合アダプタもバインディングに使用されます。

結合ルール

各結合ビュー・アダプタには、プライマリ・アダプタのエントリと結合アダプタのエントリ間の結合関係を指定するゼロ以上の結合ルールがあります。結合ルールは、結合関係、結合しているアダプタ、およびuserprincipalname=uid検索基準などのSimple結合構成情報で構成されています。結合ルールは、定義された順序で処理され、累積的に実行されます。各結合が処理されると、結果の結合エントリが次の結合関係に使用されます。

詳細は、「結合関係」を参照してください。

結合ビュー・アダプタのルーティング

結合ビュー・アダプタは、いくつかのルーティング属性(特にルーティング取得可能およびルーティング格納可能)に依存して、各アダプタのどの属性が取得可能かつ編集可能かを判断します。可視性のルーティング属性を使用すると、結合ビュー・アダプタを形成するプライマリ・アダプタおよび結合アダプタを非表示にできます。

結合ビュー・アダプタの検索

デフォルトでは、結合ビュー・アダプタは、プライマリ・アダプタのみを検索します。ただし、ForkJoinプラグインを使用すると、結合されたソースの属性全体を検索できます。

関連項目:
詳細は、「ForkJoinプラグイン」を参照してください。

2つのアダプタ、AとBがあるとします。アダプタAはプライマリ・アダプタであり、uid、sn、およびcnが含まれています。アダプタBには、uid、mail、およびemployeeNumberが含まれています。アダプタAをプライマリ・アダプタとし、アダプタBをセカンダリ・アダプタとして結合ビュー・アダプタCを作成し、uidを検索します。Oracle Virtual DirectoryはアダプタAを検索してそのエントリを見つけ、アダプタBを検索して一致する結合エントリをすべて見つけます。この検索では、uid、sn、cn、mail、およびemployeeNumberを含むエントリが戻されます。

クライアントがすべての属性を戻すようリクエストした場合、つまり検索操作後に属性のリストが残らない場合、Oracle Virtual Directoryは結合アダプタからすべての属性をリクエストします。ただし、クライアントが戻される属性のリストを指定した場合、それらの属性は結合条件の属性を使用して内部的に拡張され、Oracle Virtual Directoryは、結合アダプタの属性のそのリストのみをリクエストします。パフォーマンス上の理由から、結合条件の属性ではなく、クライアントが指定した属性のみが戻されます。Oracle Virtual Directoryであるか、結合ビュー・アダプタを使用しているかにかかわらず、LDAPサーバーから戻される属性の数を制限すると、パフォーマンスが向上します。

結合ビュー・アダプタの属性の複製

複数のデータ・ソースに同じ名前の属性が複数存在し(異なる2つのLDAPアダプタの2つのuidなど)、特定のアダプタからのみ属性値を取得するよう結合ビュー・アダプタを構成している場合、結合ビュー・アダプタにより表示されるのは単一の値のみです。特定のアダプタの属性のみを表示するには、属性を表示しないアダプタの「ルーティング」設定の「取得可能な属性」フィールドに、その属性がリストされていないことを確認してください。オプションで、マッピングまたはプラグインを使用して特定の属性を非表示にできます。

2.5.1 一般的な結合ビュー・アダプタのデプロイ

結合ビュー・アダプタは、動的かつリアルタイムにデータの結合ビューを提供します。同期は不要で、特に、次に示すような一般的なID管理タスクの実行に便利です。

- Microsoft Active Directoryとのパスワードの統合
主要なユーザーIDリポジトリとしてMicrosoft Active Directoryを使用している場合には、結合ビュー・アダプタを使用することで、面倒なパスワード統合プロセスを行わずにすみます。結合ビュー・アダプタを使用すると、2つを結合して、Active Directoryからその他のアプリケーション・ディレクトリにパスワード情報をエクスポートする必要がなくなります。結合ビュー・アダプタを使用すると、Active Directoryのデータを使用したバインドを除き、クライアントにアプリケーション・ディレクトリ・データのビューが提供されます。

- データ統合
結合ビュー・アダプタを使用すると、データベースおよびディレクトリを含む複数のデータ・ソースを結合し、Oracle Virtual Directoryでユーザーの統合ビューを作成できます。

- アプリケーションの統合
一部のアプリケーション(特にカスタム・アプリケーション)には独自のデータ要件があり、多くの場合、それらの独自の要件に対応するために企業のディレクトリ・スキーマを変更するのは困難です。結合ビュー・アダプタを使用すると、企業ディレクトリのデータを使用し、かつ別のディレクトリまたはローカル・ストア・アダプタでカスタム・アプリケーションの独自のデータを管理できます。

2.5.2 結合関係

各結合ビュー・アダプタには、個別のプライマリ・アダプタを必要です。結合ビュー・アダプタとそのプライマリ・アダプタを結合するには、結合関係(ジョイナとも呼ばれる)を作成します。結合関係は、どのように結合を形成するか、およびそれらがクライアントのかわりにすべてのディレクトリ操作にどのように影響を与えるかを定義する一連のルーチンです。Oracle Virtual Directoryは、カスタム・ロジックの作成に使用できる拡張可能なジョイナ・クラスを提供します。ジョイナ・クラスにはAPIが含まれ、これを使用することで、事前処理やDNマッピング・ロジック(preAdd、preModify、preGet、preDelete、preRenameなど)を各LDAP操作に加えることができます。

結合関係を指定せずに結合ビュー・アダプタを使用し、既存のアダプタをディレクトリ・ツリーの新しい場所にコピーすることもできます。これには、複製のアダプタを作成せずに、元のアダプタの接続プールを共有するという利点があります。

次に、サポートされている結合関係タイプの説明を示します。

- Simpleジョイナ

- 条件付きSimpleジョイナ

- OneToManyジョイナ

- Shadowジョイナ

- カスタム結合

2.5.2.1 Simpleジョイナ

Simple結合関係は、remoteattribute=primaryadapterattributeという形式のSimple結合関係を使用してエントリの属性を比較することで、プライマリ・アダプタと結合ビュー・アダプタのエントリの間に1対1関係を定義します。remoteattributeは、ターゲットの結合アダプタの属性で、primaryadapterattrinuteはプライマリ・アダプタの属性です。条件のカンマ区切りのリストを使用して、より複雑な基準にすることができます。これにより、すべての条件をandで結合する複数条件の結合が作成されます。たとえば、uid=uid,sn=sn,mail=mailのようになります。

一致する属性が複数存在する場合、Oracle Virtual Directoryでは最初の一致する属性が使用されます。Oracle Virtual Directoryは、プライマリ・アダプタにのみAdd、Delete、RenameのLDAP操作を適用し、結合ビュー・アダプタではそれらの操作を無視します。

図2-1に、認証に使用されるSimple結合の高度な例を示します。

図2-1 認証用のSimple結合の例

2.5.2.2 条件付きSimpleジョイナ

「Simpleジョイナ」の項で説明されているように、Simpleジョイナは、共有される属性値に基づいて2つのアダプタのエントリを結合します。条件付きのSimple結合関係は、結合が追加の条件によってのみ行われるように、Simpleジョイナの機能を拡張します。条件付きのSimple結合関係では、結合ルールに ;文字を使用してSimple結合関係を拡張し、employeenumber>0など、その場合にのみ結合が行われる条件を追加します。

たとえば、Simpleジョイナ条件がemployeenumber=employeenumberであるとします。

次のように、ConditionalSimpleJoinerおよび ;文字を使用して、このSimpleジョイナ・ルールを拡張し、条件を追加できます。

employeenumber=employeenumber;(&(employeenumber=101)(sn=Smith))

2.5.2.3 OneToManyジョイナ

OneToMany結合関係は、複数のプライマリ・アダプタと結合ビュー・アダプタの間に1対多関係を定義します。Simple結合関係と同様、OneToMany結合関係では、属性を比較することで結合ビュー・アダプタの属性が特定されますが、結合ビュー・アダプタの一致するすべてのエントリがアダプタ間の関係に含まれます。OneToMany結合は、複数のロール・オブジェクトまたはIDを1つの仮想エントリに統合するために役立ちます。これもSimple結合関係と同じですが、Oracle Virtual Directoryは、プライマリ・アダプタにのみAdd、Delete、RenameのLDAP操作を適用し、OneToMany結合関係を使用している場合には、結合ビュー・アダプタではそれらの操作を無視します。

図2-2に、ポリシー・サーバーで個人についてポリシー決定をする必要がある場合の例を示します。統合を目的とする場合、ポリシー・サーバーは、権限属性として公開されているユーザーの権限が含まれる1つのエントリを認識することが望ましいとされます。これにより、ポリシー・サーバーは次の問合せで権限のアサーションをテストできます。

ldapsearch –b "uid=e027451,ou=People,o=LargeCo" –s base "(priv=XYZ Mgr)"

OneToManyジョイナは、メインのou=Peopleエントリのプロファイル属性に基づいて、1つ以上の権限を1ユーザーと一致させるために使用されます。OneToManyジョイナは、エントリと同じプロファイル値のすべての権限を検索して、それらをエントリとマージします。第2段階の結合ではSimpleジョイナが使用され、SunOne Directoryの組み合されたプロファイルが、ユーザーのActive Directory資格証明とともに使用されます。

図2-2 OneToMany結合の例

2.5.2.4 Shadowジョイナ

Shadowジョイナは、スキーマ拡張機能を必要とするLDAPアダプタまたはデータベース・アダプタなどのソースにエントリを格納する必要があるが、スキーマ拡張機能をビジネスまたは技術的な理由で使用できない場合に使用します。Shadowジョイナを使用すると、ローカル・ストア・アダプタなどの別のストアや、Oracle Internet DirectoryまたはOracle Directory Server Enterprise Edition (旧称はSun(tm) Java System Directory Server)などのextensibleobjectオブジェクト・クラスをサポートする別のLDAPディレクトリの拡張属性を使用できます(現在Microsoft Active Directoryでは、extensibleobjectオブジェクト・クラスはサポートされていません)。

注意:
ローカル・ストア・アダプタは、テストやデモの目的でのみ、Shadowジョイナ属性のストアとして使用することをお薦めします。本番環境では、Oracle Internet DirectoryをShadow結合データ・ストアとして使用します。

Shadow結合関係は、プライマリ・アダプタのエントリと同じ構造を維持しますが、別のアダプタを使用してシャドウ・エントリを作成することで追加の属性を保持します。Shadow結合関係を使用すると、アプリケーションで企業ディレクトリを使用し、アプリケーション固有の属性を結合ビュー・アダプタのデータ・ストアに格納できます。アプリケーションは、すべての属性を格納するディレクトリと通信していると認識しますが、アプリケーション固有のデータは実際には、Oracle Virtual Directoryにより別のShadowディレクトリに格納されています。Shadow属性が表示されるのは、値の指定された属性が、結合されたエントリDNに追加された後のみです。

Shadowジョイナを使用するには、データを格納するディレクトリでExtensibleEntryオブジェクト・クラスがサポートされ、vdeshadowobjectオブジェクト・クラスが定義されている必要があります。extensibleobjectオブジェクト・クラスは、任意の属性を含み、どのLDAPv3サーバー製品でもサポートされていないオブジェクトを定義します(IETF RFC 2251ではオプションのアイテムです)。ローカル・エントリには1つ以上の属性のみが含まれ、有効なオブジェクト・クラスを形成しない可能性があるため、Shadowジョイナでは、extensibleobjectおよびvdeshadowobjectオブジェクト・クラスを使用してローカル・エントリが格納されます。一般的に、ローカル・ストア・アダプタはローカル・エントリの格納に使用されますが、extensibleobjectオブジェクト・クラスをサポートし、vdeshadowobjectオブジェクト・クラスが定義されているLDAPディレクトリを使用することもできます。

注意:
Oracle Internet Directoryでは、ExtensibleEntryオブジェクト・クラスがサポートされています。

Shadowジョイナは、プライマリ・アダプタのすべてのDNをハッシュにエンコードすることで機能します。ハッシュにより、検索を実行せずに、結合アダプタで結合エントリを見つけられるようになります。Shadowジョイナは、対応するレコードを結合ビュー・アダプタで見つけられないと、自動的に新しいレコードを作成し、指定の属性を結合アダプタに格納します。Shadowジョイナはアプリケーションに対してできるかぎり透過的に稼働し、プライマリ・アダプタのエントリと同期してエントリの作成や名前の変更を処理します。

注意:
Shadow結合は、Oracle Access Manager 10gなどユーザー・レコードに対するスキーマ変更を必要とする大部分のOracleアプリケーションで問題なく機能します。ただし、Shadow結合を使用して、Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティのスキーマ変更を排除することはできません。その理由はユーザー・パスワードのハッシュをActive Directoryユーザー・レコードに格納する必要があり、Oracle Virtual Directoryがそのために拡張属性orclCommonAttributeを使用するためです。
ディレクトリ統合プラットフォームでOracle Internet Directoryとエンタープライズ・ユーザー・セキュリティを使用することで、別のディレクトリにパスワードのハッシュを格納できます。ディレクトリ統合プラットフォームによってパスワードの変更がインターセプトされ、それがOracle Internet Directoryに送信されて格納されます。

Shadowジョイナでは、すべてのLDAP操作がサポートされています。LDAP変更操作が行われると、Shadowジョイナはアダプタの格納可能属性ルーティング・パラメータによって示されたパラメータを調査し、Shadow結合アダプタに格納する属性の有無を確認します。そのような属性が存在する場合、Shadowジョイナは、プライマリ・エントリのMD5ハッシュを使用して、ローカル・エントリの特定を試行します。特定されると、適切なLDAP変更操作がローカルで実行されます。ローカル・エントリが検出されない場合、Shadowジョイナは、プライマリDNが変更されている場合に備えて2回目の検索を実行し、プライマリ・キーを使用してエントリを特定します。ローカル・エントリが検出されない場合は、新しいエントリが自動的に作成されます。

図2-3は、Oracle Virtual Directoryと接続するように構成されたCheckPointファイアウォールを示しています。Oracle Virtual Directoryは、CheckPointファイアウォール・スキーマを管理するためにOracle Internet Directoryを使用します。これにより、企業ディレクトリ・スキーマをアプリケーション固有データで拡張することなく、企業エンタープライズ・ディレクトリへのCheckPointファイアウォールの統合が可能になります。かわりに、Oracle Internet Directoryにそれを格納することにより、CheckPointファイアウォール管理を担当するチームがアプリケーション固有データを管理できます。

図2-3 アプリケーション固有データをローカルに格納するためのShadow結合の使用例

2.5.2.5 カスタム結合

結合ビュー・アダプタでは、様々な複雑な関係を実装できるJavaベース・プラグイン結合関係もサポートされています。たとえば、結合で複数の段階からなる操作を実行する場合、カスタム結合により、実際のシナリオに適した特別なリカバリ・メカニズムを提供できます。Javaベースのプラグインの詳細は、第4章「Oracle Virtual Directoryのプラグインの概要」を参照してください。

2.6 カスタム・アダプタの概要

Oracle Virtual Directoryではカスタム・アダプタの作成機能もサポートされています。これには、定義済のAPIによってほとんどすべてのデータ・ソースに接続できるプラグインを使用します。カスタム・アダプタのデプロイの詳細は、「カスタム・アダプタの作成および構成」を参照してください。

2.7 アダプタによる仮想ディレクトリ作成の概要

この項では、アダプタを使用して仮想ディレクトリを作成する方法を説明する次の例を示します。

- 基本的な仮想ディレクトリの例

- 結合ビュー・アダプタを使用する仮想ディレクトリの例

2.7.1 基本的な仮想ディレクトリの例

図2-4に、ベースがo=YourCompany,c=USで、次のようなメイン・ブランチを持つディレクトリの仮想ディレクトリ構造を示します。

- ou=Airius: パートナのLDAPディレクトリを指します。

- ou=People: 社内のRDBMSを指します。

- ou=Groups: ローカルのOracle Virtual Directoryディレクトリ・ストアに格納されるグループとロールの情報です。

図2-4 仮想ディレクトリ構造の例

図2-4の仮想ディレクトリには次のアダプタが必要です。

- LDAPアダプタ

- データベース・アダプタ

- ローカル・ストア・アダプタ

次のリストは、仮想ディレクトリを作成するために、図2-5でアダプタがどのように構成されているかを説明します。

- アダプタ0: ローカル・ストア・アダプタ
このアダプタは、ディレクトリのベースを形成し、プロキシの対象にならないエントリを保持します。この場合、Groupsの下のディレクトリ・エントリはローカル・ディレクトリに格納されます。

- アダプタ1: LDAPアダプタ
このアダプタは、リモートLDAPディレクトリと、仮想ディレクトリ・ツリーにマッピングされるリモート・ベースを指定します。この場合、リモート・サーバーのo=Airius.comの下のすべてのエントリは、仮想ディレクトリでou=Airius,o=YourCompany,c=USとして表されます。

- アダプタ2: データベース・アダプタ
このデータベース・アダプタは、2つの表を使用してディレクトリのエントリが形成されることを指定するデータベース接続です。この場合、2つの表の結合問合せによるレコードが、仮想ディレクトリのネームスペースou=People,o=YourCompany,c=USのユーザー・オブジェクトを形成するために使用されます。

図2-5 サンプルの仮想ディレクトリに構成されたアダプタ

図2-5に示されているように、Oracle Virtual Directoryおよびそのアダプタでは、ディレクトリ・ツリーの各部分のソースを様々な場所に求めることができます。仮想ディレクトリ情報ツリー構造を計画するときは、2つのアダプタ・ルートが同じルート・ノードを占有しないようにしてください。ただし、アダプタを別のアダプタの子ノードとして表すことは可能です。

2.7.2 結合ビュー・アダプタを使用する仮想ディレクトリの例

第1章「Oracle Virtual Directoryの概要」の図1-2には、ある企業の全従業員が使用するエンタープライズ・アプリケーションの例が示されています。アプリケーションは、3つの異なるソースのディレクトリ情報にアクセスし、各ソースには異なるユーザーのグループがあります。図2-6と図1-2のトポロジは同じですが、図2-6の右側にある3つのすべてのディレクトリ・ソースには同じユーザー・グループが含まれています。

図2-6 同じユーザー・グループのディレクトリの仮想化

図2-6では、すべてのユーザーの企業ディレクトリ情報の主なソースが含まれるメインの企業ディレクトリを示しています。たとえば、企業ディレクトリの各ユーザーについては、ユーザー認証のためにMicrosoft Active Directoryの対応するアカウントと一致させる必要があるとします。また、企業データベースで職員関連のアプリケーション情報にアクセスするために、企業ディレクトリの各ユーザーを企業データベースの表エントリに関連付ける必要があります。

図2-6の要件に対応するには、次の4つのアダプタを使用してOracle Virtual Directoryを構成します。

- アダプタ0は、ローカル・アプリケーション記憶域用で、ツリーのルート位置を保持します。

- アダプタ1はActive Directoryのプロキシとして定義されます。

- アダプタ2は、企業LDAPディレクトリのプロキシです。

- アダプタ3はデータベース・アダプタで、企業RDBMSの該当するユーザー・レコードにマップされます。

- アダプタ4は結合ビュー・アダプタです。この場合、企業ディレクトリのアダプタ2がプライマリ・アダプタとして使用されるため、アダプタ4で表示されるすべてのエントリは、アダプタ2のエントリとまったく同一になります。他に何も定義しない場合、結合ビュー・アダプタはアダプタ2のコピーにすぎません。

アダプタを構成したら、結合関係を定義する必要があります。この場合、Active Directoryに対して1つ、企業RDBMSに対して1つ、あわせて2つの結合関係を定義します。Active Directoryの結合では、アダプタ2に対するSimple結合をアダプタ4に定義します。プライマリ・アダプタであるアダプタ1と実際に結合していることに注意してください。

結合を完了するために、Active Directoryのエントリをプライマリ・アダプタに結合する一意の基準を指定します。図2-7に示すように、uid=userprincipalnameを使用します。uidはアダプタ1にあり、userprincipalnameはアダプタ2(Active Directory)にあります。2つ目の結合では、Simple結合を使用してアダプタ3と結合し、uid=useridを使用して一意の一致を取得します。

図2-7 結合間の一意の基準の指定

最後に、プライマリ・アダプタ(アダプタ2)ではなくアダプタ1を認証用に使用するため、bindadapter設定は1とします。これにより結合ビュー・アダプタは、プライマリ・アダプタではなく結合アダプタに対して認証をテストするようになります。

注意:
ユーザーを複数のRDBMSレコード(たとえば権限表)と一致させる場合は、approle=privのようなOneToMany結合を指定できます。このapproleは、企業ディレクトリの属性です。approle属性は、RDBMSの一連の権限と一致します。この例で結合を実行することで、単純なロールが一連の権限に変換されます。

アダプタ4を構成したら、これらの各アダプタのルーティング可視性を内部に設定することで、アダプタ1、2および3をエンド・ユーザーに対して非表示にできます。これにより、ディレクトリのブランチが1つ(ou=People,o=AppView)に見えるようになります。ou=Peopleの下のディレクトリを参照するときは、結合ビュー・アダプタであるアダプタ4を問い合せることになります。結合ビュー・アダプタが問合せを受け取ると、問合せを自動的に変換して、表示されていない他の3つのアダプタに渡します。結果として、アプリケーションに対しては、各ユーザーに1つのエントリしかないように見えます。

2.8 アダプタ・ネームスペースの概要

図2-8に、個別ディレクトリが4つあるソース・ディレクトリ・ツリー構造を示します。目標は4つの個別ディレクトリすべてを1つの新しいディレクトリ・ツリー設計にまとめることです。Oracle Virtual Directoryで実装できる最も基本的なディレクトリ・ツリー設計には変換機能がないため、4つの個別のディレクトリ・ツリーを含むソース・ディレクトリ構造がOracle Virtual Directory内で有効になり、変換機能を使用しない純粋なディレクトリ・プロキシとして機能します。

図2-8 個別ディレクトリが4つあるソース・ディレクトリ・ツリー構造の例

図2-9に、o=YourCompany, c=USの子として追加された外部の2つの企業を示します。この例では、アダプタ1とアダプタ2はアダプタ0に相対的なサブツリー・エントリの位置を占めています。また、アダプタ3は別のネームスペースを占めており、管理ネットワーク・サービスを提供するが、他の3つの組織のビジネス・アプリケーションには参加しないサード・パーティの会社を表しています。この場合、ISPディレクトリ・エントリを別にしておくことをお薦めします。

図2-9 2つの子が追加されたソース・ディレクトリ・ツリー構造の例

図2-10では、すべてのパートナ・ユーザーがou=Peopleブランチの下に配置されるように再設計されたディレクトリ構造を示しています。アプリケーションの制限のためにこのような要件になることがあります(アプリケーションがou=People, o=YourCompany, c=USの1ベースのユーザーしか認証しない場合など)。YourCompanyの人のエントリはou=Peopleの直下にありますが、パートナのディレクトリはou=Peopleの下の組織単位に含まれることに注意してください。組織単位を配置することで、それらのパートナのユーザー固有のアクセス制御グループやロールの作成が容易になり、ネームスペースの競合が回避されます。ツリーのどのノードも1つのアダプタが占有することに注意してください。

図2-10 再設計されたソース・ディレクトリ・ツリーの例

図2-11に、アダプタ0に格納されるエントリとアダプタ1と3のルート・エントリとの間の競合のために2つの問題が生じる例を示します。検索操作時に、Oracle Virtual Directoryはオーバーラップするネームスペースを検索し、すべてのアダプタから一致結果を戻します。ただし、変更操作時には、Oracle Virtual Directoryは、そのエントリからツリー内を下から順に進んで最初に一致したアダプタ内のエントリしか処理しません(この例では、アダプタ0はツリー内で上にあるため、アダプタ1と3のみが処理されます)。

図2-11 オーバーラップするディレクトリ構造の例

従来は、オーバーラップしたディレクトリ構造は受け入れられませんでしたが、Oracle Virtual Directoryでは、オーバーラップ・ネームスペースの操作の処理方法を制御するルーティング・フィルタがサポートされています。

2.9 アダプタ・テンプレートの概要

Oracle Virtual Directoryには、アダプタの構成プロセスを簡略化するアダプタ・テンプレートが用意されています。新規アダプタを作成する場合、新規アダプタ画面には、各アダプタで使用可能なテンプレートが表示される「アダプタ・テンプレート」リストがあります。アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が自動的に移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。

次の項では、アダプタ・テンプレートをリストして説明します。

- デフォルト・テンプレート

- LDAPアダプタ・テンプレート

- ローカル・ストア・アダプタ・テンプレート

- データベース・アダプタ・テンプレート

2.9.1 デフォルト・テンプレート

デフォルト・テンプレートは、すべてのアダプタ・タイプで使用可能な汎用テンプレートで、1つのベンダーのディレクトリに固有ではありません。デフォルト・テンプレートは、他のテンプレートがニーズに一致しない場合に使用します。

2.9.2 LDAPアダプタ・テンプレート

次の項では、LDAPアダプタ・テンプレートを説明します。

- Active_Directory

- CA_eTrust

- Changelog_LDAP-TYPE

- EUS_ActiveDirectory

- EUS_OID

- EUS_Sun (ODSEE)

- EUS_eDirectory

- General_LDAP_Directory

- IBM_Directory

- Novell_eDirectory

- マッパーを使用したOAM/ADアダプタ

- SSLおよびマッパーを使用したOAM/ADアダプタ

- スクリプトを使用したOAM/ADアダプタ

- マッパーを使用したOAM/ADAMアダプタ

- SSLおよびマッパーを使用したOAM/ADAMアダプタ

- スクリプトを使用したOAM/ADAMアダプタ

- マッパーを使用したOAM/SunOne (ODSEE)アダプタ

- スクリプトを使用したOAM/SunOne (ODSEE)アダプタ

- ONames_LDAP-TYPE

- Oracle_Internet_Directory

- Siemens_DirX

- SunOne_Directory (ODSEE)

- User_LDAP-TYPE

注意:
一部のアダプタ・テンプレートでは、Pythonマッピング・スクリプトが使用されます。テンプレートにより、アダプタの情報を使用してマッピング・スクリプトが構成されますが、そのマッピング・スクリプトのデプロイは行われません。マッピング・スクリプトを使用するアダプタ・テンプレートを使用する場合は、アダプタの構成後にOracle Virtual Directoryサーバーにマッピング・スクリプトを明示的にデプロイする必要があります。

2.9.2.1 Active_Directory

Active_Directoryテンプレートは、Microsoft Active DirectoryまたはActive Directoryアプリケーション・モードのターゲットに接続し、Active DirectoryオブジェクトをInetOrgPersonオブジェクトにマップしない場合に使用します。

注意:
Microsoft Active DirectoryまたはActive Directoryアプリケーション・モードのターゲットに接続し、Active DirectoryオブジェクトをInetOrgPersonオブジェクトにマップする場合は、Oracle Access Managerと統合しない場合でもマッパーを使用したOAM/ADアダプタ・テンプレートを使用します。

2.9.2.2 CA_eTrust

CA_eTrustテンプレートは、Computer Associates(CA)eTrustディレクトリに接続する際に使用します。

2.9.2.3 Changelog_LDAP-TYPE

ソースLDAPディレクトリのchangelog情報を適切な書式に標準化する必要がある場合は、Changelog_LDAP-TYPEテンプレートを使用します。Oracle Virtual Directoryには、次のアダプタ・テンプレートが含まれます。

- Microsoft Active Directory (Changelog_ActiveDirectory)

- Oracle Internet Directory (Changelog_OID)

- Oracle Unified Directory (Changelog_OUD)

- Oracle Directory Server Enterprise Edition (Changelog_SunOne (ODSEE))

各Changelog_LDAP-Typeテンプレートによって、Changelogプラグインがデプロイされます。

注意:
表2-1は、Oracle Virtual Directoryリリース11.1.1.4.0では推奨されません。この表に記載されているアダプタ・テンプレートは、Oracle Virtual Directoryリリース11.1.1.4.0では機能しません。

表2-1 Changelogアダプタ・テンプレート

ソースLDAPディレクトリ

アダプタ・テンプレート

アダプタ・テンプレートによってデプロイされるプラグイン

Oracle Internet Directory

Changelog_OID

oidchangelog

Microsoft Active Directory

Changelog_ActiveDirectory

adchangelog

Oracle Directory Server Enterprise Edition

Changelog_SunOne

sunonechangelog

2.9.2.4 EUS_ActiveDirectory

Active Directoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_ActiveDirectoryテンプレートを使用します。EUS_ActiveDirectoryを使用すると、次のプラグインがデプロイされ、統合が簡単になります。

- Objectclass Mapper: Active Directoryで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。

- Active Directory Password: データベースにディレクトリが登録されている場合には、データベース・パスワードをActive Directoryに格納できます。

- EUSActiveDirectory: GUIDなど、特定のActive Directoryの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。

2.9.2.5 EUS_OID

Oracle Internet Directoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_OIDテンプレートを使用します。EUS_OIDを使用すると、特定の属性をエンタープライズ・ユーザー・セキュリティで使用可能な一貫性のある形式に変換するEUSOIDプラグインがデプロイされるため、統合が簡単になります。

2.9.2.6 EUS_Sun (ODSEE)

Oracle Directory Server Enterprise Editionを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_Sun (ODSEE)テンプレートを使用します。EUS_Sun (ODSEE)テンプレートを使用すると、次のプラグインがデプロイされ、統合が簡単になります。

- Objectclass Mapper: Oracle Directory Server Enterprise Editionで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。

- EUSSun: GUIDなど、特定のOracle Directory Server Enterprise Editionの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。

2.9.2.7 EUS_eDirectory

Novell eDirectoryを使用するOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合には、EUS_eDirectoryテンプレートを使用します。EUS_eDirectoryを使用すると、次のプラグインがデプロイされ、統合が簡単になります。

- Objectclass Mapper: eDirectoryで管理できるよう、特定のOracle属性およびオブジェクト・クラスをマッピングします。

- EUSeDirectory: 特定のeDirectoryの属性を、エンタープライズ・ユーザー・セキュリティで使用できる形式に変換します。

2.9.2.8 General_LDAP_Directory

General_LDAP_Directoryテンプレートは、デフォルト・テンプレートと同じです。

2.9.2.9 IBM_Directory

IBM_Directoryテンプレートは、IBM Directory Serverに接続する際に使用します。

2.9.2.10 Novell_eDirectory

Novell_eDirectoryテンプレートは、Novell eDirectoryに接続する際に使用します。

2.9.2.11 マッパーを使用したOAM/ADアダプタ

このテンプレートを使用することでその他のアプリケーションにも利点がありますが、Microsoft Active Directoryを使用するOracle Virtual DirectoryとOracle Access Managerの統合には、このテンプレートを使用することをお薦めします。マッパーを使用したOAM/ADアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directoryの通信が簡単になります。

- Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。

- ObjectClass Mapper: Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングします。

- ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。

- Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

- Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

注意:
マッパーを使用したOAM/ADアダプタ・テンプレートは、スクリプトを使用したOAM/ADアダプタ・テンプレートに似ていますが、スクリプトを使用したOAM/ADアダプタ・テンプレートのように、追加のマッピング・スクリプトをデプロイする必要はありません。

2.9.2.12 SSLおよびマッパーを使用したOAM/ADアダプタ

Oracle Virtual DirectoryとOracle Access Managerの統合においてのみ、パスワード変更操作でSSLを使用してActive Directoryターゲットに接続するようLDAPアダプタを構成します。デフォルトで、アダプタの可視性のルーティング設定が内部に設定されており、アダプタはクライアントに対して非表示になり、Active Directory Passwordプラグインなどのプラグインを介してのみアクセスできるようになります。

2.9.2.13 スクリプトを使用したOAM/ADアダプタ

属性名の変更にObjectClass MapperではなくOblixADMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/ADアダプタ・テンプレートに似ています。スクリプトを使用したOAM/ADアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directoryの通信が簡単になります。

- Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。

- ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。

- Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

- Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

スクリプトを使用したOAM/ADアダプタ・テンプレートでは、アダプタの情報を使用して、OblixADMappingスクリプトも構成されます。OblixADMappingスクリプトは、Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングするObjectClass Mapperに似ています。

注意:
スクリプトを使用したOAM/ADアダプタ・テンプレートを使用してアダプタを構成したら、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。
同じ結果を得るために、スクリプトを使用したOAM/ADアダプタ・テンプレートまたはマッパーを使用したOAM/ADアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/ADアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/ADアダプタ・テンプレートでは、アダプタの構成後に、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/ADアダプタ・テンプレートではこの必要がないためです。

2.9.2.14 マッパーを使用したOAM/ADAMアダプタ

このテンプレートを使用することでその他のアプリケーションにも利点がありますが、Microsoft Active Directoryアプリケーション・モードを使用するOracle Virtual DirectoryとOracle Access Managerの統合には、このテンプレートを使用することをお薦めします。マッパーを使用したOAM/ADAMアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directory Application Modeの通信が簡単になります。

- Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。

- ObjectClass Mapper: Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングします。

- ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directoryアダプタの名前に設定します。

- Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

- Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

注意:
マッパーを使用したOAM/ADAMアダプタ・テンプレートは、スクリプトを使用したOAM/ADAMアダプタ・テンプレートに似ていますが、スクリプトを使用したOAM/ADAMアダプタ・テンプレートのように、追加のマッピング・スクリプトをデプロイする必要はありません。

2.9.2.15 SSLおよびマッパーを使用したOAM/ADAMアダプタ

Oracle Virtual DirectoryとOracle Access Managerの統合においてのみ、パスワード変更操作でSSLを使用してActive Directory Application Modeターゲットに接続するようLDAPアダプタを構成します。デフォルトで、アダプタの可視性のルーティング設定が内部に設定されており、アダプタはクライアントに対して非表示になり、Active Directory Passwordプラグインなどのプラグインを介してのみアクセスできるようになります。

2.9.2.16 スクリプトを使用したOAM/ADAMアダプタ

属性名の変更にObjectClass MapperではなくOblixADMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/ADAMアダプタ・テンプレートに似ています。スクリプトを使用したOAM/ADAMアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとActive Directory Application Modeの通信が簡単になります。

- Active Directory Ranged Attribute: 範囲指定された属性を1つのリクエストに変換します。範囲指定された属性とは複数値の値がいくつかある属性で、Active Directoryにより複数のリクエストに分割され、クライアントの混乱の原因になります。

- ActiveDirectory Password: 標準のuserPassword属性をMicrosoftのunicodePWD属性に変換します。また、このアダプタを非SSLのポートを介してActive Directoryに接続させるために、このプラグインで、SSLを使用してActive Directoryサーバーに接続する別のアダプタ・インスタンスにパスワードの更新をルーティングできます(Active DirectoryでSSLを使用するにはLDAPを介したパスワードの変更が必要なため)。アダプタがSSLを使用するように設定されている場合は、プラグイン構成からホスト名を削除します。アダプタがSSLを使用しないように設定されている場合は、プラグインのホスト名を、SSLを使用してActive Directoryに接続されているActive Directory Application Modeアダプタの名前に設定します。

- Dump Before: プラグインにデータを渡す前に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

- Dump After: プラグインにデータを渡した後に、操作の値をvde.logにダンプするDump Transactionプラグインの一種。

スクリプトを使用したOAM/ADAMアダプタ・テンプレートでは、アダプタの情報を使用して、OblixADMappingスクリプトも構成されます。OblixADMappingスクリプトは、Active Directory User/GroupオブジェクトをInetOrgPerson/GroupOfUniqueNameオブジェクトにマッピングするObjectClass Mapperに似ています。

注意:
スクリプトを使用したOAM/ADAMアダプタ・テンプレートを使用してアダプタを構成したら、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。
同じ結果を得るために、スクリプトを使用したOAM/ADAMアダプタ・テンプレートまたはマッパーを使用したOAM/ADAMアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/ADAMアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/ADAMアダプタ・テンプレートでは、アダプタの構成後に、OblixADMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/ADAMアダプタ・テンプレートではこの必要がないためです。

2.9.2.17 マッパーを使用したOAM/SunOne (ODSEE)アダプタ

Oracle Virtual DirectoryとOracle Access Manager統合のSunOne Directoryターゲットに接続するようLDAPアダプタを構成し、SunOneの属性をOracle Access Managerで使用できるように変換します。マッパーを使用したOAM/SunOneアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、LDAPアダプタとSunOneの通信が簡単になります。

- ObjectClass Mapper: nsaccountlock属性を除外し、ディレクトリ・タイプをSunOneとマークします。

- Dump SunOne: プラグイン・アクティビティの出力をvde.logにダンプします。

2.9.2.18 スクリプトを使用したOAM/SunOne (ODSEE)アダプタ

属性名の変更にObjectClass MapperではなくOblixSunOneMapping Pythonマッピング・スクリプトを使用することを除き、マッパーを使用したOAM/SunOneアダプタ・テンプレートに似ています。最初のインストールおよびフレッシュ・インストールには、スクリプトを使用したOAM/SunOneアダプタ・テンプレートではなく、マッパーを使用したOAM/SunOneアダプタ・テンプレートの使用をお薦めします。

スクリプトを使用したOAM/SunOneアダプタ・テンプレートを使用すると、プラグインおよびマッピング・アクティビティの出力をvde.logにダンプするDump Transactionプラグインがデプロイされ、LDAPアダプタとSunOneの通信が簡単になります。

スクリプトを使用したOAM/SunOneアダプタ・テンプレートでは、アダプタの情報を使用して、OblixSunOneMappingスクリプトも構成されます。OblixSunOneMappingは、nsaccountlock属性を除外し、ディレクトリ・タイプをSunOneとマークするObjectClass Mapperに似ています。

注意:
スクリプトを使用したOAM/SunOneアダプタ・テンプレートを使用してアダプタを構成したら、OblixSunOneMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。
同じ結果を得るために、スクリプトを使用したOAM/SunOneアダプタ・テンプレートまたはマッパーを使用したOAM/SunOneアダプタ・テンプレートのいずれかを使用できる場合は、マッパーを使用したOAM/SunOneアダプタ・テンプレートの使用をお薦めします。これは、スクリプトを使用したOAM/SunOneアダプタ・テンプレートでは、アダプタの構成後に、OblixSunOneMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があり、マッパーを使用したOAM/SunOneアダプタ・テンプレートではこの必要がないためです。

2.9.2.19 ONames_LDAP-TYPE

ONames_LDAP-TYPEアダプタ・テンプレートは、Oracle Virtual DirectoryをOracle Net Servicesと統合している場合にのみ使用します。Oracle Virtual Directoryには、Microsoft Active Directory (ONames_ActiveDirectory)、Oracle Internet Directory (ONames_OID)およびOracle Directory Server Enterprise Edition (ONames_Sun (ODSEE))用のONamesアダプタ・テンプレートが組み込まれています。

各ONames_LDAP-TYPEテンプレートは、ONamesプラグインのみをデプロイします。このプラグインは、ソースLDAPディレクトリに固有のエントリを削除し、Oracle Virtual DirectoryとOracle Net Servicesの統合を容易にします。

2.9.2.20 Oracle_Internet_Directory

Oracle_Internet_Directoryテンプレートは、Oracle Internet Directory(OID)に接続する際に使用します。

2.9.2.21 Siemens_DirX

Siemens_DirXテンプレートは、Siemens DirXディレクトリに接続する際に使用します。

2.9.2.22 SunOne_Directory (ODSEE)

SunOne_Directory (ODSEE)テンプレートは、Netscape、Sun Microsystems、FedoraなどのNetscapeファミリのディレクトリに接続する際に使用します。

2.9.2.23 User_LDAP-TYPE

User_LDAP-TYPEアダプタ・テンプレートは、Oracle Virtual DirectoryとOracle Identity Managerの統合に使用します。この統合には、Oracle Identity Managerの属性からLDAPディレクトリ・サーバーへのデータ・マッピングが必要です。Oracle Virtual Directoryには、次のテンプレートがあります。

- Microsoft Active Directory (User_ActiveDirectory)

- Oracle Internet Directory (User_OID)

- Oracle Directory Server Enterprise Edition (User_SunOne)

各User_LDAP-TYPEテンプレートによって、UserManagementプラグインがデプロイされます。

2.9.3 ローカル・ストア・アダプタ・テンプレート

次の項では、ローカル・ストア・アダプタ・テンプレートを説明します。

- Local_Storage_Adapter

2.9.3.1 Local_Storage_Adapter

Local_Storage_Adapterテンプレートは、デフォルト・テンプレートと同じです。

2.9.4 データベース・アダプタ・テンプレート

次の項では、次のデータベース・アダプタ・テンプレートについて説明します。

- スクリプトを使用したOAM/DBアダプタ

2.9.4.1 スクリプトを使用したOAM/DBアダプタ

Oracle Virtual DirectoryとOracle Access Manager統合のデータベース・ターゲットに接続するようデータベース・アダプタを構成し、ビジネス・ロジックの処理にPythonマッピング・スクリプトを使用します。スクリプトを使用したOAM/DBアダプタ・テンプレートを使用すると、次のプラグインがデプロイされ、データベース・アダプタとOracle Access Managerの通信が簡単になります。

- DumpDB1: プラグインおよびマッピングにデータを渡す前に、操作の出力をvde.logにダンプするDump Transactionプラグインの一種。

- DumpDB2: プラグインおよびマッピングにデータを渡した後に、操作の出力をvde.logにダンプするDump Transactionプラグインの一種。

スクリプトを使用したOAM/DBアダプタ・テンプレートでは、アダプタの情報を使用して、Oblix_OAMMappingスクリプトも構成されます。Oblix_OAMMappingスクリプトは、エントリの追加前に削除する必要のあるOracle Access Manager固有のオブジェクト・クラスの削除など、Oracle Access Manager統合用のビジネス・ロジックを提供します。

注意:
スクリプトを使用したOAM/DBアダプタ・テンプレートを使用してアダプタを構成したら、Oblix_OAMMappingマッパー・スクリプトをOracle Virtual Directoryサーバーに明示的にデプロイする必要があります。

3 Oracle Virtual Directoryのルーティングの概要

この章では、Oracle Virtual Directoryのルーティングについて説明します。この章の内容は次のとおりです。

- 第3.1項「ルーティングとは」

- 第3.2項「ルーティング設定の概要」

3.1 ルーティングとは

従来型のディレクトリ・サーバーには、複数のデータベースが定義されており、それぞれがディレクトリ・ツリーのネームスペースの一部に対応し、選択はネームスペースの比較のみに基づいて決定されます。仮想ディレクトリでは、複数のアダプタで同じネームスペースを共有できるため、選択はより複雑ですが、より詳細に制御できます。

ルーティングは、LDAP操作に対して選択するアダプタをOracle Virtual Directoryが決定するために行われる処理です。ルーティングはタイプに関係なくすべてのアダプタに適用され、次に示すような、複数の役割を果します。

- 選択されるアダプタ数を制限し、リクエストされたクライアント・データを含み、現在のLDAP操作と関連するアダプタのみに絞り込む。

- 複雑な環境の設計を可能にする。

- 特定トランザクションのアダプタ数を削減し、よりセキュアでパフォーマンスの高い構成を実装できるようにOracle Virtual Directoryのチューニングを可能にする。

ルーティングでは、基本的なDNネームスペースのみでなく、DNパターン一致、LDAPフィルタ、属性フィルタ、問合せフィルタなど、トランザクション情報のその他の局面も調査してアダプタの選択を制御します。最も基本的なレベルでは、Oracle Virtual Directoryはアダプタ接尾辞比較プロセスを使用してアダプタを選択できます。アダプタ接尾辞の比較では、特定の検索ベースまたはエントリDN(追加、変更、削除、名前変更の場合)を調べて、各アダプタの接尾辞(ルート)と比較します。有効範囲によっては、Oracle Virtual Directoryは、1つ以上のアダプタが特定の問合せの影響を受けたかどうかを判別できます。

アダプタ接尾辞の比較は、アダプタ数が少ない場合に非常によく機能しますが、通常はさらに柔軟性の高い決定が必要で、このような場合にルーティングが重要になります。管理者はルーティングを使用すると、プロキシ・データ・ソースの情報をOracle Virtual Directoryにルーティング・インテリジェント機能という形で知らせることができます。ルーティングにより、Oracle Virtual Directoryはディレクトリ操作に細かい条件を付けて、操作が必要な特定の場所に送ることができます。これにより、既存のディレクトリに無関係な操作による過剰な負荷をかけずにすみ、自身のディレクトリに関係ない問合せがパートナに送られなくなります。Oracle Virtual Directoryルーティング・プロセスは、従来のアダプタ接尾辞比較に加えてLDAPクライアントの検索フィルタを分析し、処理に適格なアダプタをさらに絞り込みます。

ルーティングの例

図3-1に示すように、次の4つのアダプタが構成されているサンプルの仮想ディレクトリ構造があるとします。

- アダプタ0は、ディレクトリ・ツリーのルートを形成し、o=AppViewにマッピングされます。このアダプタは、ツリーの仮想ルート、およびアクセス制御グループなどのローカル・エントリを保持します。

- アダプタ1から3は、各ディレクトリ・ソースを新しいアプリケーション・ツリーのou=Peopleブランチの下の位置にマッピングします。

図3-1 仮想ディレクトリ構造の例

たとえば、図3-1のディレクトリを使用するアプリケーションがあり、ディレクトリ・サービスに関するインテリジェント機能がほとんどないと仮定します。これは本来1つのビジネスのために設計されたため、複数のビジネス・ユーザー・グループが同じアプリケーションを使用することに対応していません。このアプリケーションは、多種多様なディレクトリ・ツリー構造を想定することなく、1つの共通ディレクトリ階層ポイント(または1つの共通ベース)のみでディレクトリを検索します。この例では、アプリケーションがou=People,o=AppViewのディレクトリのみを検索するとします。ユーザーがjim.smith@divisionB.comなどのログイン証明書を入力すると、アプリケーションは次の検索を実行します。

- ベース: ou=People,o=AppView

- 有効範囲: subtree

- フィルタ: (uid=jim.smith@divisionb.com)

Oracle Virtual Directoryは、この問合せを受け取ると、この問合せで使用できるすべてのアダプタを自動的に選択します。問合せはツリーのベースを対象としているため、すべてのアダプタが選択され、調査が必要なパフォーマンスの問題の原因になります。他のすべての企業がディレクトリ構造の下部に存在する場合(たとえばou=DivisionB, ou=People,o=AppView)、親であるou=People,o=AppViewよりもそれらのブランチが下にあるため、デフォルトですべてのディレクトリ・ソースが検索されます。

この問題を解決するために、Oracle Virtual Directoryはルーティングの組込みと除外のフィルタを提供しています。これらのフィルタを使用して、特定のパートナ・ディレクトリへのトラフィックをフィルタ処理できます。この例では、管理者は次のルーティング組込みフィルタを設定できます。

- Division Aのアダプタ: (uid=*@divisiona.com)

- Division Bのアダプタ: (uid=*@divisionb.com)

- Division Cのアダプタ: (uid=*@divisionc.com)

LDAPクライアント検索のベースでは通常すべてのディレクトリが選択されますが、このフィルタによって、(uid=jim.smith@divisionb.com)の検索はDivision Bのディレクトリのみを対象とすることが指定されます。図3-2では、通常選択される3つのアダプタを灰色で示し、フィルタ処理の後ではDivision Bのデータのみが検索されることを点線で示しています。

図3-2 フィルタを使用したアダプタ検索の例

問合せのフィルタ処理の他に、Oracle Virtual Directoryでは各アダプタに優先度を割り当てることもできます。常に優先度の数値が小さいアダプタから順に問合せの対象になります。優先度の数値が同じアダプタは、構成ファイルでの定義順に検索されます。競合が発生した場合(2つのエントリが同じDNを持つ場合など)、Oracle Virtual Directoryは常に優先度または構成の数値が小さい方のアダプタの応答のみを受け入れます。ルーティングのフィルタで1つのアダプタを選択できなかった場合、競合が発生する可能性がありますが、優先度の選択によって解消されます。

3.2 ルーティング設定の概要

アダプタを作成したら、Oracle Directory Services Managerでアダプタの「ルーティング」タブを使用して、そのアダプタのルーティングを構成できます。この項では、「ルーティング」タブで実行可能なアダプタ・ルーティング設定について説明します。この項の内容は次のとおりです。

- 優先度

- 「含めるフィルタ」および「除外するフィルタ」

- DN一致

- レベル

- 「属性フロー」設定

- 可視性

- バインド・サポート

- 重要性

- ビュー

- 「バインドを含む」および「バインドの除外」

注意:
アダプタの「ルーティング」タブの「適用」ボタンをクリックして、アダプタのルーティング設定に行った変更を適用します。変更を行う前に構成されていたルーティング設定に戻すには、「回復」ボタンをクリックします。「適用」をクリックすると、設定を元に戻せなくなります。

3.2.1 優先度

複数のアダプタでネームスペースが重複している場合など、他のアダプタより先に特定のアダプタが処理されるように、Oracle Virtual Directoryを設定することが必要になる場合があります。このような状況は、既存のディレクトリをオンライン状態にしたまま新しいディレクトリを使用可能にする場合に発生します。

優先度の設定により、アダプタが他のアダプタに対して相対的に処理される優先度が決定されます。最も高い優先度は1で、100が最も低くなります。デフォルトの設定は50です。

既存のディレクトリをオンライン状態にしたまま新しいディレクトリを使用可能にする前述の例のような状況では、より新しくより重要なアダプタの優先度の設定は、より高い優先度(つまり、デフォルトの50より小さく、なおかつネームスペースが重複する既存のアダプタより小さい数値)に設定する必要があります。

優先度は、他のルーティング・パラメータがすべて処理されてから、最後のセレクタとして使用されます。その他の点で同等の2つの候補がある場合、優先度が高い(数値が小さい)方のアダプタが先に処理されます。優先度の数値が同じアダプタは、構成ファイルでの定義順に検索されます。同じDNをサポートするアダプタが2つあるなど、検索操作で競合が発生した場合、Oracle Virtual Directoryでは、構成の優先度の数値が低い方のアダプタが先に使用されます。変更操作では、エントリからツリーを上位にさかのぼって先に一致したアダプタ内のエントリのみが処理されます。

注意:
正確を期すために、複数のアダプタが選択される構成での判断基準として、「含めるフィルタ」、「除外するフィルタ」および「DN一致」の設定を使用することをお薦めします。

3.2.2 「含めるフィルタ」および「除外するフィルタ」

「含めるフィルタ」および「除外するフィルタ」の設定は、基本的にフィルタのフィルタで、クライアントによって指定されたLDAP検索フィルタに適用されます。クライアント検索フィルタが「含めるフィルタ」設定に定義された論理的要件を満たしている場合、そのアダプタが選択され、検索に使用するアダプタ・セットに含められます。同様に、「除外するフィルタ」設定の場合は、論理的要件が満たされると、クライアント検索に使用するアダプタ・セットからそのアダプタが除外されます。

「含めるフィルタ」および「除外するフィルタ」フィールドの書式では、標準のLDAP検索フィルタの後にスコープ条件(#base、#oneまたは#sub)が続きます。このスコープは、フィルタを適用するスコープ・レベルを示します。たとえば、#oneスコープを使用するフィルタは、1レベルまたはサブツリーの検索に適用され、ベース検索はフィルタ処理されません。

包含フィルタのデフォルト・スコープは#subで、サブツリー全体に関する問合せのみが除外されます。すべてのスコープにフィルタを適用するには、スコープを#baseに設定します。これにより、フィルタはベース、1レベル、およびサブツリーの検索に適用されます。

除外フィルタのデフォルト・スコープは#oneで、特定の検索がブロックされます。すべてのスコープにフィルタを適用するには、スコープを#baseに設定します。サブツリー検索のみにフィルタを適用するには、スコープを#subに設定します。

「含めるフィルタ」と「除外するフィルタ」の両方の設定を同時に使用することで、より複雑な条件セットを作成して、クライアント検索操作で使用されるアダプタを管理できます。たとえば、ファイアウォールとしてデプロイされたLDAPアダプタを介する、特定の種類の検索を許可するとします。特定の検索のみを許可するには、次のような「含めるフィルタ」設定を使用します。

(|(mail=*@myorg.com)(uid=*@myorg.com)(sn=*)(givenname=*)(cn=*))

このフィルタでは、mail、uid、sn、givennameまたはcn以外の条件の検索がブロックされます。許可されるのは、これらの条件の1つ以上を伴う検索のみです。たとえば、(cn=Jim Smith)は受け入れられますが、(uid=smith@oracle.com)はmyorg.comで終わらないため受け入れられません。

ほとんどのアダプタ構成では、単純な検索条件が使用されますが、より複雑な例を参考にすると、ロジックの適用方法をより理解できます。そこで、次に示すフィルタの例をみてください。

クライアント検索コマンド

$ ldapsearch -b dc=oracle,dc=com -s sub "(|(sn=user2)(cn=user2b))"

ルーティング・フィルタ:

(&(|(uid=*)(cn=*))(sn=*))

このルーティング・フィルタは、クライアント検索フィルタに1つのsn属性、およびuidまたはcnのどちから一方の条件が含まれる場合に一致となることを示します。この例では、他の条件に関係なく、指定されたルーティング・フィルタが「含めるフィルタ」設定に割り当てられている場合はアダプタが選択され、「除外するフィルタ」設定に割り当てられている場合は選択解除されます。これは、クライアント・フィルタにsnおよびcnの条件が含まれており、フィルタのロジックが満たされるためです。

3.2.3 DN一致

DN一致は、アダプタ間で同じアダプタ・ルートを共有する場合や、どのエントリがどのアダプタに属すかを判断する方法が必要な場合に、最も使用されます。DN一致を使用すると、プロキシ設定された2つのソース間で発生するネーミングの相違を利用できます。たとえば、大規模な開発では、アルファベットに基づいてエントリを分けることもできます。DN一致では、アルファベットの範囲を選択し、範囲の一致に基づいてOracle Virtual Directoryでアダプタを選択できます。たとえば、名前を3つの範囲に分割する場合は、ユーザーのIDの先頭文字を基準に、AからJを1つのディレクトリ、KからRを別のディレクトリ、SからZを最後のディレクトリ部分のように指定できます。

DN一致のもう1つの役立つシナリオとしてあげられるのは、Microsoft Active DirectoryユーザーとOpen LDAPやその他のディレクトリなどの外部ディレクトリに含まれるユーザーとのフェデレーションです。Open LDAPのユーザーにuid属性に基づく相対識別名(RDN)が設定されており、Active Directoryにcn属性に基づくユーザー・エントリがある場合は、RDNタイプに基づいてアダプタを選択する正規表現を設定できます。

Active DirectoryアダプタのDN一致は次のようになります。

(.*)cn=[a-z0-9]*$

Open LDAPのDN一致は次のようになります。

(.*)uid=[a-z0-9]*$

DN一致を使用することで、Oracle Virtual Directoryでは、既存のソースの相違を利用して、重複するアダプタを効果的に管理できます。

「DN一致」フィールドには、アダプタ内のDNの書式を示す正規表現を入力できます。この正規表現は、アダプタ・ルートの下のDN部分に適用されます。たとえば、アダプタのルートがou=People,o=MyBigOrg.comで、次のレベルにあるRDNの先頭文字がAからJまでのエントリのみを許可する場合は、次のような式を指定します。

m/^(.*)uid=[a-j][a-z0-9]*$/

この式は、DNにuid=の条件が含まれ、その後にAからJの文字があり、その後に任意の数の英数字が続く必要があることを示しています。$記号は文字列の終わりを示します。この場合、文字列の終わりのカンマは除外されるため、uid=がこのアダプタ内のDNの最後の構成要素であることが必要です。UID値はAからJで始まる必要があるため、この条件と一致するUIDのみが受け入れられます。最後に、正規表現の^(.*)部分は、なんらかの文字(種類と数は特定しない)が文字列の最初(^の部分)と特定の値uid=の間に含まれることを示しています。

注意:

- DNは大文字と小文字が区別されないため、正規表現の一致は、大文字と小文字を区別せずに実行されます。

- 一致表現のm/および末尾の/の部分はオプションです。

3.2.4 レベル

使用する複数のアダプタの一部がその他のアダプタの子である場合は、親アダプタを構成して子アダプタのネームスペース内で発生する問合せが親アダプタに送信されないようにする必要が出てきます。これは、LDAP操作のDNが、通常のネームスペース選択を介して子アダプタと親アダプタの両方に関係する場合に発生します。親アダプタの深さ(レベル)を設定すると、Oracle Virtual Directoryで子トランザクションから親アダプタを排除できます。

ルーティングの「レベル」設定をLDAP検索とともに使用すると、検索ベースとなる、アダプタ・ルートの下のレベル数を指定できます。たとえば、値0では、検索ベースがアダプタのルートと同じになり、値1では、検索ベースがアダプタのルートまたは1つ下のレベルになります。デフォルトの設定である空(空白)の「レベル」設定では、すべてのレベルで検索が行われます。

「レベル」設定は、複数のアダプタが複雑にネストされた状況を混在させる場合に便利です。ルート・アダプタは、仮想化ツリーのすべての問合せに対して選択される可能性がありますが、その他のアダプタが関連データを含むツリーの一部を指すように設定されている可能性があるため、望ましくありません。ルート・アダプタを、実際にルート・エントリを調査する問合せ以外のすべての問合せから除外するには(つまりサーバーのパフォーマンスを向上させるには)、「レベル」設定を0に設定する必要があります。

たとえば、ローカル・ストア・アダプタがo=Oracle.comと定義されている場合は、ou=Partner1, o=Oracle.comおよびou=Partner2, o=Oracle.comなどの一連のLDAPアダプタの共通の親として使用できます。この場合、o=Oracle.comは子アダプタのプレースホルダになります。アダプタのエントリは1つのみであるため、検索ベースがo=Oracle.comである操作に対してのみの問合せを行う必要があります。検索ベースがou=Partner1, o=Oracle.comの場合には、このアダプタを検索する必要はありません。この場合、ルーティングの「レベル」の値は0が適切です。

3.2.5 「属性フロー」設定

「属性フロー」ルーティング設定は、アダプタへの属性のフロー、およびそのアダプタからの属性のフローを制御します。「属性フロー」ルーティング設定は、認証されていないクライアントからの情報のリクエストや、そのようなクライアントに情報が戻されるのを防ぐことによりセキュリティを実現します。また、結合ビュー・アダプタの場合は、複数のアダプタが同じ仮想結合エントリをもたらす可能性があるため、どの属性がどのアダプタに送られるかを制御するのに「属性フロー」ルーティング設定が役立ちます。

注意:
アクセス制御とは異なり、属性フロー規則は内部で適用されます。つまり、単純にリクエストがフィルタ処理されるのみで、クライアントにはエラーは戻されません。セキュリティ性の高い設定では、この内部での適用により、クライアント側では、特定の属性の表示が許可されているかどうかさえ知ることができません。

次に、「属性フロー」ルーティング設定のリストを示します。各設定については、この項の残りの部分で詳細に説明します。

- 取得可能な属性

- 取得不可能な属性

- 格納可能な属性

- 格納できない属性

3.2.5.1 取得可能な属性

「取得可能な属性」設定は、ターゲット・ディレクトリ上のアダプタで取得される属性を制御します。「取得可能な属性」設定では、プロキシ設定されたサーバーから追加、変更、削除などの操作をリクエストできるのは指定された属性に対してのみであるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。

また、結合ビュー・アダプタの使用時に、「取得可能な属性」設定を使用して属性フローを制御できます。結合ビュー・アダプタでは、2つ以上のアダプタからのエントリが結合されるため、どの属性を関連アダプタから取得するのかを制御する必要があります。結合ビューの関連アダプタから取得できる属性を制御するには、結合ビューの各アダプタに「取得可能な属性」設定を構成します。

「取得可能な属性」フィールドに、アダプタから取得できる属性の明示的なリストを指定します。リストが空の場合は、すべての属性が取得可能です。「取得可能な属性」フィールドに指定されているリストは、リストに含まれている属性のみがプロキシ設定されたディレクトリからリクエストされることを示します。

注意:
DNおよびオブジェクト・クラスは、アダプタの「取得可能な属性」ルーティング設定に関係なく、常にldapsearchから戻されます。必要に応じて、ObjectClass Mapperなどのプラグインを使用してDNまたはオブジェクト・クラスを変更できます。

3.2.5.2 取得不可能な属性

「取得不可能な属性」設定は、ターゲット・ディレクトリ上のアダプタで取得できない属性を制御します。リストが空の場合は、すべての属性が取得可能です。

3.2.5.3 格納可能な属性

「格納可能な属性」設定は、ターゲット・ディレクトリ上のアダプタに格納される属性を制御します。「格納可能な属性」設定では、プロキシ設定されたサーバーに追加、変更、削除などの操作が送信されるのは指定された属性とその値のみであるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。

また、結合ビュー・アダプタの使用時に、「格納可能な属性」設定を使用して属性フローを制御できます。結合ビュー・アダプタでは、2つ以上のアダプタからのエントリが結合されるため、どの属性を関連アダプタに送信する必要があるかを制御する必要があります。結合ビューの関連アダプタに送信する属性を制御するには、結合ビューの各アダプタに「格納可能な属性」設定を構成します。

「格納可能な属性」フィールドに、アダプタに書き込まれる属性のリストを入力します。リストが空の場合は、「格納できない属性」が定義されていないかぎり、すべての属性が格納可能です。「格納できない属性」が指定されている場合は、「格納可能な属性」フィールドにリストされている特定の値のみが格納可能です。

アダプタを読取り専用にするには、「格納可能な属性」のリストに_neverを入力します。_文字は属性名では無効なため、この条件が満たされることはなく、アダプタは読取り専用になります。

3.2.5.4 格納できない属性

変更可能な属性よりも変更できない属性を示す方が簡単な場合には、(「格納可能な属性」フィールドを使用して示すように)このリストを使用します。通常、「格納可能な属性」リストと「格納できない属性」リストは、両方ではなく、どちらか一方を指定します。

3.2.6 可視性

アダプタの「可視性」ルーティング設定は、外部クライアントによるアダプタへの問合せが可能かどうか、また、ルート・エントリの下にあるサーバーのnamingcontexts属性で公開されるかどうかを制御します。次に、各「可視性」設定のリストと説明を示します。

注意:
「可視性」のオプションは、Oracle Directory Services Managerのインタフェースに英語でのみリストされますが、「可視性」の各オプションの説明はローカライズされた言語翻訳でサポートされています。

はい

デフォルトの設定。可視アダプタは、namingcontexts属性の一部としてサーバーのルート・エントリにルートが公開されるアダプタです。

いいえ

可視性を「いいえ」に設定すると、アダプタはnamingcontexts属性に含まれませんが、外部のLDAPクライアントでは使用できます。複数のアダプタが同時に機能して単一のディレクトリ・ツリー・ブランチを形成している場合に便利です。論理ツリー全体は暗黙的に利用できる上、子アダプタの公開はアプリケーションにとって冗長で複雑なため、namingcontextsに含まれる親およびすべての子アダプタを公開せずに、ルート・アダプタのみを公開することもできます。

内部

「内部」に設定されているアダプタは、Oracle Virtual Directory内部で実行されるプラグインおよび結合ビュー・アダプタでのみ使用できるアダプタです。「内部」のアダプタは、外部のLDAPクライアントでは使用できません。結合ビュー・アダプタで使用するために構成されたアダプタは、これに当てはまります。外部の仮想ディレクトリで情報を2度公開するかわりに、プライマリ・アダプタおよびジョイナ・アダプタを「内部」としてマーク付けすると、これらのアダプタで定義された情報に結合ビュー・アダプタのみがアクセスできるようになります。

3.2.7 バインド・サポート

「バインド・サポート」オプションは、アダプタがLDAPバインド操作を処理できるかどうかを示します。アダプタがバインド機能をサポートしない場合、Oracle Virtual Directoryは、指定されているDNに対応するエントリからのuserPassword属性の取得を試行し、ローカル・パスワードの比較操作を実行します。これは、LDAPアダプタで「パススルー・モード」設定を「なし」に設定することと同じです。バインド操作をサポートするかどうかが不明なカスタム・アダプタを定義する際に、「バインド・サポート」設定を有効化します。

3.2.8 重要性

ホストのエラーによってアダプタでの検索操作が失敗した場合、Oracle Virtual Directoryでは「重要性」設定に基づいて処理が行われます。次に、各「重要性」設定のリストと概要を示します。

注意:
「重要性」のオプションは、Oracle Directory Services Managerのインタフェースに英語でのみリストされますが、「重要性」フィールドの説明はローカライズされた言語翻訳でサポートされています。

true

デフォルトの設定。これは、操作エラーやすべてのリモート・ホストが失敗した場合など、アダプタが結果を戻すのに失敗した場合、Oracle Virtual Directoryでは検索操作全体が失敗し、その他のアダプタでデータが検出されたかどうかに関係なく、クライアントにDSA使用不可というエラーが戻されることを示します。

false

この設定では、アダプタで操作の実行に失敗しても、Oracle Virtual Directoryでは、全体的な結果には重大ではないと認識されます。重大でないアダプタで操作上のエラーが発生した場合は、単純に、LDAP検索結果全体からその結果が省略されます。Oracle Virtual Directoryによってその他のアダプタからの結果の一部が戻されますが、エラーは示されません。

partial

アダプタの重要性を「partial」に設定すると、アプリケーションを介して、結果の一部が取得されたことをユーザーに通知できます。エラーが発生すると、Oracle Virtual Directoryによって「管理制限を超えました」というエラーが戻されます。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。

3.2.9 ビュー

「ビュー」では、Oracle Virtual Directoryの様々な情報をアプリケーションから参照できるようにします。ビューは、「ビュー」フィールドに構成された識別名(DN)またはIPアドレスによって定義されます。アダプタがビューに対して有効な場合は、「ビュー」で構成されたDNまたはIPアドレスのみが、そのアダプタからのデータを表示できます。アダプタは、1つまたは複数のビューに対して有効にできます。ビューのメンバーであるユーザーは、同じビューに対して有効なアダプタからの情報のみを参照できます。

アダプタをビューに対して有効にするには、アダプタの「ルーティング」タブで、適切なビューの「有効化」オプションを選択します。ビューに対して有効にされていないアダプタは、デフォルト・ビューに属します。ビューに割り当てられていないすべてのクライアントは、デフォルト・ビューに含まれるすべてのアダプタを表示できます。

3.2.9.1 ビューの作成および構成

ビュー作成および構成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. ツリーで「サーバー・ビュー」を開きます。既存のビューのリストが表示されます。
ビューを作成するには、次のようにします。

1. 「新規ビューの追加」ボタンをクリックします。「新規ビューの追加」ダイアログ・ボックスが表示されます。

2. 「ビュー名」フィールドにこのビューの名前を入力し、「OK」ボタンをクリックして、新規ビューを作成します。既存のビューのリストに新規作成したビューが表示されます。
ビューを構成するには、次の手順を実行します。

ビューを構成するには、次のようにします。

1. 既存のビューのリストで、構成するビューの名前をクリックします。このビューのDNおよびIPアドレスを構成できる画面が表示されます。
このビューにDNまたはIPアドレスを追加するには、適切なフィールドで「作成」ボタンをクリックし、値を入力し、「適用」ボタンをクリックします。

ビューからDNまたはIPアドレスを削除するには、削除する値を選択し、「削除」ボタンをクリックします。

3.2.10 「バインドを含む」および「バインドの除外」

「バインドを含める」および「バインドを除外」の設定は、現在のアダプタのネームスペースの下にないDNを解決するのに使用されるメカニズムです。これらの設定は、どのアダプタが互いの資格証明を共有できるかを管理者に示します。また、これらの設定は、ユーザー資格証明またはアダプタのプロキシ・アカウントが操作で渡される必要があるかどうか、アダプタが判断するのに役立ちます。

たとえば、Microsoft Active Directoryフォレスト内の2つの異なるドメイン・コントローラをプロキシ設定する、異なるLDAPアダプタについて考えてみます。Oracle Virtual Directoryでは、1つのドメインからのユーザー資格証明は、別のドメインの一部として認識されません。また、両方のドメインが同じフォレストに属すため、2番目のドメインでは実際に別のドメインからの資格証明が受け入れられることは明白です。管理者は、「バインドを含む」および「バインドの除外」設定を使用して、このような状況の処理方法をOracle Virtual Directoryに対して指定できます。

ユーザー資格証明を渡せるかどうかを決定する際に、Oracle Virtual Directoryでは次の2つの条件が考慮されます。

- 提供された資格証明が現在のアダプタのルートの下にあるか。

- ユーザー資格証明が「バインドを含む」フィールドにリストされているアダプタの下にマップされているか。また、ユーザー資格証明が「バインドの除外」フィールドにリストされている除外アダプタの下にマップされているか。

例は、次の項を参照してください。

3.2.10.1 例1

アダプタのルートがou=admin,o=depts,dc=oracle,dc=comである場合の例を次に示します。ユーザー資格証明は、次のいずれかに当てはまります。

1. ケースA: ou=admin,o=depts,dc=oracle,dc=comのネームスペース内にマップされます。

2. ケースB: ou=admin,o=depts,dc=oracle, dc=comのネームスペース内にマップされません(たとえば、資格証明のDNがou=sales,o=depts, dc=oracle,dc=comで終わるなど)。

ケースA

ユーザー資格証明がou=admin,o=depts,dc=oracle,dc=comで終わる場合:

「バインドの除外」フィールドが空でない場合は、ユーザーの資格証明をチェックして、除外アダプタの子であるかどうかを確認する必要があります。

- ユーザーの資格証明が除外アダプタの子である場合は、クライアントの資格証明を渡すのではなく、プロキシ資格証明を使用する必要があります。

- ユーザー資格証明が除外アダプタに属さない場合は、ユーザー資格証明が現在のアダプタを通過します。

この状況が最も発生するのは、2つのLDAPアダプタが定義されていて、2番目のアダプタが最初のアダプタ(親アダプタ)の子である場合です。子アダプタの一部である資格証明は、誤って親アダプタの一部でもあるとみなされる可能性があります。「バインドの除外」設定を使用すると、子アダプタの資格証明が不正に親アダプタに渡されるという問題を修正するのに役立ちます。「バインドの除外」設定を使用することで、特定の子DNが親アダプタの資格証明セットにマップされないことをOracle Virtual Directoryに認識させることができます。

ケースB

ユーザー資格証明がou=admin,o=depts, dc=oracle,dc=comとは異なるルートで終わる場合:

「バインドを含む」フィールドが空ではないが、共有として定義されているアダプタがある場合は、ユーザー資格証明をチェックして、共有アダプタにマップされているかどうか確認する必要があります。

- ユーザーの資格証明が共有アダプタにマップする場合は、共有アダプタが資格証明をマップし、元のアダプタに戻します。その後、元のアダプは、共有アダプタによってマップされた資格証明を渡すことが可能になります。

- 資格証明が現在のアダプタまたはいずれかの共有アダプタにマップされない場合は、提供された資格証明を渡すかわりに、プロキシ資格証明を使用する必要があります。
Oracle Virtual Directoryが複数のMicrosoft Active Directoryドメインにプロキシを設定するのは、このシナリオの一例です。ユーザー資格証明のルートが異なる場合でも、すべてのプロキシの行き先は同じフォレストであるため、1つのドメイン・コントローラによって別のドメイン・コントローラからのDNが認証されます。この場合は、どちらのアダプタからの資格証明でも、両方のアダプタで同様に共有できます。

たとえば、Domain AアダプタによってDomain Aがプロキシ設定され、Domain BアダプタによってDomain Bがプロキシ設定されます。Domain AおよびDomain Bは同じフォレストに存在します。そのため、Domain AおよびDomain Bアダプタの両方で、「バインドを含む」設定をDomain AとDomain Bに設定でき、両方のアダプタがそれぞれの資格証明を相互に渡すことができます。

3.2.10.2 例2

この例は「バインドを含める」および「バインドを除外」機能を説明します。

- バインドを含める。2つのアダプタが存在すると仮定します。

- A1はルートがroot dc=oracle,dc=comで、同じremotebaseを持ちます。

- A2はルートがdc=example,dc=comで同じremotebaseを持ちます。

この場合、A1とA2が互いに信頼し、すなわち、互いの資格証明をパススルーできます。「バインドを含める」機能の意図は、管理者がA1のために信頼されるすべてのアダプタを構成するようにすることです。そうすることによって、管理者は認証されたユーザーが信頼されるアダプタのいずれかに属しているかを確認でき、ユーザーが信頼されるアダプタのいずれにも属していない場合には、プロキシ資格証明を使用します。この設定は主に、同じAD FORESTS内で複数のドメイン制御の間で信頼を構成するのに使用されます。

ユーザーがバインドDN: cn=jsmith,dc=oracle,dc=com Search baseDN: dc=example,dc=comでバインドと検索を実行する場合:

この検索ではA2がヒットするだろうが、資格証明はA1によって認証されていたでしょう。しかし、A2はA1からの資格証明を信頼するため、このユーザーがそのネームスペースの下でなくてもA2はバインドDN(cn=jsmith,dc=oracle,dc=com)をパススルーする必要があります。

このシナリオを実現するには、A2の「バインドを含める」リストでA1を構成します。

- バインドを除外。2つのアダプタが存在すると仮定します。

- A1ルートがdc=oracle,dc=comです。

- A2はルートがdc=us,dc=oracle,dc=comです。

ユーザーがバインドDN: cn=jsmith,dc=us,dc=oracle,dc=com Search baseDN: dc=users,dc=oracle,dc=comでバインドと検索を実行する場合:

この検索ではA1がヒットするだろうが、資格証明はA2によって認証されていたでしょう。A1がまたバインドDNのネームスペースを満たしているという理由のみで、ユーザーがそのネームスペースの下に存在すると仮定して、A1はA1自身に対してバインドDN(cn=jsmith,dc=us,dc=oracle,dc=com)にサイレント・バインドを実行する必要はありません。このシナリオを実現するために、A1の「バインドを除外」リストでA2を構成します。この場合、A1はそのバインドDNを使用しようとしませんが、プロキシ資格証明を使用して検索を実行します。

4 Oracle Virtual Directoryのプラグインの概要

この章では、Oracle Virtual DirectoryのJavaプラグインについて説明します。この章の内容は次のとおりです。

- 第4.1項「プラグインとは」

- 第4.2項「汎用目的のプラグインの概要」

- 第4.3項「エンタープライズ・ユーザー・セキュリティ、Real Application SecurityおよびOracle Net Servicesプラグインの概要」

- 第4.4項「Microsoft Active Directoryのプラグインの概要」

- 第4.5項「Oracle Access Managerプラグインの概要」

4.1 プラグインとは

プラグインを使用すると、情報の区分化機能でOracle Virtual Directoryを拡張し、特定のビジネスや技術の要件に対応することができます。また、プラグインを使用して、カスタム・ロジックをトランザクションの一部として提供することや、カスタム・データ・ソースに簡単に接続することができます。Oracle Virtual Directoryは、JavaプラグインおよびPythonマッピング・プラグインの2種類をサポートしています。

注意:
この章は、Oracle Virtual Directory用のJavaプラグインに特化していますが、操作上、Oracle Virtual Directoryではこれら2種類のプラグインは同等に扱われます。この章では、プラグインはJavaプラグインを表します。マッピング・プラグインの詳細は、第5章「Oracle Virtual Directoryのマッピングの概要」を参照してください。

Oracle Virtual Directoryには、分析、監査、キャッシング、動的グループのプレゼンテーションなど各種の目的に応じたプラグインがいくつか用意されています。また、様々な方法を使用してプラグインをデプロイすることで、仮想ディレクトリ内でのプラグインの配置を完全に制御できます。次に例を示します。

- プラグインを「接続」し、結合された再利用可能な機能を構築する。

- プラグインがすべてのリクエストとレスポンスを処理するように、「グローバル」サーバー・レベルでプラグインをデプロイする。

- プラグインが特定のアダプタに対するリクエストとレスポンスを処理するように、アダプタ・レベルでプラグインをデプロイする。

たとえば、特定のMicrosoft Active Directoryサーバー上のみで、Active Directoryユーザーの標準inetOrgPersonオブジェクト・クラスへの変換を行うマッピングが実行された後にのみ実行されるCacheプラグインをデプロイすることができます。

注意:

- グローバル・レベルでプラグインを構成するには、Oracle Directory Services Managerのタスク選択バーから「拡張」を選択します。プロセスの詳細な手順は、「グローバル・サーバー・プラグインの管理」を参照してください。

- アダプタ・レベルでプラグインを構成するには、Oracle Directory Services Managerのタスク選択バーから「アダプタ」を選択します。プロセスの詳細な手順は、「アダプタ・プラグインの管理」を参照してください。

図4-1に、Oracle Virtual Directoryのプラグイン・フレームワークの3層アーキテクチャを示します。

図4-1 Oracle Virtual Directoryのプラグイン・フレームワーク

プラグインはチェーンを形成するように配置されています。Oracle Virtual Directoryがリクエストを受信すると、リクエストは次の順序でOracle Virtual Directoryに渡されます(図4-1を参照)。

1. グローバル・サービス・インタフェース(GSI)

2. グローバル・プラグインのチェーン

3. アダプタ・サービス・インタフェース(ASI)

4. アダプタ・プラグインのチェーン

グローバル・プラグインは、すべてのリクエストに対してコールされます。インバウンド・リクエストの場合、すべてのグローバル・プラグインが実行されると、リクエストはASIに移動します。ASIは、ルーティングおよびアダプタの処理が決定されるOracle Virtual Directoryのコンポーネントです。ルーティング・システムによりリクエストにどのアダプタが含まれるかが決定されると、選択されたアダプタ・プラグインが実行されます。アダプタによりレスポンスが生成され、さらに処理およびフィルタ処理を実行するためにチェーンに戻されます。

4.1.1 ネームスペースのフィルタ処理

Oracle Virtual Directoryでは、プラグインをグローバルに実行するか、または1つのアダプタのコンテキスト内で実行するかを柔軟に判断できます。状況によっては、プラグインがいつ使用されるかをさらに制限する必要が生じる場合もあります。たとえば、アダプタがMicrosoft Active Directoryドメインのかわりになるように設定され、DC=VAN,DC=Oracle,DC=comを指しているとします。ドメイン・ツリー内のそのポイントの下には、CN=UsersコンテナおよびCN=Groupsコンテナがあります。プラグインまたはマッピングにネームスペース・フィルタを追加すると、ツリーの一部にのみそれらを適用できます。

4.2 汎用目的のプラグインの概要

この項では、Oracle Virtual Directoryに組み込まれている汎用目的のプラグインについて説明します。汎用目的のプラグインは、Oracle Virtual Directoryの機能を拡張して、特殊な機能またはマッピングを実行します。この項の内容は、次のとおりです。

- FA UserRoleプラグイン

- HideEntriesByFilterプラグイン

- ChangeUserRDNプラグイン

- UPNBindプラグイン

- ForkJoinプラグイン

- VirtualMemberofプラグイン

- VirtualAttributeプラグイン

- Dump Transactionsプラグイン

- DynamicTreeプラグイン

- DynamicEntryTreeプラグイン

- FlatTreeプラグイン

- DynamicGroupsプラグイン

- Cacheプラグイン

- ObjectClass Mapperプラグイン

- Sub-Treeプラグイン

- Performance Monitorプラグイン

- UniqueEntryプラグイン

- アダプタ・プラグイン・バージョン・プラグイン

- Proxy Authorization Supportプラグイン

- UserManagementプラグイン

- Changelogプラグイン

- Consolidated Changelogプラグイン

- GenericMapperプラグイン

- CoordinatorAdapterプラグイン

- DBPasswordプラグイン

- DNTranslatorプラグイン

- HideGroupsAndUsersプラグイン

- SAML XASPプラグイン

4.2.1 FA UserRoleプラグイン

FA UserRoleプラグインは、VDEが追加および変更操作を特定のアダプタにリダイレクトできるようにします。このプラグインは、グローバル・プラグインとしてのみ使用してください。

4.2.1.1 構成パラメータ

FA UserRoleプラグインには次の構成パラメータがあります。

objectWrite

アダプタ名のリストが後に続くattribute=valueタイプのフィルタ。このアダプタ名のリストは、指定された順序でアダプタのリストに追加および変更操作をリダイレクトするために使用されます。

この構成の複数のインスタンスを定義できます。たとえば、objectclass=user;A1;A2は、user objectclassのエントリがある場合、そのエントリに対する追加および変更操作は最初にアダプタA1にリダイレクトされることを意味します。A1に一致するものがない場合、操作はA2で実行されます。別の例として、cn=user1;A3があります。

4.2.2 HideEntriesByFilterプラグイン

HideEntriesByFilterプラグインは、検索によってどのエントリを戻すのかを詳細に制御できるようにします。HideEntriesByFilterプラグインは、そのhideFilter構成パラメータを使用してどのエントリを戻すのかを明示的に制御できるようにします。たとえば、Oracle Virtual Directoryをアドレス帳ディレクトリとして使用していて、技術サポートのエントリ(ou値がCSR)のみを表示する必要があるとします。hideFilterをou=CSRに設定してHideEntriesByFilterプラグインを使用し、アダプタが検索されたときに技術サポートのエントリのみが戻されるようにすることができます。

バインド操作のサポート

HideEntriesByFilterプラグインをデプロイすると、プラグインによって公開されるエントリのみがバインド操作を実行できるようになります。このプラグインは、検索中に非表示になっているエントリによるバインド操作の実行を防止します。バインド操作中はHideEntriesByFilterプラグイン・パラメータで構成される静的非表示フィルタおよびLdapURLのみが有効になり、動的非表示フィルタは有効になりません。

4.2.2.1 構成パラメータ

HideEntriesByFilterプラグインには、次の構成パラメータがあります。

hideFilter

検索に対して制限するエントリを制御するLDAPフィルタ。このフィルタには、静的フィルタまたは動的フィルタを含めることができます。

- たとえば、静的フィルタを作成する場合、hideFilterを(department=Sales)に設定すると、検索ではdepartment=Salesを含むエントリのみが戻されます。ただし、hideFilterを(!(department=Sales))に設定すると、検索ではdepartment=Salesを含まないエントリのみが戻されます。

- 動的フィルタは認証済ユーザーの属性値に基づいて作成します。動的フィルタは、「バインドされたユーザーと部門が同じユーザーをすべて取得する。ただし、アプリケーションでは、LDAP検索フィルタにこの基準を指定する必要はない。」などのユースケースをサポートできます。
たとえば、hideFilterを(department=%department%)に設定すると、このプラグインによって%department%が、そのバインドされたユーザーと関連付けられた実際の部門の値に置換されます。バインドされたユーザーのエントリに指定された属性の値が複数ある場合は、そのすべての値にORを指定することでフィルタが作成されます。

ldapURL

エントリDNに基づいて検索結果をさらに制限するために使用されるパラメータ。検索結果の一部として戻されるエントリがURLフィルタを満たす場合、そのエントリは、それがそのURLベースの子である場合にのみクライアントに戻されます。エントリがURLフィルタを満たさない場合、エントリはそのまま戻されます。

このパラメータは、1つのプラグイン構成で複数回使用できます。少なくともhideFilterまたはldapURLのいずれかの構成パラメータを設定する必要があります。

adapterNames

プラグインが1つのアダプタにデプロイされており、バインドされたユーザーが別のアダプタに存在している場合に使用されるパラメータ。このパラメータは、アダプタのリストをとり、1つのプラグイン構成で複数回使用できます。

動的フィルタを処理するために、ユーザーはadapterNamesで指定されているすべてのアダプタで問い合わせられます。ユーザーを戻すことなくすべてのアダプタに対する検索が失敗した場合、動的フィルタは無視され、元の検索フィルタが次のプラグインに送られます。

applyForAdmin

管理者に対してプラグインの処理を実行するかどうかを制御するブール値。このパラメータをfalseに設定しており、かつバインドされたユーザーがadminである場合、検索結果はこのプラグインでさらにフィルタ処理されることなく、そのままの状態で戻されます。

4.2.3 ChangeUserRDNプラグイン

ChangeUserRDNプラグインで、ソース・ディレクトリからOracle Virtual DirectoryにRDN値を名前変更または置換できます。このプラグインはLDAPディレクトリの移行の際に役立ちます。

4.2.3.1 構成パラメータ

ChangeUserRDNプラグインには、次の構成パラメータがあります。

objectType

RDNの名前変更を実行するオブジェクト・クラスのタイプを指定します。デフォルト設定はpersonです。

replaceValue

TrueまたはFalse: 元のRDN値(fromRDNパラメータで指定する)を新しいRDN値(toRDNパラメータで指定する)に置き換えるかどうかを指定します。デフォルト設定はtrueです。

注意:
この値がtrueに設定されており、エントリでその新しいRDN属性に複数の値がある場合、Oracle Virtual DirectoryではRDNの属性値ベクターの最初の値が使用されます。

fromRDN

Oracle Virtual Directoryで置換または名前変更される、ソース・ディレクトリの元のRDN属性名を指定します。

toRDN

Oracle Virtual Directoryで使用される新しいRDN属性名を指定し、fromRDN構成パラメータで指定されている属性名と置き換えます。

dnAttributes

RDNの名前変更を実行するDNを持つ属性のリスト。属性のデフォルト・リストは、member、uniquemember、manager、owner、managedbyです。

4.2.4 UPNBindプラグイン

UPNBindプラグインにより、任意の構成済のusername属性(cn、SamAccountName、sn、uidなど)またはusername@suffix属性(UserPrincipalName、Mailなど)を使用してバインドできます。このプラグインは、Active Directory中心のアプリケーションで役立ち、DNを検索する必要性を排除することでアダプタのデプロイメントを容易にすることができます。

注意:
UPNBindプラグインは、グローバル・プラグインとしてのデプロイメントに対してのみサポートされています。UPNBindプラグインをアダプタにデプロイしないでください。

4.2.4.1 構成パラメータ

UPNBindプラグインには、次の構成パラメータがあります。

注意:
少なくともNameAttributesまたはNameAndSuffixAttributesのいずれかの構成パラメータを設定する必要があります。

NameAttributes

ユーザーを認証するために使用するnaming属性のリストを指定します。たとえば、cn、sn、uid、SAMAccountNameです。

NameAndSuffixAttributes

ユーザーを認証するために使用する、UPN、mailなどのname@suffixの形式の属性のリスト。

BindOption

複数のユーザーがNameAttributesおよびNameAndSuffixAttributesのパラメータに同じ値を持っている場合に、UPNBindプラグインが結果のエントリを処理する方法を決定します。次に、BindOptionオプションでサポートされている値のリストと説明を示します。デフォルト設定はQuickFailです。

- QuickFail: 構成済の属性に対して複数のユーザーが同じ値を持っている場合、UPNBindプラグインによって複数のユーザー・エントリが見つかりましたエラーが表示され、LDAPバインドは失敗します。

- FirstUser: UPNBindプラグインは最初のユーザーとしてバインドし、そのバインドの結果を戻します。

- FirstSuccess: UPNBindプラグインは最初のユーザーとしてバインドします。そのバインドに失敗すると、UPNBindプラグインは、成功したバインドが見つかるまでリストのすべてのユーザーに対して試行を続けます。

AdapterName

認証に使用するアダプタを指定します。指定したアダプタにそのユーザー・エントリが存在しない場合、LDAPバインドは失敗し、「無効な資格証明」メッセージが表示されます。これはオプションのパラメータです。このパラメータを指定しない場合、このプラグインでは、ユーザーを認証するために使用可能なすべてのアダプタが考慮されます。このパラメータは、認証にどのアダプタを使用するのかわかっている場合にプラグインのパフォーマンスの向上に役立ちます。

4.2.5 ForkJoinプラグイン

ForkJoinプラグインは、結合ビュー・アダプタに対してのみサポートされており、プライマリ・アダプタ、セカンダリ・アダプタ、または結合ビューでプライマリとセカンダリの両方のアダプタに対する検索の実行を可能にします。LDAP検索の際に、セカンダリ・アダプタでのみ使用可能な属性が検索フィルタに1つ以上含まれている場合、このプラグインを使用しないと、検索フィルタ全体がプライマリ・アダプタにのみ送られるため、Oracle Virtual Directoryはそのフィルタを満たす結合エントリを戻すことができません。ForkJoinプラグインを使用すると、Oracle Virtual Directoryは、プライマリ・アダプタ内のみの属性、セカンダリ・アダプタ内のみの属性、およびプライマリとセカンダリの両方のアダプタ内の属性を検索できます。

たとえば、ユーザー・データがActive Directoryのsamaccountname、sn、givenname、employeenumberという複数のアイデンティティ・ソースに置かれているとします。ただし、title属性はHuman Resourcesデータベースに格納されています。Active Directoryがプライマリ・アダプタとして、Human Resourcesデータベースがセカンダリ・アダプタとして構成されており、ForkJoinプラグインがデプロイされている場合、LDAP対応アプリケーションがsamaccountname、またはtitle、あるいはその両方に基づいてユーザー・データの問合せを実行すると、Oracle Virtual Directoryがそのフィルタを満たし、かつActive DirectoryとHuman Resourcesデータベースの両方のデータを含むエントリを戻します。

バインド操作のサポート

ForkJoinプラグインを結合アダプタに対してデプロイしており、JoinPolicyがFullOuterJoinに設定されている場合、バインドは、プライマリ・アダプタに存在しない、セカンダリのみのユーザーに対しても可能になります。

4.2.5.1 構成パラメータ

ForkJoinプラグインには、次の構成パラメータがあります。

注意:
ForkJoinプラグインをデプロイするには、少なくともSecondaryOnlyAttributesまたはPrimaryAndSecondaryAttributesのいずれかの構成パラメータを設定する必要があります。

SecondaryOnlyAttributes

セカンダリ・アダプタにのみ存在し、アプリケーションが検索フィルタで使用できる属性のリスト。SecondaryOnlyAttributes構成パラメータで指定した属性をPrimaryAndSecondaryAttributes構成パラメータでも指定することはできません。

PrimaryAndSecondaryAttributes

プライマリとセカンダリの両方のアダプタに存在し、アプリケーションが検索フィルタで使用できる属性のリスト。PrimaryAndSecondaryAttributes構成パラメータで指定した属性をSecondaryOnlyAttributes構成パラメータでも指定することはできません。

注意:
objectclass属性は、明示的に構成されていない場合でも、デフォルトで常にPrimaryAndSecondaryAttributesであると見なされます。

JoinPolicy

次の設定をサポートしています。

- Standard Join: セカンダリ・アダプタで対応するエントリと結合した後、プライマリ・アダプタで検索フィルタを満たすすべてのエントリを戻します。

- Left Outer Join: セカンダリ・アダプタの対応するエントリと結合した後、プライマリ・アダプタのすべてのエントリを戻し(Standard Join)、さらに、セカンダリ・アダプタの、結合条件を満たし、かつプライマリ・アダプタに対応する一致があるエントリを戻します。これは、データベース用語の左側外部結合と同等です。

- Full Outer Join: セカンダリ・アダプタの対応するエントリと結合した後、プライマリ・アダプタのすべてのエントリを戻し(Standard Join)、さらに、セカンダリ・アダプタの、結合条件を満たし、かつプライマリ・アダプタに対応する一致があるエントリを戻し(Left Outer Join)、さらに、検索フィルタを満たすがプライマリ・アダプタに一致するエントリがないエントリを戻します。これは、データベース用語の左側外部結合+右側外部結合と同等です。

注意:
Full Outer Joinが構成されている場合の条件付き結合については、セカンダリ・アダプタのエントリは、結合条件のフィルタを考慮することなくプライマリ・アダプタのエントリにマップされます。

4.2.5.2 ForkJoinプラグイン・デプロイメントの例

この項では、ForkJoinプラグインのデプロイメント例を示します。次のデータが、プライマリ・アダプタおよびセカンダリ・アダプタに配置されています。プライマリ・アダプタのネームスペースはdc=primary、セカンダリ・アダプタのネーム・スペースはdc=secondaryです。

プライマリ・アダプタのデータ

セカンダリ・アダプタのデータ

dn: cn=Rock, dc=primary
objectclass: inetorgperson
cn: Rock
sn: Anne
givenname: Anne rock
telephonenumber: 54300

dn: cn=Rock, dc=secondary
objectclass: inetorgperson
cn: Rock
sn: Anne
title: Manager

dn: cn=Sandy, dc=primary
objectclass: inetorgperson
cn: Sandy
sn: Ketty
manager:  cn=Rock, dc=primary
telephonenumber: 54301

dn: cn=Sandy, dc=secondary
objectclass: inetorgperson
cn: Sandy
sn: Ketty
title: SMTS

dn: cn=Rivry,dc=primary
objectclass: inetorgperson
cn: Rivry
sn: Rod
title: Trainee
manager: cn=Rock, dc=secondary
telephonenumber: 54303
description: Trainee for dept 543
departmentNumber: 543

dn: cn=Rivry,dc=secondary
objectclass: inetorgperson
cn: Rivry
sn: Rod
title: Trainee

dn: cn=Woods,dc=primary
objectclass: inetorgperson
cn: Woods
sn: Tent
description: User with no title

dn: cn=Mounty,dc=secondary
objectclass: inetorgperson
cn: Mounty
sn: Ret
title: MTS - dept_sec

結合条件はcn=cnであり、SecondaryOnlyAttributesパラメータがtitleに設定されています。サブツリー有効範囲と(|(title=*e*)(sn=*e*))のフィルタを指定したldapsearchを、結合ビュー・アダプタに対して実行します。

JoinPolicyのタイプごとの検索結果は次のとおりです。

Standard Join:

cn=Rock,dc=Join
sn=Anne
cn=Rock
title=Manager

cn=Sandy,dc=Join
sn=Ketty
cn=Sandy
title=SMTS

cn=Woods,dc=Join
sn=Tent
cn=Woods

Left Outer Join:

cn=Rock,dc=Join
sn=Anne
cn=Rock
title=Manager

cn=Sandy,dc=Join
sn=Ketty
cn=Sandy
title=SMTS

cn=Woods,dc=Join
sn=Tent
cn=Woods

cn=Rivry,dc=Join
sn=Rod
cn=Rivry
title=Trainee

Full Outer Join:

cn=Rock,dc=Join
sn=Anne
cn=Rock
title=Manager

cn=Sandy,dc=Join
sn=Ketty
cn=Sandy
title=SMTS

cn=Woods,dc=Join
sn=Tent
cn=Woods

cn=Rivry,dc=Join
sn=Rod
cn=Rivry
title=Trainee

cn=Mounty,dc=Join
sn=Ret
cn=Mounty
title=MTS - dept_sec

4.2.6 VirtualMemberofプラグイン

VirtualMemberofプラグインは、memberof属性をpersonエントリに追加します。このmemberof属性の値は、そのpersonエントリが属するすべてのグループのDNです。VirtualMemberofプラグインは、アプリケーションがグループ・メンバーシップを確認する必要があるが、グループに対する2つ目の検索の実行を回避する場合に役立ちます。

4.2.6.1 構成パラメータ

VirtualMemberofプラグインには、次の構成パラメータがあります。

searchBase

personエントリを含むグループを検索するベースのDN。

explicitrequestonly

TrueまたはFalse: Trueに設定した場合、戻される属性として明示的にリクエストされている場合にかぎり、memberof属性がそのエントリに追加されます。デフォルト値はTrueです。

adapterName

グループ・エントリを含むアダプタのリスト。このパラメータは、グループに対して検索の有効範囲を最小限にするために役立ちます。

4.2.7 VirtualAttributeプラグイン

VirtualAttributeプラグインにより、マッピングをデプロイせずに複数の属性で属性データを再使用できます。たとえば、新しいアプリケーションで、ある人の姓名を表示に使用する必要がある場合、アプリケーションではcnを検索するかわりにdisplayname属性を使用する必要があるが、それがアダプタ・データに存在しないとします。VirtualAttributeプラグインを使用すると、displaynameをcnの値にマップでき、かつcn属性を検索する他のアプリケーションがその属性を依然として使用できるようにすることができます。displayname属性がアダプタ・データにすでに存在している場合、displaynameの既存の値にcnの値を追加するか、displaynameの値をcnの値に置き換えるのかを指定できます。

属性値の追加および置換に加えて、VirtualAttributeプラグインを使用して、次のように実行することもできます。

- 他の属性およびリテラル値を使用することで属性をその場で作成する。

- ConditionalPublishマッピングの機能を実行する。つまり、RemoveAttributes構成パラメータを使用すると、属性がクライアントに戻される前にエントリから実際に削除される属性を指定できます。

注意:
VirtualAttributeプラグインで追加または置換される属性に対して定数値を指定できます。
AddAttributeパラメータとReplaceAttributeパラメータでは、仮想属性に %dn%値を割り当てて、その仮想属性にエントリDN(エントリ名)値を追加したり、エントリDN(エントリ名)値で置き換えることができます。

たとえば、エントリDN(名)値をdistinguishedNameに追加するには、AddAttributeパラメータの値をdistinguishedName=%dn%に設定します。

4.2.7.1 構成パラメータ

VirtualAttributeプラグインには、次の構成パラメータがあります。

注意:
最低でも、AddAttributeまたはReplaceAttributeのいずれかの構成パラメータを設定する必要があります。

ContainerDN

オフションのパラメータであるContainerDNは、VirtualAttributeプラグインが適用されるコンテナを指定します。VirtualAttributeプラグインは、containerDNの下のmatchFilterパラメータで指定されたフィルタに一致するすべてのエントリに適用できます。このパラメータは、繰り返し使用して複数のcontainerDNを指定できます。また、このパラメータは、VirtualAttributeプラグインを、アダプタによって公開されるデータ内の特定のブランチに制限します。デフォルト設定は""、つまりDSEです。ContainerDNパラメータを設定しないと、VirtualAttributeプラグインはディレクトリ・ツリー全体を検索します。

MatchFilter

オフションのパラメータであるMatchFilterは、VirtualAttributeプラグインが適用されるエントリを指定します。VirtualAttributeプラグインは、containerDNの下のMatchFilterパラメータで指定されたフィルタに一致するすべてのエントリに適用できます。MatchFilterパラメータを設定しないと、VirtualAttributeプラグインは、ContainerDNパラメータによって指定されるDNの下のすべてのエントリに適用されます。

AddAttribute

エントリに追加する属性のリストおよび、これらの仮想属性に割り当てる値。AddAttributeパラメータによって指定された属性がすでにエントリに存在している場合、VirtualAttributeプラグインは、指定された値を値の既存のセットに追加します。この値は、定数、別の属性、または属性値と定数の組合せにすることができます。

AddAttributeパラメータは、VirtualAttributeプラグインに対して複数回設定できます。AddAttributeパラメータに設定する値は、ReplaceAttributeと相互に排他、つまり異なる必要があります。

次に例を示します。

- cn属性の値をuidおよびdisplayNameに追加するには、AddAttributeパラメータの値をuid=displayName=%cn%に設定します。

- 定数値AcmeをcompanyName属性に追加するには、AddAttributeパラメータの値をcompanyName=Acmeに設定します。

- cn、snおよびdcの値の組合せをmember属性に追加するには、AddAttributeパラメータ値をmember={cn=%cn%, sn=%sn%, dc=oracle, dc=com}に設定します。

注意:
中カッコ({})は重要です。

AddAttributeパラメータでは、仮想属性に値ペアを含むリストを割り当てることができます。Oracle Virtual Directoryでは、クライアント・アプリケーションとバックエンド・ストレージの間の値のマッピングを実行できます。

このフォーマットの値を入力します。

<attributename> = (clientValue1, sourceValue1)(clientValue2, sourceValue2)...

たとえば、departmentName属性のクライアント・アプリケーション値が(1,2,3)で、対応するバックエンド・ストレージ値が(Marketing, Sales, Finance)であると仮定します。Oracle Virtual Directoryでマッピングする場合は、パラメータ値をdepartmentName=(1,Marketing)(2,Sales)(3,Finance)として構成します。

別の例では、エントリが従業員用あるいは顧客用かを示すためにUserType仮想属性を追加することで、従業員用にActive Directoryを、顧客用にOracle Unified Directoryを使用するようにOracle Virtual Directoryを構成するとします。

- Active Directoryアダプタを構成するには、UserType=Employeeに設定したAddAttributeパラメータを使用して、VirtualAttributeプラグインをデプロイする必要があります。

- Oracle Unified Directoryアダプタを構成するには、UserType=Customerに設定したAddAttributeパラメータを使用して、VirtualAttributeプラグインをデプロイする必要があります。

この構成のエントリでは、追加の仮想属性UserTypeが含まれており、それらを返すアダプタに応じて、EmployeeまたはCustomerの値が指定されます。

ReplaceAttribute

エントリに追加する属性のリストおよび、これらの仮想属性に割り当てる値。ReplaceAttributeパラメータによって指定された属性がすでにエントリに存在している場合、VirtualAttributeプラグインは、指定された値を使用してそれらを置換します。この値は、定数、別の属性、または属性値と定数の組合せにすることができます。

ReplaceAttributeパラメータは、VirtualAttributeプラグインに対して複数回設定できます。ReplaceAttributeパラメータに設定する値は、AddAttributeと相互に排他、つまり異なる必要があります。

次に例を示します。

- uidおよびdisplayNameの値をcn属性の値に置き換えるには、ReplaceAttributeパラメータをuid=displayName=%cn%のように構成できます。

- companyName属性の値を定数値Acmeに置き換えるには、ReplaceAttributeパラメータをcompanyName=Acmeのように構成できます。

- member属性値をcn、snおよびdcの値の組合せに置き換えるには、ReplaceAttributeパラメータをmember={cn=%cn%, sn=%sn%, dc=oracle, dc=com}のように構成します。

注意:
中カッコ({})は重要です。

ReplaceAttributeパラメータでは、仮想属性に値ペアを含むリストを割り当てることができます。Oracle Virtual Directoryでは、クライアント・アプリケーションとバックエンド・ストレージの間の値のマッピングを実行できます。

このフォーマットの値を入力します。

<attributename> = (clientValue1, sourceValue1)(clientValue2, sourceValue2)...

たとえば、departmentName属性のクライアント・アプリケーション値が(1,2,3)で、対応するバックエンド・ストレージ値が(Marketing, Sales, Finance)であると仮定します。Oracle Virtual Directoryでマッピングする場合は、パラメータ値をdepartmentName=(1,Marketing)(2,Sales)(3,Finance)として構成します。

RemoveAttributes

指定されたContainerDNの下でMatchFilterを満たすエントリから実際に削除される属性のカンマ区切りリスト。

4.2.7.2 VirtualAttributeプラグイン・デプロイメントの例

次に示すVirtualAttributeプラグイン構成パラメータが設定されているとします。

構成パラメータ

値

AddAttribute

uid=displayName=%cn%

AddAttribute

certificate=Verisign

AddAttribute

member={cn=%cn%, sn=%sn%, dc=oracle, dc=com}

ReplaceAttribute

title=%designation%

RemoveAttributes

designation,uid

処理される元のエントリは次のとおりであるとします。

dn: cn=john, dc=com
cn: john
cn: jsmith
uid: 1234
certificate: selfsigned
designation: SMTS
title: Senior Software Engineer
sn: smith
objectclass: person
objectclass: top

次に、VirtualAttributeプラグインが元のエントリをどのように変換するのかを示します。

AddAttributes構成パラメータを処理した後のエントリは次のとおりです。

dn: cn=john, dc=com
cn: john
cn: jsmith
uid: 1234
uid: john
uid: jsmith
displayName: john
displayName: jsmith
certificate: verisign
certificate: selfsigned
designation: SMTS
title: Senior Software Engineer
sn: smith
objectclass: person
objectclass: top
member: cn=john, sn=smith, dc=oracle, dc=com
member: cn=jsmith, sn=smith, dc=oracle, dc=com

ReplaceAttributes構成パラメータを処理した後のエントリは次のとおりです。

dn: cn=john, dc=com
cn: john
cn: jsmith
uid: 1234
uid: john
uid: jsmith
displayName: john
displayName: jsmith
certificate: verisign
certificate: selfsigned
designation: SMTS
title: SMTS
sn: smith
objectclass: person
objectclass: top
member: cn=john, sn=smith, dc=oracle, dc=com
member: cn=jsmith, sn=smith, dc=oracle, dc=com

RemoveAttributes構成パラメータを処理した後のエントリは次のとおりです。

dn: cn=john, dc=com
cn: john
cn: jsmith
displayName: john
displayName: jsmith
certificate: verisign
certificate: selfsigned
title: SMTS
sn: smith
objectclass: person
objectclass: top
member: cn=john, sn=smith, dc=oracle, dc=com
member: cn=jsmith, sn=smith, dc=oracle, dc=com

4.2.8 Dump Transactionsプラグイン

Dump Transactionsプラグインは、各LDAP操作の全トランザクションのレコードを生成し、そのレコードをOracle Virtual Directoryのコンソール・ログに記録します。Dump Transactionsプラグインは、任意のログ・レベルで実行するように構成できます。Dump Transactionsプラグインは、ロジックがOracle Virtual Directoryシステムを通過する際に、マッピングおよび統合作業を診断するのに特に便利です。Dump Transactionsプラグインを使用すると、サーバー・ログ・レベル全体をより詳細なレベルに設定せずに、特定のアダプタの問題を分析できます。Dump Transactionsプラグインは、Oracle Virtual Directoryのプロトコル・アナライザのようなものです。

4.2.8.1 構成パラメータ

Dump Transactionsプラグインには、次の構成パラメータがあります。

loglevel

プラグインがトランザクションを記録するログ・レベル。サポートされている値は、SEVERE、WARNING、INFO、FINE、FINERおよびFINESTです。デフォルト値はありません。

4.2.9 DynamicTreeプラグイン

DynamicTreeプラグインにより、実在、仮想、または別の実在エントリを指すポインタである親エントリを持つソース・ディレクトリ・エントリの属性値を使用してOracle Virtual Directory内にDNを作成できます。

注意:
DynamicTreeプラグインは、アダプタへのデプロイメントに対してのみサポートされています。DynamicTreeプラグインをグローバル・プラグインとしてデプロイしないでください。

このプラグインは、ソース・ディレクトリ・エントリに含まれる構造型データに基づいてLDAP階層形式で組織図およびレポートを生成する際に役立ちます。Dynamic Treeプラグインは、ユーザーによるディレクトリ・ツリーの参照が可能なため、DynamicEntry Treeプラグインよりも高い柔軟性を備えています。

次の図と例について考えてみます。

注意:
次の図では、ソース・ディレクトリの属性値が太字で示されています。

図4-2は、ソース・ディレクトリに配置されているディレクトリ構造の例を示しています。

図4-2 ソース・ディレクトリのディレクトリ構造の例

図4-3は、parentEntryTypeパラメータを1に、attributeNameパラメータをparentouに設定したDynamicTreeプラグインが、図4-2に示すソース・ディレクトリの平面的な階層を、Oracle Virtual Directoryのレイヤー階層に変換する方法の例を示しています。

図4-3 DynamicTreeプラグインを使用したOracle Virtual Directoryのディレクトリ構造

図4-4は、ソース・ディレクトリに配置されているディレクトリ構造のもう1つの例を示しています。

図4-4 ソース・ディレクトリのディレクトリ構造の例

図4-5は、parentEntryTypeパラメータを0に、attributeNameパラメータをlに設定したDynamicTreeプラグインが、図4-4に示すソース・ディレクトリのl属性値に基づいてOracle Virtual Directoryにレイヤー階層に作成する方法の例を示しています。

図4-5 DynamicTreeプラグインを使用したOracle Virtual Directoryのディレクトリ構造

4.2.9.1 構成パラメータ

DynamicTreeプラグインには、次の構成パラメータがあります。

attributeName

エントリの親エントリを指定するために使用される属性。

parentEntryType

親エントリのタイプを指定します。サポートされている値は0および1です。仮想親エントリに対しては0を選択します。これは、ソース・ディレクトリの属性値に基づいてOracle Virtual Directoryによって作成されるエントリです。複数のouコンテナによって作成された親エントリに対しては1を選択します。

4.2.10 DynamicEntryTreeプラグイン

DynamicEntryTreeは、汎用目的のプラグインであり、エントリのリーフ・ノードにある属性を使用して仮想ディレクトリ・ツリー階層を生成するために使用できます。たとえば、アダプタがo=Airius.comというルートを持っており、ユーザーがuid=scarter,ou=people,o=airius.comとして存在する場合、DynamicEntryTreeプラグインは、uid=scarter,ou=accounting,ou=people,o=airius.comなどユーザーのエントリに存在するデータを使用して新しい階層を挿入できます。

4.2.10.1 構成パラメータ

DynamicEntryTreeプラグインには、次の構成パラメータがあります。

patterns

DynamicEntryTreeプラグインは、patterns構成パラメータを使用して一致パターンを指定することにより構成されます。patternsパラメータ値の構文は次のとおりです。

attr[=entryattr[(SUPPRESS|value)]],...

DNコンポーネントごとに、属性名は、等号(=)の右側にある属性で置換される値を持つことができます。置換が必要ない場合、単に属性がリストされ、それらは基本的に元のDNと一致するコンポーネントを参照します。値が置換される場合、entryattrに値がない場合の処理をさらに条件付けることもできます。SUPPRESSを指定してエントリを完全に抑制するか、entryattr名の後の大カッコ内にデフォルト値を指定できます。

|を使用して区切ることで、複数のパターンを定義できます。次に例を示します。

uid,ou=department(contract),ou|cn,ou=code(SUPPRESS)

このルールには2つのパターンがあります。1つのパターンは、uid,ouに一致するdnコンポーネントを持つアダプタ・ルート(o=airius.com)の下のオブジェクトに一致します。したがって、uid=scarter,ou=people,o=airius.comがマッピングに選択されます。戻されるときは、department属性が値についてチェックされます。何も存在しない場合、静的テキストcontractに置換されます。検索の際は、ベースがuid=scarter,ou=accounting,ou=people,o=airius.comに設定されている場合、新しいベースがuid=scarter,ou=people,o=airius.comになるように検索が変更され、フィルタはou=accountingの追加のandで結合された項目で変更されます。

2つ目のパターンは、cn rdnコンポーネントを持つo=airius.comの子オブジェクトに一致することが意図されています。一致した場合、そのエントリに属性codeがあると、cn=mygroup,ou=code12,o=airius.comを作成してその値が置換されます。属性codeがない場合、エントリの結果はSUPPRESSキーワードによって抑制されます。

4.2.11 FlatTreeプラグイン

FlatTreeプラグインは、DynamicEntryTreeの場合と同様に、仮想ディレクトリ・ツリーの動的マッピングを実行します。FlatTreeプラグインではディレクトリ・ソースが圧縮されるため、すべてのエントリがアダプタ・ルートの下に直接表示されます。

たとえば、ルートがdc=oracle,dc=comのアダプタがあり、FlatTreeプラグインはそれに対してデプロイされていると仮定します。FlatTreeプラグインは、uid=jsmith,cn=users,dc=peopleContainer,dc=oracle,dc=comなどのエントリDNを、バックエンドからuid=jsmith,dc=oracle,dc=comに変換します(アダプタ・ベースで直接実行される)。したがって、バックエンド・データの階層構造はフラット化され、アダプタ・ベースの下に直接表示されます。

FlatTreeプラグインは、2種類のデプロイ・モードで動作します。

- 既存のネームスペースをフラット化するための既存のアダプタの一部として動作

- カスタム・アダプタ・デプロイの一部として動作

カスタム・アダプタ・デプロイメントの一部として、FlatTreeプラグインのアダプタ・パラメータを使用して、指定されたアダプタからデータを取得できます。これにより、データは、カスタム・アダプタのネームスペースの一部として表示されます。この方法でデプロイすると、アダプタ・ルート・オブジェクトは定義されません。このタイプのデプロイメントは、重複した親ノードを作成せずに、親アダプタの上に複数のアダプタをオーバーレイする場合に便利です。

4.2.11.1 構成パラメータ

次に、FlatTreeプラグイン構成パラメータのリストと説明を示します。

criteria

criteriaには、FlatTreeプラグインを介して検索できるエントリを制限するLDAPフィルタを定義します。たとえば、criteriaをobjectclass=userと設定した場合、FlatTreeプラグインを介して戻されるのはuserオブジェクトのみです。

adapter

adapterパラメータが定義されていない場合、FlatTreeプラグインでは、データは親アダプタを介して取得されるとみなされます。定義されている場合、adapterパラメータは、Oracle Virtual Directory構成内の別のアダプタ名である必要があります。FlatTreeプラグインによりこのアダプタからデータが取得され、そのエントリが親アダプタのルートにマップされます。adapterパラメータが定義されている場合、子エントリのみが戻され、ルート・オブジェクトは戻されません。

4.2.12 DynamicGroupsプラグイン

DynamicGroupsプラグインを使用すると、Oracle Virtual Directoryで(動的グループと呼ばれる)groupofuniquenamesおよびgroupofurlsの両方のLDAPオブジェクト・クラスを処理し、それを仮想の静的なグループまたはgroupofuniquenamesと同等のものに変換できます。このプラグインは、戻されるLDAPオブジェクトを監視することで機能し、memberurl属性が存在し、かつオブジェクト・クラスがgroupofuniquenamesおよびgroupofurlsの両方であるオブジェクトを検出します。

検出された場合には、プラグインによりmemberurl値が自動的に処理され、uniquemember属性に結果が追加されます。動的にオブジェクトが処理されることにより、管理者は、通常ならgroupofurlsオブジェクト・クラスをサポートしないアプリケーションとの互換性を維持しながら、静的メンバーおよび動的メンバーの両方が含まれるグループを定義できます。

例4-1は、Dynamic Groupsプラグインが有効化されていない場合の問合せの例を示しています。2つのグループが戻され、1つ目のグループには、2つの静的メンバーと、メンバーとなる特定のディレクトリ・サブツリーを定義するmemberurlが含まれています。

例4-1 Dynamic Groupsプラグインが有効化されていない場合の問合せの例

C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(memberurl=*)"

cn=test,ou=groups,ou=airius,o=yourcompany.com
cn=test
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(objectclass=person)(obj
ectclass=organizationalperson))
objectclass=groupofuniquenames
objectclass=groupofurls
objectclass=top
uniquemember=cn=Paul Jacobs,ou=People,ou=Airius,o=yourcompany.com
uniquemember=cn=Wendy Verbaas,ou=People,ou=Airius,o=YourCompany.com

cn=TestCheck,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=alt bind,o=yourcompany.com??sub?(&(userprincipalname=*))
objectclass=groupofuniquenames
objectclass=groupofurls
cn=TestCheck

例4-2に、例4-1と同じ問合せで、Dynamic Groupsプラグインが有効化されている場合の結果を示します。

例4-2 Dynamic Groupsプラグインが有効化されている場合の問合せの例

C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(cn=test)"

cn=test,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(objectclass=person)(obj
ectclass=organizationalperson))
objectclass=groupofuniquenames
objectclass=groupofurls
objectclass=top
cn=test
uniquemember=cn=Paul Jacobs,ou=People,ou=Airius,o=yourcompany.com
uniquemember=cn=Wendy Verbaas,ou=People,ou=Airius,o=YourCompany.com
uniquemember=cn=Vipi Velasquez,ou=accounting,o=yourcompany.com
uniquemember=cn=Preston Pena-Fernandez,ou=accounting,o=yourcompany.com
uniquemember=cn=Andreas O'Hara,ou=accounting,o=yourcompany.com
uniquemember=cn=Chitra Guenette,ou=accounting,o=yourcompany.com
...
uniquemember=cn=Jim Ward,ou=accounting,o=yourcompany.com

クライアント・リクエストに指定されている検索フィルタがリモート・バックエンド・サーバーからエントリを戻さない場合にのみ、Dynamic GroupプラグインがmemberURL値を拡張します(つまり、memberURLにベース、有効範囲、フィルタを指定してLDAP検索問合せを実行し、戻されたDNをメンバー属性に追加します)。

この点を説明するために、例4-3に示すLDAPエントリが、Oracle Virtual Directoryを使用するように構成されたリモートLDAPサーバーに存在していると想定します。

例4-3 Oracle Virtual Directoryを使用しているリモートLDAPサーバー上のLDAPエントリ

dn:cn=admingroup,dc=groups,dc=acme,dc=com
uniqueMember:cn=mark,cn=users,dc=acme,dc=com
memberURL:ldap:///cn=users,dc=acme,dc=com??sub?(|(cn=john)(cn=smith))
objectClass:groupOfUniqueNames
objectClass:groupOfUrls

次のLDAP検索では、memberURL値を拡張することなく、エントリがそのままの状態で戻されます。

Base DN: dc=groups,dc=acme,dc=com
Scope: sub
Filter: uniquemember=cn=mark,cn=users,dc=acme,dc=com

ただし、次のLDAP検索を実行すると、Dynamic Groupプラグインによって例4-4に示すuniqueMemberにcn=john値を持つLDAPエントリが戻されます。

Base DN: dc=groups,dc=acme,dc=com
Scope: sub
Filter: uniquemember=cn=john,cn=users,dc=acme,dc=com

例4-4 uniqueMemberの値とともに戻されるLDAPエントリ

dn:cn=admingroup,dc=groups,dc=acme,dc=com
uniqueMember:cn=mark,cn=users,dc=acme,dc=com
uniqueMember:cn=john,cn=users,dc=acme,dc=com
memberURL:ldap:///cn=users,dc=acme,dc=com??sub?(|(cn=john)(cn=smith))
objectClass:groupOfUniqueNames
objectClass:groupOfUrls

バックエンド・リモート・サーバーで構成された動的グループを解決するには、次の手順を実行する必要があります。

1. DynamicGroupsプラグインを構成します。

2. memberurlをリモート・ベースからプロキシ・ルートDNに変更するアダプタ構成の「DN属性」リストにmemberurl属性を追加します。この構成がない場合、このアダプタに対して動的グループを変換することはできません。

たとえば、Oracle Virtual Directoryアダプタ構成のベース・ルートDNがリモート・ベースと異なる場合に、DynamicGroupsプラグインをアクティブ化して動的グループを解決するには、次の手順を実行します。

1. リモート・サーバーで動的グループを構成します。

cn=dyngroup,dc=ralf,dc=oracle,dc=com
memberurl: ldap:///dc=ralf,dc=oracle,dc=com??sub?cn=a*
uniquemember: cn=b1,ralf,dc=oracle,dc=com

2. 動的メンバー・エントリを移入します。

cn=a1,dc=ralf,dc=oracle,dc=com

3. LDAPアダプタをルートDNがリモート・ベースと等しくならないように構成します。

Root DN : dc=test,dc=ovd,dc=comRemote base : dc=ralf,dc=oracle,dc=com

4. アダプタ構成のdnAttributeリストにmemberurlを追加します。

DN Attributes : uniquemember,manager,secretary,owner,memberurl

5. DynamicGroupsプラグインを構成します。

6. プロキシ・ベースで検索操作を実行します。

> ldapsearch -p 5566 -D cn=admin -w welcome1 -b
"dc=test,dc=ovd,dc=com"
-s sub "cn=dyn*"

テスト結果は、次の例のようになります。

cn=dyngroup,dc=test,dc=ovd,dc=com
memberURL=ldap:///dc=dc=test,dc=ovd,dc=com??sub?cn=a*
objectClass=groupofuniquenames
objectClass=groupofurls
objectClass=top
cn=dyngroup
uniquemember=cn=b1,dc=test,dc=ovd,dc=com
uniquemember=cn=a1,dc=test,dc=ovd,dc=com

ベースDNのすべてが、dc=ralf,dc=oracle,dc=com to dc=test,dc=ovd,dc=comから変換されていることに注意してください。

次の例は、Oracle Virtual Directoryアダプタ構成のベース・ルートDNがリモート・ベースと同じ場合に、DynamicGroupsプラグインをアクティブ化して動的グループを解決する方法を示しています。

1. リモート・サーバーで動的グループを構成します。

cn=dyngroup,dc=ralf,dc=oracle,dc=com
memberurl: ldap:///dc=ralf,dc=oracle,dc=com??sub?cn=a*
uniquemember: cn=b1,ralf,dc=oracle,dc=com

2. 動的メンバー・エントリを移入します。

cn=a1,dc=ralf,dc=oracle,dc=com

3. LDAPアダプタをルートDNがリモート・ベースと等しくなるように構成します。

Root DN : dc=ralf,dc=oracle,dc=comRemote base : dc=ralf,dc=oracle,dc=com

4. Dynamic Groupsプラグインを構成します。

5. プロキシ・ベースで検索操作を実行します。

> ldapsearch -p 5566 -D cn=admin -w welcome1
-b "dc=ralf,dc=oracle,dc=com" -s sub "cn=dyn*"

この例のテスト結果は、次のようになります。

cn=dyngroup,dc=ralf,dc=oracle,dc=com
memberURL=ldap:///dc=ralf,dc=oracle,dc=com??sub?cn=a*
objectClass=groupofuniquenames
objectClass=groupofurls
objectClass=top
cn=dyngroup
uniquemember=cn=b1,dc=ralf,dc=oracle,dc=com
uniquemember=cn=a1,dc=ralf,dc=oracle,dc=com

この最後の例では、動的グループを解決せずに、memberurlのベースDNのみを変換する方法を示しています。

1. リモート・サーバーで動的グループを構成します。

cn=dyngroup,dc=test,dc=ovd,dc=com
memberurl: ldap:///dc=ralf,dc=oracle,dc=com??sub?cn=a*
uniquemember: cn=b1,dc=test,dc=ovd,dc=com

2. 動的メンバー・エントリを移入します。

cn=a1,dc=test,dc=ovd,dc=com

3. LDAPアダプタをルートDNがリモート・ベースと等しくならないように構成します。

Base DN : dc=test,dc=ovd,dc=comRemote base : dc=ralf,dc=oracle,dc=com

4. プロキシ・ベースで検索操作を実行します。

> ldapsearch -p 5566 -D cn=admin -w welcome1 -b
"dc=test,dc=ovd,dc=com"
-s sub "cn=dyn*"

テスト結果は、次のようになります。

cn=dyngroup,dc=test,dc=ovd,dc=com
memberURL=ldap:///dc=test,dc=oracle,dc=com??sub?cn=a*
objectClass=groupofuniquenames
objectClass=groupofurls
objectClass=top
cn=dyngroup
uniquemember=cn=b1,dc=test,dc=ovd,dc=com

Oracle Virtual DirectoryがベースDNを変換し、静的メンバーのみを取得していることに注意してください。

4.2.12.1 グループ・メンバーシップのテスト

ポリシー・サーバーなどの製品では、特定のユーザーがグループのメンバーであるかどうかの確認が必要な場合がよくあります。これは、グループが大規模であったり動的グループである場合には大変な作業になります。ただし、Dynamic Groupsプラグインでは、cnおよびuniquememberフィルタ項目の両方の有無を確認することで、メンバーシップ・テストの問合せを検出できます。存在する場合、Dynamic Groupsプラグインは、クライアントでメンバーシップ・アサーションのテストが必要であることを確認し、別の方法で問合せを処理します。例4-5に示すように、プラグインにより結果が変更され、メンバーとしてテストされる単一のユーザーのみが戻されます。

例4-5 Dynamic Groupsプラグインを使用したメンバーシップ・テストの例

C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(&(cn=TestCheck)(uniquemember=cn=Jim Ward,ou=accounting,o=yourcompany.com))"

cn=TestCheck,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(userprincipalname=*))
objectclass=groupofuniquenames
objectclass=groupofurls
cn=TestCheck
uniquemember=cn=Jim Ward,ou=Accounting,o=YourCompany.com

4.2.12.2 構成パラメータ

次に、構成パラメータのリストと説明を示します。Dynamic Groupsプラグインを有効化するには、それをプラグイン・チェーンに追加します。

memberattribute

メンバー値を格納する属性の名前。値が指定されていない場合、uniqueMemberにデフォルト設定されます。

accessInternal

このパラメータをtrueに設定すると、このプラグインが、可視性が内部に設定されているアダプタにアクセスし、それらの内部アダプタで構成されているメンバーのmemberURLを解決できるようになります。デフォルトはfalseです。

usersearchbase

LDAP URLに指定されているベースを上書きする必要がある仮想検索ベース用のオプションの値。

fetchBothStaticAndDynamicGps

ユーザーが、静的および動的の両方のグループのメンバーである場合に使用されるパラメータ。デフォルトはfalseです。

- falseに設定した場合、特定の検索されたユーザーが属する静的グループのみが取得され、動的グループは取得されません。

- trueに設定した場合、検索されたユーザーが属する静的および動的の両方のグループが取得されます。

checkurlbase

メンバーシップ・テスト問合せを実行する際に、memberURLに指定されているベースおよび有効範囲を尊重するかどうかを示すブール値。デフォルトはfalseです。

globalsearch

動的グループを展開するための検索の発生場所の制御に使用されるパラメータ。

- trueに設定した場合、検索はグローバル・プラグイン・チェーン(グローバル・サービス・インタフェース)層から発生します。

- falseに設定した場合、検索はアダプタ・プラグイン・チェーン(アダプタ・サービス・インタフェース)層から発生します。

- vsiに設定した場合、検索はOracle Virtual Directoryの動的グループ・プラグイン(仮想サービス・インタフェース)の次に構成されたプラグインから発生します。

expandGroupURL

動的グループが展開される必要があるかどうかを示すブール。この値が明示的に構成されていない場合は、検索リクエストのリクエストされた属性に基づいて黙示的に計算されます。黙示的な計算については、検索問合せリクエストでリクエストされた属性がすべての属性用、またはmember/uniquemember属性用の場合、グループは展開されます。そうでない場合、グループは展開されません。しかし、この明示的に構成された値は、黙示的な動作に優先します。

4.2.13 Cacheプラグイン

Cacheプラグインは、Oracle Virtual Directoryに本来のキャッシュを提供します。これは、LDAP検索結果セットのメモリー内コピーであり、繰り返される問合せのパフォーマンスが向上するように設計されています。たとえば、3回連続でエンタープライズLDAPサーバー(Oracle Virtual Directory)のすべてのグループを問い合せる日次同期プロセスの一部としてサード・パーティのポータル・サーバーがあるとします。Cacheプラグインは、LDAPクライアントが再利用できるように、最初の検索結果のコピーを保持できます。クライアント・アプリケーションにとっては結果がわずかに早くなるだけですが、より重要なことは、エンタープライズ・ソース・システムの負荷が削減されることです。

Oracle Virtual DirectoryはCacheプラグインなしで機能するように設計されており、多くの場合、Cacheプラグインは必要ありません。これは、多くのアプリケーションで結果がそれ自体にキャッシュされるか、ほとんどのエンタープライズ・ソース・システムですでにデータがキャッシュされているためです。また、Oracle Virtual Directoryはセキュリティで保護された環境で使用されることが多く、キャッシュを保持すると、従業員が操作を終了してもそのユーザー結果がキャッシュに残されたままになるなど、セキュリティ要素の公開につながります。

注意:
Cacheプラグインを使用する場合は、キャッシュ・タイムアウトを小さくして、このような場合にキャッシュの更新の問題を避ける必要があります。

Cacheプラグインを使用すると、問合せが何度も繰り返されるアプリケーションのパフォーマンスを大幅に向上できます。また、Oracle Virtual Directory内のどこでも実行できるように構成できます。Cacheプラグインはグローバルに実行することも、単一アダプタのコンテキスト内で実行することも可能であり、ネームスペース・フィルタ処理を使用して特定のネームスペースに制限することもできます。

問合せが同じユーザーによって繰り返され、同一の属性または属性のサブセットがリクエストされる場合、Oracle Virtual Directoryがソースから情報を取得するのではなく、キャッシュから問合せの結果が戻されます。たとえば、問合せ2でクライアントが検索属性を変更する、次のような2つの仮想の問合せがあるとします。

問合せ1

- バインド: "cn=Example User,cn=users,dc=mycompany,dc=com"

- ベース: "dc=mycompany,dc=com"

- 問合せ: "uid=jdoe"

- 属性: "cn,mail"

問合せ2

- バインド: "cn=Example User,cn=users,dc=mycompany,dc=com"

- ベース: "dc=mycompany,dc=com"

- 問合せ: "uid=jdoe"

- 属性: "telephonenumber,manager"

Cacheプラグインを使用すると、Oracle Virtual Directoryは問合せ1および問合せ2を2つの別々の問合せとして扱わないため、バックエンド・ソースは2回検索されません。Oracle Virtual Directoryは、問合せ1で一致するエントリのすべての属性をリクエストしますが、クライアントがリクエストした属性のみを戻し、キャッシュに検索結果のメモリー内コピーを保持します。

注意:
Oracle Virtual Directoryは、バックエンドのソース・リポジトリであるアクセス制御リスト(ACL)、Oracle Virtual Directory ACLおよびアダプタ・ルーティング・ルールに基づいて、バインドされたユーザーがアクセス権を持っている属性のみを取得します。

キャッシュ・ヒットをユーザー間で共有できるようにCacheプラグインを構成することもできます。passcredentialsがバックエンド・ソースに渡されず、Oracle Virtual Directoryのみによってセキュリティが実施されている場合以外は、ユーザー間でキャッシュ・エントリを共有しないでください。

注意:
より強力な権限を持つユーザーのキャッシュ結果にアクセスする可能性があり、許可されていない情報を表示することも可能であるため、ユーザー間でキャッシュ・ヒットを共有する際には慎重に計画を立ててください。

Cacheプラグインは、キャッシュを定期的に確認し、期限切れの結果や以前の変更トランザクションで無効にされたエントリがないかどうかチェックします。キャッシュの割当てを超えた場合、Cacheプラグインは使用されていない期間が最も長い問合せをパージしてメモリーのサイズを小さくしようと試みます。

4.2.13.1 構成パラメータ

次に、Cacheプラグイン構成パラメータのリストと説明を示します。

storeallattrs

Cacheプラグインですべての属性をサイレントにリクエストするかどうかを制御します。サポートされている値は0(無効化)または1(有効化)です。デフォルトで、storeallattrsパラメータは無効化(0)されています。

bysubject

サブジェクト間でキャッシュ結果を共有するかどうかを示します。サポートされている値は0または1です。0の値はサブジェクト間で結果が共有されることを意味し、1の値はサブジェクト間で結果が共有されないことを意味します。デフォルト値は1です。

maintenanceinterval

キャッシュ・マネージャが期限切れの問合せがないかチェックする間隔(秒)。デフォルト値は60です。

size

一度にキャッシュ可能なエントリの最大数。デフォルト値は10000です。

maximumage

キャッシュに保存される問合せ/エントリの秒単位の最大有効期間(時間)。デフォルト値は600です。

maxresultsize

特定の問合せに対してキャッシュ可能なエントリの最大数。デフォルト設定は1000です。

trimsize

このパラメータは、最大キャッシュ・サイズを超えた場合に、キャッシュ・マネージャが調整する必要のある量を示します。デフォルト値は10000です。

注意:
必要な場合には、最初に有効期限の切れた問合せ、続いて使用頻度が最低の問合せをパージすることで調整が行われます。

zeroresults

含まれているエントリがゼロ個の問合せ結果をキャッシュするかどうかを示します。サポートされている値は0および1です。

4.2.14 ObjectClass Mapperプラグイン

ObjectClass Mapperプラグインは、あるobjectClass(userなど)を別のobjectClass(inetOrgPersonなど)として認識させる一般的なマッピング・プラグインです。この機能は、ディレクトリで特定のobjectClassまたは属性はサポートされていないが、アプリケーションでそのobjectClassおよび属性が予期されている際に便利です。

ObjectClass Mapperプラグインでは、選択する構成パラメータに基づいて、次に示すような複数の異なるタイプの操作を実行できます。

- 属性マッピング

- オブジェクト・クラス・マッピング

- オブジェクト・クラスへの属性条件の追加

- 属性の削除

- 補助クラスのフィルタ処理

- アクティブ化および非アクティブ化の処理

属性のマッピング関係が生じた場合、接頭辞client-はクライアント側を、source-はデータ・ソース側を表します。たとえば、Active DirectoryサーバーのuserをマッピングしてそれをInetOrgPersonとして表すようにした場合、Active Directoryはソース側でInetOrgPersonはクライアント側になります。

4.2.14.1 構成パラメータ

次に、ObjectClass Mapperプラグイン構成パラメータのリストと説明を示します。

directoryType

ユーザーのアクティブ化を実行する際に使用するディレクトリのタイプ。サポートされている値はSunOne、eDirectory、ADAMおよびActiveDirectoryです。次に例を示します。

パラメータ名: directoryType

パラメータ値: ActiveDirectory

activationAttribute

activationAttributeパラメータは、アプリケーションに、基礎となるディレクトリのユーザー・アクティベーション・システムに関する情報がない場合に使用します。activationAttributeパラメータにより、ユーザー・アクティベーション・フラグが含まれている着信属性が、Oracle Virtual Directoryに通知されます。その後、このフラグは、ディレクトリ固有の属性およびフラグにマップされます。次に例を示します。

パラメータ名: activationAttribute

パラメータ値: myuseraccountcontrol

deactivationValue

ユーザーを非アクティブとしてマークする必要があることを示すactivationAttributeに指定された属性値のカンマ区切りリスト。

activationValue

ユーザーをアクティブとしてマークする必要があることを示すactivationAttributeに指定された属性値のカンマ区切りリスト。

mapObjectClass

client-ObjectClass=source-ObejctClassという書式でマップされるobjectClass。次に例を示します。

パラメータ名: mapObjectClass

パラメータ値: inetOrgPerson=user

mapObjectClassパラメータは、複数のマッピングに複数回使用できます。

addAttribute[-objectclassvalue]

追加プロセス中にユーザーに属性を追加します。オプションのオブジェクト・クラス値は、特定のオブジェクト・クラスのみに属性を追加するために、構成名に追加できます。たとえば、ユーザー・オブジェクト・クラスのみにuserAccountControl属性を追加するには、次のものを使用します。

パラメータ名: addAttribute-user

パラメータ値: userAccountControl=546

注意:
属性名をパーセンテージ文字(%)で囲んで入力することにより、式の値側で属性値を参照できます。次に例を示します。
パラメータ名: addAttribute-group

パラメータ値: samaccountname=%cn%

filterAttribute[-objectclassvalue]

追加操作または変更操作中に削除される(および返されたすべてのエントリから削除される)属性のカンマ区切りのリスト。次に例を示します。

パラメータ名: filterAttribute

パラメータ値: objectsid,memberof,samaccountname

- filterAttribute定義にobjectclass(filterAttribute-ユーザー:memberof)を追加する場合、追加および変更操作中に、属性のカンマ区切りリストが、関連するobjectclassを持つエントリから削除されます。

- filterAttribute定義にobjectclass(filterAttribute-ユーザー:memberof)を追加しない場合は、属性のカンマ区切りのリストは、追加および変更操作中に削除されます(および返されたすべてのエントリから削除される)。

mapAttribute

client-Attribute=source-attributeという書式でマップされる属性。次に例を示します。

パラメータ名: mapAttribute

パラメータ値: uniqueMember=member

mapAttributeパラメータは、複数のマッピングに複数回使用できます。

filterAuxiliaryClass

追加操作中に削除する必要のあるオブジェクト・クラスのカンマ区切りのリスト。たとえば、Microsoft Active Directory for Windows 2000では、エントリの追加中に補助オブジェクト・クラスをリストすることはできませんが、Microsoft Active DirectoryおよびADAM for Windows Server 2003では補助クラスをリストできます。次に例を示します。

パラメータ名: filterAuxiliaryClass

パラメータ値: person,myorgPerson

filterObjectClassOnModify

filterObjectClassOnModifyパラメータを使用して、変更操作中にobjectClassエントリの変更を削除します。サポートされる値はtrue (変更を削除)またはfalse (変更を削除しない)です。trueがデフォルトです。次に例を示します。

パラメータ名: filterObjectClassOnModify

パラメータ値: true、false

4.2.15 Sub-Treeプラグイン

Sub-Treeプラグインは、元々、IBMのTivoli Access Manager製品の旧バージョンをサポートするために開発されました。この製品には、ユーザー・エントリの下にユーザー・エントリに関するポリシー情報を格納するという要件があったため、通常のリーフ・モデルからのユーザー・エントリはブランチに変更されていました。一部のディレクトリではそのようなモデルをサポートしていないか、企業ディレクトリにそのような方法で移入する必要がありませんでした。

Sub-Treeプラグインを使用すると、アプリケーション(この場合はTivoli Access Manager)に対象のディレクトリ・ツリー・ビューを提供しながら、これらのサブツリー・エントリを異なるアダプタに格納できます。通常のリーフ・エントリの下にエントリを追加するという要件は、一般的ではありません。より一般的なケースは、データ・ストアを既存のデータ・ストアの下にブランチとして表示させることです。これは、ルートのネームスペース値を正しく設定することで、どのアダプタでも実行できます。

4.2.15.1 構成パラメータ

次に、Sub-Treeプラグイン構成パラメータのリストと説明を示します。

storeadapter

ユーザー・サブツリー・オブジェクトを格納するためのアダプタ。

storeroot

ユーザー・サブツリー・オブジェクトを格納するストア・アダプタの場所。

subtreematch

Sub-Treeプラグインが捕捉してストア・アダプタにリダイレクトする必要のあるサブツリー識別名(DN)コンポーネントを指定します。デフォルト値はsecAuthority=Defaultです。

matchdn

ユーザー・オブジェクトが検出される識別名(DN)、およびユーザー・オブジェクトRDNを指定する番号付きのパラメータ。たとえば、0=ou=People,o=Airius.com\:uidのようになります。

4.2.16 Performance Monitorプラグイン

Performance Monitorプラグインを使用すると、特定のアダプタのパフォーマンスを監視できます。Performance Monitorプラグインを使用するには、それをアダプタに追加して、そのアダプタに対して操作を実行します。アダプタのパフォーマンスを表示するには、アダプタのルートのネームスペースで、vdeSearchtime=*というフィルタを使用して特定タイプのベース・レベルのLDAP検索を実行する必要があります。

検索により、例4-6のような結果が戻されます。この例では、時間はすべてミリ秒単位で計測されています。

例4-6 Performance Monitorプラグインを使用して戻されるデータの例

dn: dc=demo,dc=com
vdeNumSearches: 4
vdeNumEntries: 5
vdeMinSearchTime: 0
vdeMaxSearchTime: 16
vdeTotalSearchTime: 16
vdeAverageSearchTime: 4
vdeMinEntryTime: 0
vdeMaxEntryTime: 0
vdeTotalEntryTime: 0
vdeAverageEntryTime: 0
vdeMinSearchCompleteTime: 0
vdeMaxSearchCompleteTime: 203
vdeTotalSearchCompletionTime: 219
vdeAverageSearchCompletionTime: 54

注意:
Performance Monitorデータは、Oracle Virtual Directoryサーバーが再起動するとリセットされます。

4.2.16.1 構成パラメータ

Performance Monitorプラグインには構成パラメータはありません。Performance Monitorプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.2.17 UniqueEntryプラグイン

一部のOracle Virtual Directory環境のユーザーは、Oracle Virtual Directoryアダプタを使用して接続する複数のサービスに対して重複したアカウントを持っています。通常、結合ビュー・アダプタを作成して複数のアダプタを統一し、単一の仮想ユーザー・エントリを作成すると、この問題は解決します。ただし、結合ビュー・アダプタの作成が選択肢にならない場合があります。たとえば、社員用のディレクトリと顧客用のディレクトリがあるが、仕事上の正当な目的で両方のディレクトリにアカウントを持っている社員がいて、結合ビュー・アダプタを作成できない場合があります。

UniqueEntryプラグインは、それぞれの管理ソースで様々なアダプタをランク付けすることでこの問題を解決します。たとえば、重複しているユーザーIDのどれが社員のアカウントであるかの判断を試行している場合、社員ディレクトリの方が顧客ディレクトリよりも問題に関連があるため、顧客ディレクトリ・アダプタよりも社員ディレクトリ・アダプタの優先度を高くします。

アダプタの優先度をランク付けする場合、ランク付けの数値が低いほど優先度が高くなります。たとえば、2つのアダプタを検索していて、1つのアダプタの優先度のランクが5で、もう1つのアダプタのランクが10の場合、ランクが10のアダプタよりもランクが5のアダプタが先に検索されます。

注意:
UniqueEntryプラグインには制限があります。Paged Result Controlを使用している場合、このプラグインでは重複エントリをフィルタできなたいめ、異なるページの一部として重複データが送信されます。

注意:
UniqueEntryプラグインはアダプタ・レベルでは適用せず、必ずグローバル・プラグインとしてのみ適用してください。

4.2.17.1 構成パラメータ

UniqueEntryプラグインには、次の構成パラメータがあります。

uniqueattribute

一意キーとして使用する属性。

4.2.18 アダプタ・プラグイン・バージョン・プラグイン

アダプタ・プラグイン・バージョン・プラグインはデプロイしないでください。これは、情報提供を目的とするもので、サーバー機能はありません。これは、Oracle Directory Services Managerホーム・ページに表示されるアダプタ・バージョン情報を提供します。

4.2.19 Proxy Authorization Supportプラグイン

多くのデプロイメントにおいて、顧客は、ユーザー資格証明をMicrosoft Active Directoryなどのエンタープライズ・パスワード資格証明ディレクトリに格納しますが、Oracle Directory Server Enterprise Edition、Oracle Internet Directoryなどの他のデータソースからのコンテンツの集計も行っています。これらのデプロイメントでは、顧客は、認証されたユーザーにマップされる一貫性のあるセキュリティおよび監査証跡を適用する機能(ID反映と呼ぶ)を必要としています。Proxy Authorization Supportプラグインは、エンタープライズ・ディレクトリのプロキシ認証機能を活用します。それにより、ユーザーが実際にActive Directoryで認証された場合でも、そのユーザー・アイデンティティを1つ以上の他のソースに伝播でき、それらの追加のソースにおけるセキュリティおよび監査が、Oracle Virtual Directoryに格納されたアプリケーション・アカウントではなく、Oracle Virtual Directoryで認証された実際のユーザーにマップされます。

Proxy Authorization Supportプラグインは、クライアントDNを作成し、このクライアントDNとともにプロキシ認証制御をそのリクエストに追加し、そのリクエストをバックエンドLDAPサーバーに渡します。LDAPサーバーは、Oracle Virtual DirectoryのプロキシDNを使用してリクエストを認証し、プロキシ認証制御で指定されているクライアント・ユーザー・アイデンティティを使用して操作を処理します。クライアント・アプリケーションに対する変更は必要ありません。

Proxy Authorization Supportプラグインを構成する場合は、ディレクトリが、渡す予定のプロキシ制御をサポートするように構成する必要があります。

4.2.19.1 構成パラメータ

次に、Proxy Authorization Supportプラグイン構成パラメータのリストと説明を示します。

remoteBase

プロキシ認証制御で渡されるユーザー認証DNを作成するために親DNとして使用されるオプションのパラメータ。デフォルトでは、アダプタのremoteBaseと同じ値になります。

directoryType

ディレクトリ・タイプを示すために使用されるオプションのパラメータ。使用可能な値はOIDおよびSunOneです。デフォルト値はSunOneで、このリリースではこの値のみがサポートされています。

4.2.20 UserManagementプラグイン

UserManagementプラグインは、Oracle Identity Managerの属性からLDAPディレクトリ・サーバーへのデータ・マッピングを提供します。

4.2.20.1 構成パラメータ

UserManagementプラグインには、次の構成パラメータがあります。

filterObjectclass

追加または変更リクエスト時に削除する必要のあるオブジェクト・クラスのカンマ区切りのリスト。

removeAttribute

クライアントに戻される前にエントリから実際に削除される属性のカンマ区切りリスト。

exclusionMapping

特定のオブジェクト・クラスに対する特定の属性マッピングの除外を定義します。たとえば、値inetorgperson,uid=samaccountnameを持つパラメータを指定すると、オブジェクト・クラスinetorgpersonのエントリ上のuidからsamaccountnameへのマッピングが除外されます。このオプションの複数のインスタンスを使用すると、マッピングに対して複数の除外が可能になります。

oimLanguages

属性言語サブタイプで使用される言語コードのカンマ区切りリスト。このパラメータは、directoryTypeパラメータがActiveDirectoryに設定されている場合にのみ機能します。

oamEnabled

TrueまたはFalse: Oracle Access ManagerがOracle Identity Managerとともにデプロイされているかどうかを示します。デフォルトでは、Oracle Access Managerはデプロイされておらず、したがってこのパラメータのデフォルト設定はfalseです。

注意:
UserManagementプラグインとchangelogプラグインのoamEnabledパラメータの値は同一であることが必要です。

directoryType

ソースLDAPディレクトリ・サーバーのタイプを指定します。サポートされている値はOID、ActiveDirectoryおよびSunOneです。デフォルト値はOIDです。

注意:
UserManagementプラグインとchangelogプラグインのdirectoryTypeパラメータの値は同一であることが必要です。

ssladapter

ssladapterパラメータは、directoryTypeパラメータがActiveDirectoryに設定されている場合にのみ機能し、リクエストにuserPasswordまたはunicodePwdが含まれている場合にUserManagementプラグインによってリクエストがルーティングされる先のアダプタの名前を指定します。unicodePwdがリクエストに含まれている場合、そのリクエストには、適切な値を持つuseraccountControl属性も含まれている必要があります。

ssladapterパラメータによって指定されるアダプタは、次のようになっている必要があります。

- UserManagementプラグインが構成されているアダプタと同じローカル・ベースを持つ

- ルーティングの可視性がInternalに設定されている

ssladapterに値が設定されていない場合は、現在のアダプタにデフォルト設定されます。

mapAttribute

OVD-attribute=OIM-attributeの形式の属性変換を定義します。たとえば、orclGUID=objectGuidなどです。mapAttribute構成パラメータを複数回設定して、複数の属性の変換を定義できます。

mapPassword

TrueまたはFalse。directoryType構成パラメータをActiveDirectoryに設定すると、mapPasswordパラメータが、ユーザー・パスワードをunicodePwd属性に変換するかどうかを制御します。デフォルト値はfalseです。

mapRDNAttribute

OVD-RDNattribute=OIM-RDNattributeの形式のRDN属性変換を定義します。たとえば、uid=cnなどです。

pwdMaxFailure

(このプラグインがデプロイされているアダプタを介して公開されるユーザー・エントリに適用されたパスワード・ポリシーの定義に従い)ソースLDAPディレクトリ・サーバーによってアカウントがロックされるために必要な失敗ログインの最大回数を指定します。

mapObjectclass

OVD-objectclass=OIM-objectclassの形式のオブジェクト・クラスの値変換を定義します。たとえば、inetorgperson=userなどです。mapObjectclass構成パラメータを複数回設定して、複数のオブジェクト・クラスの変換を定義できます。

注意:
UserManagementプラグインとchangelogプラグインのmapObjectclassパラメータの値は同一であることが必要です。

addAttribute

このパラメータは、attribute=value pairsの形式でget操作結果を戻す前に追加する属性を指定します。属性名の前にobjectclass,を追加すると、属性と値を特定のオブジェクト・クラスに追加できます。また、値を%で囲んで他の属性を参照することもできます。たとえば、値user,samaccountname=%cn%を指定すると、エントリがobjectclass=userである場合にcnの値がsamaccountnameに代入されます。値samaccountname=jdoeを指定すると、値jdoeを持つ属性samaccountnameがすべてのエントリに追加されます。

4.2.21 Changelogプラグイン

注意:
リリース11.1.1.4.0より前のOracle Virtual Directoryには、次の3つのchangelogプラグインがありました。

- Oracle Internet Directoryとともに使用するためのoidchangelog

- Oracle Directory Server Enterprise Editionとともに使用するためのsunonechangelog

- Microsoft Active Directoryとともに使用するためのadchangelog

これらの3つのプラグインはリリース11.1.1.4.0では非推奨となり、新しい単一のChangelogプラグインが使用可能になっています。このプラグインは、Oracle Internet Directory、Oracle Directory Server Enterprise Edition、およびMicrosoft Active Directoryで使用できます。

4.2.21.1 リリース11.1.1.4.0 Changelogプラグインのデプロイ

この単一のChangelogプラグインをデプロイする際は、次のことが必要です。

- アダプタの「リモート・ベース」を空の値に、つまり空白にします。

- アダプタの「マップされたネームスペース」をcn=changelogに設定します。

- バックエンドがOracle Directory Server Enterprise Editionである場合、Oracle Directory Server Enterprise Edition上のロギングの変更を必ず有効化してください。

4.2.21.2 前のリリースからのChangelogプラグインのデプロイ

11.1.1.4.0より前にリリースされたバージョンのOracle Virtual Directoryを使用している場合、次のchangelogプラグインを使用して、changelog情報をソース・ディレクトリからOracle Identity Managerに適した形式に標準化してください。

注意:
これらのプラグインはOracle Virtual Directoryリリース11.1.1.4.0では機能しません。

Oracle Internet Directoryの場合

Oracle Internet Directoryではoidchangelogプラグインを使用します。

oidchangelogプラグインをデプロイする場合は、アダプタの「リモート・ベース」を空の値に、つまり空白にします。

Oracle Directory Server Enterprise Editionの場合

Oracle Directory Server Enterprise Editionでは、sunonechangelogプラグインを使用します。

sunonechangelogプラグインをデプロイする際は、次のことが必要です。

- アダプタの「リモート・ベース」を空の値に、つまり空白にします。

- Oracle Directory Server Enterprise Editionで変更ログが有効化されていることを確認します。

- アダプタの「マップされたネームスペース」をcn=changelogに設定します。

Microsoft Active Directoryの場合

Microsoft Active Directoryではadchangelogプラグインを使用します。

adchangelogプラグインをデプロイする際は、次のことが必要です。

- アダプタの「リモート・ベース」を空の値に、つまり空白にします。

- アダプタの「マップされたネームスペース」をcn=changelogに設定します。

4.2.21.3 構成パラメータ

各changelogプラグインには、次の構成パラメータがあります。

removeAttribute

クライアントに戻される前にエントリから実際に削除される属性のカンマ区切りリスト。

oimLanguages

属性言語サブタイプで使用される言語のカンマ区切りリスト。

skipErrorChangelog

TrueまたはFalse。falseに設定されていて、破損したchangelogエントリがプラグインによって検出された場合、プラグインはDirectoryExceptionをスローし、changelogエントリのそれ以降の処理を停止します。trueに設定されている場合、プラグインは例外をスローせずにエラーを記録し、このchangelogをスキップして、次のchangelogの処理を続行します。デフォルト値はfalseです。

oamEnabled

TrueまたはFalse: Oracle Access ManagerがOracle Identity Managerとともにデプロイされているかどうかを示します。デフォルトでは、Oracle Access Managerはデプロイされておらず、したがってこのパラメータのデフォルト設定はfalseです。

注意:
UserManagementプラグインとchangelogプラグインのoamEnabledパラメータの値は同一であることが必要です。

directoryType

ソースLDAPディレクトリ・サーバーのタイプを指定します。サポートされている値はOID、ActiveDirectoryおよびSunOneです。デフォルト値はOIDです。

注意:
UserManagementプラグインとchangelogプラグインのdirectoryTypeパラメータの値は同一であることが必要です。

mapObjectclass

OIM-objectclass=Source-Directory-objectclassの形式のオブジェクト・クラスの値変換を定義します。たとえば、inetorgperson=userなどです。mapObjectclass構成パラメータを複数回設定して、複数のオブジェクト・クラスの変換を定義できます。

Oracle Identity Managerのユース・ケースでは、次のパラメータがすぐに使用できるように構成されています。

- Active Directoryの場合: inetorgperson=user, orclidxperson=user, and groupOfUniqueNames=group

- Oracle Directory Server Enterprise Editionの場合: container=nsContainer and changelog=changelogentry

- Oracle Internet Directoryの場合: container=orclContainer

注意:
UserManagementプラグインとchangelogプラグインのmapObjectclassパラメータの値は同一であることが必要です。

sizeLimit

戻されるchangelogエントリの最大数を指定します。

ゼロ(0)または負の値は、サイズ制限がないことを意味します。

受信する検索リクエストでサイズの制約が指定されている場合、小さいほうの値が使用されます。たとえば、プラグインのsizeLimitを100に指定してあり、検索リクエストのカウント制限が200である場合は、リクエストの実際のサイズ制限は100にリセットされます。

mapAttribute

Source-Directory-attribute=OIM-attributeの形式の属性変換を定義します。たとえば、orclGUID=objectGuidなどです。mapAttribute構成パラメータを複数回設定して、複数の属性の変換を定義できます。

targetDNFilter

変更の取得元となるコンテナを指定します。このパラメータは複数回設定して、変更の取得元となるコンテナを複数指定できます。複数回設定した場合、targetDNフィルタは次の例のようになります。このtargetDNフィルタは受信フィルタにandで結合されます。

"(|(targetDN=*cn=users,dc=mycom1)(targetDN=*,cn=groups,dc=mycom2))"

次に値の例を示します。

- *,cn=xxx,dc=yyy

- *cn=xxx,dc=yyy

- cn=xxx,dc=yyy (virtualDITAdapterNameで指定されているアダプタのローカル・ベースの子であることが必要です。)

これらの例はすべて同じ意味を持ちます。

requiredAttribute

Oracle Virtual Directoryへのchangelog問合せに対して指定されている戻り属性リストに関係なく、ソースLDAPディレクトリ・サーバーから常に取得される属性のカンマ区切りリスト。

addAttribute

正規化されているchangelogエントリに追加される属性のカンマ区切りリスト。たとえば、orclContainerOC=1, changelogSupported=1などです。ここで、=1はchangelogをサポートしているソース・ディレクトリから取得される変更を示します。

mapUserState

TrueまたはFalse。このパラメータは、ディレクトリ固有のアカウント属性からOracle Virtual Directoryの仮想アカウント属性へのマッピングを有効化または無効化します。

modifierDNFilter

modifiersNameに対するLDAPフィルタを定義する単一の値を持つ構成パラメータ。このパラメータは、受信フィルタにandで結合されます。値の例としては、(modifiersName=cn=myadmin,cn=users,dc=mycom)があります。

注意:
この構成は、directoryType=ActiveDirectoryの場合は無効です。

virtualDITAdapterName

対応するユーザー・プロファイル・アダプタ名を指定します。

たとえば、単一ディレクトリ・デプロイメントでは、このパラメータの値をA1に設定できます。これはユーザー・アダプタ名です。分割ユーザー・プロファイルのシナリオでは、このパラメータをJ1;A2に設定できます。ここでJ1はJoinViewアダプタ名であり、A2はJ1における対応するユーザー・アダプタです。

このパラメータは複数値を取ることができます。これは、changelogアダプタと同じバックエンド・ディレクトリ・サーバーに対して構成されている複数のベース・エントリ・アダプタがあることを意味します。

このパラメータをA1に設定する場合、このプラグインはアダプタA1のUserManagementPluginのmapAttributeおよびmapObjectclass構成をフェッチするため、ユーザーがそれらの構成を複製する必要はありません。

4.2.22 Consolidated Changelogプラグイン

Consolidated Changelogプラグインは、Oracle Virtual Directoryが複数のディレクトリからのアイデンティティの統合ビューを提供する際に、統合変更番号を提供します。このプラグインは、様々なchangelogからのデータの統合された正規化ビューも提供します。このプラグインは、グローバル・プラグインとしてのみデプロイできます。

Consolidated Changelogプラグインは、統合changelogに対して統合Cookieを提供するという概念に基づいています。このCookieは、Oracle Virtual Directoryでアダプタが構成されているディレクトリの統合ビューの提供に関係するアダプタに基づいて作成されます。

統合変更番号は、次の形式のCookieです。

<changelogAdapterName1>:<changenumber1>;<changelogAdapterName2><changenumber2>;
<targetDN:dn>

説明:

- <changelogAdapterName1>は、changelogの取得元のソース・アダプタです。

- <changenumber1>は、changelogAdapter1のこのエントリのchangeNumberです。

- <changelogAdapterName2>は、このOracle Virtual Directoryで構成されている2つ目のchangelogアダプタです。

- <changenumber2>は、changelogAdapter2から最後に読み取られたchangeNumberです。

- <targetDN:dn>は、バックエンド・ディレクトリなどの場合のこのchangelogエントリのtargetDNです。この値は、オプションであり、診断目的でのみ使用されます。

たとえば、changelogを統合する2つのディレクトリがあり、changelogアダプタはCA1およびCA2であると想定します。また、CA1が指しているディレクトリ・サーバーの変更番号が101から始まり、CA2が指しているディレクトリ・サーバーの変更番号が501から始まると想定します。この場合、CA1の変更101に対するCookieの値は次のようになります。

CA1:101;CA2:501;<targetDN:targetDN_of_CA1_101>

同様に、CA2に対するCookieの値は次のようになります。

CA2:501;CA1:101;<targetDN:targetDN_of_CA2_501>

このCookieの値の長さは2048バイトです。

通常のディレクトリの場合と同様に、Consolidated Changelogプラグインでは、次のようにlastChangeNumber問合せがサポートされています。

ldapsearch -h <ovdHost> -p <ovdPort> -D <ovdAdmin> -w <ovdAdminPwd>
-b "cn=changelog" -s base "objectclass=*" lastChangeNumber

例4-7は、戻されるエントリの例を示しています。

例4-7 lastChangeNumber問合せによって戻されるエントリの例

cn=Changelog
lastChangeNumber=Changelog_ActiveDirectory:165095;Changelog_OID:408;
Changelog_SunOne:298328

注意:
このプラグインは、Oracle Identity Manager 11gでのみ使用するように設計されています。

このプラグインがデプロイされている場合、サポートされる問合せフィルタは、1つのフィルタ(changenumber>=cookie)を1つ以上の次に示すフィルタと結合する形式にする必要があります。

- (targetdn=*domain) ここでdomainは有効なドメインdnです。
たとえば、(targetdn=*cn=.yyy, dc=zzz)です。

- (modifiersname=xxx) ここでxxxはdnです。

- !(modifiersname=yyy) ここでyyyはdnです。

- (changetype=xxx) ここでxxxはADD/MODIFY/DELETE/ADDRMODIFYとすることができます。

- !(changetype=yyy) ここでyyyはADD/MODIFY/DELETE/ADDRMODIFYとすることができます。

4.2.22.1 構成パラメータ

Consolidated Changelogプラグインには構成パラメータはありません。Consolidated Changelogプラグインを有効にするには、それをグローバル・プラグインとしてインストールおよびデプロイする必要があります。

4.2.23 GenericMapperプラグイン

GenericMapperプラグインは、次に示すOracle Virtual Directoryプラグインと同等の機能を備えていますが、さらに柔軟性を提供します。

- VirtualAttributeプラグイン

- ObjectClass Mapperプラグイン

- DynamicTreeプラグイン

このプラグインは、『Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド』に記載されているディレクトリ統合プラットフォームのマッピング・ルール・ファイル形式に基づいています。

GenericMapperプラグインは、エントリのオブジェクト・クラスに基づいてマッピングを処理します。ユーザーのすべての属性はバック・エンド・ディレクトリに、そしてバック・エンド・ディレクトリからユーザーのすべての属性にそのままの状態でコピーされます。このプラグインは、ディレクトリ統合プラットフォームのドキュメントに記載されているキーワードに加えて、次のキーワードを使用します。

ATTRIBUTEEXCLUSIONLIST

エンド・ユーザーに戻される結果から除外される属性のリスト。これは、UserBound操作(検索/読取り)に適用されます。

VIRTUALATTRIBUTELIST

操作がバックエンドで実行される場合に含めない属性のリスト。これは、UserBound操作(検索/読取り)に適用されます。

FILTERRULES

マッピング・ルールが適用されるフィルタ処理されたエントリ。

4.2.23.1 構成パラメータ

次の表は、VirtualAttribute、ObjectClass Mapper、およびDynamicTreeプラグインの機能を実現するためにGenericMapperプラグインを構成する際に使用する構成パラメータを示しています。

VirtualAttributeプラグインの機能を実現する場合:

次の表に示すパラメータを使用します。

パラメータ名

説明

Container DN

ドメイン・ルール。ドメイン・ルールとしてコンテナDNに指定されているすべてのコンテナを指定します。

MatchFilter

フィルタ・ルール。filterRulesの後にmatchfilter値を指定します。

AddAttribute

次のように属性マッピング・ルールを指定します。

<attribute to be added >:[required]: [attribute type – string/binary]:
<objectclass to which the attribute belongs to>:
<backend attr name>:[attribute type]:<objectclass> :
<rule defining the value to be added>

たとえば、my commonnameのcnを戻すには次のルールを使用します。

Mycommonname: : : myObjectClass: cn: :inetorgperson: cn

departmentのSALESを戻すには次のルールを指定します。

Department: : :organizationalperson:cn: :person: "SALES"

ReplaceAttribute

次のように属性マッピング・ルールを指定します。

<clientview of attribute >:[required]: [attribute type –
string/binary]:<objectclass to which the attribute belongs to>:
<backend attr name>:[attribute type]:<objectclass> :

たとえば、displaynameのcnを戻すには次のルールを使用します。

displayname: : : inetorgperson: cn: :inetorgperson:

GenericMapperプラグインによって、ルールが解釈されるときにdisplayname値がcnに置換されます。

RemoveAttributes

AttributeExclusionList (除外するすべての属性のリストを指定します)。

ObjectClass Mapperプラグインの機能を実現する場合:

次の表に示すパラメータを使用します。

パラメータ名

説明

Container DN

ドメイン・ルール。ドメイン・ルールとしてコンテナDNに指定されているすべてのコンテナを指定します。

MatchFilter

フィルタ・ルール。filterRulesの後にmatchfilter値を指定します。

AddAttribute

次のように属性マッピング・ルールを指定します。

<attribute to be added >:[required]: [attribute type – string/binary]:
<objectclass to which the attribute belongs to>:
<backend attr name>:[attribute type]:<objectclass> :
<rule defining the value to be added>

たとえば、my commonnameのcnを戻すには次のルールを使用します。

Mycommonname: : : myObjectClass: cn: :inetorgperson: cn

departmentのSALESを戻すには次のルールを指定します。

Department: : :organizationalperson:cn: :person: "SALES"

ReplaceAttribute

次のように属性マッピング・ルールを指定します。

<clientview of attribute >:[required]: [attribute type – string/binary]:
<objectclass to which the attribute belongs to>:
<backend attr name>:[attribute type]:<objectclass> :

たとえば、displaynameのcnを戻すには次のルールを使用します。

displayname: : : inetorgperson: cn: :inetorgperson:

GenericMapperプラグインによって、このルールが解釈されるときにdisplayname値がcnに置換されます。

RemoveAttributes

AttributeExclusionList (除外するすべての属性のリストを指定します)。

ObjectClassMapping/Filtering auxiliary classes

オブジェクト・クラス・マッピングは、そのオブジェクト・クラスがSrc属性定義およびdestination属性定義で指定されているとおりに処理されます。どの属性がマップされているのかに応じてオブジェクト・クラスの値も追加されます。

アクティブ化および非アクティブ化の処理

この情報は、サンプル・マップ・ファイルで提供されています。

DynamicTreeプラグインの機能を実現する場合:

DynamicTreeプラグインと同じ結果を実現するためにGenericMapperプラグインを構成するには、次のように構成する必要があります。

<domain name as seen by client> : <domain name as seen in the backend> : cn=%, l=%,ou=%, <domain name as seen by the client>

すべてのエントリが、それらの属性に基づいて異なるDITの一部であるとみなされます。

注意:
GenericMapperプラグインには1つの制限があります。ベースとして構築ルールの属性を指定した検索では、GenericMapperプラグインはサブツリー・エントリのみを戻し、ベース・エントリは戻しません。

4.2.24 CoordinatorAdapterプラグイン

CoordinatorAdapterプラグインでは、バインドおよび検索ルーティング・ポリシーをカスタマイズできます。たとえば、LDAPバインド・リクエストがリクエストのルーティング先である複数のアダプタの必要を満たす場合、Oracle Virtual Directoryルーティング・エンジンは常にアダプタへのリクエストを最優先でルーティングします。その結果、他のアダプタのデータソースにプロビジョニングされたユーザーの認証は失敗します。

このプラグインは、バインド操作で、このプラグインで構成されているすべての適格なアダプタのリストを失敗させることができます。同様に、それはまた、エントリが1つのアダプタから返されていない場合にのみ、次のアダプタに検索を継続することができる検索ポリシーを提供します。

注意:
このプラグインにアダプタを構成するときは、次の点を考慮することが重要です。

- このプラグインに構成されているすべてのアダプタで、Visibilityに"Internal"を指定する必要があります。

- 任意のDNAttributesをバックエンド・ベースからカスタム・アダプタ・ベースに変換する必要がある場合は、それらはすべての内部アダプタのDNAttributesリストおよびCoordinatorAdapterプラグイン自体で構成される必要があります。

- アダプタを構成する順序は重要です。
同じ優先度でCoordinatorAdapterプラグインに複数のアダプタを構成する場合、Oracle Virtual Directoryはアダプタがプラグインで構成された順序に基づいて処理順序を決定します。

4.2.24.1 構成パラメータ

次に、CoordinatorAdapterプラグイン構成パラメータのリストを示します。

BindOption

次のバインド・オプションをサポートしているオプションのパラメータを示します。

- BindFirstSuccess(デフォルト・モード)は、最初の成功に到達するまで、バインドがすべての適格なアダプタのリスト(このプラグインで構成されている)で失敗するようにします。

- BindQuickFailでは、異なるアダプタ(このプラグインに構成されている)の複数のユーザーが同じDNをbindDNとして使用している場合、バインドですぐにエラーがスローされます。

SearchOption

次の検索モードをサポートしているオプションのパラメータを示します。

- SearchFirstMatch(デフォルト・モード)はすべてのアダプタに対してではなく、最初の適格なアダプタに対してのみ検索します。検索は、エントリが最初の適格なアダプタに存在しない場合にのみ次のアダプタで継続されます。

- SearchAllCandidatesは、Oracle Virtual Directoryのデフォルトの検索動作を保持します。

AdapterNames

アダプタを提供する必須で繰返しのパラメータ。そのアダプタに対して、ユーザーは認証されるか、または検索される必要があります。

DNAttributes

DNAttributesのリストを指定するオプションのパラメータ。その値は、Custom Adapter Baseから個々に構成されたアダプタ・ベースに変換される必要があります(または、その逆を行う必要がある)。このパラメータを構成しない場合は、いずれの属性もDN変換されません。

AutoTuneSearchOption

CoordinatorAdapterプラグインがSearchAllCandidatesモードに切り替えるためのインテリジェンス機能を持っているかどうかを制御するパラメータ。(このパラメータはデフォルトで無効になっているかfalseに設定されています。)

特定のケースでは、このプラグインは、SearchFirstMatchに構成されている場合でも、SearchAllCandidatesモードに切り替えるためのインテリジェント機能を持っています(検索フィルタの対象がすべての候補の場合)。たとえば、プラグインは検索フィルタが非平等コンポーネント(たとえばcn=*)を含む場合、すべてのコンポーネントがobjectclass属性(たとえばobjectclass=*)である場合などにモードを切り替えることができます。

- false(デフォルト・モード)は、モードを切り替えるプラグインの機能を無効にします。

- trueは、SearchAllCandidatesモードへの切替えプラグインを有効にします。

4.2.25 DBPasswordプラグイン

DBPasswordプラグインは、ハッシュされたパスワードを使用してデータベースに保存されているユーザーの認証を行うことができます。

注意:
このプラグインは、データベース・アダプタに対してのみデプロイする必要があります。

4.2.25.1 構成パラメータ

次に、DBPasswordプラグイン構成パラメータのリストと説明を示します。

HashAlgorithm

データベースでパスワードのハッシュ処理に使用される標準のハッシュ・アルゴリズムを指定するオプションのパラメータ。このパラメータは、MD5がデフォルト値の場合、MD2、MD5、SHA-1、SHA-256、SHA-384、SHA-512およびSSHAのハッシュ・アルゴリズムをサポートします。

EncodingMethod

データベース・パスワードに使用されているエンコーディング・メソッドを指定するオプションのパラメータ。このパラメータは、Hexがデフォルト値の場合、Base64またはHexのエンコーディング・メソッドをサポートします。

4.2.26 DNTranslatorプラグイン

DNTranslatorプラグインは、アダプタ間の識別名値属性のネームスペースを変換します。

注意:
このプラグインは、LDAPアダプタのDN属性リストで指定されるすべての属性のネームスペースを変換します。
このプラグインをLDAPアダプタに対してデプロイする必要があります。そして、この機能を必要とするすべてのLDAPアダプタに対してデプロイする必要があります。

4.2.26.1 構成パラメータ

次に、DNTranslatorプラグイン構成パラメータについて説明します。

IncludedAdapter

DN属性値を変換する間、ネームスペースが検討されているアダプタのリストを制限するオプションのパラメータ。デフォルトでは、このパラメータを指定しない場合、Oracle Virtual Directoryでは、すべての構成されたLDAPアダプタが含まれているものと見なされます。このパラメータは、プラグイン構成で何度でも繰返し指定できます。

グループとユーザーに対して2つの異なるアダプタがある場合は、1つのアダプタからのDN構文属性(uniquemember、memberofなど)は、別のアダプタ(デフォルト動作の対象アダプタではなく)のネームスペースに対して変換される必要があります。

たとえば、usersアダプタからのmemberof属性値は、groupsアダプタのvirtual baseに基づいて変換される必要があります。同様に、groupsアダプタのuniquemember属性は、usersアダプタのvirtualDNに基づいて変換される必要があります。

DNTranslatorプラグインは、入力パラメータとしてアダプタのリストを受け取り、入力リストで構成されている任意のアダプタの仮想ネームスペースに基づいてDN属性値(プラグインがデプロイされているアダプタから)を変換します。

次に例を示します。

Adapter A1:
Remote base: dc=a1,dc=com
Virtual base: dc=virtual a1,dc=com

Adapter A2:
Remote base: dc=a2,dc=com
Virtual base: dc=virtual a2,dc=com

Assume the entry from A1 is something like:
cn=test1,dc=virtual a1,dc=com
memberof: cn=group1,dc=a2,dc=com

DNTranslatorプラグインが値A2で構成されているIncludedAdaptersパラメータを使用してA1に構成されている場合、A1からのエントリは次のようになります。

cn=test1,dc=virtual a1,dc=com
memberof: cn=group1,dc=virtual a2,dc=com

4.2.27 HideGroupsAndUsersプラグイン

HideGroupsAndUsersプラグインは、AllowedGroupNameリストで指定されているこれらのユーザー・エントリとグループ・エントリのみの公開を可能にします。他のすべてのエントリは非表示になります。

注意:

- 返されるエントリが構成されたGroupObjectclassに属する場合、つまり、グループ・エントリの場合、プラグインまたは許可されたグループのネストされたグループで構成された許可されたグループである場合のみ、そのエントリが返されます。

- 返されるエントリが構成されているUserObjectclassに属する場合、つまりユーザー・エントリの場合、適格なグループのメンバーである場合のみ、そのエントリは返されます。

- 返されるエントリが前述の条件のいずれも満たしていない場合、つまり、グループ・エントリでもユーザー・エントリでもない場合には、エントリがそのまま返されます。

4.2.27.1 構成パラメータ

次に、HideGroupsAndUsersプラグイン構成パラメータについて説明します。

AllowedGroupName

Oracle Virtual Directoryによって公開される複数のグループ名を指定するのにAllowedGroupNameパラメータを使用します。このプラグインは、AllowedGroupNameリスト、それらのネストされたグループおよびそれらのネストされたグループのユーザーに含まれるそれらのグループのみを公開します。他のグループとユーザーは非表示です。たとえば、AllowedGroupNameパラメータ値がMyGroup1の場合、cn=MyGroup1属性と値のペアを持つグループが許可されたグループとみなされます。この繰返しのパラメータはオプションです。

AllowedGroupNameパラメータを指定しない場合は、Oracle Virtual Directoryはすべてのグループとユーザーを返します。

注意:

- この入力パラメータに静的グループを使用することができます。

- AllowedGroupNameパラメータで構成されたグループがバックエンド・データ・ソースで修正された場合、Oracle Virtual Directoryサーバーを再起動する必要があります。

GroupObjectClass

グループ・オブジェクトクラスを指定するのにGroupObjectClassパラメータを使用します。デフォルトでは、グループ・オブジェクトクラスはgroupOfUniqueNamesです。このパラメータはオプションです。

UserObjectClass

ユーザー・オブジェクトクラスを指定するのにUserObjectClassパラメータを使用します。デフォルトでは、ユーザー・オブジェクトクラスはpersonです。このパラメータはオプションです。

4.2.28 SAML XASPプラグイン

SAML XASPプラグインは、Oracle Virtual DirectoryがSAML X.509属性共有プロファイルを使用してSAMLアイデンティティ・プロバイダから属性を取得できるようにします。Oracle Virtual Directoryは、リモートLDAPサーバーにLDAP問合せを転送したり、RDBMSサーバーに対するSQL問合せを作成することなく、アイデンティティ・プロバイダにSAML V2.0アサーション問合せを送信します。その後、SAMLレスポンスの内容を使用して、SAML XASPプラグインによって戻されるエントリが作成されます。

SAML XASPプラグインは、次の3つのタイプの検索操作で動作可能です。

- (certificatedn=cn=user1,cn=users,dc=example,dc=com)を含むフィルタを使用したカスタム・アダプタ・ベースに対するサブツリー検索
この検索は、サブジェクトcn=user1,cn=users,dc=example,dc=comの情報をリクエストするSAML V2.0アサーション問合せに変換されます。問合せでエントリが戻されると、そのエントリは、キャッシュに追加され、そのcnによって索引付けされます。

- cn=user1,cn=users,dc=example,dc=comエントリに対するベース検索
この検索は、サブジェクトcn=user1,cn=users,dc=example,dc=comの情報をリクエストするSAML V2.0アサーション問合せに変換されるか、エントリがすでにキャッシュに格納されている場合、そのエントリを戻します。

- (cn=user1)を含むフィルタを使用したカスタム・アダプタ・ベースに対するサブツリー検索
エントリがキャッシュで検索されます。

注意:
前述の説明で、certificatednはattrname構成パラメータの値に、cnはindex構成パラメータの値に置き換えることができます。

4.2.28.1 制約

SAML XASPプラグインを使用する場合、次の制約が適用されます。

- このプラグインは、カスタム・アダプタで構成する必要があります。
詳細は、第2.6項「カスタム・アダプタの概要」および第18.2項「カスタム・アダプタの作成および構成」を参照してください。

- カスタム・アダプタのルートDNは、アイデンティティ・プロバイダで使用されるベースDNと一致するように構成する必要があります。

4.2.28.2 構成パラメータ

次に、SAML XASPプラグイン構成パラメータについて説明します。

- url: (必須)次のようにアイデンティティ・プロバイダのWebサービスURLを定義します。
http://hostname:port/fed/ar/soap

- attrname: (必須)検索フィルタのエントリのDNを含む属性を定義します(certificatednなど)。

- contains: (必須)エントリのDNの一部となる必要がある文字列を定義します(dc=exampleなど)。
エントリのDNに、これと正確に一致する文字列(大/小文字区別なし)が含まれない場合、エントリは戻されません。このパラメータによって、プラグインは、DITの一部に検索を制限できます(cn=usersの下のエントリのみを対象とするなど)。検索を制限しない場合、dc=exampleを指定します。

- index: (オプション)結果の索引付けに使用する属性のカンマ区切りリストを定義します(cnなど)。

注意:
索引付けするには、この属性がSAMLレスポンスに含まれる必要があります。

- ttl: (オプション)キャッシュ存続時間(ミリ秒)を定義します(デフォルト値および最小値は5000です)。

- debug: (オプション)追加メッセージを記録するかどうかを指定します。

- true: 追加メッセージを記録します。

- false: 追加メッセージを記録しません。

- reversedn: (オプション)証明書に含まれるDNを逆方向にするかどうかを定義します(dc=com,dc=example,cn=users,cn=user1など)。

- true: DNを逆方向にする場合に指定します。

- false: DNを逆方向にしない場合に指定します。

- response: (オプション)戻される各エントリに追加される属性=値のペアのカンマ区切りリストを定義します(department=Salesなど)。

4.3 エンタープライズ・ユーザー・セキュリティ、Real Application SecurityおよびOracle Net Servicesプラグインの概要

Oracle Virtual Directoryは、エンタープライズ・ユーザー・セキュリティ(EUS)、Real Application Security (RAS)、およびOracle Net Servicesとの統合を簡素化するためのプラグインが組み込まれています。この項では、この統合に関連するプラグインについて説明します。この項の内容は次のとおりです。

- EUSActiveDirectoryプラグイン

- EUSiPlanetプラグイン

- EUSOIDプラグイン

- EUSeDirectoryプラグイン

- EUSMemberDNMappingプラグイン

- EUSLockoutプラグイン

- ONamesプラグイン

- SubschemaSubentryプラグイン

- Real Application Securityプラグイン

関連項目:

- Oracleのエンタープライズ・ユーザー・セキュリティとの統合

- Oracleのネット・サービスとの統合

4.3.1 EUSActiveDirectoryプラグイン

EUSActiveDirectoryプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する際に、ユーザーIDがMicrosoft Active Directoryに格納されている場合にのみ使用します。EUSActiveDirectoryプラグインは、Active Directoryの属性を、エンタープライズ・ユーザー・セキュリティ・データベースで使用できる形式に変換します。

4.3.1.1 構成パラメータ

EUSActiveDirectoryプラグインには構成パラメータはありません。EUSiPlanetプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.2 EUSiPlanetプラグイン

EUSiPlanetプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する際に、ユーザーIDがOracle Directory Server Enterprise Edition(旧称はSun Java System Directory Server)に格納されている場合にのみ使用します。EUSiPlanetプラグインは、Oracle Directory Server Enterprise Editionの属性を、エンタープライズ・ユーザー・セキュリティ・データベースで使用できる形式に変換します。

4.3.2.1 構成パラメータ

EUSiPlanetプラグインには構成パラメータはありません。EUSiPlanetプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.3 EUSOIDプラグイン

EUSOIDプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する際に、ユーザーIDがOracle Internet Directoryに格納されている場合にのみ使用します。EUSOIDプラグインは、Oracle Internet Directoryの属性を、エンタープライズ・ユーザー・セキュリティ・データベースで使用できる形式に変換します。

4.3.3.1 構成パラメータ

EUSOIDプラグインには構成パラメータはありません。EUSOIDプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.4 EUSeDirectoryプラグイン

EUSeDirectoryプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する際に、ユーザーIDがNovell eDirectoryに格納されている場合にのみ使用します。EUSeDirectoryプラグインは、Novell eDirectoryの属性を、エンタープライズ・ユーザー・セキュリティ・データベースで使用できる形式に変換します。

4.3.4.1 構成パラメータ

EUSeDirectoryプラグインには構成パラメータはありません。EUSeDirectoryプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.5 EUSMemberDNMappingプラグイン

EUSMemberDNMappingプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する場合にのみ使用します。EUSMemberDNMappingプラグインは、外部リポジトリに格納されているエンタープライズ・ユーザー・セキュリティ・データベースの管理者グループの識別名(DN)ネームスペースを、Oracle Virtual Directoryがデータベースに送信するのと同じペイロードに変換します。

4.3.5.1 構成パラメータ

次に、EUSMemberDNMappingプラグイン構成パラメータのリストと説明を示します。

remoteDomainDN

エンタープライズ・ユーザー・セキュリティ・データベースの管理者グループが配置されているリモートの外部リポジトリ(Active Directory、Oracle Internet Directory、Oracle Directory Server Enterprise Edition)のベースDN。

localDomainDN

Oracle Virtual Directoryが公開するグループ名のベースDN。

注意:
一般的に、remoteDomainDNおよびlocalDomainDn構成パラメータの値は同一です。

4.3.6 EUSLockoutプラグイン

EUSLockoutプラグインは、Oracle Virtual DirectoryをOracleのエンタープライズ・ユーザー・セキュリティ・データベース製品と統合する場合にのみ使用します。LDAPサーバーには、バインドの試行が何度か失敗したらユーザー・アカウントをロックする機能があります。EUSLockoutプラグインにより、Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティの統合では、このロックアウト機能を使用し、次のようにして、バックエンドのLDAPサーバーのパスワード・ロックアウト・ポリシーを適用できます。

- Oracleデータベースへの不正なログインでは、バックエンドのLDAPサーバーにログインの失敗が記録されます。

- Oracleデータベースへの適切なログインにより、バックエンドのLDAPサーバーのログインの失敗数がリセットされます。

注意:
この機能は、Active Directoryを使用する統合では使用できません。

- ロックされたユーザー・アカウントを使用して、Oracleデータベースにログインすることはできません。

関連項目:
ユーザー・アカウントのロックアウトの有効化

EUSLockoutプラグインを構成するには、次の手順を実行する必要があります。

- バックエンドのLDAPサーバーに応じて、Active Directoryの場合はActiveDirectory、Oracle Directory Server Enterprise Editionの場合はiPlanet、Novell eDirectoryの場合はeDirectoryなどの値を使用し、directoryTypeパラメータを作成します。

- Oracle Virtual Directory-Enterprise User Security統合のユーザー・コンテナの名前を使用して、ネームスペースを作成します。

4.3.6.1 構成パラメータ

次に、EUSLockoutプラグイン構成パラメータのリストと説明を示します。

directoryType

ユーザーIDが格納されるOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合のバックエンド・ディレクトリ・サーバーのタイプ。サポートされる値は、Active Directory用のActiveDirectory、Oracle Directory Server Enterprise Edition用のiPlanet、またはNovell eDirectory用のeDirectoryです。

4.3.7 ONamesプラグイン

ONamesプラグインは、Oracle Virtual DirectoryをOracle Net Servicesと統合する場合にのみ使用します。このプラグインは、ソースLDAPディレクトリに固有のエントリを削除し、Oracle Virtual DirectoryとOracle Net Servicesの統合を容易にします。

4.3.7.1 構成パラメータ

ONamesプラグインには構成パラメータはありません。ONamesプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.8 SubschemaSubentryプラグイン

Oracleデータベースが、エンタープライズ・ユーザー・セキュリティおよびOracle Net Servicesの統合のOracle Virtual Directoryに問合せを行う場合、LDAPスキーマはOracle Internet Directoryのスキーマと同じ名前であることが想定されます。ただし、Oracle Internet DirectoryとOracle Virtual Directoryでは、LDAPスキーマの格納方法が異なります。SubschemaSubentryプラグインでは、Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティまたはOracle Virtual DirectoryとOracle Net Servicesの統合が機能できるよう、Oracleデータベースの問合せが透過的にリダイレクトされます。

4.3.8.1 構成パラメータ

SubschemaSubentryプラグインには構成パラメータはありません。SubschemaSubentryプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.3.9 Real Application Securityプラグイン

OracleのReal Application Security機能を使用してOracle Virtual Directoryを統合する場合にのみReal Application Securityプラグインを使用します。

注意:
このプラグイン用にjps-config-jse.xmlにポリシー・ストア情報を構成する必要があります。ポリシー・ストアの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のJava SEアプリケーションでのポリシー・ストアと資格証明ストアの構成に関する項を参照してください。

4.3.9.1 構成パラメータ

次に、Real Application Securityプラグイン構成パラメータのリストと説明を示します。

DirectoryType

LDAPアダプタで定義されたserverTypeから得られたパラメータ。

LoginAttributeNameInBackend

バックエンドLDAPでネーミング属性の必須パラメータ。

GuidAttributeNameInBackend

バックエンド・サーバーに定義されたグローバル・ユニバーサル識別子(GUID)属性を指定するオプションのパラメータ。(デフォルトではディレクトリ・タイプに基づいて導出されます。)

EnableAccountLockout

アカウントのロックアウトを有効または無効にするオプションのパラメータ。(デフォルトでは有効化されています。)

NestedGroupsResolutionLevel

ネストされたグループの解決を有効または無効にするオプションのパラメータ。(デフォルトでは無効化されています。)

GroupSearchBase

グループにSearchBase DNを指定するオプションのパラメータ。(デフォルトではアダプタのルートと同じです。)

GroupFilter

バックエンド・ディレクトリでグループ・エントリを識別するのにどのLDAP検索フィルタを使用するかを指定するオプションのパラメータ。(デフォルトではobjectclass=groupofuniquenamesです。)

GroupMemberAttribute

グループ・メンバーに属性名を指定するオプションのパラメータ。(デフォルトはuniquememberです。)

LoginAttributeName

RAS DBがログインにどの属性名を使用するかを指定するオプションのパラメータ。(デフォルトはuidです。)

MapAttribute

マッピングされる必要のある任意の属性を指定するオプションのパラメータ。フォーマットはattr1=attr2です。たとえば、cn=samaccountnameです。

4.4 Microsoft Active Directoryのプラグインの概要

Microsoft Active Directoryには、多くのアプリケーションで処理できない機能が複数ありますOracle Virtual Directoryには、アプリケーションに影響を与えず、再コーディングや再構成もせずに、アプリケーションがそれらの独自の機能を使用できるようにする複数のプラグインが組み込まれています。

この項では、Oracle Virtual Directoryに含まれているMicrosoft Active DirectoryおよびActive Directory Application Mode(ADAM)のプラグインについて説明します。この項の内容は次のとおりです。

- ActiveDirectory Passwordプラグイン

- Active Directory Ranged Attributesプラグイン

- InetADプラグイン

4.4.1 ActiveDirectory Passwordプラグイン

Active DirectoryおよびADAMには、LDAPを使用したユーザーのパスワードの更新に関して、次に示すような特別なルールがあります。

- パスワードの更新はセキュアなSSL接続経由でのみ行う。

- ユーザーが自分のパスワードを更新する場合は、同じ変更操作で新しいパスワードが変更追加に含まれている状態で、元のパスワードが変更削除に含まれている必要がある。

- 以前のパスワードがわからなくても、ユーザー・パスワードをリセットできるのは管理者のみ。

- Active DirectoryではuserPassword属性は使用せず、unicodePwd属性(Unicode形式)を使用する。

ActiveDirectory Passwordプラグインは、アプリケーションがActive Directoryのパスワード更新ルールを使用するように設計されておらず、すべての操作においてSSL経由でActive DirectoryまたはADAMに接続するのが不都合な場合に、Active Directoryのパスワード更新ルールを使用して管理者を支援します。ActiveDirectory PasswordプラグインをSSLに対応していないアダプタに構成し、そのプラグインがSSL対応のアダプタを指すようにすることにより、Active Directoryのパスワード更新がinetOrgPersonディレクトリのパスワード更新であるかのように機能します。

重要:
ActiveDirectoryプラグインは、LDAPアダプタにのみ構成する必要があります(通常はMicrosoft Active Directory)。

4.4.1.1 構成パラメータ

ActiveDirectory Passwordプラグインには、次の構成パラメータがあります。

adapter

リクエストにuserPassword属性が含まれる場合に、ActiveDirectory Passwordプラグインがリクエストを再ルーティングするアダプタの名前。指定されたアダプタでは、仮想ルートが現行のアダプタと同一で、ルーティングの可視性が内部に設定されている必要があります。adapterパラメータが定義されていない場合は、現行のアダプタが使用されます。

mapPassword

パスワードをunicodePwd属性に変換する必要がある(true)か、不要である(false)かを示します。サポートされる値は、trueまたはfalseです。デフォルト値はtrueです。

4.4.2 Active Directory Ranged Attributesプラグイン

Active DirectoryおよびADAMの属性には1000を超える値があり、戻された値の範囲を含む名前が付けられて、一度に1000の属性が戻されます(Windows 2003では1500)。クライアントには、次の書式で範囲が戻されます。

member;1-1000: somevalue

次の1000のエントリを取得するためには、クライアント・アプリケーションが問合せを繰り返し、属性メンバー1001-2000をリクエストすることを把握している必要があります。このため、アプリケーションでは、その他のディレクトリ製品に比べて独特な方法でActive Directoryに対応する必要があります。

Active Directory Ranged Attributesプラグインにより、Active DirectoryまたはADAMによって範囲が指定された属性が検出され、自動的にすべての値が取得されます。値の範囲が属性名に追加されるため、Active Directory Ranged Attributesプラグインが有効化されていない場合、LDAPアダプタのdn属性LDAP構成オプションは適用されません。

重要:
Active Directory Ranged Attributesプラグインにより、アダプタのどの属性をdn属性としてマークするかが決定され、適切なベース・マッピングが実行されます。LDAPアダプタでアダプタ・プラグインとして使用できるのは、Active Directory Ranged Attributesプラグインのみです。

4.4.2.1 構成パラメータ

Active Directory Ranged Attributesプラグインには構成パラメータはありません。Active Directory Ranged Attributesプラグインを有効化するには、それをプラグイン・チェーンに追加します。

4.4.3 InetADプラグイン

InetADプラグインは、ObjectClass Mapperプラグイン、Active Directory Ranged AttributesプラグインおよびActive Directory Passwordプラグインの機能を結合し、複数のActive Directory独自の機能を処理するために単一のプラグインを構成できるようにします。

Active DirectoryではActive DirectoryのNOS要件に固有の属性を持つuserおよびgroupオブジェクト・クラスが使用される一方で、ほとんどのLDAPディレクトリで、ユーザーやグループにinetOrgPersonおよびgroupOfUniqueNamesオブジェクト・クラスが使用されるため、InetADプラグインはObjectClass Mappingプラグインを利用します。

InetADプラグインを使用すると、Oracle Virtual DirectoryでActive DirectoryまたはADAMディレクトリ・サーバーにinetOrgPersonスキーマがあるように使用できます。InetADプラグインは、パラメータ構成に基づいて、属性およびオブジェクト・クラスの名前を変更し、Active Directoryのユーザーが必要な属性をすべて使用できるように属性を追加できます。構成パラメータが使用されていない場合、InetAdプラグインはActive DirectoryのuserまたはgroupをinetOrgPersonまたはgroupOfUniqueNamesオブジェクト・クラスとして使用できます。

注意:
属性のマッピング関係が生じた場合、client-接頭辞はクライアント側を、source-接頭辞はデータ・ソース側を表します。たとえば、Active DirectoryサーバーのuserをマッピングしてそれをInetOrgPersonとして表すようにした場合、Active Directoryはソース側でInetOrgPersonはクライアント側になります。

4.4.3.1 構成パラメータ

次に、InetADプラグイン構成パラメータのリストと説明を示します。

directoryType

ユーザーのアクティブ化を実行する際に使用するディレクトリのタイプ。サポートされている値はSunOne、eDirectory、ADAMおよびActiveDirectoryです。次に例を示します。

パラメータ名: directoryType

パラメータ値: ActiveDirectory

activationAttribute

activationAttributeパラメータは、アプリケーションに、基礎となるディレクトリのユーザー・アクティベーション・システムに関する情報がない場合に使用します。activationAttributeパラメータにより、ユーザー・アクティベーション・フラグが含まれている着信属性が、Oracle Virtual Directoryに通知されます。その後、このフラグは、ディレクトリ固有の属性およびフラグにマップされます。次に例を示します。

パラメータ名: activationAttribute

パラメータ値: myuseraccountcontrol

deactivationValue

ユーザーを非アクティブとしてマークする必要があることを示すactivationAttributeに指定された属性値のカンマ区切りリスト。

activationValue

ユーザーをアクティブとしてマークする必要があることを示すactivationAttributeに指定された属性値のカンマ区切りリスト。

mapObjectClass

client-ObjectClass = AD-ObejctClassという書式でマップされるobjectClass。次に例を示します。

パラメータ名: mapObjectClass

パラメータ値: inetOrgPerson=user

mapObjectClassパラメータは、複数のマッピングに複数回使用できます。デフォルト値は、groupOfUniqueNames=group, inetOrgPerson=userです。

addAttribute[-objectclassvalue]

追加プロセス中にユーザーに属性を追加します。オプションのオブジェクト・クラス値は、特定のオブジェクト・クラスのみに属性を追加するために、構成名に追加できます。たとえば、ユーザー・オブジェクト・クラスのみにuserAccountControl属性を追加するには、次のものを使用します。

パラメータ名: addAttribute-user

パラメータ値: userAccountControl=546

注意:
名前をパーセンテージ文字(%)で囲んで入力することにより、別の属性値が式として代入されます。デフォルト構成は次のとおりです。

addAttribute-user: useraccountcontrol=544,
addAttribute-group:samaccountname=%cn%,
addAttribute-group: grouptype=-2147483646

filterAttribute[-objectclassvalue]

追加操作中に、戻されるすべてのエントリから削除される属性のカンマ区切りのリスト。条件のオブジェクト・クラス値は、特定のオブジェクト・クラスの属性を除外するために、パラメータ名に追加できます。次に例を示します。

パラメータ名: filterAttribute

パラメータ値: objectsid,memberof,samaccountname

mapAttribute

client-Attribute=AD-attributeという書式でマップされる属性。次に例を示します。

パラメータ名: mapAttribute

パラメータ値: uniqueMember=member

mapAttributeパラメータは、複数のマッピングに複数回使用できます。デフォルト値は、uniqueMember=member、uid=samaccountname、ntgrouptype=grouptypeです。

filterAuxiliaryClass

追加操作中に削除する必要のあるオブジェクト・クラスのカンマ区切りのリスト。Active Directory for Windows 2000では、エントリの追加中に補助オブジェクト・クラスをリストすることはできませんが、Microsoft Active DirectoryおよびADAM for Windows Server 2003では補助クラスをリストできます。デフォルト値は、person、organizationalPersonです。

filterObjectClassOnModify

filterObjectClassOnModifyパラメータを使用して、変更操作中にobjectClassエントリの変更を削除します。サポートされる値はtrue (変更を削除)またはfalse (変更を削除しない)です。trueがデフォルトです。次に例を示します。

パラメータ名: filterObjectClassOnModify

パラメータ値: true、false

mapPassword

パスワードをunicodePwd属性に変換する必要がある(true)か、不要である(false)かを示します(ADAM)。サポートされる値は、trueまたはfalseです。デフォルト値はtrueです。

sslAdapter

リクエストにuserPasswordが含まれる場合に、このプラグインがリクエストを再ルーティングするアダプタの名前。sslAdapterパラメータを設定しない場合は、現行のアダプタが使用されます。sslAdapterパラメータによって指定されるアダプタは、次のようになっている必要があります。

- InetADプラグインが構成されているアダプタと同じローカル・ベース

- ルーティングの可視性がInternalに設定されている

4.5 Oracle Access Managerプラグインの概要

Oracle Virtual Directoryには、Oracle Access Managerとの統合を簡略化するプラグインが含まれています。この項では、この統合に関連するプラグインについて説明します。この項の内容は次のとおりです。

- OAMPolicyControlプラグイン

4.5.1 OAMPolicyControlプラグイン

Oracle Virtual DirectoryとOracle Access Managerの統合の場合のみ、OAMPolicyControlプラグインは、認証にLDAPを使用し、Oracle Access Managerポリシー制御を使用する必要があるがOracle Access Managerと統合できないアプリケーションに対応します。

OAMPolicyControlプラグインをデプロイする前に、次のことが必要です。

- Oracle Access Managerポリシー構成を使用しているLDAPアダプタすべてについて、「バインド」パススルー設定を「なし」に設定します。
このプラグインは、すべての認証を処理し、プロキシ資格証明を使用してすべての操作を実行します。

- Oracle Access Managerに対して別のアダプタを構成します。
これらのアダプタは、Oracle Access Managerポリシーを使用するには、OAMPolicyControlプラグインを使用する必要があります。これらのアダプタを同じOracle Virtual Directoryサーバーにデプロイする場合は、次のオプションのいずれかを構成する必要があります。

- アダプタごとに異なるLDAPネームスペースを使用します。Oracle Access Managerのアダプタのネームスペースは、汎用LDAPクライアントが使用するネームスペースから独立したものにする必要があります。

- 「Oracle Virtual Directory」ビューを、別のOracle Access Managerアダプタに対するリクエストを区別するアクセス・レベルの基準を指定して使用します。

- 次のようにしてOracle Access Manager Access Serverを構成します。

- Oracle Virtual Directoryに対応するプロキシ・リソースを作成します。

- アイデンティティ・サーバーおよびアクセス・サーバー用のポリシー・ドメインを無効化します。これは、このプラグインがOBSSO Cookieをキャッシュしないためです。

- AccessSDKを次のように構成します。

- AccessServerSDK\oblix\tools\configureAccessGateを使用して、Oracle Access Manager Access Server用にAccessSDKインストールを構成します。

- -Djava.library.pathがAccessSDKインストールを指すようにすることで、Oracle Virtual Directoryコンポーネントを起動するようにopmnを構成します。
INSTANCE_HOME/config/OPMN/opmn/opmn.xmlファイルを次のように編集します。

<ias-component id="ovd1">
<process-type id="OVD" module-id="OVD">
<module-data>
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms512m -Xmx512m
-Dvde.soTimeoutBackend=0
-Doracle.security.jps.config=$ORACLE_
INSTANCE/config/JPS/jps-config-jse.xml
-Djava.library.path=AccessSDK_install_
dir/AccessSDK/AccessServerSDK/oblix/lib/"/>
<data id="java-classpath" value="$ORACLE_
HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
</module-data>
<stop timeout="120"/>
</process-type>
</ias-component>

- AccessSDK_install_dir/AccessServerSDK/oblix/libからORACLE_HOME/ovd/plugins/libにjobaccess.jarファイルをコピーします。

注意:
前述の前提条件となる構成を正常に完了しないと、Oracle Virtual DirectorによってNoClassDefFoundエラーが生成されます。

4.5.1.1 構成パラメータ

OAMPolicyControlプラグインには、次の構成パラメータがあります。

注意:
useAccessAuthPolicyを除く次のすべての構成パラメータが、OAMPolicyControlプラグインのデプロイに必要です。

resourceIdOVD

Oracle Access Managerサーバーによって構成されるOracle Virtual Directory用のプロキシ・リソースを指定します。たとえば、//host:port/ovd_proxy_resourceなどです。

identityproxyid

identityproxyidパラメータは、アイデンティティ・サーバーに対する認証に使用され、管理者のusernameAttributeの値を指定します。

install_dir

必須ライブラリを含むAccessSDKインストール・ディレクトリを指定します。たとえば、AccessSDK_INSTALL_DIRECTORY/AccessServerSDK/などです。

OrclOVDEncryptedproxypasswd

アイデンティティ・サーバーに対する認証用の管理者パスワード。

identityEndpointAddress

アイデンティティ・サーバーのum_modifyUser Webサービスのリスニング・エンドポイントに対応するURLを指定します。たとえば、http://host:port/identity/oblix/apps/userservcenter/bin/userservcenter.cgiなどです。

usernameAttribute

アイデンティティ・サーバーのログイン属性となるように構成される属性を指定します。たとえば、uidやgenUserIdです。

useAccessAuthPolicy

useAccessAuthPolicyは、オプションの大文字小文字を区別しないパラメータであり、プロキシ・リソースにアクセスする際のOracle Access Managerサーバーの認証ポリシーの使用方法を決定します。サポートされている値はTrueおよびFalseです。デフォルト設定はFalseです。

5 Oracle Virtual Directoryのマッピングの概要

この章では、Oracle Virtual Directoryマッピングについて説明します。この章の内容は次のとおりです。

- 第5.1項「マッピングとは」

- 第5.2項「マッピング・テンプレートの概要」

注意:
この章のマッピング情報は、履歴情報として提供されています。これまでのデフォルトのマッピング・スクリプトもサポートされていますが、新しいカスタマイズではJavaプラグインAPIを使用する必要があります。これは、Java APIがすべてのOracle Virtual Directory機能へのアクセスを完全にサポートし、一般的に開発が容易なためです。

5.1 マッピングとは

Oracle Virtual Directoryには、Pythonスクリプト言語に基づく、双方向のマッピング・システムが含まれています。マッピングは、特別なPythonスクリプト(ファイル形式は.mpy)で、インバウンドおよびアウトバウンドのトランザクション・データ・フローを処理します。マッピングによりOracle Virtual Directoryサーバーにデータが渡されるため、Oracle Virtual Directoryの管理者は、データを操作およびマッピングできます。広く普及しているPythonスクリプト言語に基づくOracle Virtual Directoryのマッピング・システムでは、新しい固有の複雑なプログラミング言語を習得せずに、複雑なデータ操作を行うことができます。Oracle Virtual Directoryのマッピング・システムにより、企業はアプリケーションからIDへのアクセスをさらに柔軟にサポートすることができます。Oracle Virtual Directoryは、マッピングを実行可能バイト・コードにコンパイルし、最高のパフォーマンスのためにインラインで実行します。

統合担当者は、1つのデータソースから別のデータソースに情報をマッピングするときに、カスタム変換を実行する使いやすいマッピング・スクリプトを開発できます。このようなスクリプトは、サーバーをリセットせずに、実行中のサーバーにインストールしてデプロイできます。マッピング・スクリプトは、リクエストがデータソースに到達するためにシステムに入る際にリクエストを調整し、クライアントに戻る途中でレスポンスを変換できます。たとえば、マッピングを使用すると、スキーマの正規化(Active DirectoryをInetOrgPersonのように見せるなど)、データ型の添付(ハッシュ・パスワードに対する{sha}など)、またはデータストアから取得した属性値に基づく仮想属性の作成を行うことができます。

マッピングの作成時には、事前定義済のマッピング・テンプレートを使用して構成を簡略化することも、新しいカスタム・マッピングを作成することもできます(マッピング・テンプレートの詳細は、「マッピング・テンプレートの概要」を参照してください)。通常、マッピングはコンパイル済JavaコードとしてOracle Virtual Directoryサーバーにデプロイされ、マッパーと呼ばれる特別なタイプのプラグイン内部で実行されます。プラグインと同様、マッピングは、グローバルに実行することも、アダプタ・レベルで実行することもできます。複数のマッピングとアダプタを組み合せて、総合的な変換サービスを実行する個々の機能のセットを作成できます。図5-1は、1つのマッピングを複数のアダプタで実行し、別のマッピングを特定のアダプタのみで実行する場合の一般的なシナリオを示しています。

図5-1 単一のアダプタおよび複数のアダプタにおけるマッピング・デプロイの例

各マッピングにはインバウンドおよびアウトバウンドのフローがあり、リクエストを受信するときに一方向の変換を行い、リクエスト元のアプリケーションに結果が戻されるときには、その変換を逆方向にすることができます。サーバーがこの意図を予測することは通常不可能なため、このようにプログラム上で方向を逆にすることは重要です。

Oracle Virtual Directoryでは、マッピングをグローバルに実行するか、または1つのアダプタのコンテキスト内で実行するかを非常に柔軟に判断できます。状況によっては、仮想ツリー内でマッピングを適用する場所をさらに制限する必要が生じる場合もあります。たとえば、アダプタがMicrosoft Active Directoryドメインのかわりになるように設定され、DC=VAN,DC=Oracle,DC=comを指しているとします。ドメイン・ツリー内のそのポイントの下には、CN=UsersコンテナおよびCN=Groupsコンテナがあります。マッピングにネームスペース・フィルタを追加すると、ツリーの一部にのみそれを適用できます。

次に、Oracle Virtual Directoryのマッピングに関して考慮する必要のある注意事項を示します。

- Oracle Virtual Directoryのマッピングでは、LDAPデータ操作用のOracle提供の追加機能を使用して、Python言語を最大限に利用できます。Pythonに関する詳細は、次に示す、Pythonプログラミング言語の公式Webサイトを参照してください。
http://www.python.org/

- マッピングを使用して属性名を変更する場合、DB_Groupsマッピングで行われるように、カスタム・コードが受信フィルタ・オブジェクトを上書きする場合にのみ、Oracle Virtual Directoryで、名前の変更された属性/値の検索がサポートされます。次に例を示します。
アウトバウンド処理中に、マッピングはgivenname属性の名前をcnに変更します。インバウンド処理中に、cn=Johnなどの受信するLDAP検索フィルタは、マッピング・カスタム・コードによってgivenname=Johnに変換される必要があります。

- マッピングをデプロイし、Oracle Virtual Directoryに対してldapsearchコマンドを実行する場合、検索ベースは、マッピングに構成されたネームスペースか、そのネームスペースの子であることが必要です。

5.1.1 マッピングおよびカスタム・プラグインを使用する理由

マッピングを使用する顧客の多くは、Oracle Virtual Directoryに付属のデフォルトのマッピングを使用してアプリケーション要件を満たしています。マッパーAPIで対応しているのはJavaプラグイン機能のサブセットのみであること、PythonよりJavaに精通している開発者の方が多く、コードの開発に必要な時間を短縮できることから、カスタマイズが必要な場合は一般的にJavaプラグインAPIが使用されます。

5.1.2 概要: マッピングのデプロイ

次に、アダプタ・レベルおよびグローバル・サーバー・レベルで、マッピングをデプロイするプロセスの概要を示します。

1. マッピング・テンプレートを使用してマッピングを構成し、スクリプトにコンパイルして、Oracle Virtual Directoryサーバーにデプロイすると、グローバル・サーバー・レベルまたはアダプタ・レベルでアクティブ化されます。

関連項目:
詳細は、「マッピング・テンプレートを使用したマッピングの作成」を参照してください。

2. マッピングをグローバル・サーバー・レベルまたはアダプタ・レベルで構成するには、名前を付け、マッピング・スクリプト・ファイルを指定し、実行予定の仮想ディレクトリでのネームスペースを決定してアクティブ化します。

関連項目:

- グローバル・サーバー・レベルでのマッピングの構成に関する詳細は、「サーバー・マッピングの作成およびアクティブ化」を参照してください。

- アダプタ・レベルでのマッピングの構成の詳細は、「アダプタへのマッピングの適用」を参照してください。

5.2 マッピング・テンプレートの概要

この項では、Oracle Virtual Directoryマッピング・テンプレートについて説明します。この項の内容は次のとおりです。

- Active_Directory_to_inetOrg

- Common_Name_to_Given_Name

- ConditionalPublish

- DB_Groups

- Map_DB_Password

5.2.1 Active_Directory_to_inetOrg

Microsoft Active Directoryのユーザーとグループ・オブジェクトを、それぞれInetOrgPerson inetOrgPersonおよびgroupOfUniquenamesオブジェクトにマッピングします。

5.2.2 Common_Name_to_Given_Name

デフォルトのsnおよびgivennameの2つの属性の値を結合することで、仮想の共通名属性を作成します。通常、Common_Name_to_Given_Nameマッピングは、名前と姓のみはあるがフルネームはないデータベース・アダプタに使用されます。

注意:
このマッピングでは、共通名属性のサブストリング・フィルタはサポートされていません。

5.2.3 ConditionalPublish

別の属性の条件値が一致する場合に、指定された属性を削除します。ConditionalPublishマッピングは、さらに高度なトレーニング環境のFERPA保護属性を非表示にする際に便利です。

5.2.4 DB_Groups

グループに関する表を有効なLDAPグループにマップするときにこのテンプレートを使用します。最初の列はcn(グループ名)になります。2番目の列はuniquememberになります。uniquememberでは、RDN値のみが表内で使用されるように、DNが削除されます。たとえば、(uniqueMember=cn=XXX,ou=testusers)が(uniqeMember=XXX)に変換されます。

5.2.5 Map_DB_Password

インバウンドのバイナリ構文パスワードを、データベースと互換性のあるIA5Stringパスワードにマッピングします。

注意:
Map_DB_Passwordマッピングとデータベース・アダプタを関連付け、changetypeをAdd、UserPasswordなどのバイナリ属性をOracle Virtual Directoryの既存の値にしてLDAP変更操作を実行すると、主キー制約がデータベース表に設定されていない場合、データベースに重複行が追加されます。

6 Oracle Virtual Directoryのセキュリティの概要

この章では、Oracle Virtual Directoryのセキュリティについて説明します。この章の内容は次のとおりです。

- 第6.1項「概要」

- 第6.2項「Oracle Virtual Directoryの認証の概要」

- 第6.3項「Oracle Virtual Directoryのアクセス制御の概要」

- 第6.4項「ウォレットおよび証明書管理の概要」

6.1 概要

Oracle Virtual Directoryは、複数層のアクセス制御および認証をサポートしています。アダプタを介してアクセスされるリモート・ディレクトリの場合、Oracle Virtual Directoryではそれらのシステムに固有のセキュリティをサポートします。使用されるアダプタやその機能に応じて、passcredentialsオプションを設定し、認証およびアクセス制御を実行するためにエンド・ユーザーのバインディング資格証明をリモート・ディレクトリに渡すかどうかを判断できます(図6-1を参照)。

図6-1 Oracle Virtual Directoryの複数層のアクセス制御および認証

6.2 Oracle Virtual Directoryの認証の概要

この項では、Oracle Virtual Directoryの認証について説明します。この項の内容は次のとおりです。

- パススルー認証

- プロキシ・アカウント認証

- クライアント証明書の認証

6.2.1 パススルー認証

アダプタのパススルー・モードが有効化されていて、ユーザーがOracle Virtual Directoryに対して認証される場合、Oracle Virtual Directoryでは受け取ったユーザーIDおよびパスワード資格証明を使用して、ユーザーのかわりにリモート・ディレクトリにログインします(パスワード認証の場合のみ)。リモート・ディレクトリへの認証(バインド)に失敗すると、ユーザーの試行したバインドも失敗します。このモードでは、リモート・ディレクトリがユーザーの資格証明を確認する役割を果しています。

passcredentialsがneverに設定されている場合(または選択したアダプタでサポートされていない場合)は、Oracle Virtual Directoryでクライアントの認証を実行する必要があります。これを実行するためには、外部ディレクトリのパスワードをクリアテキストで保存するか、CRYPT、SHAまたはSSHAの一方向暗号化ハッシュを使用する必要があります。Oracle Virtual Directoryで使用されている暗号化ハッシュを判断するには、暗号化されたテキストに{crypt}という形式の接頭辞が適用されている必要があります。代替元のソースでこの形式が使用されていない場合は、マッピング・ルールを設定してこれを定義する必要があります。マッピング・ルールにより、Oracle Virtual Directoryに特定の暗号化書式の処理方法を伝達する接頭辞が追加されます。接頭辞が存在しない場合は、通常のテキスト比較が行われます。

passcredentialsのneverモードでは、ユーザーによって指定されたパスワードのハッシュ・アルゴリズム(アダプタから戻された値に指定されている)を実行し、アダプタから戻された値と結果を比較することで、Oracle Virtual Directoryによって認証が完了します。

注意:
クライアントがクリアテキスト・パスワードを使用せずに(証明書などを使用して)バインドすると、サーバーはユーザーの資格証明を代替元のディレクトリに渡すことができません。Oracle Virtual Directoryでは、構成済のアダプタ・アカウントを使用して、バインド検証およびリクエストされたLDAPサービスを実行します。これは、passcredentialsがneverに設定されている場合の処理と同じです。

6.2.2 プロキシ・アカウント認証

Oracle Virtual Directoryでは、使用可能なパスワードのないユーザーを認証する場合、バインドDNがアダプタのネームスペースの外にあるユーザーのかわりを行う場合、またはpasscredentialsがneverに設定されている場合にプロキシ(またはデフォルト)アカウントが使用されます。また、接続されたLDAPアダプタのディレクトリに対してOracle Virtual Directoryのルート管理者アカウントおよび匿名の両方を認証する際にも、アダプタのプロキシ・ユーザーIDおよびパスワードが使用されます。デフォルト・アカウントは、証明書を使用して認証するユーザーにも使用されます。そのため、passcredentialsモードが有効化されている場合には、リモート・ディレクトリでデフォルト・アカウントを権限のないアカウント(匿名など)に設定する必要があることの理解が重要です。これは、現行のアダプタにマップできないアカウントを処理するために、プロキシ・アカウントが必要な状況が数多くあるためです。

6.2.3 クライアント証明書の認証

Oracle Virtual Directoryでは、X.509デジタル証明書を使用してクライアントが仮想ディレクトリに対して認証する機能がサポートされています。LDAPクライアントでは、X.509デジタル証明書を使用して仮想ディレクトリに対して認証するには、SSLおよびSASLがサポートされている必要があります。次に、SSL認証が機能する2つのモードを示します。

- 接続は保護するが実際のディレクトリに対しては認証しない方法としてクライアント証明書を使用

- 証明書を使用してOracle Virtual DirectoryをバインドするためにSASLを使用

次に、認証にクライアント資格証明を使用する場合のガイドラインのリストを示します。

- Oracle Virtual Directoryへのバインドに証明書を使用している場合、証明書はバックエンドのデータ・ストアに対してではなく、Oracle Virtual Directoryに対する認証にのみ使用されます。クライアント証明書の認証に必要な秘密鍵へのアクセス権があるのはLDAPクライアントのみであるため、バックエンドのデータ・ストアに対する認証は公開鍵インフラストラクチャ(PKI)によって阻止されます。そのため、LDAPアダプタを使用している場合には、バックエンドのデータ・ストアに対するすべてのOracle Virtual Directory操作はプロキシDNアカウントとして実行されます。

- 証明書には独自の識別名(DN)が含まれます。これは、実際にバインディングしているユーザーのDNと一致しない場合もあります。その場合、アクセス制御リストが適切に機能するように、証明書のDNをOracle Virtual DirectoryのユーザーのDNにマップする必要が生じることがあります。このマッピングは、プラグインを使用して実行できます。

- Oracle Virtual Directoryでは、keys.jksファイルに保存されている、ルートCAによって発行された証明書はすべて受け入れられます。

6.3 Oracle Virtual Directoryのアクセス制御の概要

Oracle Virtual Directoryは、接続されたすべてのデータ・ストアに一様に適用できる詳細なアクセス制御を提供します。また、Internet Engineering Task ForceのRFC 2820「Access Control Requirements for LDAP」にも準拠しています。アクセス制御のルールは、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)というタイトルのインターネット・ドラフトに基づいてモデル化されています。

注意:
Oracle Virtual Directoryは、1つ以上のエンタープライズ・データ・ソースを1つのディレクトリ・ビューに仮想的に抽出します。そのため、アクセス制御リスト(ACL)およびアダプタ・ネームスペースはそれぞれ独立しています。エントリを削除すると、そのエントリに関連付けられているACLも削除されます。ただし、アダプタのルート値を変更しても、エントリに関連付けられているACLには影響しません。ACLおよびアダプタ・ネームスペースは、それぞれ独立させて構成する必要があります。

この項では、Oracle Virtual Directoryのアクセス制御について説明します。この項の内容は次のとおりです。

- ソース・ディレクトリのアクセス制御

- Oracle Virtual Directoryのアクセス制御

- アクセス制御およびグループ

- Oracle Virtual Directoryのアクセス制御コンポーネント

- Oracle Virtual Directoryのアクセス制御リストの適用

6.3.1 ソース・ディレクトリのアクセス制御

リモート・ディレクトリに対するクライアントとして、Oracle Virtual Directoryは、リモート・ディレクトリで実行されている認証ルールに従う必要があります。適用されるルールは、リモート・ディレクトリに渡されたユーザー・コンテキスト(Oracle Virtual Directoryが代替元のディレクトリへの接続にどのアカウントを使用しているかなど)によって異なります。

passcredentialsオプションを有効化した場合、リモート・ディレクトリでは、Oracle Virtual Directoryがリモート・ディレクトリに渡すユーザー・コンテキストに応じてルールが実行されます。Oracle Virtual Directoryにより、適切に変換されたデータの結果およびエラーがユーザーに戻されます。たとえば、「アクセスが拒否されました」というメッセージが戻された場合、Oracle Virtual Directoryによりそのメッセージがクライアントに戻されます。アクセス制御によりデータがフィルタ処理された場合には、Oracle Virtual Directoryによりフィルタ処理されたデータが取得され、構成済の任意の変換が適用されてユーザーにそのデータが渡されます。

passcredentialsオプションが有効化されていない場合、リモート・ディレクトリではすべてのリクエストのプロキシ・ユーザーのみが認識され、どのユーザーがOracle Virtual Directoryにバインドされているかにかかわらず同じ認証が適用されます。

passcredentialsオプションが有効化されているか無効化されているかに関係なく、Oracle Virtual Directoryの独自のアクセス制御および認証が提供されます。

6.3.2 Oracle Virtual Directoryのアクセス制御

Oracle Virtual Directoryでは、アクセス制御情報を保存することで、仮想ディレクトリのネームスペース全体でアクセス制御がサポートされています。この情報は、DITのエントリのDNまたはサブツリーのDNへの変更リクエストを捕捉することで、自動的にメンテナンスされます。Oracle Virtual Directoryのアクセス制御リスト(ACL)は、アダプタを使用して接続されているディレクトリではなく、仮想ディレクトリのネームスペースに定義されているため、単一のACLを、複数のアダプタ全体のデータに対するアクセス権を制御するように定義できます。

同じアクセス制御のドラフト標準を使用している代替元のLDAPディレクトリにエントリが属する場合、Oracle Virtual Directoryにより変更が捕捉され、その内容がエントリの独自のACI値に適用されるため、Oracle Virtual Directoryを使用してそのソース・ディレクトリ内のアクセス制御を変更することはできません。この場合、それらのエントリに対する変更は、ソース・ディレクトリに直接行う必要があります。他のベンダーのディレクトリ・サーバーではアクセス制御情報の保存に異なる属性が使用されているため、通常これは問題ではありません。

6.3.3 アクセス制御およびグループ

アクセス制御のサブジェクトとしてグループを使用している場合、グループの位置およびアダプタ変換によるグループへの影響を考慮することが重要です。定義されている各LDAPプロキシ・アダプタでは、DN属性リストの値が定義されていることを確認してください。この値により、エントリDNに加えて、仮想ディレクトリ・ツリーにマップする必要のある属性のリストが定義されます。DNを含む属性値に依存するアクセス制御の場合は、値が正しくマップされている必要があります。

複数のアダプタ(ローカル・ストア・アダプタおよびLDAPアダプタなど)のメンバーが含まれるグループを作成するには、グループをローカル・ストア・アダプタのアダプタ・ネームスペース(仮想ディレクトリのローカル・ストアなど)に配置する必要があります。グループが外部のLDAPディレクトリ内に配置されていて、そのディレクトリには存在しないメンバーが含まれている場合には、外部ディレクトリのネームスペースに存在しないエントリにはコンテキストがないため、変換は正常に実行されません。

6.3.4 Oracle Virtual Directoryのアクセス制御コンポーネント

この項では、Oracle Virtual Directoryのアクセス制御コンポーネントについて説明します。この項の内容は次のとおりです。

- 概要

- アクセス制御の有効範囲

- アクセス制御権

- 属性のアクセス制御

- アクセス制御の権限

- アクセス制御のサブジェクト

6.3.4.1 概要

Oracle Virtual DirectoryのACLを作成するには、次のようにします。

- アクセス制御ポイントを構成(つまり、ACLが適用される場所を指定)します。通常、アクセス制御は識別名ですが、ツリーのベースを表すルートにすることもできます。

- 仮想ディレクトリ・ツリーのエントリ全体である構造型アクセス項目と、エントリの属性であるコンテンツ・アクセス項目の両方にポリシーを構成します。

注意:
Oracle Virtual Directoryサーバーのアクセス対象または変更対象のエントリがACLアクセス制御ポイントと同じまたはそれより下の場所に存在しない場合、指定されたACLはそれ以上評価されません。アクセス対象または変更対象のエントリがACLアクセス制御ポイントと同じまたはそれより下の場所に存在する場合は、ACLのスコープ設定が評価されます。

6.3.4.2 アクセス制御の有効範囲

Oracle Virtual Directoryでは、アクセス制御にエントリとサブツリーという2種類の有効範囲が定義されています。図6-2に、これらの有効範囲コンポーネントがどのように機能するかを示します。

図6-2 Oracle Virtual Directoryのアクセス制御の有効範囲

図6-2に示すように、場所と有効範囲は関連しており、場所は有効範囲が評価されるDITでの位置を示します。図6-2のエントリ部分では、アクセス対象または変更対象のディレクトリ・エントリ(DN)が、場所1で示されているのと同じDNである場合にのみACLが適用されます。図6-2のサブツリー部分では、場所1から始まり下に伸びているすべてのDNが、有効範囲がサブツリーであるACLの影響を受けます。指定されたACLの場合、サブツリー有効範囲の唯一のエンドポイントは、1つ目のACLよりも下の場所(場所2)で宣言された他のACLによって、1つ目のACLで定義されているルールが変更される場合に発生します。

エントリ有効範囲は、多くの場合、様々なサブジェクトおよび拒否の設定とともに使用されます。あるエントリに、同じレベルまたはそれより下のエントリよりも機密性の高い情報が含まれていて、プライベートにしておく必要がある場合に特に便利です。タイプのみが異なる2つの有効範囲のルールが存在する場合、エントリ有効範囲がサブツリー有効範囲より優先されます。

6.3.4.3 アクセス制御権

各権限に対するOracle Virtual Directoryのアクセス権には、付与と拒否の2種類があります。クライアントに特定情報の一部へのアクセス権を付与するか拒否するかは、アクセス制御ルールおよび保護されているエントリに関連する多くの要因に基づいて決定されます。決定プロセスでは、次のガイドラインが使用されます。

- 特性: より明確なルールが曖昧なルールより優先されます。たとえば、ACLの特定のクライアントDNはグループ参照よりも優先されます。

- 拒否: アクセス制御が有効化されている場合のデフォルトで、操作を承諾または拒否するアクセス制御情報はありません。

- 承諾: Oracle Virtual Directoryでアクセス制御が無効化されている場合のデフォルトです。

- エントリとサブツリー: subjectおよびattributesの特性が同一の場合、エントリ有効範囲はサブツリー有効範囲よりも優先されます。

subjectのタイプのみが異なるACLの評価において、Oracle Virtual Directoryで使用される優先順位は次のとおりです。

1. 特定のDNまたはIPアドレス

2. this

3. group

4. subtree

5. public

注意:
2つのACLの違いが承諾/拒否のプロパティのみの場合、ACLが追加される順序に関係なく、許可されるのは拒否です。たとえば、次の2つのACLでは、publicのすべての属性の検索(s)および読取り(r)は拒否されます。

deny:s,r#[all]#public:
grant:s,r#[all]#public:

6.3.4.4 属性のアクセス制御

attributesコンポーネントは、エントリを選択することで権限をエントリ全体に適用するか、特定の属性を識別することで一部またはすべての属性に適用するかが決定されるため、permissionsコンポーネントと強力にリンクされています。

6.3.4.5 アクセス制御の権限

エントリ全体またはその属性に適用する権限は、実行可能なLDAP操作のタイプに対応しています。それぞれのLDAPアクセス権限は独立しており、ある権限を保持していても別の権限が付与されていることにはなりません。ACLを構成している場合、同じ場所に関連する2つのACLを保持することがよくあります。これは、個々の属性の権限(属性権限)と、エントリ自体の権限(エントリ権限)を分離する必要から生じます。属性権限には、*(すべての属性を表す)のattributeコンポーネント、または属性権限を適用するリスト属性が必要です。エントリ権限には、エントリのattributeコンポーネントが必要です。

構造型アクセス権限

構造型アクセス権限は、仮想ディレクトリ・ツリーのエントリ全体を対象としています。次に、各構造型アクセス項目権限のリストと説明を示します。

- add (a): 指定より下の場所へのエントリの追加が許可されます。クライアント・アプリケーションがエントリを追加するには、少なくとも各objectclassの必須属性を追加するためのmake属性権限も付与されている必要があります。

- delete (d): エントリ内の既存の属性権限にかかわらず、エントリをDITから削除することが許可されます。

- rename DN (n): エントリの名前の変更または移動が許可されます。

- browse DN (b): エントリの参照が許可されます。付与されている場合、エントリの名前が明示的に指定されていないディレクトリ操作を使用してエントリにアクセスできます。

- return DN (t): エントリのDNをLDAP操作の結果で公開することが許可されます。

新規相対DN(RDN)で名前が変更されるエントリには、rename DNを付与する必要があります。ただし、下位エントリがある場合には、その識別名も間接的に変更されることを考慮する必要があります。エントリ名の変更では、RDN自体の属性など、含まれる属性の前提条件権限は不要です。

さらに、名前の変更を行うには2つの条件があります。(1)上位DNの名前は変更されません(つまり、文字どおりRDNの名前が変更されます)。また、(2)名前の変更によりDNおよびDITの下位項目が移動され、エントリの上位DNが新しくなります(つまり移動されます)。

どのタイプの名前の変更の場合でも、移動されるDNにはrenameDN権限が必要で、(その下に新しいエントリが配置される)ターゲットDNにはaddおよびrenameDNの両方の権限が必要です。

その他の要件で禁止されていないかぎり、ディレクトリのデータを完全に取得できるよう大部分の場所にbrowseDNおよびreturnDNエントリ権限を指定するのが一般的です。同様に、データの変更が必要になる可能性がある場所には、writeおよびobliterate権限の両方を付与するのが一般的です。

コンテンツ・アクセス権限

コンテンツ・アクセス権限は、エントリ属性を対象としています。次に、各コンテンツ・アクセス項目権限のリストと説明を示します。

- read: 読取りまたは検索操作で属性値を読み取ることが許可されます。

- write: 変更操作で属性値を変更または追加することが許可されます。

- obliterate: 変更操作で属性値を削除することが許可されます。

- search: 検索操作で指定した値に関して属性を検索することが許可されます。

- compare: 比較操作で属性を比較することが許可されます。

- make/create: 指定されたエントリよりも下の新規エントリに新しい属性を作成することが許可されます。

make/create属性権限は、エントリの作成時にエントリのすべての属性に必要です。特に、addエントリ権限と関連付けられます。

その他の要件で禁止されていないかぎり、ディレクトリのデータを完全に取得できるよう大部分の場所にsearch、readおよびcompare属性権限を指定するのが一般的です。同様に、データの変更が必要になる可能性がある場所には、writeおよびobliterate権限の両方を付与するのが一般的です。

writeおよびobliterateには追加操作との関連はなく、makeには変更操作との関連はありません。新規エントリが存在しないため、その作成に必要なaddおよびmake権限を新規エントリの親に付与する必要があります。この点は、変更対象のエントリに付与する必要のあるwriteおよびobliterateとは異なります。make権限はwriteおよびobliterate権限とは異なるため、エントリへの新しい子の追加に必要な権限や、同じエントリの既存の子の変更に必要な権限との競合はありません。

変更操作を使用して属性値を置き換えるには、属性に対してエントリのwriteおよびobliterate権限の両方が有効化されている必要があります。

6.3.4.6 アクセス制御のサブジェクト

ACLのサブジェクトで、その適用対象が決定されます。Oracle Virtual Directoryでは、予期される様々なサブジェクト・タイプが利用されます。それによって、ユーザー指定であるかプロキシ・アカウント(binddnなど)からであるかに関係なくクライアント資格証明が使用され、次の条件で適用されます。

図6-3 Oracle Virtual DirectoryのACLサブジェクト

- 特定のDN: クライアントDNの資格証明を、ACL設定に指定した値と比較して一致した場合にACLが適用されます。

- this: 資格証明がアクセス対象のエントリの資格証明と一致するクライアントに適用されます。

- subtree: ACLは、クライアント資格証明の期限が切れた場合、またはサブジェクトで指定されたDNより下に適用されます。

- グループ: subjectコンポーネントによって指定されたDNが検出され、クライアント資格証明がgroupOfUniqueNames、groupOfNames、groupOfUniqueURLsの3つのオブジェクト・クラスのいずれかによって決定されたグループのメンバーである場合にACLが適用されます。最初の2つのタイプのグループによって、ユーザーの静的なリストが指定されます。groupOfUniqueNamesでは、uniquemembers属性がクライアント資格証明に一致している必要があります。groupOfNamesでは、member属性がクライアント資格証明に一致している必要があります。3つ目のグループ・タイプgroupOfUniqueURLsでは、動的グループが処理され、memberurl属性の値によって指定された検索を実行して取得されたDNの少なくとも1つと、クライアント資格証明が一致している必要があります。

- public: 認証されているかどうかにかかわらず、ACLはディレクトリに接続されているすべてのクライアントに適用されます。

- IPアドレス: クライアントIPアドレスを、ACL設定に指定した値と比較して一致した場合にACLが適用されます。

次に、それぞれのACLサブジェクトの注意事項と例を示します。

特定のDN

特定のDNサブジェクトは、プロキシbinddnなどの特定のクライアントに、DITの一部に対するアクセス権を付与または拒否するために使用されます。ユーザーが匿名でバインドすると、サーバーにプロキシ資格証明が送信されるため、プロキシbinddnにDITの機密エントリや属性の表示または変更を許可するのは賢明ではありません。

次に例を示します(binddnがcn=serviceの場合)。

ACL1

ACL2

location

ou=security, o=oracle.com

ou=security, o=oracle.com

scope

サブツリー

サブツリー

rights

deny

deny

permissions

read, search, make, write, obliterate

add, delete, renameDN, browseDN, returnDN

attributes

[all]

[entry]

subject

specificDN=cn=service

specificDN=cn=service

this

thisサブジェクトは、DIT内に配置されている指定された任意のクライアントに、userpassword、postaladdress、telephonenumberなど個人情報の読取りおよび変更の両方を行う権限を付与するために使用されます。通常、一般のpublicにそのようなアクセスを拒否するために、別のACLも使用されます。

次に例を示します。

ACL1

ACL2

ACL3

location

o=oracle.com

o=oracle.com

o=oracle.com

scope

サブツリー

サブツリー

サブツリー

rights

deny

grant

grant

permissions

read, compare

read

write, obliterate

attributes

userpassword

userpassw

userpassword, postaladdress

subject

public

this

this

subtree

subtreeサブジェクトは、クライアント資格証明がDITのサブツリー内のどこからでも検出される場合に便利です。subtreeには、関連性の強いブランチの特権アカウントのみが含まれている場合があります。

次に例を示します。

cn=jbowen, ou=eng_admins, ou=admins, ou=security, o=oracle.com

前にDNのあるadminを認証する必要があります。その他の同じような権限を持つadminsとともにこのadminを認証し、サブツリーを使用するACL実装の例は次のようになります。

ACL1

ACL2

location

o=oracle.com

o=oracle.com

scope

サブツリー

サブツリー

rights

grant

grant

permissions

read, search, make, write, obliterate

add, delete, renameDN, browseDN, returnDN

attributes

[all]

[entry]

subject

subtree=ou=admins, ou=security, o=oracle.com

subtree=ou=admins, ou=security, o=oracle.com

group

groupサブジェクトは、認証を実行するエントリをDIT内のどこで検索すればよいかを指定する際の柔軟性が最も高いため、特定の権限および許可を様々なカテゴリのユーザーに付与する場合に最も多く選択されます。

たとえば、資格証明を持つadminの場合、cn=jbowen, ou=admins, ou=security, o=oracle.comを認証する必要があります。オブジェクト・クラスがgroupOfURLsで属性がmemberURLのGroupサブジェクトを使用してこのadminを認証する、ACLとエントリの組合せの例は次のようになります。

ACL1

ACL2

location

o=oracle.com

o=oracle.com

scope

サブツリー

サブツリー

rights

grant

grant

permissions

read, search, make, write, obliterate

add, delete, renameDN, browseDN, returnDN

attributes

[all]

[entry]

subject

group=ou=sales, ou=depts, o=oracle.com

group=ou=sales, ou=depts, o=oracle.com

グループを指定するオブジェクト・クラスに対して調査されるsubjectコンポーネントのDNは、次のようになります。

dn: ou=sales, ou=depts, o=oracle.com
objectclass: organizationalUnit
objectclass: groupofurls
ou=sales
memberurl: ldap:///ou=admins,ou=security,o=oracle.com?sub?(objectclass=inetOrgPerson)

上のDNでは、memberurl属性によって指定されているLDAP検索には少なくとも、クライアント資格証明を認証する次のDNが含まれます。

dn: cn=jbowen, ou=admins, ou=security, o=oracle.com
objectclass: inetOrgPerson
cn: jbowen
userpassword: xyz123

public

通常grantとともにPublicを使用するACLでは、考えられる最も広い範囲のクライアント・ベースに対してDITへのアクセス権が付与されます。通常、有効範囲がentryの場所[root]に対して実行されます。また、特に有効範囲がentryの別のACLおよび有効範囲がsubtreeのACLが適用されているツリーのベースに対しても実行されます。一般的に、ツリーの特定部分、およびuserpasswordなどの特定の属性がpublicによって表示または変更されるのを制限するために、その他のACLも追加されます。

次に例を示します。

ACL1

ACL2

ACL3

ACL4

location

[root]

[root]

o=oracle.com

o=oracle.com

scope

entry

entry

サブツリー

サブツリー

rights

grant

grant

grant

grant

permissions

search, read

browse, return

search, read

browse, return

attributes

[all]

[entry]

[all]

[entry]

subject

public

public

public

public

IPアドレス

クライアントIPアドレスを、ACL設定に指定した値と比較して一致した場合にACLが適用されます。IPアドレスの値にはIPマスクを使用できます。

次に例を示します。

ACL1

ACL2

location

ou=security, o=oracle.com

ou=security, o=oracle.com

scope

サブツリー

サブツリー

rights

deny

deny

permissions

read, search, make, write, obliterate

add, delete, renameDN, browseDN, returnDN

attributes

[all]

[entry]

subject

specificIP=192.168.1.*

specificIP=192.168.1.*

6.3.5 Oracle Virtual Directoryのアクセス制御リストの適用

次に、Oracle Virtual DirectoryによりACLがどのように適用されるかをまとめます。

1. 調査対象の属性に関連する最初のACLは、一致したACLと呼ばれます。一致したACLは、Oracle Virtual Directoryが順序を下げていくと最も優先度の高い適用を推測し、後続のACLをすべて評価します。

2. 後続のACLに指定された有効範囲がより具体的である場合、つまりDITの階層がより深い場合、またはサブジェクト・タイプがpublicからthisに変更される場合など、一致したACLの適用が変更されるのはいくつかの条件のみです。

3. 一致したACLおよび後続のACLの有効範囲が同一で、いずれかのACLで調査対象の属性に対する権限が拒否されている場合は、Oracle Virtual DirectoryによりACLのアクセスが拒否されます。

4. Oracle Virtual Directoryは、すべてのACLを評価して適用が決定されるまで、リストの最後のACLまで下がりながらリストされているすべてのACLを順番に評価します。

6.4 ウォレットおよび証明書管理の概要

Oracle Virtual Directory 11gリリース1(11.1.1)では、Oracle Enterprise Manager Fusion Middleware Controlを使用してウォレットおよび証明書を管理できます。Oracle Virtual Directoryのウォレットおよび証明書の管理の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

7 Oracle Virtual Directoryのフォルト・トレランスの概要

この章では、Oracle Virtual Directoryのフォルト・トレランスについて説明します。この章の内容は次のとおりです。

- 第7.1項「概要」

- 第7.2項「DNSおよびネットワークのフェイルオーバー」

- 第7.3項「Oracle Virtual Directoryのフェイルオーバー」

- 第7.4項「プロキシ・ソースのフェイルオーバー」

7.1 概要

Oracle Virtual Directoryは、非常に柔軟にフォルト・トレラント設計を実装できます。Oracle Virtual Directoryではデータがローカルに格納されないため、データのコピーを複製し、複数のOracle Virtual Directoryインスタンス全体にデプロイして管理できます。また、Oracle Virtual Directoryの構成ファイルは、適切なストレージ・エリア・ネットワーク(SAN)構成で簡単に複製または共有できます。

Oracle Virtual DirectoryのLDAPアダプタは、複数のソース・ディレクトリのレプリカおよびマスターへの接続を管理するための優れたサポートを提供します。Oracle Virtual Directoryは、複数のディレクトリ・レプリカに問合せの負荷を分散すると同時に、指定したディレクトリ・マスター・サーバーに追加、変更、削除、および名前変更の操作を転送する機能を備えています。

あるソース・ディレクトリにフォルト・トレランスがなく、LDAPクライアント・アプリケーションがすべてのディレクトリを対象とする問合せを発行した場合、LDAP RFCでは、ディレクトリのすべての部分が正しく応答するか、すべての結果が無効になることが必要です。プロキシ・ディレクトリが使用不可にならないかぎり、通常は問題なく作動します。冗長ディレクトリ・リンクのないソースで障害が発生すると、ユーザー・ベースの一部しか影響を受けない場合でも、グローバル問合せがすべてのディレクトリでフェイルオーバーするようになります。Oracle Virtual Directoryを使用すると、個々のプロキシで障害が発生したときの応答や、障害のサービス全体への影響を制御することができます。

多くのシナリオでは、パートナ企業のユーザーがホスト企業のアプリケーションにアクセスできるようにプロキシ・ディレクトリが提供されます。パートナ・ディレクトリがオフラインまたはアクセス不可になると、その企業のユーザーもアプリケーションを使用できないことが多く、障害はアプリケーションにとってクリティカルではないとみなされます。この場合、停止中のサーバー接続を無視するようにOracle Virtual Directoryを構成することで、その他のパートナが作業を続行することができます。

次に、Oracle Virtual Directoryのフェイルオーバーの主な分野のリストを示します。これらの分野については、この章の後続の項で説明します。

- DNSおよびネットワークのフェイルオーバー

- Oracle Virtual Directoryのフェイルオーバー

- プロキシ・ソースのフェイルオーバー

7.2 DNSおよびネットワークのフェイルオーバー

Oracle Virtual Directoryのフォルト・トレランスの実装計画によって異なりますが、クライアントを使用可能なOracle Virtual Directoryシステムにルーティングするためにいくつかの方法を検討することができます。

最も単純な方法は、DNSラウンド・ロビンを定義することです。その場合、DNS管理条件で1つの特定のDNS名が2つのIN Aレコードを持つようになります。こうすることで、特定のアドレスへのリクエストが発生するたびにDNSサーバーが順番のアドレスを割り当てます(たとえば、ldap.corp.comは交互に192.168.0.1および192.168.0.2になります)。この方法は、2つの使用可能なサーバーの間で負荷を分散する場合には便利ですが、いずれかのサーバーが使用不可になるとそれほど有効ではありません。DNSは障害を認識しないため、障害が発生したサーバーのアドレスの番になるたびにクライアントをそのサーバーに送り続けるためです。

Cisco社のLocalDirectorやF5社のBig-IPなどのハードウェア・ロード・バランサを使用することもできます。これらのタイプの製品では、各サーバーのパフォーマンスが監視されて、本来のロード・バランシングが提供されます。この分野には価格や機能の異なる多くの製品があります。

もう1つの方法として、クラスタ内の障害が発生したノードのIPアドレスを切り替えられるクラスタ構成(Veritasなど)を使用することもできます。

7.3 Oracle Virtual Directoryのフェイルオーバー

Oracle Virtual Directoryシステムのフェイルオーバーは、ローカル・ストア・アダプタを使用していないかぎり比較的容易です。Oracle Virtual Directoryでは、起動時にのみ読み取られる構成ファイルが使用されます。理論上は、同じ構成データを読み取る2つのサーバーは同じ機能を自動的に実行します。

7.3.1 ローカル・ストア・アダプタのフェイルオーバー

ローカル・ストア・アダプタを使用するときは、その他の問題、特にレプリケーションについても考慮する必要があります。レプリケーションは、ローカル・データ・ストアの変更を反映するように1つのノードが別のノードを更新するプロセスです。

注意:
Oracle Virtual Directoryはレプリケーション・プロセスを提供しません。Oracle Virtual Directoryは仮想サーバーであるため、バックエンド・ソースの高可用性はOracle Virtual Directory自体の範囲を超えています。

- LDAPアダプタを使用している場合、LDAPディレクトリはレプリケートされ(必要な場合)、Oracle Virtual DirectoryアダプタでLDAPホストとして提供することができます。

- ローカル・ストア・アダプタを使用している場合、ローカル・ストア・アダプタに格納されているデータを、Oracle Virtual Directoryサーバーから別のサーバーにコピーするのにoidcmprecツールを使用できます。oidcmprecツールの詳細は、第2.4.1項「ローカル・ストア・アダプタ・データの移行」を参照してください。

ローカル・ストア・アダプタを使用している場合は、クラスタ・ノード間で(および、場合によっては他の非クラスタ・ノード間でも)レプリケーション承諾を設定する必要があります。レプリケーションが構成されると、1つのノードが1次ノードになり、もう一方のノードは1次ノードの下位ノードになります。たとえば、ノード1がプライマリ、ノード2が下位になります。この構成では、両方のノードは同等に機能しますが、書込みを処理できるのはノード1のみです。処理が終了すると、ノード1が自動的にノード2を更新します。

障害に備えて、適切なアクションを実行するようにクラスタ障害の処理スクリプトを構成する必要があります。ノード2で障害が発生した場合、ノード2の復帰時にレプリケーションが再開されるのであれば何も影響はありません。反対にノード1で障害が発生した場合は、ノード2をプライマリにして、ノード1がなくてもノード2で書込み処理を続行できるようにする必要があります。ノード1が稼働できる状態に戻る前に、レプリケーション承諾を逆方向にする必要があります。

7.4 プロキシ・ソースのフェイルオーバー

Oracle Virtual DirectoryのLDAPアダプタは、すべてのLDAP準拠データ・リポジトリに対して、高機能のフェイルオーバーおよびロード・バランシング管理を提供します。どのプロキシ・ソースまたはアダプタについても、複数のリモート・ホスト・レプリカを定義して、次の特徴を指定できます。

- 読取り/書込みまたは読取り専用(マスター・ノードまたはレプリカ・ノード)

- 負荷分散のパーセンテージまたは障害時のみの切替え

図7-1に、Oracle Virtual DirectoryのLDAPアダプタで、トランザクション・ロード・バランシングがどのように実行されるかの例を示します。

図7-1 Oracle Virtual DirectoryのLDAPアダプタとトランザクション・ロード・バランシング

Oracle Virtual Directoryには構成可能な接続処理設定があり、次の項目を指定できます。

- ハートビート間隔: Oracle Virtual Directoryがプロキシのオンライン・ステータスを確認する間隔。ハートビート間隔は、サーバーの可用性を継続して確認します。プロキシがオフラインになると、Oracle Virtual Directoryはアクティブ・サーバーのリストからそのプロキシを自動的に削除し、その他の定義済レプリカに負荷を分散させます。サーバーが再び使用可能になったことがハートビート間隔で確認されると、サーバーは使用可能リストに戻されます。

- タイムアウト時間: 接続に障害が発生したことを判別するまでOracle Virtual Directoryが待機する時間(ミリ秒単位)。接続で障害が発生すると、Oracle Virtual Directoryはレプリカ・リストの次のサーバーを自動的に試行します。応答するプロキシ・サーバーがない場合、LDAPクライアントがDSA使用不可というエラーを受け取ります。

- 重大性: プロキシの結果が問合せ全体に対して重大であることをOracle Virtual Directoryが判別する方法。問合せが複数のアダプタからのレスポンスを必要とする場合、いずれかのソースが使用不可になっており(すべてのアダプタを問合せできないため)、それらが「重要性」と指定されていると、Oracle Virtual Directoryがエラーで応答します。場合によっては、一部のサーバーしか問合せできないときでもOracle Virtual Directoryからの結果を必要とすることがあります。Oracle Virtual Directoryで部分的な結果を戻すようにするには、結果を得られなくてもよいアダプタを「重要ではない」に設定します。

第II部

基本的な管理

ここでは、Oracle Virtual Directoryに対する基本的な管理タスクの実行について説明します。内容は次のとおりです。

- 第8章「Oracle Virtual Directoryの管理の開始」

- 第9章「Oracle Virtual Directoryサーバーの構成と管理」

- 第10章「Oracle Virtual Directoryサーバー・プロセスの管理」

- 第11章「Oracle Virtual Directoryリスナーの作成および管理」

- 第12章「Oracle Virtual Directoryのアダプタの作成および構成」

- 第13章「Oracle Virtual Directoryのプラグインの管理」

- 第14章「Oracle Virtual Directoryのマッピングの管理」

- 第15章「Oracle Virtual Directoryのエントリおよびスキーマの管理」

- 第16章「Oracle Virtual Directoryのアクセス制御の構成」

- 第17章「Oracle Virtual Directoryのロギングと監査の管理」

8 Oracle Virtual Directoryの管理の開始

Oracle Virtual Directoryは、グラフィカル・ユーザー・インタフェースとコマンドライン・インタフェースのどちらからでも管理できます。この章では、Oracle Virtual Directoryのそれらの管理インタフェース、およびOracle Virtual Directoryの起動と停止の方法について説明します。

注意:
この章では、Oracle Virtual Directoryが『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従ってインストールおよび構成されていることを前提としています。

この章では、次の項目について説明します。

- 第8.1項「11gリリース1 (11.1.1)のインストール後の作業」

- 第8.2項「Oracle Virtual Directoryの構成および管理の基本的なタスク」

- 第8.3項「Oracle Directory Services Managerの開始」

- 第8.4項「Fusion Middleware Controlの開始」

- 第8.5項「WLSTを使用したOracle Virtual Directoryの管理の開始」

- 第8.6項「LDAPツールの使用」

8.1 11gリリース1(11.1.1)のインストール後の作業

11gリリース1(11.1.1)のインストールが終了したら、次の作業を行うことをお薦めします。

- 付録A「Oracle Virtual Directory 11gリリース1(11.1.1)と10gリリース(10.1.4.x)の比較」を確認し、11gリリース1(11.1.1)と以前のOracle Virtual Directory 10gリリース(10.1.4.x)との基本アイテムの実装方法の違いを理解する。

- 付録B「Oracleスタックの起動と停止」を確認し、11gリリース1(11.1.1)でのOracleスタックのコンポーネントの起動および停止方法を理解する。

- 表8-1を確認し、11g Release 1(11.1.1)でのOracle Virtual Directoryの管理に使用できる様々なインタフェースのデフォルトURLを理解する。

表8-1 管理インタフェースのデフォルトURL

インタフェース

デフォルトURL

Oracle Directory Services Manager

http://host:7005/odsm/

Fusion Middleware Control

http://host:7001/em/

Oracle WebLogic Server管理コンソール

http://host:7001/console/

- 表8-2を確認し、11gリリース1(11.1.1)でのOracle Virtual Directoryの様々なデフォルト・ポートを理解する。

表8-2 デフォルト・ポート

ポート・タイプ

デフォルト・ポート

LDAP

6501

LDAPS

7501

管理ポート(HTTPS)

8899

- 表8-3を確認し、Oracle Virtual Directory 11gリリース1(11.1.1)の様々な環境変数を理解する。

表8-3 環境変数

変数

説明

ORACLE_HOME

Oracle Identity Managementインストールの書込み不可能ファイルの格納場所。

ORACLE_INSTANCE

Oracle Identity Managementインストールの書込み可能ファイルの格納場所。

PATH

PATHには次のディレクトリの場所を追加します。

- $ORACLE_HOME/bin

- $ORACLE_HOME/ldap/bin

- $ORACLE_INSTANCE/bin

8.2 Oracle Virtual Directoryの構成および管理の基本的なタスク

次に、基本的なOracle Virtual Directory環境の構成および管理に一般的に使用される手順の概要を示します。

1. 使用環境に固有になるように設定をカスタマイズしてOracle Virtual Directoryサーバーを構成します。詳細は次の項目を参照してください。

- Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーのプロパティの構成

- WLSTを使用したOracle Virtual Directoryサーバーの設定の構成

2. ターゲット・データ・リポジトリに、アダプタを作成および構成します。詳細は次の項目を参照してください。

- 第2章「Oracle Virtual Directoryのアダプタの概要」

- 第12章「Oracle Virtual Directoryのアダプタの作成および構成」

3. 環境に合せてプラグインを構成します。詳細は次の項目を参照してください。

- 第4章「Oracle Virtual Directoryのプラグインの概要」

- 第13章「Oracle Virtual Directoryのプラグインの管理」

4. Oracle Virtual Directoryのアクセス制御リストを構成します。詳細は次の項目を参照してください。

- Oracle Virtual Directoryのアクセス制御の概要

- 第16章「Oracle Virtual Directoryのアクセス制御の構成」

8.3 Oracle Directory Services Managerの開始

この項では、Oracle Virtual Directoryとともに使用するOracle Directory Services Managerインタフェースの設定方法について説明します。この項の内容は次のとおりです。

- Oracle Directory Services Managerの概要

- SSO統合の構成

- Oracle Directory Services Managerの統合のためのSSOサーバーの構成

- ODSM-SSO統合用Oracle HTTP Serverの構成

- Oracle Directory Services Managerの起動

- Oracle Directory Services Managerからサーバーへの接続

- Oracle Directory Services Managerのキー・ストアの管理

- Oracle Directory Services Managerセッション・タイムアウトの構成

- Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成

8.3.1 Oracle Directory Services Managerの概要

Oracle Directory Services Managerは、Oracle Virtual DirectoryおよびOracle Internet Directory用の統合されたブラウザベースのグラフィカル・ユーザー・インタフェース(GUI)です。Oracle Directory Services Managerを使用すると、Webベースのフォームとテンプレートを使用できるため、Oracle Virtual DirectoryとOracle Internet Directoryの管理および構成が簡略化されます。

注意:
Oracle Directory Services Managerの管理者アクセスを持つユーザー(通常はcn=orcladmin)のみがOracle Directory Services Managerにログインできます。

8.3.1.1 サポートされているブラウザ

Fusion Middleware ControlおよびOracle Directory Services Managerに対してサポートされているブラウザの詳細は、次のサイトにあるOracle JDeveloperおよびApplication Development Framework 11gの動作保証およびサポートのマトリクスを参照してください。

http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xls

8.3.1.2 Oracle Directory Services ManagerでのJAWSスクリーン・リーダーの使用

Oracle Directory Services ManagerとともにJAWSを使用していて、新しいウィンドウが表示された場合は、JAWSが「ポップアップ」と読み上げます。ページ全体を読み取るには、[Insert]キーを押しながら[b]キーを押します。

8.3.1.3 Oracle Directory Services Managerとシングル・サインオンの統合の概要

シングル・サインオン(SSO)を使用するようにOracle Directory Services Managerを構成できます。SSOを使用するように構成すると、SSOサーバーによって認証済のユーザーがSSO対応ディレクトリを管理する権限を持っている場合、ユーザーはログインせずにそのディレクトリに接続できるようになります。

Oracle Directory Services Managerは、SSO認証済ユーザーが管理できるOracle Virtual Directoryサーバーのリストを維持します。SSO認証済ユーザーがOracle Virtual Directoryを管理するために必要な権限を持っているかどうかを検証するために、Oracle Directory Services Managerは、SSO認証済ユーザーをOracle Virtual Directoryサーバーでの識別名にマップします。

Oracle Directory Services Managerは、プロキシ認証を使用してディレクトリに接続します。プロキシ・ユーザーの識別名およびパスワードは、資格証明ストア・フレームワーク(CSF)と呼ばれるセキュアなストレージ・フレームワークに格納されます。

SSO認証済ユーザーをマップするために、Oracle Directory Services Managerは、プロキシ権限を持つユーザーの資格証明を使用して、Oracle Virtual Directoryサーバーに対して認証します。次に、Oracle Directory Services ManagerはSSO認証済ユーザーの一意識別子をOracle Virtual Directoryユーザーの一意識別子にマップしようとします。

WLS管理者は、プロキシ・ユーザーの資格証明、一意の識別子属性、およびOracle Directory Services ManagerがCSFに格納されているユーザーを検索するベース識別名を構成します。Oracle Directory Services Managerは、有効な識別名を取得すると、SSO認証済ユーザーをその識別名にマップします。SSO認証済ユーザーが有効な識別名にマップされると、Oracle Directory Services Managerは、プロキシ認証を使用して、SSO認証済ユーザーのマップされた識別名でOracle Virtual Directoryサーバーに接続します。

注意:
SSO認証済ユーザーは、Oracle Virtual Directoryを管理するにはOracle Virtual Directoryの管理グループのメンバーである必要があります。ユーザーは有効なDNを持っていても管理グループのメンバーでなればOracle Virtual Directoryを管理できません。
Oracle Directory Services ManagerがユーザーのDNを検索するコンテナDNは、Oracle Virtual Directoryで構成されたいずれかのアダプタのものになります。

「SSO統合の構成」の説明に従ってOracle Directory Services Managerプロキシのバインド構成画面を使用して、プロキシID、参照属性、ユーザー・コンテナ、およびその他の情報を構成します。

8.3.2 SSO統合の構成

Oracle Directory Services ManagerとSSOの統合を構成するには、http://host:port/odsm-configのOracle Directory Services Managerプロキシのバインド構成画面を使用します。WebLogic管理者としてログインします。

この画面で、SSOユーザーが管理できるディレクトリ・サーバーのセットをOracle Directory Services Managerに提供します。この画面には、シングル・サインオンによりアクセス可能なディレクトリが示されます。

「表示」リストを使用して、列の数および順序を変更します。既存のディレクトリを削除するには、「削除」をクリックします。

既存のディレクトリを変更するには、「変更」をクリックします。

シングル・サインオンによりアクセス可能なディレクトリを新たに追加するには、「追加」をクリックします。

「変更」または「追加」をクリックすると、「ディレクトリ詳細」画面が表示されます。次の手順を実行します。

1. 「ポート・タイプ」リストから「非SSL」または「SSL」を選択します。

2. 「ディレクトリ・タイプ」リストから「OID」または「OVD」を選択します。

3. 次の情報を指定します。

- ディレクトリのホストおよびポート。

- プロキシ・ユーザーのDNおよびパスワード: Oracle Directory Services Managerがプロキシ認証に使用する識別名およびパスワード。

- ユーザー・コンテナDN: ディレクトリでユーザー・エントリが配置される識別名。

- ユーザー参照属性: ディレクトリ内のユーザーの識別名を参照するための一意属性。たとえば、SSOサーバーがユーザーのメールIDをそのユーザーの一意識別子としてOracle Directory Services Managerに送信した場合、mailをユーザー参照属性として構成できます。

4. 「検証」をクリックして、ディレクトリ接続の詳細を検証します。
Oracle Directory Services Managerは、提供された資格証明を使用してディレクトリ・サーバーに対して認証します。

5. 「適用」をクリックして選択内容を適用します。
選択を中止する場合は、「元に戻す」をクリックします。

6. 「SSOログアウトURL」テキスト・ボックスでSSOサーバーの「ログアウトURL」を指定します。
たとえば、http://myoamhost.mycompany.com:14100/oam/server/logoutは、Oracle Access Manager 11gサーバーのデフォルトのログアウトURLです。このフィールドのみを構成した場合、Oracle Directory Services Managerにより、Oracle Directory Services Managerページの右上の隅に「ログイン」リンクが表示されます。

8.3.3 Oracle Directory Services Managerの統合のためのSSOサーバーの構成

SSOとOracle Directory Services Managerとの統合作業を適切に実行するには、特定のOracle Directory Services ManagerのURLを保護または非保護として構成する必要があります。

Oracle Directory Services Managerホーム・ページは非保護URLにする必要があります。つまり、SSO認証プロセスを通過できないユーザーを含めてすべてのユーザーがOracle Directory Services Managerホーム・ページにアクセスできることが必要です。

URL /odsm/odsm-sso.jspは、SSOサーバーによって保護されている必要があります。ユーザーがホーム・ページの右上の隅に表示される「ログイン」リンクをクリックすると、ユーザーは/odsm/odsm-sso.jspにリダイレクトされます。SSOサーバーは、そのユーザーがまだ認証されていない場合、ユーザーのユーザー名およびパスワードを調べます。認証に成功すると、ユーザーはOracle Directory Services Managerホーム・ページに戻されます。

Oracle Directory Services ManagerのURLは次のように構成します。

- 保護: /odsm/odsm-sso.jsp

- 非保護: /odsm/faces/odsm.jspx

- 除外: /odsm/.../

CSS、JavaScriptおよびグラフィック(/odsm/.../)ファイルを除外に設定すると、これらのファイルがOracle Access Managerによって検証されなくなり、デプロイメントのパフォーマンスを改善できます。

Oracle Access Manager 11gまたはOracle Access Manager 10gをSSOプロバイダとして使用できます。

Oracle Access Manager 11gを構成するには、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

SSO認証済ユーザーの一意識別子をHTTPヘッダーを介してOracle Directory Services Managerに送信するようにOracle Access Managerサーバーを構成する必要があります。Oracle Directory Services ManagerはOAM_REMOTE_USER HTTPヘッダーを探します。Oracle Access Managerサーバーは、デフォルトでOAM_REMOTE_USERヘッダーを設定します。このヘッダーを使用できない場合、Oracle Directory Services Managerはodsm-sso-user-unique-id HTTPヘッダーを探します。Oracle Directory Services Managerがこれらのヘッダーのいずれも見つけることができない場合、Oracle Directory Services Manager SSO統合は機能しません。

ユーザーの一意識別子をHTTPヘッダーを介して送信する以外に、オプションで、次のHTTPヘッダーを送信するようにOracle Access Managerを構成できます。

- ユーザーの名を送信するようにodsm-sso-user-firstname HTTPヘッダーを構成します。

- ユーザーの姓を送信するようにodsm-sso-user-lastname HTTPヘッダーを構成します。

これらのヘッダーが使用可能な場合、ユーザーの名および姓がOracle Directory Services Managerの右上の隅にある「次としてログイン」セクションに表示されます。名または姓を使用できない場合は、ユーザーの一意識別子が「次としてログイン」セクションに表示されます。

8.3.4 ODSM-SSO統合用のOracle HTTP Serverの構成

Oracle HTTP Serverを、SSOサーバーのWebGateエージェントをホストするために使用し、かつOracle Directory Services ManagerをホストするWebLogicサーバーへのフロント・エンドとして使用している場合、Oracle Directory Services ManagerをホストしているWebLogicサーバーに/odsmで始まるすべてのリクエストを転送するようにOracle HTTP Serverのmod_wl_ohsモジュールを構成する必要があります。mod_wl_ohsモジュールにより、Oracle HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理できます。

mod_wl_ohsを構成するには、『Oracle HTTP Server管理者ガイド』のWebLogicプロキシ・プラグイン(mod_wl_oh)の構成に関する項を参照してください。

8.3.5 Oracle Directory Services Managerの起動

Oracle Directory Services Managerの起動は、直接、またはOracle Enterprise Manager Fusion Middleware Controlから実行できます。

注意:

- Oracle Virtual Directoryのインストール時にドメインを要求されたときに「ドメインなしで構成」を選択した場合、Oracle Directory Services Managerは使用できなくなります。

- Fusion Middleware ControlおよびOracle Directory Services Managerでサポートされているブラウザの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlからリンクされている、Oracle Fusion Middleware 11gR1のシステム要件およびサポートされているプラットフォームに関する説明を参照してください

- Oracle Directory Services Managerを直接起動するには、ブラウザのアドレス・フィールドに次のURLを入力します。

http://host:port/odsm

Oracle Directory Services ManagerにアクセスするURLでは、次のようになっています。

- hostは、Oracle Directory Services Managerが実行されている管理対象サーバーの名前です。

- portは、WebLogicサーバーの管理対象サーバーのポート番号です。

正確なポート番号は、$Fusion_Middleware_Home/Oracle_Identity_Management_domain/servers/wls_ods/data/nodemanager/wls_ods1.urlファイル( Fusion_Middleware_HomeはFusion Middlewareがインストールされているルート・ディレクトリ)で確認できます。

- Fusion Middleware ControlからOracle Directory Services Managerを起動するには、Oracle Virtual Directoryターゲットの「Oracle Virtual Directory」メニューから「Directory Services Manager」を選択し、「データ・ブラウザ」、「スキーマ」、「セキュリティ」、または「拡張」を選択します。(同じ方法で「Oracle Internet Directory」メニューから接続できます。)
ブラウザ・ウィンドウが新たに起動され「Oracle Directory Services Managerへようこそ」画面が表示されます。次の項の説明に従って、サーバーに接続します。

関連項目:
付録D「Oracle Virtual Directoryのトラブルシューティング」の「Oracle Directory Services Managerを起動できない」

8.3.6 Oracle Directory Services Managerからサーバーへの接続

Oracle Directory Services Managerの「ようこそ」画面が表示されたら、Oracle Virtual DirectoryサーバーまたはOracle Internet Directoryサーバーに接続できます。

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

- Oracle Directory Services Managerからのディレクトリ・サーバーへのログイン

- SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン

- SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続

注意:
Oracle Directory Services Managerからディレクトリ・サーバーに接続する場合は、次の事項に注意してください。

- Oracle Directory Services Managerからディレクトリ・サーバーに接続するには、ディレクトリ・サーバーが稼働している必要があります。

- Oracle Directory Services Managerの管理者アクセスを持つユーザー(通常はcn=orcladmin)のみがOracle Directory Services Managerにログインできます。

- 同じブラウザ・プログラムの複数のウィンドウを使用して異なるディレクトリに同時に接続することは避けてください。これを行うことによって、Target unreachableエラーが発生する場合があります。

- Internet ExplorerやFirefoxなどの異なるブラウザ・プログラムから、同じOracle Directory Services Managerコンポーネントを使用して、異なるディレクトリ・システム・コンポーネントに接続できます。

- ブラウザの言語設定を変更した場合は、新しい設定を使用するためにそのセッションを更新する必要があります。セッションを更新するには、「URL」フィールドにOracle Directory Services ManagerのURLを再入力して[Enter]を押すか、ブラウザを終了して再起動します。

8.3.6.1 Oracle Directory Services Managerからディレクトリ・サーバーへのログイン

次のようにしてOracle Directory Services Managerからディレクトリ・サーバーの非SSLポートにログインします。

1. Oracle Directory Services Managerの「ようこそ」画面の最上部にある「ディレクトリに接続」をクリックし、次のセクションが含まれているダイアログ・ボックスを開きます。

- ライブ接続: 戻ることのできる現在の接続。

- 切断されている接続: 一度接続した後、切断したディレクトリ・サーバーのリスト。Oracle Directory Services Managerでは、以前に使用した接続に関する情報を保存し、オプション名別またはサーバー別にリストし、その接続を再選択できるようにします。

注意:
接続情報が変更された場合(たとえば、サーバーのポート番号が変更された場合)は、Oracle Directory Services Managerの接続情報が不正確になり、接続に失敗します。接続情報は編集できないため、リストから接続を削除してから、新たに接続を作成する必要があります。

- 新規接続: 新規接続の開始に使用されます。

SSO認証済であるユーザーには、追加セクションが表示される場合があります。詳細は、「SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続」を参照してください。

2. 「OID」または「OVD」を選択します。

3. この接続を識別できるように、オプションで「名前」フィールドに別名を入力します。この名前は、現行のOracle Directory Services Managerセッションの終了後にライブ接続のリスト(手順1を参照)に表示され、即座に再接続できます。

4. 「名前」フィールドに、Oracle Internet DirectoryまたはOracle Virtual Directoryが稼働しているサーバーの名前を入力します。

5. 「ポート」フィールドに、非SSLポートを入力します。Oracle Virtual Directoryの場合は、管理リスナーの非SSLポートを入力します。Oracle Internet Directoryの場合は、非SSL LDAPポートを入力します。

6. 「SSL有効」の選択を解除します。

7. Oracle Directory Services Manager管理者アクセス(通常はcn=orcladmin)を持つユーザーの名前とパスワードを入力します。

8. ログイン後に移動する「開始ページ」を選択します。

9. 「接続」をクリックします。

Oracle Internet DirectoryまたはOracle Virtual Directoryサーバーにログインしたら、ナビゲーション・タブを使用して別のページを選択できます。

Oracle Internet DirectoryおよびOracle Virtual Directory用のOracle Directory Services Managerのホームページには、ディレクトリとアダプタのみでなく、Oracle Directory Services Manager自体のバージョン情報もリストされています。また、Oracle Virtual Directoryの既存の構成済アダプタおよびリスナーもリストされます。

関連項目:
付録D「Oracle Virtual Directoryのトラブルシューティング」の「Oracle Directory Services Managerを起動できない」

8.3.6.2 SSLを使用したOracle Directory Services Managerからディレクトリ・サーバーへのログイン

サーバーのSSLポートにログインする場合は、手順4でSSLポートを指定していて手順6で「SSL有効」を選択している場合を除き、「Oracle Directory Services Managerからディレクトリ・サーバーへのログイン」の手順に従ってください。具体的にはOracle Virtual Directoryの管理リスナーのSSLポートを入力するか、Oracle Internet DirectoryのSSL LDAPポートを入力します。手順9で「接続」をクリックした後、SSL認証のタイプによっては証明書が提示される場合があります。次の項では、サポートされているSSL認証タイプごとの証明書の処理について説明します。

- SSL認証なし

- SSLサーバーのみ認証

8.3.6.2.1 SSL認証なし

ディレクトリ・サーバーがSSL認証なしモードで稼働している場合、証明書は提示されません。SSL認証なしモードでは、データの機密性と整合性が保証されますが、X.509証明書を使用した認証は行われません。

8.3.6.2.2 SSLサーバーのみ認証

ディレクトリ・サーバーがSSLサーバー認証専用モード(Oracle Virtual Directoryのデフォルト)を使用している場合、手順9で「接続」をクリックしたときにサーバーの証明書が提示されます。サーバーの証明書の信憑性を手動で検証したら、証明書を永続的に受け入れるか、現行のセッションでのみ受け入れるか、または却下することができます。証明書を永続的に受け入れる場合、証明書はOracle Directory Services ManagerのJavaキー・ストア(JKS)に保管されます。それ以降、この特定のOracle Directory Services Manager URLを使用してそのサーバーに接続するときに、証明書の受け入れを求められることはありません。現在のセッションに対してのみ受け入れた場合、サーバーに接続するたびに証明書を受け入れるか拒否するかを確認されます。証明書を却下すると、Oracle Directory Services Managerはこのサーバーへの接続を閉じます。

詳細は、「Oracle Directory Services Managerのキー・ストアの管理」を参照してください。

8.3.6.3 SSO認証済ユーザーとしてのSSO対応ディレクトリへの接続

シングル・サインオン・サーバーによってすでに認証されている場合、Oracle Directory Services Managerでは、SSO対応ディレクトリにエントリを持っている場合は、ログインせずにそのディレクトリに接続できます。Oracle Directory Services Managerの「ようこそ」ページにアクセスすると、エントリを持っているSSO対応ディレクトリが1つのみであればOracle Directory Services Managerによってそれに接続されます。複数のSSO対応ディレクトリにエントリを持っている場合は、Oracle Directory Services Managerで接続するディレクトリを次のように選択できます。

ラベル「クリックしてディレクトリに接続」の右にある小さな矢印をクリックします。この場合、ダイアログ・ボックスには、接続する権限があるSSO対応ディレクトリがリストされた追加のセクションが表示されます。必要なディレクトリを選択します。Oracle Directory Services Managerによってユーザー名やパスワードを要求されることなく接続されます。

接続しているポートがSSLポートである場合は、「SSL認証なし」または「SSLサーバーのみ認証」の適切な手順を実行する必要があります。

注意:
SSO認証済ユーザーは、Oracle Virtual Directoryを管理するにはOracle Virtual Directoryの管理グループのメンバーである必要があります。ユーザーは有効なDNを持っていても管理グループのメンバーでなればOracle Virtual Directoryを管理できません。
Oracle Directory Services ManagerがユーザーのDNを検索するコンテナDNは、Oracle Virtual Directoryで構成されたいずれかのアダプタのものになります。

8.3.7 Oracle Directory Services Managerのキー・ストアの管理

Oracle Directory Services Managerは、Oracleによるセキュアな格納フレームワークである資格証明ストア・フレームワークと統合されています。この項では、Oracle Directory Services Managerを使用した資格証明の管理方法について説明します。この項の内容は次のとおりです。

- Oracle Directory Services Managerのキー・ストアの概要

- Oracle Directory Services ManagerのJavaキー・ストア・パスワードの取得

- odsm.cer Javaキーストアの内容のリスト

- 期限が切れた証明書の管理

- 信頼できる証明書の削除

8.3.7.1 Oracle Directory Services Managerのキー・ストアの概要

Oracle Directory Services Managerは、Javaキー・ストア(JKS)を使用してその秘密鍵、証明書、および信頼できる証明書を管理します。Oracle Directory Services Managerを初めて使用するときに、プログラムによってodsm.cerというJavaキー・ストア・ファイルが作成され、そのJKSにランダムなパスワードが割り当てられます。このJKSファイルは、次の書式の名前のディレクトリに置かれます。

DOMAIN_HOME/config/fmwconfig/servers/AdminServer/applications/odsm/conf

Oracle Directory Services Managerは、このランダム・パスワードを資格証明ストア・フレームワークに保管します。WebLogicサーバー管理者は、資格証明ストア・フレームワークに保管されているJavaキー・ストア・パスワードを取得できます。

Oracle Directory Services Managerは、独力で自己署名付きの証明書も生成し、Javaキー・ストアに保管します。自己署名証明書は、生成日から15000日間有効であり、テストのためにのみ使用します。本番用としては、自己署名証明書を、認証局(CA)によって署名された証明書に置き換えることをお薦めします。

Oracle Directory Services Managerには、キーストアを管理するためのWebベースのユーザー・インタフェースは用意されていません。このキー・ストアは、SunのJRE/JDKに用意されているコマンドライン・ツールであるkeytoolを使用して管理する必要があります。

注意:
Oracle Directory Services Managerを使用するとき、Oracle Directory Services ManagerおよびOracle Virtual Directoryサーバーが同じJDKメジャー・バージョンであること、または、Oracle Virtual DirectoryがOracle Directory Services Managerよりも上位のJavaバージョンを使用していることを確認する必要があります。

関連項目:
詳細は、次の公開資料を参照してください。

- 資格証明ストア・フレームワークの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

- JavaTM暗号化アーキテクチャAPI仕様およびリファレンスについては、http://java.sun.comを参照してください。

- keytool(キーおよび証明書管理ツール)の詳細は、http://java.sun.comを参照してください。

8.3.7.2 Oracle Directory Services ManagerのJavaキー・ストア・パスワードの取得

Oracle Directory Services ManagerのJavaキー・ストアを管理するには、まずOracle Directory Services ManagerのJavaキー・ストア・パスワードを取得する必要があります。このパスワードを取得するには2つの方法があります。

- Enterprise Manager Fusion Middleware Controlの使用

- Pythonスクリプトの使用

8.3.7.2.1 Enterprise Manager Fusion Middleware Controlの使用

Enterprise Managerを使用してOracle Directory Services ManagerのJavaキー・ストア・パスワードを取得するには、次の手順を実行します。

1. weblogic administratorとしてEnterprise Managerに接続します。

2. Enterprise Managerのナビゲーション・パネルの左側で、「WebLogicドメイン」を拡張し、Oracle Directory Services Managerがデプロイされているドメインを選択します。

3. Enterprise Managerのナビゲーション・パネルの右側で、「WebLogicドメイン」メニューをクリックし、「システムMBeanブラウザ」を選択します。

4. システムMBeanブラウザで、「アプリケーション定義のMBean」→「com.oracle.jps」→「ドメイン」 : 「NameOfTheDomainWhereODSMisDeployed」→「JPSCredentialStore」→JPSCredentialストアを開きます。

5. 詳細ペインに表示される「操作」タブをクリックします。

6. 次の図に示されているように、getPortableCredential操作をクリックします。

図8-1 getPortableCredential操作

7. 次のページで、getPortableCredentialメソッドのパラメータを入力する必要があります。

- P1には、ODSMMapを入力します。

- P2には、ODSMKey.Walletを入力します。

8. 「起動」ボタンをクリックします。
次の図に示されるように、「戻り値」表は「パラメータ」表の下に表示されます。Oracle Directory Services ManagerのJavaキー・ストア・パスワードは、「パスワード」フィールドに表示されます。

図8-2 getPortableCredential操作

8.3.7.2.2 Pythonスクリプトの使用

Enterprise Managerがない場合は、Pythonスクリプトを使用してOracle Directory Services ManagerのJavaキー・ストア・パスワードを取得できます。

パスワードを取得するには、次の手順を実行します。

1. 次の内容で.pyファイル(たとえば、odsm.py)を作成します。

import sys,getopt
from oracle.security.jps.mas.mgmt.jmx.credstore import PortableCredential
connect(sys.argv[1], sys.argv[2], sys.argv[3])
domainRuntime()
params= ["ODSMMap", "ODSMKey.Wallet"]
sign=["java.lang.String", "java.lang.String"]
on=ObjectName("com.oracle.jps:type=JpsCredentialStore")
cred = None
cred = mbs.invoke(on, "getPortableCredential", params, sign)
if cred != None:
credObject = PortableCredential.from(cred)
print credObject
print "ODSM Java Key Store Password: " + String.valueOf(credObject.getPassword())

2. 次のコマンドを実行します。

$MW_HOME/oracle_common/common/bin/wlst.sh odsm.py <wls_admin_user>
<wls_admin_password> t3://<adminserver_host>:<adminserver_port>

次に例を示します。

$MW_HOME/oracle_common/common/bin/wlst.sh odsm.py weblogic welcome1
t3://myadminserver:7001

このスクリプトを実行すると、ルートとしてDomainMBeanを指定する、読取り専用のdomainRuntimeツリーに出力先が変更されます。

注意:
ヘルプを表示するには、コマンド・ラインでhelp(domainRuntime)と入力します。

[Name : ODSM, Description : ODSM Key store password, expiry Date : null]
ODSM Java Key Store Password: XXXXXXXXXX

関連項目:
詳細は、次の公開資料を参照してください。

- Oracle Platform Security Servicesによるアプリケーションの保護

- Oracle Platform Security Services MBeans Java APIリファレンス

8.3.7.3 odsm.cer Javaキーストアの内容のリスト

Javaキー・ストア・パスワードを取得したら、keytoolコマンドを使用してそれを管理できます。

odsm.cerの内容をリストする手順は、次のとおりです。

1. odsm.cerが含まれるディレクトリに移動(cd)します。次に例を示します。

cd DOMAIN/config/fmwconfig/servers/AdminServer/applications/odsm/conf

2. keytoolを使用して、odsm.cerの内容を表示します。次に例を示します。

ORACLE_HOME/jdk/jre/bin/keytool -list -keystore odsm.cer \
-storepass "&M)S86)/RB" -v

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: serverselfsigned
Creation date: Dec 26, 2008
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California, C=US
Issuer: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California, C=US
Serial number: 495586b6
Valid from: Fri Dec 26 17:36:54 PST 2008 until: Wed Jun 24 18:36:54 PDT 2009
Certificate fingerprints:
MD5:  6C:11:16:F3:88:8D:18:67:35:1E:16:5B:3E:03:8A:93
SHA1: F4:91:39:AE:8B:AC:46:B8:5D:CB:D9:A4:65:BE:D2:75:08:17:DF:D0
Signature algorithm name: SHA1withRSA         Version: 3

*******************************************
*******************************************

Alias name: cn=rootca, o=oracle, c=us (0)
Creation date: Dec 31, 2008
Entry type: trustedCertEntry

Owner: CN=RootCA, O=Oracle, C=US
Issuer: CN=RootCA, O=Oracle, C=US
Serial number: 0
Valid from: Tue Dec 30 02:33:11 PST 2008 until: Mon Jan 24 02:33:11 PST 2050
Certificate fingerprints:
MD5:  72:31:7B:24:C9:72:E3:90:37:38:68:40:79:D1:0B:4B
SHA1: D2:17:84:1E:19:23:02:05:61:42:A9:F4:16:C8:93:84:E8:20:02:FF
Signature algorithm name: MD5withRSA
Version: 1

*******************************************
*******************************************

8.3.7.4 期限が切れた証明書の管理

ユーザーの信頼できる証明書は、すべてOracle Directory Services Manager Javaキー・ストアに格納されています。Oracle Directory Services Managerは、キー・ストアを管理するためのWebベースのインタフェースは提供しておらず、期限が切れた証明書をJKSから自動的に削除することもできません。管理者がkeytoolを使用して期限が切れた証明書を見つけて削除する必要があります。

「odsm.cer Javaキーストアの内容のリスト」の説明のように、keytoolによって各証明書の妥当性がリストされ、期限が切れた証明書をすべて見つけることができます。たとえば、次の証明書はPDT2008年10月31日土曜日9時41分23秒まで有効です。

Alias name: cn=ovd, ou=development, o=MyCompany, l=redwood shores, st=california, c=us (1241455283)
Creation date: May 5, 2008
Entry type: trustedCertEntry

Owner: CN=OVD, OU=Development, O=MyCompany, L=Redwood Shores, ST=California,C=US
Issuer: CN=OVD, OU=Development, O=Oracle, L=Redwood Shores, ST=California,C=US
Serial number: 49ff1ab3
Valid from: Mon May 04 09:41:23 PDT 2008 until: Sat Oct 31 09:41:23 PDT 2008
Certificate fingerprints:
MD5: 93:0E:41:5E:95:88:71:BD:8A:49:ED:A9:29:3B:0A:1E
SHA1: 84:C6:75:60:D9:BE:7B:CA:D6:8B:B5:4B:97:E4:20:39:44:82:FE:93
Signature algorithm name: SHA1withRSA
Version: 3

期限が切れた証明書を削除するには、「信頼できる証明書の削除」を参照してください。

8.3.7.5 信頼できる証明書の削除

odsm.cerの信頼できる証明書を削除する手順は、次のとおりです。

1. odsm.cerが含まれるディレクトリに移動(cd)します。次に例を示します。

cd DOMAIN_HOME/config/fmwconfig/servers/AdminServer/

2. keytoolを使用して、odsm.cerの内容を削除します。次に例を示します。

ORACLE_HOME/jdk/jre/bin/keytool -delete -keystore odsm.cer \
-storepass PASSWORD_OBTAINED_FROM_CSF -alias "cn=rootca, o=oracle, c=us (0)"
[Storing odsm.cer]

8.3.8 Oracle Directory Services Managerセッション・タイムアウトの構成

Oracle Virtual Directory 11gリリース1 (11.1.1.9.0)以降では、Oracle Directory Services Managerのデフォルトのセッション・タイムアウトは、5分(300秒)です。

Oracle Directory Services Managerセッション・タイムアウトを異なる値に設定するには、WebLogic Server管理コンソールを使用します。(以前のリリースでは、web.xmlデプロイメント記述子の<session-config>要素を編集してタイムアウトを設定していました。)

Oracle Directory Services Managerセッション・タイムアウトを構成する手順は、次のとおりです。

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

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

3. 左ペインで、「デプロイメント」をクリックします。

4. 「デプロイメント」で、「odsm (11.1.1.2.0)」を展開します。

5. 「モジュール」で、「/odsm」をクリックします。

6. 「構成」タブを選択します。

7. 「セッション・タイムアウト」を必要な値に設定します。例: 600秒。

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

9. 「デプロイメント・プラン保存アシスタント」で、「OK」をクリックしてPlan.xmlファイルに変更を保存します。

10. チェンジ・センターで、変更のアクティブ化をクリックします。

変更をテストするには、Oracle Directory Services Managerにアクセスし、ディレクトリ・サーバーにログインして、セッション・タイムアウトに指定した時間(600秒など)が経過するまでセッションをアイドル状態のままにします。指定した時間が経過するとセッションがタイムアウトし、Oracle Directory Services Managerにセッション・タイムアウトのポップアップ・メッセージが表示されます。

8.3.9 セッションのリセット

必要に応じて、ウィンドウの右上隅にある設定のリセット・オプションを使用すると、現在のセッションをリセットしてOracle Directory Services Managerに対するすべてのオープン接続を閉じることができます。

8.3.10 Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成

クラスタ化されたOracle WebLogic Server環境でOracle Directory Services Managerのリクエストを複数のOracle WebLogic ServerにルーティングするようOracle HTTP Serverを構成するには、次の手順に従います。

1. Oracle HTTP Serverのhttpd.confファイルのバックアップ・コピーを作成します。この手順の実行後に問題が起きた場合、このバックアップ・コピーで元の状態に戻すことができます。

2. Oracle HTTP Serverのhttpd.confファイルの末尾に次の文字列を追加し、変数プレースフォルダ値を、使用している環境固有のホスト名および管理対象サーバー・ポート番号と置き換えます。エントリの最初の行として、必ず<Location /odsm/ >を使用してください。<Location /odsm/faces >または<Location /odsm/faces/odsm.jspx >を使用すると、Oracle Directory Services Managerインタフェースの外観がゆがむことがあります。

<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>

3. Oracle HTTP Serverを停止してから起動し、構成の変更を有効にします。

注意:
Oracle Directory Services Managerでは、クラスタ内の接続先のOracle WebLogic Serverに障害が発生すると、接続が失われ、セッション・タイムアウト・メッセージが表示されます。Oracle Directory Services Managerにログインしなおすと、Oracle Directory Services Managerのリクエストは、httpd.confファイルで指定したクラスタ内の2番目のOracle WebLogic Serverにルーティングされます。

8.4 Fusion Middleware Controlの開始

この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directoryでの作業を開始する方法について説明します。この項の内容は次のとおりです。

- Oracle Virtual Directory管理のためのFusion Middleware Controlの起動

- Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動

- Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止

- Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの再起動

- Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryの監視

注意:
Oracle Virtual Directoryが権限ポートでリスニングするように構成されている場合、この項で説明されているようにOracle Enterprise Manager Fusion Middleware Controlを使用してOracle Virtual Directoryを起動、停止または再起動する前に、OPMNがOracle Directory Services Manager管理者として起動されていることを確認します。詳細は、第10章「Oracle Virtual Directoryサーバー・プロセスの管理」を参照してください。

8.4.1 Oracle Virtual Directory管理のためのFusion Middleware Controlの起動

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle Fusion Middlewareに対して包括的なシステム管理プラットフォームを提供するグラフィカル・ユーザー・インタフェースです。Oracle Enterprise Manager Fusion Middleware Controlは、幅広い様々なパフォーマンス・データと管理機能を、ファーム、Oracle Fusion Middlewareコンポーネント、ミドルウェア・システム・コンポーネント、およびアプリケーション用のWebベースの各ホームページで提供します。

Oracle Virtual Directoryは、Oracle Enterprise Manager Fusion Middleware Controlのターゲット・タイプです。Oracle Enterprise Manager Fusion Middleware Controlインタフェースを使用してOracle Virtual Directoryを管理するには、次の手順を実行します。

1. Webブラウザを使用してOracle Enterprise Manager Fusion Middleware Controlに接続します。URLの形式は次のとおりです。

https://host:port/em

2. 左パネルのトポロジ・ツリーで、ファームを展開し、続いて「Identity and Access」を展開します。または、ファーム・ホームページから、「Fusion Middleware」→「Identity and Access」を開きます。両方の場所にOracle Virtual Directoryコンポーネントがリストされます。
各コンポーネントを識別するために、コンポーネント名の上にマウスを置き、ツールチップでコンポーネントの完全名を表示します。

3. 管理するOracle Virtual Directoryのコンポーネントを選択します。

4. 「Oracle Virtual Directory」メニューを使用して、タスクを選択します。

「Oracle Virtual Directory」メニューを使用して、Oracle Virtual Directory用の他の「Oracle Enterprise Manager Fusion Middleware Control」ページ、およびOracle Virtual Directory用の「Oracle Directory Services Manager」ページにナビゲートできます。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』

- 概要

8.4.2 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動

Oracle Enterprise Manager Fusion Middleware Controlを使用して、稼働していないOracle Virtual Directoryサーバーを起動するには、次の手順を実行します。稼働中のOracle Virtual Directoryサーバーを再起動するには、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの再起動」を参照してください。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、起動するOracle Virtual Directoryターゲットにナビゲートします。

2. 「Oracle Virtual Directory」メニューから「コントロール」を選択し、「起動」を選択します。メッセージおよびターゲットのステータスがリストされたダイアログ・ボックスが表示されます。

3. メッセージ・ダイアログ・ボックスで「OK」をクリックして閉じます。

8.4.3 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止

Oracle Enterprise Manager Fusion Middleware Controlを使用して、稼働中のOracle Virtual Directoryサーバーを停止するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、停止するOracle Virtual Directoryターゲットにナビゲートします。

2. 「Oracle Virtual Directory」メニューから「コントロール」を選択し、「停止」を選択します。

3. 確認ダイアログ・ボックスで「はい」をクリックし、Oracle Virtual Directoryサーバーを停止することを確認します。メッセージおよびターゲットのステータスがリストされたダイアログ・ボックスが表示されます。

4. メッセージ・ダイアログ・ボックスで「OK」をクリックして閉じます。

8.4.4 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの再起動

Oracle Enterprise Manager Fusion Middleware Controlを使用して、現在稼働中のOracle Virtual Directoryサーバーを再起動するには、次の手順を実行します。

注意:
稼働中のOracle Virtual Directoryを再起動すると、ファイルシステムからすべてのサーバー構成がリロードされます。稼働中のOracle Virtual Directoryを再起動しても、サーバー・プロセスは停止されません。

1. Oracle Enterprise Manager Fusion Middleware Controlにナビゲートし、再起動するOracle Control Directoryターゲットに接続します。

2. 「Oracle Virtual Directory」メニューから「コントロール」を選択し、「再起動」を選択します。

3. 確認ダイアログ・ボックスで「はい」をクリックし、Oracle Virtual Directoryサーバーを再起動することを確認します。メッセージおよびターゲットのステータスがリストされたダイアログ・ボックスが表示されます。

4. メッセージ・ダイアログ・ボックスで「OK」をクリックして閉じます。

8.4.5 Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryの監視

Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directoryサーバーの複数タイプのメトリックを表示できます。Oracle Enterprise Manager Fusion Middleware Controlを使用してメトリックを表示するには、Oracle Virtual Directoryサーバーが稼働している必要があります。メトリックには、Oracle Enterprise Manager Fusion Middleware Controlの次の場所からアクセスできます。

- Oracle Virtual Directory「ホーム」ページ

- Oracle Virtual Directory「パフォーマンス・サマリー」ページ

「ホーム」ページ

Oracle Virtual Directory「ホーム」ページでメトリックを表示するには、Oracle Enterprise Manager Fusion Middleware Controlにログインし、メトリックが必要なOracle Virtual Directoryターゲットにナビゲートします。統計情報を含む「ホーム」ページが表示されます。

表8-4に、Oracle Virtual Directory「ホーム」ページで確認できる統計情報を示します。

表8-4 「ホーム」ページで確認できるメトリック

サブジェクト

メトリック

現行ロード

- オープン接続: Oracle Virtual Directoryサーバーに接続しているクライアントの数。

- 個別に接続しているユーザー: Oracle Virtual Directoryサーバーに接続している一意のユーザーの数。

- 個別に接続されたIPアドレス: Oracle Virtual Directoryサーバーに接続している一意のIPアドレスの数。

リソース使用率

- Oracle Virtual Directoryのホストで使用されているCPUの割合

- Oracle Virtual Directoryのホストで使用されているメモリーの割合

平均レスポンス時間と操作

- LDAP検索リクエストの完了までの平均時間。

- LDAP検索リクエスト数。

リスナー

次の内容を含む、構成済のOracle Virtual Directoryリスナーの表が表示されます。

- リスナー名

- リスナーが有効化または無効化されているかどうか

- リスナー・タイプ

- リスナーがリスニングするポート

アダプタ

次の内容を含む、構成済のOracle Virtual Directoryアダプタの表が表示されます。

- アダプタ名

- アダプタが有効化または無効化されているかどうか

- アダプタ・タイプ

- アダプタが実行する検索の数

- アダプタが実行する操作の合計数

「パフォーマンス・サマリー」ページ

「パフォーマンス・サマリー」ページでは、様々なメトリックを選択し、時間ベースのコンテキストで表示できます。「パフォーマンス・サマリー」ページに表示されるメトリックは、メトリック・パレットを使用してカスタマイズできます。メトリック・パレットの使用方法の詳細は、管理者ガイドを参照してください。

「パフォーマンス・サマリー」ページでメトリックを表示する手順:

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、メトリックが必要なOracle Virtual Directoryターゲットにナビゲートします。

2. 「Oracle Virtual Directory」メニューから「監視中」を選択し、「パフォーマンス・サマリー」を選択します。「パフォーマンス・サマリー」ページが表示されます。

「パフォーマンス・サマリー」ページで確認できるメトリックのリストとその説明は、表D-1を参照してください。

8.5 WLSTを使用したOracle Virtual Directoryの管理の開始

複数のOracle Virtual Directoryの管理タスクを実行するインタフェースとして、WebLogic Scripting Tool(WLST)を使用できます。このドキュメントでも、複数のタスクと手順でWLSTを使用する方法が説明されていますが、使用方法の詳細は、次のドキュメントを参照してください。

- WLSTコマンドライン・ツールの使用方法の詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

- WLSTコマンドライン・ツールの構文の詳細は、『WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

重要:
Oracle Virtual Directoryのインストールの後、またはOracle WebLogic Serverの再起動の後、他のWLSTコマンドを実行する前に、WLST load()メソッドを実行する必要があります。
また、Oracle Virtual Directory MBean上で他のWLSTコマンドを実行する前に、WLST load()メソッドを実行することをお薦めします。load()メソッドを実行すると、MBeanが現行の構成にリフレッシュされます。

次のようにload()メソッドを起動します。

1. WLSTコマンドライン・ツール・シェルを起動します。

2. WebLogic管理サーバーに接続します。次に例を示します。

connect('username', 'password','t3://host_name:Admin_Server_Port')

3. Oracle Virtual Directoryルート・プロキシMBeanノードに移動し、MBeanを初期化します。次に例を示します。

custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,
instance=asinst1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))

8.6 LDAPツールの使用

Oracle Virtual DirectoryのLDAPツール(ldapadd、ldapdelete、ldapbindなど)が、パスワードの公開を防止するために変更されました。ユーザー・パスワードの-wオプションのかわりに-qオプションを使用し、ウォレット・パスワードの-Pオプションのかわりに-Qオプションを使用してください。-qおよび-Qオプションを使用すると、パスワードの入力を求められます。

-wおよび-Pパスワード・オプションは、LDAP_PASSWORD_PROMPTONLY環境変数をTRUEまたは1に設定することによって無効にできます。可能なときにこの環境変数を設定してください。

9 Oracle Virtual Directoryサーバーの構成と管理

この章では、Oracle Virtual Directoryのサーバー設定の構成方法について説明します。この章の内容は次のとおりです。

- 第9.1項「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーのプロパティの構成」

- 第9.2項「Oracle Directory Services Managerを使用したOracle Virtual Directoryサーバーの設定の構成」

- 第9.3項「WLSTを使用したOracle Virtual Directoryサーバーの設定の構成」

- 第9.4項「Oracle Virtual Directoryサーバーに割り当てる最大ヒープ・サイズの制御」

- 第9.5項「リモート・クライアントまたはサーバー障害が原因の孤立した接続の制御」

- 第9.6項「Oracle Directory Services Managerを使用したOracle Virtual Directoryライブラリの管理」

- 第9.7項「syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー」

9.1 Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーのプロパティの構成

Oracle Virtual Directoryでは、サーバーが匿名ユーザーや認証ユーザーに返すことができるエントリの数などの項目を管理できます。また、インバウンド・トランザクション・トラフィックを制限してプロキシ設定されたソースをDoS攻撃から保護したり、LDAPトラフィックを制限して一定のディレクトリ・インフラストラクチャ・リソースへのアクセスを制御することができます。これらのプロパティなどは、Oracle Enterprise Manager Fusion Middleware ControlのOracle Virtual Directoryサーバーのプロパティのページで構成できます。

サーバー・プロパティ画面には、次の2つのタブがあります。

- 一般。このタブを使用して、アクティビティ制限に対する割当て制限、検索設定、スキーマおよびアクセス制御チェックなどの一般的なサーバー・プロパティを構成します。

- スーパーユーザー・パスワードの変更。このタブを使用して、Oracle Virtual Directoryのスーパーユーザーのパスワードを変更します。

各タブでプロパティを構成するには:

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、サーバー設定を構成するOracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「サーバー・プロパティ」を選択します。サーバー・プロパティ画面が表示されます。

一般的なOracle Virtual Directoryサーバー・プロパティを構成するには:

1. 「サーバー・プロパティ」画面の「一般」タブをクリックします。

2. 「割当て制限実行の有効」オプションを選択し、次の情報を入力して、サーバーの割当て制限実行を有効化します。

注意:

- 割当て制限実行は、デフォルトでは無効化されています。「アクティビティ制限」パラメータを構成するには、「割当て制限実行の有効」オプションを選択する必要があります。

- Oracle Virtual Directoryに接続しているアプリケーションのタイプ、各LDAP操作に対して新規接続を行うかまたはプールの接続を再利用するか、などの様々な要因が影響するため、これらの設定の最小値または最大値は推奨されていません。デプロイメントの要件に基づいて、これらのパラメータを調整する必要があります。

- 「クライアント最大接続数」フィールドに、許可するクライアント接続の最大数を入力します。(デフォルトは0 (無制限)です。)

- 「1接続当たりの最大操作数」フィールドに、接続ごとに許可する操作の最大数を入力します。(デフォルトは0 (無制限)です。)

- 「1認証済サブジェクト当たりの最大接続数」フィールドに、認証されたサブジェクトごとに許可する接続の最大数を入力します。(デフォルトは0 (無制限)です。)

- 「1IPアドレス当たりの最大接続数」フィールドに、Oracle Virtual Directoryに接続されたIPアドレスごとに許可する接続の最大数を入力します。(デフォルトは0 (無制限)です。)

- 「非アクティブ接続タイムアウト」(分単位)フィールドに、Oracle Virtual Directoryが接続を閉じるまでに、クライアント接続が非アクティブの状態でいることができる最大期間(分単位)を入力します。(デフォルトは0 (無制限)です。)

- 「除外IPアドレス」フィールドに、割当て制限チェックから除外するIPアドレスを追加または削除します。IPアドレスを追加するには、「除外IPアドレス」フィールドにIPアドレスを入力します。IPアドレスを削除するには、「除外IPアドレス」フィールドでIPアドレスを選択し、削除します。(デフォルトは127.0.0.1です)

注意:
Oracle Virtual Directory 11gリリース1 (11.1.1)ではIPv6がサポートされています。使用しているネットワークでIPv6がサポートされている場合、「除外IPアドレス」フィールドのリテラルIPv6アドレスを使用して、割当て制限実行から除外するIPアドレスを指定できます。

- 「除外サブジェクト」フィールドに、割当て制限チェックから除外するサブジェクトを追加または削除します。サブジェクトを追加するには、除外IPサブジェクト・フィールドにサブジェクトを入力します。サブジェクトを削除するには、除外IPサブジェクト・フィールドでサブジェクトを選択し、削除します。(デフォルトは、cn=orcladminです。)

注意:
デフォルトでは、Oracle Directory Services Managerの管理者アクセス(通常はcn=orcladmin)を持つユーザーが割当て制限チェックから除外されます。

3. 「匿名検索」フィールドに、匿名クライアント検索に対して戻すエントリの最大数を入力します。(デフォルトは1000です。)

4. 「認証されたユーザーの検索」フィールドに、認証済ユーザーに対して戻すエントリの最大数を入力します。認証済ユーザーは、Oracle Virtual Directoryにバインドされたユーザーとして定義されます。Oracle Virtual Directoryのルート・アカウントはこの割当て制限から除外されています。(デフォルトは10,000です。)

5. 「アクセス制御チェックの有効化」オプションを選択し、Oracle Virtual Directoryでアクセス制御ファイルの定義に従ってアクセス制御を実行できるようにします。

6. 構成されているアダプタに関係なく、Oracle Virtual Directoryで永続検索制御をサポートできるようにするには、「永続検索の有効化」オプションを選択します。

7. 「スキーマ・チェックの有効化」オプションを選択し、「スキーマの場所」フィールドにリストされているファイルに含まれるスキーマ定義にLDAPエントリが適合しているかどうかをOracle Virtual Directoryでチェックできるようにします。
外部のスキーマ・チェック機能を使用する場合にのみ、「スキーマ・チェックの有効化」オプションを無効化することをお薦めします。

8. 「スキーマ・チェックの有効化」オプションが選択されている場合、Oracle Virtual Directoryは「スキーマの場所」フィールドにリストされているファイルを使用して、LDAPエントリがスキーマ定義に適合しているかどうかを確認します。このフィールドを使用して、Oracle Virtual Directoryによってそのスキーマを定義するために使用されるファイルを指定します。
各ファイルは上から下へ降順で適用され、競合が発生した場合は各ファイルによって前のファイルが上書きされます。通常、最後に指定されているファイルはschema.user.xmlです。スキーマに対するどのような変更もすべてschema.user.xmlファイルに適用され、標準ファイル(schema.core.xmlなど)がリリース間で変更されないようにすると同時に、それらを、schema.user.xmlにおける変更でschema.core.xml内のデフォルトの出荷時に備わっているスキーマを上書きすることで実質的に変更することができます。

製造業者提供のスキーマ(DSML形式)をインストールする場合は、そのファイルをスキーマ・ファイル・リストの最後から2番目に指定します。これにより、配布された製造業者ファイルが変更されなくなると同時に、ローカルなカスタマイズが可能になり、それらがschema.user.xmlに格納されます。

次に、デフォルトのスキーマ・ファイルのリストを示します。

- schema.core.xml

- schema.cosine.xml

- schema.inetorgperson.xml

- schema.nis.xml

- schema.dyngroup.xml

- schema.java.xml

- schema.diameter.xml

- schema.eus.xml

- schema.user.xml

9. 「TLS構成」セクションを使用すると、次の操作を実行できます。

- アダプタのキーストアおよびトラストストアの名前を読み取ります。Oracle Enterprise Manager Fusion Middleware Controlを使用してこれらの値を構成することはできません。

- アダプタのキーストアおよびトラストストアのパスワードを設定します。

10. 「サーバー構成」画面の「適用」をクリックして、設定を適用します。

Oracle Virtual Directoryのスーパーユーザー・パスワードの変更手順:

1. 「サーバー・プロパティ」画面の「スーパーユーザー・パスワードの変更」タブをクリックします。

2. 「旧パスワード」フィールドに、既存のスーパーユーザーのパスワードを入力します。

3. 「新規パスワード」フィールドに、新しいスーパーユーザーのパスワードを入力します。

4. 「パスワードの確認」フィールドに、新しいスーパーユーザーのパスワードをもう一度入力します。

5. 「適用」をクリックします。

Oracle Virtual Directoryのスーパーユーザーの紛失したパスワードをリセットする手順は、次のとおりです。

スーパーユーザー・パスワードを紛失した場合、ovdcred.plスクリプトを実行してパスワードをリセットできます。また、このスクリプトを使用してOracle Virtual Directoryのルート・ユーザー名を変更することもできます。

注意:
このスクリプトを実行する前に、ORACLE_HOMEを設定する必要があります。

1. $ORACLE_HOME/ovd/bin/ディレクトリでovdcred.plを見つけます。

2. 次の構文を使用してovdcred.plスクリプトを実行します。

ovdcred.pl -componentName  ovd-component-name -instancePath
ovd-instance-path -option username/password option

説明

- componentName (必須)はOracle Virtual Directoryのコンポーネント名です

- instancePath (オプション)は、ORACLE_INSTANCE値です。ORACLE_INSTANCE値をすでに設定してある場合、このオプションを指定する必要はありません。

- option (必須)には、編集またはリセットする値のパスワードまたはユーザー名を指定します。

次に例を示します。

ovdcred.pl –componentName ovd1 –instancePath /scratch/aime1/asinst_1 –option Password
ovdcred.pl –componentName ovd1 –instancePath /scratch/aime1/asinst_1 –option Username

9.2 Oracle Directory Services Managerを使用したOracle Virtual Directoryサーバーの設定の構成

Oracle Directory Services Managerを使用して、次のものに関連する設定など、いくつかのOracle Virtual Directoryサーバーの設定を構成できます。

- スキーマ・ファイル

- アクセス制御

- サーバー検索制限

- サーバー・アクティビティ制限

- アダプタSSL設定

Oracle Directory Services Managerを使用してOracle Virtual Directoryサーバーの設定を構成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 「拡張」ナビゲーション・ツリーで「サーバー設定」エントリをクリックします。「サーバー設定」エントリが開き、ナビゲーション・ツリーに「設定」、「割当」、および「アダプタSSL設定」グループが表示されます。

4. 構成するグループをクリックします。次の表は、各グループの各設定を示しています。

注意:

- Oracle Virtual Directoryに接続しているアプリケーションのタイプ、各LDAP操作に対して新規接続を行うかまたはプールの接続を再利用するか、などの様々な要因が影響するため、これらの設定の最小値または最大値は推奨されていません。デプロイメントの要件に基づいて、これらのパラメータを調整する必要があります。

- 適切な設定を構成した後、メインの「Oracle Directory Services Manager」画面で「適用」をクリックし、Oracle Virtual Directoryサーバーに設定を保存します。

表9-1 ODSMにおける設定構成パラメータのグループ

カテゴリ

設定

説明

スキーマ

スキーマ・ファイル

Oracle Virtual Directoryによってそのスキーマを定義するために使用されるファイルを指定します。

- 「使用可能なファイル」フィールドには、スキーマ定義が含まれている使用可能なスキーマ・ファイルがすべてリストされます。

- 「選択済のファイル」フィールドには、LDAPエントリがスキーマ定義に適合していることを検証するためにOracle Virtual Directoryによって使用されるファイルがリストされます。Oracle Virtual Directoryによって、「選択済のファイル」フィールドにリストされているファイルに対してLDAPエントリが検証されるのは、「スキーマ・チェックの有効化」オプションが選択されている場合のみです。

1つ以上のファイルを選択し、「移動」または「削除」ボタンを使用して、「使用可能なファイル」フィールドと「選択済のファイル」フィールドの間でファイルを移動します、

Oracle Virtual Directoryによって、LDAPエントリが、「選択済のファイル」フィールドのファイルに対してそれらがフィールドに表示されている順序で検証されます。各ファイルは上から下へ降順で検証に使用され、競合が発生した場合は各ファイルによって前のファイルが上書きされます。ファイルを検証に使用する順序を変更するには、「選択済のファイル」フィールドでファイル名を選択し、「選択済のファイル」フィールドの右にある下向きおよび上向きの矢印ボタンを使用します。

通常、最後に指定されているファイルはschema.user.xmlです。スキーマに対するすべての変更がschema.user.xmlファイルに適用され、標準ファイル(schema.core.xmlなど)がリリース間で変更されないようにすると同時に、それらを、schema.user.xmlにおける変更でschema.core.xml内のデフォルトの出荷時に備わっているスキーマを上書きすることで実質的に変更することができます。

製造業者提供のスキーマ(DSML形式)をインストールする場合は、そのファイルをスキーマ・ファイル・リストの最後から2番目に指定します。これにより、配布された製造業者ファイルが変更されなくなると同時に、ローカルなカスタマイズが可能になり、それらがschema.user.xmlに格納されます。

次に、デフォルトのスキーマ・ファイルのリストを示します。

- schema.core.xml

- schema.cosine.xml

- schema.inetorgperson.xml

- schema.nis.xml

- schema.dyngroup.xml

- schema.java.xml

- schema.diameter.xml

- schema.eus.xml

- schema.user.xml

スキーマ

スキーマ・チェックの有効化

「スキーマ・チェックの有効化」オプションを選択し、「スキーマ・ファイル」セクションにリストされているファイルに含まれるスキーマ定義にLDAPエントリが適合しているかどうかをOracle Virtual Directoryでチェックできるようにします。外部のスキーマ・チェック機能を使用する場合にのみ、「スキーマ・チェックの有効化」オプションを無効化することをお薦めします。

アクセス制御

アクセス制御の有効化

「アクセス制御の有効化」オプションを選択し、Oracle Virtual Directoryでアクセス制御ファイルの定義に従ってアクセス制御を実行できるようにします。

アクセス制御

アクセス制御ファイル

Oracle Virtual Directoryのアクセス制御リスト(ACL)が格納されているファイルを指定します。

サーバー・ルート・アダプタ

ルートDN

仮想ディレクトリ・ツリーの別の場所にOracle Virtual DirectoryのルートDSEエントリ(base="")を再配置できるようにします。

DSEの再配置は、一般的に別のサーバーのルート・エントリをプロキシ設定して、Oracle Virtual Directoryのルート・エントリを置き換える場合(通常、Oracle Virtual Directoryを別のディレクトリ・サーバーとして表示する場合)に実行されます。これは、アプリケーションでディレクトリに関する想定が行われる場合に役立つことがあります。

Oracle Virtual Directoryのルート・エントリの名前を""から変更した後、""のリモート・ベースでLDAPアダプタを作成してそのローカル・ルートを""として設定することでそれを置換できます。これを実行する場合、LDAPアダプタの「ルーティング」の「レベル」を0に設定し、Oracle Virtual Directoryのルートに問合せが行われた場合にのみ、そのリモート・サーバーのルート・エントリに問合せが試行されるようにすることも必要です。「ルーティング」の「レベル」を0に設定しない場合、リモート・サーバーは、Oracle Virtual Directoryが受信するすべてのリクエストについて問合せを受信します。

コントロール

永続検索制御

構成されているアダプタに関係なく、Oracle Virtual Directoryの永続検索制御のサポートを有効化または無効化します。

サーバー・セキュリティ

管理グループURL

Oracle Directory Services Manager管理ポートへの接続に使用する有効なLDAP管理グループURLを入力します。このURLに一致するすべてのユーザーは、管理ポートに接続し、Oracle Virtual Directoryを再起動した後にOracle Virtual Directory構成を管理できます。

表9-2 ODSMにおける割当構成パラメータのグループ

カテゴリ

設定

説明

検索制限

匿名

匿名クライアント検索に対して戻すエントリの最大数を入力します。(デフォルトは1000です。)

認証済

認証されたユーザーに対して戻すエントリの最大数を入力します。認証済ユーザーは、Oracle Virtual Directoryにバインドされたユーザーとして定義されます。Oracle Virtual Directoryのルート・アカウントはこの割当て制限から除外されています。(デフォルトは10,000です。)

アクティビティ制限

割当て制限の実行

Oracle Virtual Directoryサーバーにおける割当て制限実行を有効化または無効化します。「アクティビティ制限」パラメータを構成するには、「割当て制限の実行」オプションを有効化する必要があります。

率

割当て制限実行の期間(ミリ秒単位)を決定します。たとえば、「率」を50000に設定すると割当は50秒間実行されます。50秒が経過すると、割当設定のカウントが再び0から始まり、割当がさらに50秒間実行されます。(デフォルトは30000 (30秒)です。)

最大接続数

許容されるクライアント接続の最大数を入力します。(デフォルトは0 (無制限)です。)

最大操作数/接続

各接続に対して許可される操作の最大数を入力します。(デフォルトは0 (無制限)です。)

最大接続数/サブジェクト

各認証済サブジェクトに対して許可される接続の最大数を入力します(デフォルトは0 (無制限)です。)

最大接続数/IPアドレス

Oracle Virtual Directoryに接続されたIPアドレスごとに許可する接続の最大数を入力します。(デフォルトは0 (無制限)です。)

非アクティブ接続タイムアウト

Oracle Virtual Directoryが接続を閉じるまでに、クライアント接続が非アクティブの状態でいることができる最大期間(分単位)を入力します。(デフォルトは0 (無制限)です。)

除外サブジェクト

割当て制限実行から除外するサブジェクトを追加または削除します。デフォルトでは、Oracle Directory Services Managerの管理者アクセス(通常はcn=orcladmin)を持つユーザーが割当て制限実行から除外されます。

除外IPアドレス

割当て制限実行から除外するIPアドレスを追加または削除します。(デフォルトは127.0.0.1です)

表9-3 ODSMにおけるアダプタSSL設定構成パラメータのグループ

設定

説明

キーストア

既存のSSLキーストアの名前および場所をリストします。

キーストア・パスワード

「キーストア」リストで選択されているキーストアのパスワード。

トラスト・ストア

既存のSSLトラスト・ストアの名前および場所をリストします。

トラスト・ストア・パスワード

「トラスト・ストア」リストで選択されているトラスト・ストアのパスワード。

アダプタ・キーの別名

既存のJava証明書別名をリストします。このリストから別名を選択し、その証明書の詳細を「選択済の証明書詳細」表に表示します。この「アダプタ・キーの別名」コントロールは情報目的のみであり、データは書き込まれません。

選択済の証明書詳細

「アダプタ・キーの別名」リストで指定した別名のJava証明書に関する詳細を表示します。

9.3 WLSTを使用したOracle Virtual Directoryサーバーの設定の構成

ORACLE_COMMON_HOME/common/bin/wlst.shに配置されているWebLogic Scripting Tool(WLST)を使用して、次の手順でOracle Virtual Directoryサーバー設定を構成できます。

1. WebLogic管理サーバーに接続します。次に例を示します。

connect('username', 'password','t3://host_name:Admin_Server_Port')

2. Oracle Virtual Directoryルート・プロキシMBeanノードに移動し、MBeanを初期化します。次に例を示します。

custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=OVD_COMPONENT_NAME,instance=INSTANCE_NAME')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

3. Oracle Virtual Directoryサーバー構成MBeanに移動します。次に例を示します。

cd('../..')
cd('oracle.as.ovd/oracle.as.ovd:type=component.serverconfig,name=serverconfig,i
nstance=INSTANCE_NAME,component=OVD_COMPONENT_NAME')

4. WLST ls()コマンドを使用すると、Oracle Virtual Directoryサーバー構成MBeanの属性のリストを表示できます。get('ATTRIBUTE_NAME')コマンドを使用して、特定の属性の現在の値を取得します。たとえば、MaxConnections (許可するクライアント接続の最大数)の現在の値を取得するには、次のコマンドを実行します。

get('MaxConnections')

set()コマンドを使用して属性を更新します。たとえば、MaxConnections設定の値を更新するには、次のコマンドを実行します。

set('MaxConnections', 3000)

注意:
前の例のとおりにset()コマンドを使用すると、属性の設定はMBeanに保存されます。Oracle Virtual Directoryサーバーに変更を保存するには、この手順の手順5 を実行する必要があります。

次の表に、Oracle Virtual Directoryサーバー構成MBeanの属性と、属性を設定するためのコマンドの例をリストします。

注意:

- Oracle Virtual Directoryに接続しているアプリケーションのタイプ、各LDAP操作に対して新規接続を行うかまたはプールの接続を再利用するか、などの様々な要因が影響するため、これらの設定の最小値または最大値は推奨されていません。デプロイメントの要件に基づいて、これらのパラメータを調整する必要があります。

- 適切な設定を構成した後、メインの「Oracle Directory Services Manager」画面で「適用」をクリックし、Oracle Virtual Directoryサーバーに設定を保存します。

表9-4 Oracle Virtual Directoryサーバー構成MBeanの属性

属性

コマンドの例

ACLCheck

set('ACLCheck',true)

Anonymous
(デフォルトは1000です。)

set('Anonymous',2000)

Authenticated
(デフォルトは10000です。)

set('Authenticated',20000)

DoSActive

set('DoSActive',true)

DoSRatePeriod
(デフォルトは30000 (30s)です。)

set('DoSRatePeriod',20000)

ExemptIPAddresses
(デフォルトは127.0.0.1です。)

最初(1つのコマンドライン上):

invoke('addExemptIPAddress',jarray.array([java.lang.String
('127.0.0.1')],
java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String))

次(1つのコマンドライン上):

invoke('deleteExemptIPAddress',jarray.array([java.lang.String
('127.0.0.1')]
,java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String))

ExemptSubjects
(デフォルトはcn=orcladminです。)

最初(1つのコマンドライン上):

invoke('addExemptSubjects',jarray.array([java.lang.String
('cn=myuser')],
java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String))

次(1つのコマンドライン上):

invoke('deleteExemptSubjects',jarray.array([java.lang.String
('cn=myuser')],
java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String))

InactiveConnectionTimeout (デフォルトは0 (無制限)です。)

set('InactiveConnectionTimeout',50)

MaxConnections
(デフォルトは0 (無制限)です。)

set('MaxConnections',50)

MaxConnectionsPerIP
(デフォルトは0 (無制限)です。)

set('MaxConnectionsPerIP',20)

MaxConnectionsPerSubject
(デフォルトは0 (無制限)です。)

set('MaxConnectionsPerSubject',20)

MaxOperationsPerConnection
(デフォルトは0 (無制限)です。)

set('MaxOperationsPerConnection',10)

PersistentSearch

set('PersistentSearch',false)

TLSKeyStore

読取り専用属性

TLSTrustStore

読取り専用属性

TLSKeyStorePassword

set('TLSKeyStorePassword',java.lang.String
('PASSWORD').toCharArray())

TLSTrustStorePassword

set('TLSTrustStorePassword',java.lang.String
('welcome1').toCharArray())

SchemaCheck

set('SchemaCheck',true)

SchemaLocations

追加(1行で):

invoke('addSchemaLocation',jarray.array([java.lang.String
('schema.myschema.
xml')],java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String
))

削除(1行で):

invoke('deleteSchemaLocation',jarray.array([java.lang.String
('schema.mysche
ma.xml')],java.lang.Object),jarray.array(['java.lang.String'],
java.lang.String))

5. Oracle Virtual Directoryサーバーに変更を保存してから、MBeanをリフレッシュします。次に例を示します。

cd('../..')
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=OVD_COMPONENT_NAME,instance=asinst1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

9.4 Oracle Virtual Directoryサーバーに割り当てる最大ヒープ・サイズの制御

opmn.xmlファイルの-Xmxパラメータは、Oracle Virtual Directoryサーバーに割り当てられる最大ヒープ・サイズを制御します。デフォルト値は-Xmx256mです。必要に応じてこのパラメータを編集し、Oracle Virtual Directoryサーバーに割り当てられる最大ヒープ・サイズを増やすか減らします。opmn.xmlファイルは次のディレクトリにあります。

ORACLE_INSTANCE/config/OPMN/opmn/

次の例は、-Xmx2048mに設定された-Xmxパラメータを示しています。これにより、Oracle Virtual Directoryサーバーに2 GBのヒープ・サイズが割り当てられます。

<ias-component id="OVD_COMPONENT_NAME">
<process-type id="OVD" module-id="OVD">
<module-data>
<category id="start-options">
<data id="java-options" value="-server -Xms512m -Xmx2048m
-Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml
-Dvde.soTimeoutBackend=120"/>
<data id="java-classpath" value="$ORACLE_
HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
</module-data>
<stop timeout="120"/>
</process-type>
</ias-component>

9.5 リモート・クライアントまたはサーバー障害が原因の孤立した接続の制御

Oracle Virtual Directoryでは、リモート・クライアントまたはサーバー障害が原因の孤立したソケット接続を検出して安全に閉じる、2つのパラメータがサポートされています。これらのパラメータは、アプリケーションまたはディレクトリ・ソースがOracle Virtual Directoryとは異なるネットワーク上(特に同じデータ・センター外)にあり、ネットワークが不安定な場合に役立ちます。

各パラメータを、TCPがクライアントまたはサーバーからのレスポンスを待機する期間に秒単位で設定します。ネットワークのステータスと安定性が、設定するパラメータおよび期間に影響します。不安定なネットワークでは、これらのパラメータを、安定したネットワーク環境の場合よりも長く設定します。

注意:
オペレーティング・システムによりTIME_WAITステータスの接続が複数報告され、それらが5分以上など、延長された期間で閉じられない場合は、これらのパラメータを使用して孤立した接続を制御する目安になります。

孤立したクライアント接続の制御:

LDAPリスナーのSocketOptionsReadTimeoutパラメータを使用して、孤立したクライアント接続を制御できます。WLST set()コマンドを使用して、SocketOptionsReadTimeoutパラメータを設定します。次に例を示します。

set('SocketOptionsReadTimeout', 120)

注意:
SocketOptionsReadTimeoutパラメータ値は、ミリ秒単位で指定する必要があります。

WLSTを使用したリスナー設定の更新の詳しい手順は、「リスナー設定の更新」を参照してください。

注意:
LDAPリスナーのこのパラメータは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定することもできます。詳細は、「LDAPリスナーの作成」で説明されているRead Timeoutパラメータを参照してください。

孤立したサーバー接続の制御:

ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlファイル内のvde.soTimeoutBackendJava仮想マシン・パラメータを使用して、孤立したサーバー接続を制御できます。

vde.soTimeoutBackendパラメータを設定するには、opmn.xmlファイルを編集してからOracle Virtual Directoryを再起動します。

注意:
soTimeoutBackendパラメータ値は、秒単位で指定する必要があります。

次に、opmn.xmlファイルに設定されたvde.soTimeoutBackendパラメータの例を示します。

<ias-component id="OVD_COMPONENT_NAME">
<process-type id="OVD" module-id="OVD">
<module-data>
<category id="start-options">
<data id="java-options" value="-server -Xms512m -Xmx512m
-Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml
-Dvde.soTimeoutBackend=120"/>
<data id="java-classpath" value="$ORACLE_
HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
</module-data>
<stop timeout="120"/>
</process-type>
</ias-component>

9.6 Oracle Directory Services Managerを使用したOracle Virtual Directoryライブラリの管理

この項では、Oracle Virtual Directoryプラグインおよび結合ビュー・アダプタで使用されるライブラリの管理方法について説明します。この項の内容は次のとおりです。

- Oracle Virtual Directoryサーバーのライブラリの表示

- Oracle Virtual Directoryサーバーへのライブラリのロード

9.6.1 Oracle Virtual Directoryサーバーのライブラリの表示

Oracle Virtual Directoryサーバーに存在するライブラリ(プラグインおよび結合ビュー・アダプタも含む)を表示するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーの「ライブラリ」エントリを開きます。Oracle Virtual Directoryサーバーに存在するライブラリ・ファイルのリストは、拡張ツリーの「ライブラリ」エントリに表示されます。

9.6.2 Oracle Virtual Directoryサーバーへのライブラリのロード

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryにライブラリをロードするには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーの「ライブラリ」エントリを開きます。

4. 拡張ツリーの上部にある「新規ライブラリのアップロード」ボタンをクリックします。「新規ライブラリのアップロード」ダイアログ・ボックスが表示されます。

5. Oracle Virtual Directoryにロードするライブラリへのパスを入力するか、「参照」をクリックし、ライブラリに移動して選択します。「新規ライブラリのアップロード」ダイアログ・ボックスで「OK」をクリックして、Oracle Virtual Directoryにライブラリをロードします。拡張ツリーの「ライブラリ」エントリにライブラリが表示されます。

9.7 syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー

syncovdconfigコマンドを使用して、複数のOracle Virtual Directoryコンポーネント間で次のOracle Virtual Directory構成ファイルをコピーできます。

- server.os_xml

- adapters.os_xml

- acls.os_xml

- schema.user.xml

このコマンドを使用すると、2つ目のOracle Virtual Directoryサーバー上で同じ構成手順(アダプタの作成など)を実行する必要がなくなります。

syncovdconfigコマンドは、ローカル・ストア・アダプタの内容をコピーしません。Oracle Virtual Directoryの構成を複製するのみです。

注意:
oidcmprecツールを使用して、ローカル・ストア・アダプタ内のデータを2つ目のサーバーにコピーできますが、それは1回かぎりの操作です。oidcmprecツールは、ローカル・ストア・アダプタの内容を同期した状態に保てないため、ローカル・ストア・アダプタの内容が変更されるたびにコールする必要があります。
エンタープライズ・ユーザー・セキュリティ(EUS)を使用すると、ローカル・ストア・アダプタの内容は、次の場合にのみ変更されます。

- DBCAを使用して新しいデータベースを登録または削除した場合。

- ESMまたはEMから任意のEUS構成タスクを実行した場合。

oidcmprecは同期をサポートしますが、これは頻繁に実行される操作ではありません。したがって、oidcmprecツールを使用して、DBCAを使用するたびに2つ目のOracle Virtual Directoryサーバーと同期化することをお薦めします。

同期制限など、oidcmprecツールの詳細は、第2.4.1項「ローカル・ストア・アダプタ・データの移行」を参照してください。

syncovdconfigコマンド(UNIX/Linuxの場合は.pl、Windowsの場合は.bat)は、$ORACLE_HOME/ovd/bin/ディレクトリにあります。

注意:

- ソースおよび宛先のユーザーのパスワードを両方とも要求されます。

- syncovdconfigコマンドを使用する前に、$ORACLE_HOME変数を設定する必要があります。

次の例は、syncovdconfigの構文を示します。

syncovdconfig -srcHost source_host_name -srcPort source_port_number
-srcUserName source_user_name -dstHost destination_host_name
-dstPort destination_port_number -dstUserName destination_user_name
-configFile name_of_configuration_file -adapterName name_of_adapter
-isSrcAdminSSL [true |false] -isDstAdminSSL [true |false]

9.7.1 オプション

次に、syncovdconfigのオプションのリストを示します。

srcHost

必須です。文字列の書式を設定します。ソースOracle Virtual Directoryサーバー(別のOracle Virtual Directoryサーバーにコピーする構成ファイルを含むOracle Virtual Directoryサーバー)のホスト名です。

srcPort

必須です。整数の書式を設定します。ソースOracle Virtual Directoryサーバー(別のOracle Virtual Directoryサーバーにコピーする構成ファイルを含むOracle Virtual Directoryサーバー)のリスニング・ポート番号です。

srcUserName

オプション。文字列の書式を設定します。ソースOracle Virtual Directoryサーバー(別のOracle Virtual Directoryサーバーにコピーする構成ファイルを含むOracle Virtual Directoryサーバー)に対するOracle Directory Services Manager管理者アクセスを持つユーザーです。srcUserNameオプションが指定されていない場合、デフォルト値のcn=orcladminが使用されます。

dstHost

必須です。文字列の書式を設定します。宛先Oracle Virtual Directoryサーバー(構成ファイルのコピー先となるOracle Virtual Directoryサーバー)のホスト名です。

dstPort

必須です。整数の書式を設定します。宛先Oracle Virtual Directoryサーバー(構成ファイルのコピー先となるOracle Virtual Directoryサーバー)のリスニング・ポート番号です。

dstUserName

オプション。文字列の書式を設定します。宛先Oracle Virtual Directoryサーバー(構成ファイルのコピー先となるOracle Virtual Directoryサーバー)に対するOracle Directory Services Manager管理者アクセスを持つユーザーです。dstUserNameオプションが指定されていない場合、デフォルト値のcn=orcladminが使用されます。

configFile

オプションです。文字列の書式を設定します。ソースOracle Virtual Directoryサーバー上の、宛先Oracle Virtual Directoryサーバーにコピーする構成ファイルの名前です。同じコマンド内でconfigFileオプションを複数回使用すると、複数の構成ファイルをコピーできます。

configFileオプションを使用しない場合、ソースOracle Virtual Directorサーバー上のserver.os_xml、adapters.os_xml、acls.os_xml、およびschema.user.xmlファイルが宛先Oracle Virtual Directoryサーバーにコピーされます。

adapterName

オプションです。文字列の書式を設定します。ソースOracle Virtual Directoryサーバー上の、宛先Oracle Virtual Directoryサーバーにコピーするアダプタの名前です。同じコマンド内でadapterNameオプションを複数回使用すると、複数のアダプタをコピーできます。

adapterNameオプションは使用せず、configFileオプションを使用してadapters.os.xmlファイルを指定すると、宛先Oracle Virtual Directoryサーバー上のadapters.os.xmlファイルは上書きされます。

空白文字を含むアダプタ名は、引用符(")で囲んでください。次に例を示します。

ORACLE_HOME/ovd/bin/syncovdconfig.pl -srcHost sales.west.com -srcPort 8888 \
-dstHost sales.east.com -dstPort 8899 -configFile adapters.os_xml \
-adapterName "Sales Organizations"

isSrcAdminSSL

オプションです。ブールの書式を設定します。ソースOracle Virtual Directoryコンポーネント上の管理リスナーでSSLが有効化されているかどうかを示します。サポートされる値は、true (デフォルト)およびfalseです。isSrcAdminSSLオプションが指定されていない場合、デフォルト値のtrueが使用されます。

isDstAdminSSL

オプションです。ブールの書式を設定します。宛先Oracle Virtual Directoryコンポーネント上の管理リスナーでSSLが有効化されているかどうかを示します。サポートされる値は、true (デフォルト)およびfalseです。DstAdminSSLオプションが指定されていない場合、デフォルト値のtrueが使用されます。

9.7.2 例

次に、syncovdconfigコマンドの例を示します。

- 2つのOracle Virtual Directoryコンポーネント間でserver.os_xml、adapters.os_xml、acls.os_xmlおよびschema.user.xmlファイルの同期を取る場合:

ORACLE_HOME/ovd/bin/syncovdconfig.pl –srcHost  sales.west.com –srcPort 8899 \
–srcUserName cn=orcladmin  –dstHost sales.west.com –dstPort 8888 –dstUserName \
cn=orcladmin  -isSrcAdminSSl true –isDstAdminSSL false

- 2つのOracle Virtual Directoryコンポーネント間でserver.os_xmlファイルのみの同期を取る場合:

ORACLE_HOME/ovd/bin/syncovdconfig.pl –srcHost  sales.west.com –srcPort 8899 \
–srcUserName cn=orcladmin –dstHost sales.west.com –dstPort 8888 \
–dstUserName cn=orcladmin -configFile server.os_xml

- 2つのOracle Virtual Directoryコンポーネント間で複数のファイルの同期を取る場合:

ORACLE_HOME/ovd/bin/syncovdconfig.pl –srcHost  sales.west.com –srcPort 8899 \
–srcUserName cn=orcladmin –dstHost sales.west.com –dstPort 8888 \
–dstUserName cn=orcladmin -configFile server.os_xml –configFile adapters.os_xml

- 2つのOracle Virtual Directoryコンポーネント間で特定のアダプタの同期を取る場合:

ORACLE_HOME/ovd/bin/syncovdconfig.pl –srcHost  sales.west.com –srcPort 8899 \
–srcUserName cn=orcladmin –dstHost sales.west.com –dstPort 8888 \
–dstUserName cn=orcladmin -configFile server.os_xml \
-configFile adapters.os_xml –adapterName Sales

10 Oracle Virtual Directoryサーバー・プロセスの管理

この章では、Oracle Process Manager and Notification Serverを使用してOracle Virtual Directoryプロセスを管理する方法について説明します。この章の内容は次のとおりです。

- 第10.1項「Oracle Process Manager and Notification Serverとは」

- 第10.2項「デフォルトOracle Virtual Directoryイメージの概要」

- 第10.3項「OPMNCTLを使用したOracle Virtual Directoryコンポーネントの作成」

- 第10.4項「OPMNCTLを使用したOracleインスタンスの登録」

- 第10.5項「OPMNCTLを使用したOracleインスタンスの登録解除」

- 第10.6項「OPMNCTLを使用したOracleインスタンスのコンポーネント登録の更新」

- 第10.7項「OPMNCTLを使用したOracle Virtual Directoryコンポーネントの削除」

- 第10.8項「OPMNCTLを使用したアクティブ・サーバー・インスタンスの情報の表示」

- 第10.9項「OPMNCTLを使用したOracle Virtual Directoryサーバーの起動」

- 第10.10項「OPMNCTLを使用したOracle Virtual Directoryサーバーの停止」

- 第10.11項「OPMNCTLを使用したOracle Virtual Directoryサーバーの再起動」

10.1 Oracle Process Manager and Notification Serverとは

Oracle Process Manager and Notification Server(OPMN)は、Oracle Virtual Directoryを含むOracle Fusion Middlewareコンポーネントを監視するデーモン・プロセスです。Oracle Enterprise Manager Fusion Middleware Controlは、OPMNを使用してOracle Virtual Directoryを停止または起動を行います。この章で説明されているOracle Virtual Directoryのプロセス管理タスクは、コマンドラインから、opmnctl(OPMNへのコマンドライン・インタフェース)を使用して実行できます。

関連項目:
OPMNおよびopmnctlコマンドの詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

10.2 デフォルトOracle Virtual Directoryイメージの概要

ホスト・コンピュータにOracle Virtual Directoryをインストールすると、Oracle Identity Management 11gインストーラによって次のものが作成されます。

- 新規または既存のOracleインスタンス内にType=OVDのOracle Fusion Middlewareコンポーネント。このOracle Virtual Directoryコンポーネント名は通常はovd1で、Oracleインスタンス名は通常はasinst_1です。

- Oracleインスタンス・ディレクトリの下にファイルシステム・ディレクトリ。インストーラによって作成されるディレクトリ・パスの一部には、コンポーネント名に固有の名前が付けられます。たとえば、UNIXまたはLinux上のOracleインスタンス・ディレクトリの下には、次の名前のパスがあります。

- ORACLE_INSTANCE/config/OVD/ovd1

- ORACLE_INSTANCE/diagnostics/logs/OVD/ovd1

インストール中に新規ドメインの作成または既存ドメインの拡張オプションのいずれかを選択すると、Oracle Virtual DirectoryコンポーネントはWebLogicドメインに登録されます。インストール中に「なし」オプションを選択すると、Oracle Virtual Directoryコンポーネントはドメインに登録されません。Oracle Virtual Directoryコンポーネントをドメインに登録することをお薦めします。この章で説明されているように、Oracle Virtual Directoryコンポーネントは、opmnctlを使用してコマンドラインから登録できます。

インストール中に既存ドメインの拡張オプションを使用して複数のノード上に複数のOracle Virtual Directoryコンポーネントをインストールする場合は、2つ目およびそれ以降のノードは、ovd2、ovd3のようなコンポーネント名を持ちます。

10.3 OPMNCTLを使用したOracle Virtual Directoryコンポーネントの作成

Oracleインスタンス内にOracle Virtual Directoryコンポーネントを作成するには、opmnctl createcomponentを使用します。次に、opmnctl createcomponentを使用してOracle Virtual Directoryコンポーネントを作成する構文を示します。

$ORACLE_INSTANCE/bin/opmnctl createcomponent
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']
-componentType OVD
-componentName componentName
[-passwordFile 'FILE_WITH_OVD_ADMIN_PASSWORD']
[-admin cn=orcladmin]
[-isAdminSSL true | false ]
[-ovdAdminPort OVD_ADMIN_GATEWAY_PORT]
[-namespace dc=us,dc=oracle,dc=com]
[-ldapPort LDAP_PORT]
[-ldapSport  SSL_ENABLED_LDAP_PORT]
[-httpPort HTTP_PORT]
[-isHttpSSL true | false]

opmnctl createcomponentコマンドでは、複数のパラメータを使用できます。次に、Oracle Virtual Directoryに固有のパラメータのリストを示します。opmnctl createcomponentコマンドのパラメータの詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

-admin

Oracle Virtual Directory管理ユーザー名(例: cn=orcladmin)。デフォルト値はcn=orcladminです。

-passwordFile

Oracle Virtual Directory管理パスワード・ファイル。ファイルの場所を指定しない場合、パスワードの入力を求められます。

-isAdminSSL

Oracle Virtual Directory管理リスナーのSSLを有効または無効にします。サポートされている値は、trueおよびfalseです。デフォルト値はtrueです。

-ovdAdminPort

Oracle Virtual Directory管理リスナーのポートを指定します。デフォルト値は8899です。

-namespace

ネームスペース値(例: dc=us,dc=oracle,dc=com)

-ldapPort

Oracle Virtual Directory LDAPリスナーのポートを指定します。デフォルト値は6501です。

-ldapSport

Oracle Virtual Directory LDAPリスナーのSSLポートを指定します。デフォルト値は6502です。

-httpPort

Oracle Virtual Directory HTTPリスナーのポートを指定します。デフォルト値は8080です。

-isHttpSSL

Oracle Virtual Directory HTTPリスナーのSSLを有効または無効にします。デフォルト値はtrueです。

例10-1 opmnctl createcomponentコマンド

次の例では、名前がovd3のOracle Virtual Directoryコンポーネントを作成します。

$ORACLE_INSTANCE/bin/opmnctl createcomponent -adminHost sales.west.com \
-adminPort 7001 -adminUsername weblogic -componentName ovd3 -componentType OVD \
-admin cn=admin -isAdminSSL true -ovdAdminPort 8890 \
-namespace dc=us,dc=oracle,dc=com -ldapPort 5566 -ldapSport 4455 -httpPort 9090 \
-isHttpSSL true

10.4 OPMNCTLを使用したOracleインスタンスの登録

OracleインスタンスおよびそのOracleインスタンス内のすべてのコンポーネントを登録するには、opmnctl registerinstanceを使用します。構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl registerinstance
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl registerinstance \
-adminHost myhost \
-adminPort 7001 \
-adminUsername weblogic \

WebLogic管理サーバーのデフォルト管理ポートは7001です。

10.5 OPMNCTLを使用したOracleインスタンスの登録解除

OracleインスタンスおよびそのOracleインスタンス内のすべてのコンポーネントの登録を解除するには、opmnctl unregisterinstanceを使用します。構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl unregisterinstance
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl unregisterinstance -adminHost myhost \
-adminPort 7001 -adminUsername weblogic \

WebLogic管理サーバーのデフォルト管理ポートは7001です。

10.6 OPMNCTLを使用したOracleインスタンスのコンポーネント登録の更新

Oracle Virtual Directoryコンポーネントの登録を変更した後に、登録済のOracleインスタンスのOracle Virtual Directoryコンポーネントの登録を更新するには、opmnctl updatecomponentregistrationを使用します。opmnctl updatecomponentregistrationコマンドは、Oracle Virtual Directoryコンポーネントのlisteners.os_xmlおよびserver.os_xmlファイルを使用して、Oracle Virtual Directoryコンポーネントの登録を更新します。

opmnctl updatecomponentregistrationの構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']
[-componentType OVD]
-componentName componentName
[-Host OVD_HOST_NAME]

注意:

- -Hostオプションを使用しない場合は、listeners.os_xmlに含まれる値が使用されます。

- パラメータcomponentNameおよびcomponentTypeは、どちらも必須です。

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost myhost \
-adminPort 7001 -adminUsername weblogic -componentType OVD -componentName ovd1

10.7 OPMNCTLを使用したOracle Virtual Directoryコンポーネントの削除

Oracle Virtual Directoryコンポーネントを削除するには、opmnctl deletecomponentを使用します。構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl deletecomponent
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']
[-componentType ovd]
-componentName componentName

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl deletecomponent -adminHost myhost -adminPort 7001 \
-adminUsername weblogic -componentType OVD -componentName ovd1

10.8 OPMNCTLを使用したアクティブなサーバー・インスタンス情報の表示

opmnctlを使用してコンポーネントとプロセスのステータスを表示するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl status -l

注意:
Oracle Virtual Directoryの両方のHTTPエンドポイント(AdminおよびWebGateway)は、同じプロトコル名httpを持ちます。ただし、opmnctl status -lコマンドを使用せずに、opmnctl debug コマンドに示されている説明を使用してこの2つを区別できます。
Oracle Enterprise Manager Fusion Middleware Controlでは、サーバーのポート情報の表示中は説明フィールドは表示されません。

10.9 OPMNCTLを使用したOracle Virtual Directoryサーバーの起動

通常、1つ目のOracle Virtual Directoryコンポーネントのコンポーネント名はovd1です。

1つ目のOracle Virtual Directoryコンポーネントを起動するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

すべてのOracle Virtual Directoryコンポーネントを起動するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl startproc process-type=OVD

すべてのコンポーネントを起動するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl startall

10.10 OPMNCTLを使用したOracle Virtual Directoryサーバーの停止

1つ目のOracle Virtual Directoryコンポーネントを停止するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

すべてのOracle Virtual Directoryコンポーネントを停止するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl stopproc process-type=OVD

すべてのコンポーネントを停止するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl stopall

10.11 OPMNCTLを使用したOracle Virtual Directoryサーバーの再起動

opmnctl restartprocコマンドは、Oracle Virtual Directory構成はリロードするものの現在のOracle Virtual Directoryサーバー・プロセスは中断しない、Oracle Virtual Directoryサーバーの「ソフト」再起動を実行します。

1つ目のOracle Virtual Directoryコンポーネントを再起動するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ovd1

すべてのOracle Virtual Directoryコンポーネントを再起動するには、次の構文を使用します。

$ORACLE_INSTANCE/bin/opmnctl restartproc process-type=OVD

11 Oracle Virtual Directoryリスナーの作成および管理

この章では、Oracle Virtual Directoryリスナーの作成方法について説明します。この章の内容は次のとおりです。

- 第11.1項「リスナーとは」

- 第11.2項「デフォルトOracle Virtual Directoryリスナーの概要」

- 第11.3項「権限ポートでリスニングするためのOracle Virtual Directoryの構成」

- 第11.4項「Fusion Middleware Controlを使用したリスナーの作成および管理」

- 第11.5項「WLSTを使用したリスナーの管理」

- 第11.6項「SSLを使用したリスナーの保護」

11.1 リスナーとは

Oracle Virtual Directoryは、リスナーと呼ばれる接続を介してクライアントにサービスを提供します。Oracle Virtual Directoryでは次の2つのタイプのリスナーがサポートされています。

- LDAP: LDAPv2/v3ベースのサービスを提供

- HTTP: DSMLv2などの1つ以上のサービス、またはXSLT対応のWebゲートウェイにより提供される基本的なホワイト・ページ機能を提供

Oracle Virtual Directoryの構成では、任意の数のリスナーを設定できます。また、リスナーを設定しないことにより、アクセスを管理ゲートウェイのみに制限することもできます。ほとんどのOracle Virtual Directoryのデプロイでは、2つのHTTPリスナーと2つのLDAPリスナーが必要になります。この場合、各プロトコルで一方のリスナーがSSL、もう一方が非SSLに使用されます。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。これが該当するのは、リスナーの作成、更新または削除後です。

11.2 デフォルトOracle Virtual Directoryリスナーの概要

Oracle Virtual Directoryには、デフォルトで、管理ゲートウェイと呼ばれるHTTPリスナーと、LDAP SSLエンドポイントと呼ばれるLDAPリスナーの2つのリスナーが含まれています。

管理ゲートウェイ

管理ゲートウェイと呼ばれるHTTPリスナーは、Oracle Virtual Directoryサーバーが、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースとの通信に使用するインタフェースです。管理ゲートウェイ・リスナーを無効化すると、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースを使用してOracle Virtual Directoryと通信できません。Oracle Virtual Directoryの管理リスナー設定の編集の詳細は、「Oracle Virtual Directoryの管理リスナー設定の編集」を参照してください。

LDAP SSLエンドポイント

LDAP SSLエンドポイントと呼ばれるLDAPリスナーは、Oracle Virtual DirectoryがOracle Enterprise Manager Fusion Middleware Controlのパフォーマンス・メトリックを提供するために使用するインタフェースです。LDAP SSLエンドポイントは、常に有効化し、SSLサーバー認証を使用して保護する必要があります。LDAP SSLエンドポイントは、削除または無効化しないでください。異なるSSLモードを使用して保護されているLDAPリスナーが必要な場合は、Oracle Enterprise Manager Fusion Middleware Controlを使用して新しいリスナーを作成してください。

11.2.1 Oracle Virtual DirectoryとFusion Middleware Controlとの間の通信の管理

デフォルト・リスナー(管理ゲートウェイおよびLDAP SSLエンドポイント)の次のいずれかの設定を編集すると、Oracle Virtual DirectoryとOracle Enterprise Manager Fusion Middleware Control間の通信は中断されます。

- リスナー・ホスト

- リスナー・ポート

- SSLの有効化/無効化

デフォルト・リスナーのこれらの設定を編集する場合は、Oracle Virtual DirectoryとOracle Enterprise Manager Fusion Middleware Controlが通信できるように、Oracle Enterprise Manager Fusion Middleware Controlのターゲットの検出情報を更新する必要があります。

Oracle Enterprise Manager Fusion Middleware Controlのターゲットの検出情報を更新するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. ナビゲーション・ツリーで「ファーム」エントリを右クリックし、「エージェントの監視中のターゲット」を選択します。「エージェントの監視中のターゲット」画面が表示されます。

3. 「ターゲット」表で適切なOracle Virtual Directoryターゲットの「構成」ボタンをクリックします。「ターゲットの構成」画面が表示されます。

4. 現在のOracle Virtual Directory環境に合せて次の設定を更新し、「ターゲットの構成」ページ上部の「OK」をクリックします。

- マシン名

- 仮想ディレクトリのAdminポート

- 仮想ディレクトリのLDAPポート

関連項目:
『管理者ガイド』のトラブルシューティングに関する付録。

11.3 権限ポートでリスニングするためのOracle Virtual Directoryの構成

UNIXまたはLinuxプラットフォーム上でOracle Virtual Directory 11gリリース1 (11.1.1.2.0)以降が権限ポート(1024未満のポート番号)でリスニングできるようにするには、次の手順を実行します。

注意:
ドメインにOracle Virtual Directoryコンポーネントのみが含まれている場合、個別にOracle Virtual Directoryを停止および起動するには、手順2および手順7を実行するかわりに、次のコマンドを使用する必要があります。
Oracle Virtual Directoryを停止するには、次を入力します。

$ORACLE_HOME/bin/hasocket $ORACLE_INSTANCE/bin/opmnctl stopproc
ias-component=ovd1

Oracle Virtual Directoryを起動するには、次を入力します。

$ORACLE_HOME/bin/hasocket $ORACLE_INSTANCE/bin/opmnctl startproc
ias-component=ovd1

Oracle Virtual Directoryがドメインでただ1つのコンポーネントの場合、opmnctl stopallおよびopmnctl startallコマンドの使用によって、Oracle Virtual Directoryによる権限ポートのリスニングが回避されます。

1. Oracle Virtual Directoryをインストールしたときと同じユーザーとして、cap.oraファイルを次のように作成します。

echo `id -ng`: bind  > /tmp/cap.ora

2. Oracle Process Manager and Notification Server (OPMN)制御コマンドを使用してすべてのコンポーネントを停止します。

$ORACLE_INSTANCE/bin/opmnctl stopall

3. rootユーザー権限に変更します。

su root

4. 次の手順を実行することでORACLE_HOME/bin/hasbindファイルを更新します。

1. 次のようにしてファイルの所有権をrootに変更します。

chown root $ORACLE_HOME/bin/hasbind

2. ファイルの権限を次のように変更します。

chmod 4755 $ORACLE_HOME/bin/hasbind

5. 手順1で作成したcap.oraファイルを/etc/ディレクトリにコピーします。

cp /tmp/cap.ora /etc/cap.ora

6. /etc/cap.oraファイルの権限を次のように変更します。

chmod 644 /etc/cap.ora

7. Oracle Virtual Directoryをインストールしたときと同じユーザーとして次のコマンドを使用することでOracle Virtual Directoryを起動し、それが特権ポート上でリスニングできるようにします。

$ORACLE_HOME/bin/hasocket $ORACLE_INSTANCE/bin/opmnctl startall

注意:
単にこのコマンドを使用してそれを起動することで、Oracle Virtual Directoryが特権ポートでリスニングできるようになります。

この手順を実行すると、Oracle Virtual Directoryリスナーは特権ポートでリスニングできます。新しいリスナーを作成して特権ポート番号を入力するか、または既存のリスナーを特権ポート番号を使用するように編集できます。

11.4 Fusion Middleware Controlを使用したリスナーの作成および管理

この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directoryのリスナーを作成および管理する方法について説明します。この項の内容は次のとおりです。

- LDAPリスナーの作成

- HTTPリスナーの作成

- Oracle Virtual DirectoryのTLSリスナーの構成

- リスナーの管理

11.4.1 LDAPリスナーの作成

Oracle Enterprise Manager Fusion Middleware Controlを使用してLDAPリスナーを作成するには、次の手順を実行します。通常、セキュアなLDAPと非セキュアなLDAPを実行する場合、通常のLDAP用に1つ(デフォルト・ポートは6501)とSSLを使用するセキュアなLDAP用に1つ(デフォルト・ポートは7501)の少なくとも2つのリスナーが構成されています。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、LDAPリスナーを作成するOracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。「リスナー」画面が表示されます。

3. 「作成」ボタンをクリックします。「リスナーの追加」画面が表示されます。

4. 「リスナー・タイプ」リストから「LDAP」 を選択し、表11-1で説明されているLDAPリスナー構成パラメータの値を設定します。

表11-1 LDAPリスナー構成パラメータ

型

パラメータ

説明

基本

リスナー名

リスナーの名前。「リスナー名」パラメータの値には、ASCII文字のみを使用してください。非ASCII文字はサポートされていません。

さらに、次の文字はリスナー名に使用しないでください。

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^空白、またはタブ

リスナー・ホスト

リスナーがクライアントからの接続のリスニングに使用する必要があるIPアドレスを指定します。このパラメータに値を指定しないか、または0.0.0.0を指定する場合、デフォルトでOracle Virtual DirectoryはすべてのIPアドレスでリスニングします。

注意: 「リスナー・ホスト」設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

このパラメータに1つのIPアドレスまたはホストを設定すると、リスナーは、そのIPアドレスまたはホストが仮想的か実在かを問わず、そのIPアドレスまたはホストを使用してクライアントからの接続をリスニングします。

リスナー・ポート

リスナーがサービスを提供するポート番号。ポートでアクティブ化できるサーバーごとのリスナーは、常に1つのみです。

既存のサーバー(たとえばActive Directoryドメイン・コントローラ)と同じサーバー上にOracle Virtual Directoryがインストールされている場合は、既存のサービスと競合しないポートを入力します。

スレッド

着信リクエストを同時に処理するためにリスナーにより使用されるアクティブなワーカー・スレッドの数。入力した数が不十分な場合は、スレッドの数がリスナーによって自動的に増加されます。この初期設定は、Oracle Virtual Directoryに対して、リソースを事前に割り当てるために必要な同時クライアントの数を示します。デフォルトの設定は10で、テスト目的には十分です。本番環境では、この設定を50に引き上げることをお薦めします。

リスナーが有効

サービスに対してリスナーを有効(選択する)または無効(選択しない)にします。

LDAPオプション

匿名バインド

Oracle Virtual DirectoryによるLDAP匿名認証方法を制御します。「許可」は、匿名認証を許可します。「拒否」は匿名操作を阻止します。「DenyDNOnly」は空のパスワード認証を阻止します。

注意: LDAPプロトコル仕様によると、LDAPクライアントが空でないDNと未設定のパスワードを使用してLDAPサーバーに接続する場合、LDAPサーバーは匿名バインドを提供することになっています。認証にLDAPを使用しているアプリケーションの場合、このような方式ではパスワードを入力せずにエンドユーザーにアプリケーションへのログインを許可することになります。ほとんどのLDAP対応アプリケーションでは、このような使用が防止されています。しかし、補足的な保護策として、このような状況を防止するようにOracle Virtual Directoryを構成することで、保護をさらに強化できます。

ワーク・キュー許容量

LDAPリスナーに関連付けられたすべてのワーカー・スレッドがリクエストの処理中に累積できる保留中のLDAPリクエストの最大数を指定します。指定した許容量に達すると、LDAPリスナーはDSAはビジー状態ですというエラーで新規リクエストを拒否します。デフォルト値は1024です。

StartTLSの許可

LDAPクライアントがStartTLSを使用可能かどうかを指定します。有効にすると、LDAPリスナーによりクライアントはStartTLS拡張操作の使用を許可され、保護されていないチャネルを介してセキュアな通信を開始できます。

ソケット・オプション

バックログ

サーバーにより新しい接続の試みの拒否が開始される前に累積できる保留中の接続リクエストの最大数を指定します。デフォルト設定は128です。

読取りタイムアウト

指定されたタイムアウト期間(ミリ秒)の間、アイドル状態のクライアント接続の許容を有効または無効にします。ゼロ以外の時間を設定すると、Oracle Virtual Directoryサーバーへのクライアント接続は、指定された時間のみアイドル状態でいることができます。クライアント接続が指定された時間以上の間アイドル状態だと、クライアント接続は終了します。値0は無限タイムアウトとみなされます。デフォルト値は0です。

アドレスの再利用

LDAPリスナーがソケット記述子を再利用する必要があるかどうかを指定します。有効にすると、TIME_WAIT状態のクライアントのソケット記述子を再利用できます。

TCPキープ・アライブ

LDAP接続がTCPキープ・アライブを使用する必要があるかどうかを指定します。有効にすると、関連付けられた接続が有効なことを確認するために、TCPキープ・アライブ・メッセージが定期的にクライアントに送信されます。

TCP遅延なし

LDAP接続がTCP遅延なしを使用する必要があるかどうかを指定します。有効にすると、同一のパケットで追加の応答メッセージを送信可能かを判断するのを待たずに、クライアントへの応答メッセージが即座に送信されます。

5. 「リスナーの追加」画面で「OK」ボタンをクリックし、LDAPリスナーを保存します。

6. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.4.2 HTTPリスナーの作成

Oracle Enterprise Manager Fusion Middleware Controlを使用してHTTPリスナーを作成するには、次の手順を実行します。

関連項目:
HTTPリスナーのWebゲートウェイ設定の詳細は、付録C「HTTPリスナーのWebゲートウェイ・サービス」を参照してください。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、HTTPリスナーを作成するOracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。「リスナー」画面が表示されます。

3. 「作成」ボタンをクリックします。「リスナーの追加」画面が表示されます。

4. 「リスナー・タイプ」リストから「HTTP」 を選択し、表11-2で説明されているHTTPリスナー構成パラメータの値を設定します。

表11-2 HTTPリスナー構成パラメータ

型

パラメータ

説明

基本

リスナー名

リスナーの名前。「リスナー名」パラメータの値には、ASCII文字のみを使用してください。非ASCII文字はサポートされていません。

リスナー・ホスト

リスナーがクライアントからの接続のリスニングに使用する必要があるIPアドレスを指定します。このパラメータに値を指定しないか、または0.0.0.0を指定する場合、デフォルトでOracle Virtual DirectoryはすべてのIPアドレスでリスニングします。

注意: 「リスナー・ホスト」設定には、
127.0.0.1、 :0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

このパラメータに1つのIPアドレスまたはホストを設定すると、リスナーは、そのIPアドレスまたはホストが仮想的か実在かを問わず、そのIPアドレスまたはホストを使用してクライアントからの接続をリスニングします。

リスナー・ポート

リスナーがサービスを提供するポート番号。ポートでアクティブ化できるサーバーごとのリスナーは、常に1つのみです。

スレッド

着信リクエストを同時に処理するためにリスナーにより使用されるアクティブなワーカー・スレッドの数。入力した数が不十分な場合は、スレッドの数がリスナーによって自動的に増加されます。この初期設定は、Oracle Virtual Directoryに対して、リソースを事前に割り当てるために必要な同時クライアントの数を示します。デフォルトの設定は10で、テスト目的には十分です。本番環境では、この設定を50に引き上げることをお薦めします。

リスナーが有効

サービスに対してリスナーを有効(選択する)または無効(選択しない)にします。

DSML V2サービス

レルム名

DSMLv2サービスのセキュリティが有効な場合に、Oracle Virtual DirectoryでDSML V2サービスを保護するために使用されるレルム名。このレルム名は、ユーザーへのHTTPブラウザ・チャレンジに表示されます。

Webゲートウェイ・サービス・セクション

匿名アクセスを許す

Webゲートウェイへの匿名アクセスを有効または無効にします。

検索ルート

Webゲートウェイが、ユーザー認証チャレンジ後に、指定されたユーザー識別名(UID)の検索を開始するサブツリーを含むディレクトリ・ツリーのルート識別名(ネームスペース)。

検索属性

UIDの検索時にWebゲートウェイが照合を試行する属性。

ユーザー・オブジェクト・クラス

認証するユーザーの検索時にWebゲートウェイが使用するオブジェクト・クラス。

結果キャッシュ・ライフ時間(秒)

ディレクトリ・ソースに格納されているユーザー資格証明を再度問い合せるまでにOracle Virtual Directoryが待機する最大時間。

HTDocsパス

Oracle Virtual Directoryのルート・インストールに相対的で、XSLTファイルおよびHTMLファイルが格納されるパス。

証明書属性

バイナリPKI証明書情報を含む属性を指定します。デフォルト値はusercertificateです。

写真/イメージ属性

グラフィック・イメージを含む属性を指定します。デフォルト値はjpegphotoです。

画像表示の高さ

Web Gatewayが写真を調整する高さ。デフォルト値は100です。

画像表示の幅

Web Gatewayが写真を調整する幅。デフォルト値は100です。

5. 「リスナーの追加」画面で「OK」ボタンをクリックし、HTTPリスナーを保存します。

6. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.4.3 Oracle Virtual DirectoryのTLSリスナーの構成

この項の情報を使用して、Oracle Virtual DirectoryのTLSリスナーを構成およびテストします(たとえば、非SSLポート上のセキュアな接続をネゴシエートできるようにするSTART_TLS拡張を必要とする場合など)。

1. TLS接続を保護するには、既存の即時利用可能なkeys.jksを使用するか、次に示すように新しいキーストアを作成します。

Oracle Virtual Directoryを開き、「セキュリティ」→「キーストア」に移動します。

1. TLS用にTLSKeyStore.jksという名前の新しいキーストアを作成します。

2. 証明書のCNが完全修飾ホスト名と一致していることを保証する自己署名証明書を追加します。

2. ovd1→「管理」→「リスナー」に移動し、次のパラメータを指定して新しいTNSリスナーを作成します。

- タイプ: LDAP

- リスナー名: TLS

- リスナー・ポート: 9999

- リスナーが有効:

- 匿名暗号を含める: Not checked

- 匿名バインド: Allow

- StartTLSの許可: 確認

3. 新しいTLSリスナーを選択し、「編集」をクリックします。

1. 「匿名暗号を含める」パラメータを選択(クリック)します。

2. 「SSL設定の変更」セクションで次のパラメータを指定します。

SSLの有効化

このボックスを選択(クリック)してください。
このセクションのその他のパラメータが編集可能になります。

「サーバー・キーストア」および「トラストストア」

これらのパラメータが、使用するキーストア(手順1を参照)に一致していること、およびそのキーストアとトラストストアにパスワードが設定してあることを確認します。

3. 「詳細設定」セクションで次のパラメータの設定を指定します。

SSL認証

サーバー認証。

すべて

このボックスを選択(クリック)してください。

SSLプロトコル・バージョン

ドロップダウン・メニューから「すべて」を選択し、v3の選択を解除します。エントリはv1;v2Helloになります。

4. Oracle Virtual Directoryを停止するには次のコマンドを使用します。

opmnctl stopproc ias-component=ovd1

5. コマンド・ラインから次の場所に移動し、listners.os_xmlファイルを編集してください。

$ORACLE_INSTANCE/config/OVD/ovd1

注意:
新しいリスナーを使用するGUIインタフェースによってlistners.os_xmlファイルに加えられた更新が正しくないか、あるいは完全ではありません。
cipherSuitesのみがanonCiphersに含まれるように、cipherSuitesセクションで<cipher>のすべての行を削除する必要があります。行は次のようになります。

<cipherSuites includeAnonCiphers="true"/>

6. 新しいTLSリスナーのlistener.os_xmlエントリを確認するには、次のサンプルを使用してください。

<ldap id="TLS" version="3">
<port>9999</port>
<host>0.0.0.0</host>
<threads>10</threads>
<active>true</active>
<ssl enabled="true">
<protocols>TLSv1,SSLv2Hello</protocols>
<cipherSuites includeAnonCiphers="true"/>
<authType>Server</authType>
<keyStore password="{AES-CBC}b2vWJAN48ufpbxla9gohlj/M+eBP/9FLwh6tLfiWF0o=">
TLSkeyStore.jks</keyStore>
<trustStore password="{AES-CBC}rOk44ucwkpQ2QRcTDK4bJRklj/OmALyUWQMjQAYoNJY=">
TLSkeyStore.jks</trustStore>
</ssl>
<extendedOps/>
<anonymousBind>Allow</anonymousBind>
<workQueueCapacity>100</workQueueCapacity>
<allowStartTLS>true</allowStartTLS>
<socketOptions>
<backlog>128</backlog>
<reuseAddress>false</reuseAddress>
<keepAlive>false</keepAlive>
<tcpNoDelay>true</tcpNoDelay>
<readTimeout>0</readTimeout>
</socketOptions>
<useNIO>false</useNIO>
</ldap>

7. 次のコマンドを使用して、Oracle Virtual Directoryを起動します。

opmnctl startproc ias-component=ovd1

8. Apache Directory Studioなど、TLSをサポートするクライアントを使用してTLSをテストします。
次に例を示します。

1. Apache Directory Studioを起動し、「LDAP」→「新規接続」をクリックします。

2. ネットワーク・パラメータの画面で、次のパラメータを設定します。

ホスト名

証明書のCNと一致する完全修飾ホスト名を入力します。

ポート

9999(あるいは使用したポート)

暗号化方法

StartTLS拡張を使用します。

3. ネットワーク・パラメータの確認をクリックします。

4. 証明書を受け入れるように促すポップアップが表示されたら、「次」をクリックします。

5. 「認証」画面が表示されたら、次のパラメータを設定します。

バインドDNの入力:

cn=orcladmin

バインド・パスワードの入力:

welcome1

9. 「終了」をクリックし、ベース・コンテナを確認します。

セキュアな接続を介してディレクトリを参照できます。

11.4.4 リスナーの管理

この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directoryのリスナーを管理する方法について説明します。この項の内容は次のとおりです。

- リスナー設定の編集

- リスナーの削除

11.4.4.1 リスナー設定の編集

Oracle Enterprise Manager Fusion Middleware Controlを使用して既存のリスナー(LDAPまたはHTTP)の設定を更新するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、編集するリスナーが存在するOracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。既存のリスナーが表示された「リスナー」画面が表示されます。

3. 編集するリスナーをクリックして選択します。

4. 「編集」ボタンをクリックします。リスナーの現在の設定が表示された「リスナーの編集」画面が表示されます。

5. 必要に応じて設定を編集します。
LDAPリスナーの各パラメータの詳細は、表11-1「LDAPリスナーの構成パラメータ」を参照してください。

HTTPリスナーの各パラメータの詳細は、表11-2「HTTPリスナーの構成パラメータ」を参照してください。

6. 「リスナーの追加」画面で「OK」ボタンをクリックし、HTTPリスナーを保存します。

7. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.4.4.1.1 Oracle Virtual Directoryの管理リスナー設定の編集

Oracle Virtual Directoryの管理リスナーの設定は、LDAPまたはHTTPリスナーの設定を編集する際と同じように編集できます。ただし、管理ゲートウェイ・リスナーを無効化すると、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。管理リスナーの詳細は、「デフォルトOracle Virtual Directoryリスナーの概要」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlを使用して管理ゲートウェイ・リスナーの設定を編集するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、Oracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。既存のリスナーが表示された「リスナー」画面が表示されます。

3. 管理ゲートウェイ・リスナーをクリックして選択します。

4. 「編集」ボタンをクリックします。管理ゲートウェイ・リスナーの現在の設定が表示された「リスナーの編集」画面が表示されます。

5. 管理リスナー設定を必要に応じて編集し、「発行」をクリックします。各管理リスナー設定は、後の「管理リスナー設定」の項で説明します。

6. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

7. opmnctl updatecomponentregistrationコマンドを使用して、編集した管理リスナーが含まれるOracle Virtual Directoryコンポーネントの登録を更新します。
opmnctl updatecomponentregistrationの構文は次のとおりです。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration
[-adminHost hostname]
[-adminPort weblogic_port]
[-adminUsername weblogic_admin]
[-adminPasswordFile 'FILE_WITH_WEBLOGIC_ADMIN_PASSWORD']
[-componentType OVD]
-componentName componentName
[-Host OVD_HOST_NAME]

注意:

- -Hostオプションを使用しない場合は、listeners.os_xmlの値が使用されます。

- パラメータcomponentNameおよびcomponentTypeは、どちらも必須です。

次に例を示します。

$ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost myhost \
-adminPort 7001 -adminUsername weblogic -componentType OVD -componentName ovd1

管理リスナー設定

リスナー・ホスト

Oracle Virtual Directoryサーバーが稼働しているホストの名前またはIPアドレス。デフォルト値は0.0.0.0です。これにより、ホストに対して構成されているすべてのIPアドレスで管理リスナーがリスニングするように設定されます。

注意:

- 「リスナー・ホスト」設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

- 「ホスト」設定を編集する場合は、即座に手順6を実行する必要があります。実行しないと、Oracle Enterprise Manager Fusion Middleware Controlユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。

リスナー・ポート

Oracle Virtual Directoryが管理サービスを提供するポート。Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlユーザー・インタフェースでは、このポートを使用してOracle Virtual Directoryサーバーと通信します。

注意:
「リスナー・ポート」設定を編集する場合は、即座に手順6を実行する必要があります。実行しないと、Oracle Enterprise Manager Fusion Middleware Controlユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。

スレッド

着信リクエストを同時に処理するためにリスナーにより使用されるアクティブなワーカー・スレッドの数。

リスナーが有効

サービスに対してリスナーを有効化する場合に選択します。ただし、管理ゲートウェイ・リスナーを無効化すると、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。デフォルト設定は「有効」です。

SSL設定の変更

リスナーの現在のSSL設定(有効または無効)を表示し、リスナーのSSL設定を変更するためのリンクを提供します。リスナーのSSL設定を編集するには、リンクをクリックします。詳細は、「Fusion Middleware Controlを使用したリスナーに対するSSLの構成」を参照してください。

注意:
SSL設定(「有効」または「無効」)を編集する場合は、「OPMNCTLを使用したOracleインスタンスのコンポーネント登録の更新」を参照してOracle Virtual Directoryコンポーネントの登録を更新する必要があります。SSL設定を編集した後にOracle Virtual Directoryコンポーネント登録を更新しないと、Oracle Enterprise Manager Fusion Middleware Controlユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。

11.4.4.2 リスナーの削除

Oracle Enterprise Manager Fusion Middleware Controlを使用して既存のリスナー(LDAPまたはHTTP)を削除するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、削除するリスナーが存在するOracle Virtual Directoryターゲットにナビゲートします。

2. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。既存のリスナーが表示された「リスナー」画面が表示されます。

3. 削除するリスナーをクリックします。

4. 「削除」ボタンをクリックします。リスナーの削除の確認を要求するダイアログ・ボックスが表示されます。

5. ダイアログ・ボックスで「OK」をクリックし、リスナーを削除します。既存のリスナーのリストからリスナーが削除されます。

6. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.5 WLSTを使用したリスナーの管理

この項では、WLSTを使用してOracle Virtual Directoryのリスナーを管理する方法について説明します。この項の内容は次のとおりです。

- リスナー設定の更新

- リスナーの削除

関連項目:

- WLSTコマンドライン・ツールの使用方法の詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

- WLSTコマンド・ツール構文の詳細は、『WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

11.5.1 リスナー設定の更新

WLSTを使用して、次のように既存のリスナーの設定を更新できます。

1. WLSTコマンドライン・ツール・シェルを起動します。

2. WebLogic管理サーバーに接続します。次に例を示します。

connect('username', 'password','t3://host_name:Admin_Server_Port')

3. Oracle Virtual Directoryルート・プロキシMBeanノードに移動し、MBeanを初期化します。次に例を示します。

custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=asin
st1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

4. 更新するリスナーのMBeanノードに移動します。次にLDAP SSL Endpointという名前のリスナーの例を示します。

cd('../..')
cd('oracle.as.ovd')
cd('oracle.as.ovd:type=component.Listenersconfig.sslconfig,name=LDAP SSL
Endpoint,instance=asinst_1,component=ovd1')

5. WLST set()コマンドを使用して、適切な設定を更新します。次に、Threads設定を更新する例を示します。

set('Threads', 20)

注意:

- Host設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

- 管理リスナーのHost、Port、またはSSL設定を編集する場合は、「OPMNCTLを使用したOracleインスタンスのコンポーネント登録の更新」を参照してOracle Virtual Directoryコンポーネントの登録を更新する必要があります。管理リスナーのこれらのいずれかの設定を編集した後にOracle Virtual Directoryコンポーネント登録を更新しないと、WLSTを使用してOracle Virtual Directoryと通信できなくなります。

関連項目:
WLSTを使用したリスナーの設定の詳細は、次の項を参照してください。

- WLSTを使用した管理リスナーの設定の構成

- WLSTを使用したLDAPリスナーの設定の構成

- WLSTを使用したHTTPリスナーの設定の構成

6. 変更を保存してから、MBeanをリフレッシュします。次に例を示します。

cd('../..')
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=asin
st1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

7. 稼働している場合、Oracle Virtual Directoryサーバーを停止します。停止した後、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.5.1.1 WLSTを使用した管理リスナーの設定の構成

次に、WLSTを使用して構成できる管理リスナー設定のリストと説明を示します。

関連項目:
管理リスナーの詳細は、「デフォルトOracle Virtual Directoryリスナーの概要」を参照してください。

アクティブ

リスナーの有効化または無効化を指定します。サポートされている値は、trueおよびfalseです。管理リスナーを無効化すると、Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlのユーザー・インタフェースを使用してOracle Virtual Directoryと通信できなくなります。

AuthenticationType

リスナーの認証モードを指定します。サポートされている値は、None、Server、およびMutualです。

- Noneでは、リスナーはSSL認証なしのモードに構成されます。

- Serverでは、リスナーはSSLサーバー認証モードに構成されます。

- Mutualでは、リスナーはSSL相互認証モードに構成されます。

BindAddress

Host設定をInetAddressで表現した値。BindAddress設定を編集すると、Host設定も変更されます。逆に、Host設定を編集すると、BindAddress設定も変更されます。

Ciphers

セキュアなコミュニケーションの開始または検証に使用されるSSLハンドシェイクの一部である暗号スイート・ネゴシエーションを構成します。暗号スイートは、認証、キー・アグリーメント、暗号化、整合性保護に使用されるセキュリティ・アルゴリズムと鍵サイズを定義する暗号パラメータの組合せです。デフォルト値はnullで、すべての暗号化スイートがサポートされていることを示します。リストに暗号化スイートが含まれる場合、それらの暗号化スイートのみがリスナーによって受け入れられます。

次に、Ciphers設定でサポートされている値のリストを示します。

- SSL_RSA_WITH_RC4_128_MD5

- SSL_RSA_WITH_RC4_128_SHA

- SSL_RSA_WITH_3DES_EDE_CBC_SHA

- SSL_RSA_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_RC4_128_MD5

- SSL_DH_anon_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

- TLS_RSA_WITH_AES_128_CBC_SHA

- TLS_RSA_WITH_AES_256_CBC_SHA

注意:
Enterprise Managerで追加のリスナーを構成すると、Enterprise Manager GUIにより「サーバーSSLプロパティ」領域にチェックボックスおよび暗号化のリストが表示され、ユーザーは構成する暗号化を選択できます。

GroupUrl

管理リスナーを使用する権限を持つユーザー・グループを定義するLDAP URL。これらのユーザーは、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Directory Services Managerのインタフェースを通じてOracle Virtual Directoryサーバーにアクセスするときに、rootに近い権限を持ちます。

Host

Oracle Virtual Directoryサーバーが稼働しているホストの名前またはIPアドレス。デフォルト値は0.0.0.0です。これにより、ホストに対して構成されているすべてのIPアドレスで管理リスナーがリスニングするように設定されます。

注意:
Host設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

KeyStore

SSLアーティファクトを含むJKSキーストアの名前。

Name

リスナーの名前。

Port

Oracle Virtual Directoryが管理サービスを提供するポート。Oracle Directory Services ManagerおよびOracle Enterprise Manager Fusion Middleware Controlユーザー・インタフェースでは、このポートを使用してOracle Virtual Directoryサーバーと通信します。

Protocol

管理リスナーがサービスの提供に使用するプロトコル。サポートされている値は、HTTPおよびHTTPSです。

SSLEnabled

リスナー上でSSLを有効化するかどうかを指定します。サポートされている値は、trueおよびfalseです。

SSLVersions

SSL通信でサポートされているプロトコル。次の値がサポートされています。

- TLSv1

- SSLv2Hello

注意:
SSLv2Hello値のみを指定することはできません。SSLv2Helloを指定する場合は、サポートされている他のバージョンを少なくとも1つ指定する必要があります。

- SSLv3

スレッド

リスナーがポート上の接続のリスニングに使用するアクティブなワーカー・スレッドの数。

TrustStore

SSLアーティファクトを含むJKSキーストアの名前。

11.5.1.2 WLSTを使用したLDAPリスナーの設定の構成

次に、WLSTを使用して構成できるLDAPリスナー設定のリストと説明を示します。

アクティブ

リスナーの有効化または無効化を指定します。サポートされている値は、trueおよびfalseです。

AllowStartTLS

LDAPクライアントがStartTLSを使用可能かどうかを指定します。有効にすると、LDAPリスナーによりクライアントはStartTLS拡張操作の使用を許可され、保護されていないチャネルを介してセキュアな通信を開始できます。サポートされている値は、trueおよびfalseです。デフォルト値はfalseです。

AnonymousBind

Oracle Virtual DirectoryによるLDAP匿名認証方法を制御します。サポートされている値を表11-3に示します。

表11-3 LDAP匿名認証オプション

オプション

制御

Allow

匿名認証が許可されます。

Deny

匿名での操作はできません。

DenyDNOnly

パスワード未設定の場合、認証できません。

注意: LDAPプロトコル仕様によると、LDAPクライアントが空でないDNと未設定のパスワードを使用してLDAPサーバーに接続する場合、LDAPサーバーは匿名バインドを提供することになっています。認証にLDAPを使用しているアプリケーションの場合、このような方式ではパスワードを入力せずにエンドユーザーにアプリケーションへのログインを許可することになります。ほとんどのLDAP対応アプリケーションでは、このような使用が防止されています。しかし、補足的な保護策として、このような状況を防止するようにOracle Virtual Directoryを構成することで、保護をさらに強化できます。

AuthenticationType

リスナーの認証モードを指定します。サポートされている値は、None、Server、およびMutualです。

- Noneでは、リスナーはSSL認証なしのモードに構成されます。

- Serverでは、リスナーはSSLサーバー認証モードに構成されます。

- Mutualでは、リスナーはSSL相互認証モードに構成されます。

BindAddress

Host設定をInetAddressで表現した値。BindAddress設定を編集すると、Host設定も変更されます。逆に、Host設定を編集すると、BindAddress設定も変更されます。

Ciphers

セキュアなコミュニケーションの開始または検証に使用されるSSLハンドシェイクの一部である暗号スイート・ネゴシエーションを構成します。暗号スイートは、認証、キー・アグリーメント、暗号化、整合性保護に使用されるセキュリティ・アルゴリズムと鍵サイズを定義する暗号パラメータの組合せです。デフォルト値はnullで、すべての暗号化スイートがサポートされていることを示します。リストに暗号化スイートが含まれる場合、それらの暗号化スイートのみがリスナーによって受け入れられます。次に、Ciphers設定でサポートされている値のリストを示します

次に、Ciphers設定でサポートされている値のリストを示します。

- SSL_RSA_WITH_RC4_128_MD5

- SSL_RSA_WITH_RC4_128_SHA

- SSL_RSA_WITH_3DES_EDE_CBC_SHA

- SSL_RSA_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_RC4_128_MD5

- SSL_DH_anon_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

- TLS_RSA_WITH_AES_128_CBC_SHA

- TLS_RSA_WITH_AES_256_CBC_SHA

注意:
Enterprise Managerで追加のリスナーを構成すると、Enterprise Manager GUIにより「サーバーSSLプロパティ」領域にチェックボックスおよび暗号化のリストが表示され、ユーザーは構成する暗号化を選択できます。

ExtendedOpsClass

この設定を使用すると、LDAPプロトコルによりサポートされている通常のLDAP操作に加えて、独自のLDAP操作を定義できます。この設定は、独自のユーザー定義LDAP操作を実装する完全なJavaクラス名です。

ExtendedOpsOid

ExtendedOpsClass設定で定義したユーザー定義LDAP操作の一意の名前。

Host

Oracle Virtual Directoryサーバーが稼働しているホストの名前またはIPアドレス。デフォルト値は0.0.0.0です。

注意:
Host設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

KeyStore

SSLアーティファクトを含むJKSキーストアの名前。

Name

リスナーの名前。

Port

LDAPリスナーがサービスを提供するポート番号。ポートでアクティブ化できるサーバーごとのリスナーは、常に1つのみです。

Protocol

LDAPリスナーがサービスの提供に使用するプロトコル。サポートされている値はLDAPおよびLDAPSです。

SSLEnabled

リスナー上でSSLを有効化するかどうかを指定します。サポートされている値は、trueおよびfalseです。

SSLVersions

SSL通信でサポートされているプロトコル。次の値がサポートされています。

- TLSv1

- SSLv2Hello

注意:
SSLv2Hello値のみを指定することはできません。SSLv2Helloを指定する場合は、サポートされている他のバージョンを少なくとも1つ指定する必要があります。

- SSLv3

SocketOptionsBacklog

サーバーにより新しい接続の試みの拒否が開始される前に累積できる保留中の接続リクエストの最大数を指定します。デフォルト設定は128です。

SocketOptionsKeepAlive

LDAP接続がTCPキープ・アライブを使用する必要があるかどうかを指定します。有効にすると、関連付けられた接続が有効なことを確認するために、TCPキープ・アライブ・メッセージが定期的にクライアントに送信されます。サポートされている値は、trueおよびfalseです。デフォルト値はfalseです。

SocketOptionsReadTimeout

指定されたタイムアウト期間(ミリ秒)の間、アイドル状態のクライアント接続の許容を有効または無効にします。ゼロ以外の時間を設定すると、Oracle Virtual Directoryサーバーへのクライアント接続は、指定された時間のみアイドル状態でいることができます。クライアント接続が指定された時間以上の間アイドル状態だと、クライアント接続は終了します。値0は無限タイムアウトとみなされます。デフォルト値は0です。

SocketOptionsReuseAddress

LDAPリスナーがソケット記述子を再利用する必要があるかどうかを指定します。有効にすると、TIME_WAIT状態のクライアントのソケット記述子を再利用できます。サポートされている値は、trueおよびfalseです。デフォルト値はfalseです。

SocketOptionsTcpNoDelay

LDAP接続がTCP遅延なしを使用する必要があるかどうかを指定します。有効にすると、同一のパケットで追加の応答メッセージを送信可能かを判断するのを待たずに、クライアントへの応答メッセージが即座に送信されます。サポートされている値は、trueおよびfalseです。デフォルト値はtrueです。

スレッド

着信リクエストを同時に処理するためにリスナーにより使用されるアクティブなワーカー・スレッドの数。指定した数が不十分な場合は、スレッドの数がリスナーによって自動的に増加されます。この初期設定は、Oracle Virtual Directoryに対して、リソースを事前に割り当てるために必要な同時クライアントの数を示します。デフォルトの設定は10で、テスト目的には十分です。本番環境では、この設定を50に引き上げることをお薦めします。

TrustStore

SSLアーティファクトを含むJKSキーストアの名前。

WorkQueueCapacity

LDAPリスナーに関連付けられたすべてのワーカー・スレッドがリクエストの処理中に累積できる保留中のLDAPリクエストの最大数を指定します。指定した許容量に達すると、LDAPリスナーはDSAはビジー状態ですというエラーで新規リクエストを拒否します。デフォルト値は1024です。

注意:
「ディレクトリ・サービス・エージェントがビジー状態です。」エラーは、短時間のうちにOracle Virtual Directoryサーバーに大量のリクエストが送信され、LDAPリスナーがそれらをサポートできないときに表示されます。

11.5.1.3 WLSTを使用したHTTPリスナーの設定の構成

次に、WLSTを使用して構成できるHTTPリスナー設定のリストと説明を示します。

アクティブ

リスナーの有効化または無効化を指定します。サポートされている値は、trueおよびfalseです。

AuthenticationType

リスナーの認証モードを指定します。サポートされている値は、None、Server、およびMutualです。

- Noneでは、リスナーはSSL認証なしのモードに構成されます。

- Serverでは、リスナーはSSLサーバー認証モードに構成されます。

- Mutualでは、リスナーはSSL相互認証モードに構成されます。

BindAddress

Host設定をInetAddressで表現した値。BindAddress設定を編集すると、Host設定も変更されます。逆に、Host設定を編集すると、BindAddress設定も変更されます。

Ciphers

セキュアなコミュニケーションの開始または検証に使用されるSSLハンドシェイクの一部である暗号スイート・ネゴシエーションを構成します。暗号スイートは、認証、キー・アグリーメント、暗号化、整合性保護に使用されるセキュリティ・アルゴリズムと鍵サイズを定義する暗号パラメータの組合せです。デフォルト値はnullで、すべての暗号化スイートがサポートされていることを示します。リストに暗号化スイートが含まれる場合、それらの暗号化スイートのみがリスナーによって受け入れられます。次に、Ciphers設定でサポートされている値のリストを示します

次に、Ciphers設定でサポートされている値のリストを示します。

- SSL_RSA_WITH_RC4_128_MD5

- SSL_RSA_WITH_RC4_128_SHA

- SSL_RSA_WITH_3DES_EDE_CBC_SHA

- SSL_RSA_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_RC4_128_MD5

- SSL_DH_anon_WITH_DES_CBC_SHA

- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA

- TLS_RSA_WITH_AES_128_CBC_SHA

- TLS_RSA_WITH_AES_256_CBC_SHA

注意:
Enterprise Managerで追加のリスナーを構成すると、Enterprise Manager GUIにより「サーバーSSLプロパティ」領域にチェックボックスおよび暗号化のリストが表示され、ユーザーは構成する暗号化を選択できます。

CustomWebappContext

ユーザーが開発したカスタムWebサービスのロケーションのベースURL。

CustomWebappSecurityRealm

カスタムWebサービスのセキュリティが有効な場合に、Oracle Virtual DirectoryでカスタムWebサービスを保護するために使用されるレルム名。

CustomWebappWebapp

HTTPリスナーのWebゲートウェイ、DMSLv2ゲートウェイ、あるいはその両方を使用するかわりに独自のWebアプリケーションを使用してHTTP接続を処理するには、この設定を使用してカスタムWebアプリケーションのwarファイルへのパスを指定します。

Dsmlv2SecurityRealm

DSMLv2サービスのセキュリティが有効な場合に、Oracle Virtual DirectoryでDSML V2サービスを保護するために使用されるレルム名。このレルム名は、ユーザーへのHTTPブラウザ・チャレンジに表示されます。

Host

Oracle Virtual Directoryサーバーが稼働しているホストの名前またはIPアドレス。デフォルト値は0.0.0.0です。

注意:
Host設定には、127.0.0.1、:0:0:1、localhostなどを含むループバックIPアドレスは使用しないでください。

KeyStore

SSLアーティファクトを含むJKSキーストアの名前。

Name

リスナーの名前。

Port

HTTPリスナーがサービスを提供するポート番号。ポートでアクティブ化できるサーバーごとのリスナーは、常に1つのみです。

Protocol

HTTPリスナーがサービスの提供に使用するプロトコル。サポートされている値は、HTTPおよびHTTPSです。

SSLEnabled

リスナー上でSSLを有効化するかどうかを指定します。サポートされている値は、trueおよびfalseです。

SSLVersions

SSL通信でサポートされているプロトコル。次の値がサポートされています。

- TLSv1

- SSLv2Hello

注意:
SSLv2Hello値のみを指定することはできません。SSLv2Helloを指定する場合は、サポートされている他のバージョンを少なくとも1つ指定する必要があります。

- SSLv3

スレッド

着信リクエストを同時に処理するためにリスナーにより使用されるアクティブなワーカー・スレッドの数。指定した数が不十分な場合は、スレッドの数がリスナーによって自動的に増加されます。この初期設定は、Oracle Virtual Directoryに対して、リソースを事前に割り当てるために必要な同時クライアントの数を示します。デフォルトの設定は10で、テスト目的には十分です。本番環境では、この設定を50に引き上げることをお薦めします。

TrustStore

SSLアーティファクトを含むJKSキーストアの名前。

WebgatewayAllowAnon

Webゲートウェイへの匿名アクセスを有効または無効にします。サポートされている値は、trueおよびfalseです。

WebgatewayCertifiedAttributes

バイナリPKI証明書情報を含む属性を指定します。デフォルト値はusercertificateです。

WebgatewayHtDocsRoot

Oracle Virtual Directoryのルート・インストールに相対的で、XSLTファイルおよびHTMLファイルが格納されるパス。

WebgatewayMatchAttributes

UIDの検索時にWebゲートウェイが照合を試行する必要がある属性。デフォルト値は、uid, mail, cnです。

WebgatewayMatchObjectClasses

認証するユーザーの検索時にWebゲートウェイが使用する必要があるオブジェクト・クラス。デフォルト値は、inetorgperson, userです。

WebgatewayPhotoAttributes

グラフィック・イメージを含む属性を指定します。デフォルト値はjpegphotoです。

WebgatewayPhotoHeight

Web Gatewayが写真を調整する高さ。デフォルト値は100です。

WebgatewayPhotoWidth

Web Gatewayが写真を調整する幅。デフォルト値は100です。

WebgatewaySearchRoot

Webゲートウェイが、ユーザー認証チャレンジ後に、指定されたユーザー識別名(UID)の検索を開始するサブツリーを含むディレクトリ・ツリーのルート識別名(ネームスペース)。

WebgatewaySecurityRealm

Webゲートウェイ・サービスのセキュリティが有効な場合に、Oracle Virtual DirectoryでWebゲートウェイ・サービスを保護するために使用されるレルム名。

WebgatewayUserCacheLife

ディレクトリ・ソースに格納されているユーザー資格証明を再度問い合せるまでにOracle Virtual Directoryが待機する最大時間(秒単位)。

11.5.2 リスナーの削除

WLSTを使用して、次のように既存のリスナーを削除できます。

1. WLSTコマンドライン・ツール・シェルを起動します。

2. WebLogic管理サーバーに接続します。次に例を示します。

connect('username', 'password','t3://host_name:Admin_Server_Port')

3. Oracle Virtual Directoryルート・プロキシMBeanノードに移動し、MBeanを初期化します。次に例を示します。

custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=asin
st1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

4. Oracle Virtual Directoryリスナー構成MBeanに移動します。次に例を示します。

cd('../..')
cd('oracle.as.ovd/oracle.as.ovd:type=component.Listenersconfig,name=Listenersco
nfig,instance=asinst1,component=ovd1')

5. 適切なリスナーを削除します。次にtest1という名前のリスナーの例を示します。

invoke('deleteListener',jarray.array([java.lang.String('test1')],java.lang.Obje
ct),jarray.array(['java.lang.String'],java.lang.String))

6. 変更を保存してから、MBeanをリフレッシュします。次に例を示します。

cd('../..')
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=asin
st1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.Strin
g))

7. 稼働している場合、Oracle Virtual Directoryサーバーを停止します。停止した後、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.6 SSLを使用したリスナーの保護

この項では、SSLを使用してOracle Virtual Directoryのリスナーを保護する方法について説明します。この項の内容は次のとおりです。

- 作業の前に

- Fusion Middleware Controlを使用したリスナーに対するSSLの構成

- WLSTを使用したリスナーに対するSSLの構成

- SSL接続の検証

- SSL再ネゴシエーションの制御

注意:
ここでは、単一コンポーネントのSSL構成について説明します。複数のコンポーネントにSSLを構成する場合は、Oracle SSL自動化ツールを使用すると、ドメイン固有のCAを使用して複数のコンポーネントにSSLを構成できます。
Oracle SSL自動化ツールの詳細は、『管理者ガイド』を参照してください。

11.6.1 始める前に

SSLを使用してOracle Virtual Directoryのリスナーを保護する場合、Oracle Virtual Directoryサーバーの完全修飾ホスト名と一致するCNの証明書、およびクライアント・アプリケーションで必要とされる証明書を作成する必要があります。一致しない場合、バインドが失敗します。

Oracle Virtual DirectoryリスナーにSSLを構成する前に、8.3.6.2.2項「SSLサーバーのみ認証」および『RFC 4513, LDAP Authentication Methods』を参照してください。

http://www.rfc-editor.org/rfc/rfc4513.txt

11.6.2 Fusion Middleware Controlを使用したリスナーでのSSLの構成

Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Virtual Directoryのリスナーを保護するには、次の手順を実行します。

注意:
リスナーをSSL認証なしモードに構成しているときは、次の手順の手順2および手順3eから3hを実行しないでください。

関連項目:
『管理者ガイド』のOracle Virtual DirectoryリスナーのSSLを有効化する方法に関する情報。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、SSLを使用して保護するリスナーのOracle Virtual Directoryターゲットにナビゲートします。

2. 存在しない場合は、「Oracle Virtual Directory」メニューから「セキュリティ」→「キーストア」を選択して、キーストアを作成します。「Javaキーストア」画面が表示されます。詳細は、『管理者ガイド』のOracle Enterprise Managerを使用してキーストアを作成する方法に関する情報を参照してください。

3. 次の手順を実行して、リスナーを構成します。

1. 「管理」を選択し、「Oracle Virtual Directory」メニューから「リスナー」を選択します。「リスナー」画面が表示されます。

2. SSLを使用して保護するリスナーをクリックして選択し、「編集」ボタンをクリックします。「リスナーを編集: Listener Name」画面が表示されます。

3. 「SSL設定の変更」リンクをクリックします。

4. 「SSLの有効化」オプションをクリックして、リスナーでSSLを有効化します。リスナーをSSL認証なしモードに構成している場合は、手順iをスキップしてください。

5. 「サーバー・キーストア名」フィールドから、使用するキーストアを選択します。

注意:
管理ゲートウェイ・リスナーまたはLDAP SSLエンドポイント・リスナーで異なるキーストアを選択するか、キーストアの証明書を変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする必要があります。証明書をインポートしない場合、Oracle Enterprise Manager Fusion Middleware ControlはOracle Virtual Directoryに接続してパフォーマンス・メトリックを取得することができません。
Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする手順:

1. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書をエクスポートします。

ORACLE_HOME/jdk/jre/bin/keytool -exportcert \
-keystore OVD_KEYSTORE_FILE -storepass PASSWORD \
-alias OVD_SERVER_CERT_ALIAS -rfc \
-file OVD_SERVER_CERT_FILE

2. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書を、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに追加します。

ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \
$ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

6. 「サーバー・キーストアのパスワード」フィールドに、キーストアのパスワードを入力します。

注意:
Oracle Virtual Directoryのインストール時に作成されたキーストアのパスワードは、インストール中に設定されたOracle Virtual Directory管理者のパスワードと同一です。

7. 「サーバーTruststore名」フィールドから、使用するトラストストアを選択します。

8. 「サーバーTruststore名」フィールドに、トラストストアのパスワードを入力します。

9. 「拡張SSL設定」オプションをクリックして開きます。

10. 「クライアント認証」フィールドから、次の認証モードの1つを選択します。
リスナーをSSL認証なしモードに構成するには、「認証なし」を選択します。

リスナーをSSLサーバー認証モードに構成するには、「サーバー認証」を選択します。

Oracle Virtual Directoryサーバーとクライアント間でリスナーをSSL相互認証モードに構成するには、「相互認証」モードを選択する必要があります。

注意:
「オプションのクライアント認証」モードは、Oracle Virtual Directoryリスナーではサポートされていません。

11. 「暗号スイート」フィールドから、適切なオプションを選択します。「すべて」を選択することも、各オプションを組み合せて選択することもできます。

注意:
リスナーをSSL認証なしモードに構成している場合は、少なくとも1つのDH_anon暗号を選択する必要があります。他のすべてのSSLモードでは、少なくとも1つのRSA暗号を選択する必要があります。

12. 「SSLプロトコル・バージョン」フィールドから、適切なオプションを選択します。

注意:
v2Helloオプションは、単独ではサポートされていません。つまり、v2Helloオプションのみを選択することはできず、リストから少なくとも1つの他のSSLプロトコル・バージョンを組み合せて選択する必要があります。

13. 「OK」ボタンをクリックします。

4. 実行されている場合は、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの停止」を参照して、Oracle Virtual Directoryを停止します。停止したら、「Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの起動」を参照して、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.6.3 WLSTを使用したリスナーでのSSLの構成

WLSTコマンドライン・ツールを使用して、Oracle Virtual Directoryに対してSSLを構成する手順:

関連項目:

- 『管理者ガイド』のSSLのWLSTリファレンスに関する項。

- WLSTコマンドライン・ツールの使用方法の詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

- WLSTコマンドの詳細は、『WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

1. WLSTコマンドライン・ツール・シェルを起動します。

2. 次のコマンドを使用して、カスタム・ツリーに移動します。

custom()

3. 次のコマンドを使用して、ルートのOracle Virtual Directory MBeanに移動します。

cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=COMPONENT_
NAME,instance=INSTANCE_NAME')

4. 次のコマンドを使用して、リモートのOracle Virtual DirectoryサーバーからWebLogicサーバーに、Oracle Virtual Directory構成を初期化してロードします。

invoke('load',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))

5. 次のコマンドを使用して、保護するリスナー(この例ではLDAP SSL Endpoint)の既存のSSL構成を表示します。

getSSL('instance1','ovd1','ovd','LDAP SSL Endpoint')

6. 次のコマンドを使用して、既存のキーストアを表示します。

listKeyStores('instance1','ovd1','ovd')

7. 必要な場合は、次のコマンドを実行して新しいキーストアと自己署名付きの証明書を作成します。
新しいキーストアを作成するには、次のコマンドを実行します。

createKeyStore('instance1','ovd1','ovd','NEW_KEYSTORE_NAME','PASSWORD_FOR_NEW_KEYSTORE')

新しいキーストアに自己署名付き証明書を作成するには、次のコマンドを実行します。

generateKey ('instance1','ovd1','ovd','NEW_KEYSTORE_NAME',
'PASSWORD_FOR_NEW_KEYSTORE', 'DN', 'keySize', 'alias')

8. 次のコマンドを実行して、Oracle Virtual DirectoryリスナーのSSL MBeanの名前を指定します。

getSSLMBeanName('instance1','ovd1','ovd','LDAP SSL Endpoint')

9. 次のようにしてMBeanのキーストアおよびトラストストアのパスワードを設定します。

1. (cd)を使用し、その後でcd ('SSL_MBEAN_NAME')を使用することでレベル/oracle.as.ovd/oracle.as.ovdに変更します。

2. 次のコマンドを実行します。

set('KeyStorePassword',java.lang.String('PASSWORD').toCharArray())
set('TrustStorePassword',java.lang.String('PASSWORD').toCharArray())

10. 次のコマンドおよびfile.propを使用して、リスナーのSSL設定を構成します。サンプルのfile.propファイルの例を示します。

configureSSL ('instance1', 'ovd1', 'ovd', 'LDAP SSL Endpoint', 'PATH_TO_file.prop')

注意:
管理ゲートウェイ・リスナーまたはLDAP SSLエンドポイント・リスナーで異なるキーストアを構成するか、キーストアの証明書を変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする必要があります。証明書をインポートしない場合、Oracle Enterprise Manager Fusion Middleware ControlはOracle Virtual Directoryに接続してパフォーマンス・メトリックを取得することができません。
Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする手順:

1. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書をエクスポートします。

ORACLE_HOME/jdk/jre/bin/keytool -exportcert \
-keystore OVD_KEYSTORE_FILE -storepass PASSWORD \
-alias OVD_SERVER_CERT_ALIAS -rfc \
-file OVD_SERVER_CERT_FILE

2. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書を、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに追加します。

ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \
$ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

例11-1 file.propファイルのサンプル

SSLEnabled=true
AuthenticationType=auth_type
SSLVersions=version
Ciphers=cipher
KeyStore=name_of_your_keystore
TrustStore=name_of_your_keystore

file.prop Fileに関する重要な注意:

- 例11-1の環境変数の値を、使用環境の値と置き換えてください。

- リスナーをSSL認証なしモードに構成している場合は、少なくとも1つのDH_anon暗号を選択する必要があります。他のすべてのSSLモードでは、少なくとも1つのRSA暗号を選択する必要があります。

- SSLをサーバー認証モードおよび相互認証モードに構成するときは、KeyStoreパラメータの値を指定する必要があります。

- AES暗号のみを指定する場合、SSLVersionsパラメータにTLSv1を含む必要があります。

- file.propファイルのテキストでは、大/小文字が区別されます。

- file.propファイルでは、暗号エントリの後に空白を使用しないでください。

- file.propファイルの内容の詳細は、『管理者ガイド』のSSLのプロパティ・ファイルに関する項を参照してください。

関連項目:
file.propで構成できるAuthenticationType、SSLVersions、およびCiphersの詳細は、次の項を参照してください。

- WLSTを使用した管理リスナーの設定の構成

- WLSTを使用したLDAPリスナーの設定の構成

- WLSTを使用したHTTPリスナーの設定の構成

11. 変更を保存してから、MBeanをリフレッシュします。次に例を示します。

cd('../..')
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=asinst1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))

12. 稼働している場合、Oracle Virtual Directoryサーバーを停止します。停止した後、Oracle Virtual Directoryを起動します。

注意:
Oracle Virtual Directoryサーバーにリスナー構成をロードするには、Oracle Virtual Directoryを再起動ではなく、明示的に停止して起動する必要があります。

11.6.4 SSL接続の検証

この項では、各SSLモードのSSL接続を検証する方法について説明します。この項の内容は次のとおりです。

- SSL認証なしモード

- SSLサーバー認証モード

- SSL相互認証モード

注意:
11gリリース1(11.1.1)のインストール後にデフォルト設定を使用する場合は、この項で説明されている次の変数に対して次の値を使用できます。

- OVD_KEY_STORE_FILEでは、次の値を使用します。
ORACLE_INSTANCE/config/OVD/ovd1

- OVD_SERVER_CERT_ALIASでは、serverselfsignedを使用します。

- -storepassおよび-jkspwdオプションで使用されるPASSWORDでは、orcladminと同じパスワードを使用します。

11.6.4.1 SSL認証なしモード

SSL認証なしモードで保護されている接続を検証するには、次のコマンドを実行します。

ORACLE_HOME/bin/ldapbind -D cn=orcladmin -q -U 1 -h HOST -p SSL_PORT

11.6.4.2 SSLサーバー認証モード

SSLサーバー認証モードで保護されている接続を検証するには、次の手順を実行します。

1. 次のコマンドを実行して、Oracleウォレットを作成します。

ORACLE_COMMON_HOME/bin/orapki wallet create -wallet DIRECTORY_FOR_SSL_WALLET \
-pwd WALLET_PASSWORD

2. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書をエクスポートします。

ORACLE_HOME/jdk/jre/bin/keytool -exportcert -keystore OVD_KEYSTORE_FILE \
-storepass PASSWORD -alias OVD_SERVER_CERT_ALIAS -rfc \
-file OVD_SERVER_CERT_FILE

3. 次のコマンドを実行して、Oracle WalletにOracle Virtual Directoryサーバーの証明書を追加します。

ORACLE_COMMON_HOME/bin/orapki wallet add -wallet DIRECTORY_FOR_SSL_WALLET \
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

4. 手順3のOracle Walletを使用して次のコマンドを実行します。

ORACLE_HOME/bin/ldapbind -D cn=orcladmin -q -U 2 -h HOST -p SSL_PORT \
-W "file://DIRECTORY_FOR_SSL_WALLET" -Q

11.6.4.3 SSL相互認証モード

SSL相互認証モードで保護されている接続を検証するには、次の手順を実行します。

1. 次のコマンドを実行して、Oracle Walletを作成します。

ORACLE_COMMON_HOME/bin/orapki wallet create -wallet DIRECTORY_FOR_SSL_WALLET \
-pwd WALLET_PASSWORD

2. 次のコマンドを実行して、Oracle Virtual Directoryキーストア・ファイルをOracle Walletに転送します。

ORACLE_COMMON_HOME/bin/orapki wallet jks_to_pkcs12 \
-wallet DIRECTORY_FOR_SSL_WALLET -pwd WALLET_PASSWORD \
-keystore ORACLE_INSTANCE/config/OVD/OVD_COMPONENT/keystores/keys.jks \
-jkspwd PASSWORD

3. 次のコマンドを実行して、クライアント証明書をBase64形式でエクスポートします。

ORACLE_COMMON_HOME/bin/orapki wallet export -wallet . -dn CLIENT_DN \
-cert ./b64certificate.txt

4. 次のコマンドを実行して、手順2で作成したクライアント証明書を、Oracle Virtual Directoryのキーストアに信頼できるエントリとしてインポートします。

ORACLE_HOME/jdk/jre/bin/keytool -importcert \
-keystore ORACLE_INSTANCE/config/OVD/OVD_COMPONENT/keystores/keys.jks
-storepass JKS_PASSWORD -alias ALIAS -file b64certificate.txt -noprompt

5. 次のコマンドを実行し、クライアント証明書のバインドDNを使用してSSL接続を検証します。

ORACLE_HOME/bin/ldapbind -U 3 -h HOST -p SSL_PORT -W "file://DIRECTORY_FOR_SSL_WALLET" -Q

11.6.5 SSL再ネゴシエーションの制御

この項では、許可されるSSL再ネゴシエーションの数を制御する方法について説明します。

サーバーのデフォルトでは、クライアント・アプリケーションは、制限なく必要な数だけSSL再ネゴシエーションを開始できます。SSL再ネゴシエーションはサーバーにとって時間のかかる処理であるため、DDOS攻撃に使用される可能性があります。このようなDDOS攻撃を避けるため、各クライアントに許可されるSSL再ネゴシエーションの数を制限するか、SSL再ネゴシエーションの許可を停止することができます。

SSL再ネゴシエーションを制御する手順:

1. $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlファイルを開き、Oracle Virtual DirectoryインスタンスのセクションでJavaプロパティ-Dsslrenegotiations=Xを設定します。

- X=-1は、制限なしを示します(これはレガシー対応のためのデフォルト値です)。

- X=-1は、再ネゴシエーションを禁止することを示します。

- X=nは、最大でn個の再ネゴシエーションの開始を各クライアントに許可することを示します。

2. SSLリスナーがブロック・モードを使用していることを確認します。
$ORACLE_INSTANCE/config/OVD/ovd1/listener.os_xmlファイルを開き、LDAP SSLリスナーのセクションで<useNIO>要素を見つけます。この要素がfalseに設定されている必要があります。

次に例を示します。

<ldap id="TLS" version="3">
<port>9999</port>
<host>0.0.0.0</host>
<threads>10</threads>
<active>true</active>
<ssl enabled="false">
<protocols>TLSv1,SSLv2Hello</protocols>
<cipherSuites includeAnonCiphers="true"/>
<authType>Server</authType>
<keyStore password="{AES-CBC}b2vWJAN48ufpbxla9gohlj/
M+eBP/9FLwh6tLfiWF0o=">TLSkeyStore.jks</keyStore>
<trustStore password="{AES-CBC}rOk44ucwkpQ2QRcTDK4bJRklj/
OmALyUWQMjQAYoNJY=">TLSkeyStore.jks</trustStore>
</ssl>
<extendedOps/>
<anonymousBind>Allow</anonymousBind>
<workQueueCapacity>100</workQueueCapacity>
<allowStartTLS>true</allowStartTLS>
<socketOptions>
<backlog>128</backlog>
<reuseAddress>false</reuseAddress>
<keepAlive>false</keepAlive>
<tcpNoDelay>true</tcpNoDelay>
<readTimeout>0</readTimeout>
</socketOptions>
<useNIO>false</useNIO>
</ldap>

3. Oracle Virtual Directoryを再起動します。

4. Oracle Virtual Directoryが適切にSSL再ネゴシエーションを拒否することを確認します。
OpenSSLを使用して、Oracle Virtual Directoryがn回の試行後に再ネゴシエーションを拒否することを確認できます。OpenSSLを起動し、Rという1文字を入力してSSL再ネゴシエーションを開始します。

$ openssl s_client -connect myhost:7502
[...]
---
R

- 再ネゴシエーションが許可されると、次の内容が表示されます。

---
R
RENEGOTIATING
depth=0 O = test, CN = servername.Yourcompany.com
verify error:num=18:self signed certificate
verify return:1
depth=0 O = test, CN = servername.Yourcompany.com
verify return:1

- 再ネゴシエーションが拒否されると、次の内容が表示されます。

---
R
3073562824:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected
message:s3_pkt.c:1252:SSL alert number 10
3073562824:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:592:

12 Oracle Virtual Directoryのアダプタの作成および構成

この章では、Oracle Virtual Directoryアダプタの作成および構成方法について説明します。この章の内容は次のとおりです。

- 第12.1項「LDAPアダプタの作成」

- 第12.2項「データベース・アダプタの作成」

- 第12.3項「ローカル・ストア・アダプタの作成」

- 第12.4項「結合ビュー・アダプタの作成」

次の表は、使用可能なOracle Virtual Directoryアダプタ・テンプレートおよびそれらのテンプレートによってデプロイされるプラグインを示しています。

注意:
この表は、単なるクイック・リファレンスとして記載しています。
これらのアダプタ・テンプレートおよびプラグインの詳細は、第2.9項「アダプタ・テンプレートの概要」を参照してください。

表12-1 アダプタ・テンプレート

アダプタ・テンプレート・タイプ

アダプタ・テンプレート

アダプタ・テンプレートによってデプロイされるプラグイン

デフォルト・アダプタ

デフォルト・テンプレート

LDAPアダプタ

Active_Directory

CA_eTrust

Changelog_LDAP-TYPE

Changelogプラグイン

EUS_ActiveDirectory

- Objectclass Mapper

- Active Directory Password

- EUSActiveDirectory

EUS_LSAMetaData_LDAP-TYPE

EUS_OID

EUSOIDプラグイン

EUS_Sun

- Objectclass Mapper

- EUSun

EUS_eDirectory

- Objectclass Mapper

- EUSeDirectory

General_LDAP_Directory

IBM_Directory

Novell_eDirectory

マッパーを使用したOAM/ADアダプタ

- Active Directory Ranged Attributes

- Objectclass Mapper

- Active Directory Password

- Dump Before

- Dump After

SSLおよびマッパーを使用したOAM/ADアダプタ

アダプタはデフォルトではクライアントには表示されません。それはActive Directory Passwordプラグインなどのプラグインを通してのみアクセスできます。

スクリプトを使用したOAM/ADアダプタ

- Active Directory Ranged Attributes

- Active Directory Password

- Objectclass Mapper

- Dump Before

- Dump After

マッパーを使用したOAM/ADAMアダプタ

- Active Directory Ranged Attributes

- Objectclass Mapper

- Active Directory Password

- Dump Before

- Dump After

SSLおよびマッパーを使用したOAM/ADAMアダプタ

アダプタはデフォルトではクライアントには表示されません。それはActive Directory Passwordプラグインなどのプラグインを通してのみアクセスできます。

スクリプトを使用したOAM/ADAMアダプタ

- Active Directory Ranged Attributes

- Active Directory Password

- Dump Before

- Dump After

マッパーを使用したOAM/SunOneアダプタ

- Objectclass Mapper

- Dump SunOne

スクリプトを使用したOAM/SunOneアダプタ

Dump Transactionsプラグイン

ONames_LDAP-TYPE

ONamesプラグイン

Oracle_Internet_Directory

Siemens_DirX

SunOne_Directory

User_LDAP-TYPE

UserManagementプラグイン

ローカル・ストア・アダプタ

Local_Storage_Adapter

データベース・アダプタ

スクリプトを使用したOAM/DBアダプタ

- DumpDB1

- DumpDB2

12.1 LDAPアダプタの作成

この項では、LDAPアダプタの作成および構成方法について説明します。この項の内容は次のとおりです。

- Oracle Unified Directory向けのアダプタの作成

- LDAPアダプタの構成

- Oracle Virtual DirectoryおよびOracle Internet Directory間の相互認証SSL接続の構成

Oracle Directory Services Managerを使用してLDAPアダプタを作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタの作成」ボタンをクリックします。新規アダプタ・ウィザードが表示されます。

4. アダプタのタイプを定義するには、次の手順を実行します。

1. 「アダプタ・タイプ」リストから「LDAP」を選択します。

2. 「アダプタ名」フィールドにLDAPアダプタの一意の名前を入力します。アダプタ名の値は、そのアダプタを参照する必要のある他の構成フィールドで使用されます。

3. 第2.9項「アダプタ・テンプレートの概要」を参照して、「アダプタ・テンプレート」リストからアダプタ・テンプレートを選択します。使用するテンプレートが不明な場合は、「デフォルト」を選択します。

注意:
アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。

4. 「次へ」をクリックします。「接続」画面が表示されます。

5. 「自動検出にDNSを使用」オプションから操作のDNSモードを選択し、(「接続詳細」表に特定のLDAPホストを構成するかわりに)定義されているリモート・ベースの適切なLDAPホストを、DNSを使用して自動的に検出するようにOracle Virtual Directoryを構成します。これは、サーバーレス・バインド・モードとも呼ばれます。LDAPアダプタは、次に示す操作のDNSモードをサポートします。

注意:
DNSオプションは、Oracle Directory Services Managerのインタフェースに英語でのみリストされますが、各DNSオプションの説明はローカライズされた言語翻訳でサポートされています。

- いいえ: サーバーレス・バインドではなく、「接続詳細」表の構成を使用します。

- 標準: Microsoft以外のサーバーの標準DNS参照を使用します。すべてのサーバーは読取り/書込みとしてマーク付けされるため、LDAPの書込みサポートを許可するために「参照の追跡」設定を有効化することをお薦めします。

- Microsoft: DNSサーバーはMicrosoftの動的DNSであり、ロード・バランシング構成もサポートします。Microsoftの動的DNSサーバーに対してプロキシ設定する場合は、この設定をお薦めします。これは、Oracle Virtual Directoryの機能により、読取り専用サーバーと比較して読取り/書込みサーバーが自動検出されるためです。

注意:
この設定の使用時には、リモート・ベースにdc=myorg,dc=comなど、ドメイン・コンポーネントのスタイル名が指定されている必要があります。この名前により、Oracle Virtual Directoryで、myorg.comを検索してDNSサービス内のLDAPホストが検出されます。

6. 「自動検出にDNSを使用」設定で「いいえ」オプションを選択した場合、「ホストの追加」ボタンをクリックしてから、次の情報を入力し、プロキシLDAPホスト情報を追加します。各プロキシLDAPホストは、同等のコンテンツを提供するレプリカであることが必要です。

注意:
プロキシ設定するホストを1つのみ指定する場合は注意が必要です。フェイルオーバー・ホストがないと、LDAPアダプタは、自動的に別のホストにフェイルオーバーされません。単一のホストが適しているのは、Oracle Virtual Directoryがロード・バランシング・システム経由で論理LDAPサービスに接続されている場合です。

1. 「ホスト」フィールドに、プロキシを設定するLDAPホストのIPアドレスまたはDNS名を入力します。

注意:
Oracle Virtual Directory 11gリリース1 (11.1.1)ではIPv6がサポートされています。ネットワークでIPv6がサポートされている場合、「ホスト」フィールドにリテラルIPv6アドレスを使用して、プロキシ設定されたLDAPホストを指定できます。

2. 「ポート」フィールドに、プロキシ設定されたLDAPホストが提供するLDAPサービスのポート番号を入力します。

3. 「重みの値」フィールドに0から100の間の数値を入力し、ホストに送信する負荷率を構成します。アダプタに構成されたすべてのホストの統合したパーセンテージが合計で100にならない場合は、ホストに対して入力したパーセンテージを、アダプタに構成されているすべてのホストの合計パーセンテージで割ることで、Oracle Virtual Directoryにより負荷率が自動的に調整されます。たとえば、20パーセント、30パーセントおよび40パーセントの3つのホストがアダプタに構成されている場合、Oracle Virtual Directoryにより、20は22(20/90)に、30は33(30/90)に、40は44(40/90)に調整されます。

4. 「読取り専用」オプションを選択し、LDAPホストでのみ検索操作を実行するようにLDAPアダプタを構成します。LDAPアダプタは、すべての変更トラフィックをリスト内の読取り/書込みホストに自動的に送ります。

7. 「SSL/TLSの使用」オプションを選択し、SSL/TLSを使用して、LDAPアダプタとプロキシLDAPホスト間の通信を保護します。

関連項目:
認証局の詳細は、第12.1.2.4項「SSLで保護されているLDAPアダプタの認証局の管理」を参照してください。

「SSL/TLSの使用」オプションを選択(有効化)する場合、「SSL認証モード」リストからオプションを選択することで、アダプタをセキュリティで保護するために使用するSSL認証モードを選択します。「SSL認証モード」設定は、「SSL/TLSの使用」オプションが有効化されている場合にのみ機能します。

8. 「サーバー・プロキシ・バインドDN」フィールドのプロキシ設定されたディレクトリへのアクセス時に、バインドするLDAPアダプタのデフォルトの識別名を入力します。「パススルー資格証明」フィールドの設定に応じて、このDNは、すべての操作で使用されるか、パススルー・モードのような特別な場合にのみ使用されます。識別名の書式は、リモート・ディレクトリの書式に合せる必要があります。「サーバー・プロキシ・バインドDN」フィールドが空の場合、LDAPアダプタは匿名としてバインドします。

9. 「プロキシ・パスワード」フィールドに、サーバー・プロキシ・バインドDN値とともに使用する認証パスワードをクリアテキストで入力します。サーバーにロードされると、値は自動的に暗号化されます。

10. 「次へ」をクリックします。Oracle Virtual Directoryにより、「接続詳細」表に定義したホストへの接続が検証されます。接続検証プロセスの結果が表示された「接続のテスト」画面が表示されます。

- 検証が成功した場合には、成功のメッセージと接続の詳細が表示されます。「次へ」をクリックします。「ネームスペース」画面が表示されます。手順11に進んで、新規LDAPアダプタの作成を続行します。

- 検証に失敗した場合は、検証できなかったホスト接続のステータス表の「接続」列に、Could not connectというメッセージが表示されます。検証できなかったホスト接続の行をクリックして、接続に失敗した理由の詳細を参照します。「戻る」ボタンをクリックして接続が失敗したホストの設定を確認し、必要に応じてホスト設定を編集して、失敗した接続を解決します。
プロキシLDAPホストへの接続は、そのLDAPホストのプロキシ設定をするアダプタに対して検証する必要があります。失敗した接続を解決したら、新規LDAPアダプタ・ウィザードの「接続テスト」画面で「次へ」をクリックします。「ネームスペース」画面が表示されます。手順11に進んで、新規LDAPアダプタの作成を続行します。

11. 「リモート・ベース」フィールドに、ローカルOracle Virtual Directoryのルート接尾辞に対応する、リモート・サーバーのディレクトリ・ツリー構造内の場所を入力します。これは、Oracle Virtual Directoryによってアダプタのすべての検索および操作が実行される、リモート・ディレクトリ内の場所です。LDAPアダプタにより、リモート・ベースからアダプタ・ルート・ベースへの全エントリの自動マッピングが適用されます。

12. 「マップされたネームスペース」フィールドに、プロキシ設定されたディレクトリのネームスペースのかわりに、Oracle Virtual Directoryクライアントに表示するネームスペースを入力します。たとえば、プロキシ設定されたディレクトリのDNがdc=oracle, dc=comで、ネームスペースをdc=Oracle Corp, dc=comとしてOracle Virtual Directoryクライアントに表示する場合は、「マップされたネームスペース」フィールドにdc=Oracle Corp, dc=comと入力します。

13. 「パススルー資格証明」リストから次のいずれかのオプションを選択して、LDAPアダプタのパススルー資格証明を設定します。

注意:
パススルー・オプションは、Oracle Directory Services Managerのインタフェースに英語でのみ表示されますが、各パススルー・オプションの説明はローカライズされた言語翻訳でサポートされています。

- プロキシDN資格証明をすべての操作で使用する場合は、「なし」を選択します。

- バインド用にのみユーザー資格証明をプロキシ設定されたLDAPサーバーに渡し、その他のすべての操作でデフォルトのサーバー資格証明を使用する場合は、「バインドのみ」を選択します。

- すべての操作で、Oracle Virtual Directoryに示されたユーザー資格証明をプロキシ設定されたLDAPサーバーに渡す場合は、「常時」を選択します。

注意:
状況によっては、「パススルー・モード」が「常時」に設定されていても、LDAPアダプタによってプロキシDNが使用される場合があります。これは、別のアダプタ・ネームスペースなどからユーザー資格証明をマップできない場合や、ユーザー資格証明がルート・アカウントの場合に発生します。
Microsoft Active Directoryフォレスト内の異なるドメイン・コントローラに複数のアダプタを定義する場合は、バインドを含むルーティング設定を使用して、LDAPアダプタが他のアダプタ(同じActive Directoryフォレストを指す複数のアダプタ)からの資格証明にプロキシを設定するように指定できます。

14. 「Kerberosの使用」オプションを選択し、Kerberosプロトコルを使用してLDAPバインド操作を実行するようにLDAPアダプタを構成します。「Kerberosの使用」設定を有効化してKerberosのMicrosoft Active Directoryバージョンに存在する既知の問題の多くを解決する場合は、Java 1.6以上を使用することをお薦めします。

「Kerberosの使用」オプションを有効化する場合は、次の点に注意する必要があります。

- Kerberos認証は資格証明の検証にのみ使用でき、その他の操作のためにバックエンド・サーバーに渡されることはないため、パススルーオプションは「バインドのみ」に設定する必要があります。

- RDN値はKerberosプリンシパル名(Active Directoryの場合はsAMAccountName)と同一であることが必要です。つまり、KerberosバインドのバインドDNは実際のユーザーDNではありません。たとえば、ユーザーDNはcn=Jane Doe,cn=users,dc=mycompany,dc=comですが、sAMAccountNameはjdoeで、「Kerberosの使用」オプションが有効化されたバインドDNはcn=jdoe,cn=users,dc=mycompany,dc=comです。

- krb5.confファイルを作成し、Oracle Virtual Directoryの構成フォルダ内に置く必要があります。krb5.confには次のプロパティがあります。

表12-2 krb5.confファイルのプロパティ

プロパティ

説明

default_realm

マッピングによって提供されていない場合に使用されるデフォルト・ドメインです。たとえば、あるユーザーがuid=jsmith,ou=people,dc=myorg,dc=comとしてバインドされると、jsmith@myorg.comとして処理されます。マップされたネームスペースにドメイン・コンポーネント(DC)ベースのルートが含まれていない場合は、かわりにこの値が置き換えられます。

domain_realm

ドメインとレルム定義との間のマッピングを定義します。(例: .oracle.com = ORACLE.COM)

realms

1つ以上のレルムを定義します(例: ORACLE.COM = {...})。

kdc

特定のレルム定義のKerberosサービスを実行するサーバーのDNS名です。

Kerberosバインドでは、標準のJavaパッケージに備わっているKerberosライブラリが使用されます。Kerberosライブラリでは、現状ではOracle Virtual DirectoryのLDAPアダプタ設定に同期していないkrb5.confファイルが使用されます。Kerberosのフェイルオーバーは、デフォルトのライブラリによって制御されます。フェイルオーバーおよびkrb5.confファイルの高度な構成の詳細は、Sun社のJavaドキュメントを参照してください。

注意:
Microsoft Active Directoryサーバーが停止(停止または再起動のいずれか)の処理中で、Oracle Virtual Directoryがそれへの接続を試行する場合、Active Directoryでは資格証明の検証が行われず、Key Distribution Center(ドメイン・コントローラ)の接続エラーではなく、Client not Found in Kerberos Databaseエラー・メッセージが戻されることがあります。
エンド・ユーザーは、Active Directoryサーバーが使用可能であるか、Key Distribution Centerのフェイルオーバーが有効化されているため、正常な認証が戻されると理解して再度ログインします。

15. 「Kerberosの使用」オプションを有効化する場合、「Kerberosの再試行」オプションを使用して、認証の試行が失敗した後にOracle Virtual Directoryがログインを再試行するかどうかを制御できます。「Kerberosの再試行」オプションを有効化してあり、かつ認証に失敗した場合、Oracle Virtual Directoryによってkerb5.confファイルがリロードされ、ログインが再試行されます。

注意:
krb5.confファイルにおいて1つのKerberosレルムで複数のActive Directoryサーバーを識別している場合、「Kerberosの再試行」オプションを有効化しないでください。再試行を有効化すると、フェイルオーバー機能が損われることがあります。

16. 「ネームスペース」画面の「次へ」をクリックします。新規LDAPアダプタの設定がリストされた「概要」画面が表示されます。

17. 新規LDAPアダプタの設定を確認し、「終了」をクリックしてLDAPアダプタを作成します。「アダプタ」ツリーに、新規LDAPアダプタが表示されます。

LDAPアダプタを作成したら、第12.1.2項「LDAPアダプタの構成」の手順に従って構成できます。

12.1.1 Oracle Unified Directory向けのアダプタの作成

Oracle Unified Directoryアダプタを作成するには、第12章「LDAPアダプタの作成」の説明に従って、デフォルト・テンプレートを使用してLDAPアダプタを作成します。

Oracle Identity Managementと統合するには、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Unified Directory (OUD)向けのアダプタの作成に関する項の手順を参照してください。

12.1.2 LDAPアダプタの構成

この項では、LDAPアダプタ設定の構成方法を説明します。この項の内容は次のとおりです。

- LDAPアダプタの一般設定の構成

- アダプタのルーティングの構成

- アダプタ・プラグインおよびマッピングの構成

- SSLで保護されているLDAPアダプタの認証局の管理

12.1.2.1 LDAPアダプタの一般設定の構成

LDAPアダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「一般」タブをクリックして次に示すフィールドに値を設定し、「適用」をクリックしてアダプタの一般設定を構成できます。

注意:
この項で説明されている接続プール・パラメータの許容可能な最小および最大設定は、Oracle Virtual Directoryとそのデータベースを実行しているシステムに応じて異なります。

ルート

このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

アクティブ

アダプタは、アクティブ(有効)または非アクティブ(無効)として構成できます。非アクティブに構成されたアダプタは、サーバーの再起動時やアダプタの起動の試行時には起動しません。非アクティブの設定は、古い構成を使用可能な状態にしておく場合や、構成から削除せずにスタンバイ状態にしておく場合に使用します。デフォルト設定はアクティブ(有効)です。

LDAPサーバーの詳細

「一般」タブの「LDAPサーバー」表にプロキシLDAPホストの情報を構成するには、次の手順を実行します。各プロキシLDAPホストは、同等のコンテンツを提供するレプリカであることが必要です。

プロキシ設定するホストを1つのみ指定する場合は注意が必要です。フェイルオーバー・ホストがないと、LDAPアダプタは、自動的に別のホストにフェイルオーバーされません。単一のホストが適しているのは、Oracle Virtual Directoryがロード・バランシング・システムを使用して論理LDAPサービスに接続されている場合です。

注意:
「LDAPサーバー」表の情報は、「自動検出にDNSを使用」パラメータを「いいえ」に設定した場合にのみ使用されます。

アダプタにプロキシLDAPホストを追加するには、次のようにします。

1. 「ホストの追加」ボタンをクリックします。

2. 「ホスト」フィールドに、プロキシを設定するLDAPホストのIPアドレスまたはDNS名を入力します。

注意:
Oracle Virtual Directory 11gリリース1 (11.1.1)ではIPv6がサポートされています。ネットワークでIPv6がサポートされている場合、「ホスト」フィールドにリテラルIPv6アドレスを使用して、プロキシ設定されたLDAPホストを指定できます。

3. 「ポート」フィールドに、プロキシ設定されたLDAPホストが提供するLDAPサービスのポート番号を入力します。

4. パーセンテージ・フィールドに0から100の間の数値を入力し、ホストに送信する負荷率を構成します。アダプタに構成されたすべてのホストの統合したパーセンテージが合計で100にならない場合は、ホストに対して入力したパーセンテージを、アダプタに構成されているすべてのホストの合計パーセンテージで割ることで、Oracle Virtual Directoryにより負荷率が自動的に調整されます。たとえば、20パーセント、30パーセントおよび40パーセントの3つのホストがアダプタに構成されている場合、Oracle Virtual Directoryにより、20は22(20/90)に、30は33(30/90)に、40は44(40/90)に調整されます。

5. 「読取り専用」オプションを選択し、LDAPホストでのみ検索操作を実行するようにLDAPアダプタを構成します。LDAPアダプタは、すべての変更トラフィックをリスト内の読取り/書込みホストに自動的に送ります。

アダプタからプロキシLDAPホストを削除するには、次のようにします。

1. 「リモート・ホスト」表で削除するホストの行をクリックします。

2. 「削除」ボタンをクリックします。確認のダイアログ・ボックスが表示されます。

3. アダプタからプロキシLDAPホストを削除するには、「確認」をクリックします。

プロキシLDAPホストの接続を検証するには、次のようにします。

1. 接続を検証するホストの「リモート・ホスト」表の行をクリックします。

2. 「検証」ボタンをクリックします。プロキシLDAPホストへの接続は、そのLDAPホストのプロキシ設定をするアダプタに対して検証する必要があります。

SSL/TLSの使用

このオプションを有効化すると、SSL/TLSを使用して、LDAPアダプタとプロキシLDAPホスト間の通信を保護できます。

関連項目:
認証局の詳細は、第12.1.2.4項「SSLで保護されているLDAPアダプタの認証局の管理」を参照してください。

SSL認証モード

「SSL/TLSの使用」オプションを選択(有効化)する場合、「SSL認証モード」リストからオプションを選択することで、アダプタをセキュリティで保護するために使用するSSL認証モードを選択します。「SSL認証モード」設定は、「SSL/TLSの使用」オプションが有効化されている場合にのみ機能します。

フェイルオーバー・モード

「順次」に設定すると、Oracle Virtual Directoryは、「LDAPサーバー」表で指定されたアクティブなホストのリストから、最初に使用可能なサーバーを常に取得します。そのサーバーが(ソケットをオープンできないか、タイムアウトに到達したために)応答しない場合、Oracle Virtual Directoryは、そのサーバーを使用不可リストに配置し、次に使用可能なサーバーの取得を試行します。

使用不可のサーバーは、ハートビート・スレッドを継続します(デフォルトは60秒間隔です)。ハートビートが実行されるたびに、Oracle Virtual Directoryは、接続を取得できるかどうかを確認します。その場合、該当するサーバーはアクティブ・リストの前の位置に戻されます。たとえば、それが最初のサーバーであった場合、最上位に戻されます。

順次フェイルオーバーは、地域間のフェイルオーバーに使用されます。順次フェイルオーバーでは、LDAPアダプタは、障害が発生するまで指定されたホストの使用を試行します。この時点で、別のデータ・センターまたは遠隔地にある使用可能な同等のホストにフェイルオーバーします。

「分散」に設定すると、作成されるすべての新規接続は、「LDAPサーバー」表に定義されたリストを使用してロード・バランスされます。分散フェイルオーバーは、同じデータ・センターにある一連のLDAPホスト、またはネットワーク・パフォーマンスに関して同等に使用可能な一連のLDAPホストにプロキシ設定する場合に使用されます。

注意:
リモート・ホストのネットワークに障害が発生した場合は、プラットフォーム固有のTCPソケットのタイムアウト設定が原因で、Oracle Virtual Directoryに数分の遅延が発生する可能性があります。ただし、Oracle Virtual Directoryのフェイルオーバーは適切に実行されており、遅延中にデータが損失することはありません。

試行延長

このオプションは、ホストへの接続が失敗したことが判明しても、Oracle Virtual Directoryサーバーが、アダプタへの新規受信リクエストで、「LDAPサーバー」表にリストされた最後のホストへの接続を試行し続けるようにする場合に有効化します。有効化すると、ホストへの接続が失敗しても、そのホストは「LDAPサーバー」表から削除さず、アダプタの「ハートビート間隔」設定が無視されます。分散ディレクトリの存在する一部の環境では、その時点での結果の一部を迅速に戻すために、ルーティング・クリティカル設定とともに「試行延長」オプションを無効化する場合があります。デフォルト設定は「有効」です。

ハートビート間隔

LDAPアダプタでは、「LDAPサーバー」表に定義されている各ホストの可用性が定期的に検証されます。この検証サイクルでは、現在無効化されているホストが復活する可能性があるほか、TCP/IP接続のテストに失敗した現在アクティブなホストが「false」とラベル付けされます。「ハートビート間隔」パラメータは、検証通過の間隔を秒数で指定します。低すぎる値を設定すると、リモート・ディレクトリへの不要な接続が発生します。高すぎる値を設定すると、障害発生時のリカバリ検出時間が長くなります。本番環境では、この値を60秒から開始し、必要に応じて調整することをお薦めします。

注意:
「ハートビート間隔」パラメータを0に設定すると、ハートビート・スレッドが無効になりますが、ハートビート・スレッドを常に有効にしておくことをお薦めします。

操作タイムアウト

LDAPリクエストがリモート・ホストによって承認されるのをサーバーが待機する時間(ミリ秒単位)。この操作が失敗した場合、LDAPアダプタにより、「リモート・ホスト」表の次のサーバーが自動的に試行されます。構成可能な最小値は15000(ミリ秒)です。本番環境では、この値を15000(15秒)から開始し、必要に応じて調整することをお薦めします。(デフォルトは15000、つまり15秒です。)

最大プール接続数

単一のサーバーに確立できる同時接続数を制御するための、チューニング・パラメータです。本番環境では、この値を10接続から開始し、必要に応じて調整することをお薦めします。(デフォルトは10接続です。)

最大プール待機数

LDAPアダプタによって新しい接続が生成される前に、既存の接続を使用するためにLDAP操作が待機する最大時間(ミリ秒単位)。本番環境では、この値を1000(1秒)から開始し、必要に応じて調整することをお薦めします。(デフォルトは1000ミリ秒です。)

最大プール試行数

「最大プール接続数」パラメータを上書きして新しい接続を生成する前に、LDAP接続のために操作が待機される最大回数。最大時間は、「最大プール待機数」の時間に試行回数を掛けた結果です。プール待機が1秒で試行の最大数が10回の場合、標準プールでLDAP接続が使用不可になってから10秒後に、増大した負荷の処理のためにプールが拡張されます。「最大プール接続数」を超過してプールが拡張されるのを回避するには、試行回数を高い数値に設定してください。本番環境では、この値を10から開始し、必要に応じて調整することをお薦めします。(デフォルトは10試行です。)

Kerberosの使用

「Kerberosの使用」オプションの詳細は、手順14を参照してください。

Kerberosの再試行

「Kerberosの使用」オプションを有効化する場合、「Kerberosの再試行」オプションを使用して、認証の試行が失敗した後にOracle Virtual Directoryがログインを再試行するかどうかを制御できます。「Kerberosの再試行」オプションを有効化してあり、かつ認証に失敗した場合、Oracle Virtual Directoryによってkerb5.confファイルがリロードされ、ログインが再試行されます。

注意:
krb5.confファイルにおいて1つのKerberosレルムで複数のActive Directoryサーバーを識別している場合、「Kerberosの再試行」オプションを有効化しないでください。再試行を有効化すると、フェイルオーバー機能が損われることがあります。

自動検出にDNSを使用

「LDAPサーバー」表で特定のプロキシLDAPホストを構成するかわりに、このオプションを使用して、定義されているリモート・ベースの適切なLDAPサーバーの検出に、Oracle Virtual DirectoryでDNSを使用するように設定できます(サーバーレス・バインド・モードとも呼ばれます)。LDAPアダプタは、次に示す操作モードをサポートします。

- いいえ: サーバーレス・バインドではなく、「LDAPサーバー」表の構成を使用します。

- 標準: Microsoft以外のサーバーの標準DNS参照を使用します。すべてのサーバーは読取り/書込みとしてマーク付けされるため、LDAPの書込みサポートを許可するために「参照の追跡」設定を有効化することをお薦めします。

- Microsoft: DNSサーバーはMicrosoftの動的DNSであり、ロード・バランシング構成もサポートします。Microsoftの動的DNSサーバーに対してプロキシ設定する場合は、この設定をお薦めします。これは、Oracle Virtual Directoryの機能により、読取り専用サーバーと比較して読取り/書込みサーバーが自動検出されるためです。

注意:
この設定の使用時には、リモート・ベースにdc=myorg,dc=comなど、ドメイン・コンポーネントのスタイル名が指定されている必要があります。この名前により、Oracle Virtual Directoryで、myorg.comを検索してDNSサービス内のLDAPホストが検出されます。

「一般」タブの「設定」セクションには、次のフィールドが表示されます。

リモート・ベース

ローカルOracle Virtual Directoryのルート接尾辞に対応する、リモート・サーバーのディレクトリ・ツリー構造内の場所。これは、Oracle Virtual Directoryによって現在のアダプタのすべての検索および操作が実行される、リモート・ディレクトリ内の場所です。LDAPアダプタにより、リモート・ベースからアダプタ・ルート・ベースへの全エントリの自動マッピングが適用されます。

DN属性

member、uniquemember、managerなど、ネームスペース変換が必要なDNとして処理される属性のリスト。たとえば、これらの属性が「DN属性」リストにある場合、プロキシ・ディレクトリからのグループ・エントリを読み取る際には、Oracle Virtual Directoryでuniquememberまたはmember属性だけでなく、グループ・エントリ自体のDNが自動的に変換されます。

注意:
クライアント・アプリケーションで使用する必要があるとわかっている属性のみを変換します。可能性のあるすべてのDN属性を入力する必要はありません。入力すると、プロキシで消費されるCPU時間が少し増加します。

「DN属性」リストに属性を追加するには、次のようにします。

1. 「追加」をクリックします。「DN属性の選択」ダイアログ・ボックスが表示されます。

2. 追加する属性を選択します。

3. 「OK」をクリックします。

エスケープ・スラッシュ

ディレクトリに/文字が含まれる場合、Oracle Virtual Directoryでは、円記号の\を使用して、オプションでスラッシュをエスケープできます。スラッシュをエスケープせずに使用できるディレクトリ・サーバー製品と、そうでない製品があります。この設定を有効化すると、スラッシュがエスケープされます。

参照の追跡

この設定を有効化すると、クライアントのかわりにソース・ディレクトリから受信した参照がLDAPアダプタにより追跡されます。無効化すると、参照はブロックされ、クライアントに戻されません。

次に、LDAP操作設定の管理対象DSAコントロールの送信と関連した異なる設定のときのLDAPアダプタの動作の概要を示します。

- LDAPアダプタの「参照の追跡」が有効(true)に設定され、かつLDAP操作の管理対象DSAコントロールの送信が「True」に設定されている場合、Oracle Virtual Directoryは参照エントリを追跡しませんが、クライアントに戻します。

- LDAPアダプタの「参照の追跡」が有効(true)に設定され、LDAP操作の管理対象DSAコントロールの送信が「False」に設定されている場合、Oracle Virtual Directoryは参照エントリを追跡しません。

- LDAPアダプタの「参照の追跡」が無効(false)に設定され、LDAP操作の管理対象DSAコントロールの送信が「True」に設定されている場合、Oracle Virtual Directoryは参照エントリを追跡しませんが、クライアントに戻します。

- LDAPアダプタの「参照の追跡」が無効(false)に設定され、かつLDAP操作の管理対象DSAコントロールの送信が「False」に設定されている場合、Oracle Virtual Directoryは参照エントリを追跡せず、クライアントにも戻しません。

プロキシ設定されたページ・サイズ

この設定を有効化すると、プロキシでPaged Result Controlをプロキシ設定されたディレクトリに使用できます。この設定は、ディレクトリで問合せの結果数を制限する場合に最もよく有効化されます。この設定は、Oracle Virtual Directoryのクライアントのかわりに透過的に使用されます。

「一般」タブの「資格証明の処理」セクションには、次のフィールドが表示されます。

プロキシDN

プロキシ設定されたディレクトリにアクセスする際に、LDAPアダプタがバインドするデフォルトのDN。「パススルー・モード」設定に応じて、このDNは、すべての操作で使用されるか、パススルー・モードのような特別な場合にのみ使用されます。識別名の書式は、リモート・ディレクトリの書式に合せる必要があります。空の値は匿名とみなされます。

プロキシ・パスワード

「プロキシDN」値とともに使用される認証パスワード。パスワードを設定するには、値をクリアテキストで入力します。サーバーにロードされると、追加のセキュリティを提供するために、可逆的なマスクを使用して値が自動的にハッシュされます(例: {OMASK}jN63CfzDP8XrnmauvsWs1g==)。

パススルー・モード

すべての操作で、Oracle Virtual Directoryに示されたユーザー資格証明をプロキシ設定されたLDAPサーバーに渡す場合は、「常時」に設定します。バインド用にのみユーザー資格証明をプロキシ設定されたLDAPサーバーに渡し、その他のすべての操作でデフォルトのサーバー資格証明を使用する場合は、「バインドのみ」に設定します。プロキシDN資格証明をすべての操作で使用する場合は、「なし」に設定します。

注意:
状況によっては、「パススルー・モード」が「常時」に設定されていても、LDAPアダプタによってプロキシDNが使用される場合があります。これは、別のアダプタ・ネームスペースなどからユーザー資格証明をマップできない場合や、ユーザー資格証明がルート・アカウントの場合に発生します。
Microsoft Active Directoryフォレスト内の異なるドメイン・コントローラに複数のアダプタを定義する場合は、バインドを含むルーティング設定を使用して、LDAPアダプタが他のアダプタ(同じActive Directoryフォレストを指す複数のアダプタ)からの資格証明にプロキシを設定するように指定できます。

「一般」タブの「pingプロトコルの設定」セクションには、次のフィールドが表示されます。

「pingプロトコルの設定」には、応答していないソースLDAPディレクトリ・サーバーがいつ使用可能になるのかを判別する方法に関するオプションがあります。複数のソース・ディレクトリ・サーバーが構成されている場合、Oracle Virtual Directoryによって応答していないサーバーが識別され、次に使用可能なサーバーに対して後続の操作が実行されます。

pingプロトコル

ソース・ディレクトリ・サーバーにpingする際にOracle Virtual Directoryが使用するプロトコルとして「TCP」または「LDAP」のいずれかを選択します。ソース・ディレクトリ・サーバーがSSLを使用している場合は、「LDAP」を選択します。

注意:
「TCP」プロトコル・オプションは「LDAP」オプションよりも高速ですが、ソース・ディレクトリ・サーバーのネットワーク・ソケットが使用可能であるがそのLDAPサーバー・プロセスを使用できない場合にソース・ディレクトリ・サーバーから不正確なレスポンスが作成されることがあります。

pingバインドDN

「pingプロトコル」として「LDAP」を選択した場合は、そのLDAPバインドに使用するDNを指定します。

pingバインド・パスワード

「pingプロトコル」として「LDAP」を選択した場合は、「pingバインドDN」設定で指定したDNのパスワードを指定します。

12.1.2.2 アダプタのルーティングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「ルーティング」タブをクリックし、第3.2項「ルーティング設定の概要」を参照することで、そのアダプタのルーティングを構成できます。

12.1.2.3 アダプタ・プラグインおよびマッピングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「プラグイン」タブをクリックし、第13.1項「アダプタ・プラグインの管理」および第14.3項「アダプタへのマッピングの適用」を参照することで、そのアダプタにプラグインおよびマッピングを適用できます。

12.1.2.4 SSLで保護されているLDAPアダプタの認証局の管理

Oracle Virtual DirectoryからLDAPアダプタのSSLポートへのSSL接続が失敗し、次のメッセージが表示される場合があります。

Oracle Virtual Directory could not load certificate chain

次に、これが発生する2つの状況の例を示します。

- SSLで保護されている新規LDAPアダプタを作成し、信頼されない認証局を使用した場合

- SSLで保護されている既存のLDAPアダプタの証明書の期限が切れていて、新しい証明書が信頼されない認証局により署名されている場合

この問題を解決するには、証明書を信頼できることをOracle Virtual Directoryが認識できるように、LDAPサーバーの証明書、およびLDAPサーバーの証明書の署名に使用されたルート認証局の証明書の両方を、Oracle Virtual Directoryサーバーにインポートします。

次のkeytoolコマンドと適切な別名をすべて1つのコマンドラインで使用します。

ORACLE_HOME/jdk/jre/bin/keytool -import -trustcacerts
-alias "NEW_CA" -file PATH_TO_CA_CERTIFICATE
-keystore ORACLE_INSTANCE/config/OVD/ovd1/keystores/adapters.jks

Microsoft Active DirectoryおよびMicrosoft Certificate ServicesとのLDAPアダプタの使用

デフォルトでは、期限切れのActive Directory SSL証明書はMicrosoft Certificate Servicesによって自動的に更新されます。ただし、通常、この変更がクライアント・アプリケーションに自動的に通知されることはありません。これが行われた場合、更新されたActive Directoryサーバーに接続しているOracle Virtual Directory LDAPアダプタは機能を停止します。その場合は、Oracle Directory Services Managerを使用してLDAPアダプタを構成し、信頼できる証明書をインポートするとアダプタが再び機能するようになります。

12.1.3 Oracle Virtual DirectoryとOracle Internet Directoryとの間の相互認証SSL接続の構成

Oracle Virtual DirectoryおよびOracle Internet Directory間に相互認証SSL接続を構成するには、次の手順を実行します。

1. 第12.1項「LDAPアダプタの作成」および第12.1.2項「LDAPアダプタの構成」参照して、Oracle Internet DirectoryのLDAPアダプタを作成および構成します。アダプタを構成するときは、非SSLポート番号を使用するように設定してください。

2. ORACLE_INSTANCE/config/OVD/ovd1/adapters.jksが存在しない場合は、次のコマンドを実行して署名付き証明書とともに作成し、信頼できる証明書を格納します。

ORACLE_HOME/jdk/jre/bin/keytool -genkey \
-keystore ORACLE_INSTANCE/config/OVD/ovd1/keystores/adapters.jks \
-storepass password -alias alias -keyalg rsa -dname DN

注意:
前のコマンドの-dnameオプションで指定されたDNは、Oracle Virtual DirectoryがOracle Internet Directoryのクライアントとして機能するときに使用するDNです。
SSL相互認証を機能させるためには、このDNに対応するユーザー・エントリがOracle Internet Directory上に存在する必要があります(または作成する必要があります)。

3. 次のコマンドを使用して、Oracle Internet Directoryサーバーの証明書をBase64形式でエクスポートします。

orapki wallet export -wallet LOCATION_OF_OID_WALLET \
-dn DN_FOR_OID_SERVER_CERTIFICATE -cert ./b64certificate.txt

注意:
orapkiコマンドで証明書別名を使用し、その別名の一部が小文字でない場合は、エラーが発生します。

4. 次のコマンドを使用して、手順3で作成したOracle Internet Directoryサーバーの証明書を、Oracle Virtual Directoryのキーストアに信頼できるエントリとしてインポートします。

ORACLE_HOME/jdk/jre/bin/keytool -importcert \
-keystore ORACLE_INSTANCE/config/OVD/ovd1/keystores/adapters.jks \
-storepass password -alias alias -file b64certificate.txt -noprompt

5. 次のコマンドを使用して、Oracle Virtual Directoryサーバーの証明書をBase64形式でエクスポートします。

ORACLE_HOME/jdk/jre/bin/keytool -exportcert \
-keystore ORACLE_INSTANCE/config/OVD/ovd1/keystores/adapters.jks \
-storepass password -rfc -alias alias -file cert.txt

6. Oracle Virtual Directoryサーバーの証明書を、Oracle Internet Directoryのウォレットに信頼できる証明書としてインポートします。Oracle Internet Directoryのウォレット・ディレクトリから、次のコマンドを実行します。

orapki wallet add -wallet ./ewallet.p12 -cert cert.txt \
-trusted_cert -pwd password

注意:
orapkiコマンドで証明書別名を使用し、その別名の一部が小文字でない場合は、エラーが発生します。

7. Oracle Directory Services Managerを使用して、次のようにOracle Internet DirectoryのLDAPアダプタを更新します。

- 「SSL/TLSの使用」オプションを選択(有効化)します。

- Oracle Internet Directoryで「相互認証」に構成されているSSLポート番号にポート番号を変更します。

- 「SSL認証モード」として「サーバー認証のみ/相互認証」を選択します。

- 「プロキシDN」および「プロキシ・パスワード」オプションは空白のままにしておきます。

- 「適用」ボタンをクリックしてアダプタの変更内容を保存します。

8. Oracle Virtual Directoryサーバーを再起動し、接続の詳細を確認します。そして、アダプタをテストしてください。
テストが成功した場合、アダプタ・ステータスはCertificates Trustedメッセージを表示します。次に例を示します。

opmnctl stopproc ias-component=ovd1
opmnctl startproc ias-component=ovd1

12.2 データベース・アダプタの作成

この項では、データベース・アダプタの作成および構成方法について説明します。この項の内容は次のとおりです。

- Oracle RACデータベース用のデータベース・アダプタの作成

- Oracle TimesTen In-Memory Database用のデータベース・アダプタの作成

- データベース・アダプタの構成

Oracle Directory Services Managerを使用してデータベース・アダプタを作成するには、次の手順を実行します。

注意:
非Oracleデータベースに初めてデータベース・アダプタを作成する前に、Oracle Virtual Directoryにデータベースのドライバをロードする必要があります。Oracle Virtual Directoryサーバーにドライバをロードする方法の詳細は、第9.6.2項「Oracle Virtual Directoryサーバーへのライブラリのロード」を参照してください。
MS SQL 2005または2008のアダプタを作成する場合は、必ず最新のsqljbdc4.jar (SQL JDBCドライバ)を使用してください。古いドライバを使用するとデータベースの表示に問題が発生し、アダプタを正常に作成できません。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタの作成」ボタンをクリックします。新規アダプタ・ウィザードが表示されます。

4. アダプタのタイプを定義するには、次の手順を実行します。

1. 「アダプタ・タイプ」リストから「データベース」を選択します。

2. 「アダプタ名」フィールドにデータベース・アダプタの一意の名前を入力します。アダプタ名の値は、そのアダプタを参照する必要のある他の構成フィールドで使用されます。

3. Oracle Virtual DirectoryとOracle Access Managerを統合している場合以外は、「アダプタ・テンプレート」リストから「デフォルト」を選択します。詳細は、第2.9項「アダプタ・テンプレートの概要」を参照してください。

注意:
アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。

4. 「次へ」をクリックします。「接続」画面が表示されます。

5. 「アダプタ接尾辞/ネームスペース」フィールドに有効なベースDNを(DN形式で)入力します。このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

6. 次の「URLタイプ」リストからオプションを1つ選択します。データベース・アダプタを作成する手順の一部は、選択するオプションによって異なります。オプションを選択したら、各オプションのアルファベットのリストの手順に従ってこの作業を続行します。

- 事前定義済データベースの使用: このオプションは、事前定義済データベースに接続する場合に選択します。事前定義済データベースは、「URLタイプ」リストから「事前定義済データベースの使用」を選択した後に「データベース・タイプ」リストに表示されます。使用するデータベース・タイプがOracle Virtual Directoryに事前に定義されているか不明な場合は、「URLタイプ」リストから「事前定義済データベースの使用」を選択し、使用するデータベースが「データベース・タイプ」リストに含まれているかどうかを確認します。「データベース・タイプ」リストにデータベースがリストされている場合は、次の手順に進みます。データベースがリストされていない場合は、「URLタイプ」リストから「カスタムURLの使用」を選択し、カスタムURLを使用する場合の手順を実行します。

1. 「データベース・タイプ」リストから、データベース・タイプを選択します。データベース・タイプを選択すると、「JDBCドライバ・クラス」および「データベースURL」フィールドにデータベースの適切な情報が移入されます。

2. 「ホスト」フィールドに、データベースのIPアドレスまたはDNSホスト名を入力します。

3. 「ポート」フィールドに、データベースがリスニングするポート番号を入力します。

4. 「データベース名」フィールドに、Oracle SIDなどのデータベース名を入力します。

5. 「データベース・ユーザー」フィールドに、データベース・アダプタがデータベースへの接続に使用するユーザー名を入力します。

6. 「パスワード」フィールドに、「データベース・ユーザー」フィールドに入力したユーザー名のパスワードを入力します。このフィールドに入力する値は、起動時にOracle Virtual Directoryにより、可逆的にマスクされた値に置き換えられます。

7. 「次へ」をクリックします。「データベース表のマップ」画面が表示されます。ここで、手順7に進んでこの手順を続行します。

- カスタムURLの使用: このオプションは、Oracle Virtual Directoryをカスタム・データベースに接続する場合に選択します。

1. 「JDBCドライバ・クラス」フィールドに、データベースのJDBCドライバ・クラスの名前を入力します。

2. 「データベースURL」フィールドに、Oracle Virtual Directoryがデータベースへのアクセスに使用するURLを入力します。

3. 「データベース・ユーザー」フィールドに、データベース・アダプタがデータベースへの接続に使用するユーザー名を入力します。

4. 「パスワード」フィールドに、「データベース・ユーザー」フィールドに入力したユーザー名のパスワードを入力します。このフィールドに入力する値は、起動時にOracle Virtual Directoryにより、可逆的にマスクされた値に置き換えられます。

5. 「次へ」をクリックします。「データベース表のマップ」画面が表示されます。ここで、手順7に進んでこの手順を続行します。

7. 表ファイルの名前を入力するか、「参照」をクリックして表ファイルに移動し、それを選択して「OK」をクリックすることで、データベース・アダプタが使用する必要のあるデータベース表を「データベース表のマップ」フィールドに指定します。「データベース表のマップ」画面で、「次へ」をクリックして続行します。「オブジェクト・クラスのマップ」画面が表示されます。

注意:
手順8でオブジェクト・クラスを定義しない場合、「データベース表のマップ」フィールドに入力した情報は保存できません。

8. 「オブジェクト・クラスのマップ」フィールドで、データベース表にマップするオブジェクト・クラスとそのRDNを定義します。「オブジェクト・クラスの作成」ボタンをクリックします。オブジェクト・クラスおよびそれらに対応するRDNを定義できる「新規オブジェクト・クラス・マッピング」ダイアログ・ボックスが表示されます。次の情報を入力します。

1. 「オブジェクト・クラス」リストに、適切なオブジェクト・クラスを選択します。

2. 「RDN」フィールドに、オブジェクト・クラスのRDNを入力します。

3. 「OK」をクリックします。「オブジェクト・クラス」表に、オブジェクト・クラスとRDNが表示されます。

注意:
既存のオブジェクトを入力することでネストされたオブジェクト・クラスを作成できます。その場合、ネストされたクラスのRDNは子オブジェクト・クラスの属性である必要があります。たとえば、場所情報が使用可能で組織単位(ou)情報の駆動にも使用できる、人々に関する表のレコードに対して親組織単位を作成できます。

9. オブジェクト・クラスのLDAP属性とRDNを、データベース表およびフィールドにマップします。オブジェクト・クラスのRDN値のLDAP属性をマップする必要があります。選択したオブジェクト・クラスのLDAPスキーマに必要なすべてのLDAP属性をマップする必要はありません。

「オブジェクト・クラス」表で適切なオブジェクト・クラスをクリックし、「属性マッピング」表の「マッピング属性の追加」ボタンをクリックします。次の情報を入力します。

- 「LDAP属性」リストから、オブジェクト・クラスのLDAP属性値を選択します。

- 「データベース表:フィールド」リストから、適切なデータベース表とフィールドを選択します。

- オプションで、「データ型」リストから、属性タイプの説明を選択します。

注意:
属性をデータベースのBLOB列にマップする場合は、「データ型」リストからBLOBを選択する必要があります。

10. すべてのオブジェクト・クラスおよび属性マッピングを定義したら、オブジェクト・クラス・マッピングのマップ画面で「次へ」をクリックします。データベース・アダプタの設定がリストされた「概要」画面が表示されます。

11. データベース・アダプタ設定を確認し、「終了」をクリックしてデータベース・アダプタを作成します。「アダプタ」ツリーに、新しいデータベース・アダプタが表示されます。

アダプタが起動すると、Oracle Virtual Directoryがデータベースに接続され、属性を定義されているLDAPスキーマと一致させるために、定義済のすべてのLDAP属性および対応する表と列の情報が取得されます。マップされたLDAP属性がすでに定義されている場合は、データベース・ソースの書式からターゲットLDAPスキーマの書式へのマッピングの作成が試行されます。LDAP属性が未定義の場合は、データベース・アダプタによって、一時的に属性がデータベース書式に最も綿密にマップするサーバー・スキーマに追加されます(この定義は永続Oracle Virtual Directoryスキーマ構成には追加されません)。

データベース・アダプタを作成したら、第12.2.3項「データベース・アダプタの構成」の手順に従って構成できます。

12.2.1 Oracle RACデータベース用のデータベース・アダプタの作成

Oracle RACデータベースとともに使用するデータベース・アダプタを作成するには、第12.2項「データベース・アダプタの作成」の手順に従いますが、「接続」画面でOracle RACデータベースへの接続を構成するときは、次の手順を実行します。

- 「URLタイプ」リストから「カスタムURLの使用」を選択します。

- 「データベースURL」フィールドに、次のようなOracle RACデータベースに接続するためのURLを入力します。

jdbc:oracle:oci:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_
BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host-name-1)(PORT=1521))(ADDRESS=
(PROTOCOL=TCP)(HOST=host-name-2)(PORT=1521)))(CONNECT_
DATA=(SERVER=DEDICATED)(SERVICE_NAME=database-service-name)))

注意:
Oracle Virtual Directoryデータベース・アダプタは、Oracle RACに対して高速接続フェイルオーバー(FCF)をサポートしていません。ただし、Oracle RAインスタンスに障害が発生すると、Oracle Virtual Directoryは存続しているRACインスタンスに再接続します。

12.2.2 Oracle TimesTen In-Memory Database用のデータベース・アダプタの作成

Oracle TimesTen In-Memory Databaseとともに使用するデータベース・アダプタを作成するには、次の手順を実行します。

1. ネイティブOracle TimesTenライブラリがOracle Virtual Directoryからアクセスできない場合、Oracle TimesTen In-Memory Databaseクライアントをインストールする必要があります。

2. Oracle Virtual Directoryのopmn.xmlファイルで、Oracle TimesTenライブラリの場所を追加し、Oracle TimesTen JDBCドライバの場所をクラスパスに追加します。opmn.xmlファイルは次のディレクトリにあります。
ORACLE_INSTANCE/config/OPMN/opmn/

Oracle TimesTenライブラリの場所を設定する場合:

UNIXおよびLinuxプラットフォームの場合はLD_LIBRARY_PATH環境変数を追加します。また、WindowsではPATH環境変数を追加します。

たとえば、UNIXおよびLinuxプラットフォームでは、次のようにLD_LIBRARY_PATH環境変数を追加します。ここで、TIMESTEN_HOMEはOracle TimesTenソフトウェアをインストールしたディレクトリを表します。

注意:
Windowsプラットフォームでは、opmn.xmlファイルで設定するPATH環境変数に、Oracle TimesTen binディレクトリ(TIMESTEN_HOME/binなど)を含める必要があります。

例12-1 UNIX/LinuxでのOracle TimesTenライブラリの場所の設定

<ias-component id="ovd1">
<process-type id="OVD" module-id="OVD">
<environment>
<variable id="TNS_ADMIN" value="$ORACLE_INSTANCE/config"/>
<variable id="LD_LIBRARY_PATH" value="/TIMESTEN_HOME/lib" append="true"/>
</environment>

Oracle TimesTen JDBCドライバの場所をクラスパスに追加する場合:

次のようにTimesTen JDBCドライバのパスが含まれるようjava-classpathを設定します。ここで、TIMESTEN_HOMEはOracle TimesTenソフトウェアをインストールしたディレクトリを表します。

例12-2 Oracle TimesTen JDBCドライバの場所のクラスパスへの追加

<module-data>
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms512m -Xmx512m
-Dvde.soTimeoutBackend=0 -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:
$ORACLE_HOME/jdbc/lib/ojdbc6.jar:/TIMESTEN_HOME/lib/ttjdbc6.jar"/>
</category>
</module-data>

3. OPMNに構成を再ロードし、Oracle Virtual Directoryを停止した後起動します。次に例を示します。
OPMNに構成を再ロードするには、次を実行します。

ORACLE_INSTANCE/bin/opmnctl reload

Oracle Virtual Directoryを停止するには、次を実行します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=NAME_OF_OVD_COMPONENT

Oracle Virtual Directoryを起動するには、次を実行します。

ORACLE_INSTANCE/bin/opmnctl startproc ias-component=NAME_OF_OVD_COMPONENT

4. Oracle TimesTenのデータベース・ソース名(DSN)を作成します。詳細は、Oracle Technology Network Webサイトで『Oracle TimesTenオペレーション・ガイド』を参照してください。

5. Oracle Directory Services Managerを使用してOracle TimesTen用のデータベース・アダプタを作成します。Oracle TimesTen用のデータベース・アダプタを作成する場合、次のようにします。
アダプタがOracle TimesTenクライアントのみのインストール用の場合:

1. 新規データベース・アダプタ・ウィザードの「URLタイプ」リストから「カスタムURLの使用」オプションを選択します。

2. 「JDBCドライバ・クラス」フィールドに次のように入力します。

com.timesten.jdbc.TimesTenDriver

3. 「データベースURL」フィールドに次のように入力します。DSNはステップ4で作成したデータベース・ソース名に置き換えます。

jdbc:timesten:client:dsn=DSN

4. 第12.2項「データベース・アダプタの作成」を参照してアダプタの作成を継続します。

アダプタがOracle TimesTenクライアントおよびサーバー・インストール用の場合:

1. 新規データベース・アダプタ・ウィザードの「URLタイプ」リストから「事前定義済データベースの使用」オプションを選択します。

2. 「データベース・タイプ」リストから「Oracle - Times-Ten」を選択します。

3. 「URLタイプ」リストから「カスタムURLの使用」オプションを選択します。

4. 「データベースURL」フィールドに次のように入力します。DSNはステップ4で作成したデータベース・ソース名に置き換えます。

jdbc:timesten:direct:dsn=DSN

5. 第12.2項「データベース・アダプタの作成」を参照してアダプタの作成を継続します。

注意:
第12.2.3.1項「データベース・アダプタの一般設定の構成」に記載されているとおり、「大/小文字区別なしの検索の有効化」オプションを使用すると、Oracle TimesTenデータベースのuidなどの大/小文字区別なしのLDAP属性の検索時に、データベース・アダプタのパフォーマンスが向上します。
「大/小文字区別なしの検索の有効化」オプションの有効化に加え、検索に使用されるデータベース列の言語索引をデータベースに作成する必要があります。Oracle TimesTenデータベースの言語索引の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』 を参照してください。

12.2.3 データベース・アダプタの構成

この項では、データベース・アダプタ設定の構成方法を説明します。この項の内容は次のとおりです。

- データベース・アダプタの一般設定の構成

- アダプタのルーティングの構成

- アダプタ・プラグインおよびマッピングの構成

12.2.3.1 データベース・アダプタの一般設定の構成

データベース・アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「一般」タブをクリックして次に示すフィールドに値を設定し、「適用」をクリックしてアダプタの一般設定を構成できます。

ルート

このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

アクティブ

アダプタは、アクティブ(有効)または非アクティブ(無効)として構成できます。非アクティブに構成されたアダプタは、サーバーの再起動時やアダプタの起動の試行時には起動しません。非アクティブの設定は、古い構成を使用可能な状態にしておく場合や、構成から削除せずにスタンバイ状態にしておく場合に使用します。デフォルト設定はアクティブです。

「一般」タブの「接続の設定」セクションには、次のフィールドが表示されます。

URLタイプ

次の「URLタイプ」リストからオプションを1つ選択します。データベース・アダプタ接続設定の一部のフィールドは、選択するオプションによって異なります。オプションを選択したら、各オプションにリストされているフィールドを設定して、「接続の設定」の構成を続行します。

- カスタムURLの使用: このオプションは、Oracle Virtual Directoryをカスタム・データベースに接続する場合に選択します。
「JDBCドライバ・クラス」フィールドに、データベースのJDBCドライバ・クラスの名前を入力します。

「データベースURL」フィールドに、Oracle Virtual Directoryがデータベースへのアクセスに使用するURLを入力します。

「データベース・ユーザー」フィールドに、データベース・アダプタがデータベースへの接続に使用するユーザー名を入力します。

「パスワード」フィールドに、「データベース・ユーザー」フィールドに入力したユーザー名のパスワードを入力します。このフィールドに入力する値は、起動時にOracle Virtual Directoryにより、可逆的にマスクされた値に置き換えられます。

- 事前定義済データベースの使用: このオプションは、事前定義済データベースに接続する場合に選択します。事前定義済データベースは、「URLタイプ」リストから「事前定義済データベースの使用」を選択した後に「データベース・タイプ」リストに表示されます。使用するデータベース・タイプがOracle Virtual Directoryに事前に定義されているか不明な場合は、「URLタイプ」リストから「事前定義済データベースの使用」を選択し、使用するデータベースが「データベース・タイプ」リストに含まれているかどうかを確認します。「データベース・タイプ」リストにデータベースがリストされている場合は、次の手順に進みます。データベースがリストされていない場合は、「URLタイプ」リストから「カスタムURLの使用」を選択し、カスタムURLを使用する場合の手順を実行します。
「データベース・タイプ」リストから、データベース・タイプを選択します。データベース・タイプを選択すると、「JDBCドライバ・クラス」および「データベースURL」フィールドにデータベースの適切な情報が移入されます。

「ホスト」フィールドに、データベースのIPアドレスまたはDNSホスト名を入力します。

「ポート」フィールドに、データベースがリスニングするポート番号を入力します。

「データベース名」フィールドに、Oracle SIDなどのデータベース名を入力します。

「データベース・ユーザー」フィールドに、データベース・アダプタがデータベースへの接続に使用するユーザー名を入力します。

「一般」タブの「設定」セクションには、次のフィールドが表示されます。

Objectclassの変更の無視

データベースのオブジェクト・クラスは論理オブジェクトであり、マッピングで表の列に直接マップされないため、オブジェクト・クラス属性を変更するとエラーが発生することがあります。「Objectclassの変更の無視」オプションが有効化されている場合、データベース・アダプタによってオブジェクト・クラス属性の参照がすべて削除され、エラーはクライアント・アプリケーションに送信されず、無視されます。「Objectclassの変更の無視」オプションが選択されていない場合、エラー・メッセージはクライアント・アプリケーションに送信されます。

オブジェクト・クラスのスーパー・クラスを含む

この設定を使用すると、データベース・アダプタにより、オブジェクト・クラス属性のメインのオブジェクト・クラスとともに、オブジェクト・クラスの親クラスもリストされます。Microsoft Active Directoryサーバーのスキーマをエミュレートする場合には、この設定を無効化します。objectclass=xxxという問合せが親のオブジェクト・クラス値に対して実行されるため、ほとんどのシナリオで、この設定を有効化しておくと便利です。

大/小文字区別なしの検索の有効化

「大/小文字区別なしの検索の有効化」オプションを有効化(選択)すると、uidなどの大/小文字の区別のないLDAP属性が、大/小文字区別なしで検索されます。Oracle Virtual Directoryは、「大/小文字区別なしの検索の有効化」オプションが有効な場合、SQL問合せのUPPERを使用します。データベースが、Oracle TimesTenデータベースまたはMySQLデータベースなどの機能別索引を保持できない場合は、「大/小文字区別なしの検索の有効化」オプションを無効にする必要があります。「大/小文字区別なしの検索の有効化」オプションを無効にすると、Oracle Virtual Directoryは大/小文字を区別して検索を実行し、SQL問合せのUPPERを使用しません。「大/小文字区別なしの検索の有効化」オプションのデフォルト値は、「有効」有効です。

最大接続数

この設定は、データベース・アダプタがデータベースに作成する最大接続数を定義します。(デフォルトは10です。)

接続待機タイムアウト

この設定は、データベースとの接続の確立中、タイムアウトするまでにデータベース・アダプタが待機する期間(秒単位)を定義します。(デフォルトは10です。)

注意:
「最大接続数」および「接続待機タイムアウト」パラメータの許容可能な最小および最大設定は、Oracle Virtual Directoryとそのデータベースを実行しているシステムに応じて異なります。

「一般」タブの「DB/LDAPマッピング」セクションには、次のフィールドが表示されます。

使用データベース表

このフィールドには、データベース・アダプタが使用するように設定されているデータベース表が表示されます。データベース表を追加するには、「追加」ボタンをクリックし、表ファイルに移動して選択し、「OK」をクリックします。

「一般」タブの「オブジェクト・クラス」セクションには、次のフィールドが表示されます。

オブジェクト・クラス

このフィールドには、データベース表にマップするオブジェクト・クラスとそのRDNが表示されます。オブジェクト・クラス・マッピングを追加するには、「作成」ボタンをクリックして「オブジェクト・クラス」リストから適切なオブジェクト・クラスを選択し、「RDN」フィールドにそのオブジェクト・クラスのRDN値を入力して「OK」をクリックします。

12.2.3.2 アダプタのルーティングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「ルーティング」タブをクリックし、第3.2項「ルーティング設定の概要」を参照することで、そのアダプタのルーティングを構成できます。

12.2.3.3 アダプタ・プラグインおよびマッピングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「プラグイン」タブをクリックし、第13.1項「アダプタ・プラグインの管理」および第14.3項「アダプタへのマッピングの適用」を参照することで、そのアダプタにプラグインおよびマッピングを適用できます。

12.3 ローカル・ストア・アダプタの作成

この項では、ローカル・ストア・アダプタの作成および構成方法について説明します。この項の内容は次のとおりです。

- ローカル・ストア・アダプタの構成

Oracle Directory Services Managerを使用してローカル・ストア・アダプタを作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタの作成」ボタンをクリックします。新規アダプタ・ウィザードが表示されます。

4. アダプタのタイプを定義するには、次の手順を実行します。

1. 「アダプタ・タイプ」リストから「ローカル・ストア」を選択します。

2. 「アダプタ名」フィールドにローカル・ストア・アダプタの一意の名前を入力します。アダプタ名の値は、そのアダプタを参照する必要のある他の構成フィールドで使用されます。

3. 第2.9項「アダプタ・テンプレートの概要」を参照して、「アダプタ・テンプレート」リストからアダプタ・テンプレートを選択します。使用するテンプレートが不明な場合は、「デフォルト」テンプレートを使用します。

注意:
アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。

4. 「次へ」をクリックします。「設定」画面が表示されます。

5. 「アダプタ接尾辞/ネームスペース」フィールドに有効なベースDNを(DN形式で)入力します。このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

6. 「アダプタ接尾辞の作成」オプションを選択し、「アダプタ接尾辞/ネームスペース」フィールドで指定した値を使用してローカル・ストア・アダプタのベース・エントリを作成します。

注意:
「アダプタ接尾辞の作成」オプションを有効化した場合、「設定」画面で「次」をクリックすると「オブジェクト・クラス」画面が表示されます。「オブジェクト・クラス」画面が表示されたら、ローカル・ストア・アダプタのベース・エントリのオブジェクト・クラスを選択します。

7. 「データベース・ファイル」フィールドに、Oracle Virtual Directoryインストールに相対的なパスと、ローカル・ストア・アダプタ・データファイルの一意のファイル名接頭辞を入力します。有効な名前は、data/localDBなどです。複数のローカル・ストア・アダプタを使用している場合、この値は、アダプタごとに一意にする必要があり、それ以外の場合はデータの破損が発生します。

8. 「キャッシュ・サイズ」フィールドにローカル・ストア・アダプタ・キャッシュのサイズを入力します。「キャッシュ・サイズ」オプションにより、常に最後にアクセスまたは書き込まれたエントリが含まれるローカル・ストア・アダプタによりキャッシュされるエントリの数が決定されます。エントリのサイズにより、必要なメモリー量が決まります。

注意:
グループやバイナリ・オブジェクトなどの大規模なエントリを格納すると、Oracle Virtual Directoryで、通常より多くのメモリーが消費される可能性があります。Oracle Virtual Directoryで使用できる全体的なメモリー量を増やすことを検討してください。

9. 「パスワード・ハッシュ・モード」リストからオプションを選択して、パスワード・ハッシュ・タイプを選択します。最もセキュアなアルゴリズムはSSHAですが、互換性を考慮してその他のアルゴリズムも提供されています。「PLAIN」を選択すると、ハッシュしないと値付けされたパスワードは、内部のローカル・ストア・アダプタのデータ・ストアに残ります。

10. 「バックアップ・ファイル」フィールドに、Oracle Virtual Directoryインストールに相対的なパスと、自動バックアップが格納される一意のファイル名を入力します。有効なバックアップ・ファイルは、backup/localDBなどです。別のローカル・ストア・アダプタによる上書きを防ぐため、バックアップ・ファイル名はローカル・ストア・アダプタ固有のものにする必要があります。

11. 「バックアップ時間 - 時間」フィールドに時間(0から23)を入力し、ローカル・ストア・アダプタの自動バックアップを実行する時間を設定します。

12. 「バックアップ時間 - 分」フィールドに分(0から59)を入力し、ローカル・ストア・アダプタの自動バックアップを実行する分を設定します。

13. 「バックアップ・ファイルの最大数」フィールドにバックアップ・ファイルの最大数を入力し、ローカル・ストア・アダプタのバックアップ・ファイルのローテーションを維持します。

14. 「次へ」をクリックします。「オブジェクト・クラス」画面が表示されます。

15. メニューからオブジェクト・クラスを選択します。

- dcObject。

- domain。

- orclMailPop3Conf。

16. 「次へ」をクリックします。ローカル・ストア・アダプタの設定がリストされた「概要」画面が表示されます。

17. ローカル・ストア・アダプタ設定を確認し、「終了」をクリックしてローカル・ストア・アダプタを作成します。「アダプタ」ツリーに、新しいローカル・ストア・アダプタが表示されます。

ローカル・ストア・アダプタを作成したら、第12.3.1項「ローカル・ストア・アダプタの構成」の手順に従って構成できます。

12.3.1 ローカル・ストア・アダプタの構成

この項では、ローカル・ストア・アダプタ設定の構成方法を説明します。この項の内容は次のとおりです。

- ローカル・ストア・アダプタの一般設定の構成

- アダプタのルーティングの構成

- アダプタ・プラグインおよびマッピングの構成

12.3.1.1 ローカル・ストア・アダプタの一般設定の構成

ローカル・ストア・アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「一般」タブをクリックして次に示すフィールドに値を設定し、「適用」をクリックしてアダプタの一般設定を構成できます。

ルート

このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

アクティブ

アダプタは、アクティブ(有効)または非アクティブ(無効)として構成できます。非アクティブに構成されたアダプタは、サーバーの再起動時やアダプタの起動の試行時には起動しません。非アクティブの設定は、古い構成を使用可能な状態にしておく場合や、構成から削除せずにスタンバイ状態にしておく場合に使用します。デフォルト設定はアクティブです。

読取り専用

「読取り専用」オプションを有効化すると、アダプタが変更トランザクションを受け付けず、検索のみが可能になります。デフォルト設定では無効化されており、アダプタは読取り/書込みモードです。

「一般」タブの「索引」セクションには、次のフィールドが表示されます。

所在

「所在」フィールドには、(attrname=*)形式の検索フィルタの操作に必要で、エントリ内での所在を迅速に特定する必要のある属性タイプのリストが含まれます。リストに属性を追加するには、「追加」をクリックし、表示されるダイアログ・ボックスから属性を選択して「OK」をクリックします。

完全

「完全」索引フィールドには、sn=smithなど、完全一致索引の検索をサポートする属性のリストが含まれます。順序付き索引を使用している場合、この索引は冗長です。リストに属性を追加するには、「追加」をクリックし、表示されるダイアログ・ボックスから属性を選択して「OK」をクリックします。

順序

「順序」フィールドには、順序付け検索(sn<=Smithなど)、完全一致検索、および最初のサブストリングによる検索(sn=Smi*など)を有効化する属性のリストが含まれます。LDAPフィルタでは<=および>=順序関係のみを使用できます。 <および>はLDAPv3ではサポートされていません。リストに属性を追加するには、「追加」をクリックし、表示されるダイアログ・ボックスから属性を選択して「OK」をクリックします。

サブストリング

「サブストリング」オプションは、順序付き索引に加え、sn=*ithなど、最後のサブストリングによる検索が必要な場合にのみ必要です。通常、最初のサブストリングによる検索は、順序付き索引を使用して処理されます。リストに属性を追加するには、「追加」をクリックし、表示されるダイアログ・ボックスから属性を選択して「OK」をクリックします。

索引付けされていない検索

特に索引付けされていない属性の、低パフォーマンスでの検索を有効化または無効化します。「索引付けされていない検索」が無効化されている場合、索引付けされていない属性の検索では結果が戻されません(falseと評価されます)。

「一般」タブの「セキュリティ」セクションには、次のフィールドが表示されます。

センシティブ属性の有効化

センシティブ属性を有効化または無効化します。これは暗号化された値を持つローカル・ストア・アダプタの属性です。「センシティブ属性の有効化」オプションを有効化する場合、「センシティブ属性」フィールドを使用して値を暗号化する属性を指定する必要があります。

センシティブ属性

「センシティブ属性の有効化」を選択すると、「センシティブ属性」フィールドにリストされた属性の値が暗号化されます。

「一般」タブの「データベース」セクションには、次のフィールドが表示されます。

データベース・ファイル

ORACLE_INSTANCE/ovd/SYSTEM_COMPONENT_NAMEに相対的なパスと、ローカル・ストア・アダプタ・データファイルの一意のファイル名接頭辞を入力します。SYSTEM_COMPONENT_NAMEは通常、ovd1です。複数のローカル・ストア・アダプタを使用している場合、この値は、アダプタごとに一意にする必要があり、それ以外の場合はデータの破損が発生します。

パスワード・ハッシュ・モード

「パスワード・ハッシュ・モード」リストからオプションを選択して、パスワード・ハッシュ・タイプを選択します。最もセキュアなアルゴリズムはSSHAですが、互換性を考慮してその他のアルゴリズムも提供されています。「PLAIN」を選択すると、ハッシュしないと値付けされたパスワードは、内部のローカル・ストア・アダプタのデータ・ストアに残ります。

自動RDN

エントリを追加する場合、LDAP RFCでは、追加するエントリの属性リストに相対識別名(RDN)、つまり一番左のDN項目が存在することが必要とされています。いくつかのディレクトリ製品ベンダーでは、これが無視されて属性リストにRDN値がなくても許容されていますが、それにより、この動作に依存しているアプリケーションで互換性の問題が発生することがあります。「自動RDN」を有効化すると、Oracle Virtual Directoryによって欠落している属性を自動的に作成できます。デフォルト設定では無効化されています。

自動圧縮

データベースを正常にバックアップしたら、Oracle Virtual Directoryでは、オプションでデータベース・ファイルを圧縮できます。ローカル・ストア・アダプタ・データが頻繁に変更される場合は、データベースを管理可能なサイズに維持するのに役立ちます。デフォルト設定では無効化されています。

注意:
Windowsプラットフォームでは、「自動圧縮」機能を無効化することをお薦めします。Windowsでは、ファイル名の変更機能が保証されず、データの破損や損失につながる場合があります。

トランザクション・ログ・サイズ

新規エントリの追加や変更が行われると、まずトランザクション・ログに書き込まれ、トランザクションのディスクへの書込みが保証されるだけでなく、アプリケーションのレスポンスも高速になります。

このオプションでは、トランザクション・ログを切り捨てるサイズ(バイト単位)を決定します。未処理のトランザクションが原因で、ログがこのオプションにリストされているサイズを超えたとしても、データ・ストアへの配置および索引付けが行われていないエントリは、トランザクション・ログから削除されません。

継続的に切捨てが行われる小さなトランザクション・ログの場合、大量のエントリが追加されると、かなりの量のオーバーヘッドが追加されます。初期一括ロードに備えてトランザクション・ログは可能なかぎり大きくし、本番環境に移行する前に、後からサイズを小さくします。

キャッシュ・サイズ

このオプションでは、ローカル・ストア・アダプタによりメモリー内にキャッシュされるエントリ数を決定します。最後にアクセスまたは書き込まれたエントリが必ず含まれます。必要なメモリー量は、エントリのサイズにより決定されます。

グループやバイナリ・オブジェクトなどの大規模なエントリを格納すると、Oracle Virtual Directoryで、通常より多くのメモリーが消費される可能性があります。Oracle Virtual Directoryで使用できる全体的なメモリー量を増やすことを検討してください。

「一般」タブの「バックアップ」セクションには、次のフィールドが表示されます。

バックアップ・ファイル

ORACLE_INSTANCE/ovd/SYSTEM_COMPONENT_NAMEに相対的な、自動バックアップの格納先となる一意のファイル名を指すパス。SYSTEM_COMPONENT_NAMEは通常、ovd1です。別のローカル・ストア・アダプタによる上書きを防ぐため、バックアップ・ファイル名はローカル・ストア・アダプタ固有のものにする必要があります。

バックアップ時間 - 時間

ローカル・ストア・アダプタの自動バックアップを実行する時間(0から23)。

バックアップ時間 - 分

ローカル・ストア・アダプタの自動バックアップを実行する分(0から59)。

バックアップ・ファイルの最大数

ローカル・ストア・アダプタのバックアップ・ファイルのローテーションに維持するバックアップ・ファイルの最大数。

12.3.1.2 アダプタのルーティングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「ルーティング」タブをクリックし、第3.2項「ルーティング設定の概要」を参照することで、そのアダプタのルーティングを構成できます。

12.3.1.3 アダプタ・プラグインおよびマッピングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「プラグイン」タブをクリックし、第13.1項「アダプタ・プラグインの管理」および第14.3項「アダプタへのマッピングの適用」を参照することで、そのアダプタにプラグインおよびマッピングを適用できます。

12.4 結合ビュー・アダプタの作成

この項では、結合ビュー・アダプタの作成および構成方法について説明します。この項の内容は次のとおりです。

- 結合ビュー・アダプタの構成

- Oracle Internet Directory用のShadow結合ビュー・アダプタの構成

注意:
この項では、結合ビュー・アダプタを使用して結合するアダプタがすでに存在していることを前提としています。

結合ビュー・アダプタ作成のための前提条件

任意のタイプの結合ビュー・アダプタを作成およびデプロイする前に、結合ビュー・アダプタのプライマリ・アダプタとなるアダプタを作成する必要があります。詳細は、「結合ビュー・アダプタのプライマリ・アダプタ」を参照してください。

Shadow結合ビュー・アダプタを作成する前に、プライマリ・アダプタを作成することに加え、Oracle Internet Directoryに接続するLDAPアダプタ、またはShadowエントリを格納するローカル・ストア・アダプタを作成する必要があります。LDAPアダプタとOracle Internet Directoryを使用する場合は、LDAPアダプタのベースDNがOracle Internet Directoryに存在する必要があります。ローカル・ストア・アダプタを使用する場合は、ローカル・ストア・アダプタのベースDNがOracle Virtual Directoryに存在する必要があります。

結合ビュー・アダプタの作成

前提条件を満たしたら、Oracle Directory Services Managerを使用して、結合ビュー・アダプタを作成するための次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタの作成」ボタンをクリックします。新規アダプタ・ウィザードが表示されます。

4. アダプタのタイプを定義するには、次の手順を実行します。

1. 「アダプタ・タイプ」リストから「結合」を選択します。

2. 「アダプタ名」フィールドに結合アダプタの一意の名前を入力します。アダプタ名の値は、そのアダプタを参照する必要のある他の構成フィールドで使用されます。

3. 「アダプタ・テンプレート」リストから「デフォルト」テンプレートを選択します。

注意:
アダプタ・テンプレートを選択すると、Oracle Directory Services Managerによってアダプタ設定の一部のデフォルト値が移入されます。これらのデフォルト値は、使用する環境に合せて変更する必要があります。

4. 「次へ」をクリックします。「設定」画面が表示されます。

5. 「アダプタ接尾辞/ネームスペース」フィールドに、結合ビュー・アダプタが情報を提供するルートDNを入力します。定義されているDNとその下の子エントリは、アダプタのネームスペースです。このフィールドに入力する値は、仮想ディレクトリのクライアントに表示される値です。値は、カンマ区切りの識別名として指定する必要があります。

注意:
結合ビュー・アダプタのルートDNは、プライマリ・アダプタまたは任意の結合アダプタのルートDNと異なることを確認してください。予期しない重複が発生する場合があります。

6. 「プライマリ・アダプタ」リストから選択することで、結合ビュー・アダプタのプライマリ・アダプタを選択します。プライマリ・アダプタは、結合ビューのデータのプライマリ・ドライバで、結合ビュー・アダプタがディレクトリ階層を構築するときに使用されます。結合ビュー・アダプタのエントリが存在するのは、プライマリ・アダプタ内にある場合にのみです。任意のアダプタをプライマリ・アダプタにできます。詳細は、「結合ビュー・アダプタのプライマリ・アダプタ」を参照してください。

注意:
結合ビューを定義およびデバッグしたら、プライマリ・アダプタの「可視性」ルーティング設定を非表示に設定し、結合されないエントリをLDAPクライアントに非表示にできます。

7. 「バインド・アダプタ」フィールドにバインド検証を実行するアダプタの名前を入力するか、「参照」をクリックしてアダプタを選択します。LDAPクライアントはプライマリ・アダプタに基づいてDNとバインドできますが、別のアダプタの結合エントリに対してパスワードが確認されることがあります。バインド・アダプタは、プライマリ・アダプタまたは結合アダプタのいずれかである必要があります。

8. 「次へ」をクリックします。結合ビュー・アダプタ設定の概要が表示された「概要」画面が表示されます。

9. 結合ビュー・アダプタ設定を確認し、「終了」をクリックして結合ビュー・アダプタを作成します。「アダプタ」ツリーに、新しい結合ビュー・アダプタが表示されます。

結合ビュー・アダプタを作成したら、第12.4.1項「結合ビュー・アダプタの構成」の手順に従って構成できます。

12.4.1 結合ビュー・アダプタの構成

この項では、結合ビュー・アダプタ設定の構成方法を説明します。この項の内容は次のとおりです。

- 結合ビュー・アダプタの一般設定および結合ルールの構成

- アダプタのルーティングの構成

- アダプタ・プラグインおよびマッピングの構成

12.4.1.1 結合ビュー・アダプタの一般設定および結合ルールの構成

結合ビュー・アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「一般」タブをクリックして次に示すフィールドに値を設定し、「適用」をクリックしてアダプタの一般設定と結合ルールを構成できます。

ルート

このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

注意:
結合ビュー・アダプタのルートDNは、プライマリ・アダプタまたは任意の結合アダプタのルートDNと異なることを確認してください。予期しない重複が発生する場合があります。

アクティブ

アダプタは、アクティブ(有効)または非アクティブ(無効)として構成できます。非アクティブに構成されたアダプタは、サーバーの再起動時やアダプタの起動の試行時には起動しません。非アクティブの設定は、古い構成を使用可能な状態にしておく場合や、構成から削除せずにスタンバイ状態にしておく場合に使用します。デフォルト設定はアクティブです。

「一般」タブの「設定」セクションには、次のフィールドが表示されます。

DN属性

member、uniquemember、managerなど、ネームスペース変換が必要なDNとして処理される属性のリスト。たとえば、これらの属性が「DN属性」リストにある場合、プロキシ・ディレクトリからのグループ・エントリを読み取る際には、Oracle Virtual Directoryでuniquememberまたはmember属性だけでなく、グループ・エントリ自体のDNが自動的に変換されます。

注意:
クライアント・アプリケーションで使用する必要があるとわかっている属性のみを変換します。可能性のあるすべてのDN属性を入力する必要はありません。入力すると、プロキシで消費されるCPU時間が少し増加します。

「DN属性のマップ」リストに属性を追加するには、次のようにします。

1. 「追加」をクリックします。「DN属性の選択」ダイアログ・ボックスが表示されます。

2. 追加する属性を選択します。

3. 「OK」をクリックします。

プライマリ・アダプタ

プライマリ・アダプタは、結合ビューのデータのプライマリ・ドライバで、結合ビュー・アダプタがディレクトリ階層を構築するときに使用されます。結合ビュー・アダプタのエントリが存在するのは、プライマリ・アダプタ内にある場合にのみです。任意のアダプタをプライマリ・アダプタにできます。詳細は、「結合ビュー・アダプタのプライマリ・アダプタ」を参照してください。

バインド・アダプタ

バインド処理に使用される1つ以上のアダプタ名のリスト。デフォルトで、プライマリ・アダプタが使用されますが、上書きして別のアダプタを1つ以上リストできます。結合ビュー・アダプタは、ターゲット・アダプタに対する結合の完了と、バインド処理を試行します。バインドに成功すると処理が停止し、クライアントに成功が戻されます。バインドに失敗した場合、結合ビュー・アダプタは、「バインド・アダプタ」リストの各アダプタのバインドを試行し続けます。バインドの失敗が戻されるのは、すべてのバインド・アダプタが失敗した場合のみです。これは、ユーザーIDが複数のディレクトリに存在し、クライアントに複数のディレクトリに対するパスワード検証を実行させる場合に便利です。

結合ルール

結合ビュー・アダプタの結合関係を作成するには、次の手順を実行します。

1. 「作成」ボタンをクリックします。「結合ルール」ダイアログ・ボックスが表示されます。

2. 結合ビュー・アダプタと結合するアダプタを、「アダプタ」リストから選択します。

3. 「タイプ」リストから結合関係を1つ選択し、結合ビュー・アダプタの結合関係タイプを選択します。結合関係の詳細は、第2.5.2項「結合関係」を参照してください。

4. 次のようにして、「条件」フィールドに結合条件を入力します。

- SimpleジョイナおよびOneToManyジョイナの場合は、remoteattribute=primaryadapterattributeという形式で条件を入力します。ここで、remoteattributeはターゲット結合アダプタの属性で、primaryadapterattrinuteはプライマリ・アダプタの属性です。

- Shadowジョイナの場合は、名前の変更の際にレコードの検出に使用できるuidなど、プライマリ・アダプタの一意のキー属性名を入力します。Shadowジョイナでは、他のジョイナとは異なり、条件は等価条件ではありません。

- ConditionalSimpleJoinerの場合は、;文字、およびemployeenumber>0など、その場合にのみ結合が行われる追加の条件を使用して、条件のSimpleジョイナ・タイプを拡張します。
たとえば、Simpleジョイナ条件がemployeenumber=employeenumberであるとします。

;文字や、次のような追加の条件を使用して、ConditionalSimpleJoiner用にこの条件を拡張します。

employeenumber=employeenumber;(&(employeenumber=101)(sn=Smith))

5. 「結合ルール」ダイアログ・ボックスで「OK」をクリックし、結合関係の情報を保存します。「結合ルール」表に結合関係情報が表示されます。

6. 「一般」タブのページ上部にある「適用」をクリックして、結合をデプロイします。

注意:
キーの異なる2つのアダプタをプライマリ・アダプタに結合するには、それぞれに単一のキーを持つ複数の結合ルールを作成します。単一の結合ルールの作成に複数のキーが必要な際には、固有の基準に応じて、ConditionalSimpleJoinerを使用できる場合や、カスタムの結合ルールの書込みが必要な場合があります。

結合ビュー・アダプタの結合関係を変更する手順は、次のとおりです。

1. 「結合ルール」表で変更する結合関係の名前をクリックします。画面の下半分に結合関係の設定が表示された分割画面が表示されます。

2. 必要に応じて結合関係を編集します。

3. 画面の下半分にある「適用」をクリックして変更内容を保存します。

4. 「一般」タブのページ上部にある「適用」をクリックして、結合をデプロイします。

結合ビュー・アダプタの結合関係を削除するには、次の手順を実行します。

1. 「結合ルール」表で削除する結合関係の名前をクリックします。

2. 「結合ルール」表で、「削除」ボタンをクリックします。結合関係の削除の確認を要求する確認のダイアログ・ボックスが表示されます。

3. 確認のダイアログ・ボックスで「削除」をクリックし、結合関係を削除します。「結合ルール」表から結合関係が削除されます。

12.4.1.2 アダプタのルーティングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「ルーティング」タブをクリックし、第3.2項「ルーティング設定の概要」を参照することで、そのアダプタのルーティングを構成できます。さらに、結合ビュー・アダプタ・ルーティングを構成する際の次の固有情報を確認してください。

- プライマリ・アダプタのルーティング

- 結合ビュー・アダプタのローカル・ストア・ディレクトリとしてのローカル・ストア・アダプタのルーティング

プライマリ・アダプタのルーティング

結合ビュー・アダプタのプライマリ・アダプタは結合ビューのデータのプライマリ・ドライバであり、結合ビュー・アダプタがディレクトリ階層を構築するときに使用されるため、プライマリ・アダプタのルーティングも構成する必要があります。

プライマリ・アダプタの「取得可能な属性」および「格納可能な属性」ルーティング設定を変更して、どの属性をプライマリ・アダプタに書き込むかを制御します。Oracle Virtual Directoryがプライマリ・アダプタに変更を書き込めないようにする場合は、「格納可能な属性」を_neverに設定します。

結合ビュー・アダプタのローカル・ストア・ディレクトリとしてのローカル・ストア・アダプタのルーティング

ローカル・ストア・アダプタを、結合ビュー・アダプタのローカル・ストア・ディレクトリとして使用している場合は、ローカル・ストア・アダプタのルーティング設定の調整が必要な場合があります。

ローカルに書き込まれる属性のみがリストされるように、ローカル・ストア・アダプタの「格納可能な属性」ルーティング設定を変更します。結合ルールで使用される一意のキー属性およびvdeprimaryref属性を含めます。LDAPクライアントに表示しない場合は、オプションで、「可視性」ルーティング設定を「内部」に設定します。

12.4.1.3 アダプタ・プラグインおよびマッピングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「プラグイン」タブをクリックし、第13.1項「アダプタ・プラグインの管理」および第14.3項「アダプタへのマッピングの適用」を参照することで、そのアダプタにプラグインおよびマッピングを適用できます。

12.4.2 Oracle Internet Directory用のShadow結合ビュー・アダプタの構成

次の手順は、結合ビューShadowアダプタをOracle Internet Directoryとともに使用するよう構成するためのプロセスの概要を示します。

Oracle Internet Directoryでの手順:

1. Oracle Internet Directoryスキーマを拡張し、次の手順を実行してshadowオブジェクト/属性のサポートを追加します。

1. 次の情報を使用してLDIFファイルを作成します。

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.17119.1.0.1 NAME 'vdeprimaryref' EQUALITY
caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' USAGE
userApplications )

dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.17119.1.1.1 NAME 'vdeShadowObject' SUP 'top'
STRUCTURAL MUST vdeprimaryref )

2. Oracle Internet Directoryのldapmodifyツールを使用し、次のようにしてLDIFファイルをインポートします。

ldapmodify -h ORACLE_INTERNET_DIRECTORY_HOST
-p ORACLE_INTERNET_DIRECTORY_PORT -D bindDN -q -v -f PATH_TO_LDIF_FILE

2. cn=shadowentries orclcontainerオブジェクトを作成して、その他の通常ユーザー・エントリを含むシャドウ・エントリとの混同を避けるために、通常ユーザーとは別のブランチにシャドウ・エントリを格納します。

Oracle Virtual Directoryでの手順:

1. 手順2で作成したOracle Internet Directoryのブランチに接続するLDAPアダプタを作成し、Shadow結合のみがアクセスするように可視性を「内部」に設定します。

2. 「格納可能な属性」フィールドに、シャドウ・エントリに格納する属性のカンマ区切りのリストが続くvdeprimaryref,uidを追加します。プライマリ・アダプタでDNが変更される場合は、uidをエントリの識別に使用できる属性の名前に置き換えます。たとえば、次のようになります。

vdeprimaryref,uid,cn,obpasswordhistory

3. Shadow結合がLDAPクライアントに対して表示されるエントリになるように、プライマリ・アダプタの可視性を「内部」に設定します。

4. 新しい結合ビュー・アダプタを作成し、バインド・アダプタをプライマリ・アダプタに設定します。

5. 次のようにして、新しいShadow結合ルールを作成します。

1. 結合アダプタが、手順1で作成したShadow LDAPアダプタになるように設定します。

2. uidを条件値として設定します。エントリのプライマリ・キー属性として別の属性を使用している場合は、uidを適切な値に置き換えます。

これらの手順の完了後、結合ビュー経由で公開されているエントリを更新する際には、次の操作が行われます。

- Oracle Virtual Directoryにより、プライマリ・アダプタおよびShadow LDAPに書き込む必要のある属性が決定されます。

- Oracle Virtual DirectoryによりShadow LDAPへの書込みが行われる場合、(vderef属性および条件属性値を確認することで)LDAPサーバーにシャドウ設定されたエントリが存在することがまず確認されます。Oracle Virtual Directoryがエントリを検出できない場合は、エントリの作成および属性の更新が行われます。

- 更新の完了後にOracle Virtual Directoryに接続すると、LDAPクライアントには、すべての属性とともに全エントリが表示されます。

13 Oracle Virtual Directoryのプラグインの管理

この章では、Oracle Virtual Directoryのプラグインの管理方法について説明します。この章の内容は次のとおりです。

- 第13.1項「アダプタ・プラグインの管理」

- 第13.2項「グローバル・サーバー・プラグインの管理」

13.1 アダプタ・プラグインの管理

この項では、アダプタ・プラグインの様々な管理タスクについて説明します。この項の内容は次のとおりです。

- アダプタ・プラグインの作成

- 特定の操作に対してのみ実行するためのアダプタ・プラグインの構成

- アダプタ・プラグインの編集

- アダプタ・プラグインの削除

13.1.1 アダプタ・プラグインの作成

アダプタを作成したら、アダプタにプラグインを作成できます。

注意:
アダプタの作成後にデフォルトで、すべてのアダプタにPerformance Monitorプラグインが追加されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlで各アダプタのパフォーマンス・メトリックを表示できるようになります。

Oracle Directory Services Managerを使用してアダプタにプラグインを作成するには、次の手順を実行します。

関連項目:
Oracle Virtual Directoryのプラグインの概要

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. アダプタ・ツリーで、プラグインを作成するアダプタの名前をクリックします。アダプタの構成画面が表示されます。

4. 「プラグイン」タブをクリックします。

5. 「プラグインの作成」ボタンをクリックします。「プラグイン」ダイアログ・ボックスが表示されます。

6. 「名前」フィールドにプラグインの名前を入力します。

7. 「クラス」フィールドにプラグインのクラス名を入力するか、「参照」をクリックし、「プラグインの選択」ボックスからプラグインを選択して「OK」をクリックします。

8. 「パラメータ」表の「パラメータの作成」ボタンをクリックして「名前」リストからパラメータを選択し、「値」フィールドにパラメータの値を入力して、プラグインにパラメータと値を追加します。

9. 「ネームスペース」表の「ネームスペースの作成」ボタンをクリックし、「ネームスペース」フィールドにネームスペースの値を入力して、プラグインにネームスペースを追加します。

10. 「OK」をクリックしてプラグイン設定を保存します。アダプタ画面のこのアダプタのデプロイ済プラグインの表に、このプラグインが追加されます。

11. オプションで、このプラグインが「バインド」、「追加」、「取得」などの特定の操作に対して実行されるように構成することもできます。詳細は、「特定の操作に対してのみ実行するためのアダプタ・プラグインの構成」を参照してください。

12. アダプタ画面の「適用」ボタンをクリックし、プラグインとアダプタを関連付けます。

13.1.2 特定の操作に対してのみ実行するためのアダプタ・プラグインの構成

アダプタ・プラグインが「バインド」、「追加」、「取得」などの特定の操作に対してのみ実行されるように構成することもできます。特定の操作に対してアダプタ・プラグインを実行する順序を構成することもできます。

アダプタ・プラグインを特定の操作に対してのみ、そして特定の順序で実行するように構成するには、次の手順を実行します。

注意:
次の手順は、プラグインが作成済で、アダプタにデプロイ済であると想定しています。それ以外の場合は、次の手順を実行する前に「アダプタ・プラグインの作成」を参照してプラグインを作成してください。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 構成するプラグインを含むアダプタの名前をクリックします。メイン画面にアダプタの構成が表示されます。

4. 「プラグイン」タブをクリックします。

5. 「操作の選択」リストから、プラグインの実行対象として特定する操作を選択します。たとえば、取得操作に対してのみプラグインを実行するように構成するには「取得」を選択します。

6. 特定の操作のプラグインの表で「プラグインの編集」(鉛筆)ボタンをクリックします。たとえば、「操作の選択」リストで「取得」操作を選択した場合、表には「取得操作のプラグイン」というラベルが付きます。

注意:
この表のラベルは、「操作の選択」リストで選択した操作に応じて変わります。

「プラグインの編集」(鉛筆)ボタンをクリックすると、「プラグインの選択および順序付け」ダイアログ・ボックスが表示されます。ダイアログ・ボックスの左側にある「すべてのプラグイン」フィールドには、そのアダプタにデプロイされているすべてのプラグインがリストされます。右側にある「選択済のプラグイン」フィールドには、「操作の選択」リストで選択されている特定の操作に対してのみ実行されるプラグインがリストされます。

7. その操作に対して実行するプラグインを選択し、移動(>)または削除ボタンを使用して、そのプラグインを右側にある「選択済のプラグイン」フィールドに移動するか、またはそこから削除します。
複数のプラグインが「選択済のプラグイン」フィールドにリストされている場合、それらを実行する順序を構成できます。

8. 操作に対してアダプタ・プラグインを実行する順序を変更するには、「選択済のプラグイン」フィールドで一度に1つのプラグインを選択し、「選択済のプラグイン」フィールドの横にある上および下矢印ボタンを使用して順序を変更します。

注意:
「選択済のプラグイン」フィールドの最上部にあるプラグインがその操作に対して最初に実行され、そのフィールド内の残りのプラグインが降順で実行されます。

9. 「プラグインの選択および順序付け」ダイアログ・ボックスの「適用」をクリックし、変更を保存します。特定の操作のプラグインの表に、実行される順序でプラグインが表示されます。

10. オプションで、次の手順を実行することで、操作固有のプラグインに対してネームスペースを設定し、それらが実行される仮想ツリー内の場所を制御できます。

1. 特定の操作のプラグインの表でプラグイン名の左にある開くまたは閉じるためのアイコンをクリックします。

2. 「ネームスペース」フィールドにネームスペースを入力します。

3. 「ネームスペース」フィールドの近くにある追加(+)および削除(X)ボタンを使用してネームスペースを追加または削除します。

11. アダプタ画面上部の「適用」ボタンをクリックして変更内容を保存します。

13.1.3 アダプタ・プラグインの編集

Oracle Directory Services Managerを使用してアダプタの既存のプラグインを編集するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタ」ツリーで、編集するプラグインを含むアダプタの名前をクリックします。アダプタの構成画面が表示されます。

4. 「プラグイン」タブをクリックします。

5. 既存のプラグインの表から編集するプラグインを選択し、「プラグイン/マッピングの編集」ボタンをクリックします。プラグインの設定を示す「プラグイン」ダイアログ・ボックスが表示されます。

6. 必要に応じてプラグインを編集し、「プラグイン」ダイアログ・ボックスで「OK」をクリックします。

7. アダプタ画面上部の「適用」ボタンをクリックして変更内容を保存します。

13.1.4 アダプタ・プラグインの削除

Oracle Directory Services Managerを使用してアダプタの既存のプラグインを削除するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタ」ツリーで、削除するプラグインを含むアダプタの名前をクリックします。アダプタの構成画面が表示されます。

4. 「プラグイン」タブをクリックします。

5. 既存のプラグインの表から削除するプラグインを選択し、「プラグイン/マッピングの編集」ボタンをクリックします。アダプタ構成からのプラグインの削除の確認を要求する確認のダイアログ・ボックスが表示されます。

6. 確認のダイアログ・ボックスの「確認」ボタンをクリックして、プラグインを削除します。既存のプラグインの表からプラグインが削除されます。

7. アダプタ画面上部の「適用」ボタンをクリックして変更内容を保存します。

13.2 グローバル・サーバー・プラグインの管理

この項では、サーバー・レベル(グローバル)プラグインの様々な管理タスクについて説明します。この項の内容は次のとおりです。

- グローバル・サーバー・プラグインの作成

- デプロイされたグローバル・サーバー・プラグインの表示

- グローバル・サーバー・プラグインの編集

- グローバル・サーバー・プラグインの削除

13.2.1 グローバル・サーバー・プラグインの作成

Oracle Directory Services Managerを使用してサーバー・レベルのプラグインを作成するには、次の手順を実行します。

関連項目:
Oracle Virtual Directoryのプラグインの概要

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. ナビゲーション・ツリーの「グローバル・プラグイン」エントリを開きます。

4. 「プラグインの作成」ボタンをクリックします。「プラグイン」ダイアログ・ボックスが表示されます。

5. 「名前」フィールドにプラグインの名前を入力します。

6. 「クラス」フィールドにプラグインのクラス名を入力するか、「選択」をクリックし、「プラグインの選択」ボックスからプラグインを選択して「OK」をクリックします。

7. 「パラメータ」表の「パラメータの作成」ボタンをクリックして「名前」リストからパラメータを選択し、「値」フィールドにパラメータの値を入力して、プラグインにパラメータと値を追加します。

8. プラグインを実行する場所を決定します。プラグインは、仮想ディレクトリの特定の場所、または仮想ツリー全体に渡るグローバル・サーバー・レベルで実行できます。
グローバル・サーバー・レベルでプラグインを実行するには、「ネームスペース」表を空のままにし、「OK」をクリックして仮想ツリー全体のプラグインをアクティブ化します。

仮想ツリーの特定の場所でプラグインを実行するには、次の手順を実行します。

1. 「ネームスペース」表の「ネームスペースの作成」ボタンをクリックします。

2. 「ネームスペース」フィールドに、プラグインを実行する仮想ツリーの場所を入力します。

注意:
仮想ツリーの複数の特定の場所でプラグインを実行するには、複数のネームスペースを作成します。

3. 「OK」をクリックして、仮想ツリーの特定の場所でプラグインをアクティブ化します。

9. プラグインがアクティブ化されたことを確認するには、「デプロイされたグローバル・サーバー・プラグインの表示」を参照してください。

13.2.2 デプロイされたグローバル・サーバー・プラグインの表示

次の手順を実行して、アダプタ・レベルではなく、サーバー・レベルにデプロイされたプラグインのリストを表示できます。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. ナビゲーション・ツリーの「グローバル・プラグイン」エントリを開きます。ナビゲーション・ツリーに、アクティブ化されたマッピングおよびプラグインのリストが表示されます。

13.2.3 グローバル・サーバー・プラグインの編集

Oracle Directory Services Managerを使用して既存のサーバー・レベルのプラグインを編集するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. ナビゲーション・ツリーの「グローバル・プラグイン」エントリを開きます。ナビゲーション・ツリーに、アクティブ化されたマッピングおよびプラグインのリストが表示されます。

4. ナビゲーション・ツリーで、編集するプラグインの名前をクリックします。プラグインの構成画面が表示されます。

5. 必要に応じてプラグインを編集し、プラグイン画面上部の「適用」ボタンをクリックして変更内容を保存します。

13.2.4 グローバル・サーバー・プラグインの削除

Oracle Directory Services Managerを使用して既存のサーバー・レベルのプラグインを削除するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. ナビゲーション・ツリーの「グローバル・プラグイン」エントリを開きます。ナビゲーション・ツリーに、アクティブ化されたマッピングおよびプラグインのリストが表示されます。

4. ナビゲーション・ツリーで、削除するプラグインの名前をクリックします。プラグインの構成画面が表示されます。

5. ナビゲーション・ツリーで「削除」ボタンをクリックします。プラグインの削除の確認を要求する確認のダイアログ・ボックスが表示されます。

6. 確認のダイアログ・ボックスの「削除」ボタンをクリックして、プラグインを削除します。ナビゲーション・ツリーの既存のプラグインのリストからこのプラグインが削除されます。

14 Oracle Virtual Directoryのマッピングの管理

この章では、Oracle Virtual Directoryのマッピングの管理方法について説明します。この章の内容は次のとおりです。

- 第14.1項「マッピング・テンプレートを使用したマッピングの作成」

- 第14.2項「サーバー・マッピングの作成およびアクティブ化」

- 第14.3項「アダプタへのマッピングの適用」

14.1 マッピング・テンプレートを使用したマッピングの作成

Oracle Virtual Directoryには、マクロとして機能し、簡単にマッピングを作成できるマッピング・テンプレートが備わっています。次の手順では、アダプタ・レベルとサーバー・レベルの両方でアクティブ化できるように、マッピングを作成してコンパイルし、Oracle Virtual Directoryサーバーにデプロイする方法を説明します。

Oracle Directory Services Managerのマッピング・テンプレート機能を使用し、マッピングを作成してコンパイルし、Oracle Virtual Directoryサーバーにデプロイするには、次の手順を実行します。

注意:
同じOracle Directory Services Managerコンポーネントから実行されている複数のOracle Directory Services Managerセッションから複数のOracle Virtual Directoryサーバーを管理していて、各Oracle Virtual Directoryサーバーに(それぞれの間隔が10秒未満で)連続して異なるマッピング・テンプレートを作成して保存すると、最も新しいマッピング・テンプレートがすべてのサーバーに保存されます。
この問題は、同じOracle Directory Services Managerの作業ディレクトリが、単一のOracle Directory Services Managerコンポーネントで管理されているすべてのOracle Virtual Directoryサーバー間で共有されているために起こります。

この問題を回避するには、異なるOracle Virtual Directoryサーバーにマッピング・テンプレートを保存する前に、必ず10秒より長く待機してください。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーで「マッピング・テンプレート」エントリを開きます。マッピング・テンプレートのリストが表示されます。

4. 「マッピング・テンプレートの概要」を参照して、マッピングの作成に使用するマッピング・テンプレートを決定します。
使用するマッピング・テンプレートを決定したら、そのテンプレートの名前をクリックします。選択したマッピング・テンプレートのマッピング・パラメータが、メイン画面に表示されます。

5. 次の手順を実行して、マッピング・テンプレートの属性に値を入力します。

1. 編集する「マッピング・パラメータ」表の属性をクリックします。属性の現在の値が表示されます。

2. 「値」フィールドに属性の新しい値を入力して、「OK」をクリックします。「マッピング・パラメータ」表に、属性の新しい値が表示されます。

マッピングのすべての必要な属性に値を設定できるまでこの手順を繰り返します。

6. マッピング・テンプレート画面上部の「適用」をクリックします。
「適用」をクリックすると、Oracle Directory Services Managerにより、マッピング・テンプレートがマッピング・スクリプトにコンパイルされ、アダプタまたはグローバル・サーバー・レベルでアクティブ化できるよう、Oracle Virtual Directoryサーバーに送信されます。

7. マッピングがOracle Virtual Directoryサーバーにデプロイされたことを確認するには、「デプロイされたマッピングの表示」を参照してください。

14.1.1 デプロイされたマッピングの表示

次の手順を実行すると、Oracle Virtual Directoryサーバーにデプロイ済で、アクティブ化して使用できるマッピングのリストを表示できます。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーで「デプロイ済マッピング」エントリを開きます。Oracle Virtual Directoryサーバーにデプロイ済で、アクティブ化して使用できるマッピングのリストが拡張ツリーに表示されます。

14.2 サーバー・マッピングの作成およびアクティブ化

この項では、グローバル・サーバー・レベルでマッピングを作成およびアクティブ化する方法を説明します。アダプタ・レベルでマッピングをアクティブ化する方法の詳細は、「アダプタへのマッピングの適用」を参照してください。

Oracle Directory Services Managerを使用して、グローバル・サーバー・レベルでマッピングを作成およびアクティブ化するには、次の手順を実行します。

注意:
マッピングを作成およびアクティブ化するには、Oracle Virtual Directoryサーバーにマッピング・ファイルが存在している必要があります。マッピングの作成およびデプロイの詳細は、「マッピング・テンプレートを使用したマッピングの作成」を参照してください。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーの「グローバル・プラグイン」エントリを開きます。

4. 拡張ツリーの「グローバル・プラグイン」エントリの上部にある「マッピングの作成」ボタンをクリックします。「マッピング」ダイアログ・ボックスが表示されます。

5. 「名前」フィールドに、マッピングを説明するための名前を入力します。この名前は、実際のマッピング・スクリプト・ファイルに名前を付けるためではなく、マッピングを識別および説明するために使用されます。

6. 「マッピング・ファイル」フィールドにマッピング・スクリプト・ファイルへのパスを入力するか、「選択」をクリックします。マッピング・スクリプト・ファイルに移動して選択し、「OK」をクリックします。

7. マッピングを実行する場所を決定します。マッピングは、仮想ディレクトリの特定の場所、または仮想ツリー全体に渡るグローバル・サーバー・レベルで実行できます。
グローバル・サーバー・レベルでマッピングを実行するには、「ネームスペース」表を空のままにし、「OK」をクリックして仮想ツリー全体のマッピングをアクティブ化します。

仮想ツリーの特定の場所でマッピングを実行するには、次の手順を実行します。

1. 「ネームスペース」表の「ネームスペースの作成」ボタンをクリックします。

2. 「ネームスペース」フィールドに、マッピングを実行する仮想ツリーの場所を入力します。
仮想ツリーの複数の特定の場所でマッピングを実行するには、複数のネームスペースを作成します。

3. 「OK」をクリックして、仮想ツリーの特定の場所でマッピングをアクティブ化します。

8. マッピングがアクティブ化されたことを確認するには、「アクティブ化されたサーバー・マッピングの表示」を参照してください。

14.2.1 アクティブ化されたサーバー・マッピングの表示

次の手順を実行して、アダプタ・レベルではなく、サーバー・レベルでアクティブ化されたマッピングのリストを表示できます。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーの「グローバル・プラグイン」エントリを開きます。拡張ツリーに、アクティブ化されたマッピングおよびプラグインのリストが表示されます。

14.3 アダプタへのマッピングの適用

Oracle Directory Services Managerを使用してアダプタにマッピングを適用するには、次の手順を実行します。

注意:
アダプタにマッピングを適用するには、Oracle Virtual Directoryサーバーにマッピング・ファイルが存在している必要があります。Oracle Virtual Directoryサーバーにマッピングを作成およびデプロイする方法の詳細は、「マッピング・テンプレートを使用したマッピングの作成」を参照してください。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. ツリー内で、マッピングを適用するアダプタの名前をクリックします。アダプタの設定画面が表示されます。

4. 「プラグイン」タブをクリックします。アダプタのプラグイン画面が表示されます。

5. 「マッピングの作成」ボタンをクリックします。「マッピング」ダイアログ・ボックスが表示されます。

6. 「名前」フィールドに、マッピングを説明するための名前を入力します。この名前は、実際のマッピング・スクリプト・ファイルに名前を付けるためではなく、マッピングを識別および説明するために使用されます。

7. 「マッピング・ファイル」フィールドにマッピング・スクリプト・ファイルへのパスを入力するか、「選択」をクリックします。マッピング・スクリプト・ファイルに移動して選択し、「OK」をクリックします。

8. マッピングを実行する場所を決定します。マッピングは、アダプタ・ネームスペースの下の特定の場所、またはアダプタ全体にわたるアダプタ・ネームスペース自体で実行できます。
アダプタ・レベルでマッピングを実行するには、「ネームスペース」表を空のままにし、「OK」をクリックしてアダプタ全体のマッピングをアクティブ化します。

アダプタの下の特定の場所でマッピングを実行するには、次の手順を実行します。

1. 「ネームスペース」表の「ネームスペースの作成」ボタンをクリックします。

2. 「ネームスペース」フィールドに、マッピングを実行する仮想ツリーの場所を入力します。
仮想ツリーの複数の特定の場所でマッピングを実行するには、複数のネームスペースを作成します。

3. 「OK」をクリックして、仮想ツリーの特定の場所でマッピングをアクティブ化します。

9. アダプタのプラグイン画面で「適用」をクリックして、アダプタにマッピングを適用します。

15 Oracle Virtual Directoryのエントリおよびスキーマの管理

この章では、Oracle Directory Services Managerを使用して、Oracle Virtual Directoryのエントリとスキーマを管理する方法について説明します。この章の内容は、次のとおりです。

- 第15.1項「データ・ブラウザを使用したOracle Virtual Directoryエントリの管理」

- 第15.2項「Oracle Directory Services Managerを使用したOracle Virtual Directoryスキーマの管理」

15.1 データ・ブラウザを使用したOracle Virtual Directoryエントリの管理

この項では、Oracle Virtual Directoryのデータ・ブラウザ、およびそれを使用してOracle Virtual Directoryエントリを管理する方法について説明します。この項では、次の項目について説明します。

- Oracle Virtual Directoryのデータ・ブラウザの概要

- クライアント・ビュー・データ・ブラウザを使用したOracle Virtual Directoryエントリの管理

- アダプタ・ブラウザを使用したOracle Virtual Directoryソース・エントリの管理

15.1.1 Oracle Virtual Directoryのデータ・ブラウザの概要

Oracle Virtual Directoryには、次のタイプのデータ・ブラウザがあります。

- クライアント・ビュー・ブラウザ

- アダプタ・ブラウザ

クライアント・ビュー・ブラウザとアダプタ・ブラウザのどちらも、新しいOracle Virtual Directoryサーバーを定義する際に自動的に作成されます。Oracle Virtual Directoryは、管理ゲートウェイを介してDSMLv2を使用して、ブラウザにより表示されたデータを取得します。

クライアント・ビュー・ブラウザ

クライアント・ビュー・ブラウザを使用すると、Oracle Virtual Directoryによりすべてのデータ・マッピングと変換が実行された後に、(構成されているすべてのアダプタにより定義されている)仮想ディレクトリ・ツリー全体を検索および表示できます。クライアント・ビューは、Oracle Virtual Directoryにより仮想化された後のデータの状態を表す処理後のビューであると考えてください。

また、クライアント・ビュー・データ・ブラウザを使用して、Oracle Virtual Directoryと相互にLDIFファイルをインポートおよびエクスポートできます。LDIFは、LDAPサーバー間でデータを交換するために設計された業界標準のテキスト交換形式です。LDIFファイルは、バッチ・データやスキーマ構成の変更をインポートおよびエクスポートするときに最もよく使用されます。

アダプタ・ブラウザ

アダプタ・ブラウザを使用すると、データを、リポジトリに接続されているLDAPアダプタとデータベース・アダプタの両方に存在しているかのように表示できます。アダプタ・ブラウザ・ビューは、LDAPおよびデータベース・リポジトリのデータがOracle Virtual Directoryにより仮想化される前の状態を表す処理前のビューです。アダプタ・ブラウザを使用してデータベースを表示すると、表およびフィールドは、データ・モデリングに役立つサンプル表の行が含まれる元のデータベースに存在しているように表示されます。

注意:

- アダプタ・ブラウザで既存のアダプタの名前をクリックすると、そのアダプタの構成がメインの「Oracle Directory Services Manager」画面に表示されます。このアダプタ構成情報は、読取り専用であり、アダプタ・ブラウザを使用してアダプタの構成を編集することはできません。

- 結合ビュー・アダプタおよびローカル・ストア・アダプタのデータは、アダプタ・ブラウザには表示されません。

15.1.2 クライアント・ビュー・データ・ブラウザを使用したOracle Virtual Directoryエントリの管理

クライアント・ビュー・ブラウザを使用すると、Oracle Virtual Directoryによりすべてのデータ・マッピングと変換が実行された後に、(構成されているすべてのアダプタにより定義されている)仮想ディレクトリ・ツリー全体を表示および検索できます。クライアント・ビュー・ブラウザを使用して、LDIFファイルを仮想ディレクトリにインポートおよび仮想ディレクトリからエクスポートできます。クライアント・ビュー・ブラウザを使用して仮想ツリー・エントリの属性を変更および削除することもできます。

この項では、次のクライアント・ビュー・ブラウザのタスクの実行方法について説明します。

- 仮想ディレクトリ・ツリーの検索

- Oracle Virtual Directoryエントリの表示

- 仮想ディレクトリ・ツリー・エントリの属性の変更

- ユーザー・アカウントのロック解除

- LDIFファイルのインポート

- LDIFファイルのエクスポート

15.1.2.1 仮想ディレクトリ・ツリーの検索

クライアント・ビュー・データ・ブラウザを使用して、仮想ディレクトリ・ツリーを検索できます。検索には、簡易検索と拡張検索の2つのタイプがあります。簡易検索では、cn、uid、sn、givenname、mail、およびinitials属性のみを検索します。拡張検索では、検索範囲の深さやその他の詳細な検索パラメータを指定できます。

簡易検索を行うには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「クライアント・ビュー」エントリを選択します。

4. 「データ・ツリー」の上部にある検索フィールドに、検索するキーワードを入力し、「簡易検索」アイコンをクリックします。

拡張検索を行うには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「クライアント・ビュー」エントリを選択します。

4. 「データ・ツリー」の上部にある「拡張」ボタンをクリックします。「検索ダイアログ」ボックスが表示されます。

5. 「検索のルート」フィールドに、検索の開始点を入力します。

6. 「最大結果件数」フィールドに、検索で戻すエントリの最大数を入力します。

7. 次の「検索の深さ」リストからいずれかのオプションを選択して、検索の深さの有効範囲を選択します。
ベース: 「検索のルート」フィールドに指定された場所にあるエントリのみを検索します。

1レベル: 「検索のルート」フィールドに指定された場所の1レベル下にあるすべてのエントリを検索します。

サブツリー: 「検索のルート」フィールドに指定された場所と、その場所の下にあるすべてのエントリを含めて検索します。

8. 「最長検索時間」フィールドに、検索を実行する最大秒数を入力します。

9. 次のようにして検索基準を入力します。

1. 属性のリストから属性名を選択して、検索する属性を選択します。

2. 一致規則のリストから一致規則を選択します。

3. 一致する値の指定フィールドに一致規則の値を入力します。
隣にある「削除」ボタンをクリックして、検索基準を削除できます。

注意:
カスタマイズした(拡張した)基準で検索するには、「LDAPフィルタの表示」オプションを選択し、「LDAP問合せ」フィールドに(objectclass=*)のようなカスタム検索フィルタを入力します。

10. 「検索」をクリックして、検索を実行します。

15.1.2.2 Oracle Virtual Directoryエントリの表示

クライアント・ビュー・データ・ブラウザを使用して、Oracle Virtual Directoryのエントリを表示するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「クライアント・ビュー」エントリを開きます。仮想ディレクトリのエントリのネームスペースが表示されます。

4. 適切なネームスペースを開いて、表示するコンテンツに移動します。

5. 表示するエントリをクリックします。そのエントリの属性とオブジェクト・クラスが表示された「プロパティ」画面が表示されます。画面の右上にある「すべて表示」または「空の値を非表示」オプションをクリックすることで、「プロパティ」画面に表示する属性と表示しない属性を調整できます。

15.1.2.3 仮想ディレクトリ・ツリー・エントリの属性の変更

クライアント・ビュー・ブラウザを使用して仮想ディレクトリ・ツリー・エントリの属性を変更および削除できます。クライアント・ビュー・ブラウザを使用してエントリを追加することはできません。

クライアント・ビュー・ブラウザを使用して仮想ディレクトリ・ツリー・エントリの属性を変更するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「クライアント・ビュー」エントリを開きます。仮想ディレクトリのエントリのネームスペースが表示されます。

4. 該当するネームスペースを開くことで変更するエントリに移動し、そのエントリをクリックします。そのエントリの詳細が、メイン画面にエントリのタイプに応じて「属性」、「個人」、「グループ」などの状況依存タブによって分類されて表示されます。

エントリを変更する一般的な手順は次のとおりです。どの手順を実行した場合でも、エントリを変更した後は「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

注意:

- すべてのタイプのエントリの属性を変更するには、「属性」タブをクリックし、目的の変更を行います。デフォルトでは、空でない属性のみが表示されます。「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

- 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

オブジェクト・クラスを追加する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. objectclassの横の「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用してオブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、そのオブジェクト・クラスをクリックして「OK」をクリックします。

オブジェクト・クラスを削除するには、次のようにします。

1. 「属性」タブをクリックします。

2. 削除するオブジェクト・クラスを選択します。

3. objectclassの横の「削除」アイコンをクリックします。「オブジェクト・クラスの削除」ダイアログに、そのクラスとともに削除される属性が表示されます。

4. 「削除」をクリックして続けるか、「取消」をクリックして削除を取り消します。

個人エントリを変更する手順は次のとおりです。

1. 「個人」タブをクリックします。

2. 必要に応じて情報を変更します。個人エントリの写真をアップロードするには、「参照」をクリックし、写真に移動し、「オープン」をクリックします。写真を更新するには、「更新」をクリックして同じ手順に従います。写真を削除するには、「削除」アイコンをクリックします。

グループ・エントリを変更する手順は次のとおりです。

1. 「グループ」タブをクリックします。

2. 該当するテキスト・ボックスで「追加」または「削除」をクリックし、グループの所有者またはメンバーを追加または削除します。

15.1.2.4 ユーザー・アカウントのロック解除

Oracle Virtual Directory LDAPアダプタをOracle Internet Directory LDAPサーバーにマップする場合、Oracle Internet Directoryでpwdaccountlockedtime属性が使用可能になります。

Oracle Directory Services Managerが1の値を持つpwdaccountlockedtime属性を検出した場合、orclpwdaccountunlock属性が表示され、アカウントはロックされます。また、orclpwdaccountunlock属性は、Oracle Directory Services Managerの「データ・ブラウザ」タブの「アカウントのロックを解除」ボタンをトリガーします。

注意:
Oracle Internet Directory LDAPアダプタのエントリに対して「アカウントのロックを解除」ボタンを使用できます。
「アカウントのロックを解除」は、パスワード・ポリシー属性をorclpwdaccountunlock属性にマップしている場合にのみ他のLDAPアダプタに対して使用できます。

この属性の構成の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

ユーザー・アカウントのロックを解除する手順は次のとおりです。

1. 「データ・ブラウザ」ツリーでロックされているアカウント・エントリをクリックします。

2. 「アカウントのロックを解除」ボタンをクリックします。

3. orclpwdaccountunlockチェック・ボックスを選択します。

15.1.2.5 LDIFファイルのインポート

クライアント・ビュー・データ・ブラウザを使用して、Oracle Virtual DirectoryにLDIFファイルをインポートするには、次の手順を実行します。

1. インポートするLDIFファイルの1行目に、有効なバージョン番号が入力されていることを確認してください。Oracle Virtual Directoryでは、インポートされるすべてのLDIFファイルは、その先頭にこのバージョン番号が含んでいる必要があります。ファイルの1行目にバージョン番号がない場合は、ファイルの最初に「version: 1」を追加します。

2. Oracle Directory Services Managerにログインします。

3. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

4. 「データ・ツリー」で、「クライアント・ビュー」エントリを開きます。

5. ツリーの「クライアント・ビュー」エントリで適切なネームスペースをクリックし、LDIFファイルをインポートする場所を選択します。

6. ツリーの上部にある「LDIFのインポート」ボタンをクリックします。「ファイルのインポート」ダイアログ・ボックスが表示されます。

7. 「LDIFファイルの選択」フィールドにインポートするLDIFファイルのパスを入力するか、「参照」ボタンをクリックしてファイルに移動します。

8. 「ファイルのインポート」ダイアログ・ボックスの「OK」ボタンをクリックして、LDIFファイルをインポートします。

15.1.2.6 LDIFファイルのエクスポート

クライアント・ビュー・データ・ブラウザを使用して、Oracle Virtual DirectoryからLDIFファイルをエクスポートするには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「クライアント・ビュー」エントリを開きます。

4. ツリーの「クライアント・ビュー」エントリで適切なネームスペースをクリックし、LDIFファイルのエクスポート元を選択します。

5. 「データ・ツリー」の上部にある「LDIFのエクスポート」ボタンをクリックします。「LDIFのエクスポート」ダイアログ・ボックスが表示されます。

注意:
1つのLDIFファイルでエクスポート可能な最大エントリ数は1000です。エクスポートしようとしているネームスペースに1000を超えるエントリがある場合は、最初の1000エントリのみがエクスポートされます。

6. 「LDIFファイルのダウンロード」ダイアログ・ボックスの「ここをクリックしてLDIFファイルを開きます」リンクをクリックして、ブラウザでLDIFファイルを開きます。

注意:
「LDIFファイルのダウンロード」ダイアログ・ボックスの「OK」ボタンをクリックすると、LDIFファイルはエクスポートされません。

「LDIFファイルのダウンロード」ダイアログ・ボックスの「ここをクリックしてLDIFファイルを開きます」リンクをクリックすると、新しい別のブラウザ・ウィンドウにLDIFファイルが表示されます。

7. ブラウザの保存コマンドを使用してLDIFファイルを保存します。

15.1.3 アダプタ・ブラウザを使用したOracle Virtual Directoryソース・エントリの管理

アダプタ・ブラウザを使用すると、データを、リポジトリに接続されているLDAPアダプタとデータベース・アダプタの両方に存在しているかのように表示できます。アダプタ・ブラウザ・ビューを使用すると、Oracle Virtual Directoryにより仮想化される前の状態のデータを表示できます。アダプタ・ブラウザを使用してソース・エントリの属性を変更および削除することもできます。

この項では、次のアダプタ・ブラウザのタスクの実行方法について説明します。

- ソース・リポジトリ・エントリの表示

- Oracle Virtual Directoryにおけるソース・リポジトリ・エントリの属性の変更

注意:

- アダプタ・ブラウザで既存のアダプタの名前をクリックすると、そのアダプタの構成がメインの「Oracle Directory Services Manager」画面に表示されます。このアダプタ構成情報は、読取り専用であり、アダプタ・ブラウザを使用してアダプタの構成を編集することはできません。

- 結合ビュー・アダプタおよびローカル・ストア・アダプタのデータは、アダプタ・ブラウザには表示されません。

15.1.3.1 ソース・リポジトリ・エントリの表示

アダプタ・ブラウザを使用して、定義された各アダプタのリモートの基礎となるリポジトリに存在しているようにデータを表示するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「アダプタ・ブラウザ」エントリを開きます。データ・リポジトリに接続されているアダプタの名前が表示されます。

4. 表示するソース・エントリが含まれるアダプタのエントリを開きます。アダプタのエントリが表示されます。

5. 表示するエントリをクリックします。そのエントリのソース・データが、「プロパティ」画面に表示されます。「プロパティ」画面には、デフォルトで、値を持つエントリの属性のみが表示されます。「すべて表示」オプションを選択し、エントリのすべての属性を表示します。

15.1.3.2 Oracle Virtual Directoryにおけるソース・リポジトリ・エントリの属性の変更

アダプタ・ブラウザを使用して、Oracle Virtual Directoryのソース・リポジトリ・エントリの属性を変更および削除できます。アダプタ・ブラウザを使用してソース・エントリを追加することはできません。

アダプタ・ブラウザを使用してOracle Virtual Directoryのソース・リポジトリ・エントリの属性を変更するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「データ・ブラウザ」を選択します。「データ・ツリー」が表示されます。

3. 「データ・ツリー」で、「アダプタ・ブラウザ」エントリを開きます。データ・リポジトリに接続されているアダプタの名前が表示されます。

4. 変更するソース・エントリが含まれるアダプタのエントリを開きます。アダプタのエントリが表示されます。

5. 変更するエントリをクリックします。そのエントリの詳細が、メイン画面にエントリのタイプに応じて「属性」、「個人」、「グループ」などの状況依存タブによって分類されて表示されます。

エントリを変更する一般的な手順は次のとおりです。どの手順を実行した場合でも、エントリを変更した後は「適用」をクリックして変更を保存するか、「元に戻す」をクリックして変更を破棄します。

注意:

- すべてのタイプのエントリの属性を変更するには、「属性」タブをクリックし、目的の変更を行います。デフォルトでは、空でない属性のみが表示されます。「ビュー」リストを使用すると、「管理対象属性」と「すべて表示」を切り替えることができます。

- 管理対象属性として表示されている属性のリストを変更するには、「オプション属性」のアイコンをクリックします。「すべての属性」リストから「表示された属性」リストに移動する属性を選択し、「移動」および「すべて移動」の矢印を使用して属性を移動します。「表示された属性」リストから「すべての属性」リストに移動する属性を選択し、「削除」および「すべて削除」の矢印を使用して属性を移動します。「属性の追加」をクリックして変更を有効にするか、「取消」をクリックして変更を破棄します。「属性の追加」をクリックすると、「表示された属性」リストにあった属性のみが「管理対象属性」ビューに表示されます。

オブジェクト・クラスを追加する手順は、次のとおりです。

1. 「属性」タブをクリックします。

2. objectclassの横の「追加」アイコンをクリックし、「オブジェクト・クラスの追加」ダイアログを使用してオブジェクト・クラスのエントリを選択します。必要に応じて、検索ボックスを使用してオブジェクト・クラスのリストをフィルタリングします。オブジェクト・クラスを追加するには、そのオブジェクト・クラスをクリックして「OK」をクリックします。

オブジェクト・クラスを削除するには、次のようにします。

1. 「属性」タブをクリックします。

2. 削除するオブジェクト・クラスを選択します。

3. objectclassの横の「削除」アイコンをクリックします。「オブジェクト・クラスの削除」ダイアログに、そのクラスとともに削除される属性が表示されます。

4. 「削除」をクリックして続けるか、「取消」をクリックして削除を取り消します。

個人エントリを変更する手順は次のとおりです。

1. 「個人」タブをクリックします。

2. 必要に応じて情報を変更します。個人エントリの写真をアップロードするには、「参照」をクリックし、写真に移動し、「オープン」をクリックします。写真を更新するには、「更新」をクリックして同じ手順に従います。写真を削除するには、「削除」アイコンをクリックします。

グループ・エントリを変更する手順は次のとおりです。

1. 「グループ」タブをクリックします。

2. 該当するテキスト・ボックスで「追加」または「削除」をクリックし、グループの所有者またはメンバーを追加または削除します。

15.2 Oracle Directory Services Managerを使用したOracle Virtual Directoryスキーマの管理

この項では、Oracle Virtual Directoryスキーマの管理方法について説明します。この項の内容は次のとおりです。

- Oracle Virtual Directoryのスキーマ属性の管理

- Oracle Virtual Directoryのスキーマ・オブジェクト・クラスの管理

注意:
この項では、Oracle Directory Services Managerを使用した、Oracle Virtual Directoryスキーマの管理方法について説明します。Oracle Virtual Directoryスキーマの変更にldapmodifyを使用する場合は、次の事項に注意してください。

- Oracle Virtual Directoryでは、スキーマ・キーワード(nameなど)は、すべて大文字(NAME)であることが必要です。

- Oracle Virtual Directoryでは、スキーマの変更時に、ldapmodify replace操作がサポートされません。

15.2.1 Oracle Virtual Directoryのスキーマ属性の管理

この項では、Oracle Virtual Directoryのスキーマ属性の管理方法について説明します。この項の内容は次のとおりです。

- スキーマ属性の検索

- 新しいスキーマ属性の作成

- 類似のスキーマ属性の作成

- スキーマ属性の変更

- スキーマ属性の削除

15.2.1.1 スキーマ属性の検索

Oracle Directory Services Managerは、スキーマ属性間を移動する手順を簡素化する検索機能を提供します。Oracle Directory Services Managerを使用してスキーマ属性を検索するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「属性タイプ」エントリを開きます。検索フィールドなどの「属性タイプ」のコントロールおよび既存のスキーマ属性のリストが表示されます。

4. 検索フィールドに検索する文字列を入力します。2つのパターン一致文字(*および?)がサポートされています。*文字は、1つ以上の文字を表すワイルドカードとして使用します。?文字は1つの文字を表すために使用します。たとえば、検索文字列auth????????を入力すると、属性authPasswordが戻されます。

5. 「実行」(>)アイコンをクリックして検索を開始します。検索基準に一致する属性がナビゲーション・ツリーに表示されます。

15.2.1.2 新しいスキーマ属性の作成

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの新しいスキーマ属性を作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「属性タイプ」エントリを開きます。既存のスキーマ属性のリストが表示されます。

4. 「作成」ボタンをクリックします。「新規属性の型」ダイアログ・ボックスが表示されます。

5. 「新規属性の型」ダイアログ・ボックス・フィールドに次の情報を入力します。

- 「名前」フィールドに属性の名前を入力します。

- 「オブジェクトID」フィールドに、ICANNにより指定された一意のオブジェクトIDを入力します。登録されていない場合は、任意の一意の値を使用できます。一意のオブジェクトIDを使用して、すべてのカスタム属性を登録することをお薦めします。

- オプションで、「説明」フィールドにその属性の説明を入力します。

- 「構文」リストのオプションを1つ選択することで、属性値の書式を選択します。Oracle Virtual Directoryでは、親構文の値のみが使用されます。

- 「サイズ(バイト)」フィールドに属性のバイト長を入力します。0を指定する場合または値を指定しない(空)場合は無制限を意味します。Oracle Virtual Directoryでは、この属性定義は施行されません。

- 属性の使用方法に関する「使用方法」リストから「標準」を選択します。

- 順序付け検索の場合は、「順序」フィールドにオブジェクトID一致規則を入力します。Oracle Virtual Directoryでは、この属性定義は使用されません。

- 等価検索の場合は、「等価」フィールドに一致規則オブジェクトIDを入力します。Oracle Virtual Directoryでは、この属性定義は使用されません。

- サブストリング検索の場合は、「サブストリング」フィールドに一致規則オブジェクトIDを入力します。Oracle Virtual Directoryでは、この属性定義は使用されません。

- 属性が一度に単一の値のみを保持する場合は、「単一値」オプションを有効化します。このオプションが有効化されていない場合、属性に複数の値が保持されます。

- オプションで、「上位」リストから既存の属性の1つを選択することで、新しい属性の親属性を選択します。

注意:
LDAPスキーマの管理に伴う1つの問題は、属性がどのオブジェクト・クラスに属しているかを判別することです。すべてのオブジェクト・クラスでそれに含まれる属性が表示されますが、ディレクトリ管理者は、どのオブジェクト・クラスが属性を使用しているのか把握する必要がある場合がよくあります(特にカスタム属性の場合)。
「属性タイプ」リストから属性を選択すると、Oracle Directory Services Managerによって「参照元」表などその属性に関する情報が表示されます。この表は、選択した属性を使用している直接のオブジェクト・クラスと、その属性がどのように参照されているのかを示しています。(属性は必須またはオプションとして参照されます。)

「参照元」表には、属性を継承する(それを間接的に使用する)オブジェクト・クラスは含まれていないことに注意してください。たとえば、snがpersonオブジェクト・クラスによって参照されている場合、「参照元」表にはpersonオブジェクト・クラスのみがリストされます。この表には、personオブジェクト・クラスから継承されるinetorganizationalpersonおよびorganizationalpersonのオブジェクト・クラスはリストされていません。

6. 「新規属性タイプ」ダイアログ・ボックスで「OK」をクリックし、属性を作成します。「属性タイプ」ツリーに新しい属性が表示されます。

15.2.1.3 類似のスキーマ属性の作成

Oracle Directory ServicesManagerは、既存の属性に類似した新しいOracle Virtual Directoryスキーマ属性を作成する機能を提供します。この機能は、「類似作成」と呼ばれます。既存の属性に類似した新しい属性を作成する場合は、新しいものの元となる既存の属性を選択し、ベース属性の定義をそれが一意になるように変更します。

Oracle Directory Services Managerを使用して既存の属性に類似した属性を作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「属性タイプ」エントリを開きます。既存のスキーマ属性のリストが表示されます。

4. 新しい属性の元となる既存の属性をクリックします。

5. ツリーの上部にある「類似作成」ボタンをクリックします。ベース属性の定義が表示されます。

6. 必要に応じてベース属性の定義を変更して、新しい属性を作成します。有効な新しい属性を作成するには、ベース属性の名前とオブジェクトID定義を変更する必要があります。

注意:
属性定義の各フィールドの詳細は、「新しいスキーマ属性の作成」の手順5を参照してください。

7. ダイアログ・ボックスで「OK」をクリックし、新しい属性を作成します。「属性タイプ」ツリーに新しい属性が表示されます。

15.2.1.4 スキーマ属性の変更

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの既存のスキーマ属性を変更するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「属性タイプ」エントリを開きます。既存のスキーマ属性のリストが表示されます。

4. リストで、変更する属性をクリックします。属性の定義が表示されます。

5. 必要に応じて属性の定義を変更します。属性の定義の詳細は、「新しいスキーマ属性の作成」の手順5を参照してください。

6. 「適用」をクリックして変更を保存します。

15.2.1.5 スキーマ属性の削除

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの既存のスキーマ属性を削除するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「属性タイプ」エントリを開きます。既存のスキーマ属性のリストが表示されます。

4. リストで、削除する属性をクリックします。属性の定義が表示されます。

5. 「属性タイプ」ツリーの上部にある「削除」ボタンをクリックします。属性の削除の確認を要求するダイアログ・ボックスが表示されます。

6. 確認のダイアログ・ボックスの「削除」ボタンをクリックして、属性を削除します。「属性タイプ」ツリーの既存属性のリストから属性が削除されます。

15.2.2 Oracle Virtual Directoryのスキーマ・オブジェクト・クラスの管理

この項では、Oracle Virtual Directoryのスキーマ・オブジェクト・クラスの管理方法について説明します。この項の内容は次のとおりです。

- スキーマ・オブジェクト・クラスの検索

- 新しいスキーマ・オブジェクト・クラスの作成

- 類似のスキーマ・オブジェクト・クラスの作成

- スキーマ・オブジェクト・クラスの変更

- スキーマ・オブジェクト・クラスの削除

15.2.2.1 スキーマ・オブジェクト・クラスの検索

Oracle Directory Services Managerは、スキーマ・オブジェクト・クラス間を移動する手順を簡素化する検索機能を提供します。Oracle Directory Services Managerを使用してスキーマ・オブジェクト・クラスを検索するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「オブジェクト・クラス」エントリを開きます。検索フィールドなどの「オブジェクト・クラス」のコントロールおよび既存のスキーマ・オブジェクト・クラスのリストが表示されます。

4. 検索フィールドに検索する文字列を入力します。2つのパターン一致文字(*および?)がサポートされています。*文字は、1つ以上の文字を表すワイルドカードとして使用します。?文字は1つの文字を表すために使用します。たとえば、検索文字列inet???personを入力すると、オブジェクト・クラスinetOrgPersonが戻されます。

5. 「実行」(>)アイコンをクリックして検索を開始します。検索基準に一致するオブジェクト・クラスがナビゲーション・ツリーに表示されます。

15.2.2.2 新しいスキーマ・オブジェクト・クラスの作成

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの新しいスキーマ・オブジェクト・クラスを作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「オブジェクト・クラス」エントリを開きます。既存のスキーマ・オブジェクト・クラスのリストが表示されます。

4. 「作成」ボタンをクリックします。「新規オブジェクト・クラス」ダイアログ・ボックスが表示されます。

5. 「新規オブジェクト・クラス」ダイアログ・ボックス・フィールドに次の情報を入力します。

- 「名前」フィールドに新しいオブジェクト・クラスの名前を入力します。

- オプションで、「説明」フィールドにオブジェクト・クラスの説明を入力します。Oracle Virtual Directoryでは、このオブジェクト・クラス定義は強制されません。

- 「オブジェクトID」フィールドに、一意のオブジェクトID文字列を入力します。一意のオブジェクトIDを使用して、すべてのカスタム・オブジェクト・クラスを登録することをお薦めします。

- 「廃止」オプションを有効化して、管理目的でオブジェクト・クラスを廃止とマークします。Oracle Virtual Directoryでは、このオブジェクト・クラス定義は強制されません。

- 次の「タイプ」リストからオプションを1つ選択して、オブジェクト・クラスのタイプを選択します。Oracle Virtual Directoryでは、このオブジェクト・クラス定義は強制されません。

- オブジェクト・クラスが別のクラスに継承されるオブジェクト・クラスを表していて、オブジェクトにより直接使用されない場合には、「抽象型」を選択します。

- オブジェクト・クラスが、(構造化オブジェクト・クラスに基づいて)既存のオブジェクトに別の属性を追加するために使用される場合には、「補助型」を選択します。

- オブジェクト・クラスでエントリを形成できる場合には、「構造型」を選択します。

- 「上位」リストから既存のオブジェクト・クラスを1つ選択することで、新しいオブジェクト・クラスの親オブジェクト・クラスを選択します。親オブジェクト・クラスを選択しない場合、新しいオブジェクト・クラスは上位から派生している必要があります。

- オブジェクト・クラスに存在する必要のある属性を追加するには、「必須属性」フィールドの「追加」ボタンをクリックし、「必須属性セレクタ」ダイアログ・ボックスの既存属性のリストから属性を選択して、「OK」をクリックします。属性を選択して、「削除」ボタンをクリックすると、必須属性を削除できます。

- オブジェクト・クラスにオプションで提供する属性を追加するには、「オプション属性」フィールドの「追加」ボタンをクリックし、「オプション属性セレクタ」ダイアログ・ボックスの既存属性のリストから属性を選択して、「OK」をクリックします。属性を選択して、「削除」ボタンをクリックすると、オプション属性を削除できます。

6. 「新規オブジェクト・クラス」ダイアログ・ボックスで「OK」をクリックし、オブジェクト・クラスを作成します。「オブジェクト・クラス」ツリーに新しいオブジェクト・クラスが表示されます。

15.2.2.3 類似のスキーマ・オブジェクト・クラスの作成

Oracle Directory Services Managerは、既存のオブジェクト・クラスに類似した新しいOracle Virtual Directoryスキーマ・オブジェクト・クラスの作成機能を提供します。この機能は、「類似作成」と呼ばれます。既存のオブジェクト・クラスに類似した新しいオブジェクト・クラスを作成する場合は、新しいものの元となる既存のオブジェクト・クラスを選択し、ベース・オブジェクト・クラスの定義をそれが一意になるように変更します。

Oracle Directory Services Managerを使用して既存のオブジェクト・クラスに類似したオブジェクト・クラスを作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「オブジェクト・クラス」エントリを開きます。既存のスキーマ・オブジェクト・クラスのリストが表示されます。

4. 新しいオブジェクト・クラスの元となる既存のオブジェクト・クラスをクリックします。

5. ツリーの上部にある「類似作成」ボタンをクリックします。ベースのオブジェクト・クラスの定義が表示されます。

6. 必要に応じてベースのオブジェクト・クラスの定義を変更して、新しいオブジェクト・クラスを作成します。有効な新しいオブジェクト・クラスを作成するには、ベースのオブジェクト・クラスの名前とオブジェクトID定義を変更する必要があります。

注意:
オブジェクト・クラスの定義の詳細は、「新しいスキーマ・オブジェクト・クラスの作成」の手順5を参照してください。

7. ダイアログ・ボックスで「OK」をクリックし、新しいオブジェクト・クラスを作成します。「オブジェクト・クラス」ツリーに新しいオブジェクト・クラスが表示されます。

15.2.2.4 スキーマ・オブジェクト・クラスの変更

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの既存のスキーマ・オブジェクト・クラスを変更するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「オブジェクト・クラス」エントリを開きます。既存のスキーマ・オブジェクト・クラスのリストが表示されます。

4. リストで、変更するオブジェクト・クラスをクリックします。オブジェクト・クラスの定義が表示されます。

5. 必要に応じてオブジェクト・クラスの定義を変更します。オブジェクト・クラスの定義の詳細は、「新しいスキーマ・オブジェクト・クラスの作成」の手順5を参照してください。

6. 「適用」をクリックして変更を保存します。

15.2.2.5 スキーマ・オブジェクト・クラスの削除

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryの既存のスキーマ属性を削除するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「スキーマ」を選択します。「属性タイプ」および「オブジェクト・クラス」ナビゲーション・ツリーが表示されます。

3. 「オブジェクト・クラス」エントリを開きます。既存のスキーマ・オブジェクト・クラスのリストが表示されます。

4. リストで、削除するオブジェクト・クラスをクリックします。オブジェクト・クラスの定義が表示されます。

5. 「オブジェクト・クラス」ツリーの上部にある「削除」ボタンをクリックします。オブジェクト・クラスの削除の確認を要求するダイアログ・ボックスが表示されます。

6. 確認のダイアログ・ボックスの「削除」ボタンをクリックして、オブジェクト・クラスを削除します。「オブジェクト・クラス」ツリーの既存のオブジェクト・クラスのリストからオブジェクト・クラスが削除されます。

16 Oracle Virtual Directoryのアクセス制御の構成

この章では、Oracle Virtual Directoryのアクセス制御の構成方法について説明します。この章の内容は次のとおりです。

- 第16.1項「Oracle Directory Services Managerを使用したアクセス制御リストの作成」

- 第16.2項「Oracle Directory Services Managerを使用したアクセス制御リストの管理」

16.1 Oracle Directory Services Managerを使用したアクセス制御リストの作成

Oracle Directory Services Managerを使用して既存のACLを作成するには、次の手順を実行します。

注意:
2つのACLの違いが承諾/拒否のプロパティのみの場合、ACLが追加される順序に関係なく、許可されるのは拒否です。たとえば、次の2つのACLでは、publicのすべての属性の検索(s)および読取り(r)は拒否されます。

deny:s,r#[all]#public:
grant:s,r#[all]#public:

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「セキュリティ」を選択します。既存のアクセス制御ポイントがリストされた「アクセス制御ポイント」ナビゲーション・ツリーが表示されます。

3. 「作成」ボタンをクリックします。「新規ACL」ダイアログ・ボックスが表示されます。

4. 「DN」フィールドに、新規ACLを適用するDNを入力して、新規ACLのアクセス制御ポイントを指定します。

5. 「範囲」リストから「エントリ」または「サブツリー」のいずれかを選択し、新規ACLの有効範囲を構成します。「エントリ」を選択すると、新規ACLは仮想ツリーのアクセス制御ポイントのDNエントリにのみ適用されます。「サブツリー」を選択すると、新規ACLは、アクセス制御ポイントのDNエントリおよびそれより下のサブツリーの全エントリに適用されます。

6. 「構造型アクセス項目(エントリ・レベル操作)」領域の「作成」ボタンをクリックし、仮想ディレクトリ・ツリーのエントリのアクセス・ポリシーを作成します。構造型アクセス構成ダイアログ・ボックスが表示されます。

7. 「権限」タブをクリックし、次の操作を実行してアクセス・ポリシーのエントリ権限を設定します。

- エントリ権限に明示的にアクセス権を付与するには、「アクセス・タイプ」リストから「付与」を選択し、アクセス権を付与する権限を選択します。

- エントリ権限へのアクセスを明示的に拒否するには、「アクセス・タイプ」リストから「拒否」を選択し、アクセスを拒否する権限を選択します。

8. 「責任者」タブをクリックし、次の操作を実行してエントリ・アクセス・ポリシーを適用するユーザーを設定します。

- 「責任者」リストからACLのサブジェクトを選択します。

- 「責任者」リストから「特定のDN」または「IPアドレス」を選択した場合は、「DNまたはIPアドレス」フィールドにDNまたはIPアドレスを入力します。

「OK」ボタンをクリックして、「構造型アクセス項目(エントリ・レベル操作)」設定を保存します。「構造型アクセス項目(エントリ・レベル操作)」表に、新しいエントリ・アクセス・ポリシーが表示されます。

9. 「コンテンツ・アクセス項目(属性レベル操作)」領域の「作成」ボタンをクリックし、エントリの属性のアクセス・ポリシーを作成します。コンテンツ・アクセス構成ダイアログ・ボックスが表示されます。

10. 「ターゲット」タブをクリックし、アクセス・ポリシーを適用する属性を「属性」リストから選択します。「*」を選択すると、すべての属性にアクセス・ポリシーが適用されます。

11. 「権限」タブをクリックし、次の操作を実行してアクセス・ポリシーの属性権限を設定します。

- 属性権限にアクセス権を明示的に付与するには、「アクセス・タイプ」リストから「付与」を選択し、アクセス権を付与する権限を選択します。

- 属性権限のアクセス権を明示的に拒否するには、「アクセス・タイプ」リストから「拒否」を選択し、アクセスを拒否する権限を選択します。

12. 「責任者」タブをクリックし、次の操作を実行して属性アクセス・ポリシーを適用するユーザーを設定します。

- 「責任者」リストからACLのサブジェクトを選択します。

- 「責任者」リストから「特定のDN」または「IPアドレス」を選択した場合は、「DNまたはIPアドレス」フィールドにDNまたはIPアドレスを入力します。

13. 「OK」ボタンをクリックして、「コンテンツ・アクセス項目(属性レベル操作)」設定を保存します。「コンテンツ・アクセス項目(属性レベル操作)」表に、新しい属性アクセス・ポリシーが表示されます。

16.2 Oracle Directory Services Managerを使用したアクセス制御リストの管理

この項では、Oracle Directory Services Managerを使用したACLの管理方法について説明します。この項の内容は次のとおりです。

- アクセス制御リストの更新

- アクセス制御リスト・エントリの削除

16.2.1 アクセス制御リストの更新

Oracle Directory Services Managerを使用して既存のACLを編集するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「セキュリティ」を選択します。既存のACLがリストされた「アクセス制御ポイント」ナビゲーション・ツリーが表示されます。

3. 編集するACLをツリーでクリックします。ACLの設定が表示されます。

4. 「サブツリー・アクセス」タブまたは「ローカル・アクセス」タブをクリックします。

5. 編集する属性を選択して「編集」ボタン(鉛筆)をクリックします。
「編集」ダイアログが表示されたら、必要に応じてACL属性を編集し、「OK」ボタンをクリックして変更を保存します。

6. ACL属性の編集が終了したら、「適用」をクリックします。

16.2.2 アクセス制御リスト・エントリの削除

Oracle Directory Services Managerを使用して既存のアクセス制御リスト(ACL)を削除するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「セキュリティ」を選択します。既存のACLがすべてリストされた「アクセス制御ポイント」ナビゲーション・ツリーが表示されます。

3. ツリーで、削除するエントリが含まれるACLをクリックします。ACLの設定が表示されます。

4. ACLで削除するエントリをクリックします。

5. 「削除」ボタンをクリックします。エントリの削除の確認を要求する「削除」ダイアログ・ボックスが表示されます。

6. 「削除」ダイアログ・ボックスの「削除」をクリックして、エントリを削除します。

7. 「ACL」設定画面の「適用」ボタンをクリックして、更新済のACLを適用します。

17 Oracle Virtual Directoryのロギングと監査の管理

この章では、Oracle Virtual Directoryのロギングと監査の管理方法について説明します。この章の内容は、次のとおりです。

- 第17.1項「Oracle Virtual Directoryのロギングの管理」

- 第17.2項「Oracle Virtual Directoryの監査の管理」

17.1 Oracle Virtual Directoryのロギングの管理

Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Scripting Tool (WLST)をインタフェースとして使用してOracle Virtual Directoryのロギングを管理できます。この項では、Oracle Virtual Directoryのロギングの管理について説明します。この項の内容は次のとおりです。

- Oracle Directory Services Managerを使用したOracle Virtual Directoryのロギングの管理

- WLSTを使用したOracle Virtual Directoryのロギングの管理

- 粒度の細かいロギングの管理

17.1.1 Oracle Enterprise Managerを使用したOracle Virtual Directoryのロギングの管理

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、複数のOracle Fusion Middlewareコンポーネントにわたってログ・ファイルをリスト、検索、および構成できます。Oracle Enterprise Manager Fusion Middleware Controlからログ・ファイルを表示することも、ログ・ファイルをダウンロードし、別のツールを使用して表示することも可能です。

関連項目:
Oracle Enterprise Manager Fusion Middleware Controlを使用したロギングの詳細は、『管理者ガイド』を参照してください。

Oracle Virtual Directory固有のロギングの考慮事項

次に示す項目は、Oracle Virtual Directoryのロギングに固有であるため、『管理者ガイド』の情報を補足します。

- Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Virtual Directoryのログ・レベルを設定する際、次のログ・レベルは適用されないため、Oracle Virtual Directoryに影響はありません。

- NOTIFICATION: 16 (CONFIG)

- TRACE: 16 (FINER)

- access.logファイルにログ・メッセージが書き込まれるのは、ロギングがNOTIFICATION:1 (INFO)レベルに設定されている場合のみです。ログ・レベルをERROR:1 (SEVERE)またはWARNING:1 (WARNING)に引き上げ、access.logファイルに情報が書き込まれないようにできます。

- 検索操作の監査ログが作成されるのは、検索によってuserPassword属性が要求される場合のみです。

- 一般的なガイドラインとして、環境に対するOracle Virtual Directoryのログ・レベルを情報量が可能なかぎり少なくなるように設定することをお薦めします。

17.1.2 WLSTを使用したOracle Virtual Directoryのロギングの管理

WLSTを使用して、Oracle Virtual Directoryのロギングの次の管理タスクを実行できます。

- listLoggersを使用したログ出力とレベルのリスト

- getLogLevelを使用した特定のログ出力のレベルの取得(表示)

- setLogLevelを使用した特定のログ出力のレベルの設定

- listLogHandlersを使用したログ・ハンドラのリスト

- configureLogHandlersを使用したログ・ハンドラの構成

- listLogsを使用した既知のログのリスト

- displayLogsを使用したログの内容の検索と表示

関連項目:
WLSTを使用したOracle Virtual Directoryのロギングの管理の詳細は、次のドキュメントを参照してください。

- 管理者ガイド

- WebLogic Scripting Toolコマンド・リファレンス

17.1.3 粒度の細かいロギングの管理

メッセージ・ロギングは、java.util.logging.Filter実装クラスの使用、およびadapters.os_xmlファイルの各アダプタ構成で指定されるlogLevel属性を通じて制御できます。

注意:
この項で説明する粒度の細かいメッセージ・ロギング機能を管理するには、該当するXMLファイルを手動で編集して、Oracle Virtual Directoryサーバーを再起動します。
粒度の細かいメッセージ・ロギングは、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用して管理することはできません。

java.util.logging.Filter StringMatchFilterのデフォルトの実装は、Oracle Virtual Directoryに含まれています。このデフォルトの実装では、次の2つのパラメータがサポートされています。

- StringToBeMatched: 1つまたは複数のDIT/Stringsを指定できます。

- AcceptOnMatch: このブール値により、指定されたDIT/Stringsのリストとの一致に基づいてログ・メッセージを含めるかまたは除外できます。

java.util.logging.Filter実装とそのパラメータは、server.os_xmlファイルで指定できます。次に、文字列c=usを含むログ・メッセージを除外するStringMatchFilterクラスのlogFilterの構成の例を示します。

<logFilters>
<filter className="com.octetstring.vde.util.StringMatchFilter">
<param name="StringToBeMatched"  value="c=us" />
<param name="AcceptOnMatch" value="false" />
</filter>
</logFilters>

ログ・メッセージを含めるには、AcceptOnMatchをtrueに設定します。ログ・メッセージに、logFilter構成で指定されているDITが含まれるようになります。ログ・メッセージを除外には、AcceptOnMatchをfalseに設定します。ログ・メッセージに、指定されているDITが含まれなくなります。StringMatchFilterを有効化するには、それをovd-logging.xmlファイルで定義されているログ出力またはハンドラのいずれかにフィルタとして構成します。次に、LogHandlerに対してフィルタを指定する構成の例を示します。

<logging_configuration>
<log_handlers>
<log_handler name='OVDHandler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'
filter='com.octetstring.vde.util.StringMatchFilter'>
<property> ... </property>
</log_handler>
</log_handlers>
<loggers> ... </loggers>
<logging_configuration>

注意:
server.os_xml、ovd-logging.xml、およびadapters.os_xmlファイルは、次のディレクトリにあります。

ORACLE_INSTANCE/config/OVD/config/COMPONENT_NAME/

17.2 Oracle Virtual Directoryの監査の管理

Oracle Virtual Directory は、コンプライアンス、監視および分析のためにOracle Application Server 11gインフラストラクチャの共通監査フレームワークを使用します。Oracle Enterprise Manager Fusion Middleware ControlおよびWLSTを共通監査フレームワークに対するインタフェースとして使用してOracle Virtual Directoryの監査を管理できます。この項では、Oracle Virtual Directoryの監査の管理について説明します。この項の内容は次のとおりです。

- Fusion Middleware Controlを使用したOracle Virtual Directoryの監査の管理

- WLSTを使用したOracle Virtual Directoryの監査の管理

- 監査データの概要

17.2.1 Fusion Middleware Controlを使用したOracle Virtual Directoryの監査の管理

Oracle Enterprise Manager Fusion Middleware Controlインタフェースを使用して、次の管理を含むOracle Virtual Directoryの監査タスクを実行できます。

- 監査ポリシー

- 監査データの収集と格納

- 監査レポート

Oracle Virtual Directoryを含めほとんどのOracle Fusion Middlewareコンポーネントの監査手順は同じで、『Oracle Platform Security Servicesによるアプリケーションの保護』に詳しく説明されています。次に、Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Virtual Directoryサーバーの監査手順の概要を示します。

1. 「Oracle Virtual Directory」メニューから「セキュリティ」を選択し、「監査ポリシー設定」を選択します。

2. 「監査ポリシー」リストから、「カスタム」を選択して独自のフィルタを構成するか、または事前設定済フィルタ(「なし」、「低」、「中」または「高」のいずれか)を選択します。

3. 障害のみの監査を実施するには、「障害のみ選択」をクリックします。

4. フィルタを構成するには、フィルタ名の隣の「編集」アイコンをクリックします。そのフィルタの「フィルタの編集」ダイアログが表示されます。

5. ボタン、メニューの選択肢、入力する文字列を使用してフィルタ条件を指定します。「条件」には、「Initiator」、「ターゲット」、リモートIP、および「リソース」が含まれます。「条件」のテストには、-contains、-contains_case、-endswith、-endswith_case、-eq、-matches、-ne、-startswith、および-startswith_caseが含まれます。テストには、文字列として値を入力します。グループ化にはカッコを使用し、結合にはANDおよびORを使用します。

6. 条件を追加するには、「追加」アイコンをクリックします。

7. フィルタの編集が完了したら、「OK」をクリックします。

関連項目:
Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Virtual Directoryの監査の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

17.2.2 WLSTを使用したOracle Virtual Directoryの監査の管理

WLSTを使用して、Oracle Virtual Directoryの次の監査タスクを実行できます。

- getAuditPolicyを使用した監査ポリシーの取得(表示)

- setAuditPolicyを使用した監査ポリシーの設定

- listAuditEventsを使用した監査イベントのリスト(表示)

関連項目:
WLSTを使用したOracle Virtual Directoryの監査の管理の詳細は、次のドキュメントを参照してください。

- Oracle Platform Security Servicesによるアプリケーションの保護

- WebLogic Scripting Toolコマンド・リファレンス

Oracle Virtual Directoryのように、ローカルでその監査ポリシーを管理するコンポーネントの場合は、コマンドに対する引数としてMBean名を含める必要があります。監査MBeanの名前の書式は次のとおりです。

oracle.as.ovd:type=component.auditconfig,name=auditconfig,instance=INSTANCE,
component=COMPONENT_NAME

注意:
前の例の監査MBeanは、1つの連続する文字列である必要があります。このドキュメントでは、スペースと幅の制限のために2つの行で表示されています。

属性に変更を加える前に、MBeanが現在のサーバー構成を保持していることを確認する必要があります。そのためには、wlst invoke()コマンドを使用して、Oracle Virtual DirectoryサーバーからMBeanに構成をロードする必要があります。変更が完了したら、invoke()コマンドを使用して、MBean構成をOracle Virtual Directoryサーバーに保存し、次にinvoke()コマンドを使用してOracle Virtual Directoryサーバーから更新された構成をMBeanにロードする必要があります。このプロセスによって、Oracle Virtual DirectoryサーバーとMBeanの同期が取られます。このようにinvoke()を使用するには、ツリーのルート・プロキシMBeanに移動する必要があります。ルート・プロキシMBeanの名前の書式は次のとおりです。

oracle.as.management.mbeans.register:type=component,name=COMPONENT_NAME,instance=INSTANCE

次に例を示します。

oracle.as.management.mbeans.register:type=component,name=ovd1,instance=instance1

setAuditPolicy()およびinvoke()を使用する wlstセッションの例を示します。

java weblogic.WLST
connect('username','password','t3://WEBLOGIC_HOST:WEBLOGIC_ADMIN_PORT')
custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=
instance1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.String)
setAuditPolicy(filterPreset='None',addSpecialUsers="cn=user2,cn=users,dc=oracle,dc
=com",removeSpecialUsers='cn=user1,cn=users,dc=oracle,dc=com',on='oracle.as.ovd:ty
pe=component.auditconfig,name=auditconfig,instance=instance1,component=ovd1'))
custom()
cd('oracle.as.management.mbeans.register')
cd
('oracle.as.management.mbeans.register:type=component,name=ovd1,instance=
instance1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))
invoke('load',jarray.array([],java.lang.Object),jarray.array([],java.lang.String))

17.2.3 監査データの概要

Oracle Virtual Directoryでは、次のコンポーネントに対する構成変更関連のイベントが監査および記録されます。

- ACL (acls.os_xml)

- アダプタ(adapters.os_xml)

- リスナー(listeners.os_xml)

- サーバー(server.os_xml)

監査ログ・レコードには、監査イベントごとに次の情報が含まれます。

- プロキシ・ユーザーDNおよび操作が実行されたIPアドレス

注意:
Oracle Directory Services Manager 11.1.1.4.0によって、すべての主要な操作中にそれらの操作を監査できるようにクライアントIPアドレスおよびユーザーDN情報がOracle Virtual Directory 11.1.1.4.0に送信されます。このOracle Directory Services Managerリリースの新しいAPIでは、Oracle Virtual Directory 11.1.1.4.0リリースの構成および管理のみがサポートされています。

- 操作名およびタイプ(追加、削除、または変更)

- イベントが発生したときのタイムスタンプ

- 影響を受ける構成タイプ(ACL、アダプタ、監査、リスナー、ロギング、またはサーバー)

- 旧構成バージョン(変更前の構成のバージョン)

- 構成の旧バージョンと新バージョンの間の正確な相違

これらの構成変更関連のイベントは、WebService APIレイヤーで監査され、監査リポジトリに記録されます。

また、Oracle Virtual Directoryには、構成変更操作を管理および監査するためのJMXテクノロジも統合されています。JMX MBeanはWebService管理APIをバイパスします。これにより、監査サービスが下位レベルに移動し、すべての構成変更アクティビティの追跡が可能になり、それらの操作イベントが成功したか失敗したかに関係なく記録されます。

17.2.3.1 IPアドレスの記録

Oracle Virtual Directory構成管理クラスおよびWebService APIには、操作の実行元のIPアドレスを追跡し、そのIPアドレスをいくつかの役立つセキュリティ監査情報とともに監査ロジックに渡すメソッドが含まれています。

17.2.3.2 監査構成管理クラス

構成ごとに、対応する構成管理クラスが1つあります。構成XMLファイルは、次のように管理クラスにマップされています。

構成XMLファイル

監査構成管理クラス

acls.os_xml

com.octetstring.vde.config.AclsCfg

adapters.os_xml

com.octetstring.vde.config.AdaptersCfg

listeners.os_xml

com.octetstring.vde.config.ListenersCfg

server.os_xml

com.octetstring.vde.config.ServerCfg

構成に変更を行うと、Oracle Virtual Directoryによって元の構成バージョンのコピーが監査リポジトリに記録され、旧バージョンと新しい構成の間の違いが記録されます。

17.2.3.3 監査メッセージの確認

Oracle Virtual Directoryの監査は、元の値と新しい値の記録など構成パラメータが変更された粒度の細かい変更の記録を試みます。この情報を入手できない場合、Oracle Virtual Directoryでは次の表記を使用して旧バージョンと新バージョンなど構成ファイル全体が記録されます。

規則

説明

NN

DNおよび入手可能な場合は操作が実行されたIPアドレス。

WHAT

変更された構成の名前とタイプ。

DD:HH

イベントが発生したときのタイムスタンプ

CONF DETAIL

正確な構成の詳細。

OO

古い構成。

WW

新規構成。

たとえば、新しいACL、アダプタ、またはリスナーを追加した場合、イベントは次のように監査リポジトリに記録されます。

NN added WHAT configuration on DD:HH. The added configuration is: CONF DETAIL.

既存のACL、アダプタ、またはリスナーを変更したり、監査、ロギング、またはサーバー構成の設定を変更した場合、そのイベントは次のように監査リポジトリに記録されます。

NN updated WHAT configuration on DD:HH. The configuration is changed from OO to WW.

第III部

高度な管理

ここでは、Oracle Virtual Directoryに対する高度な管理タスクについて説明します。内容は次のとおりです。

- 第18章「Oracle Virtual Directoryのカスタマイズ」

- 第19章「統合ディレクトリ・ソリューションに対するOracle Virtual Directoryの構成」

- 第20章「Oracle Communications Universal User Profile」

18 Oracle Virtual Directoryのカスタマイズ

この章では、Oracle Virtual Directoryのカスタマイズ方法について説明します。この章の内容は次のとおりです。

- 第18.1項「Oracle Directory Services Managerへのローカライズされた言語の設定」

- 第18.2項「カスタム・アダプタの作成および構成」

- 第18.3項「カスタムJavaプラグインの開発」

- 第18.4項「Oracle Virtual DirectoryへのWebサービス・クライアントの接続」

18.1 Oracle Directory Services Managerへのローカライズされた言語の設定

Oracle Virtual Directoryには、次の言語で、Oracle Directory Services Managerインタフェースのローカライズされた翻訳が用意されています。

- フランス語

- イタリア語

- ドイツ語

- スペイン語

- ポルトガル語(ブラジル)

- 日本語

- 繁体字中国語

- 簡体字中国語

- 韓国語

Webブラウザの言語設定を使用して、Oracle Directory Services Managerインタフェースに言語を設定できます。言語設定に関する固有の情報は、使用しているWebブラウザのドキュメントを参照してください。

注意:
Oracle Directory Services Managerの管理者アクセスを持つユーザー(通常はcn=orcladmin)のみがOracle Directory Services Managerにログインできます。

18.2 カスタム・アダプタの作成および構成

Oracle Virtual Directoryではカスタム・アダプタの作成機能もサポートされています。これには、定義済のAPIによってほとんどすべてのデータ・ソースに接続できるプラグインを使用します。たとえば、カスタム・アダプタを使用して、Webサービスで入手できる情報を抽出できます。カスタム・アダプタは、それ自体には機能がないアダプタです。かわりに、アダプタ・レベルのプラグインを構成してその機能を実装できるプレースホルダです。デフォルトでは、カスタム・アダプタはどのデータ・ソースにもマップされていません。Oracle Directory Services Managerの「プラグイン」タブでカスタム・アダプタに追加されるDiameterプラグインなどのプラグインは、カスタム・アダプタにデータを提供します。通常、カスタム・アダプタは、Oracle Virtual Directoryを、Webサービスなど非LDAPサービスまたは非データベース・サービスに接続する必要がある顧客によって作成されます。

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

- カスタム・アダプタの作成

- カスタム・アダプタの構成

18.2.1 カスタム・アダプタの作成

Oracle Directory Services Managerを使用してカスタム・アダプタを作成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「アダプタ」を選択します。「アダプタ」ナビゲーション・ツリーが表示されます。

3. 「アダプタの作成」ボタンをクリックします。新規アダプタ・ウィザードが表示されます。

4. アダプタのタイプを定義するには、次の手順を実行します。

1. 「アダプタ・タイプ」リストから「カスタム」を選択します。

2. 「アダプタ名」フィールドにカスタム・アダプタの一意の名前を入力します。アダプタ名の値は、そのアダプタを参照する必要のある他の構成フィールドで使用されます。

3. 「アダプタ・テンプレート」リストから「デフォルト」テンプレートを選択します。

4. 「次へ」をクリックします。「設定」画面が表示されます。

5. 「アダプタ接尾辞/ネームスペース」フィールドに有効なベースDNを(DN形式で)入力します。このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。アダプタ接尾辞フィールドに、戻されるエントリのベースDN値を入力します。たとえば、「アダプタ接尾辞/ネームスペース」フィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

6. 「次へ」をクリックします。カスタム・アダプタの設定の概要が表示されます。設定を確認し、「終了」をクリックしてカスタム・アダプタを作成します。「アダプタ」ツリーに、カスタム・アダプタが表示されます。

カスタム・アダプタを作成したら、「カスタム・アダプタの構成」の手順に従って構成できます。

18.2.2 カスタム・アダプタの構成

この項では、カスタム・アダプタ設定の構成方法を説明します。この項の内容は次のとおりです。

- カスタム・アダプタの一般設定の構成

- アダプタのルーティングの構成

- アダプタ・プラグインおよびマッピングの構成

18.2.2.1 カスタム・アダプタの一般設定の構成

カスタム・アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックし、「一般」タブをクリックして次に示すフィールドに値を設定し、「適用」をクリックしてアダプタの一般設定を構成できます。

ルート

このフィールドには、アダプタが情報を提供するルートDNを定義します。定義されているDNとその下の子エントリには、アダプタのネームスペースが含まれます。このフィールドに入力する値は、戻されるエントリのベースDN値です。たとえば、このフィールドにdc=mydomain,dc=comと入力すると、すべてのエントリはdc=mydomain,dc=comで終わります。

アクティブ

アダプタは、アクティブ(有効)または非アクティブ(無効)として構成できます。非アクティブに構成されたアダプタは、サーバーの再起動時やアダプタの起動の試行時には起動しません。非アクティブの設定は、古い構成を使用可能な状態にしておく場合や、構成から削除せずにスタンバイ状態にしておく場合に使用します。デフォルト設定はアクティブです。

18.2.2.2 アダプタのルーティングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「ルーティング」タブをクリックし、「ルーティング設定の概要」を参照することで、そのアダプタのルーティングを構成できます。

注意:
バインド操作をサポートするかどうかが不明なカスタム・アダプタを定義する際には、「バインド・サポート」ルーティング設定を有効化します。

18.2.2.3 アダプタ・プラグインおよびマッピングの構成

アダプタを作成したら、「アダプタ」ツリーでアダプタ名をクリックして「プラグイン」タブをクリックし、「アダプタ・プラグインの管理」および「アダプタへのマッピングの適用」を参照することで、そのアダプタにプラグインおよびマッピングを適用できます。

18.3 カスタムJavaプラグインの開発

この項では、Oracle Virtual DirectoryのカスタムJavaプラグインの開発方法について説明します。この項の内容は次のとおりです。

- 概要

- チェーン・システムの概要

- プラグインの実装ポイント

- EntrySetの作成

- フィルタ処理の概要

- クラスの概要

18.3.1 概要

Oracle Virtual Directoryでは、Oracle Virtual Directoryのパススルー時にLDAP操作を処理および操作できるカスタムJavaプラグインを作成してデプロイできます。プラグインは、すべてのリクエストを把握し処理するグローバル・レベル、または特定のアダプタに対するリクエストのみを把握し処理するアダプタ・レベルに配置できます。また、特定の操作やネームスペースに対して実行されるようにプラグインを作成およびデプロイすることもできます。

注意:
カスタムJavaプラグインを使用して属性名を変更する場合、DB_Groupsマッピングで行われるように、カスタム・コードが受信フィルタ・オブジェクトを上書きする場合にのみ、Oracle Virtual Directoryで、名前の変更された属性/値の検索がサポートされます。

Oracle Virtual Directoryの各プラグインには、表18-1にリストされているように、特定の実装ポイントがあります。

表18-1 プラグインの実装ポイント

実装ポイント

説明

構成

プラグインの構成データ。構成のカスタム部分は、初期化パラメータの名前と値のペアで構成されています。

起動/停止

init(PluginInit initParams, String name)およびdestroy()メソッドは、プラグインの初期化および初期化解除時に呼び出されます。

可用性

available(Chain chain, DirectoryString base)メソッドは、プラグインを実行するかどうかを決定するために、プラグインの実行前に呼び出されます。

操作

呼び出される様々な操作メソッド。

この章では、表18-1にリストされている実装ポイントを説明して、カスタム・プラグインの作成方法を示します。この章では、バインド操作が失敗したか成功したかを検出するBad Password Countプラグインという仮想の例のプラグインについて説明します。操作が成功した場合は件数が消去され、バインドが失敗した場合は件数が増加します。仮想のBad Password Countプラグインを使用すると、不正なパスワード件数をディレクトリの外から変更できなくなります。

注意:
この章で説明するBad Password Countプラグインは仮想の例で、Oracle Virtual Directoryプラグインおよびそのチェーン・システムがどのように機能するかを示すために使用されます。作成すればサポートされますが、Oracle Virtual DirectoryにはBad Password Countプラグインは用意されていません。

18.3.2 チェーン・システムの概要

Oracle Virtual Directoryプラグインは、Java Servlet 2.3フィルタ・モデルに基づく実装に準拠しています。このモデルでは、前操作および後操作の処理、および操作を続行するかどうかの判断に 1 つのメソッドが使用されます。複数のプラグインが結合されて、プラグインのチェーンが形成されます。このチェーンの実装を例示するために、仮想の例であるBad Password Countプラグインが、ディレクトリに追加されるエントリに不正なパスワード件数属性を追加するかどうかを決定する次のような状況を考えてみます。

addメソッドが呼び出されたときにリクエストを操作でき、それにより、渡される属性とそれらの値を操作(たとえば、ActiveDirectoryを汎用LDAPディレクトリとしてマスキングしている場合にオブジェクト・クラス値inetOrgPersonをuserに変更)したり、カスタム・アダプタなどでデータの記憶域を非ディレクトリ・システムまたはデータベース・システムにすることができます。仮想ディレクトリで、他のプラグインを使用してそのリクエストをさらに処理できるようにするには、chain.nextAddメソッドを呼び出します。ほとんどのプラグイン・メソッドには、対応するchain.next<XXX>メソッドがあります。プラグインによってリクエストをさらに処理することを許可しない場合は、chain.next<XXX>コールを省略できます。

注意:
アダプタ・タイプはプラグインとは無関係です。プラグインは、どのようなタイプのアダプタにも追加できます。

18.3.3 プラグインの実装ポイント

カスタム・プラグインを作成する前に、com.octetstring.vde.chain.Pluginインタフェースを実装するか、com.octetstring.vde.chain.BasePluginクラスを拡張するかを決定する必要があります。BasePluginクラスを使用すると、プラグイン開発者は、プラグインによって処理される操作用のメソッドのみを実装できます。この章で示す例のプラグインでは、BasePluginクラスを拡張して実装を簡略化しています。

この項では、Oracle Virtual Directoryのプラグインの実装ポイントについて説明します。

- 構成、開始および停止のプラグインの実装ポイント

- 使用可用なプラグインの実装ポイント

- 操作のプラグインの実装ポイント

18.3.3.1 構成、開始および停止のプラグインの実装ポイント

プラグインの1番目の実装ポイントは構成です。プラグインは、Oracle Virtual Directory構成システムによって提供される、一連の単純な名前と値のペアを使用して構成されます。このペアは、プラグインのinitメソッドに対するparams引数を介してプラグイン開発者に提供されます。この章で示す例のプラグインには、次の構成オプションがあります。

- countAttribute: 不正なパスワード件数を保存するすべてのユーザー・エントリに追加される属性。

- addOnCreate: ユーザーの作成時にプラグインがこの属性を追加する場合にtrueに設定されるブール値。

- objectClassForAdd: 属性が追加されるユーザーを表すオブジェクト・クラス。

- ignoreOnModify: countAttributeの変更リクエストが無視される場合にtrueに設定されるブール値。

これらの構成オプションは、2番目の実装ポイントであるライフ・サイクル・メソッドで取得されます。initメソッドはサーバー起動時にプラグインを初期化する際に呼び出され、destroyメソッドはプラグインを停止する際に呼び出されます。例18-1に、サンプルのinitメソッドを示します。

例18-1 サンプルのinitメソッド

/**
* Passes initialization information to the Plug-in
*
* @param initParams
*            Hashmap of key/value pairs specified in initial config
* @param name
*            The name specified in the config for this Plug-in
*/
public void init(PluginInit initParams, String name) throws ChainException {
//the countAttribute parameter is required
if (!initParams.containsKey(BadPasswordCount.CONFIG_COUNT_ATTRIBUTE)) {
throw new ChainException(name + ": The "
+ BadPasswordCount.CONFIG_COUNT_ATTRIBUTE
+ " attribute is required");
}
this.countAttribute = new DirectoryString(initParams
.get(BadPasswordCount.CONFIG_COUNT_ATTRIBUTE));
this.attribType = SchemaChecker.getInstance().getAttributeType(
this.countAttribute);
//determine if add on create
this.addOnCreate = initParams
.containsKey(BadPasswordCount.CONFIG_ADD_ON_CREATE)
&& initParams.get(BadPasswordCount.CONFIG_ADD_ON_CREATE)
.equalsIgnoreCase("true");

if (this.addOnCreate) {
&& !initParams
.containsKey(BadPasswordCount.CONFIG_OBJECTCLASS_FOR_ADD)) {
throw new ChainException(name
+ ": When adding count attribute, the parameter "
+ BadPasswordCount.CONFIG_OBJECTCLASS_FOR_ADD
+ " is required");
}

String[] objectClasses = initParams
.getVals(BadPasswordCount.CONFIG_OBJECTCLASS_FOR_ADD);
this.objectClasses = new HashSet();

for (int i = 0, m = objectClasses.length; i < m; i++) {
this.objectClasses.add(new DirectoryString(objectClasses[i]));

}
} else {
this.addOnCreate = false;
}

logger.info("Adding on create : " + this.addOnCreate);
//determine if the modify operation should be ignored
this.ignoreModify = initParams
.containsKey(BadPasswordCount.CONFIG_IGNORE_MODIFY)
&& initParams.get(BadPasswordCount.CONFIG_IGNORE_MODIFY)
.equalsIgnoreCase("true");

例18-1のメソッドでは、プラグインを設定するための初期化パラメータが確認されています。構成情報が不十分な場合は、プラグインにより例外がスローされ、サーバーによる操作目的での使用が可能になるようプラグインを構成できない原因になります。接続の解放またはサービスの停止が必要な場合以外は、destroyメソッドを実装する必要はありません。

18.3.3.2 可用性のプラグインの実装ポイント

使用可能な実装ポイントは、構成、開始および停止の実装ポイントに続きます。availableメソッドは、特定のLDAP操作に対する各プラグインの呼出しが可能になる前に呼び出されます。availableメソッドによりtrueが戻されると、プラグインが実行されます。例18-2では、availableメソッドによりRequestオブジェクトのignoreOnModifyオプションの有無が確認されています。それが定義されている場合、プラグインはスキップされます。同様に、addonCreateオプションがfalseに設定されている場合も、プラグインはスキップされます。

例18-2 ignoreOnModifyオプションの有無を確認するサンプルのメソッド

/**
* Determines if a plugin is available for the current chain
*
* @param chain
* @param base
* @return True or False if available for a particular chain & base
*/
public boolean available(Chain chain, DirectoryString base) {

if (chain.getOperationType() == Chain.ADD_OP && !this.addOnCreate) {
return false;
} else if (chain.getOperationType() == Chain.MOD_OP
&& this.ignoreOnModify) {
return false;
} else {
return true;
}
}

availableメソッドがtrueを戻すと、リクエストの操作部分が実行されます。

18.3.3.3 操作のプラグインの実装ポイント

最後の実装ポイントは、操作の実装です。例18-3に、次のバインド操作のコード実装を示します。

例18-3 バインド操作の実装の例

/**
* Moves through the "bind" operation's chain
*
* @param chain
*            The current chain
* @param dn
*            The DN for the user
* @param password
*            The user's password
* @param result
*            The result of the bind
*/
public void bind(Chain chain, Credentials creds, DirectoryString dn,
BinarySyntax password, Bool result) throws DirectoryException,
ChainException {

// Pre-event processing

// calls the next plug-in in the chain (or comment out if a handler)
try {
chain.nextBind(creds, dn, password, result);
} catch (DirectoryException e) {
throw e;
}

// Post-event processing
if (result.booleanValue()) {
// success, reset count
setPasswordCount(chain, creds, dn, 0);
} else {
Vector searchAttributes = new Vector();
searchAttributes.add(this.countAttribute);

ChainVector results = new ChainVector();
try
{
chain.getVSI().get(chain.getRequest(), creds, dn,
new Int8((byte) 0), ParseFilter.parse("(objectClass=*)"),
new Bool(false), searchAttributes, results);

if (results.size() > 0) {
EntrySet es = (EntrySet) results.get(0);
Entry entry = es.getNext();
Vector values = entry.get(this.countAttribute);
Syntax value = (Syntax) values.get(0);
IntegerSyntax is = new IntegerSyntax(value.getValue());
setPasswordCount(chain, creds, dn,
((int) is.getLongValue()) + 1);
} else
{
setPasswordCount(chain, creds, dn, 1);
chain.getVSI().get(...);
}
}
catch (Exception ex)
{

}
finally
{
for (EntrySet entrySet : results)
entrySet.cancelEntrySet();
}

}
}
}

private void setPasswordCount(Chain chain, Credentials creds,
DirectoryString dn, int count) throws DirectoryException,
ChainException {

Vector values = new Vector();
values.add(new IntegerSyntax(count));
EntryChange modify = new EntryChange(EntryChange.MOD_REPLACE,
this.countAttribute, values);
Vector changes = new Vector();
changes.add(modify);
chain.getVSI().modify(chain.getRequest(), creds, dn, changes);

}

例18-3のメソッドでは、パスワード失敗件数がパスワード・ポリシーという形でディレクトリ内に維持されている例が示されています。メソッドでは、操作の前処理も実行されておらず、バインド操作の引継ぎも試行されていないことに注意してください。プラグインのbindメソッドがchain.nextBindメソッドをすぐに呼び出し、独自のロジックで続行する前にバインドが完了するまで待機します。コントロールがchain.nextBindから戻されてバインドが完了すると、プラグインによりバインドが成功したかどうかが確認されます。バインドが成功した場合には、プラグインにより失敗件数属性がゼロに設定されます。バインドが失敗した場合には、現行の失敗件数が取得され、増加した値が設定されます。

bindメソッドは、仮想サービス・インタフェース(VSI)を使用してバインディング・ユーザーのレコードを変更します。VSIインタフェースは、プラグインがグローバルにデプロイされているかアダプタのコンテキスト内にデプロイされているかにかかわらず、ディレクトリ情報への一貫したアクセス方法としてOracle Virtual Directory全体で使用できます。これはVSIが、現行のプラグインの後にチェーン内の次のプラグインを開始することにより、常にOracle Virtual Directoryをコールすることで実現されます。たとえば、プラグインの前にマッパーが存在し、プラグインの後にキャッシュが存在する場合、VSIへのコールはキャッシュのみを経由します。

このプラグインは、論理的にバインド失敗件数の保持を担うため、LDAPクライアントによる件数変更の試行を防止するために、プラグインのmodifyメソッドを実装する必要があります。例18-4のプラグインのmodifyメソッドは、count属性がmodify変更リストに含まれている場合に例外をスローするように実装されています。

例18-4 サンプルのmodifyメソッド

/**
* Moves through the "modify" operation's chain
*
* @param chain
*            The current chain
* @param creds
*            The currnet user's credentials
* @param name
*            The name of the object being modified
* @param changeEntries
*            The group of EntryChange Objects
*/
public void modify(Chain chain, Credentials creds, DirectoryString name,
Vector changeEntries) throws DirectoryException, ChainException {

Iterator it = changeEntries.iterator();
while (it.hasNext()) {
EntryChange ec = (EntryChange) it.next();
if (ec.getAttr().equals(this.countAttribute)) {
throw new
DirectoryException(LDAPResult.CONSTRAINT_VIOLATION
.intValue(), "Cannot modify password count attribute");
}
}

chain.nextModify(creds, name, changeEntries);

}

ステータス・コードおよびメッセージとともにDirectoryExceptionがスローされています。この例外が別のプラグインによって捕捉されない場合、例外はメッセージとコードの両方でクライアントに戻されます。ignoreOnModifyが構成されているかどうかの判断はavailableメソッドに委任してあるため、この例では確認する必要はありません。設定されている場合、例18-4のプラグインのmodifyメソッドは呼び出されていません。

18.3.3.3.1 検索

検索は、他の操作とは異なり、1つではなく3つのメソッドを実装できます。第一のメソッドgetは他の操作メソッドと同様に機能し、プラグイン開発者は検索リクエストを前処理し、戻りを後処理できます。戻される各Entryを処理することもできますが、それを実行するとメモリー使用率の面で大変非効率的です。getメソッドの結果の処理では、クライアントに戻す前にすべての結果をメモリーに取得する必要があります。そのために、クライアントに戻すすべてのEntryに対して実行されるpostSearchEntryメソッドが用意されており、これによって属性を効率的な方法で変更または追加できます。また、検索操作が完了したマークを付けるpostSearchCompleteメソッドもあります。

postSearchEntry処理を効率的に使用するために、Oracle Virtual Directoryでは、EntrySetと呼ばれる特別なクラスを使用して結果セットの処理が行われます。getメソッドは、Vectorを戻すことにより結果を戻し、その結果には1つ以上のEntrySetが含まれます(詳細は「EntrySetの作成」を参照)。

18.3.4 EntrySetの作成

Oracle Virtual Directoryでは、ディレクトリの各オブジェクトはcom.octetstring.vde.Entryオブジェクトで表されます。各エントリには、オブジェクトの名前と属性値を持つ属性が含まれています。すべてのエントリ・オブジェクトは、com.octetstring.vde.EntrySetインタフェースの実装を使用してOracle Virtual Directoryで処理されます。エントリ・セットでは、特定のデータ・ソースから戻されたすべてのエントリが保存または処理されます。通常のOracle Virtual Directory処理では、検索リクエスト中に呼び出された各アダプタにより、Oracle Virtual Directoryから戻される結果のリストに独自のEntrySet実装が追加されます。また、プラグインにより、結果のVector配列に追加のEntrySetオブジェクトが挿入される場合もあります。検索リクエストを実行するためにすべてのアダプタへの問合せが完了すると、各EntrySetはクライアントに送信されるエントリに関して調査されます。

すべてのアダプタでEntrySet実装が作成されますが、プラグインでもEntrySetインタフェースのインスタンスが作成され、それを使用して検索リクエスト中にクライアントにエントリが戻されます。

次に、EntrySetの作成にプラグインで使用できる2つの方法を示します。

- ExtensibleEntrySet

- カスタムのEntrySet

18.3.4.1 ExtensibleEntrySet

EntrySetの作成にプラグインで使用できる最も簡単な方法は、com.octetstring.vde.backend.extensible.ExtensibleEntrySetクラスを使用して、Entryオブジェクトのjava.util.Vectorに基づくEntrySetを作成する方法です。次にその手順を示します。

1. 新規のjava.util.Vector配列を作成します。

2. VectorにすべてのEntryオブジェクトを追加します。

3. コンストラクタに前述のVectorを渡すExtensibleEntrySetの新規インスタンスを作成します。

例18-5は、Webサービスを使用して銘柄記号に基づいて株価を取得するプラグインの例を示しています。このプラグインは、カスタム・アダプタの概念を実装するように設計されています。それは、それ自体は機能を持たないアダプタであり、かわりにその機能を実装するようにアダプタ・レベルのプラグインを構成できるプレースホルダです。このStock Serviceの例では、プラグインはカスタム・アダプタに対して構成されます。このプラグインによってすべてのイベントの処理が行われるため、Stock Serviceプラグインによってchain.getNext()メソッドは呼び出されないことが想定されます。

プラグインのgetメソッドにより、VectorにEntryオブジェクト(株価エントリ)のリストが追加され、そのVectorに基づいてExtensibleEntrySetが作成されます。

例18-5 ExtensibleEntrySetを使用したEntrySet作成の例

public void get(Chain chain, Credentials creds, DirectoryString base,
Int8 scope, Filter filter, Bool typesonly, Vector attributes,
Vector result) throws DirectoryException, ChainException {

// Since this method is a handler, chain.getNext is not called.

if (scope.intValue() == SearchScope.BASEOBJECT && base.equals(this.suffix)) {
// handle the logical root of the adapter
Entry root = this.getSimpleEntry(this.suffix);
Vector entries = new Vector();
entries.add(root);
result.add(new ExtensibleEntrySet(entries));
return;
}

//This adapter only supports searches based on an equality match
//or an or'ing of equality matches
if (filter.getSelector() != Filter.EQUALITYMATCH_SELECTED &&
filter.getSelector() != Filter.OR_SELECTED) {
throw new DirectoryException("Only equality match or an or'ing "+
"of equality matches are allowed");
}

Vector entries = new Vector();

//If the filter is an OR filter, we can iterate over every quote
if (filter.getSelector() == Filter.OR_SELECTED) {
Iterator it = filter.getOr().iterator();
while (it.hasNext()) {
Entry entry = getStockEntry((Filter) it.next());
if (entry != null) {
entries.add(entry);
}
}
} else {
//single quote
Entry entry = getStockEntry(filter);
if (entry != null) {
entries.add(entry);
}
}
//We use the ExtensibleEntrySet as a simple holder for entry sets.
result.add( new ExtensibleEntrySet(entries));
}

18.3.4.2 カスタムEntrySet

ExtensibleEntrySetを使用してEntrySetを作成するのは最も簡単な方法ですが、処理がクライアントに戻される前にすべての結果をコンパイルする必要があるため、最も効率のよい方法ではありません。この場合、フィルタの各項目に対するサービスがコールされます。このリクエストをより効率的に処理できるのは、LDAPアダプタ操作と同じように、Stock Serviceからリクエストされるときに新規エントリを取得してEntrySetsを作成する方法です。

LDAPアダプタのEntrySetに次のEntryが要求されると、システムにより、リモート・サーバーから一度に1つずつ次のエントリが取得されます。これは、LDAPプロトコルが意図する動作です。クライアントはすべてのエントリが処理される前にエントリの取得を開始できるため、この方法ははるかに効率的です。また、この方法では、クライアントによるエントリ取得の停止や、問合せの中断も可能です。

プラグインがリクエストどおりにエントリを戻すEntrySetを作成するためには、com.octetstring.vde.EntrySetの実装を作成する必要があります。各EntrySetで、次のメソッドを実装する必要があります。

- boolean hasMore()
EntrySetに他のエントリがある場合にtrueを戻します。このメソッドにより悪い影響が出ないように注意する必要があります。

- Entry getNext()
EntrySetの次のエントリを戻します。他にエントリがない場合にはNULLを戻します。

- void cancelEntrySet()
このメソッドは、EntrySetを完全に実行できない場合に呼び出されます。これにより、カスタムのEntrySet実装が保持しているシステム・リソースが解放されます。

例18-6は、株価を表示するWebサービスからアダプタを作成する例18-5と同じプラグインの実装ですが、例18-6では、getメソッドにより、カスタムEntrySetに渡される記号のリストのみが作成されます。例18-6のgetメソッドにより、VectorにEntryオブジェクト(株価エントリ)のリストが追加され、そのVectorに基づいてExtensibleEntrySetが作成されます。

例18-6 カスタムのEntrySetへの引渡しを行うサンプルのgetメソッド

public void get(Chain chain, Credentials creds, DirectoryString base,
Int8 scope, Filter filter, Bool typesonly, Vector attributes,
Vector result) throws DirectoryException, ChainException {
if (scope.intValue() == SearchScope.BASEOBJECT && base.equals(this.suffix)) {
Entry root = this.getSimpleEntry(this.suffix);
Vector entries = new Vector();
entries.add(root);
result.add(new ExtensibleEntrySet(entries));
return;
}

//This adapter only supports searches based on an equality match
//or an or'ing of equality matches
if (filter.getSelector() != Filter.EQUALITYMATCH_SELECTED &&
filter.getSelector() != Filter.OR_SELECTED) {
throw new DirectoryException("Only equality match or an or'ing"+
" of equality matches are allowed");
}

String rdn="uid";
ArrayList symbols = new ArrayList();
//If the filter is an OR filter, we can iterate over every quote
if (filter.getSelector() == Filter.OR_SELECTED) {
Iterator it = filter.getOr().iterator();
while (it.hasNext()) {
//Extract the symbol from the filter
String symbol = new String(filter.getEqualityMatch().
getAssertionValue().toByteArray());

//The attribute being checked in the equality search
//doesn't really matter, but we need an RDN for each entry
rdn = new String(filter.getEqualityMatch().
getAttributeDesc().toByteArray());
symbols.add(symbol);
}
} else {
//single quote
//Extract the symbol from the filter
String symbol = new String(filter.getEqualityMatch().
getAssertionValue().toByteArray());

//The attribute being checked in the equality search doesn't
//really matter, but we need an RDN for each entry
rdn = new String(filter.getEqualityMatch().
getAttributeDesc().toByteArray());
symbols.add(symbol);
}

//We use the ExtensibleEntrySet as a simple holder for entry sets.
result.add( new StockEntrySet(symbols.iterator(),rdn,this.base));

}

例18-6では、銘柄記号のリストは、検索フィルタのorを反復することによって作成されています。コンパイルされたリストは、例18-7に示すカスタムのEntrySet実装に渡されます。

例18-7 カスタムのEntrySetに渡されるデータの例

public class StockEntrySet implements EntrySet {

Iterator quotes;
String rdn;
String base;

public StockEntrySet(Iterator quotes, String rdn,String base) {
this.rdn = rdn;
this.quotes = quotes;
this.base = base;
}

public Entry getNext() throws DirectoryException {
Entry entry = this.getStockEntry((String) quotes.next());
if (entry == null) {
if (this.hasMore()) {
return this.getNext();
} else {
return null;
}
} else {
return entry;
}
}

public boolean hasMore() {
return quotes.hasNext();
}

/**
* Returns an entry for a stock quote
* @param filter
* @return An entry for the stock quote, or null for none.
* @throws DirectoryException
*/
public Entry getStockEntry(String symbol) throws DirectoryException {
//Create a new entry with the symbol as the RDN
Entry entry = new Entry(new DirectoryString(rdn + "=" + symbol + "," +
this.base));

//This uses an Apache Axis generated client stub
NetXmethodsServicesStockquoteStockQuoteService service = new
NetXmethodsServicesStockquoteStockQuoteServiceLocator();
try {
NetXmethodsServicesStockquoteStockQuotePortType
quoteService = service.
getNetXmethodsServicesStockquoteStockQuotePort();
double value = quoteService.getQuote(symbol);
if (value == -1) {
return null;
}

//Create the attribute for the entry
Vector vals = new Vector();
vals.add(new DirectoryString(symbol));
entry.put(new DirectoryString(rdn),vals);

vals = new Vector();
vals.add(new DirectoryString("top"));
vals.add(new DirectoryString("stockForOrganization"));
entry.put(new DirectoryString("objectClass"),vals);

vals = new Vector();
vals.add(new DirectoryString(Double.toString(value)));
entry.put(new DirectoryString("quote"),vals);

return entry;

} catch (ServiceException e) {
throw new DirectoryException("Could not load web service : " +
e.getMessage());
} catch (RemoteException e) {
throw new DirectoryException("Could not load web service : " +
e.getMessage());
}
}
public void cancelEntrySet() {
// nothing to do
}
}

例18-7のEntrySet実装では、現在どの記号が処理されているかを追跡するjava.util.Iteratorが使用されています。StockEntrySetクラスでは、クライアントのかわりにOracle Virtual DirectoryによってEntryがリクエストされるまで、エントリ結果作成のためにWebサービスが呼び出されることはありません。

プラグインでは、1つ以上の株式の検索がサポートされているため、すべての検索で有効な結果が戻されるとはかぎりません。株式のリストを完全に検索し終わる前に、getNextでOracle Virtual DirectoryにNULLという結果が戻され、Oracle Virtual Directoryで結果が空であるとみなされる場合について考えてみます。この状況に対処するために、getNextには、getStockEntryの呼出しの後に特別なコード・ブロックが追加されています。getStockEntryでNULLが戻され、リクエストされた株式の反復が終了していない場合には、次の候補を処理するためにgetNextによりそれ自身が呼び出されます。この再帰は、有効な結果が1つ以上戻されるか、すべての問合せが完了するまで続きます。

18.3.5 フィルタ処理の概要

LDAPフィルタ処理は複雑になる場合もあります。Oracle Virtual Directoryプラグインのコンテキストでは、前処理または後処理の際の2度、フィルタの解析に役立ちます。どちらの方法にもそれぞれのメリットとデメリットがあり、必ずしも相互に排他的であるとはかぎりません。

後処理のフィルタ処理

後処理のフィルタ処理ではcom.octetstring.vde.util.FilterUtils.evalFilter(Entry e, Filter f)メソッドを使用して、結果として戻されるエントリが必要なフィルタに一致するかどうかが確認されます。このメソッドはフィルタを処理する最も簡単な方法で、Entryオブジェクトの集合としてメモリーに残る事前定義済の少量のデータ・セットを処理する際に便利です。一般的に、フィルタを別の形式(SQLのWHERE句や外部APIの特別なオブジェクト・モデルなど)に変換する必要がある場合には、このメソッドは適していません。

前処理のフィルタ処理

前処理フィルタを使用してフィルタを解析し、解析したフィルタを変更された検索に適用するか、検索ターゲットが解釈できる別の形式に変換する際に使用されます。LDAPフィルタをSQLのWHERE句に変換する前処理のフィルタについて考えてみます。これを実行するには、フィルタ・オブジェクトを調査する必要があります。たとえば、次のLDAPフィルタをSQLのWHERE句に変換するとします。

(&(|(user=jsmith)(user=lswanson)(user=ccarson))(dept=payroll))

前のLDAPフィルタには、ユーザーがjsmith、lswansonまたはccarsonで部門がpayrollのすべてのレコードと指定されています。図18-1に、このLDAPフィルタを図で示します。

図18-1 サンプルのLDAPフィルタの図

図18-1のフィルタをSQLのWHERE句に変換するには、ツリーを調査する再帰関数を使用します。Oracle Virtual Directoryでは、この例のフィルタはFilterオブジェクトの階層として表され、これらには、調査可能なツリーを作成するための他のFilterオブジェクトのコレクションが含まれています。図18-1のフィルタには、図18-2に示すオブジェクト・モデルが含まれます。ここでは、フィルタ要素を表すために使用されているクラス名を、操作または演算子の下に示しています。

図18-2 フィルタのオブジェクト・モデルの例

図18-2に示されているツリーを調査するために、フィルタのgetSelector()メソッドに問い合せてフィルタのタイプを判断する再帰メソッドが使用されます。フィルタのタイプが判明したら、getFilterTypeメソッドを使用してその値を抽出する必要があります。たとえば、フィルタがuser=jsmithなどの等価フィルタの場合、フィルタ・オブジェクトの値はcurrentFilter.getEqualityMatch()から取得します。この場合の戻り値はAttributeValueAssertionで、属性名および値がOracleとして保存されます。取得したら、値は文字列オブジェクトに変換できます。Filter_andおよびFilter_orオブジェクトは、操作中の子フィルタを反復するためのjava.util.Iteratorクラスを戻します。

LDAPフィルタでは、関連ごとに項目が2つに制限されるわけではありません。OR部分には3つのオペランドがあります。SQLで許可されているオペランドは操作ごとに2つのみであるため、図18-2のツリーはバイナリ・ツリーに変換する必要があります。

図18-3 OR機能の分割

図18-3では、OR操作は、2つの別々のOR操作に分割されています。フィルタの最後のWHERE句は、((user=jsmith) OR ((user=lswanson) OR (user=ccarson))) AND (dept=payroll)です。LDAPの前置記法は、操作ごとに2つのオペランドのみを伴うSQLのLIKE中置記法に変換されています。例18-8に、変換のソース・コードを示します。

例18-8 LDAPの前置記法をSQLの表記法に変換するためのサンプルのソース・コード

import com.octetstring.vde.util.*;
import com.octetstring.ldapv3.*;
import java.util.*;

public class ConvertFilter {
public static void main(String[] args) throws Exception {
String ldapFilter = "(&(|(user=jsmith)(user=lswanson)" +
(user=ccarson))(dept=payroll))";

System.out.println("Ldap Filter : " + ldapFilter);
System.out.println("SQL WHERE : " +
filterToSQL(ParseFilter.parse(ldapFilter)));
}
/**
*Converts an ldap filter to an SQL WERE clause
*@param currentFilter The filter being converted
*/
public static String filterToSQL(Filter currentFilter) {
String[] filterVal;
String infix="";
switch (currentFilter.getSelector()) {
case Filter.EQUALITYMATCH_SELECTED :  // (attrib=val)
filterVal = getString(currentFilter.getEqualityMatch());
return filterVal[0] + "=" + filterVal[1];

case Filter.PRESENT_SELECTED : // (attrib=*)
return new String(currentFilter.getPresent().toByteArray()) + "=*";

case Filter.GREATEROREQUAL_SELECTED : // (attrib>=val)
filterVal = getString(currentFilter.getGreaterOrEqual());
return filterVal[0] + ">=" + filterVal[1];

case Filter.LESSOREQUAL_SELECTED :  // (attrib<=val)
filterVal = getString(currentFilter.getLessOrEqual());
return filterVal[0] + "<=" + filterVal[1];

case Filter.SUBSTRINGS_SELECTED: // (attrib=val*ue)
String type = new String(currentFilter.getSubstrings().getType().toByteArray(), "UTF-8");

StringBuilder subfilter = new StringBuilder();
for (SubstringFilter_substrings_Seq oneSub : currentFilter.getSubstrings().getSubstrings()) {
if (oneSub.getSelector() == SubstringFilter_substrings_Seq.INITIAL_SELECTED) {
subfilter.append(new String(oneSub.getInitial().toByteArray(), "UTF-8") + "%");
} else if (oneSub.getSelector() == SubstringFilter_substrings_Seq.ANY_SELECTED) {
if (subfilter.length() == 0) {
subfilter.append("%");
}
subfilter.append(new String(oneSub.getAny().toByteArray(), "UTF-8") + "%");
} else if (oneSub.getSelector() == SubstringFilter_substrings_Seq.FINAL__SELECTED) {
if (subfilter.length() == 0) {
subfilter.append("%");
}
subfilter.append(new String(oneSub.getFinal_().toByteArray(), "UTF-8"));
}
}
return type + " LIKE " + subfilter.toString();

case Filter.AND_SELECTED : // &((attrib=val)(attrib2=val2))
Filter_and andFilter = currentFilter.getAnd();

infix = "";
for (Iterator andEnum = andFilter.iterator();andEnum.hasNext();) {
Filter aFilter = (Filter) andEnum.next();
infix += "(" + filterToSQL(aFilter) + ") AND ";
}

infix = infix.substring(0,infix.lastIndexOf("AND")) + " ";
return infix;

case Filter.OR_SELECTED : // &((attrib=val)(attrib2=val2))
Filter_or orFilter = currentFilter.getOr();
infix = "";
for (Iterator orEnum = orFilter.iterator();orEnum.hasNext();)   {
Filter aFilter = (Filter) orEnum.next();
infix += " ( " + filterToSQL(aFilter) + " ) OR ";
}
infix = infix.substring(0,infix.lastIndexOf("OR")) + " ";
return infix;
case Filter.NOT_SELECTED : // !(&((attrib=val)(attrib2=val2)))
return " NOT (" + filterToSQL(currentFilter.getNot()) +    ") ";

case Filter.APPROXMATCH_SELECTED : // (attrib~=val)
filterVal = getString(currentFilter.getApproxMatch());
return filterVal[0] + " LIKE " + filterVal[1];

case Filter.EXTENSIBLEMATCH_SELECTED : //not standard
return ""; //not supported
}

//will never reach
return "";
}

/**
*Converts an AttributeValueAssertion to a two element array with the
*first being the attribute name and the second being the value
*/
public static String[] getString(AttributeValueAssertion ava) {
String matchAttr = new String(ava.getAttributeDesc().toByteArray());
String matchVal = new
String(ava.getAssertionValue().toByteArray(),"UTF8");

return new String[] {matchAttr,matchVal};
}
}

18.3.6 クラスの概要

この項では、使用可能なOracle Virtual Directoryのクラスの高度な概要について説明します。Oracle Virtual Directoryのクラスの詳細は、Oracle Virtual Directory Javadocを参照してください。この項の内容は次のとおりです。

- 仮想サービス・インタフェース

- グローバル・サービス・インタフェース

- アダプタ・サービス・インタフェース

- ジョイナ

- ユーティリティ・クラス

- データ・クラス

- データ型

- 例外

18.3.6.1 仮想サービス・インタフェース

仮想サービス・インタフェース(VSI)には、LDAPと同じようにOracle Virtual Directoryをコールするメソッドが用意されています。VSIは、コンテキストがグローバル・プラグインであるかアダプタ・レベルのプラグインであるかにかかわらず、同様に機能します。

チェーン内に3つのプラグインがあり、そのチェーンの1つ目のプラグインがVSIへのコールを実行する場合、2つ目および3つ目のプラグインにも出現するように、コールのコンテキストはOracle Virtual Directoryです。コールが2つ目のプラグインから実行された場合、コールは3つ目のプラグインのみを経由します。コールが3つ目のプラグインから実行された場合、プラグインがグローバルであるかローカルであるかにかかわらず、そのコールはどのプラグインも経由しません。プラグインがグローバルの場合、コールはOracle Virtual Directoryのルーティング・システムを経由してアダプタ・レベルのチェーンまで、グローバル・チェーンの外でも続行されます(ルーターによって1つ以上のアダプタが選択されているかどうかによります)。これにより、Oracle Virtual Directoryへのコールの一貫性が保証されるだけでなく、プラグインが自身をコールする無限ループからも保護されます。VSIは、各プラグイン・メソッドに渡されるチェーン・オブジェクトを使用して取得されます。

18.3.6.2 グローバル・サービス・インタフェース

グローバル・サービス・インタフェース(GSI)には、Oracle Virtual Directoryに対して、エンド・クライアントから実行されているようなLDAPに似たコールを行うメソッドが用意されています。各コールはアクセス制御システム(有効な場合)を介して処理され、ルーターによって操作に適切なアダプタを選択することが可能になります。GSIは、LDAPリスナーやWebゲートウェイが通信に使用するのと同じインタフェースです。

GSIは、chain.getVSI().getGSI()を呼び出すことでVSIを使用して取得できます。このハンドルを使用すると、add、bind、delete、get、getByDN、modifyおよびrenameメソッドを呼び出せます。

警告:
GSIでは、現在のプラグインの前にあるコンテキストをコールすると、プラグインが無限ループに捕捉される場合があります。これにより、プラグイン・コードが繰り返しコールされ、予期しない結果を招く原因になる可能性があります。意図的に発生させる場合を除き、プラグインがスタックを遡ってコールし、ループが発生する可能性のあるシナリオには注意してください。一般的に、特定のアダプタをコールする必要がある場合を除き、VSIを使用するのが最も安全です。
Oracle Virtual Directoryには、ループ検出メカニズムは用意されていません。スタックのオーバーフローまたはメモリー不足が原因によるOracle Virtual Directoryとカスタム・プラグインとのクラッシュが検出された場合、これが原因である可能性が高いです。

18.3.6.3 アダプタ・サービス・インタフェース

アダプタ・サービス・インタフェース(ASI)には、ルーター・レベルにおいて、または特定のアダプタに対して直接、LDAPと同じようにOracle Virtual Directoryをコールするメソッドが用意されています。Oracle Virtual Directoryの結合ビュー・アダプタおよびそのジョイナでは、検索および結合の対象であるアダプタとの通信にASIが使用されます。ASIインタフェースは、プラグイン・クラスの検索情報を提供するために構成された場合など、内部アダプタから情報を取得する際に便利です。

ASIは、chain.getVSI().getASI()を呼び出すことでVSI経由で取得されます。このハンドルを使用すると、add、bind、delete、get、getByDN、modifyおよびrenameメソッドを呼び出せます。各メソッドには、アダプタ名のパラメータを指定するものと指定しないものの2種類があります。アダプタ名が指定されているメソッドを使用して特定のアダプタを選択するか、その他の任意のメソッドを使用して、ルーターがルーティング・ロジックおよびルーティング構成に基づいて適切なアダプタを選択するようにします。

警告:
ASIでは、現在のプラグインの前にあるコンテキストをコールすると、プラグインが無限ループに捕捉される場合があります。これにより、プラグイン・コードが繰り返しコールされ、予期しない結果を招く原因になる可能性があります。意図的に発生させる場合を除き、プラグインがスタックを遡ってコールし、ループが発生する可能性のあるシナリオには注意してください。一般的に、特定のアダプタをコールする必要がある場合を除き、VSIを使用するのが最も安全です。
Oracle Virtual Directoryには、ループ検出メカニズムは用意されていません。スタックのオーバーフローまたはメモリー不足が原因によるOracle Virtual Directoryとカスタム・プラグインとのクラッシュが検出された場合、ループが原因である可能性が高いです。

VSI、GSIおよびASIのいずれも共通のインタフェースを共有しており、追加機能が用意されているインタフェースもあります。

次のリストでは、サポートされているASIメソッドを説明します。

- add()
LDAPの追加操作を実行します。このメソッドには2つのバージョンがあり、Oracle Virtual Directoryルーターによるターゲット・アダプタの選択、または特定のアダプタの選択が可能です。

- bind()
LDAPのバインド操作を実行します。Oracle Virtual Directoryルーターによるアダプタの選択、または特定のアダプタの適用が可能です。

- delete()
LDAPの削除操作を実行します。Oracle Virtual Directoryルーターによるアダプタの選択、または特定のアダプタの適用が可能です。

- get()
LDAPの取得操作を実行し、これにより、Oracle Virtual Directoryルーターが適切なアダプタを選択できます。このgetメソッドは、EntrySet値のjava.util.Vectorを戻します。EntrySetは、問合せが行われたアダプタごとに含まれます。

- getbyDN()
特定のDNを使用してLDAPベースの検索を実行する便利なメソッドです。コール元は、選択して特定のアダプタを指定するか、Oracle Virtual Directoryルーターによる選択を行います。

- modify()
LDAPの変更操作を実行します。コール元は、特定のアダプタを指定するか、ルーターによる自動選択を選択します。

- rename()
LDAPの名前変更操作を実行します。コール元は、特定の送信元および宛先アダプタを指定するか、ルーターによる自動選択を選択します。

18.3.6.4 ジョイナ

Oracle Virtual Directoryの結合ビュー・アダプタではジョイナを使用して、特定のアダプタからのエントリを結合し、プライマリ・アダプタのエントリとマージします。ジョイナは、新しいジョイナの実装に必要な基本的な操作やメソッドを定義する抽象クラスです。ジョイナは、結合済のエントリに対して操作を実行する必要がある場合に結合ビュー・アダプタによりコールされます。ジョイナは、LDAP操作前のデータ操作を可能にする事前アクション操作を定義します。また、コールされる操作に応じて、ジョイナによるターゲット結合アダプタ内のターゲット・エントリの選択を可能にするmapOperationTargetByEntryメソッドも定義します。

ジョイナは、プライマリ・アダプタおよびターゲット・アダプタとともにインスタンス化されます。結合ビュー・アダプタは常にプライマリ・アダプタのコンテキスト内で機能し、マッピングや操作をターゲット結合アダプタで実行する必要がある場合にジョイナ・メソッドを呼び出します。

結合ビュー・アダプタの取得操作により、プライマリ・アダプタの結果のみに基づいてJoinEntrySetが作成されます。続いてOracle Virtual DirectoryクライアントがOracle Virtual Directoryの結果をポーリングすると、JoinEntrySetクラスによりジョイナJoinByEntryメソッドが呼び出され、結合アダプタへのコールとエントリ結果のマージが行われます。複数の結合関係が構成されている場合、定義されているすべての関係に基づいてエントリが完全に結合されるまで、エントリ・セットの処理はすべての結合をループします。

ジョイナ・コンストラクタ・メソッドは、結合ビュー・アダプタによってジョイナがインスタンス化される際に呼び出されます。この状況は、最初のLDAP操作が(遅延構成という形で)結合ビュー・アダプタによって処理されるまで発生しません。コンストラクタは、関連するターゲット・アダプタ名とともに、構成ファイルのジョイナの構成パラメータに渡されます。

createJoinFilterメソッドは、一般的にはローカル・メソッドで、AdapterServiceInterfaceへの後続のコール用に検索フィルタを作成するためにJoinByEntryメソッドによって呼び出されます。

18.3.6.5 ユーティリティ・クラス

Oracle Virtual Directoryでは、次のユーティリティ・クラスがサポートされます。

- PluginUtils
このクラスは、renameAttribute、copyAttributeなどを含むマッピング機能の基本的なツールボックスです。通常、これらのクラスは、マッピング・スクリプトで使用されますが、Javaプラグインでも使用できます。

- FilterTools
このクラスには、LDAP検索フィルタを作成および操作するためのメソッドがあります。

- ParseFilter
ParseFilterクラスには、文字列とフィルタを相互に変換する機能があります。

- DNUtility
このクラスには、個々のDN名コンポーネントの操作を可能にするDNの展開や作成など、DN操作ルーチンが用意されています。

- LDAPResult
LDAPResultは、Int8値を戻す任意のメソッドから戻される結果の比較に使用できるユーティリティ・クラスです。これらの定数は、結果コードのLDAPエラー・コードへの変換に便利です。

- VDELogger
Loggerクラスには、Oracle Virtual Directoryロギング・ファシリティ(Log4J)へのインタフェースがあります。このクラスを使用して、コンソールまたは監査メッセージをOracle Virtual Directoryのメッセージと統合します。

- PasswordEncryptor
このクラスには、文字列値をCrypt、SHA、SSHAなどの様々なハッシュ形式に暗号化する多様なメソッドがあります。

18.3.6.6 データ・クラス

Oracle Virtual Directoryでは、次のユーティリティ・クラスがサポートされます。

- Attribute
Attributeは、Entryクラスとともに使用される基本的なオブジェクトです。Attributeでは(属性名などの)タイプが定義され、その値が含まれます。また、クローニングおよび等価テスト用のメソッドが用意されています。

- Credentials
セッションの資格証明を保持する基本的なオブジェクト。このオブジェクトには、IPアドレス、binddnおよびパスワード(必要な場合)が含まれます。通常、AdapterServiceInterfaceに関連する多くの操作では、関連するのはbinddnのみです。

- Entry
このオブジェクトは、LDAPエントリおよびLDAPの変更リクエストなどの部分エントリの保持に使用されます。多くの場合、FilterToolユーティリティをこれらのオブジェクトと組み合せてフィルタをテストします。

- EntryChange
このオブジェクトには、LDAP変更項目が含まれます。変更リクエストを処理する際には、通常、EntryChangeオブジェクトのVectorがAdapterServiceInterfaceに渡されます。各EntryChangeには、単一エントリへの単一の変更が含まれます。

- EntrySet
EntrySetには、アダプタからの一連の問合せ結果が含まれます。メソッドが最初にEntrySetを受け取る際には、エントリの結果セットがメモリーに存在しない場合があります。getNextメソッドを呼び出すことで、EntrySetから一意のEntryオブジェクトが戻されます。getNextが呼び出されるたびに、関連するアダプタまたはプラグイン・クラス・コードが呼び出され、存在する場合には次のEntryが取得されます。他のエントリの可用性をテストするには、hasMore()メソッドを使用します。

ヒント:
結果セット全体を処理する場合以外は、getNext()を直接呼び出さないようにしてください。LDAPクライアントから呼出しを実行することをお薦めします。Oracle Virtual Directoryプラグイン・クラスの場合には、特別なメソッドpostSearchEntry()が用意されており、クライアントに戻される際に各エントリを変更できます。アダプタから到着するたびにエントリを処理するのではなく、Oracle Virtual Directoryで結果セット全体を一度にロードするなど、不必要にgetNext()を呼び出すと、メモリーの過剰な使用およびパフォーマンス低下の原因になる可能性があります。

- Filter
Filterオブジェクトは、標準のLDAPフィルタを表します。このオブジェクトには、LDAPフィルタの設定、テストおよび比較に便利なメソッドがあります。Filterオブジェクトには、その他のフィルタ・オブジェクトの階層(Filter_and、Filter_orなど)が含まれる場合もあります。

- LDAPURL
このクラスには、標準のLDAPURLを解析または作成するためのメソッドがあります。

18.3.6.7 データ型

Oracle Virtual Directoryでは次のデータ型をサポートしています。

- BinarySyntax
パスワードまたはユーザー証明書などの任意のバイナリ値。

- DirectoryString
大/小文字が区別されない文字列。

- IASString
大/小文字が区別される文字列。

- IntegerSyntax
整数値。

- DistinguishedName
識別名の値(比較はDN等価ルールに準拠します)。

18.3.6.8 例外

Oracle Virtual Directoryでは、次の例外がサポートされます。

- DirectoryBindException
バインドに失敗した場合にスローされる例外。

- DirectoryException
すべてのディレクトリ・エラー時にスローされる一般的な例外。詳細はgetMessage()を参照してください。LDAPエラー・コードを確認する場合はgetLDAPErrorCode()を参照してください。この例外は、アダプタまたは別のプラグインによって生成されることがあります。

- DirectorySchemaViolation
リモート・スキーマまたはローカル・スキーマに違反するエントリの追加や変更が試行されると、スキーマ違反が発生します。

- InvalidDNException
InvalidDNExceptionは、無効なDNがパラメータとして渡されるとオブジェクトおよびユーティリティによってスローされます。

18.4 Oracle Virtual DirectoryへのWebサービス・クライアントの接続

Oracle Virtual Directoryが最初にリリースされたときは、LDAPがアイデンティティ・プロファイル情報にアクセスするための主要なプロトコルでした。LDAPは、認証および認可については依然として主要なプロトコルですが、新しいアプリケーションは、多くの場合、SOAPまたはREST標準に基づいたWebサービスを使用して構築されます。Oracle Virtual Directoryは、デフォルトでこれらの要件を満たすメカニズムを提供します。

RESTベースのクライアント(簡単に言えば、HTTP POSTを送信してデータを取得するクライアント・アプリケーション)は、Oracle Virtual DirectoryのWebゲートウェイによって処理されます(付録C「HTTPリスナーのWebゲートウェイ・サービス」を参照)。

かわりに、Oracle Virtual DirectoryのDSMLv2サービスを使用できます。これは、オラクル社によるDSMLv2標準の実装です。DSMLは、最初はLDAPデータのXML表現(基本的にASCIIベースのLDIFの代替)を提供するために作成されました。DSMLv2によってSOAPベースのWebサービスが追加されました。

このSOAPベースのWebサービスは、HTTPリスナーでDSMLv2サービスを有効にするとOracle Virtual Directoryで使用可能になります。URLは次のとおりです。

http://ovdserver:httpport/services/dsmlv2/service

DSMLはOASIS標準化団体によって定義済の標準であり、SOAPベースのサービスですが、残念ながら公式のWSDLファイルは作成されたことがありません。WSDLファイルは、SOAPベースのWebサービスで使用されるドキュメントであり、それらのサービスをクライアント・アプリケーションに説明し、アプリケーションでどのメソッドをコールするかを判断できるようにするものです。

ただし、サード・パーティによってWSDLファイルが開発されており、次のサイトから入手できます。

http://www.users.globalnet.co.uk/~jonbek/EASBlogLinks/dsmlQuery_v3.wsdl

認証の概要

Oracle Virtual DirectoryのDSMLv2サービスでは、ACL、ルーティング・ルールなどのOracle Virtual Directoryのセキュリティ・セマンティクスのすべてが適用されます。

アプリケーションは、HTTP Basic認証を使用してDSMLv2サービスを認証します。HTTP Basic認証では、Oracle Virtual DirectoryのWebゲートウェイで使用される.htaccessファイルは使用されません。

資格証明をDSMLv2サービスに送信するには、SOAPクライアントは次の値を含むHTTP認証ヘッダーを送信する必要があります。

base64-encoded-dn:base64-encoded-password

たとえば、ユーザーがcn=orcladminであり、パスワードがwelcome1である場合、資格証明は次のようになります。

Y249b3JjbGFkbWlu:d2VsY29tZTE=

この文字列も、Base64でエンコードされている必要があり、完全なヘッダーは次のようになります。

Authorization: Basic WTI0OWIzSmpiR0ZrYldsdTpkMlZzWTI5dFpURT0=

有効なDNまたは資格証明を指定するかぎり、LDAPクライアントを経由してOracle Virtual DirectoryにアクセスしているかのようにOracle Virtual Directoryのセキュリティが使用されます。

19 統合ディレクトリ・ソリューションに対するOracle Virtual Directoryの構成

この章では、一般的に使用されているディレクトリ・テクノロジおよびID管理テクノロジと統合するためのOracle Virtual Directoryの構成方法について説明します。この章の内容は次のとおりです。

- 第19.1項「Oracle Access Managerに対するOracle Virtual Directoryの構成」

- 第19.2項「Oracleのエンタープライズ・ユーザー・セキュリティとの統合」

- 第19.3項「Oracleのネット・サービスとの統合」

- 第19.4項「OracleのReal Application Securityとの統合」

注意:
Oracle Virtual Directoryは、ほとんどのLDAP対応テクノロジとともに使用できます。この章では、一般的な統合を簡略化するOracle Virtual Directoryの機能を中心に説明します。
その他のOracle Virtual Directoryの統合に関しては、Oracleサポートに連絡してください。

19.1 Oracle Access Managerに対するOracle Virtual Directoryの構成

Oracle Directory Services Managerの「クイック・コンフィギュレーション・ウィザード: Oracle Access Managerの設定」を使用して、Oracle Access Manager(OAM)と統合するためにOracle Virtual Directoryを構成するには、次の手順を実行します。「クイック・コンフィギュレーション・ウィザード: Oracle Access Managerの設定」は、必要なローカル・ストア・アダプタや、Oracle Access Managerが使用するデータ・リポジトリに適切なアダプタ・タイプ(LDAP、データベースまたはカスタム)を作成する手順を1つずつ説明します。

1. Oracle Directory Services Managerにログインします。

2. タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。

3. 拡張ツリーの「クイック構成ウィザード」エントリを開きます。

4. ツリーで、「Oracle Access Managerの設定」をクリックします。「Oracle Access Managerの設定」画面が表示されます。

5. 「ローカル・ストア・アダプタ(LSA)の作成に使用されるネームスペース」フィールドにローカル・ストア・アダプタのネームスペースをDN形式入力し、「適用」をクリックします。「アダプタ」画面が表示されます。

6. Oracle Access Managerが使用するデータ・リポジトリのアダプタを作成します。Oracle Access Managerが使用するデータ・リポジトリに適切な、次のいずれかの手順を実行します。
Oracle Access Manager用のLDAPアダプタを作成する手順:

1. 「OAM LDAPアダプタの作成」ボタンをクリックします。「OAM用のOVDを準備中 - LDAPアダプタの作成」ダイアログ・ボックスが表示されます。

2. 「アダプタ名」フィールドにLDAPアダプタの一意の名前を入力します。「アダプタ・テンプレート」リストからオプションを選択することで、LDAPアダプタに適したテンプレートを選択します。Microsoft Active DirectoryまたはOracle Directory Server Enterprise Edition (旧称はSun Java System Directory Server)と統合している場合以外は「デフォルト」を選択します。詳細は、「アダプタ・テンプレートの概要」を参照してください。「次」をクリックします。「OAM用のOVDを準備中 - LDAPアダプタの作成」ダイアログ・ボックスの「接続」画面が表示されます。

3. OAM用にLDAPアダプタを構成するには、「LDAPアダプタの作成」の手順5から16を実行します。

4. 設定の概要を確認し、「終了」をクリックしてOAM用のLDAPアダプタを作成します。「Oracle Access Managerの設定」画面のアダプタのリストに、OAM用の新しいLDAPアダプタが表示されます。

Oracle Access Manager用のデータベース・アダプタを作成する手順:

1. 「OAMデータベース・アダプタの作成」ボタンをクリックします。「OAM用のOVDを準備中 - データベース・アダプタの作成」ダイアログ・ボックスが表示されます。

2. 「アダプタ名」フィールドにデータベース・アダプタの一意の名前を入力します。「アダプタ・テンプレート」リストからオプションを選択することで、データベース・アダプタに適したテンプレートを選択します。詳細は、「アダプタ・テンプレートの概要」を参照してください。「次」をクリックします。「OAM用のOVDを準備中 - データベース・アダプタの作成」ダイアログ・ボックスの「接続」画面が表示されます。

3. OAM用にデータベース・アダプタを構成するには、「データベース・アダプタの作成」の手順5から10を実行します。

4. 設定の概要を確認し、「終了」をクリックしてOAM用のデータベース・アダプタを作成します。「Oracle Access Managerの設定」画面のアダプタのリストに、OAM用の新しいデータベース・アダプタが表示されます。

Oracle Access Manager用のカスタム・アダプタを作成する手順:

1. 「OAMカスタム・アダプタの作成」ボタンをクリックします。「OAM用のOVDを準備中 - カスタム・アダプタの作成」ダイアログ・ボックスが表示されます。

2. 「アダプタ名」フィールドにカスタム・アダプタの一意の名前を入力します。

3. 「アダプタ接尾辞/ネームスペース」フィールドに有効なベースDNを入力します。

4. 「OAM用のOVDを準備中 - カスタム・アダプタの作成」ダイアログ・ボックスで、「次へ」をクリックします。プラグインの構成画面が表示されます。

5. 「名前」フィールドにプラグインの名前を入力します。

6. 「クラス」フィールドにプラグインのクラス名を入力するか、「参照」をクリックし、「プラグインの選択」ボックスからプラグインを選択して「OK」をクリックします。

7. 「パラメータ」表の「作成」ボタンをクリックして「名前」リストからパラメータを選択し、「値」フィールドにパラメータの値を入力して、プラグインにパラメータと値を追加します。

8. プラグインの構成画面の「次へ」をクリックします。

9. 設定の概要を確認し、「終了」をクリックしてOAM用のカスタム・アダプタを作成します。「Oracle Access Managerの設定」画面のアダプタのリストに、OAM用の新しいカスタム・アダプタが表示されます。

7. Oracle Directory Services Managerのタスク選択バーから「アダプタ」を選択し、「アダプタ」ツリーで構成するアダプタの名前をクリックすることで、Oracle Access Managerが使用するデータ・リポジトリのアダプタを構成します。

関連項目:
各タイプのアダプタを構成する方法の詳細は、次の項を参照してください。

- LDAPアダプタの構成

- データベース・アダプタの構成

- カスタム・アダプタの構成

19.1.1 Oracle Access Managerのアダプタ設定の変更

Oracle Access Managerの統合アダプタの設定を変更するには、次のようにします。

1. Oracle Directory Services Managerにログインし、Oracle Directory Services Managerのタスク選択バーから「アダプタ」タブを選択します。

2. 「アダプタ」ツリーで、変更するアダプタの名前を選択します。

3. 「アダプタ」タブのアダプタ設定を必要に応じて変更します。アダプタ設定の詳細は、第12章「Oracle Virtual Directoryのアダプタの作成および構成」を参照してください。

4. 変更を適用するには、「適用」をクリックします。

19.2 Oracleのエンタープライズ・ユーザー・セキュリティとの統合

Oracle Virtual Directoryをエンタープライズ・ユーザー・セキュリティ(EUS)と統合すると、外部LDAPリポジトリに格納されたユーザーIDを活用することによって、認証機能や認可機能が強化および簡略化され、追加の同期も必要ありません。

この項では、Oracle Virtual DirectoryとOracleのエンタープライズ・ユーザー・セキュリティとの統合方法について説明します。この項の内容は次のとおりです。

- エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備

- エンタープライズ・ユーザー・セキュリティのアダプタの構成

- 外部ディレクトリとOracle Virtual Directoryとの統合

- エンタープライズ・ユーザー・セキュリティとの統合のためのアクセス制御リストの構成

- 複数のエンタープライズ・ユーザー・セキュリティ・ドメインをサポートするためのOracle Virtual Directoryの構成

- ユーザー・アカウントのロックアウトの有効化

- 統合の制限事項

注意:
アップグレード環境では、次のようになります。
Oracle Virtual Directoryのエンタープライズ・ユーザー・セキュリティの統合手順は、11.1.1.6.0リリースで変更されました。

11.1.1.6.0にアップグレードする前にデプロイメントにEUSをすでに構成してある場合、EUSの構成には以前の手順を引き続き使用する必要があります。この手順を確認するには、前にリリースされたバージョンの『Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド』のOracleのエンタープライズ・ユーザー・セキュリティとの統合に関する項を参照してください。

11.1.1.6.0にアップグレードした後は、すべての新しい構成についてこの項で説明する統合手順を使用する必要があります。

19.2.1 エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備

ユーザーIDを格納している外部ディレクトリに関係なく、まずこの項の手順を実行する必要があります。この項の手順を実行したら、「外部ディレクトリとOracle Virtual Directoryとの統合」を参照して統合を続行します。

エンタープライズ・ユーザー・セキュリティと統合するためにOracle Virtual Directoryを準備するには、次の手順を実行します。

1. ORACLE_HOME/ovd/eus/ディレクトリのバックアップ・コピーを作成します。エンタープライズ・ユーザー・セキュリティ統合で必要な構成ファイルはすべてeusディレクトリにあります。eusディレクトリのバックアップコピーを作成すると、使用する環境に基づいているオリジナルのeusディレクトリにあるファイルをテンプレートとして編集しつつ、オリジナル・ファイルのコピーを保持しておくことができます。

2. 存在しない場合は、第11章「Oracle Virtual Directoryリスナーの作成および管理」を参照して、SSL認証なしモードで保護されたLDAPリスナーを作成します。

3. Oracle Directory Services Managerを使用する場合、Oracle Directory Services ManagerおよびOracle Virtual Directoryサーバーが同じJDKメジャー・バージョンを使用していること、または、Oracle Virtual DirectoryがOracle Directory Services Managerよりも上位のJavaバージョンを使用していることを確認する必要があります。

重要:
Oracle Virtual Directoryをエンタープライズ・ユーザー・セキュリティと統合するためのこの先の手順は、ユーザーIDを格納している外部ディレクトリにより異なります。
「外部ディレクトリとOracle Virtual Directoryとの統合」を参照して、エンタープライズ・ユーザー・セキュリティとの統合を続行します。

19.2.2 エンタープライズ・ユーザー・セキュリティのアダプタの構成

EUS用にLDAPおよびローカル・ストア・アダプタを構成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. 「アダプタ」タブを選択します。

3. 「エンタープライズ・ユーザー・セキュリティ(EUS)のアダプタを構成します。」アイコンをクリックします。
ウィザードが表示され、デフォルトのdc=eusovd,dc=com Realm DNが表示されます。

注意:
このデフォルトのレルムDNは必要に応じて変更できますが、デフォルトを使用することをお薦めします。dc=eusovd,dc=comを選択した場合、NetCA、DBCA、ESM、EMなどのRDBMSツールはdc=eusovd,dc=comをレルムDNとして認識します。

4. 「次」をクリックし、「ユーザーおよびグループの場所」ページに移動します。

5. 次のオプションのいずれかを選択することで、ユーザーおよびグループのエントリの場所を指定します。

- 異なるディレクトリ: 異なるバックエンド・ディレクトリからのエントリを使用します。
このオプションを選択すると、入力に基づいてOracle Virtual Directoryが複数のLDAPアダプタを作成します。ポップアップが表示されたら、適切な「次のエントリを含む」ボタンをクリックし、「OK」をクリックすることでLDAPアダプタにユーザー・エントリとグループ・エントリのいずれが含まれるのかを示し、新しいLDAPアダプタを作成します。

- 同じ親 (デフォルト): バックエンド・ディレクトリの同じ親コンテナの下にあるエントリを使用します。
たとえば、バックエンド・ディレクトリのユーザーとグループがou=People,dc=example,dc=comおよびou=Groups,dc=example,dc=comの下にある場合、構成でバックエンド・ディレクトリの共通の親コンテナdc=example,dc=comを使用できます。

- 異なる親: バックエンド・ディレクトリの異なる親コンテナからのエントリを使用します。
このオプションを選択した場合、Oracle Virtual Directoryによって2つのLDAPアダプタ(1つはユーザー用、1つはグループ用)が作成されます。デフォルトでは、ユーザーの「マップされたネームスペース」はcn=Users,dc=eusovd,dc=comであり、グループの「マップされたネームスペース」はcn=Groups,dc=eusovd,dc=comです。これらの値は必要に応じて変更できます。

6. 「次」をクリックし、「LDAPアダプタ」ページに移動し、アダプタについて次の情報を入力します。

注意:
これらのパラメータを使用できるかどうかは、「ユーザーおよびグループの場所」での選択によって異なります。これらのパラメータの詳細は、「LDAPアダプタの作成」を参照してください。

アダプタ名(必須)

新しいアダプタの一意の名前を入力します。その他の構成フィールドでは、この名前を使用してこのアダプタが参照されます。

アダプタ・テンプレート(必須)

メニューからEUSテンプレートを選択します。たとえば、Oracle Virtual Directoryを、Active Directoryに格納されているユーザーID用のEUSと統合するには、EUS ActiveDirectoryを選択します。

LDAPサーバー表

表から既存のホストを選択するか、「ホストの追加」をクリックして新しいホストを追加します。
新しいホストの場合、ホストIPアドレス、ポート番号、および重みの値を指定する必要があります。読取り専用サーバーが必要な場合は、「読取り専用」ボックスを有効にします。

プロキシDN

プロキシDNを入力します。アダプタは、このDNを使用してディレクトリにバインドします。

プロキシ・パスワード

プロキシ・パスワードに変更します。

SSL/TLSの使用

このオプションはデフォルトで有効化されています。

SSL認証モード

メニューを使用して、「サーバー認証のみ/相互認証」または「認証なし」を指定します。

ユーザー・アカウントのロックアウトの有効化

ユーザー・アカウントのロックアウト機能を有効化するには、このオプションを選択します。
注意: Oracle Directory Server Enterprise EditionをバックエンドLDAPサーバーとして使用している場合、追加の「パスワード失敗の最大数」パラメータを入力する必要があります。

Oracle Directory Server Enterprise Editionに問合せをしてそのpasswordMaxFailure値を判別し、それをここに入力します。次に例を示します。

ORACLE_HOME/bin/ldapsearch -h Sun_Java_System_Directory_Server_Name \
-D bindDN -q -s base -b "cn=password policy,cn=config" objectclass="*" passwordmaxfailure

次のエントリを含む
(「異なるディレクトリ」オプションのみ)

ディレクトリにユーザーとグループのどちらのエントリが含まれるのかを指定します。

マップされたネームスペース(必須)

- 同じ親の下を選択する場合、ローカルにマップされているDNを指定する必要があります。たとえば、cn=UsersGroups,dc=eusovd,dc=comを指定します。

- 異なる親の下を選択する場合、2つのマップされたネームスペース(ユーザー用とグループ用にそれぞれ1つずつ)を指定する必要があります。

リモート・ベース(必須)

- 同じ親の下を選択する場合、すべての操作の開始点となるリモート・ベース・エントリ(DN)を指定する必要があります。

- 異なる親の下を選択する場合、2つのリモート・ベース(ユーザー用とグループ用にそれぞれ1つずつ)を指定する必要があります。

7. 「Next」をクリックして、「Summary」ページに移動します。

8. このページに表示されている情報を確認し、追加で変更する必要がなければ「終了」をクリックします。
Oracle Virtual Directoryによって次のアクションが実行されます。

- subSchemaSubentryプラグインとDynamic Groupsプラグインをグローバル・プラグインとして追加します。

- cn=OracleContext、cn=OracleSchemaVerison、およびレルムDNという接尾辞を持つ3つのローカル・ストア・アダプタを作成します。

- 選択したユーザー・エントリおよびグループ・エントリの場所に基づいて1つ以上のLDAPアダプタを作成します。

- 必要なエントリすべてをOracle Virtual Directoryにアップロードします。

- 必要なACLすべてをOracle Virtual Directoryに追加します。
各ACLの詳細は、「エンタープライズ・ユーザー・セキュリティとの統合のためのアクセス制御リストの構成」を参照してください。

9. Oracle Virtual Directoryサーバーに問合せを実行し、次のすべてのエントリがアップロードされていることを確認します。

注意:
この例では、5566がLDAPリスナー・ポートです。このポート番号は必要に応じて変更できます。

$ldapsearch -p 5566 -h ovd_host_name -D cn=orcladmin -q -s base -b
"cn=Common,cn=Products,cn=OracleContext,dc=eusovd,dc=com" "(objectclass=*)"
dn orclCommonUserSearchBase orclCommonGroupSearchBase
cn=Common,cn=Products,cn=OracleContext,dc=eusovd,dc=com
orclCommonGroupSearchBase=cn=UsersGroups,dc=eusovd,dc=com
orclCommonUserSearchBase=cn=UsersGroups,dc=eusovd,dc=com

注意:
この例では、レルムDNはdc=eusovd,dc=comであり、「同じ親」オプションが、ユーザー・エントリおよびグループ・エントリの場所に使用されると想定しています。
カスタム・レルムDNを使用した場合、それに応じて検索ベースも変更する必要があります。さらに、ユーザーおよびグループのエントリの場所に対して他のオプションを使用した場合、orclCommonUserSearchBaseおよびorclCommonGroupSearchBaseの値も異なる可能性があります。

19.2.3 外部ディレクトリとOracle Virtual Directoryとの統合

この項では、Oracle Virtual Directoryを、特定の外部ディレクトリと使用するためのエンタープライズ・ユーザー・セキュリティと統合する手順を説明します。これらの手順は、次の項に外部ディレクトリ・タイプに基づいて編成されています。

- Microsoft Active DirectoryのユーザーID

- Microsoft Active DirectoryのユーザーIDおよびOracle Internet Directoryのメタデータ

- Oracle Directory Server Enterprise EditionのユーザーID

- Novell eDirectoryのユーザーID

- Oracle Internet DirectoryのユーザーID

ユーザーIDを格納している外部ディレクトリを説明している項に進んでください。

注意:
バックエンドLDAPのスキーマ拡張はActive Directoryを除き、これらの外部ディレクトリのいずれも必要ありません。これらの変更は、現在はOracle Virtual Directoryのローカル・ストアで行われます。
orclCommonAttribute属性定義を加えるためには、単一で最小限のスキーマ変更がActive Directoryに必要です。

19.2.3.1 Microsoft Active DirectoryのユーザーID

Oracle Virtual Directoryを、Active Directoryに格納されているユーザーID用のエンタープライズ・ユーザー・セキュリティと統合するには、次の手順を実行します。

- Active Directoryの統合構成

- Oracle Virtual Directoryの統合構成

19.2.3.1.1 Active Directoryの統合構成

Active Directoryの統合を構成するには、次の手順を実行します。

注意:
統合にKerberos認証を使用している場合は、次の手順の手順3および4は実行しないでください。

1. Active Directoryイメージのバックアップ・コピーを作成します。Active Directory内部のスキーマ拡張機能は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

2. Oracle Virtual Directoryに組み込まれているJavaクラスを使用して、Active Directoryにエンタープライズ・ユーザー・セキュリティの必須スキーマであるextendADをロードするために、次のコマンドを実行します。
extendADファイルは、$ORACLE_HOME/ovd/eus/ディレクトリにあります。ORACLE_HOME/jdk/binディレクトリのjava実行可能ファイルを使用できます。

java extendAD -h Active_Directory_Host_Name -p Active_Directory_Port
-D Active_Directory_Admin_DN -w Active_Directory_Admin_Password
–AD Active_Directory_Domain_DN -commonattr

注意:
有効なActive DirectoryドメインDNは、たとえばdc=oracle,dc=comです。

3. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグイン、oidpwdcn.dllをインストールします。

1. $ORACLE_HOME/ovd/eus/oidpwdcn.dllファイルをActive Directory WINDOWS\system32ディレクトリにコピーします。

2. regedt32を使用してレジストリを編集し、oidpwdcn.dllを有効にします。コマンド・プロンプトでregedt32と入力して、regedt32を起動します。

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\レジストリにあるNotification Packagesエントリの末尾にoidpwdcnを追加します。次に例を示します。

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

4. 変更したら、Active Directoryシステムを再起動します。

4. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグインを検証します。

1. Active Directoryユーザーのパスワードを変更します。

2. パスワードを変更したユーザーをActive Directoryで検索します。orclCommonAttribute属性に、生成されたハッシュ・パスワード値が含まれることを確認します。
この値は、Active DirectoryにorclCommonAttribute属性定義を追加します。

3. すべてのActive Directoryユーザーのパスワードをリセットすることで、プラグインがパスワード変更を取得して、パスワード検証を生成および格納できるようにします。

5. Oracle Database Advanced SecurityとともにWindows 2000またはWindows 2003上でKerberos認証を使用している場合、『Oracle Database Advanced Security管理者ガイド』を参照してここでそれを構成する必要があります。
Kerberos認証を構成した後、次の手順に進む前に、Active Directoryユーザー資格証明を使用してデータベースにログインできることを確認します。

19.2.3.1.2 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合構成する手順は次のとおりです。

1. この手順に進む前に「エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行済であることを確認します。

2. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

3. 第19.2.2項「エンタープライズ・ユーザー・セキュリティのアダプタの構成」に示す手順を使用して、ローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- EUS_ActiveDirectoryテンプレートを選択します。

- 「SSL/TLSの使用」オプションが有効になっていることを確認します。

- 「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

これで、エンタープライズ・セキュリティとの統合、およびMicrosoft Active Directoryとの使用のためにOracle Virtual Directoryを構成する手順は完了です。『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』を参照して、統合プロセスを続行し、エンタープライズ・ユーザー・セキュリティを構成します。

19.2.3.2 Microsoft Active DirectoryのユーザーIDおよびOracle Internet Directoryのメタデータ

Active DirectoryにユーザーIDが格納されている場合にOracle Virtual Directoryをエンタープライズ・ユーザー・セキュリティと統合し、Oracle Internet Directoryにメタデータを格納するには、次の手順を実行します。

注意:

- この手順では、「エンタープライズ・ユーザー・セキュリティのアダプタの構成」で説明しているOracle Directory Services Managerのエンタープライズ・ユーザー・セキュリティ(EUS)のアダプタの構成ウィザードは使用しません。第12章「Oracle Virtual Directoryのアダプタの作成および構成」の説明に従って、Oracle Directory Services Managerのアダプタの作成手順を使用してアダプタを作成する必要があります。

- 統合にKerberos認証を使用している場合は、次の手順の手順6および7は実行しないでください。

1. ORACLE_HOME/ovd/eus/ディレクトリのバックアップ・コピーを作成します。エンタープライズ・ユーザー・セキュリティ統合で必要な構成ファイルはすべてeusディレクトリにあります。eusディレクトリのバックアップコピーを作成すると、使用する環境に基づいているオリジナルのeusディレクトリにあるファイルをテンプレートとして編集しつつ、オリジナル・ファイルのコピーを保持しておくことができます。

2. 存在しない場合は、第11章「Oracle Virtual Directoryリスナーの作成および管理」を参照して、SSLで保護されたLDAPリスナーを作成します。

3. SubschemaSubentryプラグインおよびDynamic Groupsプラグインをグローバル・サーバー・プラグインとして作成および追加します。サーバー・プラグインを作成する手順は、「グローバル・サーバー・プラグインの管理」を参照してください。

4. Active Directoryイメージのバックアップ・コピーを作成します。Active Directory内部のスキーマ拡張機能は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

5. 次のコマンドを実行することで、Oracle Virtual Directoryに組み込まれているJavaクラスを使用してActive Directoryに、エンタープライズ・ユーザー・セキュリティの必須スキーマをロードします。ORACLE_HOME/jdk/binディレクトリのjava実行可能ファイルを使用できます。

java extendAD -h Active_Directory_Host_Name -p Active_Directory_Port
-D Active_Directory_Admin_DN -w Active_Directory_Admin_Password
–AD Active_Directory_Domain_DN -commonattr

注意:
有効なActive DirectoryドメインDNは、たとえばdc=oracle,dc=comです。

6. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグイン、oidpwdcn.dllをインストールします。

1. oidpwdcn.dllファイルを見つけ、Active DirectoryのWINDOWS\system32ディレクトリにコピーします。

2. regedt32を使用してレジストリを編集し、oidpwdcn.dllを有効にします。コマンド・プロンプトでregedt32と入力して、regedt32を起動します。

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\レジストリにあるNotification Packagesエントリの末尾にoidpwdcnを追加します。次に例を示します。

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

4. 変更したら、Active Directoryシステムを再起動します。

7. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグインを検証します。

1. Active Directoryユーザーのパスワードを変更します。

2. パスワードを変更したユーザーをActive Directoryで検索します。orclCommonAttribute属性に、生成されたハッシュ・パスワード値が含まれることを確認します。
この値は、Active DirectoryにorclCommonAttribute属性定義を追加します。

3. すべてのActive Directoryユーザーのパスワードをリセットすることで、プラグインがパスワード変更を取得して、パスワード検証を生成および格納できるようにします。

8. Oracle Database Advanced SecurityとともにWindows 2000またはWindows 2003上でKerberos認証を使用している場合、『Oracle Database Advanced Security管理者ガイド』を参照してここでそれを構成する必要があります。
Kerberos認証を構成した後、次の手順に進む前に、Active Directoryユーザー資格証明を使用してデータベースにログインできることを確認します。

9. 次のコマンドを使用して、Oracle Internet Directory LDAP属性およびオブジェクト・クラスを拡張します。

ORACLE_HOME/bin/ldapmodify -h OID_Host_Name -p OID_Port -D bindDN \
-q -v -f OIDSchema.ldif

10. 次の設定を使用し、Oracle Internet Directoryのホスト情報を入力して、新しいLDAPアダプタを4つ作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。
最初の3つの新規LDAPアダプタでは、次の点に注意してください。

- Oracle_Internet_Directoryアダプタ・テンプレートを使用します。

- 1つ目のアダプタのリモート・ベースおよびマップされたネームスペースはcn=OracleContextであることが必要です。

- 2つ目のアダプタのリモート・ベースおよびマップされたネームスペースはcn=OracleSchemaVersionであることが必要です。

- 3つ目のアダプタのリモート・ベースおよびマップされたネームスペースはcn=subschemasubentryであることが必要です。

4つ目の新規LDAPアダプタでは、次の点に注意してください。

- EUS_OIDアダプタ・テンプレートを使用します。

- 4つ目のアダプタのリモート・ベースおよびマップされたネームスペースはcn=oraclecontext,your_OID_realmであることが必要です。

11. 次の設定を使用して、新規ローカル・ストア・アダプタを作成します。ローカル・ストア・アダプタの作成の詳細は、「ローカル・ストア・アダプタの作成」を参照してください。

- Local_Storage_Adapterテンプレートを使用します。

- Oracle Internet Directoryレルムがdc=example,dc=netの場合、「アダプタ接尾辞」をdc=netにする必要があります。それ以外の場合は、「アダプタ接尾辞」をdc=comにする必要があります。

12. dn、dc、o、orclsubscriberfullname、memberurl属性など、独自のネームスペースを使用するには、realmRoot.ldifを更新します。Active DirectoryとOracle Virtual Directoryの間にDNマッピングがある場合、Oracle Virtual Directoryから認識できるDNを使用します。

注意:
realmRoot.ldifファイルには、エンタープライズ・ユーザー・セキュリティが問合せを行うディレクトリ・ネームスペースにあるコア・エントリが含まれます。realmRoot.ldifファイルには、登録されたエンタープライズ・ユーザー・セキュリティ・データベースが含まれる動的グループも含まれ、機密性の高いエンタープライズ・ユーザー・セキュリティ関連の属性(ユーザーのエンタープライズ・ユーザー・セキュリティのハッシュ化されたパスワード属性など)への保護されたアクセスが可能になっています。

13. 次のコマンドを使用して、realmRoot.ldifファイルにあるドメイン・ルート情報をOracle Virtual Directoryにロードします。

ORACLE_HOME/bin/ldapmodify -h Oracle_Virtual_Directory_Host –p OVD_Port \
-D bindDN -q -v -a –f realmRoot.ldif

14. 次の設定を使用し、リモート・ベースを含むActive Directoryのホスト情報を入力して、Active Directoryにユーザー検索ベース用の新規LDAPアダプタを作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。

- アダプタにEUS_ActiveDirectoryテンプレートを使用します。

- 「SSL/TLSの使用」オプションを有効化します。

- 「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

- リモート・ベースに、cn=users,dc=adrealm,dc=comなど、Active Directoryのコンテナを入力します。

15. EUSActiveDirectory.pyマッピングがすでにデプロイされているかどうかをチェックします。

注意:
アダプタにマッピングをデプロイするには、2つの手順を実行する必要があります。

1. マッピングをコンパイルし、アダプタ・レベルでのアクティブ化を有効にするサーバー上で、グローバルにデプロイする必要があります。

2. 特定のアダプタにマッピングを構成する必要があります。

この手順では、EUSActiveDirectory.pyマッピングがすでにアダプタ・レベルでデプロイされているかどうかを確認しています。Oracle Directory Services Managerの「アダプタ」タブをオープンしてください。手順14で作成した新しいアダプタの名前を選択し、「プラグイン」タブを選び、マッピングが表に表示されていることを確認してください。

- 表にマッピングが表示されていたら、手順3へ進んでください。

- EUSActiveDirectory.pyマッピングが表にリストされていない場合は、まだデプロイされていません。Active Directoryユーザー検索ベース・アダプタにマッピングを作成するためには、「マッピングの作成」ボタンをクリックし、EUSActiveDirectory.pyを選択して一意のマッピング名を入力します。次に、「OK」をクリックして、「適用」をクリックします。

注意:
「Oracle Directory Services Manager」→「詳細」→「デプロイ済マッピング」を選択して、マッピングを最初にデプロイすることが必要な場合もあります。

16. cn=Common,cn=Products,cn=oraclecontext,<OIDレルム> の下にあるorclcommonusersearchbaseに、マップされたネームスペースを追加します。次のようなLDIFファイルを使用します。

dn: cn=Common,cn=Products,cn=oraclecontext,dc=oracle,dc=com
changetype: modify
add: orclcommonusersearchbase
orclcommonusersearchbase: cn=users,dc=adrealm,dc=com

17. 次のACLを作成します。ACL作成の詳細は、「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。Oracle Virtual Directoryインストール後にACLをカスタマイズした場合、カスタマイズの結果を有効にするには次のACL設定を調整する必要があります。

ターゲットDN

cn=subschemasubentry

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=subschemasubentry

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

authpassword

拒否

すべての操作

アクセス

public

注意:
次のACLは、dc=comのACLリスト内で最後のACLである必要があります。

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

authpassword

権限

検索と読取り

アクセス

cn=EUSDBGroup,<Your Mapped OID domain>のDNを持つグループ。

18. 次のように、OracleContextAdmins管理グループをサポートするようにOracle Virtual DirectoryのACLを設定します。

ターゲットDN

cn=OracleContext,<YOUR DOMAIN>

有効範囲

サブツリー

適用先

エントリ

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<YOUR DOMAIN>

ターゲットDN

cn=OracleContext,<YOUR DOMAIN>

有効範囲

サブツリー

適用先

すべての属性

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<YOUR DOMAIN>

19. Oracle Internet DirectoryのACLをcn=OracleContext,<YOUR DOMAIN>の下のデータを保護するように設定します。

19.2.3.3 Oracle Directory Server Enterprise EditionのユーザーID

この統合では、Oracle Directory Server Enterprise Editionを手動で構成する必要はありません。

19.2.3.3.1 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合用に構成するには、次の手順を実行します。

1. この手順に進む前に「エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行済であることを確認します。

2. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

3. 第19.2.2項「エンタープライズ・ユーザー・セキュリティのアダプタの構成」に示す手順を使用して、新しいローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- EUS_Sunテンプレートを選択します。

- SSL認証モードを「サーバー認証のみ/相互認証」に設定します。

- プロキシDNユーザーは、Oracle Directory Server Enterprise EditionでuserPassword属性を読み取ることができる必要があります。

これで、エンタープライズ・セキュリティと統合してOracle Directory Server Enterprise Editionとともに使用するためのOracle Virtual Directoryの構成手順は完了です。『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』を参照して、統合プロセスを続行し、エンタープライズ・ユーザー・セキュリティを構成します。

19.2.3.4 Novell eDirectoryのユーザーID

Oracle Virtual Directoryを、Novell eDirectoryに格納されているユーザーID用のエンタープライズ・ユーザー・セキュリティと統合するには、次の手順を実行します。

- Novell eDirectoryの統合構成

- Oracle Virtual Directoryの統合構成

19.2.3.4.1 Novell eDirectoryの統合構成

統合用にNovell eDirectoryを構成するには、eDirectoryのユニバーサル・パスワードを有効化し、管理者がユーザー・パスワードを取得できるようにします。詳細は、Novell eDirectoryのパスワード管理に関するドキュメントを参照してください。

19.2.3.4.2 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合用に構成するには、次の手順を実行します。

1. この手順に進む前に「エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行済であることを確認します。

2. Novell開発者コミュニティのWebサイトから、NMASツールキットをダウンロードします。

3. Oracle Directory Services Managerを使用してこのライブラリをOracle Virtual Directoryにアップロードします。詳細は、「Oracle Virtual Directoryサーバーへのライブラリのロード」を参照してください。
Oracle Virtual Directoryサーバーを再起動します。

4. Oracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

5. 「エンタープライズ・ユーザー・セキュリティのアダプタの構成」に示す手順を使用して、新しいローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- EUS_eDirectoryテンプレートを選択します。

- 「SSL/TLSの使用」オプションを有効化し、「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

これで、エンタープライズ・セキュリティとの統合のためにOracle Virtual Directoryを構成し、Novell eDirectoryとともに使用するための手順は完了です。『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』を参照して、統合プロセスを続行し、エンタープライズ・ユーザー・セキュリティを構成します。

19.2.3.5 Oracle Internet DirectoryのユーザーID

Oracle Virtual Directoryを、Oracle Internet Directoryに格納されているユーザーID用のエンタープライズ・ユーザー・セキュリティと統合するには、次の手順を実行します。

- Oracle Internet Directoryの統合構成

- Oracle Virtual Directoryの統合構成

19.2.3.5.1 Oracle Internet Directoryの統合構成

この統合では、Oracle Internet Directoryを手動で構成する必要はありません。

19.2.3.5.2 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合用に構成するには、次の手順を実行します。

1. この手順に進む前に「エンタープライズ・ユーザー・セキュリティとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行済であることを確認します。

2. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

3. 「エンタープライズ・ユーザー・セキュリティのアダプタの構成」に示す手順を使用して、新しいローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- EUS_OIDテンプレートを選択します。

これで、エンタープライズ・セキュリティ用にOracle Virtual Directoryを構成してOracle Internet Directoryとともに使用するための手順は完了です。『Oracle Databaseエンタープライズ・ユーザー管理者ガイド』を参照して、統合プロセスを続行し、エンタープライズ・ユーザー・セキュリティを構成します。

19.2.4 エンタープライズ・ユーザー・セキュリティとの統合のためのアクセス制御リストの構成

この項では、ユーザーIDの格納に使用している外部リポジトリに関係なく、エンタープライズ・ユーザー・セキュリティとの統合のためにOracle Virtual Directoryに構成する必要のあるアクセス制御リスト(ACL)について説明します。

注意:
これらのACLは、第19.2.2項「エンタープライズ・ユーザー・セキュリティのアダプタの構成」に示すようにEUS構成ウィザードを実行するときに、Oracle Virtual Directoryで自動的に構成されます。

ただし、Oracle Virtual Directoryインストール後にACLをカスタマイズした場合、カスタマイズの結果を有効にするには次のACL設定を調整する必要があります。エンタープライズ・ユーザー・セキュリティと統合するためにOracle Virtual DirectoryのACLを手動で構成するには、次の手順を実行します。

1. 次のACLを作成します。ACL作成の詳細は、「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

authpassword

拒否

すべての操作

アクセス

public

注意:
次のACLは、dc=comのACLリスト内で最後のACLである必要があります。

ターゲットDN

dc=com

有効範囲

サブツリー

適用先

authpassword

権限

検索と読取り

アクセス

cn=EUSDBGroup,dc=dbdemo,dc=orion,dc=comのDNを持つグループ
注意: dc=dbdemo,dc=orion,dc=com
をネームスペースのDNで上書きします。

2. 次のように、OracleContextAdmins管理グループをサポートするようにOracle Virtual DirectoryのACLを設定します。

ターゲットDN

cn=OracleContext,<YOUR DOMAIN>

有効範囲

サブツリー

適用先

エントリ

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<YOUR DOMAIN>

ターゲットDN

cn=OracleContext,<YOUR DOMAIN>

有効範囲

サブツリー

適用先

すべての属性

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<YOUR DOMAIN>

3. cn=OracleContextAdmins,cn=Groups,cn=OracleContext,<YOUR DOMAIN>グループに書込み権限を付与します。

19.2.5 複数のエンタープライズ・ユーザー・セキュリティ・ドメインをサポートするためのOracle Virtual Directoryの構成

複数のドメインに含まれるエンタープライズ・ユーザー・セキュリティのユーザーがデータベースに対して認証できるようにOracle Virtual Directoryを構成するには、次の手順を実行します。

1. 「エンタープライズ・ユーザー・セキュリティ(EUS)のアダプタを構成します。」アイコンをクリックし、その構成ウィザードのユーザーおよびグループの場所ページで「異なるディレクトリ」オプションを指定します。
詳細は、「エンタープライズ・ユーザー・セキュリティのアダプタの構成」を参照してください。

2. 追加のドメインをサポートするには、前述の手順を繰り返します。

注意:
これらの追加のドメインのいずれかからエンタープライズ・ユーザーとしてデータベースにログインするには、Enterprise Security ManagerまたはEnterprise Managerから追加のユーザー・コンテナのユーザーとスキーマのマッピングを作成する必要があります。
詳細は、『Oracle® Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

19.2.6 ユーザー・アカウントのロックアウトの有効化

バインドの試行が何度か失敗したら、LDAPサーバーによりユーザー・アカウントをロックできます。Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティの統合では、このロックアウト機能を使用し、次のようにして、バックエンドのLDAPサーバーのパスワード・ロックアウト・ポリシーを適用できます。

- Oracleデータベースへの不正なログインでは、バックエンドのLDAPサーバーにログインの失敗が記録されます。

- Oracleデータベースへの適切なログインにより、バックエンドのLDAPサーバーのログインの失敗数がリセットされます。

注意:
Active Directoryを使用する統合では、この機能はRDBMSバージョン10.2.0.5および11.2のみでサポートされています。

- ロックされたユーザー・アカウントを使用して、Oracleデータベースにログインすることはできません。

Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティとの統合を実行した後、「エンタープライズ・ユーザー・セキュリティのアダプタの構成」の説明に従ってエンタープライズ・ユーザー・セキュリティの構成手順を実行するときに「ユーザー・アカウント・ロックアウトの有効化」オプションを選択することで、ユーザー・アカウント・ロックアウトを有効化できます。

ユーザーIDがActive Directoryに、およびOracle Internet Directoryにメタデータが格納されている場合のアカウント・ロックアウトの有効化

ユーザーIDがActive Directoryに、およびOracle Internet Directoryにメタデータが格納されている場合にユーザー・アカウント・ロックアウト機能を有効化するためには、次の手順を実行する必要があります。

注意:
ユーザーIDがActive Directoryに格納されている場合のOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティの統合、およびOracle Internet Directoryへのメタデータの格納方法の詳細は、第19.2.3.2項「Microsoft Active DirectoryのユーザーIDおよびOracle Internet Directoryのメタデータ」を参照してください。

1. 「アダプタ・プラグインの管理」を参照して、エンタープライズ・ユーザー・セキュリティ統合のLDAPアダプタ用にeuslockoutプラグインを作成および構成します。euslockoutプラグインを構成するには、次の手順を実行する必要があります。

- Active Directoryに対するActiveDirectoryのような、バックエンドLDAPサーバーに応じた値を持つdirectoryTypeパラメータを作成します。

- ユーザー・コンテナの名前を使用して、ネームスペースを作成します。

2. 次のアクセス制御リストを作成します。ACL作成の詳細は、第16.1項「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。

ターゲットDN

Your_User_Container

有効範囲

サブツリー

適用先

orclaccountstatusevent

拒否

すべての操作

アクセス

public

ターゲットDN

Your_User_Container

有効範囲

サブツリー

適用先

orclaccountstatusevent

権限

書込み

アクセス

cn=EUSDBGroup,dc=dbdemo,dc=orion,dc=comのDNを持つグループ
注意: dc=dbdemo,dc=orion,dc=comをネームスペースのDNで上書きします。

19.2.7 統合の制限事項

次に、Oracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティの統合の既知の制限事項を示します。

- 統合では次の機能がサポートされません。

- ドメインDNを含むActive DirectoryのドメインがOracle Virtual Directoryにマップされている場合の、Microsoft Active DirectoryおよびOracle Virtual Directoryの間のDNマッピング。たとえば、Active DirectoryのDNがdc=us,dc=oracle,dc=comで、Oracle Virtual Directoryのdc=oracle,dc=comへのマップを試行している場合、このタイプのDNマッピングはサポートされません。

- OracleContextAdmins以外の管理グループ

- Oracle Internet Directory Delegated Administration ServiceへのEnterprise Security Managerコンソール

- パスワード・ポリシー

- クライアント証明書の認証

- Oracle Directory Server Enterprise EditionおよびOracle Internet Directoryとともに使用するために統合する場合のKerberos認証

- ユーザー移行ユーティリティ(UMU)

- 複数ドメイン環境

- JDBCシン・ドライバ - 必ずOCIドライバを使用

- Microsoft Active DirectoryとOracle Directory Server Enterprise Editionを組み合せた環境

- 適切なログイン後のアカウント・ロックアウト・カウンタのリセットは、Active Directoryを使用したOracle Virtual Directoryとエンタープライズ・ユーザー・セキュリティの統合では使用できません。かわりに、Active Directoryには、指定された期間が経過した後に、アカウント・ロックアウト・カウンタをリセットする機能があります。このオプションは、ロックアウト・カウンタが無制限に累積されるのを防ぐために使用できます。

- Enterprise Security Managerインタフェースでの制限

- リストされたデータベースにActive Directoryの廃棄エントリが含まれることがあります。

- データベースおよびOracle Internet Directoryのバージョン情報は利用できません。

19.3 Oracleのネット・サービスとの統合

この項では、Oracle Virtual DirectoryとOracle Database Net Servicesを統合し、Oracle Internet Directory、Microsoft Active DirectoryおよびOracle Directory Server Enterprise Editionのネーム・サービスを集中管理する方法を説明します。この項は、次の内容で構成されます。

- 概要

- 統合の開始

- Microsoft Active Directoryとともに使用するための統合

- Oracle Directory Server Enterprise Editionとともに使用するための統合

- Oracle Internet Directoryとともに使用するための統合

19.3.1 概要

Oracle Virtual Directoryは、OracleのNet Servicesデータベース製品と統合できます。Oracle Virtual Directoryをネット・サービスと統合すると、外部LDAPリポジトリに格納されたサービス・エントリを活用することによって、追加の同期を行わずに、ネーム・サービスが強化および簡略化されます。

19.3.2 統合の開始

この項では、Oracle Virtual Directoryとネット・サービスのすべての統合に必要な共通の手順をリストします。統合を開始するには、まずこの項の手順を実行し、Oracle Internet Directory、Microsoft Active DirectoryおよびOracle Directory Server Enterprise Editionに固有の後続のいずれかの項に進みます。Oracle Internet Directory、Microsoft Active Directory、Oracle Directory Server Enterprise Editionのいずれと使用するためにOracle Virtual DirectoryをNet Servicesと統合するかによって、説明されている手順が異なります。使用する環境に該当する手順のみを実行してください。

Oracle Virtual DirectoryとNet Servicesの統合プロセスを開始するには、次の手順を実行します。

1. ORACLE_HOME/ovd/eus/ディレクトリのバックアップ・コピーを作成します。

2. subschemasubentryプラグインをグローバル・サーバー・プラグインとして作成します。サーバー・プラグインを作成する手順は、「グローバル・サーバー・プラグインの管理」を参照してください。

19.3.3 Microsoft Active Directoryとともに使用するための統合

Microsoft Active Directoryとともに使用するためにOracle Virtual DirectoryをNet Servicesと統合するには、次の手順を実行します。この手順は、「統合の開始」の項の手順を完了してから実行してください。Microsoft Active Directoryとともに使用するためにOracle Virtual DirectoryをNet Servicesと統合する手順には、次のタスクが含まれます。

- Active Directoryの統合構成

- Oracle Virtual Directoryの統合構成

19.3.3.1 Active Directoryの統合構成

Active Directoryを統合用に構成するには、次の手順を実行します。

1. Active Directoryイメージのバックアップ・コピーを作成します。Active Directory内部のスキーマ拡張機能は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

2. 次のコマンドを実行することで、Oracle Virtual Directoryに組み込まれているJavaクラスを使用してActive Directoryに、Net Servicesの必須スキーマをロードします。ORACLE_HOME/jdk/binディレクトリにあるjava実行可能ファイルを使用できます。

java extendAD -h Active_Directory_Host_Name -p Active_Directory_Port
-D Active_Directory_Admin_DN -w Active_Directory_Admin_Password
–AD Active_Directory_Domain_DN

注意:
有効なActive DirectoryドメインDNは、たとえばdc=oracle,dc=comです。

19.3.3.2 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合用に構成するには、次の手順を実行します。

1. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

2. 次の設定を使用して、新規ローカル・ストア・アダプタを2つ作成します。ローカル・ストア・アダプタの作成の詳細は、「ローカル・ストア・アダプタの作成」を参照してください。

- 各アダプタにLocal_Storage_Adapterテンプレートを使用します。

- ローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleContextで、他のローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleSchemaVersionであることが必要です。

- 各アダプタの「データベース・ファイル」および「バックアップ・ファイル」フィールドは一意である必要があります。

3. 次のコマンドを実行し、loadOVD.ldifファイルを使用してOracle Virtual Directoryスキーマを拡張することで、ローカル・ストア・アダプタにエントリを更新してロードします。loadOVD.ldifファイルには、Net Servicesが問合せを行うOracleコンテキストおよびschemaversionに対応するエントリが含まれます。loadOVD.ldifファイルは、ORACLE_HOME/ovd/eus/ディレクトリにあります。

ORACLE_HOME/bin/ldapmodify -h Oracle_Virtual_Directory_Host –p OVD_Port \
-D bindDN -q -v -a -f loadOVD.ldif

4. 次の設定を使用し、ホスト名、SSL以外のポート番号、プロキシDNとパスワード、適切なリモート・ベースおよびマップされたネームスペースも含め、Active Directoryのホスト情報を入力して、Net Services用のLDAPアダプタを作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。

- ONames_ActiveDirectoryアダプタ・テンプレートを使用します。

- 「バインドのみ」の「パススルー資格証明」オプションを選択します。

5. 次の手順を実行して、アクセス制御リストを更新します。Oracle Virtual Directoryインストール後にACLをカスタマイズした場合、カスタマイズの結果を有効にするには次のACL設定を調整する必要があります。

1. 次のACLを作成します。ACL作成の詳細は、「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

2. 次のように、OracleNetAdmins管理グループをサポートするようにOracle Virtual DirectoryのACLを設定します。

ターゲットDN

cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

有効範囲

サブツリー

適用先

エントリ

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleNetAdmins,cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

ターゲットDN

cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

有効範囲

サブツリー

適用先

すべての属性

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleNetAdmins,cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

6. 次の設定を使用し、ポート番号、プロキシDNおよびパスワードも含め、Active Directoryのホスト情報を入力して、OracleNetAdmins管理グループ用のLDAPアダプタを作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。

- Active_Directoryアダプタ・テンプレートを使用します。

- リモート・ベースとしてcn=OracleNetAdmins,cn=users, <YOUR Active_Directory_Domain_DN>を入力します。

- マップされたネームスペースとしてcn=OracleNetAdmins,cn=OracleContext,<YOUR MAPPED DOMAIN DN in Oracle Virtual Directory>を入力します。

7. 次の手順を実行して、OracleNetAdmins管理グループ・アダプタのマッピングとプラグインを構成します。

1. 拡張タブ→「Active_Directory_to_inetOrg」→「適用」ボタンをクリックして、マッピングをデプロイします。

2. 「アダプタ」タブをクリックし、OracleNetAdmins管理グループ用のアダプタをクリックして、「プラグイン」タブをクリックします。次に、「マッピングの作成」ボタンをクリックして「Active_Directory_to_inetOrg.py」を選択し、一意のマッピング名を入力して「OK」をクリックします。

3. 「プラグインの作成」ボタンをクリックし、「選択」ボタンをクリックし、EUSMemberDNMappingプラグインを選択して、「OK」をクリックします。その後、一意のプラグイン名を入力し、localDomainDNおよびremoteDomainDNパラメータを作成し、「OK」をクリックします。DNマッピングを構成済である場合は、localDomainDNおよびremoteDomainDNが異なることがあります。

4. 「適用」ボタンをクリックします。

注意:
Active Directoryで変更した直後は、グループ・メンバーシップの変更が表示されない場合があります。これは、Active Directoryのグループ・メンバーシップのリフレッシュ間隔の構成によるものです。

これで、Net Servicesとの統合、およびMicrosoft Active Directoryとの使用のためにOracle Virtual Directoryを構成する手順は完了です。『Oracle Database Net Services管理者ガイド』を参照して、統合プロセスを続行し、Oracle Net Servicesを構成します。

19.3.4 Oracle Directory Server Enterprise Editionとともに使用するための統合

Oracle Directory Server Enterprise Editionとともに使用するためにOracle Virtual DirectoryをNet Servicesと統合するには、次の手順を実行します。この手順は、「統合の開始」の項の手順を完了してから実行してください。Oracle Directory Server Enterprise Editionとともに使用するためにOracle Virtual DirectoryをNet Servicesと統合する手順には、次のタスクが含まれます。

- Oracle Directory Server Enterprise Editionの統合構成

- Oracle Virtual Directoryの統合構成

19.3.4.1 Oracle Directory Server Enterprise Editionの統合構成

Oracle Directory Server Enterprise Editionを統合用に構成するには、次の手順を実行します。

1. 次のコマンドを使用して、iPlanet LDAP属性およびオブジェクト・クラスを拡張します。

ORACLE_HOME/bin/ldapmodify -h iPlanet_Host_Name -p iPlanet_Port \
-D cn="directory manager" -q -v -a -f ./iPlanetSchema.ldif

2. 次の手順を実行して、iPlanetにレルムを作成します。

1. realmiPlanet.ldifファイルを開き、文字列dc=us,dc=oracle,dc=comのすべてのインスタンスを、使用するドメイン名に置換します。

2. 次のコマンドを実行し、realmiPlanet.ldifファイルを使用してiPlanetにレルムを作成します。

ORACLE_HOME/bin/ldapmodify -h iPlanet_Host_Name -p iPlanet_Port \
-D cn="directory manager" -q -v -a -f ./realmiPlanet.ldif

3. 新しいユーザー・コンテナまたはグループ・コンテナを作成するか、既存のユーザー・コンテナまたはグループ・コンテナを使用して、ユーザー・コンテナとグループ・コンテナを構成します。
新しいユーザー・コンテナとグループ・コンテナの作成

1. iPlanetContainers.ldifファイルを開き、文字列dc=us,dc=oracle,dc=comのすべてのインスタンスを、使用するドメイン名に置換します。

2. 次のコマンドを実行し、iPlanetContainers.ldifファイルを使用してiPlanetにユーザーおよびグループのコンテナを作成します。

ORACLE_HOME/bin/ldapmodify -h iPlanet_Host_Name -p iPlanet_Port \
-D cn="directory manager" -q -v -a -f ./iPlanetContainers.ldif

既存のユーザー・コンテナとグループ・コンテナの使用

1. useiPlanetContainers.ldifファイルを開きます。

2. 文字列cn=users,dc=us,dc=oracle,dc=comのすべてのインスタンスを、使用するユーザー・コンテナの名前に置換します。

3. 文字列cn=groups,dc=us,dc=oracle,dc=comのすべてのインスタンスを、使用するグループ・コンテナの名前に置換します。

注意:
ユーザー・コンテナとグループ・コンテナが、作成しているものと同一のドメインとレルムにあることを確認します。たとえば、ドメインがdc=superdemo,dc=netの場合、ou=people,dc=ultrademo,dc=orgは有効なユーザー・コンテナではありません。

4. 次のコマンドを実行し、useiPlanetContainers.ldifファイルを使用してiPlanetにレルムを作成します。

ORACLE_HOME/bin/ldapmodify -h iPlanet_Host_Name -p iPlanet_Port \
-D cn="directory manager" -q -v -a -f ./useiPlanetContainers.ldif

19.3.4.2 Oracle Virtual Directoryの統合構成

Oracle Virtual Directoryを統合用に構成するには、次の手順を実行します。

1. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

2. 次の設定を使用して、新規ローカル・ストア・アダプタを2つ作成します。ローカル・ストア・アダプタの作成の詳細は、「ローカル・ストア・アダプタの作成」を参照してください。

- 各アダプタにLocal_Storage_Adapterテンプレートを使用します。

- ローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleContextで、他のローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleSchemaVersionであることが必要です。

- 各アダプタの「データベース・ファイル」および「バックアップ・ファイル」フィールドは一意である必要があります。

3. 次のコマンドを実行し、loadOVD.ldifファイルを使用してOracle Virtual Directoryスキーマを拡張することで、ローカル・ストア・アダプタにエントリを更新してロードします。loadOVD.ldifファイルには、Net Servicesが問合せを行うOracleコンテキストおよびschemaversionに対応するエントリが含まれます。loadOVD.ldifファイルは、ORACLE_HOME/ovd/eus/ディレクトリにあります。

ORACLE_HOME/bin/ldapmodify -h Oracle_Virtual_Directory_Host –p OVD_Port \
-D bindDN -q -v -a -f loadOVD.ldif

4. 次の設定を使用し、ホスト名、SSL以外のポート番号、プロキシDNとパスワード、適切なリモート・ベースおよびマップされたネームスペースも含め、Oracle Directory Server Enterprise Editionのホスト情報を入力して、Net Services用のLDAPアダプタを作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。

- ONames_Sunアダプタ・テンプレートを使用します。

- 「バインドのみ」の「パススルー資格証明」オプションを選択します。

5. 次の手順を実行して、アクセス制御リストを更新します。Oracle Virtual Directoryインストール後にACLをカスタマイズした場合、カスタマイズの結果を有効にするには次のACL設定を調整する必要があります。

1. 次のACLを作成します。ACL作成の詳細は、「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

2. 次のように、OracleNetAdmins管理グループをサポートするようにOracle Virtual DirectoryのACLを設定します。

ターゲットDN

cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

有効範囲

サブツリー

適用先

エントリ

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleNetAdmins,cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

ターゲットDN

cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

有効範囲

サブツリー

適用先

すべての属性

権限

すべて

アクセス

次のDNを持つグループ:
cn=OracleNetAdmins,cn=OracleContext,<マップされたOracle Virtual Directoryのネームスペース>

3. 外部ディレクトリのACLをcn=OracleContext,<YOUR DOMAIN>の下のデータを保護するように設定します。
OracleContextAdminsグループのみが、ドメイン固有のOracleContextサブツリーにアクセスおよび管理できるようにOracle Directory Server Enterprise Editionのアクセス制御項目(ACI)を作成する必要があります。

次のLDIFエントリは、OracleContextレルムに読取りおよび書込みアクセスを提供します。<YOUR DOMAIN>は、使用している具体的なドメインDNに置き換えてください。

dn:cn=OracleContext,<YOUR DOMAIN>
changetype:modify
add:aci
aci:(target = "ldap:///cn=OracleContext,<YOUR DOMAIN>")(targetattr =  "*")
(version 3.0; acl "Allow OracleContextAdmins Group read and write
access to all attributes"; allow (read, search, compare, add, write,
delete) (groupdn = "ldap:///cn=OracleContextAdmins,cn=Groups,
cn=OracleContext,<
YOUR DOMAIN>");)

注意:
ACIの詳細は、ディレクトリ固有のACLの管理ガイドを参照してください。

ACIが適切にロードされたことを確認するには、明示的にACI属性をリクエストするときにldapsearchを使用します。次に例を示します。

ldapsearch -h <sun host> -p <port> -D "<admin dn, ie cn=directory manager>"
-w <password> -s base -b "cn=OracleContext,dc=mydomain,dc=com" objectclass=*
aci

これで、Net Servicesと統合してOracle Directory Server Enterprise Editionとともに使用するためのOracle Virtual Directoryの構成手順は完了です。『Oracle Database Net Services管理者ガイド』を参照して、統合プロセスを続行し、Oracle Net Servicesを構成します。

19.3.5 Oracle Internet Directoryとともに使用するための統合

Oracle Internet Directoryとともに使用するためにOracle Virtual DirectoryをNet Servicesと統合するには、次の手順を実行します。この手順は、「統合の開始」の項の手順を完了してから実行してください。

1. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

2. 次の設定を使用して、新規ローカル・ストア・アダプタを2つ作成します。ローカル・ストア・アダプタの作成の詳細は、「ローカル・ストア・アダプタの作成」を参照してください。

- 各アダプタにLocal_Storage_Adapterテンプレートを使用します。

- ローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleContextで、他のローカル・ストア・アダプタの「アダプタ接尾辞」はcn=OracleSchemaVersionであることが必要です。

- 各アダプタの「データベース・ファイル」および「バックアップ・ファイル」フィールドは一意である必要があります。

3. 次のコマンドを実行し、loadOVD.ldifファイルを使用してOracle Virtual Directoryスキーマを拡張することで、ローカル・ストア・アダプタにエントリを更新してロードします。loadOVD.ldifファイルには、Net Servicesが問合せを行うOracleコンテキストおよびschemaversionに対応するエントリが含まれます。loadOVD.ldifファイルは、ORACLE_HOME/ovd/eus/ディレクトリにあります。

ORACLE_HOME/bin/ldapmodify -h Oracle_Virtual_Directory_Host –p OVD_Port \
-D bindDN -q -v -a -f loadOVD.ldif

4. ONames_OIDアダプタ・テンプレートを使用し、ホスト名、SSL以外のポート番号、プロキシDNとパスワード、適切なリモート・ベースおよびマップされたネームスペースも含め、Oracle Internet Directoryのホスト情報を入力して、Net Services用のLDAPアダプタを作成します。LDAPアダプタの作成の詳細は、「LDAPアダプタの作成」を参照してください。

5. 次の手順を実行して、アクセス制御リストを更新します。Oracle Virtual Directoryインストール後にACLをカスタマイズした場合、カスタマイズの結果を有効にするには次のACL設定を調整する必要があります。

1. 次のACLを作成します。ACL作成の詳細は、「Oracle Directory Services Managerを使用したアクセス制御リストの作成」を参照してください。

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleContext

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

cn=OracleSchemaVersion

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

エントリ

権限

DNの参照と戻し

アクセス

public

ターゲットDN

dc=example,dc=comなど、Oracle Virtual Directoryのマップされたネームスペース

有効範囲

サブツリー

適用先

すべての属性

権限

検索と読取り

アクセス

public

これで、Net Servicesとの統合、およびOracle Internet Directoryとの使用のためにOracle Virtual Directoryを構成する手順は完了です。『Oracle Database Net Services管理者ガイド』を参照して、統合プロセスを続行し、Oracle Net Servicesを構成します。

19.4 OracleのReal Application Securityとの統合

Oracle Virtual DirectoryとReal Application Security(RAS)の統合では、アプリケーション層とデータベース・インスタンスに及ぶ統合したインフラストラクチャを使用することで、Oracleアプリケーションに均一な認可サービスが提供されます。

RASのユーザー・セッションは、処理と格納にOracle RDBMSを使用するアプリケーションや中間層サーバーのセキュリティおよびパフォーマンスを向上させるように設計されています。RASセッションを使用すると、アプリケーションとそのユーザーに関連する状態を保持するデータベース・サーバー上のユーザー・セッションを、アプリケーションで作成できます。

RASはOracle Platform Security Services(OPSS)と統合されているため、RASセッションは外部で管理されているユーザーとロールをサポートします。また、アイデンティティ・ストアに存在する外部ユーザーとして、RASはRAS DBへのロギングを直接サポートします。この機能はエンタープライズ・ユーザー・セキュリティ(EUS)に似ています。

この項では、Oracle Virtual DirectoryとOracleのReal Application Security(RAS)との統合方法について説明します。この項の内容は次のとおりです。

- 作業の前に

- Real Application Securityとの統合のためのOracle Virtual Directoryの準備

- Real Application Security (RAS)のLDAPアダプタの構成

- RAS DBルートDN検出の有効化

- 外部ディレクトリとOracle Virtual Directoryとの統合

- Real Application Securityとの統合のためのアクセス制御リストの構成

- 複数のアイデンティティ・ストアをサポートするためにOracle Virtual Directoryを構成

- ユーザー・アカウントのロックアウトを使用した作業

19.4.1 作業の前に

どの外部ディレクトリをユーザーIDの格納に使用しているかにかかわらず、Real Application Securityとの統合用にOracle Virtual Directoryを準備するために次の手順を実行する必要があります。

- Active Directoryのバックエンド·ディレクトリを使用している場合は、バックエンドのLDAPスキーマをロードする必要があります。orclCommonAttribute属性定義を追加するという、1つの最小限のスキーマ変更がActive Directoryで必要です。この手順は、他のディレクトリ・タイプには必要ありません。

- 『Oracle Platform Security Servicesによるアプリケーションの保護』の「Java SEアプリケーションの認可」の章の手順に従って、Java SEアプリケーションの認可のためのOracle Virtual Directoryのポリシー・ストアを構成します。

19.4.2 Real Application Securityとの統合のためのOracle Virtual Directoryの準備

Real Application Security統合のためにOracle Virtual Directoryを構成する前に、ORACLE_HOME/ovd/ras/ディレクトリのバックアップ・コピーを作成する必要があります。

Real Application Security統合に必要なすべての構成ファイルはrasディレクトリに格納されています。rasディレクトリのバックアップ・コピーを作成すると、使用する環境に基づいた元のrasディレクトリにあるファイルをテンプレートとして編集しつつ、元のファイルのコピーを保持しておくことができます。

19.4.3 Real Application Security (RAS)のLDAPアダプタの構成

各アイデンティティ・ストアのLDAPアダプタを作成する必要があります。LDAPアダプタがすでに存在している場合は、RASプラグインを構成できます。

RAS用のOracle Virtual Directoryを構成すると、Oracle Virtual Directoryのローカル・ストア・アダプタにcn = RealApplicationSecurityRootエントリが作成されます。Oracle Virtual Directoryは、このサブツリー内のすべてのRAS固有データを格納します。さらに、cn=RealApplicationSecurityRootエントリは、RASがデータベースからLDAPを要求するためのデフォルトの検索ベースとして使用するオプションのorclRASSearchBase属性を組み込んでいます。

RAS用にLDAPおよびローカル・ストア・アダプタを構成するには、次の手順を実行します。

1. Oracle Directory Services Managerにログインします。

2. 「アダプタ」タブを選択し、「Real Application Security (RAS)のLDAPアダプタの構成」アイコンをクリックします。

3. Real Application SecurityのLDAPアダプタ構成ウィザードが表示されたら、「情報」ノードを展開してRASプラグインとRASセッションについて読み取ります。
次のようにLDAPアダプタを作成、追加、編集あるいは削除するには、アダプタ表の上に位置するアイコンを使用します。

- RASの新しいLDAPアダプタを作成するには、「新規LDAPアダプタの作成」アイコンをクリックします。「LDAPアダプタの作成」ダイアログが表示されたら、次の情報を入力して「OK」をクリックします。

表19-1 LDAPアダプタのパラメータ

パラメータ

説明

アダプタ名(必須)

新しいアダプタの一意の名前を入力します。その他の構成フィールドでは、この名前を使用してこのアダプタが参照されます。

アダプタ・テンプレート(必須)

メニューからRASテンプレートを選択します。たとえば、Oracle Virtual Directoryを、Active Directoryに格納されているユーザーID用のRASと統合するには、RAS ActiveDirectoryを選択します。

ホスト(必須)

LDAPサーバー接続に使用されているホストDNS名またはIPアドレスを入力します。

ポート(必須)

ポート番号を入力します。

サーバー・プロキシ・バインドDN

アダプタがディレクトリにバインドするために使用する識別名を入力します。匿名バインドのために、このフィールドを空白にしておきます。

プロキシ・パスワード

プロキシ・パスワードを入力します。匿名バインドのために、このフィールドを空白にしておきます。

SSL/TLSの使用

このオプションはデフォルトで有効化されています。

注意: LDAPアダプタでSSLを使用する必要があります。

SSL認証モード

「認証なし」または「サーバー認証のみ」を指定するためにメニューを使用します。

リモート・ベース(必須)

すべての操作の開始点であるリモート・ベース・エントリ(DN)を入力します。

マップされたネームスペース(必須)

ローカルのマップされたDNを入力します。たとえば、dc=org。

プラグイン名(必須)

この値はデフォルトではRASです。

バックエンドのログイン属性(必須)

バックエンドのログイン属性名を入力します。

オプションのパラメータ

このアダプタにオプションのプラグインのパラメータを指定するには、「追加」または「削除」のアイコンを使用します。

- 新しいパラメータ名および値を追加するには、「追加」をクリックして表に新しい行を挿入します。

- リストからそのパラメータを削除するには、表にリストされているパラメータを選択し、「削除」をクリックします。

これらのオプションのパラメータの詳細は、第4.3.9項「Real Application Securityのプラグイン」を参照してください。

- 既存のLDAPアダプタを使用してRASプラグインを構成するには、「既存のLDAPアダプタの追加」アイコンをクリックします。「LDAPアダプタの追加」ダイアログが表示されたら、表で1つ以上のアダプタを選択し、「OK」をクリックします。

- 表にリストされたアダプタを編集するには、アダプタ名を選択し、「選択したLDAPアダプタの編集」アイコンをクリックします。「LDAPアダプタの編集」ダイアログが表示されたら、必要に応じてパラメータを編集し、「OK」をクリックします。

- 表にリストされたアダプタを削除するには、アダプタ名を選択し、「選択したLDAPアダプタの削除」アイコンをクリックします。アダプタの情報がすぐにアダプタ表から削除されます。

4. アダプタ表にリストされているアダプタが適切な場合、「次」をクリックして「検索ベース」のページへ進んでください。以前指定した「マップされたネームスペース」値が、この表に記載されていることに注意してください。

5. RAS検索ベースDNを追加または削除するには、「検索ベース」ページを使用します。

- 追加するDNを指定するには、「追加」アイコンをクリックし、表に新しい行が表示されたらDN情報を入力します。

- DNを削除するには、削除対象の行を選択し、「削除」アイコンをクリックします。

6. 「Next」をクリックして、「Summary」ページに移動します。

7. このページに表示されている「LDAPアダプタ詳細」および「検索ベース」情報を確認します。追加の変更が必要ない場合は、「終了」をクリックします。
Oracle Virtual Directoryによって次のアクションが実行されます。

- 新しいLDAPアダプタを作成するか、または既存のLDAPアダプタをRASプラグイン・パラメータを使用して更新します。

- ルートとしてcn=RealApplicationSecurityRootを使用して、RealApplicationSecurityRootローカル・ストア・アダプタを作成します。

- 「ローカル・ストア・アダプタ」にcn=RealApplicationSecurityRootエントリを作成します(まだ存在していない場合)。
すべてのRAS固有のデータはこのサブツリーに格納されます。

- ユーザーが提供する検索ベースを使用してorclRASSearchBase属性を更新します。この検索ベースは、データベースからのLDAPリクエストのデフォルトの検索ベースとして使用されます。

- cn=RealApplicationSecurityRootエントリにACLを作成することでACLを更新します(まだ存在していない場合)。

19.4.4 RAS DBルートDN検出の有効化

Oracle Virtual Directoryは、cn=RealApplicationSecurityRootエントリにオプション属性の一部としてorclRASSearchBaseと呼ばれるRAS DBルートDNを発行します。

orclRASSearchBase属性は複数値です。それらのディレクトリ構造に基づいて、RAS DBは、DBのログオン時のユーザーを検索するための検索ベースとして、これらのDNを使用しています。RAS DBのOracle Virtual Directoryを構成した後、管理者は必要に応じてこの属性を移入する必要があります。RAS DBのLDAPアダプタがOracle Virtual Directoryに構成されている場合、この属性は複数の値を持っている可能性があります。orclRASSearchBase属性値の例を次に示します。

注意:
管理者はデプロイメントDITに基づいて、使用する検索ベースを決定します。Oracle Virtual Directoryアダプタのルートと同じネームスペース内にある場合、DNを選択できます。

- 単一のRAS DB LDAPアダプタの場合、または同じアダプタのルートDNを使用する複数のRAS DBアダプタ
たとえば、Oracle Virtual Directory LDAPアダプタのルートがdc=oracle,dc=comの場合、orclRASSearchBaseはdc=oracle,dc=comの可能性があります。

- アダプタが同じルートを共有しない複数のRAS DB LDAPアダプタの場合
たとえば、Oracle Virtual Directory LDAPアダプタのルートがdc=oracle,dc=comおよびdc=test,dc=comの場合、orclRASSearchBaseはdc=oracle,dc=comおよびdc=test,dc=comの可能性があります。

- 管理者が、RAS DBから特定のコンテナ(バックエンドにある)へのユーザー検索リクエストの検索範囲を制限する、RAS DB LDAPアダプタの場合
たとえば、Oracle Virtual Directory LDAPアダプタのルートがdc=oracle,dc=comの場合、orclRASSearchBaseはou=ST-Dev,dc=oracle,dc=comと類似している可能性があります。

次のコマンド・ラインldapsearchは、どの値がorclRASSearchBaseに構成されているのかを表示します。

ldapsearch –h <host> -p <port> -D DN –w password –b "cn=RealApplicationSecurityRoot"
–s base "objectclass=*" orclRASSearchBase

19.4.5 外部ディレクトリとOracle Virtual Directoryとの統合

この項では、Oracle Virtual Directoryと、特定の外部ディレクトリで使用するReal Application Securityとの統合手順を説明します。これらの手順は、次の項に外部ディレクトリ・タイプに基づいて編成されています。

- Active Directoryの統合構成

- Novell eDirectoryの統合構成

- Oracle Internet Directoryの統合構成

- Oracle Directory Services Managerの統合のための構成

ユーザーIDを格納している外部ディレクトリを説明している項に進んでください。

注意:
Active Directoryを除き、バックエンドLDAPのスキーマ拡張は、これらのどの外部ディレクトリでも必要ありません。これらの変更は、Oracle Virtual Directoryのローカル・ストアで行われます。
Active Directoryディレクトリでは、1つの最小限のスキーマ変更のみが必要です。Oracle Internet Directoryパスワード変更通知プラグインで、生成されたパスワードのハッシュ値の格納に使用されるorclCommonAttribute属性定義を追加する必要があります。

RAS DBについては、バックエンド・ディレクトリにはメタデータのエントリは格納されません。したがって、Active Directoryを除き、バックエンドのLDAPスキーマの拡張は、どの外部ディレクトリでも行う必要はありません。

19.4.5.1 Active Directoryの統合構成

この項では、RASとの統合のためのActive DirectoryおよびOracle Virtual Directoryを構成する方法について説明します。

19.4.5.1.1 Active Directoryの統合構成

注意:
統合にKerberos認証を使用している場合は、次の手順の手順3および4は実行しないでください。

Active Directoryの統合を構成するには、次の手順を実行します。

1. Active Directoryイメージのバックアップ・コピーを作成します。Active Directory内部のスキーマ拡張機能は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

2. Oracle Virtual Directoryに組み込まれているJavaクラスを使用して、Active DirectoryにRASの必須のorclCommonAttributeスキーマであるextendADをロードするために、次のコマンドを実行します。
extendADファイルは、$ORACLE_HOME/ovd/eus/ディレクトリにあります。ORACLE_HOME/jdk/binディレクトリのjava実行可能ファイルを使用できます。

java extendAD -h Active_Directory_Host_Name -p Active_Directory_Port
-D Active_Directory_Admin_DN -w Active_Directory_Admin_Password
–AD Active_Directory_Domain_DN -commonattr

注意:
有効なActive DirectoryドメインDNは、たとえばdc=oracle,dc=comです。

3. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグイン、oidpwdcn.dllをインストールします。

1. $ORACLE_HOME/ovd/ras/oidpwdcn.dllファイルをActive DirectoryのWINDOWS\system32ディレクトリにコピーします。

2. regedt32を使用してレジストリを編集し、oidpwdcn.dllを有効にします。コマンド・プロンプトでregedt32と入力して、regedt32を起動します。

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\レジストリにあるNotification Packagesエントリの末尾にoidpwdcnを追加します。次に例を示します。

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

4. 変更したら、Active Directoryシステムを再起動します。

4. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグインを検証します。

1. Active Directoryユーザーのパスワードを変更します。

2. パスワードを変更したユーザーをActive Directoryで検索します。orclCommonAttribute属性に、生成されたハッシュ・パスワード値が含まれることを確認します。
この値は、Active DirectoryにorclCommonAttribute属性定義を追加します。

3. すべてのActive Directoryユーザーのパスワードをリセットすることで、プラグインがパスワード変更を取得して、パスワード検証を生成および格納できるようにします。

5. Oracle Database Advanced SecurityとともにWindows 2000またはWindows 2003上でKerberos認証を使用している場合、『Oracle Database Advanced Security管理者ガイド』を参照してここでそれを構成する必要があります。
Kerberos認証を構成した後、次の手順に進む前に、Active Directoryユーザー資格証明を使用してデータベースにログインできることを確認します。

19.4.5.1.2 Oracle Virtual Directoryの統合構成

注意:
この手順を開始する前に、第19.4.2項「Real Application Securityとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行したことを確認してください。

Oracle Virtual Directoryを統合構成する手順は次のとおりです。

1. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

2. 第19.4.3項「Real Application Security (RAS)のLDAPアダプタの構成」に示す手順を使用して、ローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- RAS_ActiveDirectoryテンプレートを選択します。

- 「SSL/TLSの使用」オプションが有効になっていることを確認します。

- 「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

これで、RASとの統合、およびMicrosoft Active Directoryとの使用のためにOracle Virtual Directoryを構成する手順は完了です。統合プロセスを続行してRASを構成するには、Oracle Real Application Security製品マニュアルを参照してください。

19.4.5.2 Novell eDirectoryの統合構成

この項では、Novell eDirectoryおよびOracle Virtual Directoryを構成してRASと統合する方法について説明します。

19.4.5.2.1 Novell eDirectoryの統合構成

統合用にNovell eDirectoryを構成するには、eDirectoryのユニバーサル・パスワードを有効化し、管理者がユーザー・パスワードを取得できるようにします。詳細は、Novell eDirectoryのパスワード管理に関するドキュメントを参照してください。

19.4.5.2.2 Oracle Virtual Directoryの統合構成

注意:
この手順を開始する前に、第19.4.2項「Real Application Securityとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行したことを確認してください。

Oracle Virtual Directoryを統合構成する手順は次のとおりです。

1. Novell開発者コミュニティのWebサイトから、NMASツールキットをダウンロードします。

2. Oracle Directory Services Managerを使用してこのライブラリをOracle Virtual Directoryにアップロードします。詳細は、「Oracle Virtual Directoryサーバーへのライブラリのロード」を参照してください。
Oracle Virtual Directoryサーバーを再起動します。

3. Oracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

4. 「Real Application Security (RAS)のLDAPアダプタの構成」に示す手順を使用して、新しいローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- RAS_eDirectoryテンプレートを選択します。

- 「SSL/TLSの使用」オプションを有効化し、「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

これで、RASとの統合のためにOracle Virtual Directoryを構成し、Novell eDirectoryとともに使用するための手順は完了です。統合プロセスを続行してRASを構成するには、Oracle Real Application Security製品マニュアルを参照してください。

19.4.5.3 Oracle Internet Directoryの統合構成

この項では、Oracle Internet DirectoryおよびOracle Virtual Directoryを構成してRASと統合する方法について説明します。

19.4.5.3.1 Oracle Internet Directoryの統合構成

この統合では、Oracle Internet Directoryを手動で構成する必要はありません。

19.4.5.3.2 Oracle Virtual Directoryの統合構成

注意:
この手順を開始する前に、第19.4.2項「Real Application Securityとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行したことを確認してください。

Oracle Virtual Directoryを統合構成する手順は次のとおりです。

1. Oracle Virtual Directoryサーバーを起動します。

2. Oracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

3. 第19.4.3項「Real Application Security (RAS)のLDAPアダプタの構成」に示す手順を使用して、ローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタ用に、RAS_OIDテンプレートを選択してください。

これで、RASとの統合、およびOracle Internet Directoryとの使用のためにOracle Virtual Directoryを構成する手順は完了です。統合プロセスを続行してRASを構成するには、Oracle Real Application Security製品マニュアルを参照してください。

19.4.5.4 Oracle Directory Services Managerの統合構成

この項では、Oracle Directory Services ManagerおよびOracle Virtual Directoryを構成してRASと統合する方法について説明します。

19.4.5.4.1 Oracle Directory Services Managerの統合構成

注意:
統合にKerberos認証を使用している場合は、次の手順の手順3および4は実行しないでください。

Oracle Directory Services Managerを統合構成するには、次の手順を実行します。

1. Oracle Directory Services Managerのイメージのバックアップ・コピーを作成します。Oracle Directory Services Managerの内部のスキーマ拡張機能は永続的で、キャンセルできません。バックアップ・イメージがあると、必要になったときに変更をすべてリストアできます。

2. Oracle Virtual Directoryに組み込まれているJavaクラスを使用して、Oracle Directory Services ManagerにRASの必須のorclCommonAttributeスキーマであるextendODSMをロードするために、次のコマンドを実行します。
extendODSMファイルは、$ORACLE_HOME/ovd/eus/ディレクトリにあります。ORACLE_HOME/jdk/binディレクトリのjava実行可能ファイルを使用できます。

java extendODSM -h ODSM_Host_Name -p ODSM_Port
-D ODSM_Admin_DN -w ODSM_Admin_Password
–ODSM ODSM_Domain_DN -commonattr

注意:
有効なOracle Directory Services ManagerドメインDNは、たとえばdc=oracle,dc=comです。

3. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグイン、oidpwdcn.dllをインストールします。

1. $ORACLE_HOME/ovd/ras/oidpwdcn.dllファイルをOracle Directory Services ManagerのWINDOWS\system32ディレクトリにコピーします。

2. regedt32を使用してレジストリを編集し、oidpwdcn.dllを有効にします。コマンド・プロンプトでregedt32と入力して、regedt32を起動します。

3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\レジストリにあるNotification Packagesエントリの末尾にoidpwdcnを追加します。次に例を示します。

RASSFM
KDCSVC
WDIGEST
scecli
oidpwdcn

4. 変更したら、Oracle Directory Services Managerシステムを再起動します。

4. 次の手順を実行して、Oracle Internet Directoryパスワード変更通知プラグインを検証します。

1. Oracle Directory Services Managerユーザーのパスワードを変更します。

2. パスワードを変更したユーザーをOracle Directory Services Managerで検索します。orclCommonAttribute属性に、生成されたハッシュ・パスワード値が含まれることを確認します。
この値は、Oracle Directory Services ManagerのorclCommonAttribute属性定義を追加します。

3. すべてのOracle Directory Services Managerユーザーのパスワードをリセットすることで、プラグインがパスワード変更を取得して、パスワード検証を生成および格納できるようにします。

5. Oracle Database Advanced SecurityとともにWindows 2000またはWindows 2003上でKerberos認証を使用している場合、『Oracle Database Advanced Security管理者ガイド』を参照してここでそれを構成する必要があります。
Kerberos認証を構成した後、次の手順に進む前に、Oracle Directory Services Managerユーザー資格証明を使用してデータベースにログインできることを確認します。

19.4.5.4.2 Oracle Virtual Directoryの統合構成

注意:
この手順を開始する前に、第19.4.2項「Real Application Securityとの統合のためのOracle Virtual Directoryの準備」のすべての手順を実行したことを確認してください。

Oracle Virtual Directoryを統合構成する手順は次のとおりです。

1. Oracle Virtual Directoryサーバーを起動し、次にOracle Directory Services Managerを起動し、Oracle Virtual Directoryサーバーに接続します。

2. 第19.4.3項「Real Application Security (RAS)のLDAPアダプタの構成」に示す手順を使用して、ローカル・ストア・アダプタおよびLDAPアダプタを作成します。
LDAPアダプタに対して必ず次の設定を使用してください。

- RAS_ODSMテンプレートを選択します。

- 「SSL/TLSの使用」オプションが有効になっていることを確認します。

- 「SSL認証モード」を「サーバー認証のみ/相互認証」に設定します。

これで、RASとの統合、およびOracle Directory Services Managerとの使用のためにOracle Virtual Directoryを構成する手順は完了です。統合プロセスを続行してRASを構成するには、Oracle Real Application Security製品マニュアルを参照してください。

19.4.6 Real Application Security統合のためのアクセス制御リストの構成

この項では、ユーザーIDの格納に使用している外部リポジトリに関係なく、Real Application Securityとの統合のためにOracle Virtual Directoryに構成する必要のあるアクセス制御リスト(ACL)について説明します。

Oracle Virtual DirectoryのデフォルトRASDB ACL

Oracle Virtual Directoryの構成時に、次のACLが、RASに構成されているサブツリーにデフォルトで設定されています。

- RAS DBエントリへのアダプタ・サブツリーの読取りおよび検索アクセス。

- 全員に対して、authpasswordおよびorclaccountstatuseventへのアクセス拒否。

cn=RealApplicationSecurityRootエントリのACL

このACLは、管理者にのみ読取りおよび書込みアクセスを設定します。

デフォルトでは、Oracle Virtual DirectoryがRASアクセス用に構成された後、ユーザーがログインできるように、管理者が明示的にユーザーにアクセス権を付与するまで、どのユーザーもRAS DBにログインできません。

ユーザーがRAS DBにログインするためには、Oracle Virtual Directoryに次のACLを設定する必要があります。

- RAS DBエントリのauthpassword属性へのアクセスを指定し、他の人にはそれを拒否します。

- RAS DBエントリのorclaccountstatusevent属性へのアクセスを指定し、他の人にはそれを拒否します。

ユーザーにRAS DBアクセスを可能にするACLを設定するには、次のいずれかの方法を使用します。

- サブツリー全体へのアクセス権の付与。

- ユーザー属性に基づいたユーザー・グループへのアクセス権の付与。たとえば、ou:st-devユーザー属性を持つすべてのユーザーに対して、データベースへのアクセス権を付与できます。

- 個々のユーザーへのアクセス権の付与。

これらのACLは、Oracle Directory Services Managerまたはldapmodifyを使用してコマンド・ラインから設定できます。Oracle Virtual Directoryでは、$ORACLE_HOME/ovd/rasディレクトリにこれらのACLを構成するためのいくつかのLDIF例が送信されます。

19.4.7 複数のアイデンティティ・ストアをサポートするためにOracle Virtual Directoryを構成

Oracle Virtual Directoryは複数のアイデンティティ・ストアをサポートできますが、それぞれのアイデンティティ・ストアのRAS DBのプラグインを使用して、対応するLDAPアダプタを構成する必要があります。

Oracle Virtual DirectoryのLDAPアダプタで、どのルートDNを使用するかを決定します。次に、LDAPアダプタを作成した後、これらのすべてのアダプタ・ルートDNを使用してorclRASSearchBase属性を移入する必要があります。

19.4.8 ユーザー・アカウントのロックアウトを使用した作業

バインドの試行が何度か失敗したら、LDAPサーバーによりユーザー・アカウントをロックできます。Oracle Virtual DirectoryとReal Application Securityの統合では、このロックアウト機能を使用して、次のようにバックエンドのLDAPサーバーのパスワード・ロックアウト・ポリシーを施行できます。

- Oracleデータベースへの不正なログインでは、バックエンドのLDAPサーバーにログインの失敗が記録されます。

- Oracleデータベースへの適切なログインにより、バックエンドのLDAPサーバーのログインの失敗数がリセットされます。

- ロックされたユーザー・アカウントを使用して、Oracleデータベースにログインすることはできません。

Real Application Securityのユーザー・アカウント・ロックアウトを有効にするには、第19.2.6「ユーザー・アカウント・ロックアウトの有効化」を参照してください。

20 Oracle Communications Universal User Profile

この章では、Oracle Communications Universal User Profileについて説明します。この章の内容は次のとおりです。

- 第20.1項「Oracle Communications Universal User Profileとは」

- 第20.2項「Oracle Communications Universal User Profileのユースケースの例およびデプロイ・シナリオ」

- 第20.3項「Oracle Communications Universal User ProfileのDiameterアダプタ」

- 第20.4項「LDAPスキーマへのIMS 3GPPスキーマのマッピング」

注意:
この章全体を通じて、「Oracle Communications Universal User Profileサーバー」という用語は、Diameterアダプタとともに構成されているOracle Virtual Directoryサーバーを指します。

20.1 Oracle Communications Universal User Profileとは

Oracle Communications Universal User Profileは、通信企業内に存在する様々なシステムからサブスクラバ・データを集約、正規化するステートレスなサブスクラバ・アイデンティティ・サービスです。通信企業が固定電話からISP、携帯電話システムへと業務拡大するにつれて、リポジトリの数は急激に増加しています。これらの新しいサービスによって可能になった新しいビジネス・チャンスを利用し、かつ、サービスを顧客に配信するコストを削減するには、サブスクラバ・アイデンティティの単一のビューをアプリケーションに提供する必要があります。

サブスクライバ・アイデンティティの単一のビューをアプリケーションに提供するには、次のようないくつかの問題に対処する必要があります。

- 合併、買収および子会社化により、サブスクライバ・データが複数のシステムに異なるキーで分散している可能性がある。

- 内部組織のデータ政策や外部規制、同期をとる必要がある場合はほとんどデータが古くなっていることから、すべてのデータを1つの汎用リポジトリにマージできない。

- アプリケーションでは、アプリケーション固有のビュー内にデータが必要である。

- アイデンティティ・データの保護に関連した側面が複数ある。

- 既存データを別の場所にコピーする際の、そのデータの記憶域、セキュリティおよびバックアップをすべて複製するプロセスが膨大な作業である(通常、ほとんどの組織にとって実行可能な選択肢ではない)。

Oracle Communications Universal User Profileは、サブスクライバ・アイデンティティ情報に関する標準かつ唯一の窓口となるステートレスなキャリアグレード・ソリューションを提供することで前述の問題を解決します。集中管理されたリポジトリにデータをコピーするかわりに、Oracle Communications Universal User Profileは必要なデータを要求に応じて取り出し、アプリケーションに必要な形式で提供します。

また、Oracle Communications Universal User Profileはステートレスであり、Oracle TimesTen In-Memory Database、Oracle Service Delivery Platform、Oracle SOA Suiteなどの主要な関連テクノロジと統合されるので、これを使用することで、スマートルーティングによって通信ソリューションの要求を満たすことができます。

Oracle Communications Universal User Profileへの標準インタフェースにはLDAPとSOAPがあり、デフォルトでは、LDAP、リレーショナル・データベースまたはDiameter HSSのリポジトリ内のデータにアクセスできます。また、Oracle Communications Universal User Profileには、XCAP、WebサービスおよびJavaで接続できるその他のシステムのデータを活用するためにカスタムJava APIが用意されています。

20.2 Oracle Communications Universal User Profileのユースケースの例およびデプロイ・シナリオ

この項では、Oracle Communications Universal User Profileのユースケースの例およびデプロイ・シナリオについて説明します。この項の内容は次のとおりです。

- ダブルまたはトリプル・プレー・サービスの有効化

- 有機的ソーシャル・ネットワーキングの向上

- ミッドコール・ムーブ

- スマート・パッケージ・ルーティング

- エントリの例

ダブルまたはトリプル・プレー・サービスの有効化

多くの通信会社は、携帯/固定電話、ISP、テレビ(ケーブルまたは光ファイバ)サービスなど、様々なサービスを提供しています。その結果、これらの通信会社の多くは、現在その全部には加入していない顧客に対して、自社の多種多様なサービスのクロスセルを試みます。

このような場合、Oracle Communications Universal User Profileを使用すると、様々なシステムからデータを集約し、販売キャンペーンと顧客ポータルの両方を構築して通信会社とやりとりする際のユーザー体験を向上させるために役立てることができます。

たとえば、販売キャンペーンを使用できるようにするには、Oracle Communications Universal User ProfileをBPELワークフローとともに使用して次のようにします。

1. 携帯電話に加入していて、テレビ・サービスには加入していないサブスクライバを全員検索します。

2. 今から4時間以内など特定の期間内にテレビ・サービスに加入した場合には割引価格のクーポンとなるショート・メッセージ・サービス(SMS)メッセージを該当するサブスクライバに送信します。

これを実現するため、Oracle Communications Universal User Profileは次の場所からデータを取得します。

- 携帯電話とテレビの両方の請求システム(どの顧客がどのサービスに加入しているかを特定するため)

- 連絡先データベース(顧客の電話番号および電話機能を特定するため)

- HSS情報リポジトリ(顧客がオンライン顧客で4時間の期限に間に合うかどうかを判断するため)

BPELを使用すると、パフォーマンスや信頼性のため、また販売グループが顧客の名前および連絡先情報を参照できないようにワークフローを隔離できるようになるため、サブスクライバのアイデンティティ情報は保護されます。

有機的ソーシャル・ネットワーキングの向上

ソーシャル・ネットワークの人気がネット上で急速に拡大している一方で、ソーシャル・ネットワークは常に実在する非電子のコミュニティで自然発生しています。しかし、実際には、直接会ったことがない、電子的ソーシャル・ネットワーク内の何千もの人々とコミュニケーションする方が、ユース・スポーツ・チームに属する子供たちの親同士といった状況で気楽に付き合っている10から15の人々とコミュニケーションするより簡単であることがしばしばです。

自分がユース・スポーツ・チームのコーチを務め、ある日、練習中に突然大雨が降り始めたとします。雨のため練習を中止する場合に、タイミングよく子供たちの親全員に連絡をとることは不可能ではないにしても、非常に困難なことです。

しかし、Oracle Web Center、Oracle Service Delivery PlatformおよびOracle Communications Universal User Profileを使用すれば、通信会社は、このような状況に対処して子供たち全員の親に迅速に連絡できるモバイルWebアプリケーションを構築できます。練習を中止することにした場合は、カスタム有料サービスに音声またはテキストのメッセージを残すことができ、その後メッセージは、チームのアドレス帳を使用して子供たちの親に中継されます。

この場合、Oracle Communications Universal User Profileにより次のものが提供されます。

- アプリケーションに対して認証を行うためのコーチの資格証明へのアクセス

- 通話を認可する属性

- チームのアドレス帳(第1連絡先番号とその番号がショート・メッセージ・サービス(SMS)または音声のみのメッセージを受信できるかどうかなどの情報を含む)

ミッドコール・ムーブ

ミッドコール・ムーブとは、電話中の人が現在の通話を別の電話にリダイレクトできるようにするサービスのことです。たとえば、自分の席で仕事中に電話会議に参加していますが、オフィスを離れる必要があるとします。ミッドコール・ムーブを使用すれば、自分の席の電話で特定の電話番号の組合せ(たとえば、アスタリスクの次に7)を押し、携帯電話に電話会議を転送することが可能になります。この場合、Oracle Communications Universal User Profileを使用すると、ミッドコール・ムーブ・サービスに加入しているかどうか確認し、加入している場合は携帯電話番号を検索した後、転送を開始できます。

スマート・パッケージ・ルーティング

仕事中に、1,000個の部品を発注し、ジョージア州アトランタの施設Aに送ったとします。その後、誤りがあったことに気づき、実際に1,000個の部品を必要としているのはマサチューセッツ州ボストンの施設Bであることがわかりました。困ったことに、ボストンの施設Bの住所がわからず、施設AまたはBの誰に状況を知らせるかもわかりません。

このような状況に対処するには、出荷サービスをオフィスの電話サービスと統合し、モバイルWebアプリケーションを使用して、荷物の追跡、別の経路の選択および担当者への連絡が(正しいオフィス名を選択するだけで)できるようにします。この場合、Oracle Communications Universal User Profileは、荷物の請求書作成に関するコストセンター情報、荷物の経路設定を変更できるようにする認証、各種施設の住所を提供します。

20.3 Oracle Communications Universal User ProfileのDiameterアダプタ

現在の通信環境では、サブスクライバ情報がIMS準拠のHome Subscriber Service(HSS)に含まれることがあります。Oracle Communications Universal User Profileの特徴の1つに、Diameterアダプタがあります。Diameterアダプタにより、Oracle Communications Universal User Profileでは次のことが可能になります。

- Diameterプロトコルを介して実行する3GPP IP Multimedia Subsystem(IMS)Home Subscriber Systemsに接続すること

- 情報のソースに関係なく、サブスクライバID情報に対する標準化されたサービス層を提示すること

注意:
Diameterアダプタはobjectclass=*フィルタでのサブツリー検索範囲をサポートしていないので、クライアント・ビュー・ブラウザではDiameterアダプタのネームスペースを参照できません。同様に、クライアント・ビュー・ブラウザでは、プライマリ・アダプタとしてDiameterアダプタが構成された結合ビュー・アダプタを参照できません。

この項は、次の内容で構成されます。

- Diameterアダプタのサポートの有効化

- Diameterアダプタの作成および構成

20.3.1 Diameterアダプタのサポートの有効化

Oracle Virtual DirectoryによるDiameterアダプタのサポートを有効化するには、次の手順を実行します。

1. WLSTを使用し、「WLSTを使用したOracle Virtual Directoryサーバーの設定の構成」の「SchemaLocations」エントリを参照して、Oracle Virtual Directoryサーバー設定にschema.diameter.xmlを追加します。

2. ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlファイルで、Oracle Virtual Directoryサーバー・エントリのjava-classpathプロパティの最後に、1つの連続する文字列として次の内容を追加します。

:$ORACLE_HOME/ovd/diameter/lib/wlssdiameter.jar:$ORACLE_
HOME/ovd/diameter/lib/weblogic.jar:$ORACLE_HOME/ovd/diameter/lib/xbean.jar

3. 次のコマンドを実行してOPMN構成を再ロードします。

$ORACLE_INSTANCE/bin/opmnctl reload

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

20.3.2 Diameterアダプタの作成および構成

Diameterアダプタを作成および構成するには、次の手順を実行します。

1. 新しいカスタム・アダプタを作成します。詳細は、「カスタム・アダプタの作成および構成」を参照してください。

2. 「新規カスタム・アダプタ」ダイアログ・ボックスで「アダプタ・テンプレート」としてDiameterを選択し、適切な「アダプタ接尾辞/ネームスペース」を入力します。「終了」ボタンをクリックします。

3. 新しいDiameterアダプタの「プラグイン」タブに移動します。DiameterAdapterPluginを選択し、「編集」ボタンをクリックします。プラグインの編集: DiameterAdapterPluginダイアログ・ボックスが表示されます。

4. パラメータを選択して、「編集」ボタンをクリックし、「パラメータ」表に次の構成パラメータ(名前: 値)を追加します。remoterealmおよびremotePeersパラメータは必須です。

- interface: HSSへの接続に使用されるDiameterインタフェースのタイプ。デフォルト値はShです。

注意:
現在、Shはinterface構成パラメータで唯一サポートされている値です。

- listener: Oracle Communications Universal User Profileサーバーのホスト名およびHSSサーバーから受信するメッセージをリスニングするポート。これはHSSプロトコルの要件です。このlistener値は、aaa://host:portの形式(たとえばaaa://ovd.mycompany.com:3689)にする必要があります。このポートは、HSSサーバーからファイアウォールを通してアクセスできるようにする必要があります。3869は、HSSクライアント・リスナー・ポートのデフォルト・ポートです。

注意:

- リスナー値のaaaという文字列は、置き換えられる変数ではありません。このとおりに含める必要があります。

- リスナー・パラメータをOracle Virtual Directoryリスナーと混同しないでください。

- nosctp: SCTPトランスポートを無効化するかどうかを決定します。サポートされている値はtrueおよびfalseです。デフォルトの設定はtrueです。

注意:
nosctpオプションの使用方法およびSCTPトランスポートの有効化の詳細は、「SCTPトランスポートの有効化」を参照してください。

- localrealm: このカスタムDiameterアダプタのレルムで、HSSサーバーの任意の有効な値に設定できます。デフォルト値はmycompany.comです。localrealmパラメータは、Oracle Communications Universal User ProfileのレコードをHSSサーバーにマップするためのキーとして使用されます。

- remoterealm(必須): HSSプロバイダにより提供されます。HSSサーバーのremoterealm値です。

- remotePeers(必須): remotePeers値は、HSSサーバーのホスト名およびポートです。どちらの値もHSSサーバーによって提供されます。remotePeers値は、aaa://host:portという形式(aaa://hss.mycompany.com:3868など)であることが必要です。デフォルト・ポートは3868です。

注意:
それぞれをセミコロン文字(;)で区切ることにより、複数の値を指定できます。たとえば、aaa://127.0.0.1:3868; aaa://different-host:3939のようにします。

- remoteHost: リモートHSSサーバーのホスト名。デフォルト値は127.0.0.1です。

- connectionWaitTimeout: アダプタの起動時にHSSサービスが使用できる時間です(ミリ秒単位)。デフォルト値は30000です。

- requestTimeout: 保留中のHSSトランザクションが完了するまでの最大待機時間です(ミリ秒単位)。空の値はタイムアウトがないことを意味します。デフォルト値は5000です。

5. プラグインの編集: DiameterAdapterPluginダイアログ・ボックスの「終了」ボタンをクリックします。

20.3.2.1 SCTPトランスポートの有効化

Solaris SPARC10およびLinuxでのみ、DiameterアダプタでSCTPトランスポートがサポートされます。Diameterアダプタに対してSCTPトランスポートを有効化するには、次の手順を実行します。

1. Oracle Communications Universal User Profileが実行されているサーバーでSCTPを有効化します。

2. LinuxおよびSolaris SPARC10環境でのみ、ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlファイルで、Oracle Virtual Directoryサーバー・エントリのjava-options属性の最後に次の内容を追加し、LD_LIB_PATHを更新します。

- Linuxでは、1つの行として次の内容を追加します。
-Djava.library.path=$ORACLE_HOME/ovd/diameter/native/linux32/libsctpwrapper.so

- Solaris SPARC10では、1つの行として次の内容を追加します。
-Djava.library.path=$ORACLE_HOME/ovd/diameter/native/solaris10_sparc64/libsctpwrapper.so

3. ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlファイルの同一のOracle Virtual Directoryサーバー・エントリのjava-classpath属性の最後に次の内容を追加します。
:$ORACLE_HOME/ovd/diameter/lib/sctp.jar

4. Diameterアダプタのnosctp構成パラメータをfalseに設定します。

5. Diameterアダプタのlistener構成パラメータを、Oracle Communications Universal User Profileサーバーの完全修飾ドメイン名に設定します。

6. DiameterアダプタのremotePeers構成パラメータを、HSSサーバーの完全修飾ドメイン名とポートに設定します。

7. DiameterアダプタのremoteHost構成パラメータを、HSSサーバーの完全修飾ドメイン名に設定します。

8. Oracle Communications Universal User Profileサーバーを再起動します。

20.4 LDAPスキーマへのIMS 3GPPスキーマのマッピング

Oracle Communications Universal User Profileでは、3GPP TS 29.328仕様(IMSユーザー・プロファイルを理解するために知識を付けることをお薦めします)に定義されているように、バージョン6のShユーザー・プロファイルがサポートされています。

schema.diameter.xmlは、Oracle Communications Universal User ProfileでマップされたLDAPスキーマであり、次の属性を含むLDAP orclHSSProfileオブジェクト・クラスを定義しています。

- orclHSSPublicId: 3GPP TS 23.008仕様で定義されているように、パブリック・ユーザーID IMSユーザー・プロファイルにマップします。orclHSSPublicIdは、HSS Shプロファイルの問合せに使用されるフィルタ属性です。

- orclHSSServiceProfile: ldapsearchの結果では、orclHSSServiceProfileに、Diameterレスポンス・メッセージのUser-Data属性-値ペアに含まれるXMLドキュメントのバイナリ値が含まれます。このXMLドキュメントは、バージョン6のSh XSDに準拠します。
ldapmodifyリクエストでは、orclHSSServiceProfileに、更新されるRepositoryDataのserviceIndicatorが次の形式で含まれます。

<serviceIndicator>:<serviceIndicator_value>

- orclHSSMSISDN: orclHSSPublicIdにかわるもので、orclHSSMSISDNは、3GPP TS23.008仕様で定義されているモバイル・ステーションISDN番号にマップします。

エントリの例

一般的に、Diameterデータは、結合ビュー・アダプタを使用してコア・レコードにリンクできます。たとえば、サブスクライバのコア・レコードは請求データベースに存在しますが、電話の実際の機能はHSSサーバーに格納されています。次に、LDIFファイルとして取得して印刷した場合などに、表示されるデータの例を示します。

uid=user1,ou=uup2,dc=imc,dc=com
givenname=Jane
sn=Doe
telephonenumber=15551234567
objectclass=top
objectclass=person
objectclass=organizationalperson
objectclass=inetorgperson
objectclass=orclHSSProfile
uid=user1
cn=Jane Doe
title=Associate
authpassword;oid={SASL/MD5}CPvyoxkufZJ69n0YBwfPsw==
authpassword;oid={SASL/MD5-DN}JnDX4y0mf8vdN1dAHVutDw==
authpassword;oid={SASL/MD5-U}/a3vgMwtjQKe8dEcAdxQwQ==
orclHSSPublicId=user1
orclHSSServiceProfile=<?xml version = '1.0' encoding = 'UTF-8'?>
<Sh-Data>
<RepositoryData>
<PublicIdentifiers>
<IMSPublicIdentity>
sip:test.user@test.company.com
</IMSPublicIdentity>
</PublicIdentifiers>
<ServiceIndication>DualRingDiameter</ServiceIndication>
<SequenceNumber>0</SequenceNumber>
</RepositoryData>
</Sh-Data>
vdejoindn=Diameter:orclhsspublicid=user1,ou=Custom,dc=hsscontractid=2001-A57

注意:
orclHSSServiceProfile属性値がXMLとして格納されていることに注意してください。これにより、別のLDAPオブジェクトを参照せずに、この属性に複雑なデータ値を格納できます。

orclHSSServiceProfile値には、IMSPublicIdentityのDataReference型の結果値が含まれています。DataReference型は、通信において数値で指定されますが、各値は1つの型に対応しています。DataReference型の結果値を表20-2に示します。

表20-1 DataReference型の結果値

型

数値

REPOSITORY DATA

0

IMS PUBLIC IDENTITY

10

IMS USER STATE

11

SCSCF NAME

12

INITIAL FILTER CRITERIA

13

LOCATION INFORMATION

14

USER STATE

15

CHARGING INFORMATION

16

MSISDN

17

PSIActivation

現在はサポートされていません。

デフォルトでは、Oracle Communications Universal User Profileは、SH UDRがすべてのIDであるIMS PUBLIC IDENTITYに対応する値をHSSに送信し、完全なユーザーIDのセットを取得します。

クライアントが異なるUDRリクエストを送信する必要がある場合は、2.16.840.1.23008.2.9.28として定義されているLDAPコントロールを使用できます。コントロール内のデータは、0;DualRingToneなど、数値の後にセミコロン(;)と参照識別子が続きます。表20-2に、UDR値のいずれかに対応する数値をリストします。

表20-2 DataReference型の結果値

型

数値

REPOSITORY DATA

0;serviceIndication

IMS PUBLIC IDENTITY

10;identitySet

identitySetでは、次のように整数値0、1および2がサポートされています。

- 0: すべてのID

- 1: 登録済ID

- 2: 暗黙的ID

IMS USER STATE

11

SCSCF NAME

12

INITIAL FILTER CRITERIA

13;serverName

LOCATION INFORMATION

14;requestedDomain

requestedDomainでは、次のように整数値0および1がサポートされています。

- 0: CSドメイン

- 1: PSドメイン

USER STATE

15;requestedDomain

requestedDomainでは、次のように整数値0および1がサポートされています。

- 0: CSドメイン

- 1: PSドメイン

CHARGING INFORMATION

16

MSISDN

17

PSIActivation

現在はサポートされていません。

Diameterアダプタでは、書込みと読取りがサポートされています。orclHSServiceProfileに格納されているデータを更新する場合、データは次の形式で提供される必要があります。

<serviceIndicator>:<serviceIndicator_value>

例: DualRingTone:30

第IV部

付録

この部には次の付録が含まれます:

- 付録A「Oracle Virtual Directory 11gリリース1(11.1.1)と10gリリース(10.1.4.x)の比較」

- 付録B「Oracleスタックの起動と停止」

- 付録C「HTTPリスナーのWebゲートウェイ・サービス」

- 付録D「Oracle Virtual Directoryのトラブルシューティング」

A Oracle Virtual Directory 11gリリース1(11.1.1)と10gリリース(10.1.4.x)の比較

この付録では、11gリリース1(11.1.1)と以前のOracle Virtual Directory 10gリリース(10.1.4.x)との基本アイテムの実装方法の違いを比較します。この付録は、リリース間の実装の変更の概要情報を説明し、11gリリース1(11.1.1)へのアップグレード後のガイドを提供することを目的としています。

この付録では、次の内容を説明します。

- 第A.1項「デフォルト・スーパー・ユーザー」

- 第A.2項「プロセス・マネジメント」

- 第A.3項「構成ファイルの場所」

- 第A.4項「プラグイン・ファイルの場所」

- 第A.5項「デプロイされたマッピング・ファイルの場所」

- 第A.6項「ログ・ファイルの場所」

- 第A.7項「ローカル・ストア・アダプタのデータ・ストアの場所」

- 第A.8項「スキーマ・ファイルの場所」

- 第A.9項「Oracle Virtual Directoryサーバーのライブラリの場所」

- 第A.10項「Oracle Virtual Directoryサーバーのデバッグの有効化」

- 第A.11項「グラフィカル・ユーザー・インタフェース」

- 第A.12項「コマンドライン・ツール」

- 第A.13項「クラスパスの更新」

- 第A.14項「2つのOracle Virtual Directoryコンポーネントの同期化」

- 第A.15項「監査の構成」

- 第A.16項「監査ログの場所」

- 第A.17項「サポートされているカスタマイズ」

注意:
次の項には、次のようなディレクトリが含まれます。
ORACLE_INSTANCE/config/OVD/ovd1

ORACLE_INSTANCEおよびovd1は、使用環境によって異なる可能性があるディレクトリ名であるため、イタリック体を使用して表示されています。

A.1 デフォルト・スーパーユーザー

10gリリース(10.1.4.x):

- cn=admin

11gリリース1(11.1.1):

- cn=orcladmin

A.2 プロセス管理

10gリリース(10.1.4.x):

- 開始、停止、再起動、およびその他のプロセスは、UNIX/Linuxプラットフォームではvde.sh、WindowsプラットフォームではOViDserver.exeを使用して制御。

- 各Oracle Virtual Directoryインストールに対して1つのOracle Virtual Directoryプロセス。

11gリリース1(11.1.1):

- 開始、停止、再起動、およびその他のプロセスは、Oracle Process Manager and Notification Serverへのコマンドライン・インタフェース(opmnctl)を使用して制御。

- opmnctlを使用して、複数のOracle Virtual Directoryインスタンスを作成可能。

関連項目:
詳細は、第10章「Oracle Virtual Directoryサーバー・プロセスの管理」を参照してください。

A.3 構成ファイルの場所

10gリリース(10.1.4.x):

- 構成ファイルの場所: ORACLE_VIRTUAL_DIRECTORY_HOME/conf

11gリリース1(11.1.1):

- 構成ファイルの場所: ORACLE_INSTANCE/config/OVD/ovd1

A.4 プラグイン・ファイルの場所

10gリリース(10.1.4.x):

- プラグイン・ファイルの場所: ORACLE_VIRTUAL_DIRECTORY_HOME/plugins/lib

11gリリース1(11.1.1):

- Oracle Virtual Directoryに含まれるデフォルト・プラグイン・ファイルの場所: ORACLE_HOME/ovd/plugins/lib

- カスタム・プラグイン・ファイルの場所: ORACLE_INSTANCE/OVD/ovd1/plugins/lib

A.5 デプロイされたマッピング・ファイルの場所

10gリリース(10.1.4.x):

- デプロイされたマッピング・ファイルの場所:
ORACLE_VIRTUAL_DIRECTORY_HOME/mappings

11gリリース1(11.1.1):

- デプロイされたマッピング・ファイルの場所:
ORACLE_INSTANCE/OVD/ovd1/mappings

A.6 ログ・ファイルの場所

10gリリース(10.1.4.x):

- ログ・ファイルの場所:

- ORACLE_VIRTUAL_DIRECTORY_HOME/log/vde.log

- ORACLE_VIRTUAL_DIRECTORY_HOME/log/vde.log.exception

11gリリース1(11.1.1):

- ログ・ファイルの場所:
ORACLE_INSTANCE/diagnostics/logs/OVD/ovd1/diagnostic.log

A.7 ローカル・ストア・アダプタのデータ・ストアの場所

10gリリース(10.1.4.x):

- ローカル・ストア・アダプタのデータ・ストアの場所:
ORACLE_VIRTUAL_DIRECTORY_HOME/data

11gリリース1(11.1.1):

- ローカル・ストア・アダプタのデータ・ストアの場所:
ORACLE_INSTANCE/OVD/ovd1/data

A.8 スキーマ・ファイルの場所

10gリリース(10.1.4.x):

- スキーマ・ファイルの場所: ORACLE_VIRTUAL_DIRECTORY_HOME/conf

11gリリース1(11.1.1):

- スキーマ・ファイルの場所:

- ORACLE_HOME/ovd/schema

- ORACLE_INSTANCE/config/OVD/ovd1/schema.user.xml

A.9 Oracle Virtual Directoryサーバーのライブラリの場所

10gリリース(10.1.4.x):

- Oracle Virtual Directoryサーバーのライブラリの場所:
ORACLE_VIRTUAL_DIRECTORY_HOME/server/lib

11gリリース1(11.1.1):

- Oracle Virtual Directoryサーバーのライブラリの場所:

- ORACLE_HOME/ovd/jlib

- ORACLE_HOME/ovd/adapters/lib

注意:
Oracle Virtual Directoryアダプタのライブラリは、別のJARファイルにあります。

A.10 Oracle Virtual Directoryサーバーのデバッグの有効化

10gリリース(10.1.4.x):

- Oracle Virtual Directoryサーバーのデバッグを有効化するには、Oracle Virtual Directory Managerインタフェースを使用して、ログ・レベルをDebugまたはDumpに設定します。

11gリリース1(11.1.1):

- Oracle Virtual Directoryサーバーのデバッグを有効化するには、Fusion Middleware ControlまたはWLSTを使用して、デバッグのログ・レベルをTRACE:1に設定するか、またはダンプのログ・レベルをTRACE:32に設定します。

関連項目:
詳細は、「Oracle Virtual Directoryのロギングの管理」を参照してください。

A.11 グラフィカル・ユーザー・インタフェース

10gリリース(10.1.4.x):

- Oracle Virtual Directory Manager(DME)

11gリリース1(11.1.1):

- Fusion Middleware Control

- Oracle Directory Service Manager

関連項目:
前述のグラフィカル・ユーザー・インタフェースの詳細は、次の項を参照してください。

- 「Fusion Middleware Control」

- 「Oracle Directory Services Manager」

A.12 コマンドライン・ツール

10gリリース(10.1.4.x):

- vde.sh(UNIX/Linuxプラットフォーム)およびOViDserver.exe(Windowsプラットフォーム)。

11gリリース1(11.1.1):

- opmnctl

- WebLogic Scripting Tool(WLST)

- syncovdconfig

関連項目:
前述のコマンドライン・ツールの詳細は、次の項を参照してください。

- 第10章「Oracle Virtual Directoryサーバー・プロセスの管理」

- 「WLSTを使用したOracle Virtual Directoryの管理の開始」

- 「syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー」

A.13 クラスパスの更新

10gリリース(10.1.4.x):

- vde.sh(UNIX/Linuxプラットフォーム)およびOViDserver.lax(Windowsプラットフォーム)。

11gリリース1(11.1.1):

- ovd1コンポーネントの java-classpathの更新の場合、ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml。

A.14 2つのOracle Virtual Directoryコンポーネントの同期化

10gリリース(10.1.4.x):

- すべての構成ファイルとデータファイルを手動でコピー

11gリリース1(11.1.1):

- syncovdconfigコマンドライン・ツール

関連項目:
詳細は、「syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー」を参照してください。

A.15 監査の構成

10gリリース(10.1.4.x):

- ログ・ファイル・パスへのアクセス

11gリリース1(11.1.1):

- フィルタの事前設定

- 監査ログのローテーション

- パージ

関連項目:
詳細は、「Oracle Virtual Directoryの監査の管理」を参照してください。

A.16 監査ログの場所

10gリリース(10.1.4.x):

- ORACLE_VIRTUAL_DIRECTORY_HOME/log/access.log(デフォルト)

11gリリース1(11.1.1):

- ORACLE_INSTANCE/auditlogs/OVD/ovd1/audit.log

A.17 サポートされているカスタマイズ

Pythonスクリプト・マッピングは、既存のデフォルト・マッピング・スクリプトを除いて、Oracle Virtual Directory 11gではサポートされなくなりました。かわりに、JavaプラグインAPIを使用してカスタマイズを実行します。

B Oracleスタックの起動と停止

Oracleスタックのコンポーネントは、特定の順序で起動および停止する必要があります。この付録では、その順序を説明します。この付録の内容は次のとおりです。

- B.1項「スタックの起動」

- B.2項「スタックの停止」

注意:
次のトピックの説明に従って、スクリプトを実行してWebLogicの管理コンポーネントを起動および停止する場合(スクリプトはそれぞれ、startManagedWebLogic.shおよびstopManagedWebLogic.sh)は、次のことに注意してください。

- DOMAIN_NAMEのデフォルト値は、IDMDomainです。

- SERVER_NAMEは、Oracle WebLogic Managed Serverの名前を表します。デフォルト値はwls_ods1です。

- スクリプトを実行するときに、USER_NAMEおよびPASSWORDをオプションとして指定しないと、これらの値の入力を求められます。

- スクリプトを実行するときに、ADMIN_URLをオプションとして指定しないと、この値は継承されます。

B.1 スタックの起動

スタック・コンポーネントは、次の順序で起動します。

1. 次のコマンドを実行して、Oracle WebLogic Administration Serverを起動します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startWebLogic.sh

注意:
コマンドラインからOracle WebLogic管理サーバーを起動すると、それはフォアグラウンドで実行され、出力が画面に送られます。

2. ノード・マネージャが実行されていることを確認します。通常、Oracle WebLogic Administration Serverがノード・マネージャを起動します。ノード・マネージャが実行されていない場合、次のコマンドを実行してこれを起動します。

MW_HOME/wlserver_10.3/server/startNodeManager.sh

3. 次のコマンドを実行して、Oracle Internet Directory、Oracle Virtual Directoryなどのシステム・コンポーネントを起動します。

ORACLE_INSTANCE/bin/opmnctl startall

次のコマンドを実行すると、システム・コンポーネントが起動したことを確認できます。

ORACLE_INSTANCE/bin/opmnctl status -l

4. 次のコマンドを実行して、WebLogicの管理対象コンポーネント(Oracle Directory Services Managerなど)を起動します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startManagedWebLogic.sh \
SERVER_NAME {ADMIN_URL}

注意:
Oracle WebLogic管理コンソールを使用して、バックグラウンドで管理対象コンポーネントを起動できます。詳細は、『Oracle WebLogic Serverの紹介』を参照してください。

B.2 スタックの停止

Oracle WebLogic管理コンソールを使用して、Oracle WebLogic Administration Serverおよびすべての管理対象サーバーを停止できます。詳細は、『Oracle WebLogic Serverの紹介』を参照してください。

コマンドラインからスタック・コンポーネントを停止するには、次の手順を実行します。

1. 次のコマンドを実行して、WebLogicの管理対象コンポーネント(Oracle Directory Services Managerなど)を停止します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/stopManagedWebLogic.sh \
{SERVER_NAME} {ADMIN_URL} {USER_NAME} {PASSWORD}

2. 次のコマンドを実行して、Oracle Internet Directory、Oracle Virtual Directoryなどのシステム・コンポーネントを停止します。

ORACLE_INSTANCE/bin/opmnctl stopall

3. 次のコマンドを実行して、Oracle WebLogic Administration Serverを停止します。

MW_HOME/user_projects/domains/DOMAIN_NAME/bin/stopWebLogic.sh

4. ノード・マネージャを停止するには、killコマンドを使用します。

kill -9 pid

C HTTPリスナーのWebゲートウェイ・サービス

Oracle Virtual DirectoryのHTTPリスナーは、HTMLベースのゲートウェイを提供します。これは、Webゲートウェイと呼ばれ、DSMLおよびXSLTによりレンダリングされるディレクトリ・レポートを提供します。WebゲートウェイのDSML機能は、OracleのURLベースの問合せゲートウェイに基づきます。これは、URLベースの操作に基づいてDSML形式のXMLの結果を戻します。DSMLv2サービスは、HTTPリスナーのDSML V2サービスを通じて別に提供されます。

この付録では、HTTPリスナーのWebゲートウェイについて説明します。この付録の内容は次のとおりです。

- 第C.1項「Webゲートウェイの機能と特徴」

- 第C.2項「デモンストレーション・ディレクトリ・ブラウザ」

- 第C.3項「Webゲートウェイのアーキテクチャ」

- 第C.4項「DSMLおよびXSLT LDAPの問合せパラメータ」

- 第C.5項「Webゲートウェイ・コマンド」

- 第C.6項「セキュリティ・コンテキスト」

- 第C.7項「XSLスタイルシートの使用方法」

C.1 Webゲートウェイの機能と特徴

DSMLおよびXSLTによりレンダリングされるディレクトリ・レポートに加え、Webゲートウェイには、静的なWebコンテンツを処理する機能があり、複雑なディレクトリ・ホワイト・ページ、委任管理およびセルフサービス機能を作成できます。

次に、Webゲートウェイの機能をリストします。

- Oracle Virtual Directoryのディレクトリ・サービスとの動的な統合。

- 認証および認可が可能なLDAP統合を使用したApacheに類似のセキュリティ

- XHTML、DSML、WMLまたは任意のXML派生形式で出力内容がレンダリングされる動的XSLT変換。

- 一般的なHTMLファイルなどの静的コンテンツのサポート。

- 追加、変更、削除など、すべてのLDAP操作がサポートされるフォームベース入力の拡張サポート。

- jpegphotoまたはusercertificateなどのバイナリ属性を取得するための拡張サポート。

- Oracle Virtual DirectoryのDoS保護メカニズムの統合サポート。

C.2 デモンストレーション・ディレクトリ・ブラウザ

Oracle Virtual Directoryでは、XSLTリスナーのXMLサービスの機能を説明するデモンストレーション・ディレクトリ・ブラウザがhtdocsディレクトリに用意されています。このデモンストレーション・ディレクトリ・ブラウザは、本番環境向けの高度なツールとしては設計されていませんが、開発者が確認や特定の目的での拡張を行うためのサンプル・コードとして提供されています。

注意:
Oracle Virtual Directoryに関するコーディング・レベルのサポートは行っていません。ただし、開発支援を行うためのコンサルティング・サービス・プログラムを介して支援を行うことができます。

C.3 Webゲートウェイのアーキテクチャ

Webゲートウェイは、広く普及しているオープン・ソースのApache AXISおよびTomcatサーバーで使用されるJettyサーバーに基づいています。Jettyサーバーは、特別な目的の製品に埋め込むために設計された拡張可能なサーバーです。次に、Webゲートウェイ・アーキテクチャのコンポーネントを説明します。

- DSMLサーブレット

- XSLTサーブレット

- ハンドラ

C.3.1 DSMLサーブレット

DSMLサーブレットではリクエストを受信すると、Oracle Virtual Directoryの内部APIがコールされるため、リクエストはリスナーからのものであるように処理されます。次に示すように、適切な問合せを伴う/dsml接頭辞を使用して、ディレクトリに標準のDSMLコンテンツに関する問合せを実行できます。

http://localhost:8080/dsml/directory?base=o=myorg.com&scope=base&filter=objectclass=*

リスナーがURLを受信すると、問合せはHTTPセッションのコンテキストで処理されます。ユーザー・セキュリティ・プリンシパルが存在しない場合、問合せは匿名の問合せとして扱われます。問合せが処理されると、結果は、DSML標準形式でHTTPクライアントに戻されます。

directoryをサーバー・ディレクトリ・コンテキストに置き換えることで、セキュリティ・コンテキストを確立できます。DSMLのセキュリティ・コンテキストは、htdocsの適切なサブディレクトリに.htaccessファイルを作成することで確立できます。たとえば、限定した問合せドメインを設定するには、.htaccessファイルを/htdocs/dsml/administratorsディレクトリに配置します。これにより、http://localhost:8080/dsml/administratorsに対する問合せは、/htdocs/dsml/administrators/.htaccessaccessファイルに指定されたアクセス要件を満たします。

C.3.2 XSLTサーブレット

XSLTサーブレットを使用すると、HTMLの表示方法を制御できます。サーブレットには、ディレクトリにコンテンツを問い合せ、指定されたXSLT変換ファイルに応じてコンテンツを変換する機能があります。

XSLTサーブレットでは、ディレクトリ問合せと、特殊な処理を可能にする特別なコマンドの両方がサポートされています。次に例を示します。

http://localhost:8080/search/results.xsl?params=...

.xslファイル接尾辞はXSLTサーブレットであることを示します。/search/results.xslは、結果のレンダリングに使用されるXSL変換ファイルを指定し、/htdocs/search/results.xslに自動的にマップされます。

C.3.3 ハンドラ

- DoSハンドラ: すべてのリクエストが、(vde.propで定義されている)DoSマネージャの割当て全体に対して、サブジェクト名とIPアドレスで追跡されます。割当て制限を超えるイベントの間、サーバーは原因であるクライアントに反応しなくなります。これにより、過剰にアクティブなクライアントまたはDoS攻撃からWebサービスが保護されます。

- LDAPUserRealm: LDAPUserRealmはHTAccessHandlerと連携して、Webゲートウェイをディレクトリ・サービス(Oracle Virtual Directory)と統合します。LDAPUserRealmは、ディレクトリに対するユーザー認証を実行し、識別名マッピングに対するUIDの提供などの他の操作のユーザー・コンテキストを追跡します。

- HTAccessHandler: このハンドラは、リクエストされた各リソースを確認し、そのリソース・ディレクトリまたは親ディレクトリで.htaccessファイルを検索することでApacheのようなWebサーバー・アクセス制御を提供します。.htaccessファイルが見つからない場合は、/conf/htaccess.propで指定されているデフォルトのアクセス制御が使用されます。現行ユーザーのコンテキストが現行のリソースの参照を認可されていない場合には、HTAccessHandlerによりHTTPクライアントにアクセスが拒否されたというレスポンスが戻されます。ブラウザがユーザーIDおよびパスワードを使用して応答すると、LDAPUserRealmサービスにより、認証目的でのHTAccessHandlerによる参照が可能なLDAPユーザー・プリンシパルが自動的に作成されます。
詳細は、「セキュリティ・コンテキスト」を参照してください。

- サーブレット・ハンドラ: サーブレット・ハンドラは.xslで終わるURLリクエストをWebゲートウェイ・サーブレットに送り、/dsmlで始まるURLリクエストをDSMLサーブレットに送ります。Webゲートウェイ・サーブレットではXSLT書式の結果を提供し、ディレクトリ問合せおよびエントリ変更操作の両方をサポートしています。DSMLサーブレットには、単純なディレクトリ問合せ機能およびDSML書式のレスポンス機能があります。

- リソース・ハンドラ: その他すべてのリクエストは、ドキュメント・リソース・リクエストとして扱われます。リソースがサーバーのhtdocsドキュメント・ルートに配置されている場合、ドキュメントはHTTPクライアントに戻されます。htmlやgifファイルなどの静的コンテンツは、標準的なWebサーバー上と同様に、リソース・ハンドラ経由でWebゲートウェイによって処理できます。静的コンテンツのアクセス制御は、ドキュメント・ディレクトリまたは親ディレクトリの.htaccessセキュリティ構成ファイルの存在に基づいて実行されます。Oracle Virtual Directoryインストールのhtdocsディレクトリにある静的ドキュメントは、直接メイン・サーバー・ルートにマップされます。たとえば、/htdocs/index.htmlはhttp://localhost:8080/index.htmlにマップします。

C.4 DSMLおよびXSLT LDAPの問合せパラメータ

Webゲートウェイでは、次に示すDSMLおよびXSLT LDAP問合せパラメータがサポートされています。

base=[dn]

検索が開始されるベースの識別名です。空の場合はNULLとみなされます。

filter=[searchfilter] ]

LDAP標準の検索フィルタ。空の場合は、"(objectclass=*)"とみなされます。

scope=[base|onelevel|sub] ]

検索の有効範囲。baseは、baseに指定したエントリのみを検索することを指定します(エントリを直接指定する場合に便利です)。onelevelは、検索でベースDNのすぐ下の子エントリのみを確認することを指定します。サブツリーは、ベースDNのすべての子が検索されることを指定します。デフォルトでは、有効範囲はbaseに設定されています。

binddn=[userDN]

検索の実行基準となるユーザー識別名。空の場合は、デフォルトで匿名とみなされます。

password=[password]

binddnアカウントと関連付けられたパスワード。通常、このパラメータは、binddnとともに指定されます。

xsl=[xsl-file](非推奨)

このパラメータは、XSLTサーブレットにのみ適用され、DSMLサーブレットでは無視されます。指定されている場合、Oracle Virtual Directoryのルート・インストール・ディレクトリに関連するファイルが参照されます。HTMLファイルはhtdocsディレクトリに関連します。空の場合、デフォルト値はconf/html.xslです。

[any]=[value]

XSLTサーブレットは、ユーザーが指定するその他のパラメータを受け入れます。コンテキスト情報(parentname="Home"など)を指定するために、XSLスタイルシートにパラメータを渡す場合に便利です。

C.5 Webゲートウェイ・コマンド

Webゲートウェイ・コマンドは、バイナリ属性の取得、フォームベースの検索やフォームベースのエントリ操作などの追加機能を提供します。次に、各Webゲートウェイ・コマンドを説明します。

- バイナリ属性の取得コマンド

- フォームベースの検索コマンド

- フォームベースのエントリ操作コマンド

- HTTP POST

- HTTP GET

C.5.1 バイナリ属性の取得コマンド

getcertおよびgetphotoコマンドを使用して、DSMLでエンコードされるのとは対照的に、バイナリ属性をネイティブのバイナリ形式で取得します。getcertのコールからは、MIMEタイプがapplication/x-x509-email-certのhttpコンテンツが戻されます。同様に、getphotoのコールからはMIMEタイプがimage/jpegのコンテンツが戻されます。

cmd=getcert

dnおよびattrパラメータによって指定されている証明書を取得します。次に例を示します。

http://localhost:8080/xslt/search/?cmd=getcert&dn=uid=jsmith,ou=people,
o=airius.com&attr=usercertificate

cmd=getphoto

dnおよびattrパラメータによって指定されているjpegphotoを取得します。

dn=[distinguished name]

エントリの識別名を指定します。通常は、コマンド・パラメータとともに使用します。

attr=[attribute name]

getcertまたはgetphotoコマンドに関して属性名を指定します。

C.5.2 フォームベースの検索コマンド

LDAPのようなXSLT/DSML形式の検索を実行することは可能ですが、cmd=searchオプションを使用するとわかりやすい検索フォームをより柔軟にサポートできます。このコマンドは、フォーム値を受け取って、コンテンツを標準のディレクトリ問合せに変換します。

cmd=search

関連するパラメータ、base、scope、kind、searchvalueおよびfilterattrsを使用するフォームベース検索をサポートします。このコマンドは、フォーム・パラメータから検索フィルタが自動的に作成される検索フォームのプログラミングをより簡単にするよう設計されていることを除き、XSLT問合せフォームに類似の機能を提供します。次に例を示します。

http://localhost:8080/xslt/search/results.xsl?cmd=search&base=o=airius.com&scope=
sub&kind=all&filterattrs=cn,sn,givenname&searchvalue=smith

base=[distinguished name]

フォームベース検索コマンドの検索ベースを指定します。

scope=[base|one|sub]

検索の有効範囲を指定します。有効な値は、base、one、subです。

kind=[all|attrname]

特定の属性と、filterattrsパラメータに指定されているすべての属性のどちらに基づいて検索フィルタを作成するかを指定します。

filterattrs=[attr1,attr2,…]

検索する属性のリスト。

searchvalue=[user searchstring value]

ユーザーが検索文字列値として入力した値。

検索フォームのアクションは、GETまたはPOSTとして作成されます。次に、検索フォームによって生成されたGETリクエストの例を示します。

http://localhost:8080/xslt/search/results.xsl?cmd=search&base=o=airius.com&scope=
sub&kind=all&filterattrs=cn,sn,givenname&searchvalue=smith

このコマンドはサーバーによって解釈され、次の内容と同等のものとして処理されます。

http://localhost:8080/xslt/search/results.xsl?base=o=airius.com&scope=sub&filter=(|(cn=*smith*)(sn=*smith*)(givename=*smith*))

問合せの処理後、XSLファイル/xslt/search/results.xslを使用して結果が変換されます。

C.5.3 フォームベースのエントリ操作コマンド

変更コマンドを使用すると、ディレクトリ・エントリの変更に使用可能なhtmlフォームを作成できます。このコマンドには、実際にLDAPディレクトリ・エントリを追加、削除または変更する機能があります。

attrs、changetype、objectclassなどの一部のフォーム・パラメータは、非表示フィールドとして提供される場合があります。新規エントリの追加時には、必ずobjectclass属性(通常は非表示フィールドとして提供)を指定してください。

注意:
以降の項で使用されているattrxは、任意の有効なLDAP属性を表します。

cmd=modify

クライアントがディレクトリ・エントリの変更をリクエストしたことを示します。変更のタイプは、changetypeフィールドで指定します。

changetype=[add|modify|delete]

ディレクトリ・エントリで実行する操作(追加、変更または削除)を指定します。操作で変更できるディレクトリ・エントリは1つのみです。

changetype=addを使用して新規エントリを追加するときは、attrx_modify=[value]値のみが処理されます。エントリの削除時には、すべてのattrxパラメータが無視されます。dnフォーム値を複数指定すると、複数のLDAPエントリを削除できます。

dn=[distinguished name]

追加、編集または削除されるエントリの識別名。

modify_attrs=[attr1,attr2,attr3]

フォームから処理される属性のリスト。このリストは、フォーム上のその他すべての属性パラメータ(attr1_type、attr1_action、attr1_new、attr1_confirmなど)の検索に使用されます。

xslerror=[/dir/error.xsl]

処理エラーが発生した場合にエラーを送るxslファイルを指定します。エラーが発生すると、XSLフォームは、指定されているすべてのフォーム・パラメータと、resultおよびmessageパラメータを渡します。これらは、エンド・ユーザーに表示する適切なエラー・メッセージを決定するために、error.xslで解析されます。

attrx_type=[single|multi|photo|cert]

attrxで表される属性のタイプを定義します。singleの場合は、attrxの最初の値のみが受け入れられます。certまたはphotoの場合は、マルチパート・フォームの一部としてバイナリ値が配置されます。一度に追加できる値は1つです。

attrx_required=[true|false]

trueに設定すると、attrxに値が指定されていることがプロセッサにより検証されます。

attrx_delete=[value]

attrxから削除する値です。1つ以上の値を指定できます。空の値は無視されます。

attrx_modify=[value]

attrx属性の変更に使用する値です。attrx_actionの値に応じて、この値がattrxに追加されるか、attrxのすべての値を置き換えます。

attrx_action=[add|replace]

attrx_modifyの値をattrxに追加するか、既存の値をすべて置き換えるかを指定します。changetype=addの場合、attrx_actionは強制的にaddになります。

rdn_attr=[attr]

add操作では、dnは親エントリとみなされ、rdn_attrはrdn値として使用する属性をプロセッサに伝えます。

C.5.4 HTTP POST

HTTP POSTは、HTTP GETのかわりに使用できます。DoS攻撃またはバッファ・オーバーフロー攻撃を防ぐため、Listeners.propファイルには最大入力ファイル・サイズを設定できます。バイナリ属性(jpegphotosおよびcertificatesなど)をアップロードするときは、RFC 1867に従ってマルチパート・フォームを使用します。

C.5.5 HTTP GET

HTTP GET操作を使用すると、すべてのパラメータがURLとして渡され、URLにブックマークを付けることができます。ただし、binddnなどの機密情報がURLで入手できるようになります。そのため、匿名以外の問合せにはHTTP POSTを使用します。

GETを使用するときは、アンパサンド(&)および空白を適切にエスケープしてURL要件に準拠する必要があります。これにはjavaScriptを追加して、発行前のフィールド・パラメータを変更する必要があります。一般的に、アンパサンド(&)は&amp;に置き換える必要があります。

C.6 セキュリティ・コンテキスト

HTAccessHandlerを使用すると、サーバー内にセキュリティ・コンテキストを定義できます。セキュリティ・コンテキストでは、サーバー上の特定のリソース・ディレクトリへのアクセスを許可するIPアドレス、サブジェクトまたはグループを定義します。セキュリティ・コンテキストは、htdocsディレクトリまたは任意のサブディレクトリに.htaccessセキュリティ構成ファイルを作成することで作成できます。各.htaccessファイルは、ファイルが存在するディレクトリおよびその下の子ディレクトリに適用されます。直下のディレクトリまたは最も近い親の.htaccessファイルは、任意のリソースに適用されるファイルです。デフォルトのセキュリティ・コンテキストは、/conf/htaccess.propファイルを編集して定義できます。

次の項で、セキュリティ・コンテキストをより詳細に説明します。

- .htaccessファイルの要件

- .htaccessファイルのディレクティブ

- リソースの制限

- セキュリティ・コンテキスト・ファイルの例

C.6.1 .htaccessファイルの要件

次に示すのは.htaccessファイルの要件の一覧です。

- .htaccessファイルはプレーン・テキスト・ファイルであることが必要です。

- 有効なディレクティブではないコンテンツには接頭辞としてコメント(#)文字が必要です。

- .htaccessファイルのディレクティブは現行ディレクトリまたは子ディレクトリにのみ適用されます。

- サブディレクトリまたは子ディレクトリに.htaccessファイルが含まれる場合は、親ディレクトリの.htaccessファイルが上書きされます。

C.6.2 .htaccessファイルのディレクティブ

次に示すのは、.htaccessファイルでサポートされているディレクティブです。

AuthUserFile [filename]

CRYPTハッシュで暗号化されたユーザーとパスワードのリストを含むテキスト・ファイルを使用して、ユーザーを認証することを示します。例については、例C-2を参照してください。

AuthUserLDAP [base]

ユーザーがOracle Virtual Directoryサーバーから認証されることを示します。baseは、認証されるユーザーの検索ベースの識別名を指定します。

AuthGroupFile [filename]

ユーザーがfilenameによって指定されているグループ・ファイルのメンバーであることが必要なことを示します。例については、例C-3を参照してください。

AuthName [name]

認証レルムの名前を設定します。ディレクトリ・ブラウザなど、ユーザーへのチャレンジで表示されるテキストです。

<Limit>

[restrictions]

詳細は、「リソースの制限」を参照してください。

</Limit>

リソース制限ブロックを定義します。制限は、トークン<Limit>と</Limit>の間に配置されます。

C.6.3 リソースの制限

リース制限は、<Limit>文の間に配置します。次の制限がサポートされています。

satisfy [all|any]

すべてまたはいずれかの要件を満たす必要があるかどうかを指定します。

require [user|valid-user|group|ldapgroup] [entities]

ユーザーが次のいずれかのメンバーであることが必要なことを示します。

- user: AuthUserFileまたはAuthUserLDAPのメンバー

- valid-user: 任意の検証済のユーザー

- group: AuthUserGroupのメンバー

- ldapgroup: LDAPグループのメンバー

entitiesは、丸カッコ()で囲まれているldapgroupか、ユーザー名またはグループの明示的なリストを指定します。

order [allow,deny|deny,allow|mutual-failure]

次のように、ルールを許可および拒否するためのルールの優先度を指定します。

- allow,deny: denyリストではなくallowリストに存在する必要があることを意味します。

- deny,allowまたはmutual-failure: denyリストに存在しない場合、またはallowリストに存在する場合に許可します。

allow from [ip address list]

リクエストを許可するための、空白で区切られたIPアドレスのリストを指定します。

deny from [ip address list]

リクエストを拒否するための、空白で区切られたIPアドレスのリストを指定します。

C.6.4 セキュリティ・コンテキスト・ファイルの例

ここでは、セキュリティ・コンテキスト・ファイルの例を示します。例C-1は、.htaccessファイルの例です。

例C-1 .htaccessファイルの例

# HTAccess example.
#
AuthName "Airius Directory Browser"
AuthType Basic
#AuthUserFile /etc/htpasswd
AuthUserLDAP ou=People,o=Airius.com
AuthGroupFile /etc/htgroup
<Limit>
satisfy any
require ldapgroup (cn=a group,ou=groups,o=Airius.com)
require ldapgroup (cn=alternate group,ou=groups,o=Airius.com)
order deny,allow
deny from 192.168.0.3 192.168.0.4
</Limit>

例C-2はhtpasswdファイルの例です。

例C-2 htpasswdファイルの例

# <PRE>
# HTPassword example.
#
# Passwords must be in CRYPT format
#
admin: adpexzg3FUZAk
tom: tofn8Rh1L.xhQ
dick: diF1tp4K2rvw.
harry: haVyKPUXAHTjA

例C-3はhtgroupファイルの例です。

例C-3 htgroupファイルの例

# HT Group example.
# Place uid values after group name
#
Users: tom dick harry jturner
TestGroup: tom harry
AdminGroup: admin

C.7 XSLスタイルシートの使用方法

ここでは、XSLスタイルシート・テンプレートの使用方法を説明します。

- 動的グループを作成するためのXSLTサーブレット問合せの使用

- メディア・タイプ属性に基づいたコンテンツ・タイプ・サーブレットの設定

- XSLのDocument()コマンドおよびImport/Includeコマンドのサポート

- XSLスタイルシートへのパラメータの受渡し

- XSLの例

C.7.1 動的グループを作成するためのXSLTサーブレット問合せの使用

XSLT問合せをスタイルシートと組み合せて使用し、クライアント用の編集フォームを作成できます。次に例を示します。

http://localhost:8080/manage/edit.xsl?base=ou=Atlanta,o=myorg.com&scope=base&filter=objectclass=*&mode=edit

このURLにより、サーバーはディレクトリ・エントリou=Atlanta,o=myorg.comを取得し、それを/manage/edit.xslのxslフォームに渡します。

xslフォームの内部でmodeパラメータを探して、結果のレンダリング方法を決定します。この場合、editは、問合せによって戻されるオブジェクトを編集できるようにフォームをレンダリングする必要があることを意味します。addchildモードは、組織への子エントリの追加に使用できるフォームを準備するために使用されます。

新しいmodeパラメータを作成できます。XSLの場合、modeは、様々なレンダリング・サブルーチンに対して異なるロジックを存在させるために、テンプレートで頻繁に使用される特別なパラメータです。デフォルトの出荷デモンストレーション・アプリケーションでは、htdocs/xslt/secure/admin.xslの1つのスタイルシート内に複数モードの編集(表示、追加、変更、削除)が用意されています。

C.7.2 メディア・タイプ属性に基づいたコンテンツ・タイプ・サーブレットの設定

XSLTスタイルシートを使用してデータを処理してHTMLにする場合、Oracle Virtual Directory Webゲートウェイによってメディア・タイプ属性についてxsl:outputタグが調査されます。それが存在している場合は、Webゲートウェイによってコンテンツ・タイプ・サーブレットが、メディア・タイプ属性と同じ設定に設定されます。メディア・タイプ属性がxsl:outputタグに存在しない場合は、コンテンツ・タイプ・サーブレットではデフォルトでtext/htmlが使用されます。

C.7.3 XSLのDocument()コマンドおよびImport/Includeコマンドのサポート

Oracle Virtual DirectoryのXSLTサーブレットのプロセッサは、document()コマンドをサポートします。完全なドキュメントURLまたはファイル仕様を指定できます。ディレクトリまたはドキュメントのみを指定すると、htdocsドキュメント・ルートの場所に対する相対位置とみなされます。

たとえば、vdexsl.xmlファイルを使用して、LDAP属性名をよりわかりやすい名前に変換するとします。

<xsl:variable name="lname"
select="translate(@name,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz')"/>
<xsl:variable name="prettyname"
select="document('xslt/vdexsl.xml')/vdexsl:vdexsl/vdexsl:fields/vdexsl:attr[@name=$lname]/vdexsl:
displayname"/>

document()コマンドを使用して取得されたファイルは、パフォーマンスのために自動的にキャッシュされます。同様に、xsl:importおよびxsl:includeコマンドもサポートされ、グローバル・サブルーチンをXSLテンプレートにインポートするために使用されます。document()コマンドと同様に、任意のURLまたはファイルを参照できます。デフォルトで、ファイル参照はhtdocsドキュメント・ルートの場所が基準になります。次に2つの例を示します。

<xsl:import href="http://192.168.0.2:8050/lib/globals.xslt"/>

<xsl:import href="lib/globals.xslt"/>

注意:
HTTPを使用してOracle Virtual Directoryからスタイルシートを取得する場合、.xslファイル接尾辞を使用すると、XSLTサーブレットが干渉し、問合せの一部であるかのようにxslファイルをレンダリングします。別のOracle Virtual Directoryから未処理のXSLファイルを取得するには、接尾辞名が.xsl以外であることが必要です。前の例では、かわりに.xsltディレクトリが使用されています。

C.7.4 XSLスタイルシートへのパラメータの受渡し

XSLTサーブレットは、渡されたすべてのパラメータをXSLスタイルシートで使用できるようにします。これにより、DSML検索結果には存在しないコンテキスト情報をXSLスタイルシートで受信できるようになります。パラメータは、有効な検索パラメータの一部またはこの目的で定義されたパラメータです。次のコード例では、parentnameおよびbaseパラメータが取得されて、XSLコード内で変数として使用できるようになっています。

…
<xml:output method="html" indent="yes"/>
<xsl:param name="parentname" select="'Root'"/>
<xsl:param name="base" select="'base'"/>
<xsl:template match="/">
<html>
…

xsl:param文のselect部分は、存在しない場合にはデフォルト値を表します。

C.7.5 XSLの例

次に示す例C-4は、ディレクトリ・ナビゲーション・バーを作成するように設計されています。XSLプログラミングの詳細は、XSLTのガイドを参照してください。例C-4では、コンテキストを確立するために2つのパラメータが使用されています。parentnameおよびbaseパラメータは、ツリー内を上下に移動できるようにするための、親エントリ名の記録に使用されます。親の親DNは、現行のbase問合せパラメータからRDNを削除することで推測できます。

例C-4 XSLの例

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/TR/REC-html40"
xmlns:dsml="http://www.dsml.org/DSML">
<xml:output method="html" indent="yes"/>
<xsl:param name="parentname" select="'parentname'"/>
<xsl:param name="base" select="'base'"/>
<xsl:template match="/">
<html>
<head>
<title>Oracle Browser Navigation Bar</title>
</head>
<body bgcolor="#99CCCC">
<xsl:choose>
<xsl:when test="$base = 'base'">
<xsl:variable name="rdn" select="'root'"/>
<xsl:variable name="rvalue" select="'Root'"/>
<xsl:variable name="parentdn" select="'base=&amp;scope=base'"/>
<FONT FACE="Verdana,Arial" size="-1">Root</FONT>
</xsl:when>
<xsl:when test="$base = ''">
<xsl:variable name="rdn" select="'root'"/>
<xsl:variable name="rvalue" select="'Root'"/>
<xsl:variable name="parentdn" select="'base=&amp;scope=base'"/>
<FONT FACE="Verdana,Arial" size="-1">Root</FONT>
</xsl:when>
<xsl:otherwise>
<xsl:variable name="rdn">
<xsl:choose>
<xsl:when test="contains($base,',') = 'true'">
<xsl:value-of select="substring-before($base,',')"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$base"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:variable name="rvalue" select="substring-after($rdn,'=')"/>
<xsl:variable name="parentdn">
<xsl:choose>
<xsl:when test="contains($base,',') = 'true'">base=<xsl:value-of select=
"substring-after($base,',')"/>&amp;scope=onelevel</xsl:when>
<xsl:otherwise>base=&amp;scope=base</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<a href="/xslt?{$parentdn}&amp;filter=(objectclass=*)
&amp;parentname={$parentdn}&amp;xsl=htdocs/
Browser-navbar.xsl" target="leftFrame">
<FONT FACE="Verdana,Arial" size="-1"><xsl:value-of select="$rvalue"/></FONT></a>
</xsl:otherwise>
</xsl:choose>
<table border="0" cellpadding="0" cellspacing="0">
<xsl:apply-templates select="dsml:dsml/dsml:directory-entries/dsml:entry"/>
</table>
</body>
</html>
</xsl:template>
<xsl:template match="dsml:entry">
<xsl:variable name="edn" select="@dn"/>
<xsl:variable name="evalue">
<xsl:choose>
<xsl:when test="contains(@dn,',') = 'true'">
<xsl:value-of select="substring-after(substring-before(@dn,','),'=')"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="substring-after(@dn,'=')"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:if test="@dn = ''">
<xsl:for-each select="dsml:attr[@name='namingContexts']/dsml:value">
<tr><td><li><a
href="/xslt?base={.}&amp;scope=onelevel&amp;filter=(objectclass=*)&amp;parentname
={.}&amp;xsl=htdocs/Browser-navbar.xsl" target="leftFrame"><FONT
FACE="Verdana,Arial" size="-1"><xsl:value-of select="."/></FONT></a>
<FONT FACE="Verdana,Arial" size="-1">[<a
href="/xslt?base={.}&amp;scope=base&amp;filter=(objectclass=*)&amp;xsl=htdocs/res
ults.xsl" target="mainFrame">-></a>]</FONT></li>
</td></tr>
</xsl:for-each>
</xsl:if>
<xsl:if test="@dn > ''">
<tr><td><li><a href="/xslt?base={@dn}&amp;scope=onelevel&amp;filter=(objectclass=*)&amp;parentna
me={$evalue}&amp;xsl=htdocs/Browser-navbar.xsl" target="leftFrame"><FONT
FACE="Verdana,Arial" size="-1"><xsl:value-of select="$evalue"/></FONT></a>
<FONT FACE="Verdana,Arial" size="-1">[<a
href="/xslt?base={@dn}&amp;scope=base&amp;filter=(objectclass=*)&amp;xsl=htdocs/r
esults.xsl" target="mainFrame">-></a>]</FONT></li>
</td></tr>
</xsl:if>
</xsl:template>

D Oracle Virtual Directoryのトラブルシューティング

この付録では、Oracle Virtual Directoryの使用時に発生する可能性のある一般的な問題とその解決策、および問題の診断に関する情報について説明します。この項の内容は次のとおりです。

- 第D.1項「問題と解決方法」

- 第D.2項「Oracle Virtual Directoryの問題の診断」

- 第D.3項「追加情報」

D.1 問題と解決策

この項では、一般的な問題と解決策について説明します。この付録の内容は次のとおりです。

- Oracle Directory Services Managerを起動できない

- Internet Explorer 7を使用してアクセシビリティ・モードでOracle Directory Services Managerにアクセスするときにカーソルに問題がある

- Oracle HTTP Serverを使用したOracle Directory Services Managerのフェイルオーバーが透過的でない

- Oracle Directory Services ManagerがOracle Virtual Directory-Oracle RACデータベース構成に接続できなくなる

- LDAPアダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

- データベース・アダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

- Oracle Virtual DirectoryへのOPMN pingが失敗する

D.1.1 Oracle Directory Services Managerを起動できない

この項では、Oracle Directory Services Managerの起動におけるいくつかの一般的な問題の解決方法を説明します。

問題: Fusion Middleware ControlからOracle Directory Services Managerを起動できない

Oracle Internet Directoryターゲットの「Oracle Internet Directory」メニューから「Directory Services Manager」を選択し、「データ・ブラウザ」、「スキーマ」、「セキュリティ」または「拡張」を選択して、Oracle Enterprise Manager Fusion Middleware ControlからのOracle Directory Services Managerの起動を試みます。

ODSMは開きません。エラー・メッセージが表示される場合があります。

解決策

これはおそらくインストールの問題です。『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。

問題: WebブラウザからOracle Directory Services Managerを起動できない

Webブラウザを使用して、Oracle Directory Services Managerの起動を試行しますが失敗します。

解決策

- Oracle Virtual Directoryサーバーが稼働していることを確認します。Oracle Directory Services ManagerからOracle Virtual Directoryサーバーに接続するには、Oracle Virtual Directoryサーバーが稼働している必要があります。

- 「サーバー」、「ポート」、「ユーザー名」および「パスワード」フィールドに、適切な資格証明を入力したことを確認します。ターゲットのOracle Virtual Directoryサーバーに対してldapbindコマンドを実行すると、サーバー、ユーザー名およびパスワードの資格証明を確認できます。

- サポートされているブラウザを使用していることを確認します。Oracle Directory Services Managerでサポートされているブラウザの詳細は、Oracle Technology Network WebサイトのOracle Identity Management動作要件情報を参照してください。Oracle Technology NetworkのWebサイトには、次でアクセスできます:
http://www.oracle.com/technetwork/index.html

- Oracle Directory Services ManagerのURLで、LDAPポートではなく、管理リスナーのポートを指定していることを確認します。

問題: 複数のNICおよびDHCPを有効化した環境でFusion Middleware ControlからOracle Directory Services Managerを起動できない

Oracle Directory Services ManagerがデプロイされているWebLogic管理対象サーバーで、複数のネットワーク・インタフェース・カードがあるか、またはDHCPが有効です。Oracle Enterprise Manager Fusion Middleware ControlからのOracle Directory Services Managerの起動が失敗し、404 errorsが返されます。

解決策

Oracle Directory Services ManagerのURL内のIPアドレスまたはホスト名にアクセスできるように、WebLogic Server管理コンソールを使用してWebLogic管理対象サーバーのリスニング・アドレスを変更します。

次のステップを実行します。

1. ブラウザを使用して、WebLogic Server管理コンソールにアクセスします。

2. WebLogic Server管理コンソールの左ペインで、「ロックして編集」をクリックしてサーバー構成を編集します。

3. WebLogic Server管理コンソールの左ペインで「環境」を開き、「サーバー」を選択します。

4. 「サーバーのサマリー」ページで、Oracle Directory Services ManagerがデプロイされているWebLogic管理対象サーバーのリンクをクリックします。

5. WebLogic管理対象サーバーの「設定」ページで、「リスニング・アドレス」を、Oracle Directory Services Managerがデプロイされているサーバーのホスト名に更新します。

6. 構成を保存するには、「保存」をクリックします。

7. 「変更のアクティブ化」をクリックして、サーバー構成を更新します。

D.1.2 Internet Explorer 7を使用してアクセシビリティ・モードでOracle Directory Services Managerにアクセスするときにカーソルに問題がある

問題

Internet Explorer 7で、キーボードのみを使用してアクセシビリティ・モードでOracle Directory Services Managerにアクセスすると、カーソルが焦点を失います。この動作は、次のような状況で確認されています。

- SSL有効モードでディレクトリにアクセスし、サーバー証明書が表示されている。

- 無効なパスワードを入力し、エラー・ダイアログが表示されている。

解決策

[Tab]キーを9回押した後、[Enter]キーを押します。

D.1.3 Oracle HTTP Serverを使用したOracle Directory Services Managerのフェイルオーバーが透過的に行われない

問題

Oracle HTTP Serverを使用してOracle Directory Services Managerのフェイルオーバーを実行すると、フェイルオーバーが透過的に行われません。次の手順を実行すると、この動作を確認できます。

1. Oracle Directory Services Managerが、Oracle HTTP Serverを使用して、高可用性アクティブ-アクティブ構成でデプロイされています。

2. Oracle HTTP Serverの名前およびポート番号を使用して、「Oracle Directory Services Manager」ページを表示します。

3. Oracle Virtual Directoryサーバーへの接続を確立します。

4. 現在のOracle Directory Services Manager Oracle HTTP Serverのホストとポートを使用して、Oracle Virtual Directoryサーバーを使用します。

5. WebLogic Server管理コンソールを使用して、一度に1つの管理対象サーバーを停止します。

6. Oracle Directory Services Managerのページとポート、およびOracle Virtual Directoryに対して以前に確立された接続に戻ります。この操作を行うと、「Oracle Directory Services Manager」ページへの接続を再確立する必要があることを示すメッセージが表示されます。

解決策

この問題が発生した場合は、次の手順を実行します。

1. Webブラウザで、現在の「Oracle Directory Services Manager」ページを終了します。

2. 新しいWebブラウザ・ページを起動し、同一のOracle Directory Services Manager Oracle HTTP Serverの名前とポートを指定します。

3. 以前に操作していたOracle Virtual Directoryサーバーへの新しい接続を再確立します。

関連項目:

- 「Oracle WebLogic ServerクラスタでOracle Directory Services ManagerをサポートするためのOracle HTTP Serverの構成」

- 高可性構成でのOracle Directory Services Managerの詳細は、高可用性ガイドを参照してください。

D.1.4 Oracle Directory Services ManagerがOracle Virtual Directory-Oracle RACデータベース構成に接続できなくなる

問題

Oracle Directory Services Managerでは、Oracle RACデータベースを使用しているOracle Virtual Directoryコンポーネントとの接続が一時的に切断されます。Oracle Directory Services Managerに、Failure accessing Oracle database (oracle errcode=errcode)などのメッセージが表示されることがあります。この場合、errcodeは、3113、3114、1092、28、1041、または1012のいずれかです。

解決策

このエラーは、Oracle Virtual Directoryコンポーネントが使用しているOracleデータベースのフェイルオーバー中に発生することがあります。接続は1分以内に再確立され、ログインしなおさずに作業を継続することができます。

D.1.5 LDAPアダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

問題

Oracle Virtual DirectoryがLDAPアダプタとともに構成されており、プロキシ設定されたLDAPサーバーでエントリを確認できます。LDAPクライアントからOracle Virtual Directoryに問合せを行うと、LDAP err=1という操作のエラー・メッセージが戻されます。

解決策

プロキシ設定されたLDAPサーバーが実行されていることを確認します。実行されていない場合は起動し、LDAPクライアントからOracle Virtual Directoryに再度問合せを行います。

D.1.6 データベース・アダプタとともに構成されているOracle Virtual Directoryへの問合せ後にエラーが戻される

問題

Oracle Virtual Directoryがデータベース・アダプタとともに構成されており、プロキシ設定されたデータベースでエントリを確認できます。LDAPクライアントからOracle Virtual Directoryに問合せを行うと、LDAP err=1という操作のエラー・メッセージが戻されます。

解決策

プロキシ設定されたデータベースが実行されていることを確認します。実行されていない場合は起動し、LDAPクライアントからOracle Virtual Directoryに再度問合せを行います。操作のエラー・メッセージがまた戻される場合は、「Oracle Virtual Directoryサーバーへのライブラリのロード」で説明されているように、Oracle Virtual Directoryに各データベースの正しいドライバがロードされていることを確認します。

D.1.7 Oracle Virtual DirectoryへのOPMN pingが失敗する

Oracle Virtual DirectoryへのOPMN pingは、ビジー・システムでは失敗することがあり、失敗するとOPMNによってOracle Virtual Directoryが再起動されます。この状況を回避するには、次の例に示すように
$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlでping間隔を60秒以上に増やします。

<process-type id="OVD" module-id="OVD">
<module-data>
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms2056m -Xmx2056m
-Dvde.soTimeoutBackend=0
-DdisableECID=1
-Didm.oracle.home=$ORACLE_HOME
-Dcommon.components.home=$ORACLE_HOME/../oracle_common
-Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:
$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
</module-data>
<stop timeout="120"/>
<ping interval="60"/>
</process-type>

D.2 Oracle Virtual Directoryの問題の診断

この項では、Oracle Virtual Directoryの問題の診断方法について説明します。この項の内容は次のとおりです。

- ログ・レベルのDEBUGへの引上げ

- Oracle Directory Services Managerを介したOracle Virtual Directoryとの接続の問題

- 診断ログに記録された例外の調査

- Dump Transactionsプラグインを使用したデータ・トランザクション・エラーに関する情報の収集

- 本番環境における問題のトラブルシューティング

- Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryサーバーの監視

D.2.1 ログ・レベルのDEBUGへの引上げ

Oracle Virtual Directoryでエラーが発生した場合、次の手順を実行すると、エラーの発生原因に関するより詳しい情報を収集できます。

1. 「Oracle Virtual Directoryのロギングの管理」を参照して、ログ・レベルをDEBUGに引き上げます。

2. エラーの発生元であるタスクまたはプロシージャを再度実行します。

3. DEBUGレベルを使用して生成されたログ情報を調査します。

D.2.2 Oracle Directory Services Managerを介したOracle Virtual Directoryとの接続の問題

Oracle Directory Services Managerを介したOracle Virtual Directoryとの接続で問題が発生する場合は、スーパーユーザー権限cn=orcladminを持っていることを確認してください。

D.2.3 診断ログに記録された例外の調査

Oracle Virtual Directoryのログ・ファイルに記録された例外の調査は、ターゲット・ディレクトリ、およびカスタム・プラグインやアダプタでのエラーの識別に役立ちます。たとえば、LDAP error=1メッセージを受け取った場合は、診断ログを調査し、host not foundやout of memoryなどのメッセージによってエラーの原因を見つけることができます。

診断ログには、次のディレクトリでアクセスできます。

$ORACLE_INSTANCE/diagnostics/logs/OVD/COMPONENT_NAME/

D.2.4 Dump Transactionsプラグインを使用したデータ・トランザクション・エラーに関する情報の収集

Dump Transactionsプラグインは、各LDAP操作の全トランザクションのレコードを生成し、そのレコードをOracle Virtual Directoryのコンソール・ログに記録します。Dump Transactionsプラグインは、任意のログ・レベルで実行するように構成できます。Dump Transactionsプラグインは、ロジックがOracle Virtual Directoryシステムを通過する際に、マッピングおよび統合作業を診断するのに特に便利です。Dump Transactionsプラグインを使用すると、サーバー・ログ・レベル全体をより詳細なレベルに設定せずに、特定のアダプタの問題を分析できます。Dump Transactionsプラグインは、Oracle Virtual Directoryのプロトコル・アナライザのようなものです。

関連項目:
詳細は、「Dump Transactionsプラグイン」を参照してください。

D.2.5 本番環境における問題のトラブルシューティング

クライアント・アプリケーションにおける問題をトラブルシューティングする場合、特に検索結果(属性やエントリの欠落など)を使用することで問題の原因を判別しようとしている場合は、操作において何が起きているのかを完全に把握することが重要です。

本番環境における問題のトラブルシューティングには、次の方法をお薦めします。

最初に、操作を再実行するためにOracle Virtual Directoryサーバー・インスタンス(DEBUGインスタンスと呼ばれる)を使用可能にしておくことが重要です。たとえば、DEBUGインスタンスが本番サーバー上で実行されている追加のインスタンスであり、サーバーが異なるポートまたはネットワーク構成上で稼動しているためにクライアント・アプリケーションからそれにアクセスできない場合があります。

Oracle Virtual Directory 11gでは、同じシステム上でOracle Virtual Directoryサーバーの複数のインスタンスを簡単に実行できます。管理者は、syncovdconfigツールを使用して、本番サーバー構成とDEBUGインスタンスの同期を保つ必要があります(「syncovdconfigを使用したOracle Virtual Directoryサーバー間での構成ファイルのコピー」を参照)。DEBUGインスタンスによって、管理者は本番サーバーのパフォーマンスを低下させることなく、どのような問題もすばやくデバッグできます。

次に、本番サーバー上のaccess.logを有効にします(「Oracle Virtual Directory固有のロギングの考慮事項」を参照)。問題が発生した場合は、access.logを使用してサーバー上でどの操作を実行中であるのかすばやく判断できます。

次の例は、検索の問題をトラブルシューティングする方法を示しています。このシナリオでは、アプリケーション管理者がユーザー・データの参照で特定の属性が欠落していると報告します。この問題は、次の方法でトラブルシューティングできます。

1. 本番サーバー上で、access.logを確認して次の事項を判別します。

- 何を検索していたか

- 検索にはどのアプリケーションがバインドされていたか

- 使用された検索パラメータ(フィルタと有効範囲)は何か、および検索結果は何であったか

注意:
結果がない(たとえば検索のnentries= valueが0であり、かつerr=0である)場合、フィルタ自体が適切な形式になっていたか確認します。たとえば、管理者がuidに基づいてユーザーjsmithを検索しようとしていた場合は、フィルタがuid=jsmithになっており、かつuid=hsmithなどのタイプミスがないことを確認します。

2. DEBUGインスタンス上で、diagnostic.logトレース・レベルをTRACE:32 (完全なロギング)に設定し、すべてのアダプタにDump Transactionsプラグインを追加します。

3. 検索を再実行します。

注意:
ログインをアプリケーションとしてレプリケートする必要があるときは、場合によってはOracle Virtual Directoryサーバーを構成してこのアカウントが別のテスト・エントリ(ローカル・ストア・アダプタ・エントリに格納されているエントリなど)を使用するようにして、Oracle Virtual Directory管理者がアプリケーション・パスワードを知らなくても問題がないようにする必要があります。

4. 検索を実行した後、DEBUG access.logを確認して、その結果がPRODUCTIONの結果と同じであることを確認します。diagnostic.logに格納されたデータとこの特定の検索をリンクさせるには、ECID値を使用します。
このデータは、Enterprise Managerのログ・マネージャを使用することでリンクできます。また、管理者がEnterprise Managerの外部でコマンドラインでログを読むことを希望する場合はgrepなどのツールを使用することでリンクできます。

問合せに対してECIDを使用すると、この特定の操作に対してOracle Virtual Directoryによって記録されたログ・データをすべて表示できます。このログ・データには次の内容が含まれています。

- ルーティングの選択(操作に対してどのアダプタが選択されたかなど)

- Oracle Virtual Directoryに送信されたデータおよびDump Transactionによって記録された結果

- TRACE:32での実行からのACLの決定などの追加のデータ
たとえば、予期される属性のいくつかをアプリケーションが参照できないという一般的な問題は、ACLによって結果がブロックされることによって発生します。

D.2.6 Fusion Middleware Controlメトリックを使用したOracle Virtual Directoryサーバーの監視

Oracle Enterprise Manager Fusion Middleware ControlのOracle Virtual Directoryの「パフォーマンス・サマリー」ページでは、Oracle Virtual Directoryサーバーの様々なメトリックを時間ベースのコンテキストで表示できます。これらのメトリックを使用して、Oracle Virtual Directoryの監視と問題の診断を行うことができます。

注意:
「パフォーマンス・サマリー」ページに表示されるメトリックは、メトリック・パレットを使用してカスタマイズできます。メトリック・パレットの使用方法の詳細は、管理者ガイドを参照してください。

「パフォーマンス・サマリー」ページでメトリックを表示する手順:

1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、メトリックを表示するOracle Virtual Directoryターゲットにナビゲートします。

2. 「Oracle Virtual Directory」メニューから「監視中」を選択し、「パフォーマンス・サマリー」を選択します。「パフォーマンス・サマリー」ページが表示されます。

表D-1に、「パフォーマンス・サマリー」ページで確認できるOracle Virtual Directoryサーバーのメトリックを示します。

表D-1 Fusion Middleware Controlの「パフォーマンス・サマリー」ページのODVのメトリック

メトリック

説明

CPU使用率(%)

Oracle Virtual Directoryが使用しているCPUの割合を指定します。

その他のCPU使用率(%)

Oracle Virtual Directory以外のコンポーネントが使用しているCPUの割合を指定します。

CPUアイドル時間(%)

Oracle Virtual DirectoryホストのCPUのアイドル時間の割合を指定します。

メモリー使用量(MB)

Oracle Virtual Directoryサーバーによって消費されたメモリー量(MB)を指定します。

メモリー使用率(%)

Oracle Virtual Directoryサーバーによって消費されたメモリーの割合を指定します。

その他のメモリー使用量(MB)

Oracle Virtual Directoryサーバー以外のコンポーネントによって消費されたメモリー量(MB)を指定します。

その他のメモリー使用率(%)

Oracle Virtual Directoryサーバー以外のコンポーネントによって消費されたメモリーの割合を指定します。

空きメモリー(MB)

Oracle Virtual Directoryサーバー・ホスト上の空きメモリー量(MB)を指定します。

空きメモリー(%)

Oracle Virtual Directoryサーバー・ホスト上の空きメモリーの割合を指定します。

メモリー合計(MB)

Oracle Virtual Directoryサーバー・ホスト上で利用可能なメモリーの合計(MB)を指定します。

ヒープ使用量(MB)

Oracle Virtual DirectoryサーバーのJVMヒープ使用量(MB)を指定します。

稼働時間(ミリ秒/Epoch以降)

Oracle Virtual Directoryサーバーが稼働している時間(ミリ秒)を指定します。

開始時間(ミリ秒/Epoch以降)

Oracle Virtual Directoryの開始時間(Epoch以降、ミリ秒)を指定します。

稼働/停止ステータス

Oracle Virtual Directoryが稼働中か、または停止中で使用不可能かを指定します。

合計操作数

最後のデータ収集以後に完了したすべてのLDAP操作の合計数を指定します。

オープン接続の合計数

Oracle Virtual Directoryサーバーへのオープン接続の合計数を指定します。

現在接続しているユーザーの合計数

Oracle Virtual Directoryサーバーに現在しているユーザーの合計数を指定します。

現在接続しているIPの合計数

Oracle Virtual Directoryサーバーに現在接続している個別のIPアドレスの合計数を指定します。

同時接続(ユーザー)

特定のユーザーの現在のオープン接続数を指定します。

合計接続数(ユーザー)

特定のユーザーによってオープンされた合計接続数を指定します。

同時接続(IP)

特定のIPアドレスからの現在のオープン接続の合計数を指定します。

合計接続数(IP)

特定のIPアドレスからの接続の合計数を指定します。

検索リクエスト完了までの最小時間

Oracle Virtual Directoryが最後に起動されてから、検索の完了に要した最小時間を指定します。

検索リクエスト完了までの最大時間

Oracle Virtual Directoryが最後に起動されてから、検索の完了に要した最大時間を指定します。

LDAP検索リクエスト完了までの平均時間

Oracle Virtual Directoryが最後に起動されてから、LDAP検索リクエストの完了に要した平均時間を指定します。

LDAP検索リクエスト数

最後のデータ収集以後のLDAP検索リクエスト数を指定します。

LDAP追加リクエスト数

最後のデータ収集以後のLDAP追加リクエスト数を指定します。

LDAPバインド・リクエスト数

最後のデータ収集以後のLDAPバインド・リクエスト数を指定します。

LDAP削除リクエスト数

最後のデータ収集以後のLDAP削除リクエスト数を指定します。

LDAP変更リクエスト数

最後のデータ収集以後のLDAP変更リクエスト数を指定します。

LDAP名変更リクエストの数

最後のデータ収集以後のLDAP名変更リクエスト数を指定します。

合計操作数

最後のデータ収集以後のすべてのLDAP操作の合計数を指定します。

有効(アダプタ)

Oracle Virtual Directory Adapterが無効化または有効化されているかを指定します。

操作バージョン(アダプタ)

Oracle Virtual Directoryアダプタの操作バージョンを指定します。

プロビジョニングされたバージョン(アダプタ)

Oracle Virtual Directoryアダプタのプロビジョニングされたバージョンを指定します。

タイプ(アダプタ)

アダプタのタイプを指定します。

名前が変更された操作の合計数(アダプタ)

特定のアダプタによって名前が変更された操作の合計数を指定します。

バインド操作の合計数(アダプタ)

特定のアダプタによって実行されたバインド操作の合計数を指定します。

再利用した接続の合計数(アダプタ)

特定のアダプタによって再利用された接続の合計数を指定します。

処理された接続の合計数(アダプタ)

特定のアダプタによって処理された接続の合計数を指定します。

検索リクエスト完了までの最小時間(アダプタ)

Oracle Virtual Directoryが最後に起動されてから、特定のアダプタがLDAP検索リクエストの完了に要した最小時間を指定します。

検索リクエスト完了までの最大時間(アダプタ)

Oracle Virtual Directoryが最後に起動されてから、特定のアダプタがLDAP検索リクエストの完了に要した最大時間を指定します。

検索リクエスト完了までの平均時間(アダプタ)

Oracle Virtual Directoryが最後に起動されてから、特定のアダプタがLDAP検索リクエストの完了に要した平均時間を指定します。

操作数(アダプタ)

特定のアダプタによって実行されたすべての操作の合計数を指定します。

追加操作(アダプタ)

最後のデータ収集後に特定のアダプタによって実行された追加操作の合計数を指定します。

変更操作(アダプタ)

最後のデータ収集後に特定のアダプタによって実行された変更操作の合計数を指定します。

検索操作(アダプタ)

最後のデータ収集後に特定のアダプタによって実行された検索操作の合計数を指定します。

削除操作(アダプタ)

最後のデータ収集後に特定のアダプタによって実行された削除操作の合計数を指定します。

オープン接続(アダプタ)

最後のデータ収集以後の特定のアダプタによってオープンされた接続の合計数を指定します。

D.3 追加情報

My Oracle Support(以前のMetaLink)(http://support.oracle.com)でより多くの解決策を参照できます。問題の解決策が見つからない場合は、サービス・リクエストを記録してください。

関連項目:
Oracle Application Serverリリース・ノート。次のサイトのOracle Technology Networkから参照できます。
http://otn.oracle.co.jp/document/

索引
A B C D E F G H I J K L M N O P R S U V W X

A

アクセス制御

属性, 6.3.4.4

コンテンツ・アクセス権限, 6.3.4.5

ACLの作成, 6.3.4.1

DN, 6.3.4.6

エンド・ユーザーのバインディング資格証明, 6.1

施行, 6.3.5

グループ, 6.3.3

IPアドレス, 6.3.4.6

概要, 6.3, 6.3.2

権限, 6.3.4.5

パブリック, 6.3.4.6

権限, 6.3.4.3

有効範囲, 6.3.4.2

ソース・ディレクトリ, 6.3.1

構造型アクセス権限, 6.3.4.5

サブジェクト, 6.3.4.6

サブツリー, 6.3.4.6

LDAPアダプタを使用, 2.2.3

アクセス制御リスト

統合用の構成, 19.2.4, 19.4.6

作成, 16.1

削除, 16.2.2

施行, 6.3.5

更新, 16.2.1, 19.3.3.2, 19.3.4.2

アカウントのロックアウト, 有効化, 19.2.6, 19.4.8 アカウント、ロック解除, 15.1.2.4 Active Directory Ranged Attributesプラグイン, 4.4.2 Active_Directory_to_inetOrgマッピング, 5.2.1 ActiveDirectory Passwordプラグイン, 4.4.1 アダプタ・データ・ブラウザ

エントリの管理, 15.1.3

ソース・エントリの変更, 15.1.3.2

ソース・エントリの表示, 15.1.3.1

アダプタ・サービス・インタフェース, 18.3.6.3 adapterNamesパラメータ, 4.2.2.1 アダプタ

EUS用の構成, 19.2.2

RAS用の構成, 19.4.3

仮想ディレクトリの作成, 2.7

カスタム

構成, 18.2.2

作成, 18.2.1

概要, 18.2

設定, 18.2.2.1

データベース

アクセス制御, 2.3.1

カスケード削除, 2.3.3

構成, 12.2.3

作成, 12.2

Oracle RAC用の作成, 12.2.1

Oracle TimesTen用の作成, 12.2.2

データ・マッピング, 2.3.3

デプロイメントの考慮事項, 2.3

エントリ名, 2.3.3

JDBCライブラリ, 2.3.2

マップされる表, 2.3.3

複数表への書込み, 2.3.3

複数値属性, 2.3.3

概要, 2.3

検索, 2.3.3

設定, 12.2.3.1

部分文字列検索, 2.3.3

複数表オブジェクトへの書込み, 2.3.3

Diameter, 20.1, 20.3, 20.3.2.1 結合ビュー

クラス, 18.3.6.4

条件付きの結合, 2.5.2.2

構成, 12.4.1

作成, 12.4

デプロイメント, 2.5.1

重複エントリ, 2.5

例, 2.7.2

結合関係, 2.5.2

結合ルール, 2.5

OneToMany結合, 2.5.2.3

概要, 2.5

プライマリ・アダプタ, 2.5

プライマリ・アダプタのルーティング, 12.4.1.2

ルーティング, 2.5

検索, 2.5

設定, 12.4.1.1

Shadow結合, 2.5.2.4

OID用のShadow結合, 12.4.2

Simple結合, 2.5.2.1

LDAP

アクセス制御, 2.2.3

証明書, 12.1.2.4

構成, 12.1.2, 19.2.2, 19.4.3

作成, 12.1

デプロイメント・タイプ, 2.2.1

フェイルオーバー, 7.4

相互認証, 12.1.3

概要, 2.2

設定, 12.1.2.1

ローカル・ストア

構成, 12.3.1, 19.2.2, 19.4.3

作成, 12.3

フェイルオーバー, 7.3.1

データの移行, 2.4.1

概要, 2.4

設定, 12.3.1.1

マッピング, 14.3 ネームスペース, 2.8 概要, 2.1 テンプレート

Active Directory, 2.9.2.1

CA_eTrust, 2.9.2.2

Changelog_LDAP-TYPE, 2.9.2.3

データベース, 2.9.4.1

デフォルト, 2.9.1

EUS_ActiveDirectory, 2.9.2.4

EUS_eDirectory, 2.9.2.7

EUS_OID, 2.9.2.5

EUS_Sun, 2.9.2.6

General_LDAP_Directory, 2.9.2.8

IBM_Directory, 2.9.2.9

LDAP, 2.9.2

ローカル・ストア, 2.9.3

Novell_Directory, 2.9.2.10

マッパーを使用したOAM/ADアダプタ, 2.9.2.11

スクリプトを使用したOAM/ADアダプタ, 2.9.2.13

SSLおよびマッパーを使用したOAM/ADアダプタ, 2.9.2.12

マッパーを使用したOAM/ADAMアダプタ, 2.9.2.14

スクリプトを使用したOAM/ADAMアダプタ, 2.9.2.16

SSLおよびマッパーを使用したOAM/ADAMアダプタ, 2.9.2.15

スクリプトを使用したOAM/DBアダプタ, 2.9.4.1

マッパーを使用したOAM/SunOneアダプタ, 2.9.2.17

スクリプトを使用したOAM/SunOneアダプタ, 2.9.2.18

ONames_LDAP-TYPE, 2.9.2.19

Oracle_internet_Directory, 2.9.2.20

概要, 2.9

Siemens_DirX, 2.9.2.21

SunOne_Directory, 2.9.2.22

User_LDAP-TYPE, 2.9.2.23

タイプ, 2.1 applyForAdminパラメータ, 4.2.2.1 ASIメソッド、サポート対象, 18.3.6.3 監査ログ

検索操作用, 17.1.1

収集される情報, 17.2.3

場所, A.16

認証

クライアント証明書, 6.2.3

Kerberos, 19.2.3.2

プロキシ・アカウント, 6.2.2

SSO対応ディレクトリ, 8.3.1.3, 8.3.6.3

B

バインド

「バインドを含む」または「バインドの除外」, 3.2.10

ブラウザ、サポート対象, 8.3.1.1

C

Cacheプラグイン, 4.2.13

証明書

期限切れの削除, 8.3.7.5

管理, 6.4

期限切れの管理, 8.3.7.4

Changelogプラグイン, 4.2.21.2 ChangeUserRDNプラグイン, 4.2.3 クラス, 18.3.6 クライアント証明書の認証, 6.2.3 クライアント・ビュー・データ・ブラウザ

LDIFファイルのエクスポート, 15.1.2.6

LDIFファイルのインポート, 15.1.2.5

エントリの管理, 15.1.2

エントリの変更, 15.1.2.3

検索, 15.1.2.1

エントリの表示, 15.1.2.2

Common_Name_to_Given_Nameマッピング, 5.2.2 ConditionalPublishマッピング, 5.2.3 OVDの構成

最大ヒープ・サイズ, 9.4

特権ポート, 11.3

サーバー・プロパティ

Fusion Middleware Control, 9.1

Oracle Directory Services Manager, 9.2

WebLogic Scripting Tool, 9.3

SSO対応ディレクトリへの接続, 8.3.6.3 CoordinatorAdapterプラグイン, 4.2.24 構成ファイルのコピー, 9.7 コンポーネントの作成, 10.3 資格証明

プロキシ設定されたディレクトリ・サーバーへの接続, 2.2.3

ODSMの管理, 8.3.7

引渡し, 2.2.3, 6.1

DSMLv2サービスへの送信, 18.4

共有, 3.2.10

パススルー・モードの使用, 12.1.2.1

カスタム

アダプタ

作成および構成, 18.2

説明, 18.3.4.1

OAM用, 19.1

トラブルシューティング, D.2.3

EntrySet, 18.3.4.2 結合, 2.5.2.5 プラグイン

説明, 18.3.4.1

ファイルの場所, A.4

Java, 18.3

トラブルシューティング, 18.3.6.2, D.2.3

使用する理由, 5.1.1

URL, 12.2 カスタマイズ、サポート対象, A.17

D

データ・ブラウザ

アダプタ・ブラウザ, 15.1.1

クライアント・ビュー, 15.1.1

概要, 15.1.1

DB_Groupsマッピング, 5.2.4 デフォルト・ポート, 8.1 コンポーネントの削除, 10.7 Diameterアダプタ, 20.1 Diameter HSSのリポジトリ, 20.1 ディレクトリ、Shadow, 2.5.2.4 DNSのフェイルオーバー, 7.2 DSMLv2サービス, 18.4 Dump Transactionsプラグイン, 4.2.8 動的フィルタ, 4.2.2.1 DynamicEntryTreeプラグイン, 4.2.10 DynamicGroupsプラグイン, 4.2.12 DynamicTreeプラグイン, 4.2.9

E

エンド・ユーザーのバインディング資格証明, 6.1

エンタープライズ・ユーザー・セキュリティ

ローカル・ストアおよびLDAPアダプタの構成, 19.2.2, 19.2.3.2

extendAD, 19.2.3.1.1, 19.4.5.1.1, 19.4.5.4.1

統合

アクセス制御リスト, 19.2.4

Active Directory, 19.2.3.1, 19.2.3.2, 19.2.6

制限, 19.2.7

複数ドメイン, 19.2.5

Novell eDirectory, 19.2.3.4

Oracle Internet Directory, 19.2.3.5

ユーザー・アカウントのロックアウト, 19.2.6

OVDの使用, 19.2

統合のためのOVDの準備, 19.2.1 EntrySet, 18.3.4 環境変数, 8.1 EUSActiveDirectoryプラグイン, 4.3.1 EUSeDirectoryプラグイン, 4.3.4 EUSiPlanetプラグイン, 4.3.2 EUSLockoutプラグイン, 4.3.6 EUSMemberDNMappingプラグイン, 4.3.5 EUSOIDプラグイン, 4.3.3 期限切れの証明書

削除, 8.3.7.5

フィルタ, 8.3.7.4

extendAD, 19.2.3.1.1, 19.4.5.1.1, 19.4.5.4.1 外部ディレクトリ, OVDの統合, 19.2.3, 19.4.5, 19.4.5

F

FA UserRoleプラグイン, 4.2.1

フェイルオーバー

DNS, 7.2

LDAPアダプタ, 7.4

ローカル・ストア・アダプタ, 7.3.1

ネットワーク, 7.2

Oracle Virtual Directory, 7.3

フォルト・トレランス, 7.1 file.prop, 11.6.3 フィルタ

動的, 4.2.2.1

静的, 4.2.2.1

FlatTreeプラグイン, 4.2.11 ForkJoinプラグイン, 4.2.5 Fusion Middleware Control

SSLリスナーの構成, 11.6.2

HTTPリスナーの作成, 11.4.2

LDAPリスナーの作成, 11.4.1

リスナーの作成, 11.4

リスナーの削除, 11.4.4.2

リスナーの編集, 11.4.4.1

開始, 8.4

起動, 8.4.1

リスナーの管理, 11.4.4

OVDの監査, 17.2.1

OVDのロギング, 17.1.1

OVDのメトリック, 8.4.5

OVDサーバー・プロパティ, 9.1

OVDの再起動, 8.4.4

OVDの起動, 8.4.2

OVDの停止, 8.4.3

サポートされているブラウザ, 8.3.1.1

URL, 8.4.1

G

GenericMapperプラグイン, 4.2.23

グローバル・サービス・インタフェース, 18.3.6.2

H

ヒープ・サイズ, 9.4

HideEntriesByFilterプラグイン, 4.2.2

HideGroupsAndUsersプラグイン, 4.2.27

I

IETFのLDAP Access Control Model for LDAPv3, 2.2.3

IETF RFC 2820, 2.2.3

バインドを含める, 3.2.10

InetADプラグイン, 4.4.3

統合、Oracle Directory Services Manager-SSO, 1.1.4, 8.3.1.3, 8.3.2

統合, EUS, 19.2.3, 19.4.5

J

Javaキーストア

内容のリスト, 8.3.7.3

パスワードの取得, 8.3.7.2

Javaプラグイン, 4.1 JAWSスクリーン・リーダー, 8.3.1.2 結合関係, 2.5

K

Kerberos認証, 19.2.3.2

キーストア

内容のリスト, 8.3.7.3

パスワードの取得, 8.3.7.2

krb5.conf, 12.1

L

LDAPツール, 8.6

LDAPツールのパスワード, 8.6

ldapURLパラメータ, 4.2.2.1

LDIFファイル

エクスポート, 15.1.2.6

インポート, 15.1.2.5

リスナー

管理ゲートウェイ, 11.2, 11.2

管理リスナーの設定, 11.4.4.1.1

SSLの構成

Fusion Middleware Controlの使用, 11.6.2

WebLogic Scripting Toolの使用方法, 11.6.3

WebLogic Scripting Toolを使用した構成, 11.5.1.2, 11.5.1.3 Fusion Middleware Controlを使用した作成, 11.4 デフォルト, 11.2 削除

Fusion Middleware Controlの使用, 11.4.4.2

WebLogic Scripting Toolの使用方法, 11.5.2

Fusion Middleware Controlを使用した編集, 11.4.4.1 HTTP

Fusion Middleware Controlを使用した作成, 11.4.2

セキュリティ・コンテキスト, C.6

設定, 11.4.2

WebGatewayのアーキテクチャ, C.3

WebGatewayのコマンド, C.5

WebGatewayのデモ・ブラウザ, C.2

WebGatewayのDSMLサーブレット, C.3.1

WebGatewayの機能, C.1

WebGatewayのハンドラ, C.3.3

WebGatewayの問合せパラメータ, C.4

WebGateway XSLTサーブレット, C.3.2

XSLスタイルシート, C.7

LDAP

Fusion Middleware Controlを使用した作成, 11.4.1

設定, 11.4.1

LDAP SSLエンドポイント, 11.2, 11.2 管理

Fusion Middleware Controlの使用, 11.4.4

WebLogic Scripting Toolの使用方法, 11.5

概要, 11.1 WebLogic Scripting Toolを使用した更新, 11.5.1, 11.5.1.1 SSL接続の検証, 11.6.4 ロギング・レベルの値、サポート対象, 4.2.8.1

M

管理インタフェース, 8.1

Map_DB_Passwordマッピング, 5.2.5

マッピング

テンプレートを使用した作成, 14.1

作成, 14.2

アダプタに適用, 14.3

表示, 14.1.1

仮想ネームスペース, 1.3.1

Middlewareホーム, 1.1.5 データの移行, 2.4.1

N

ネームスペース

フィルタ, 4.1.1

マッピング, 1.3.1, 2.2.1

値, 10.3

ネームスペース・アダプタ, 2.8

O

OAMPolicyControlプラグイン, 4.5.1

ObjectClass Mapperプラグイン, 4.2.14

oidcmprec, 2.4, 2.4.1, 2.4.1, 9.7

Onamesプラグイン, 4.3.7

操作、サポート対象, 2.3.3, 2.4.1

opmnctl

createcomponent, 10.3

deletecomponent, 10.7

概要, 10.1

registerinstance, 10.4

restartproc, 10.11

startproc, 10.9

ステータス, 10.8

stopproc, 10.10

unregisterinstance, 10.5

updatecomponentregistration, 10.6

Oracle Access Manager, 19.1 Oracle Communications Universal User Profile

Diameterアダプタ, 20.3

IMS 3GPPスキーマ, 20.4

概要, 20.1

ユース・ケース, 20.2

Oracle Database Net Services

統合, 19.3

Active Directory, 19.3.3

Oracle Directory Server Enterprise Edition, 19.3.4

Oracle Internet Directory, 19.3.5

開始, 19.3.2

Oracle Directory Services Manager

アクセス, 8.3.1

クラスタ, 8.3.10

キーストアの内容, 8.3.7.3

ACLの作成, 16.1

ACLの削除, 16.2.2

説明, 8.3.1

起動, 8.3.5

言語, 18.1

ディレクトリ・サーバーへのログイン, 8.3.6.1

スキーマの管理, 15.2

OVDサーバー, 9.2

SSL, 8.3.6.2

SSOとの統合, 1.1.4, 8.3.1.3, 8.3.2

サポートされているブラウザ, 8.3.1.1

ACLの更新, 16.2.1

URL, 8.3.5

Oracle Fusion Middleware, 1.1.5 Oracleホーム, 1.1.5 Oracleインスタンス, 10.2 Oracle Process Manager and Notification Server, 10.1 Oracle RAC, 12.2.1 Oracle TimesTen, 12.2.2 orcladmin, 8.3.1 orclpwdaccountunlock属性, 15.1.2.4 孤立したソケット接続, 9.5 OVD

監査, 17.2

Fusion Middleware Controlを使用した監査, 17.2.1

WebLogic Scripting Toolを使用した監査, 17.2.2

クラス, 18.3.6

アダプタ・サービス・インタフェース, 18.3.6.3

データ, 18.3.6.6

データ型, 18.3.6.7

例外, 18.3.6.8

グローバル・サービス・インタフェース, 18.3.6.2

結合ビュー・アダプタ, 18.3.6.4

ユーティリティ, 18.3.6.5

仮想サービス・インタフェース, 18.3.6.1

リリース間の比較, A

監査の構成, A.15

監査ログ, A.16

クラスパス, A.13

コマンドライン・ツール, A.12

構成ファイル, A.3

デフォルト・スーパーユーザー, A.1

GUI, A.11

ローカル・ストア・アダプタ・ファイル, A.7

ログ・ファイル, A.6

マッピング・ファイル, A.5

プラグイン・ファイル, A.4

プロセス管理, A.2

スキーマ・ファイル, A.8

サーバーのデバッグ, A.10

サーバー・ライブラリ, A.9

Oracle Access Manager用の構成, 19.1 デフォルト・イメージ, 10.2 DSMLv2サービス, 18.4 エンタープライズ・ユーザー・セキュリティとの統合, 19.2 ロギングの粒度, 17.1.3 Fusion Middleware Controlを使用したロギング, 17.1.1 WebLogic Scripting Toolを使用したロギング, 17.1.2 スキーマ, 15.2 検索, 15.1.2.1 複数のEUSドメインのサポート, 19.2.5 トラブルシューティング, D OVDサーバー

ヒープ・サイズ, 9.4

ライブラリ, 9.6.1

P

パススルー認証, 6.2.1

パスワード

公開の防止, 8.6

Javaキーストアの取得, 8.3.7.2

Performance Monitorプラグイン, 4.2.16 プラグイン

アダプタ

作成, 13.1.1

削除, 13.1.4

編集, 13.1.3

操作固有, 13.1.2

グローバル

作成, 13.2.1

削除, 13.2.4

編集, 13.2.3

表示, 13.2.2

Java

Active Directory Ranged Attributes, 4.4.2

ActiveDirectory Password, 4.4.1

Cache, 4.2.13

チェーン・システム, 18.3.2

Changelog, 4.2.21.2

ChangeUserRDN, 4.2.3

CoordinatorAdapter, 4.2.24

カスタム, 18.3

カスタムEntrySet, 18.3.4

カスタム・フィルタ, 18.3.5

カスタム実装ポイント, 18.3.3

Dump Transactions, 4.2.8

DynamicEntryTree, 4.2.10

DynamicGroups, 4.2.12

DynamicTree, 4.2.9

EUSActiveDirectory, 4.3.1

EUSeDirectory, 4.3.4

EUSiPlanet, 4.3.2

EUSLockout, 4.3.6

EUSMemberDNMapping, 4.3.5

EUSOID, 4.3.3

FA UserRole, 4.2.1

FlatTree, 4.2.11

ForkJoin, 4.2.5

HideEntriesByFilter, 4.2.2

HideGroupsAndUsers, 4.2.27

InetAD, 4.4.3

ネームスペースのフィルタ処理, 4.1.1

OAMPolicyControl, 4.5.1

ObjectClass Mapper, 4.2.14

Onames, 4.3.7

概要, 4.1

Performance Monitor, 4.2.16

Proxy Authorization Support, 4.2.19

SAML XASP, 4.2.28

SubschemaSubentry, 4.3.8

Sub-Tree, 4.2.15

UniqueEntry, 4.2.17

UPNBind, 4.2.4

UserManagement, 4.2.20

VirtualAttribute, 4.2.7

VirtualMemberof, 4.2.6

Pythonマッピング

Active_Directory_to_inetOrg, 5.2.1

Common_Name_to_Given_Name, 5.2.2

ConditionalPublish, 5.2.3

DB_Groups, 5.2.4

デプロイ, 5.1.2

Map_DB_Password, 5.2.5

概要, 5.1

プロキシ・アカウント認証, 6.2.2 Proxy Authorization Supportプラグイン, 4.2.19 pwdaccountlockedtime属性, 15.1.2.4 Pythonマッピング, 5.1, A.17

R

Real Application Security

ローカル・ストアおよびLDAPアダプタの構成, 19.4.3

統合

アクセス制御リスト, 19.4.6

ユーザー・アカウントのロックアウト, 19.4.8

統合のためのOVDの準備, 19.4.1 「参照元」表, 15.2.1.2 Oracleインスタンスの登録, 10.4 OVDの再起動

opmnctl, 10.11

RESTベースのクライアント, 18.4 ルーティング

例, 3.1

概要, 3.1

設定, 3.2

属性フロー，3.2.5

バインド・サポート, 3.2.7

バインド, 3.2.10

重要性, 3.2.8

DN一致, 3.2.3

フィルタ, 3.2.2

レベル, 3.2.4

優先度, 3.2.1

取得可能な属性, 3.2.5.1

格納可能な属性, 3.2.5.3

未取得属性, 3.2.5.2

格納できない属性, 3.2.5.4

ビュー, 3.2.9

可視性, 3.2.6

S

SAML XASPプラグイン, 4.2.28

スキーマ

類似属性の作成, 15.2.1.3

類似オブジェクト・クラスの作成, 15.2.2.3

新しい属性の作成, 15.2.1.2

新しいオブジェクト・クラスの作成, 15.2.2.2

属性の削除, 15.2.1.5

オブジェクト・クラスの削除, 15.2.2.5

管理, 15.2

属性の変更, 15.2.1.4

オブジェクト・クラスの変更, 15.2.2.4

検索, 15.2.1.1

オブジェクト・クラスの検索, 15.2.2.1

検索操作

監査ログ, 17.1.1

セッション・タイムアウト、構成, 8.3.8 Shadowディレクトリ, 2.5.2.4 Shadowジョイナ

説明, 2.5.2.4

スキーマの変更の削除, 2.5.2.4

属性の格納, 2.5.2.4

シングル・サインオン

ディレクトリへの接続, 8.3.6.3

Oracle Directory Services Managerとの統合の理解, 1.1.4, 8.3.1.3

SSL

AD Application Modeターゲットに対するLDAPアダプタの構成, 2.9.2.15

ADターゲットに対するLDAPアダプタの構成, 2.9.2.11, 2.9.2.12

SSL接続の検証, 11.6.4

SSO対応ディレクトリ

認証, 8.3.1.3, 8.3.6.3

接続, 8.3.6.3

opmnctlを使用したOVDの起動, 10.9 静的フィルタ, 4.2.2.1 コンポーネントのステータス, 10.8 opmnctlを使用したOVDの停止, 10.10 SubschemaSubentryプラグイン, 4.3.8 Sub-Treeプラグイン, 4.2.15 スーパーユーザー, A.1 スーパーユーザー・パスワード, 9.1 サポートされている

ASIメソッド, 18.3.6.3

ブラウザ, 8.3.1.1

カスタマイズ, A.17

結合関係タイプ, 2.5.2

ログ・レベル値, 4.2.8.1

操作, 2.3.3, 2.4.1

syncovdconfig, 2.4, 9.7, 9.7.1, 9.7.2, A.12, A.14

U

UniqueEntryプラグイン, 4.2.17

「アカウントのロックを解除」ボタン, 15.1.2.4

ユーザー・アカウントのロック解除, 15.1.2.4

Oracleインスタンスの登録解除, 10.5

Oracleインスタンスの登録の更新, 10.6

UPNBindプラグイン, 4.2.4

URL、カスタムの使用, 12.2

ユーザー・アカウントのロックアウト、有効化, 19.2.6, 19.4.8

ユーザー・アカウント、ロック解除, 15.1.2.4

UserManagementプラグイン, 4.2.20

V

SSL接続の検証, 11.6.4

ビュー、作成および構成, 3.2.9

仮想サービス・インタフェース, 18.3.6.1

VirtualAttributeプラグイン, 4.2.7

VirtualMemberofプラグイン, 4.2.6

W

ウォレット

作成, 11.6.4.2

証明書のインポート, 11.6.2

管理, 6.4

パスワード, 8.6

Webゲートウェイ

アーキテクチャ, C.3

コマンド, C.5

デモ・ブラウザ, C.2

DSMLサーブレット, C.3.1

機能, C.1

ハンドラ, C.3.3

概要, C

問合せパラメータ, C.4

XSLT, C.3.2

Webサービス・クライアント、接続, 18.4 WebLogic,

ドメイン, 1.1.5

ホーム, 1.1.5

WebLogic Scripting Tool

リスナーの構成

HTTP, 11.5.1.3

LDAP, 11.5.1.2

SSL, 11.6.3

リスナーの削除, 11.5.2 開始, 8.5, 8.5 リスナーの管理, 11.5 OVDの監査, 17.2.2 OVDのロギング, 17.1.2 OVDサーバー, 9.3 リスナーの更新, 11.5.1, 11.5.1.1 WSDLファイル, 18.4

X

XSLスタイルシート, C.7

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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の登録商標です。

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

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

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