| Oracle Access Managerインストレーション・ガイド 10g（10.1.4.3） B55482-01 |
|
 戻る |
 次へ |
この付録では、Active Directoryと一緒に使用する際のOracle Access Managerの前提条件、インストールおよび設定についてまとめています。次の項目について説明します。
また、Oracle Access ManagerとActive Directoryの間の通信プロトコルとして、LDAP（デフォルト）、LDAP over SSLおよびActive Directory Service Interfaces（ADSI）（オプション）のすべてを使用する構成についての基本情報も示します。
『Oracle Access Manager IDおよび共通管理ガイド』にも次の事項の詳細が含まれています。
ADSIのためのOracle Access Managerの構成
LDAPを使用するActive DirectoryのためのOracle Access Managerの構成
Active Directoryに対するOracle Access ManagerのデプロイとActive Directoryの特定機能のためのOracle Access Managerの構成
.NET機能のためのOracle Access Managerの構成
ここでは、Active Directoryの動作の概要について説明します。「Oracle Access ManagerとActive Directoryについて」も参照してください。Active Directoryは、ネットワークの1つ以上のドメインにオブジェクトの情報を格納して、その情報をユーザーやネットワーク管理者が使用できるようにします。
Active Directoryのドメインはオブジェクトのコレクションの管理境界を定義し、この境界はネットワーク上の特定のユーザー・グループに関連します。
ドメイン・コントローラは、ディレクトリ・パーティション（ネーミング・コンテキスト）を格納します。これは、不連続の単位としてレプリケートされた、Active Directoryの論理分散セグメントに対応しています。
複数のツリーまたはドメインをサポートするActive Directoryは、Active Directory Forestと呼ばれます。Active Directoryは、ディレクトリ情報の論理的階層編成として構造化データ・ストアを使用します。Active Directoryに含まれる内容を次に示します。
ディレクトリに含まれるオブジェクトや属性のクラスを定義するスキーマ、これらのオブジェクトのインスタンスに対する制約と制限、これらのオブジェクト名の形式。
ドメイン・コントローラは、ディレクトリ・パーティション（ネーミング・コンテキスト）を格納します。これは、不連続の単位としてレプリケートされた、Active Directoryの論理分散セグメントに対応しています。
複数のツリーまたはドメインをサポートするActive Directoryは、Active Directory Forestと呼ばれます。Active Directoryは、ディレクトリ情報の論理的階層編成として構造化データ・ストアを使用します。Active Directoryに含まれる内容を次に示します。
ディレクトリに含まれるオブジェクトや属性のクラスを定義するスキーマ、これらのオブジェクトのインスタンスに対する制約と制限、これらのオブジェクト名の形式。
グローバル・カタログ。Active Directoryのフォレストのすべてのオブジェクトのコピーを格納するドメイン・コントローラです。アプリケーションやクライアントがフォレスト内の任意のオブジェクトを探すときに問い合せることができます。これはOracle Access Managerでは不要になりました。
問合せと索引のメカニズム。オブジェクトとそのプロパティをネットワーク・ユーザーまたはアプリケーションが公開して検索できます。
レプリケーション・サービス。スキーマ、構成、アプリケーション、およびドメイン・コントローラ間のドメイン・ディレクトリ・パーティションを同期化し、ネットワーク上にディレクトリ・データを分散します。
Active Directory Forest内のすべてのActive Directoryサーバー（ドメイン・コントローラ）は、レプリケーションを行い、そのドメインのすべてのディレクトリ情報の完全なコピーを含みます。ディレクトリ・データを変更すると、ドメイン内のすべてのドメイン・コントローラにレプリケートされます。Active Directory Forestのすべてのドメイン・コントローラには、3つの書込み可能なフル・ディレクトリ・パーティションが格納されています。Active Directoryのディレクトリ・パーティションは、フォレスト内の他のドメイン・コントローラに1つのユニットとしてレプリケートされる、連続したActive Directoryサブツリーです。ドメイン・コントローラには同じサブツリーのレプリカが含まれます。
1つのドメイン・コントローラには常に少なくとも3つのディレクトリ・パーティションがあります。
スキーマ: フォレストごとに1つ。ディレクトリのクラスと属性の定義を含みます。
構成: フォレストごとに1つ。レプリケーション・トポロジと関連するメタデータを含みます。
ドメイン: 1つのフォレストに多数。1ドメインに対してドメイン当たりのオブジェクトを含む1つのサブツリーを含みます。
Oracle Access Managerでは、Windows Server 2000およびWindows 2003 ServerプラットフォームでのActive Directoryをサポートしています。Windows Server 2003, Web Editionを実行するサーバーでは、次のようになります。
Windows Server 2003, Web Editionを実行するサーバーにはActive Directoryをインストールできません。
Windows Server 2003, Web EditionサーバーをActive Directoryドメインにメンバー・サーバー（ドメイン・コントローラではない）として追加できます。
Oracle Access Managerでは、ユーザー・データを構成データやポリシー・データとは別のタイプのディレクトリ・サーバーに格納することができます。詳細は、「データ記憶域の要件」および「ADSIオプションの考慮事項」を参照してください。Oracle Access Managerではグローバル・カタログの使用は必要ありません。Oracle Access Managerでは、構造型オブジェクト・クラスと補助オブジェクト・クラスがサポートされます。構造型オブジェクト・クラスはスタンドアロン可能です。Oracle Access Managerアプリケーション内で使用するために必要な基本属性を含んでいます。構造型オブジェクト・クラスは、Oracle Access Managerアプリケーションでタブを作成するときに割り当てる必要があります。補助オブジェクト・クラスはスタンドアロン不可です。構造型オブジェクト・クラスにはなくてもよい補足的な属性（請求書送付先、チャレンジ・フレーズ、チャレンジ・フレーズのレスポンスなど）を含んでいるためです。補助オブジェクト・クラスは、既存の構造型オブジェクト・クラスに基づくエントリに割り当てる必要があります。Oracle Access Managerでは、UserとGroupに加えて、InetOrgpersonとGroupofUniqueNamesがそれぞれ標準のPersonオブジェクト・クラスおよびGroupオブジェクト・クラスとしてサポートされます。また、Oracle Access Managerでは、静的リンク補助クラスと動的リンク補助クラスがサポートされます。詳細は、「Oracle Access ManagerとActive Directory Forestについて」および「Active Directoryに対するインストールと設定の考慮事項」を参照してください。
Windows Server 2000では、Active Directoryは静的リンク補助クラスのみをサポートし、スキーマ定義そのもので補助クラスを別のobjectclassに静的にリンクできるようにしていました。静的リンク・オブジェクト・クラスは、スキーマ内で、オブジェクト・クラスのclassSchema定義のauxiliaryClass属性またはsystemAuxiliaryClass属性に含まれています。静的リンク・オブジェクト・クラスは、関連付けられるクラスのすべてのインスタンスの一部です。静的リンク補助クラス（Oracle Access Managerのデフォルト）に関してActive Directoryに実装するスキーマを設計するときは、次のようにします。
oblixOrgPersonオブジェクトとoblixPersonPwdPlicyオブジェクトをユーザー（Person）オブジェクト・クラスに定義します。
oblixGroupとoblixAdvancedGroupをGroupオブジェクト・クラスに定義します。
詳細は、「静的リンク補助クラスのためにスキーマを変更する手順」を参照してください。
Windows 2003 Serverでは、Active Directoryは、個々のオブジェクト（オブジェクトのクラス全体ではない）への補助クラスの動的なリンクをサポートしています。この場合、あるエントリのオブジェクトのobjectclass属性の値に、補助オブジェクト・クラスの名前を追加します。補助クラスに必須属性がある場合は、それらも同時に設定する必要があります。
動的リンクにより、クラス全体のスキーマ定義を拡張してフォレスト全体に影響を与えずに、個々のオブジェクトに追加の属性を格納できます。たとえば、企業は動的リンクを使用することで、販売固有の補助クラスを販売員のユーザー・オブジェクトに追加し、他の部署固有の補助クラスを他の部署の従業員のユーザー・オブジェクトに追加できます。
Oracle Access Managerでは静的な補助スキーマが提供されます。これにより、補助クラスとそれに対応する構造型オブジェクト・クラスの関連がスキーマに指定されます。静的補助クラスを使用すると、Oracle Access Managerは、追加や削除のために補助クラスのobjectclass属性を更新しません。動的補助のサポートでは、そのような別のスキーマ・ファイルはなく、Oracle Access Managerは必要に応じてobjectclass属性を補助クラス名で更新します。
アイデンティティ・サーバーの設定およびアクセス・システムのインストールと設定の際に、ターゲット・ディレクトリで動的リンク補助クラスをサポートするかどうかが確認されます。次に示す概要で、動的リンク補助クラスを実行時にOracle Access Managerに関連付けるためのタスクを説明しています。
Oracle Access Managerでは、静的リンク補助クラスと動的リンク補助クラスをサポートしていますが、両方は同時にサポートされません。
|
警告: 動的補助クラスがサポートされるのは、フォレストのすべてのドメイン・コントローラがWindows Server 2003を実行しており、フォレストの機能モデルがWindows Server 2003である場合です。2003ドメイン・コントローラとそれ以前のドメイン・コントローラが混在する環境はサポートされません。フォレストのレベルを上げた後にはActive Directoryサーバーを再起動してください。 |
Oracle Access Managerをインストールする前に、Active Directoryのドメインとフォレストの機能が、Microsoft社のドキュメントに説明されているようにWindows 2003 Serverレベルで作動していることを確認する必要があります。
アイデンティティ・システムのインストールと設定の際に、第4章「アイデンティティ・サーバーのインストール」と第6章「アイデンティティ・システムの設定」の説明に従って動的リンク補助クラスを指定します。
ポリシー・マネージャのインストールと設定の際に、第7章「ポリシー・マネージャのインストール」の説明に従って動的リンク補助クラスを指定します。
アクセス・サーバーのインストールの際に、第8章「アクセス・サーバーのインストール」の説明に従って動的リンク補助クラスを指定します。
インストールと設定の後で、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従ってOracle Access Managerで動的補助クラスのサポートを構成します。
Oracle Access Managerの以前のバージョンでは、1つのActive Directory Forest内にしかOracle Access Managerをインストールすることができませんでした。図A-1に、3つのドメインRoot_domain、Sub_domainおよびDisjoint_domainを含む1つのActive Directory Forestを示します。
現在、Oracle Access Managerコンポーネントは、Active Directory Forest内にOracle Access Managerのユーザー・データ、構成データおよびポリシー・データと一緒に存在することも、Oracle Access Managerデータを含むフォレストの外部に存在することもできます。Oracle Access Managerコンポーネントを1つのActive Directory Forest内にインストールした場合は、Oracle Access ManagerとActive Directoryの間で次のいずれかの通信プロトコルを使用できます。
LDAP（デフォルト）
LDAP over SSL
ADSI
図A-2に、1つのフォレスト（フォレスト1）にインストールされたOracle Access Managerコンポーネントを示します。ユーザー・データ、構成データおよびポリシー・データはもう1つのフォレスト（フォレスト2）にあります。このタイプの構成は、フォレスト外のOracle Access Managerとも呼ばれます。ADSIの使用はオプションです。
2フォレスト構成では、1つのフォレストにある1つのドメイン・コントローラ（スキーマ・マスター）が、スキーマ・ディレクトリ・パーティションに対するすべての変更を処理します。1フォレストにつき1つのドメイン・コントローラ（ドメインネーミング・マスター）が、ドメイン名がフォレスト内で一意になるように管理し、外部ディレクトリに対するオブジェクトのクロスリファレンスが維持されるようにします。詳細は、Microsoft社のドキュメントを参照してください。2フォレスト構成では、ユーザー・データ、ポリシー・データおよび構成データを含むフォレストとOracle Access Managerサーバーがインストールされているフォレストとの間に信頼関係を設定する必要はありません。1つのフォレストに構成データとポリシー・データを含み、別のフォレストにユーザー・データを含む環境も可能です。
Active Directoryドメインは、階層を形成する親子関係として編成できます。親ドメインとは、階層内で、1つ以上の下位ドメイン（子ドメイン）のすぐ上にあるドメインです。子ドメインも、1つ以上の子ドメインの親になることができます。Oracle Access Managerの検索ベースによって、データが格納されるディレクトリ情報ツリーのノードと、すべての検索に対する最高位のベースが定義されます。ただし、子ドメイン内のエントリを探すことはできません。デフォルトのOracle Access Managerディレクトリ・サーバー・プロファイルは、Root_domainのみに対して作成されます。インストール内のその他のドメイン（たとえば、Disjoint_domainやSub_domain）のディレクトリ・プロファイルは設定する必要があります。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。アクセス・システムでは、認証時にはcredential_mappingプラグインを使用してサブツリーレベルの検索が実行されます。また、認可時にも、検索がサブツリーレベルで行われることがLDAPルール（たとえばLDAP URL）によって明示的に指定されていると、サブツリーレベルの検索が実行されます。LDAP URLを含むObMyGroupsアクションを使用すると、ユーザーが所属するすべてのグループが返されます。表A-1に、親子ドメインをサポートする構成をまとめています。
表A-1 親子ドメインをサポートする構成
| 機能 | 親子ドメインの構成 |
|---|---|
|
認証 |
資格証明のマッピングを使用して、親ドメインと子ドメインの両方に対してユーザーを認証する。 Oracle Access Manager credential_mappingプラグインを使用して、ユーザーのDNを取得できる。Active Directory Forestの場合、credential_mappingプラグインの典型的なパラメータは次のとおり。 credential_mapping?ObMappingBase="%domain%, ObMappingFilter="(&(objectclass=user) (samaccountname=%login%))", Obdomain="domain" accountname=%login%))", Obdomain="domain" |
|
認可 |
複数のLDAP URLを認可ルール内で使用する。 |
|
ObMyGroups |
LDAP URLを含むObMyGroupsを使用する。ユーザーが親ドメインと子ドメイン両方のグループに所属する場合は、各ドメインのグループに対して別のヘッダー変数を定義する必要がある。 URLなしでObMyGroupsを使用すると、アクセス・システムの検索ベースのみからグループが返される。検索ベースが親ドメインのものである場合、子ドメインのグループはまったく取得されない。 たとえば、2つのドメインがあり、両方の検索ベースからグループを取得する場合は、次のように指定する。 dc=goodwill,dc=oblix,dc=com and dc=dilbert,dc=goodwill,dc=oblix,dc=com この場合は、各ドメインに1つずつ2つのヘッダー変数が必要。 Return Type Name Return Attribute headervar HTTP_PARENT_GROUP "obmygroups:ldap:///dc=goodwill,dc=oblix,dc=com??sub?(group_type=role)" headervar HTTP_CHILD_GROUP "obmygroups:ldap:///dc=dilbert,dc=goodwill,dc=oblix,dc=com??sub?(group_type=role)" HTTP_PARENT_GROUP: "dc=goodwill,dc=oblix,dc=com"ツリー（ログイン・ユーザーがメンバー、group_typeが"role"）のすべてのグループが返される。 HTTP_CHILD_GROUP: "dc=dilbert,dc=goodwill,dc=oblix,dc=com"ツリー（ログイン・ユーザーがメンバー、group_typeが"role"）のすべてのグループが返される。 |
Active Directoryに対するOracle Access Managerのインストールを開始する前に見なおすことができるように、各考慮事項の概要を次のようにまとめています。
Active Directory 2000とActive Directory 2003のスキーマ、およびそれらのスキーマがOracle Access Managerに適用される方法にはいくつかの違いがあります。
鍵の違い: Windows 2000スキーマ（ADSchema.ldif）とWindows 2003スキーマ（dotnetschema.ldif）（Oracle Access Managerに関連）の鍵の大きな違いは、inetOrgPersonとgroupofuniquenamesをサポートするかどうかです。これら2つのオブジェクト・クラスは、他のほとんどのLDAPディレクトリに存在しており、Windows 2003スキーマには正式に追加されました。inetOrgPersonオブジェクト・クラスの追加により、このオブジェクト・クラスを使用してOracle Access Managerを構成することができます。Windows 2000の場合のように手動でこのオブジェクト・クラスを追加する必要はありません。
Oracle Access Managerスキーマ・ファイルへの影響: Oracle Access Manager Windows 2000スキーマ・ファイル（ADschema.ldif）とWindows 2003スキーマ・ファイル（ADdotnetschema.ldif）の主な違いについて次に説明します。
次のエントリは、ADSchema.ldifにはありますがADdotnetschema.ldifにはありません。
dn: cn=groupOfUniqueNames,cn=schema,cn=configuration,<domain-dn> dn: cn=uniquemember,cn=schema,cn=configuration,<domain-dn>
oblixgroupofuniquenamesクラス定義は2つのファイルで異なります。これは、2000スキーマ・ファイルでのgroupofuniquenamesの定義方法と、Microsoft社による2003スキーマでのgroupofuniquenamesの実装方法の違いによるものです。
2つのスキーマのobjectclassの違い: 2つのスキーマのobjectclassがどのように異なるかを次に示します。
ADSchema.ldif:
必須属性: 必須の属性はありません。
オプション属性:
obuniquemember
businesscategory
obver
ADdotNetschema.ldif:
必須属性: cn businesscategory obuniquemember obver description o ou
owner seeAlso uniqueMember
ADschema.ldifというファイルがWindows 2000のOracle Access Managerスキーマ・ファイル、ADdotnetschema.ldifというファイルがWindows 2003のOracle Access Managerスキーマ・ファイルです。環境にロードするスキーマを決めるときは、次の点を考慮してください。
ADdotnetschema.ldif: Windows 2000とWindows 2003のどちらを実行しているかに関係なく、Active Directory 2003スキーマをロードしている場合は、.NETSchema（Windows 2003スキーマ）を使用してOracle Access Managerをインストールします。
たとえば、企業によっては、Windows 2003へのアップグレード準備として既存のWindows 2000ドメインにWindows 2003スキーマをロードしていることがあります。このような場合は、Oracle Access ManagerをインストールするときにADdotnetschema.ldifファイルを使用する必要があります。
ADschema.ldif: Windows 2000スキーマがある場合はWindows 2000スキーマをロードします。
|
注意: スキーマ・ファイルを手動でロードしない場合は、Windows 2003をインストールしているかという質問に対するユーザーの回答に基づいて、使用するスキーマ・ファイルをインストーラが決定します。Windows 2003をインストールしていると回答した場合は、インストーラがADdotnetschema.ldifを使用します。 |
スキーマ・タイプの判別: 環境にWindows 2000スキーマとWindows 2003スキーマのどちらがあるかを判別する簡単な方法は、スキーマ・スナップインを使用して、2003スキーマの新しい文字列構文を検索することです。次に例を示します。
2000スキーマでは、文字列型にattributesyntax 2.5.5.12のUnicode形式が使用されていました。
2003スキーマでは、新しい構文IA5 attributesyntax 2.5.5.5., omysyntax: 22に変更されています。
Active Directoryに対するすべてのOracle Access Managerインストールの概要を次に説明します。アイデンティティ・サーバーとアクセス・システムのインストールと設定の手順では、時間を節約しエラーを防ぐために自動スキーマ更新を受け入れることをお薦めします。後でいつでも変更できます。ただし、手動スキーマ更新の場合、環境によっては設定プロセスで次の1つ以上のファイルを使用する必要があります。
Windows 2003の動的リンク補助クラスでは、次の1ファイルのみが必要です。
\install_dir\identity|access\oblix\data\common\ADDotNetSchema.ldif
ldifde -i credentials -c "<domain-dn>" "your domain" -f ADDotNetSchema.ldif
Windows 2003の静的リンク補助クラスでは、次の2つのファイルが両方とも必要です。
\install_dir\identity|access\oblix\data\common\ADDotNetSchema.ldif \install_dir\identity|access\oblix\data\common\ADAuxSchema.ldif
Windows 2000では次の1ファイルのみが必要です。
\install_dir\identity|access\oblix\data\common\ADSchema.ldif
メイン管理者、スキーマ管理者、グループ・ポリシー管理者、エンタープライズ管理者、ドメイン管理者、ユーザー、管理者のメンバーに管理ユーザーのプロパティを追加することをお薦めします。次のガイドラインは、Active Directoryと一緒に使用するOracle Access Managerのすべての構成に適用されます。
ガイドライン: Active Directoryに対するOracle Access Managerのインストール
Oracle Access Managerのインストールと設定の際には、使用するActive Directoryのバージョンを指定し、関連する質問に適切に回答してください。
Oracle Access Managerのインストールと設定の際には、アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーで同じ構成DNを使用します。
|
注意: マルチ・ドメイン・フォレストのログイン名は、アクセス・サーバーDBプロファイルの表示名です。 |
インストールと設定の後で、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、Active Directoryの認証スキーム（1つまたは複数）を作成または変更できます。
インストールと設定の後で、次の行をアイデンティティ・サーバーのglobalparams.xmlに追加して、Active Directory上の大容量の動的グループを拡張できます。
<SimpleList>
<NameValPair ParamName="maxForRangedMemberRetrieval"
Value="1500"/
</SimpleList>
ADSIを使用する構成の概要を次に説明します。ADSIの使用はオプションです。
ADSIの資格証明は、フォレスト全体にバインドするために使用されます。1つのフォレストは複数のActive Directoryホストを含むことができます。ユーザー・データと構成データが別のフォレストの別のActive Directoryホストに格納されている場合は、ADSIを使用してこれらのデータに同時に接続することはできません。詳細は、「このDBプロファイルでADSIを有効化できない（Active Directory）」を参照してください。
ADSIでは、フォレストの様々なドメインについて具体的なホストやポート番号は必要ありません。ADSIは、次のようなLDAP URLを使用してActive Directoryのホストに接続します。
LDAP://domain.oracle.com/ou=oblix,dc=domain,dc=oblix,dc=com
ユーザー・データと構成データが同じフォレストの別のActive Directoryホストに格納されている場合は、ADSIを使用してこれらのデータに接続できます。データの検索と変更は、ドメインネーミング・コンテキストを使用して、フォレストのそれぞれのActive Directoryサーバーで行われます。
インストールの際に、構成データをユーザー・データ・ディレクトリに格納するかどうかを確認されます。ユーザー・データと構成データが同じフォレストの別のActive Directoryホストに格納されており、ユーザー・ツリーにADSIを使用するときは、構成データをユーザー・データ・ディレクトリに格納するように指定してください。ユーザー・データと構成データを別に格納するように指定すると、ADSIを使用して構成データ・ディレクトリ・サーバーに接続できなくなり、「アイデンティティ・システム・コンソール」ページで「ADSI」を選択して構成データのDBプロファイルを作成できなくなります。ただし、LDAPを使用すれば構成データ・ディレクトリ・サーバーに接続できます。
フォレスト全体でADSIを使用するとき、マスター管理者の資格証明は、フォレスト全体の管理権限を含むエンタープライズ管理者の資格証明であることが必要です。
フォレスト全体で同じユーザー・ツリー資格証明を有効にする必要があります。ユーザー・ツリーに対してADSIを構成し、構成ツリーとポリシー・ツリーに対してLDAPを構成するように決めた場合は、設定が完了した後で、globalparamsファイルのパラメータを変更して、適切なプロファイルを定義することができます。『Oracle Access Manager IDおよび共通管理ガイド』の説明を参照してください。
Oracle Access Managerのデータとコンポーネントが同じドメインにあるときは、アイデンティティ・システムをインストールおよび設定した後で、パスワード変更権限を持つ特権管理ユーザーのコンテキストでアイデンティティ・サーバーを実行する必要があります。
別のフォレストにある構成データおよびポリシー・データとは別のActive Directoryサーバーにユーザー・データを格納するとき、いずれかに接続するためにADSIを使用できますが、両方に接続することはできません。
Oracle Access Managerのインストール時: 構成データをユーザー・データと一緒に格納するかどうかを確認されたら「はい」を選択し、ユーザー・データ・ディレクトリ・サーバーには「ADSI」を選択します（構成データに対するADSIについては確認されません）。
Oracle Access Managerの設定時: DBプロファイルのディレクトリ・タイプを次のように指定します。
ユーザーDBプロファイル: Microsoft Active DirectoryおよびADSI
構成DBプロファイル: Microsoft Directoryのみ（ADSIなし）
Oracle Access Managerのコンポーネントが1つのドメインにありデータがもう1つのドメインにある場合は、Oracle Access ManagerコンポーネントとActive Directoryの間でADSIまたはLDAPを使用できます。
インストールと設定の際に、Oracle Access Managerは、アイデンティティ・サーバー上のadsi_params.xmlファイルとポリシー・マネージャ上のadsi_params.lstファイルの特定のパラメータを自動的に更新します。これらのファイルのパスを次に示します。
\IdentityServer_install_dir\identity\oblix\config\adsi_params.xml \AccessServer_install_dir\access\oblix\config\adsi_params.xml
これらのファイルには、ユーザー・バインドDNのuseImplicitBind値が含まれています。表A-2に、指定可能なバインド・パラメータをまとめています。
表A-2 指定可能なバインド・パラメータのまとめ
| useImplicitBind値 | 定義 | 説明 |
|---|---|---|
|
0 |
現在のプロセスの暗黙の資格証明をバインドで使用する。 |
1つのActive Directory Forest adsi_params.xmlファイルでのアイデンティティ・サーバーのデフォルト。 |
|
1 |
ユーザーのDNによる明示的な資格証明をバインドで使用する。 |
2つのActive Directory Forest adsi_params.xmlファイルと.lstファイルでuseImplicitBind値を1に設定する。 |
|
2 |
バインドでuserPrincipalNameを使用する。 |
2つのActive Directory Forest
|
ADSIの使用時に設定する各パラメータについて次に説明します。
useImplicitBind=1: useImplicitBindの値が1の場合は、アイデンティティ・サーバーでサービス・ログイン資格証明を設定する必要はありません。Oracle Access Managerのコンポーネントとデータが別のフォレストにある場合は、useDNSPrefixedLDAPPaths=trueを設定します。
implicitBind=0: implicitBind=0を使用する場合は、IIS匿名ユーザーの権限をドメイン・ユーザーに設定する必要はありません。デフォルトは、implicitBind=0、useDNSPrefixedLDAPPaths=falseです。
この場合、ADSIはActive Directoryサーバーにバインドするためにプロセスのコンテキストを使用します。デフォルトでは、匿名ユーザー（IWAM*）にはディレクトリ・サーバーの権限はありません。
useDNSPrefixedLDAPPath: adsi_params.xmlファイルおよびadsi_params.lstファイルのuseDNSPrefixedLDAPPathパラメータを使用して、ドメイン名をLDAP文字列の接頭辞にすることができます。デフォルト値はfalseです。
Oracle Access Managerをインストールする前に、Microsoft社のドキュメントと「環境の設定」の説明に従って、Active Directoryを設定する必要があります。
アイデンティティ・サーバーのインストールの際に、第4章「アイデンティティ・サーバーのインストール」と「アイデンティティ・システムのインストール」の説明に従ってADSIを有効にします。
アイデンティティ・システムを設定する前に、「ADSIの設定（オプション）」の手順を実行します。
アイデンティティ・システムの設定の際に、第6章「アイデンティティ・システムの設定」と「アイデンティティ・システムの設定」の説明に従ってADSIを指定します。
ポリシー・マネージャのインストールと設定の際に、第7章「ポリシー・マネージャのインストール」と「アクセス・システムのインストールと設定」の説明に従ってADSIを指定します。
アクセス・サーバーのインストールの際に、第8章「アクセス・サーバーのインストール」の説明に従ってADSIを有効にし、「アクセス・サーバーでのADSIの設定（オプション）」にある追加の手順を実行します。
図18のようにOracle Access ManagerコンポーネントとOracle Access Managerデータが別のフォレストにある場合は、アイデンティティ・システムとアクセス・システムを設定する前に、次のタスクを実行します。
インストールと設定の後で、Oracle Access Manager adsi_paramsファイルでパラメータと値が次のように設定されていることを確認してください。次に例を示します。
\IdentityServer_install_dir\identity\oblix\config\adsi_params.xml \AccessServer_install_dir\access\oblix\config\adsi_params.xml
NameValPair ParamName="useDNSPrefixedLDAPPaths
Value="true"
\IdentityServer_install_dir\identity\oblix\config\adsi_params.xml
NameValPair ParamName="adsiCredential"
Value="cn=Administrator,cn=users,dc=goodwill,dc=oblix,dc=com"
adsi_paramsファイルおよびパラメータの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
次に概要を示します。LDAPオープン・バインドは、Oracle Access Managerとディレクトリ・サーバーの間のデフォルト（指定がない場合に使用される）の通信方法です。LDAPオープン・バインドをOracle Access ManagerコンポーネントとActive Directoryの間で使用する場合は、Oracle Access Managerのインストールと設定の際に追加の手順を実行することをお薦めします。
Oracle Access Managerをインストールする前に、Microsoft社のドキュメントと「環境の設定」の説明に従って、Active Directoryを設定する必要があります。
アイデンティティ・システムのインストールと設定の際に、Oracle Access ManagerとActive Directoryの間にSSL接続がないことを必ず指定してください。
アクセス・サーバーのインストールの後で、LDAPのフェイルオーバー情報とタイムアウト、およびポート番号を指定するように求められます。
アクセス・サーバーをActive Directoryに対してインストールするときは、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って必ずタイムアウトを構成してください。
フェイルオーバー情報は、後から『Oracle Access Managerデプロイメント・ガイド』の説明に従って再構成できます。
次に概要を示します。LDAP over SSLをOracle Access ManagerコンポーネントとActive Directoryの間で使用する場合は、Oracle Access Managerのインストールと設定の際に追加の手順を実行してください。
ガイドライン: SSLの設定
Oracle Access Managerをインストールする前に、「環境の設定」の説明に従って、コンピュータに証明書があることを確認します。
インストールと設定の後で、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従ってディレクトリ・サーバーとの通信を再構成できます。
ADSIを有効化した状態でディレクトリ・サーバーとの通信を再構成する場合は、adsi_params.xmlファイルとadsi_params.lstファイルを編集して暗号化パラメータをfalseにリセットする必要もあります。
これまでに説明した考慮事項に注意して、Active Directoryの設定とOracle Access Managerのインストールを行うことができます。次に、すべての手順と実行する順序を説明します。
タスクの概要: Active Directoryに対するOracle Access Managerのインストール
タスク概要のこれらの項目には複数の手順が含まれることがあります。その場合は、さらにタスク概要を示して、手順を実行する順序を説明します。
次に、Oracle Access Managerコンポーネントをインストールする前にActive Directoryを設定する方法の概要を示します。
Oracle Access Managerコンポーネントをインストールする前に、ドメイン・コントローラを設定する必要があります。
|
警告: 動的リンク補助クラスを有効化する予定がある場合は、Microsoft社のドキュメントの説明に従って、ドメインとフォレストの両方をWindows 2003 Serverレベルに上げる必要があります。 |
ドメイン・コントローラを準備する手順
Microsoft社の指示に従って、Active Directory Forestの各コンピュータのドメイン・コントローラを設定して構成します。
Microsoft社の指示に従って、すべての補助クラスについて、動的リンク補助クラスと静的リンク補助クラスのどちらの方法にするかを指定します。
LDAP over SSLを使用する場合、Microsoft CA Certificate Serverをインストールして証明書を取得する必要があります。
|
注意: LDAP（デフォルト）またはADSIを使用している場合、この説明は必要ありません。 |
証明書サーバーはActive Directory Forestの任意のコンピュータにインストールできます。ただし、Active Directory Forestのルート・ドメインにインストールすることをお薦めします（たとえばRoot_domain）。有効化すると、すべてのドメイン・コントローラが証明書を自動的にリクエストして、SSLポート636を使用してLDAPをサポートします。
他のドメイン・コントローラにMicrosoft CA Certificate Serverを設定する手順
証明書サーバーを設定したら、証明書サーバーをインストールしたコンピュータからMicrosoft CA証明書を取得して、Oracle Access Managerコンポーネントをインストールするコンピュータに保存する必要があります。たとえば、アイデンティティ・サーバーのRoot_domainに保存します。
|
警告: 証明書はSSLが有効化されている各コンピュータに必要です。 |
タスクの概要: 証明書の取得と設定
対象のアイデンティティ・サーバーの証明書を取得する手順
アイデンティティ・サーバーをインストールするコンピュータで、Microsoft CA Certificate Serverがインストールされているコンピュータにナビゲートします。次に例を示します。
http://Root_domain/certsrv/
「Retrieve the CA certificate or certificate revocation list」を選択します。
「Base64 encoded」を選択します。
「Download CA certificate」リンクをダブルクリックします。
アイデンティティ・サーバーのインストール先となるマシンにこのファイルを保存するために、「Save」を選択します。
ディレクトリとファイル名を入力します。
アイデンティティ・サーバーをインストールするときのためにこのファイルのフルパスを記録します。次に例を示します。
F:\OracleAccessManager\certnew.cer
アイデンティティ・システムをインストールする準備ができました。「証明書を設定する手順」も参照してください。
証明書を設定する手順
証明書サーバーにナビゲートします。次に例を示します。
http://Root_domain/certsrv/
証明連鎖をファイルにダウンロードして、証明書を保存します。
次に説明するように、このファイルをインポートしてローカル・コンピュータに保存するとき、現在ログインしているユーザーの個人用証明書ストアにCAがIEによってインポートされます（デフォルト）。
ファイルをローカル・コンピュータ上の信頼できるルートCAストアにインポートします。次に例を示します。
「Internet Explorer」→「ツール」→「インターネット オプション」を選択します。「コンテンツ」→「証明書」→「信頼されたルート証明機関」→「フレンドリ名」→「インポート」→「次へ」を選択します。「参照」をクリックして「ファイル名」を指定し、「次へ」→「信頼されたルート証明機関」→「ローカル・コンピュータ」をクリックします。
Active Directoryの準備設定が終了したら、アイデンティティ・サーバーとWebPass（アイデンティティ・システムの主要な2つのコンポーネント）をインストールする必要があります。
タスクの概要: Active Directoryに対するアイデンティティ・システムのインストール
インストールと設定の際には、他のディレクトリ・サーバーに対してOracle Access Managerをインストールするユーザーの場合と同じ質問に答えるように求められます。その他に、ADSIと動的リンク補助クラスのオプションを指定するように求められます。
アイデンティティ・サーバーのインストールの手順
必要であれば、「環境の設定」を実行します。
第4章「アイデンティティ・サーバーのインストール」の指示に従い、Active Directory環境の仕様やプリファレンスを設定します。
指定するバインドDNは、属性の変更および読取りとスキーマのアクセスに十分な権限があれば、どのユーザーのものでもかまいません。LDAPまたはSSLを使用する場合にはパスワードの変更権限も必要です。ADSIではアイデンティティ・サーバー・サービス資格証明書が適切であることが必要です。
Active Directory上の大容量の動的グループを拡張する場合は、次の行をglobalparams.xmlファイルに追加してアイデンティティ・サーバーを再起動します。
\IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml
<SimpleList >
<NameValPair ParamName="maxForRangedMemberRetrieval" Value="1500"/>
</SimpleList>
アイデンティティ・システムのインストールを完了する手順
第5章「WebPassのインストール」の手順に従います。
環境に応じて次のいずれかのタスクを実行します。
「ADSIの設定（オプション）」の説明に従ってADSIを設定します。
「アイデンティティ・システムの設定」の説明に従ってアイデンティティ・システムの設定を完了します。
オプションのADSIを使用する場合は、次のタイミングで、この後に示す手順を実行する必要があります。
アイデンティティ・システム（アイデンティティ・サーバーおよびWebPass）のインストールの直後
アイデンティティ・システムの設定前
デフォルトではADSIによって暗黙のバインドが使用されます。これは、Windows 2000 ServerおよびWindows Server 2003サービスのログイン資格証明に対応しています。詳細は、「ADSIオプションの考慮事項」および『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
アイデンティティ・システムの設定前にADSIを設定する手順
\IdentityServer_install_dir\identity\oblix\config\adsi_params.xmlで、環境に応じたバインド・メカニズムを選択します。次に例を示します。
単一フォレストの場合のADSI:
<NameValPair ParamName="useImplicitBind"
Value="0"/>
Oracle Access Managerとデータが別のフォレストにある場合のADSI:
<NameValPair ParamName="useImplicitBind"
Value="1"/>
<NameValPair ParamName="useDNSPrefixedLDAPPaths"
Value="true">
When useImplicitBind=0: アイデンティティ・サーバーのサービス・ログイン資格証明をドメインの管理ユーザー（アイデンティティ・サーバーのインストール時にルート・バインドDNとして指定したユーザーと同じ権限を持つ）に設定します。
次の「アイデンティティ・システムの設定」の説明に従ってアイデンティティ・システムを設定します。
アイデンティティ・サーバー・コンポーネントとWebPassコンポーネントをインストールしたら、アイデンティティ・システムを設定する準備ができています。次に、アイデンティティ・システムの設定が成功するように、設定前や設定時に実行することを示します。いくつかの状況について説明します。
Active Directoryの特定の属性を有効化するには、次の手順を実行する必要があります。たとえば、userPrincipalNameをログイン属性として使用するため、この属性をアイデンティティ・システムの設定時に使用できるようにするには、アイデンティティ・システムの設定前に次のアクティビティを完了する必要があります。
Active Directoryの属性を有効化する手順
ad_exlude_attrs.xmlファイルとexclude_attrs-ad.xmlファイルを探します。次に例を示します。
\IdentityServer_install_dir\identity\oblix\data.ldap\common\ad_exlude_attrs.xml
\IdentityServer_install_dir\identity\oblix\data.ldap\common\exclude_attrs-ad.xml
これらのファイルを編集して、アイデンティティ・システムのユーザー・プロファイルでActive Directoryの特定の属性を使用可能にします。次に例を示します。
<ValNameList ListName="userPrincipalName"> <NameValPair ParameterName="appliesto" Value="None" />
静的リンク補助クラスのためにスキーマを変更する手順
スキーマを変更して、oblixOrgPersonオブジェクトとoblixPersonPwdPlicyオブジェクトをユーザー・オブジェクト・クラスに追加し、oblixGroupとoblixAdvancedGroupをGroupオブジェクト・クラスに追加します。
このように変更した後でMMCスキーマ・マネージャ・アプリケーションでスキーマのリロードを実行します。スキーマの変更がすべてのドメイン・コントローラにレプリケートされるまで約15分かかります。
Oracle Access Managerのデータとコンポーネントが同じフォレストにあるときは、パスワード変更権限を持つ特権管理ユーザーのコンテキストでアイデンティティ・サーバーを実行する必要があります。
|
注意: LDAP over SSLの場合、アイデンティティ・サーバーにサービスの資格証明を設定する必要はありません。 |
これまでのタスクを完了したら、Active Directory Forestに対してRoot_domainを使用してアイデンティティ・システムを設定する準備ができています。
Active Directory Forestにアイデンティティ・システムを設定する手順
次のアイデンティティ・システムの設定ページにナビゲートします。
http://hostname:port/identity/oblix
「アイデンティティ・システム・コンソール」をクリックし、「セットアップ」をクリックして、プロセスを起動します。
第6章「アイデンティティ・システムの設定」の手順に従います。
該当する場合はADSIを有効化します。
該当する場合は、「動的補助オブジェクト・クラス」ボックスを選択します。
設定が完了したら、次に示すタスクを実行できます。
「アイデンティティ・システム設定の検証」の説明に従ってアイデンティティ・システムの設定を検証します。
必要であれば、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、その他のドメインのディレクトリ・サーバー・プロファイルを定義します。
|
注意: ADSIを使用している場合、デフォルト・ディレクトリ・プロファイルとその他のディレクトリ・プロファイルに関するADSI有効化の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
必要であれば、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、disjointドメインのdisjoint検索ベースを設定します。
「アクセス・システムのインストールと設定」の説明に従って、アクセス・システムをインストールして設定します。
アクセス・システムのインストールを開始する前に、アイデンティティ・システムが設定されて正常にActive Directoryと一緒に機能していることを検証するようにお薦めします。
アイデンティティ・システムの設定を検証する手順
アイデンティティ・システムのログイン・ページにナビゲートします。
http://hostname:port/identity/oblix
ログイン・ページのドロップダウン・リストに表示されるすべてのドメイン名を確認します。
ログインします。
「ディレクトリ・オプションの構成」ページにナビゲートし、disjoint検索ベースがリストされていることを確認します。
アイデンティティ・システム・コンソールで、「システム管理」→「システム構成」→「ディレクトリ・オプション」を選択します。
|
注意: disjoint検索ベースがリストされていない場合は、ここで追加することができます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
アイデンティティ・システムが正常に作動していることを検証したら、アクセス・システムをインストールして設定できます。
アクセス・システムをActive Directory Forestにインストールするときは、次の項目を参照してください。
アクセス・システムのインストールを試行する前に、次の手順が完了していることを確認してください。
アクセス・システムのインストールと設定を準備する手順
「アイデンティティ・システムのインストール」の説明に従ってアイデンティティ・システムをインストールします。
「アイデンティティ・システムの設定」の説明に従ってアイデンティティ・システムを設定します。
「アイデンティティ・システム設定の検証」の説明に従ってアイデンティティ・システムを検証します。
|
警告: コンピュータがドメイン・コントローラではなく、他のOracle Access Managerデータと同じフォレストにある場合、ADSIのためにポリシー・マネージャ・ホストを準備するには、useImplicitBind=1（または2）、useDNSPrefixedLDAPPaths=trueを指定してください。 |
この環境でアクセス・システムをインストールして設定するには、ガイドとして次の手順を使用します。
ポリシー・マネージャをインストールして設定する手順
Oracle Access Managerのインストールを開始する前に、必要であれば、ADSIまたはLDAP over SSLの証明書が各コンピュータにあることを確認します。
構成データ、ユーザー・データおよびOracle Access Managerポリシー・データを同じディレクトリ・サーバーに置く場合のみ、アイデンティティ・サーバーのインストールで使用したのと同じディレクトリ・サーバーの詳細を次の手順で使用します。また、バインドDNとして指定した識別名に、ディレクトリ情報ツリー（DIT）のユーザー・ブランチと構成ブランチに対する全面的な権限があることを確認します。
「ポリシー・マネージャのインストール」の説明に従ってポリシー・マネージャをインストールします。
該当する場合は、ADSIを使用するActive Directoryを選択します。
該当する場合は、動的リンク補助クラスを選択します。
「ポリシー・マネージャの設定」の説明に従ってポリシー・マネージャを設定します。次の点を考慮してください。
ADSIの場合は、「ADSIを有効化」を選択し、userPrincipleNameをバインドDNとして入力し（たとえばuser@company.com）、設定を完了します。
LDAPオープン・バインドの場合は、『Oracle Access Managerアクセス管理ガイド』を参照してポリシー・マネージャの設定を完了します。
|
警告: Oracle Access Managerサーバーのコンポーネントとデータが別のフォレストにある場合のみ、次の手順を実行します。 |
\PolicyManager_install_dir\access\oblix\config\adsi_params.lstファイルのuseDNSPrefixedLDAPPaths値がtrueに設定されていることを確認します。次に例を示します。
<NameValPair
ParamName="useDNSPrefixedLDAPPaths"
Value="true" />
\PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.lstファイルでforceExplicitBindUsingDNを確認し、値をtrueに設定します。次に例を示します。
forceExplicitBindUsingDN:true
アイデンティティ・サーバーおよびWebPass Webサーバーを再起動します。
アクセス・サーバーとWebGateをインストールして設定する手順
Oracle Access Managerのインストールを開始する前に、必要であれば、ADSIまたはLDAP over SSLの証明書が各コンピュータにあることを確認します。
「アクセス・サーバーのインストール」の説明に従ってアクセス・サーバーをインストールします。次の項目を考慮してください。
該当する場合は、「ADSIを使用するActive Directory」を選択し、求められたらadsiCredentialとadsiPasswordを入力します。その後、アクセス・サーバーを再起動する前に、「アクセス・サーバーでのADSIの設定（オプション）」を実行します。
adsiCredentialとadsiPasswordは、暗号化パスワードを生成するために必要です。このパスワードは、ADSIを使用するActive Directoryに明示的にバインドするときに使用できます。Oracle Access Managerには暗号化ツールは含まれていないため、求められたときにadsiCredentialとadsiPasswordの値を入力する必要があります。
該当する場合は、動的補助クラスを選択します。
|
注意: ユーザー・データ、構成データおよびポリシー・データを格納する場所と、ディレクトリ・サーバーの構成の詳細について、確認を求められます。 |
Active Directory 2000を使用する場合は手順3を実行する必要があります。Active Directory 2000では、同一LDAP接続の様々なOracle Access Managerスレッドから受信する同時バインド・リクエストがサポートされないためです。詳細は、「Active Directoryのヒントとトラブルシューティング」を参照してください。
Active Directory 2000: アクセス・サーバーで、globalparams.lstファイルを開き、exclusiveAuthnConnectionという新しいフラグをtrueに設定して追加します。これによって、ディレクトリ・サーバーに送信されるバインド・リクエストに対して、Oracle Access Managerスレッドが強制的に別のLDAP接続を使用するようになります。
WebGate: 第9章「WebGateのインストール」の説明に従ってWebGateをインストールして構成します。
Active Directoryでの認証と認可、およびActive Directoryの特定の機能に対するOracle Access Managerの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ADSIの使用（オプション）を選択した場合は、次の時点でアクセス・サーバーにADSIを設定する必要があります。
アクセス・サーバーのインストール後
アクセス・サーバーの再起動前
アクセス・サーバーでADSIを設定する手順
管理ユーザーとしてドメインにログインします。
アクセス・サーバーのサービス・ログイン資格証明をドメインの管理ユーザーに設定します。
このユーザーは、ポリシー・マネージャとアクセス・サーバーのインストール時に「ルートDN」に指定したユーザーと同じ権限を持つ必要があります。
adsi_params.lstファイルで適切なバインド・メカニズムを選択します。たとえば、2フォレスト構成では次のようになります。
\AccessServer_install_dir\access\oblix\config\adsi_params.xml
useImplicitBind Value="1"
デフォルトでは、アクセス・サーバーのuseImplicitBindは1フォレスト構成用に0に設定されています。ADSIでは暗黙のバインドが使用されます。これは、Windows 2000 ServerまたはWindows Server 2003サービスのログイン資格証明に対応しています。ADSIバインド・メカニズムの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
手順4と5は環境に応じて実行します。
Oracle Access ManagerコンポーネントをActive Directory Forest外にインストールしているときは、adsi_params.lstのuseDNSPrefixedLDAPPathsパラメータの値がtrueに設定されていることを確認する必要があります。次に例を示します。
useDNSPrefixedLDAPPaths Value="true"
Oracle Access Managerコンポーネントとデータを別のフォレストにインストールしているときは、globalparams.lstファイルでforceExplicitBindUsingDNパラメータ値をtrueに設定します。次に例を示します。
\AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.lst
forceExplicitBindUsingDN Value="true"
Active Directoryでの認証と認可、およびActive Directoryの機能に対するOracle Access Managerの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
詳細は、「Active Directoryの問題」を参照してください。
