A Active Directoryでのデプロイ

『Oracle Access Managerインストレーション・ガイド』のアクティビティを完了してOracle Access ManagerをActive Directoryとともにインストールし、設定した後で、ここに示すアクティビティを実行して、日常的な使用とメンテナンス用にこれらのコンポーネントを構成できます。

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

ディレクトリ・プロファイルと検索ベースの設定
Active Directoryでの認証および認可
credential_mappingプラグインの構成
Active Directoryで使用するシングル・サインオンの構成
検索フィルタについて
SAMAccountNameの長さについて
.NET機能の構成
トラブルシューティング
Microsoftリソース

詳細および手順は、『Oracle Access Managerインストレーション・ガイド』を参照してください。次の項も参照してください。

A.1 ディレクトリ・プロファイルと検索ベースの設定

図A-1に示すActive Directoryフォレストには、Root_domain、Sub_domain、Disjoint_domainという3つのドメインが含まれます。図A-1の構成は、この後の説明で参照します。

図A-1 単一のActive Directoryフォレスト内の3つのドメイン

『Oracle Access Managerインストレーション・ガイド』の説明に従ってActive Directoryのインストールおよび設定を終了すると、次のタスクを実行する準備ができます。

他のドメインのディレクトリ・サーバー・プロファイルの定義
非結合検索ベースの設定
グループ検索読取り操作の構成（オプション）

注意:

複数のフォレストにデプロイする場合、フォレストはすべて同一のスキーマを使用する必要があります。これにより、他の非結合LDAPドメインと同様の方法で、複数のフォレストを構成することができます。詳細は、「複数のディレクトリ検索ベースの操作」を参照してください。

A.1.1 他のドメインのディレクトリ・サーバー・プロファイルの定義

デフォルトのディレクトリ・サーバー・プロファイルは、アイデンティティ・サーバーをインストールして新規ディレクトリ・サーバーの接続情報を指定するたびに自動的に作成されます。ディレクトリ・サーバー・プロファイルには、同じネームスペースおよび読取り、書込み、検索などの操作要件を共有する1つ以上のディレクトリ・サーバーの接続情報が含まれます。接続情報には、名前、適用されるドメインまたはネームスペース、ディレクトリ・タイプ、および操作のセットが含まれます。

インストール後に、次の手順で概説するように、アイデンティティ・システム・コンソールを使用してディレクトリ・サーバー・プロファイルを変更できます。次の手順が完了したら、非結合検索ベースを設定できます。

詳細は、「ディレクトリ・サーバー・プロファイルの管理」を参照してください。

注意:

デフォルトのディレクトリ・サーバー・プロファイルは、Root_domainに対してのみ作成されます。インストール環境の他のドメイン（Disjoint_domainとSub_domainなど）のディレクトリ・プロファイルを設定する必要があります。

追加のディレクトリ・サーバー・プロファイルを設定する手順

アイデンティティ・システム・コンソールにナビゲートします。

http://hostname:port/identity/Oblix
ディレクトリ・サーバー・プロファイルにナビゲートします（「アイデンティティ・システム・コンソール」、「システム管理」、「システム構成」、「ディレクトリ・オプションの構成」、リンク）。
「ディレクトリ・サーバー・プロファイルの管理」の説明に従って、Disjoint_domainのプロファイルを追加します（存在する場合）。
Sub_domainのプロファイルを追加します。
アイデンティティ・システムの設定時に収集されたデフォルト名が意味を持たない場合は、デフォルトのディレクトリ・プロファイルの名前を変更します。
次に説明するように、非結合検索ベースを設定します。

A.1.2 非結合検索ベースの設定

ドメインを構成した後で、Disjoint_domainの非結合検索ベースを追加し、「タブ検索ベース」フィールドに値がないことを確認する必要があります。

注意:

Root_domainをどのように構成したかに応じて、Sub_Domainの非結合検索ベースの追加が必要な場合があります。

Disjoint_domainの非結合検索ベースを追加する手順

アイデンティティ・システム・コンソールにナビゲートします。

http://hostname:port/identity/oblix
「ディレクトリ・サーバー」リンクにナビゲートして選択します（「アイデンティティ・システム・コンソール」、「システム管理」、「システム構成」、「ディレクトリ・オプションの構成」、リンク）。
Disjoint_domainの非結合検索ベースを追加し、「保存」をクリックします。
「ユーザー・マネージャ」の「タブの構成」機能にナビゲートして選択します（「アイデンティティ・システム・コンソール」、「ユーザー・マネージャ構成」、「タブの構成」）。
「タブの構成」ページでリンクを選択します。
「タブ検索ベース」フィールドに値がないことを確認します。
Sub_domainがある場合は、これについて前述の手順を繰り返します。

A.1.2.1 非結合検索ベースの削除について

