1. Oracle Internet Directoryの管理
  2. 拡張管理: ディレクトリ・デプロイメントの管理
  3. レルムの計画、デプロイおよび管理

34 レルムの計画、デプロイおよび管理

次のトピックでは、Oracle Internet Directoryでのアイデンティティ管理レルムの実装について説明し、企業内デプロイメントとホスティングされたデプロイメント用のアイデンティティ管理レルムを計画、デプロイおよび管理する方法について説明します。

ノート:

このガイドで言及するOracle Single Sign-Onはすべて、Oracle Single Sign-On 10g (10.1.4.3.0)以上のことです。

34.1 アイデンティティ管理レルムの理解

この項では、アイデンティティ管理レルムの計画の概要について説明します。

この概要の項目は次のとおりです。

34.1.1 アイデンティティ管理レルム計画の概要

この項では、DIT全体およびデプロイメント対象のユーザーとグループの配置を構成する場合のガイドラインを示しています。これらのガイドラインを実装すると、膨大な数のデプロイメント構成を行うことになるため、デプロイメントの目的をディレクトリ自体にメタデータとして取得する必要があります。Oracle Identity Managementインフラストラクチャに依存するOracleソフトウェアおよびサード・パーティのソフトウェアは、このメタデータによってデプロイメントの目的を認識し、カスタマイズされた環境で正常に機能できます

「Oracle Internet Directory編成の理解」を参照してください。

Oracle Internet Directoryでは、デプロイメントの目的は、アイデンティティ管理レルムに取得されます。このレルムは、前述の項で配置について説明したユーザーおよびグループに対して、アイデンティティ管理ポリシーを設定する場合にも役立ちます。

アイデンティティ管理レルムは、ディレクトリ内の適用範囲が明確な領域で、次の要素で構成されています。

  • 適用範囲が明確なエンタープライズ・アイデンティティの集合(米国内のすべての従業員など)

  • これらのアイデンティティに関連付けられたアイデンティティ管理ポリシーの集合

  • アイデンティティ管理ポリシーを設定しやすくするグループの集合(アイデンティティの集約)

DIT全体の構造およびユーザーとグループの配置を決定した後、アイデンティティ管理レルムのルートとして機能するディレクトリ・エントリを識別する必要があります。このエントリによって、レルムに定義されたアイデンティティ管理ポリシーの範囲が決まります。デフォルトでは、アイデンティティ管理レルムのルート下のディレクトリ・サブツリー全体が、範囲となります。このエントリの下に、OracleContextという特別なエントリが作成されます。次の項目が含まれます。

  • ユーザーおよびグループのネーミングおよび配置などのデプロイメント固有のDIT設計(前述の項を参照)

  • このレルムに関連付けられたアイデンティティ管理ポリシー

  • Oracleアプリケーション特有のレルム固有の追加情報

アイデンティティ管理レルムを計画する場合は、次のことを考慮します。

  • 企業のセキュリティ要件に基づいて、アイデンティティ管理レルムのルートを選択する必要があります。通常、ほとんどの企業で必要なレルムは1つのみです。ただし、個別のアイデンティティ管理ポリシーを使用して複数のユーザー集団を管理するときは、複数のレルムが必要になる場合があります。

  • サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、選択したアイデンティティ管理レルムのルートを、サード・パーティのディレクトリのDIT設計と一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。

  • アイデンティティ管理レルムを構成し管理するには、Oracle Internet Directoryで提供される管理ツールを使用します。これには、Oracle Identity Management 10g (10.1.4.3.0)以上のOracle Internet Directoryセルフサービス・コンソールやコマンド行ツールなどがあります。

    関連項目:

    『Oracle Identity Managementリファレンス』のOracle Internet Directoryレルム・ツールに関する項のoidrealmコマンドのリファレンス。

  • Oracle Internet Directoryツールを使用してアイデンティティ管理レルムを構成した後、デプロイメントによって行われたカスタマイズを反映するために、ディレクトリのネーミングおよび格納ポリシーの更新を計画します。この更新は、Oracle Identity Managementインフラストラクチャを使用する他のOracleコンポーネントをインストールして使用する前に行う必要があります。

