第 4 章 Directory Server の設定

この章では、Directory Server の設定方法について説明します。これには dsconf コマンドを使用できます (dsconf(1M) のマニュアルページを参照)。

また、Directory Service Control Center (DSCC) も使用でき、こちらが推奨される方法です。DSCC では、設定プロセスの間に追加のチェックが行われ、これによりエラーを最小限に抑えることができます。さらに、DSCC では、設定をあるサーバーインスタンスから別のサーバーインスタンスにコピーできます。DSCC の使い方の詳細は、DSCC のオンラインヘルプを参照してください。

Directory Server インスタンスの設定の表示

Directory Server インスタンスの設定を表示するには、dsconf info を実行します。

$ dsconf info -h host -p port
インスタンスのパス   :  instance path
グローバルな状態    :  read-write
ホスト名       :  host
ポート            :  port
セキュリティー保護されたポート     :  secure port
エントリ合計数   :  20844

サフィックス        :  suffix-DN

ターゲットサーバー   :  host:port

実行中のタスク  :  import
完了したタスク  :  backup

この出力は、サフィックス、およびターゲットサーバーとのレプリケーションアグリーメントが作成されていることを前提としています。実行中のインポート処理と完了したバックアップ処理も表示されます。

DSCC による設定の変更

設定を変更する方法としては、DSCC の使用を推奨します。このブラウザインタフェースには、タスクベースの制御が用意されており、迅速かつ効率的な設定に役立ちます。DSCC を使えば、1 つのサーバーの設定を変更してから、その設定をほかのサーバーにコピーできます。また、DSCC のインタフェースは、設定の複雑さや相互依存の解決に役立ちます。DSCC による設定変更の詳しい手順については、DSCC のオンラインヘルプを参照してください。

コマンド行からの設定の変更

コマンド行ツールを使用するスクリプトを作成することで、設定タスクを自動化することができます。

dsconf コマンドを使用して、コマンド行から設定を変更します。このコマンドは、LDAP を使用して cn=config サブツリーを変更します。dsconf の詳細は、「Directory Server のコマンド行ツール」を参照してください。

dsconf では実行できないタスクの場合は、ldapmodify コマンドを使用します。

dsconf set-server-prop コマンドを使用してサーバー設定プロパティーを変更する場合は、変更できるプロパティーとそれらのデフォルト値がわかっている必要があります。すべてのプロパティーのヘルプを表示するには、次のコマンドを使用します。

$ dsconf help-properties -v

必要な項目についてプロパティーのヘルプを検索します。たとえば、UNIX プラットフォームの場合は、次のように入力してメモリーキャッシュのプロパティーを検索します。

$ dsconf help-properties -v | grep cache

cn=config 内の設定エントリの詳細と、許容値の範囲を含むすべての設定エントリおよび属性の詳しい説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』を参照してください。

dse.ldif ファイルの変更

Directory Server では、その設定情報が次のファイル内に格納されます。

instance-path/config/dse.ldif

dse.ldif ファイルの内容を直接編集して設定を変更することは、エラーが生じる可能性が高くなるため、お勧めできません。ただし、このファイルを手動で編集する場合は、ファイルを編集する前にサーバーを停止し、編集が終わったらサーバーを再起動します。

