1. Oracle Directory Integration Platformの管理
  2. サード・パーティ・ディレクトリとの統合
  3. 接続ディレクトリ統合の概念と考慮事項

19 接続ディレクトリ統合の概念と考慮事項

この章では、Oracle Directory Integration Platformと接続ディレクトリとの統合の基本概念と、統合プロセスの一環として行う様々な決定について説明します。

この章のトピックは、次のとおりです:

関連項目:

接続ディレクトリとの同期に関する特定の実装の詳細は、次の各章を参照してください。

19.1 接続ディレクトリ統合の概念とアーキテクチャ

すべてのOracleコンポーネントは、Oracle Identity Managementと統合することによって、セキュリティが集中管理されます。環境内でOracleディレクトリ(Oracle Unified Directory、Oracle Internet DirectoryまたはOracle Directory Server Enterprise Edition)のいずれかとその他のディレクトリ(Microsoft Active Directoryなど)を使用する場合、コネクタを使用して2つのシステムを統合し、それらのデータを同期化できます。コネクタとは、あらかじめパッケージされた接続ソリューションで、これを使用するとOracleディレクトリを接続ディレクトリと同期化できます。

この項では、Oracle Directory Integration Platformと接続ディレクトリの統合に必要なOracleコンポーネントとアーキテクチャについて説明します。次のトピックが含まれます。

ノート:

  • 各Oracleバックエンド・ディレクトリ(Oracle Internet Directory、Oracle Unified DirectoryおよびOracle Directory Server Enterprise Edition)との統合に関して保証されているディレクトリおよびサーバーの詳細は、Oracle Fusion Middlewareのサポートされるシステム構成の動作保証マトリックスを参照してください。

  • プラガブル・データベースも接続ディレクトリとして構成できます。

19.1.1 その他のディレクトリとの統合に関するOracle Identity Managementコンポーネント

Oracle Identity Managementには、別のディレクトリとの統合に使用するOracleバックエンド・ディレクトリ、Oracle Directory Integration Platform、Oracle Directory Services Managerおよび委任認証が含まれています。

トピック:

関連項目:

Oracle Internet Directoryとサード・パーティ・ディレクトリとの統合に使用されるツールの詳細は、「Oracle Directory Integration Platformの管理」を参照してください

19.1.1.1 Oracleバックエンド・ディレクトリの理解

Oracleバックエンド・ディレクトリはOracleコンポーネントとサード・パーティ・アプリケーションがユーザー・アイデンティティおよび資格証明を格納してアクセスするリポジトリです。Oracleディレクトリ・サーバーを使用し、ユーザーが入力した資格証明をOracleバックエンド・ディレクトリに格納されている資格証明で検証してユーザーを認証します。資格証明は、接続ディレクトリからOracleバックエンド・ディレクトリに同期化するか、接続ディレクトリに格納することができます。この場合、Oracleバックエンド・ディレクトリは、接続ディレクトリに認証を委任します。

19.1.1.2 Oracle Directory Integration Platformの理解

Oracle Directory Integration Platformは、Oracle Identity Managementの一部としてインストールされます。これをOracleバックエンド・ディレクトリと同じホストで実行するようにも、異なるホストで実行するようにも構成できます。

Oracle Directory Integration Platformでは、次の処理が可能です。

  • Oracleバックエンド・ディレクトリと他の接続ディレクトリおよびユーザー・リポジトリ間の同期。

  • Oracle Internet DirectoryまたはOracle Unified DirectoryがOracleバックエンド・ディレクトリである場合のOracleコンポーネント用自動プロビジョニング・サービス。

Oracle Directory Integration Platformには、Oracleバックエンド・ディレクトリを他のLDAPディレクトリまたはデータ・ストアと同期化するためのコネクタが含まれています。Oracle Directory Integration Platform統合コネクタを使用すると、次のことができます。

  • 接続ディレクトリとの一方向または双方向いずれかの同期を構成します。

    ノート:

    Oracle Directory Integration Platformでは、Oracleバックエンド・ディレクトリから接続ディレクトリへのパスワード同期がサポートされます。

  • 同期化属性の特定のサブセットの指定これを行うには、適切なマッピング・ルールを構成します(実行時に変更可能)。

関連項目:

属性マッピング・ルールの構成については、「属性レベル・マッピング」を参照してください

19.1.1.3 Oracle Directory Services Managerの概要
19.1.1.4 委任認証の理解

外部認証プラグイン(Microsoft Active Directory外部認証プラグインなど)は、バックエンド・ディレクトリで使用でき、これを使用すると、ユーザーはMicrosoft Windows資格証明を使用してOracle環境にログインできます。

Oracle Unified DirectoryおよびOracle Directory Server Enterprise Editionバックエンド・ディレクトリは、Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionからのユーザーについての認証をMicrosoft Active Directoryなどの接続ディレクトリに渡すため、パススルー認証を使用します。

外部認証プラグインがインストールされていれば、Oracleディレクトリ・サーバーにより起動されます。このプラグインにより、接続ディレクトリでユーザーの資格証明が検証されます。

詳細は、次を参照してください。

19.1.2 接続ディレクトリとの同期用のOracleバックエンド・ディレクトリ・スキーマ要素

Oracleバックエンド・ディレクトリには、接続ディレクトリ(Microsoft Active Directoryなど)に固有の属性に対応するスキーマ要素が含まれています。スキーマ要素は、Oracle Directory Integration Platformにより接続ディレクトリと同期化されるバックエンド・ディレクトリ・オブジェクトを識別します。

次の各項では、これらのスキーマ要素について説明します。

19.1.3 接続ディレクトリとの統合におけるディレクトリ情報ツリー

ディレクトリ情報ツリー(DIT)によって、ディレクトリに格納されたデータを参照する方法が提供されます。ディレクトリ・ツリーの設計は、格納されている情報のタイプ、エンタープライズの物理的性質、ディレクトリを使用するアプリケーション、および使用するレプリケーションのタイプに応じて異なります。

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

関連項目:

19.1.3.1 Oracle Internet Directoryのレルムについて

Oracle Internet Directoryでは、アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイにより定義され、施行される企業内での範囲を定義します。

アイデンティティ管理レルムは、次のもので構成されます。

  • 有効範囲の定義されたエンタープライズ・アイデンティティの集合(USドメインのすべての従業員など)。

  • これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。

  • グループの集合。すなわち、アイデンティティ管理ポリシーの設定を簡単にするアイデンティティの集合です。

複数のレルム

同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。したがって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー(パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど)を施行できます。これは、Oracle Fusion Middlewareのホスティングされたデプロイで役立ちます。

各アイデンティティ管理レルムには、他のレルムと区別するために固有の名前が付けられます。また、レルムに対して完全な管理制御を行うために、レルム固有の管理者も決められます。

デフォルトのレルム

機能するすべてのOracleコンポーネントに対して、アイデンティティ管理レルムが必要です。Oracleディレクトリのインストール中に作成される特別なレルムは、デフォルトのアイデンティティ管理レルムと呼ばれます。レルムの名前が指定されていない場合に、Oracleコンポーネントがユーザー、グループおよび関連付けられたポリシーを検索する場所です。このデフォルト・レルムを使用すると、情報の適切な編成が容易になり、ディレクトリで適切なアクセス制御が施行されます。

デフォルトのアイデンティティ管理レルムは、ディレクトリに1つのみです。デプロイメントに、複数のアイデンティティ管理レルムが必要である場合、その1つをデフォルトとして選択する必要があります。

図19-1に、デフォルト・アイデンティティ管理レルムを示します。

図19-1 デフォルト・アイデンティティ管理レルム

この図については本文で説明しています。

図19-1に示されているとおり、デフォルトのアイデンティティ管理レルムはグローバルDITの一部です。ルートDSEに続くノードはdc=comで、さらにdc=MyCompany、dc=usと続きます。これらの4つのノードは、全体的なDIT構造を表します。ノードdc=usは、デフォルト・アイデンティティ管理レルムのルートです。ユーザーおよびグループの情報を含む2つのサブツリー(cn=Usersおよびcn=Groups)があります。例として、cn=Usersノードには2つのリーフ(uid=user1およびuid=user2)が含まれています。同様に、cn=Groupsノードにはcn=group1およびcn=group2が含まれています。

