Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

Previous: パート I Directory Server の管理

パート II Directory Proxy Server の管理

第 17 章 Directory Proxy Server のツール

Sun Java^TM System Directory Proxy Server には、Directory Proxy Server のインスタンスの登録と管理を行うためのブラウザインタフェースとコマンド行ツールがあります。このブラウザインタフェースは、Directory Service Control Center (DSCC) と呼ばれています。この章では、DSCC やコマンド行による Directory Proxy Server の管理に必要な基本タスクについて説明します。

特殊なタスクの実行に DSCC を使用するか、コマンド行を使用するかを決定するには、「DSCC を使用する場合とコマンド行を使用する場合の判断」を参照してください。

管理フレームワークの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「Directory Server Enterprise Edition の管理モデル」を参照してください。

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

Directory Proxy Server を管理するために DSCC を使用する

この節では、Directory Proxy Server の管理目的で、DSCC にアクセスする方法について説明します。

Directory Proxy Server の管理目的で、DSCC にアクセスする

Directory Server の場合と同じ方法で DSCC にアクセスします。

「DSCC にアクセスする」を参照してください。

「プロキシサーバー」タブをクリックして Directory Proxy Server を表示し管理します。

次の図に Directory Proxy Server の最初のウィンドウを示します。

図 17–1 Directory Proxy Server の最初の DSCC ウィンドウ

Directory Proxy Server インスタンスをクリックして、その該当のサーバーを表示または管理します。

注 –
DSCC の使い方の詳細は、オンラインヘルプを参照してください。

Directory Proxy Server のコマンド行ツール

Directory Proxy Server の操作に使用するコマンド行ツールは、dpadm および dpconf と呼ばれています。これらのコマンドの使用方法については、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。

dpconf、dsconf、dsmig、 dsccmon、dsccreg、および dsccsetup は LDAP ベースのコマンドなので、認証を行うにはこれらのコマンドのユーザーバインド DN とパスワードを指定する必要があります。一方、dpadm コマンドと dsadm コマンドはインスタンスファイルで動作します。

この節では、dpadm コマンドと dpconf コマンドの場所について説明します。また、環境変数、これらのコマンドの比較、これらのコマンドを使用する際の参照情報の入手先についても記載します。

Directory Proxy Server コマンドの場所

Directory Proxy Server のコマンド行ツールは、デフォルトでは次の場所にあります。

install-path/dps6/bin

インストールパスはオペレーティングシステムによって異なります。すべてのオペレーティングシステムのインストールパスは、「デフォルトのパスとコマンドの場所」に一覧表示されています。

`dpconf` に対する環境変数の設定

dpconf コマンドには、環境変数によってプリセットできるオプションが必要です。コマンドを使用する際にオプションが指定されていない場合や、環境変数が設定されていない場合は、デフォルト設定が使用されます。環境変数は次のオプションに対して設定できます。

-D userDN: ユーザーバインド DN。環境変数: LDAP_ADMIN_USER。デフォルト: cn=Proxy Manager。
-w password-file: ユーザーバインド DN のパスワードファイル。環境変数: LDAP_ADMIN_PWF。デフォルト: パスワード入力用のプロンプトを表示する。
-h host: ホスト名または IP アドレス。環境変数: DIR_PROXY_HOST。デフォルト: localhost。
-p LDAP-port: LDAP ポート番号。環境変数: DIR_PROXY_HOST。デフォルト: サーバーインスタンスが root として実行中の場合は 389、サーバーインスタンスが通常のユーザーとして実行中の場合は 1389。
-e, --unsecured: dpconf がデフォルトでクリア接続を開くように指定します。環境変数: DIR_PROXY_UNSECURED。この変数が設定されていない場合、dpconf はデフォルトでセキュリティー保護された接続を開きます。

詳細は、dpconf(1M) のマニュアルページを参照してください。

`dpadm` と `dpconf` の比較

次の表に、dpadm コマンドと dpconf コマンドの比較を示します。

表 17–1 dpadm コマンドと dpconf コマンドの比較


	`dpadm` コマンド	`dpconf` コマンド
目的	Directory Proxy Server のローカルインスタンスのプロセスやファイルを管理すること	Directory Proxy Server のローカルやリモートのインスタンスを設定すること
ユーザー	オペレーティングシステムのユーザー	LDAP ユーザー
ローカルまたはリモート	コマンドはインスタンスに対してローカルでなければなりません。つまり、コマンドは、サーバーが実行中のホストで実行する必要があります。	コマンドはインスタンスに対してローカルにすることができますが、ネットワーク上のどの場所からも実行できます。
コマンドの使用例	Directory Proxy Server のインスタンスを作成します。 Directory Proxy Server のインスタンスを起動および停止します。証明書データベースを管理します。	Directory Proxy Server のインスタンスの設定を変更します。データビューを作成します。データソースプールの負荷分散を設定します。
サーバーの状態	サーバーは稼動中でも停止していてもかまいません。	サーバーは動作している必要があります。
コマンドがサーバーインスタンスを識別する方法	インスタンスパスを指定することで識別します。インスタンスパスは相対でも絶対でもかまいません。	ホスト名か IP アドレスと、ポート番号を指定することで識別します。コマンドは、LDAP ポート (`-p`) または LDAPS セキュアポート (`-P`) を使用します。コマンド行にポート番号が指定されていない場合は、PROXY_PORT 環境変数が使用されます。環境変数が設定されていない場合は、デフォルトポートが使用されます。

`dpconf` による複数の値を持つプロパティーの設定

Directory Proxy Server のプロパティーによっては、複数の値をとることがあります。複数の値を指定するには、次の構文を使用します。

$ dpconf set-container-prop -h host -p port \
 property:value [property:value]

たとえば、my-view という LDAP データビューに複数の書き込み可能属性を設定するには、次のコマンドを入力します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\
 writable-attr:uid writable-attr:cn writable-attr:userPassword

すでに値が含まれている複数値プロパティーに値を追加するには、次のコマンドを入力します。

$ dpconf set-container-prop -h host -p port \
 property+:value

すでに値が含まれている複数値プロパティーから値を削除するには、次のコマンドを入力します。

$ dpconf set-container-prop -h host -p port\
 property-:value

たとえば、前述の例で、書き込み可能属性のリストに sn を追加するには、次のコマンドを入力します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\
writable-attr+:sn

書き込み可能属性のリストから cn を削除するには、次のコマンドを入力します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\
writable-attr-:cn

`dpadm` と `dpconf` に関するヘルプ情報の表示

dpadm コマンドと dpconf コマンドの使用方法については、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。

サブコマンドの一覧を表示するには、次の該当するコマンドを入力します。
$ dpadm --help
$ dpconf --help
サブコマンドの使用方法についての説明を表示するには、次の該当するコマンドを入力します。
$ dpadm subcommand --help
$ dpconf subcommand --help
dpconf コマンドで使用する設定プロパティーについての情報を得るには、次のように入力します。
$ dpconf help-properties
サブコマンドの設定プロパティーについての情報を得るには、次のコマンドを使用します。
$ dpconf help-properties subcommand-entity
たとえば、アクセスログプロパティーについての情報を調べるには、次のように入力します。
$ dpconf help-properties access-log
サブコマンドで使用するプロパティーについての情報を得るには、次のコマンドを使用します。
$ dpconf help-properties subcommand-entity property
たとえば、set-access-log-prop サブコマンドの log-search-filters プロパティーについての情報を調べるには、次のように入力します。
$ dpconf help-properties access-log log-search-filters

データビューや接続ハンドラなどのエンティティーのグループのキープロパティーを一覧表示するには、list サブコマンドで冗長オプション -v を指定してください。

たとえば、接続ハンドラすべてのキープロパティーや相対プロパティーを表示するには、次のコマンドを使用します。

$ dpconf list-connection-handlers -h host -p port -v
Name                        is-enabled  priority  description
--------------------------  ----------  --------  ---------------------------
anonymous                   false       99        unauthenticated connections
default connection handler  true        100       default connection handler
dscc administrators		true		  1         Administrators connection 
                                                   handler

個々のプロパティーの詳細は、該当のプロパティーのマニュアルページを参照してください。

第 18 章 Directory Proxy Server のインスタンス

この章では、Directory Proxy Server のインスタンスを管理する方法について説明します。この章の内容は次のとおりです。

Directory Proxy Server インスタンスの操作

Directory Proxy Server のインスタンスを作成すると、インスタンスに必要なファイルとディレクトリが指定するパス内に作成されます。

Directory Proxy Server インスタンスを作成する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

DSCC を使用して新しいサーバーインスタンスを作成する場合は、既存のサーバーからサーバー設定の一部またはすべてをコピーするよう選択できます。

Directory Proxy Server のインスタンスを作成します。
$ dpadm create -p port instance-path
たとえば、ディレクトリ /local/dps 内に新しいインスタンスを作成するには、次のコマンドを使用します。
$ dpadm create -p 2389 /local/dps
インスタンスのほかのパラメータの指定については、dpadm(1M) のマニュアルページを参照してください。

必要に応じてパスワードを入力します。

インスタンスの状況を確認して、インスタンスが作成されていることを確認します。
$ dpadm info instance-path

(省略可能) Directory Proxy Server が Sun Java^TM Enterprise System インストーラまたはネイティブパッケージインストールを使用してインストールされていて、OS がサービス管理ソリューションを提供する場合は、次の表に示すサービスとしてサーバーを管理できます。

オペレーティングシステム	コマンド
Solaris 10	`dpadm enable-service --type SMF instance-path`
Solaris 9	`dpadm autostart instance-path`
Linux、HP-UX	`dpadm autostart instance-path`
Windows	`dpadm enable-service --type WIN_SERVICE instance-path`

(省略可能) 次のいずれかの方法で、サーバーインスタンスを登録します。
- https://localhost:6789 という URL で DSCC にアクセスし、ブラウザインタフェースにログインします。
- dsccreg add-server コマンドを使用します。
  
  詳細は、dsccreg(1M) のマニュアルページを参照してください。

Directory Proxy Server インスタンスの状況を確認する

Directory Proxy Server のインスタンスの状況を確認します。
$ dpadm info instance-path

Directory Proxy Server を起動および停止する

Directory Proxy Server を起動または停止するには、次のいずれかを実行します。
- Directory Proxy Server を起動するには、次のように入力します。
  $ dpadm start instance-path
  たとえば、インスタンスを /local/dps で起動するには、次のコマンドを入力します。
  $ dpadm start /local/dps
- Directory Proxy Server を停止するには、次のように入力します。
  $ dpadm stop instance-path
  次に例を示します。
  $ dpadm stop /local/dps

Directory Proxy Server インスタンスを再起動する必要があるかどうかを確認する

設定変更は、変更を有効にする前にサーバーの再起動が必要になる場合があります。設定変更後に Directory Proxy Server インスタンスを再起動する必要があるかどうかを確認するには、この手順に従います。

サーバーを再起動する必要があるかどうかを確認します。
$ dpconf get-server-prop -h host -p port is-restart-required
- このコマンドが true を返す場合、Directory Proxy Server のインスタンスを再起動する必要があります。
- このコマンドが false を返す場合、Directory Proxy Server のインスタンスを再起動する必要はありません。

Directory Proxy Server を再起動する

Directory Proxy Server を再起動します。
$ dpadm restart instance-path
たとえば、インスタンスを /local/dps で再起動するには、次のコマンドを入力します。
$ dpadm restart /local/dps

Directory Proxy Server インスタンスを削除する

(省略可能) Directory Proxy Server インスタンスを停止します。
$ dpadm stop instance-path
インスタンスを停止していない場合は、削除コマンドによって自動的に停止します。ただし、サービス管理ソリューションでインスタンスが有効になっている場合は、手動で停止する必要があります。

(省略可能) 以前に DSCC を使用してサーバーを管理していた場合は、コマンド行を使用してサーバーを登録解除します。

$ dsccreg remove-server /local/dps
Enter DSCC administrator's password:
/local/dps is an instance of DPS
Enter password of "cn=Proxy Manager" for /local/dps:
Unregistering /local/dps from DSCC on localhost.
Connecting to /local/dps
Disabling DSCC access to /local/dps

詳細については、dsccreg(1M) のマニュアルページを参照してください。

(省略可能) 以前にサーバー管理ソリューションでサーバーインスタンスを有効にした場合は、サービスとしてのサーバーの管理を無効にします。

オペレーティングシステム	コマンド
Solaris 10	`dpadm disable-service --type SMF instance-path`
Solaris 9	`dpadm autostart --off instance-path`
Linux、HP-UX	`dpadm autostart --off instance-path`
Windows	`dpadm disable-service --type WIN_SERVICE instance-path`

インスタンスを削除します。
$ dpadm delete instance-path

Directory Proxy Server インスタンスの設定

この節では、Directory Proxy Server のインスタンスを設定する方法について説明します。この節で示す手順では、dpadm コマンドと dpconf コマンドを使用します。これらのコマンドについては、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。

Directory Proxy Server インスタンスの設定を表示する

dpconf info を入力します。

$ dpconf info
インスタンスのパス           :  instance path
ホスト名               :  host
セキュリティー保護された待機アドレス   :  IP address
ポート                    :  port
セキュリティー保護されたポート             :  secure port
SSL サーバー証明書  :  defaultServerCert

Directory Proxy Server を再起動する必要があります。

dpconf info では、「セキュリティー保護された待機アドレス」と「待機アドレス」は、これらのプロパティーがデフォルト以外の値に設定されている場合にのみ表示されます。この出力例では、「待機アドレス」のプロパティーがデフォルト値に設定されているため、この項目は表示されていません。

また、dpconf info では、必要な場合はインスタンスを再起動するようにユーザーに促します。

dpadm info でも Directory Proxy Server インスタンスの設定情報を表示できます。

Directory Proxy Server の設定を変更する

この節では、Directory Proxy Server の設定を変更する方法について説明します。

Directory Proxy Server の現在の設定を調べます。

$ dpconf get-server-prop -h host -p port

allow-cert-based-auth                : allow
allow-ldapv2-clients                             : true
allow-persistent-searches                        : false
allow-sasl-external-authentication               : true
allow-unauthenticated-operations                 : true
allowed-ldap-controls                            : -
cert-data-view-routing-custom-list               : none
cert-data-view-routing-policy                    : all-routable
cert-search-attr-mappings                        : none
cert-search-base-dn                              : none
cert-search-bind-dn                              : none
cert-search-bind-pwd                             : none
cert-search-user-attr                            : userCertificate
configuration-manager-bind-dn                    : cn=proxy manager
configuration-manager-bind-pwd                   : {3DES}RPdIFbvoWdvhLR8lU43zCMZyKFGPxfFg
connection-pool-wait-timeout                     : 3s
data-source-read-timeout                         : 20s
data-view-automatic-routing-mode                 : automatic
email-alerts-enabled                             : false
email-alerts-message-from-address                : local
email-alerts-message-subject                     : Proxy Server Administrative Alert
email-alerts-message-subject-includes-alert-code : false
email-alerts-message-to-address                  : root@localhost
email-alerts-smtp-host                           : localhost
email-alerts-smtp-port                           : smtp
enable-remote-user-mapping                       : false
enable-user-mapping                              : false
enabled-admin-alerts                             : none
enabled-ssl-cipher-suites                        : JRE
enabled-ssl-protocols                            : SSLv3
enabled-ssl-protocols                            : TLSv1
encrypt-configuration                            : true
extension-jar-file-url                           : none
is-restart-required                              : false
number-of-search-threads                         : 20
number-of-worker-threads                         : 50
proxied-auth-check-timeout                       : 30m
remote-user-mapping-bind-dn-attr                 : none
scriptable-alerts-command                        : echo
scriptable-alerts-enabled                        : false
search-mode                                      : parallel
search-wait-timeout                              : 10s
ssl-client-cert-alias                            : none
ssl-server-cert-alias                            : defaultServerCert
supported-ssl-cipher-suites                      : SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DHE_DSS_WITH_DES_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DHE_RSA_WITH_DES_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
supported-ssl-cipher-suites                      : SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DH_anon_WITH_DES_CBC_SHA
supported-ssl-cipher-suites                      : SSL_DH_anon_WITH_RC4_128_MD5
supported-ssl-cipher-suites                      : SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
supported-ssl-cipher-suites                      : SSL_RSA_EXPORT_WITH_RC4_40_MD5
supported-ssl-cipher-suites                      : SSL_RSA_WITH_3DES_EDE_CBC_SHA
supported-ssl-cipher-suites                      : SSL_RSA_WITH_DES_CBC_SHA
supported-ssl-cipher-suites                      : SSL_RSA_WITH_NULL_MD5
supported-ssl-cipher-suites                      : SSL_RSA_WITH_NULL_SHA
supported-ssl-cipher-suites                      : SSL_RSA_WITH_RC4_128_MD5
supported-ssl-cipher-suites                      : SSL_RSA_WITH_RC4_128_SHA
supported-ssl-cipher-suites                      : TLS_DHE_DSS_WITH_AES_128_CBC_SHA
supported-ssl-cipher-suites                      : TLS_DHE_RSA_WITH_AES_128_CBC_SHA
supported-ssl-cipher-suites                      : TLS_DH_anon_WITH_AES_128_CBC_SHA
supported-ssl-cipher-suites                      : TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
supported-ssl-cipher-suites                      : TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
supported-ssl-cipher-suites                      : TLS_KRB5_EXPORT_WITH_RC4_40_MD5
supported-ssl-cipher-suites                      : TLS_KRB5_EXPORT_WITH_RC4_40_SHA
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_3DES_EDE_CBC_MD5
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_3DES_EDE_CBC_SHA
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_DES_CBC_MD5
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_DES_CBC_SHA
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_RC4_128_MD5
supported-ssl-cipher-suites                      : TLS_KRB5_WITH_RC4_128_SHA
supported-ssl-cipher-suites                      : TLS_RSA_WITH_AES_128_CBC_SHA
supported-ssl-protocols                          : SSLv2Hello
supported-ssl-protocols                          : SSLv3
supported-ssl-protocols                          : TLSv1
syslog-alerts-enabled                            : false
syslog-alerts-facility                           : USER
syslog-alerts-host                               : localhost
use-cert-subject-as-bind-dn                      : true
use-external-schema                              : false
user-mapping-anonymous-bind-dn                   : none
user-mapping-anonymous-bind-pwd                  : none
user-mapping-default-bind-dn                     : none
user-mapping-default-bind-pwd                    : none
verify-certs                                     : false

あるいは、1 つまたは複数のプロパティーの現在の設定を確認します。

$ dpconf get-server-prop -h host -p port property-name ...

たとえば、このコマンドを実行することで、未認証の操作が許可されているかどうかを調べます。

$ dpconf get-server-prop -h host -p port allow-unauthenticated-operations
allow-unauthenticated-operations  :  true

1 つまたは複数の設定パラメータを変更します。

$ dpconf set-server-prop -h host -p port property:value ...

たとえば、このコマンドを実行することで、未認証の操作を許可しないようにします。

$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:false

不正な変更を試みても、変更は行われません。たとえば、allow-unauthenticated-operations パラメータを false ではなく f に設定すると、次のようなエラーが発生します。

$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:f
The value "f" is not a valid value for the property "allow-unauthenticated-operations".
Allowed property values: BOOLEAN
The "set-server-prop" operation failed.

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

Proxy Manager の設定

Proxy Manager とは、特権を持つ管理者のことで、UNIX® システムの root ユーザーにあたります。Proxy Manager のエントリは、Directory Proxy Server のインスタンスの作成時に定義されます。Proxy Manager のデフォルト DN は cn=Proxy Manager です。

Proxy Manager DN およびパスワードは、次の手順で示すように表示および変更できます。

Proxy Manager を設定する

Proxy Manager の設定を調べます。

$ dpconf get-server-prop -h host -p port configuration-manager-bind-dn configuration-manager-bind-pwd
configuration-manager-bind-dn   :  cn=proxy manager
configuration-manager-bind-pwd  :  {3DES}U77v39WX8MDpcWVrueetB0lfJlBc6/5n

Proxy Manager のデフォルト値は cn=proxy manager です。設定マネージャーのパスワードに対するハッシュ値が返されます。

Proxy Manager の DN を変更します。

$ dpconf set-server-prop -h host -p port configuration-manager-bind-dn:bindDN

Proxy Manager に対するパスワードを含むファイルを作成し、そのファイルを指すプロパティーを設定します。
$ dpconf set-server-prop -h host -p port configuration-manager-bind-pwd-file:filename

サーバーの再起動を必要とする設定変更

Directory Proxy Server とそのエントリに対するほとんどの設定変更は、オンラインで行うことができます。一部の変更は、変更を有効にするためにサーバーを再起動する必要があります。次のリストのプロパティーに対する設定変更を行う場合は、サーバーを再起動する必要があります。

aci-data-view
bind-dn
client-cred-mode
custom-distribution-algorithm
db-name
db-pwd
db-url
db-user
distribution-algorithm
ldap-address
ldap-port
ldaps-port
listen-address
listen-port
load-balancing-algorithm
num-bind-init
num-read-init
num-write-init
number-of-search-threads
number-of-threads
number-of-worker-threads
ssl-policy
use-external-schema

プロパティーの rws キーワードとrwd キーワードは、プロパティーを変更した場合にサーバーを再起動する必要があるかどうかを示します。

プロパティーに rws (読み取り、書き込み、静的) キーワードが含まれている場合は、プロパティーを変更したときにサーバーを再起動する必要があります。
プロパティーに rwd (読み取り、書き込み、動的) キーワードが含まれている場合、プロパティーに対する変更は、サーバーを再起動しなくても、動的に実装されます。

プロパティーに対する変更でサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。

$ dpconf help-properties | grep property-name

たとえば、LDAP データのバインド DN の変更でサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。

$ dpconf help-properties | grep bind-dn
connection-handler   	bind-dn-filters        rwd  STRING | any
This property specifies a set of regular expressions. The bind DN 
of a client must match at least one regular expression in order for 
the connection to be accepted by the connection handler. (Default: any)
ldap-data-source      bind-dn               rws  DN | ""
This property specifies the DN to use when binding to the LDAP data 
source. (Default: undefined)

設定変更のあとでサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。

$ dpconf get-server-prop -h host -p port is-restart-required

Directory Proxy Server インスタンスのバックアップと復元

dpadm を使って Directory Proxy Server をバックアップすると、設定ファイルとサーバー証明書がバックアップされます。Directory Proxy Server の仮想 ACI が実装されている場合は、ACI もバックアップされます。

Directory Proxy Server では、サーバーが正常に起動した場合は常に、conf.ldif ファイルが自動的にバックアップされます。

Directory Proxy Server インスタンスをバックアップする

Directory Proxy Server のインスタンスを停止します。
$ dpadm stop instance-path

Directory Proxy Server のインスタンスをバックアップします。
$ dpadm backup instance-path archive-dir
archive-dir ディレクトリは backup コマンドによって作成され、このコマンドを実行する前から存在してはいけません。このディレクトリには、設定ファイルと証明書のそれぞれのバックアップが含まれます。

Directory Proxy Server インスタンスを復元する

復元操作を開始する前に、Directory Proxy Server インスタンスを作成してください。

Directory Proxy Server のインスタンスを停止します。
$ dpadm stop instance-path

Directory Proxy Server のインスタンスを復元します。
$ dpadm restore instance-path archive-dir
- インスタンスパスが存在する場合、復元操作はメッセージを表示せずに実行されます。instance-path ディレクトリ内の設定ファイルと証明書は、archive-dir ディレクトリ内のもので置き換えられます。
- インスタンスパスが存在しない場合、復元操作は失敗します。

第 19 章 LDAP データビュー

LDAP データビューは、LDAP サーバーのデータをクライアント要求に公開し、その要求に応答するデータソースプールを指定します。LDAP データビューを定義することで、次の操作を実行できます。

データベース全体を 1 つのビューで公開する
データベース内の異なるサブツリーに対して異なるビューを提供する
異なるデータベースの統合ビューを提供する

LDAP データビューの作成

LDAP データビューの作成には、次の手順が含まれます。

LDAP データソースの作成と設定

この節では、dpconf コマンドを使用して LDAP データソースを作成および設定する方法について説明します。これらのトピックの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「LDAP Data Sources」を参照してください。

LDAP データソースの作成と設定の方法については、次の手順を参照してください。

LDAP データソースを作成する

データソースを作成します。
$ dpconf create-ldap-data-source -h host -p port source-name host:port
このコマンドで、source-name は新しいデータソースに割り当てる名前です。host と port は、LDAP サーバーが実行されているホストとポートを示します。データソースはデフォルトで SSL を使用しない点に注意してください。

ホストが IP V6 アドレスで指定されている場合、データソースの作成時に IP V6 参照を使用する必要があります。たとえば、Directory Proxy Server がポート 2389 で IP V6 アドレス fe80::209:3dff:fe00:8c93 を持つホストにバインドされる場合、次のコマンドを使用してデータソースを作成します。
$ dpconf create-ldap-data-source -h host1 -p 1389 ipv6-host \ [fe80::209:3dff:fe00:8c93]:2389
コンソールを使用してデータソースを作成する場合は、実際の IP V6 アドレスを角括弧なしで指定する必要があります。

LDAP データソースのプロパティーの変更方法については、「LDAP データソースを設定する」を参照してください。

(省略可能) データソースの一覧を表示します。
$ dpconf list-ldap-data-sources -h host -p port

LDAP データソースを設定する

次の手順では、LDAP データソースのプロパティーを表示する方法、および変更する必要のあるプロパティーを設定する方法を示します。LDAP データソースのどのプロパティーの変更にも使用できるコマンドも示します。また、プロパティーの詳細情報を取得する方法も示します。この情報は、そのプロパティーの設定に役立ちます。

次のコマンド構文を使用して、データソースのプロパティーを表示します。

$ dpconf get-ldap-data-source-prop -h host -p port \
[-M unit] [-Z unit] source-name [property...]

このコマンドで -M と -Z は、データを表示する単位を示します。M オプションは時間の単位を指定します。-M の値は、月、週、日、時間、分、秒、ミリ秒を示すために、M、 w、d、h、m、 s、または ms にできます。-Z オプションはデータサイズの単位を指定します。-Z の値は、T バイト、G バイト、M バイト、K バイト、バイトを示すために、T、 G、M、k、または b にできます。

プロパティーを指定しないと、すべてのプロパティーが表示されます。LDAP データソースのデフォルトプロパティーは次のとおりです。

bind-dn                        :  -
bind-pwd                       :  -
client-cred-mode               :  use-client-identity
connect-timeout                :  10s
description                    :  -
is-enabled                     :  false
is-read-only                   :  true
ldap-address                   :  host
ldap-port                      :  port
ldaps-port                     :  ldaps
monitoring-bind-timeout        :  5s
monitoring-entry-dn            :  ""
monitoring-entry-timeout       :  5s
monitoring-inactivity-timeout  :  2m
monitoring-interval            :  30s
monitoring-mode                :  proactive
monitoring-search-filter       :  (|(objectClass=*)(objectClass=ldapSubEntry))
num-bind-incr                  :  10
num-bind-init                  :  10
num-bind-limit                 :  1024
num-read-incr                  :  10
num-read-init                  :  10
num-read-limit                 :  1024
num-write-incr                 :  10
num-write-init                 :  10
num-write-limit                :  1024
proxied-auth-check-timeout     :  1.8s
proxied-auth-use-v1            :  false
ssl-policy                     :  never
use-tcp-no-delay               :  true

データソースを有効にします。

$ dpconf set-ldap-data-source-prop -h host -p port source-name is-enabled:true

デフォルト設定を変更する場合は、手順 1に一覧表示されているプロパティーをすべて設定します。

$ dpconf set-ldap-data-source-prop -h host -p port source-name property:value

たとえば、データソース上のエントリを変更する場合、書き込み操作を許可するようにデータソースを設定します。

$ dpconf set-ldap-data-source-prop -h host -p port source-name is-read-only:false

サブコマンドで使用するプロパティーについての情報を見つけるには、次のコマンドを実行します。

$ dpconf help-properties ldap-data-source property

たとえば、is-read-only プロパティーについての情報を見つけるには、次のコマンドを実行します。

dpconf help-properties ldap-data-source is-read-only

データソースの主要なプロパティーを一覧表示するには、list-ldap-data-sources サブコマンドとともに冗長オプション - v を使用します。