非結合検索ベースの検索ベース・ポリシーがある場合、このノードにこの検索ベースを持つユーザーは、ベースがこの検索ベースであるフィルタをクエリー・ビルダーで作成できます。削除する前に、この非結合検索ベースのアクセス制御ポリシーをすべて削除することをお薦めします。

非結合検索ベースを削除する場合は、この検索ベースを使用するすべてのデータベース・エージェントを無効にする必要があります。

A.1.3 グループ検索読取り操作の構成（オプション）

Active Directoryは、グループ・メンバーの増分取得を使用します。このため、アイデンティティ・システムは複数の読取りを実行してグループ・メンバーの完全なセットを取得する必要があります。

Windows 2000上のActive Directoryの場合、1回の読取りで取得できる最大のメンバー数は1000です。パラメータを変更しないかぎり、アイデンティティ・システムはデフォルト値の1000を使用します。Windows .NET Server 2003上のActive Directoryの場合、最大数は1500です。globalparams.xmlにあるパラメータmaxForRangedMemberRetrievalに、アイデンティティ・システムが使用する最大値が格納されます。

注意:

install_dirという表記法は、名前付きコンポーネントをインストールしたディレクトリを表します。

Windows 2003でグループ検索読取り操作を構成する手順

\IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xmlにあるglobalparams.xmlファイルを探します。

IdentityServer_install_dirは、アイデンティティ・サーバーをインストールしたディレクトリを表します。
maxForRangedMemberRetrievalエントリに1500の値を加算します。

次に例を示します。
```
<SimpleList > <NameValPair ParamName="maxForRangedMemberRetrieval" Value="1500"/> </SimpleList>
```
ファイルを保存します。
アイデンティティ・サーバーを再起動します。

A.2 Active Directoryでの認証および認可

2フォレスト構成については、『Oracle Access Managerインストレーション・ガイド』で概説しています。インストール後、Active Directory用のアクセス・システムの構成には、親子ドメインでの認証と認可の設定が含まれる場合があります。

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

親子認証
親子認可
ObMyGroupsアクション属性

A.2.1 親子認証

この場合は、アクセス・システムの資格証明マッピング・プラグインを使用して、親ドメインと子ドメインの両方に対してユーザーを認証する必要があります。このプラグインはユーザーのDNを取得します。

たとえば、foo.goodwill.oracle.comおよびgoodwill.oracle.comという2つのドメインがあるとします。アイデンティティ・システムには、2つのディレクトリ・プロファイルがあります。1つはfoo.goodwill.oracle.comに対するもので表示名はfooであり、もう1つはgoodwill.oracle.comに対するもので表示名はgoodwillです。

Foo.goodwill.Oracle.com:DisplayName=fooSearchbase = dc=foo,dc=goodwill,dc=Oracle,dc=comUser:Alice

Goodwill.Oracle.comDisplayName=goodwillSearchbase=dc=goodwill,dc=Oracle,dc=comUser:Bob

また、前の例で示したcredential_mappingプラグインのフィルタを使用するOracle Access and Identity認証メカニズムを使用しているとします。ユーザーがアクセス・システムにログインしようとすると、「Basic Over LDAP」ダイアログ・ボックスが表示されます。

ドメインは、ログインIDの一部であり、"\"の前に入力されます。ドメイン名から、アクセス・システムはこのユーザーの識別に使用する検索ベースを知ることができます。Aliceがログインする場合はドメイン名fooを指定する必要があり、Bobがログインする場合はドメイン名goodwillを指定する必要があります。両方のユーザーが認証されます。

注意:

Active Directoryフォレスト用のOracle Access and Identity認証スキームで保護されているリソースにアクセスするには、ユーザーは「認証」ダイアログ・ボックスでユーザー名としてdomainname\usernameを入力する必要があります。このdomainnameは、このユーザーの認証の実行に使用される、アクセス・サーバーに対して作成されたDBプロファイルの表示名である必要があります。

A.2.2 親子認可

ドメインごとに別々のLDAPルールを定義できます。たとえば、マネージャの肩書きを持つすべてのユーザーがリソースにアクセスできるようにする場合は、ドメインごとに1つずつ、合計2つのLDAPルールを指定する必要があります。これらのルールの例を次に示します。

ldap:///dc=goodwill,dc=Oracle,dc=com??sub?(&(title=Manager)(objectclass=user)

ldap:///dc=foo,dc=goodwill,dc=oracle,dc=com??sub?(&(title=Manager)(objectclass=user)

これらのルールを使用して、fooとgoodwillの両方のマネージャを認可できます。

A.2.3 ObMyGroupsアクション属性

ObMyGroupsアクション属性を使用して、ユーザーが属するすべてのグループをヘッダー変数で返すことができます。属性名にObMyGroupsを指定して、アクセス・システムに対して構成された検索ベースを使用します。アクセス・サーバーは、返されるグループ数に制限を課しません。返されるグループ数は、ディレクトリに対して構成されているサイズ制限によってのみ制限されます。

