Oracle® Fusion Middleware

Oracle Unified Directory移行ガイド

11g リリース2 (11.1.2)

E53622-01(原本部品番号:E51265-02)

2014年4月

Oracle Fusion Middleware Oracle Unified Directory移行ガイド 11g リリース2 (11.1.2)

E53622-01

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

原本著者:  Francisco Franklin

原本協力著者:  Sylvain Duloutre

原本協力者:  Etienne Remillon、Don Biasotti

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

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

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

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の登録商標です。

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

1 Oracle Unified Directoryへの移行の理解

- 1.1 サポートされている移行パス

- 1.2 この移行ガイドの使用

- 1.3 OUDへの移行

- 1.4 OUDプロキシへの移行

2 移行ストラテジの選択

- 2.1 要件の分析

- 2.1.1 本番環境での(O)DSEEとOUDトポロジの共存

- 2.1.2 共存と(O)DSEEとOUDの間のデータの整合性

- 2.1.3 (O)DSEEインフラストラクチャでの移行の影響

- 2.1.4 書込みサービスの中断を伴う(または伴わない)移行

- 2.1.5 ユーザー・データ構造の変更

- 2.2 サポートされている移行ストラテジ

- 2.2.1 レプリケーション・ゲートウェイを使用した共存

- 2.2.2 Oracle Directory Integration Platform (DIP)を使用した共存

- 2.2.3 直接移行ストラテジ

- 2.2.4 決定マトリックス

3 移行ストラテジの検証

- 3.1 選択したストラテジの検証

- 3.2 DSEEバージョンの検討

- 3.3 (O)DSEEのレガシー機能の調整

- 3.3.1 ロールベースのACI

- 3.3.2 ロールとサービス・クラス(CoS)

- 3.3.3 カスタム・パスワード・ポリシー

- 3.3.4 データの矛盾の管理

- 3.4 レビュー: (O)DSEE技術特性の影響

- 3.4.1 ds2oudを使用した関連する(O)DSEE機能の識別

4 移行の実行

- 4.1 OUDへの移行の開始

- 4.2 手順1: 参照OUDインスタンスの作成

- 4.3 手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断

- 4.3.1 (O)DSEEディレクトリ・サーバー、構成およびスキーマの診断

- 4.3.2 ディレクトリ・サーバー・データの診断

- 4.3.3 診断中の既知のエラー

- 4.4 手順3: ディレクトリ・スキーマの移行

- 4.5 手順4: ディレクトリ構成の移行

- 4.5.1 ds2oudコマンドを使用した構成設定の移行

- 4.5.1.1 SSL証明書の移行

- 4.5.1.2 PKCS#12キーストアの構成

- 4.5.1.3 PKCS#12キーストアを使用するためのLDAPS接続ハンドラの構成

- 4.5.1.4 ディレクトリ・サーバーの証明書キー・ペアのインポート

- 4.5.1.5 暗号化された属性の移行

- 4.5.2 共存のためのパスワード記憶スキームの変更

- 4.5.3 構成変更の適用

- 4.6 手順5: ユーザー・データおよびディレクトリ・メタデータの移行

- 4.6.1 (O)DSEEからOUDへのユーザー・データのエクスポート

- 4.6.2 OUDへのデータのインポート

- 4.6.3 ディレクトリ・メタデータの移行

- 4.6.4 レプリケーション・トポロジ内のACIの管理

- 4.6.5 サービス・クラス(CoS)の管理

- 4.6.5.1 集合属性と仮想属性

- 4.6.5.2 ポインタCoS

- 4.6.5.3 間接CoS

- 4.6.5.4 クラシックCoS

- 4.6.6 OUDへのロールの移行

- 4.6.6.1 ロールとACI

- 4.6.6.1.1 ロールとパスワード・ポリシー

- 4.6.6.1.2 クライアント・アプリケーションに公開されるロール

- 4.6.6.1.3ロールのセキュアな移行

- 4.6.7 OUDへのパスワード・ポリシー移行の管理

- 4.6.7.1 パスワード・ポリシーの割当て

- 4.6.7.2 パスワード・ポリシーの継承

- 4.6.7.3 パスワード・ポリシーとレプリケーション・ゲートウェイ

- 4.6.7.4 レプリケーション・ゲートウェイと(O)DSEEパスワード・ポリシーのアップグレード

- 4.6.7.5 アカウント・ロックアウト

- 4.6.7.6 カスタム・リソース制限

- 4.7 手順6: レプリケーション・ゲートウェイまたはDIPのデプロイ

- 4.7.1 レプリケーション・ゲートウェイのデプロイ

- 4.7.2 DIPのデプロイ

- 4.8 手順7: レプリケートされるトポロジのデプロイ

- 4.9 手順8: OUDトポロジへのトラフィックのリダイレクト

- 4.10 手順9: 共存の中止

5 OUDへの移行後

- 5.1 新しいOUD環境

- 5.2 追加のOUD情報

はじめに

『Oracle Unified Directory移行ガイド』では、Sun Directory Server Enterprise EditionおよびOracle Directory Server Enterprise EditionのコンポーネントをOracle Unified Directory 11g リリース2 (11.1.2.2)に更新する方法について説明します。このガイドでは、Directory Serverを移行する方法、およびDirectory Proxy Serverを移行する方法について説明します。

対象読者

このガイドは、Oracle Unified Directoryに移行するディレクトリ・サービスの管理者を対象としています。Oracle Unified Directoryへの移行を検討しているビジネス・プランナにも役立ちます。

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

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

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=accid=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=accid=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Unified Directory 11g リリース2 (11.1.2.2)のドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle Unified Directoryリリース・ノート

- Oracle Unified Directory管理者ガイド

- Oracle Unified Directory開発者ガイド

- Oracle Unified Directoryインストレーション・ガイド

1 Oracle Unified Directoryへの移行の理解

Oracle Unified Directoryへの移行プロセスを使用すると、Directory Server Enterprise Editionの既存のインストールをOracle Unified Directory 11g リリース(11.1.2.2)に置換できます。この章の内容は、次のとおりです。

- 第1.1項「サポートされている移行パス」

- 第1.2項「この移行ガイドの使用」

- 第1.3項「OUDへの移行」

- 第1.4項「OUDプロキシへの移行」

1.1 サポートされている移行パス

次のものからOracle Unified Directory 11g リリース2 (11.1.2.2)に移行できます。

- Oracle Directory Server Enterprise Edition (ODSEE) 11g

- Sun Directory Server Enterprise Edition (DSEE) 7.0

- Sun Java System Enterprise Edition (DSEE) 6.x

- Sun ONE Directory Server / Sun Java System Directory Server (DSEE) 5.2

注意:

"(O)DSEEは、DSEEとODSEEの両方のディレクトリを指します。ODSEEとDSEEは、このガイドでは情報がその特定のディレクトリに固有の場合にのみ使用されます。

ODSEE (旧名: SUN Directory Server Enterprise Edition (DSEE))は、通信業界などの企業環境で実績のある大規模なデプロイメント機能を持つ非常に有名なディレクトリ・サーバーです。

OUDは、ストレージ、プロキシ、同期および仮想化の各機能を備えた一体型のディレクトリ・ソリューションです。

OUDは、高パフォーマンスの企業および通信業者レベルの環境に必要なすべてのサービスを提供します。次のものが保証されます。

- 数十億のエントリへのスケーラビリティ

- 容易なインストール

- 弾力性のあるデプロイメント

- 企業管理の容易性

- 有効な監視

- 優れたパフォーマンス

- ハードウェアおよびオペレーティング・システムの選択肢の最大化

- 最新のLDAP標準の厳密な順守

- Oracle Fusion Middleware製品との統合

OUDと(O)DSEEは、同じOracle Directory Services Plusライセンス・スキームの一部ですが、2つの製品のコード・ベースおよびアーキテクチャは異なるため、OUDへの移行には、慎重に検討する必要があるいくつかの手順があります。

1.2 この移行ガイドの使用

このガイドでは、Directory ServerおよびDirectory Proxy ServerをOracle Unified Directoryにアップグレードする方法について説明します。このガイドは、(O)DSEEユーザーがシステム要件および制約に基づいて最適な移行ストラテジを選択する際に役立ちます。ストラテジを選択した後、OUDに移行してデプロイするための段階的な手順を示します。

このガイドでは、一般的なアップグレードに重点を置いており、最も一般的なユース・ケースを取り上げています。独自のデプロイメントでは追加の手順が必要になる場合があるため、Oracle Consulting Servicesのサポートを受けながら実行する必要がある場合があります。

このガイドに提示されている方法では、移行がクライアント・アプリケーションに対して透過的になるように、ユーザー・データと重要なサーバー・構成を保持しながら、新しいOUDサービスを利用します。

移行はディレクトリ・アーキテクチャの一部を再検討するのに適した機会であり、移行プロセスの一部として実行できますが、インフラストラクチャの強化はこのガイドの主な目的ではありません。

1.3 OUDへの移行

OUDへの移行のプロセスの概要は次のとおりです。

1. 移行に関連する重要な要件を識別した後、最適な移行ストラテジを選択します。

2. 既存の(O)DSEEデプロイメントの詳細な診断に基づいて、選択した移行ストラテジを検証します。

3. このガイドの手順を実行して、検証されたストラテジを実行します。

図1-1 OUDへの移行プロセス

1.4 OUDプロキシへの移行

Directory Proxy Server (DPS)は、最新のディレクトリ・サービスを構成するもう一つの重要な要素です。OUDをプロキシ・コンポーネントとして構成した場合、DSEEのDPSコンポーネントと同じレベルのプロキシおよび分散機能を提供します。

移行計画の一部として、プロキシ・インスタンスの移行も計画する必要があります。プロキシ・モードで構成されたDPSとOUDはどちらもデータがないため、この移行は主に、新しいインスタンスの稼働準備ができた後の構成の移行とトラフィックの切替えで構成されます。

dps2oudコマンドを使用してDPSインスタンス構成をOUDに移行する方法の詳細は、『Oracle Unified Directory管理者ガイド』の第A.2.2項を参照してください。

2 移行ストラテジの選択

この章では、移行ストラテジを選択するための方法を示します。ストラテジの選択は、反復プロセスになる可能性があることに注意してください。この章の内容は次のとおりです。

- 第2.1項「要件の分析」

- 第2.2項「サポートされている移行ストラテジ」

2.1 要件の分析

移行プロセスは、アーキテクチャおよび操作上の要件と連携している必要があります。適切な移行ストラテジを選択することは、OUDにスムーズに移行するための重要な要因です。移行ストラテジを選択する際に考慮する重要な要因を次に示します。

2.1.1 本番環境での(O)DSEEとOUDトポロジの共存

共存させる方法を使用することで、差分移行プロセスを実行できます。このプロセスでは、クライアント・アプリケーションが徐々にOUDに変換される間、(O)DSEEとOUDデプロイメントが共存し、本番環境での同期が維持されます。この方法により、サービスを中断しなくてもアプリケーションを(O)DSEEに戻すこともできます。

共存が終了するまでOUDが提供するいくつかの付加価値サービス/機能をデプロイできないため、特定の期間にのみこのストラテジを使用することをお薦めする、という点を認識していることが重要です。同様に、変更を(O)DSEEにレプリケートできなくなるまで、トポロジはOUDによって可能となる書込みパフォーマンスの向上を提供できなくなります。

2つの環境を稼働させておくには、2つのインフラストラクチャを個別に管理する必要があるため、追加のシステム・リソースが必要です。また、2つの環境を同期させておくことでシステムがさらに複雑になるため、移行プロジェクトで共存が重要な要件になるかどうかを評価することをお薦めします。

2.1.2 共存と(O)DSEEとOUDの間のデータの整合性

レプリケーション中は、サーバー間ですべてのデータがコピーおよび同期され、最新の状態が維持されます。ただし、各サーバーには必ずしも同じデータ(特にメタデータ)が含まれるわけではありません。本番環境でのODSEEとOUDトポロジの共存を選択した場合は、次のガイドラインに従います。

- 2つの環境の間で想定されるデータの整合性のレベルを評価します。

- すべての変更が一貫して正しい順序で適用されるように、グローバル・レプリケーションの競合管理との厳密な整合性が必要かどうかを決定します。

- 同期の遅延に対応するか、(O)DSEEとOUDトポロジの間でほぼリアルタイムのデータ整合性を必要とするかを選択することで、一時的なデータの整合性の処理方法を決定します。

- トポロジ全体で一貫してアカウントがロックされるように、パスワード・ポリシー関連の完全な同期状態を必要とするかどうかを設定します。

注意:

非常に短期間の共存を必要とするプロジェクトでは、十分な機能を持つグローバル・パスワード・ポリシーのサポートを必要としない可能性があります。別々のサーバーで同じエントリを同時に変更すると、競合が発生する可能性があります。このような特定の状況では、完全な競合管理により、両方のサーバーでエントリが同じになります。

2.1.3 (O)DSEEインフラストラクチャでの移行の影響

特別な場合、(O)DSEEインフラストラクチャに限定的な変更を加えることで、移行プロセスを大幅に簡素化し、特定の機能のサポートが可能になる可能性があります。たとえば、(O)DSEEに対するそのような変更には、LDAPスキーマ拡張の追加、パスワード・ポリシー・モードの変更、レトロ変更ログのデプロイメントなどがあります。

移行ストラテジの選択の一部として、(ODSEE)に対する特定の変更が受入可能かどうかを決定します。

2.1.4 書込みサービスの中断を伴う(または伴わない)移行

サービスを中断せずにクライアント・トラフィックを(O)DSEEからOUDにリダイレクトできるかどうかは、重要な検討要素です。管理者は、移行中の書込みサービスを確実にする組込みの自動メカニズムを認識している必要があります。他のプロジェクトの場合、更新の中断は受け入れられません。