図34-1に、MyCompanyという会社のアイデンティティ管理レルムの例を示します。

図34-1 アイデンティティ管理レルムの例

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

図34-1の例は、ドメイン名ベースのDIT構造を使用するデプロイメントになっています。コンテナdc=us,dc=mycompany,dc=comは、アイデンティティ管理レルムのルートです。その結果、デフォルトで、適用範囲がdc=usエントリ下のディレクトリ・サブツリー全体に限定される新しいアイデンティティ管理レルムが作成されます。アイデンティティ管理レルムの名前はUSです。

34.1.2 企業内デプロイメントにおけるアイデンティティ管理レルムの理解

次の各トピックでは、単一および複数のアイデンティティ管理レルムを使用するデプロイメントについて説明します。

34.1.2.1 企業における単一アイデンティティ管理レルムについて

この例では、企業にはユーザーの集団が1つあり、そのすべてのユーザーが同一のアイデンティティ管理ポリシーによって管理されます。これは、すべてのOracle製品のデフォルトの構成です。Oracle Internet Directoryに存在するデフォルトのアイデンティティ管理レルムは1つのみであり、企業内のすべてのOracleコンポーネントが、このレルムのユーザーに対応します。図34-2に、この使用方法を示します。

図34-2 企業での使用例: 単一アイデンティティ管理レルム

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

図34-2の例には、従業員のみを含む単一のデフォルトのアイデンティティ管理レルムがあります。このレルムでは、すべてのユーザーおよびグループが管理され、同じアプリケーションであるアプリケーションAおよびアプリケーションBへのアクセスを共有しています。

34.1.2.2 企業における複数アイデンティティ管理レルムについて

同一のアイデンティティ管理インフラストラクチャを使用して、内部ユーザーと外部の自己登録ユーザーの両方に対応することも可能です。内部ユーザーと外部ユーザーではアイデンティティ管理ポリシーが異なるため、内部ユーザー用と外部ユーザー用にレルムを1つずつデプロイできます。図34-3に、この使用方法を示します。

図34-3 企業での使用例: 複数アイデンティティ管理レルム

図34-3の説明が続きます
「図34-3 企業での使用例: 複数アイデンティティ管理レルム」の説明

図34-3の例では、デフォルトのアイデンティティ管理レルムは内部ユーザー(従業員)用であり、これらの内部ユーザーにはアプリケーションA、BおよびCへのアクセス権があります。外部アイデンティティ管理レルムは外部ユーザー用であり、外部ユーザーには、アプリケーションCおよびDへのアクセス権があります。

34.1.3 ホスティングされたデプロイメントにおけるアイデンティティ管理レルムの概要

ホスティングされたデプロイメントでは、アプリケーション・サービス・プロバイダ(ASP)が、1社以上にアイデンティティ管理サービスを提供し、これらの企業にかわってアプリケーションのホスティングを行います。ホスティングされた各企業は、その企業のユーザーが管理される個別のアイデンティティ管理レルムに対応付けられます。アプリケーション・サービス・プロバイダに属するユーザーは、別のレルム(通常は、デフォルトのレルム)で管理されます。

図34-4に、ホスティングされたデプロイメント(2社をホスティング)を示します。

図34-4 ホスティングされたデプロイメントでの使用例

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

図34-4の例では、ASPユーザーはデフォルトのアイデンティティ管理レルムに存在します。ASPは、そのレルムのユーザー、グループおよび関連するポリシーを管理します。ASPユーザーは、ホスティングされた企業のためにアプリケーションA、B、Cを管理しています。ホスティングされた企業のMyCompanyユーザーは、MyCompanyというアイデンティティ管理レルムに存在します。これらのユーザーは、アプリケーションAおよびアプリケーションBを使用します。ホスティングされた企業のXY Corpユーザーは、XY Corpというアイデンティティ管理レルムに存在します。それらは、アプリケーションBおよびアプリケーションCを使用します。

