| Oracle Access Manager IDおよび共通管理ガイド 10g（10.1.4.3） B55478-01 |
|
 戻る |
 次へ |
アイデンティティ・システムとアクセス・システムの両方に、Active Directory Services Interface（ADSI）クライアント・アプリケーションのサポートが用意されています。この章では、Oracle Access ManagerをActive DirectoryフォレストおよびActive Directory Services Interface（ADSI）とともに実行しているときの要件および手順をまとめます。
この付録には次の項があります。
詳細および手順は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Active Directoryは、Windows® 2000およびWindows Server 2003ドメイン・コントローラ上で稼働します。ADSIを使用しているクライアント・アプリケーションを作成し、他のWindowsプラットフォームで実行できます。
ADSIは、Active Directoryとの緊密な統合を可能にするCOMインタフェースのセットです。たとえば、ADSIには次の機能があります。
複数のベンダーの異なるディレクトリ・サービスの機能を抽象化して、ネットワーク・リソースを管理するための単一のインタフェースを提示します。
どのネットワーク環境にリソースが含まれているかにかかわらず、管理者および開発者がディレクトリ・サービス内のリソースを管理できるようにします。
管理者が、ユーザーとグループの追加、プリンタの管理、ネットワーク・リソースに対する権限の設定などの一般的なタスクを自動化できるようにします。
|
重要: ADSIを有効にすると、Oracle Access Managerは、Active Directoryの暗黙的なフェイルオーバーおよびパスワード変更機能を利用できます。 |
ADSIを使用すると、Oracle Access Managerコンポーネントは、Active Directoryデータにアクセスするために特定のホストおよびポートにバインドする必要がありません。かわりに、ADSIにより、Oracle Access Managerコンポーネントは最も近くにある使用可能ドメイン・コントローラに接続して、任意のユーザー、グループまたはOracle Access Manager構成情報にアクセスできます。
『Oracle Access Managerインストレーション・ガイド』で説明しているように、ADSIの資格証明を使用してフォレスト全体にバインドできます。フォレストには、複数のActive Directoryホストを含めることができます。ユーザー・データおよび構成データが異なるフォレストの異なるActive Directoryホストに格納されている場合は、ADSIを使用してこれらのデータに同時にアクセスすることはできません。
ADSIは、フォレスト内の異なるドメインに対して特定のホストおよびポート番号を必要としません。ADSIは、次のようなLDAP URLを使用してActive Directoryホストに接続します。
LDAP://domain.oblix.com/ou=oblix,dc=domain,dc=oblix,dc=com
インストール時のADSIの有効化の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Active Directoryは、ツリー構造全体をレプリケートします。レプリケーションが遅延する可能性があるため、Oracle構成データを含むディレクトリ・ツリーはレプリケートしないことをお薦めします。構成データに対する変更は、即時に使用可能にならない場合があります。たとえば、ポリシー・マネージャでユーザーのアクセス権限に対して行った変更は、別のドメイン・コントローラと対話しているアクセス・サーバーから使用できない場合があります。
Oblixツリーをレプリケートする必要がある場合は、Active Directory上のドメイン・コントローラ間のレプリケーション頻度を変更します。
Oracle Access Managerは、認証オプションおよびバインド・オプションの選択に関連するADSIおよびLDAPの柔軟な組合せをサポートします。
|
注意: SSLは、ADSIとOracle Access Managerでは不要です。ただし、業務上の他の理由でSSLが必要になる場合があります。たとえば、ディレクトリ・バインドはクリア・テキストであり、SSLは自動的には提供されません。 |
この項の内容は次のとおりです。
純粋なADSI設定では、Active Directoryツリー内のプライマリ・ドメイン・コントローラに対するアイデンティティ・システムの設定時に単一のADSIデータベース・エージェントが作成されます。各子ドメインに対してエージェントを追加する必要があります。
さらに、ドメイン・ツリーの不連続フォレストがある場合は、図B-1に示すように、プライマリ・ドメイン・コントローラごとに別々のADSIデータベース・エージェントを関連付ける必要があります。
複数のディレクトリ・プロファイルおよびDBエージェントの詳細は、「ディレクトリ・サーバー・プロファイルの管理」を参照してください。
ADSI認証は、LDAPよりも低速な場合があります。このため、読取り、書込み、検索などの他の操作がADSIで処理される場合に、認証にLDAPを使用することが必要な場合があります。ADSIエージェントは、すべてのドメインと関連付ける必要があります。
アイデンティティ・システム・コンソールの「ディレクトリ・サーバー・プロファイルの作成」ページにある「Microsoft Active Directory(ADSIを使用)」の横の「認証にLDAPを使用」チェック・ボックスを選択します。
複数のディレクトリ・プロファイルおよびDBエージェントの詳細は、「ディレクトリ・サーバー・プロファイルの管理」を参照してください。
必要に応じて繰り返します。
|
注意: このリリースでは、Global Catalogは不要です。 |
詳細は、「アクセス・サーバーのバインド・メカニズム」および「Oracle Access Manager ADSI構成ファイル」を参照してください。
ADSIは、Active Directoryにバインドする複数の方法をアイデンティティ・サーバーに提供します。ある特定の方法に有利な点はありません。利点は、使用する資格証明に依存します。次に例を示します。
暗黙的: 現在のプロセスの資格証明を使用します。
これはアイデンティティ・サーバーに対するデフォルトです。これは、アイデンティティ・サーバーのサービス・ログオン資格証明に対応します。暗黙的バインドの場合、adsi_params.xmlファイル内のuseImplicitBindフラグは0に設定する必要があります。詳細は、「Oracle Access Manager ADSI構成ファイル」を参照してください。
|
注意: Active Directoryにバインドするにはアイデンティティ・サーバーのアカウントを作成する必要があります。 |
アイデンティティ・サーバーがActive Directoryにバインドできるようにするためのアカウントは、アイデンティティ・サーバーの設定時に指定したルートDNと等価である必要があります。これには、Oracle Access Managerを使用して実行する操作の管理権限がすべて必要です。Active Directoryフォレストでは、フォレスト内の他のすべてのドメインの制御をこのユーザーに委任する必要があります。DSIは、静的補助クラスを使用して構成されています。
ユーザーのDNを使用して明示的: adsi_params.xmlファイル内のuseImplicitBindフラグを1に設定する必要があります。adsi_params.xmlファイルにあるadsiCredentialパラメータでユーザーDNを指定する必要があります。詳細は、「Oracle Access Manager ADSI構成ファイル」を参照してください。
userPrincipleNameを使用して明示的: adsi_params.xmlファイル内のuseImplicitBindフラグを2に設定する必要があります。adsi_params.xmlファイル内のadsiUPNパラメータでUPNを指定する必要があります。詳細は、「Oracle Access Manager ADSI構成ファイル」を参照してください。
ADSI構成パラメータは、次の2つのファイルでメンテナンスされます。
\IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml \IdentityServer_install_dir\identity\oblix\config\adsi_params.xml
IdentityServer_install_dirは、アイデンティティ・サーバーをインストールしたディレクトリです。
この項では、サンプルのglobalparams.xmlファイルと、パラメータ値の表を示します。
\IdentityServer_install_dir\identity\oblix\apps\common\bin\ globalparams.xmlのインストール・プログラムは、デフォルトのディレクトリ・プロファイルに対してADSIを有効にする場合に、adsiEnableパラメータを作成してその値をtrueに設定します。このパラメータは、Oracle構成データを格納するシステム・レベルのディレクトリ・プロファイルを参照します。
|
注意: パラメータを変更した後は、アイデンティティ・サーバーを再起動する必要があります。ただし、ADSIEnabledパラメータ値は変更しないでください。 |
<SimpleList> <NameValPair ParamName="ActiveDirectory" Value="true" /> </SimpleList> <SimpleList> <NameValPair ParamName="ADSIEnabled" Value="true" /> </SimpleList>
この項では、サンプルのadsi_params.xmlファイルと、パラメータ値の表を示します。デフォルトでは、次の例に示すように、adsi_params.xmlにはadsiCredentialパラメータの値とパスワードが含まれます。これにより、初期設定後にバインド・メカニズムを「明示的」に変更できます。
adsiPasswordは暗号化され、設定時にOracle Access Managerでのみ生成できます。次に、このファイルの例を示します。
<?xml version="1.0" ?>
- <ParamsCtlg xmlns="http://www.oblix.com" CtlgName="adsi_params">
- <CompoundList ListName="adsi_params">
- <ValNameList ListName="adsi_params">
<NameValPair ParamName="sizeLimit" Value="0" />
<NameValPair ParamName="timeLimit" Value="0" />
<NameValPair ParamName="pagesize" Value="100" />
<NameValPair ParamName="useImplicitBind" Value="0" />
<NameValPair ParamName="adsiCredential"
Value="cn=Administrator,cn=users,dc=goodwill,dc=oblix,dc=com" />
<NameValPair ParamName="adsiPassword" Value="0243455B5B5F5C4C5651595D41" />
<NameValPair ParamName="useGCForAuthn" Value="false" />
<NameValPair ParamName="encryption" Value="false" />
<NameValPair ParamName="asynchronousSearch" Value="true" />
<NameValPair ParamName="useDNSPrefixedLDAPPaths" Value="false" />
</ValNameList>
</CompoundList>
..</ParamsCtlg>
デフォルトでは、暗号化はadsi_params.xmlでfalseに設定されます。オープン・モードで実行しているときにこれをtrueに設定し、アイデンティティ・サーバーを再起動すると、アイデンティティ・サーバーが動作しなくなります。
|
注意: パラメータを変更した後は、アイデンティティ・サーバーを再起動する必要があります。 |
表B-2に、adsi_paramsファイル内のパラメータと値を説明します。
表B-2 adsi_paramsファイルのパラメータと値
| adsi_paramsのパラメータ | 値 |
|---|---|
|
sizeLimit |
認証に対して返される問合せ結果の数を制限する整数値。 |
|
timeLimit |
問合せがタイムアウトになるまでの秒数を制限する整数値。 |
|
pageSize |
ADSIがサーバーにリクエストする結果のページ・サイズ。 |
|
useImplicitBind |
0 = 暗黙的な資格証明 1 = 明示的な資格証明 2 = userPrincipalNameを使用 |
|
adsiCredential |
cn=Administrator,cn=users,dc=myhost,dc=mydomain,dc=comなど、ユーザーのLDAP指定。 |
|
adsiPassword |
LDAPユーザーのパスワードを表すエンコードされたテキスト文字列。 |
|
useGCForAuthn |
true/false False |
|
aynchronousSearch |
true/false デフォルトでは、ADSIは非同期検索を実行できます。falseに設定されている場合は、同期検索を実行します。 |
|
adsiUPN |
このパラメータは、useImplicitBindが2に設定されている場合に追加する必要があります。パラメータの値は、ユーザーのUPN（userPrincipalName）にする必要があります。 |
|
chaseReferral |
このフラグをfalseに設定すると、LDAP参照がオフになります。 |
アイデンティティ・システムと同様に、アクセス・システムでは、ADSIと、LDAP認証を行うADSIの両方がサポートされます。
アクセス・システムでは、複数のActive Directoryドメインもサポートされ、Oracle Access Managerの設定時に作成したデフォルトのディレクトリ・プロファイルに対してADSIを有効にする手順を実行する必要があります。
この項の内容は次のとおりです。
アクセス・サーバーは、ADSIを使用してActive Directoryを認証します。これは、これらのコンポーネントでADSIを有効にする場合のデフォルトです。
ポリシー・マネージャは、アイデンティティ・サーバーと同じ認証モードを使用します。それでも、ポリシー・マネージャに対してADSIを有効にする必要があります。
詳細は、「アクセス・システムに対するADSIの構成」を参照してください。
アクセス・サーバーは、フォレスト内のすべてのディレクトリ・サーバーと直接通信でき、LDAP認証にGlobal Catalogは不要です。
ADSIのインストールおよび設定の考慮事項のリストは、『Oracle Access Managerインストレーション・ガイド』のActive Directoryでのインストールに関する付録を参照してください。
認証メカニズム
ユーザーがActive Directoryに対して認証される場合、メカニズムはドメイン・コントローラであり、ADSIでの認証にそれぞれのドメイン・コントローラを使用します。
詳細は、「アクセス・システムADSI構成ファイル」を参照してください。
ADSIは、Active Directoryにバインドする複数の方法をアクセス・サーバーおよびポリシー・マネージャに提供します。ある特定の方法に有利な点はありません。利点は、使用する資格証明に依存します。
暗黙的: 現在のプロセスの資格証明を使用します（アクセス・サーバーに対するデフォルト）。
これは、アクセス・サーバーのサービス・ログオン資格証明に対応します。暗黙的バインドの場合、adsi_params.xmlファイル内のuseImplicitBindフラグは0に設定する必要があります。詳細は、「アクセス・システムADSI構成ファイル」を参照してください。
|
注意: Active DirectoryにバインドするにはAccess Serviceのアカウントを作成する必要があります。このアカウントは、アクセス・サーバーの設定時に指定するルートDNと等価である必要がります。これには、Oracle Access Managerを使用して実行する操作の管理権限がすべて必要です。Active Directoryフォレストでは、フォレスト内の他のすべてのドメインの制御をこのユーザーに委任する必要があります。 |
ユーザーのDNを使用して明示的: adsi_params.xmlファイル内のuseImplicitBindフラグを1に設定する必要があります。
ユーザーDNは、adsi_params.xmlファイルにあるadsiCredentialパラメータで指定する必要があります。詳細は、「アクセス・システムADSI構成ファイル」を参照してください。
userPrincipleNameを使用して明示的: adsi_params.xmlファイル内のuseImplicitBindフラグを2に設定する必要があります。
UPNは、adsi_params.xmlファイル内のadsiUPNパラメータで指定する必要があります。詳細は、「アクセス・システムADSI構成ファイル」を参照してください。
マルチドメインActive Directoryフォレストでは、サポートされる明示的バインド・メカニズムはuserPrincipleNameのみです。ポリシー・マネージャはこのメカニズムのみサポートします。
ポリシー・マネージャとアクセス・サーバーの両方に、ADSI関連のパラメータを変更するための2つの構成ファイルがあります。ファイルは異なる場所でメンテナンスでき、コンポーネントごとに別々に変更する必要がありますが、それらのコンテンツは同じです。ポリシー・マネージャおよびアクセス・サーバーの構成ファイルは次のとおりです。
\PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.xml \PolicyManager_install_dir\access\oblix\config\adsi_params.xml
\AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml \AccessServer_install_dir\access\oblix\config\adsi_params.xml
これらのファイルについて、次の各項で説明します。
ポリシー・マネージャADSI構成
この項では、サンプルのglobal-parameters構成ファイルと、パラメータ値の表を示します。
|
注意: ポリシー・マネージャとアクセス・サーバーをインストールする際に、ADSIオプションを選択しないと、globalparams.xmlにADSIEnabledパラメータがありません。一方、ADSIEnabledがないとuseLDAPBindパラメータは何も目的を果しませんが、このパラメータは存在します。 |
BEGIN:vCompoundList ... useLDAPBind:false ADSIEnabled:true ActiveDirectory:true END:vCompoundList
パラメータとその値について、表B-3で説明します。
表B-3 globalparamsファイルのパラメータと値
| globalparamsのパラメータ | 値 |
|---|---|
|
useLDAPBind |
true | false マスター管理者がポリシー・マネージャの構成時に「Microsoft Active Directory（LDAPを使用）」を選択した場合はtrueです。このフラグを有効にするには、ADSIEnabledフラグがtrueである必要があります。デフォルトはfalseです。 |
|
ADSIEnabled |
true | false マスター管理者がポリシー・マネージャの構成時にADSIを有効にした場合はtrueです。 |
|
ActiveDirectory |
true | false マスター管理者がポリシー・マネージャの構成時にディレクトリ・サーバー・タイプとしてActive Directoryを選択した場合はtrueです。 |
アクセス・サーバーのADSI構成
この項では、サンプルのadsiパラメータ構成ファイルと、パラメータ値を示す表B-4を示します。
表B-4 adsi_paramsファイルのパラメータと値
| adsi_paramsのパラメータ | 値 |
|---|---|
|
sizeLimit |
認証に対して返される問合せ結果の数を制限する整数値。 |
|
timeLimit |
問合せがタイムアウトになるまでの秒数を制限する整数値。 |
|
pageSize |
ADSIがサーバーにリクエストする結果のページ・サイズ。デフォルトは0です。 |
|
useImplicitBind |
0 = 暗黙的な資格証明 1 = 明示的な資格証明 2 = UserPrincipalNameを使用 |
|
adsiCredential |
cn=Administrator,cn=users,dc=myhost,dc=mydomain,dc=comなど、ユーザーのLDAP指定。 |
|
adsiPassword |
LDAPユーザーのパスワードを表すエンコードされたテキスト文字列。 |
|
adsiUPN |
ImplicitBind=2を使用する場合のUserPrincipalNameのテキスト文字列です。UPN文字列は、通常はuser@company.comの形式の電子メール・アドレスです。 |
|
useGCForAuthn |
True/False useGCForAuthenticationパラメータをfalseに変更します。 |
|
asynchronousSearch |
True/False デフォルトでは、ADSIは非同期検索を実行できます。falseに設定されている場合は、同期検索を実行します。 |
|
asynchronousSearch |
adsiUPN。このパラメータは、useImplicitBindが2に設定されている場合に追加する必要があります。パラメータの値は、ユーザーのUPN（userPrincipalName）にする必要があります。 |
アイデンティティ・システムに対するADSIの構成には、複数のタスクが関係します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
タスクの概要: アイデンティティ・システムに対するADSIの構成
Microsoftドキュメントと『Oracle Access Managerインストレーション・ガイド』の説明に従って、Active Directoryを準備します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、Oracle Access Managerのインストールおよび設定時にADSIを指定します。
デフォルトでは、これにより純粋なADSI構成が作成されます。この構成では、単一のADSIディレクトリ・プロファイル（DBエージェント）により、関連アイデンティティ・サーバーが、暗黙的バインドを使用してActive Directoryツリー内のプライマリ・ドメイン・コントローラですべての操作を実行できます。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、Active Directory属性を設定し、パスワードの変更権限を有効にします。
「デフォルトのディレクトリ・プロファイルに対するADSIの有効化」の説明に従ってデフォルトのディレクトリ・プロファイルを構成します。
必要に応じて、「その他のディレクトリ・プロファイルに対するADSIの有効化」の説明に従って、追加のディレクトリ・プロファイルに対してADSIを有効にします。
アイデンティティ・システムは、インストール時にデフォルトのディレクトリ・プロファイルを自動的に作成します。アイデンティティ・システムの設定時にデフォルト・プロファイルに対してADSIを有効にできます。
デフォルトのデータベース・エージェントには、default-ois-computer nameという表記法を使用して名前が自動的に割り当てられます。ユーザーが認証時にこの名前を入力する必要があるため、この名前をそれぞれのドメイン名に変更する必要があります。
ドメイン・ツリーの不連続フォレストがある場合は、プライマリ・ドメイン・コントローラごとに別々のADSIデータベース・エージェントを関連付ける必要があります。次の手順で概説し、「アイデンティティ・システム管理者の指定」で説明するように、追加のディレクトリ・プロファイルはアイデンティティ・システムのインストールおよび設定後に構成します。
追加のディレクトリ・プロファイルに対してADSIを有効にする手順
アイデンティティ・システム・コンソールに移動します。
http://hostname:port/identity/oblix
アイデンティティ・システム・コンソールで、「システム構成」サブタブをクリックし、次に左側のナビゲーション・ペインの「ディレクトリ・プロファイル」リンクをクリックします。
「追加」ボタンをクリックして、「ディレクトリ・サーバー・プロファイルの作成」ページを表示します。
ユーザーが認証時にプロファイル名を入力する必要があるため、プロファイル名としてそれぞれのドメイン名を使用することをお薦めします。
このディレクトリ・プロファイルの名前を入力します。
各ドメイン・コントローラおよびサブドメイン・コントローラのディレクトリ・プロファイルを構成する必要があります。詳細は、「アイデンティティ・システムに対するADSIの構成」を参照してください。
このディレクトリ・プロファイルのネームスペースを入力します。
ディレクトリ・タイプには複数の選択肢があります。ADSIを有効にしないでActive Directoryを使用するには、「Microsoft Active Directory」を選択する必要があります。
|
注意: パスワードの変更に対してADSIまたはSSLを有効にするオプションもあります。また、セカンダリ・チェック・ボックス「認証にLDAPを使用」を選択して、LDAPを有効にできます。LDAPが有効になっている場合、ADSI DBエージェントはプライマリ・ドメイン・コントローラに関連付けます。認証に使用するサブドメイン・コントローラに対してLDAPエージェントを構成する必要があります。 |
適切なディレクトリ・タイプを選択します。次に例を示します。
次のように、このディレクトリ・プロファイルに対してサポートされる操作を選択します。
このディレクトリ・プロファイルがドメイン・コントローラに対して構成されている場合は、すべての操作を選択します。
通常どおり、他のディレクトリ・プロファイルを完成して保存します。
ディレクトリ・プロファイルの構成の詳細は、「ディレクトリ・サーバー・プロファイルの管理」を参照してください。複数のディレクトリ・プロファイル（DBエージェント）の詳細は、「ディレクトリ・サーバー・プロファイルの管理」を参照してください。
ポリシー・マネージャは、認証にアイデンティティ・サーバーを使用します。したがって、ログイン操作では、通信先のアイデンティティ・サーバーと同じモード（ADSIまたはLDAP）を使用します。ポリシー・マネージャの設定時に、デフォルトでは、明示的なバインドを使用して、ポリシー・マネージャとアクセス・システム・コンソールがActive Directoryツリー内で認証を除くすべての操作を実行できるようにします。
|
注意: SSLは、Oracle Access ManagerでのADSI構成には不要です。ただし、業務上の他の理由でSSLが必要になる場合があります。たとえば、ディレクトリ・バインドはクリア・テキストであり、SSLは自動的には提供されません。 |
デフォルトでは、アクセス・サーバーに対してADSIを有効にすると、純粋なADSI構成が作成されます。この構成では、アクセス・サーバーが、暗黙的バインドを使用してActive Directoryツリー内のプライマリ・ドメイン・コントローラですべての操作を実行します。
アクセス・システムでのADSIサポートの構成には、次のタスクが含まれます。
『Oracle Access Managerインストレーション・ガイド』の付録の説明に従って、設定を検証します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、ポリシー・マネージャをインストールおよび設定します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、アクセス・サーバーをインストールし、ADSIを設定します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、WebGateをインストールします。
必要に応じて、「アクセス・サーバーに対するLDAP認証の有効化」の説明に従って、アクセス・サーバーに対してLDAP認証を有効にします。
ADSI認証は、LDAPよりも低速な場合があります。このため、認証や監査などの他の操作をADSIで処理する一方で、認証にLDAPを使用することが必要な場合があります。
テキスト・エディタで、AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xmlを開きます。
useLDAPBindの値をtrueに変更します。
globalparams.xmlを保存します。
AccessServer_install_dir\access\oblix\config\にあるConfigDBfailover.xmlのコピーを作成し、AppDBfailover.xmlという名前を付けます。
両方のファイルが同じディレクトリに存在する必要があります。
保存します。
アクセス・サーバーを再起動します。
Active Directoryフォレストのデプロイに基づいて、adsi_paramsファイル内のpage-sizeパラメータを変更することが必要な場合があります。たとえば、図B-2では、Active Directoryドメイン間に親子関係があり、親ドメインと子ドメインの両方に同じsamaccountnameを持つユーザーがいます。
認証スキームがActive Directoryフォレスト用のOracle Access and Identityであると想定します。この場合は、次のようになります。
user1k1がChild1ドメインにログインする場合、ユーザーはユーザーIDをChidl1\user1k1として入力できます。
user1k2がChild2ドメインにログインする場合、ユーザーはユーザーIDをChild2\user1k2として入力できます。
ただし、pageSizeパラメータが0に設定されている場合、親ドメインのuser1k1がParent\user1k1と入力してログインすると、「ログインに使用される資格認証(Parent\user1k1)が、アイデンティティ・システム内の複数のユーザー・プロファイルに対応しています。対応は一意である必要があります。」というエラーが発生します。
その理由は、ページ・サイズが0に設定されている場合、ADSIはサブドメインを検索するため、基準を満たす2人のユーザーが見つかるからです。user1k1とuser1k2が親ドメインにログインする場合は、pageSizeパラメータを有限値に設定する必要があります。100を使用することをお薦めします。
ADSIを構成した場合には、IISに関する特別な考慮事項があります。IIS 5.0 Webサーバーを使用する環境で、ADSIを指定してOracle Access Managerを構成した場合は、次の設定を行う必要があります。
Oracle Access ManagerおよびADSIと併用するためにIIS 5.0を構成する手順
次のように、Webサーバーで匿名アクセスに使用されるアカウントを変更します。
IISコンソールで構成するコンピュータのノードを右クリックし、「プロパティ」をクリックします。「マスタ プロパティ」ドロップダウン・リストから「WWWサービス」を選択して「編集」をクリックします。
「ディレクトリ セキュリティ」タブ→「匿名アクセスおよび認証コントロール」→「編集」をクリックします。
ドメイン管理者アカウントのユーザー名およびパスワードを入力します。
これは、Active Directoryのインストール時に作成されたドメインの管理者です。Oracle Access Managerのインストール時には、この管理者ユーザーとしてこのコンピュータにログインする必要があります。たとえば、AccessManager\Administrator（AccessManagerは新規ドメイン）としてログインできます。
同じウィンドウで、表示されているすべての認証済アクセス方法を選択解除します。
デフォルトでは「統合Windows認証」が選択されています。この設定では、統合認証をコールして保護されているリソースにアクセスした場合に問題が発生します。
IISコンソールで構成するコンピュータのノードを右クリックし、「プロパティ」をクリックします。「マスタ プロパティ」ドロップダウン・リストから「WWWサービス」を選択して「編集」をクリックします。
「ホーム ディレクトリ」タブを選択し、「実行アクセス権」ドロップダウン・リストで「スクリプトおよび実行可能ファイル」を選択します。
さらに、「ホーム ディレクトリ」タブで「読み取り」チェック・ボックスを選択して、スクリプトの読取り権限を付与します。
トラブルシューティングの詳細は、「Oracle Access Managerのトラブルシューティング」を参照してください。