このガイドに示す一部の移行ストラテジでは、移行中に完全書込みの高可用性が実現します。他の移行ストラテジでは、トラフィックを複製できるプロキシなど、追加コンポーネントのデプロイメントが必要になります。

2.1.5 ユーザー・データ構造の変更

ディレクトリ・サービスを移行する前に、既存のディレクトリ・サービス・アーキテクチャおよびユーザー・データ構造を評価することもできます。既存のアーキテクチャに満足している場合は、ユーザー・データのサブセットのみを再度表示することもできます。

このガイドでは、ユーザー・データ構造の再設計を含む移行は取り上げません。移行の際にユーザー・データ構造の変更が必要な場合は、Oracle Support担当に問い合せてください。

2.2 サポートされている移行ストラテジ

この項では、Oracleが移行でサポートしているストラテジ、および技術的なニーズに最も適した移行ストラテジを選択する際に役立つ決定マトリックスについて説明します。次のいずれかのストラテジを選択します。

- 第2.2.1項「レプリケーション・ゲートウェイを使用した共存」

- 第2.2.2項「Oracle Directory Integration Platform (DIP)を使用した共存」

- 第2.2.3項「直接移行ストラテジ」

2.2.1 レプリケーション・ゲートウェイを使用した共存

このストラテジでは、(O)DSEEおよびOUDトポロジは、レプリケーション・ゲートウェイを使用することでネイティブ・レプリケーション・プロトコル・レベルで同期が維持されます。ゲートウェイ経由のレプリケーションでは、ポーリング・メカニズムが含まれないため、非常に低遅延になります。

レプリケーション・ゲートウェイは他のOUDコンポーネントのようにインストールおよび管理され、(O)DSEEとOUDの間で必要なレプリケーション・プロトコルが調整されます。レプリケーション・ゲートウェイでは、2つのタイプのディレクトリ間で厳密なデータ整合性が提供され、競合管理が十分に活用されます。完全なディレクトリ・メタデータがレプリケートされると、適切なアカウント・ロックが維持されるように、レプリケーション・ゲートウェイは内部パスワード・ポリシー状態も同期します。

レプリケーション・ゲートウェイは、(O)DSEEとOUDの間で双方向の完全なレプリケーションを提供します。それは、ゲートウェイ・レベルで格納されることなく、異機種環境のレプリケートされたトポロジ間で更新を伝播する高パフォーマンスのルートです。レプリケーションの単位は、(O)DSEE側で定義されているサフィックスです。OUDからの変更が(O)DSEEに反映されない間にディレクトリ・サーバーからの変更がOUDにレプリケートされるように、レプリケーション・ゲートウェイを一方向モードで実行することもできます。

高可用性を実現するために、すべてのシナリオで2つの(O)DSEEマスターと2つのOUDレプリケーション・サーバーの間に少なくとも2つのレプリケーション・ゲートウェイ・サーバーがデプロイされます。これにより、シングル・ポイント障害のリスクが排除されます。

2.2.2 Oracle Directory Integration Platform (DIP)を使用した共存

Oracle Directory Integration Platform (DIP)は、様々なリポジトリで使用される多目的の同期ツールで、次の処理を実行できます。

- (O)DSEEとOUDトポロジを同期します。

- 停止時間なしで徐々に移行する際にOUDを使用してディレクトリ・サーバーを実行します。

- (O)DSEEおよびOUDで構成された変更ログを使用して、変更を検出し、繰り返します。

同期は定期的に行われ、実行のたびに構成可能な最大数の変更が処理されます。DIPはユーザー・データのみを同期します。

DIPの詳細は、『Oracle Directory Integration Platform (DIP)管理者ガイド』を参照してください。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

2.2.3 直接移行ストラテジ

このストラテジでは、標準のディレクトリ管理コマンドとともにエクスポートおよびインポート・メソッドを使用します。ユーザー・データおよび構成は(O)DSEEからエクスポートされ、このガイドで説明するツールおよび手順を使用して必要に応じて調整されます。その後、ユーザー・データおよび構成がOUDにインポートされます。

直接移行ストラテジは特異な移行であり、簡単かつ迅速に実行できます。書込み機能の中断が受入れ可能な場合に使用できます。通常、ディレクトリ管理者はロード・バランサまたはLDAPプロキシを使用して、インフラストラクチャを読取り専用モードに設定し、データを(O)DSEEからエクスポートし、データをOUDにインポートした後、トラフィックをOUDにリダイレクトします。

2.2.4 決定マトリックス

次の決定マトリックスは、移行ストラテジを選択する際の主要な決定要因をまとめたものです。

表2-1 移行ストラテジの決定要因

決定要因

レプリケーション・ゲートウェイを使用した共存

DIPを使用した共存

直接移行

共存

はい

はい

いいえ

データ整合性レベル

厳密

低遅延

ルーズ

遅延はDIP構成に依存します

N/A

パフォーマンス

高

中

N/A

(O)DSEEへの影響

(O)DSEEリリースおよび設定に依存します(第3章「移行ストラテジの検証」)

レトロ変更ログの有効化

いいえ

書込みサービスの可用性

組込みサポート

組込みサポート

追加コンポーネント(*)が必要です

データ調整/構造の変更

いいえ

可(制限を適用)

可(任意で実行可能)

高可用性

組込みサポート

デプロイメント固有

N/A

(*)このガイドでは取り上げません

3 移行ストラテジの検証

ストラテジを選択した後、次のステップではストラテジを検証します。この章では、潜在的な障害を検出し、選択したストラテジを検証するためのガイダンスを示します。この章の内容は次のとおりです。

- 第3.1項「選択したストラテジの検証」

- 第3.2項「DSEEバージョンの検討」

- 第3.3項「(O)DSEEのレガシー機能の調整」

- 第3.4項「(O)DSEE技術特性の影響」

3.1 選択したストラテジの検証

選択した最適な移行ストラテジを検証するには、選択したストラテジについて、(O)DSEEリリース、使用されるパスワード・ポリシーのバージョン、および第2章「移行ストラテジの選択」で識別されるもの以外に(O)DSEE固有の機能(ロール、サービス・クラスなど)が使用されるかどうか、という側面をすべて検討する必要があります。

3.2 DSEEバージョンの検討

次のようにレプリケーション・ゲートウェイが使用される場合、DSEEバージョンは移行に影響します。

- パスワード・ポリシー状態のレプリケーション
DSEE 5.2ではパスワード・ポリシー属性セットが使用されます。DSEE 6.0以上では、新しく標準のパスワード・ポリシー属性(DS6-mode)セットが導入されました。DSEE 5.2パスワード・ポリシーとDS6パスワード・ポリシーのどちらを選択するかは、構成によって決まります。

OUDとレプリケーション・ゲートウェイは標準属性を管理します。(O)DSEEとOUDの間で完全に機能するパスワード・ポリシーでは、すべての(O)DSEEインスタンスをDS6モードで実行する必要があります。

デフォルトのパスワード・ポリシー・モードからDS6モードに切り替えるには、管理操作が必要です。

パスワード・ポリシーの詳細は、Oracle Directory Server Enterprise Edition管理者ガイドのパスワード・ポリシーの互換性に関する項を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

DSEE 5.2インスタンスまたは既存の(O)DSEEトポロジ内にある古いパスワード・ポリシー・モードの(O)DSEEインスタンスでは、(O)DSEEとOUDの両方にスキーマ拡張が必要です。

- レプリケーション・ゲートウェイの統合
レプリケーション・ゲートウェイは、互換性のあるODSEEマスター・インスタンスと通信する必要があります。つまり、レプリケーション・ゲートウェイに接続されたODSEEサーバーは、少なくとも1つのODSEE 11gR1 (11.1.1.5)インスタンスである必要があります。いずれも使用できない場合、レプリケーション・ゲートウェイで使用するためにODSEE 11gをトポロジに追加する必要があります。このODSEE 11gR1とそのレプリケーション・ゲートウェイを同じボックス内に配置しておくことも、既存のインスタンスをODSEE11gR1 (11.1.1.5)以上にアップグレードすることもできます。

図3-1 レプリケーション・ゲートウェイを使用したOUDへの移行プロセス

3.3 (O)DSEEのレガシー機能の調整

選択したストラテジに関係なく、次のものはOUDを使用するために調整する必要があります。

- ロールベースのACI

- ロールとサービス・クラス(CoS)

- カスタム・パスワード・ポリシー

3.3.1 ロールベースのACI

ロールベースのACIを使用すると、ユーザー・ロールに基づいてデータへのアクセスを管理できます。ロールベースのACIはOUD 11g R2 リリース2 (11.1.2.2)ではサポートされていないため、そのようなACIは、使用するストラテジに関係なく、移行プロセス中にグループベースのACIに調整および置換する必要があります。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、ACIを含むすべてのディレクトリ・メタデータがレプリケートされます。つまり、ロールベースのACIは、共存が確立される前に(O)DSEE上のグループベースのACIに置換する必要があります。

DIPストラテジを使用する場合、同期をデプロイする前に(O)DSEE上のそのようなACIを調整するか、またはそのようなACIの同期の除外を検討する必要があります。

ロールベースのACIの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.2 ロールとサービス・クラス(CoS)

第4.6.6項「OUDへのロールの移行」および第4.6.5項「サービス・クラス(CoS)の管理」で説明しているように、(O)DSEEのロールとサービス・クラスは、同等のOUDメカニズムに置換する必要があります。場合によっては、対応するOUDメカニズムでディレクトリ・メタデータを使用する必要があります。たとえば、サービス・クラス定義は、ユーザー・データとともに格納されるOUD集合属性定義に置換できます。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、これらのOUD固有のメタデータを(O)DSEEにレプリケートできます。そのような場合、これらの追加属性とオブジェクト・クラスをサポートするように(O)DSEEスキーマを拡張する必要があります。互換性のために(O)DSEEサーバーで使用できるOUDスキーマの抽出内容は、OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldifで使用できます。

ロールとCoSの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.3 カスタム・パスワード・ポリシー

カスタム・パスワード・ポリシーは、データの一部として(O)DSEEに格納できます。このようなパスワード・ポリシー定義は、(OUDでサポートされる)標準属性と(OUDの他の属性に置換される) (O)DSEE固有の属性で構成されます。さらに、特定のユーザー・エントリへのパスワード・ポリシーの割当ては、(O)DSEEとOUDで異なります。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、一部のOUD固有のメタデータをレプリケートできますが、(O)DSEEスキーマ拡張が必要です。互換性のためにODSEEサーバーで使用できるOUDスキーマの抽出内容は、OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldifで使用できます。

カスタム・パスワード・ポリシーの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.4 データの矛盾の管理

OUDは、属性値構文の検証を含む完全なスキーマ検査を実装するため、(O)DSEEに格納されているユーザー・データの特性が移行に影響する可能性があります。(O)DSEEは完全なスキーマ検査を実装しないため、(O)DSEEで受け入れられる一部の値はOUDでは拒否される可能性があります。これらのデータの矛盾は、OUDに付属する診断ツールを使用して識別できます。これらの問題に対処するには、移行前のデータの修正、スキーマの修正、OUDでのチェックの実行など、複数の方法があります。

3.4 レビュー: (O)DSEE技術特性の影響

次の表に、(O)DSEE技術特性の影響を示します。アスタリスク(*)は、移行が双方向のレプリケーションを必要としない場合に優先されるオプションであることに注意してください。このオプションを使用すると、一方向のレプリケーションは変更を(O)からOUDにのみレプリケートするため、(O)DSEE側の影響が軽減します。

表3-1 既存のディレクトリ・サーバー・リリース

ディレクトリ・サーバー・リリース

レプリケーション・ゲートウェイ

DIP

直接

DSEE 5.2

- 1つのODSEE 11gインスタンスをゲートウェイ・コンパニオンとしてデプロイします。

- OUDパスワード・ポリシーを使用してDSEEスキーマを拡張します(*)。

- 制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます

- 制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます

- 制限: パスワード・ポリシー状態は移行中にリセットされます。

DSEE 6.x/7.x

- 1つのODSEE 11gインスタンスをゲートウェイ・コンパニオンとしてデプロイします。

- OUDパスワード・ポリシーを使用してDSEEスキーマを拡張します(*)。

- 必要に応じて、DSEEパスワード・ポリシー・モードをアップグレードします。

- 制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます。

- 制限: パスワード・ポリシー状態は移行中にリセットされます。

ODSEE 11gR1+

- グローバル・パスワード・ポリシーが不要な場合は、OUDパスワード・ポリシーを使用してDSEEスキーマを拡張し、古いパスワード・ポリシー・モードをそのまま使用します(*)。

- 必要に応じて、DSEEパスワード・ポリシー・モードをアップグレードします。

- 制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます。

- 制限: パスワード・ポリシー状態は移行中にリセットされます。

表3-2 既存のディレクトリ・サーバー・データ

既存のディレクトリ・サーバー・データ

レプリケーション・ゲートウェイ

DIP

直接

メタデータ: ロールベースのACI

- 移行前にDSEE ACIを更新します。

- 移行前にDSEE ACIを更新します

または

- OUDのACIを調整し、ACIを同期しません。

- ACIを調整します。

メタデータ: CoS/ロール

- CoS/ロールを調整します。

- オプションで、DSEEスキーマを拡張します(*)。

- CoS/ロールを調整します(同期しません)。

- CoS/ロールを調整します。

メタデータ: サブ・エントリとしてのパスワード・ポリシー(データ内)

- パスワード・ポリシーを調整します。

- オプションで、移行前にパスワード・ポリシーを更新します。

- 可能であれば、カスタム・パスワード・ポリシーを同期または調整しません。

