| Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド 11g リリース1(11.1.1) B65032-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド 11g リリース1(11.1.1) B65032-02 |
|
前 |
次 |
この章では、Oracle Identity Managementと接続ディレクトリとの統合の基本概念と、統合プロセスの一環として行う様々な決定について説明します。
|
注意: この章を読む前に、次の資料の内容を理解しておく必要があります。
|
この章は、次の項目を含みます。
Oracle Directory Server Enterprise Edition(Sun Java System Directory Server)統合の概念
Oracle Directory Integration Platform 11gリリース1(11.1.1)での接続ディレクトリ統合の制限事項
|
関連項目: 接続ディレクトリとの同期に関する特定の実装の詳細は、次の各章を参照してください。 |
すべてのOracleコンポーネントは、Oracle Identity Managementと統合することによって、セキュリティが集中管理されます。環境内でOracleバックエンド・ディレクトリとその他のディレクトリ(Microsoft Active Directoryなど)の両方を使用する場合、コネクタを使用して2つのシステムを統合し、それらのデータを同期化できます。コネクタとは、あらかじめパッケージされた接続ソリューションで、これを使用するとOracleバックエンド・ディレクトリを接続ディレクトリと同期化できます。
この項では、Oracle Identity Managementと接続ディレクトリの統合に必要なOracleコンポーネントとアーキテクチャについて説明します。内容は次のとおりです。
|
注意: 各Oracleバックエンド・ディレクトリ(Oracle Internet Directory、Oracle Unified DirectoryおよびOracle Directory Server Enterprise Edition)との統合に関して保証されているディレクトリおよびサーバーの詳細は、「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バックエンド・ディレクトリ
Oracleバックエンド・ディレクトリはOracleコンポーネントとサード・パーティ・アプリケーションがユーザー・アイデンティティおよび資格証明を格納してアクセスするリポジトリです。Oracleディレクトリ・サーバーを使用し、ユーザーが入力した資格証明をOracleバックエンド・ディレクトリに格納されている資格証明と比較してユーザーを認証します。資格証明がOracleバックエンド・ディレクトリではなく接続ディレクトリに格納されている場合でも、Oracle Internet DirectoryがOracleバックエンド・ディレクトリである場合は、ユーザーは認証されます。この場合、Oracle Internet Directoryは、接続ディレクトリ・サーバーに対してユーザーを認証する外部認証プラグインを使用します。(Oracle Unified DirectoryまたはOracle Directory Server Enterprise EditionがOracleバックエンド・ディレクトリである場合は、外部認証プラグインは使用できません。)
|
関連項目: Oracle Internet DirectoryがOracleバックエンド・ディレクトリである場合、セキュリティの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のセキュリティに関する章を参照してください。 |
Oracle Directory Integration Platform
Oracle Directory Integration Platformは、Oracle Identity Managementの一部としてインストールされます。これをOracleバックエンド・ディレクトリと同じホストで実行するようにも、異なるホストで実行するようにも構成できます。
Oracle Directory Integration Platformでは、次の処理が可能です。
Oracleバックエンド・ディレクトリ(Oracle Internet Directory、Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionのいずれか)とその他の接続ディレクトリおよびユーザー・リポジトリとの間の同期化。
Oracle Internet DirectoryがOracleバックエンド・ディレクトリである場合のOracleコンポーネント用自動プロビジョニング・サービス。
Oracle Directory Integration Platformには、Oracleバックエンド・ディレクトリを他のLDAPディレクトリまたはデータ・ストアと同期化するためのコネクタが含まれています。Oracle Directory Integration Platform統合コネクタを使用すると、次のことができます。
接続ディレクトリとの一方向または双方向いずれかの同期を構成します。
|
注意: 双方向のパスワードの同期は、バックエンド・ディレクトリがOracle Internet Directoryである場合にのみサポートされます。Oracle Directory Integration Platformでは、Oracle Unified Directoryバックエンド・ディレクトリまたはOracle Directory Server Enterprise Editionバックエンド・ディレクトリから接続ディレクトリへのパスワードの同期はサポートされません。接続ディレクトリからOracle Unified Directoryバックエンド・ディレクトリまたはOracle Directory Server Enterprise Editionバックエンド・ディレクトリのいずれかへの一方向のパスワードの同期はサポートされます。 |
同期化属性の特定のサブセットの指定これを行うには、適切なマッピング・ルールを構成します(実行時に変更可能)。
Oracle Delegated Administration Services
Oracle Delegated Administration Servicesは、事前定義済みのWebベース・ユニットで、ユーザーのかわりにディレクトリ操作を実行します。他の管理者およびエンド・ユーザーに特定の機能を委任することができるため、ディレクトリ管理者はディレクトリ管理のルーチン・タスクをあまり実行する必要がありません。ユーザー・エントリの作成、グループ・エントリの作成、エントリの検索、ユーザー・パスワードの変更など、ディレクトリ対応アプリケーションで必要なほとんどの機能が提供されます。ディレクトリでアプリケーション・データを管理するには、Oracle Internet Directoryセルフ・サービス・コンソール(Oracle Delegated Administration Servicesに基づくツール)を使用します。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コンポーネントにアクセスできます。
|
注意: OracleAS Single Sign-On Serverを使用するには、バックエンド・ディレクトリがOracle Internet Directoryである必要があります。Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionのいずれかがバックエンド・ディレクトリである場合、シングル・サインオンはサポートされません。 |
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 Enterprise Single Sign-On Suite Plus管理者ガイドを参照してください。 |
外部認証プラグイン(Microsoft Active Directory外部認証プラグインなど)は、Oracle Internet Directoryで使用でき、これを使用すると、ユーザーはMicrosoft Windows資格証明を使用してOracle環境にログインできます。(Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionでは、外部認証プラグインは使用できません。)外部認証プラグインがインストールされていれば、Oracleディレクトリ・サーバーにより起動されます。このプラグインにより、接続ディレクトリでユーザーの資格証明が検証されます。検証が正常に実行された場合は、Oracleディレクトリ・サーバーからOracleAS Single Sign-On Serverに通知されます。
Oracleバックエンド・ディレクトリには、接続ディレクトリ(Microsoft Active Directoryなど)に固有の属性に対応するスキーマ要素が含まれています。スキーマ要素は、Oracle Directory Integration Platformにより接続ディレクトリと同期化されるバックエンド・ディレクトリ・オブジェクトを識別します。
この章の次の各項では、これらのスキーマ要素について説明します。
この項の内容は次のとおりです。
|
関連項目:
|
Oracle Internet Directoryでは、アイデンティティ管理レルムは、あるアイデンティティ管理ポリシーがデプロイにより定義され、施行される企業内での範囲を定義します。
アイデンティティ管理レルムは、次のもので構成されます。
有効範囲の定義されたエンタープライズ・アイデンティティの集合(USドメインのすべての従業員など)。
これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合。アイデンティティ管理ポリシーの例としては、すべてのユーザー・パスワードに少なくとも1文字の英数字を含む必要があることなどがあります。
グループの集合。すなわち、アイデンティティ管理ポリシーの設定を簡単にするアイデンティティの集合です。
同じOracle Identity Managementインフラストラクチャ内で複数のアイデンティティ管理レルムを定義できます。したがって、ユーザーの集団を区別し、各レルムで異なるアイデンティティ管理ポリシー(パスワード・ポリシー、ネーミング・ポリシー、自己変更ポリシーなど)を施行できます。これは、Oracle Fusion Middlewareのホスティングされたデプロイで役立ちます。
各アイデンティティ管理レルムには一意に名前が付けられ、他のレルムと区別されます。また、レルムを完全に管理するレルム固有の管理者がいます。
機能するすべてのOracleコンポーネントに対して、アイデンティティ管理レルムが必要です。Oracle Internet Directoryのインストール時に作成される1つの特別なレルムを、デフォルト・アイデンティティ管理レルムといいます。レルムの名前が指定されていない場合に、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サブツリーに表示されます。
この例では、1対1のドメイン・マッピングを使用して接続ディレクトリからOracle Internet Directoryに同期化する必要があるのは、usersサブツリーのみです。
|
注意: 図では、2つのディレクトリのトポロジは同じですが、これは単なる例であることに注意してください。2つのディレクトリは、同じドメインに存在する必要はありません。Oracle Internet Directoryは、接続ディレクトリに接続できる場所である場合、ネットワーク内のどこにでも配置できます。さらに、例では同期が接続ディレクトリからOracle Internet Directoryへの一方向ですが、かわりに同期を双方向に行うこともできます。 |
この項では、統合環境の計画方法について説明します。内容は次のとおりです。
LDAPディレクトリ・サーバーをすでに所有している企業にOracleバックエンド・ディレクトリをデプロイする場合は、両方のディレクトリが同じ環境に共存するように構成する必要があります。
ディレクトリの共存には、次のいずれかのデプロイが必要です。
Oracleバックエンド・ディレクトリとの単純な同期。使用する環境において、データベース・サーバーを使用してエンタープライズ・ユーザーがサポートされている場合は、この方法を使用します。Oracle Internet 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インフラストラクチャとの完全な統合には、そのレルムのコンテナについていくつか決定を行う必要があります。これらの事項を決定した後、ディレクトリ間でブートストラップおよび同期を構成できます。
この項では、企業の中央ディレクトリまたはメタディレクトリとなるディレクトリの選択方法について説明します。内容は次のとおりです。
Oracle Internet Directoryが中央ディレクトリの場合、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトを作成すると、Oracle Internet DirectoryはすべてのOracleコンポーネントおよび接続ディレクトリに関するプロビジョニング情報のソースになります。その後、企業全体のユーザー・オブジェクトとグループ・オブジェクトが、各種Oracleコンポーネントおよび接続ディレクトリ内にOracle Internet Directoryからプロビジョニングされます。
|
注意: シナリオ1では、Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionも、企業の中央ディレクトリとして使用できます。ただし、Oracle Application Server Single Sign-onは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(バージョン10.1.4.x) |
ユーザーは、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 Unified DirectoryまたはOracle Directory Server Enterprise Editionなど)のいずれかが企業の中央ディレクトリであり、Oracle Internet DirectoryがOracleバックエンド・ディレクトリです。このシナリオでは、ユーザー・オブジェクト、グループ・オブジェクトおよびレルム・オブジェクトが作成されると、企業の中央ディレクトリはすべてのOracleコンポーネントおよびその他のディレクトリに関するプロビジョニング情報のソースになります。Oracle Internet Directoryは、Oracleコンポーネントをサポートするために、Oracleバックエンド・ディレクトリとしてデプロイされます。このサポートを提供するために、Oracle Internet Directoryではフットプリントを格納して、接続ディレクトリでエントリを識別できるようにします。
表16-2に、このデプロイの一般的な要件を示します。
表16-2 Oracle Internet Directory以外のディレクトリを企業の中央ディレクトリとして使用するが、Oracle Internet Directoryがバックエンド・ディレクトリである場合の一般的な要件
| 要件 | 説明 |
|---|---|
|
初期起動 |
syncProfileBootstrapコマンドにより、Oracle Internet Directoryに企業の中央ディレクトリに格納されているユーザーおよびグループが移入されます。 パスワード資格証明などのユーザー情報を、企業の中央ディレクトリでのみ管理することを選択できます。そのようなデプロイでは、Oracle環境でシングル・サインオンを有効にするために、Oracle Directory Integration Platformにより、Oracleコンポーネントで必要なユーザー・エントリ属性のみを同期化できます。 パスワードは、企業の中央ディレクトリからOracle Internet Directoryに移行されません。 |
|
同期 |
ユーザーおよびグループ情報用の企業の中央ディレクトリは、Oracle Unified Directory、Oracle Directory Server Enterprise Editionまたはサード・パーティ・ディレクトリです。企業の中央ディレクトリでのユーザーおよびグループ情報への変更は、インポート・プロファイルが構成されたときに、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 Internet Directoryによって認証されます。 Oracle Internet Directoryで資格証明を持つユーザーは、ローカルで認証されます。 |
|
サード・パーティ・ディレクトリ外部認証プラグイン |
ユーザー資格証明がOracle Unified Directory、Oracle Directory Server Enterprise Editionまたはサード・パーティ・ディレクトリで管理される場合、Oracle Internet Directoryではこのプラグインを必要とします。ユーザーを認証するために、OracleAS Single Sign-On ServerによりOracle Internet Directoryディレクトリ・サーバーが呼び出されます。次に、プラグインによって、Oracle Unified Directory、Oracle Directory Server Enterprise Editionまたはサード・パーティ・ディレクトリに格納されているユーザー資格証明に対する、そのユーザーの認証が行われます。 |
企業の中央ディレクトリとして指定されているディレクトリに作成された新しいユーザーまたはグループは、Oracle Directory Integration Platformによって、Oracle Internet Directoryに自動的に同期化されます。プロビジョニングが実行される前に、企業の中央ディレクトリとOracle Internet Directory間で一方向の同期が確立されている必要があります。
図16-4に、サード・パーティ・ディレクトリが企業の中央ディレクトリとなっている場合の通常のデプロイを示します。
図16-4に、サード・パーティ・ディレクトリが企業の中央ディレクトリとなっている場合に、ユーザーまたはグループをプロビジョニングするための通常のプロセスを示します。
|
注意: Oracle Unified DirectoryおよびOracle Directory Server Enterprise Editionでは、プロビジョニングはサポートされません。 |
このプロセスは次のとおりです。
ユーザー・エントリまたはグループ・エントリがサード・パーティ・ディレクトリ内に作成されます。
次にスケジュールされた間隔に、エントリ作成イベントが、Oracle Directory Integration Platform内のサード・パーティ・ディレクトリ・コネクタによって読み取られます。
統合プロファイル内のマッピング情報に従って、サード・パーティ・ディレクトリのユーザー属性またはグループ属性がサード・パーティ・ディレクトリ内の対応する属性にマップされます。
ユーザー・エントリまたはグループ・エントリが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から接続ディレクトリへ定期的に同期化されます。これには、レルムのパスワード・ポリシーと可逆暗号化の両方を有効にする必要があります。
|
関連項目:
|
通常、パスワード値はハッシュされます。両方のディレクトリが同一のハッシング・アルゴリズムを使用する場合は、そのままの状態でハッシュ値を同期化できます。たとえば、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への同期化は、その他の属性の場合と同様です。両方のディレクトリで同一のハッシング・アルゴリズムがサポートされていない場合は、クリアテキスト形式でのみパスワードを同期化する必要があります。セキュリティ上の理由から、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構造を作成する必要があります。または、ドメイン・レベルのマッピングを実行できます。
この項の内容は次のとおりです。
両方のディレクトリで同一の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の下で同期化する必要があります。これを実行するには、ドメイン・レベルのマッピング・ルールに指定します。
すべてのユーザーおよびグループの同期が目的の場合は、適切な識別名マッピングですべてのユーザー・エントリを同期化できます。ただし、グループ・エントリを同期化する場合は、時間がかかり、制限が追加される場合があります。この項では、識別名マッピングが行われている場合のユーザーおよびグループ両方の同期の例を示します。
マッピング・ファイルで、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またはその他の識別名タイプの属性に対して識別名マッピングを行うことはできません。
グループ・メンバーシップを同期化する場合は、ソース・ディレクトリと宛先ディレクトリに同じネーミング属性を指定してください。
任意の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 Internet Directory内の正しいorclcommonnicknameattributeにその属性をマップする必要があります。これは、接続ディレクトリとの同期に関連付けられているコネクタ用のマッピング・ファイルにある、マッピング・ルールの1つであることが必要です。
たとえば、Oracle Internet DirectoryをMicrosoft Active Directoryと同期化していて、Microsoft Active Directoryのログイン識別子がユーザー・エントリのuserPrincipalName属性に含まれているとします。userPrincipalName属性の値をOracle Internet Directoryと同期化して、uid属性(orclcommonnicknameattribute属性の値)に格納するとしますこのマッピングは、ディレクトリ統合プロファイルのマッピング・ルールに反映される必要があります。
ログイン識別子用のその他の属性も使用できます。たとえば、ログインに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バックエンド・ディレクトリとMicrosoft Active Directoryとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
Microsoft Active DirectoryからOracleバックエンド・ディレクトリへ変更を同期化するために、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バックエンド・ディレクトリに格納されている古い値と比較され、更新されます。このためDirSync方式より時間がかかる可能性があります。 |
|
複数値の属性の変更 |
複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。 |
複数値の属性に加えられた増分変更を、属性値の完全置換として反映します。 |
|
同期点の追跡方法 |
ディレクトリ内の変更を問い合せたときに、ディレクトリの状態を識別するCookie値に基づく増分変更が渡されます。 |
|
|
必須のユーザー権限 |
ユーザーは、対象となるネーミング・コンテキストに対する変更のレプリケート権限が必要です。これにより、Microsoft Active Directory内のすべてのオブジェクトおよび属性を、それらに対するアクセス保護に関係なく、読み取ることができます。 関連項目: DirSync方式の使用時にMicrosoft Active Directoryユーザーに権限を割り当てる方法は、Microsoft Knowledge Base Article 303972( |
Microsoft Active Directoryユーザーには、Oracleバックエンド・ディレクトリに対して同期化するすべての必須属性を読み取る権限が必要です。 関連項目: USN-Changed方式の使用時に、Microsoft Active Directoryユーザーに権限を割り当てる方法は、Microsoftライブラリ( |
|
複数ドメインのサポート |
異なるドメイン内のエントリに加えられた変更を読み取るには、異なるドメイン・コントローラへの個々の接続が必要です。 |
グローバル・カタログ・サーバーに接続することで、複数のドメインに加えられた変更を取得できます。 |
|
異なるMicrosoft Active Directoryドメイン・コントローラへの切替え時のレプリケートされたディレクトリからの同期 |
同期は続行可能です。レプリケートされた環境に接続するときも同期キーは同じです。 |
次のことが必要です。
関連項目: 「同一ドメイン内の異なるMicrosoft Active Directoryドメイン・コントローラへの切替え」 |
|
同期の有効範囲 |
ディレクトリ内のすべての変更を読み取り、必須エントリへの変更のみをOracleバックエンド・ディレクトリに伝播します。 |
特定のサブツリーで変更の同期を有効にします。 |
|
ロード・バランサの背後に複数のMicrosoft Active Directory Serverを配置した環境の可用性 |
- |
特定のMicrosoft Active Directoryドメイン・コントローラに接続するか、グローバル・カタログに接続します。次の場合にグローバル・カタログに接続します。
|
WebDAVプロトコルを使用している場合、SSL用のアプリケーションを構成する必要があります。Oracleバックエンド・ディレクトリがエンド・ユーザーを認証する唯一の方法は、検証のためにActive Directoryにプレーン・テキスト・パスワードを渡すことであるため、Basic認証が必要です。Basic認証が存在しない場合は、Digest認証が使用されます。ただし、Digest認証の場合、検証のためにActive Directoryに渡すプレーン・テキスト・パスワードがOracleバックエンド・ディレクトリにないため、エンド・ユーザーは認証されません。エンド・ユーザーとサーバー間の通信チャネルが暗号化されないこと、エンド・ユーザー・パスワードも同様に暗号化されずに送信されることから、Basic認証はSecure Sockets Layer(SSL)を使用しないHTTP上ではサポートされません。
この項では、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バックエンド・ディレクトリ・ユーザーがシングル・サインオン・サーバーを起動するには、ユーザー・エントリごとに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 Enterprise Single Sign-On Suite Plus管理者ガイドを参照してください。
表16-4に、Microsoft Active Directoryからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。
表16-4 Microsoft Active Directory用のOracleバックエンド・ディレクトリ・スキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Microsoft Active DirectoryからOracleバックエンド・ディレクトリに移行されたユーザーおよびグループに対するMicrosoft Active Directoryの |
|
|
Microsoft Active DirectoryからOracleバックエンド・ディレクトリに移行されたユーザーおよびグループに対するMicrosoft Active Directoryの |
|
|
Microsoft Active Directoryの |
|
|
Microsoft Active DirectoryユーザーのKerberosユーザー・プリンシパル名を格納します。 |
|
|
Microsoft Active Directoryのグループ属性を格納します。これらのグループ属性は、Oracle Directory Integration環境におけるMicrosoft Active Directoryのグループ・オブジェクトとOracleバックエンド・ディレクトリのグループ・オブジェクトの同期に使用されます。 |
|
|
Microsoft Active Directoryのユーザー属性を格納します。これらのユーザー属性は、Oracle Directory Integration and Provisioning環境におけるMicrosoft Active Directoryのユーザー・オブジェクトとOracleバックエンド・ディレクトリのユーザー・オブジェクトの同期に使用されます。 |
|
|
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バックエンド・ディレクトリにどのように反映されるかを示します。
図16-6 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ドメインのドメイン・コントローラ間で一方向の同期が確立されている必要があります。
この項では、複数ドメインMicrosoft Active Directory環境との同期化の考慮事項について説明します。内容は次のとおりです。
Microsoft Active DirectoryからOracleバックエンド・ディレクトリへのインポートに必要な構成
Microsoft Active Directory Lightweight Directory ServiceからOracleバックエンド・ディレクトリへのインポートに必要な構成
Oracleバックエンド・ディレクトリからMicrosoft Active Directoryへのエクスポートに必要な構成
通常、インポートを行うには、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を参照してください。 |
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に接続するインポート・プロファイルを、それぞれのポート詳細を使用して構成する必要があります。
複数ドメインMicrosoft Active Directory環境と統合するために、Oracle Directory Integration Platformでは、各Microsoft Active Directoryドメインから構成情報を取得します。Microsoft Active Directoryドメインの数と同数のエクスポート・プロファイルを構成する必要があります。
複数のドメインを持つ接続ディレクトリのデプロイでは、単一のDITにすることも、複数のDITを組み合せることもできます。図16-7に、接続ディレクトリの複数のドメインが、Oracleバックエンド・ディレクトリのDITにどのようにマップされるかを示します。
図16-7 Oracleバックエンド・ディレクトリとMicrosoft Active Directory内の複数のドメインの間のマッピングの例
図16-7では、接続ディレクトリ環境に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にマップされます。
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環境の非推移的な信頼関係では、あるドメインが別のドメインからの外部セキュリティ・プリンシパルを認識すると、そのエンティティはDNエントリのように表されます。そのエントリでは、RDNコンポーネントは、信頼関係のドメインにおける元のエントリのSIDに設定されます。グループの場合は、外部セキュリティ・プリンシパルの識別名が、信頼関係のドメインにおける元のエントリの識別名としてではなく、メンバーの値として表されます。このため、外部セキュリティ・プリンシパルがOracleバックエンド・ディレクトリと同期化されるときに問題が発生する可能性があります。
この項では、Oracle Internet DirectoryとOracle Directory Server Enterprise Edition(以前のSun Java System Directory Server)との統合に関するその他の考慮事項について説明します。内容は次のとおりです。
Oracle Directory Server Enterprise Edition(以前のSun Java System Directory Server)は、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。Oracle Directory Server Enterprise EditionからOracle Internet Directoryへの同期は、この変更ログを活用します。
|
関連項目:
|
Oracle Internet Directoryには、Oracle Directory Server Enterprise Editionからインポートされるユーザー用のorclSourceObjectDN属性が含まれます。orclSourceObjectDN要素は、Oracle Directory Server Enterprise Editionの各エントリの識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。
この項では、Oracleバックエンド・ディレクトリとIBM Tivoli Directory Serverとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
IBM Tivoli Directory Serverは、ディレクトリ・オブジェクトへの増分変更が保存される変更ログを保持します。IBM Tivoli Directory ServerからOracleバックエンド・ディレクトリへの同期では、この変更ログを利用します。
|
注意: IBM Tivoli Directory Serverバージョン6.2では、tombstoneがサポートされています。 |
表16-5に、IBM Tivoli Directory Serverからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。
表16-5 IBM Tivoli Directory Server用のOracleバックエンド・ディレクトリ・スキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Tivoliの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
IBM Tivoliの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。 |
|
|
Tivoliディレクトリ・オブジェクトを表します。 |
|
関連項目:
|
この項では、Oracleバックエンド・ディレクトリとNovell eDirectoryまたはOpenLDAPとの統合に関するその他の考慮事項について説明します。内容は次のとおりです。
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の特定のサブセットを検索するように比較をカスタマイズできます。
|
関連項目:
|
表16-6に、Novell eDirectoryからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。
表16-6 Novell eDirectory用のOracleバックエンド・ディレクトリ・スキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
Novell eDirectoryの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
調整に必須。Novell eDirectoryの各エントリに対するGUID値を表します。この値は、同期キーとして使用されます。 |
|
|
必須。Novell eDirectoryの各エントリの |
|
|
必須。Novell eDirectoryの各エントリの |
|
|
Novell eDirectoryのNDSオブジェクトを表します。 |
|
関連項目: Novell eDirectory用のOracleバックエンド・ディレクトリ・スキーマ要素の詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。 |
表16-7に、OpenLDAPからインポートされるユーザー用のOracleバックエンド・ディレクトリ・スキーマ要素を示します。
表16-7 OpenLDAP用のOracle Internet Directoryスキーマ要素
| スキーマ要素 | 説明 |
|---|---|
|
|
OpenLDAPの各エントリに対する識別名を表します。この値は、両方のディレクトリ間に異なるドメインがマップされている場合の外部認証の実行に必要です。 |
|
|
調整に必須。OpenLDAPの各エントリに対するentryUUID値を表します。この値は、同期キーとして使用されます。 |
|
|
必須。OpenLDAPの各エントリの |
|
|
必須。OpenLDAPの各エントリの |
|
|
OpenLDAPオブジェクトを表します。 |
|
関連項目: OpenLDAP用のOracleバックエンド・ディレクトリ・スキーマ要素の詳細は、『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リファレンス』を参照してください。 |
