| Oracle Fusion Middleware Oracle Identity Management統合ガイド 11gリリース1（11.1.1） B55920-01 |
|
 戻る |
 次へ |
この章では、Oracle Identity Managementとサード・パーティ・ディレクトリとの統合の基本概念と、統合プロセスの一環として行う様々な決定について説明します。
|
注意: この章を読む前に、次の資料の内容を理解しておく必要があります。
|
この章の内容は次のとおりです。
|
関連項目: サード・パーティ・ディレクトリとの同期に関する特定の実装の詳細は、次の各章を参照してください。 |
すべてのOracleコンポーネントは、Oracle Identity Managementと統合することによって、セキュリティが集中管理されます。環境内でOracle Identity Managementとサード・パーティ・ディレクトリ（Microsoft Active Directoryなど）の両方を使用する場合、コネクタを使用して2つのシステムを統合し、両方のデータを同期化することができます。コネクタとは、あらかじめパッケージされた接続ソリューションで、これを使用するとOracle Internet Directoryを接続ディレクトリと同期化できます。
この項では、Oracle Identity Managementとサード・パーティ接続ディレクトリの統合に必要なOracleコンポーネントとアーキテクチャについて説明します。内容は次のとおりです。
|
注意: Oracle Internet Directory 11gリリース1（11.1.1）との統合に関して保証されているサード・パーティ・ディレクトリおよびサーバーの詳細は、「Oracle Identity Management Certification Information」を参照してください。「Oracle Identity Management Certification Information」には、次に示すOracle Technology NetworkのWebサイトからアクセスできます。 |
この項では、Oracle Identity Managementとサード・パーティ・ディレクトリとの統合に使用される次のコンポーネントについて説明します。
|
関連項目: Oracle Internet Directoryとサード・パーティ・ディレクトリとの統合に使用されるツールの詳細は、第3章「Oracle Directory Integration Platformの管理ツール」を参照してください。 |
Oracle Internet Directory
Oracle Internet Directoryは、Oracleコンポーネントとサード・パーティのアプリケーションによって、ユーザー・アイデンティティおよび資格証明が格納され、アクセスされるリポジトリです。ここでは、Oracleディレクトリ・サーバーを使用して、ユーザーにより入力された資格証明をOracle Internet Directoryに格納された資格証明と比較することで、ユーザー認証が行われます。資格証明がサード・パーティのディレクトリに格納されていて、Oracle Internet Directoryに格納されていない場合でも、ユーザーを認証することはできます。この場合は、Oracle Internet Directoryでは、サード・パーティのディレクトリ・サーバーに対してユーザー認証を行う外部認証プラグインが使用されます。
|
関連項目: Oracle Internet Directoryでのセキュリティの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のセキュリティに関する章を参照してください。 |
Oracle Directory Integration Platform
Oracle Directory Integration Platformは、Oracle Identity Managementの一部としてインストールされます。これをOracle Internet Directoryと同じホストで実行するようにも、異なるホストで実行するようにも構成できます。
Oracle Directory Integration Platformでは、次の処理が可能です。
Oracle Internet Directoryと他のディレクトリおよびユーザー・リポジトリ間の同期
Oracleコンポーネント用の自動プロビジョニング・サービス
Oracle Directory Integration Platformには、Oracle Internet Directoryを他のLDAPディレクトリまたはデータ・ストアと同期化するためのコネクタが含まれています。Oracle Directory Integration Platform統合コネクタを使用すると、次のことができます。
サード・パーティ・ディレクトリとの一方向または双方向いずれかの同期の構成
同期専用の属性サブセットの指定。これは、適切なマッピング・ルールを構成することによって行います。マッピング・ルールは、実行時に変更できます。
Oracle Delegated Administration Services
Oracle Delegated Administration ServicesはWebベースの事前定義済ユニットのセットで、ユーザーのかわりにディレクトリ操作を実行します。ディレクトリ管理者は、他の管理者やエンド・ユーザーに特定の機能を委任できるようになるため、より多くの日常的なディレクトリ管理タスクから解放されます。また、ユーザー・エントリの作成、グループ・エントリの作成、エントリの検索、ユーザー・パスワードの変更など、ディレクトリ対応アプリケーションに必要な機能の大部分が提供されます。ディレクトリ内のアプリケーション・データを管理するには、Oracle Delegated Administration ServicesベースのツールであるOracle Internet Directoryセルフサービス・コンソールを使用します。このツールは、Oracle Internet Directoryとともに使用できるようになっています。あるいは、Oracle Delegated Administration Servicesを使用して、アプリケーション・データを管理するための独自ツールを開発できます。
|
関連項目: 『Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management』 |
Oracle Application Server Single Sign-On
OracleAS Single Sign-On Serverを使用すると、ユーザーは1回のみのログインで、WebベースのOracleコンポーネントにアクセスできます。
Oracleコンポーネントは、ログイン機能をOracleAS Single Sign-On Serverに委任します。初めてOracleコンポーネントにログインする場合は、そのコンポーネントによってOracleAS Single Sign-On Serverにログインがリダイレクトされます。OracleAS Single Sign-On Serverでは、ユーザーが入力した資格証明を、Oracle Internet Directoryに格納されている資格証明と比較します。資格証明の検証後、OracleAS Single Sign-On Serverにより、現行セッション中、ユーザーが使用を認可されているすべてのコンポーネントに対するユーザー・アクセス権が付与されます。
Oracle Application Server Single Sign-Onを使用すると、Microsoft Windows環境でのネイティブ認証が有効になります。ユーザーは、Windows環境にログインすると、自動的にOracleコンポーネントにアクセスできるようになります。OracleAS Single Sign-On Serverが、ユーザーのKerberos資格証明を使用してユーザーをOracle環境に自動的にログインさせます。
|
関連項目: OracleAS Single Sign-On Serverの詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On』を参照してください。 |
外部認証プラグイン（Microsoft Active Directory外部認証プラグインなど）は、Oracleディレクトリ・サーバーの一部で、これを使用すると、ユーザーはMicrosoft Windows資格証明を使用してOracle環境にログインできます。外部認証プラグインがインストールされていれば、Oracleディレクトリ・サーバーにより起動されます。このプラグインにより、サード・パーティ・ディレクトリでユーザーの資格証明が検証されます。検証が正常に実行された場合は、Oracleディレクトリ・サーバーからOracleAS Single Sign-On Serverに通知されます。
サード・パーティ・ディレクトリのオブジェクトと同期化されるオブジェクトを識別するために、Oracle Internet Directoryには、サード・パーティ・ディレクトリ（Microsoft Active Directoryなど）に固有の属性に対応するスキーマ要素が含まれています。次の各項では、これらのスキーマ要素について説明します。
この項の内容は次のとおりです。
|
関連項目: ディレクトリ情報ツリーの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のディレクトリの概念とアーキテクチャに関する章を参照してください。 |
Oracle Internet Directoryでは、アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイにより定義され、施行される企業内での範囲を定義します。次の要素で構成されます。
有効範囲の定義されたエンタープライズ・アイデンティティの集合（USドメインのすべての従業員など）。
これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。
グループの集合。すなわち、アイデンティティ管理ポリシーの設定を簡単にするアイデンティティの集合です。
同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。したがって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー（パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど）を施行できます。これは、Oracle Fusion Middlewareのホスティングされたデプロイで役立ちます。
各アイデンティティ管理レルムには、他のレルムと区別するために固有の名前が付けられます。また、レルムに対して完全な管理制御を行うために、レルム固有の管理者も決められます。
すべてのOracleコンポーネントが機能するには、アイデンティティ管理レルムが必要です。Oracle Internet Directoryのインストール中に作成される特別なレルムは、デフォルト・アイデンティティ管理レルムと呼ばれます。これは、レルムの名前が指定されていない場合に、Oracleコンポーネントが、ユーザー、グループおよび関連付けられたポリシーを検索する場所です。このデフォルトのレルムにより、ディレクトリ内で情報の適切な編成が容易になり、適切なアクセス制御が実行されます。
デフォルト・アイデンティティ管理レルムは、ディレクトリに1つのみです。デプロイに複数のアイデンティティ管理レルムが必要である場合、その1つをデフォルトとして選択します。
図16-1に、デフォルト・アイデンティティ管理レルムを示します。
図16-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レルムのデプロイに関する章を参照してください。 |
DITを計画する際、同期の前に行う最も重要な決定は、次のとおりです。
中央ディレクトリとなるディレクトリ
同期化するオブジェクト。たとえば、次のようなものです。
DITで同期化する必要のある部分。DIT全体またはその一部のみを同期化できます。
エントリごとの、同期化の必要な特定のコンテンツ。エントリのコンテンツ全体またはその一部のみを同期化できます。
同期化する位置。次の2つのオプションがあります。
DITの各エントリの相対的な位置が、ソース・ディレクトリと宛先ディレクトリの両方で同じになるように同期化できます。この構成は、1対1識別名マッピングと呼ばれ、最も一般的に使用されている構成です。ソース識別名が宛先識別名と同じであるため、この構成では2つの識別名が異なる場合よりパフォーマンスが向上します。
DITの各エントリの相対的な位置が、ソース・ディレクトリと宛先ディレクトリで異なるように同期化できます。この構成では、Oracle Directory Integration Platformにより、マップされるすべてのエントリ（グループ・エントリ内の参照を含む）の識別名値を変更する必要があります。これにはより集中的な計算が必要です。
このように同期化する場合、「サポートされている属性マッピング・ルールと例」で説明されているように、dnconvertマッピング・ルールを使用する必要があります。
図16-2に、Oracle Internet Directoryとサード・パーティ・ディレクトリ間での1対1マッピングの例を示します。
図16-2 Oracle Internet Directoryとサード・パーティ・ディレクトリのホストがドメインus.MyCompany.com下に存在する場合の両ディレクトリにおけるデフォルトのDIT構造
図16-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サブツリーに表示されます。
図16-2の例では、usersサブツリーのみ、1対1のドメイン・マッピングを使用してサード・パーティ・ディレクトリからOracle Internet Directoryに同期する必要があります。
|
注意: 図16-2では、2つのディレクトリのトポロジが同じですが、これは説明目的でそうしているだけです。2つのディレクトリは、同じドメインに存在する必要はありません。Oracle Internet Directoryは、サード・パーティ・ディレクトリに接続できるのであれば、ネットワークのどこにあってもかまいません。さらに、例では同期がサード・パーティ・ディレクトリからOracle Internet Directoryへの一方向ですが、かわりに同期を双方向に行うこともできます。 |
この項では、統合環境の計画方法について説明します。内容は次のとおりです。
LDAPディレクトリ・サーバーをすでに所有している企業にOracle Internet Directoryをデプロイする場合は、両方のディレクトリが同じ環境に共存するように構成する必要があります。
ディレクトリの共存には、次のいずれかのデプロイが必要です。
エンタープライズ・ユーザー・セキュリティをサポートするためのOracle Internet Directoryとの単純な同期。データベース・サーバーの使用により、環境内でエンタープライズ・ユーザーがサポートされている場合は、この方法を使用します。
Oracle Fusion Middlewareインフラストラクチャとの完全な統合。これにより、エンタープライズ・ユーザー全員が、Oracle Fusion Middlewareスイートの各種コンポーネントを使用できるようになります。環境内で企業ディレクトリとしてサード・パーティ・ディレクトリが使用され、Oracle Fusion Middlewareスイートのアプリケーションがデプロイされている場合は、この方法を使用します。
すべてのOracle Fusion Middlewareコンポーネントがアイデンティティ管理レルムに依存するため、Oracle Fusion Middlewareインフラストラクチャとの完全な統合には、そのレルムのコンテナについていくつか決定を行う必要があります。これらの事項を決定した後、ディレクトリ間でブートストラップおよび同期を構成できます。
この項では、企業の中央ディレクトリとなるディレクトリの選択方法について説明します。内容は次のとおりです。
Oracle Internet Directoryが中央ディレクトリの場合、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトを作成すると、Oracle Internet DirectoryはすべてのOracleコンポーネントおよびサード・パーティ・ディレクトリに関するプロビジョニング情報のソースになります。その後、企業全体のユーザー・オブジェクトとグループ・オブジェクトが、各種Oracleコンポーネントおよびサード・パーティ・ディレクトリ内にOracle Internet Directoryからプロビジョニングされます。
表16-1に、このデプロイの一般的な要件を示します。
表16-1 Oracle Internet Directoryを企業の中央ディレクトリとして使用する場合の一般的な要件
| 要件 | 説明 |
|---|---|
|
初期起動 |
syncProfileBootstrapコマンドにより、Oracle Internet Directoryに格納されているユーザーおよびグループがサード・パーティ・ディレクトリに移入されます。 |
|
同期 |
ユーザーおよびグループ情報は、Oracle Internet Directoryで管理されます。その情報への変更は、エクスポート・プロファイルが構成されたときに、Oracle Directory Integration Platformによりサード・パーティ・ディレクトリと同期化されます。 サード・パーティ・ディレクトリからOracle Internet Directoryへの同期は、インポート・プロファイルを構成することによって実行できます。 |
|
パスワードおよびパスワード・ベリファイア |
パスワードは、Oracle Internet Directoryセルフ・サービス・コンソールなどのOracleツールを使用してOracle Internet Directoryで管理されます。パスワードの変更は、Oracle Directory Integration Platformによってサード・パーティ・ディレクトリと同期化されます。ただし、このサーバーでパスワードの変更を同期化する前に、マッピング・ルールにパスワードの同期を構成する必要があります。 パスワードは安全に管理されるため、パスワードを同期化するためのサード・パーティ・ディレクトリとの通信は、SSLで行う必要があります。サーバー認証モードで、サード・パーティ・ディレクトリからの適切な資格証明により、Oracle Directory Integration Platformを実行します。サード・パーティ・ディレクトリもSSLに対応していることを確認してください。 Oracle環境にパスワード・ベリファイアが必要な場合は、ユーザー・エントリを作成するか、またはパスワードを変更すると、パスワード・ベリファイアが自動的に生成されます。 |
|
Oracle Application Server Single Sign-On |
ユーザーは、OracleAS Single Sign-On Serverを使用して、Oracle環境にログインします。 Oracleディレクトリ・サーバーは、ユーザーの認証のためにOracleAS Single Sign-On Serverからコールされると、ローカルで使用可能な資格証明を使用します。外部認証は起動しません。 ユーザーがOracle環境内の各種コンポーネントにアクセスするためにログインするのは1回のみです。 |
Oracle Internet Directoryの新しいユーザーまたはグループは、Oracle Directory Integration Platformによって自動的にプロビジョニングできます。この自動プロビジョニングには、次の条件が必要です。
Oracleディレクトリ・サーバーが、変更ログが有効な状態で稼働している。
変更ログはパージされない。
これら2つの条件が満たされていない場合、Oracle Internet DirectoryのエントリをLDIFファイルにダンプし、サード・パーティ・ディレクトリに対してそのデータをアップロードする必要があります。
|
関連項目: 変更ログのパージの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のガベージ・コレクションに関する章を参照してください。 |
図16-3に、Oracle Internet Directoryが企業の中央ディレクトリとなっている場合の通常のデプロイを示します。
図16-3が示すように、Oracle Internet Directoryが企業の中央ディレクトリの場合、ユーザーまたはグループの通常のプロビジョニングは次のプロセスに従います。
ユーザー・エントリまたはグループ・エントリは、Oracle Internet Directoryセルフ・サービス・コンソールまたはコマンドライン・ツールを使用してOracle Internet Directoryに作成されます。
次にスケジュールされた間隔に、エントリ作成イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。
統合プロファイル内のマッピング情報に従って、Oracle Internet Directory内のユーザー属性またはグループ属性が、サード・パーティ・ディレクトリのスキーマで必要とされるとおりに、対応するユーザー属性またはグループ属性に適切にマップされます。
ユーザー・エントリおよびグループ・エントリがサード・パーティ・ディレクトリ内に作成されます。
次の場合、Oracle Internet Directory内でユーザー・エントリが変更されます。
新しい属性がエントリに追加される場合。
既存の属性の値が変更される場合。
既存の属性が削除される場合。
Oracle Internet Directoryが企業の中央ディレクトリの場合、ユーザー・エントリまたはグループ・エントリの変更時に実行されるイベントの順序は次のとおりです。
Oracle Internet Directoryセルフ・サービス・コンソールまたはOracle Enterprise Manager Fusion Middleware Controlを使用して、エントリが変更されます。
次にスケジュールされた間隔に、エントリ変更イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。
統合プロファイル内のマッピング情報に従って、Oracle Internet Directory内の属性が、接続ディレクトリ内の対応する属性に適切にマップされます。
サード・パーティ・ディレクトリ内でユーザー・エントリが変更されます。
サード・パーティ・ディレクトリが企業の中央ディレクトリの場合、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトを作成すると、サード・パーティ・ディレクトリはすべてのOracleコンポーネントおよびその他のディレクトリに関するプロビジョニング情報のソースになります。この場合、Oracle Internet DirectoryはOracleコンポーネントのサポート用にデプロイされます。このサポートを提供するために、Oracle Internet Directoryには、サード・パーティ・ディレクトリ内のエントリの識別を可能にするフットプリントが格納されています。
表16-2に、このデプロイの一般的な要件を示します。
表16-2 サード・パーティ・ディレクトリを企業の中央ディレクトリとして使用する場合の一般的な要件
| 要件 | 説明 |
|---|---|
|
初期起動 |
syncProfileBootstrapコマンドにより、サード・パーティ・ディレクトリに格納されているユーザーおよびグループがOracle Internet Directoryに移入されます。 サード・パーティ・ディレクトリでのみ、パスワード資格証明などのユーザー情報の管理を選択できます。そのようなデプロイでは、Oracle環境でシングル・サインオンを有効にするために、Oracle Directory Integration Platformにより、Oracleコンポーネントで必要なユーザー・エントリ属性のみを同期化できます。 パスワードは、サード・パーティ・ディレクトリからOracle Internet Directoryへ移行されません。 |
|
同期 |
ユーザーおよびグループ情報の中央ディレクトリはサード・パーティ・ディレクトリです。サード・パーティ・ディレクトリでのユーザーおよびグループ情報への変更は、インポート・プロファイルが構成されたときに、Oracle Directory Integration PlatformによりOracle Internet Directoryと同期化されます。 Oracle Internet Directoryからサード・パーティ・ディレクトリへの同期は、エクスポート・プロファイルを構成することによって実行されます。 |
|
パスワードおよびパスワード・ベリファイア |
パスワードは、サード・パーティ・ディレクトリで管理されます。パスワードの変更は、Oracle Directory Integration PlatformによってOracle Internet Directoryに同期化されません。 |
|
Oracle Application Server Single Sign-On |
ユーザーは、OracleAS Single Sign-On Serverを使用して、Oracle環境に1回のみログインします。 サード・パーティ・ディレクトリでのみ資格証明を持つユーザーは、外部認証プラグインを起動するOracleディレクトリ・サーバーによって認証されます。 Oracle Internet Directoryで資格証明を持つユーザーは、Oracleディレクトリ・サーバーによってローカルで認証されます。 |
|
サード・パーティ・ディレクトリ外部認証プラグイン |
サード・パーティ・ディレクトリでユーザーの資格証明を管理するときに、このプラグインが必要です。ユーザーを認証するために、OracleAS Single Sign-On ServerによりOracleディレクトリ・サーバーがコールされます。このプラグインによって、サード・パーティ・ディレクトリに格納されているユーザーの資格証明に対するユーザーの認証が実行されます。 |
サード・パーティ・ディレクトリに作成された新しいユーザーまたはグループは、Oracle Directory Integration Platformによって、Oracle Internet Directoryに自動的に同期化されます。プロビジョニングが実行される前に、サード・パーティ・ディレクトリとOracle Internet Directory間で一方向の同期が確立されている必要があります。
図16-4に、サード・パーティ・ディレクトリが企業の中央ディレクトリとなっている場合の通常のデプロイを示します。
図16-4が示すように、サード・パーティ・ディレクトリが企業の中央ディレクトリの場合、ユーザーまたはグループの通常のプロビジョニングは次のプロセスに従います。
ユーザー・エントリまたはグループ・エントリがサード・パーティ・ディレクトリ内に作成されます。
次にスケジュールされた間隔に、エントリ作成イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。
統合プロファイル内のマッピング情報に従って、サード・パーティ・ディレクトリのユーザー属性またはグループ属性がOracle Internet Directory内の対応する属性にマップされます。
ユーザー・エントリまたはグループ・エントリがOracle Internet Directory内に作成されます。
次の場合、サード・パーティ・ディレクトリ内でエントリが変更されます。
新しい属性がエントリに追加される場合。
既存の属性の値が変更される場合。
既存の属性が削除される場合。
サード・パーティ・ディレクトリが企業の中央ディレクトリの場合、ユーザー・エントリまたはグループ・エントリの変更は次のプロセスに従います。
サード・パーティ・ディレクトリ内でエントリが変更されます。
次にスケジュールされた間隔に、エントリ変更イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。
統合プロファイル内のマッピング情報に従って、サード・パーティ・ディレクトリ内の属性がOracle Internet Directory内の対応する属性に適切にマップされます。
Oracle Internet Directory内でユーザー・エントリまたはグループ・エントリが変更されます。
図16-4が示すように、サード・パーティ・ディレクトリが企業の中央ディレクトリの場合、パスワード・リポジトリとして動作しているディレクトリ内でパスワードの変更が非同期的に発生します。これは、プラグインを使用することによって発生します。
次の場合、LDAPスキーマをカスタマイズする必要があります。
ディレクトリのデプロイに、カスタム・オブジェクト・クラス、カスタム属性などのスキーマ拡張が含まれている場合
カスタム属性を、ディレクトリ・サーバー間で同期化する必要がある場合
LDAPスキーマをカスタマイズするには、次のことを行う必要があります。
ソース・ディレクトリでスキーマ拡張を識別します。
データの移行および同期を開始する前に、ターゲット・ディレクトリでスキーマ拡張を作成します。
|
注意: スキーマ拡張の作成に加えて、対応するオブジェクト・クラスと同期化させる属性も、マッピング・ルールに追加する必要があります。 |
|
関連項目:
|
企業の中央ディレクトリとなるディレクトリに関係なく、パスワードは、一方または両方のディレクトリに格納できます。いずれのオプションにも長所と短所があります。この項では2つのオプションを比較します。内容は次のとおりです。
1つのディレクトリにのみパスワードを格納すると、エントリ・ポイントの数を減らすことになるため、パスワードのセキュリティがより強力になります。また、パスワードが変更された場合の同期の問題もなくなります。
ただし、1つのディレクトリにのみパスワードを格納すると、ネットワーク全体に対するシングル・ポイント障害の原因となります。サード・パーティ・ディレクトリで障害が発生した場合、ユーザーは、Oracle Internet Directory内でユーザー・フットプリントが使用可能な場合でもOracleコンポーネントにアクセスできません。
中央ディレクトリにのみパスワードを格納すると同期の問題はなくなりますが、アプリケーションでユーザーをそのディレクトリに対して認証できるようにする必要があります。これには、適切なプラグインを使用する必要があります。たとえば、企業の中央ディレクトリおよび中央パスワード・ストアの両方としてMicrosoft Active Directoryを使用している場合は、Microsoft Active Directoryに対してユーザーを認証するアプリケーションを有効にする必要があります。これには、外部認証プラグインを使用します。
|
注意: Oracleコンポーネントは、パスワード検証を使用してユーザーを認証します。パスワードがサード・パーティ・ディレクトリに格納される場合、それらの検証はOracle Internet Directoryに格納されません。Oracleコンポーネントを使用してパスワードが変更された場合は、Oracle Internet Directory内で検証が生成され、格納されます。 |
Oracle Internet Directoryとサード・パーティ・ディレクトリの両方にパスワードを格納する場合、理想的には、リアルタイムでパスワードを同期化する必要があります。
Oracle Internet Directory 11gリリース1（11.1.1）の場合、パスワードはリアルタイムではなく、スケジュールに従って同期化されます。これは、企業の中央ディレクトリ内でパスワードが変更された時刻とその変更がもう1つのディレクトリに記録される時刻の間に、明確な差があることを意味します。
中央ディレクトリとしてOracle Internet Directoryをデプロイした場合、パスワード値は、Oracle Internet Directoryから接続ディレクトリへ定期的に同期化されます。これには、レルムのパスワード・ポリシーと可逆暗号化の両方を有効にする必要があります。
|
関連項目:
|
通常、パスワード値はハッシュされます。両方のディレクトリが同一のハッシング・アルゴリズムを使用する場合は、そのままの状態でハッシュ値を同期化できます。たとえば、Sun Java System Directory ServerとOracle Internet Directoryが統合されている環境があるとします。これらのディレクトリは両方とも共通のハッシング・アルゴリズムに対応しています。Oracle Internet Directoryでサポートされているハッシング方法を使用して、パスワードをハッシュし、Sun Java System Directory Serverに格納する場合、Sun Java System Directory ServerのパスワードのOracle Internet Directoryへの同期化は、その他の属性の場合と同様です。両方のディレクトリで同一のハッシング・アルゴリズムがサポートされていない場合は、クリアテキスト形式でのみパスワードを同期化する必要があります。セキュリティ上の理由から、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 Internet Directoryのデフォルトのインストール環境ではパスワードの同期化は実行できません。構成する必要があります。Oracle Internet Directoryが中央ディレクトリではないデプロイでは、サード・パーティ・ディレクトリによってパスワード・ポリシーが施行されます。サード・パーティ・ディレクトリに対する認証リクエストがある場合、このディレクトリから認証が成功したか失敗したかの応答があります。ただし、サード・パーティ・ディレクトリからのパスワード・ポリシーの詳細なエラーは、Oracle Internet Directoryに配信されないため、クライアント・アプリケーションにも配信されません。 |
|
関連項目: プラグインの詳細は、次の章を参照してください。
|
インストール時に、各ディレクトリ・サーバーがデフォルトのドメインとデフォルトのディレクトリ情報ツリー（DIT）構造を作成します。Oracle Internet Directoryインフラストラクチャのインストールにより、企業内のユーザーおよびグループの格納用に指定されたコンテナで、デフォルトのレルムが作成されます。サード・パーティ・ディレクトリと統合する場合は、Oracle Internet Directoryのデフォルトのインストールを使用するために、両方のディレクトリで同一のDIT構造を作成する必要があります。または、ドメイン・レベルのマッピングを実行できます。
この項の内容は次のとおりです。
両方のディレクトリ上で同一のディレクトリ情報ツリーを構成することをお薦めします。これによって、すべてのユーザー・オブジェクトとグループ・オブジェクトをそのままの状態で同期化できるため、一方のディレクトリ内の識別名を持つエントリを別のディレクトリのURLにマップする必要がなくなります。また、このようなマッピングで発生する可能性があるパフォーマンスの問題も回避できます。
同一のディレクトリ情報ツリーを作成するには、まず、企業の中央ディレクトリとなるディレクトリを決定し、その後、それにあわせてもう一方のディレクトリ情報ツリーを変更します。ディレクトリ統合プロファイルを更新して、確実にドメイン・レベルのルールを反映してください。
ユーザーがOracle Application Server Single Sign-Onを介してOracleアプリケーションにアクセスできるようにするには、ディレクトリ情報ツリーを、独自の認証および認可ドメインを持つ個別のアイデンティティ管理レルムとして識別することをお薦めします。
|
関連項目: 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のアイデンティティ管理レルムのデプロイに関する章 |
両方のディレクトリ上に同一のディレクトリ情報ツリーを持つことが不可能な場合は、Oracle Internet Directoryと接続ディレクトリの間でドメインをマップする必要があります。たとえば、コンテナdc=mydir,dc=comの下にあるエントリはすべて、Oracle Internet Directory内のdc=myoid,dc=comの下で同期化する必要があります。これを実行するには、ドメイン・レベルのマッピング・ルールに指定します。
すべてのユーザーおよびグループの同期が目的の場合は、適切な識別名マッピングですべてのユーザー・エントリを同期化できます。ただし、グループ・エントリを同期化する場合は、時間がかかり、制限が追加される場合があります。この項では、識別名マッピングが行われている場合のユーザーおよびグループ両方の同期の例を示します。
マッピング・ファイルでは、Sun Java System Directory Server内のエントリはuid=name,ou=people,o=iplanet.orgという形式をとるとします。また、Oracle Internet Directory内のエントリは、cn=name,cn=users,dc=iplanet,dc=comという形式をとるとします。Sun Java System Directory Server上のネーミング属性は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という値は、各変更がSun Java System Directory Serverから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またはその他の識別名タイプの属性に対して識別名マッピングを行うことはできません。
グループ・メンバーシップを同期化する場合は、ソース・ディレクトリと宛先ディレクトリに同じネーミング属性を指定してください。
ログイン名の属性には、Oracleコンポーネントにログインする際のエンド・ユーザーのアイデンティティが含まれます。この属性は、Oracle Internet Directoryのコンテナcn=common,cn=products,cn=oracleContext,identity_management_realmの下に、属性orclcommonnicknameattributeの値として格納されます。
デフォルトでは、orclcommonnicknameattribute属性の値はuidです。これは、ログインに使用されるアイデンティティがユーザー・エントリのuid属性に格納されることを意味します。
接続ディレクトリにログイン用の特定の属性が存在する場合は、Oracle Internet Directory内の正しいorclcommonnicknameattributeにその属性をマップする必要があります。これは、サード・パーティ・ディレクトリとの同期に関連付けられているコネクタ用のマッピング・ファイルにある、マッピング・ルールの1つであることが必要です。
たとえば、Oracle Internet DirectoryをMicrosoft Active Directoryと同期させるとします。また、後者では、ログイン識別子がユーザー・エントリのuserPrincipalName属性に含まれているとします。userPrincipalName属性の値をOracle Internet Directoryに同期させ、orclcommonnicknameattribute属性の値であるuid属性に格納します。このマッピングは、ディレクトリ統合プロファイル内のマッピング・ルールに反映する必要があります。
ログイン識別子用のその他の属性も使用できます。たとえば、ログインにemployeeIDを使用する場合は、それに応じてマッピング・ルールを設定できます。この設定は、構成には影響しません。
|
注意: orclcommonnicknameattribute属性はOracle Application Server Single Sign-Onで広範囲に使用されるため、この属性をサード・パーティ・ディレクトリの属性にどのようにマップするかを慎重に計画してください。この属性を変更した場合は、変更を有効にするために、Oracle Application Server Single Sign-Onをリフレッシュする必要があります。 |
|
関連項目: ログイン名の属性の設定手順は、『Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management』を参照してください。 |
ユーザー検索コンテキストは、ユーザーが存在するすべてのコンテナをリストする複数値属性によって表されます。デプロイに応じて、ユーザー集団全体にわたるユーザー検索コンテキスト値を設定するか、Oracle Internet Directoryセルフ・サービス・コンソールを使用してユーザー検索コンテキスト属性にコンテナを追加します。
|
関連項目: ユーザー検索コンテキストの設定手順は、『Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management』を参照してください。 |
グループ検索コンテキストは、グループが存在するすべてのコンテナをリストする複数値属性によって表されます。デプロイに応じて、すべてのグループ・エントリにわたるグループ検索コンテキスト値を設定するか、Oracle Internet Directoryセルフ・サービス・コンソールを使用してグループ検索コンテキスト属性にコンテナを追加します。
|
関連項目: グループ検索コンテキストの設定手順は、『Oracle Fusion Middleware Guide to Delegated Administration for Oracle Identity Management』を参照してください。 |
セキュリティ上の3つの主要な問題を考慮する必要があります。
アクセス・ポリシー: ユーザー検索ベースとグループ検索ベースを不正なユーザーによるアクセスから適切に保護する必要があります。
同期: Oracle Internet Directoryおよびサード・パーティのディレクトリに接続するときにSSLを使用するようにOracle Directory Integration Platformを構成できます。これを実行すると、ディレクトリ・サーバー間で交換されるすべての情報が保護されます。
パスワードの同期化: 構成に応じて、パスワードを同期化できます。たとえば、Oracle Internet Directoryが企業の中央ディレクトリの場合は、パスワードの変更を接続ディレクトリに通信できます。パスワードを同期化する場合は、ディレクトリ間の通信をSSLサーバー認証モードで構成することをお薦めします。
この項では、Oracle Internet DirectoryとMicrosoft Active Directoryとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
Microsoft Active DirectoryからOracle Internet Directoryへ変更を同期化するために、Oracle Directory Integration Platformでは、Microsoft Active Directory変更追跡メカニズムで使用可能になる増分変更をインポートします。Oracle Directory Integration Platformでは、次の2つのMicrosoft Active Directory変更追跡メカニズムをサポートします。
いずれの方式でも、変更が導出されるディレクトリに対して、Microsoft Active Directoryコネクタによりスケジュールされた間隔で問合せが行われます。各方式には、長所と短所があります。表16-3に、これら2つの方式の相違点を示します。
表16-3 DirSync方式とUSN-Changed方式の比較
| 考慮事項 | DirSync方式 | USN-Changed方式 |
|---|---|---|
|
キーの変更 |
エントリの一意の識別子である |
識別名に変更を渡します。 |
|
エラー処理 |
エラー状態の結果、同期が停止した場合、次のサイクル中に、適用済の変更がすべて読み取られ、スキップされます。 |
同期が原子性を持つ必要はありません。同期が停止した場合、同期が中断されたエントリから、次の同期サイクルが開始します。 |
|
検索結果の情報 |
変更は、変更された属性と新しい値のみです。このためUSN-Changed方式より速くなる可能性があります。 |
変更エントリのすべての属性が取得されます。取得された値は、Oracle Internet Directoryに格納されている古い値と比較され、更新されます。このためDirSync方式より時間がかかる可能性があります。 |
|
複数値の属性の変更 |
複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。 |
複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。 |
|
同期点の追跡方法 |
ディレクトリ内の変更を問い合せたときに、ディレクトリの状態を識別するCookie値に基づく増分変更が渡されます。 |
|
|
必須のユーザー権限 |
ユーザーは、対象となるネーミング・コンテキストに対する変更のレプリケート権限が必要です。これにより、Microsoft Active Directory内のすべてのオブジェクトおよび属性を、それらに対するアクセス保護に関係なく、読み取ることができます。 関連項目: DirSync方式の使用時にMicrosoft Active Directoryユーザーに権限を割り当てる方法は、Microsoft Knowledge Base Article 303972（ |
Microsoft Active Directoryユーザーには、Oracle Internet Directoryに対して同期化するすべての必須属性を読み取る権限が必要です。 関連項目: USN-Changed方式の使用時に、Microsoft Active Directoryユーザーに権限を割り当てる方法は、Microsoftライブラリ（ |
|
複数ドメインのサポート |
異なるドメイン内のエントリに加えられた変更を読み取るには、異なるドメイン・コントローラへの個々の接続が必要です。 |
グローバル カタログ サーバーに接続することで、複数のドメインに加えられた変更を取得できます。 |
|
異なるMicrosoft Active Directoryドメイン・コントローラへの切替え時のレプリケートされたディレクトリからの同期 |
同期は続行可能です。レプリケートされた環境に接続するときも同期キーは同じです。 |
次のことが必要です。
関連項目: 「同一ドメイン内の異なるMicrosoft Active Directoryドメイン・コントローラへの切替え」 |
|
同期の有効範囲 |
ディレクトリ内のすべての変更を読み取り、必須エントリへの変更のみをOracle Internet Directoryに伝播します。 |
特定のサブツリーで変更の同期を有効にします。 |
|
ロード・バランサの背後に複数のMicrosoft Active Directory Serverを配置した環境の可用性 |
- |
特定のMicrosoft Active Directoryドメイン・コントローラに接続するか、グローバル カタログに接続します。次の場合にグローバル カタログに接続します。
|
WebDAVプロトコルを使用する場合は、アプリケーションをSSL用に構成する必要があります。Oracle Internet Directoryがエンド・ユーザーを認証する唯一の方法は、検証用プレーン・テキスト・パスワードをActive Directoryに渡すことです。そのため、Basic認証が必要になります。Basic認証が存在しない場合は、Digest認証が使用されます。しかし、Digest認証では、Active Directoryに渡す検証用プレーン・テキスト・パスワードがないため、Oracle Internet Directoryはエンド・ユーザーを認証できません。Secure Sockets Layer（SSL）なしでは、HTTP経由でのBasic認証はサポートされません。これは、エンド・ユーザーとサーバー間の通信チャネルが暗号化されず、同じくエンド・ユーザーのパスワードも暗号化されずに送信されるためです。
この項では、Windowsネイティブ認証をOracle Directory Integration Platformとともに使用する方法について説明します。内容は次のとおりです。
Windowsネイティブ認証は、Microsoft WindowsでのMicrosoft Internet Explorerユーザーの認証方法です。この機能がOracleAS Single Sign-On Serverで有効な場合、ユーザーはOracleAS Single Sign-On Serverのパートナ・アプリケーションに自動的にログインします。このためにユーザーは、Windowsのドメインへのログイン時に取得したKerberos資格証明を使用します。
Internet Explorerバージョン5.0以上では、Simple and Protected GSS-API Negotiation Mechanism（SPNEGO）プロトコルを使用して、ユーザーのKerberos資格証明をリクエスト先のKerberos対応のWebサーバーに自動的に渡すことができます。これにより、Webサーバーは資格証明を復号化してそのユーザーを認証できます。
Microsoft統合セキュリティやその他のタイプのセキュリティ・メカニズムは、Oracle Application Server Single Sign-OnをWindowsネイティブ認証と統合する際に使用できません。SPNEGOプロトコルは、Kerberosバージョン5とNT Lan Manager（NTLM）の両方の認証スキームをサポートしますが、Oracle Application Server 11gリリース1（11.1.1）では、SPNEGO使用のKerberos V5のみをサポートします。
|
注意: この章ではWindows 2000についてのみ説明しますが、Windows XPプラットフォームもWindowsネイティブ認証をサポートしています。ブラウザがInternet Explorer 5.0以上でない場合、Oracle Identity Managementでは、OracleAS Single Sign-On Serverを使用してユーザー認証を行います。外部ディレクトリに対する認証は、外部認証プラグインを使用して行われます。 |
次の手順は、シングル・サインオンで保護されたアプリケーションにユーザーがアクセスするときのプロセスを示しています（図16-5を参照）。
ユーザーはWindowsコンピュータでKerberosレルム（ドメイン）にログインします。
ユーザーは、Internet Explorerを使用してSingle Sign-Onパートナ・アプリケーションへのアクセスを試みます。
アプリケーションは、ユーザーを認証するためにSingle Sign-On Serverにルーティングします。このルーティングの一環として、次の動作が行われます。
ブラウザは、Key Distribution Center（KDC）からKerberosセッション・チケットを取得します。
OracleAS Single Sign-On Serverでは、Kerberosセッション・チケットを検証し、ユーザーは、認可されると、リクエストしたURLへのアクセスを許可されます。
このアプリケーションによって、ユーザーの必要とするコンテンツが表示されます。
ユーザーがWindowsセッションからログアウトすると、このアプリケーションとアクセスされたすべてのシングル・サインオン・アプリケーションからも、同時にログアウトします。
Microsoft Active Directoryが中央ディレクトリであるデプロイでWindowsネイティブ認証を使用するには、ユーザーはMicrosoft Active Directory内に存在する必要があります。Windowsネイティブ認証が有効な場合、ローカルのOracle Internet Directoryユーザーがシングル・サインオン・サーバーを起動するには、ユーザー・エントリごとにorclsamaccountname属性とkrbprincipalname属性を移入する必要があります。
1つのフォレストに属する複数のMicrosoft Active Directoryドメインに対してユーザーを認証するには、グローバル カタログを作成し、認証のためにOracle Application Server Single Sign-Onをそのグローバル カタログに接続します。しかし、ドメインが同じフォレストに属さない場合は、ドメイン間でドメイン信頼を作成する必要があります。構成手順の詳細は、「Windowsネイティブ認証の構成」を参照してください。
Windowsネイティブ認証は、アプリケーションの既存の認証メカニズムを自動的に上書きしません。Windowsネイティブ認証とOracle Application Server Single Sign-Onを内部認証メカニズムを含むアプリケーションで使用するには、次のタスクのいずれかを実行する必要があります。
アプリケーションの内部認証メカニズムを削除する。
アプリケーションをOracle Application Server Single Sign-Onの外部アプリケーションとして構成する。この作業には、有効なアプリケーション・ユーザーの名前とパスワードをアプリケーション構成に格納し、ユーザーがOracle Application Server Single Sign-Onを使用してログインした後に、認証プロセスをユーザーに対して透過的にする必要があります。詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On』を参照してください。
表16-4に、Microsoft Active Directoryからインポートされるユーザー用のOracle Internet Directoryスキーマ要素を示します。
表16-4 Microsoft Active Directory用のOracle Internet Directoryスキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Microsoft Active DirectoryからOracle Internet Directoryに移行されたユーザーおよびグループに対するMicrosoft Active Directoryの |
|
|
Microsoft Active DirectoryからOracle Internet Directoryに移行されたユーザーおよびグループに対するMicrosoft Active Directoryの |
|
|
Microsoft Active Directoryの |
|
|
Microsoft Active DirectoryユーザーのKerberosユーザー・プリンシパル名を格納します。 |
|
|
Microsoft Active Directoryのグループ属性を格納します。これらのグループ属性は、Oracle Directory Integration環境におけるMicrosoft Active Directoryのグループ・オブジェクトとOracle Internet Directoryのグループ・オブジェクトの同期に使用されます。 |
|
|
Microsoft Active Directoryのユーザー属性を格納します。これらのユーザー属性は、Oracle Directory Integration and Provisioning環境におけるMicrosoft Active Directoryのユーザー・オブジェクトとOracle Internet Directoryのユーザー・オブジェクトの同期に使用されます。 |
|
|
Microsoft Active Directoryの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
関連項目: Microsoft Active Directory用のOracle Internet Directoryスキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。 |
複数のドメインを持つMicrosoft Active Directoryのデプロイでは、単一のDITにすることも、複数のDITを組み合せることもできます。Microsoft Active Directoryでは、DITのグループをフォレストと呼びます。図16-6に、Microsoft Active DirectoryのフォレストがOracle Internet Directoryにどのように反映されるかを示します。
このディレクトリでは、2つのドメイン・ツリーが1つのフォレストを構成しています。これらのツリーは信頼関係にあります。つまり、一方のドメインのユーザーは、他方のドメインのドメイン・コントローラにより認証されます。Microsoft Active Directoryのこのフォレストは、Oracle Internet Directory内の同一構造のサブツリーにマップされます。
Oracle Internet Directoryが中央ディレクトリであるデプロイの考慮事項
複数のMicrosoft Active Directoryドメインが存在する場合は、Microsoft Active Directoryドメインの数と同じ回数だけ、syncProfileBootstrapコマンドを実行する必要があります。これを実行するたびに、ターゲットのMicrosoft Active Directory Serverで必要な特定のデータ・セットを選択します。
Oracle Directory Integration Platformによって、それぞれのMicrosoft Active Directoryドメイン内のユーザーおよびグループがプロビジョニングされます。プロビジョニングが行われるには、Oracle Internet DirectoryからMicrosoft Active Directoryドメインへの一方向の同期を構成する必要があります。
Microsoft Active Directoryが中央ディレクトリであるデプロイの考慮事項
複数のMicrosoft Active Directoryサーバーがある場合、Microsoft Active Directoryの各ドメインからデータをブートストラップする必要があります。Microsoft Active DirectoryからOracle Internet Directoryへの一方向の同期にグローバル カタログを使用する場合は、グローバル カタログ サーバーから1回のみブートストラップする必要があります。
Oracle Directory Integration Platformによって、それぞれのMicrosoft Active DirectoryドメインからOracle Internet Directoryにユーザーおよびグループが同期化されます。プロビジョニングが実行される前に、Oracle Internet Directoryと各Microsoft Active Directoryドメインのドメイン・コントローラ間で一方向の同期が確立されている必要があります。
この項では、複数ドメインMicrosoft Active Directory環境との同期化の考慮事項について説明します。内容は次のとおりです。
Microsoft Active DirectoryからOracle Internet Directoryへのインポートに必要な構成
Microsoft Active Directory Lightweight Directory ServiceからOracle Internet Directoryへのインポートに必要な構成
Oracle Internet DirectoryからMicrosoft Active Directoryへのエクスポートに必要な構成
通常、インポートを行うには、DirSync方式またはUSN-Changed方式のいずれを使用しているかに関係なく、Microsoft Active Directoryドメインごとに1つインポート・プロファイルを構成する必要があります。ただし、USN-Changed方式を使用している場合は、グローバル カタログを使用すれば、Microsoft Active Directoryフォレスト全体からインポートできます。グローバル カタログを使用するにはインポート・プロファイルを1つ構成するだけですが、次の考慮事項に注意してください。
グローバル カタログは読取り専用であるため、Oracle Internet Directoryにデータをインポートする場合にのみ使用できます。
グローバル カタログにはすべての属性は含まれていませんが、使用可能な属性はMicrosoft Active Directoryで構成できます。
グローバル カタログは認証のポイントであるため、このポイントから同期が開始されると追加のオーバーヘッドが発生する可能性があります。
|
関連項目: Microsoft Active Directoryスキーマ内のグローバル カタログの属性の詳細は、Microsoft Help and Support（http://support.microsoft.com/）にあるMicrosoft Knowledge Base Article 256938を参照してください。 |
Microsoft Active Directoryと異なり、Microsoft Active Directory Lightweight Directory Service（AD LDS: 旧称Active Directory Application Mode（ADAM））からOracle Internet Directoryへの同期にはUSN-Changed方式のみが使用されます。Microsoft AD LDSからOracle Internet Directoryにエントリをインポートするには、Microsoft AD LDSに接続するインポート・プロファイルを、それぞれのポート詳細を使用して構成する必要があります。
複数ドメインMicrosoft Active Directory環境と統合するために、Oracle Directory Integration Platformでは、各Microsoft Active Directoryドメインから構成情報を取得します。Microsoft Active Directoryドメインの数と同数のエクスポート・プロファイルを構成する必要があります。
複数のドメインを持つサード・パーティ・ディレクトリのデプロイでは、単一のDITにすることも、複数のDITを組み合せることもできます。図16-7に、サード・パーティ・ディレクトリの複数のドメインがどのようにOracle Internet DirectoryのDITにマップされるかを示します。
図16-7では、サード・パーティ・ディレクトリ環境に1つの親ドメインと2つの子ドメインがあります。
最初の子ドメインa.us.MyCompany.comは、Oracle Internet Directoryのdc=a,dc=us,dc=MyCompany,dc=comにマップされます。2番目の子ドメインb.us.MyCompany.comは、Oracle Internet Directoryのdc=b,dc=us,dc=MyCompany,dc=comにマップされます。サード・パーティ・ディレクトリ環境の共通ドメイン・コンポーネントus.MyCompany.comは、Oracle Internet Directoryのデフォルトのアイデンティティ管理レルム、この場合はdc=us,MyCompany,dc=comにマップされます。
Microsoft Active Directoryのユーザーやコンピュータ・アカウントは、コンピュータや人などの物理エンティティを表します。ユーザー・アカウントおよびコンピュータ・アカウントは、グループと同様に、セキュリティ・プリンシパルと呼ばれます。セキュリティ・プリンシパルは、自動的にセキュリティ識別子を割り当てられるディレクトリ・オブジェクトです。セキュリティ識別子を持つオブジェクトは、ネットワークにログインし、ドメイン・リソースにアクセスできます。ユーザー・アカウントまたはコンピュータ・アカウントは、次のことに使用されます。
ユーザーまたはコンピュータのアイデンティティの認証
ドメイン・リソースへのアクセス権の認可または否認
他のセキュリティ・プリンシパルの管理
ユーザー・アカウントまたはコンピュータ・アカウントを使用して実行されるアクションの監査
たとえば、エンタープライズ管理者グループのメンバーであるユーザー・アカウントまたはコンピュータ・アカウントは、フォレスト内のすべてのドメイン・コントローラで、ログインの許可を自動的に付与されます。
ユーザー・アカウントおよびコンピュータ・アカウントは、Microsoft Active Directory Users and Computersを使用して、追加、無効化、リセットおよび削除されます。
Microsoft Active Directoryの信頼関係では、あるドメインのユーザーは、別のドメインのドメイン・コントローラにより認証されます。信頼関係は、推移的にも非推移的にもなります。
推移的な信頼関係では、あるドメインに拡張された信頼関係は、そのドメインを信頼する他のすべてのドメインに自動的に拡張されます。たとえば、A、B、Cの3つのドメインがあり、BとCはAと直接の信頼関係にあるとします。この場合、BとCの間にも信頼関係が生じます。これは、BとCの間には直接の信頼関係はありませんが、どちらもAと直接の信頼関係にあるためです。
あるフォレストのWindows 2000ドメインと、そのフォレスト外のWindows 2000ドメインの間に信頼関係が確立されている場合、外部ドメインからのセキュリティ・プリンシパルは、フォレスト内のリソースへのアクセス権を付与されます。外部ドメインからのセキュリティ・プリンシパルは、外部セキュリティ・プリンシパルと呼ばれ、Microsoft Active Directoryでは外部セキュリティ・プリンシパル・オブジェクトとして表されます。これらの外部セキュリティ・プリンシパルは、フォレスト外のドメインからメンバーを受け入れるドメイン・ローカル・グループのメンバーになることができます。
外部セキュリティ・プリンシパルは、Microsoft Active Directory環境の2つのドメイン間に非推移的な信頼関係がある場合に使用されます。
Microsoft Active Directory環境の非推移的な信頼関係では、あるドメインが別のドメインからの外部セキュリティ・プリンシパルを認識すると、そのエンティティは識別名エントリのように表されます。そのエントリでは、RDNコンポーネントは、信頼関係のドメインにおける元のエントリのSIDに設定されます。グループの場合は、外部セキュリティ・プリンシパルの識別名が、信頼関係のドメインにおける元のエントリの識別名としてではなく、メンバーの値として表されます。このため、外部セキュリティ・プリンシパルがOracle Internet Directoryと同期化されるときに問題が発生する可能性があります。
この項では、Oracle Internet DirectoryとSun Java System Directory Serverとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
Sun Java System Directory ServerからOracle Directory Integration Platformへの同期
Sun Java System Directory Server用のOracle Internet Directoryスキーマ要素
Sun Java System Directory Serverは、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。Sun Java System Directory ServerからOracle Internet Directoryへの同期は、この変更ログを活用します。
|
関連項目:
|
この項では、Oracle Internet DirectoryとIBM Tivoli Directory Serverとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
IBM Tivoli Directory Serverは、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。IBM Tivoli Directory ServerからOracle Internet Directoryへの同期は、この変更ログを活用します。
|
注意: IBM Tivoli Directory Serverバージョン6.2では、tombstoneがサポートされています。 |
表16-5に、IBM Tivoli Directory Serverからインポートされるユーザー用のOracle Internet Directoryスキーマ要素を示します。
表16-5 IBM Tivoli Directory Server用のOracle Internet Directoryスキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Tivoliの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
IBM Tivoliの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。 |
|
|
Tivoliディレクトリ・オブジェクトを表します。 |
|
関連項目:
|
この項では、Oracle Internet DirectoryとNovell eDirectoryまたはOpenLDAPとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
Novell eDirectoryまたはOpenLDAPからOracle Internet Directoryへ変更を同期化するために、Oracle Directory Integration Platformでは、Novell eDirectoryまたはOpenLDAPの各エントリの変更タイムスタンプを評価します。最後の同期の実行時間よりも新しいタイムスタンプを持つエントリがOracle Internet Directoryで更新されます。
Novell eDirectoryまたはOpenLDAPで削除されたエントリについて、Oracle Directory Integration Platformでは、Oracle Internet DirectoryのエントリとNovell eDirectoryまたはOpenLDAPとの間で線形比較して削除済エントリを識別します。つまり、両方のディレクトリのエントリが指定された間隔で比較されます。Oracle Internet DirectoryとNovell eDirectoryまたはOpenLDAPの両方で使用できないエントリは削除されます。ディレクトリ・エントリが比較される際にサーバーでのパフォーマンスの低下を回避するために、DITの特定のサブセットを検索するように比較をカスタマイズできます。
|
関連項目:
|
表16-6に、Novell eDirectoryからインポートされるユーザー用のOracle Internet Directoryスキーマ要素を示します。
表16-6 Novell eDirectory用のOracle Internet Directoryスキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Novell eDirectoryの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
調整に必須。Novell eDirectoryの各エントリに対するGUID値を表します。この値は、同期キーとして使用されます。 |
|
|
必須。Novell eDirectoryの各エントリの |
|
|
必須。Novell eDirectoryの各エントリの |
|
|
Novell eDirectoryのNDSオブジェクトを表します。 |
|
関連項目: Novell eDirectory用のOracle Internet Directoryスキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。 |
表16-7に、OpenLDAPからインポートされるユーザー用のOracle Internet Directoryスキーマ要素を示します。
表16-7 OpenLDAP用のOracle Internet Directoryスキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
OpenLDAPの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
調整に必須。OpenLDAPの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。 |
|
|
必須。OpenLDAPの各エントリの |
|
|
必須。OpenLDAPの各エントリの |
|
|
OpenLDAPオブジェクトを表します。 |
|
関連項目: OpenLDAP用のOracle Internet Directoryスキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。 |
Oracle Directory Integration Platform 11gリリース1（11.1.1）では、スキーマおよびACLの同期はサポートされません。schemasyncツールを使用して、Oracle Internet Directoryと接続ディレクトリの間で、スキーマの違い、特に属性とオブジェクト・クラスの違いを確認できます。違いを確認した後、schemasyncツールを使用して、スキーマを同期することができます。
|
関連項目: schemasyncツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。 |