34.1.4 アイデンティティ管理レルム・オブジェクト

この項では、アイデンティティ管理レルムのオブジェクトを示します。

表34-1に、アイデンティティ管理レルムのオブジェクトを示します。

表34-1 Oracle Identity Managementオブジェクト

オブジェクト 説明

ルートOracleコンテキスト

このオブジェクトには、次のものが含まれます。

  • インフラストラクチャ内のデフォルトのアイデンティティ管理レルムへのポインタ

  • 単純な名前の指定によりレルムの位置を特定する方法に関する情報

アイデンティティ管理レルム

特別なオブジェクト・クラスが関連付けられた通常のディレクトリ・エントリ。

ID管理レルム固有のOracleコンテキスト

このオブジェクトには、レルムごとに次のものが含まれます。

  • アイデンティティ管理レルムのユーザー・ネーミング・ポリシー(つまり、ユーザーをネーミングおよび検索する方法)

  • 必須認証属性

  • アイデンティティ管理レルム内のグループの位置

  • アイデンティティ管理レルムに対する権限の割当(たとえば、誰がレルムに別のユーザーを追加する権限を持つかなど)

  • レルムに関するアプリケーション固有のデータ(認可など)

34.1.5 デフォルトのアイデンティティ管理レルムの概要

構成を簡単にするために、Oracle Internet Directoryのインストール時に、デフォルトのDITが作成され、デフォルトのアイデンティティ管理レルムが設定されます。

図34-5 デフォルトのアイデンティティ管理レルム

デフォルトのアイデンティティ管理レルム

図34-5に示されているとおり、デフォルトのアイデンティティ管理レルムはグローバルDITの一部です。ルートDSEのすぐ下のノードはdc=comで、その下にdc=MyCompany、次にdc=usが続きます。これらの4つのノードは、全体的なDIT構造を表します。ノードdc=usは、デフォルト・アイデンティティ管理レルムのルートです。ユーザーおよびグループの情報を含む2つのサブツリー(cn=Usersおよびcn=Groups)があります。説明上の理由から、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 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 Directory Managerを使用してレルム管理者のアカウントのパスワードを変更することにより、ロックを解除できます。

  • 認証サービスで適切な処理を実行できるようにするデフォルトの認証ポリシー。これには次のものがあります。

    • デフォルトのディレクトリ・パスワード・ポリシー(パスワードの長さ、ロックアウト、有効期限など)

    • ユーザーのプロビジョニングを行う際に自動生成される必要がある追加のパスワード・ベリファイア

  • アイデンティティ管理の権限。Oracle Internet Directoryによって、Oracle Internet Directoryセルフサービス・コンソールを介してこれらの権限を委任できるレルム管理者に付与されます。これらの権限の例は、次のとおりです。

    • 共通のアイデンティティ管理構成権限(ユーザーの作成、ユーザー・プロファイルの変更、グループの作成など)

    • Oracle Identity Managementインフラストラクチャを使用して新しいOracleコンポーネントをインストールする権限。

    • Oracle Internet Directoryセルフサービス・コンソールを管理する権限

      関連項目:

      • orclUserV2の詳細は、『Oracle Identity Managementリファレンス』のorclUserV2オブジェクト・クラスを参照してください

      • Oracle Identity Managementのデフォルトのアクセス制御ポリシーの詳細は、「Oracle Identity Managementの権限の委任」を参照してください

34.2 デフォルトのアイデンティティ管理レルムのカスタマイズ

次の各トピックでは、いくつかのユース・ケースに基づいて、デフォルトのアイデンティティ管理レルムのカスタマイズ方法について説明します。