$ dpconf list-ldap-data-sources -v
Name         is-enabled  ldap-address  ldap-port  ldaps-port  description
-----------  ----------  ------------  ---------  ----------  -----------
datasource0  true        myHost        myPort     ldaps       -
datasource1  true        myHost        myPort     ldaps       -

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。サーバーの再起動が必要な設定の変更の一覧は、「サーバーの再起動を必要とする設定変更」を参照してください。

LDAP データソースプールの作成と設定

この節では、dpconf コマンドを使用して LDAP データソースプールを作成および設定する方法について説明します。これらのトピックの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「LDAP Data Sources」を参照してください。

データソースプールの作成と設定の方法については、次の手順を参照してください。

LDAP データソースプールを作成する

1 つまたは複数のデータソースプールを作成します。
$ dpconf create-ldap-data-source-pool -h host -p port pool-name
最初の pool-name のあとに、追加のデータソースプールを指定できます。データソースプールのプロパティーの変更方法については、「LDAP データソースプールを設定する」を参照してください。

(省略可能) データソースプールの一覧を表示します。
$ dpconf list-ldap-data-source-pools -h host -p port

LDAP データソースプールを設定する

次のコマンド構文を使用して、データソースプールのプロパティーを表示します。

$ dpconf get-ldap-data-source-pool-prop -h host -p port \
[-M unit] [-Z unit] pool-name [property...]

プロパティーを指定しないと、すべてのプロパティーが表示されます。LDAP データソースプールのデフォルトプロパティーは次のとおりです。

client-affinity-policy    :  write-affinity-after-write  
client-affinity-timeout   :  20s  
description               :  -  
enable-client-affinity    :  false  
load-balancing-algorithm  :  proportional

手順 1に一覧表示されているプロパティーを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ property:value
負荷分散とクライアントアフィニティーのためにデータソースプールのプロパティーを設定する方法については、第 21 章「Directory Proxy Server による負荷分散とクライアントアフィニティー」を参照してください。

LDAP データソースのデータソースプールへの接続

データソースプールに接続されたデータソースは、接続済みデータソースと呼ばれます。接続済みデータソースのプロパティーによって、データソースプールの負荷分散設定が決まります。接続済みデータソースのウェイトを設定する場合は、データソースプールのすべての接続済みデータソースのウェイトを考慮します。ウェイトの設定どおりに負荷分散が機能することを確認します。負荷分散のためにウェイトを設定する方法については、「負荷分散のウェイトを設定する」を参照してください。

LDAP データソースをデータソースプールに接続する

1 つまたは複数のデータソースをデータソースプールに接続します。

$ dpconf attach-ldap-data-source -h host -p port pool-name \
 source-name [source-name ...]

(省略可能) 特定のデータソースプールの接続済みデータソースをすべて一覧表示します。
$ dpconf list-attached-ldap-data-sources -h host -p port -E pool-name
このコマンドで、-E はオプションであり、1 行に 1 つずつプロパティー値を表示するように表示を変更します。

(省略可能) 特定のデータソースプールの接続済みデータソースの主要なプロパティーを表示します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name

このコマンドで、-v は冗長出力を指定します。たとえば、データソースプールの例のプロパティーを表示します。

$ dpconf list-attached-ldap-data-sources -h host1 -p 1389 -v My-pool
SRC_NAME     add-weight  bind-weight  compare-weight  
-----------  ----------  -----------  --------------  
datasource0  disabled    disabled     disabled        
datasource1  disabled    disabled     disabled        

delete-weight  modify-dn-weight  modify-weight  search-weight
-------------  ----------------  -------------  -------------
disabled       disabled          disabled       disabled
disabled       disabled          disabled       disabled

(省略可能) 次のコマンド構文を使用して、接続済みデータソースのプロパティーを表示します。

$ dpconf get-attached-ldap-data-source-prop -h host -p port [-M unit] [-Z unit] \
 pool-name source-name [property...]

プロパティーを指定しないと、すべてのプロパティーが表示されます。

接続済みデータソースのプロパティーは、負荷分散で各種の操作のウェイトを定義します。接続済みデータソースのデフォルトウェイトは次のとおりです。

add-weight        :  disabled  
bind-weight       :  disabled  
compare-weight    :  disabled  
delete-weight     :  disabled  
modify-dn-weight  :  disabled  
modify-weight     :  disabled  
search-weight     :  disabled

Directory Proxy Server が意図したとおりに動作するためには、接続済みデータソースのプロパティーを設定する必要があります。次の例では、すべてのプロパティーが 1 に設定されています。これらのプロパティーの値は、要件によって変更できます。負荷分散のために接続済みデータソースのウェイトを設定する方法については、「負荷分散のウェイトを設定する」を参照してください。

$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name add-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name bind-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name compare-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name delete-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name modify-dn-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name modify-weight:1
$ dpconf set-attached-ldap-data-source-prop -h host -p port \
pool-name source-name search-weight:1

LDAP データビューの操作

LDAP データビューの作成と設定の方法については、次の手順を参照してください。

LDAP データビューを作成する

LDAP データビューを作成します。
$ dpconf create-ldap-data-view -h host -p port view-name pool-name suffix-DN
LDAP データビューのプロパティーの変更方法については、「LDAP データビューを設定する」を参照してください。

LDAP データビューの一覧を表示します。
$ dpconf list-ldap-data-views -h host -p port

LDAP データビューを設定する

LDAP データビューのプロパティーを表示します。

$ dpconf get-ldap-data-view-prop -h host -p port view-name

プロパティーを設定せずにデータビューを作成すると、データビューは次のような設定になります。

alternate-search-base-dn                    :  ""
attr-name-mappings                          :  none
base-dn                                     :  suffix-DN
contains-shared-entries                     :  false
custom-distribution-algorithm-class         :  none
description                                 :  -
distribution-algorithm                      :  none
dn-join-rule                                :  none
dn-mapping-attrs                            :  none
dn-mapping-source-base-dn                   :  none
excluded-subtrees                           :  -
filter-join-rule                            :  none
is-enabled                                  :  true
is-read-only                                :  false
is-routable                                 :  true
ldap-data-source-pool                       :  pool-name
lexicographic-attrs                         :  all
lexicographic-lower-bound                   :  none
lexicographic-upper-bound                   :  none
non-viewable-attr                           :  none
non-writable-attr                           :  none
numeric-attrs                               :  all
numeric-default-data-view                   :  false
numeric-lower-bound                         :  none
numeric-upper-bound                         :  none
pattern-matching-base-object-search-filter  :  all
pattern-matching-dn-regular-expression      :  all
pattern-matching-one-level-search-filter    :  all
pattern-matching-subtree-search-filter      :  all
process-bind                                :  -
replication-role                            :  master
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

注 –

プロキシマネージャー以外のすべてのユーザーには、バックエンドサーバーの cn=config および cn=monitor サフィックスが表示されます。プロキシマネージャーは、デフォルトでバックエンドサーバーからのデータを使用できません。プロキシマネージャーが使用できる cn=config および cn=monitor サブツリーは、プロキシ自体のサブツリーです。

Directory Proxy Server インスタンスを作成すると、プロキシマネージャーの接続ハンドラが空のデータビューポリシーで作成されます。プロキシマネージャーがバックエンドデータへのアクセスを必要とする場合、プロキシマネージャーの接続ハンドラのデータビューポリシーにデータビューを追加する必要があります。このようなデータビューでは、cn=config および cn=monitor サブツリーは、デフォルトで除外されます。

手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ property:value [property:value ... ]
たとえば、データソースの dc=example,dc=com サブツリーにアクセスするには、データビューで dn-mapping-source-base-dn と指定します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \ dn-mapping-source-base-dn:dc=example,dc=com
複数値プロパティーに値を追加するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name property+:value
複数値プロパティーから値を削除するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name property-:value

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

Directory Proxy Server による Directory Server の設定エントリへのアクセス

Directory Proxy Server の設定エントリは cn=config 内にあります。Directory Proxy Server を使用して設定エントリにアクセスすると、デフォルトでは、Directory Proxy Server の設定エントリにアクセスします。

ディレクトリサーバーの設定エントリにアクセスするには、Directory Proxy Server ではなく Directory Server に直接接続することをお勧めします。Directory Server の設定方法の詳細は、第 4 章「Directory Server の設定」を参照してください。

注意 –

ディレクトリサーバーの設定エントリにアクセスするよう Directory Proxy Server を設定し直すと、たいていは Directory Proxy Server の管理フレームワークが壊れます。

どうしても Directory Proxy Server からディレクトリサーバーの設定エントリにアクセスする必要がある場合は、Directory Proxy Server の管理フレームワークが壊れないよう、特別の手順をとります。この節では、Directory Proxy Server を使用してディレクトリサーバーの設定エントリにアクセスする方法について説明します。

Directory Proxy Server を使用して Directory Server の設定エントリにアクセスする

1 つまたは複数のデータソースを作成します。これについては、「LDAP データソースの作成と設定」を参照してください。

LDAP データソースプールを作成します。これについては、「LDAP データソースプールの作成と設定」を参照してください。

1 つまたは複数のデータソースを、データソースプールに接続します。これについては、「LDAP データソースのデータソースプールへの接続」を参照してください。
- 1 つの特定のデータソースの設定エントリを公開するには、1 つの LDAP データソースだけを LDAP データソースプールに接続します。
  $ dpconf attach-ldap-data-source -h host -p port pool-name data-source-name
  この手順を実行したあと、クライアントは、Directory Proxy Server に接続されているデータソースの設定エントリにアクセスできるようになります。
- 任意の特定のデータソースの設定エントリを公開するには、複数の LDAP データソースを LDAP データソースプールに接続します。
  $ dpconf attach-ldap-data-source -h host -p port pool-name data-source-name \ data-source-name ...
  この手順を実行したあと、クライアントは、Directory Proxy Server に接続されているデータソースの 1 つの設定エントリにアクセスできるようになります。ただし、クライアントには、設定エントリがどのデータソースに属するかはわかりません。

LDAP データビューを作成して、cn=config を公開します。

$ dpconf create-ldap-data-view -h host -p port view-name pool-name cn=config

属性と DN の名前の変更

ディレクトリ内の各エントリは、DN および一連の属性とその値によって識別されます。しばしば、クライアント側で定義された DN と属性は、サーバー側で定義された DN と属性にマップされません。DN と属性の名前を変更するためにデータビューを定義できます。クライアントが要求を行うと、DN と属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されると、DN と属性はクライアント側と一致するよう元に戻されます。

属性と DN の名前の変更については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Attribute Renaming and DN Renaming」を参照してください。属性と DN の名前の変更方法については、次の手順を参照してください。

属性の名前の変更を設定する

属性のマッピングを設定するデータビューで 1 つまたは複数の attr-name-mappings プロパティーを設定します。

