| Oracle® Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-05 |
|
 前 |
 次 |
この章では、アイデンティティ管理レルムと、その企業内デプロイメントおよびホスティングされたデプロイメント用の計画および構成方法について説明します。
この章の項目は次のとおりです。
|
注意: この章で言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g(10.1.4.3.0)以上のことです。 |
この概要の項目は次のとおりです。
第5章「Oracle Internet Directory編成の理解」では、DIT全体およびデプロイメント対象のユーザーとグループの配置を構成する場合のガイドラインを示しています。これらのガイドラインを実装すると、膨大な数のデプロイメント構成を行うことになるため、デプロイメントの目的をディレクトリ自体にメタデータとして取得する必要があります。Oracle Identity Managementインフラストラクチャに依存するOracleソフトウェアおよびサード・パーティのソフトウェアは、このメタデータによってデプロイメントの目的を認識し、カスタマイズされた環境で正常に機能できます。
Oracle Internet Directoryでは、デプロイメントの目的は、アイデンティティ管理レルムに取得されます。このレルムは、前述の項で配置について説明したユーザーおよびグループに対して、アイデンティティ管理ポリシーを設定する場合にも役立ちます。
アイデンティティ管理レルムは、ディレクトリ内の適用範囲が明確な領域で、次の要素で構成されています。
適用範囲が明確なエンタープライズ・アイデンティティの集合(米国内のすべての従業員など)
これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合
アイデンティティ管理ポリシーを設定しやすくするグループの集合(アイデンティティの集約)
DIT全体の構造およびユーザーとグループの配置を決定した後、アイデンティティ管理レルムのルートとして機能するディレクトリ・エントリを識別する必要があります。このエントリによって、レルムに定義されたアイデンティティ管理ポリシーの範囲が決まります。デフォルトでは、アイデンティティ管理レルムのルート下のディレクトリ・サブツリー全体が、範囲となります。このエントリの下に、OracleContextという特別なエントリが作成されます。次の項目が含まれます。
ユーザーおよびグループのネーミングおよび配置などのデプロイメント固有のDIT設計(前述の項を参照)
このレルムに関連付けられたアイデンティティ管理ポリシー
Oracleアプリケーション特有のレルム固有の追加情報
アイデンティティ管理レルムを計画する場合は、次のことを考慮します。
企業のセキュリティ要件に基づいて、アイデンティティ管理レルムのルートを選択する必要があります。通常、ほとんどの企業で必要なレルムは1つのみです。ただし、個別のアイデンティティ管理ポリシーを使用して複数のユーザー集団を管理するときは、複数のレルムが必要になる場合があります。
サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、選択したアイデンティティ管理レルムのルートを、サード・パーティのディレクトリのDIT設計と一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。
アイデンティティ管理レルムを構成し管理するには、Oracle Internet Directoryで提供される管理ツールを使用します。これには、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のOracle Internet Directoryセルフサービス・コンソールやコマンドライン・ツールなどがあります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の |
Oracle Internet Directoryツールを使用してアイデンティティ管理レルムを構成した後、デプロイメントによって行われたカスタマイズを反映するために、ディレクトリのネーミングおよび格納ポリシーの更新を計画します。この更新は、Oracle Identity Managementインフラストラクチャを使用する他のOracleコンポーネントをインストールして使用する前に行う必要があります。
図34-1に、MyCompanyという会社のアイデンティティ管理レルムの例を示します。
図34-1の例は、ドメイン名ベースのDIT構造を使用するデプロイメントになっています。コンテナdc=us,dc=mycompany,dc=comは、アイデンティティ管理レルムのルートです。その結果、デフォルトで、適用範囲がdc=usエントリ下のディレクトリ・サブツリー全体に限定される新しいアイデンティティ管理レルムが作成されます。アイデンティティ管理レルムの名前はUSです。
この項では、単一および複数のアイデンティティ管理レルムを使用するデプロイメントについて説明します。この項の内容は、次のとおりです。
この例では、企業にはユーザーの集団が1つあり、そのすべてのユーザーが同一のアイデンティティ管理ポリシーによって管理されます。これは、すべてのOracle製品のデフォルトの構成です。Oracle Internet Directoryに存在するデフォルトのアイデンティティ管理レルムは1つのみであり、企業内のすべてのOracleコンポーネントが、このレルムのユーザーに対応します。図34-2に、この使用方法を示します。
図34-2の例には、従業員のみを含む単一のデフォルトのアイデンティティ管理レルムがあります。このレルムでは、すべてのユーザーおよびグループが管理され、同じアプリケーションであるアプリケーションAおよびアプリケーションBへのアクセスを共有しています。
同一のアイデンティティ管理インフラストラクチャを使用して、内部ユーザーと外部の自己登録ユーザーの両方に対応することも可能です。内部ユーザーと外部ユーザーではアイデンティティ管理ポリシーが異なるため、内部ユーザー用と外部ユーザー用にレルムを1つずつデプロイできます。図34-3に、この使用方法を示します。
図34-3の例では、デフォルトのアイデンティティ管理レルムは内部ユーザー(従業員)用であり、これらの内部ユーザーにはアプリケーションA、BおよびCへのアクセス権があります。外部アイデンティティ管理レルムは外部ユーザー用であり、外部ユーザーには、アプリケーションCおよびDへのアクセス権があります。
ホスティングされたデプロイメントでは、アプリケーション・サービス・プロバイダ(ASP)が、1社以上にアイデンティティ管理サービスを提供し、これらの企業にかわってアプリケーションのホスティングを行います。ホスティングされた各企業は、その企業のユーザーが管理される個別のアイデンティティ管理レルムに対応付けられます。アプリケーション・サービス・プロバイダに属するユーザーは、別のレルム(通常は、デフォルトのレルム)で管理されます。
図34-4に、ホスティングされたデプロイメント(2社をホスティング)を示します。
図34-4の例では、ASPユーザーはデフォルトのアイデンティティ管理レルムに存在します。ASPは、そのレルムのユーザー、グループおよび関連するポリシーを管理します。ASPユーザーは、ホスティングされた企業のためにアプリケーションA、B、Cを管理しています。ホスティングされた企業のMyCompanyユーザーは、MyCompanyというアイデンティティ管理レルムに存在します。これらのユーザーは、アプリケーションAおよびアプリケーションBを使用します。ホスティングされた企業のXY Corpユーザーは、XY Corpというアイデンティティ管理レルムに存在します。それらはアプリケーションBおよびアプリケーションCを使用します。
表34-1に、アイデンティティ管理レルムのオブジェクトを示します。
表34-1 Oracle Identity Managementオブジェクト
構成を簡単にするために、Oracle Internet Directoryのインストール時に、デフォルトのDITが作成され、デフォルトのアイデンティティ管理レルムが設定されます。
図34-5に示されているとおり、デフォルトのアイデンティティ管理レルムはグローバルDITの一部です。ルートDSEのすぐ下のノードはdc=comで、その下にdc=MyCompany、次にdc=usが続きます。これらの4つのノードにより、DIT構造全体が表されます。ノードdc=usは、デフォルトのアイデンティティ管理レルムのルートです。これには、ユーザーおよびグループの情報を格納するためのcn=Usersおよびcn=Groupsという2つのサブツリーが含まれています。説明上の理由から、cn=Usersノードには、uid=user1およびuid=user2という2つのリーフが含まれています。同様に、cn=Groupsノードには、cn=group1およびcn=group2が含まれています
オプションで、Oracle Internet Directoryをインストールするコンピュータのドメインに基づいて、DITを設定することもできます。たとえば、oidhost.us.mycompany.comというコンピュータにインストールすると、デフォルトのアイデンティティ管理レルムのルートは、dc=us,dc=mycompany,dc=comとなります。
また、「Internet Directoryのネームスペースの指定」インストール画面で、デプロイメント要件を満たす別の識別名を、デフォルトのアイデンティティ管理レルムのルートとして指定することも可能です。たとえば、独自のアイデンティティ管理インストール環境をサード・パーティ・ディレクトリと統合する予定がある場合、サード・パーティ・ディレクトリのデフォルト・ネーミング・コンテキストの識別名と一致する識別名を指定することをお薦めします。サード・パーティ・ディレクトリからデフォルト・ネーミング・コンテキストを取得する方法の詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』のサード・パーティ・ディレクトリとの統合に関する章を参照してください。
構成中に、Oracle Internet Directoryによって次のものが作成されます。
デフォルトのアイデンティティ管理レルムに関連付けられたOracleコンテキスト。Oracleコンテキストには、レルム固有のすべてのポリシーとメタデータが格納されます。前述の例の場合は、cn=OracleContext,dc=us,dc=mycompany,dc=comという識別名を持つOracleコンテキストが作成されます。このエントリとその下にあるノードによって、Oracleソフトウェアはレルム固有のポリシーと設定を検出できます。
デフォルトのアイデンティティ管理レルムでのディレクトリ構造およびネーミング・ポリシー。これによって、Oracleコンポーネントが様々なアイデンティティを検索できるようになります。これらのデフォルト値は、次のとおりです。
すべてのユーザーは、アイデンティティ管理レルムのベースの下にあるコンテナcn=usersに配置されます。この例では、cn=users,dc=us,dc=mycompany,dc=comがこのコンテナです。
Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成した新規ユーザーも、コンテナcn=usersの下に作成されます。
Oracle Identity Managementインフラストラクチャを使用してアイデンティティ管理レルム内に作成したすべての新規ユーザーは、オブジェクト・クラスorclUserV2およびinetOrgPersonに属します。
すべてのグループは、アイデンティティ管理レルムのベースの下にあるコンテナcn=groupsに配置されます。この例では、cn=groups,dc=us,dc=mycompany,dc=comがこのコンテナです。
アイデンティティ管理レルム管理者。このユーザーは、ユーザー・コンテナの下に配置されます。この例では、レルム管理者の完全修飾された識別名はcn=orcladmin,cn=users,dc=us,dc=mycompany,dc=comです。
認証サービスで適切な処理を実行できるようにするデフォルトの認証ポリシー。次のポリシーが含まれます。
デフォルトのディレクトリ・パスワード・ポリシー(パスワードの長さ、ロックアウト、有効期限など)
ユーザーのプロビジョニングを行う際に自動生成される必要がある追加のパスワード・ベリファイア
アイデンティティ管理の権限。Oracle Internet Directoryによって、Oracle Internet Directoryセルフサービス・コンソールを介してこれらの権限を委任できるレルム管理者に付与されます。これらの権限の例は、次のとおりです。
共通のアイデンティティ管理構成権限(ユーザーの作成、ユーザー・プロファイルの変更、グループの作成など)
Oracle Identity Managementインフラストラクチャを使用して新しいOracleコンポーネントをインストールする権限
Oracle Internet Directoryセルフサービス・コンソールを管理する権限
|
関連項目:
|
レルムを作成した後、その様々な要素をカスタマイズできます。表34-2に、カスタマイズできる要素、各種のカスタマイズで使用可能なツールおよび参照先を示します。
表34-2 デフォルトのアイデンティティ管理レルムのカスタマイズ
| カスタマイズ可能な対象 | ツール | 参照箇所 |
|---|---|---|
|
ディレクトリ構造およびネーミング・ポリシー |
Oracle Internet Directoryセルフサービス・コンソール Oracle Directory Services Manager コマンドライン・ツール |
この項。 第34.1.5項「デフォルトのディレクトリ情報ツリーおよびアイデンティティ管理レルム」 10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のOracle Internet Directoryセルフサービス・コンソールの使用に関する章 |
|
認証ポリシー |
Oracle Directory Services Manager コマンドライン・ツール |
|
|
アイデンティティ管理の権限 |
Oracle Internet Directoryセルフサービス・コンソール Oracle Directory Services Manager コマンドライン・ツール |
第32章「Oracle Identity Managementの権限の委任」 10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のOracle Internet Directoryセルフサービス・コンソールの使用に関する章 |
これが必要となる可能性がある典型的なシナリオは、Oracle Identity Managementインストールをサード・パーティ・ディレクトリと統合する場合です。
たとえば、デフォルトのアイデンティティ管理レルムがdc=mycompany,dc=comであり、cn=users,dc=mycompany,dc=comの下にユーザーが存在すると仮定します。
サード・パーティ・ディレクトリのネーミング・コンテキストが、デフォルト・レルム内のユーザーおよびグループの現在の検索ベースと一致しない場合は、既存のユーザーとサード・パーティのユーザーがどちらもOracle Single Sign-Onを使用してログインできるように、デフォルト・レルムのユーザーおよびグループの検索ベースを変更できます。既存のユーザーとサード・パーティのユーザーをともに含むことができて最も下位にあるユーザー検索ベースを選択します。この検索ベースを、最下位の共通ユーザー検索ベースと呼ぶことにします。
|
注意: このアプローチでは、Oracle Single Sign-Onのログインで選択されるユーザーの |
デプロイメント環境が次の1から5の使用例のいずれかと一致する場合は、第34.2.1項「ユーザーおよびグループの既存の検索ベースを更新する手順」で説明されている手順に従ってください。
使用例1:
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの下にありますが、レルムのユーザー検索ベース以外のコンテナ内に存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users,o=employees,dc=mycompany,dc=comの下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。
使用例2:
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの外部にありますが、最下位の共通ユーザー検索ベースが存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users, dc=mycompanyecorp,dc=comの下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=comです。
最下位の共通ユーザー検索ベースがルートDSEの場合は、「使用例6:」の次の項で説明されている手順に従います。
使用例3:
サード・パーティのネーミング・コンテキストは、デフォルト・レルムの識別名と同じです。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがdc=mycompany,dc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。
使用例4:
サード・パーティのネーミング・コンテキストに、デフォルト・レルムの識別名の親が含まれます。
たとえば、識別名(DN)がdc=us,dc=mycompany,dc=comであるデフォルト・レルムがあり、既存のユーザーがcn=users,dc=us,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがdc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、dc=comです。
使用例5:
サード・パーティのネーミング・コンテキストは、既存のユーザー検索ベースの下に存在します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがl=emea,cn=users,dc=mycompany,dc=comのすぐ下に存在する場合です。この場合、最下位の共通ユーザー検索ベースは、cn=users,dc=mycompany,dc=comです。この使用例の場合、ユーザー検索ベースを変更する必要はありません。
サード・パーティ・ディレクトリとの同期化を設定する前に、次の手順を実行する必要があります。
Oracle Internet Directoryデータベースをバックアップします。
サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。
次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。
ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。
ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。
次の手順に従って新規グループ・コンテナに適切なACLを適用します。
ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。
ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。
既存のユーザーとサード・パーティのユーザーをともに含むことができる最下位の共通ユーザー検索ベースを決定します。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのユーザーがl=emea,dc=mycompany,dc=comの下に存在する場合、最下位の共通ユーザー検索ベースは、dc=mycompany,dc=comです。
最下位の共通ユーザー検索ベースが、ルート・エントリになることもあります。たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのユーザーがdc=mycompanycorp,dc=netの下に存在する場合です。この場合は、第34.2.2項「追加の検索ベースの設定」で説明されているデプロイメント例までスキップしてください。
グループも同期化する必要がある場合は、既存のグループとサード・パーティのグループをともに含むことができて最も下位にあるグループ検索ベースを決定します。この検索ベースを、最下位の共通グループ検索ベースと呼ぶことにします。
たとえば、既存のグループがcn=groups,dc=mycompany,dc=comの下に存在し、サード・パーティのグループがl=emea,dc=mycompany,dc=comの下に存在する場合、最下位の共通グループ検索ベースは、dc=mycompany,dc=comです。
レルムの管理者(通常はorcladmin)としてセルフサービス・コンソールにログインします。
「構成」タブに移動し、ユーザー検索ベースを手順5で決定した最下位の共通ユーザー検索ベースに設定します。グループも同期化する場合は、グループ検索ベースを手順6で決定した最下位の共通グループ検索ベースに設定します。
Oracle Single Sign-Onにこれらの変更を認識させるため、第34.2.3項「Oracle Single Sign-Onのリフレッシュ」に説明されている手順を実行します。
orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。
変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。第34.2.4項「プロビジョニング・プロファイルの再構成」に説明されている手順に従ってください。
|
注意: ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフサービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する説明を参照してください。 |
使用例6:
この場合、サード・パーティのネーミング・コンテキストはデフォルト・レルムの外部にあり、最下位の共通ユーザー検索ベースはルートDSEです。
たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users,dc=mycompanycorp,dc=netの下に存在する場合、最下位の共通ユーザー検索ベースは、ルートDSEです。
この場合、サード・パーティのネーミング・コンテキストを別の検索ベースとして追加する必要があります。この手順は次のとおりです。
サード・パーティ・ディレクトリとの同期化を設定する前に、次の手順を実行します。
Oracle Internet Directoryデータベースをバックアップします。
サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。
次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。
ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。
ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。
次の手順に従って新規グループ・コンテナに適切なACLを適用します。
ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。
ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。
レルムの管理者としてセルフサービス・コンソールにログインします。
「構成」タブに移動します。
現在のレルムのusersearchbaseにcn=users,dc=mycompanycorp,dc=netを追加します。
現在のレルムのgroupsearchbaseにcn=groups,dc=mycompanycorp,dc=netを追加します。
Oracle Single Sign-Onにこれらの変更を認識させるため、第34.2.3項「Oracle Single Sign-Onのリフレッシュ」に説明されている手順を実行します。
orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。
このアイデンティティ管理構成に基づいて中間層が構成されている場合、変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。第34.2.4項「プロビジョニング・プロファイルの再構成」に説明されている手順に従ってください。
|
注意: ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフサービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する説明を参照してください。 |
Oracle Single Sign-Onに構成変更を認識させるため、$ORACLE_HOME/sso/admin/plsql/sso/ディレクトリに移動して次のように入力し、Oracle Single Sign-Onのリフレッシュ・スクリプトを実行します。
sqlplus orasso@ssoreoid.sql
パスワードが要求されます。orassoスキーマ・パスワードを取得するには、10g(10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の付録「シングル・サインオン・スキーマ・パスワードの取得」を参照してください。
ユーザーおよびグループの検索ベースを変更する前にデフォルトのアイデンティティ管理レルムに基づいて中間層アプリケーションをインストールしている場合、中間層のインストールによって作成されたプロビジョニング・プロファイルは、無効になります。この理由は、プロファイルのevent subscriptions属性に含まれるユーザーまたはグループの検索ベースの情報が古くなるためです。oidprovtoolを使用して、すべてのプロファイルを変更する必要があります。
すべてのプロビジョニング・プロファイルに対して次の手順を実行します。
ldapsearchを使用して、すべてのプロビジョニング・プロファイル情報をLDIFファイルに出力します。
ldapsearch -h oid_host -p oid_port \ -D "cn=orcladmin" -q -s sub \ -b "cn=provisioning profiles,cn=changelog subscriber,\ cn=oracle internet directory" \ "objectclass=*" > provprofiles.ldif
イベント・サブスクリプションの例は、次のとおりです。
USER:cn=users,dc=mycompany,dc=com:MODIFY(list_of_attributes)USER:cn=users,dc=mycompany,dc=com:DELETEGROUP:cn=groups,dc=mycompany,dc=com:MODIFY(list_of_attributes)GROUP:cn=groups,dc=mycompany,dc=com:DELETE
ここで、cn=users,dc=mycompany,dc=comとcn=groups,dc=mycompany,dc=comは、それぞれアプリケーションのインストールおよび構成時に作成したユーザー検索ベースとグループ検索ベースです。
GUIDに基づいてOracle Internet Directoryサーバーを検索することで、アプリケーション・アイデンティティの実際の識別名を取得します。アプリケーションの識別名を取得するには、次のように入力します。
ldapsearch -h host -p port -D cn=orcladmin -q \ -s sub -b "" \ "orclguid=Value_of_orclODIPProvisioningAppGuid" dn
provprofiles.ldifの属性値から各プロファイルのGUID値を取得できます。
返された各プロファイルを次のように変更します。
$ORACLE_HOME/bin/oidprovtool operation=MODIFY \
ldap_host=host ldap_port=port \
ldap_user_dn="cn=orcladmin" \
ldap_user_passwd=password \
interface_version=interfaceVersion \
application_dn=applicationDN \
organization_dn=identity_Realm_DN \
event_subscription=New_Event_Subscription_1
event_ subscription=New_Event_Subscription_2
.
.
.
event_subscription=New_Event_Subscription_n
New_Event_Subscription引数には、次の書式を使用する必要があります。
USER: new_user_search_base:MODIFY(list_of_attributes) USER: new_user_search_base:DELETE GROUP: new_group_search_base:MODIFY(list_of_attributes) GROUP: new_group_search_base:DELETE
ここで、organization_dnの値には、元のアイデンティティ・レルムの識別名を指定する必要があります。
追加のアイデンティティ管理レルムは、Oracle Delegated Administration Services 10g(10.1.4.3.0)以上のセルフサービス・コンソールまたはoidrealmを使用して作成できます。
ASPAdminsグループのメンバーのみが、新しいアイデンティティ管理レルムを作成できます。Oracle Directory Services Managerを使用して、デフォルトのアイデンティティ管理レルム固有のOracleコンテキストにおけるASPAdminsグループのuniquemember属性にユーザー識別名を追加し、このグループにユーザーを追加します。詳細は、「Oracle Directory Services Managerを使用した静的グループ・エントリの変更」を参照してください。
|
注意: 複数のアイデンティティ管理レルムでは、動作しないアプリケーションもあります。 レルムを追加する場合は、追加したレルムが既存アプリケーションで認識されるように手動で設定する必要があります。詳細は、アプリケーション固有のマニュアルを参照してください。 Oracle Identity Managementインフラストラクチャでは、特別な管理手順を使用してシングル・サインオン・サーバーに追加のレルムを認識させる必要があります。Oracle Single Sign-Onで複数のレルムを有効にする方法は、10g(10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の「複数レルムでのシングル・サインオン」の章を参照してください。 |
|
関連項目:
|