34.2.1 デフォルトのアイデンティティ管理レルムのカスタマイズ

レルムを作成した後、その様々な要素をカスタマイズできます。

表34-2に、カスタマイズできる要素、各種のカスタマイズで使用可能なツールおよび参照先を示します。

表34-2 デフォルトのアイデンティティ管理レルムのカスタマイズ

カスタマイズ可能な対象 ツール 情報

ディレクトリ構造およびネーミング・ポリシー

Oracle Internet Directoryセルフサービス・コンソール

Oracle Directory Service Manager

コマンド行ツール

この項。

デフォルトのアイデンティティ管理レルムの概要

12cリリース2 (12.2.1.3.0)の『Oracle Fusion Middleware Oracle Identity Managerでのセルフ・サービス・タスクの実行』のOracle Internet Directoryセルフサービス・コンソールの使用に関する章。

認証ポリシー

Oracle Directory Service Manager

コマンド行ツール

パスワード・ポリシーの管理

アイデンティティ管理の権限

Oracle Internet Directoryセルフサービス・コンソール

Oracle Directory Service Manager

コマンド行ツール

Oracle Identity Managementの権限の委任

10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」

34.2.2 デフォルトのアイデンティティ管理レルムのカスタマイズのユース・ケースの理解

これが必要となる可能性がある典型的なシナリオは、Oracle Identity Managementインストールをサード・パーティ・ディレクトリと統合する場合です。

たとえば、デフォルトのアイデンティティ管理レルムがdc=mycompany,dc=comであり、cn=users,dc=mycompany,dc=comの下にユーザーが存在すると仮定します。

サード・パーティ・ディレクトリのネーミング・コンテキストが、デフォルト・レルム内のユーザーおよびグループの現在の検索ベースと一致しない場合は、既存のユーザーとサード・パーティのユーザーがどちらもOracle Single Sign-Onを使用してログインできるように、デフォルト・レルムのユーザーおよびグループの検索ベースを変更できます。既存のユーザーとサード・パーティのユーザーをともに含むことができて最も下位にあるユーザー検索ベースを選択します。この検索ベースを、最下位の共通ユーザー検索ベースと呼ぶことにします。

ノート:

このアプローチでは、Oracle Single Sign-Onのログインで選択されるユーザーのnickname属性が、既存のユーザー検索ベースとサード・パーティ・ディレクトリのネーミング・コンテキスト全体で一意であると仮定しています。そうでない場合、nickname属性の値が競合しているすべてのユーザーは、Oracle Single Sign-Onの認証に失敗します。

デプロイメント環境が次の1から5のユース・ケースのいずれかと一致する場合は、「既存のユーザーおよびグループの検索ベースの更新」で説明されている手順に従ってください。

ユース・ケース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です。

ユース・ケース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です。この使用例の場合、ユーザー検索ベースを変更する必要はありません。

ユース・ケース6

この場合、サード・パーティのネーミング・コンテキストはデフォルト・レルムの外部にあり、最下位の共通ユーザー検索ベースはルートDSEです。

たとえば、既存のユーザーがcn=users,dc=mycompany,dc=comの下に存在し、サード・パーティのネーミング・コンテキストがcn=users,dc=mycompanycorp,dc=netの下に存在する場合、最下位の共通ユーザー検索ベースは、ルートDSEです。

この場合、サード・パーティのネーミング・コンテキストを別の検索ベースとして追加する必要があります。ステップは次のとおりです。

  1. 追加の検索ベースの設定

  2. Oracle Single Sign-Onのリフレッシュ

  3. プロビジョニング・プロファイルの再構成

34.2.3 既存のユーザーおよびグループの検索ベースの更新

この項では、既存のユーザー・グループ検索ベースを更新する手順について説明します。