dse.ldif ファイルの形式は、LDIF (LDAP Data Interchange Format) です。LDIF は、エントリ、属性、およびその値をテキスト表現したもので、RFC 2849 (http://www.ietf.org/rfc/rfc2849) に定義されている標準形式です。

dse.ldif ファイルにある Directory Server の設定は、次のもので構成されます。

• cn=config エントリの属性と値。

• cn=config の下のサブツリーに含まれるすべてのエントリと、その属性および属性値。

• ルートエントリ ("") と cn=monitor エントリのオブジェクトクラス、およびアクセス制御命令。これらのエントリのその他の属性は、サーバーによって生成されます。

  このファイルの読み書き権限を持っているのは、Directory Server インスタンスを所有するシステムユーザーのみです。

  Directory Server では、LDAP を通じてすべての設定を読み取り、書き込むことができます。デフォルトでは、ディレクトリの cn=config ブランチは、許可されているすべてのユーザーが読み取りでき、ディレクトリマネージャー (cn=Directory Manager) だけが cn=Administrators,cn=config の下の管理ユーザーに書き込むことができます。管理ユーザーは、他のディレクトリエントリと同様に、設定エントリを表示、変更できます。

  cn=config エントリの下には設定エントリ以外のものは作成しないでください。通常のエントリとは異なり、cn=config 配下では、作成されたエントリは、スケーラブルなデータベースとは異なる dse.ldif ファイルに格納されるためです。多くのエントリ、特に頻繁に更新されるエントリが cn=config の下に格納されている場合、パフォーマンスが低下する可能性が高くなります。ただし、レプリケーションマネージャー (サプライヤバインド DN) などの特別なユーザーエントリを cn=config の下に格納しておくと、設定情報を集中管理できて便利です。

管理ユーザーの設定

Directory Server には、デフォルトの管理ユーザーであるディレクトリマネージャーと cn=admin,cn=Administrators,cn=config ユーザーが含まれています。これらのユーザーは両方とも同じアクセス権限を持ちますが、ACI の対象は cn=admin,cn=Administrators,cn=config です。

この節では、ルートアクセス権を持つ管理ユーザーを作成する方法と、ディレクトリマネージャーを設定する方法について説明します。

ルートアクセス権を持つ管理ユーザーを作成する

cn=admin,cn=Administrators,cn=config と同じ権限を持つ新しい管理ユーザーを作成する場合は、グループ cn=Administrators,cn=config 内に新しいユーザーを作成します。このグループ内のすべてのユーザーが、ディレクトリマネージャーと同じ権限を許可するグローバル ACI の対象となります。

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

1. 新しい管理ユーザーを作成します。

   たとえば、cn=Admin24,cn=Administrators,cn=config という新しいユーザーを作成するには、次のように入力します。

   $ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=admin24,cn=Administrators,cn=config changetype: add objectclass: top objectclass: person userPassword: password description: Administration user with the same access rights as Directory Manager.

   --D オプションと --w オプションでは、それぞれ、このエントリの作成に必要な権限を持つユーザーのバインド DN とパスワードを指定します。

ディレクトリマネージャーを設定する

ディレクトリマネージャーとは、特権を持つサーバー管理者のことで、UNIX システムの root ユーザーにあたります。アクセス制御はディレクトリマネージャーには適用されません。

ほとんどの管理タスクでは、ディレクトリマネージャーを使用する必要はありません。代わりに、ユーザー cn=admin,cn=Administrators,cn=config を使用するか、cn=Administrators,cn=config の下に作成するその他のユーザーを使用できます。ディレクトリマネージャーを必要とするタスクは、ルート ACI の変更と、レプリケーションの修復や削除記録 (tombstone) の検索などのレプリケーションのトラブルシューティングタスクだけです。

ディレクトリマネージャー DN およびパスワードを変更でき、パスワードを自動的に読み取ることができるファイルを作成することもできます。

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

1. 既存のディレクトリマネージャー DN を見つけます。

   $ dsconf get-server-prop -h host -p port root-dn root-dn:cn=Directory Manager

2. 必要に応じてディレクトリマネージャーの設定を変更します。

   • ディレクトリマネージャー DN を変更するには、次のように入力します。

     $ dsconf set-server-prop -h host -p port root-dn:new-root-dn

     ディレクトリマネージャー DN のなかに空白文字がある場合は、引用符を使います。次に例を示します。

     $ dsconf set-server-prop -h host1 -p 1389 root-dn:"cn=New Directory Manager"

   • ディレクトリマネージャーパスワードを変更するには、次のように入力します。

     $ dsconf set-server-prop -h host -p port root-pwd:new-root-dn-password

     セキュリティー上の理由でコマンド行引数としてクリアテキストのパスワードを渡したくない場合は、パスワード設定用の一時ファイルを作成します。

     $ echo password > /tmp/pwd.txt

     このファイルが一度読み取られ、パスワードは将来使用するために格納されます。サーバールートのパスワードファイルプロパティーを設定します。

     $ dsconf set-server-prop -h host -p port root-pwd-file:/tmp/pwd.txt

     このコマンドは、サーバーにパスワードファイルの読み取りを要求します。パスワードファイルプロパティーの設定が完了したら、一時パスワードファイルを削除します。

     $ rm /tmp/pwd.txt

設定情報の保護

Directory Server のルートエントリ (長さゼロの DN "" によるベースオブジェクト検索で返されるエントリ) と、 cn=config、cn=monitor、cn=schema の下のサブツリーには、Directory Server によって自動的に生成されるアクセス制御命令 (ACI) が含まれます。これらの ACI は、ディレクトリエントリに対するユーザーアクセス権を確認するために使われます。評価目的としては、これらの ACI は十分に使えます。しかし、本稼働環境への配備の場合には、アクセス制御要件を評価し、独自のアクセス制御を設計する必要があります。

セキュリティー上の理由で 1 つまたは複数の追加のサブツリーの存在を非表示にし、設定情報を保護する場合は、追加の ACI を DIT 上に配置する必要があります。

• ACI 属性を、非表示にするサブツリーのベースにあるエントリに配置する。

• ACI をルート DSE エントリの namingContexts 属性に配置する。namingContexts というルート DSE エントリに、Directory Server の各データベースのベース DN のリストがあります。

• ACI を cn=config サブツリーと cn=monitor サブツリーに配置する。サブツリー DN も、cn=config と cn=monitor の下のマッピングツリーエントリ内に格納されます。

ACI の作成の詳細は、第 7 章「Directory Server のアクセス制御」を参照してください。

DSCC の設定

この節では、DSCC の設定に関する次のような点について記載します。

• 「共通エージェントコンテナのポート番号を変更する」

• 「Directory Service Manager パスワードをリセットする」

• 「DSCC セッションの自動タイムアウト遅延を延長する」

• 「DSCC に対するフェイルオーバーの設定」

• 「DSCC のトラブルシューティング」

共通エージェントコンテナのポート番号を変更する

デフォルトの共通エージェントコンテナのポート番号は 11162 です。共通エージェントコンテナは、DSCC エージェントポートを jmxmp-connector-port として定義します。管理上の理由で、DSCC エージェントと共通エージェントコンテナに別のポート番号を使用する必要がある場合は、次の手順に従います。

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

1. root として、jmxmp-connector-port の既存のポート番号を確認します。

   $ su Password: # cacaoadm list-params ... jmxmp-connector-port=11162 ...

2. DSCC エージェントのポート番号を変更します。

   DSCC エージェントのポート番号を変更するときは、共通エージェントコンテナを停止する必要があります。

   # cacaoadm stop # cacaoadm set-param jmxmp-connector-port=new-port # cacaoadm start

   このコマンドの場所については、「コマンドの場所」を参照してください。

3. DSCC で、サーバーの登録を解除してから、新しいDSCC エージェントのポート番号でそれらを再登録します。

   また、新しいサーバーを作成する場合は、デフォルト以外の DSCC エージェントのポート番号を指定する必要があります。

Directory Service Manager パスワードをリセットする

Directory Service Manager パスワードをリセットするには、次の手順で示すように DSCC を使用します。

1. 「DSCC にアクセスする」で説明するように DSCC にアクセスします。

2. 「設定」タブをクリックし、次に「Directory Service Manager」を選びます。

3. パスワードを変更する Directory Service Manager の名前をクリックします。

4. プロパティー画面で新しいパスワードを入力します。

   新しいパスワードをもう一度「パスワードの確認」フィールドに入力して確認します。「OK」をクリックして、変更を保存します。

DSCC セッションの自動タイムアウト遅延を延長する

DSCC セッションは、一定の時間が経過するとタイムアウトになり、ユーザーは DSCC からログアウトさせられます。タイムアウト遅延を延長するには、次の手順に従います。この手順では、DSCC および Sun Java Web Console 内のほかのすべてのアプリケーションのタイムアウトを延長します。

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

1. root として、タイムアウト遅延を延長します。

   # wcadmin add -p -a ROOT session.timeout.value=mm

   mm は、タイムアウトまでの時間 (分) です。

   たとえば、タイムアウトを 2 時間に設定するには、次のように入力します。

   $ su Password: # wcadmin add -p -a ROOT session.timeout.value=120 Set 1 properties for the ROOT application. # wcadmin list -p Shared service properties (name, value): session.timeout.value 120 ...

2. Sun Java Web Console を再起動します。

   # smcwebserver restart Shutting down Sun Java(TM) Web Console Version 3.0.2 ... Starting Sun Java(TM) Web Console Version 3.0.2 ... The console is running.

   これらのコマンドの場所については、「コマンドの場所」を参照してください。

DSCC に対するフェイルオーバーの設定

DSCC には、DSCC に登録されているサーバーが表示されます。

DSCC がインストールされているマシンで問題が発見された場合は、DSCC を別のマシンにインストールし、次にサーバーを再登録します。ただし、これにはかなり時間がかかる可能性があります。DSCC を使ってサーバーにすぐにアクセスする場合は、DSCC フェイルオーバーを設定できます。

DSCC フェイルオーバーを設定する場合は、次のような点を考慮に入れてください。

• 登録済みサーバーのすべての情報は、DSCC レジストリに格納される。このレジストリは Directory Server インスタンスである。管理コマンド dsadm および dsconf で、レジストリを管理できます。

• DSCC レジストリには、次のようなデフォルトの特性があります。

  サーバーインスタンス

  Solaris — /var/opt/SUNWdsee/dscc6/dcc/ads

  Linux および HP-UX — /var/opt/sun/dscc6/dcc/ads

  Windows — C:\Program Files\Sun\DSEE\var\dscc6\dcc\ads

  サフィックス

  cn=dscc

  ポート

  LDAP 3998、LDAPS 3999

• DSCC を複数のマシンにインストールしたあとは、DSCC レジストリサフィックス間にレプリケーションを設定できます。第 11 章「Directory Server のレプリケーション」で説明するレプリケーションコマンド行の手順に従います。あるいは、単純なレプリケーション設定の例については、dsconf(1M) のマニュアルページを参照してください。

  レプリケーションを設定したら、別のマシンから DSCC に登録されているサーバーと同じサーバーにアクセスできます。たとえば、host1 および host2 上のDSCC レジストリサフィックス間にレプリケーションを設定する場合は、 https://host1:6789 または https://host2:6789 のいずれかにある DSCC で同じサーバーを管理できます。ホストで障害が発生した場合は、もう一方のホストから DSCC にアクセスします。

DSCC のトラブルシューティング

DSCC のトラブルシューティングの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「To Troubleshoot Directory Service Control Center Access」を参照してください。

Directory Server のポート番号の変更

DSCC を使うか、dsconf set-server-prop コマンドを使って、ディレクトリサーバーの LDAP ポートまたは LDAPS セキュアポート番号を変更できます。

ポート番号を変更する場合は、次の点に注意してください。

• ほかのユーザーがアクセスするマシンに Directory Server がインストールされている場合、Directory Server のポートを root 権限を必要としないポート番号に設定すると、このポートはほかのアプリケーションによってハイジャックされる危険にさらされることになります。ほかのアプリケーションが同じアドレスとポートのペアにバインドできることになり、そのアプリケーションが、Directory Server になりすまして要求を処理できるようになってしまいます。つまり、そのアプリケーションを使って認証プロセスで使われるパスワードを取得したり、クライアント要求やサーバー応答を変更したり、サービス拒否攻撃を生成したりすることが可能となってしまいます。こうしたセキュリティー上のリスクを回避するには、listen-address または secure-listen-address プロパティーを使用して、Directory Server が待機するインタフェース (アドレス) を指定します。

コマンド行でポート番号を変更する場合は、次の点に注意してください。

• ほかのサーバー上に定義されているレプリケーションアグリーメントで Directory Server が参照される場合、そのレプリケーションアグリーメントは新しい ポート番号を使用するよう更新する必要があります。

• 以前に DSCC を使ってサーバーを管理していた場合は、ポート番号の変更後、一時的にサーバーを表示できなくなります。サーバーを再度表示するには、サーバーの登録を解除してから、新しいポート番号を使って DSCC で再度登録する必要があります。

ポート番号を変更する、ポートを使用可能にする、ポートを使用不可にする

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

設定を変更したあとは、変更を有効にするためにサーバーを再起動してください。

1. ポートの既存の設定を確認します。

   $ dsconf get-server-prop -h host -p port port-type

   ここで、port-type は次のいずれかです。

   ldap-port

   LDAP デフォルトポート

   ldap-secure-port

   LDAPS セキュアポート

   dsml-port

   DSML デフォルトポート

   dsml-secure-port

   DSML セキュアポート

   たとえば、LDAPS セキュアポートを表示するには、次のように入力します。

   $ dsconf get-server-prop -h host1 -p 2501 ldap-secure-port Enter "cn=Directory Manager" password: ldap-secure-port : 2511

   返される結果が整数の場合、ポートは使用可能です。返される結果が disabled の場合、ポートは使用不可です。

   ---

   注 –

   また、dsadm を使って LDAP デフォルトポートと LDAPS セキュアポートのリストを表示することもできます。

   ---

2. 必要に応じて、ポート番号を変更するか、ポートを使用可能にします。

   $ dsconf set-server-prop -h host -p port port-type:new-port

   たとえば、LDAP ポート番号を 1389 から 1390 に変更するには、次のコマンドを使用します。

   $ dsconf set-server-prop -h host1 -p 1389 ldap-port:1390

   ポート番号 2250 の DSML セキュアポートを使用可能にするには、次のコマンドを使用します。

   $ dsconf set-server-prop -h host1 -p 1389 dsml-secure-port:2250

3. 必要に応じて、ポートを使用不可にします。

   $ dsconf set-server-prop -h host -p port port-type:disabled

   たとえば、DSML セキュアポートを使用不可にするには、次のコマンドを使用します。

   $ dsconf set-server-prop -h host1 -p 1389 dsml-secure-port:disabled

DSML の設定

Directory Server は、LDAP (Lightweight Directory Access Protocol) で要求を処理するほか、DSMLv2 (Directory Service Markup Language version 2) で送信された要求も処理します。DSML は、クライアントがディレクトリ操作をエンコードするためのもう 1 つの方法です。サーバーは DSML を、同じアクセス制御とセキュリティー機能のすべてを持つほかの要求として処理します。この DSML 処理により、さまざまな種類のクライアントがディレクトリの内容にアクセスできるようになります。

Directory Server では、ハイパーテキスト転送プロトコル (HTTP/1.1) で DSMLv2 を使用できます。また、DSML の内容を転送するためのプログラミングプロトコルとして SOAP (Simple Object Access Protocol) version 1.1 が使われます。これらのプロトコルの詳細とDSML 要求の例については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 10 章「Directory Server DSMLv2」を参照してください。

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

• 「DSML-over-HTTP サービスを有効にする」

• 「DSML-over-HTTP サービスを無効にする」

• 「DSML のアイデンティティーマッピング」

DSML-over-HTTP サービスを有効にする

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

1. DSML モードを on に設定します。

   $ dsconf set-server-prop -h host -p port dsml-enabled:on

2. セキュア DSML ポートを設定します。

   $ dsconf set-server-prop -h host -p port dsml-secure-port:port

3. セキュアではない DSML ポートを設定します。

   $ dsconf set-server-prop -h host -p port dsml-port:port

   デフォルトでは、このポートは disabled に設定されます。

4. サーバーを再起動します。

   $ dsadm restart instance-path

次の手順

ユーザーによって定義されたパラメータと属性値に従い、DSML クライアントは次の URL を使用して、このサーバーに要求を送信できます。

http://host:DSML-port/ relative-URL

https://host:secure-DSML-port /relative-URL

relative-URL の読み取りおよび設定は、dsml-relative-root-url プロパティーを使用して行うことができます。

DSML-over-HTTP サービスを無効にする

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

1. DSML モードを off に設定します。

   $ dsconf set-server-prop -h host -p port dsml-enabled:off

2. セキュア DSML ポートを disabled に設定します。

   $ dsconf set-server-prop -h host -p port dsml-secure-port:disabled

3. サーバーを再起動します。

   $ dsasm restart instance-path

DSML セキュリティーを設定する

DSML 要求を受け入れるために必要なセキュリティーレベルを設定できます。このためには、DSML クライアント認証を設定する必要があります。

1. DSML クライアント認証モードを設定します。

   $ dsconf set-server-prop -h host -p port dsml-client-auth-mode:dsml-mode

   デフォルトでは、dsml-client-auth-mode プロパティーは client-cert-first に設定されます。

   dsml-mode は、次のいずれかです。

   • http-basic-only - これはデフォルト値です。サーバーは HTTP Authorization ヘッダーの内容を使用して、ディレクトリ内のエントリに対応付けるユーザー名を見つけます。このプロセスとその設定は SSL によって暗号化されますが、クライアント証明書は使用しません。これについては、「DSML のアイデンティティーマッピング」で説明しています。

   • client-cert-only: サーバーはクライアント証明書の資格情報を使用してクライアントを識別します。この設定では、DSML クライアントはすべて、セキュリティー保護された HTTPS ポートを使用して DSML 要求を送信し、証明書を提示する必要があります。サーバーは、このクライアント証明書がディレクトリ内のエントリと一致するかどうかを確認します。詳細は、第 6 章「Directory Server のセキュリティー」を参照してください。

   • client-cert-first: クライアント証明書が提示された場合、サーバーはまずその証明書を使用してクライアントの認証を試みます。それ以外の場合は、Authorization ヘッダーの内容を使用してクライアントを認証します。

   HTTP 要求に証明書も Authorization ヘッダーもない場合は、匿名バインドを使用して DSML 要求を実行します。匿名バインドは、次の場合にも使われます。

   • client-cert-only が指定されている場合で、クライアントから有効な Authorization ヘッダーが提示されたが、証明書は提示されていないとき。

   • http-basic-only が指定されている場合で、クライアントから有効な証明書が提示されたが、Authorization ヘッダーは提示されていないとき。

   証明書が提示されていてもエントリと一致しない場合や、HTTP Authorization ヘッダーが指定されていてもユーザーのエントリに対応付けることができない場合、クライアント認証方式にかかわらず DSML 要求は拒否され、エラーメッセージ 403「Forbidden」が返されます。

DSML のアイデンティティーマッピング

証明書を使わない基本認証を実行するときは、Directory Server はアイデンティティーマッピングというメカニズムを使用して、DSML 要求を受け入れるときに使うバインド DN を決定します。このメカニズムでは、HTTP 要求の Authorization ヘッダーから情報が抽出され、バインドに使うアイデンティティーを決定します。

DSML/HTTP のデフォルトのアイデンティティーマッピングは、サーバー設定の次のエントリで指定されます。

dn: cn=default,cn=HTTP-BASIC,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
cn: default
dsSearchBaseDN: ou=people
dsSearchFilter: (uid=${Authorization})

この設定は、サーバーでは、Directory Server サフィックスに格納された DN のuid 値として、HTTP ユーザー ID を使用するべきであることを示します。たとえば、HTTP ユーザーが bjensen の場合、サーバーは、DN uid=bjensen,ou=people を使ってバインドを実行しようとします。

したがって、マッピングを適切に処理するためには、dsSearchBaseDN の値を完全にする必要があります。たとえば、dsSearchBaseDN の値を ou=people,dc=example,dc=com に変更することができます。そのあと、HTTP ユーザーが bjensen の場合、サーバーは、DN uid=bjensen,ou=people,dc=example,dc=com を使ってバインドを実行しようとします。

dn: cn=default,cn=HTTP-BASIC,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
cn: default
dsSearchBaseDN: ou=people,dc=example,dc=com
dsSearchFilter: (uid=${Authorization})

マッピングエントリ属性 dsSearchFilter 内では、${header } という形式のプレースホルダを使用できます。ここで、header は HTTP ヘッダーの名前です。

DSML マッピングでもっともよく使われるヘッダーは、次のとおりです。

${Authorization}

この文字列は、HTTP Authorization ヘッダーに格納されているユーザー名で置き換えられます。Authorization ヘッダーにはユーザー名とパスワードの両方が格納されていますが、このプレースホルダにはユーザー名だけが入ります。

${From}

この文字列は、HTTP From ヘッダーに格納されている電子メールアドレスで置き換えられます。

${host}

この文字列は、DSML 要求の URL に含まれるホスト名とポート番号 (サーバーのホスト名とポート番号) に置き換えられます。

DSML 要求で別の種類のアイデンティティーマッピングを実行するには、HTTP ヘッダーのアイデンティティーマッピングを新しく定義します。

HTTP ヘッダーの新しいアイデンティティーマッピングを定義する

1. デフォルトの DSML-over-HTTP アイデンティティーマッピングを編集するか、このプロトコル用のカスタムマッピングを作成します。

   マッピングエントリは、エントリ cn=HTTP-BASIC,cn=identity mapping,cn=config の下になければなりません。

   「ldapmodify によるエントリの追加」で説明するように、ldapmodify コマンドを使ってこのエントリをコマンド行から追加します。

2. Directory Server を再起動して、新しいマッピングを有効にします。

   最初にカスタムマッピングが評価されます。カスタムマッピングが正常に行われていない場合は、デフォルトマッピングが評価されます。どのマッピングを使用しても、DSML 要求の認証に使うバインド DN を特定できない場合、DSML 要求は禁止され拒否されます (エラー 403)。

読み取り専用としてのサーバーの設定

ディレクトリ内のそれぞれのサフィックスは、単独で読み取り専用モードにすることができ、特定のリフェラルが 1 つ定義されていれば、それを返すことができます。また、Directory Server には、すべてのサフィックスに適用されるサーバー用の読み取り専用モードがあり、グローバルリフェラルが 1 つ定義されている場合は、それを返すことができます。

サーバーの読み取り専用モードは、管理者がサフィックスのインデックスを作成し直すときなどに、途中でディレクトリの内容が変更されないようにするために使います。このため、サーバーの読み取り専用モードは、次のエントリには適用されません。

• cn=config

• cn=monitor

• cn=schema

これらのエントリは、読み取り専用の設定とは無関係に、管理者以外のユーザーによる変更に対して常にアクセス制御命令 (ACI) によって保護してください (第 7 章「Directory Server のアクセス制御」を参照)。グローバルな読み取り専用モードでは、ディレクトリマネージャーで開始された更新操作を含む、ディレクトリ内のほかのすべてのサフィックスに対する更新操作が行われません。

読み取り専用モードでは、このモードが適用されているサフィックスについてはレプリケーションも中断されます。レプリケーションの対象となる変更がマスターレプリカに加えられることはなくなります。ただし、読み取り専用モードが適用される前に加えられた変更は、引き続きレプリケートされます。読み取り専用モードが無効になるまでは、コンシューマレプリカは更新を受け取りません。マルチマスターレプリケーション環境のマスターは、レプリケーションの対象となる変更が加えられることはなく、他のマスターから更新を受け取りません。

サーバー読み取り専用モードを有効または無効にする

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

1. グローバルな読み取り専用モードを有効にします。

   $ dsconf set-server-prop -h host -p port read-write-mode:read-only

2. 準備ができたら、読み取り専用モードを無効にします。

   $ dsconf set-server-prop -h host -p port read-write-mode:read-write

メモリーの設定

この節では、さまざまなタイプのメモリーについて説明します。さまざまなタイプのキャッシュの説明と、キャッシュチューニングの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 5 章「Directory Server Data Caching」を参照してください。

キャッシュのプライミング (priming)

キャッシュのプライミングとは、キャッシュをデータで満たすことを意味するため、それ以降の Directory Server の動作は、立ち上げ時のパフォーマンスではなく、通常動作時のパフォーマンスを反映します。キャッシュプライミングを使うと、ベンチマーク時に再現性のある結果に到達させるのに便利です。また、可能性のある最適化を測定し分析するためにも便利です。

可能なかぎり、キャッシュのプライミングは積極的には行わないでください。キャッシュのプライミングは、パフォーマンスを測定する前に、Directory Server を使って通常または一般的なクライアント対話によって行なってください。

データベースキャッシュのプライミングツールについては、http://www.slamd.com を参照してください。

データベースキャッシュを変更する

キャッシュを変更すると、サーバーのパフォーマンスに重大な影響を与える可能性があります。キャッシュを変更する場合は十分に注意してください。

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

1. 現在のデータベースのキャッシュレベルを取得します。

   $ dsconf get-server-prop -h host -p port db-cache-size

2. データベースキャッシュレベルを変更します。

   $ dsconf set-server-prop -h host -p port db-cache-size:size

   size は、G バイト (G)、M バイト (M)、K バイト (k)、バイト (b) のいずれかの単位で表せます。マシンでサポートされるサイズを指定してください。

データベースキャッシュを監視する

インストール時のキャッシュのデフォルトレベルはテスト環境に適したものであり、本稼働環境に適したものではありません。チューニング目的の場合は、サーバーのデータベースキャッシュを監視することもできます。

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

1. データベースキャッシュを監視します。

   $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=monitor,cn=ldbm database,cn=plugins,cn=config" "(objectclass=*)"

   データベースキャッシュのサイズが十分に大きく、キャッシュのプライミングが終わっている場合は、ヒット率 (dbcachehitratio) を高くしてください。また、(dbcachepagein) で読み取られるページ数と (dbcacheroevict) で書き出されるクリーンページは、低くしてください。この場合、「高い」と「低い」というのは、配備の制約に対して相対的に高いか低いかを意味します。

エントリキャッシュを監視する

チューニング目的では、1 つまたは複数のサフィックスのエントリキャッシュをチェックすることもできます。エントリキャッシュレベルを表示するには、この手順を使用します。

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

1. エントリキャッシュを監視します。

   $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=monitor,cn=db-name,cn=ldbm database,cn=plugins,cn=config" "(objectclass=*)"

   サフィックスのエントリキャッシュの大きさがサフィックス内の大半のエントリを保持するには十分な場合で、キャッシュが事前準備されている場合、ヒット率 (entrycachehitratio ) は高くしてください。

   キャッシュを事前準備した場合は、以前に空だったエントリキャッシュが満たされると、エントリキャッシュのサイズ (currententrycachesize) がエントリキャッシュの最大サイズ (maxentrycachesize) に近づいていることがわかります。理想としては、エントリ内のサイズ (currententrycachecount) は、サフィックス内のエントリの総数 (ldapentrycachecount) と等しいか非常に近いものにしてください。

エントリキャッシュを変更する

キャッシュを変更すると、サーバーのパフォーマンスに重大な影響を与える可能性があります。キャッシュを変更する場合は十分に注意してください。

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

1. 現在のエントリキャッシュレベルを取得します。

   $ dsconf get-suffix-prop -h host -p port suffix-DN entry-cache-count entry-cache-size

2. キャッシュのエントリ数を変更します。

   $ dsconf set-suffix-prop -h host -p port suffix-DN entry-cache-count:integer

   integer は、キャッシュに格納されるエントリの数です。

3. エントリキャッシュのサイズを変更します。

   $ dsconf set-suffix-prop -h host -p port suffix-DN entry-cache-size:size

   size は、G バイト (G)、M バイト (M)、K バイト (k)、バイト (b) のいずれかの単位で表されるキャッシュサイズです。マシンでサポートされるサイズを指定してください。

ヒープメモリーのしきい値を設定する

nsslapd プロセスで使用するヒープメモリーの量を制限する場合は、動的メモリーのフットプリントのしきい値を設定できます。このしきい値は、リソースが共有されているか sparse 状態であるマシン上で Directory Server が実行中の場合に設定することもできます。

このしきい値は、Solaris および Linux プラットフォームのみに設定できます。

メモリーサイズの設定の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「Directory Server とメモリー」を参照してください。

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

デフォルトでは、heap-high-threshold-size および heap-low-threshold-size プロパティーは undefined に設定されます。

1. 最大ヒープの高メモリーしきい値を設定します。

   $ dsconf set-server-prop -h host -p port heap-high-threshold-size:value

   value は、undefinedか、または G バイト (G)、M バイト (M)、K バイト (k)、バイト (b) のいずれかの単位で表されるメモリーサイズです。マシンでサポートされるサイズを指定してください。

   heap-high-threshold-size に使用する値に関する推奨事項については、server(5dsconf) のマニュアルページを参照してください。

2. オプションで、最大ヒープ低メモリーしきい値を設定します。

   $ dsconf set-server-prop -h host -p port heap-low-threshold-size:value

   value は、undefinedか、または G バイト (G)、M バイト (M)、K バイト (k)、バイト (b) のいずれかの単位で表されるメモリーサイズです。マシンでサポートされるサイズを指定してください。

   heap-low-threshold-size に使用する値に関する推奨事項については、server(5dsconf) のマニュアルページを参照してください。

各クライアントアカウントのリソース制限の設定

各クライアントアカウントに対する、サーバー上の検索操作のリソース制限を制御できます。このような制限をアカウントのオペレーショナル属性に設定すると、それらの制限は、クライアントがディレクトリへのバインドに使用するアカウントに基づいて、Directory Server で実施されます。

設定できる制限は次のとおりです。

• 検索制限は、検索処理で参照されるエントリの最大数を指定する。

• サイズ制限は、検索操作に応答して返されるエントリの最大数を指定する。

• 時間制限は、検索処理に費やせる最大時間を指定する。

• アイドルタイムアウトは、接続が切断されるまでに、クライアント接続がアイドル状態でいられる最大時間を指定する。

デフォルトでは、ディレクトリマネージャーは無制限にリソースを利用できます。

特定のユーザーアカウントに対して設定したリソース制限は、サーバー規模の設定で設定したリソース制限より優先されます。この節では、各アカウントに対するリソース制限の設定について説明します。

この節で示す例では、エントリの属性に直接リソース制限を設定します。また、サービスクラス (CoS) メカニズムを使ってアカウントにリソース制限を設定することもできます。クライアントアプリケーション用にエントリが取得されるとき、CoS メカニズムによって計算された属性が生成されます。CoS の定義の詳細は、「サービスクラス」を参照してください。

ヒープメモリーのしきい値を設定する

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

1. dsconf get-server-prop コマンドを使用して、リソース制限サーバープロパティーを読み取ります。

   $ dsconf get-server-prop -h host -p port look-through-limit search-size-limit \ search-time-limit idle-timeout look-through-limit : 5000 search-size-limit : 2000 search-time-limit : 3600 idle-timeout : none

   この出力は、検索により最大 5000 エントリが調べられ、最大 2000 エントリが返され、検索の処理には最大 1 時間 (3600 秒) が費やされることを示しています。

2. 検索制限を変更します。

   $ dsconf set-server-prop -h host -p port look-through-limit:integer

   integer は、検索処理で参照されるエントリの最大数です。

3. 検索サイズ制限を変更します。

   $ dsconf set-server-prop -h host -p port search-size-limit:integer

   integer は、検索処理で返されるエントリの最大数です。

4. 検索時間制限を変更します。

   $ dsconf set-server-prop -h host -p port serach-time-limit:integer

   integer は、検索処理に費やせる最大時間です。

5. アイドルタイムアウトを変更します。

   $ dsconf set-server-prop -h host -p port idle-timeout:integer

   integer は、接続が切断されるまでに、クライアント接続がアイドル状態でいられる最大時間を指定します。