この章では、プロキシ・インスタンスに固有のサーバー要素を構成する方法を説明します。
注意: プロキシ・インスタンスの設定時にロード・バランシングまたは分散トポロジを構成すると、これらの要素の多くは自動的に構成されます。 |
この章には次のセクションが含まれます:
注意: 場合によっては、dsconfig またはOracle Directory Services Manager (ODSM)を使用して統合を構成することを選択できます。
|
Oracle Unified Directoryでは、それを使用することでMicrosoft Active Directoryサーバーから属性値の全範囲を取得できる、Microsoft Active Directoryページングをサポートしています。
この項では、Microsoft Active Directoryページングを、ワークフロー要素チェーンのリーフがActive Directoryサーバーに接続されている場合にのみ関連するワークフロー要素として構成する方法について説明します。また、範囲オプションを検出するための属性のスキャン処理を軽減するオプションの属性リストを構成する方法についても説明します。
この項の内容は次のとおりです。
次の例をActive Directoryページング・ワークフロー要素を構成するための基盤として使用します。この例では、LDAPプロキシ・ワークフローproxy-we1
を指すad-paging-we1
という名前のActive Directoryページング・ワークフロー要素が作成されます。
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ad-paging-we1 --type ad-paging \ --set next-workflow-element:proxy-we1 --set enabled:true
効率性を高めるために、ワークフロー要素のhandled-attributes
複数値プロパティを設定することによって特定の属性のみがスキャンされるようActive Directoryページング・ワークフロー要素を構成できます。このプロパティの値は必要な数だけ追加できます。
デフォルトで、すべての属性がスキャンされます。これは、パフォーマンスに直接影響を与える可能性があります。パフォーマンスの影響を軽減するために、handled-attributes
プロパティの値としてスキャンする必要のある属性のみをリストします。
次の例では、memberOf
属性のみがスキャンされるように、前の例で作成したワークフロー要素が変更されています:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name ad-paging-we1 \ --set handled-attributes:memberOf
追加の同期なしで、Oracle Unified Directoryおよびエンタープライズ・ユーザー・セキュリティを統合して、LDAP準拠ディレクトリ・サービスに格納されているユーザーIDを利用できます。
エンタープライズ・ユーザー・セキュリティと統合した場合、Oracle Unified Directoryで次のものがサポートされます。
Microsoft Active Directory
Novell eDirectory
Oracle Unified Directory
Oracle Directory Server Enterprise Edition
Oracle Enterprise User Securityの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。Oracle Unified Directoryおよびエンタープライズ・ユーザー・セキュリティが連携して動作するように構成する手順の詳細は、第31章「Oracle Enterprise User SecurityへのOracle Unified Directoryの統合」を参照してください。
ADパスワード・ワークフロー要素により、Oracle Unified Directory LDAPクライアント・アプリケーションでは、LDAPプロトコルを使用してMicrosoft Active DirectoryおよびActive Directoryライトウェイト・ディレクトリ・サービス(AD LDS)に保存されているユーザー・パスワードを更新できるようになります。
ADパスワード・ワークフロー要素の概要は、第12.4.3項「LDAPクライアントからのActive Directoryに格納されているユーザー・パスワードの更新の有効化」を参照してください。
次の項では、ADパスワード・ワークフロー要素およびその必須コンポーネントの構成方法について説明しています。
注意: この項の例では、dsconfig コマンド行ユーティリティを使用して、ADパスワード・ワークフロー要素およびその必須コンポーネントを作成および構成します。これらの例の説明は、設定する必要がある主要オプションおよびプロパティを対象としています。
すべての |
ADパスワード・ワークフロー要素には、LDAPクライアントおよびActive DirectoryまたはAD LDSサーバー間のインタフェースとしてOracle Unified Directoryプロキシ・サーバーが必要です。
この項の例は、第23.3.2項「ADパスワード・ワークフロー要素の作成および構成」で説明している両方のユースケースに適用されます。
UNIXシステムまたはLinuxシステムでコマンド行ツールを使用してプロキシ・サーバー・インスタンスを設定するには、次のようにします。
JAVA_HOME
環境変数が、サポートされているJVMインストール(JRE 7またはJDK 7)に設定されていることを確認します。
次のoud-proxy-setup
スクリプトを実行し、プロキシ・サーバー・インスタンスを設定します。
$ export INSTANCE_NAME=ad-oud-proxy-instance $ OUD_HOME/oud-proxy-setup --cli -p oud-port --adminConnectorPort admin-port -D "cn=Directory Manager" -j password-file
この例の説明は、次のとおりです。
ad-oud-proxy-instance
はプロキシ・インスタンス・ディレクトリ名です。この例では、oud-proxy-setup
スクリプトを実行する前に、INSTANCE_NAME
環境変数をこのディレクトリに設定します。
oud-port
は、プロキシ・サーバー・インスタンスへのアクセスに使用されるLDAPポートです。
admin-port
は管理ポートです。
password-file
には管理者パスワードが含まれます。
Windowsシステムの場合、oud-proxy-setup.bat
スクリプトを実行します。
詳細は、Oracle Unified DirectoryのインストールのOracle Unified Directoryのプロキシ・サーバーとしての設定に関する項を参照してください。
ADパスワード・ワークフロー要素およびサポートされるコンポーネントを作成および構成する場合、次の2つの選択肢があります。
パスワード変更でのみSSLが必要
このユースケースでは、secure-proxy-workflow-element
およびnext-workflow-element
の両方のプロパティでADパスワード・ワークフロー要素を定義する必要があります。secure-proxy-workflow-element
は、remote-ldap-server-ssl-policy
がalways
に設定されたLDAPサーバー拡張を使用する必要があります。
このユースケースでは、パスワードの変更操作がsecure-proxy-workflow-element
にルーティングされ、SSL経由で実行されます。パスワード変更に関係のない操作はnext-workflow-element
にルーティングされ、非SSL接続経由で実行されます。
第23.3.2.1項「パスワード変更でのみSSLが必要な場合のADパスワード・ワークフロー要素の構成」を参照してください。
すべてのLDAP操作でSSLが必要
このユースケースでは、プロキシLDAPワークフローが、常にSSLを使用する(remote-ldap-server-ssl-policy
がalways
に設定されている) LDAPサーバー拡張を指している必要があります。ADパスワード・ワークフロー要素は、next-workflow-element
プロパティでのみ定義できます。すべての操作がnext-workflow-element
にルーティングされ、SSL経由で実行されます。
第23.3.2.2項「すべてのLDAP操作でSSLが必要な場合のADパスワード・ワークフロー要素の構成」を参照してください。
次のタスクでは、パスワード変更を実行するLDAP操作でのみActive DirectoryまたはAD LDSサーバーへのSSL接続が必要な場合のADパスワード・ワークフロー要素およびその必須コンポーネントが作成および構成されます。その他のLDAP操作は非SSL接続経由で実行されます。
次のようなタスクがあります。
このユースケースでは、リモートActive DirectoryまたはAD LDSサーバーと通信するための2つのLDAPサーバー拡張が必要です。
SSL接続を必要としないLDAP操作用のLDAPサーバー拡張。
および
SSL接続を必要とするLDAP操作用のLDAPサーバー拡張。
非SSL接続用のLDAPサーバー拡張
LDAPクライアントからActive DirectoryまたはAD LDSサーバーへのSSL接続を必要としないLDAPサーバー拡張を作成するには、次のようにします。
$ dsconfig create-extension \ --set enabled:true \ --set remote-ldap-server-address:adserver.example.com \ --set remote-ldap-server-port:389 \ --set remote-ldap-server-ssl-port:636 \ --type ldap-server \ --extension-name adserver \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
このコマンドではremote-ldap-server-ssl-policy
が設定されていないため、デフォルト値のnever
によって非SSL接続が指定されます。
非SSL接続用にextension-name
がadserver
に設定されています。
LDAPサーバー拡張をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
SSL接続用のLDAPサーバー拡張
LDAPクライアントからActive DirectoryまたはAD LDSサーバーへのSSL接続を必要とするLDAPサーバー拡張を作成するには、次のようにします。
$ dsconfig create-extension \ --set enabled:true \ --set remote-ldap-server-address:adserver.example.com \ --set remote-ldap-server-ssl-policy:always \ --set remote-ldap-server-port:389 \ --set remote-ldap-server-ssl-port:636 \ --set ssl-trust-all:true \ --type ldap-server \ --extension-name adsecureserver \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
remote-ldap-server-ssl-policy
がalways
に設定されているため、Active DirectoryまたはAD LDSサーバーにアクセスするために常にSSL接続が使用されます。
SSL接続を示すためにextension-name
がadsecureserver
に設定されています。
LDAPサーバー拡張をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
このユースケースでは、リモートActive DirectoryまたはAD LDSサーバーと通信するための2つのプロキシLDAPワークフロー要素が必要です。
Active DirectoryまたはAD LDSサーバーへのSSL接続を必要としないLDAP操作用のプロキシLDAPワークフロー要素。
および
Active DirectoryまたはAD LDSサーバーへのSSL接続を必要とするLDAP操作用のセキュアなプロキシLDAPワークフロー要素。
非SSL接続用のプロキシLDAPワークフロー要素
LDAPクライアントからActive DirectoryまたはAD LDSサーバーへのSSL接続を必要としないプロキシLDAPワークフロー要素を作成するには、次のようにします。
$ dsconfig create-workflow-element \ --set client-cred-mode:use-client-identity \ --set enabled:true \ --set ldap-server-extension:adserver \ --type proxy-ldap \ --element-name adproxy \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
client-cred-mode
がuse-client-identity
バインド・モードに設定されており、これはプロキシが、クライアントがプロキシに接続するために使用したものと同じ資格証明を使用してActive DirectoryまたはAD LDSサーバーに接続することを示します。
element-name
により、プロキシLDAPワークフロー要素の名前にadproxy
が指定されます。
ldap-server-extension
により、LDAPサーバー拡張の名前にadserver
が指定されます。
ADパスワード・ワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
SSL接続用のプロキシLDAPワークフロー要素
LDAPクライアントからActive DirectoryまたはAD LDSサーバーへのSSL接続を使用するセキュアなプロキシLDAPワークフロー要素を作成するには、次のようにします。
$ dsconfig create-workflow-element \ --set client-cred-mode:use-client-identity \ --set enabled:true \ --set ldap-server-extension:adsecureserver \ --type proxy-ldap \ --element-name adsecureproxy \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
client-cred-mode
がuse-client-identity
バインド・モードに設定されており、これはプロキシが、クライアントがプロキシに接続するために使用したものと同じ資格証明を使用してActive DirectoryまたはAD LDSサーバーに接続することを示します。
element-name
により、セキュアなプロキシLDAPワークフロー要素の名前にadsecureproxy
が指定されます。
ldap-server-extension
により、LDAPサーバー拡張の名前にadsecureserver
が指定されます。
プロキシLDAPワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
このユースケースでは、Active DirectoryまたはAD LDSサーバーへのSSL接続および非SSL接続の両方をサポートするLDAP操作を処理できるADパスワード・ワークフロー要素が必要です。
このADパスワード・ワークフロー要素を作成するには、次のようにします。
$ dsconfig create-workflow-element \ --set enabled:true \ --set next-workflow-element:adproxy \ --set secure-proxy-workflow-element:adsecureproxy \ --type ad-password \ --element-name ADPasswordWFE \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
type
はad-password
である必要があります。
element-name
により、ワークフロー名にADPasswordWFE
が指定されます。
next-workflow-element
により、非SSL接続経由で操作をルーティングするadproxy
という名前のプロキシLDAPワークフロー要素にLDAP操作がルーティングされます。
secure-proxy-workflow-element
により、SSL接続経由で操作をルーティングするadsecureproxy
という名前のプロキシLDAPワークフロー要素にLDAP操作がルーティングされます。
ADパスワード・ワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
次の構成タスクでは、LDAPクライアントとActive DirectoryまたはAD LDSサーバー間のすべてのLDAP操作をSSL接続経由で実行する必要がある場合の、ADパスワード・ワークフロー要素のコンポーネントが作成および構成されます。
次のようなタスクがあります。
ADパスワード・ワークフロー要素には、リモートActive DirectoryまたはAD LDSサーバーと通信するためのLDAPサーバー拡張が必要です。
常にSSL接続を使用するLDAPサーバー拡張を作成するには、次のようにします。
$ dsconfig create-extension \ --set enabled:true \ --set remote-ldap-server-address:adserver.example.com \ --set remote-ldap-server-port:389 \ --set remote-ldap-server-ssl-port:636 \ --set remote-ldap-server-ssl-policy:always \ --set ssl-trust-all:true \ --type ldap-server \ --extension-name adsecureserver \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
type
はldap-server
である必要があります。
extension-name
により、新しい拡張の名前としてadsecureserver
が定義されます。
remote-ldap-server-ssl-policy
プロパティがalways
に設定されているため、プロキシ・サーバーへのクライアントの接続方法に関係なく、プロキシからリモートActive DirectoryまたはAD LDSサーバーへのすべての接続でSSLが使用されます。
LDAPサーバー拡張をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
このユースケースでは、リモートActive DirectoryまたはAD LDSサーバーとSSL経由で通信するためのセキュアなプロキシLDAPワークフロー要素が必要です。
セキュアなプロキシLDAPワークフロー要素を作成するには、次のようにします。
$ dsconfig create-workflow-element \ --set client-cred-mode:use-client-identity \ --set enabled:true \ --set ldap-server-extension:adsecureserver \ --type proxy-ldap \ --element-name adsecureproxy \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
type
はproxy-ldap
である必要があります。
element-name
により、新しいプロキシLDAPワークフロー要素の名前にadsecureproxy
が指定されます。
ldap-server-extension
がadsecureserver
に設定されます。これは、remote-ldap-server-ssl-policy
プロパティがalways
に設定されているLDAPサーバー拡張の名前です。
client-cred-mode
がuse-client-identity
に設定されており、これはプロキシが、クライアントがプロキシに接続するために使用したものと同じ資格証明を使用してActive DirectoryまたはAD LDSサーバーに接続することを示します。
プロキシLDAPワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
このユースケースでは、Active DirectoryまたはAD LDSサーバーへのSSL接続を常に必要とするLDAP操作を処理できるADパスワード・ワークフロー要素が必要です。
このADパスワード・ワークフロー要素にはnext-workflow-element
プロパティのみが必要です。すべての操作がSSL接続経由で実行されます。
このADパスワード・ワークフロー要素を作成するには、次のようにします。
$ dsconfig create-workflow-element \ --set enabled:true \ --set next-workflow-element:adsecureproxy \ --type ad-password \ --element-name ADPasswordWFE \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
next-workflow-element
プロパティが、adsecureproxy
という名前のセキュアなプロキシLDAPワークフロー要素に設定されています。
type
はad-password
である必要があります。
element-name
がADPasswordWFE
に設定されています。
ADパスワード・ワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
ADパスワード・ワークフロー要素をワークフローと関連付ける必要があります。次の例は、第23.3.2項「ADパスワード・ワークフロー要素の作成および構成」で説明している両方のユースケースに適用されます。
ADパスワード・ワークフロー要素のワークフローを作成するには、次のようにします。
$ dsconfig create-workflow \ --set base-dn:dc=example,dc=com \ --set enabled:true \ --set workflow-element:ADPasswordWFE \ --type generic \ --workflow-name adworkflow \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
この例の説明は、次のとおりです。
workflow-element
が、ADPasswordWFE
という名前のADパスワード・ワークフロー要素に設定されています。
workflow-name
がadworkflow
に設定されています。
ADパスワード・ワークフロー要素をサーバーで使用できるようにするために、enabled
をtrue
に設定する必要があります。
ネットワーク・グループは、Oracle Unified Directoryに対するクライアント・リクエストの単一のエントリ・ポイントです。ワークフローは、少なくとも1つのネットワーク・グループに登録される必要がありますが、複数のネットワーク・グループにアタッチできます。
前のタスクから既存のネットワーク・グループまたは新しいネットワーク・グループのいずれかにワークフローを追加する必要があります。
次の例は、第23.3.2項「ADパスワード・ワークフロー要素の作成および構成」で説明している両方のユースケースに適用されます。この例では、adworkflow
ワークフローがデフォルトのネットワーク・グループ(network-group
)に追加されます。
$ dsconfig set-network-group-prop \ --group-name network-group \ --add workflow:adworkflow \ --hostname localhost \ --port 4444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile pwd.txt \ --no-prompt
パススルー認証を実装するには、次のようにします。
次の前提条件およびベスト・プラクティス情報を確認し、必要に応じて、前提条件のステップを実行します。
パススルー認証を構成します。
dsconfig
を使用している場合は、第23.4.3項「dsconfig
を使用したパススルー認証の構成」を参照してください。
ODSMを使用している場合は、第23.4.3項「dsconfig
を使用したパススルー認証の構成」を参照してください。
パススルー認証のワークフロー要素またはKerberosワークフロー要素を使用して、ワークフローを作成します。
ユーザー・エントリがリモートLDAPサーバーに格納されている場合は、第23.4.3.1項「異なるサーバーに対するパススルー認証の構成」を参照してください。
ユーザー・エントリがKerberosサーバーに格納されている場合は、第23.4.3.2項「Kerberosサーバーに対するパススルー認証の構成」を参照してください。
ステップ3で作成したワークフローを、既存のネットワーク・グループまたは新しいネットワーク・グループに挿入します。
パススルー認証を実装する前に、第12.4.4項「パススルー認証の理解」を参照してください。また、パススルー認証の構成時には、次のステップを考慮する必要があります。
認証プロバイダのワークフロー要素を作成または識別します。
資格証明がリモートLDAPサーバーに格納されている場合、このリモート・サーバーに対するLDAPサーバー拡張およびプロキシLDAPワークフロー要素を作成し、このプロキシLDAPワークフロー要素をauth-provider-workflow-element
として使用する必要があります。詳細は、第23.4.3.1項「異なるサーバーに対するパススルー認証の構成」を参照してください。
remote-root-dn
パラメータおよびremote-root-password
パラメータを構成し、client-cred-mode=use-client-identity
バインド・モードを設定する必要があることに注意してください。
LDAPサーバー拡張の作成方法の詳細は、第20.2.1項「LDAPサーバー拡張の構成」を参照してください。
資格証明がKerberosサーバー内に格納されている場合、Kerberosワークフロー要素を作成し、このKerberosワークフロー要素を第23.4.3.2項「Kerberosサーバーに対するパススルー認証の構成」のステップ1でauth-provider-workflow-element
として使用する必要があります。
ユーザー・プロバイダのワークフロー要素を作成または識別します。
ユーザー・エントリがリモートLDAPサーバーに格納されている場合、このリモート・サーバーに対するLDAPサーバー拡張およびプロキシLDAPワークフロー要素を作成し、このプロキシLDAPワークフロー要素をuser-provider-workflow-element
として使用する必要があります。詳細は、第23.4.3.1項「異なるサーバーに対するパススルー認証の構成」を参照してください。
remote-root-dn
パラメータおよびremote-root-password
パラメータを構成する必要があることに注意してください。
LDAPサーバー拡張の作成方法の詳細は、第20.2.1項「LDAPサーバー拡張の構成」を参照してください。
ユーザー・エントリがローカルに格納されている場合、ローカル・バックエンド・ワークフロー要素を作成し、このローカル・バックエンド・ワークフロー要素をuser-provider-workflow-element
として使用する必要があります。詳細は、第23.4.3.1項「異なるサーバーに対するパススルー認証の構成」を参照してください。
パススルー認証の構成には次のベスト・プラクティスを実施することをお薦めします。
ユーザー・プロバイダ・ワークフロー要素と認証プロバイダ・ワークフロー要素に異なる接尾辞を使用している場合は、データを保護するために仮想ACIを定義することをお薦めします。仮想ACIはpta-suffix
を使用して定義します。
認証プロバイダがKerberosワークフロー要素の場合、結合ルールや認証サフィックスは指定しないでください。
認証プロバイダがプロキシ・ワークフロー要素の場合、remote-root-dn
を構成する必要があります。
ユーザー・プロバイダがプロキシ・ワークフロー要素の場合、remote-root-dn
を構成する必要があります。プロキシ・サーバーは、サイレント・バインドを実行するため、慎重に構成する必要があります。
dsconfig
を使用したパススルー認証の構成この項では、dsconfig
コマンドを使用したパススルー認証の構成方法について説明します。
次の例では、資格証明とベースDN dc=auth,dc=com
を格納したリモートLDAPサーバーを使用して、パススルー認証を構成します。Oracle Unified Directoryインスタンスはdc=user,dc=com
接尾辞の下にユーザー・エントリをローカルに格納します。
ここでは、リモートLDAPサーバーは認証サーバーとして動作し、Oracle Unified Directoryはユーザー・サーバーとして動作します。
次の各プロシージャで使用するすべてのコマンドで、プロキシ・ホスト名(-h
)、プロキシ管理ポート(-p
)、バインドDN(-D
)およびバインド・パスワード・ファイル(-j
)が指定されます。各例では、すべての証明書を信頼するために-X
オプションが使用されます。
このセクションには次のトピックが含まれます:
リモートLDAPサーバーに対してパススルー認証を構成するには、次のようにします。
資格証明を格納しているLDAPサーバーのLDAPサーバー拡張を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" \ -j pwd-file -X -n create-extension --extension-name authServer \ --type ldap-server --set enabled:true \ --set remote-ldap-server-address:authHostname \ --set remote-ldap-server-port:1389 \
LDAPサーバー拡張の作成方法の詳細は、第20.2.1.4項「LDAPサーバー拡張の作成」を参照してください。
ステップ1で作成したLDAPサーバー拡張を使用して、プロキシLDAPワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name authProxy --type proxy-ldap \ --set enabled:true --set client-cred-mode:use-client-identity \ --set ldap-server-extension:authServer \ --set remote-root-dn:cn=administrator,cn=users,dc=auth,dc=com \ --set remote-root-password:********
プロキシLDAPワークフロー要素の作成方法の詳細は、第23.3.2.1.2項「プロキシLDAPワークフロー要素の作成」を参照してください。
ローカル・バックエンド・ワークフロー要素を作成して、dc=user,dc=com
接尾辞の下にユーザー・エントリをローカルに格納します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name userWfe --type db-local-backend \ --set enabled:true --set base-dn:"dc=user,dc=com"
パススルー認証のワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ptaWfe \ --type pass-through-authentication --set enabled:true \ --set auth-provider-workflow-element:authProxy \ --set user-provider-workflow-element:userWfe \ --set pta-auth-suffix:dc=auth,dc=com --set pta-suffix:dc=user,dc=com \ --set pta-user-suffix:dc=user,dc=com
Kerberosワークフロー要素を使用してパススルー認証を構成するステップは、次のとおりです。
Kerberos認証プロバイダのワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --type kerberos-auth-provider \ --element-name kerberosWfe --set enabled:true
ローカル・バックエンド・ワークフロー要素を作成して、dc=user,dc=com
接尾辞の下にユーザー・エントリをローカルに格納します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name userWfe --type db-local-backend \ --set enabled:true --set base-dn:dc=user,dc=com
パススルー認証のワークフロー要素を作成します。
dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ create-workflow-element --element-name ptaWfe \ --set auth-provider-workflow-element:kerberosWfe --set enabled:true \ --set user-provider-workflow-element:userWfe --type pass-through-authentication
ODSMを使用したパススルー認証ワークフロー要素の構成の詳細は、第17.3.4.1項「ワークフロー要素の作成」を参照してください。
特定の要件があり、Oracle Unified Directoryでその要件に対応するために必要な機能が提供されない場合、Oracle Unified DirectoryプラグインAPIを使用して既存のディレクトリ・サーバー機能を拡張できます。
たとえば、LDAP操作をカスタマイズしたり、結果をプログラムで操作するプラグインを構成できます。
注意:
|
プロキシ・サーバーは、ヘルス・チェックを定期的に実行してホストのステータス、可用性を順に判別します。ldap-server-extension
インスタンスのmonitoring-check-interval
プロパティを使用すると、チェックの間の時間間隔を構成できます。
すべてのバックエンド・サーバーに対するプロキシ構成のmonitoring-check-interval
プロパティは、プロキシ・サーバーによってスケジュールされたヘルス・チェック間の時間間隔(ミリ秒)を定義します。
dsconfig
コマンドを次のように使用すると、monitoring-check-interval
プロパティを設定できます。
dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --no-prompt\
set-extension-prop \
--extension-name proxy1 \
--set monitoring-check-interval:50000 \
グローバル索引では、エントリが特定の分散パーティションにマップされるため、分散トポロジでの検索操作および変更操作が速くなります。グローバル索引では、電話番号など一意の属性に基づいてエントリがマップされます。グローバル索引のリストは、グローバル索引カタログに含まれます。1つのプロキシ・インスタンスに1つ以上のグローバル索引カタログを含めることができます。
注意: グローバル索引およびグローバル索引カタログを構成および管理するには、リモート・サーバーで特定の制御、特にLDAP読込み前制御およびCSN制御を有効にする必要があります。詳細は、付録B「サポートされている制御および操作」を参照してください。 |
このセクションには次のトピックが含まれます:
gicadm
を使用したグローバル索引カタログの構成グローバル索引カタログは、INSTANCE_DIR/OUD/catalogs
にあるBerkeleyデータベースに格納されます。分散トポロジの高可用性を確保するために、グローバル索引カタログのレプリケーションをお薦めします。詳細は、第23.7.2項「グローバル索引カタログのレプリケーション」を参照してください。
gicadm
コマンドは、次のサーバー・インスタンス・ディレクトリにあります:
UNIXの場合: INSTANCE_DIR/OUD/bin/gicadm
Windowsの場合: INSTANCE_DIR\OUD\bat\gicadm.bat
詳細は、付録A「gicadm」を参照してください。
この項で示している各プロシージャでは、分散アーキテクチャにプロキシがデプロイされており、デフォルトのプロキシ管理ポート(4444)を使用していることが前提となっています。このセクションには次のトピックが含まれます:
グローバル索引を作成するには、次のプロシージャで示しているとおりに、まずグローバル索引カタログを作成する必要があります。このプロシージャでは、グローバル索引カタログの作成、グローバル索引の作成と追加およびグローバル索引へのデータの追加を実行する方法を示しています。必要に応じて、データは後でグローバル索引に追加できます。
開始する前に、プロキシを分散にデプロイしておく必要があります。
gicadm
コマンドを使用して、グローバル索引カタログを作成します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ create-catalog --catalogName sampleCatalog
カタログ名は一意である必要があります。
作成したグローバル索引カタログに、少なくとも1つのグローバル索引を作成して追加します。
次のコマンドによって、telephoneNumber
属性値で構成されたグローバル索引が作成され、そのグローバル索引が、前のステップで作成したグローバル索引カタログに追加されます。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ add-index --catalogName sampleCatalog --attributeName telephoneNumber
後でadd-index
サブコマンドを使用して、追加のグローバル索引をこのグローバル索引カタログに追加できます。
グローバル索引カタログを分散に関連付けます。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ associate --catalogName sampleCatalog \ --distributionWorkflowElement myDistributionName
ワークフロー要素の詳細は、第17.1.8項「dsconfig
を使用したワークフロー要素の構成」を参照してください。分散の詳細は、第22.1項「dsconfig
コマンドを使用した分散の構成」を参照してください。
split-ldif
コマンドを使用して、1つのLDIFファイルから複数のファイルを生成します。
split-ldif
コマンドでは、プロキシで構成されている分散アルゴリズムに基づいて、1つのLDIFファイルのコンテンツが、複数のLDIFファイルに分割されます。このコマンドを使用して、グローバル索引にロードするデータを含めるファイルを生成することもできます。ディレクトリ・サービスを開始したときに索引付けする必要があるデータをリモートLDAPサーバーに含める場合は、グローバル索引の初期化時にsplit-ldif
を使用する必要があります。ディレクトリにデータを含めない状態で開始する場合は、このステップを省略できます。
split-ldif
コマンドの詳細は、このコマンドを使用してグローバル索引に1つまたは複数の索引付き属性を移入する方法の例も含めて、付録A「split-ldif」を参照してください。
gicadm import
コマンドを使用して、グローバル索引にデータをインポートします。
詳細は、第23.7.1.8項「グローバル索引カタログへのコンテンツのインポート」を参照してください。
グローバル索引カタログのプロパティは、グローバル索引カタログのレプリケーションに関連しています。グローバル索引カタログのプロパティのリストおよびそれらの使用についての説明を表示するには、第23.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。
グローバル索引カタログのすべてのプロパティを表示するには、gicadm
コマンドをget-catalog-prop
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-catalog-prop --catalogName sampleCatalog --property all
出力は、次のようになります。
Property : Value(s) -------------------:------------------------------- replication-server : localhost:3390, localhost:4390 server-id : 4247 window-size : 100 heartbeat-interval : 1000 group-id : 1
グローバル索引カタログの特定のプロパティの値を表示するには、そのプロパティを指定します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-catalog-prop --catalogName sampleCatalog --property heartbeat-interval
グローバル索引のプロパティは、グローバル索引カタログのレプリケーションに関連しています。使用可能なグローバル索引カタログのプロパティは、次のとおりです:
replication-server
: host:portの形式で、レプリケーション・トポロジ内のサーバーをリストします。set-catalog-prop
コマンドを使用してこのプロパティを変更しないでください。かわりに、enable-replication
コマンドを使用します。
server-id
: グローバル索引カタログ・レプリケーション・ドメイン内のグローバル索引に一意の識別子を指定します。同一のグローバル索引カタログ・レプリケーション・ドメイン内の各インスタンスに、異なるサーバーIDを指定する必要があります。1つのインスタンスが複数のグローバル索引カタログ・レプリケーション・ドメインのメンバーとなっている場合は、それぞれのグローバル索引カタログ・レプリケーション・ドメイン構成で同じサーバーIDを使用できます。
構文: 1 <= INTEGER <= 65535またはテキスト。このプロパティは変更しないでください。
window-size
: インスタンスがレプリケーション・サーバーとの通信で使用するウィンドウ・サイズを指定します。デフォルト値は100です。
構文: 0 <= INTEGERまたはテキスト。
heartbeat-interval
: インスタンスがレプリケーション・サーバーとの通信で使用するハートビート間隔を指定します。インスタンスは、レプリケーション・サーバーからの、指定した間隔内での定期的なハートビートを予期します。ハートビートをこの間隔内に受信しなかった場合、インスタンスはその接続をクローズして、別のレプリケーション・サーバーに接続します。
構文: 100 ms <= DURATION (ms)
group-id
: 特定のレプリケートされたドメインに関連付けられたID。この値は、レプリケートされたドメインのグループIDを定義します。レプリケーション・システムは、自身のものと同じグループIDのレプリケーション・サーバーに接続して更新を送信し、レプリケートしようとします。
構文: 1 <= INTEGER <= 127
注意: このプロパティは変更しないでください。 |
グローバル索引カタログのプロパティのリストは、第23.7.1.3項「グローバル索引カタログのプロパティの変更」を参照してください。
gicadm
コマンドをset-catalog-prop
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --set property:value
たとえば、変更可能なプロパティの1つとして、ハートビート間隔があります。この場合、次のように実行します:
--set heartbeat-interval:500
グローバル索引またはグローバル索引カタログの複数値プロパティの場合、--add
オプションまたは--remove
オプションを使用して、値を追加または削除できます。
グローバル索引カタログの場合、複数値を含めることができるのは、replication-server
プロパティのみです。グローバル索引の複数値プロパティの場合は、かわりにset-index-prop
サブコマンドを使用します。
値を追加するには、gicadm
コマンドをset-catalog-prop
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --add replication-server:hostname
複数値プロパティから値を削除するには、gicadm
コマンドをset-catalog-prop
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog \
--remove replication-server:hostname
グローバル索引カタログのいずれかのプロパティを変更して、その後それらの値をデフォルト値にリセットする必要が生じた場合は、次のプロシージャを実行します。
gicadm
コマンドをset-catalog-prop
サブコマンドとともに使用します。
たとえば、ハートビート間隔をリセットする場合は、次のように実行します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
set-catalog-prop --catalogName sampleCatalog --reset heartbeat-interval
グローバル索引のプロパティを表示するには、gicadm
コマンドをget-index-prop
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ get-index-prop --catalogName sampleCatalog --attributeName telephoneNumber \ --property all
プロパティは、次のようになります:
Property Names : Property Values ---------------------------------------------:--------------------------------- global-index-deleted-entry-retention-timeout : 500 db-cleaner-min-utilization : 50 db-log-file-max : 10000000 db-checkpointer-bytes-interval : 20000000 db-checkpointer-wakeup-interval : 30 db-num-lock-tables : - db-num-cleaner-threads : - db-txn-no-sync : false db-txn-write-no-sync : true je-property : - db-directory : catalogs db-directory-permissions : 700 global-index-catalogs-shared-cache : global-index-catalogs-shared-cac global-index-attribute : telephoneNumber
注意: 通常、これらの値は変更できません。 |
特定のファイルのコンテンツを、グローバル索引カタログ内の1つまたは複数のグローバル索引にインポートできます。ファイルのコンテンツのインポート先のカタログの名前を指定する必要があります。オプションでattributeName
パラメータを指定することによって、ファイルのコンテンツを特定の索引に関連するデータにフィルタで抽出できます。
インポート対象のデータ・ファイルは、たとえば、split-ldif
コマンドまたはgicadm export
コマンドを実行することによって作成できます。
ファイルのコンテンツをグローバル索引カタログにインポートするには、gicadm
コマンドをimport
サブコマンドとともに使用します。例:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ import --file /usr/local/import-file --catalogName sampleCatalog
gicadm import
タスクの実行中にプロキシ・サーバーが停止すると、グローバル索引カタログ・ワークフロー要素は無効になります。この場合、次のようにdsconfig
を使用して、グローバル索引カタログ・ワークフロー要素を再度有効にします。ここで、sampleCatalogはグローバル索引カタログの名前です:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name sampleCatalog set enabled:true
グローバル索引カタログのコンテンツをディレクトリにエクスポートするには、gicadm
コマンドをexport
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
export --exportDirectory directory-path --catalogName sampleCatalog
グローバル索引カタログを分散要素に関連付けるには、gicadm
コマンドをassociate
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
associate --catalogName sampleCatalog --distributionWorkflowElement element-name
グローバル索引カタログを分散ワークフロー要素に関連付けると、グローバル索引カタログが分散のプロパティにリストされるようになります。分散に関連付けるグローバル索引カタログを確認するには、dsconfig get-workflow-element-prop
コマンドを使用します。ワークフロー要素の詳細は、第17.1.8項「dsconfig
を使用したワークフロー要素の構成」を参照してください。
グローバル索引カタログの分散トポロジへの関連付けを解除するには、グローバル索引カタログが関連付けられている分散ワークフロー要素を確認する必要があります。対象のグローバル索引カタログを使用している分散ワークフロー要素の名前を確認するには、dsconfig get-workflow-element-prop
コマンドを使用して、分散トポロジのプロパティを表示します。
グローバル索引カタログの分散ワークフロー要素への関連付けを解除するには、gicadm
コマンドをdisassociate
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \
disassociate --distributionWorkflowElement element-Name
たとえば新規属性をマップするために、新規グローバル索引を既存のグローバル索引カタログに追加するには、次のプロシージャを使用します。このプロシージャによって、グローバル索引が作成され、グローバル索引カタログに追加されます。グローバル索引カタログには追加することなく、グローバル索引を作成することはできません。
開始する前に、グローバル索引カタログを構成しておく必要があります。
gicadm
コマンドをadd-index
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ add-index --catalogName sampleCatalog --attributeName telephoneNumber
gicadm
コマンドをremove-index
サブコマンドとともに使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ remove-index --catalogName sampleCatalog --attributeName telephoneNumber
高可用性を確保するために、グローバル索引カタログをレプリケートする必要があります。第3.2.7項「構成7: レプリケートされる複数のプロキシ」の図で示しているように、標準のハードウェア・ロード・バランサを使用でき、デプロイメント内のグローバル索引カタログのレプリケーションを構成できます。
このセクションには次のトピックが含まれます:
この項では、図23-1に示しているように、3つのプロキシ・インスタンスが設定されたレプリケート・トポロジを作成し、グローバル索引カタログのレプリケーションを有効する方法について説明します。
レプリケート・トポロジを作成してグローバル索引カタログのレプリケーションを有効にするには、次のようにします。
サーバー・トポロジに、少なくとも2つのプロキシ・インスタンスをインストールします。
これらのインスタンスは、冗長性のために、個別の物理マシンに配置する必要があります。
トポロジ内のプロキシのインスタンスごとに1つのグローバル索引カタログを構成して、1つ以上のグローバル索引を追加します。
gicadm
コマンドを使用したグローバル索引カタログの構成の詳細は、第23.7.1.1項「グローバル索引が含まれるグローバル索引カタログの作成」を参照してください。
グローバル索引カタログのレプリケーションを有効にします。
トポロジ全体で、グローバル索引カタログがレプリケートされるプロキシ・インスタンスは、CLI構文においては、localインスタンスと見なされますが、コマンドで宣言されたその他のプロキシ・インスタンスはremoteインスタンスと見なされます。gicadm enable-replication
コマンド実行の詳細は、第23.7.2.2項「グローバル索引カタログのレプリケーションの有効化」を参照してください。
レプリケート・トポロジに含まれるプロキシごとにこのステップを繰り返します。
レプリケーションを初期化するプロキシ・インスタンスを選択します。グローバル索引カタログのコンテンツが最新となっているプロキシ・インスタンスを確認します。
あるいは、トポロジに含まれる各プロキシにLDIFファイルをインポートできます。第23.7.1.8項「グローバル索引カタログへのコンテンツのインポート」を参照してください。
前のステップで選択したプロキシ・インスタンスで、gicadm initialize-replication --all
コマンドを実行します。詳細は、第23.7.2.3項「グローバル索引カタログのレプリケーションの初期化」を参照してください。
注意: レプリケートされた複数のリモートLDAPサーバーで1つのグローバル索引カタログを使用する際に、書込み操作で同一の値を同時に変更できる上に、その値が索引付けされている場合は、1つのリモートLDAPサーバーのみでそれらの書込み操作を処理する必要があります。このためには、ロード・バランシング・ワークフロー要素の重みを、すべての書込みトラフィックが同一サーバーに送られるように設定できます。詳細は、第21.1.4項「ロード・バランシングのプロパティの変更」を参照してください。 |
このコマンドでは、レプリケーションが構成されますが、レプリケーションの初期化は行われません。このコマンドは、-h
オプションによって宣言されたローカル・ホストで、そのローカル・ホストの管理ポートを使用して実行されます。リモート・ホストは、--remoteHost
オプションによって宣言されますが、完全修飾ホスト名またはIPアドレスである必要があります。このコマンドによって、バインドIDがadminUIDであるグローバル索引カタログ・レプリケーション管理者が作成されます。
インストール時にグローバル索引カタログを作成した場合は、グローバル索引管理者はすでに作成されており、このパスワードはディレクトリ・マネージャのものと同じです。グローバル索引を使用した分散デプロイメントのインストールの詳細は、Oracle Unified Directoryのインストールの単純な分散の構成に関する項を参照してください。
グローバル索引カタログのレプリケーションを有効にするには、gicadm enable-replication
コマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ enable-replication --catalogName sampleCatalog --adminUID adminUID --localReplicationPort 8989 --remoteReplicationPort 8989 \ --remoteAdminPort 4444 --remoteHost host
このコマンドによって、ローカル・ホスト上のsampleCatalogというグローバル索引カタログのコンテンツをレプリケートするようプロキシ構成が更新されます。トポロジ内のいずれかのプロキシ・インスタンスですでにグローバル索引カタログがレプリケートされている場合、このコマンドによってトポロジ内のその他すべてのプロキシ・インスタンスの構成が更新されます。このため、トポロジ内の最初の2つのプロキシ・インスタンスに対してgicadm enable-replication
を実行した後は、トポロジを拡張するために追加される新規プロキシ・インスタンスごとにこのコマンドを1回実行すれば十分です。
このコマンドを実行するプロキシ・インスタンスのレプリケーション・ポートを--localReplicationPort
オプションで宣言しておく必要があります。このローカル・インスタンスのグローバル索引カタログが、後でgicadm initialize-replication
コマンドによってトポロジ全体にレプリケートされることになります。--remoteReplicationPort
オプションによって、sampleCatalogというグローバル索引カタログのコンテンツが、このローカル・インスタンスからリモート・インスタンスにレプリケートされます。--remoteAdminPort
は、リモート・プロキシ・インスタンスの管理ポートです。
ファイルに格納されている、ローカル・プロキシ・インスタンスのパスワードを--adminPasswordFile
サブオプションを使用して宣言できます。
オプションで、--remoteBindDN
サブオプションを使用してリモート・サーバーへのバインドのためのDNを、および--remoteBindPasswordFile
サブオプションを使用してファイル内の、リモート・プロキシ・インスタンスのパスワードを宣言できます。これらを宣言しないと、--adminUID
によって宣言されたグローバル管理者がバインドに使用されます。
またオプションで、--localSecureReplication
サブオプションを使用してローカル・サーバーのレプリケーションポートを通した通信、および--remoteSecureReplication
サブオプションを使用してリモート・サーバーのレプリケーション・ポートを通した通信のセキュリティの確保を必須とすることもできます。
このコマンドによって、-h
オプションによって宣言されたサーバー上のプロキシ・インスタンスから、トポロジに含まれるすべてのインスタンスへのsampleCatalogというグローバル索引カタログのコンテンツが初期化されます。指定するポートは管理ポートであり、レプリケーション・ポートではありません。
レプリケーション・トポロジに含まれるすべてのプロキシ・インスタンスへのグローバル索引カタログのレプリケーションを初期化するには、次のように、gicadm initialize-replication
--all
を使用します:
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ initialize-replication --catalogName sampleCatalog \ --adminUID adminUID --all
gicadm status-replication
コマンドを使用して、レプリケーションが完了したことを確認します。
レプリケーションが完了していない場合は、トポロジ内のすべてのプロキシ・インスタンスのステータスがrunning replicated
となっています。
たとえばパッチを適用した後に、トポロジ内のプロキシ・インスタンスを再起動する前に、レプリケーションが完了している必要があります。
gicadm status-replication
コマンド使用の詳細は、第23.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスの表示」を参照してください。
グローバル索引カタログのレプリケーションを無効にするには、gicadm disable-replication
コマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ disable-replication --catalogName sampleCatalog --adminUID adminUID
gicadm disable-replication
コマンドは、トポロジ内の、レプリケーションを無効にするプロキシ・インスタンスごとに実行する必要があります。
レプリケートされたグローバル索引カタログの基本構成情報を表示するには、gicadm status-replication
コマンドを使用します。
$ gicadm -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ status-replication --catalogName sampleCatalog --adminUID adminUID
カタログ名を宣言しないと、レプリケートされたすべてのグローバル索引カタログのステータス情報が表示されます。
レプリケーション・ログは、レプリケーション修復ログに格納されます。変更は変更ログに記録されます。これらのログへのアクセスの詳細は、第35.5.4項「ログへのアクセス」を参照してください。
グローバル索引カタログをレプリケートする場合は、変更ログ用のディスク領域をプロビジョニングしてください。デフォルトで、これらのログには変更が24時間格納されます。300,000回の書込み操作に、訳100MBが必要です。デフォルト値の24時間では、その期間に予期されるサービスのサイズに基づいてログを構成する必要があります。ヒントとして、24時間で1秒当たり5000回の変更につき約150GBのプロビジョニングが考えられます。ログを構成する方法の詳細は、第35.3項「ログの構成」を参照してください。
この項では、レプリケーション・トポロジでイベントが発生した場合の典型的なライフサイクルの例をいくつか示します。これらすべての例で使用している基本のレプリケーション・トポロジは、第23.7.2.1項「レプリケート・トポロジの作成およびグローバル索引カタログのレプリケーションの有効化」で作成したものです。
例23-1 レプリケート・トポロジでのグローバル索引カタログの再起動
図23-2で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス3がなんらかの理由でダウンするか停止した場合、次のステップに従って、3つのプロキシ・インスタンスがレプリケートされていることを確認します。
プロキシ・インスタンス3で、start-ds
コマンドを発行します。
第23.7.2.5項「レプリケートされたグローバル索引カタログ構成のステータスの表示」に示されているように、gicadm status-replication
コマンドを実行することによって、レプリケーションが完了しているかどうかを確認できます。
例23-2 レプリケートされたグローバル索引カタログ・トポロジへのグローバル索引の追加
図23-3で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログに、属性(たとえば、mail
)を追加するには、次のステップに従います。
まず、3つのプロキシ・インスタンスそれぞれで、gicadm add-index mail
コマンドを実行します。
分散ルートの下のディレクトリ・データをいずれかのリモートLDAPサーバーからfile1という名前のLDIFファイルに、export-ldif
を使用してエクスポートします。
split-ldif
を実行して、指定したディレクトリにGICコンテンツを生成します。
プロキシ・インスタンス1で、コマンドgicadm import --importDirectory directory-name
を実行します。
プロキシ・インスタンス1で、gicadm initialize-replication --all
コマンドを実行します。このコマンドによって、変更が、プロキシ1からトポロジ内のその他すべてのプロキシにプッシュされ、新規グローバル索引が追加されます。
例23-3 レプリケートされたグローバル索引カタログのコンテンツの上書き
図23-4で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。プロキシ・インスタンス2および3のグローバル索引カタログのコンテンツをインスタンス1のグローバル索引カタログのコンテンツで上書きするには、次のステップに従います。
プロキシ・インスタンス1で、gicadm initialize-replication --all
コマンドを実行します。これによってプロキシ・インスタンス2および3のグローバル索引カタログのコンテンツが、プロキシ・インスタンス1のグローバル索引カタログのコンテンツに置き換わります。
例23-4 レプリケート・トポロジへのプロキシの追加
図23-5で示している例では、3つのプロキシ・インスタンスが、レプリケートされたグローバル索引カタログを指定して実行されています。レプリケートされたグローバル索引カタログが指定された4つ目のプロキシ・インスタンスを追加するには、その新規プロキシ・インスタンスについて次のステップを実行します。
新規のプロキシ・インスタンス4で、gicadm create-catalog
コマンドを実行します。
コマンドgicadm add-index cn
、gicadm add-index sn
およびgicadm add-index mail
を実行します。
gicadm associate
コマンドを実行します。
次のコマンドを実行します:
gicadm enable-replication --localReplicationPort replication port of instance 4 --remoteHost name or IP address of host running instance 1
このコマンドによって、インスタンス1からインスタンス4までのレプリケーションが構成されます。
initialize replication --from proxy 1
コマンドを実行します。
Oracle Unified Directoryディレクトリ・サーバーをLDAPデータ・ソースとして指定してプロキシ・サーバーを使用する場合、プロキシ・サーバーとディレクトリ・サーバーとの間の接続をディレクトリ・サーバーの管理IDを使用してバインドする必要があります。そうしない場合は、グローバル索引カタログが正常に機能できるようにディレクトリ・サーバーに一定の構成が必要です。
制御のグローバルACIが変更されていない場合は、ldapmodify
コマンドを使用して、次の変更をディレクトリ・サーバーに適用します。
dn: cn=Access Control Handler,cn=config changetype: modify add: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 | | 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 | | 2.16.840.1.113730.3.4.16 || 1.3.6.1.1.13.1 || 1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";) ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName| |modifyTimestamp||entryDN||entryUUID||subschemaSubentry||aclRights||aclRightsInfo") (version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)
ACIをOracle Unified Directory 11g R1ディレクトリ・インスタンスから削除する場合、次のACIを削除する必要があります。
dn: cn=Access Control Handler,cn=config changetype: modify delete: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";) ds-cfg-global-aci: (targetattr="createTimestamp||creatorsName||modifiersName|| modifyTimestamp||entryDN||entryUUID||subschemaSubentry") (version 3.0; acl "User-Visible Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)
ACIをOracle Unified Directory 11g R2ディレクトリ・インスタンスから削除する場合、次のACIを削除する必要があります。
dn: cn=Access Control Handler,cn=config changetype: modify delete: ds-cfg-global-aci ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
注意: 前述のOIDは、Oracle Unified Directoryの未変更の構成に適しています。デフォルトのOIDを変更する場合、適切なOIDを含めるようコマンドを変更します。 |
グローバル索引カタログには次の制御が必要です:
読込み前制御、OID = 1.3.6.1.1.13.1
CSN制御、OID = 1.3.6.1.4.1.42.2.27.9.5.9
各ワークフローは、このワークフローで処理される操作に適用されるACIのリストを定義しているアクセス制御グループに関連付けられます。
デフォルトでは、ローカル・バックエンドと呼ばれるアクセス制御グループが作成されます。このアクセス制御グループには、ユーザー・データから取得されたすべてのACIが含まれています。「名前」属性は削除できません。ワークフローの仮想ACIが無効化されている場合、そのワークフローのアクセス制御グループとしてローカル・バックエンドを指定する必要があります。仮想ACIが無効になるワークフローの場合、任意のアクセス制御グループを使用できます。
この項では、ワークフローの仮想ACIの構成方法について説明します。この項の内容は次のとおりです。
dsconfig
を使用した仮想ACIの構成この項では、dsconfig
を使用した仮想ACIの構成方法について説明します。この項の内容は次のとおりです。
特定のワークフローの仮想ACIを有効にするには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-prop --workflow-name workflow1 --set virtual-aci-mode:true \ --set access-control-group:group1
この例では、group1
はアクセス制御グループを参照します。このアクセス制御グループは、デフォルトで作成されたローカル・バックエンド
まはたそれ以外の作成済のアクセス制御グループのいずれかにすることができます。アクセス制御グループの作成の詳細は、第17.1.11項「dsconfig
によるアクセス制御グループの構成」を参照してください。
特定のワークフローの仮想ACIを無効にするには、次のコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-workflow-prop --workflow-name workflow1 --set virtual-aci-mode:false \ --set access-control-group:"Local Backends"
注意: ワークフローの仮想ACIを無効にする際は、次の点に注意してください。
|
dsreplication
コマンドの--advanced
モードによって、仮想ACIのレプリケーションを構成できます。
仮想ACIのレプリケーションを構成するステップは、次のとおりです。
仮想ACIのレプリケーションを有効化します。
$ dsreplication enable \ --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \ --bindPasswordFile1 pwd-file1 --replicationPort1 8989 \ --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd-file2--replicationPort2 8989 \ --adminUID admin --adminPasswordFile admin-pwd-file \ --advanced --baseDN virtual-acis -X -n
レプリケーションを初期化します。
$ dsreplication initialize --advanced --baseDN virtual-acis \ --adminUID admin --adminPasswordFile admin-pwd-file \ --hostSource host1 --portSource 4444 \ --hostDestination host2 --portDestination 4444 -X -n
ODSMを使用して、Oracle Unified Directoryプロキシ・サーバーのアクセス制御要素を作成できます。このようにするには、次の手順を実行します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」要素を選択します。
プロパティが右側のペインに表示されます。
「アクセス制御グループ」を開きます。
「追加」をクリックして、プロキシ・インスタンスによって処理されるローカル・バックエンドを1つ以上指定します。
いずれのワークフローにも関連付けられていないこれらのアクセス制御グループを削除する場合は、「削除」をクリックします。アクセス制御グループを削除すると、そのアクセス制御グループに含まれるすべてのACIが削除されます。