$ dpconf set-ldap-data-view-prop -h host -p port view-name \
  attr-name-mappings:client-side-attribute-name#server-side-attribute-name\
  [attr-name-mappings:client-side-attribute-name#server-side-attribute-name ...]

たとえば、クライアント側の surname をサーバー側では sn と名前変更します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \
 attr-name-mappings:surname#sn

既存のマッピングリストに属性マッピングを追加するには、次のコマンドを使用します。

$ dpconf set-ldap-data-view-prop -h host -p port view-name \
 attr-name-mappings+:client-side-attribute-name#server-side-attribute-name

既存のマッピングリストから属性マッピングを削除するには、次のコマンドを使用します。

$ dpconf set-ldap-data-view-prop -h host -p port view-name \
 attr-name-mappings-:client-side-attribute-name#server-side-attribute-name

DN の名前の変更を設定する

DN の名前を変更するデータビューの base-dn プロパティーと DN マッピングプロパティーを表示します。

$ dpconf get-ldap-data-view-prop -h host -p port view-name base-dn \
 dn-mapping-source-base-dn dn-mapping-attrs

プロパティーの意味は次のとおりです。

base-dn は、クライアント側のサブツリーの DN で、データビューのベース DN と同じです。
dn-mapping-source-base-dn はサーバー側のサブツリーの DN です。
dn-mapping-attrs はエントリの DN を含む属性の一覧を定義します。

たとえば、DN の名前の変更が定義されていない場合、クライアント側の dc=example,dc=com データベースのデータビューは次の値になります。

$ dpconf get-ldap-data-view-prop myDataView base-dn \
 dn-mapping-source-base-dn dn-mapping-attrs
 base-dn                    :  dc=example,dc=com
 dn-mapping-attrs           :  none
 dn-mapping-source-base-dn  :  none

クライアント側の DN をサーバー側の DN にマップします。

$ dpconf set-ldap-data-view-prop -h host -p port view-name \
  dn-mapping-source-base-dn:server-side-dn

たとえば、クライアント側の dc=example,dc=com データベースをサーバー側の dc=example,dc=org にマップします。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \
 dn-mapping-source-base-dn:dc=example,dc=org

手順 2 の影響を受ける DIT の一部で属性に DN が含まれている場合、これらの属性の名前を変更します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ dn-mapping-attrs:attribute-name [dn-mapping-attrs:attribute-name ...]
たとえば、手順 2の名前変更操作に影響を受ける名前空間で group 属性に DN が含まれている場合、次のように属性の名前を変更します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView dn-mapping-attrs:group
既存のマッピングリストに DN マッピングを追加するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port \ view-name dn-mapping-attrs+:attribute-name
既存のマッピングリストから DN マッピングを削除するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port \ view-name dn-mapping-attrs-:attribute-name

DN の名前を変更したデータビューの base-dn プロパティーと DN マッピングプロパティーを表示します。

$ dpconf get-ldap-data-view-prop -h host -p port view-name base-dn \
 dn-mapping-source-base-dn dn-mapping-attrs

たとえば、DN の名前の変更後、クライアント側の dc=example,dc=com データベースのデータビューは次の値になります。

$ dpconf get-ldap-data-view-prop -h host1 -p 1389 myDataView base-dn \
 dn-mapping-source-base-dn dn-mapping-attrs
 base-dn                    :  dc=example,dc=com
 dn-mapping-attrs           :  group
 dn-mapping-source-base-dn  :  dc=example,dc=org

ビュー除外ベースおよび代替検索ベースの設定

下位のデータビューが作成されると、Directory Proxy Server は上位のデータビューから下位のデータビューを自動的に除外します。要求のターゲットが下位のデータビューの場合、要求は上位のデータビューではなく、下位のデータビューに送られます。

下位のデータビューで代替検索ベースが指定されている場合、上位のデータビューをターゲットとした検索操作も下位のデータビューで実行されます。

デフォルトで、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを自動的に設定します。次の手順では、これらのプロパティーの手動での設定方法を説明します。

`excluded-subtrees` プロパティーと `alternate-search-base-dn` プロパティーを手動で設定する

手動で要求を経路指定するよう Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port data-view-automatic-routing-mode:manual
data-view-automatic-routing-mode が manual の場合、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを生成しません。これらのプロパティーの値は手動で設定する必要があります。ここで設定した値は、Directory Proxy Server で確認されません。これらの値を間違って設定すると、管理パスが壊れる可能性があることに注意してください。

または、要求を部分的に手動で経路指定するように Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port data-view-automatic-routing-mode:limited
data-view-automatic-routing-mode が limited の場合、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを生成しません。ただし、ここで設定した値が管理パスと競合しないか、Directory Proxy Server が確認します。

ビュー除外ベースを設定します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name excluded-subtrees:suffix-DN
ビュー除外ベースによって、データビューでエントリが公開されない DIT のエントリが決まります。

代替検索ベースを設定します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ alternate-search-base-dn:search-base-DN
代替検索ベースによって、このデータに属しているエントリが配置される DIT のほかのエントリが決まります。ベース DN は、すべてのデータビューで代替検索ベースとしてデフォルトで定義されます。

データビューの作成と設定に関するユースケースの例

この節では、データビューの次の情報とその作成および設定方法について説明します。

ここでの例は、接続ハンドラが Directory Proxy Server によって処理されるすべてのクライアント接続を許可していることを前提としています。

デフォルトデータビュー

プロパティーを設定せずにデータビューを作成すると、データビューは次のような設定になります。

alternate-search-base-dn                    :  ""
alternate-search-base-dn                    :  base-DN
attr-name-mappings                          :  none
base-dn                                     :  suffix-DN
contains-shared-entries                     :  -
description                                 :  -
distribution-algorithm                      :  -
dn-join-rule                                :  -
dn-mapping-attrs                            :  none
dn-mapping-source-base-dn                   :  none
excluded-subtrees                           :  -
filter-join-rule                            :  -
is-enabled                                  :  true
is-read-only                                :  false
is-routable                                 :  true
ldap-data-source-pool                       :  pool-name
lexicographic-attrs                         :  all
lexicographic-lower-bound                   :  none
lexicographic-upper-bound                   :  none
non-viewable-attr                           :  -
non-writable-attr                           :  -
numeric-attrs                               :  all
numeric-default-data-view                   :  false
numeric-lower-bound                         :  none
numeric-upper-bound                         :  none
pattern-matching-base-object-search-filter  :  all
pattern-matching-dn-regular-expression      :  all
pattern-matching-one-level-search-filter    :  all
pattern-matching-subtree-search-filter      :  all
process-bind                                :  -
replication-role                            :  master
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

要求のターゲット DN にかかわりなく、要求をすべて経路指定するデータビュー

この節では、要求のターゲット DN にかかわりなく、要求をすべてデータソースプールに経路指定するデータビューの設定について説明します。このデータビューは、root データビューと呼ばれます。root データビューは、Directory Proxy Server のインスタンスが作成されると、デフォルトで作成されます。root データビューについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route All Requests, Irrespective of the Target DN of the Request」を参照してください。

root データビューには次の設定があります。

alternate-search-base-dn                    :  -
attr-name-mappings                         :  none
base-dn                                    :  ""
contains-shared-entries                    :  -
description                                :  Automatically-generated data view 
                                              able to route client operations 
                                              independently of the operation base dn
distribution-algorithm                     :  -
dn-join-rule                               :  -
dn-mapping-attrs                           :  none
dn-mapping-source-base-dn                  :  none
excluded-subtrees                          :  ""
excluded-subtrees                          :  cn=config
excluded-subtrees                          :  cn=monitor
excluded-subtrees                          :  cn=proxy manager
excluded-subtrees                          :  cn=virtual access controls
excluded-subtrees                          :  dc=example,dc=com
filter-join-rule                           :  -
is-enabled                                 :  true
is-read-only                               :  false
is-routable                                :  true
ldap-data-source-pool                      :  defaultDataSourcePool
lexicographic-attrs                        :  all
lexicographic-lower-bound                  :  none
lexicographic-upper-bound                  :  none
non-viewable-attr                          :  -
non-writable-attr                          :  -
numeric-attrs                              :  all
numeric-default-data-view                  :  false
numeric-lower-bound                        :  none
numeric-upper-bound                        :  none
pattern-matching-base-object-search-filter :  all
pattern-matching-dn-regular-expression     :  all
pattern-matching-one-level-search-filter   :  all
pattern-matching-subtree-search-filter     :  all
process-bind                               :  -
replication-role                           :  master
viewable-attr                              :  all except non-viewable-attr
writable-attr                              :  all except non-writable-attr

サブツリーの一覧がデータとして等価な複数のデータソースに保存されている場合に要求を経路指定するデータビュー

この節では、サブツリーの一覧をターゲットとする要求をデータ同等のデータソースセットに経路指定するデータビューの設定方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When a List of Subtrees Are Stored on Multiple, Data-Equivalent Data Sources」を参照してください。

ここでの例には、同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと同等で、負荷分散のために 1 つのデータソースプールにプールされます。データビューは、サブツリーをクライアント要求に公開するために、各サブツリーに対して設定されます。次の図は、配備の例を示しています。

図 19–1 サブツリーの一覧が複数のデータ同等のデータソースに保存されると要求を経路指定する配備の例

図は、サブツリーの一覧をターゲットとする要求をデータ同等のデータソースのセットに経路指定する配備の例を示しています。

サブツリーの一覧がデータとして等価な複数のデータソースに保存されている場合に要求を経路指定するデータビューを設定する

「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。

「LDAP データソースプールの作成と設定」で説明しているように、データソースプールを作成します。

「LDAP データソースのデータソースプールへの接続」で説明しているように、データソースをデータソースプールに接続します。

(省略可能) 負荷分散を設定します。

詳細は、「負荷分散の設定」を参照してください。

dc=example1,dc=com でデータソースプールを参照するベース DN を持つデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example1,dc=com

dc=example2,dc=com でデータソースプールを参照するベース DN を持つデータビューをもう 1 つ作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-1 dc=example2,dc=com
データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビュー

この節では、異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Provide a Single Point of Access When Different Subtrees Are Stored on Different Data Sources」を参照してください。

この節の例では、各サブツリーのデータビューが含まれます。データソースプールは、データ同等のデータソースのセットごとに設定されます。次の図は、配備の例を示しています。

図 19–2 異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供する配備の例

図は、複数のデータソースに保存されたさまざまなサブツリーに単一のアクセスポイントを提供する配備の例を示しています。

異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビューを設定する

「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。

「LDAP データソースプールの作成と設定」で説明しているように、2 つのデータソースプールを作成します。

「LDAP データソースのデータソースプールへの接続」で説明しているように、dc=example1,dc=com を含むデータソースを data-source-pool-1 に、dc=example2,dc=com を含むデータソースを data-source-pool-2 に接続します。

(省略可能) 負荷分散を設定します。

詳細は、「負荷分散の設定」を参照してください。

dc=example1,dc=com で data-source-pool-1 を参照するベース DN を持つデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example1,dc=com

dc=example2,dc=com で data-source-pool-2 を参照するベース DN を持つデータビューをもう 1 つ作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-1 dc=example2,dc=com
データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に単一のアクセスポイントを提供するデータビュー

この節では、上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に、単一のアクセスポイントを提供するデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When Superior and Subordinate Subtrees Are Stored in Different Data Sources」を参照してください。

ここでの例には、3 つのデータビューが含まれます。データビュー 1 のベース DN は、データビュー 2 のベース DN とデータビュー 3 のベース DN より上位です。つまり、データソースプール 2 とデータソースプール 3 にはデータソースプール 1 のサブツリーの下位であるサブツリーが含まれます。次の図は、配備の例を示しています。

図 19–3 上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に要求を経路指定する配備の例

図は、上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に要求を経路指定する配備の例を示しています。

下位エントリが別のデータビューのベース DN として設定されると、Directory Proxy Server は、サブツリーの下位エントリをデータビューから自動的に除外します。

上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に単一のアクセスポイントを提供するデータビューを設定する

「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。

「LDAP データソースプールの作成と設定」で説明しているように、3 つのデータソースプールを作成します。

「LDAP データソースのデータソースプールへの接続」の指示に従って、データソースをデータソースプールに接続します。
- dc=example,dc=com を含むデータソースを data-source-pool-1 に接続します。
- ou=computer,dc=example,dc=com を含むデータソースを data-source-pool-2 に接続します。
- ou=people,dc=example,dc=com を含むデータソースを data-source-pool-3 に接続します。

(省略可能) 負荷分散を設定します。

詳細は、「負荷分散の設定」を参照してください。

ベース DN を dc=example,dc=com、データソースプールを data-source-pool-1 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example,dc=com

ベース DN を ou=computer,dc=example,dc=com、データソースプールを data-source-pool-2 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-2 ou=computer,dc=example,dc=com

ベース DN を ou=people,dc=example,dc=com、データソースプールを data-source-pool-3 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-3 \ data-source-pool-3 ou=people,dc=example,dc=com

excluded-subtrees パラメータをチェックして、サブツリー ou=computer,dc=example, dc=com と ou=people,dc=example, dc=com が dataview-1 から除外されていることを確認します。
$ dpconf get-ldap-data-view-prop -h host1 -p 1389 dataview-1 excluded-subtrees
除外されたサブツリーの一覧が返されます。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

第 20 章 Directory Proxy Server の証明書

この章では、Directory Proxy Server で証明書を設定する方法について説明します。Directory Server での証明書の設定については、「証明書の管理」を参照してください。

この章で説明する手順では、dpadm コマンドと dpconf コマンドを使用します。これらのコマンドについては、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。

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

デフォルトの自己署名付き証明書

Directory Proxy Server インスタンスを作成すると、デフォルトの自己署名付き証明書が組み込まれます。自己署名付き証明書は公開鍵と非公開鍵のペアであり、公開鍵は Directory Proxy Server で自己署名が付けられます。

デフォルトの自己署名付き証明書の表示

デフォルトの自己署名付き証明書を表示します。
$ dpadm show-cert instance-path defaultservercert

Directory Proxy Server 用の証明書の作成、要求、インストール

Directory Proxy Server で Secure Sockets Layer (SSL) を実行するには、自己署名付き証明書または公開鍵インフラストラクチャー (PKI) ソリューションのいずれかを使用する必要があります。

PKI ソリューションには外部認証局 (CA) が関与します。PKI ソリューションでは CA 署名付きサーバー証明書が必要であり、これには公開鍵と非公開鍵の両方が含まれます。この証明書は、1 つの Directory Proxy Server インスタンスに固有です。また、公開鍵が含まれる「信頼できる CA 証明書」も必要です。信頼できる CA 証明書は、CA からのサーバー証明書はすべて信頼できることを保証します。この証明書は、CA ルート鍵またはルート証明書と呼ばれることもあります。

デフォルト以外の自己署名付き証明書を作成する方法と、CA 署名付き証明書を要求しインストールする方法については、次の手順を参照してください。

Directory Proxy Server 用のデフォルト以外の自己署名付き証明書を作成する

Directory Proxy Server インスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。デフォルト以外の設定で自己署名付き証明書を作成する場合は、次の手順を使用します。

この手順では、サーバー証明書用の公開鍵と非公開鍵のペアを作成し、公開鍵が Directory Proxy Server によって署名されます。自己署名付き証明書は、3 か月間有効です。

Directory Proxy Server 用のデフォルト以外の自己署名付き証明書を作成するには、次のように入力します。
$ dpadm add-selfsign-cert instance-path cert-alias
ここで、cert-alias は自己署名付き証明書の名前です。

たとえば、次のように入力して、 my-self-signed-cert という証明書を作成することもできます。
$ dpadm add-selfsign-cert /local/dps my-self-signed-cert
すべてのコマンドオプションの説明については、dpadm(1M) のマニュアルページを参照するか、コマンド行で dpadm add-selfsign-cert --help と入力してください。

Directory Proxy Server 用のCA 署名付き証明書を要求する

自己署名付き証明書はテスト目的では便利です。ただし、稼働環境では、信頼できる認証局 (CA) 証明書を使用するほうがより安全です。

CA 署名付きサーバー証明書を要求します。

$ dpadm request-cert instance-path cert-alias

ここで、cert-alias は、要求する証明書の名前です。認証局は、サーバーを識別するためにコマンドのすべてのオプションを必要とすることがあります。すべてのコマンドオプションの説明については、dpadm(1M) マニュアルページを参照してください。

CA 証明書を入手するプロセスは、使用する CA によって異なります。商用 CA のなかには、証明書をダウンロードできる Web サイトを備えているものもあります。また、証明書を電子メールで送信する CA もあります。

たとえば、次のように入力して、 my-CA-signed-cert という証明書を要求することもできます。

$ dpadm request-cert -S cn=my-request,o=test /local/dps my-CA-signed-cert
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBYDCBygIBADAhMQ0wCwYDVQQDEwRnZXJpMRAwDgYDVQQDEwdteWNlcnQ0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQC3v9ubG468wnjBDAMbRrEkmFDTQzT+LO30D/ALLXOiElVsHrtRyWhJ
PG9cURI9uwqs15crxCpJvho1kt3SB9+yMB8Ql+CKnCQDHlNAfnn30MjFHShv/sAuEygFsN+Ekci5
W1jySYE2rzE0qKVxWLSILFo1UFRVRsUnORTX/Nas7QIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEA
fcQMnZNLpPobiX1xy1ROefPOhksVz8didY8Q2fjjaHG5lajMsqOROzubsuQ9Xh4ohT8kIA6xcBNZ
g8FRNIRAHCtDXKOdOm3CpJ8da+YGI/ttSawIeNAKU1DApF9zMb7c2lS4yEfWmreoQdXIC9YeKtF6
zwbn2EmIpjHzETtS5Nk=
-----END NEW CERTIFICATE REQUEST-----

dpadm request-cert コマンドを使用して証明書を要求するとき、証明書要求は PEM (Privacy Enhanced Mail) 形式の PKCS #10 証明書要求です。PEM は、RFC 1421 〜 1424 で指定されている形式です。詳細は、http://www.ietf.org/rfc/rfc1421.txt を参照してください。PEM 形式は、base64 形式で符号化された ASCII 形式の証明書要求を表します。

CA 署名付き証明書を要求すると、一時的な自己署名付き証明書が作成されます。CA 署名付き証明書を CA から受信しインストールすると、新しい証明書が一時的な自己署名付き証明書に取って代わります。

その手順に従って、証明書要求を CA に送信します。

証明書要求を送信したら、証明書に関する CA からの回答を待つ必要があります。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、短い時間で回答が届くこともあります。ただし、CA が社外にある場合は、数週間かかることもあります。

CA から受け取った証明書を保存します。

証明書をテキストファイルで保存し、安全な場所に証明書をバックアップします。

Directory Proxy Server 用の CA 署名付きサーバー証明書をインストールする

CA 署名付きサーバー証明書を信頼するには、証明書を Directory Proxy Server インスタンスにインストールする必要があります。ここで示す手順では、CA 証明書の公開鍵を Directory Proxy Server 上の証明書データベースにインストールします。

この CA に対する信頼できる CA 証明書がすでにインストール済みかどうかを確認します。

このためには、「CA 証明書を一覧表示する」で示すように、インストールされているすべての CA 証明書をリストします。

信頼できる CA 証明書がインストールされていない場合は、それをDirectory Proxy Server インスタンス上の証明書データベースに追加します。
$ dpadm add-cert instance-path cert-alias cert-file
ここで、cert-alias は信頼できる CA 証明書の名前で、cert-file は信頼できる CA 証明書が含まれるファイルの名前です。

CA 署名付きサーバー証明書を証明書データベースにインストールします。
$ dpadm add-cert instance-path cert-alias cert-file
ここで、cert-alias は CA 署名付きサーバー証明書の名前で、cert-file は CA 署名付きサーバー証明書が含まれるファイルの名前です。この cert-alias は、証明書要求で使用した cert-alias と同じでなければなりません。

たとえば、次のように入力して、CA-cert という CA 署名付きサーバー証明書を、/local/dps 上の証明書データベースに追加できます。
$ dpadm add-cert /local/dps CA-cert /local/safeplace/ca-cert-file.ascii

Directory Proxy Server 用の期限切れ CA 署名付き証明書の更新

この節では、期限切れ CA 署名付きサーバー証明書を更新する方法について説明します。

Directory Proxy Server 用の期限切れ CA 署名付きサーバー証明書を更新する

CA から更新された証明書を入手します。

証明書を Directory Proxy Server のインスタンスにインストールします。
$ dpadm renew-cert instance-path cert-alias cert-file
ここで、cert-alias は新しい証明書の名前で、cert-file は証明書が含まれるファイルの名前です。すべてのコマンドオプションについては、dpadm(1M) のマニュアルページを参照してください。

証明書のリスト

サーバーと CA 証明書を一覧表示する方法については、次の手順を参照してください。

サーバー証明書を一覧表示する

ここで示す手順では、Directory Proxy Server の 1 つのインスタンスにインストールされているすべての証明書を一覧表示します。

Directory Proxy Server インスタンスにある証明書データベース内のサーバー証明書を一覧表示します。

$ dpadm list-certs instance-path

デフォルトでは、Directory Proxy Server のインスタンスには、defaultservercert というサーバー証明書が含まれます。Same as issuer は、デフォルト証明書が自己署名付きサーバー証明書であることを示します。

次に例を示します。

$ dpadm list-certs /local/dps
Alias             Valid from       Expires on       Self-signed? Issued by          Issued to
----------------- ---------------- ---------------- ------------ ------------------ --------------
defaultservercert 2006/06/01 04:15 2008/05/31 04:15 y            CN=myserver:myport Same as issuer
1 certificate found.

CA 証明書を一覧表示する

ここで示す手順では、Directory Proxy Server の 1 つのインスタンスにインストールされている CA 証明書を一覧表示します。

Directory Proxy Server インスタンスにある証明書データベース内の CA 証明書を一覧表示します。

$ dpadm list-certs -C instance-path

次に例を示します。

$ dpadm list-certs -C /local/dps
Alias   Valid from       Expires on        Built-in  Issued by    Issued to
------  ----------       ----------------  --------- ---------    ---------
CAcert1 1999/06/21 06:00 2020/06/21 06:00  y         CN=company1, O=company2
...

バックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースへの証明書の追加

この節では、証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する方法について説明します。

証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する

次のコマンド構文を使用して、 PEM 形式のバックエンドディレクトリサーバーからの証明書を表示します。

dsadm show-cert -F ascii instance-path [cert-alias]

cert-alias を指定しないと、デフォルトのサーバー証明書が表示されます。すべてのコマンドオプションについては、dsadm(1M) のマニュアルページを参照してください。

たとえば、次のように入力して、デフォルトの自己署名付きサーバー証明書を表示します。

$ dsadm show-cert -F ascii /local/ds defaultCert
-----BEGIN CERTIFICATE-----
MIICJjCCAY+gAwIBAgIFAIKL36kwDQYJKoZIhvcNAQEEBQAwVzEZMBcGA1UEChMQ
U3VuIE1pY3Jvc3lzdGVtczEZMBcGA1UEAxMQRGlyZWN0b3J5IFNlcnZlcjENMAsG
A1UEAxMEMjAxMTEQMA4GA1UEAxMHY29uZHlsZTAeFw0wNjA1MjIxMTQxNTVaFw0w
NjA4MjIxMTQxNTVaMFcxGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGTAXBgNV
BAMTEERpcmVjdG9yeSBTZXJ2ZXIxDTALBgNVBAMTBDIwMTExEDAOBgNVBAMTB2Nv
bmR5bGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK9U3ry3sJmEzwQY8CGd
7S2MTZuBedo03Vea1lfDtD08WIsdDMzhHplTdeHAkWWNc8g2PDcEFXeWp9UXFMuD
Pcia7t8HtFkm73VmlriWhMd8nn3l2vkxhsPK2LHFEeOIUDR9LBBiMiEeLkjdoEhE
VLMSoYKqKI+Aa5grINdmtFzBAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAF4eDbSd7
qy2l10dIogT+rnXZ362gLTlQFCblhbGpmmptbegUdL1ITGv/62q1isPV2rW7CkjM
Cqb0fo3k5UkKKvW+JbMowpQeAPnlgpX612HuDr1tldnKV4eyU7gpG31t/cpACALQ
7OPi1A7oVb2Z8OJKfEJHkp3txBSsiI2gTkk=
-----END CERTIFICATE-----

証明書を保存します。

証明書をテキストファイルで保存し、安全な場所に証明書をバックアップします。

証明書をバックエンド LDAP サーバーから Directory Proxy Server のインスタンス上の証明書データベースに追加します。
$ dpadm add-cert instance-path cert-alias cert-file
ここで、cert-alias は証明書の名前で、cert-file は証明書に含まれるファイルの名前です。

たとえば、証明書 defaultCert は次のようにして追加できます。
$ dpadm add-cert /local/dps defaultCert /local/safeplace/defaultCert.ascii

バックエンド LDAP サーバーへの証明書のエクスポート

バックエンド LDAP サーバーは、Directory Proxy Server からの証明書を必要とすることがあります。この節では、証明書をバックエンド LDAP サーバーにエクスポートするように Directory Proxy Server を設定する方法について説明します。

クライアント証明書をバックエンド LDAP サーバーにエクスポートするように Directory Proxy Server を設定する

バックエンド LDAP サーバーに送信する証明書を指定します。
$ dpconf set-server-prop -h host -p port ssl-client-cert-alias:cert-alias
ここで、cert-alias は証明書の名前です。すべてのコマンドオプションについては、dpconf(1M) のマニュアルページを参照してください。

証明書の内容をファイルにコピーします。

$ dpadm show-cert -F ascii -o filename instance-path cert-alias

「CA 署名付きサーバー証明書と信頼できる CA 証明書を追加する」で示すように、証明書をバックエンド LDAP サーバーの証明書データベースに追加します。

次の手順

バックエンド LDAP サーバーをクライアント認証用に設定します。Directory Server 用にこれを行う方法については、「資格レベルと認証方法の設定」を参照してください。

参照

クライアントと Directory Proxy Server 間の証明書ベースの認証の設定については、「証明書ベースの認証を設定する」を参照してください。

Directory Proxy Server 用の証明書データベースのバックアップと復元

サーバー証明書は、dpadm を使って Directory Proxy Server をバックアップするときにバックアップされます。バックアップされた証明書は、 archive-path/alias ディレクトリに格納されます。

Directory Proxy Server のバックアップと復元の方法については、「Directory Proxy Server インスタンスのバックアップと復元」を参照してください。

証明書データベースにアクセスするためのパスワードの入力要求

デフォルトでは、証明書データベース用のパスワードは内部的に管理されます。したがって、証明書パスワードを入力したりパスワードファイルを指定したりする必要はありません。証明書データベースが格納されているパスワードによって内部的に管理されている場合、パスワードは安全な環境に格納されます。

証明書のセキュリティーを高め、さらに管理するためには、コマンド行でパスワードの入力を要求するように Directory Proxy Server を設定します。それにより、すべての dpadm サブコマンドに対してパスワードの入力を要求されます。ただし、autostart、backup、disable-service、enable-service、info、restore、および stop は除きます。

パスワードの入力を要求する、または要求しないという Directory Proxy Server の設定の詳細は、次の手順を参照してください。

証明書データベースにアクセスするためのパスワードの入力を要求する

サーバーを停止します。

$ dpadm stop instance-path
Directory Proxy Server instance 'instance-path' stopped

パスワードプロンプトフラグを on に設定してから、証明書データベースのパスワードを入力し、確認します。
$ dpadm set-flags instance-path cert-pwd-prompt=on Choose the certificate database password: Confirm the certificate database password:

サーバーを起動してから、証明書データベースのパスワードを入力します。
$ dpadm start instance-path Enter the certificate database password:

証明書データベースにアクセスするためのパスワードの入力要求を無効にする

サーバーを停止します。

$ dpadm stop instance-path
Directory Proxy Server instance 'instance-path' stopped

パスワードプロンプトフラグを off に設定してから、既存のパスワードを入力します。
$ dpadm set-flags instance-path cert-pwd-prompt=off Enter the old password:

次のように入力して、Server を起動します。
$ dpadm start instance-path

第 21 章 Directory Proxy Server による負荷分散とクライアントアフィニティー

負荷分散とクライアントアフィニティーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 16 章「Directory Proxy Server Load Balancing and Client Affinity」を参照してください。この章の内容は次のとおりです。

負荷分散の設定

負荷分散の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Load Balancing」を参照してください。この節では、負荷分散を設定する方法について説明し、設定例を示します。

負荷分散アルゴリズムを選択する

LDAP データソースプールのプロパティーを表示することで、現在の負荷分散アルゴリズムを取得します。

$ dpconf get-ldap-data-source-pool-prop -h host -p port pool-name

LDAP データソースプールのデフォルトプロパティーは次のとおりです。

client-affinity-policy    :  write-affinity-after-write
client-affinity-timeout   :  20s
description               :  -
enable-client-affinity    :  false
load-balancing-algorithm  :  proportional

デフォルトでは、負荷分散アルゴリズムは proportional です。

アルゴリズムを使用するように LDAP データソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:selected-algorithm
ここで、selected-algorithm は次のいずれかです。
- failover
- operational-affinity
- proportional
- saturation
アルゴリズムの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Introduction to Load Balancing」を参照してください。

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

負荷分散のウェイトを設定する

データソースのウェイトは、データソースプールに接続されているほかのすべてのデータソースのウェイトを考慮して設定する必要があります。データソースに操作のタイプに対して disabled のウェイトがある場合、そのタイプの要求がそのデータソースに送信されることはありません。データソースにウェイト 0 (ゼロ) がある場合、そのデータソースには要求は配信されません。

データソースプールに接続されているデータソースのリストを表示します。
$ dpconf list-attached-ldap-data-sources -h host -p port pool-name

接続済みデータソースのいずれかのプロパティーを表示します。

$ dpconf get-attached-ldap-data-source-prop pool-name \
 attached-data-source-name

接続済みデータソースのプロパティーは、各タイプの操作に対するウェイトを定義します。接続済みデータソースのデフォルトウェイトは次のとおりです。

add-weight        :  disabled  
bind-weight       :  disabled  
compare-weight    :  disabled  
delete-weight     :  disabled  
modify-dn-weight  :  disabled  
modify-weight     :  disabled  
search-weight     :  disabled

接続済みデータソースのいずれかのウェイトを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name \
 attached-data-source-name add-weight:value \
 bind-weight:value compare-weight:value delete-weight:value \
 modify-dn-weight:value modify-weight:value search-weight:value

接続されているほかのデータソースに対して、手順 2 と手順 3 を繰り返します。

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name

たとえば、データソースプールには、次のようなウェイトを持つデータソースを含めることができます。

$ dpconf list-attached-ldap-data-sources -h host1 -p 1389 -v myPool
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
DS-1     disabled   3		       disabled       disabled      
DS-2     2          2           2              2             
DS-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
disabled         disabled      disabled
2                2             2
1                1             1

負荷分散の設定例

この節では、各負荷分散アルゴリズムの設定手順の例を示します。

比例アルゴリズムを用いて負荷分散を設定する

比例アルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Proportional Algorithm for Load Balancing」を参照してください。

この例では、データソース ds–1 が、他の 2 つのデータソースのウェイトの 2 倍に設定されます。

始める前に

データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。

負荷分散に対して比例アルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:proportional

最初のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \
 add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \
 modify-weight:2 search-weight:2

2 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

3 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
ds-1     2          2           2              2             
ds-2     1          1           1              1             
ds-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
2                2             2
1                1             1
1                1             1

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

飽和アルゴリズムを用いて負荷分散を設定する

飽和アルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Saturation Algorithm for Load Balancing」を参照してください。

この例では、データソース ds-1 で大半のバインド操作が実行されますが、ほかのタイプの操作は実行されません。3 つのデータソースが次のウェイトによって設定されます。

ds-1 は、バインド操作に対してウェイト 3 を持つよう設定され、他のすべてのタイプの操作に対しては無効です。
ds-2 は、すべての操作に対してウェイト 2 を持つよう設定されます。
ds-3 は、すべての操作に対してウェイト 1 を持つよう設定されます。

始める前に

負荷分散に対して飽和アルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:saturation

最初のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \
 add-weight:disabled bind-weight:3 compare-weight:disabled delete-weight:disabled \
 modify-dn-weight:disabled modify-weight:disabled search-weight:disabled

2 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \
 add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \
 modify-weight:2 search-weight:2

3 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
ds-1     disabled   3		       disabled       disabled      
ds-2     2          2           2              2             
ds-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
disabled         disabled      disabled
2                2             2
1                1             1

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

グローバルアカウントロックアウトに対してアフィニティーアルゴリズムを設定する

このアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Operational Affinity Algorithm for Global Account Lockout」を参照してください。

この例には、3 つのデータソースがあります。データソース ds-1 は、すべてのバインド要求を受信するように設定されます。

始める前に

アフィニティーアルゴリズムを使用するようにデータソースプールを設定します。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 load-balancing-algorithm:operational-affinity

最初のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \
 add-weight:1 bind-weight:100 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

2 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

3 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
ds-1     1          100         1              1             
ds-2     1          1           1              1             
ds-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
1                1             1
1                1             1
1                1             1

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

キャッシュの最適化のためにアフィニティーアルゴリズムを設定する

このアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Operational Affinity Algorithm for Cache Optimization」を参照してください。

この例には、3 つのデータソースがあります。すべての検索操作と比較操作は、データソース ds-1 で処理されます。ds-1 が要求に応答すると、ターゲットエントリがキャッシュ内に格納されます。ds-1 が同じ要求に繰り返し応答する場合、データソースはキャッシュに入れられたデータを使用できます。

始める前に

アフィニティーアルゴリズムを使用するようにデータソースプールを設定します。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 load-balancing-algorithm:operational-affinity

最初のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \
 add-weight:1 bind-weight:1 compare-weight:100 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:100

2 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

3 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
ds-1     1          1           100            1             
ds-2     1          1           1              1             
ds-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
1                1             100
1                1             1
1                1             1

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

フェイルオーバーアルゴリズムを用いて負荷分散を設定する

フェイルオーバーアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Failover Algorithm for Load Balancing」を参照してください。

この例には、3 つのデータソースがあります。データソース ds-1 はすべての要求を受信します。ds-1 が失敗した場合は、ds-1 が回復するまで ds-2 がすべての要求を受信します。ds-1 が回復する前に ds-2 が失敗した場合は、ds-3 がすべての要求を受信します。

始める前に

負荷分散に対してフェイルオーバーアルゴリズムを使用するように、データソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:failover

最初のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \
 add-weight:3 bind-weight:3 compare-weight:3 delete-weight:3 modify-dn-weight:3 \
 modify-weight:3 search-weight:3

2 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \
 add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \
 modify-weight:2 search-weight:2

3 番目のデータソースのプロパティーを設定します。

$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \
 add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \
 modify-weight:1 search-weight:1

接続済みデータソースのキーパラメータを比較します。

$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name
SRC_NAME add-weight bind-weight compare-weight delete-weight 
-------- ---------- ----------- -------------- ------------- 
ds-1     3          3           3              3             
ds-2     2          2           2              2             
ds-3     1          1           1              1             

modify-dn-weight modify-weight search-weight
---------------- ------------- -------------
3                3             3
2                2             2
1                1             1

Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path

Directory Proxy Server で負荷分散を実行するための設定

単純な負荷分散の例として、検索操作と比較操作を 1 つのディレクトリセットに送信し、その他の操作をもう 1 つのディレクトリセットに送信します。Directory Proxy Server は、すべてのクライアント操作を受け取ります。Directory Proxy Server は、読み取りを取得するディレクトリセットとその他の操作を取得するディレクトリセットを判別する必要があります。

Directory Proxy Server でこの負荷分散を処理するための設定の主要な手順は次のとおりです。

Directory Proxy Server 用のデータソースとしてディレクトリを追加します。
それらのデータソースをデータソースプールに追加します。
それらのデータソースのいくつかで検索と比較の操作を受け入れるように設定し、残りのデータソースで追加、バインド、削除、変更、および DN 変更の操作を受け入れるように設定します。
データソースプールをデータビューに追加します。

次の例では、Directory Proxy Server はポート 9389 で待機しています。この例では、記述されているように、検索操作と比較操作を処理する Directory Server インスタンス (ds1:1389) と、その他の操作を処理する Directory Server インスタンス (ds2:2389 ) に負荷を分散するようにプロキシを設定します。

最初の手順では、データソースを作成し、そのデータソースを有効にします。この手順では、プロキシサーバーを再起動する必要があります。

$ dpconf create-ldap-data-source -p 9389 ds1 localhost:1389
$ dpconf create-ldap-data-source -p 9389 ds2 localhost:2389
$ dpconf set-ldap-data-source-prop -p 9389 ds1 is-enabled:true
$ dpconf set-ldap-data-source-prop -p 9389 ds2 is-enabled:true
$ dpadm restart /local/dps

2 番目の手順では、データソースをデータソースプールに追加します。

$ dpconf create-ldap-data-source-pool -p 9389 "Directory Pool"
$ dpconf attach-ldap-data-source -p 9389 "Directory Pool" ds1 ds2

3 番目の手順では、ds1 が検索操作と比較操作を受け入れ、ds2 がその他の操作を受け入れるように設定します。

$ dpconf set-attached-ldap-data-source-prop -p 9389 "Directory Pool" ds1 \
add-weight:disabled bind-weight:disabled compare-weight:1 delete-weight:disabled \
modify-dn-weight:disabled modify-weight:disabled search-weight:1
$ dpconf set-attached-ldap-data-source-prop -p 9389 "Directory Pool" ds2 \
add-weight:1 bind-weight:1 compare-weight:disabled delete-weight:1 \
modify-dn-weight:1 modify-weight:1 search-weight:disabled

4 番目の手順では、クライアントアプリケーション要求がデータソースプールに経路指定されるように、そのプールをデータビューに追加します。

$ dpconf create-ldap-data-view -p 9389 "Balanced View" "Directory Pool" \
dc=example,dc=com

クライアントアフィニティーの設定

クライアントアフィニティーにより、負荷分散された配備での伝播遅延のリスクが削減されます。クライアントアフィニティーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Client Affinity」を参照してください。この節では、クライアント接続とデータソース間のアフィニティーを設定する方法を説明し、設定例を示します。

クライアントアフィニティーを設定する

この手順では、クライアント接続とデータソース間のアフィニティーを設定する方法について説明します。

データソースプールのプロパティーを表示することで、現在の負荷分散アルゴリズムを表示します。

$ dpconf get-ldap-data-source-pool-prop -h host -p port pool-name

データソースプールのデフォルトプロパティーは、次のとおりです。

client-affinity-policy    :  write-affinity-after-write
client-affinity-timeout   :  20s
description               :  -
enable-client-affinity    :  false
load-balancing-algorithm  :  proportional

次のパラメータは、クライアントアフィニティーを設定します。client-affinity-policy 、client-affinity-timeout、enable-client-affinity 。プロパティーの詳細とそれらの有効な値のリストについては、次のように入力します。

dpconf help-properties ldap-data-source-pool client-affinity-policy \
 client-affinity-timeout enable-client-affinity

プロパティーの詳細は、次のマニュアルページを参照してください。client-affinity-policy(5dpconf)、client-affinity-timeout(5dpconf)、および enable-client-affinity(5dpconf)。

クライアントアフィニティーを有効にします。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 enable-client-affinity:true

クライアントアフィニティーに対するポリシーを選択します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-policy:selected-policy
ここで、selected-policy は次のいずれかです。

write-affinity-after-write

最初の書き込み要求のあとの書き込み要求に対するアフィニティー

read-write-affinity-after-write

最初の書き込み要求のあとのすべての要求に対するアフィニティー

read-write-affinity-after-any

最初の読み取り要求または書き込み要求のあとのすべての要求に対するアフィニティー

read-affinity-after-write

書き込み要求のあとの最初の読み取り要求に対するアフィニティー

クライアントアフィニティーの期間を設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-timeout:time-out[unit]
タイムアウトのデフォルトの unit はミリ秒です。

クライアントアフィニティーの設定例

この節では、クライアントアフィニティーに関連する設定の例を示し、レプリケーションの遅延、書き込み操作の検証、接続ベースのルーティングの例を示します。

データソースプールにマスターとコンシューマが含まれている場合に、レプリケーションの遅延に対するクライアントアフィニティーを設定する

この手順では、最初の書き込み操作後、3 秒までの間に行われるすべての読み取り操作と書き込み操作に対するクライアントアフィニティーを設定します。

データソースプールのアフィニティーパラメータを設定します。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 client-affinity-policy:read-write-affinity-after-write client-affinity-timeout:3000 \
 enable-client-affinity:true

書き込み操作のそれぞれを読み取り操作で検証するようにクライアントアフィニティーを設定する

この手順では、それぞれの書き込み操作のあとの最初の読み取り操作に対するクライアントアフィニティーを設定します。例は、読み取り操作を行うことで指定した DN がそれぞれの書き込み操作の妥当性検査を行うアプリケーションの場合もあります。

データソースプールのアフィニティーパラメータを設定します。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 client-affinity-policy:read-affinity-after-write enable-client-affinity:true

接続ベースのルーティングに対するクライアントアフィニティーを設定する

Directory Proxy Server 6.0 より前のバージョンでは、クライアントと LDAP サーバー間で確立される接続数は 1 つです。この接続が閉じられるまで、クライアントからのすべての要求に使用されました。このタイプのルーティングを、connection-based routing といいます。この手順では、接続ベースのルーティングに対してクライアントアフィニティーを設定する方法について説明します。

始める前に

すべてのデータソースがデータソースプールに接続されていて、client-cred-mode が use-client-identity に設定されていることを確認します。

データソースプールのアフィニティーパラメータを設定します。

$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \
 client-affinity-policy:read-write-affinity-after-any enable-client-affinity:true

第 22 章 Directory Proxy Server によるデータ配布

Directory Proxy Server では、データビューの定義によってデータ配布を行うことができます。データビューは、そのデータビュー内のエントリのベース DN を決定するビューベースを使って定義されます。Directory Proxy Server に用意されている配布アルゴリズムに基づいて、エントリをさまざまなデータビュー間で分割する方法を指定できます。

Directory Proxy Server によるデータ配布の概要とユースケースの例の説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 17 章「Directory Proxy Server Distribution」を参照してください。

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

Directory Proxy Server の配布アルゴリズムの設定

Directory Proxy Server には、次の配布アルゴリズムが用意されています。

パターンマッチング
数値
辞書式
レプリケーション
カスタム

パターンマッチング配布アルゴリズムの設定

Directory Proxy Server では、要求のパラメータと 1 つ以上のパターンの間の一致に基づいて、要求をデータビューに配布します。次のパラメータを設定して、パターンマッチング配布アルゴリズムの設定を行います。

pattern-matching-base-object-search-filter pattern-matching-base-object-search-filter(5dpconf)
pattern-matching-dn-regular-expression pattern-matching-dn-regular-expression(5dpconf)
pattern-matching-one-level-search-filter pattern-matching-one-level-search-filter(5dpconf)
pattern-matching-subtree-search-filter pattern-matching-subtree-search-filter(5dpconf)

filter で終わる設定属性は LDAP フィルタであり、正規表現ではありません。これらの LDAP フィルタは、受信検索要求に含まれる LDAP フィルタに対して評価されます。

たとえば、偶数の uid を持つユーザーの要求を even データビューに、奇数の uid を持つユーザーの要求を odd データビューに送信するようにパターンマッチング配布アルゴリズムを設定するときは、次の設定を使用します。

$ dpconf set-ldap-data-view-prop even
pattern-matching-base-object-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\
(uid=*4)(uid=*6)(uid=*8))'\
pattern-matching-one-level-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\
(uid=*4)(uid=*6)(uid=*8))'\
pattern-matching-subtree-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\
(uid=*4)(uid=*6)(uid=*8))'\
pattern-matching-dn-regular-expression:'uid=[0-9]+[02468]'
distribution-algorithm: pattern-matching

$ dpconf set-ldap-data-view-prop odd
pattern-matching-base-object-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\
(uid=*5)(uid=*7)(uid=*9))'\
pattern-matching-one-level-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\
(uid=*5)(uid=*7)(uid=*9))'\
pattern-matching-subtree-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\
(uid=*5)(uid=*7)(uid=*9))'\
pattern-matching-dn-regular-expression:'uid=[0-9]+[13579]'
distribution-algorithm: pattern-matching

(uid=\2a) の式で、\2a は * の ASCII 表現であり、2 および a は 2 つの 16 進数字です。(uid=\2a) の式により、データビューがすべての uid の要求を確実に受け入れるようになります。

パターンマッチングアルゴリズムでサポートされる構文は、Java パターンクラス (http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html で説明されています) によって指定されます。この構文は、通常の regex 構文と同じではありません。

数値配布アルゴリズムの設定

Directory Proxy Server では、要求内の RDN の数値に応じて、要求をデータビューに配布します。この数値は、データビューのベース DN の下にある最初の RDN の値から取られます。次のパラメータを設定して、数値の範囲を定義します。

numeric-attrs numeric-attrs(5dpconf)
numeric-default-data-view numeric-default-data-view(5dpconf)
numeric-lower-bound numeric-lower-bound(5dpconf)
numeric-upper-bound numeric-upper-bound(5dpconf)

たとえば、0 から 99 の間の uid の要求を特定のデータビューに送信する数値配布アルゴリズムを設定できます。残りのユーザーでも同じ構文を使用しますが、データビューは異なります。

$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:numeric \
 numeric-attrs:uid numeric-lower-bound:0 numeric-upper-bound:99

辞書式配布アルゴリズムの設定

Directory Proxy Server では、要求内の RDN の辞書式の値に応じて、要求をデータビューに配布します。辞書式の範囲は、データビューのベース DN の下にある最初の RDN の値から取られます。次のパラメータを設定して、辞書式の範囲を定義します。

lexicographic-attrs lexicographic-attrs(5dpconf)
lexicographic-lower-bound lexicographic-lower-bound(5dpconf)
lexicographic-upper-bound lexicographic-upper-bound(5dpconf)