サード・パーティ・ディレクトリとの同期を設定するには:

  1. Oracle Internet Directoryデータベースをバックアップします。

  2. サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。

  3. 次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。

    1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

    2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。

  4. 次の手順に従って新規グループ・コンテナに適切なACLを適用します。

    1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

    2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。

  5. 既存のユーザーとサード・パーティのユーザーをともに含むことができる最下位の共通ユーザー検索ベースを決定します。

    たとえば、既存のユーザーが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の下に存在する場合です。この場合は、「追加の検索ベースの設定」で説明されているデプロイメント例までスキップしてください。

  6. グループも同期化する必要がある場合は、既存のグループとサード・パーティのグループをともに含むことができて最も下位にあるグループ検索ベースを決定します。この検索ベースを、最下位の共通グループ検索ベースと呼ぶことにします。

    たとえば、既存のグループがcn=groups,dc=mycompany,dc=comの下に存在し、サード・パーティのグループがl=emea,dc=mycompany,dc=comの下に存在する場合、最下位の共通グループ検索ベースは、dc=mycompany,dc=comです。

  7. レルムの管理者(通常はorcladmin)としてセルフサービス・コンソールにログインします。

  8. 「構成」タブに移動し、ユーザー検索ベースを決定した最下位の共通ユーザー検索ベースに設定します。グループも同期化する場合は、グループ検索ベースを決定した最下位の共通グループ検索ベースに設定します。

  9. Oracle Single Sign-Onにこれらの変更を認識させるため、「Oracle Single Sign-Onのリフレッシュ」で説明されている手順を実行します。

  10. orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。

  11. 変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。「プロビジョニング・プロファイルの再構成」で説明されているステップに従ってください。

ノート:

ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。

34.2.4 追加の検索ベースの設定

この項では、追加の検索ベースを設定する手順について説明します。

サード・パーティ・ディレクトリとの同期を設定するには:

  1. Oracle Internet Directoryデータベースをバックアップします。

  2. サード・パーティ・ディレクトリにまだエントリが存在しない場合、Oracle Directory Services Managerを使用してそのディレクトリにユーザー・コンテナおよびグループ・コンテナを作成します。

  3. 次の手順に従って新規ユーザー・コンテナに適切なACLを適用します。

    1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbsの変数%USERBASE%と%REALMBASE%をインスタンス化し、usracl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

    2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのusracl.ldifをアップロードします。

  4. 次の手順に従って新規グループ・コンテナに適切なACLを適用します。

    1. ACLテンプレート・ファイル$ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbsの変数%GRPBASE%と%REALMBASE%をインスタンス化し、grpacl.ldifファイルを作成します。変数%USERBASE%は新規ユーザー・コンテナの識別名に、変数%REALMBASE%はデフォルト・レルムの識別名に設定します。

    2. ldapmodifyコマンドを使用してインスタンス化したLDIFファイルのgrpacl.ldifをアップロードします。

  5. レルムの管理者としてセルフサービス・コンソールにログインします。

  6. 「構成」タブに移動します。

    1. 現在のレルムのusersearchbaseにcn=users,dc=mycompanycorp,dc=netを追加します。

    2. 現在のレルムのgroupsearchbaseにcn=groups,dc=mycompanycorp,dc=netを追加します。

  7. Oracle Single Sign-Onにこれらの変更を認識させるため、「Oracle Single Sign-Onのリフレッシュ」で説明されている手順を実行します。

  8. orcladminとしてログインし、元のユーザー検索ベースのユーザーによるOracle Single Sign-Onのログインを検証します。

  9. このアイデンティティ管理構成に基づいて中間層が構成されている場合、変更されたユーザーおよびグループ・ベースを反映するように、プロビジョニングされているアプリケーションも再構成する必要があります。「プロビジョニング・プロファイルの再構成」で説明されているステップに従ってください。

ノート:

ユーザーおよびグループの検索ベースの属性に加え、ログイン名(ニックネーム)の属性やRDNの属性など、アイデンティティ管理レルムの他の構成設定もセルフサービス・コンソールを使用して変更できます。詳細は、10g (10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』の「Oracle Internet Directoryセルフ・サービス・コンソールの使用方法」の章にある、アイデンティティ管理レルムの構成設定の変更に関する項を参照してください。

34.2.5 Oracle Single Sign-Onのリフレッシュ

この項では、Oracle Single Sign-onスクリプトをリフレッシュする方法を説明します。

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管理者ガイド』の付録「Single Sign-Onスキーマのパスワードの取得」を参照してください。
                        

                     

                     
                  

               
34.2.6 プロビジョニング・プロファイルの再構成
                  

                  

                     
ユーザーおよびグループの検索ベースを変更する前にデフォルトのアイデンティティ管理レルムに基づいて中間層アプリケーションをインストールしている場合、中間層のインストールによって作成されたプロビジョニング・プロファイルは、無効になります。この理由は、プロファイルのevent subscriptions属性に含まれるユーザーまたはグループの検索ベースの情報が古くなるためです。oidprovtoolを使用して、すべてのプロファイルを変更する必要があります。
                     

                     

                        
すべてのプロビジョニング・プロファイルを再構成するには:

                     

                     
                     
    
                        
  1. 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は、それぞれアプリケーションのインストールおよび構成時に作成したユーザー検索ベースとグループ検索ベースです。
                              
    
                           
    
                        
    2. 
                        
  2. GUIDに基づいてOracle Internet Directoryサーバーを検索することで、アプリケーション・アイデンティティの実際の識別名を取得します。アプリケーションの識別名を取得するには、次のように入力します。
    ldapsearch -h host -p port -D cn=orcladmin -q \
           -s sub -b "" \
           "orclguid=Value_of_orclODIPProvisioningAppGuid" dn

    provprofiles.ldifの属性値から各プロファイルのGUID値を取得できます。
                              
    
                           
    
                        
    3. 
                        
  3. 返された各プロファイルを次のように変更します。
    $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の値には、元のアイデンティティ・レルムの識別名を指定する必要があります。
                              
    
                           
    
                        
    4. 
                     

                  

               

            
34.3 ホスティングされたデプロイメント用の追加アイデンティティ管理レルムについて
               

               

                  
追加のアイデンティティ管理レルムは、Oracle Identity Management 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管理者ガイド』の「複数レルムでのシングル・サインオン」を参照してください。 
                     

                  

                  

                     
関連項目:

                     

                     
    
                        
  • 
                           
    『Oracle Identity Managementリファレンス』のoidrealmコマンドのリファレンス。
                           
    
                        
    • 
                        
  • 
                           
    静的グループ・エントリの属性の変更。
                           
    
                        
    • 
                        
  • 
                           
    アイデンティティ管理レルムの追加作成の詳細は、12cリリース2 (12.2.1.3.0)ライブラリの『Oracle Fusion Middleware Oracle Identity Managerでのセルフ・サービス・タスクの実行』の「Oracle Internet Directoryセルフサービス・コンソール」を参照してください。 
                           
    
                        
    • 
                     

                  

               

            
34.4 DITビューの作成
               

               

                  
11gリリース1 (11.1.1.9.0)以降では、異なるDITまたはソースDITのエントリを表示した仮想ビューまたはネームスペースであるDITビューを作成できます。次の項目がソースDITからDITビューのネームスペースに変換されます。

                  
    
                     
  • 
                        
    エントリ内の識別名とすべての識別名属性
    
                     
    • 
                     
  • 
                        
    DITビューで指定されている相対識別名マッピング
    
                     
    • 
                  

                  
DITビューによって、テナント全体の共通エントリに対するクラウド環境の記憶域要件全体が削減されます。DITビューでは、LDAPMODDN以外のすべての操作が可能です。DITビューでは、エントリ内の任意の属性から相対識別名属性の値を導出できるため、ユーザー名がエントリ識別名に表示される場合に元のエントリを非表示にできます。

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

                  
               
34.4.1 DITビューの指定
                  

                  

                     
次のコマンドを使用してDITビューを指定できます。

                     

                        
DITビューを指定するには、次の構文を使用します。
objectclass: orclditview
objectclass: extensibleobject
orclRDNAttrMapping:targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN]
orclDITBaseDN: realDN
orclrdnmapping: targetRDN:sourceRDN
orclreturnattr: orclmemberof
orclreturnattr: attrName


                     
                  

               
34.4.2 DITビューの構文
                  

                  

                     
この項では、orclditviewオブジェクト・クラスの項目について説明します。
                     

                     

                        
表34-3に、DITビューを指定するために使用する項目を示します。
                        

                     

                     
                     

                        
表34-3 DITビューの構文

                        

                           
                              

                                 項目
                                 説明
                              

                           
                           
                              

                                 