レルムにおけるアクセス制御ポリシー

Oracle Directory Integration Platformで次のことを可能にするには、Oracle Internet Directoryで適切なACLを構成する必要があります。

  • インポート・プロファイルによりusersコンテナとgroupsコンテナでオブジェクトの追加、変更および削除ができるようにします。デフォルトでは、インポート・プロファイルはレルム管理グループの一部で、レルム識別名の下の任意のエントリに対してあらゆる操作を実行できます。レルム内でACLをカスタマイズした場合、同期化されるサブツリーで、あるいは同期が行われる場所に応じてuserコンテナまたはgroupコンテナ(あるいはその両方)で、インポート・プロファイルにこれらの操作を実行するための適切な権限があることを確認します。

  • Oracleコンポーネントでレルム内のユーザーとグループを管理できるようにします。デフォルトでは、Oracleコンポーネントでusersコンテナとgroupsコンテナのそれぞれのユーザーとグループを管理できます。レルム内でusersearchbaseとgroupsearchbaseを更新した場合、usersコンテナとgroupsコンテナで適切なACLを設定します。

関連項目:

Oracle Internet Directoryによりインストールされたデフォルト・レルムの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のOracle Identity Managementレルムのデプロイに関する章を参照してください。

19.1.3.2 Oracle Unified DirectoryおよびOracle Directory Server Enterprise Editionの接尾辞について

存在しない場合、Oracle Unified DirectoryおよびOracle Directory Server Enterprise Editionに必須の接尾辞を作成する必要があります。

Oracle Directory Server Enterprise Editionでは、「Oracle Directory Server Enterprise Edition接尾辞の作成」の説明に従って、手動で接尾辞を作成する必要があります。

Oracle Unified Directoryでは、インストール中に接尾辞が作成されていない場合、「Oracle Unified Directory接尾辞の作成」の説明に従って、接尾辞を作成する必要があります。

次の説明に従って、必要なアクセス制御命令(ACI)を必ず追加してください。

19.1.3.3 デプロイメントの計画方法の理解

デプロイを計画する際、同期の前に行う最も重要な決定は、次のとおりです。

  • 中央ディレクトリとなるディレクトリ

  • 同期化するオブジェクト。たとえば、次のようなものです。

    • DITで同期化する必要のある部分。DIT全体またはその一部のみを同期化できます。

    • エントリごとの、同期化の必要な特定のコンテンツ。エントリのコンテンツ全体またはその一部のみを同期化できます。

  • 同期化する位置。次の2つのオプションがあります。

    • DITの各エントリの相対的な位置が、ソース・ディレクトリと宛先ディレクトリの両方で同じになるように同期化できます。この構成は、1対1識別名マッピングと呼ばれ、最も一般的に使用されている構成です。ソース識別名が宛先識別名と同じであるため、この構成では2つの識別名が異なる場合よりパフォーマンスが向上します。

    • DITの各エントリの相対的な位置が、ソース・ディレクトリと宛先ディレクトリで異なるように同期化できます。この構成では、Oracle Directory Integration Platformにより、マップされるすべてのエントリ(グループ・エントリ内の参照を含む)の識別名値を変更する必要があります。これにはより集中的な計算が必要です。

      このように同期化する場合、「サポートされている属性マッピング・ルールと例」で説明されているように、dnconvertマッピング・ルールを使用する必要があります。

関連項目:

ディレクトリ情報ツリーの計画の詳細は、「ディレクトリ情報ツリーの構造の選択について」を参照してください

19.1.3.4 例: 単一の接続ディレクトリ・ドメインとの統合

図19-2に、Oracle Internet Directory (Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionも使用可能)と接続ディレクトリ間の1対1マッピングの例を示します。

図19-2 Oracle Internet Directoryと接続ディレクトリのホストがドメインus.MyCompany.com下に存在する場合の両ディレクトリにおけるデフォルトのDIT構造

図19-2の説明が続きます
「図19-2 Oracle Internet Directoryと接続ディレクトリのホストがドメインus.MyCompany.com下に存在する場合の両ディレクトリにおけるデフォルトのDIT構造」の説明

図19-2の1対1マッピングの場合:

  • Oracle Internet Directoryおよび接続ディレクトリの両方のホストが同じトポロジを持ちます。

  • ユーザーは、接続ディレクトリからOracle Internet Directoryにのみ同期化されます。同期化されるすべてのユーザーが、接続ディレクトリ内の1つのコンテナ(この場合、users.us.MyCompany.com)に格納されます。

  • 同じDIT構造が接続ディレクトリとOracle Internet Directoryの両方で保持されます。すべてのユーザーが、値cn=users,dc=us,dc=MyCompany,dc=comで識別される同じusersサブツリーに表示されます。

図19-2の例では、1対1のドメイン・マッピングを使用して接続ディレクトリからOracle Internet Directoryに同期化する必要があるのは、usersサブツリーのみです。

ノート:

図19-2では、2つのディレクトリのトポロジは同じですが、これは単なる例であることに注意してください。2つのディレクトリは、同じドメインに存在する必要はありません。Oracle Internet Directoryは、接続ディレクトリに接続できる場所である場合、ネットワーク内のどこにでも配置できます。

さらに、例では同期が接続ディレクトリからOracle Internet Directoryへの一方向ですが、かわりに同期を双方向に行うこともできます。

19.2 統合環境の計画

この項では、Oracle Directory Integration Platformと接続ディレクトリの統合環境を計画する方法について説明します。

トピック:

19.2.1 接続ディレクトリとの統合に関する予備的な考慮事項

LDAPディレクトリ・サーバーをすでに所有している企業にOracleバックエンド・ディレクトリをデプロイする場合は、両方のディレクトリが同じ環境に共存するように構成する必要があります。

ディレクトリの共存には、次のいずれかのデプロイが必要です。

  • Oracleバックエンド・ディレクトリとの単純な同期。使用する環境において、データベース・サーバーを使用してエンタープライズ・ユーザーがサポートされている場合は、この方法を使用します。Oracle Internet DirectoryまたはOracle Unified DirectoryがOracleバックエンド・ディレクトリの場合、このアプローチによってエンタープライズ・ユーザー・セキュリティがサポートされます。

    ノート:

    エンタープライズ・ユーザー・セキュリティをサポートするには、Oracleバックエンド・ディレクトリは、Oracle Internet DirectoryまたはOracle Unified Directoryである必要があります。Oracle Directory Server Enterprise Editionバックエンド・ディレクトリでは、エンタープライズ・ユーザー・セキュリティを含む、その他のFusion Middlewareコンポーネントとの統合をサポートしていません。

  • Oracle Fusion Middlewareインフラストラクチャとの完全な統合。これにより、エンタープライズ・ユーザー全員が、Oracle Fusion Middlewareスイートの各種コンポーネントを使用できるようになります。環境内でエンタープライズ・ディレクトリとして接続ディレクトリが使用され、Oracle Fusion Middlewareスイートのアプリケーションがデプロイされている場合は、この方法を使用します。

    すべてのOracle Fusion Middlewareコンポーネントがアイデンティティ管理レルムに依存するため、Oracle Fusion Middlewareインフラストラクチャとの完全な統合には、そのレルムのコンテナについていくつか決定を行う必要があります。これらの事項を決定した後、ディレクトリ間でブートストラップおよび同期を構成できます。

19.2.2 セントラル・エンタープライズ・ディレクトリとなるディレクトリの選択

この項では、セントラル・エンタープライズ・ディレクトリまたはメタディレクトリとなるディレクトリの選択方法について説明します。

トピック:

19.2.2.1 シナリオ1の概要: Oracleディレクトリがセントラル・エンタープライズ・ディレクトリである場合

Oracle Unified Directory、Oracle Internet Directory、Oracle Directory Server Enterprise EditionなどのOracleディレクトリが中央ディレクトリである場合、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトが作成されると、OracleディレクトリはすべてのOracleコンポーネントおよび接続ディレクトリに関する情報のソースになります。その後、企業全体のユーザー・オブジェクトとグループ・オブジェクトが、各種Oracleコンポーネントにプロビジョニングされ、Oracleディレクトリから接続ディレクトリに同期されます。

表19-1に、このデプロイの一般的な要件を示します。

表19-1 Oracleディレクトリをセントラル・エンタープライズ・ディレクトリとして使用する場合の一般的な要件