たとえば、名前が A から M の間で始まるユーザーの要求をあるデータビューに送信し、残りのユーザの要求を別のデータビューに送信する辞書式配布アルゴリズムを設定できます。

$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:lexicographic \
 lexicographic-attrs:cn lexicographic-lower-bound:A lexicographic-upper-bound:M

レプリケーション配布アルゴリズムの設定

Directory Proxy Server では、レプリケーションにおけるデータビューのロールに応じて、要求をデータビューに配布します。このアルゴリズムでは、書き込み操作はデータソースプール内のすべてのデータソースに配布され、読み取り操作は 1 つのデータソースに配布されます。レプリケーションロールは、replication-role パラメータによって定義されます。データビューには、マスターロールまたはコンシューマロールを設定できます。

$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:replication

カスタム配布アルゴリズムの設定

全種類のデータビュー (ldap-data-view、jdbc-data-view、ldif-data-view、および join-data-view) でカスタム配布アルゴリズムを設定できます。次の手順では、このアルゴリズムを ldap-data-view だけで設定します。

カスタム配布アルゴリズムを設定する

配布アルゴリズムクラスが格納された Java Archive (JAR) ファイルのパスが含まれるように extension-jar-file-url プロパティーを設定します。
$ dpconf set-server-prop -h host -p port extension-jar-file-url:jar file path
jar file path を、file:/expt/dps/custom_plugin/myjar.jar のような有効な JAR ファイルパスに置き換えることができます。

custom-distribution-algorithm を設定する前に、distribution-algorithm を none に設定します。
$ dpconf set-ldap-data-view-prop view name distribution-algorithm:none

custom-distribution-algorithm プロパティーをカスタム配布アルゴリズムクラスに設定します。
$ dpconf set-ldap-data-view-prop view name custom-distribution-algorithm:PackageName.AlgoClassName

サフィックスデータを配布するための Directory Proxy Server の設定

単純なデータ配布の例として、A から M までの文字で始まる UID を持つエントリを 1 つのディレクトリセットに格納し、N から Z までの文字で始まる UID を持つエントリをもう 1 つのディレクトリセットに格納します。Directory Proxy Server は、すべてのクライアント操作を受け取ります。Directory Proxy Server は、A から M を処理するディレクトリセットと N から Z を処理するディレクトリセットを判別する必要があります。

Directory Proxy Server でこのデータ配布を処理するための設定の主要な手順は次のとおりです。

Directory Proxy Server 用のデータソースとしてディレクトリを追加します。
それらのデータソースを、各データ配布を処理するデータソースプールに追加します。
クライアント要求を適切なデータプールに配布するためのデータビューを作成します。
適切なデータソースに読み込まれるように LDIF を分割します。
分割した LDIF を適切なデータソースにインポートします。
適切なデータプールに接続されたデータソースごとに、操作ベースのウェイトを調整します。

次の例では、Directory Proxy Server はポート 9389 で待機しています。単純にするため、この例では、記述されているように 3 つの Directory Server インスタンスのみに配布するようにプロキシが設定されています。可用性と読み取りのスケーラビリティーを確保するため、レプリケートされたディレクトリトポロジを使用して LDAP データを格納します。一方の Directory Server インスタンス (dsA-M:1389) は、A から M までの文字で始まる UID を持つユーザーエントリを処理します。もう一方の Directory Server インスタンス (dsN-Z:2389) は、N から Z までの文字で始まる UID を持つユーザーエントリを処理します。最後のディレクトリインスタンス (dsBase:3389) は、サフィックスのベースエントリを処理します。

最初の手順では、データソースを作成して有効にします。ベースデータソースは、UID を持たない、サフィックスのルートに近いエントリを保持します。一般的な配備では、これらのエントリは、配布されるエントリよりもずっと少数です。

$ dpconf create-ldap-data-source -p 9389 dsA-M localhost:1389
$ dpconf set-ldap-data-source-prop -p 9389 dsA-M is-enabled:true

$ dpconf create-ldap-data-source -p 9389 dsN-Z localhost:2389
$ dpconf set-ldap-data-source-prop -p 9389 dsN-Z is-enabled:true

$ dpconf create-ldap-data-source -p 9389 dsBase localhost:3389
$ dpconf set-ldap-data-source-prop -p 9389 dsBase is-enabled:true

2 番目の手順では、データソースをデータソースプールに追加します。

$ dpconf create-ldap-data-source-pool -p 9389 "Base Pool"
$ dpconf attach-ldap-data-source -p 9389 "Base Pool" dsBase

$ dpconf create-ldap-data-source-pool -p 9389 "A-M Pool"
$ dpconf attach-ldap-data-source -p 9389 "A-M Pool" dsA-M

$ dpconf create-ldap-data-source-pool -p 9389 "N-Z Pool"
$ dpconf attach-ldap-data-source -p 9389 "N-Z Pool" dsN-Z

3 番目の手順では、クライアント要求を適切なデータプールに配布するためのデータビューを作成します。ベースプールでは dc=example,dc=com を処理するのに対して、UID 値に従って配布されたデータを保持するプールでは ou=people,dc=example,dc=com を処理します。この手順では、サーバーを再起動する必要があります。

$ dpconf create-ldap-data-view -p 9389 "Base View" "Base Pool" \
dc=example,dc=com

$ dpconf create-ldap-data-view -p 9389 "A-M View" "A-M Pool" \
ou=people,dc=example,dc=com
$ dpconf set-ldap-data-view-prop -p 9389 "A-M View" \
distribution-algorithm:lexicographic lexicographic-attrs:uid \
lexicographic-lower-bound:a lexicographic-upper-bound:m
The proxy server will need to be restarted in order for the changes to take effect

$ dpconf create-ldap-data-view -p 9389 "N-Z View" "N-Z Pool" \
ou=people,dc=example,dc=com
$ dpconf set-ldap-data-view-prop -p 9389 "N-Z View" \
distribution-algorithm:lexicographic lexicographic-attrs:uid \
lexicographic-lower-bound:n lexicographic-upper-bound:z
The proxy server will need to be restarted in order for the changes to take effect
$ dpadm restart /local/dps

4 番目の手順では、適切なデータソースに読み込まれるように LDIF を分割します。この例では、dsadm split-ldif コマンドを使用して最初の分割を実行し、さらに、ファイル編集を使用して、すべてのデータソースで最上位エントリを保持します。これにより、アクセス制御命令を指定する最上位エントリの保持と、各データソースに対する 1 つのインポートコマンドの使用が可能になります。

$ dpadm split-ldif /local/dps /local/ds6/ldif/Example.ldif /tmp/
[14/May/2007:21:14:13 +0200] - STARTUP    - INFO  - Java Version: 1.5.0_09
 (Java Home: /local/jre)
[14/May/2007:21:14:13 +0200] - STARTUP    - INFO  - Java Heap Space: Total Memory
 (-Xms) = 3MB,
 Max Memory (-Xmx) = 63MB
[14/May/2007:21:14:13 +0200] - STARTUP    - INFO  - Operating System: SunOS/sparc 5.10
[14/May/2007:21:14:15 +0200] - INTERNAL   - ERROR - Entry starting at line 0 does not
 start with a DN
[14/May/2007:21:14:15 +0200] - INTERNAL   - ERROR - Unable to parse line "# Kirsten is
 a Directory Administrator and therefore should not" of entry "uid=kvaughan, ou=People,
 dc=example,dc=com" starting at line 112 as an attribute/value pair -- no colon found.
[14/May/2007:21:14:15 +0200] - INTERNAL   - ERROR - Unable to parse line "# Robert is
 a Directory Administrator and therefore should not" of entry "uid=rdaugherty,
 ou=People, dc=example,dc=com" starting at line 298 as an attribute/value pair --
 no colon found.
[14/May/2007:21:14:16 +0200] - INTERNAL   - ERROR - Unable to parse line "# Harry is
 a Directory Administrator and therefore should not" of entry "uid=hmiller, ou=People,
 dc=example,dc=com" starting at line 556 as an attribute/value pair -- no colon found.
[14/May/2007:21:14:16 +0200] - INTERNAL   - INFO  - SplitLDIF processing complete.
  Processed 156 entries.