アクセス・システムでは、1つの検索ベースのみサポートされます。したがって、goodwill.Oracle.comを製品検索ベースとして選択する場合、ObMyGroupsは、goodwill.oracle.comの下のグループを検索します。この場合、アクセス・システムは参照に従うことができず、アクセス・システムには複数検索ベース機能がないため、foo.goodwill.oracle.comのグループを返すことができません。

LDAP URLでObMyGroupsを指定できます。この場合、検索ベースはLDAP URLから取得されます。ただし、1つのヘッダー変数に1つの属性のみ関連付けることができるため、2つのドメインがある場合は、ユーザーが属するすべてのグループを取得するために、少なくとも2つのヘッダー変数が必要です。

たとえば、dc=goodwill,dc=oracle,dc=comおよびdc=dilbert,dc=goodwill,dc=oracle,dc=comという2つのドメインがあるとします。この両方の検索ベースからグループを取得するには、表A-1に示すように、ドメインごとに1つずつ、合計2つのヘッダー変数を定義する必要があります。

表A-1 2つのドメインのLDAP URLがあるObMyGroups

タイプ	名前	戻り値
headervar	HTTP_PARENT_GROUP	"obmygroups:ldap:///dc=goodwill,dc=Oracle,dc=com??sub?(group_type=role)"
headervar	HTTP_CHILD_GROUP	"obmygroups:ldap:///dc=dilbert,dc=goodwill,dc=Oracle,dc=com??sub?(group_type=role)"

HTTP_PARENT_GROUPでは、"dc=goodwill,dc=Oracle,dc=com"ツリーの中で、ログインしているユーザーがメンバーとなっており、group_typeがロールであるすべてのグループが返されます。
HTTP_CHILD_GROUPでは、"dc=dilbert,dc=goodwill,dc=Oracle,dc=com"ツリーの中で、ログインしているユーザーがメンバーとなっており、group_typeがロールであるすべてのグループが返されます。

次の手順では、Active Directory用にcredential_mapping認証プラグインを構成し、必要に応じてSSOを設定します。

A.3 credential_mappingプラグインの構成

各ポリシー・ドメインには認証スキームが必要です。各認証チャレンジ方法は、1つ以上のプラグインによってサポートされます。認証チャレンジ方法のプラグインの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

credential_mappingプラグインは、ユーザーのユーザーIDをディレクトリ内の有効な識別名（DN）にマッピングします。ユーザーIDがマッピングされる属性を構成できます。最も一般的なマッピング先属性はuidです。ただし、obMappingFilterパラメータを変更することにより、顧客がユーザーIDをuid以外のプロファイル属性にマッピングすることもできます。

obmappingbaseはユーザー検索ベースを定義します。シングル・ドメインでは、マッピング・ベースをcredential_mappingプラグインのobMappingBaseパラメータで明示的に定義する必要があります。次に例を示します。

ou=company,dc=mydomain,dc=Oracle,dc=com).

Active Directoryフォレストでは、ユーザーは、指定されたドメインに対するユーザー資格証明を検証するために、ログイン時にドメインに加えてユーザーIDを提供する必要があります。この場合、マッピング・ベースはobMappingBase="%domain%"に設定する必要があります。Active DirectoryフォレストのOracle Access and Identityの資格証明マッピングを定義するためのテンプレートは、次のようになります。

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user) (sam accountname=%userid%))", obdomain="domain"

ドメイン情報は、アイデンティティ・システム・コンソールのDBプロファイルでメンテナンスします。ドメインごとに必ずDBプロファイルを作成してください。マルチドメイン・フォレストのログイン名は、アクセス・サーバーDBプロファイルに定義されている表示名です。

credential_mappingプラグインの構成手順

通常どおり、ポリシー・マネージャにポリシー・ドメインを作成します。

注意:
現在、アクセス・システムをActive Directoryとともにデプロイする場合、ポリシー・ドメイン数の上限は350です。
「認証管理」プラグイン・ページにナビゲートします（「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」→「link」→「プラグイン」）。

linkは、変更する認証スキームの名前です。
Active Directory用のcredential_mappingプラグインを構成します。

次に例を示します。

フォーム・ベースの場合:

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user)(samaccountname=%login%))

Oracle Access and Identityの場合:

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user)(samaccountname=%userid%))", obdomain="domain"

注意:

A.4 Active Directoryで使用するシングル・サインオンの構成

次の手順で説明するように、アイデンティティ・システムまたはアクセス・システムに対してシングル・サインオンを構成できます。ポリシー・ドメインでのリソースの保護およびシングル・サインオンの構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

アイデンティティ・システムまたはアクセス・システムでシングル・サインオンを構成する手順