要件 説明

初期起動

syncProfileBootstrapコマンドにより、Oracleディレクトリに格納されているユーザーおよびグループが接続ディレクトリに移入されます。

同期

ユーザーおよびグループ情報は、Oracleディレクトリで管理されます。その情報への変更は、エクスポート・プロファイルが構成されたときに、Oracle Directory Integration Platformにより接続ディレクトリと同期化されます。

接続ディレクトリからOracleディレクトリへの同期は、インポート・プロファイルを構成することによって実行できます。

パスワード同期

パスワードは、Oracleツールを使用してOracleディレクトリで管理されます。パスワードの変更は、Oracle Directory Integration Platformによって接続ディレクトリと同期化されます。ただし、このサーバーでパスワードの変更を同期化する前に、「パスワード同期」の説明に従ってパスワード同期を構成する必要があります。

パスワード同期にはSSL通信を使用することをお薦めします。

Oracleディレクトリの新しいユーザーまたはグループは、Oracle Directory Integration Platformによって自動的に同期化できます。この自動同期では、Oracleディレクトリ・サーバーが変更ログを有効化した状態で実行され、変更ログがパージされていない必要があります。

これらの2つの条件が満たされない場合、OracleディレクトリのエントリをLDIFファイルにダンプして、接続ディレクトリにデータをアップロードする必要があります。

関連項目:

図19-3に、Oracleディレクトリがセントラル・エンタープライズ・ディレクトリとなっている場合の通常のデプロイを示します。

図19-3 Oracleディレクトリをセントラル・エンタープライズ・ディレクトリとして使用するコンポーネント間の相互作用

図19-3の説明が続きます
「図19-3 Oracleディレクトリをセントラル・エンタープライズ・ディレクトリとして使用するコンポーネント間の相互作用」の説明

図19-3に示されているとおり、Oracleディレクトリがセントラル・エンタープライズ・ディレクトリとなっている場合、ユーザーまたはグループの通常の同期は、次のプロセスに従います。

  1. ユーザー・エントリまたはグループ・エントリは、グラフィカル・ツールまたはコマンド行ツールを使用してOracleディレクトリに作成されます。詳細は、「Oracle Directory Integration Platformの管理」を参照してください。

  2. 次にスケジュールされた間隔に、エントリ作成イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。

  3. 統合プロファイル内のマッピング情報に従って、Oracle Internet Directory内のユーザー属性またはグループ属性が、接続ディレクトリのスキーマで必要とされるとおりに、対応するユーザー属性またはグループ属性に適切にマップされます。

  4. ユーザー・エントリおよびグループ・エントリが接続ディレクトリ内に作成されます。

Oracleディレクトリでユーザー・エントリが変更されるのは、新しい属性がエントリに追加された場合、既存の属性の値が変更された場合、または既存の属性が削除された場合です。

Oracleディレクトリがセントラル・エンタープライズ・ディレクトリの場合、ユーザー・エントリまたはグループ・エントリの変更時に実行されるイベントの順序は次のとおりです。

  1. エントリが、Oracle Directory Services Manager (Oracle Unified DirectoryおよびOracle Internet Directoryの場合)、Directory Service Control Center (Oracle Directory Server Enterprise Editionの場合)またはOracle Enterprise Manager Fusion Middleware Controlを使用して変更されます。

  2. 次にスケジュールされた間隔に、エントリ変更イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。

  3. 統合プロファイル内のマッピング情報に従って、Oracleディレクトリ内の属性が、接続ディレクトリ内の対応する属性に適切にマップされます。

  4. 接続ディレクトリ内でユーザー・エントリが変更されます。

19.2.2.2 シナリオ2の概要: Oracleディレクトリ以外のディレクトリがセントラル・エンタープライズ・ディレクトリである場合

このシナリオでは、接続ディレクトリ(サード・パーティ・ディレクトリまたは別のOracleディレクトリ)がセントラル・エンタープライズ・ディレクトリであり、OracleディレクトリがOracleバックエンド・ディレクトリです。このシナリオでは、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトが作成されると、セントラル・エンタープライズ・ディレクトリはすべてのOracleコンポーネントおよびその他のディレクトリに関する同期情報のソースになります。Oracleディレクトリは、OracleコンポーネントをサポートするOracleバックエンド・ディレクトリとしてデプロイされます。このサポートを提供するために、Oracleディレクトリではフットプリントを格納して、接続ディレクトリでエントリを識別できるようにします。

トピック:

19.2.2.2.1 このデプロイメントの要件の理解

表19-2に、このデプロイの一般的な要件を示します。

表19-2 接続ディレクトリがセントラル・エンタープライズ・ディレクトリである場合の一般的な要件

要件 説明

初期起動

syncProfileBootstrapコマンドにより、セントラル・エンタープライズ・ディレクトリに格納されているユーザーおよびグループがOracleバックエンド・ディレクトリに移入されます。

パスワード資格証明などのユーザー情報を、セントラル・エンタープライズ・ディレクトリでのみ管理することを選択できます。そのようなデプロイでは、Oracle環境でシングル・サインオンを有効にするために、Oracle Directory Integration Platformにより、Oracleコンポーネントで必要なユーザー・エントリ属性のみを同期化できます。

パスワードは、セントラル・エンタープライズ・ディレクトリからOracle Internet Directoryに移行されません。

同期

ユーザーおよびグループ情報用のセントラル・エンタープライズ・ディレクトリは、接続ディレクトリ(Oracle Internet Directory、Oracle Unified Directory、Oracle Directory Server Enterprise Editionまたはサード・パーティ・ディレクトリ)です。セントラル・エンタープライズ・ディレクトリでのユーザーおよびグループ情報への変更は、インポート・プロファイルが構成されたときに、Oracle Directory Integration PlatformによりOracleバックエンド・ディレクトリと同期化されます。

Oracleバックエンド・ディレクトリからセントラル・エンタープライズ・ディレクトリへの同期は、エクスポート・プロファイルを構成することによって実行されます。

パスワード同期

パスワードは、セントラル・エンタープライズ・ディレクトリで管理されます。詳細は、「パスワード同期」を参照してください。

サード・パーティ委任認証プラグイン

ユーザー資格証明が接続ディレクトリで管理される場合、Oracleバックエンド・ディレクトリによって認証を委任できます。ユーザーを認証するため、特定のプラグインが、接続ディレクトリに格納されているユーザー資格証明に基づいてユーザーの認証を実行します。詳細は、「委任認証の理解」を参照してください。

セントラル・エンタープライズ・ディレクトリとして指定されているディレクトリに作成された新しいユーザーまたはグループは、Oracle Directory Integration Platformによって、Oracleディレクトリに自動的に同期化されます。これが発生する前に、セントラル・エンタープライズ・ディレクトリとOracleバックエンド・ディレクトリ間で一方向の同期が確立されている必要があります。

図19-4に、サード・パーティ・ディレクトリがセントラル・エンタープライズ・ディレクトリとなっている場合の通常のデプロイを示します。

図19-4 委任認証デプロイメントでサード・パーティ・ディレクトリをセントラル・エンタープライズ・ディレクトリとして使用するコンポーネント間の相互作用


図19-4の説明が続きます
「図19-4 委任認証デプロイメントでサード・パーティ・ディレクトリをセントラル・エンタープライズ・ディレクトリとして使用するコンポーネント間の相互作用」の説明

19.2.2.2.2 ユーザーまたはグループの同期プロセスとは

図19-4に、サード・パーティ・ディレクトリがセントラル・エンタープライズ・ディレクトリとなっている場合に、ユーザーまたはグループを同期化するための通常のプロセスを示します。

このプロセスは次のとおりです。

  1. ユーザー・エントリまたはグループ・エントリがサード・パーティ・ディレクトリ内に作成されます。

  2. 次にスケジュールされた間隔に、エントリ作成イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。

  3. 統合プロファイル内のマッピング情報に従って、サード・パーティ・ディレクトリのユーザー属性またはグループ属性がサード・パーティ・ディレクトリ内の対応する属性にマップされます。

  4. ユーザー・エントリまたはグループ・エントリがOracleバックエンド・ディレクトリ内に作成されます。

19.2.2.2.3 ユーザー・エントリまたはグループ・エントリの変更プロセスとは