$ ls /tmp/*ldif
/tmp/a-m view.ldif    /tmp/base view.ldif   /tmp/n-z view.ldif

この手順では、インポートの前に LDIF に追加する最上位エントリも必要です。

$ cp /local/ds6/ldif/Example.ldif /tmp/top.ldif
$ vi /tmp/top.ldif 
$ cat /tmp/top.ldif  
dn: dc=example,dc=com
objectclass: top
objectclass: domain
dc: example
aci: (target ="ldap:///dc=example,dc=com")(targetattr !=
 "userPassword")(version 3.0;acl "Anonymous read-search access";
 allow (read, search, compare)(userdn = "ldap:///anyone");)
aci: (target="ldap:///dc=example,dc=com") (targetattr =
  "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn =
  "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

$ cat /tmp/top.ldif /tmp/base\ view.ldif > /tmp/top\ and\ base\ view.ldif
$ cat /tmp/top.ldif /tmp/a-m\ view.ldif > /tmp/top\ and\ a-m\ view.ldif
$ cat /tmp/top.ldif /tmp/n-z\ view.ldif > /tmp/top\ and\ n-z\ view.ldif

5 番目の手順では、分割した LDIF を適切なデータソースにインポートします。ここでは、ベースエントリを処理するディレクトリはポート 3389 上にあります。A 〜 M を処理するディレクトリはポート 1389 で待機します。N 〜 Z を処理するディレクトリはポート 2389 で待機します。

$ dsconf import -p 1389 /tmp/top\ and\ a-m\ view.ldif dc=example,dc=com
...
Task completed (slapd exit code: 0).

$ dsconf import -p 2389 /tmp/top\ and\ n-z\ view.ldif dc=example,dc=com
...
Task completed (slapd exit code: 0).
$ dsconf import -p 3389 /tmp/top\ and\ base\ view.ldif dc=example,dc=com
...
Task completed (slapd exit code: 0).

6 番目の手順では、適切なデータプールに接続されたデータソースの操作ベースのウェイトを調整します。クライアントアプリケーションが検索以外の操作を実行する場合は、それらの操作のウェイトも設定してください。

$ dpconf set-attached-ldap-data-source-prop -p 9389 "Base Pool" dsBase search-weight:1
$ dpconf set-attached-ldap-data-source-prop -p 9389 "A-M Pool" dsA-M search-weight:1
$ dpconf set-attached-ldap-data-source-prop -p 9389 "N-Z Pool" dsN-Z search-weight:1

操作ベースのウェイトを設定すると、クライアントアプリケーションでは、データが物理的に配布されない場合と同じように Directory Proxy Server を検索できます。

次の検索では、UID が R で始まるユーザーを探します。

$ ldapsearch -p 9389 -b dc=example,dc=com uid=rfisher
version: 1
dn: uid=rfisher, ou=People, dc=example,dc=com
cn: Randy Fisher
sn: Fisher
givenName: Randy
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Human Resources
ou: People
l: Cupertino
uid: rfisher
mail: rfisher@example.com
telephoneNumber: +1 408 555 1506
facsimileTelephoneNumber: +1 408 555 1992
roomNumber: 1579

次の検索では、ベースエントリの 1 つを探します。

$ ldapsearch -p 9389 -b ou=groups,dc=example,dc=com cn=hr\ managers
version: 1
dn: cn=HR Managers,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: HR Managers
ou: groups
uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com
uniqueMember: uid=cschmith, ou=People, dc=example,dc=com
description: People who can manage HR entries

データビューの作成と設定に関するユースケースの例

この節では、データビューの次の情報とその作成および設定方法について説明します。

ここでの例は、接続ハンドラが Directory Proxy Server によって処理されるすべてのクライアント接続を許可していることを前提としています。

サブツリーの異なる部分が異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビュー

この節では、サブツリーのさまざまな部分への単一のアクセスポイントを提供するデータビューを設定する方法を説明します。この例では、同じベース DN の 2 つのデータビューが含まれています。数値配布アルゴリズムは、エントリを様々なデータビューに分割するために使用されます。データソースプールは、データ同等のデータソースのセットごとに設定されます。次の図は、配備の例を示しています。

このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When Different Parts of a Subtree Are Stored in Different Data Sources」を参照してください。

図 22–1 サブツリーの異なる部分が異なるデータソースに保存されている場合に単一のアクセスポイントを提供する配備の例

図は、複数のデータソースに保存されたサブツリーのさまざまな部分に単一のアクセスポイントを提供する配備の例を示しています。

サブツリーの異なる部分が異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビューを設定する

「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。

「LDAP データソースプールの作成と設定」で説明しているように、2 つのデータソースプールを作成します。

「LDAP データソースのデータソースプールへの接続」で説明しているように、サブツリーのある部分を含むデータソースを data-source-pool-1 に、サブツリーのもう 1 つの部分を含むデータソースを data-source-pool-2 に接続します。

(省略可能) 負荷分散を設定します。

詳細は、「負荷分散の設定」を参照してください。

ou=people,dc=example,dc=com で uid が 0 から 99 までのエントリが選択されるように、配布アルゴリズムを使ってデータビューを作成し、要求を data-source-pool-1 に送信するようデータビューを設定します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 dataview-1 \
 ldap-data-source-pool:data-source-pool-1 base-dn:ou=people,dc=example,dc=com \
 distribution-algorithm	:numeric numeric-attrs:uid numeric-lower-bound	:0 \
 numeric-upper-bound	:99

ou=people,dc=example,dc=com で uid が 100 から 199 までのエントリが選択されるように、配布アルゴリズムを使ってもう 1 つのデータビューを作成し、要求を data-source-pool-2 に送信するようデータビューを設定します。

$ dpconf set-ldap-data-view-prop -h host1 -p 1389 dataview-2 \
 ldap-data-source-pool:data-source-pool-2 base-dn:ou=people,dc=example,dc=com \
 distribution-algorithm:numeric numeric-attrs:uid numeric-lower-bound:100
 numeric-upper-bound	:199

データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

階層と配布アルゴリズムを持つデータビュー

この節では、階層と配布アルゴリズムを組み合わせるデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views With Hierarchy and a Distribution Algorithm」を参照してください。

ここでの例には、4 つのデータビューが含まれます。データビュー 1 のベース DN は、その他のデータビューのベース DN より上位です。データビュー 3 とデータビュー 4 のベース DN は同じですが、数値配布アルゴリズムによって、エントリがデータビュー 3 か 4 に割り振られます。

下位エントリが別のデータビューのベース DN として設定されると、Directory Proxy Server は、サブツリーの下位エントリをデータビューから自動的に除外します。数値配布アルゴリズムは同じサブツリーのエントリが異なるデータビューに分割します。データソースプールは、データ同等のデータソースのセットごとに設定されます。

次の図は、配備の例を示しています。

図 22–2 階層と配布アルゴリズムを持つデータビューの例

階層と配布アルゴリズムを持つデータビューを設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。

「LDAP データソースプールの作成と設定」で説明しているように、4 つのデータソースプールを作成します。

「LDAP データソースのデータソースプールへの接続」の指示に従って、データソースをデータソースプールに接続します。
- dc=example,dc=com を含むデータソースを data-source-pool-1 に接続します。
- ou=computer,dc=example,dc=com を含むデータソースを data-source-pool-2 に接続します。
- ou=people,dc=example,dc=com で uid が 0 と 99 の間のエントリを持つデータソースを data-source-pool-3 に接続します。
- ou=people,dc=example,dc=com で uid が 100 と 199 の間のエントリを持つデータソースを data-source-pool-4 に接続します。

(省略可能) 負荷分散を設定します。

詳細は、「負荷分散の設定」を参照してください。

ベース DN が dc=example,dc=com で data-source-pool-1 を参照するデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example,dc=com

ベース DN が ou=computer,dc=example,dc=com で data-source-pool-2 を参照するデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-2 ou=computer,dc=example,dc=com

ベース DN が ou=people,dc=example,dc=com で data-source-pool-3 を参照するデータビューを作成します。uid が 0 から 99 までのエントリを選択するようにデータビューで配布アルゴリズムを設定します。

$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-3 \
 data-source-pool-3 ou=people,dc=example,dc=com
$ dpconf set-ldap-data-view-prop dataview-3 distribution-algorithm:numeric \
 numeric-attrs:uid numeric-lower-bound:0 numeric-upper-bound:99

ベース DN が ou=people,dc=example,dc=com で data-source-pool-4 を参照するデータビューを作成し、uid が 100 から 199 までのエントリを選択するようデータビューで配布アルゴリズムを設定します。

$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-4 \
 data-source-pool-4 ou=people,dc=example,dc=com
$ dpconf set-ldap-data-view-prop dataview-4 distribution-algorithm:numeric \
 numeric-attrs:uid numeric-lower-bound:100 numeric-upper-bound:199

excluded-subtrees パラメータをチェックして、サブツリー ou=computer,dc=example, dc=com と ou=people,dc=example, dc=com が dataview-1 から除外されていることを確認します。
$ dpconf get-ldap-data-view-prop -h host1 -p 1389 dataview-1 excluded-subtrees
除外されたサブツリーの一覧が返されます。

変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

第 23 章 Directory Proxy Server による仮想化

この章では、仮想データビューの作成方法を説明します。仮想データビューは、ソースデータを変換し、そのデータをクライアントアプリケーションに異なるビューで表示します。仮想データビューには、変換された LDAP データビュー、LDIF データビュー、結合データビュー、および JDBC ^TMデータビューが含まれます。仮想データビューの機能の概要とユースケースの例の説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。

Directory Service Control Center (DSCC) を使用してこの章の手順を実行することはできません。コマンド行を使用する必要があります。

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

LDIF データビューの作成と設定

LDIF データビューは、LDIF ファイルを LDAP データソースのように見せかける、単純な仮想データビューです。LDAP データビューとは異なり、LDIF データビューを設定する場合にデータソースやデータソースプールは作成しません。代わりに、データビューを作成する場合に LDIF ファイルを指定します。デフォルトで、LDIF データビューに書き込むことはできません。詳細については、「仮想データビューでのアクセス制御の定義」を参照してください。

LDIF データビューの作成と設定については、次の手順を参照してください。

LDIF データビューを作成する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

LDIF データビューを作成します。

$ dpconf create-ldif-data-view -h host -p port view-name path-to-ldif-file suffix-dn

(省略可能) LDIF データビューの一覧を表示します。
$ dpconf list-ldif-data-views -h host -p port
デフォルトで設定されている LDIF データビューは、virtual access controls データビューのみです。このデータビューは、サーバーによって生成され、要求を仮想アクセス制御命令 (ACI) に経路指定できるようにします。

LDIF データビューを設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

LDIF データビューのプロパティーを表示します。

$ dpconf get-ldif-data-view-prop -h host -p port view-name

LDIF データビューには、次のデフォルトプロパティーがあります。

alternate-search-base-dn                    :  ""
alternate-search-base-dn                    :  dc=com
attr-name-mappings                          :  none
base-dn                                     :  suffixDN
bind-pwd-attr                               :  userPassword
contains-shared-entries                     :  -
db-pwd-encryption                           :  clear-text
description                                 :  -
distribution-algorithm                      :  -
dn-join-rule                                :  -
dn-mapping-attrs                            :  none
dn-mapping-source-base-dn                   :  none
excluded-subtrees                           :  -
filter-join-rule                            :  -
is-enabled                                  :  true
is-read-only                                :  false
is-routable                                 :  true
ldif-data-source                            :  /path/to/filename.ldif
lexicographic-attrs                         :  all
lexicographic-lower-bound                   :  none
lexicographic-upper-bound                   :  none
non-viewable-attr                           :  -
non-writable-attr                           :  -
numeric-attrs                               :  all
numeric-default-data-view                   :  false
numeric-lower-bound                         :  none
numeric-upper-bound                         :  none
pattern-matching-base-object-search-filter  :  all
pattern-matching-dn-regular-expression      :  all
pattern-matching-one-level-search-filter    :  all
pattern-matching-subtree-search-filter      :  all
process-bind                                :  -
replication-role                            :  master
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-ldif-data-view-prop -h host -p port view-name property:value \ [property:value ... ]
たとえば、データビューのソース LDIF ファイルを変更するには、 ldif-data-source プロパティーを設定します。
$ dpconf set-ldif-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myLDIFDataView ldif-data-source:/local/files/example.ldif

仮想データビューでのアクセス制御の定義

仮想データビューの ACI は、LDAP ディレクトリまたは LDIF ファイルに保存できます。仮想 ACI の機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Access Control On Virtual Data Views」を参照してください。

Directory Proxy Server インスタンスを作成すると、仮想アクセス制御の次のデフォルト設定が定義されます。

ACI がデフォルトで保存される LDIF ファイル ( instance-path/config/access_controls.ldif)
virtual access controls という名前の LDIF データビュー

このデータビューは、Directory Proxy Server が LDIF ファイルに保存された ACI にアクセスできるようにします。

新しい ACI ストレージリポジトリを定義する

前述のデフォルト ACI 設定を使用しない場合は、別のストレージリポジトリを定義できます。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

仮想 ACI が保存されるリポジトリのデータビューを作成します。
- ACI が LDAP ディレクトリに保存される場合は、第 19 章「LDAP データビュー」の説明に従って、LDAP データソースと LDAP データビューを作成します。
- ACI が LDIF ファイルに保存される場合は、「LDIF データビューの作成と設定」の説明に従って、LDIF データビューを作成します。

前の手順で作成したデータビューに ACI データビューとして名前を指定します。
```
$ dpconf set-virtual-aci-prop -h host -p port aci-data-view:data-view-name
```

ACI リポジトリが LDAP ディレクトリの場合は、ACI データビューへのアクセスに必要な資格を指定します。

$ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-dn:bind-dn
$ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-pwd-file:filename

仮想アクセス制御を設定する

使用する ACI リポジトリに関係なく、仮想アクセス制御を設定する必要があります。

注 –

ACI のプールを作成し、ACI データビューによって直接 ACI を管理できるのはプロキシマネージャーだけです。ACI リポジトリが LDAP ディレクトリの場合、aciSource オブジェクトクラスと dpsaci 属性が含まれるようにそのディレクトリのスキーマを変更します。スキーマのカスタマイズの詳細については、「Directory Server スキーマの拡張」を参照してください。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

ACI リポジトリに ACI のプールを作成し、グローバル ACI を設定します。

グローバル ACI の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Global ACIs」を参照してください。グローバル ACI を設定するには、ACI データビューのビューベースの下に aciSource エントリを追加します。次に例を示します。

% ldapmodify -p port -D "cn=proxy manager" -w -
dn: cn=aci-source-name,cn=virtual access controls
changetype: add
objectclass: aciSource
dpsaci: (targetattr="*") (target="ldap:///ou=people,o=virtual") (version 3.0; 
 acl "perm1"; allow(all) groupdn="ldap:///cn=virtualGroup1,o=groups,o=virtual";)
cn: data-source-name

この ACI のプールを使用するよう 1 つまたは複数の接続ハンドラを設定します。

% dpconf set-connection-handler-prop -h host -p port connection-handler \
aci-source:aci-source-name

必要な ACI をデータに追加します。

これを行うには、ACI を含む仮想エントリを作成します。次に例を示します。

% ldapmodify -p port -D "cn=virtual application,ou=application users,dc=com" -w -
dn: ou=people,o=virtual
changetype: modify
add: dpsaci
dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(all) userdn="ldap:///self";)
dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(search, read, compare) 
 userdn ="ldap:///anyone";)

注 –

適切なアクセス権限をもつユーザーなら誰でも、データビューを使用して仮想 ACI を追加、取得できます。

仮想データビューでのスキーマチェックの定義

一般に、LDAP データビューの場合、スキーマチェックはバックエンドディレクトリによって、バックエンドディレクトリのスキーマを使用して実行されます。Directory Proxy Server でスキーマチェックを実行する場合は、次の手順に従います。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

要求を正規化するには、特に DN の場合、サーバーの use-external-schema プロパティーを次のように設定します。

スキーマチェックを定義する

サーバーインスタンスが外部スキーマを使用するように設定します。
$ dpconf set-server-prop -h host -p port use-external-schema:true

接続ハンドラでスキーマチェックを有効にします。

$ dpconf set-connection-handler-prop -h host -p port connection-handler \
 schema-check-enabled:true

cn=schema を公開するデータビューを作成します。

外部スキーマが LDAP ディレクトリで定義される場合、第 19 章「LDAP データビュー」での説明に従って、ビューベースを cn=schema にして LDAP データビューを作成します。

外部スキーマが LDIF ファイルで定義される場合、「LDIF データビューの作成と設定」での説明に従って、ビューベースを cn=schema にして LDIF データビューを作成します。

接続ハンドラによって公開されるデータビューの一覧にこのデータビューを追加します。

デフォルトで、データビューはすべて接続ハンドラによって公開されます。接続ハンドラによって公開されたデータビューのカスタムリストを定義している場合、このデータビューをリストに追加します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ data-view-routing-custom-list+:data-view-name

結合データビューの作成と設定

結合データビューは複数のデータビューを 1 つにまとめたものです。結合データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Join Data Views」を参照してください。

結合データビューの作成と設定の方法については、次の手順を参照してください。

結合データビューを作成する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

結合ビューを形成するためにまとめる一次データビューと二次データビューを特定します。

結合ビューを作成する前に、一次データビューと二次データビューを準備しておきます。一次ビューと二次ビューは、LDAP データビュー、LDIF データビュー、JDBC データビュー、またはその他の結合データビューを含むどんな種類のデータビューでも構いません。特定のプロパティーを二次ビュー上で設定し、結合ビューのソースとして機能できるようにします。詳細については、「結合ビューの二次ビューを設定する」を参照してください。

結合データビューを作成します。

$ dpconf create-join-data-view -h host -p port view-name primary-view secondary-view \
 suffix-dn

(省略可能) データビューが正常に作成されたことを確認するために、結合ビューの一覧を表示します。
$ dpconf list-join-data-views -h host -p port

結合データビューを設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

結合データビューのプロパティーを表示します。

$ dpconf get-join-data-view-prop -h host -p port view-name

結合データビューのデフォルトプロパティーは次のとおりです。

alternate-search-base-dn                    :  ""
alternate-search-base-dn                    :  dc=com
attr-name-mappings                          :  none
base-dn                                     :  suffixDN
contains-shared-entries                     :  -
description                                 :  -
distribution-algorithm                      :  -
dn-join-rule                                :  -
dn-mapping-attrs                            :  none
dn-mapping-source-base-dn                   :  none
excluded-subtrees                           :  -
filter-join-rule                            :  -
is-enabled                                  :  true
is-read-only                                :  false
is-routable                                 :  true
join-rule-control-enabled                   :  false
lexicographic-attrs                         :  all
lexicographic-lower-bound                   :  none
lexicographic-upper-bound                   :  none
non-viewable-attr                           :  -
non-writable-attr                           :  -
numeric-attrs                               :  all
numeric-default-data-view                   :  false
numeric-lower-bound                         :  none
numeric-upper-bound                         :  none
pattern-matching-base-object-search-filter  :  all
pattern-matching-dn-regular-expression      :  all
pattern-matching-one-level-search-filter    :  all
pattern-matching-subtree-search-filter      :  all
primary-view                                :  primary-view
process-bind                                :  -
replication-role                            :  master
secondary-view                              :  secondary-view
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-join-data-view-prop -h host -p port view-name property:value \ [property:value ... ]
たとえば、データソースの一次データビューを myLDAPDataView に変更するには、次のコマンドを使用します。
$ dpconf set-join-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myJoinDataView primary-view:myLDAPDataView

結合データビューを設定する場合は、一次データビューと二次データビューで viewable-attr および writable-attr プロパティーを設定します。

これらのプロパティーを設定すると、一次データビューと二次データビューで検索フィルタを適切に分割できます。これらのプロパティーを設定しなければ、二次データビューからの属性が検索フィルタに含まれている場合、検索結果に矛盾が生じる可能性があります。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

複数の結合データビューが 1 つのデータビューを参照できるよう結合データビューを設定する

結合データビューで結合ルール設定情報を設定することにより、そのデータビューが複数の結合データビューから参照されるようにします。これを行うには、次の手順を実行します。

結合データビューで join-rule-control-enabled を true に設定します。
$ dpconf set-join-data-view-prop view-name join-rule-control-enabled:true
join-rule-control-enabled を true に設定すると、その結合データビューに格納された結合ルール設定情報がサーバーで使用されます。ある結合データビューに対して、結合ルール設定情報が二次データビューに格納されている場合、この情報はサーバーで使用されません。この情報をサーバーに使用させるには、結合データビューレベルで設定情報を手動で追加してください。

二次ビューが一次ビューに関連付けられる方法を決定する結合ルールを定義します。

次のどちらかの結合ルールを使用できます。
- DN 結合ルール
  $ dpconf set-join-data-view-prop view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example
- フィルタ結合ルール
  $ dpconf set-join-data-view-prop view-name \ filter-join-rule:uid=\${primary-view-name.uid}
上のコマンドで、属性名を変数として扱う場合には ${} で囲みます。属性名を ${} で囲まないと、その属性名は定数として扱われます。

UNIX で bash または ksh を使用する場合、構築と同様に $ 文字は \${primary-view-name .uid} では \ でエスケープするべきですが、Windows の場合、エスケープは必要ありません。

結合ビューの二次ビューを設定する

特定のプロパティーを二次データビュー上で設定し、結合ビューのソースとして機能できるようにします。二次ビューはどんな種類のデータビューでも構わないため、使用するコマンドは、データビューの種類によって異なります。次のサンプルコマンドは、二次ビューが LDAP データビューであることを前提としています。ここで説明するプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Additional Secondary Data View Properties」を参照してください。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

二次ビューが一次ビューに関連付けられる方法を決定する結合ルールを定義します。

filter-join-rule および dn-join-rule は、結合ビューの一次データビューでは決して設定しないでください。

次のどちらかの結合ルールを使用できます。
- DN 結合ルール
  $ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example
- フィルタ結合ルール
  $ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ filter-join-rule:uid=\${primary-view-name.uid}
dn-join-rule および filter-join-rule プロパティーの設定がサーバーで使用されるのは、結合データビューで join-rule-control-enabled プロパティーが false に設定されている場合だけです。結合データビューで join-rule-control-enabled プロパティーが true に設定されていると、二次ビューで設定された情報は無視されます。

結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \ write add-attr-value dn uid=\${uid}
注 –
このルールを設定しなければ、結合データビューにエントリを追加できません。

(省略可能) 二次ビューでバインドを許可するかどうかを指定します。

デフォルトでは、すべてのデータビューでバインドが可能です。二次データビューのバインドを禁止する場合は、次のコマンドを実行します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name process-bind:false
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Handling of Binds」を参照してください。

(省略可能) 二次データビューに共有エントリが含まれるかどうかを指定します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ contains-shared-entries:true
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Handling of Shared Entries」を参照してください。

JDBC データビューの作成と設定

JDBC データビューを使用すると、LDAP クライアントアプリケーションがリレーショナルデータベースにアクセスできるようになります。JDBC データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「JDBC Data Views」を参照してください。

JDBC データビューの作成と設定の方法については、次の手順を参照してください。

JDBC データビューを作成する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

リレーショナルデータベース用の JDBC データソースを作成します。
$ dpconf create-jdbc-data-source -h host -p port -b db-name -B db-url -J driver-url \ [-J driver-url]... -S driver-class source-name
現在、各 JDBC データビューでサポートされる JDBC データソースは 1 つだけです。つまり、JDBC データソースで負荷分散することはできません。複数の JDBC データソースにアクセスするには、各データソース用にデータビューを作成し、それらをすべて結合データビューに結合します。

JDBC データソースを作成する場合は、次のプロパティーを設定します。

db-name

リレーショナルデータベースの名前。たとえば、payrolldb などです。

db-url

データベースへの URL。形式は、jdbc: vendor:driver://dbhost: dbport です。

db-url には、データベース名が含まれていないため、JDBC データベース URL としては完全ではありません。(データベース名は、db-name プロパティーで指定されます。)

db-url の末尾には、MySQL、DB2、および Derby データベースの場合は /、Oracle データベースの場合は : を付けてください。

driver-class

JDBC ドライバクラス。たとえば、org.hsqldb.jdbcDriver などです。

driver-url

JDBC ドライバへのパス。たとえば、file:/// path/to/hsqldb/lib/hsqldb.jar などです。

driver-url プロパティーは複数値プロパティーです。そのため、driver-url で JDBC ドライバ用の複数の JAR ファイルを設定することにより、各種のプラットフォームで JDBC ソースに接続できます。

JDBC データソースプールを作成します。

$ dpconf create-jdbc-data-source-pool -h host -p port pool-name

JDBC データソースを JDBC データソースプールに接続します。
$ dpconf attach-jdbc-data-source -h host -p port pool-name source-name

JDBC データビューを作成します。

$ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN

(省略可能) データビューが正常に作成されたことを確認するために、JDBC データビューの一覧を表示します。
$ dpconf list-jdbc-data-views -h host -p port

JDBC データビューを設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

JDBC データビューのプロパティーを表示します。

$ dpconf get-jdbc-data-view-prop -h host -p port view-name

JDBC データビューのデフォルトプロパティーは次のとおりです。

alternate-search-base-dn                    :  -
attr-name-mappings                          :  none
base-dn                                     :  o=sql1
contains-shared-entries                     :  -
description                                 :  -
distribution-algorithm                      :  -
dn-join-rule                                :  -
dn-mapping-attrs                            :  none
dn-mapping-source-base-dn                   :  none
excluded-subtrees                           :  -
filter-join-rule                            :  -
is-enabled                                  :  true
is-read-only                                :  false
is-routable                                 :  true
jdbc-data-source-pool                       :  pool-name
lexicographic-attrs                         :  all
lexicographic-lower-bound                   :  none
lexicographic-upper-bound                   :  none
non-viewable-attr                           :  -
non-writable-attr                           :  -
numeric-attrs                               :  all
numeric-default-data-view                   :  false
numeric-lower-bound                         :  none
numeric-upper-bound                         :  none
pattern-matching-base-object-search-filter  :  all
pattern-matching-dn-regular-expression      :  all
pattern-matching-one-level-search-filter    :  all
pattern-matching-subtree-search-filter      :  all
process-bind                                :  -
replication-role                            :  master
viewable-attr                               :  all except non-viewable-attr
writable-attr                               :  all except non-writable-attr

手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。

$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \
 [property:value ... ]

JDBC テーブル、属性、オブジェクトクラスを設定する

JDBC データビューを設定する場合、次のオブジェクトも設定する必要があります。

JDBC オブジェクトクラス。1 つまたは複数の JDBC テーブルを LDAP オブジェクトクラスにマップします。
JDBC テーブル。各リレーショナルデータベーステーブルに対して定義します。
JDBC 属性。JDBC テーブル内の指定された列の LDAP 属性を定義します。

リレーショナルデータベースの各テーブルの JDBC テーブルを作成します。
% dpconf create-jdbc-table jdbc-table-name db-table
db-table の名前は大文字と小文字を区別します。リレーショナルデータベースで使用したのと同じ文字 (大文字または小文字) を使用してください。異なる文字を使用すると、そのテーブルをターゲットとする操作は失敗する場合があります。

各リレーショナルデータベーステーブル内で各列の JDBC 属性を作成します。
% dpconf add-jdbc-attr table-name attr-name sql-column
JDBC 属性を作成すると、テーブル列が LDAP 属性にマップされます。

(省略可能) リレーショナルデータベース内の列が大文字と小文字を区別する場合、JDBC 属性の LDAP 構文を変更します。
% dpconf set-jdbc-attr-prop table-name attr-name ldap-syntax:ces
ldap-syntax の値は、デフォルトで cis です。これは、jdbc-attr が大文字と小文字を区別しないことを意味します。リレーショナルデータベースが大文字と小文字を区別する場合、値を ces に変更します。

Oracle や DB2 など、特定のリレーショナルデータベースはデフォルトで大文字と小文字を区別します。LDAP はデフォルトで大文字と小文字を区別しません。Directory Proxy Server はリレーショナルデータベーステーブルの列が大文字と小文字を区別することを検出すると、フィルタ内の対応する属性の ldapsearch クエリーが UPPER 関数を使用して SQL クエリーに変換されます。

たとえば、クエリー ldapsearch -b "dc=mysuffix" "(attr=abc)" は次の SQL クエリーに変換されます。
SELECT * FROM mytable WHERE (UPPER(attr)='ABC')
デフォルトで、この種類のクエリーはインデックスが生成されません。このため、このようなクエリーは、パフォーマンスに大きな影響を与える可能性があります。

次の 2 つの方法でパフォーマンスへの影響を緩和できます。
- jdbc-attr の ldap-syntax プロパティーを ces に設定する。
- LDAP フィルタで使用されている可能性のある各 jdbc-attr の UPPER 関数でインデックスを作成する。
注 –
リレーショナルデータベースが大文字と小文字を区別しない場合は、ldap-syntax をデフォルト値の cis に設定します。ldap-syntax:ces は、大文字と小文字を区別しないデータベースではサポートされません。

LDAP リレーショナルデータベーステーブルの JDBC オブジェクトクラスを作成します。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern
JDBC オブジェクトクラスを作成すると、原則的にこれらのテーブルが関連付けられる LDAP オブジェクトクラスが指定されます。JDBC オブジェクトクラスは、一次テーブルと二次テーブルが存在する場合、これらも指定します。

JDBC オブジェクトクラスを作成する場合、DN パターンを指定します。DN パターンは、エントリの DN の構築にどの属性を使用するかを示します。たとえば、DN パターンを uid として指定すると、エントリの DN は、データビューの属性 uid とビューベースを使用して構築されます。たとえば、uid=bjensen,ou=people,dc=example,dc=com のようになります。DN パターンは複数の属性で構成されることがあります。その場合は、属性を , (カンマ) で区切るようにしてください。たとえば、DN パターンを uid,country として指定した場合、データビューによって返されるエントリの DN は uid=bjensen,country=America,ou=people,dc=example,dc=com となります。

JDBC オブジェクトクラスの DN パターンに定義されたサブツリーコンポーネントにはすべて、それらのサブツリーコンポーネント用に定義された JDBC オブジェクトクラスを設定するようにしてください。たとえば、JDBC オブジェクトクラスに uid,ou という DN パターンがある場合、JDBC オブジェクトクラス定義に DN パターン ou を設定するようにしてください。これは、Directory Proxy Server で正しい構造の DIT を構築するために必要です。この設定を行わないと、ou=xxx,base-DN のような値を持つサブツリーが検索結果で返されません。

二次テーブルが存在する場合、一次テーブルと二次テーブル間の結合ルールを定義します。
% dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule
結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。オブジェクトクラスの一次テーブルと二次テーブル間の関係の定義方法は重要です。詳細については、「JDBC テーブル間の関係の定義」を参照してください。

JDBC オブジェクトクラスのスーパークラスを指定します。
% dpconf set-jdbc-object-class-prop view-name objectclass super-class:value
スーパークラスは、JDBC オブジェクトクラスが継承した LDAP オブジェクトクラスを示します。

JDBC テーブル間の関係の定義

もっとも単純な場合、JDBC オブジェクトクラスにはテーブルが 1 つ (一次) しか含まれません。二次テーブルはなく、このため、テーブル間の関係を定義する必要はありません。

オブジェクトクラスに複数のテーブルが含まれる場合、これらのテーブル間の関係を明確に定義します。テーブル間の関係は、常に二次テーブル上で定義されます。二次テーブルの次のプロパティーによって、これらの関係を定義できます。

is-single-row-table は、テーブルで LDAP エントリに一致する行が 1 つだけであると指定します。
contains-shared-entries は、二次テーブルの行が一次テーブルの複数の行に使用されることを指定します。
filter-join-rule は、エントリが一次テーブルに基づいて二次テーブルから取得される方法を示します。

次の例は、最初の 2 つのプロパティーの値に基づいて、フィルタ結合ルールがどのように定義されるかを示しています。以降の例では、オブジェクトクラスに一次テーブルと二次テーブルが 1 つずつあることを前提としています。

例 23–1 `is-single-row-table:true` と `contains-shared-entries:true`

それぞれプロパティーのデフォルト値が指定されています。この場合、一次テーブルと二次テーブルの関係は、n->1 です。つまり、一次テーブルの n 行は二次テーブルの共有行の 1 つを参照します。

リレーショナルデータベースで、外部キー (FK) が一次テーブルで定義され、二次テーブルの列をポイントします。

たとえば、複数の従業員が同じマネージャーを共有できる組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : EMPLOYEE [ID, NAME, FK_MANAGER_ID]
secondary table : MANAGER  [ID, NAME]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : name (from primary EMPLOYEE.NAME)
attr : manager (from secondary MANAGER.NAME)

次のフィルタ結合ルールが、二次テーブルで定義されます。

ID=\${EMPLOYEE.FK_MANAGER_ID}"

複数の二次テーブルの場合は、二次テーブルごとに filter-join-rule を設定する必要があります。複数の二次テーブルで filter-join-rule を設定する方法の詳細については、手順 11 を参照してください。

この設定の場合、LDAP 操作で次の動作が行われます。

従業員エントリの追加。従業員エントリのマネージャーがテーブルに存在しない場合、新しい行が作成されます。マネージャーが存在する場合は、既存の行が使用されます。
エントリ内の「manager」属性の値の置き換え。MANAGER.NAME 行の値が変更されます。
従業員エントリの削除。マネージャーエントリが共有されているため、二次テーブルの行は削除されません。
エントリから「manager」属性の削除。二次テーブルの行が削除され、外部キー (EMPLOYEE.FK_MANAGER_ID) が NULL に設定されます。

例 23–2 `is-single-row-table:true` と `contains-shared-entries:false`

この場合、一次テーブルと二次テーブルの関係は、1->1 または 1<-1 です。つまり、一次テーブルの 1 行が二次テーブルの 1 行で参照されます。

リレーショナルデータベースで、外部キー (FK) が一次テーブルまたは二次テーブルで定義されることがあります。

たとえば、従業員の UID が 1 つのテーブルに保存され、従業員の姓が二次テーブルに保存されている組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : UID [ID, VALUE, FK_SN_ID]
secondary table : SN [ID, VALUE]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : uid (from primary UID.VALUE)
attr : sn (from secondary ID.VALUE)

次のフィルタ結合ルールが、二次テーブルで定義されます。

ID=\${UID.FK_SN_ID}

別の方法として、二次テーブルに保存されている外部キー FK_UID_ID を UID.ID にポイントさせることでも同等の設定が可能です。

例 23–3 `is-single-row-table:false` と `contains-shared-entries:false`

この場合、一次テーブルと二次テーブルの関係は、1->n です。つまり、一次テーブルの 1 行が二次テーブルの n 行で参照されます。この例は、複数値属性の場合を示しています。複数値属性は、属性値ごとに 1 行で表され、それぞれ二次テーブル内の行のセットと対応します。

リレーショナルデータベースで、外部キーが二次テーブルで定義され、一次テーブルの列をポイントします。

たとえば、従業員が複数の電話番号を持っている可能性のある組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : EMPLOYEE [ID, NAME]
secondary table : PHONE [ID, VALUE, USER_ID]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : cn (from primary EMPLOYEE.NAME)
attr : telephoneNumber (from secondary PHONE.VALUE)

次のフィルタ結合ルールが、二次テーブルで定義されます。

USER_ID=\${EMPLOYEE.ID}

例 23–4 `is-single-row-table:false` と `contains-shared-entries:true`

これは、現在 Directory Proxy Server でサポートされていません。

仮想設定の例

次の節では、2 つの設定例について説明します。これらの設定は、仮想ディレクトリの主な機能と、これらの機能の設定方法を示しています。

LDAP ディレクトリと MySQL データベースの結合

ここでの手順は、LDAP ディレクトリと MySQL データベースを結合する仮想設定の例について説明しています。LDAP ディレクトリは、一次データソースとして、ユーザー情報のほとんどが含まれています。mySQL データベースには、ユーザーについての追加情報が含まれています。結果として得られる設定を次の図に示します。

図 23–1 仮想設定の例

図は、LDAP データビューおよび JDBC データビューから成る結合データビューを示しています。

install-path /ds6/ldif/Example.ldif のサンプルデータを使用して、この例を複製したり、サンプルデータを独自のデータに置き換えられます。

この設定は、3 つの部分に分割できます。

LDAP データビューの設定とテスト
JDBC データビューの設定とテスト
結合データビューの設定とテスト

わかりやすいように、ここでのコマンドはすべて Directory Proxy Server が /local/dps のローカルホストで実行されていることを前提としています。コマンドは、次の環境変数が設定されていることも前提としています。

DIR_PROXY_PORT: 1389
LDAP_ADMIN_PWF: pwd.txt、管理者パスワードを含むファイル
DIRSERV_PORT: 4389
LDAP_ADMIN_USER: cn=Directory Manager

LDAP データビューの設定とテスト

LDAP データビューを設定する

始める前に

ここでの作業は次の情報を前提としています。

Directory Server インスタンスが host1 上のポート 4389 で実行されている。
Directory Server のデータがサフィックス dc=example,dc=com の下に保存されている。この例と同じ環境を構築するには、Directory Server インスタンスとサフィックス dc=example,dc=com を作成し、install-path/ds6/ldif/Example.ldif のサンプルデータをインポートしてください。

Directory Server インスタンスに対して、myds1 という名前の LDAP データソースを作成します。
% dpconf create-ldap-data-source myds1 host1:4389

データソースを有効にして、データソースへの書き込み操作を許可します。
% dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false

myds1-pool という名前の LDAP データソースプールを作成します。
% dpconf create-ldap-data-source-pool myds1-pool

LDAP データソースを LDAP データソースプールに接続します。
% dpconf attach-ldap-data-source myds1-pool myds1

データソースがそのデータソースプールからのバインド、追加、検索、および変更操作の 100% を受け取るように指定します。
% dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \ bind-weight:100 modify-weight:100 search-weight:100

ベース DN が dc=example,dc=com で myds1–view という名前のデータソースプールの LDAP データビューを作成します。
% dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com

LDAP データビューをテストする

dc=example,dc=com のユーザーとして、LDAP データソース内のエントリをすべて検索して、データビューから読み取りができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery \ -b dc=example,dc=com "objectclass=*"
注 –
dc=example,dc=com のユーザーの資格を使用します。cn=Directory Manager を使用する場合は、この DN を処理するようにデータビューを定義する必要があります。

dc=example,dc=com のユーザーとして、userPassword 属性を変更して、データビューに書き込みができることを確認します。
% ldapmodify -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery dn: uid=kvaughan,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: myNewPassword
注 –
Directory Server 内のデフォルト ACI はユーザーが自分自身のパスワードを変更することを許可しています。

JDBC データビューの設定とテスト

次の作業は、mySQL データベースがインストールされて実行中であり、データベースにデータが存在し、mySQL データベースが次のように設定されていることが前提となっています。

データベース名: sample_sql
データベース URL: host2.example.com:3306/
JDBC ドライバ URL: file:/net/host2.example/local/mysql/lib/jdbc.jar
ドライバクラス: com.mysql.jdbc.Driver
データベースユーザー: root
データベースパスワードファイル: mysqlpwd.txt

次の表は、データベース内のテーブルと複合フィールドを説明しています。JDBC データビューを設定するためにこの情報が必要です。

mySQL テーブル	フィールド
`EMPLOYEE`	`ID`、`SURNAME`、`PASSWORD`、 `ROOM`、`COUNTRY_ID`
`COUNTRY`	`ID`、`NAME`
`PHONE`	`USER_ID`、`NUMBER`

JDBC データビューを設定する

SQL データベース用の mysql1 という名前の JDBC データソースを作成します。

% dpconf create-jdbc-data-source -b sample_sql \
 -B jdbc:mysql://host2.example.com:3306/ \
 -J file:/net/host2.example/local/mysql/lib/jdbc.jar \
 -S com.mysql.jdbc.Driver mysql1

SQL データベースのユーザー名とパスワードファイルを指定します。
% dpconf set-jdbc-data-source-prop mysql1 db-pwd-file:sqlpwd.txt db-user:root

プロキシサーバーを再起動します。
% dpadm restart /local/dps

データソースを有効にして、データソースへの書き込み操作を許可します。
% dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false

mysql1–pool という名前の JDBC データソースプールを作成します。
% dpconf create-jdbc-data-source-pool mysql1-pool

JDBC データソースをデータソースプールに接続します。
% dpconf attach-jdbc-data-source mysql1-pool mysql1

ベース DN が o=sql で myjdbc1–view という名前のデータソースプールの JDBC データビューを作成します。
% dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql

MySQL データベースの各テーブルの JDBC テーブルを作成します。
% dpconf create-jdbc-table employee1 EMPLOYEE % dpconf create-jdbc-table country1 COUNTRY % dpconf create-jdbc-table phone1 PHONE
SQL データベースのテーブル名は大文字と小文字を区別します。SQL データベースの場合と同じ文字 (大文字または小文字) を使用していることを確認してください。

各テーブルの各列の JDBC 属性を作成します。

JDBC 属性を作成すると、MySQL 列が LDAP 属性にマップされます。

% dpconf add-jdbc-attr employee1 uid ID
% dpconf add-jdbc-attr employee1 sn SURNAME
% dpconf add-jdbc-attr employee1 userPassword PASSWORD
% dpconf add-jdbc-attr employee1 roomNumber ROOM
% dpconf add-jdbc-attr phone1 telephoneNumber NUMBER
% dpconf add-jdbc-attr country1 countryName NAME

phone1 user_id 列と country1 id 列には、LDAP 属性 uid がすでに作成されている EMPLOYEE.ID に存在する値だけが含まれるため、これらの列の JDBC 属性を必ずしも作成する必要はありません。

LDAP person オブジェクトクラスに対して JDBC オブジェクトクラスを作成します。

ここでは、employee1 テーブルを一次テーブル、country1 テーブルと phone1 テーブルを二次テーブルとします。JDBC オブジェクトクラスの作成にも DN が必要です。この例では、DN は uid 属性とデータビューのベース DN から構築されます。
% dpconf create-jdbc-object-class mysql1-view person employee1 country1 phone1 uid

一次テーブルと二次テーブル間の結合ルールを定義します。

結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。
% dpconf set-jdbc-table-prop country1 filter-join-rule:ID=\${EMPLOYEE.COUNTRY_ID} % dpconf set-jdbc-table-prop phone1 filter-join-rule:USER_ID=\${EMPLOYEE.ID}

JDBC オブジェクトクラスのスーパークラスを指定します。

スーパークラスは、JDBC オブジェクトクラスが属性を継承した LDAP オブジェクトクラスを示します。
% dpconf set-jdbc-object-class-prop mysql1-view person super-class:top

必要な ACI を作成する

JDBC データビューをテストする前に、ACI を設定してデータビューへの書き込みアクセスを有効にします。デフォルトで、LDAP データビュー以外への書き込みアクセスは拒否されます。この例では、ユーザーに自分のパスワードの変更を許可するグローバル ACI を 1 つ追加するだけで十分です。

プロキシマネージャーとして、ACI のプールを JDBC データソースに追加し、ユーザーに自分のエントリの変更を許可するグローバル ACI を追加します。

% ldapmodify -p 1389 -D "cn=proxy manager" -w password
dn: cn=mysql1,cn=virtual access controls
changetype: add
objectclass: acisource
dpsaci: (targetattr="*") (target = "ldap:///o=sql") 
(version 3.0; acl "enable all access for all users "; allow(all) 
userdn="ldap:///uid=kvaughan,o=sql";)
cn: mysql1

o=sql ドメインへの接続を処理するために接続ハンドラを作成します。
% dpconf create-connection-handler mysql1-handler

接続ハンドラを有効にして、o=sql ドメイン内のユーザーからのバインドをすべて処理するように設定します。
% dpconf set-connection-handler-prop mysql1-handler is-enabled:true \ bind-dn-filters:"uid=.*,o=sql"

前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。
% dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1

JDBC データビューをテストする

o=sql のユーザーとして JDBC データソースを検索し、データビューから読み取りができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*"
注 –
o=sql のユーザーの資格を使用する必要があります。

o=sql のユーザーとして、 userPassword 属性を変更して、データビューに書き込みができることを確認します。

% ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd
dn: uid=kvaughan,o=sql
changetype: modify
replace: userPassword
userPassword: myNewpwd

結合データビューの作成とテスト

結合データビューを作成する

myjoin1–view という名前の結合データビューを作成します。

LDAP データビューを一次データビュー、JDBC データビューを二次データビューに指定します。
% dpconf create-join-data-view myjoin1-view myds1-view mysql1-view o=join

二次データビューで結合ルールを定義します。

次の結合ルールは、二次データビューのエントリの uid 属性が一次データビューのエントリの uid 属性に一致することを指定します。
% dpconf set-jdbc-data-view-prop mysql1-view filter-join-rule:uid=\${myds1-view.uid}

結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \ write add-attr-value dn uid=\${uid}
注 –
このルールを設定しなければ、結合データビューにエントリを追加できません。

結合データビューを使用して、一次データビューに対して読み書きができる属性のセットを定義します。

% dpconf set-ldap-data-view-prop myds1-view viewable-attr:dn \
viewable-attr:cn viewable-attr:sn viewable-attr:givenName \
viewable-attr:objectClass viewable-attr:ou viewable-attr:l \
viewable-attr:uid viewable-attr:mail viewable-attr:telephoneNumber \
viewable-attr:facsimileTelephoneNumber viewable-attr:roomNumber \
viewable-attr:userPassword
% dpconf set-ldap-data-view-prop myds1-view writable-attr:dn \
writable-attr:cn writable-attr:sn writable-attr:givenName \
writable-attr:objectClass writable-attr:ou writable-attr:l \
writable-attr:uid writable-attr:mail writable-attr:telephoneNumber \
 writable-attr:facsimileTelephoneNumber writable-attr:roomNumber \
writable-attr:userPassword

これらの定義は、結合ビューのコンテキストにのみ適用されます。LDAP データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。

結合データビューを使用して、二次データビューに対して読み書きができる属性のセットを定義します。

% dpconf set-jdbc-data-view-prop mysql1-view viewable-attr:dn \
 viewable-attr:objectclass viewable-attr:sn viewable-attr:roomNumber \
 viewable-attr:userpassword viewable-attr:jobtitle viewable-attr:countryName \
 viewable-attr:telephoneNumber
% dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn \
writable-attr:objectclass writable-attr:sn writable-attr:roomNumber \
writable-attr:userpassword writable-attr:jobtitle \
writable-attr:countryName writable-attr:telephoneNumber

これらの定義は、結合ビューのコンテキストにのみ適用されます。JDBC データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。

必要な ACI を作成する

プロキシマネージャーとして、結合データビューへの匿名アクセスを許可するグローバル ACI を追加します。

% ldapmodify -p 1389 -D "cn=proxy manager" -w password
dn: cn=myjoin1,cn=virtual access controls
changetype: add
objectclass: acisource
dpsaci: (targetattr="*") (target = "ldap:///o=join") 
(version 3.0; acl "anonymous_access"; allow(all) userdn="ldap:///anyone";)
cn: myjoin1

前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。
% dpconf set-connection-handler-prop default-connection-handler aci-source:myjoin1

結合データビューをテストする

匿名ユーザーとして、結合データビューを検索します。

ここでは、Kirsten Vaughan のエントリを検索し、両方の結合ビューからのデータが取得されるかどうかを確認します。
% ldapsearch -p 1389 -b o=join "uid=kvaughan"
返されるエントリには、LDAP データビューと JDBC データビューの両方からの属性が含まれていることに注意してください。

o=join のユーザーとして、userPassword 属性を変更して、結合データビューに書き込みができることを確認します。
% ldapmodify -p 1389 dn: uid=kvaughan,ou=people,o=join changetype: modify replace: userPassword userPassword: myPassword

複数の異種データソースの結合

この設定は、仮想ディレクトリの機能のいくつかが特定のディレクトリサービス要件を満たしている Example.com という組織で説明します。

データストレージシナリオ

Example.com は複数の異種データソースに組織データを保存しています。過去の経緯により、ユーザーデータは LDAP ディレクトリ、フラット LDIF ファイル、SQL データベースに分散されています。HR 部門は o=example.com のベース DN でユーザーデータを LDAP ディレクトリに保存しています。給与部門はデータを SQL データベースに保存しています。部門やビルの番号などの管理データはdc=example,dc=com のベース DN で管理部門の LDIF ファイルに保存されています。

さらに、Example.com は Company22 という名前の企業を買収しました。Company 22 もユーザーデータを dc=company22,dc=com のベース DN で LDAP ディレクトリに保存しています。

次の図は、Example.com のユーザーデータがどのように保存されているかをまとめたものです。

図 23–2 異種ソースのデータストレージ

図は、Example.com のユーザーデータがどのように異種のデータソースに保存されているかを示しています。

クライアントアプリケーション要件

Example.com には、異種データソースに保存されたデータにアクセスする必要のある LDAP クライアントアプリケーションがいくつかあります。クライアントアプリケーションの要件はすべて同じではありません。異なるデータビューは必要です。場合によっては、クライアントはデータを集約する必要があります。さらに、Example.com の新しい従業員を以前からの従業員とともに管理できるように、一部のクライアントアプリケーションは Company22 のユーザーデータにアクセスする必要があります。

次の図は、Example.com のクライアントアプリケーション要件をまとめたものです。

図 23–3 クライアントアプリケーション要件

図は、Example.com の LDAP アプリケーションの要件を示しています。

次の節では、Directory Proxy Server データビューがこのサンプルシナリオで説明したクライアントアプリケーション要件を十分満たすことができる設定について見ていきます。データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 17 章「Directory Proxy Server Distribution」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。

サンプルシナリオの設定は次のセクションで構成されています。

HR LDAP ディレクトリと管理 LDIF ファイルのデータの集約

HR 部門は従業員名、職務開始データ、職務レベルなどの情報を保存しています。管理部門は、建築基準法や会社の電話番号などの追加データを保存しています。HR データを処理するクライアントアプリケーションは、両方のソースからの複合データにアクセスする必要があります。各エントリ内の属性 employeeNumber は両方のデータソースに共通です。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–4 LDAP ディレクトリと LDIF ファイルのデータの集約

このアプリケーション要件を満たすために、給与ディレクトリと管理 LDIF ファイル用にデータビューが作成されます。これらの 2 つのデータビューは、その後、集約されたデータにアクセスできるよう結合されます。この共通属性によって、Directory Proxy Server は各ユーザーのデータを集約できます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
給与 LDAP ディレクトリは payrollHost という名前のホストのポート 2389 で実行されている。
管理データを保存している LDIF ファイルの名前は、 example.ldif である。

各コマンドの完全な構文を取得するために、オプションを使用せずにコマンドを実行します。次に例を示します。

$ dpconf create-ldap-data-view
Operands are missing
Usage: dpconf create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN

給与ディレクトリの LDAP データビューの作成と有効化

給与ディレクトリの LDAP データソースを作成します。
```
$ dpconf create-ldap-data-source payroll-directory payrollHost:2389
```

給与ディレクトリの LDAP データソースプールを作成します。
```
$ dpconf create-ldap-data-source-pool payroll-pool
```

給与データソースをデータソースプールに接続します。
```
$ dpconf attach-ldap-data-source payroll-pool payroll-directory
```

接続済みデータソースのウェイトを設定します。

$ dpconf set-attached-ldap-data-source-prop -h payrollHost -p 2389 \
payroll-pool payroll-directory add-weight:2 \
bind-weight:2 compare-weight:2 delete-weight:2 \
modify-dn-weight:2 modify-weight:2 search-weight:2

給与ディレクトリの LDAP データビューを作成します。
```
$ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com
```

クライアント要求がこのデータビューに経路指定できるように LDAP データビューを有効にします。
```
$ dpconf set-ldap-data-view-prop payroll-view is-enabled:true
```

変更を有効にするために、Directory Proxy Server を再起動します。
```
$ dpadm restart /local/myDPS
```

管理データの LDIF データビューの作成と有効化

管理データの LDIF データビューを作成します。

$ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com

管理データの LDIF データビューを有効にします。
```
$ dpconf set-ldif-data-view-prop admin-view is-enabled:true
```

管理ビューに給与ビューの複数のエントリで使用されるエントリが含まれるように指定します。
```
$ dpconf set-ldif-data-view-prop admin-view contains-shared-entries:true
```
このプロパティーが TRUE に設定されている場合、給与データビューのエントリを削除しても、管理データビューの共有エントリは削除されません。給与データビューにエントリを追加すると、それがすでに存在していなければ、二次データビューのエントリのみが追加されます。

変更を有効にするために、Directory Proxy Server を再起動します。
```
$ dpadm restart /local/myDPS
```

給与データビューと管理データビューの結合

データの集約方法を指定するフィルタ結合ルールを管理データビューで作成します。

次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。
```
$ dpconf set-ldif-data-view-prop admin-view \
filter-join-rule:employeeNumber=\${payroll-view.employeeNumber}
```

2 つのデータビューを集約する結合データビューを作成します。

結合データビューに対して、組織はサフィックス DN dc=example,dc=com を使用します。
```
$ dpconf create-join-data-view example-join-view payroll-view admin-view \
dc=example,dc=com
```

DN の名前を変更して Company 22 からのデータを Example.Com の DIT に追加

Company 22 のユーザーデータは、DN dc=company22,dc=com で保存されています。Example.com はこのユーザーデータをほとんどの場合に区別しておきたいと考えていますが、あるクライアントアプリケーションは Company 22 の従業員を Example.com の残りの従業員とともに管理する必要があります。このクライアントアプリケーションは Company 22 のユーザーデータが Example.com のデータのように見えることを必要としています。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–5 DN の名前の変更

このアプリケーション要件を満たすために、仮想 DN の dc=example,dc=com のデータビューが Company 22 ディレクトリに対して作成されます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
Company 22 LDAP ディレクトリは company22Host という名前のホストのポート 2389 で実行されている。

仮想 DN を持つ Company 22 のディレクトリに対するデータビューの作成

Company 22 のディレクトリの LDAP データソースを作成します。
```
$ dpconf create-ldap-data-source company22-directory company22Host:2389
```

Company 22 のディレクトリの LDAP データソースプールを作成します。
```
$ dpconf create-ldap-data-source-pool company22-pool
```

Company 22 のデータソースをデータソースプールに接続します。
```
$ dpconf attach-ldap-data-source company22-pool company22-directory
```

接続済みデータソースのウェイトを設定します。

$ dpconf set-attached-ldap-data-source-prop -h company22Host -p 2389 \
company22-pool company22-directory add-weight:2 \
bind-weight:2 compare-weight:2 delete-weight:2 \
modify-dn-weight:2 modify-weight:2 search-weight:2

仮想 DN の dc=example,dc=com で Company 22 のディレクトリの LDAP データビューを作成します。
```
$ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com
```

この仮想 DN を Company 22 のディレクトリの実際の DN にマップするよう Directory Proxy Server に命令します。
```
$ dpconf set-ldap-data-view-prop company22-view \
dn-mapping-source-base-dn:dc=company22,dc=com
```

クライアント要求がこのデータビューに経路指定できるように、Company 22 のディレクトリの LDAP データビューを有効にします。
```
$ dpconf set-ldap-data-view-prop company22-view is-enabled:true
```

変更を有効にするために、Directory Proxy Server を再起動します。
```
$ dpadm restart /local/myDPS
```

Company 22 のデータの HR データへの追加

HR 部門は Example.com と新しく買収した Company 22 の HR データの集約されたビューを必要としています。次の図は、グローバル HR アプリケーションの要件を示しています。

図 23–6 結合データビューと LDAP データビューからのデータの集結

図は、LDAP ディレクトリとほかの結合ビューの複合的な結合ビューを示しています。

結合データビューの例と Company 22 データビューの結合

データの集約方法を指定するフィルタ結合ルールを Company 22 データビューで作成します。

次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。
```
$ dpconf set-ldif-data-view-prop company22-view \
filter-join-rule:employeeNumber=\${example-join-view.employeeNumber}
```

Company 22 のデータビューと Example.com の結合データビューを集約する結合データビューを作成します。
```
$ dpconf create-join-data-view global-join-view example-join-view \
company22-view dc=example,dc=com
```

LDAP クライアントによる SQL データベース内の給与データへのアクセスの有効化

Example.com の給与部門は給与データを SQL データベースに保存しています。データベースには、employee テーブルと salary テーブルの 2 つのテーブルがあります。Example.com には、このデータへのアクセスを必要とする LDAP クライアントアプリケーションがあります。クライアントアプリケーションは SQL データが LDAP データのように見えることを必要としています。

次の図は、クライアントアプリケーションの要件を示しています。

図 23–7 SQL データベースへのアクセスを提供する JDBC データビュー

図は、SQL データベースへのアクセスを提供する JDBC データビューを示しています。

このアプリケーション要件を満たすために、SQL テーブル内の列を LDAP 属性にマップする JDBC データビューが作成されます。

わかりやすいように、ここで使用するコマンドは次の情報を前提としています。

Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
SQL データベースが起動して実行中である。
JAVA_HOME 変数が正しい Java パスに設定されている。
SQL データベースへのパスワードは、myPasswordFile ファイルに格納された myPassword である。

Example.com の給与データベースに対する JDBC データビューの作成

給与データベース用の JDBC データソースを作成します。

$ dpconf create-jdbc-data-source -b payrollsqldb \
  -B jdbc:payrollsqldb:payrollsql://localhost/ \
  -J file://payrollsqldb.jar \
  -S org.payrollsqldb.jdbcDriver payroll-src

SQL データベースのプロパティーで JDBC データソースを設定します。

$ dpconf set-jdbc-data-source-prop payroll-src \
  db-user:proxy db-pwd-file:password-file-location/myPasswordFile

JDBC データソースを有効にします。

$ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true

給与データベース用の JDBC データソースプールを作成します。
```
$ dpconf create-jdbc-data-source-pool payroll-pool
```

給与データソースをデータソースプールに接続します。
```
$ dpconf attach-jdbc-data-source payroll-pool payroll-src
```

仮想 DN の o=payroll で給与データベースの JDBC データビューを作成します。
```
$ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll
```

SQL データベースの各テーブルの JDBC テーブルを作成します。

$ dpconf create-jdbc-table jdbc-employee employee
$ dpconf create-jdbc-table jdbc-salary salary

各 SQL テーブルの各列の JDBC 属性を作成します。

$ dpconf add-jdbc-attr jdbc-employee eid employee_id
$ dpconf add-jdbc-attr jdbc-employee first firstname
$ dpconf add-jdbc-attr jdbc-employee last lastname
$ dpconf add-jdbc-attr jdbc-employee description description
$ dpconf add-jdbc-attr jdbc-employee spouse spousename
$ dpconf add-jdbc-attr jdbc-salary salary salary
$ dpconf add-jdbc-attr jdbc-salary social ssn

JDBC データビューで表示できる属性と書き込める属性を指定します。

$ dpconf set-jdbc-data-view-prop payroll-view \
 viewable-attr:eid \
 viewable-attr:first \
 viewable-attr:last \
 viewable-attr:desc \
 viewable-attr:spouse \
 viewable-attr:salary \
 viewable-attr:social 
 $ dpconf set-jdbc-data-view-prop payroll-view \
 writable-attr:eid \
 writable-attr:first \
 writable-attr:last \
 writable-attr:description \
 writable-attr:spouse \
 writable-attr:salary \
writable-attr:social

LDAP オブジェクトクラスにマップされる JDBC オブジェクトクラスを作成します。

次のコマンドは、LDAP person オブジェクトクラスにマップされるオブジェクトクラスを作成します。オブジェクトクラスは、従業員テーブルは一次テーブルとして使用され、給与テーブルが二次テーブルとして使用されるよう指定します。eid 属性は、DN を構築するために使用されます。
```
$ dpconf create-jdbc-object-class payroll-view \
 person jdbc-employee jdbc-salary eid
```

二次テーブルからのデータが一次テーブルからのデータにリンクされる方法を指定したフィルタ結合ルールを二次テーブル上で作成します。

次の結合ルールは、employee_id 属性に基づいてデータが結合されるよう指定します。
```
$ dpconf set-jdbc-table-prop jdbc-salary \
filter-join-rule:employee_id=\${employee.employee_id}
```

JDBC オブジェクトクラス上のスーパークラスを作成します。

$ dpconf set-jdbc-object-class-prop payroll-view person super-class:extensibleObject

仮想アクセス制御の追加

LDAP ディレクトリ上のアクセス制御は、ディレクトリ自体で ACI を定義することで処理されます。仮想データビューによってデータソースにアクセスされる場合、これらのデータビューで表示されるデータのみに適用される ACI を定義する必要があります。

Directory Proxy Server を経由するアクセスはすべて、接続ハンドラによって制御されます。接続ハンドラについては、第 26 章「クライアントと Directory Proxy Server の接続」を参照してください。

匿名アクセスを許可する ACI の追加

ACI を追加します。

$ ldapadd -v -D "cn=proxy manager" -w password -p 389
dn: cn=ldifonly-acis,cn=virtual access controls
objectclass: top
objectclass: aciSource
cn: ldifonly-acis
dpsaci: (targetattr="*")(version 3.0; acl "anonymous_access"; allow(all) \
(userdn="ldap:///anyone");)

接続ハンドラで仮想 ACI をポイントします。

$ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis

接続ハンドラを有効にします。

$ dpconf set-connection-handler-prop anonymous is-enabled:true

第 24 章仮想データ変換

仮想データ変換は、既存のデータビュー上で定義され、仮想データビューを使用して仮想データを作成できるようにします。機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Virtual Data Transformations」を参照してください。

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

仮想データ変換の設定

仮想データ変換は次のどの種類のデータビューにも追加できます。LDAP データビュー、LDIF データビュー、結合データビュー、または JDBC データビュー。

仮想変換を追加する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

変換をデータビューに追加します。
$ dpconf add-virtual-transformation -h host -p port view-name \ transformation-model transformation-action attribute-name [parameters...]
transformation-model は、mapping、write、および read 変換のいずれかです。

transformation-action は、add-attr、remove-attr、add-attr-value、remove-attr-value、def-value、および attr-value-mapping アクションのいずれかです。

transformation-model と transformation-action によっては、parameters は必須である場合があります。

変換のモデル、変換アクション、変換パラメータについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Virtual Data Transformations」を参照してください。

(省略可能) データビューで定義された仮想変換の一覧を表示します。
```
$ dpconf list-virtual-transformations -h host -p port view-name
```

仮想変換を削除する

次のコマンドを使用して仮想変換を削除します。

dpconf remove-virtual-transformation view_name transformation_name

仮想変換の例

次の節では、仮想データビューが必要なユースケースと、それらのユースケースの実装に必要な変換のモデルとアクションの組み合わせを示します。

エントリの既存の属性から派生した属性の誘導

次の変換ルールを使用して、エントリの既存の属性から属性を誘導します。たとえば、次の変換ルールを適用すると、givenName および sn 属性から派生した mail 属性が表示されます。

$ dpconf add-virtual-transformation dataview1 read add-attr \
mail \${givenName}.\${sn}@example.com

次の図に、検索で返されるユーザーエントリで発生する変換を示します。

物理属性への属性のマップ

次のマッピング変換ルールを使用して、純粋な仮想属性の一部として配信された属性を追加します。たとえば、次の変換ルールを適用すると、givenName は、エントリで指定されていなくてもサーバーに格納されます。値は、mail \${givenName}@example.com として定義された純粋な仮想属性から取られます。

$ dpconf add-virtual-transformation dataview1 mapping add-attr \
mail \${givenName}@example.com

まず、仮想属性として mail 属性を含み、givenName 属性を含まないエントリを追加します。仮想変換により、givenName 属性の値が生成され、エントリは givenName 属性とともに格納されますが、mail 属性は含まれていません。次に、uid 属性の使用時に検索を行いながら、givenName の値を取得すると、同じ仮想変換により、仮想属性 mail の値が生成されます。

次の図に、ユーザーエントリで発生する変換を示します。

別の物理属性によって指定された属性の 2 つ目の仮想値の表示

次の変換を使用して、別の属性によって指定された属性の値を表示します。たとえば、uid を cn として表示するときに、すでにエントリに格納されている cn の値も表示できます。次の場合は、cn に追加の値は格納されませんが、結果がクライアントに返される前に変換が適用されます。

$ dpconf add-virtual-transformation dataview1 read add-attr-value cn \${uid}

次の図に、検索で返されるユーザーエントリで発生する変換を示します。

別の物理属性によって指定された属性への 2 つ目の値の格納

次の変換ルールを使用して、属性の値と、新しいエントリを追加するときに指定した値を格納します。このシナリオでは、エントリを追加すると、mail 属性の追加の値が格納されます。この変換は、新しいエントリを作成するときだけ適用されます。

$ dpconf add-virtual-transformation dataview1 write add-attr-value \
mail \${uid}@example.com

次の図に、追加要求で発生する変換を示します。

属性の出力からの削除

属性を出力に表示しない場合は、次の変換ルールを使用します。たとえば、次の変換ルールを適用すると、givenName は出力に返されません。

dpconf add-virtual-transformation dataview1 read remove-attr givenName

次の図に、検索で返されるユーザーエントリで発生する変換を示します。

エントリの保存時の属性のマスキング

特定の属性を格納しない場合は、次の変換ルールを使用します。たとえば、次の変換ルールを適用すると、givenName 属性は物理データベースに格納されません。この変換は、新しいエントリを作成するときだけ適用されます。

$ dpconf add-virtual-transformation dataview1 write remove-attr givenName

次の図に、追加要求で発生する変換を示します。

属性のデフォルト値の表示

属性に割り当てられたデフォルト値を表示する場合は、次の変換を使用します。たとえば、次の変換を適用すると、それ自体の電話番号が含まれていないエントリのデフォルトの電話番号が表示されます。

$ dpconf add-virtual-transformation data-view read 11111 telephoneNumber default-number

次の図に、検索で返されるユーザーエントリで発生する変換を示します。

属性へのデフォルト値の格納

デフォルト値は、エントリの作成時に属性の値が指定されない場合のみ格納されます。デフォルト値を持つ属性を格納する場合は、次の変換ルールを使用します。たとえば、次の変換を適用すると、作成するエントリごとにデフォルトの電話番号が追加されます。この変換は、エントリを追加するときだけ適用されます。

$ dpconf add-virtual-transformation dataview1 write 11111 \
telephoneNumber telephone-number

次の図に、追加要求で発生する変換を示します。

第 25 章 Directory Proxy Server とバックエンド LDAP サーバーの接続

この章では、Directory Proxy Server とバックエンド LDAP サーバーの接続の設定方法について説明します。この章の内容は次のとおりです。

Directory Proxy Server とバックエンド LDAP サーバーの接続の設定

LDAP データソースを作成した場合、その LDAP データソースに対して開かれるデフォルトの接続数は 6 で、読み取り操作、バインド操作、および書き込み操作にそれぞれ 2 つずつ使用されます。デフォルトの接続数を確認するには、次のコマンドを入力します。

dpconf get-ldap-data-source-prop src-name num-read-init num-write-init num-bind-init
num-bind-init   :  2
num-read-init   :  2
num-write-init  :  2

接続数は、トラフィックが増加すると自動的に増やされます。

Directory Proxy Server とバックエンド LDAP サーバーの接続の設定方法については、次の手順を参照してください。

Directory Proxy Server とバックエンド LDAP サーバーの接続の数を設定する

注 –

この手順では、バインド操作の接続数を設定します。読み取り操作または書き込み操作の接続数を設定するには、同じ手順を実行しますが bind を read または write に置き換えます。

バインド操作のための Directory Proxy Server とバックエンド LDAP サーバーの接続数の初期値を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-init:new-value

バインド操作のための接続の増分を設定します。

増分は、現在の数より多い接続が要求されるたびに追加される接続数です。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-incr:new-value

バインド操作のための接続の最大数を設定します。

この接続の最大数に達すると、それ以上接続を追加できなくなります。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-limit:new-value

接続のタイムアウトを設定する

Directory Proxy Server がデータソースに接続し続けることのできる最長時間を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ connect-timeout:new-value
たとえば、接続のタイムアウトを 10 ミリ秒に設定します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 data-source-name connect-timeout:10

接続プール待機タイムアウトを設定する

Directory Proxy Server が接続プール内の確立された接続を使用できるようになるまで待機できる最長時間を設定します。
$ dpconf set-server-prop -h host -p port data-source-name \ connection-pool-wait-timeout:value
たとえば、タイムアウトを 20 秒に設定します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 data-source-name \ connection-pool-wait-timeout:20000

Directory Proxy Server とバックエンド LDAP サーバーとの間の SSL の設定

次の手順では、Directory Proxy Server とバックエンド LDAP サーバーとの間の SSL の設定方法を説明しています。

Directory Proxy Server とバックエンド LDAP サーバーとの間の SSL を設定する

Directory Proxy Server とバックエンド LDAP サーバー間のセキュアポートを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ ldaps-port:port-number

Directory Proxy Server とバックエンド LDAP サーバーの接続にいつ SSL が使用されるかを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name ssl-policy:value
- value が always の場合、接続に常に SSL が使用されます。
- value が client の場合、クライアントが SSL を使用している場合に SSL が使用されます。
接続が SSL を使用していない場合、startTLS コマンドを使用して SSL への接続をプロモートできます。

Transport Layer Security (TLS) は SSL の標準バージョンです。TLS over LDAP は、IETF 認可の、LDAP をセキュリティー保護する標準の方法です。LDAPS は事実上の標準ですが、サービス用のポートが 1 つだけでなく 2 つあるなど、いくぶん複雑な面があります。

「Directory Proxy Server の SSL 暗号化方式と SSL プロトコルの選択」で説明されているように、SSL のプロトコルと暗号化方式を選択します。

バックエンド LDAP サーバーからの SSL サーバー証明書を検証するよう Directory Proxy Server を設定します。

詳細は、「証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する」を参照してください。

バックエンド LDAP サーバーが Directory Proxy Server からの証明書を要求する場合は、SSL クライアント証明書を送信するよう Directory Proxy Server を設定します。

詳細については、「バックエンド LDAP サーバーへの証明書のエクスポート」を参照してください。

変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

Directory Proxy Server の SSL 暗号化方式と SSL プロトコルの選択

Directory Proxy Server で使用できる暗号化方式とプロトコルは、使用している Java^TM 仮想マシン (JVM^TM) によって異なります。デフォルトで、Directory Proxy Server は JVM マシンで有効なデフォルトの暗号化方式とプロトコルを使用します。

暗号化方式とプロトコルの一覧を選択する

この手順に従って、サポートされている暗号化方式とプロトコルおよび有効な暗号化方式とプロトコルを取得します。暗号化方式またはプロトコルがサポートされている場合は、それを有効または無効にできます。

サポートされている暗号化方式とプロトコルの一覧を表示します。

$ dpconf get-server-prop -h host -p port supported-ssl-cipher-suites \
 supported-ssl-protocols

有効な暗号化方式とプロトコルの一覧を表示します。

$ dpconf get-server-prop -h host -p port enabled-ssl-cipher-suites \
 enabled-ssl-protocols

1 つまたは複数のサポートされている暗号化方式またはプロトコルを有効にします。
1. 1 つまたは複数のサポートされている暗号化方式を有効にします。
  $ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-suites:supported-ssl-cipher-suite \ [enabled-ssl-cipher-suites:supported-ssl-cipher-suite ...]
  サポートされている暗号化方式の既存リストに暗号化方式を追加するには、次のコマンドを使用します。
  $ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-suites+:supported-ssl-cipher-suite
2. 1 つまたは複数のサポートされているプロトコルを有効にします。
  $ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-protocols:supported-ssl-cipher-protocol \ [enabled-ssl-cipher-protocols:supported-ssl-cipher-protocol ...]
  サポートされているプロトコルの既存リストにプロトコルを追加するには、次のコマンドを使用します。
  $ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-protocols+:supported-ssl-cipher-protocol

(省略可能) サポートされている暗号化方式またはプロトコルを無効にします。

$ dpconf set-server-prop -h host -p port \
 enabled-ssl-cipher-protocols-:supported-ssl-cipher-protocol

バックエンド LDAP サーバーへの要求の転送

この節では、Directory Proxy Server からの要求をバックエンド LDAP サーバーに転送するためのさまざまな方法について説明します。

バインド再実行での要求の転送

Directory Proxy Server のクライアント資格のバインド再実行については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Configured for BIND Replay」を参照してください。次の手順は、Directory Proxy Server からの要求をバックエンド LDAP サーバーにバインド再実行を使用して転送する方法について説明しています。

バインド再実行で要求を転送する

クライアントによって提供された資格を使用してバックエンド LDAP サーバーへの接続を認証するデータソースクライアント資格を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-client-identity

プロキシ承認での要求の転送

Directory Proxy Server 内のプロキシ承認については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Configured for Proxy Authorization」を参照してください。

この節では、プロキシ承認とプロキシ承認制御を使用して要求を転送する手順について説明します。

プロキシ承認を使用して要求を転送する

version 1 または version 2 のプロキシ承認制御を受け入れるようデータソースを設定します。

たとえば、version 1 のプロキシ承認制御を受け入れるようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-use-v1:true
または、version 2 のプロキシ承認制御を受け入れるようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-use-v1:false

プロキシ承認を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-proxy-auth
書き込み操作のみのため、プロキシ承認を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定するには、次のコマンドを実行します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-proxy-auth-for-write
書き込み操作のみがプロキシ承認制御で実行される場合、クライアントのアイデンティティーは読み取り要求のために LDAP サーバーに転送されません。クライアントアイデンティティーのない要求の転送の詳細については、「クライアントアイデンティティーなしでの要求の転送」を参照してください。

Directory Proxy Server のバインド資格でデータソースを設定します。

$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \
 bind-dn:DPS-bind-dn bind-pwd-file:filename

タイムアウトでデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-check-timeout:value
Directory Proxy Server は、getEffectiveRights コマンドを使用して、プロキシ承認に適した ACI がクライアント DN にあることを確認します。その結果は Directory Proxy Server のキャッシュに格納され、proxied-auth-check-timeout の期限が終了すると更新されます。

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

要求にプロキシ承認制御が含まれている場合に、プロキシ承認を使用して要求を転送する

version 1、version 2、またはその両方のプロキシ承認制御を受け入れるよう Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port allowed-ldap-controls:proxy-auth-v1 \ allowed-ldap-controls:proxy-auth-v2

クライアントアイデンティティーなしでの要求の転送

次の手順は、クライアントアイデンティティーを転送せずに Directory Proxy Server からの要求をバックエンド LDAP サーバーに転送する方法について説明しています。

クライアントアイデンティティーなしでの要求を転送する

Directory Proxy Server の資格を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-specific-identity

Directory Proxy Server のバインド資格でデータソースを設定します。

$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \
 bind-dn:bind-dn-of-DPS bind-pwd-file:filename

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

代替ユーザーとしての要求の転送

ここでは、代替ユーザーとして要求を転送する方法について説明します。

リモートユーザーマッピングを設定する

代替ユーザーで転送が行えるように設定を有効にします。
$ dpconf set-server-prop -h host -p port enable-user-mapping:true

リモートマッピング用の ID を含む属性の名前を指定します。

$ dpconf set-server-prop -h host -p port \
 remote-user-mapping-bind-dn-attr:attribute-name

Directory Proxy Server がクライアント ID をリモートでマップできるようにします。
$ dpconf set-server-prop -h host -p port enable-remote-user-mapping:true

デフォルトマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-default-bind-dn:default-mapping-bind-dn \ user-mapping-default-bind-pwd-file:filename
マップしたアイデンティティーがリモート LDAP サーバー上に見つからない場合、クライアントアイデンティティーはデフォルトアイデンティティーにマップされます。

リモート LDAP サーバー上のクライアントのエントリでユーザーマッピングを設定します。

Directory Server でのユーザーマッピングの設定については、「プロキシ承認」を参照してください。

ローカルユーザーマッピングを設定する

代替ユーザーで転送が行えるように設定を有効にします。
$ dpconf set-server-prop -h host -p port enable-user-mapping:true

Directory Proxy Server がクライアント ID をリモートでマップする設定がされていないことを確認します。
$ dpconf set-server-prop -h host -p port enable-remote-user-mapping:false

デフォルトマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-default-bind-dn:default-mapping-bind-dn \ user-mapping-default-bind-pwd-file:filename
リモート LDAP サーバー上のマッピングに失敗すると、クライアント ID がこの DN にマップされます。

認証されていないユーザーに操作の実行を許可する場合は、認証されていないクライアントに対するマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-anonymous-bind-dn:anonymous-mapping-bind-dn \ user-mapping-anonymous-bind-pwd-file:filename
認証されていないユーザーに操作の実行を許可する方法については、「匿名アクセスを設定する」を参照してください。

クライアントの ID を設定します。

$ dpconf set-user-mapping-prop -h host -p port \
 user-bind-dn:client-bind-dn user-bind-pwd-file:filename

代替ユーザーの ID を設定します。

$ dpconf set-user-mapping-prop -h host -p port \
 mapped-bind-dn:alt-user-bind-dn mapped-bind-pwd-file:filename

匿名クライアントのユーザーマッピングを設定する

認証されていないクライアントのマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-anonymous-bind-dn:anonymous-mapping-bind-dn \ user-mapping-anonymous-bind-pwd-file:filename
リモート LDAP サーバーには匿名クライアントのエントリが含まれていないため、匿名クライアントのマッピングは、Directory Proxy Server で設定されます。

認証されていないユーザーへの操作の実行の許可については、「匿名アクセスを設定する」を参照してください。

第 26 章クライアントと Directory Proxy Server の接続

クライアントと Directory Proxy Server の接続の概要、接続ハンドラ、および接続ハンドラで使用される条件とポリシーの説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 20 章「Connections Between Clients and Directory Proxy Server」を参照してください。

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

接続ハンドラの作成、設定、削除

接続ハンドラの作成、設定、削除の方法と、データビューに対するアフィニティーの設定方法については、次の手順を参照してください。

接続ハンドラを作成する

接続ハンドラを作成します。

$ dpconf create-connection-handler -h host -p port connection-handler-name

(省略可能) 接続ハンドラのリストを表示します。
$ dpconf list-connection-handlers -h host -p port

接続ハンドラを設定する

始める前に

接続ハンドラのプロパティーは、Directory Proxy Server インスタンスに定義されているその他の接続ハンドラのプロパティーに関連して定義する必要があります。さまざまな基準のセットを確実に指定し、正しい優先順位を設定するため、すべての接続ハンドラのプロパティーを考慮してください。

接続ハンドラの詳細リストを表示して、それらのキープロパティーと対応する優先順位を確認します。

$ dpconf list-connection-handlers -h host -p port -v
Name                        is-enabled  priority  description
--------------------------  ----------  --------  ---------------------------
anonymous                   false       99        unauthenticated connections
default connection handler  true        100       default connection handler

接続ハンドラ anonymous および default connection handler は、Directory Proxy Server のインスタンスの作成時に作成されます。

1 つの接続ハンドラのすべてのプロパティーを表示します。

$ dpconf get-connection-handler-prop -h host -p port connection-handler-name

新しい接続ハンドラのデフォルトプロパティーは、次のようになります。

aci-source                     :  -
allowed-auth-methods           :  anonymous
allowed-auth-methods           :  sasl
allowed-auth-methods           :  simple
allowed-ldap-ports             :  ldap
allowed-ldap-ports             :  ldaps
bind-dn-filters                :  any
data-view-routing-custom-list  :  -
data-view-routing-policy       :  all-routable
description                    :  -
domain-name-filters            :  any
enable-data-view-affinity      :  false
ip-address-filters             :  any
is-enabled                     :  false
is-ssl-mandatory               :  false
priority                       :  99
request-filtering-policy       :  no-filtering
resource-limits-policy         :  no-limits
schema-check-enabled           :  false
user-filter                    :  any

接続ハンドラの優先順位を設定します。
$ dpconf set-connaection-handler-prop -h host -p port connection-handler-name priority:value
優先順位は 1 〜 100 の任意の数にすることができ、もっとも高い優先順位は 1 です。Directory Proxy Server のインスタンスでは、接続ハンドラは優先順位の順に評価されます。

(省略可能) 接続ハンドラの DN フィルタリングプロパティーを指定します。

このプロパティーにより、バインド DN の一部またはすべてに基づいてアクセスを制御できます。プロパティーの値は正規表現です。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ bind-dn-filters:regular-expression
バインド DN フィルタは、Java^TM 正規表現の形式をとります。Java 正規表現の作成については、http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html を参照してください。

たとえば、すべてのバインドを ou=people,dc=example,dc=com の下のユーザーから secure-handler という接続ハンドラに送信するには、次のように bind-dn-filters プロパティーを設定します。
$ dpconf set-connection-handler-prop -h host1 -p 1389 secure-handler \ bind-dn-filters:"uid=.*,ou=people,dc=example,dc=com"

(省略可能) この接続ハンドラで使用する要求フィルタリングポリシーの名前を指定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ request-filtering-policy:policy-name
ここで、policy-name は既存の要求フィルタリングポリシーの名前です。要求フィルタリングポリシーの作成と設定の方法については、「要求フィルタリングポリシーと検索データの非表示ルールの作成と設定」を参照してください。

(省略可能) この接続ハンドラで使用するリソース制限ポリシーの名前を指定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ resource-limits-policy:policy-name
ここで、policy-name は既存のリソース制限ポリシーの名前です。リソース制限ポリシーの作成と設定の方法については、「リソース制限ポリシーの作成と設定」を参照してください。

手順 2 で一覧表示されるほかのプロパティーを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ property:value [property:value ...]
たとえば、SSL 接続のみを受け付けるように接続ハンドラを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ is-ssl-mandatory:true
プロパティーとその有効な値のリストについては、次のコマンドを実行します。
$ dpconf help-properties connection-handler

接続ハンドラを有効にします。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name is-enabled:true

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

接続ハンドラを削除する

(省略可能) 接続ハンドラのリストを表示します。
$ dpconf list-connection-handlers -h host -p port

1 つまたは複数の接続ハンドラを削除します。

$ dpconf delete-connection-handler -h host -p port connection-handler-name [connection-handler-name ... ]

データビューに対するアフィニティーを設定する

接続ハンドラに接続を割り当てると、その接続にある要求は、その接続ハンドラに設定されているデータビューのリスト、または設定されているデータビューのすべてに公開されます。その接続のそれ以降の要求は、最初の要求に対して使われるデータビューに排他的に公開されます。

データビューに対するアフィニティーを有効にします。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 enable-data-view-affinity:true

(省略可能) 要求をデータビューのカスタムリストに経路指定するように接続ハンドラを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name data-view-routing-policy:custom

(省略可能) データビューのリストを設定します。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 data-view-routing-custom-list:view-name [data-view-routing-custom-list:view-name ...]

データビューの既存リストにデータビューを追加するには、次のコマンドを使用します。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 data-view-routing-custom-list+:view-name

データビューの既存リストからデータビューを削除するには、次のコマンドを使用します。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 data-view-routing-custom-list-:view-name

要求フィルタリングポリシーと検索データの非表示ルールの作成と設定

要求フィルタリングポリシーの概要は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Request Filtering Policies for Connection Handlers」を参照してください。検索データの非表示ルールの概要は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Search Data Hiding Rules in the Request Filtering Policy」を参照してください。

要求フィルタリングポリシーと検索データの非表示ルールの作成と設定の方法については、次の手順を参照してください。

要求フィルタリングポリシーを作成する

要求フィルタリングポリシーを作成します。
$ dpconf create-request-filtering-policy policy-name

要求フィルタリングポリシーを接続ハンドラと関連付けます。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 request-filtering-policy:policy-name

要求フィルタリングポリシーを設定する

要求フィルタリングポリシーのプロパティーを表示します。

$ dpconf get-request-filtering-policy-prop -h host -p port policy-name

要求フィルタリングポリシーのデフォルトプロパティーは次のとおりです。

allow-add-operations                :  true
allow-bind-operations               :  true
allow-compare-operations            :  true
allow-delete-operations             :  true
allow-extended-operations           :  true
allow-inequality-search-operations  :  true
allow-modify-operations             :  true
allow-rename-operations             :  true
allow-search-operations             :  true
allowed-comparable-attrs            :  all
allowed-search-scopes               :  base
allowed-search-scopes               :  one-level
allowed-search-scopes               :  subtree
allowed-subtrees                    :  ""
description                         :  -
prohibited-comparable-attrs         :  none
prohibited-subtrees                 :  none

手順 1 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、要求フィルタリングポリシーを設定します。
$ dpconf set-request-filtering-policy-prop -h host -p port policy-name \ property:value [property:value ...]
手順 1 で一覧表示されるプロパティーを設定することで、次のような要求フィルタリングポリシーの機能を設定します。
- クライアントに実行が許可されている操作のタイプ
- クライアントに公開されるサブツリー、またはクライアントから非表示にされるサブツリー
- 検索操作の範囲
- 検索フィルタのタイプ
- 検索操作と比較操作で比較できる属性と比較できない属性のタイプ

検索データ非表示ルールを作成する

要求フィルタリングポリシーに対して、1 つまたは複数の検索データ非表示ルールを作成します。
$ dpconf create-search-data-hiding-rule -h host -p port policy-name rule-name \ [rule-name ...]

検索データ非表示ルールのプロパティーを表示します。

$ dpconf get-search-data-hiding-rule-prop policy-name rule-name

検索データ非表示ルールのデフォルトプロパティーは、次のとおりです。

attrs                              :  -
rule-action                        :  hide-entry
target-attr-value-assertions       :  -
target-dn-regular-expressions      :  -
target-dns                         :  -

手順 2 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、検索データ非表示ルールを設定します。
$ dpconf set-search-data-hiding-rule-prop -h host -p port policy-name rule-name \ property:value [property:value ...]
次のいずれかのルールアクションを使用できます。

hide-entry

ターゲットエントリは返されません。

hide-attributes

ターゲットエントリは返されますが、指定した属性は表示されません。

show-attributes

ターゲットエントリは返されますが、指定した属性以外は表示されません。

ルールは次のエントリに適用できます。

target-dns

指定した DN を持つエントリ

target-dn-regular-expressions

指定した DN パターンを持つエントリ

target-attr-value-assertions

指定した属性名と属性値のペアを持つエントリ (attrName#attrValue )

次の設定では、タイプ inetorgperson のエントリを非表示にする検索データ非表示ルールを定義します。
$ dpconf set-search-data-hiding-rule-prop -h host1 -p port my-policy my-rule \ target-attr-value-assertions:objectclass#inetorgperson

要求フィルタリングポリシーと検索データ非表示ルールの例

次の例には、要求フィルタリングポリシーと検索データ非表示ルールが含まれます。要求フィルタリングポリシーを検索データ非表示ルールと組み合わせると、次のようにデータへのアクセスが制限されます。

次のタイプの操作は許可されません。追加、削除、拡張、変更、名前変更。
アクセスできるのは、ou=people,dc=sun,dc=com サブツリーだけです。
検索操作では inetorgperson タイプ以外のエントリが返されます。

例 26–1 要求フィルタリングポリシーの例

allow-add-operations                :  false
allow-bind-operations               :  true
allow-compare-operations            :  true
allow-delete-operations             :  false
allow-extended-operations           :  false
allow-inequality-search-operations  :  true
allow-modify-operations             :  false
allow-rename-operations             :  false
allow-search-operations             :  true
allowed-comparable-attrs            :  all
allowed-search-scopes               :  base
allowed-search-scopes               :  one-level
allowed-search-scopes               :  subtree
allowed-subtrees                    :  ou=people,dc=sun,dc=com
description                         :  myRequestFilteringPolicy
prohibited-comparable-attrs         :  none
prohibited-subtrees                 :  none

例 26–2 検索データ非表示ルールの例

attrs                              :  -
rule-action                        :  hide-entry
target-attr-value-assertions       :  objectclass:inetorgperson
target-dn-regular-expressions      :  -
target-dns                         :  -

リソース制限ポリシーの作成と設定

リソース制限ポリシーの概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Resource Limits Policies for Connection Handlers」を参照してください。リソース制限ポリシーを作成する方法と検索制限をカスタマイズする方法については、次の手順を参照してください。

リソース制限ポリシーを作成する

リソース制限ポリシーを作成します。
$ dpconf create-resource-limits-policy -h host -p port policy-name
リソース制限ポリシーのプロパティーを変更する方法については、「リソース制限ポリシーを設定する」を参照してください。

リソース制限ポリシーを接続ハンドラに関連付けます。

$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \
 resource-limits-policy:policy-name

リソース制限ポリシーを設定する

リソース制限ポリシーのプロパティーを表示します。

$ dpconf get-resource-limits-policy-prop -h host -p port policy-name

リソース制限ポリシーのデフォルトプロパティーは次のとおりです。

description                                 :  -
max-client-connections                      :  unlimited
max-connections                             :  unlimited
max-simultaneous-operations-per-connection  :  unlimited
max-total-operations-per-connection         :  unlimited
minimum-search-filter-substring-length      :  unlimited
referral-bind-policy                        :  default
referral-hop-limit                          :  default
referral-policy                             :  default
search-size-limit                           :  unlimited
search-time-limit                           :  unlimited

手順 1 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、リソース制限ポリシーを設定します。
$ dpconf set-resource-limits-policy-prop -h host -p port policy-name \ property:value [property:value ...]

検索制限をカスタマイズする

検索ベースと検索範囲に従って行われる検索操作に対して、カスタマイズした検索制限を定義することができます。検索操作のターゲット DN と範囲が指定した条件と一致すると、検索結果で返されるエントリの数が制限されます。

1 つまたは複数のカスタムの検索制限を作成します。

$ dpconf create-custom-search-size-limit -h host -p port policy-name \
  custom-search-limit-name [custom-search-limit-name ...]

カスタムの検索制限に対する条件を設定します。

$ dpconf set-custom-search-size-limit-prop -h host -p port policy-name \
  custom-search-limit-name one-level-search-base-dn:value subtree-search-base-dn:value

手順 2 で検索が条件の 1 つを満たす場合に返される結果の数の制限を設定します。

$ dpconf set-custom-search-size-limit-prop -h host -p port policy-name \
 custom-search-limit-name search-size-limit:value

カスタムの検索制限のプロパティーを表示します。

$ dpconf get-custom-search-size-limit-prop -h host -p port policy-name \
  custom-search-limit-name

カスタムの検索制限のデフォルトプロパティーは、次のとおりです。

one-level-search-base-dn  :  -
search-size-limit         :  unlimited
subtree-search-base-dn    :  -

接続ベースのルーターとしての Directory Proxy Server の設定

Directory Proxy Server 5.2 は接続ベースのルーターです。Directory Proxy Server 5.2 では、クライアント接続は特定のディレクトリサーバーに経路指定されます。そのクライアント接続のすべての要求は、接続が切断されるかクライアントがアンバインドされるまでは、同じディレクトリサーバーに送信されます。

Directory Proxy Server 6.3 は、操作ベースのルーターです。ただし、互換性のため、このバージョンの Directory Proxy Server は、次の手順で説明するように接続ベースのルーターとして設定できます。

Directory Proxy Server を接続ベースのルーターとして設定する

「接続ハンドラの作成、設定、削除」で説明するように、1 つまたは複数の接続ハンドラを作成し、設定します。

デフォルトの接続ハンドラを使用することもできます。

要求を root data view のみに経路指定するように、すべての接続ハンドラを設定します。

次に例を示します。

$ dpconf set-connection-handler-prop -h host1 -p 1389 myConnectionHandler \
 data-view-routing-policy:custom data-view-routing-custom-list:"root data view"

「LDAP データソースの作成と設定」で説明するように、各バックエンド LDAP サーバーのデータソースを作成し設定します。

次に例を示します。
$ dpconf create-ldap-data-source -h host1 -p 1389 myDataSource host2:2389

「LDAP データソースプールの作成と設定」で説明するように、データソースプールを作成し設定します。

次に例を示します。
$ dpconf create-ldap-data-source-pool -h host1 -p 1389 myDataSourcePool

「LDAP データソースのデータソースプールへの接続」で説明するように、すべてのデータソースをデータソースプールに接続します。

次に例を示します。
$ dpconf attach-ldap-data-source -h host1 -p 1389 myDataSourcePool myDataSource

「バインド再実行での要求の転送」で説明するように、BIND 再実行を使用してクライアントを認証するように各データソースを設定します。

次に例を示します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 myDataSource \ client-cred-mode:use-client-identity

「クライアントアフィニティーの設定」で説明するように、クライアント接続とデータソースプール間のアフィニティーを設定します。

次に例を示します。
$ dpconf set-ldap-data-source-pool-prop -h host1 -p 1389 myDataSourcePool \ enable-client-affinity:true client-affinity-policy:read-write-affinity-after-write

第 27 章 Directory Proxy Server のクライアント認証

Directory Proxy Server のクライアント認証の概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 21 章「Directory Proxy Server Client Authentication」を参照してください。

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

クライアントと Directory Proxy Server 間のリスナーの設定

Directory Proxy Server には、クライアントとの通信のために、セキュリティー保護されたリスナーとセキュリティー保護されていないリスナーがあります。Directory Proxy Server のリスナーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Client Listeners」を参照してください。ここでは、リスナーの設定方法について説明します。

クライアントと Directory Proxy Server 間のリスナーを設定する

注 –

この手順では、クライアントと Directory Proxy Server 間のセキュリティー保護されていないリスナーを設定します。セキュリティーが確保されているリスナーを設定するには、手順は同じですが、ldap を ldaps に置き換えます。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。 DSCC では、このプロパティーを「パフォーマンス」タブで設定できます。

セキュリティー保護されていないリスナーのプロパティーを表示します。

$ dpconf get-ldap-listener-prop -h host -p port

セキュリティー保護されていないリスナーのデフォルトプロパティーは、次のとおりです。

connection-idle-timeout          :  1h
connection-read-data-timeout     :  2s
connection-write-data-timeout    :  1h
is-enabled                       :  true
listen-address                   :  0.0.0.0
listen-port                      :  port-number
max-connection-queue-size        :  128
max-ldap-message-size            :  unlimited
number-of-threads                :  2
use-tcp-no-delay                 :  true

手順 1に一覧表示されているプロパティーの 1 つまたは複数を要件に応じて変更します。
$ dpconf set-ldap-listener-prop -h host -p port property:new-value
たとえば、host1 で実行されている Directory Proxy Server のインスタンスのセキュリティー保護されていないポートを無効にするには、次のコマンドを実行します。
$ dpconf set-ldap-listener-prop -h host1 -p 1389 is-enabled:false
注意 –
非特権ポート番号を使用する場合は、Directory Proxy Server を root として実行する必要があります。

セキュリティー保護されていないポート番号を変更するには、次のコマンドを実行します。
$ dpconf set-ldap-listener-prop -h host -p port listen-port:new-port-number

必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。

特定のリスナープロパティーの変更には、サーバーの再起動が必要です。サーバーの再起動が必要な場合は、dpconf アラートが表示されます。Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。

Directory Proxy Server に対するクライアントの認証

デフォルトでは、Directory Proxy Server は単純バインド認証用に設定されています。単純バインド認証では、追加の設定は必要ありません。

クライアントと Directory Proxy Server 間の認証については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Client Authentication Overview」を参照してください。認証の設定方法については、次の手順を参照してください。

証明書ベースの認証を設定する

クライアントの証明書ベースの認証については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Configuring Certificates in Directory Proxy Server」を参照してください。この節では、証明書ベースの認証の設定方法について説明します。

注 –

証明書ベースの認証は、SSL 接続でのみ実行できます。

クライアントが SSL 接続を確立する場合に証明書の提示を必要とするように Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port allow-cert-based-auth:require

匿名アクセスを設定する

匿名アクセスについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Anonymous Access」を参照してください。匿名クライアントのアイデンティティーを別のアイデンティティーにマップする方法については、「代替ユーザーとしての要求の転送」を参照してください。

非認証ユーザーに操作の実行を許可します。

$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:true

SASL 外部バインド用に Directory Proxy Server を設定する

SASL 外部バインドについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Using SASL External Bind」を参照してください。

非認証操作を禁止します。

$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:false

接続の確立時に証明書を提示するようクライアントに求めます。
$ dpconf set-server-prop -h host -p port allow-cert-based-auth:require
クライアントが DN が含まれた証明書を提供します。

SASL 外部バインドによってクライアントの認証を有効にします。
$ dpconf set-server-prop -h host -p port allow-sasl-external-authentication:true

バックエンド LDAP サーバーでクライアント証明書をマップするために Directory Proxy Server に使用されアイデンティティーを設定します。
$ dpconf set-server-prop -h host -p port cert-search-bind-dn:bind-DN \ cert-search-bind-pwd-file:filename

Directory Proxy Server が検索するサブツリーのベース DN を設定します。

Directory Proxy Server がサブツリーを検索し、クライアント証明書にマップされたユーザーエントリを見つけます。
$ dpconf set-server-prop -h host -p port cert-search-base-dn:base-DN

クライアント証明書の情報を LDAP サーバー上の証明書にマップします。
1. 証明書を含む LDAP サーバー上の属性に名前を付けます。
  $ dpconf set-server-prop cert-search-user-attribute:attribute
2. クライアント証明書上の属性を、証明書のある LDAP サーバー上のエントリの DN にマップします。
  $ dpconf set-server-prop -h host -p port \ cert-search-attr-mappings:client-side-attribute-name:server-side-attribute-name
  たとえば、DN が cn=user1,o=sun,c=us のクライアント証明書を DN が uid=user1,o=sun の LDAP エントリにマップするには、次のコマンドを実行します。
  $ dpconf set-server-prop -h host1 -p 1389 cert-search-attr-mappings:cn:uid \ cert-search-attr-mappings:o:o

(省略可能) SASL 外部バインド操作の要求をすべてのデータビューまたはデータビューのカスタムリストに経路指定します。
- すべてのデータビューに要求を経路指定するには、次のコマンドを実行します。
  $ dpconf set-server-prop -h host -p port cert-data-view-routing-policy:all-routable
- データビューのリストに要求を経路指定するには、次のコマンドを実行します。
$ dpconf set-server-prop -h host -p port cert-data-view-routing-policy:custom \ cert-data-view-routing-custom-list:view-name [view-name...]

第 28 章 Directory Proxy Server のログ

Directory Proxy Server では、アクセスログおよびエラーログに情報が記録されます。Directory Server とは異なり、Directory Proxy Server には監査ログはありません。Directory Proxy Server のログについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 23 章「Directory Proxy Server Logging」を参照してください。

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

Directory Proxy Server ログの表示

Directory Proxy Server のログは、ログファイルを直接表示するか、Directory Service Control Center (DSCC) を通して参照できます。

デフォルトでは、ログは次のディレクトリ内に格納されます。

instance-path/logs

次の図は、DSCC 上の Directory Proxy Server のエラーログの画面キャプチャーです。

図 28–1 Directory Proxy Server のエラーログウィンドウ

画面キャプチャーは、Directory Proxy Server のエラーログを示しています。エラーログエントリは表に一覧表示されています。

Directory Proxy Server のログの設定

Directory Proxy Server のエラーログとアクセスログは、dpconf コマンドまたは DSCC を使用することで設定できます。DSCC によるログの設定方法については、Directory Proxy Server のオンラインヘルプを参照してください。この節では、dpconf コマンドを使用して Directory Proxy Server のログを設定する方法について説明します。

次のコマンドを実行することで、設定オプションのリストを、個々のオプションで設定可能な値およびデフォルトの設定値の情報とともに取得できます。

$ dpconf help-properties error-log

$ dpconf help-properties access-log

Directory Proxy Server のアクセスログとエラーログを設定する

この手順では、Directory Proxy Server のアクセスログを設定します。Directory Proxy Server のエラーログを設定する場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。

アクセスログのプロパティーを表示します。

$ dpconf get-access-log-prop -h host -p port

アクセスログのデフォルトプロパティーは、次のとおりです。

default-log-level                :  info
enable-log-rotation				  :  true
log-buffer-size                  :  9.8k
log-file-name                    :  logs/access
log-file-perm                    :  600
log-level-client-connections     :  -
log-level-client-disconnections  :  -
log-level-client-operations      :  -
log-level-connection-handlers    :  -
log-level-data-sources           :  -
log-level-data-sources-detailed  :  -
log-min-size						  :  100M
log-rotation-frequency           :  1h
log-rotation-policy              :  size
log-rotation-size                :  100M
log-rotation-start-day           :  1
log-rotation-start-time          :  0000
log-search-filters               :  false
max-age                          :  unlimited
max-log-files                    :  10
max-size                         :  unlimited
min-free-disk-space-size         :  1M

手順 1 で一覧表示されるプロパティーのうち、1 つまたは複数を変更します。
$ dpconf set-access-log-prop -h host -p port property:value \ [property:value ...]
たとえば、すべてのメッセージカテゴリのデフォルトのログレベルを warning に設定するには、default-log-level プロパティーの値を warning に設定します。
$ dpconf set-access-log-prop -h host1 -p 1389 default-log-level:warning
すべてのログを無効にするには、各メッセージカテゴリのログレベルに関係なく、default-log-level プロパティーの値を none に設定します。
$ dpconf set-access-log-prop -h host1 -p 1389 default-log-level:none
特定のログレベルをデフォルトのログレベルにリセットするには、該当のログレベルのプロパティーを inherited に設定します。たとえば、クライアント接続のログレベルをリセットするには、次のコマンドを実行します。
$ dpconf set-access-log-prop -h host1 -p 1389 log-level-client-connections:inherited
set-access-log-prop サブコマンドで設定できるプロパティーを調べるには、次のように入力します。
$ dpconf help-properties access-log

Directory Proxy Server ログのローテーションの設定

デフォルトでは、ログファイルのサイズが 100M バイトに達すると、ログファイルのローテーションが行われます。デフォルトでは 10 個のログファイルが保存され、それ以降はローテーション手順によってもっとも古いログファイルの上書きが始められます。この節では、Directory Proxy Server ログを予定されたローテーションに対して設定する方法、ログのローテーションを手動で行う方法、ログのローテーションを無効にする方法について説明します。設定例は、「ログローテーションの設定例」を参照してください。

アクセスログとエラーログの定期ローテーションを設定する

(省略可能) アクセスログのプロパティーを表示します。
$ dpconf get-access-log-prop -h host -p port

(省略可能) アクセスログのプロパティーに対して有効な値を表示します。
```
$ dpconf help-properties access-log
```

一定のサイズに達するとログのローテーションが行われるようにするには、次のプロパティーを設定します。
$ dpconf set-access-log-prop -h host -p port \ log-rotation-policy:size log-rotation-size:maximum file size
最大ファイルサイズの単位を指定しない場合、デフォルトの単位である「バイト」が使用されます。ログファイルが定義されたサイズに達すると、ログのローテーションが行われます。ファイルサイズは、少なくとも 1M バイトにし、2G バイトを超えないようにする必要があります。

サイズによるログのローテーションの例については、「ログサイズに基づくログのローテーション」を参照してください。

ログのローテーションを定期的に行うには、ログサイズに関係なく、次のプロパティーを設定します。

$ dpconf set-access-log-prop -h host -p port \
 log-rotation-frequency:interval in months, weeks, hours, or minutes \
 log-rotation-policy:periodic \
 log-rotation-start-day:day in week (1-7) or day in the month (1-31) \
 log-rotation-start-time:time of day (hhmm)

ログのローテーションが月の 31 日に行われるように設定すると、その月の日数が 31 日より短い場合、ログのローテーションは次の月の最初の日に行われます。

定期的なログのローテーションの例については、「時間に基づくログのローテーション」を参照してください。

ログファイルが十分に大きくなったときに定期的なログのローテーションを行うには、log-rotation-frequency プロパティーと log-min-size プロパティーを設定します。

$ dpconf set-access-log-prop -h host -p port \
 log-rotation-frequency:interval in months, weeks, hours, or minutes \
 log-rotation-policy:periodic log-min-size:minimum file size
 log-rotation-start-day:day in week (1-7) or day in the month (1-31) \
 log-rotation-start-time:time of day (hhmm)

log-min-size プロパティーは、ログの最小サイズを示します。ローテーションは、ログファイルが指定したサイズより大きくなった場合のみ、予定された時間に実行されます。

ファイルサイズが十分に大きくなったときに定期的にログのローテーションを行う方法の例については、「時間とログサイズに基づくログのローテーション」を参照してください。

アクセスログとエラーログのファイルのローテーションを手動で行う

この手順では、Directory Proxy Server のアクセスログのローテーションを行います。Directory Proxy Server のエラーログのローテーションを行う場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。

アクセスログのローテーションを行います。
$ dpconf rotate-log-now -h host -p port access

アクセスログとエラーログのローテーションを無効にする

この手順では、Directory Proxy Server のアクセスログのローテーションを無効にします。Directory Proxy Server のエラーログのローテーションを無効にする場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。

ログファイルのローテーションを無効にします。

$ dpconf set-access-log-prop -h host -p port enable-log-rotation:false

ログローテーションの設定例

ログサイズ、時間、またはその両方によってログのローテーションを設定する方法の例は、次のとおりです。

ログサイズに基づくログのローテーション

この節では、ログサイズだけに従ってログのローテーションを設定する方法の例を示します。次の設定では、最後にログのローテーションが行われてから経過した時間に関係なく、ログが 10M バイトに達したときにローテーションが行われます。

$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-policy:size \
  log-rotation-size:10M

時間に基づくログのローテーション

この節で示す例では、ログサイズに関係なく、最後のローテーションからの経過時間に従ってログローテーションを設定する方法を示します。

次の設定では、ログのローテーションは今日の 3:00 とそれ以降の 8 時間ごとに行われ、ログファイルのサイズとは無関係です。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:8h \ log-rotation-policy:periodic log-rotation-start-time:0300
次の設定では、ログファイルのサイズとは無関係に、毎日 3:00、13:00、23:00 にログのローテーションが行われます。log-rotation-start-time パラメータは log-rotation-frequency パラメータに優先するため、ログのローテーションは 23:00 に行われると、次回は 10 時間後ではなく、4 時間後の 3:00 に行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:10h \ log-rotation-policy:periodic log-rotation-start-time:0300
次の設定では、ログのローテーションは月曜日の正午に行われ、そのあと毎週同じ時間に行われ、ログファイルのサイズとは無関係です。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:1w \ log-rotation-policy:periodic log-rotation-start-day:2 log-rotation-start-time:1200
次の設定では、ログファイルのサイズとは無関係に、月曜日の正午に最初のログのローテーションが行われ、それ以降は、3 日おきに正午にローテーションが行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:3d \ log-rotation-policy:periodic log-rotation-start-day:2 log-rotation-start-time:1200
ログのローテーションが行われる曜日は、月曜日、木曜日、日曜日、水曜日というように続きます。log-rotation-start-day パラメータは最初の週だけに適用されます。2 週目の月曜日にはログのローテーションは行われません。

次の設定では、ログサイズとは無関係に、毎月 22 日の正午にログのローテーションが行われます。

$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:1m \
 log-rotation-policy:periodic log-rotation-start-day:22 \
 log-rotation-start-time:1200

log-rotation-start-day を 31 に設定したときに、30 日しかない月の場合、ログのローテーションは次の月の最初の日に行われます。log-rotation-start-day を 31 に設定したときに、28 日しかない月 (2 月) の場合、ログのローテーションは 3 日に行われます。

時間とログサイズに基づくログのローテーション

この例では、ファイルサイズが十分に大きくなった場合の、指定した間隔でのログのローテーションの設定方法を示します。

次の設定では、ログファイルのサイズが 1M バイトを超えた場合に、毎日 3:00、11:00、19:00 にログのローテーションが行われます。ログファイルのサイズが 1M バイトを超えなければ、ログファイルのローテーションは行われません。

$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:8h \
 log-rotation-policy:periodic log-min-size:1M log-rotation-start-time:0300

Directory Proxy Server ログの削除

Directory Proxy Server では、時間、サイズ、またはディスクの空き容量 (デフォルト) に基づいたログの削除を設定できます。これらの削除ポリシーの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Log File Deletion」を参照してください。

次の手順では、アクセスログのログの削除を設定します。エラーログのログの削除を設定するときも同じコマンドを使います。ただし、 access を error に置き換えます。

時間に基づいたアクセスログとエラーログの削除を設定する

ログファイルの最長有効期間を指定します。
$ dpconf set-access-log-prop -h host -p port max-age:duration
ここで、duration には、日( d)、週 (w)、または月 (M) の単位を指定します。たとえば、5 日前より古いバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 max-age:5d

ファイルサイズに基づいたアクセスログとエラーログの削除を設定する

ログファイルの最大サイズを指定します。
$ dpconf set-access-log-prop -h host -p port max-size:memory-size
たとえば、1M バイトより大きいバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 max-size:1M

ディスクの空き容量に基づいたアクセスログとエラーログの削除を設定する

使用可能な最小ディスク容量を指定します。
$ dpconf set-access-log-prop -h host -p port min-free-disk-space-size:memory-size
たとえば、使用可能なディスク容量が 2M バイトより少なくなったときにバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 min-free-disk-space-size:2M

`syslogd` デーモンに対するアラートのログ

この節では、syslogd デーモンに対するアラートメッセージのログを設定する方法と、syslog アラートを受け付けるようにオペレーティングシステムを設定する方法について説明します。

`syslogd` デーモンに対するアラートをログに記録するように Directory Proxy Server を設定する

(省略可能) システムログアラートのプロパティーの現在の値を表示します。
$ dpconf get-server-prop -h host -p port syslog-alerts-enabled \ syslog-alerts-facility syslog-alerts-host
システムログアラートのデフォルトプロパティーは、次のとおりです。
syslog-alerts-enabled : false syslog-alerts-facility : USER syslog-alerts-host : localhost
syslog-alerts-host プロパティーは、メッセージの送信先である syslogd デーモンのホスト名を定義します。syslog-alerts-facility プロパティーは読み取り専用であり、メッセージをシステムログ内の user カテゴリに送信します。

syslogd デーモンにアラートメッセージのログを記録できるようにします。
$ dpconf set-server-prop -h host -p port syslog-alerts-enabled:true

(省略可能) アラートメッセージを別のホスト上の syslogd デーモンに送信します。
$ dpconf set-server-prop -h host -p port syslog-alerts-host:hostname

`syslog` アラートを受け付けるオペレーティングシステムの設定

この節では、syslog アラートを受け付けるように Solaris^TM、Linux、および HP-UX オペレーティングシステムを設定する手順を示します。

`syslog` アラートを受け付けるように Solaris OS を設定する

適切な機能を syslog 設定ファイルに追加します。

たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
```
user.info       /var/adm/info
```
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。

syslogd デーモンを再起動します。
1. Solaris 8 および 9 の場合は、次のように入力して syslogd を再起動します。
```
$ /etc/init.d/syslog stop | start
```
2. Solaris 10 の場合は、次のように入力して syslogd を再起動します。
```
$ svcadm restart system/system-log
```

メッセージが syslog に記録されることを確認します。

$ logger -p user.info "Test message"
$ cat /var/adm/info
 Jun 19 17:18:38 host user: [ID 12345 user.info] Test message

`syslog` アラートを受け付けるように Linux を設定する

適切な機能を syslog 設定ファイルに追加します。

たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
```
user.info       /var/adm/info
```
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。

- r オプションを指定して実行するように、syslogd デーモンを設定します。

このオプションを使えば、syslogd でネットワークからの接続を受け付け可能になります。デフォルトでは、-r オプションは設定されていません。

-r オプションを設定するには、/etc/sysconfig/syslog に次の行を追加します。
```
SYSLOGD_OPTIONS="-m 0 -r"
```
/etc/sysconfig/syslog が存在しない場合は、同じ行を /etc/init.d/syslog に追加します。

syslogd デーモンを再起動します。
```
$ /etc/init.d/syslog stop | start
```

メッセージが syslog に記録されることを確認します。

$ logger -p user.info "Test message"
$ cat /var/adm/info
 Jun 19 17:18:38 host user: [ID 12345 user.info] Test message

`syslog` アラートを受け付けるように HP-UX を設定する

適切な機能を syslog 設定ファイルに追加します。

たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
```
user.info       /var/adm/info
```
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。

syslogd デーモンを再起動します。
```
$ /sbin/init.d/syslogd stop | start
```

メッセージが syslog に記録されることを確認します。

$ logger -p user.info "Test message"
$ cat /var/adm/info
 Jun 19 17:18:38 host user: [ID 12345 user.info] Test message

Directory Proxy Server および Directory Server のアクセスログによるクライアント要求の追跡

クライアント要求のパスを追跡するには、要求が Directory Proxy Server のアクセスログと Directory Server のアクセスログに記録される方法を理解する必要があります。この節の内容を理解するには、最初に『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Tracking Client Requests Through Directory Proxy Server and Directory Server Access Logs」をお読みください。

Directory Proxy Server から Directory Server を経由したクライアントアプリケーションへの操作を追跡する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

Directory Server のアクセスログ内で追跡する操作の接続番号を見つけます。

たとえば、アクセスログ内の次の行は、接続番号が conn=12839 である op=2 という操作を示します。
[20/Jul/2006:18:01:49 -0500] conn=12839 op=2 msgId=4 - SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=organizationalunit)" attrs=ALL

その接続についての Directory Proxy Server の接続情報を入手します。

この情報を入手するには、Directory Server のアクセスログを検索して、対応する接続番号を持つすべての操作を見つけます。たとえば、UNIX システムの場合、次のような grep コマンドを実行して、Directory Server のアクセスログ内の接続 conn=12839 に対応するすべての行を見つけます。
$ grep conn=12839 access
最初の LDAP 接続を示す行が探している行であり、次のようになります。
[19/Jul/2006:16:32:51 -0500] conn=12839 op=-1 msgId=-1 - fd=27 slot=27 LDAP connection from 129.153.160.175:57153 to 129.153.160.175
前述の行は、129.153.160.175:57153 から Directory Server への LDAP 接続があることを示しています。ポート番号 (57153) は、Directory Proxy Server のアクセスログで接続情報を調べる際に必要となります。このポート番号を使って、Directory Proxy Server のログ内で対応する接続を見つけることができ、この接続からクライアント情報を見つけることができます。

接続が最初に確立されてからログファイルのローテーションが行われている場合は、アーカイブされたログファイルと現在のアクセスログファイルを検索する必要があります。

Directory Proxy Server のアクセスログ内で対応する接続を見つけます。

この情報を入手するには、Directory Proxy Server のアクセスログを検索して、対応するポート番号を持つすべての操作を見つけます。

ログファイル内で、同じポート番号を持つ複数のエントリが見つかることがあります。正しいエントリを確実に見つけるには、Directory Server のログを検索したときに見つかったエントリに記載されていたタイムスタンプも条件に含めて検索します。

たとえば、UNIX システムでは、次のように grep コマンドを実行して、Directory Server のログで見つけたエントリのタイムスタンプおよびポート番号に対応する接続エントリを見つけます。
$ grep 19/Jul/2006:16:32 access | grep 57153
サーバー間でのわずかな時間のずれを考慮に入れて、検索条件にタイムスタンプを含めるときには、秒の値は除きます。

Directory Proxy Server のログ内の対応する行は、次のようになります。
[19/Jul/2006:16:32:51 -0500] - SERVER_OP - INFO - Created BIND LDAP connection s_conn=sunds-d1m1-9389:34 client=0.0.0.0:57153 server=idm160.central.sun.com:9389 main
この行は、Directory Proxy Server で s_conn=sunds-d1m1-9389:34 への BIND 接続が作成されたことを示します。Directory Proxy Server は、自分自身を TCP ポート 57153 上のクライアント client=0.0.0.0 として識別します。

ログのこの行から得られる重要な情報は、サーバー ID とポート番号 (s_conn=sunds-d1m1-9389:34 ) です。

前述の手順で識別されたサーバー ID とポート番号に対応するすべての操作を見つけます。

この情報を入手するには、Directory Proxy Server のアクセスログで、対応するサーバー ID とポート番号を持つすべての操作をを検索します。

たとえば、UNIX システムでは、次のような grep コマンドを実行して、前述の手順で見つけたサーバー ID に対応する操作を見つけます。

$ grep s_conn=sunds-d1m1-9389:34 access

この例では、関連する操作が数日にまたがっている可能性があるため、タイムスタンプを用いた検索は有効ではないかもしれません。ただし、検索によって返される操作が正しいものであることを確認する必要があります。複数の Create 接続ステートメントがある場合は、必ず、Directory Server のログで見つけた Create 接続ステートメントと合致するものを見つけてください。そのためには、手順 1 で見つかったエントリのタイムスタンプと同じタイムスタンプのエントリを見つけます。

Directory Proxy Server のアクセスログの次の抜粋は、s_conn=sunds-d1m1-9389:34 に対して返されたすべての操作を示します。

[19/Jul/2006:16:32:51 -0500] - SERVER_OP  - INFO - Created BIND LDAP connection
 s_conn=sunds-d1m1-9389:34 client=0.0.0.0:57153 server=idm160.central.sun.com:9389 main
[20/Jul/2006:18:01:49 -0500] - SERVER_OP  - INFO  - conn=31 op=0 BIND dn="cn=directory manager"
 method="SIMPLE" s_msgid=3 s_conn=sunds-d1m1-9389:34
[20/Jul/2006:18:01:49 -0500] - SERVER_OP  - INFO  - conn=31 op=0 BIND RESPONSE err=0 msg=""
 s_conn=sunds-d1m1-9389:34
[20/Jul/2006:18:01:49 -0500] - SERVER_OP  - INFO  - conn=31 op=1 SEARCH base="dc=example,dc=com"
 scope=2 s_msgid=4 s_conn=sunds-d1m1-9389:34
[20/Jul/2006:18:01:49 -0500] - SERVER_OP  - INFO  - conn=31 op=1 SEARCH RESPONSE err=0 msg=""
 nentries=1 s_conn=sunds-d1m1-9389:34

この情報により、Directory Proxy Server のこの検索操作に対する接続 ID が 31 (conn=31) であることがわかります。

前述の手順で見つかった接続 ID に対応する、クライアント接続 IP アドレスを見つけます。

この情報を入手するには、Directory Proxy Server のアクセスログで、正しい接続 ID とタイムスタンプを持つすべての操作を検索します。検索時には、手順 1 で検索したステートメントのタイムスタンプを使用します。

たとえば、UNIX システムでは、次のような grep コマンドを実行して、クライアント接続 IP アドレスを見つけます。
$ grep "20/Jul/2006:18:01" access | grep conn=31
目的の行は次のようになります。
[20/Jul/2006:18:01:49 -0500] - CONNECT - INFO - conn=31 client=129.150.64.156:2031 server=0.0.0.0:11389 protocol=LDAP

前述の手順で見つかった IP アドレスの所有者を確認します。

この情報により、Directory Server 上で行われた操作をだれが担当したかを、正確に証明できます。

第 29 章 Directory Proxy Server の監視とアラート

監視により、Directory Proxy Server とデータソースの障害が検出されます。

Directory Proxy Server の監視フレームワークの詳細と、cn=monitor エントリの詳細なレイアウトについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Monitoring Directory Proxy Server」を参照してください。この章の内容は次のとおりです。

Directory Proxy Server に関する監視データの取得

Directory Proxy Server に関する監視データを取得するには、cn=monitor エントリを使用します。このエントリは、Directory Proxy Server によって、ローカルのメモリー内データベース内で管理されます。cn=monitor エントリで LDAP 検索を実行することで、cn=monitor の下にある属性を取得できます。このエントリを検索するには、Proxy Manager としてバインドする必要があります。

監視データを取得するための JVM の使用については、「JVM による Directory Proxy Server についての監視データの取得」を参照してください。

データソースに関する監視データの取得

Directory Proxy Server でデータソースの健全性を監視する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Monitoring Data Sources」を参照してください。この節では、データソースの監視を設定する方法について説明します。

エラーを待機することでデータソースを監視する

このタイプの監視では、Directory Proxy Server は、Directory Proxy Server とデータソース間のトラフィックのエラーを待機します。このタイプの監視をリアクティブな監視といいます。これは、Directory Proxy Server が、エラーが検出されると反応を示しますが、データソースを積極的にはテストしないためです。

データソースの監視モードを reactive に設定します。

$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:reactive

「Directory Proxy Server に対する管理アラートの設定」で説明するように、エラーが検出された場合、またはデータソースがオフラインまたはオンラインになる場合に送信されるアラートを設定します。

専用接続を定期的に確立することでデータソースを監視する

Directory Proxy Server では、指定した時間内にデータソースへの要求やデータソースからの応答がなかった場合、データソースへの専用接続が作成されます。

データソースの監視モードを proactive に設定します。

$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:proactive

Directory Proxy Server で実行する、監視する検索要求を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource \ monitoring-bind-timeout:timeout monitoring-entry-dn:dn \ monitoring-search-filter:filter monitoring-entry-timeout:timeout
検索要求では次のプロパティーが使用されます。

monitoring-bind-timeout

Directory Proxy Server がデータソースへの接続の確立を待機する時間の長さ。デフォルトでは、このプロパティーの値は 5 秒です。

monitoring-entry-dn

検索要求にあるターゲットエントリの DN。デフォルトでは、このプロパティーはルート DSE エントリ ("") です。

monitoring-search-filter

検索フィルタ。

monitoring-entry-timeout

Directory Proxy Server が検索応答を待機する時間の長さ。デフォルトでは、このプロパティーの値は 5 秒です。

(省略可能) 予防保守の監視を設定し、特定のユーザーとしてバインドします。
$ dpconf set-ldap-data-source-prop ldap-data-source \ monitoring-bind-dn:uid=user-id monitoring-bind-pwd-file:password-file
user-id を uid=bjensen,dc=example,dc=com などの有効な dn で、password-file をパスワードを含むファイルのパスで置き換えます。

デフォルトでは、バインドは匿名として実行されます。つまり、monitoring-bind-dn 属性と monitoring-bind-pwd 属性の両方とも none に設定されます。

ポーリング間隔を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-interval:interval
接続がダウンすると、Directory Proxy Server が、その復旧を検出するために、この間隔で接続をポーリングします。デフォルトでは、監視間隔は 30 秒です。

「Directory Proxy Server に対する管理アラートの設定」で説明するように、データベースがオフラインまたはオンラインとして検出された場合に送信されるアラートを設定します。

確立された接続をテストすることでデータソースを監視する

このタイプの監視では、Directory Proxy Server は、各データソースへの各接続で、定期的な間隔で検索を行います。このようにして Directory Proxy Server では、閉じた接続が検出され、停止しているために接続がドロップすることがないようにします。

データソースの監視モードを proactive に設定します。

$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:proactive

接続がドロップすることがないように Directory Proxy Server からデータソースに要求を送信するまでの時間間隔を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource \ monitoring-inactivity-timeout:time
デフォルトでは、非活動タイムアウトは 120 秒です。

(省略可能) 予防保守の監視を設定し、特定のユーザーとしてバインドします。
$ dpconf set-ldap-data-source-prop ldap-data-source monitoring-bind-dn:uid=user-id monitoring-bind-pwd-file:password-file
user-id を uid=bjensen,dc=example,dc=com などの有効な dn で、password-file をパスワードを含むファイルのパスで置き換えます。

デフォルトでは、バインドは匿名として実行されます。つまり、monitoring-bind-dn 属性と monitoring-bind-pwd 属性の両方とも none に設定されます。

「Directory Proxy Server に対する管理アラートの設定」で説明するように、データベースがオフラインまたはオンラインとして検出された場合に送信されるアラートを設定します。

Directory Proxy Server に対する管理アラートの設定

管理アラートの設定方法については、次の手順を参照してください。

管理アラートを有効にする

有効になっているアラートを表示します。

% dpconf get-server-prop -h host -p port enabled-admin-alerts

1 つまたは複数の管理アラートを有効にします。

% dpconf set-server-prop -h host -p port enabled-admin-alerts:alert1 \
  [enabled-admin-alerts:alert2 ...]

たとえば、使用可能なすべてのアラートを有効にするには、次のコマンドを実行します。

% dpconf set-server-prop -h host -p port \
 enabled-admin-alerts:error-configuration-reload-failure-with-impact \
 enabled-admin-alerts:error-server-shutdown-abrupt \ 
 enabled-admin-alerts:info-configuration-reload \
 enabled-admin-alerts:info-data-source-available \
 enabled-admin-alerts:info-server-shutdown-clean \
 enabled-admin-alerts:info-server-startup \
 enabled-admin-alerts:warning-configuration-reload-failure-no-impact \
 enabled-admin-alerts:warning-data-source-unavailable \
 enabled-admin-alerts:warning-data-sources-inconsistent \
 enabled-admin-alerts:warning-listener-unavailable

すべてのアラートを無効にするには、次のコマンドを実行します。

% dpconf set-server-prop -h host -p port enabled-admin-alerts:none

有効なアラートの既存リストにアラートを追加するには、次のコマンドを実行します。

% dpconf set-server-prop -h host -p port enabled-admin-alerts+:alert-name

有効なアラートの既存リストからアラートを削除するには、次のコマンドを実行します。

% dpconf set-server-prop -h host -p port enabled-admin-alerts-:alert-name

デフォルトでは、有効なアラートはありません。

参照

詳細は、enabled-admin-alerts(5dpconf) を参照してください。

Syslog に送信する管理アラートを設定する

「管理アラートを有効にする」で説明するように、syslog デーモンに送信されるアラートを選択します。

syslog デーモンに送信されるアラートを有効にします。
$ dpconf set-server-prop -h host -p port syslog-alerts-enabled:true
すべてのアラートは、USER の機能によって syslog に送信されます。

アラートの送信先である、syslog デーモンのホスト名を設定します。
$ dpconf set-server-prop -h host -p port syslog_hostname:hostname

電子メールに送信する管理アラートを設定する

「管理アラートを有効にする」で説明するように、syslog に送信されるアラートを選択します。

電子メールのアドレスと特性を設定します。

$ dpconf set-server-prop -h host -p port email-alerts-smtp-host:host-name \
  email-alerts-smtp-port:port-number \
  email-alerts-message-from-address:sender-email-address \
  email-alerts-message-to-address:receiver-email-address \
  [email-alerts-message-to-address:receiver-email-address ...] \
  email-alerts-message-subject:email-subject

電子メールに送信されるアラートを有効にします。

$ dpconf set-server-prop -h host -p port email-alerts-enabled:true

(省略可能) 電子メールのなかにアラートコードを組み込むフラグを設定します。
$ dpconf set-server-prop -h host -p port \ email-alerts-message-subject-includes-alert-code:true

スクリプトを実行するように管理アラートを設定する

「管理アラートを有効にする」で説明するように、syslog に送信されるアラートを選択します。

アラートでスクリプトを実行できるようにします。

$ dpconf set-server-prop -h host -p port scriptable-alerts-enabled:true

実行するスクリプトの名前を設定します。

$ dpconf set-server-prop -h host -p port scriptable-alerts-command:script-name

JVM による Directory Proxy Server についての監視データの取得

Directory Proxy Server は Java 仮想マシン (JVM) の内部で実行され、JVM マシンのメモリーに依存します。Directory Proxy Server が確実に正しく実行されるようにするには、JVM マシンのメモリー消費量を監視する必要があります。

JVM マシン用にパラメータを調整する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「Directory Proxy Server のハードウェアサイジング」を参照してください。

デフォルトでは、JVM マシンのヒープサイズは 250M バイトです。Directory Proxy Server に十分な物理メモリーがないと、ヒープサイズが 250M バイトより少なくなることがあります。

Directory Proxy Server が実行中の場合は、JVM マシンのヒープサイズを監視して、メモリー不足にならないようにすることができます。このためには、Java Development Kit (JDK) とともに配布される標準ツールを使用します。これらのツールは、次のディレクトリ内にあります。$JAVA_HOME/bin/jps および $JAVA_HOME/bin/jstat。

JVM のヒープサイズを表示する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

JVM のヒープサイズを表示します。

$ dpadm get-flags instance-path jvm-args
jvm-args: -Xms250M  -Xmx250M

Directory Proxy Server の実行時に JVM のヒープサイズを監視する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

Directory Proxy Server のインスタンスの PID を表示します。
$ jps

JVM マシンで使われるメモリーを表示します。
$ jstat -gcutil PID
- ゼロ列が 100% に近い場合、JVM マシンに十分なメモリーはありません。
- FGC は、フルガベージコレクション (GC) のイベントの数です。ガベージコレクションには膨張性があります。
- GCT (ガベージコレクション時間) は、GC が費やす時間の量です。

Previous: パート I Directory Server の管理

パート II Directory Proxy Server の管理

第 17 章 Directory Proxy Server のツール

Directory Proxy Server を管理するために DSCC を使用する

Directory Proxy Server の管理目的で、DSCC にアクセスする

図 17–1 Directory Proxy Server の最初の DSCC ウィンドウ

Directory Proxy Server のコマンド行ツール

Directory Proxy Server コマンドの場所

dpconf に対する環境変数の設定

dpadm と dpconf の比較

dpconf による複数の値を持つプロパティーの設定

dpadm と dpconf に関するヘルプ情報の表示

第 18 章 Directory Proxy Server のインスタンス

Directory Proxy Server インスタンスの操作

Directory Proxy Server インスタンスを作成する

Directory Proxy Server インスタンスの状況を確認する

Directory Proxy Server を起動および停止する

Directory Proxy Server インスタンスを再起動する必要があるかどうかを確認する

Directory Proxy Server を再起動する

Directory Proxy Server インスタンスを削除する

Directory Proxy Server インスタンスの設定

Directory Proxy Server インスタンスの設定を表示する

Directory Proxy Server の設定を変更する

Proxy Manager の設定

Proxy Manager を設定する

サーバーの再起動を必要とする設定変更

Directory Proxy Server インスタンスのバックアップと復元

Directory Proxy Server インスタンスをバックアップする

Directory Proxy Server インスタンスを復元する

第 19 章 LDAP データビュー

LDAP データビューの作成

LDAP データソースの作成と設定

LDAP データソースを作成する

LDAP データソースを設定する

LDAP データソースプールの作成と設定

LDAP データソースプールを作成する

LDAP データソースプールを設定する

LDAP データソースのデータソースプールへの接続

LDAP データソースをデータソースプールに接続する

LDAP データビューの操作

LDAP データビューを作成する

LDAP データビューを設定する

Directory Proxy Server による Directory Server の設定エントリへのアクセス

Directory Proxy Server を使用して Directory Server の設定エントリにアクセスする

属性と DN の名前の変更

属性の名前の変更を設定する

DN の名前の変更を設定する

ビュー除外ベースおよび代替検索ベースの設定

excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを手動で設定する

データビューの作成と設定に関するユースケースの例

デフォルトデータビュー

要求のターゲット DN にかかわりなく、要求をすべて経路指定するデータビュー

サブツリーの一覧がデータとして等価な複数のデータソースに保存されている場合に要求を経路指定するデータビュー

図 19–1 サブツリーの一覧が複数のデータ同等のデータソースに保存されると要求を経路指定する配備の例

サブツリーの一覧がデータとして等価な複数のデータソースに保存されている場合に要求を経路指定するデータビューを設定する

異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビュー

図 19–2 異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供する配備の例

異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビューを設定する

上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に単一のアクセスポイントを提供するデータビュー

図 19–3 上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に要求を経路指定する配備の例

上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に単一のアクセスポイントを提供するデータビューを設定する

第 20 章 Directory Proxy Server の証明書

デフォルトの自己署名付き証明書

デフォルトの自己署名付き証明書の表示

Directory Proxy Server 用の証明書の作成、要求、インストール

Directory Proxy Server 用のデフォルト以外の自己署名付き証明書を作成する

Directory Proxy Server 用のCA 署名付き証明書を要求する

Directory Proxy Server 用の CA 署名付きサーバー証明書をインストールする

Directory Proxy Server 用の期限切れ CA 署名付き証明書の更新

Directory Proxy Server 用の期限切れ CA 署名付きサーバー証明書を更新する

証明書のリスト

サーバー証明書を一覧表示する

CA 証明書を一覧表示する

バックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースへの証明書の追加

証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する

バックエンド LDAP サーバーへの証明書のエクスポート

クライアント証明書をバックエンド LDAP サーバーにエクスポートするように Directory Proxy Server を設定する

次の手順

参照

Directory Proxy Server 用の証明書データベースのバックアップと復元

証明書データベースにアクセスするためのパスワードの入力要求

`dpconf` に対する環境変数の設定

`dpadm` と `dpconf` の比較

`dpconf` による複数の値を持つプロパティーの設定

`dpadm` と `dpconf` に関するヘルプ情報の表示

`excluded-subtrees` プロパティーと `alternate-search-base-dn` プロパティーを手動で設定する

例 23–1 `is-single-row-table:true` と `contains-shared-entries:true`

例 23–2 `is-single-row-table:true` と `contains-shared-entries:false`

例 23–3 `is-single-row-table:false` と `contains-shared-entries:false`

例 23–4 `is-single-row-table:false` と `contains-shared-entries:true`