objectclass: orclditview

                                 
                                    
Oracle Internet Directoryサーバーに、DITビュー・マッピングのエントリを処理するように指示します。

                                 		
                              

                              

                                 
objectclass: extensibleobject

                                 
                                    
エントリでは、オプションで任意の属性を保持できます。

                                 		
                              

                              

                                 
orclRDNAttrMapping: targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN ]

                                 
                                    
ターゲット属性に対するソース属性のマッピングと、別の属性の値を使用するオプションを指定します。

                                    
    
                                       
  • 
                                          
    targetAttributeは、DITビューのエントリの相対識別名属性の名前です。
                                          
    
                                       
    • 
                                       
  • 
                                          
    sourceAttributeは、元のソース・エントリの相対識別名属性の名前です。
                                          
    
                                       
    • 
                                       
  • 
                                          
    valueFromAttributeは、RDN値の導出元となる属性です。ほとんどの場合、この値は、sourceAttributeと同じにすることができます。
                                          
    
                                       
    • 
                                       
  • 
                                          
    optionalRelativeDNは、オプションで、この相対識別名の下にある場合にのみサーバーで変換を実行するかどうかを指定します。
                                          
    
                                       
    • 
                                    

                                 		
                              

                              

                                 
orclDITBaseDN: realDN

                                 
                                    
元のソース・エントリの場所であるrealDNを指定します。たとえば:
                                    

                                    
ou=people,dc=us,dc=example,dc=com

                                 		
                              

                              

                                 
orclrdnmapping: targetRDN: sourceRDN

                                 
                                    
sourceRDNから宛先のtargetRDNに対する相対識別名マッピングを指定します。
                                    

                                 		
                              

                              

                                 
orclreturnattr: attrName

                                 
                                    
返却する複数値属性の名前を指定します。Oracle Internet Directoryサーバーは、これらの構成済属性のみを返します。

                                    
オプション。orclreturnattrが指定されていない場合、サーバーは、エントリのすべての属性を返します。
                                    

                                 		
                              

                              

                                 
orclmaskfilter: LDAP Filter

                                 
                                    
このLDAPフィルタを使用してエントリをマスクします。

                                 		
                              

                              

                                 
orclrdnfilter: LDAP Filter

                                 
                                    
このLDAPフィルタを使用して、orclrdnfilterが適用可能な場合にのみ、相対識別名マッピング変換を実行します。
                                    

                                 		
                              

                              

                                 
                                    
orclattrmapping:targetAttr:SourceAttr:overwrite

                                 		
                                 
                                    
SourceAttrからtarget Attrに値をコピーします。overwriteを1に設定すると、targetAttrの値にはsourceAttrからの値のみが含まれます。それ以外の場合、既存のtargetAttrの値に追加されます。
                                    

                                 		
                              

                              

                                 
                                    
orclattrexclude: attrName: specificValue

                                 		
                                 
                                    
属性または属性の特定の値を除外できます。specificValueパラメータはオプションです。
                                    

                                 		
                              

                              

                                 
orclalternateDITDN: AlternateDN


                                 
                                    