接続ディレクトリでエントリが変更されるのは、新しい属性がエントリに追加された場合、既存の属性の値が変更された場合、または既存の属性が削除された場合です。

接続ディレクトリがセントラル・エンタープライズ・ディレクトリの場合、ユーザー・エントリまたはグループ・エントリの変更は次のプロセスに従います。

  1. 接続ディレクトリ内でエントリが変更されます。

  2. 次にスケジュールされた間隔に、エントリ変更イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。

  3. 統合プロファイル内のマッピング情報に従って、接続ディレクトリ内の属性がバックエンド・ディレクトリ内の対応する属性に適切にマップされます。

  4. ユーザー・エントリまたはグループ・エントリがOracleバックエンド・ディレクトリで変更されます。

図19-4に示すとおり、サード・パーティ・ディレクトリがセントラル・エンタープライズ・ディレクトリの場合、選択したパスワード同期方法に応じて、パスワード・リポジトリとして動作しているディレクトリ内でパスワードの変更が非同期的に発生します。これは、プラグインを使用することによって発生します。

19.2.3 LDAPスキーマのカスタマイズ方法の理解

宛先ディレクトリのLDAPスキーマは、ディレクトリのデプロイメントにカスタムのオブジェクト・クラスと属性やディレクトリ・サーバー間で同期する必要のあるカスタムの属性などのスキーマ拡張が含まれている場合にカスタマイズできます。

LDAPスキーマをカスタマイズするには、次のことを行う必要があります。

  • ソース・ディレクトリでスキーマ拡張を識別します。

  • データの移行および同期を開始する前に、ターゲット・ディレクトリでスキーマ拡張を作成します。

    ノート:

    スキーマ拡張の作成に加えて、対応するオブジェクト・クラスと同期化させる属性も、マッピング・ルールに追加する必要があります。

    関連項目:

19.2.4 パスワードの格納場所の選択について

どのディレクトリがセントラル・エンタープライズ・ディレクトリであるかに関係なく、パスワードは一方または両方のディレクトリに格納できます。どちらにもそれぞれ長所と短所があります。

この項では、次の項目でこれら2つについて比較します。

19.2.4.1 1つのディレクトリにのみパスワードを格納する場合の長所と短所の理解

1つのディレクトリにのみパスワードを格納すると、エントリ・ポイントの数を減らすことになるため、パスワードのセキュリティがより強力になります。また、パスワードが変更された場合の同期の問題もなくなります。

ただし、1つのディレクトリにのみパスワードを格納すると、ネットワーク全体に対するシングル・ポイント障害の原因となります。パスワードが格納されているディレクトリに障害が発生すると、他のディレクトリに接続するユーザーのバインド操作も失敗し、ユーザーは認証されません。

中央ディレクトリにのみパスワードを格納すると同期の問題はなくなりますが、アプリケーションでユーザーをそのディレクトリに対して認証できるようにする必要があります。これには、適切なプラグインを使用する必要があります。たとえば、セントラル・エンタープライズ・ディレクトリおよび中央パスワード・ストアの両方としてMicrosoft Active Directoryを使用している場合は、Microsoft Active Directoryに対してユーザーを認証するアプリケーションを有効にする必要があります。これを行うには、バックエンド・ディレクトリで委任認証を構成します。

ノート:

Oracleコンポーネントはパスワード・ベリファイアを使用してユーザーを認証しますが、パスワードがサード・パーティ・ディレクトリに格納されている場合、パスワード・ベリファイアはOracle Internet Directoryに格納されません。パスワードがOracleコンポーネントを使用して変更された場合、パスワード・ベリファイアの生成とOracle Internet Directoryへの格納の両方が行われます。

19.2.4.2 両方のディレクトリにパスワードを格納する場合の長所と短所の理解

Oracleバックエンド・ディレクトリと接続ディレクトリの両方にパスワードを格納する場合、理想的には、リアルタイムでパスワードを同期化する必要があります。

Oracle Directory Integration Platform 11gリリース1 (11.1.1)以上では、パスワードはリアルタイムで同期化されず、スケジュールに従って同期化されます。これは、セントラル・エンタープライズ・ディレクトリ内でパスワードが変更された時刻とその変更がもう1つのディレクトリに記録される時刻の間に、明確な差があることを意味します。

関連項目:

通常、パスワード値はハッシュされます。両方のディレクトリが同一のハッシング・アルゴリズムを使用する場合は、そのままの状態でハッシュ値を同期化できます。たとえば、Oracle Directory Server Enterprise Edition(以前のSun Java System Directory Server)とOracle Internet Directoryが統合されている環境があるとします。これらのディレクトリは両方とも共通のハッシング・アルゴリズムに対応しています。Oracle Internet Directoryでサポートされているハッシング方法を使用して、パスワードをハッシュし、Oracle Directory Server Enterprise Editionに格納する場合、Oracle Directory Server Enterprise EditionのパスワードのOracle Internet Directoryへの同期化は、その他の属性の場合と同様です。両方のディレクトリで同一のハッシング・アルゴリズムがサポートされていない場合は、クリアテキスト形式でのみパスワードを同期化する必要があります。

ノート:

バックエンド・ディレクトリと接続ディレクトリのパスワードを同期化するには、SSL接続を使用することをお薦めします。詳細は、「パスワード同期」を参照してください。

Oracle Internet Directoryが中央ディレクトリである場合や、Oracle Internet Directoryでサポートされているハッシング・アルゴリズムがその他のディレクトリでサポートされていない場合でも、パスワードの可逆暗号化が有効なときにはSSLサーバー認証モードによる同期化が可能です。

Microsoft Active Directoryが中央ディレクトリである場合にMicrosoft Active Directory内でパスワードを変更すると、プラグインがパスワード変更を遮断してOracle Internet Directoryに送信します。Oracle Internet Directoryが中央ディレクトリで、中央パスワード・ストアである場合、Oracle Directory Integration Platformがパスワード変更を特権ユーザーとして読み取り、対応するディレクトリに送信します。

ノート:

両方のディレクトリが同一のハッシング・アルゴリズムを使用しないデプロイでは、Oracleディレクトリのデフォルトのインストール環境ではパスワードの同期化は実行できません。構成する必要があります。

Oracleバックエンド・ディレクトリが中央ディレクトリではないデプロイでは、サード・パーティ・ディレクトリによってパスワード・ポリシーが施行されます。サード・パーティ・ディレクトリに対する認証リクエストがある場合、このディレクトリから認証が成功したか失敗したかの応答があります。ただし、サード・パーティ・ディレクトリからのパスワード・ポリシーの詳細なエラーは、Oracle Internet Directoryに配信されないため、クライアント・アプリケーションにも配信されません。

関連項目:

プラグインの詳細は、次を参照してください。

19.2.5 ディレクトリ情報ツリーの構造の選択について

インストール時に、各ディレクトリ・サーバーがデフォルトのドメインとデフォルトのディレクトリ情報ツリー(DIT)構造を作成する場合と作成しない場合があります。Oracle Internet Directoryインフラストラクチャのインストールにより、企業内のユーザーおよびグループの格納用に指定されたコンテナで、デフォルトのレルムが作成されます。Oracle Unified DirectoryおよびOracle Directory Server Enterprise Editionは、デフォルトのDITを作成しません。接続ディレクトリと統合する場合、両方のディレクトリで同一のDIT構造を作成して構成を単純化できます。または、ドメイン・レベルのマッピングを実行できます。

トピック:

19.2.5.1 両方のディレクトリ上での同一ディレクトリ情報ツリー構造の作成

両方のディレクトリで同一のDITを構成することをお薦めします。これによって、すべてのユーザー・オブジェクトとグループ・オブジェクトをそのままの状態で同期化できるため、一方のディレクトリにある識別名を持つエントリを別のディレクトリのURLにマップするタスクが削減されます。また、マッピングで発生する可能性のあるパフォーマンスの問題も削減できます。

同一のディレクトリ情報ツリーを作成するには、まず、セントラル・エンタープライズ・ディレクトリとなるディレクトリを決定し、その後、それにあわせてもう一方のディレクトリ情報ツリーを変更します。ディレクトリ統合プロファイルを更新して、確実にドメイン・レベルのルールを反映してください。