- パスワード・ポリシーを調整します。

DSEE内のデータが無効です(LDAPスキーマと完全に一致しません)。

- DSEE内のデータを修正します

または

- OUDのスキーマ検査を緩和します

または

- OUDのスキーマを更新します。

- DSEE内のデータを修正します

または

- OUDのスキーマ検査を緩和します

または

- OUDのスキーマを更新します。

- DSEE内のデータを修正します

または

- OUDのスキーマ検査を緩和します

または

- OUDのスキーマを更新します。

3.4.1 ds2oudを使用した関連する(O)DSEE機能の識別

OUDには、移行に影響する(O)DSEE機能を自動的に識別するds2oudという診断ツールが用意されています。診断モードでは、ds2oudは、OUDに完全に対応するものがない、現在使用中の(O)DSEE固有の機能を識別することもできます。これには、ロールとサービス・クラスが含まれます。ds2oudツールは構成およびスキーマを移行し、調整が必要な(O)DSEE機能を識別するため、すべてのストラテジで役に立ちます。ds2oudツールが特に役立つのは、レプリケーション・ゲートウェイ・ストラテジを使用する場合です。これは、ゲートウェイはユーザー・データ以外にディレクトリ・メタデータをレプリケートするためです。このツールは(O)DSEEスキーマとデータも分析して、OUDによって実装されるLDAPスキーマに準拠していることを確認します。

ds2oudコマンドを診断モードで実行する方法の詳細は、『Oracle Unified Directory管理者ガイド』のds2oudに関する項を参照してください。

『Oracle Unified Directory管理者ガイド』は、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlにあります。

4 移行の実行

この章では、OUDに移行するために実行する必要がある手順について説明しており、項目は次のとおりです。

- 第4.1項「OUDへの移行の開始」

- 第4.2項「手順1: 参照OUDインスタンスの作成」

- 第4.3項「手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断」

- 第4.4項「手順3: ディレクトリ・スキーマの移行」

- 第4.5項「手順4: ディレクトリ構成の移行」

- 第4.6項「手順5: ユーザー・データおよびディレクトリ・メタデータの移行」

- 第4.7項「手順6: レプリケーション・ゲートウェイまたはDIPのデプロイ」

- 第4.8項「手順7: レプリケートされるトポロジのデプロイ」

- 第4.9項「手順8: OUDトポロジへのトラフィックのリダイレクト」

- 第4.10項「手順9: 共存の中止」

4.1 OUDへの移行の開始

この章では、OUDに移行するために実行する必要がある手順について説明します。使用している移行ストラテジに関係なく、この章のすべての手順を実行する必要があります。

注意:

直接ストラテジを使用している場合は、第4.7項「手順6: レプリケーション・ゲートウェイまたはDIPのデプロイ」にスキップしてください。

4.2 手順1: OUDインスタンスの作成

まず、OUD 11g リリース2 (11.1.2)をインストールして新しいインスタンスを作成する必要があります。移行手順の実行中に新しいOUDインスタンスが構成および初期化された後、レプリケートされるトポロジに追加インスタンスを構成およびデプロイするためのベースとして使用されます。

OUDインスタンスのインストール手順は、『Oracle Unified Directoryインストレーション・ガイド』を参照してください。

次のいずれかの方法で新しいOUDを設定できます。

- Graphical User Interface (GUI)

- コマンド行インタフェース

- バッチ・モード

ds2oudコマンドが正常に機能するには、サフィックスを付けずに新しいインスタンスを構成する必要があります。

GUIまたはCLIを使用してディレクトリ・サーバーを構成するには、サフィックス/ベースdnを空白のままにしておく必要があります。GUIおよびCLIを使用してディレクトリ・サーバーを設定する手順は、『Oracle Unified Directoryインストレーション・ガイド』を参照してください。

ディレクトリ・サーバーをバッチ・モードで設定する場合は、-bオプションを指定しないでください。

注意:

ds2oudコマンドは<OUD_INSTANCE>/OUD/binにあります。OUD_INSTANCEは、第4.2項「手順1: 参照OUDインスタンスの作成」で作成したベースOUDインスタンスのパスです。

4.3 手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断

この手順では、OUD側に対応するものがなく自動的に移行できない機能を識別するために、既存の(O)DSEE設定を分析します。これらの機能は、移行中に特に注意する必要があります。

(O)DSEEディレクトリ・サーバーにアクセスするためのLDAP管理パスワードがあることを確認します。診断サイクル中にこのサーバーで変更は行われません。詳細は、『Oracle Unified Directory管理者ガイド』のrootユーザーと特権サブシステムの理解に関する項を参照してください。

(O)DSEEディレクトリ・サーバーからエクスポートされたユーザー・データを含むLDIFファイルがあることを確認します。LDIFファイルのエクスポートの詳細は、次を参照してください。

- 5.2のLDIFファイルのエクスポートの詳細は、Sun ONE Directory Server 5.2リファレンス・マニュアルのデータベースのエクスポートに関する項を参照してください。リファレンス・マニュアルは、http://docs.oracle.com/cd/E19199-01/のSun Java Enterprise System 2003Q4 Webサイトにあります。

- 6.xのLDIFファイルのエクスポートの詳細は、Sun Java System Directory Server Enterprise Edition 6.3管理ガイドのLDIFへのエクスポートに関する項を参照してください。管理ガイドは、http://docs.oracle.com/cd/E19261-01/のSun Java System Directory Server Enterprise Edition 6.3 Webサイトにあります。

- 7.0のLDIFファイルのエクスポートの詳細は、Sun Directory Server Enterprise Edition 7.0管理ガイドのLDIFへのエクスポートに関する項を参照してください。管理ガイドは、http://docs.oracle.com/cd/E19424-01/のSun Directory Server Enterprise Edition 7.0 Webサイトにあります。

- 11gのLDIFファイルのエクスポートの詳細は、Oracle Directory Server Enterprise Edition管理ガイドのLDIFへのエクスポートに関する項を参照してください。管理ガイドは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.5)ライブラリにあります。

(O)DSEEサーバー・スキーマ拡張を保持するユーザー・スキーマ拡張のコピー(99user.ldif)へのアクセス権があることを確認します。

この診断プロセスは、OUDに付属するds2oudツールを実行することで実行されます。診断モードのds2oudで検出される差異の数を使用すると、複雑性および移行作業を見積もることができます。

4.3.1 (O)DSEEディレクトリ・サーバー、構成およびスキーマの診断

OUDに移行する必要があるサーバー構成を診断するには、次のds2oudコマンドを実行します。

$ ds2oud --diagnose -h host1.example.com -p 1389 \
-D "cn=directory manager" -j pwdfile

前述のコマンドで、host1はOUDサーバーではなく(O)DSEEサーバーです。

--diagnoseサブコマンドは、ディレクトリ・サーバー構成の次の要素を調べます。

- サポートされていないプラグイン

- デフォルトのスキーマに対する拡張

- レプリケーション・ゲートウェイを使用する場合に影響する可能性がある、使用されるパスワード・ポリシーのタイプ

- 暗号化された属性

- 索引設定

- グローバル構成パラメータ

前述の要素ごとに、ds2oudは移行する必要があるものと潜在的な非互換性(ある場合)を調べます。次に出力の例を示します。

*** diagnose the deployment ...

*******************************************************************************
Diagnose ODSEE Server : host1:1389
*******************************************************************************

** Plugins : No user plugins are defined, nothing particular to migrate

** Plugins : No subtree counter plugins are enabled, nothing particular to
migrate

** Schema