orclDITBaseDNで検出されない場合に、別のコンテナのエントリを検索できます。これは単一値構成です。
                                    

                                    
ノート: Oracle Internet DirectoryサーバーがorclDITBaseDNとorclalternateDITDNの使用時期を判別できるようにorclmaskfilterを構成する必要があります。

                                 		
                              

                           
                        

                     

                     
                  

               
34.4.3 DITビューの条件について
                  

                  

                     
この項では、DITビューの条件について説明します。

                     
DITビューを使用する場合、次の条件に留意する必要があります。

                     
    
                        
  • 
                           
    マップされるDITビューのエントリの相対識別名属性には、カンマ(,)、プラス記号(+)、等号(=)、セミコロン(;)、ハッシュ(#)、バックスラッシュ(\)、より小さい(<)、より大きい(>)などの特殊文字を含めることはできません。
    
                        
    • 
                        
  • 
                           
    マップされるDITビューのエントリの相対識別名属性は、uniqueness属性が有効化された単一値属性である必要があります。
                           
    
                        
    • 
                        
  • 
                           
    DITビューからorclmemberof属性の別名(memberof/ismemberof)を取得する場合、DITビューの作成時に、次のように返却属性リストの別名を指定する必要があります。
                           
    orclreturnattr: orclmemberof

    • 
                     

                  

               
34.4.4 DITビューの例
                  

                  

                     
次の例では、実際のエントリがDITビュー・エントリに変換されます。

                     

                        
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:
displayname=user.1,ou=people,dc=uk,dc=example,dc=com

たとえば:
dn: ou=people,dc=uk,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=people,dc=us,dc=example,dc=com

次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.comはmail属性の値です)。
                        

                        
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:
displayname=user.1@example.com,ou=people,dc=ind,dc=example,dc=com

たとえば:
dn: ou=people,dc=ind,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=People,dc=us,dc=example,dc=com
ou: people

次の例では、実際のエントリがDITマップ・エントリに変換されます(user.1@example.comはmail属性の値です)。
                        

                        
実際のエントリ:
uid=user.1,ou=people,dc=us,dc=example,dc=com

DITビュー・エントリ:
displayname=user.1@example.com,cn=users,cn=common,dc=example,dc=com

たとえば:
dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
cn: common

次の例では、属性構成が返されます。この構成は、エントリがこのツリーで検索されると、uid、mail、cnおよびsn属性のみが返されることを示しています。他の属性を持つエントリを追加または更新する場合、この制限は適用されないため、他の属性を持つエントリを追加できることに注意してください。
                        
dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
orclreturnattr: cn
orclreturnattr: uid
orclreturnattr: mail
orclreturnattr: sn
cn: common

次の例で、属性マッピングについて説明します。構文は次のとおりです。
orclattrmapping=targetAttr:SourceAttr:overWrite

overWriteが1に設定されている場合、targetAttrの既存の値は削除されます。overWriteが0に設定されている場合、targetAttrの既存の値にsourceAttrの値が追加されます。
                        
dn: cn=ditview,dc=oracle,dc=com
changetype: modify
replace: orclattrmapping
orclattrmapping: cn:mail:0     
orclattrmapping: sn:givenname:1

次の例で、属性の値を除外する方法について説明します。構文は次のとおりです。
orclattrexclude: attribute: optionalValue

dn: cn=ditview,dc=oracle,dc=com
changetype: modify
orclattrexclude: objectclass:orgperson
orclattrexclude: authpassword
orclattrexclude: userpassword

次の例で、代替ベース識別名について説明します。
dn: cn=filteredusers,dc=oracle
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclditbasedn: ou=people,dc=us,dc=oracle,dc=com
orclalternateditdn: ou=contractors, dc=us,dc=oracle,dc=com
orclmaskfilter: (employeetype=regular)
cn: filteredusers