ユーザーがOracle Application Server Single Sign-Onを介してOracleアプリケーションにアクセスできるようにするには、ディレクトリ情報ツリーを、独自の認証および認可ドメインを持つ個別のアイデンティティ管理レルムとして識別することをお薦めします。

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のアイデンティティ管理レルムのデプロイに関する章

19.2.5.2 識別名のマッピングおよび制限

両方のディレクトリ上に同一のディレクトリ情報ツリーを持つことが不可能な場合は、Oracleバックエンド・ディレクトリと接続ディレクトリの間でドメインをマップする必要があります。たとえば、コンテナdc=mydir,dc=comの下にあるエントリはすべて、Oracleバックエンド・ディレクトリ内のdc=myOracleDir,dc=comの下で同期化する必要があるとします。これを実行するには、ドメイン・レベルのマッピング・ルールに指定します。

すべてのユーザーおよびグループの同期が目的の場合は、適切な識別名マッピングですべてのユーザー・エントリを同期化できます。ただし、グループ・エントリを同期化する場合は、時間がかかり、制限が追加される場合があります。この項では、識別名マッピングが行われている場合のユーザーおよびグループ両方の同期の例を示します。

例: ユーザー・エントリ・マッピング

接続ディレクトリがOracle Directory Server Enterprise Edition (以前のSun Java System Directory Server)で、そのエントリの形式がuid=name,ou=people,o=iplanet.orgであるとします。また、バックエンド・ディレクトリがOracle Internet Directoryで、そのエントリの形式がcn=name,cn=users,dc=iplanet,dc=comであるとします。Oracle Directory Server Enterprise Editionのネーミング属性はuidですが、Oracle Internet Directoryではcnであることに注意してください。

マッピング・ファイルには次のようなルールがあります。

DomainRules
ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com: cn=%, cn=users,dc=iplanet,dc=com
AttributeRules
Uid:1: :person:cn: :inetorgperson:

最終行の2列目の1の値は、Oracle Directory Server Enterprise EditionからOracle Internet Directoryに伝播されるすべての変更で、uid属性が存在している必要があることを示しています。これは、Oracle Internet Directory内のエントリの識別名を構成するには、uidを使用可能にする必要があるためです。

例: グループ・エントリ・マッピング

識別名マッピングが行われている場合、グループ・エントリの同期化は複雑になります。グループ・メンバーシップ(識別名)には、同期後、有効な識別名の値が必要です。これは、ユーザー識別名に対して行われた識別名マッピングをグループ・メンバーシップの値に適用する必要があることを意味します。

たとえば、ユーザー識別名の値を次のようにマップするとします。

ou=people,o=iplanet.org: cn=users,dc=iplanet,dc=com:

これは、ou=people,o=iplanet.orgの下のすべてのユーザー・エントリがcn=users,dc=iplanet,dc=comに移動することを示します。

グループ・メンバーシップは、次のようにマップする必要があります。

uniquemember: : : groupofuniquenames: uniquemember: :groupofuniquenames:dnconvert(uniquemember)

たとえば、uniquememberの値がcn=testuser1,ou=people,o=iplanet.orgの場合、その値はcn=testuser1,cn=users,dc=iplanet,dc=comになります。

また、uniquememberの値がcn=testuser1,dc=subdomain,ou=people,o=iplanet.orgの場合、その値はcn=testuser1,dc=subdomain,cn=users,dc=iplanet,dc=comになります。

これは、ネーミング属性またはRDN属性が両方のディレクトリで同じ場合に適した解決方法です。ネーミング属性がou=people,o=iplanet.org:cn=users,dc=iplanet,dc=com:cn=%,cn=users,dc=iplanet,dc=comなどのようにそれぞれのディレクトリで異なる場合、グループ・メンバーシップの実際の識別名は、指定したマッピング・ルールでは導出できません。現在、このような場合に、uniquememberまたはその他の識別名タイプの属性に対して識別名マッピングを行うことはできません。

グループ・メンバーシップを同期化する場合は、ソース・ディレクトリと宛先ディレクトリに同じネーミング属性を指定してください。

関連項目:

マッピング・ルールの指定方法は、「マッピング・ルールの構成」を参照してください

19.2.6 ログイン名の属性

任意のOracleコンポーネントにログインするときのログイン名の属性にはエンド・ユーザーのアイデンティティが含まれます。これは、Oracleバックエンド・ディレクトリに、属性orclcommonnicknameattributeの値として格納されます。

Oracleバックエンド・ディレクトリがOracle Internet Directoryの場合、属性orclcommonnicknameattributeは、コンテナcn=common,cn=products,cn=oracleContext,identity_management_realmの下にあります。

Oracleバックエンド・ディレクトリがOracle Unified DirectoryまたはOracle Directory Server Enterprise Editionの場合、属性orclcommonnicknameattributeは、コンテナcn=common,<suffix>,identity_management_realmの下にあります。

デフォルトでは、orclcommonnicknameattribute属性の値はuidです。これは、ログインに使用されるアイデンティティがユーザー・エントリのuid属性に格納されることを意味します。

接続ディレクトリにログイン用の特定の属性が存在する場合は、Oracleディレクトリ内の正しいorclcommonnicknameattributeにその属性をマップする必要があります。これは、接続ディレクトリとの同期に関連付けられているコネクタ用のマッピング・ファイルにある、マッピング・ルールの1つであることが必要です。

たとえば、Oracle Internet DirectoryをMicrosoft Active Directoryと同期化していて、Microsoft Active Directoryのログイン識別子がユーザー・エントリのuserPrincipalName属性に含まれているとします。userPrincipalName属性の値をOracle Internet Directoryと同期化して、uid属性(orclcommonnicknameattribute属性の値)に格納するとしますこのマッピングは、ディレクトリ統合プロファイルのマッピング・ルールに反映される必要があります。

ログイン識別子用のその他の属性も使用できます。たとえば、ログインにemployeeIDを使用する場合は、それに応じてマッピング・ルールを設定できます。この設定は、構成には影響しません。

関連項目:

ログイン名の属性の設定手順は、Oracle Fusion Middleware Oracle Identity Management委任管理ガイドを参照してください

19.2.7 ユーザー検索ベースの選択

ユーザー検索コンテキストは、ユーザーが存在するすべてのコンテナをリストする複数値属性によって表されます。デプロイメントに応じて、次のいずれかを実行します。

  • ユーザー集団全体にわたるユーザー検索コンテキスト値を設定します。

  • Oracle Internet Directoryセルフ・サービス・コンソールを使用してユーザー検索コンテキスト属性にコンテナを追加します。

関連項目:

ユーザー検索コンテキストの設定手順は、Oracle Fusion Middleware Oracle Identity Management委任管理ガイドを参照してください

19.2.8 グループ検索ベースの選択

グループ検索コンテキストは、グループが存在するすべてのコンテナをリストする複数値属性によって表されます。デプロイに応じて、すべてのグループ・エントリにわたるグループ検索コンテキスト値を設定するか、Oracle Internet Directoryセルフ・サービス・コンソールを使用してグループ検索コンテキスト属性にコンテナを追加します。

関連項目:

グループ検索コンテキストの設定手順は、Oracle Fusion Middleware Oracle Identity Management委任管理ガイドを参照してください。

19.2.9 セキュリティ問題に対処するためのガイドライン

セキュリティ上の3つの主要な問題を考慮する必要があります。

  • アクセス・ポリシー—ユーザー検索ベースとグループ検索ベースを不正なユーザーによるアクセスから適切に保護する必要があります。

  • 同期—Oracleバックエンド・ディレクトリおよび接続ディレクトリに接続するときにSSLを使用するようにOracle Directory Integration Platformを構成できます。これを実行すると、ディレクトリ・サーバー間で交換されるすべての情報が保護されます。

    ノート:

    Microsoft Active Directoryとパスワードを同期化するには、SSL通信を使用する必要があります。

  • パスワードの同期化—構成に応じて、パスワードを同期化できます。たとえば、Oracle Internet Directoryがセントラル・エンタープライズ・ディレクトリの場合は、パスワードの変更を接続ディレクトリに通信できます。パスワードを同期化する場合は、ディレクトリ間の通信をSSLサーバー認証モードで構成することをお薦めします。

19.2.10 Oracle Access Managerによるデプロイメントの管理方法について