The schema was extended regarding the original delivery. The following schema
should be added to the new OUD server
attributeTypes : ( 2.16.840.1.113730.9999 NAME 'customAttributeType' DESC
'Oracle defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE X-ORIGIN ( 'Custom' 'user defined' ) )

** Password Policy

A compatible password policy is defined, nothing particular to migrate

** Naming context(s) available on the ODSEE server :
o=migration

No incompatibility has been detected for naming context o=migration

** Indexes

Only default indexes are defined, nothing particular to migrate

** Encrypted attributes
No encrypted attributes are defined, no action is required

4.3.2 ディレクトリ・サーバー・データの診断

データをインポートする前に、ディレクトリ・サーバー・データがOUDスキーマに準拠していることを確認するには、次の手順を実行します。

1. ディレクトリ・サーバーからLDIFにデータをエクスポートします。LDIFへのデータのエクスポートの詳細は、第4.2項「手順1: 参照OUDインスタンスの作成」を参照してください。

2. ds2oudコマンドを実行してデータを診断します。次に例を示します。

$ ds2oud --ldifDBFile odsee-data.ldif --userSchemaFile 99user.ldif

この例では、odsee-data.ldifはLDIFにエクスポートされるディレクトリ・サーバー・データ、99user.ldifはカスタマイズされたディレクトリ・サーバー・スキーマ・ファイルです。次にデータ診断中の出力の例を示します。

*** diagnose the data ...

*******************************************************************************
* Diagnose ODSEE LDIF data file :
odsee-data.ldif
*******************************************************************************

Error validating data against OUD schema
Entry : unknown
org.opends.sdk.DecodeException: Entry uid=user2,ou=users,o=data read from LDIF starting at line 49 includes value "" for attribute description that is invalid according to the associated syntax: The operation attempted to assign a zero-length value to an attribute with the directory string syntax

4.3.3 診断中の既知のエラー

次の理由でスキーマ・エラーが報告される可能性があります。

- デフォルト・スキーマが異なる。

- OUDに標準スキーマの最新バージョンが使用されている。

- 属性値構文の検証と包含ルールの検証

- サポートされていないディレクトリ・メタデータ。これには、ロールベースのACI、LDAPサブエントリとしてOUDパスワード・ポリシーで現在サポートされていないロールまたはサービス・クラス定義があります。これらのサブエントリには、(O)DSEEとOUDで異なる(O)DSEE固有の拡張アカウントベースのリソース制限があります。

前述のケースでは、OUDは次のコマンドを提供して、スキーマの制約を柔軟にし、そのスキーマ・エラーを解決します。

構造的なobjectclassエラー:

インポート中にディレクトリ・サーバー・データが拒否されると、構造的なobjectclassエラーが発生します。このエラーの一般的な理由は、ユーザー・エントリの構造化オブジェクト・クラスです。ユーザー・エントリには1つの構造オブジェクト・クラスが必要です。エントリが0個または複数ある場合、エントリは拒否されます。また、(O)DSEEディレクトリ・サーバーは2つのオブジェクト・クラス・タイプを区別しないため、この種のスキーマの矛盾は頻繁に発生します。このエラーを回避するには、次のコマンドを使用します。

dsconfig set-global-configuration-prop --set \
single-structural-objectclass-behavior:accept -n

無効な属性値エラー:

属性値は、スキーマに定義されている属性構文に準拠する必要があります。デフォルトでは、OUDで属性構文チェックが有効になっています。たとえば、ブール構文を持つ属性は、TRUEまたはFALSE値のみを保持できます。また、長さが0の属性値は、インポート中にOUDで拒否されます。ただし、次のコマンドを使用することで、DirectoryString構文でこの制約を柔軟にすることができます。

dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \
--set allow-zero-length-values:true -n

4.4 手順3: ディレクトリ・スキーマの移行

ディレクトリ・ユーザー・スキーマを移行する場合、移行モードのds2oudツールを使用して、(O)DSEEスキーマ拡張がOUD参照インスタンス・スキーマに自動的に追加されます。

スキーマはds2oudツールを使用して自動的に移行されます。構成を移行する前にスキーマを移行しないと、後続の移行手順で構成エラーが発生します。次のコマンドは、(O)DSEEディレクトリ・サーバーからOUDにユーザー・スキーマを伝播し、(O)DSEEスキーマを他のOUDインスタンスに移行する場合にも使用できます。

$ ds2oud --migrateUserSchema -h host1.example.com -p 1389 \
-D "cn=directory manager" -j pwdfile

(O)DSEEスキーマを他のOUDインスタンスに移行する場合、<OUD_INSTANCE>/OUD/config/schemaディレクトリの内容を新しいOUDインスタンスの対応するディレクトリにコピーし、OUDインスタンスを再起動することもできます。

注意:

ds2oud --migrateUserSchemaコマンドは、(O)DSEEユーザー・スキーまで行われた拡張を処理しますが、ユーザー・データをOUDにインポートするときにスキーマ違反エラーが発生する可能性があります。これは、ユーザー定義スキーマと異なり、標準スキーマは(O)DSEEとOUDで若干異なるためです。インポート・プロセス中にスキーマ違反が発生した場合、(O)DSEE診断プロセスの結果として提示される可能性がある追加のスキーマ拡張を作成する必要があります。

4.5 手順4: ディレクトリ構成の移行

この手順では、(O)DSEEと同等のLDAPサービスが提供されるようにOUD参照インスタンスを構成します。

(O)DSEEディレクトリ構成の大部分は、移行モードのds2oudツールを使用して自動的に移行されます。自動的に移行できないその他の構成要素は、第4.3項「手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断」で識別されています。

自動的に生成される構成コマンドは、他のインスタンスを迅速に初期化する際に再利用できるように、バッチ・ファイルに保持されます。手動で作成した追加コマンドもそのバッチ・ファイルに追加することをお薦めします。

4.5.1 ds2oudコマンドを使用した構成設定の移行

次の構成設定を(O)DSEEディレクトリ・サーバーからOUDに移行するには、ds2oudコマンドを実行します。

- 命名コンテキスト

- OUDに関連するグローバル構成設定

- Size-limit

- Look-through-limit

- Idle-time-limit

- Max-psearches

- Bind-with-dn-require-password

- Allidthresholds

- データベース索引

- グローバル・デフォルト・アクセス制御

- サポートされている組込みプラグイン

- 7ビット検索

- UID一意性プラグイン

- 参照整合性プラグイン

- 厳密なパスワード・ポリシー検査

前述の各構成設定を各OUDインスタンスに適用するには、ds2oudコマンドをバッチ・モードで実行する必要があります。次に、dsconfigで適用されるコマンドのリストを生成します。変更を補完し、すべてのターゲット・システムで簡単に再現できるようにするために、これを実行することをお薦めします。

構成を移行するための管理コマンド・バッチ・ファイルを生成するには、次のコマンドを実行します。

ds2oud --migrateConfiguration
--odseeBindDN "cn=directory manager"
--odseePort <ODSEE_PORT>
--odseeBindPasswordFile <ODSEE_ADMIN_PASSWORD_FILE>
--oudBindDN "cn=directory manager"
--oudBindPasswordFile <OUD_ADMIN_PASSWORD_FILE1>
--oudPort <OUD_LDAP_PORT1>
--oudAdminPort <OUD_ADMIN_PORT1>
--no-prompt --batchFile <COMMAND_BATCH_FILE>

4.5.1.1 SSL証明書の移行

デフォルトでは、OUDインスタンスの作成時に自己署名付き証明書が自動的に生成されます。移行がSSLクライアントに対して透過的になるように、新しいOUDインスタンスの(O)DSEEサーバー証明書を再利用することもできます。ただし、使用するSSL証明書オプションに応じて、(O)DSEEサーバーと同じボックスにOUDインスタンスをインストールする必要がある場合があります。

SSLサーバー証明書を再利用するには、次の手順を実行します。

1. ディレクトリ・サーバー証明書をPKCS12ファイルにエクスポートします。次の例では、dsee.p12はPKCS12ファイル名です。

dsadm export-cert -o dsee.p12  <instance_path> defaultCert

注意:

デフォルトでは、ディレクトリ・サーバー証明書の別名はdefaultCertです。別の値を使用する場合は、適切な別名を使用します。ディレクトリ・サーバーのエクスポートの詳細は、『Oracle Unified Directory管理者ガイド』を参照してください。

2. PKCS12ファイルを<OUD_INSTANCE>/configにコピーします。

3. <OUD_INSTANCE>/configディレクトリに、PKCS12ファイル・パスワードを含むPINファイル(dsee.p12.pinなど)を作成します。ディレクトリ・サーバー証明書は、2つの方法でOUDインスタンスにインポートできます。

- ディレクトリ・サーバーからエクスポートされたファイルを指すPKCS12 OUDキーストアを構成します。

- 証明書をデフォルトのJKS OUDキーストアにインポートします。

4.5.1.2 PKCS#12キーストアの構成

OUD PKCS12キーストアを構成するには、次のコマンドを実行します。

dsconfig set-key-manager-provider-prop \
-provider-name PKCS12 \
-set key-store-file:config/dsee.p12 \
-set key-store-pin-file:config/dsee.p12.pin \
-set enabled:true \

前述のコード例では、dsconfigコマンドの接続関連の引数(ports、credentialsなど)は、簡略化のため省略されています。

4.5.1.3 PKCS#12キーストアを使用するためのLDAPS接続ハンドラの構成

LDAPS接続を構成するには、次のコマンドを実行します。

dsconfig set-connection-handler-prop \
--handler-name LDAPS\ Connection\ Handler \
--set key-manager-provider:PKCS12 \

4.5.1.4 ディレクトリ・サーバーの証明書キー・ペアのインポート

証明書を既存のOUD JKSキーストアにインポートするには、次の手順を実行します。

1. OUDで使用されるJVMのJAVA_HOMEを探します。使用されるJVMのバージョンは、OUDエラー・ログの開始時に表示されます。

2. 次のコマンドを実行して、証明書をインポートします。

JAVA_HOME/bin/keytool -v -importkeystore -srckeystore <Path to PKCS12 cert file exported from DSEE>  -srcstoretype PKCS12 -destkeystore <OUD_INSTANCE_DIR>/OUD/config/keystore  -deststoretype JKS

プロンプトが表示されたら、DSEEサーバー証明書のエクスポートに使用したJKS PIN (<OUD_INSTANCE_DIR>/OUD/config/keystore.pinにあります)およびPKCS12 PINを指定します。

3. インポート処理が成功したことを確認します。
OUD JKSキーストアの内容をリストするには、次のコマンドを使用します。

JAVA_HOME/bin/keytool -list -keystore <OUD_INSTANCE_DIR>/OUD/config/keystore

キーストア・パスワードを入力します。

キーストア・タイプ: JKS

キーストア・プロバイダ: SUN

キーストアには2つのエントリが含まれます。

defaultcert, Aug 29, 2013, PrivateKeyEntry, Certificate fingerprint (MD5): 10:63:DC:B5:6B:C8:F3:A0:6B:A7:23:9E:0B:EA:9C:30
server-cert, Aug 29, 2013, PrivateKeyEntry, Certificate fingerprint (MD5): BE:C9:F3:8A:49:98:96:15:EF:AC:B4:08:6F:76:FB:05

デフォルトでは、(O)DSEEディレクトリ・サーバー証明書の別名は"defaultCert"、OUDサーバー証明書の別名は"server-cert"であり、Javaはキーストアに存在する証明書のうち最適なものを自動的に選択します。特定の証明書を強制的に使用するには、次のコマンドを実行します。

dsconfig set-connection-handler-prop \
--handler-name LDAPS\ Connection\ Handler \
--set ssl-cert-nickname:defaultcert \

4.5.1.5 暗号化された属性の移行

属性を復号化するには、dsconf exportを指定して--decrypt-attrオプションを使用します。LDIFファイルにエクスポートしたときに属性が復号化されることを確認する必要があります。インポート中に値が再暗号化されるように、対応する属性の暗号化をOUDで構成する必要があります。

OUDで暗号化された属性を構成する方法の詳細は、『Oracle Unified Directory管理者ガイド』を参照してください。

4.5.2 共存のためのパスワード記憶スキームの変更

共存ストラテジ、つまりレプリケーション・ゲートウェイまたはDIPを使用している場合、OUDパスワード記憶スキームの構成を変更する必要があります。これにより、OUD側で構成されるパスワード記憶スキームが、(O)DSEEでサポートされるアルゴリズムに対応するようになります。それ以外の場合、OUD側でパスワードを変更すると、ユーザーは(O)DSEE側でログインできなくなります。(O)DSEEでは、パスワードはパスワード暗号化スキーム(SHA-1など)を使用して格納されます。OUDでは、これに似ていますが、デフォルトではパスワードはSSHA512に格納されます。OUDでは、パスワード記憶スキームはパスワード・ポリシーで構成されます。

4.5.3 構成変更の適用

第4.5.1項「ds2oudコマンドを使用した構成設定の移行」で生成された構成の変更を、次のコマンドを使用してOUDディレクトリ・サーバー・インスタンスに適用できます。

dsconfig -h <oud hostname> -p <oud admin port> -D cn="directory manager" -w <admin password> \
-F command_batch_file -X -n

dsconfigコマンドの-Fオプションまたは--batchFilePathオプションを使用して、1つのファイルにまとめることにより1回のコマンドで完了できる複数の操作を指定できます。これにより、複数のdsconfigコマンドが必要な場合、パフォーマンスが大幅に向上し、他のインスタンスの構成が簡素化されます。

第4.5.1.1項「SSL証明書の移行」に示した追加の構成変更も適用する必要があります。

注意:

スキーマの変更は、常に構成変更の前に適用する必要があります。これらの構成変更は、後でデプロイされる各OUDインスタンスに適用する必要があります。詳細は、第4.7.1項「レプリケーション・ゲートウェイのデプロイ」を参照してください。

4.6 手順5: ユーザー・データおよびディレクトリ・メタデータの移行

OUD参照インスタンスを構成すると、実際の(O)DSEEユーザー・データおよびディレクトリ・メタデータとともにロードされます。

4.6.1 (O)DSEEからOUDへのユーザー・データのエクスポート

まず、ディレクトリ・サーバーに存在するユーザー・データをOUDに再インポートできるように、LDIF形式にエクスポートする必要があります。LDIFファイルへのエクスポートの詳細は、第4.3項「手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断」を参照してください。

エクスポートされるデータは、選択した移行ストラテジによって異なります。たとえば、直接移行ストラテジまたはDIPを使用した移行ストラテジを使用している場合、ディスク上の大量のデータを占めるレプリケーション・メタデータはエクスポート時に除外する必要があります。ただし、レプリケーション・ゲートウェイを使用した移行ストラテジの場合、レプリケーション・メタデータが必要です。

直接移行ストラテジまたはDIPを使用した移行ストラテジを使用している場合は、次の例に示すように、dsconfエクスポート・コマンドを実行してユーザー・データをLDIFにエクスポートします。

$ dsconf export -no-repl --decrypt-attr \
-h host1.example.com -p 1389 \
dc=example,dc=com odsee-data.ldif

レプリケーション・ゲートウェイ・ストラテジを使用した移行を使用している場合は、レプリケーション・メタデータを保持し、OUD形式に調整する必要があります。このストラテジを使用してユーザー・データをLDIFにエクスポートするには、次の例に示すように、dsconf exportコマンドを実行します。

$ dsconf export -f opends-export --decrypt-attr -h host1.example.com -p 1389 \
dc=example,dc=com odsee-data.ldif

注意:

前述のコマンドの-f opends-exportオプションは、ODSEE 11g リリース1 (11.1.1.5以上)にのみ適用可能です。これは、レプリケーション・ゲートウェイを使用している場合に必要なODSEE 11gマスターからデータをエクスポートする必要があるためです。ディスク上の暗号化されたデータは、エクスポート中に復号化する必要があることにも注意してください。

4.6.2 OUDへのデータのインポート

import-ldifコマンドは、LDIFファイルから読み込まれたデータをOUDディレクトリ・サーバー・バックエンドに移入するために使用します。次に、import-ldifの例を示します。

import-ldif -b <your user data suffix>  -n userRoot --excludeAttribute "nsds5replconflict"  -l <path to LDIF file>

移行時にopends-exportオプションを使用すると、(O)DSEE固有の属性が一部のエントリに存在する場合があり、これらのエントリがインポートされないようにできます。たとえば、nds5replconflictが(O)DSEEのデータに存在する場合があるため、OUDへのインポート時に、次のインポート・オプションを使用してこの属性をフィルタする必要があります。

--excludeAttribute "nsds5replconflict"

4.6.3 ディレクトリ・メタデータの移行

ディレクトリ・メタデータの移行は、使用する移行ストラテジによって異なります。これには、アクセス制御情報(ACI)、集合属性、LDAPサブエントリなどがあります。

- 直接移行ストラテジの場合: ディレクトリ・メタデータのみをただちに調整する必要があります。

- レプリケーション・ゲートウェイ・ストラテジの場合: ディレクトリ・サーバーとOUDの間でディレクトリ・メタデータがレプリケートされます。ディレクトリ・メタデータは両方で互換性を維持する必要があります。ただし、一部のメタデータは2つの環境間で異なるため、エラーまたはデータの損失を回避するために追加のスキーマ拡張が必要になります。

- DIPストラテジの場合: ユーザー・データを同期するようにDIPを構成する必要があります。通常、ディレクトリ・メタデータは手動でOUDに追加されます。メタデータを同期するようにDIPを構成することもできます。

データへのアクセスは、エントリのアクセス権を指定するアクセス制御命令(ACI)で管理されます。ACIは、ユーザー・データの一部として、またはOUD構成に格納できます。

- グローバルACIとデータ内のACI
グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。これらは構成に格納されます。(O)DSEEとOUDのグローバルACIは、レプリケートされないためにエラーが発生しない場合、異なる可能性があります。

ds2oudツールは、グローバルACIをOUDグローバルACIに自動的に移行します。

データの一部として格納されるACIはレプリケートされます。

- 構文の違い
現在、rolednキーワードはOUD 11g リリース2ではサポートされていません。ACI構文チェックが失敗するため、rolednキーワードを含むACIをOUDにインポートすることはできません。ロールをグループに置換し、rolednキーワードをgroupdnに置換できます(「ロールとACI」を参照)。

targetscopeキーワードの新しい値subordinateは、OUDで導入されます。この値は(O)DSEEではサポートされないため、(O)DSEEとOUDの間の双方向レプリケーション・トポロジでは使用しないでください。

- 動作の違い
同じACIの評価が(O)DSEEとOUDで異なる場合があります。デフォルトではOUDは(O)DSEEより少ないアクセス権を付与するため、OUDが(O)DSEEのように動作するように、移行中に追加の書込みアクセス権を付与する必要があります。このような場合、OUD ACIの評価は(O)DSEE側よりも柔軟性が低くなります。

デフォルトでは、OUD ACIはユーザーが別のユーザーのパスワードをリセットするのを許可しません。OUDでは、(O)DSEEと同等の動作を実行するための権限を追加する必要があります。権限サブシステムを無効にすることもできます。たとえば、次のコマンドでは、管理者は(O)DSEEのユーザー・パスワードをリセットできます(このタイプのパスワード・リセットは、OUDではデフォルトで拒否されます)。

ldapmodify -p <dsee port> -D "cn=directory manager"-w <admin password
dn: dc=example,dc=com
changetype: modify
replace: aci
aci: (targetattr = "*") (version 3.0;acl "Custom LDAP Administrator";allow (all)(userdn = "ldap:///uid=admin,dc=example,dc=com");)

OUDでは、同等の動作を実行する次の権限を追加する必要があります。

dn: uid=admin,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: password-reset

次のコマンドを使用して、権限サブシステムを無効にすることもできます。

dsconfig set-global-configuration-prop  -add disabled-privilege:password-reset

4.6.4 レプリケーション・トポロジ内のACIの管理

(O)DSEEとOUDをレプリケーション・トポロジで共存させる必要がない場合、前に説明したように、ACIをOUDにインポートする前に必要に応じてACIを手動で調整できます。

一方向のレプリケーションを使用する場合、(O)DSEE上のデータに存在するACIを移行の前に手動で調整する必要があります。ACI構文チェックにより、レプリケーション初期化中に無効なACIはインポートされません。(O)DSEE側のACIの更新は、引き続きOUDにレプリケートされる可能性がありますが、OUD側には適用されません。

互換性のないACIを使用している場合、レプリケーション中にACIを除外するようにレプリケーション・ゲートウェイを構成することもできます。各(O)DSEE ACIが除外され、管理者はデータの一部として、または構成内に、OUDの対応するACIを作成する必要があります。

(O)DSEEとOUDの間の双方向のレプリケーションの場合、一方向のレプリケーションと同じ推奨事項が適用されます。また、OUD固有のACI拡張を混合環境で使用しないでください。

注意:

(O)DSEEとOUD ACIは互換性がありますが、roleDNとして(O)DSEE固有のキーワードが使用される場合を除きます。

4.6.5 サービス・クラス(CoS)の管理

サービス・クラス定義は、ユーザー・データとともにLDAPサブエントリとして格納されます。

現在、サービス・クラス機能はOUDではサポートされていません。(O)DSEEとOUDの間にレプリケーションが構成されている場合、CoS定義はレプリケーション・ゲートウェイによって自動的に除外されます。

CoSは、標準の集合属性メカニズムまたは仮想属性に置換できます。レプリケートされるトポロジでは、計算された属性は(O)DSEE側のCoSによって生成されますが、同等の計算はOUD側の集合属性または仮想属性を使用して実行されます。

4.6.5.1 集合属性と仮想属性

集合属性定義はユーザー・データとともにLDAPサブエントリとして格納されます。つまり、レプリケートされます。集合属性は、汎用的なサブエントリ・サブツリー仕様を通じてファイングレイン・スコーピング制御を提供します。仮想属性はOUD構成に格納され、レプリケーションには依存しません。(O)DSEEとOUDの間で双方向レプリケーションが有効になっている場合、集合属性ではなく仮想属性を使用する必要があります。これは、集合属性は(O)DSEEに再びレプリケートされるためです。

明確に集合属性を使用する必要がある場合(第4.6.5.4項「クラシックCoS」および第4.6.5.3項「間接CoS」を参照)、集合属性に関連するスキーマ・オブジェクトを使用して(O)DSEEスキーマを拡張する必要があります。この場合、LDAPサブエントリは(O)DSEEに存在しますが、非アクティブになります。つまり、属性計算は行われません。(OUDスキーマ・ファイル00-core.ldifに存在する)collectiveAttributeSubentryおよびsubentryオブジェクト・クラスに関連付けられたスキーマ定義、および関連付けられた属性を(O)DSEEスキーマに追加できます。

注意:

(O)DSEEでは、CoSは通常、ロールおよびパスワード・ポリシーとともに使用されます。たとえば、カスタム・パスワード・ポリシーをユーザーのセットに割り当てるために使用できます。OUDは、パスワード・ポリシーをユーザー・アカウントに割り当てるための新しい方法を提供します。したがって、ほとんどの場合、CoSには単純な代替方法があります。

(O)DSEEサービス・クラス・タイプは、次の項で詳しく説明しています。

4.6.5.2 ポインタCoS

(O)DSEEポインタCoSを使用すると、エントリのセットで共通の属性を共有できます。

次の(O)DSEEポインタCoSは、固定値(+61245607890)を持つfacsimiletelephonenumberを、ou=People,dc=example,dc=comの下にあるすべてのエントリに自動的に割り当てます。

dn: cn=ZipTemplate,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
facsimiletelephonenumber: +61245607890
cosPriority: 0

dn: cn=pointerCoS,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com
cosAttribute: facsimiletelephonenumber

次のOUD仮想属性を使用すると、同等の属性値を計算できます。この例では、objectclass=personフィルタに一致するユーザー・エントリに、仮想のFAX番号+61245607890を追加する仮想属性ルールを作成して有効にします(ユーザー・エントリにすでにFAX番号がある場合を除く)。

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j <password_file> -n \
create-virtual-attribute \
--type user-defined -name "Sydney Fax Number" \
--set attribute-type:facsimiletelephonenumber -set enabled:true \
--set value:+61245607890 -set filter:"(objectClass=person)"

仮想属性と異なり、集合属性はユーザー・データとともに格納されるため、OUDインスタンス間でレプリケートされます。

次の集合属性は、サブツリーou=people,dc=example,dc=comにエントリのfacsimiletelephonenumberを生成します。

dn: cn=People Preferred Language,dc=example,dc=com
changetype: add
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People fac simile number
facsimiletelephonenumber;collective: +61245607890
subtreeSpecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real

4.6.5.3 間接CoS

(O)DSEE間接CoSでは、各ターゲットに固有のテンプレートを見つけるために、cosIndirectSpecifier属性内の属性に名前が付けられます。間接CoSのテンプレート・エントリは、他のユーザー・エントリを含むディレクトリ内の任意のエントリにできます。次の間接CoSの例では、ターゲット・エントリのmanager属性を使用して、CoSテンプレート・エントリを識別します。テンプレート・エントリはマネージャのユーザー・エントリです。マネージャのユーザー・エントリには、生成する属性の値が含まれます。この場合、値はdepartmentNumber属性の値になります。

dn: cn=generateDeptNum,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber

dn: cn=Carla Fuentes,ou=People,dc=example,dc=com
objectclass: cosTemplate
objectclass: person
departmentNumber: 318842
cn: Carla Fuentes

継承集合属性を使用して、間接CoSを置換できます。通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。継承集合属性は、OUDインスタンス間でレプリケートされます。(O)DSEEとOUDの間で双方向のレプリケーションが使用される場合、第4.6.5.1項「集合属性と仮想属性」で説明したように、集合属性スキーマ要素を使用して(O)DSEEスキーマを拡張する必要があります。次の継承集合属性は、前述の間接CoS定義と同等です。

dn: cn=indirectCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromDNCollectiveAttributeSubentry
cn: indirectCOS
subtreeSpecification: {base "ou=people"}
inheritFromDNAttribute: manager
inheritAttribute: departmentNumber

4.6.5.4 クラシックCoS

この例では、クラシックCoS定義による住所値の生成方法を示します。生成される値は、CoS定義のcosTemplateDNおよびターゲット・エントリのcosSpecifier属性の値の組合せで検索されるテンプレート・エントリに指定されます。次の例では、cosClassicDefinitionオブジェクト・クラスを使用して定義エントリを作成します。

dn: cn=classicCoS,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: ou=templates,ou=People,dc=example,dc=com
cosSpecifier: building
cosAttribute: postalAddress

dn: cn=B07,ou=templates, ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalAddres: 7 Old Oak Street, Anytown, CA 95054

このCoS定義では、building属性を含むターゲット・エントリ(ou=People,dc=example,dc=comの下のエントリ)には、自動的に対応する住所が含まれます。CoSメカニズムは、RDNに指示子属性値を持つテンプレート・エントリを検索します。この例では、Babs JensenがビルB07に割り当てられると、Jensenの住所が生成されます。

OUDでは、次のように、継承集合属性を使用して同等の動作を実行できます。

dn: cn=classicCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromRDNCollectiveAttributeSubentry
cn: classicCOS
subtreeSpecification: {base "ou=people"}
inheritFromBaseRDN: ou=templates
inheritFromRDNAttribute: building
inheritFromRDNType: cn
inheritAttribute: postalAddress

この継承集合属性サブエントリは、ou=people,dc=example,dc=comの下のユーザー・エントリに適用されます。サブエントリは、DNがou=templatesから構築されたユーザー・エントリから継承されたpostalAddress属性、継承集合属性サブエントリ・ルートDN dc=example,dc=com、および適用可能なエントリ構築属性(ある場合)から取得されたRDN cn値を追加します。

通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。これらはOUDインスタンス間でレプリケートされます。(O)DSEEとOUDの間で双方向のレプリケーションが使用される場合、第4.6.5.1項「集合属性と仮想属性」で説明したように、集合属性スキーマ要素を使用して(O)DSEEスキーマを拡張する必要があります。

4.6.6 OUDへのロールの移行

現在、非標準の(O)DSEEロールはOUD 11g リリース2 (11.1.2)ではサポートされていません。通常は、標準のOUDグループに置換されます。ロール定義は、レプリケーション・ゲートウェイによって除外されます。

(O)DSEEロールをOUDに移行するために必要な手順は、ロールを外部クライアント・アプリケーションに公開する方法によって異なります。多くのデプロイメントでは、ロールはクライアント・アプリケーションに公開されません。つまり、アプリケーションはnsRoleおよびnsRoleDN属性を利用しません。このようなロールは、ACIおよびパスワード・ポリシーの静的または動的グループに置換できます。

4.6.6.1 ロールとACI

roledn ACIキーワードを使用すると、ユーザー・ロールに基づいてデータにアクセス権を付与/拒否できます。たとえば、次の(O)DSEE ACIは「パスワード・マネージャ」ロールを持つユーザーにユーザー・パスワード属性へのアクセス権を付与します。

dn: ou=data,o=example.com
aci: (targetattr="userPassword")(version 3.0; acl "PasswordManager";allow (read,search,compare,write) roledn = "ldap:///cn=Password_Manager_Role,ou=roles,dc=example,dc=com";

rolednキーワードはOUD 11g リリース2 (11.1.2)ではサポートされていません。これは次のような意味合いを持ちます:

- rolednキーワードを含むACIをOUD 11g リリース2 (11.2.2)にインポートすることはできません。

- (O)DSEEデータに存在するACIはOUDに適用されません。これらのACIはOUDにレプリケートされますが、ACI構文はOUDに対して無効なため、変更は適用されません。

ACIで使用されるロールは、移行の前にgroupdnキーワードを使用してグループに置換する必要があります。OUDの場合、前述のACIを次のように書き換えられます。

dn: ou=data,o=example.com
aci: (targetattr="userPassword")(version 3.0; acl "PasswordManager";allow (read,search,compare,write) groupdn = "ldap:///cn=Password_Manager_Group,ou=group,dc=example,dc=com";

ACIが指すグループは、静的グループまたは動的グループのいずれかになります。

OUDに移行する前にロールベースのACIをグループベースのACIに移行するには、次の処理を実行する必要があります。

- (同じDNを使用して)ロールに対応するグループを定義します。

- OUDに移行する前に(O)DSEE側のACIを書き換えます。

注意:

(O)DSEE構成に存在するロールベースのACIはレプリケートされないため、書き換える必要はありません。

4.6.6.1.1 ロールとパスワード・ポリシー

多くのデプロイメントでは、ロールを使用して、ロール・メンバーシップに基づいてカスタム・パスワード・ポリシーを割り当てます。たとえば、管理者ロールを持つユーザーは管理者パスワード・ポリシーの影響を受けます。このユース・ケースでは、ロールとCoSを使用して、使用するパスワード・ポリシーを指すすべてのユーザー・エントリに仮想属性pwdPolicySubEntryを作成します。

OUDでは、仮想属性を使用することで、パスワード・ポリシーをグループのメンバーと直接関連付けることができます。次の例では、adminPasswordPolicyパスワード・ポリシーをadministratorグループのメンバーに関連付けます。

dsconfig create-virtual-attribute -name "PWPolicy for Admins"
--type user-defined
--set attribute-type:ds-pwp-password-policy-dn
--set group-dn:cn=administrators,ou=groups,dc=example,dc=com
--set conflict-behavior:real-overrides-virtual
--set value:"cn=adminPasswordPolicy,ou=policies,ddc=example,dc=com"

注意:

CoSと異なり、パスワード・ポリシーをロールに関連付ける前述の仮想属性は、OUDインスタンスにはレプリケートされません。

4.6.6.1.2 クライアント・アプリケーションに公開されるロール

直接移行ストラテジまたはDIPストラテジを使用した移行を使用している場合(次の例はレプリケーション・ゲートウェイ・ストラテジを使用した移行とは互換性がありません)、ターゲット・ユーザーのエントリでnsRole属性を使用して、ユーザーがアプリケーション内の特定のロールのメンバーであるかどうかを判断する必要がある場合に適切なロールのDNが存在するかどうかを判断します。この場合、次の手順に従って、ロール機能をシミュレートできます。

- OUDスキーマをnsRole属性定義で拡張します(このスキーマはファイル03-dsee-roles.ldifで提供されます)。

- 静的グループまたは動的グループを作成して、ロール・メンバーシップを定義します。nsRole属性の内容に影響しないように、グループを作成するときにロールDNを再利用する必要があります。

- 次のように、isMemberOf仮想属性の新規インスタンスを作成して、nsRole仮想属性を指定します。

dsconfig -h localhost -p 4444 -D "cn=directory manager" -j <password_file> -n \
create-virtual-attribute -type is-member-of -name nsRole -set \
attribute-type:nsRole -set enabled:true

注意:

仮想属性定義はOUD構成に格納されるため、レプリケートされません。すべてのOUDインスタンスで構成する必要があります。

ユーザーのエントリのnsRoleDN仮想属性に、対応するロールの名前を配置することによってアプリケーションがメンバーシップを変更する場合、各ロールの動的グループを作成(ロールDNを再利用する必要があります)し、グループ・メンバーシップのnsRoleDNが考慮されるようにグループのmemberURLフィルタを拡張します。次の例では、値が"cn=Test Role,ou=Roles,dc=example,dc=com"のnsRoleDNを含むユーザー・エントリのnsRole操作属性にもそのDNがあります。

dn: cn=Test Role,ou=Roles,dc=example,dc=com
objectClass: top
objectClass: groupOfURLs
cn: Test Role
memberURL: ldap:///dc=example,dc=com??sub?(nsRoleDN=\
cn=Test Role,ou=Roles,dc=example,dc=com)

使用しているアプリケーションでロール・エントリを作成、変更または削除することが必要な場合(たとえば、nsRoleDefinitionオブジェクト・クラスのいずれかの下位クラスが含まれるエントリ)、この機能は現在OUDでは使用できません。

4.6.6.1.3ロールのセキュアな移行

OUDでは、ロールはグループに置換されます。対応するグループをセキュアに使用するために、アクセス制御命令(ACI)を設定して、該当する属性を保護する必要があります。動的グループでは、属性変更によりユーザーがフィルタ処理されたグループを放棄できないよう、フィルタを一部保護する必要があります。フィルタ処理されたグループで使用する属性をユーザーが追加、削除および変更できないようにする必要があります。フィルタ属性値の計算の場合も同様に、フィルタ属性値の変更が可能な属性はすべて保護する必要があります。

4.6.7 OUDへのパスワード・ポリシー移行の管理

OUDに付属するds2oudツールは、デフォルトのパスワード・ポリシーの標準属性のみを移行します。(O)DSEEからOUDへのパスワード・ポリシー・マッピングについては、表4-1「(O)DSEEおよびOUDのパスワード拡張」を参照してください。

カスタム・パスワード・ポリシーはデータまたはOUD構成に格納できます。また、ユーザー・エントリ内の属性を使用して、またはDIT内のサブエントリの位置に基づいて、ターゲット・ユーザーに割り当てることができます。パスワード・ポリシーの移行が成功するためには、最適なオプションを選択することが重要です。使いやすさとOUD管理に対する影響を考慮する必要があります(たとえば、サブエントリとしてのパスワード・ポリシーはOUDインスタンス全体にレプリケートされますが、構成内のパスワード・ポリシーはレプリケートされません)。また、すべての組合せがOUD 11g リリース 2 (11.1.2)で使用可能なわけではありません。

デプロイメントの制約に基づいて次のオプションを選択する必要があります。

- カスタム・パスワード・ポリシーをサブエントリとして、またはOUD構成内に格納します

- パスワード・ポリシーを割り当てるには、ユーザー・エントリ内の属性を使用するか、またはサブ・エントリのサブツリー仕様を使用します

- ユーザー・エントリ内の属性を使用してパスワード・ポリシーを割り当てる場合は、明示的な設定、仮想属性または集合属性を使用して属性を移入します

- レプリケーション中に(O)DSEEパスワード・ポリシーを再利用または除外します

考慮する必要がある主な決定基準は次のとおりです。

- (O)DSEEカスタム・パスワード・ポリシーが特定の拡張機能に依存しているかどうか

- レプリケーションが(O)DSEE一方向とのみ使用されるかどうか

- (O)DSEEカスタム・パスワード・ポリシーのサブエントリ位置がOUDと互換性があるかどうか

- パスワード・ポリシー割当てがグループ・メンバーシップに基づいているかどうか

OUDと(O)DSEEのパスワード・ポリシーの違いをまとめたものを次に示します。

- (O)DSEEパスワード・ポリシー定義は(pwdPolicyオブジェクト・クラスで定義される)標準属性と(sunPwdPolicyオブジェクト・クラスで定義される)特定の拡張機能で構成されます。

- OUDパスワード・ポリシーも(pwdPolicyオブジェクト・クラスで定義される)標準属性に依存します。ただし、現在、(O)DSEE固有の拡張機能はOUD 11g リリース2ではサポートされていません。このような拡張機能はレプリケーション中に自動的に除外されるため、ds-cfg-password-policyオブジェクト・クラスで定義されるOUD固有の拡張機能に置換する必要があります。

これらの拡張機能を移行するために必要な手動の調整を次の表に示します。

表4-1 (O)DSEEおよびOUDのパスワード拡張機能

(O)DSEEの拡張機能

OUDの拡張機能

PasswordStorageScheme

default-password-storage-scheme

PwdKeepLastAuthTime

last-login-time-attribute、last-login-time-format

PasswordRootDnMayByPassModsChecks

skip-validation-for-administrators

pwdIsLockoutPrioritized

N/A

PwdCheckQuality

password-validator

グローバル・パスワード・ポリシー以外に、カスタム・パスワード・ポリシーを作成できます。(O)DSEEでは、カスタム・パスワード・ポリシーはデータの一部またはLDAPサブエントリの一部として格納されます。

OUDでは、カスタム・パスワード・ポリシーはデータの一部またはLDAPサブエントリの一部として格納されるか、OUD構成に直接格納されます。

OUDでは、LDAPサブエントリとして定義されたパスワード・ポリシーは標準属性にのみ依存する必要があり(前項を参照)、拡張機能を含めることはできません。この制限は、OUD構成に格納されたパスワード・ポリシーには適用されません。

4.6.7.1 パスワード・ポリシーの割当て

(O)DSEEでは、パスワード・ポリシーはpwdPolicySubEntry属性の値に基づいてユーザー・アカウントに割り当てられます。属性値は、ユーザー・エントリに物理的に格納することも、エントリで照合された基準に基づいてCoSで動的に作成することもできます。パスワード・ポリシーのLDAPサブエントリの場所は、ポリシーをターゲット・ユーザーに割り当てる目的では使用されません。pwdPolicySubEntry属性がユーザー・エントリに存在しない場合は、デフォルトのパスワード・ポリシーが適用されます。

OUDでは、2つの方法でパスワード・ポリシーをユーザー・アカウントに割り当てることができます。

- (O)DSEEと同じように、明示的に、または仮想属性または集合属性を介して属性ds-pwp-password-policy-dnを設定

- パスワード・ポリシー・エントリとターゲット・ユーザー・エントリの下のすべてのユーザー・エントリが、サブエントリに存在するLDAPフィルタ/サブツリー仕様と一致するように、DITにパスワード・ポリシー・サブエントリを作成。サブエントリ・サブツリー仕様はRFC3672で定義されます。

次の例は、最初のケースに対応しています。パスワード・ポリシーServiceAccountは、グループ・メンバーシップに基づいて属性ds-pwp-password-policy-dnを移入する仮想属性を作成することで、グループgroup_FirstLoginPolicyのメンバーに割り当てられます。

dn: cn=group_FirstLoginPolicy,dc=example,dc=com
objectClass: groupOfURLs
MemberURL: ldap://ou=people,dc=example,dc=com??sub? (pwdReset=TRUE)
cn:group_FirstLoginPolicy

dsconfig create-virtual-attribute --name "PWPolicy to Admins" \
--type user-defined --set attribute-type:ds-pwp-password-policy-dn \
--set group-dn:cn=group_FirstLoginPolicy,dc=example,dc=com \
--set conflict-behavior:real-overrides-virtual \
--set value:"cn=ServiceAccount,ou=passwordPolicies,ou=config,dc=example,dc=com"

次の例は、2番目のケースに対応しています。ポリシーFirstLoginPolicyは、サブツリーou=people,dc=example,dc=com内のグループnewbeesのメンバーであるユーザーに適用されます。

dn: cn=FirstLoginPolicy,dc=example,dc=com
objectClass: subentry
Objectclass: pwdpolicy
SubtreeSpecification: { specificationFilter "ismemberOf=cn=group_FirstLoginPolicy,dc=example,dc=com"}
PwdMaxFailure: 2
PwdAttribute: userPassword
cn:FirstLoginPolicy

注意:

OUDで実装されるサブツリー仕様は、標準のスーパーセットです。OUDでは、適格なLDAPフィルタをspecificationFilter属性の有効な値とみなします。これは、前述の例に示すように、グループ・メンバーシップに基づいてパスワード・ポリシーを割り当てる際に非常に便利です。

4.6.7.2 パスワード・ポリシーの継承

カスタム・パスワード・ポリシーの評価は、(O)DSEEとOUDで異なります。(O)DSEEでは、カスタム・パスワード・ポリシーがデフォルトのパスワード・ポリシー設定を上書きします。OUDでは、カスタム・パスワード・ポリシーはデフォルトのパスワード・ポリシーから継承されます。カスタム・ポリシー・レベルで定義されていないプロパティは、(属性名が対応していない場合でも)機能レベルのデフォルト・パスワード・ポリシーから取得されます。移行中は、これらの違いを考慮する必要があります。

4.6.7.3 パスワード・ポリシーとレプリケーション・ゲートウェイ

OUDと(O)DSEEがレプリケートされるトポロジに共存している場合、レプリケーション・プロトコルを介してレプリケートされない場合でも、2つの環境の間でパスワード・ポリシーの一貫性をできるかぎり維持する必要があります。たとえば、パスワード・バリデータが異なる場合、パスワードは一方で有効になり、他方で無効とみなされる可能性があるため、矛盾が生じる可能性があります。

特定のエントリのセットのアカウント・ロックアウトが(O)DSEEで有効になっており、OUDで無効になっている(またはその逆)場合、パスワード・リセットは他方のアカウントをロック解除しません。

4.6.7.4 レプリケーション・ゲートウェイと(O)DSEEパスワード・ポリシーのアップグレード

トポロジ全体でグローバル・パスワード・ポリシーとアカウント・ロックアウトが設定された、レプリケートされるトポロジでは、レプリケーション・ゲートウェイと直接通信する(O)DSEEサーバーは、DS6modeのパスワード・ポリシーを使用して実行する必要があり、ユーザー・エントリに前のパスワード・ポリシー・モードに関連するデータを含めることはできません。(これは、グローバル・パスワード・ポリシーが不要で、OUDと(O)DSEEが独自のパスワード・ポリシー管理を行っている場合は必須ではありません。)他の(O)DSEEサーバーは非互換性モードで実行できますが、そのようなデプロイメントは優先されません。

パスワード・ポリシー・モードの変更の詳細は、Oracle Directory Enterprise Edition 11g管理者ガイドを参照してください。

コマンドdsconf get-server-prop pwd-compat-modeを使用すると、現在のパスワード・ポリシー・モードを取得できます。デフォルトでは、ODSEE 11g リリース2はDS5-compatibleモードを使用します。(O)DSEEからデータをエクスポートする前にDS6-modeに切り替える必要があります。DS6-modeに切り替えるには、まず中間のDS6-migrationモードに切り替える必要があります。

DS6-modeに切り替えてユーザー・エントリを再生成するプロセスは、Oracle Directory Server Enterprise Edition管理者ガイドのパスワード・ポリシーの互換性に関する項で説明しています。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

4.6.7.5 アカウント・ロックアウト

(O)DSEEとOUDの両方で、指定した回数のバインド試行が失敗した後に、アカウントを強制的にロックアウトするパスワード・ポリシーを設定できます。アカウントを手動でロックすることもできます。ロックされたアカウントは、アカウントがアクティブ化されるまで、ロックされたままとなります。

(O)DSEEとOUDの間でアカウント状態(ロック済/ロック解除済)を移行するには、特定の設定が必要です。(O)DSEEでは、手動のアカウント・ロックはロールに依存します。ロックされたエントリにはnsRoleDN=cn=nsManagedDisabledRole,dc=com roleが割り当てられます。OUDでは、手動のアカウント・ロックはブール属性ds-pwp-account-disabledに依存します。手動でロックされたアカウントを(O)DSEEからOUDに自動的にインポートするには、次の手順を使用します。

1. OUDで集合属性を作成して、nsroledn:nsRoleDN=cn=nsManagedDisabledRoleをds-pwp-account-disabled: trueにマップします。

ldapmodify -a
dn: cn=ManagedDisabledAttribute,<dc=example>
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: ManagedDisabledAttribute
ds-pwp-account-disabled;collective: true
subtreeSpecification: {specificationFilter
"nsRoleDN=cn=nsManagedDisabledRole,dc=com"}

2. nsroledn操作属性を使用してOUDスキーマを拡張します。

ldapmodify
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.575 NAME 'nsRoleDN' DESC 'Sun ONE defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE directoryOperation X-DS-USE 'internal' X-ORIGIN 'Sun ONE Directory Server' )

ロックされたアカウントの一方向((O)DSEE->OUD)レプリケーションでは、レプリケーション・ゲートウェイ構成を変更する必要があります。デフォルトでは、nsroledn属性はレプリケートされないため、レプリケーション・ゲートウェイによって除外されます。次のコマンドを実行して、このフィルタリング・ルールを削除する必要があります。

dsconfig set-plugin-prop --plugin-name Gateway\ Plugin --remove
dsee-specific-attribute-types:nsroledn

注意:

OUD側のアプリケーションでnsroledn属性を使用しないでください。これは、アカウント状態の情報を伝達するためにのみレプリケートされます。

アカウント・ロックアウトの双方向のレプリケーションには、OUD側の追加設定が必要です。

3. (O)DSEEスキーマを拡張してds-pwp-account-disabled操作属性を追加します。

ldapmodify
dn: cn=schema
changetype: modify
add: attributeTypes
@ attributeTypes: ( 1.3.6.1.4.1.26027.1.1.166 NAME 'ds-pwp-account-disabled'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation
X-ORIGIN 'OpenDS Directory Server' )

4. (O)DSEEでフィルタされたロールを作成して、OUDからアカウント・ロックアウトをマップします。

ldapmodify -a
dn: cn=OUD_DisabledRole,<dc=example>
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: OUD_DisabledRole
nsRoleFilter: (ds-pwp-account-disabled=true)
Description: filtered role to map account lockout from OUD

5. ODSEEのアカウントを無効にするために使用したネストされたロールで、前のフィルタされたロールを統合します。

ldapmodify
dn: cn=nsDisabledRole,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=OUD_DisabledRole,dc=com

注意:

(O)DSEEでアカウントがロックされている場合、状態情報がOUDにレプリケートされるため、OUDでもアカウントがロックされます。ただし、アカウントのロック解除は両側((O)DSEEとOUD)で実行する必要があります。

nsAccountLock属性を使用して(O)DSEEでアカウントを明示的にロックすることもできます。OUDの同等の属性はds-pwp-account-disabledです。一部のクライアント・アプリケーションはnsAccountLock属性に依存する場合があります。この場合、最も簡単にこれに対処するには、次に示すように、nsAccountLockをOUDスキーマのds-pwp-account-disabledの属性別名として宣言します。

attributeTypes: ( 1.3.6.1.4.1.26027.1.1.166
NAME ( 'ds-pwp-account-disabled' 'nsAccountLock' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
USAGE directoryOperation
X-ORIGIN 'OpenDS Directory Server' )

4.6.7.6 カスタム・リソース制限

(O)DSEEでは、次の制限をパスワード・ポリシーと関連付けることができます。

- 検索制限は、検索操作で調べるエントリの最大数を指定する。

- サイズ制限は、検索操作に応答して返されるエントリの最大数を指定する。

- 時間制限は、検索操作に費やせる最大時間を指定する。

- アイドル・タイムアウトは、接続が切断されるまでに、クライアント接続がアイドル状態でいられる最大時間を指定する。

アカウント制限の設定の詳細は、Oracle Fusion Middleware Oracle Directory Server Enterprise Edition管理ガイドの各クライアント・アカウントのリソース制限の設定に関する項を参照してください。ドキュメントは、http://docs.oracle.com/cd/E19656-01/のOracle Directory Server Enterprise Edition 11g リリース1の索引ページにあります。

それ以外に、特定のアカウント/ユーザー・エントリに対してこれらの制限を設定することもできます。一部の(O)DSEEエントリには、nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeoutというリソース制限属性が含まれている可能性があります。

OUDに対応する属性は、ds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limitです。

アカウントベースのリソース制限はds2oudでは考慮されないため、手動で移行する必要があります。

レプリケーション・ゲートウェイを使用する場合、リソース制限に関連する各(O)DSEE属性名が、対応する各OUD属性の別名として制限されるように、OUDスキーマ(02-config.ldif)を変更する必要があります。

(O)DSEEでは、-1を使用してリソース制限を無効にします。OUDでは0を使用します。この違いに対処するには、OUDで仮想属性を作成して、(O)DSEE属性の値が-1に等しくなったときにOUD属性の内容を上書きするという方法があります。4つの属性に対して仮想属性を作成する必要があります。次に説明を示します。

attributeTypes: ( 1.3.6.1.4.1.26027.1.1.166
NAME ( 'ds-pwp-account-disabled' 'nsAccountLock' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
USAGE directoryOperation
X-ORIGIN 'OpenDS Directory Server' )

dsconfig create-virtual-attribute --name "mapping nsTimeLimit " \
--type user-defined --set attribute-type:ds-rlim-time-limit \
--set filter:"(nsTimeLimit=-1)" \
--set conflict-behavior:virtual-overrides-real \
--set value:"0" \
--set enabled:true

dsconfig create-virtual-attribute --name "mapping nsLookthroughLimit " \
--type user-defined --set attribute-type:ds-rlim-lookthrough-limit \
--set filter:"(nsLookthroughLimit=-1)" \
--set conflict-behavior:virtual-overrides-real \
--set value:"0" \
--set enabled:true

dsconfig create-virtual-attribute --name "mapping nsIdleTimeout " \
--type user-defined --set attribute-type:ds-rlim-idle-time-limit \
--set filter:"(nsIdleTimeout=-1)" \
--set conflict-behavior:virtual-overrides-real \
--set value:"0" \
--set enabled:true

パフォーマンスのために、「プレゼンス」の前述の4つの属性に索引を作成することをお薦めします。

注意:

前述の設定では、OUD側でも(O)DSEEリソース制限属性名を常に使用する必要があります。(O)DSEEとOUDが同じレプリケーション・トポロジに共存する場合、OUD属性名の使用は使用できません。

4.7 手順6: レプリケーション・ゲートウェイまたはDIPのデプロイ

第4.6項「手順5: ユーザー・データおよびディレクトリ・メタデータの移行」を実行した後、選択したアプリケーションをOUDサーバーに対して検証できます。参照先は次のとおりです。

- 「レプリケーション・ゲートウェイを使用した共存」を選択した場合は、レプリケーション・ゲートウェイをデプロイする手順について第4.7.1項「レプリケーション・ゲートウェイのデプロイ」を参照してください。

- 「Oracle Directory Integration Platform (DIP)を使用した共存」を選択した場合は、DIPをデプロイする手順について第4.7.2項「DIPのデプロイ」を参照してください。

- 「直接移行ストラテジ」を選択した場合は、「手順7: レプリケートされるトポロジのデプロイ」に進みます。

4.7.1 レプリケーション・ゲートウェイのデプロイ

レプリケーション・ゲートウェイを使用して(O)DSEEとOUDの間でレプリケーションを構成するための追加コンポーネントを次に示します。

Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのレプリケーション・ゲートウェイの設定に関する項の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。

この時点で、レプリケーションのグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象OUDトポロジに接続する予定の場合は、他のOUDサーバーで定義されている同じグローバル管理者の資格証明を使用します。

たとえば、既存のOUDトポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります。

図4-1 移行前の(O)DSEEおよびOUDのレプリケーション・サーバー・トポロジ

移行後のサーバー・レイアウトは次のようになります。

図4-2 移行後の(O)DSEEおよびOUDのレプリケーション・サーバー・トポロジ

4.7.2 DIPのデプロイ

DIPを使用して(O)DSEEとOUDの間をリンクするための追加コンポーネントを次に示します。古いディレクトリ・サーバーをプロビジョニング解除し、DIPが削除された後、DIP関連のメタデータがOUDに格納されなくなるように、次の手順では(O)DSEEサーバーをDIPバックエンド・ディレクトリとして構成します。

1. 同期される(O)DSEEマスター・インスタンスおよびOUDディレクトリ・サーバー・インスタンスを選択します。レプリケーション・サーバーが外部の変更ログ・サービスを提供するため、OUDディレクトリ・サーバーには埋込みのレプリケーション・サーバーが必要です。

2. パスワード記憶スキームを同期します。
パスワード記憶スキームは、(O)DSEEとOUDの間で同一であり、互換性がある必要があります。同期を有効にするようにパスワード記憶スキームを構成するには、『Oracle Unified Directory管理者ガイド』のデフォルト・パスワード・ポリシーに関する項を参照してください。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Unified Directory 11g リリース2 (11.1.2)ライブラリにあります。

3. (O)DSEEにDIPメタデータを保持するディレクトリ・サフィックスを作成します。
DSEE 6.x (以上)で次のコマンドを使用して、DIPメタデータを保持するサフィックスcn=products,cn=oraclecontextを作成します。

dsconf create-suffix -i -c -p $PORT -D "$ADMIN" -w "$PW_FILE" cn=products,cn=oraclecontext

DSEE 5.2のディレクトリ・サフィックスを作成する手順の詳細は、Sun ONE Directory Server管理ガイドを参照してください。このドキュメントは、次のSun Java Enterprise System 2003Q4索引ページにあります。

http://docs.oracle.com/cd/E19199-01/

4. 変更ログを有効化します。
変更を含むディレクトリで変更ログを有効にする必要があります。次のコマンドを使用して、(O)DSEEで変更ログを有効にします。

dsconf set-server-prop -p $PORT -w "$PW_FILE" retro-cl-enabled:on

双方向同期の場合、OUDで外部変更ログを有効にする必要があります。デフォルトでは、OUDインスタンスがレプリケーション・トポロジの一部である場合、外部変更ログは自動的に有効化されます。テスト用に、スタンドアロンOUDディレクトリ・サーバー・インスタンスを設定し、次のコマンドを使用して外部変更ログを有効にします。

dsreplication enable-changelog --no-prompt --baseDN "dc=example,dc=com" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll

5. DIPをインストールして構成します。

1. WeblogicコンテナにDIPをインストールします。
WeblogicコンテナへのDIPのインストールの詳細は、『Oracle Directory Integration Platform管理者ガイド』を参照してください。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

2. 次のコマンドを使用してDIPを構成します。

3. $ORACLE_HOME/bin/dipConfigurator setup -wlshost <hostname> -wlsport <admin_server_domain_Port> -wlsuser weblogic -ldaphost <dsee_host> -ldapport <dsee_port> -ldapuser "dsee_administrator" -metadatasuffix cn=products,cn=oraclecontext -isldapssl false

たとえば、<dsee_administrator>、cn=directoryマネージャには、DIPメタデータ・サフィックス(cn=products,cn=oraclecontext)への読取りおよび書込みアクセス権を付与する必要があります。
デフォルトのパスワード・ポリシーでは、allow-pre-encodedオプションは'true'である必要があります。これにより、<dsee_administrator>は事前にエンコードされたパスワードへの書込みアクセス権を持つことができます。

LDAPユーザーの場合は、次のコマンドによりデフォルトのパスワード・ポリシーが変更されます。

dsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords: true

SSLユーザーは、DIP管理者ガイドを参照して証明書を管理します。

6. 同期プロファイルを作成します。
oud_ldap_administrator (cn=directory managerなど)が、同期されるサフィックスへの読取りおよび書込みアクセス権を持っていることを確認します。また、双方向同期を使用する場合、OUD外部変更ログでの読取りアクセス権が必要です。

プロファイルを同期するには、コマンド行とDIPグラフィカル・ユーザー・インタフェース(EM)の2つの方法があります。コマンド行を使用してプロファイルを同期する例を次に示します。

$ORACLE_HOME/bin/expressSyncSetup -h <dip_hostname> -p <dip_domain_port> -D weblogic -conDirType IPLANET -conDirUrl <OUD_host>:<oud_port> -conDirBindDN <oud_ldap_administrator> -conDirContainer <target_suffix> -backendDirContainer cn=products,cn=oraclecontext  -pf <profile_name>

前述のコマンドは、次の命名規則を使用して1つのインポート・ファイルおよび1つのエクスポート・ファイルを作成します。

- プロファイル名(-pf argument)がprofile1の場合、expresSyncSetupは2つのプロファイル(profile1Exportおよびprofile1Import)を作成します。

EMを使用して同期プロファイルを作成する方法は、『Oracle Directory Integration Platform管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

同期する属性のリストを更新するには、DIPグラフィカル・ユーザー・インタフェースを使用します。この機能は、『Oracle Directory Integration Platform管理者ガイド』で説明されています。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

1-1の正確な属性マッピング(cn<->cnなど)を作成し、属性の別名ごとに1つの余分なマッピング(commonName->commonNameなど)を作成することをお薦めします。

7. ACIを構成します。
DIPが正しく動作するためには、バックエンド・ディレクトリ・サーバーに追加のディレクトリACIを作成する必要があります。

次のコマンドは、同期されるサフィックスのバックエンド・ディレクトリに作成されるACIの例です(dc=example,dc=com)。

ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///dc=example,dc=com")(version 3.0; acl "Entry-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; )
-
add: aci
aci: (targetattr="*")(version 3.0; acl "Attribute-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext";)
EOF

エクスポート・プロファイルのエントリをエクスポート・グループに追加する必要があります。

ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
dn: cn=odipegroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext
changetype: modify
add: uniqueMember
uniqueMember: orclodipagentname=profile1Export,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext
EOF

プロファイル名(例ではprofile1Export)は、新しいメンバーのDNの一部であることに注意してください。

双方向同期を使用する場合、インポート・プロファイルのエントリをインポート・グループに追加する必要があります。

ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF
dn: cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext
changetype: modify
add: uniqueMember
uniqueMember: orclodipagentname=profile1Import,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext
EOF

前述の例では、プロファイル名(例ではprofile1Export)は、新しいメンバーのDNの一部であることに注意してください。

8. ディレクトリ・ブートストラップを管理します。
ブートストラップは、(O)DSEEバックエンド・ディレクトリとOUDの間のデータの初期移行を指します。同期プロセスでは(O)DSEEとOUD間のデータの移行も処理されるため、ディレクトリのブートストラップを実行する必要はありません。ただし、初期のデータ移行を同期プロセスに依存すると、時間がかかる可能性があります。このため、初めてDIPをデプロイする場合には、ディレクトリのブートストラップを実行します。

2つのディレクトリ・トポロジを初期化するには2つの可能性が考えられます。

1. DIPがOUDへのすべての(O)DSEEエントリを作成するように同期を有効にします。

2. (O)DSEEディレクトリの内容をLDIFファイルにエクスポートした後、その内容をOUDにインポートし、(O)DSEE変更ログを使用するようにDIPを構成します。

最初の解決策は単純ですが、この手順を使用する直接移行ストラテジよりも遅くなります。

最初の解決策を使用するには、次のことを実行する必要があります。

1. 同期プロファイルを有効化します

2. 次のコマンドを実行します:

$ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Import

$ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Export

ディレクトリ・ブートストラップは、『Oracle Directory Integration Platform管理者ガイド』で説明されています。ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

LDIFブートストラップを使用するには、次の手順を実行します。

1. 次のコマンドを使用して、レプリケーション・メタデータなしで、バックエンド・サーバーをオフライン・モードに設定して、DSEEからdata.ldifファイルにエントリをエクスポートします。

$ dsconf export --no-repl -h host -p port suffix-DN LDIF-file

2. エクスポートの開始前に適用された最終更新の変更番号を取得します。そのためには、エクスポート手順を開始した後、その時間を書き留めてYYYYMMDDHHMMSSZ形式の一般化された時間に変換します。一般化された時刻形式のタイムスタンプの例として、20130508200557Zは、(UTCタイムゾーンで)2013年5月28日午後8時5分57秒の時刻を指定します。

3. エクスポートが完了した後、(必要に応じて) (O)DSEEサーバーを再起動します。

4. 次の検索コマンドを実行します。

ldapsearch -p <dsee_port> -D <dsee_admin> -w <password> -b "cn=changelog" "changetime>= <timeStamp>" changeNumber

5. 次のコマンドを実行して返される最も小さいchangeNumberの値を書き留めます。

bash-3.2$ ./ldapsearch -p PORT -h DSEE HOSTNAME -D "cn=directory manager" -w PASSWORD -b "cn=changelog" "changetime>=20130508200557Z" changeNumber
dn: changenumber=16747773,cn=changelog
changeNumber: 16747773
dn: changenumber=167477734,cn=changelog
changeNumber: 167477734
dn: changenumber=1674777345,cn=changelog
changeNumber: 1674777345

6. 『Oracle Directory Integration Platform管理者ガイド』のOracle Directory Integration Platformの管理に関する項に説明されているように、DIP管理コンソール(EM)を使用します。
ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

同期を開始するmanageSyncProfiles updatechgnumコマンドを使用して、DIP同期エクスポート・プロファイルの最終変更番号パラメータを前述の値で更新することもできます。manageSyncProfiles updatechgnumコマンドは、『Directory Integration Platform管理者ガイド』のmanageSyncProfiles"の構文に関する項で説明されています。

ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

7. 『Directory Integration Platform管理者ガイド』の同期プロファイルの有効化および無効化に関する項で説明されているGUIまたはCLIを使用して、DIP同期プロファイルを有効にします。
ドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Fusion Middleware 11g リリース1 (11.1.1.7)ライブラリにあります。

変更ログに基づいて同期が開始されます。

4.8 手順7: レプリケートされるトポロジのデプロイ

OUD参照インスタンスを初期化すると、移行作業の大部分が完了します。

第4.5項「手順4: ディレクトリ構成の移行」で説明されているバッチ手順を使用して、追加インスタンスが作成および初期化されます。その後、OUDインスタンス間でレプリケーションが有効になります。

詳細は、『Oracle Unified Directory管理者ガイド』および『Oracle Unified Directoryインストレーション・ガイド』を参照してください。

「手順1: 参照OUDインスタンスの作成」、「手順2: ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの診断」、「手順3: ディレクトリ・スキーマの移行」、「手順4: ディレクトリ構成の移行」で説明されている(O)DSEEからのデータを使用して、参照OUDサーバーを構成およびロードした後、レプリケートされる環境で追加インスタンスを設定できます。この手順は次のとおりです。

1. OUDレプリカの構成

2. トポロジのデプロイ

3. データの初期化

これらの手順はすべてのストラテジに必要です。

レプリカのタイプ

(O)DSEEは、3つのタイプのレプリカを区別することに注意してください。

1. マスター・レプリカは、ディレクトリ・データのマスター・コピーが含まれている読取り-書込みデータベースです。

2. コンシューマ・レプリカは、マスター・レプリカに格納されている情報のコピーを含む読取り専用データベースです。

3. ハブ・レプリカは、コンシューマ・レプリカと同様に読取り専用のデータベースですが、1つ以上のコンシューマ・レプリカを提供するディレクトリ・サーバー上に格納されます。

(O)DSEEレプリカの詳細は、Oracle Directory Server Enterprise Editionリファレンスのレプリカの概要に関する項を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.5)ライブラリにあります。

OUDレプリケーション・モデルはマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバー・レプリカが、読取り操作と書込み操作の両方を処理できます。

DSEE 6.xのリリース以降、コンシューマ・レプリカおよびハブ・レプリカが不要になる一般的なデプロイメントのマルチマスター・レプリケーションを推奨してきました。

ほとんどのデプロイメントでは、パフォーマンス上の理由で読取り専用レプリカを使用する必要はありません。アプリケーションで必要な場合のみ使用します。この場合、バックエンドの書込み可能性モードを構成することで実行します。ただし、OUDディレクトリ・サーバーを読取り専用になるように構成できます。その場合、LDAPクライアントからの追加、変更および削除操作はこのサーバーでは拒否され、レプリケートされるトポロジ内の他の(読取り-書込み)サーバーへのポインタを含むリフェラルが返されます。

OUD読取り-書込みレプリカの構成

- カスケード型レプリケーションと集中化レプリケーション・モデル
(O)DSEEでは、レプリケーション・プロトコルの動作を改善するために、カスケード型レプリケーションとともにハブ・レプリカが導入されます。カスケード型レプリケーションは、次の場合に役立ちます。

- コンシューマの数が多い場合

- レプリケーション・トポロジ内のマスターは更新トラフィックをすべて処理するため、コンシューマへのレプリケーション・トラフィックをサポートすると、マスターに大きな負荷がかかる場合があります。レプリケーション・トラフィックの負荷を複数のハブに分散すると、それぞれのハブから、コンシューマのサブセットに対して、レプリケーションの更新を送信できます。

- 地理的に分散した環境で、ローカル・ハブを使用して接続コストを削減する場合

OUDでは、ハブ・レプリカは存在しません。レプリケーションは、パブリッシュ・サブスクライブ・アーキテクチャを中心に構築されています。各ディレクトリ・サーバーは、中央サービスと通信し、自身の変更のパブリッシュおよび他のディレクトリ・サーバーの変更通知の受信を行うために中央サービスを使用します。この中央サービスは、レプリケーション・サービスと呼ばれます。OUD読取り-書込みマスターはデフォルトであるため、ほとんどの場合デプロイされます。

レプリケーション・サービスは、複数のホストで動作する複数のサーバー・インスタンスを使用することで、高可用性を持たせることができます。レプリケーション・アーキテクチャ内でレプリケーション・サービスを提供するサーバー・インスタンスは、レプリケーション・サーバーと呼ばれます。ディレクトリ・サービスを提供するサーバー・インスタンスは、ディレクトリ・サーバーと呼ばれます。

小規模トポロジ(ディレクトリ・サーバーの数が最大4つ)では、各サーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして構成することが合理的です。大規模トポロジ(ディレクトリ・サーバーの数が20を超えている)では、ディレクトリ・サーバー・インスタンスとレプリケーション・サーバー・インスタンスを別々のJVMに分けて、レプリケーション・サーバーの数を制限することをお薦めします。

この2つの極端なトポロジの中間の規模の場合は、要件にあわせて最適な構成を決定できます。すべてのサーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして動作させるほうが、一般にはトポロジが単純になり、管理しやすくなります。ディレクトリ・サーバーとレプリケーション・サーバーを分ける場合、ディレクトリ・サーバー・インスタンスはレプリケーション変更ログを保存する必要がないので必要なディスク容量が少なくなります。

複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。これは、レプリケーション・サーバーを異なるタイプの異なる能力を持つマシンで実行している場合に、特に重要です。予想されるマシンのパフォーマンスがレプリケーション・サーバー間で大幅に異なる場合は、その能力に従ってレプリケーション・サーバーに負荷を分散させることが有効です。

OUDのレプリケーションの概念を理解する必要があります。これは、(O)DSEEの場合とは異なるためです。レプリケーション・サーバーおよびロード・バランシングの構成の詳細は、『Oracle Unified Directory管理者ガイド』のレプリケーション・サーバーのロード・バランシングに関する項を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Unified Directory 11g リリース2 (11.1.2)ライブラリにあります。

OUD読取り専用レプリカの構成

この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2上のディレクトリ・サーバーを読取り専用にして、管理コネクタを使用してサーバー構成にアクセスするdsconfigコマンドを使用します。

OUD読取り専用レプリカの構成の詳細は、『Oracle Unified Directory管理者ガイド』のサーバーへの管理トラフィックの管理に関する項を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Unified Directory 11g リリース2 (11.1.2)ライブラリにあります。

OUDを読取り専用レプリカとして構成するには、dsconfigコマンドを使用してhost2の書込み可能性モードを設定します。

- $ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j <password_file> -X -n \
set-global-configuration-prop --set writability-mode:internal-only

internal-onlyという書込み可能性モードは、サーバーでレプリケーション操作は処理されるが、LDAPクライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。
サーバーのデプロイ

新しいOUDインスタンスを作成してインスタンス間のレプリケーションを有効にするには、次の手順を実行します。

1. OUDインスタンスを作成します。ディレクトリ・サーバーの設定手順は、『Oracle Unified Directoryインストレーション・ガイド』を参照してください。

2. 第4.5項「手順4: ディレクトリ構成の移行」で説明されている構成の変更を適用して各OUDインスタンスを構成します。データのインポート中に実行された可能性がある追加の構成の変更については、第4.6項「手順5: ユーザー・データおよびディレクトリ・メタデータの移行」を参照してください。

3. dsreplicationコマンドを実行して、OUDインスタンス間のレプリケーションを有効にします。dsreplicationコマンドは、『Oracle Unified Directory管理者ガイド』の2つのサーバー間のレプリケーションの有効化に関する項で説明されています。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Unified Directory 11g リリース2 (11.1.2)にあります。

レプリケートされるトポロジへのサーバーのデプロイについては、『Oracle Unified Directory管理者ガイド』のdsreplicationを使用したデータ・レプリケーションの構成に関する項で説明されています。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Unified Directory 11g リリース2 (11.1.2)にあります。

(O)DSEEデータとともにOUDサーバーがロードされた後、『Oracle Unified Directory管理者ガイド』で説明されているように、他のすべてのOUDインスタンスに同じファイルをインポートするか、バイナリ・コピーを使用するか、別のレプリケート対象サーバーからのデータでレプリケート対象サーバーを初期化できます。

(O)DSEEデータによるOUDの初期化

レプリケーション・トポロジを設定した後、新しいデータで初期化する必要があります。すでに参照インスタンスに含まれている(O)DSEEデータでOUDインスタンスを初期化するには、ストラテジごとに4つのオプションがあります。

レプリケーション・ゲートウェイ・ストラテジを使用している場合は、(O)DSEEで(O)DSEEレプリケーション・パージ遅延が構成される前にエクスポートされた(O)DSEEデータとともにOUD参照インスタンスがロードされることを確認する必要があります。

4つのオプションは次のとおりです。

- dsreplicationコマンドを実行して、空の各OUDインスタンスを初期化します。この手順は、『Oracle Unified Directory管理者ガイド』の第26.1.2項で説明されています。

- 各OUDインスタンスを同時に初期化します。この手順は、『Oracle Unified Directory管理者ガイド』の第26.1.3項で説明されています。

- 参照OUDから各OUDインスタンスに、データベース・ファイルのバイナリ・コピーを実行します。この手順は、『Oracle Unified Directory管理者ガイド』の第26.4.3項で説明されています。

- 参照OUDからエントリをエクスポートし、空の各OUDインスタンスに再インポートします。

4.9 手順8: OUDトポロジへのトラフィックのリダイレクト

2つの環境間の共存は、アプリケーション・テストが完了するまで維持されます。

この手順はアーキテクチャに依存します。リダイレクトには、ソフトウェアまたはハードウェアのロード・バランサ、LDAPプロキシ・サーバーの再構成、ドメイン・ネーム・システム(DNS)の変更、またはIP偽装の使用が含まれる可能性があります。

4.10 手順9: 共存の中止

すべてのアプリケーションをOUDにリダイレクトして検証した後、レプリケーション・ゲートウェイおよびコンパニオン(O)DSEEサーバーをプロビジョニング解除できます。

レプリケーション・ゲートウェイを使用しなくなった場合、停止してアンインストールできます。同じことが(O)DSEE側にも当てはまります。

注意:

第4.10項「手順9: 共存の中止」を実行すると、OUDへの移行は完了です。移行中に問題が発生した場合は、Oracleサポート担当者に問い合せてください。詳細は、https://support.oracle.comのMy Oracle Support Webサイトにアクセスしてください。

5 OUDへの移行後

この章では、OUDへの移行後に役立つ情報について説明しており、項目は次のとおりです。

- 第5.1項「新しいOUD環境」

- 第5.2項「追加のOUD情報」

5.1 新しいOUD環境

OUDは弾力性のあるスケーラビリティ、高可用性、優れたパフォーマンスおよび企業管理の容易性を備えているため、事業の成長に応じて拡大する通信業者レベルのサービスを提供します。OUDへの移行を完了した後、ディレクトリ・サービスを改善および拡張する付加価値機能をデプロイできます。

独特なレプリケーション・ゲートウェイを備えたOUDは、DIPおよびOVDと組み合せることで、業界で最初かつ唯一のJavaベースの統合ディレクトリ・ソリューションとして機能します。企業が現在直面している断片化したソリューションの課題に対応し、総所有コストを大幅に削減します。

最後に、OUDはLDAP標準に従ってOracle Fusion Middlewareプラットフォームと統合されるため、OUDへの移行により、ディレクトリ・サービスを既存のアプリケーションと簡単に連携させることが可能になり、広範囲のFusion Middlewareソリューションでディレクトリ内のデータの価値を最大化します。

5.2 追加のOUD情報

OUDの詳細は、次のリソースを参照してください。

- Oracle Unified Directoryリリース・ノート

- Oracle Unified Directory管理者ガイド

- Oracle Unified Directory開発者ガイド

- Oracle Unified Directoryインストレーション・ガイド

- Oracle Technology Network WebサイトのOracle Directory Servicesページ(http://www.oracle.com/us/products/middleware/identity-management/directory-services/overview/index.html)

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, 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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

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