ヘッダー変数ObUniqueIdに（uidではなく）HTTP_OBLIX_UIDを渡す必要のあるポリシー・ドメイン認証ルールでアクションを変更します。

注意:
現在、Active Directoryでのポリシー・ドメイン数の上限は350です。詳細は、「トラブルシューティング」を参照してください。
Webサーバーで、次のファイルのWhichAttrIsLoginパラメータの値をObUniqueIDに変更します。

\IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml 
\PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml

WhichAttrIsLogin:ObUniqueId

ディレクトリ・サーバー・プロファイルの構成ページに、属性の数を指定する関連ディレクトリ・プロファイルが表示されます。次に例を示します。

マシン:
ポート番号:
ルートDN:
ルート・パスワード:
検索ベース:
構成ベース:
ディレクトリ・サーバー・セキュリティ・モード:
非結合検索ベース:
ADSI有効: Yes

次に、結果として表示される、シングル・サインオンに関連する基本ログイン・ウィンドウを示します。

Active Directoryフォレストに対して構成している場合、ユーザーが属するドメインは、アイデンティティ・システムで構成され、アクセス・システムで使用されるディレクトリ・プロファイルによって決まります。これらのディレクトリ・プロファイルは、アイデンティティ・システム・コンソールの「ディレクトリ・オプションの構成」機能からアクセスできるディレクトリ・サーバー・プロファイルの構成ページで有効または無効にできます。

ディレクトリ・プロファイルが無効で、ユーザーがログイン時にアクセス・システムを通じてドメイン名を入力した場合、ユーザーはアクセスを許可されません。
ディレクトリ・プロファイルが有効で、ユーザーがドメイン名としてその名前を入力した場合、ユーザーはアクセスを許可されます。

ただし、ユーザーがすでに認証されていて、有効なセッション・トークンを持っており、その後でディレクトリ・プロファイルが無効にされた場合、ユーザーは認証ルールなどに基づいてアクセスを許可されます。ディレクトリ・プロファイルの状態（有効/無効）は、認可時には影響しません。認証のみがプロファイルの状態を参照します。

A.5 検索フィルタについて

フィルタに、「次を含む」に評価される制約が含まれている場合（Smithを含む値を検索するcn=*Smithなどのフィルタ）、Active Directoryは索引付き検索を起動しません。索引付き検索では、次の制約が有効です。

次と等しい（cn=Smith）
次で始まる（cn=Smith*）

動的グループ・オプションが有効になっていて、指定された動的フィルタに「次を含む」検索フィルタが含まれている場合、「グループ・マネージャ」の「グループ」タブでは、結果の評価に長時間を要することがあります。

ユーザーが「次を含む」検索フィルタを使用しないようにするには、カタログ・ファイルを変更して使用可能なフィルタを制限します。次のディレクトリにあります。

component_install_dir/identity|access/oblix/app//bin/application

component_install_dirはコンポーネントがインストールされているディレクトリで、identity|accessはそれぞれアイデンティティ・システムとアクセス・システムを表します。

複数のxxxparams.xmlファイルがあります。これらのファイルで、許可される有効なフィルタのタイプをvallist（ObEnhanceSearchList）で指定できます。

「あいまいな名前の解決」も参照してください。

A.6 SAMAccountNameの長さについて

Active DirectoryスキーマにあるSecurity Access Managerアカウント名の属性（SAMAccountName）は、Windows 2000より前のWindowsバージョンとの下位互換性を保つために使用されます。これらの旧バージョンをサポートする必要がない場合は、Active Directoryをネイティブ・モードで実行できます。

Active Directoryを混在モードで実行する必要がある場合、Active Directoryは、SAMAccountNameの値として指定できる文字数を制限します。デフォルトでは、Oracle Access Managerは混在モードに適応し、SAMAccountName文字列の長さを20文字に制限します。Active Directoryをネイティブ・モードで実行している場合は、globalparams.xmlファイルでsamAccountNameLengthパラメータの値を編集する必要があります。このファイルは次のディレクトリにあります。

component_install_dir/apps/common/bin/globalparams.xml

component_install_dirは、Oracle Access Managerコンポーネントがインストールされているディレクトリの名前です。このファイルで、次のエントリの値を編集します。

<SimpleList>
<NameValPair
    ParamName="samAccountNameLength"
    Value="20">
</NameValPair>
</SimpleList>

globalparams.xmlの詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。

ユーザーが、globalparams.xmlのsamAccountNameに対して設定された制限を超える名前を持つ人物またはグループを定義すると、エラーが発生します。デフォルトのメッセージは、このパラメータが20文字を超えてはならないことを示します。メッセージ・タグは"MSamAccountNameExceeds20Error"です。

注意:

このパラメータの値を変更する場合は、メッセージ・カタログglobalmsg.xmlでエラー・メッセージを変更する必要もあります。