Oracle Access Managerを使用して、接続ディレクトリと同期するOracle Internet Directoryのデプロイを管理するには、同期化されたユーザーがOracle Access Managerで表示できることを保証する必要があります。

19.3 Microsoft Active Directory統合の概念

この項では、Oracleバックエンド・ディレクトリとMicrosoft Active Directoryとの統合に関するその他の考慮事項について説明します。この項の内容は、次のとおりです。

関連項目:

Microsoft Active Directoryとの統合

19.3.1 Microsoft Active DirectoryからOracleバックエンド・ディレクトリへの同期方法の理解

Microsoft Active DirectoryからOracleバックエンド・ディレクトリへ変更を同期化するために、Oracle Directory Integration Platformでは、Microsoft Active Directory変更追跡メカニズムで使用可能になる増分変更をインポートします。Oracle Directory Integration Platformでは、次の2つのMicrosoft Active Directory変更追跡メカニズムをサポートします。

  • DirSync方式。Microsoft Active DirectoryでサポートされるLDAPコントロールを使用します。

  • USN-Changed方式。エントリの属性を使用します。

いずれの方式でも、変更が導出されるディレクトリに対して、Microsoft Active Directoryコネクタによりスケジュールされた間隔で問合せが行われます。各方式には、長所と短所があります。表19-3に、これら2つの方式の相違点を示します。

表19-3 DirSync方式とUSN-Changed方式の比較

考慮事項 DirSync方式 USN-Changed方式

キーの変更

エントリの一意の識別子であるObjectGUIDに変更を渡します。

識別名に変更を渡します。ObjectGUIDは識別名の変更の追跡に使用されます。

コネクタの有効化

コネクタを有効にするには、プロファイルの作成時にプロパティReaderをoracle.ldap.odip.gsi.ActiveReaderに設定します。

コネクタを有効にするには、プロファイルの作成時にプロパティReaderをoracle.ldap.odip.gsi.ActiveChgReaderに設定します。

テンプレート・ファイル

同期プロファイルのテンプレート・ファイルはadimport.properties (ORACLE_HOME/ldap/odi/conf)です。

同期プロファイルのテンプレート・ファイルはactivechgimp.properties (ORACLE_HOME/ldap/odi/conf)です。

エラー処理

エラー状態の結果、同期が停止した場合、次のサイクル中に、適用済の変更がすべて読み取られ、スキップされます。

同期が原子性を持つ必要はありません。同期が停止した場合、同期が中断されたエントリから、次の同期サイクルが開始します。

検索結果の情報

変更は、変更された属性と新しい値のみです。このためUSN-Changed方式より速くなる可能性があります。

変更エントリのすべての属性が取得されます。取得された値は、Oracleバックエンド・ディレクトリに格納されている古い値と比較され、更新されます。このためDirSync方式より時間がかかる可能性があります。

複数値の属性の変更

複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。

複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。

同期点の追跡方法

ディレクトリ内の変更を問い合せたときに、ディレクトリの状態を識別するCookie値に基づく増分変更が渡されます。

USNChanged属性(長整数、すなわち8バイト)に基づいて、ディレクトリ内の変更を問い合せます。値を変更して、同期を開始する点を調整できます。

必須のユーザー権限

ユーザーは、対象となるネーミング・コンテキストに対する変更のレプリケート権限が必要です。これにより、Microsoft Active Directory内のすべてのオブジェクトおよび属性を、それらに対するアクセス保護に関係なく、読み取ることができます。

関連項目: DirSync方式の使用時にMicrosoft Active Directoryユーザーに権限を割り当てる方法は、Microsoft Knowledge Base Article 303972 (https://support.microsoft.com/en-usで入手可能)を参照してください。このコンテキストには、この記事にあるMicrosoft Active Directory管理エージェントに使用される方法を適用します。

Microsoft Active Directoryユーザーには、Oracleバックエンド・ディレクトリに対して同期化するすべての必須属性を読み取る権限が必要です。

関連項目: USN-Changed方式の使用時に、Microsoft Active Directoryユーザーに権限を割り当てる方法は、Microsoftライブラリ(http://msdn.microsoft.com/)で入手可能なMicrosoft社のネットワーキングおよびディレクトリ関連のドキュメントを参照してください。

複数ドメインのサポート

異なるドメイン内のエントリに加えられた変更を読み取るには、異なるドメイン・コントローラへの個々の接続が必要です。

グローバル・カタログ・サーバーに接続することで、複数のドメインに加えられた変更を取得できます。

関連項目: 「複数ドメインMicrosoft Active Directory環境との同期化」。

異なるMicrosoft Active Directoryドメイン・コントローラへの切替え時のレプリケートされたディレクトリからの同期

同期は続行可能です。レプリケートされた環境に接続するときも同期キーは同じです。

次のことが必要です。

  • 既知のポイントに対する完全同期化

  • USNChanged値の更新

  • フェイルオーバー・ディレクトリとの同期開始

関連項目: 「同一ドメイン内の異なるMicrosoft Active Directoryドメイン・コントローラへの切替え」

同期の有効範囲

ディレクトリ内のすべての変更を読み取り、必須エントリへの変更のみをOracleバックエンド・ディレクトリに伝播します。

特定のサブツリーで変更の同期を有効にします。

ロード・バランサの背後に複数のMicrosoft Active Directory Serverを配置した環境の可用性

-

特定のMicrosoft Active Directoryドメイン・コントローラに接続するか、グローバル・カタログに接続します。次の場合にグローバル・カタログに接続します。

  • インポート操作のみに関心がある場合

  • グローバル・カタログに、同期化するすべてのエントリおよび属性が含まれている場合

  • グローバル・カタログのパフォーマンスが許容範囲内である場合

関連項目:

「バックエンド・ディレクトリから接続ディレクトリへの同期の理解」

19.3.2 WebDAVプロトコルの使用要件

WebDAVプロトコルを使用している場合、SSL用のアプリケーションを構成する必要があります。Oracleバックエンド・ディレクトリがエンド・ユーザーを認証する唯一の方法は、検証のためにActive Directoryにプレーン・テキスト・パスワードを渡すことであるため、Basic認証が必要です。Basic認証が存在しない場合は、Digest認証が使用されます。ただし、Digest認証の場合、検証のためにActive Directoryに渡すプレーン・テキスト・パスワードがOracleバックエンド・ディレクトリにないため、エンド・ユーザーは認証されません。エンド・ユーザーとサーバー間の通信チャネルが暗号化されないこと、エンド・ユーザー・パスワードも同様に暗号化されずに送信されることから、Basic認証はSecure Sockets Layer(SSL)を使用しないHTTP上ではサポートされません。

19.3.3 Microsoft Active Directory用のOracleバックエンド・ディレクトリ・スキーマ要素

表19-4に、Microsoft Active Directoryからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。

表19-4 Microsoft Active Directory用のOracleバックエンド・ディレクトリ・スキーマ要素

スキーマ要素 説明

orclObjectGUID

Microsoft Active DirectoryからOracleバックエンド・ディレクトリに移行されたユーザーおよびグループに対するMicrosoft Active DirectoryのOBJECTGUID属性値を格納します。

orclObjectSID

Microsoft Active DirectoryからOracleバックエンド・ディレクトリに移行されたユーザーおよびグループに対するMicrosoft Active DirectoryのOBJECTSID属性値を格納します。

orclSAMAccountName

Microsoft Active DirectoryのSAMAccountName属性値を格納します。Oracleバックエンド・ディレクトリでは、この属性はディレクトリ文字列型として定義されます。しかし、Microsoft Active Directoryでは、この属性に特殊文字または印刷不可能文字を使用できません。この属性を保持するエントリをOracleバックエンド・ディレクトリに追加する場合は、単純なテキスト文字列しか入力できず、そうしないとOracleバックエンド・ディレクトリからMicrosoft Active Directoryへの同期は失敗します。

orclUserPrincipalName

Microsoft Active DirectoryユーザーのKerberosユーザー・プリンシパル名を格納します。

orclADGroup

Microsoft Active Directoryのグループ属性を格納します。これらのグループ属性は、Oracle Directory Integration環境におけるMicrosoft Active Directoryのグループ・オブジェクトとOracleバックエンド・ディレクトリのグループ・オブジェクトの同期に使用されます。

orclADUser

Microsoft Active Directoryのユーザー属性を格納します。これらのユーザー属性は、Oracle Directory Integration and Provisioning環境におけるMicrosoft Active Directoryのユーザー・オブジェクトとOracleバックエンド・ディレクトリのユーザー・オブジェクトの同期に使用されます。

orclSourceObjectDN

Microsoft Active Directoryの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。

関連項目:

Microsoft Active Directory用のOracle Internet Directoryスキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

19.3.4 複数のMicrosoft Active Directoryドメイン・コントローラとの統合について

複数のドメインを持つMicrosoft Active Directoryのデプロイでは、単一のDITにすることも、複数のDITを組み合せることもできます。Microsoft Active Directoryでは、DITのグループをフォレストと呼びます。図19-5に、Microsoft Active DirectoryのフォレストがOracleバックエンド・ディレクトリにどのように反映されるかを示します。

図19-5 Oracleバックエンド・ディレクトリとMicrosoft Active Directory内のフォレストの間のマッピング

図19-5の説明が続きます
「図19-5 Oracleバックエンド・ディレクトリとMicrosoft Active Directory内のフォレストの間のマッピング」の説明

このディレクトリでは、2つのドメイン・ツリーが1つのフォレストを構成しています。これらのツリーは信頼関係にあり、一方のドメインのユーザーは他方のドメインのドメイン・コントローラによって認証されます。Microsoft Active Directory内のこのフォレストは、Oracleバックエンド・ディレクトリ内の同一に構成されているサブツリーにマップされます。

Oracleバックエンド・ディレクトリが中央ディレクトリであるデプロイの考慮事項

複数のMicrosoft Active Directoryドメインが存在する場合は、Microsoft Active Directoryドメインの数と同じ回数だけ、syncProfileBootstrapコマンドを実行する必要があります。これを実行するたびに、ターゲットのMicrosoft Active Directoryドメインで必要な特定のデータ・セットを選択します。

Oracle Directory Integration Platformによって、それぞれのMicrosoft Active Directoryドメイン内のユーザーおよびグループが同期化されます。同期を行うには、Oracleバックエンド・ディレクトリからMicrosoft Active Directoryドメインへの一方向の同期プロファイルを構成する必要があります。

Microsoft Active Directoryが中央ディレクトリであるデプロイの考慮事項

複数のMicrosoft Active Directoryサーバーがある場合、Microsoft Active Directoryの各ドメインからデータをブートストラップする必要があります。Microsoft Active DirectoryからOracleバックエンド・ディレクトリへの一方向の同期にグローバル・カタログを使用する場合は、グローバル・カタログ・サーバーから1回のみブートストラップする必要があります。

Oracle Directory Integration Platformによって、それぞれのMicrosoft Active DirectoryドメインからOracleバックエンド・ディレクトリにユーザーおよびグループが同期化されます。同期が行われる前に、Oracleバックエンド・ディレクトリと各Microsoft Active Directoryドメインのドメイン・コントローラ間で一方向の同期プロファイルが確立されている必要があります。

19.3.5 複数ドメインMicrosoft Active Directory環境との同期化

この項では、複数ドメインMicrosoft Active Directory環境との同期化の考慮事項について説明します。この項の内容は、次のとおりです。

19.3.5.1 Microsoft Active DirectoryからOracleバックエンド・ディレクトリへのインポートに必要な構成について

通常、インポートを行うには、DirSync方式またはUSN-Changed方式のいずれを使用しているかに関係なく、Microsoft Active Directoryドメインごとに1つインポート・プロファイルを構成する必要があります。ただし、USN-Changed方式を使用している場合は、グローバル・カタログを使用すれば、Microsoft Active Directoryフォレスト全体からインポートできます。グローバル・カタログを使用するにはインポート・プロファイルを1つ構成するだけですが、次の考慮事項に注意してください。

  • グローバル・カタログは読取り専用であるため、Oracleバックエンド・ディレクトリにデータをインポートする場合にのみ使用できます。

  • グローバル・カタログにはすべての属性は含まれていませんが、使用可能な属性はMicrosoft Active Directoryで構成できます。

  • グローバル・カタログは認証のポイントであるため、このポイントから同期が開始されると追加のオーバーヘッドが発生する可能性があります。

関連項目:

Microsoft Active Directoryスキーマ内のグローバル・カタログの属性の詳細は、Microsoft Help and Support (http://support.microsoft.com/)にあるMicrosoft Knowledge Base Article 256938を参照してください

19.3.5.2 Microsoft Active Directory Lightweight Directory ServiceからOracleバックエンド・ディレクトリへのインポートに必要な構成について

Microsoft Active Directoryと異なり、Microsoft Active Directory Lightweight Directory Service(AD LDS: 旧称Active Directory Application Mode(ADAM))からOracleバックエンド・ディレクトリへの同期にはUSN-Changed方式のみが使用されます。Microsoft AD LDSからOracleバックエンド・ディレクトリにエントリをインポートするには、Microsoft AD LDSに接続するインポート・プロファイルを、それぞれのポート詳細を使用して構成する必要があります。

19.3.5.3 Oracleバックエンド・ディレクトリからMicrosoft Active Directoryへのエクスポートに必要な構成について

複数ドメインMicrosoft Active Directory環境と統合するために、Oracle Directory Integration Platformでは、各Microsoft Active Directoryドメインから構成情報を取得します。Microsoft Active Directoryドメインの数と同数のエクスポート・プロファイルを構成する必要があります。

19.3.5.4 例: 複数の接続ディレクトリ・ドメインとの統合

複数のドメインを持つ接続ディレクトリのデプロイでは、単一のDITにすることも、複数のDITを組み合せることもできます。図19-6に、接続ディレクトリの複数のドメインが、Oracleバックエンド・ディレクトリのDITにどのようにマップされるかを示します。

図19-6 Oracleバックエンド・ディレクトリとMicrosoft Active Directory内の複数のドメインの間のマッピングの例

図19-6の説明が続きます
「図19-6 Oracleバックエンド・ディレクトリとMicrosoft Active Directory内の複数のドメインの間のマッピングの例」の説明

図19-6では、接続ディレクトリ環境に1つの親ドメインと2つの子ドメインがあります。

最初の子ドメインa.us.MyCompany.comは、Oracleバックエンド・ディレクトリのdc=a,dc=us,dc=MyCompany,dc=comにマップされます。2番目の子ドメインb.us.MyCompany.comは、Oracleバックエンド・ディレクトリのdc=b,dc=us,dc=MyCompany,dc=comにマップされます。接続ディレクトリ環境の共通ドメイン・コンポーネントus.MyCompany.comは、Oracleバックエンド・ディレクトリのデフォルトのアイデンティティ管理レルム、この場合はdc=us,MyCompany,dc=comにマップされます。

19.3.6 外部セキュリティ・プリンシパルの理解

Microsoft Active Directoryのユーザーやコンピュータ・アカウントは、コンピュータや人などの物理エンティティを表します。ユーザー・アカウントおよびコンピュータ・アカウントは、グループと同様に、セキュリティ・プリンシパルと呼ばれます。セキュリティ・プリンシパルは、自動的にセキュリティ識別子を割り当てられるディレクトリ・オブジェクトです。セキュリティ識別子を持つオブジェクトは、ネットワークにログインし、ドメイン・リソースにアクセスできます。ユーザー・アカウントまたはコンピュータ・アカウントは、次のことに使用されます。

  • ユーザーまたはコンピュータのアイデンティティの認証

  • ドメイン・リソースへのアクセス権の認可または否認

  • 他のセキュリティ・プリンシパルの管理

  • ユーザー・アカウントまたはコンピュータ・アカウントを使用して実行されるアクションの監査

たとえば、エンタープライズ管理者グループのメンバーであるユーザー・アカウントまたはコンピュータ・アカウントは、フォレスト内のすべてのドメイン・コントローラで、ログインの許可を自動的に付与されます。

ユーザー・アカウントおよびコンピュータ・アカウントは、Microsoft Active Directory Users and Computersを使用して、追加、無効化、リセットおよび削除されます。

Microsoft Active Directoryの信頼関係では、あるドメインのユーザーは、別のドメインのドメイン・コントローラにより認証されます。信頼関係は、推移的にも非推移的にもなります。

  • 推移的な信頼関係では、あるドメインに拡張された信頼関係は、そのドメインを信頼する他のすべてのドメインに自動的に拡張されます。たとえば、A、B、Cの3つのドメインがあり、BとCはAと直接の信頼関係にあるとします。この場合、BとCの間にも信頼関係が生じます。これは、BとCの間には直接の信頼関係はありませんが、どちらもAと直接の信頼関係にあるためです。

  • 非推移的な信頼関係では、信頼は直接関係のある2つのドメインに限定され、フォレスト内の他のドメインには適用されません。

あるフォレストのWindows 2000ドメインと、そのフォレスト外のWindows 2000ドメインの間に信頼関係が確立されている場合、外部ドメインからのセキュリティ・プリンシパルは、フォレスト内のリソースへのアクセス権を付与されます。外部ドメインからのセキュリティ・プリンシパルは、外部セキュリティ・プリンシパルと呼ばれ、Microsoft Active Directoryでは外部セキュリティ・プリンシパル・オブジェクトとして表されます。これらの外部セキュリティ・プリンシパルは、フォレスト外のドメインからメンバーを受け入れるドメイン・ローカル・グループのメンバーになることができます。

外部セキュリティ・プリンシパルは、Microsoft Active Directory環境の2つのドメイン間に非推移的な信頼関係がある場合に使用されます。

Microsoft Active Directory環境の非推移的な信頼関係では、あるドメインが別のドメインからの外部セキュリティ・プリンシパルを認識すると、そのエンティティはDNエントリのように表されます。そのエントリでは、RDNコンポーネントは、信頼関係のドメインにおける元のエントリのSIDに設定されます。グループの場合は、外部セキュリティ・プリンシパルの識別名が、信頼関係のドメインにおける元のエントリの識別名としてではなく、メンバーの値として表されます。このため、外部セキュリティ・プリンシパルがOracleバックエンド・ディレクトリと同期化されるときに問題が発生する可能性があります。

19.4 Oracle Directory Server Enterprise Edition(Sun Java System Directory Server)統合の概念

この項では、Oracle Internet Directory (バックエンド・ディレクトリ)とOracle Directory Server Enterprise Edition (以前のSun Java System Directory Server)との統合に関するその他の考慮事項について説明します。この項の内容は、次のとおりです。

関連項目:

Oracle Directory Server Enterprise Edition (接続ディレクトリ)との統合

19.4.1 Oracle Directory Server Enterprise EditionからOracle Directory Integration Platformへの同期の理解

Oracle Directory Server Enterprise Edition(以前のSun Java System Directory Server)は、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。Oracle Directory Server Enterprise EditionからOracle Internet Directoryへの同期は、この変更ログを活用します。

関連項目:

19.4.2 Oracle Directory Server Enterprise Edition (Sun Java System Directory Server)用のOracle Internet Directoryスキーマ要素の理解

Oracle Internet Directoryには、Oracle Directory Server Enterprise Editionからインポートされるユーザー用のorclSourceObjectDN属性が含まれます。orclSourceObjectDN要素は、Oracle Directory Server Enterprise Editionの各エントリの識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。

19.5 IBM Tivoli Directory Server統合の概念

この項では、Oracleバックエンド・ディレクトリとIBM Tivoli Directory Serverとの統合に関するその他の考慮事項について説明します。この項の内容は、次のとおりです。

19.5.1 IBM Tivoli Directory Serverでのディレクトリ・オブジェクトの変更について

IBM Tivoli Directory Serverは、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。IBM Tivoli Directory ServerからOracleバックエンド・ディレクトリへの同期では、この変更ログを利用します。

ノート:

IBM Tivoli Directory Serverバージョン6.2では、tombstoneがサポートされています。

19.5.2 IBM Tivoli Directory Server用のOracleバックエンド・ディレクトリ・スキーマ要素の理解

表19-5に、IBM Tivoli Directory Serverからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。

表19-5 IBM Tivoli Directory Server用のOracleバックエンド・ディレクトリ・スキーマ要素

スキーマ要素 説明

orclSourceObjectDN

Tivoliの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。

orclTDSEntryUUID

IBM Tivoliの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。

orclTDSObject

Tivoliディレクトリ・オブジェクトを表します。

関連項目:

19.6 Novell eDirectoryおよびOpenLDAP統合の概念

この項では、Oracleバックエンド・ディレクトリとNovell eDirectoryまたはOpenLDAPとの統合に関するその他の考慮事項について説明します。

トピック:

関連項目:

Novell eDirectoryまたはOpenLDAPとの統合

19.6.1 Novell eDirectoryまたはOpenLDAPからOracleバックエンド・ディレクトリへの同期について

Novell eDirectoryまたはOpenLDAPからOracleバックエンド・ディレクトリへ変更を同期化するために、Oracle Directory Integration Platformでは、Novell eDirectoryまたはOpenLDAPの各エントリの変更タイムスタンプを評価します。最後の同期の実行時間よりも新しいタイムスタンプを持つエントリがOracleバックエンド・ディレクトリで更新されます。

Novell eDirectoryまたはOpenLDAPで削除されたエントリについて、Oracle Directory Integration Platformでは、Oracleバックエンド・ディレクトリのエントリとNovell eDirectoryまたはOpenLDAPとの間で線形比較して削除済エントリを識別します。つまり、両方のディレクトリのエントリが指定された間隔で比較されます。Oracleバックエンド・ディレクトリとNovell eDirectoryまたはOpenLDAPの両方で使用できないエントリは削除されます。ディレクトリ・エントリが比較される際にサーバーでのパフォーマンスの低下を回避するために、DITの特定のサブセットを検索するように比較をカスタマイズできます。

関連項目:

19.6.2 Novell eDirectory用のOracleバックエンド・ディレクトリ・スキーマ要素の理解

Novell eDirectoryからインポートしたOracleバックエンド・ディレクトリのスキーマ要素について理解します。

表19-6に、Novell eDirectoryからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。

表19-6 Novell eDirectory用のOracleバックエンド・ディレクトリ・スキーマ要素

スキーマ要素 説明

orclSourceObjectDN

Novell eDirectoryの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。

orclndsobjectguid

調整に必須。Novell eDirectoryの各エントリに対するGUID値を表します。この値は、同期キーとして使用されます。

orclsourcemodifytimestamp

必須。Novell eDirectoryの各エントリのmodifytimestamp属性を表します。この値は、同期化する必要があるエントリを取得する際に使用されます。

orclsourceCreateTimestamp

必須。Novell eDirectoryの各エントリのcreatetimestamp属性を表します。この値は、削除されたエントリの同期で使用されます。

orclndsobject

Novell eDirectoryのNDSオブジェクトを表します。

関連項目:

Novell eDirectory用のOracleバックエンド・ディレクトリ・スキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAPスキーマの概要に関する項を参照してください。

19.6.3 OpenLDAP用のOracleバックエンド・ディレクトリ・スキーマ要素の理解

OpenLDAPからインポートしたOracleバックエンド・ディレクトリのスキーマ要素について理解します。

表19-7に、OpenLDAPからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。

表19-7 OpenLDAP用のOracle Internet Directoryスキーマ要素

スキーマ要素 説明

orclSourceObjectDN

OpenLDAPの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。

orclOpenLdapEntryUUID

調整に必須。OpenLDAPの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。

orclsourcemodifytimestamp

必須。OpenLDAPの各エントリのmodifytimestamp属性を表します。この値は、同期化する必要があるエントリを取得する際に使用されます。

orclsourceCreateTimestamp

必須。OpenLDAPの各エントリのcreatetimestamp属性を表します。この値は、削除されたエントリの同期で使用されます。

orclopenldapobject

OpenLDAPオブジェクトを表します。

関連項目:

OpenLDAP用のOracleバックエンド・ディレクトリ・スキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAPスキーマの概要に関する項を参照してください。

19.7 Oracle Directory Integration Platformでの接続ディレクトリ統合の制限

Oracle Directory Integration Platformでは、スキーマおよびACLの同期はサポートされません。schemasyncツールを使用して、Oracle Internet Directoryと接続ディレクトリの間で、スキーマの違い、特に属性とオブジェクト・クラスの違いを確認できます。違いを確認した後、schemasyncツールを使用して、スキーマを同期することができます。

関連項目:

schemasyncツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のスキーマ要素同期ユーティリティに関する項を参照してください。