パート I Directory Server による管理

第 1 章 Directory Server のツール

Sun Java^TM System Directory Server Enterprise Edition は、複数のサーバー、インスタンス、サフィックスをレプリケートされた環境で管理するためのブラウザインタフェースとコマンド行ツールを備えています。この章では、Directory Server の管理ツールの概要を説明します。

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

• 「Directory Server の管理の概要」

• 「DSCC を使用する場合とコマンド行を使用する場合の判断」

• 「Directory Service Control Center のインタフェース」

• 「Directory Server のコマンド行ツール」

Directory Server の管理の概要

Directory Server の管理フレームワークについては、このマニュアルセットの別のマニュアルで説明しています。

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

• Directory Server の管理フレームワークの詳細な情報については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 1 章「Directory Server Overview」を参照してください。

DSCC を使用する場合とコマンド行を使用する場合の判断

Directory Server Enterprise Edition には、Directory Server と Directory Proxy Server を管理するためのユーザーインタフェースが 2 つあります。ブラウザインタフェースである Directory Service Control Center (DSCC) とコマンド行インタフェースです。

DSCC を使用して手順を実行できるかどうかの判断

このマニュアルの手順のほとんどは、コマンド行または DSCC を使用して実行できます。このマニュアルの手順は、コマンド行を使用して手順を実行する方法を説明しています。ほとんどの場合、DSCC を使用しても同じ作業を実行できます。DSCC が特定の手順に使用できる場合、手順の初めにその旨が表記されています。

DSCC のオンラインヘルプには、DSCC を使用してこのマニュアルの手順を実行する詳細な指示が記載されています。

DSCC を使用した方が良い場合

DSCC は、次の節で説明するように、一部の操作と作業をコマンド行から実行するより簡単に実行できます。一般に、いくつかのサーバーに適用するコマンドは、DSCC を使用した方がうまくいきます。

サーバーとサフィックスのレプリケーション状態の表示

DSCC は、DSCC に登録されているすべてのサーバーインスタンスと設定されているすべてのサフィックス、およびそれぞれの状態を表に表示します。

サーバーの表は、「ディレクトリサーバー 」タブにあり、サーバーの操作状態を示します。可能なサーバー状態の完全な一覧については、Directory Server のオンラインヘルプを参照してください。

サフィックスの表は「サフィックス」タブにあり、エントリの数やレプリケートされてない変更の数や経過時間など、レプリケーション状態の情報を示します。この表に表示される情報の詳細については、Directory Server のオンラインヘルプを参照してください。

サーバーのグループの管理

サーバーグループによって、サーバーの監視や設定を円滑に行えます。グループを作成し、そのグループにサーバを割り当てられます。たとえば、地理的な位置や機能によってサーバーをグループ化できます。多数のサーバーがある場合、グループ内のサーバーのみを表示するよう「ディレクトリサーバー」タブに表示されるサーバーにフィルタを適用できます。また、あるサーバーのサーバー設定 (たとえば、インデックスやキャッシュ設定など) をグループ内のほかのすべてのサーバーにコピーすることもできます。サーバーグループの設定と使用方法については、Directory Server のオンラインヘルプを参照してください。

設定のコピー

DSCC では、既存のサーバー、サフィックス、またはレプリケーションアグリーメントの設定を 1 つまたは複数のほかのサーバー、サフィックス、レプリケーションアグリーメントにコピーできます。これらの作業の実行方法については、Directory Server のオンラインヘルプを参照してください。

レプリケーションの設定

DSCC を使用すると、レプリケーショントポロジをすばやく簡単に設定できます。単純にサーバーインスタンスを作成し、DSCC によって提供される手順を使用して、各サーバーのロールを割り当てます。DSCC によってレプリケーションアグリーメントが自動的に作成されます。DSCC を使用してレプリケーションを設定する方法については、Directory Server のオンラインヘルプを参照してください。

Directory Service Control Center のインタフェース

Directory Service Control Center (DSCC) は、ブラウザを使用して Directory Server と Directory Proxy Server を管理できるユーザーインタフェースです。

DSCC を設定するには、「DSCC の設定」を参照してください。DSCC の使用については、次の節を参照してください。

DSCC の管理ユーザー

DSCC では次の管理者権限でのアクセスが必要となる場合があります。

• OS ユーザー。サーバーインスタンスを作成し、dsadm コマンドを使用してサーバーインスタンス上でオペレーティングシステムコマンドを実行する権限を持った唯一のユーザーです。DSCC は、場合によっては、OS ユーザーパスワードを要求することがあります。このユーザーはパスワードを持ち、ディレクトリサーバーインスタンスを作成できます。

• ディレクトリマネージャー。サーバーの LDAP スーパーユーザーです。デフォルト DN は cn=Directory Manager です。

• ディレクトリ管理者。Directory Server を管理します。このユーザーはアクセス制御、パスワードポリシー、認証の要件に関する条件付きで、ディレクトリマネージャーと同じ権限を持ちます。ディレクトリ管理者は必要な数だけ作成できます。

• Directory Service Manager。DSCC を使用して複数のマシン上のデータとサーバー設定を管理します。このユーザーには、DSCC に登録されている各サーバーに対してディレクトリマネージャーと同じ権限があり、ディレクトリ管理者グループのメンバーです。

DSCC にアクセスする

DSCC へのアクセスに問題がある場合は、『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide』の「To Troubleshoot Directory Service Control Center Access」を参照してください。

1. DSCC が『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide』の「Software Installation」で説明されているとおりに正しくインストールされていることを確認します。

2. ネイティブパッケージインストールによって DSCC をインストールした場合は、次の手順に従います。

   1. ブラウザを開き、DSCC ホスト URL を次の形式で入力します。

      https://hostname:6789

      次に例を示します。

      https://host1:6789

      ここで、ホスト名は、DSCC ソフトウェアをインストールしたシステムです。

      Sun Java Web Console のデフォルトポートは 6789 です。

      次の図は、Sun Java Web Console のログインウィンドウを示しています。

      図 1–1 Sun Java Web Console のログインウィンドウ

      
      

   2. Sun Java Web Console にログインします。

      • Sun Java Web Console に初めてログインする場合は、DSCC ソフトウェアをインストールしたシステムに root として ログインします。

      • これが 2 回目以降のログインである場合は、オペレーティングシステムのユーザー名とパスワードを入力します。このユーザーは、Directory Server インスタンスを起動、停止、および管理する特権が必要です。

      ログインすると、アプリケーションの一覧が表示されます。

   3. Directory Service Control Center (DSCC) を選択します。

      DSCC ログインウィンドウが表示されます。

3. zip 形式の配布パッケージによって DSCC をインストールした場合は、次の手順に従います。

   1. 好みのアプリケーションサーバーで、DSCC のホスト URL を入力して、DSCC に直接アクセスします。DSCC のホスト URL は、アプリケーションサーバーの設定に応じて次のいずれかにできます。

      https://hostname:6789

      または

      http://hostname:6789

   2. 次のコマンドを使用して DSCC を初期化します。

      $ install path/dscc6/bin/dsccsetup ads-create

4. DSCC にログインします。

   DSCC に初めてログインする場合は、Directory Service Manager パスワードを設定する必要があります。2 回目以降のログインの場合は、初回のログイン時に設定したパスワードを使用します。

   DSCC にログインすると「共通操作」タブが表示されます。

   図 1–2 DSCC の「共通操作」タブ

   
   

5. タブを使用して移動します。

   • 「共通操作」タブには、一般的に使用するウィンドウやウィザードへのショートカットが表示されます。

   • 「ディレクトリサーバー」タブには、DSCC で管理される Directory Server がすべて表示されます。特定のサーバーを管理および設定するためのオプションを表示するには、サーバー名をクリックします。

   • 「プロキシサーバー」タブには、DSCC で管理される Directory Proxy Server がすべて表示されます。特定のサーバーを管理および設定するためのオプションを表示するには、サーバー名をクリックします。

   ---

   注 –

   DSCC を使用して作業を実行する方法については、DSCC のオンラインヘルプを参照してください。

   ---

   図 1–3 「サーバー」サブタブ上の Directory Server の一覧

   
   

DSCC のタブの説明

DSCC のタブを使用してインタフェースを移動します。

「共通操作」タブ

「共通操作」タブ (図 1–2を参照) は、DSCC を開いたときに最初に表示されるインタフェースです。ここには、ディレクトリデータの検索、ログの確認、サーバーの管理など、一般的に使用する管理作業へのリンクが表示されます。

「ディレクトリサーバー」タブ

「ディレクトリサーバー」タブ (図 1–3を参照) には、DSCC に登録されているディレクトリサーバーがすべて一覧表示されます。各サーバーのサーバーの状態とインスタンスがどこにあるかを示すインスタンスパスを確認できます。

サーバー名をクリックすると、そのサーバーにのみ関連するタブのセットが表示されます。

「プロキシサーバー」タブ

「プロキシサーバー」タブは、DSCC に登録されているディレクトリプロキシサーバーをすべて一覧表示します。各サーバーのサーバーの状態とインスタンスがどこにあるかを示すサーバーインスタンスパスを確認できます。

サーバー名をクリックすると、そのサーバーにのみ関連するタブのセットが表示されます。

「サーバーグループ」タブ

「サーバーグループ」タブでは、サーバーをグループに割り当て、サーバー管理を簡素化できます。多数のサーバーがある場合、フィルタを使用して特定のグループのサーバーのみを表示できます。また、あるサーバーのサーバー設定 (たとえば、インデックスやキャッシュ設定など) をグループ内のほかのすべてのサーバーにコピーすることもできます。

「設定」タブ

このタブには、DSCC ポート番号が表示され、Directory Service Manager を作成および削除できます。

DSCC のオンラインヘルプ

オンラインヘルプには、次の情報が表示されます。

• 現在使用しているページのコンテキスト依存ヘルプ。

• DSCC を使用して管理および設定手順を実行するための一般的なヘルプ。

ほとんどのページで画面の右上にある「ヘルプ」ボタンをクリックすればヘルプにアクセスできます。ウィザードから、「ヘルプ」タブをクリックするとヘルプにアクセスできます。また、「共通操作」タブからオンラインヘルプにアクセスすることもできます。

Directory Server のコマンド行ツール

DSCC で実行する作業のほとんどは、コマンド行ツールを使用して実行できます。これらのツールによって、コマンド行から直接 Directory Server を管理し、スクリプトを使用してサーバーを管理できます。

主なディレクトリサーバーのコマンドは、dsadm と dsconf です。これらのコマンドを使用して、バックアップ、LDIF へのエクスポート、証明書の管理などを行えます。これらのコマンドについては、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

この節では、Directory Server コマンド行ツールの次の情報について説明します。

• 「Directory Server コマンドの場所」

• 「dsconf の環境変数の設定」

• 「dsadm と dsconf の比較」

• 「dsadm と dsconf を使用するためのヘルプの表示」

• 「dsconf を使用した設定プロパティーの変更」

• 「マニュアルページ」

Directory Server コマンドの場所

Directory Server コマンド行ツールは、デフォルトインストールディレクトリにあります。

install-path/ds6/bin

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

dsconf の環境変数の設定

dsconf コマンドでは、いくつかのオプションが必要となりますが、それらは環境変数によってあらかじめ設定することができます。コマンドを使用する際にオプションが指定されていない場合や、環境変数が設定されていない場合は、デフォルト設定が使用されます。環境変数は次のオプションに対して設定できます。

-D user DN

ユーザーバインド DN。環境変数: LDAP_ADMIN_USER。デフォルト: cn=Directory Manager。

-w password-file

ユーザーバインド DN のパスワードファイル。環境変数: LDAP_ADMIN_PWF。デフォルト: パスワード入力用のプロンプトを表示する。

-h host

ホスト名。環境変数: DIRSERV_HOST。デフォルト: localhost。

-p LDAP-port

LDAP ポート番号。環境変数: DIRSERV_PORT。デフォルト: 389。

-e, --unsecured

dsconf がデフォルトで開くクリア接続を指定します。環境変数: DIRSERV_UNSECURED。この変数が設定されていない場合、dsconf はデフォルトでセキュリティー保護された接続を開きます。

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

dsadm と dsconf の比較

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

dsadm と dsconf を使用するためのヘルプの表示

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

• サブコマンドの一覧を表示するには、次の該当するコマンドを入力します。

  $ dsadm --help

  $ dsconf --help

• サブコマンドの使用方法についての説明を表示するには、次の該当するコマンドを入力します。

  $ dsadm subcommand --help

  $ dsconf subcommand --help

dsconf を使用した設定プロパティーの変更

dsconf のさまざまなサブコマンドを使って、ユーザーは設定プロパティーを表示したり、変更したりできます。

• Directory Server で使用する設定プロパティーを一覧表示するには、次のように入力します。

  $ dsconf help-properties

• 特定のプロパティーを見つけるには、ヘルププロパティーの出力を検索します。

  たとえば、UNIX® プラットフォームを使用している場合は、リフェラルに関連するプロパティーをすべて検索するには、次のコマンドを使用します。

  $ dsconf help-properties | grep -i referral SER referral-url rw M LDAP_URL | undefined Referrals returned to clients requesting a DN not stored in this Directory Server (Default: undefined) SUF referral-mode rw disabled|enabled|only-on-write Specifies how referrals are used for requests involving the suffix (Default: disabled) SUF referral-url rw M LDAP_URL | undefined Server(s) to which updates are referred (Default: undefined) SUF repl-rewrite-referrals-enabled rw on|off Specifies whether automatic referrals are overwritten (Default: off)

  プロパティーは、サフィックス (SUF) やサーバー (SER) などターゲットオブジェクトによってグループ化されることに注意してください。rw キーワードは、そのプロパティーが読み書き可能であることを示します。M キーワードは、そのプロパティーが複数の値を持つことを示します。

• サーバー属性を表示するには、冗長モードを使用します。たとえば、UNIX システムでは次のように入力します。

  $ dsconf help-properties -v | grep -i referral-mode SUF referral-mode rw disabled|enabled|only-on-write nsslapd-state Specifies how referrals are used for requests involving the suffix (Default: disabled)

個々のプロパティーの詳細は、各プロパティーのマニュアルページを参照してください。マニュアルページは、『Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference 』にあります。

dsconf を使用した複数値プロパティーの設定

特定の Directory Server プロパティーは複数の値をとることができます。これらの値を指定する構文は、次のとおりです。

$ dsconf set-container-prop -h host -p port container-name \
 property:value1 property:value2

たとえば、サーバーに対して複数の暗号化方式を設定するには、次のコマンドを使用します。

$ dsconf set-server-prop -h host1 -p 1389 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \
 ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

すでに値が含まれている複数値プロパティーに値を追加するには、次の構文を使用します。

$ dsconf set-container-prop -h host -p port container-name property+:value

すでに値が含まれている複数値プロパティーから値を削除するには、次の構文を使用します。

$ dsconf set-container-prop -h host -p port container-name property-:value

たとえば、前述の例で、暗号化方式のリストに SHA 暗号化方式を追加するには、次のコマンドを実行します。

$ dsconf set-server-prop -h host1 -p 1389 \
 ssl-cipher-family+:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

このリストから MD5 暗号化方式を削除するには、次のコマンドを実行します。

$ dsconf set-server-prop -h host1 -p 1389 ssl-cipher-family-:SSL_RSA_WITH_RC4_128_MD5

マニュアルページ

マニュアルページには、Directory Server で使用するコマンドと属性すべての説明が記載されています。さらに、マニュアルページには配備でコマンドを使用する方法についての有効な例もいくつか記載されています。

旧バージョンのツール

旧バージョンのツールは、下位互換性のために通常の Directory Server ツールに含まれています。これらのツールは、含まれてはいますが、推奨されていません。

第 2 章 Directory Server のインスタンスとサフィックス

この章では、Directory Server のインスタンスとサフィックスを作成、管理する方法について説明します。その他多くのディレクトリ管理業務はサフィックスレベルで設定されますが、このマニュアルでは別の章で説明しています。

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

• 「サーバーインスタンスとサフィックスを手短に作成する手順」

• 「Directory Server インスタンスの作成と削除」

• 「Directory Server インスタンスの起動、停止、および再起動」

• 「サフィックスの作成」

• 「サフィックスの無効化と有効化」

• 「リフェラルを設定し、サフィックスを読み取り専用にする」

• 「サフィックスの削除」

• 「サフィックスの圧縮」

サーバーインスタンスとサフィックスを手短に作成する手順

この章では、サーバーインスタンスとサフィックスを作成する方法について詳しく説明します。Directory Server のインスタンスとサフィックスを手短に作成し、サンプルデータをインポートする必要がある場合は、『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide』の「Server Instance Creation」を参照してください。

Directory Server インスタンスの作成と削除

この節では、Directory Server インスタンスの作成と削除の方法について説明します。

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

データを管理する前に、コマンド行ツールまたはブラウザインタフェース Directory Service Control Center (DSCC) を使用して Directory Server インスタンスを作成する必要があります。DSCC で、Directory Server インスタンスは単に「Directory Server」と呼ばれることがあります。

Directory Server インスタンスを作成する場合、Directory Server に必要なファイルとディレクトリは、指定した instance-path で作成されます。

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

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

1. 新しい Directory Server インスタンスを作成して、インスタンスパスを設定します。

   $ dsadm create instance-path

   このサーバーのディレクトリマネージャーのパスワードを設定するよう要求されます。

   サーバーインスタンスにデフォルト以外のポート番号またはその他のパラメータを指定するには、dsadm(1M) のマニュアルページを参照してください。

   たとえば、ディレクトリ /local/ds で新しいインスタンスを作成するには、次のコマンドを使用します。

   $ dsadm create /local/ds Choose the Directory Manager password: Confirm the Directory Manager password: Use 'dsadm start /local/ds' to start the instance

2. サーバーインスタンスが正しく作成されていることを確認します。

   $ dsadm info instance-path

   次に例を示します。

   $ dsadm info /local/ds1 インスタンスのパス: /local/ds1 所有者: user1(group1) セキュリティーが確保されていないポート: 1389 セキュアポート: 1636 ビットフォーマット: 64-bit 状態: 稼働中 サーバーの PID: 22555 DSCC URL: - SMF アプリケーション名: - ブート時に起動する: 無効 インスタンスのバージョン: D-A00

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

   オペレーティングシステム	コマンド
   Solaris 10	Sun クラスタ環境で作業している場合、次のコマンドを使用します。  dsadm enable-service --type CLUSTER instance-path resource-group そうでない場合は、次のようになります。  dsadm enable-service --type SMF instance-path
   Solaris 9	Sun クラスタ環境で作業している場合、次のコマンドを使用します。  dsadm enable-service --type CLUSTER instance-path resource_group そうでない場合は、次のようになります。  dsadm autostart instance-path
   Linux、HP-UX	dsadm autostart instance-path
   Windows	dsadm enable-service --type WIN_SERVICE instance-path

4. Directory Server を起動します。

   $ dsadm start instance-path

   ---

   注 –

   サーバーは実行されますが、データやサフィックスは含まれていません。サフィックスを作成するには、 dsconf を使用します。

   ---

5. (省略可能) 次のいずれかの方法で、サーバーインスタンスを登録します。

   • URL https://host:6789 にアクセスし、DSCC によってサーバーを登録します。

   • dsccreg add-server コマンドを使用します。

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

6. Directory Server インスタンスがスタンドアロンでパスワードポリシーを使用する場合、またはDS6-only パスワードポリシーモードにすでに移行したレプリケーショントポロジに属している場合は、インスタンスをこのモードに移行します。

   $ dsconf pwd-compat -h host -p port to-DS6-migration-mode ## Beginning password policy compatibility changes . ## Password policy compatibility changes finished. Task completed (slapd exit code: 0). $ dsconf pwd-compat -h host -p port to-DS6-mode ## Beginning password policy compatibility changes . ## Password policy compatibility changes finished. Task completed (slapd exit code: 0).

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

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

1. Directory Server を停止します。

   $ dsadm stop instance-path

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

   $ dsccreg remove-server /local/ds Enter DSCC administrator's password: /local/ds is an instance of DS Enter password of "cn=Directory Manager" for /local/ds: This operation will restart /local/ds. Do you want to continue ? (y/n) y Unregistering /local/ds from DSCC on localhost. Connecting to /local/ds Disabling DSCC access to /local/ds Restarting /local/ds

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

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

   オペレーティングシステム	コマンド
   Solaris 10	Sun クラスタ環境で作業している場合、次のコマンドを使用します。  dsadm disable-service --type CLUSTER instance-path そうでない場合は、次のようになります。  dsadm disable-service --type SMF instance-path
   Solaris 9	Sun クラスタ環境で作業している場合、次のコマンドを使用します。  dsadm disable-service --type CLUSTER instance-path そうでない場合は、次のようになります。  dsadm autostart --off instance-path
   Linux、HP-UX	dsadm autostart --off instance-path
   Windows	dsadm disable-service --type WIN_SERVICE instance-path

4. サーバーインスタンスを削除します。

   $ dsadm delete instance-path

   ---

   注意 –

   このコマンドによって、データベースやデータを含むすべてが削除されます。

   インスタンスがサービスとして有効にされている場合、またはインスタンスがシステムの起動時に自動的に起動されている場合には、ルートアクセス権を持つ管理ユーザーで、dsadm delete を実行する必要があります。

   ---

Directory Server インスタンスの起動、停止、および再起動

コマンド行からサーバーを起動、停止、または再起動するには、それぞれコマンド dsadm start、dsadm stop、または dsadm restart を使用します。

エントリを維持するよう設定されたメモリーに大容量のキャッシュがある状態で Directory Server インスタンスを停止して再起動する場合、キャッシュを復元するにはしばらく時間がかかります。キャッシュを復元している間、インスタンスの応答時間は遅くなります。

これらのコマンドは、Directory Server を作成したものと同じ UID と GID で実行するか、root で実行する必要があります。たとえば、Directory Server を user1 として実行している場合、start、stop、および restart ユーティリティーも user1 として実行する必要があります。

Solaris 上では、役割に基づくアクセス制御によって、root 以外のユーザーとして Directory Server を実行できます。

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

DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。ただし、これは、サービス管理を有効および無効にする手順には適用されません。サービス管理の有効化と無効化は、Directory Server の起動および停止時にコマンド行で実行する必要があります。

1. Directory Server を起動、停止、および再起動するには、次のいずれかを実行します。

   • サーバーを起動するには、次のように入力します。

     $ dsadm start instance-path

     たとえば、インスタンスパスが /local/ds のサーバーを起動するには、次のコマンドを使用します。

     $ dsadm start /local/ds

   • サーバーを停止するには、次のように入力します。

     $ dsadm stop instance-path

     次に例を示します。

     $ dsadm stop /local/ds

   • サーバーを再起動するには、次のように入力します。

     $ dsadm restart instance-path

     次に例を示します。

     $ dsadm restart /local/ds

サフィックスの作成

Directory Server インスタンスを作成した後、サーバーのディレクトリ情報ツリー (DIT) に対して 1 つまたは複数のサフィックスを作成します。DIT はサーバー内のすべてのエントリから構成され、エントリはそれぞれ DN (識別名) によって識別されます。DN は階層構造を持つため、ツリー内のデータ構成を決定する分岐のエントリおよびリーフエントリが作成されます。DIT は、サフィックスとサブサフィックスの点で管理上、定義され、管理されます。DSCC は、これらの要素すべての作成と管理を制御します。または、コマンド行ツールを使用することもできます。

ディレクトリデータの構造化と一般的なサフィックスの概念的な情報については、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』を参照してください。

次の手順で説明しているように、dsconf create-suffix コマンドを使用して、ディレクトリでサフィックス設定を作成できます。ルートサフィックスとサブサフィックスは、サーバーによって内部的に同じ方法で管理されるため、それらをコマンド行から作成する手順はほとんど同じです。手順では、必要なオプションのみと dsconf create-suffix コマンドを使用しています。このコマンドのその他のオプションについては、dsconf(1M) のマニュアルページを参照するか、次のコマンドを実行してください。

$ dsconf create-suffix --help

任意の管理ユーザーが設定エントリを作成できます。ただし、サフィックスの最上位エントリは、ディレクトリマネージャーが作成するか、cn=admin,cn=Administrators,cn=config のようなディレクトリ管理者が作成する必要があります。

サフィックスを作成する

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

DSCC を使用して新しいサフィックスを作成するには、既存のサフィックスからサフィックス設定の一部またはすべてをコピーするよう選択できます。

1. ルートサフィックスを作成します。

   サーバーが起動中であることを確認して、次のコマンドを入力します。

   $ dsconf create-suffix -h host -p port suffix-DN

   ここで、suffix-DN は新しいサフィックスの完全な DN です。ルートサフィックスでは、ドメインコンポーネント (dc) のネーミング属性が使用されます。

   たとえば、DN dc=example,dc=com のサフィックスを作成する場合は、次のコマンドを使用します。

   $ dsconf create-suffix -h host1 -p 1389 dc=example,dc=com

   このコマンドによって、次のように新しいサフィックスが作成されます。

   • ルートサフィックスの最上位レベル (またはベース) エントリが作成されます。

   • cn=config 内にサフィックスとデータベースの両方に対する設定エントリが作成されます。

   • デフォルトデータベース名は、サフィックス DN に基づきます。

   作成された新しいサフィックスを含む、すべてのサフィックスについては、次のコマンドを使用します。

   $ dsconf list-suffixes -h host -p port -v

   -v オプションによって冗長モードが表示されます。これによって、サフィックス上のエントリの数とレプリケーション情報が表示されます。

   ---

   注 –

   複数の Directory Server インスタンスがある場合、 -h host name と -p port number オプションを使用して、サフィックスの属するサーバーインスタンスを指定します。

   データベースファイル用にデフォルト以外のパスを指定する場合は、-L オプションを使用します。サフィックスデータベースパスはあとで変更できます。これを実行するには、コマンド dsconf set-suffix-prop suffix-DN db-path:new-db-path を使用してから、サーバーを停止し、データベースファイルを手動で移動して、サーバーを再起動します。

   サフィックスの作成時に使用できるオプションをすべて確認するには、dsconf(1M) のマニュアルページを参照してください。

   ---

2. 必要に応じてサブサフィックスを作成します。

   $ dsconf create-suffix -h host -p port subSuffix-DN

   その後、サブサフィックスをルートサフィックスに追加します。

   $ dsconf set-suffix-prop -h host -p port subSuffix-DN parent-suffix-dn:parentSuffix-DN

   ここで、parentSuffix-DN は、前の手順の suffix-DN と同じ値にします。サブサフィックスの suffix-DN には、サブサフィックスの相対識別名 (RDN) と親サフィックスの DN が含まれます。

   たとえば、サブサフィックス ou=Contractors,dc=example,dc=com を作成して、サブサフィックスをルートサフィックスに追加するには、次のように入力します。

   $ dsconf create-suffix -h host1 -p 1389 ou=Contractors,dc=example,dc=com $ dsconf set-suffix-prop -h host1 -p 1389 ou=Contractors,dc=example,dc=com \ parent-suffix-dn:dc=example,dc=com

   このエントリがディレクトリに追加されると、サーバーのデータベースモジュールは、次のディレクトリにデータベースファイルを自動的に作成します。

   instance-path/db/database-name

   ここで、database-name は、サフィックスの一部から自動的に構築された名前です。たとえば、前の例で、database-name は Contractors となります。

3. (省略可能) サフィックスをデータで初期化します。「サフィックスの初期化」を参照してください。

サフィックスの無効化と有効化

場合によっては、保守のためにサフィックスを使用不可にしたり、セキュリティー上の理由からその内容を使用不可にする必要のあることがあります。サフィックスを無効にすることによって、クライアント操作に応えてサーバーがサフィックスの内容を読み書きするのを防げます。サフィックスを無効にすると、そのサフィックスにアクセスすることはできなくなり、リフェラルモードは自動的に無効になります。

サフィックスを無効にしてから有効にする

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

1. サフィックスを無効にします。

   $ dsconf set-suffix-prop -h host -p port suffix-DN enabled:off

   ---

   注 –

   レプリケートされたサフィックスのほとんどのプロパティーがレプリケーションメカニズムによって決定されるため、レプリケーションが有効になっているサフィックスを無効にすることはできません。

   ---

2. サフィックスを有効にします。

   $ dsconf set-suffix-prop -h host -p port suffix-DN enabled:on

リフェラルを設定し、サフィックスを読み取り専用にする

サフィックスを完全に無効にすることなくサフィックスへのアクセスを制限するには、アクセス権を変更して、読み取り専用アクセスを許可することもできます。この場合、書き込み操作に対しては、別のサーバーへのリフェラルを定義する必要があります。また、読み取りアクセスと書き込みアクセスの両方を拒否し、サフィックスへのすべての操作に対するリフェラルを定義できます。

さらに、リフェラルを使用して、クライアントアプリケーションが一時的に別のサーバーを使用するように設定することもできます。たとえば、サフィックスの内容をバックアップしている間、別のサフィックスへリフェラルを追加できます。

サフィックスがレプリケートされた環境のコンシューマである場合、レプリケーションメカニズムによって、リフェラル設定の値が決まります。リフェラルの設定は手動で変更できますが、リフェラルは次のレプリケーションの更新時に上書きされます。レプリケーションのリフェラルの設定については、「コンシューマの詳細設定を行う」を参照してください。

リフェラルはラベル化された URL なので、LDAP URL には空白文字とラベルが続く場合があります。次に例を示します。

ldap://phonebook.example.com:389/

または

ldap://phonebook.example.com:389/ou=All%20People,dc=example,dc=com

リフェラルの URL 部分にある空白文字は、%20 を使用してエスケープする必要があります。

リフェラルを設定して、サフィックスを読み取り専用にする

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

1. リフェラルの URL を設定します。

   $ dsconf set-suffix-prop -h host -p port suffix-DN referral-url:LDAP-URL

   ここで、LDAP-URL はターゲットのホスト名、ポート名、DN を含む有効な URL です。

   次に例を示します。

   $ dsconf set-suffix-prop -h host1 -p 1389 dc=example,dc=com \ referral-url:ldap://phonebook.example.com:389/

   LDAP URL は任意の個数だけ指定できます。

2. サフィックスを読み取り専用にするためにリフェラルモードを設定します。

   $ dsconf set-suffix-prop -h host -p port suffix-DN referral-mode:only-on-write

   サフィックスを読み取りも書き込みもできないようにし、すべての要求にリフェラルを返すにはreferral-mode を enabled に設定します。

3. コマンドが正常に実行されるとすぐに、サフィックスは読み取り専用またはアクセス不可になり、リフェラルを返す準備ができます。

4. (省略可能) サフィックスが使用できるようになったら、ふたたびサフィックスの読み書きができるようにリフェラルを無効にします。

   $ dsconf set-suffix-prop -h host -p port suffix-DN referral-mode:disabled

   リフェラルが無効になると、サフィックスの enabled プロパティーを off に設定してサフィックス自体を無効にしていない限り、サフィックスは自動的に読み書き可能になります。

サフィックスの削除

サフィックスを削除すると、DIT からそのエントリ全体が削除されます。

サフィックスを削除すると、ディレクトリからそのデータエントリすべてが完全に削除されます。レプリケーション設定を含むサフィックス設定情報もすべて削除されます。

親サフィックスを削除し、そのサブサフィックスを、DIT で新しいルートサフィックスとして保持することはできません。サブサフィックスを含むエントリ全体を削除する場合は、削除された親のサブサフィックスと考えられるサブサフィックスも削除します。

サフィックスを削除する

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

1. サフィックスの設定エントリを削除します。

   $ dsconf delete-suffix -h host -p port [subSuffix-DN] suffix-DN

   このコマンドによって、suffix-DN のベースエントリで始まるサフィックスがサーバーから削除されます。これで、サフィックスはディレクトリに表示されなくなり、アクセスできなくなります。

サフィックスの圧縮

Directory Server 6.2 では、オフラインでのサフィックスの圧縮がサポートされます。このリリースでは、オンラインでの圧縮はサポートされません。記憶領域を使用できる場合、サフィックスを圧縮すると、データベースキーが再構成されることによりデータベースのサイズが縮小されます。

サフィックスをオフラインで圧縮する

この手順を実行する前に、サーバーを停止してデータベースをバックアップしてください。

1. 必要なサフィックスを圧縮します。

   $ dsadm repack instance-path suffix-dn

   指定したサフィックスに関連するすべての .db3 ファイルが圧縮されます。

   このコマンドに -b オプションを付けて実行すると、サフィックス DN の代わりにバックエンドデータベース名を指定できます。少なくとも 1 つのサフィックスまたはバックエンドを指定してください。

第 3 章 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.2 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-pwd-file:new-root-dn-password-file

     ディレクトリマネージャー 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 の作成の詳細は、第 6 章「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 レジストリサフィックス間にレプリケーションを設定できます。第 10 章「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.2 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.2 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 要求を送信し、証明書を提示する必要があります。サーバーは、このクライアント証明書がディレクトリ内のエントリと一致するかどうかを確認します。詳細は、第 5 章「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) によって保護してください (第 6 章「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.2 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.2 配備計画ガイド』の「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 は、接続が切断されるまでに、クライアント接続がアイドル状態でいられる最大時間を指定します。

第 4 章 Directory Server のエントリ

この章では、ディレクトリ内のデータエントリを管理する方法について説明します。また、リフェラルを設定する方法と属性値を暗号化する方法についても説明します。

ディレクトリの配備を計画する場合には、ディレクトリに格納するデータの種類を把握する必要があります。エントリの作成とデフォルトスキーマの変更に入る前に、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』の関連する章に目を通すようにしてください。

適切な ACI (アクセス制御命令) が定義されていない場合、ディレクトリは変更できません。詳細は、第 6 章「Directory Server のアクセス制御」を参照してください。

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

• 「エントリの管理」

• 「リフェラルの設定」

• 「有効な属性構文のチェック」

• 「ディレクトリエントリへの変更の記録」

• 「属性値の暗号化」

エントリの管理

エントリを管理するための最良な方法は、状況によって異なります。

• DSCC を主に管理用に使用していて、検索や変更を行いたいエントリは少ししかない場合は、DSCC を使用します。DSCC の詳細については、「Directory Service Control Center のインタフェース」を参照してください。

• Directory Server で管理タスクを実行せず、検索や変更を行いたいエントリが少ししかない場合は、Directory Editor を使用します。Directory Editor の詳細は、『Sun Java System Directory Editor 1 2005Q1 Installation and Configuration Guide』を参照してください。

• 多数のエントリを検索したり変更したりする場合は、コマンド行ユーティリティー ldapmodify および ldapdelete を使用します。

DSCC によるエントリの管理

DSCC では、エントリの読み取り可能なすべての属性を表示し、書き込み可能な属性を編集できます。また、属性の追加と削除、複数値属性の設定、エントリのオブジェクトクラスの管理も行えます。DSCC によるエントリの管理方法の詳細は、DSCC のオンラインヘルプを参照してください。DSCC の概要については、「Directory Service Control Center のインタフェース」を参照してください。

Directory Editor によるエントリの管理

Directory Editor は、管理者とエンドユーザーがデータを検索、作成、編集するための、使いやすいディレクトリ編集ツールです。扱えるデータの種類は、ユーザー、グループ、およびコンテナです。

ldapmodify および ldapdelete によるエントリの管理

コマンド行ユーティリティー ldapmodify および ldapdelete には、ディレクトリの内容を追加、編集、削除するための完全な機能が用意されています。これらのユーティリティーを使用して、サーバーの設定エントリと、ユーザーエントリに含まれるデータの両方を管理できます。これらのユーティリティーは、1 つまたは複数のディレクトリの一括管理を実行するためのスクリプトの作成にも利用できます。

ldapmodify コマンドと ldapdelete コマンドは、このマニュアル全体の手順で使用されます。次の節で、これらの手順の実行に必要な基本操作について説明します。ldapmodify コマンドと ldapdelete コマンドの詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

コマンド行ユーティリティーへの入力は、常に LDIF 形式で行います。この形式の入力は、コマンド行から直接指定できるだけでなく、入力ファイルからも行うことができます。次の節では、LDIF 入力について説明し、それ以降の節では各種変更処理で使われる LDIF 入力について説明します。

LDIF 入力の正しい形式については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の「Guidelines for Providing LDIF Input」を参照してください。

これらの基本操作については、次の節で説明します。

• 「ldapmodify によるエントリの追加」

• 「ldapmodify によるエントリの変更」

• 「ldapdelete によるエントリの削除」

• 「ldapmodify によるエントリの削除」

• 「ldapsearch によるエントリの検索」

ldapmodify によるエントリの追加

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

ldapmodify の -a オプションを使用して、ディレクトリに1 つまたは複数のエントリを追加できます。次の例では、まずユーザーが属するエントリを作成し、次にユーザーエントリを作成しています。

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: ou=People,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
ou: People
description: Container for user entries

dn: uid=bjensen,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgPerson
uid: bjensen
givenName: Barbara
sn: Jensen
cn: Babs Jensen
telephoneNumber: (408) 555-3922
facsimileTelephoneNumber: (408) 555-4000
mail: bjensen@example.com
userPassword: secret

-D オプションと -w オプションは、これらのエントリの作成に必要な権限を持つユーザーのバインド DN とパスワードを指定します。-a オプションは、LDIF に指定されているすべてのエントリが追加されることを示します。各エントリは DN と属性値でリストされ、エントリとエントリの間には空白行が挿入されます。ldapmodify ユーティリティーは、入力されるすべてのエントリを順番に作成し、エラーが発生した場合は、それをレポートします。

慣例により、エントリの LDIF には次の属性が指定されます。

1. エントリの DN。

2. オブジェクトクラスのリスト。

3. 1 つまたは複数のネーミング属性。これは DN で使用される属性で、必須属性である必要はありません。

4. すべてのオブジェクトクラスの必須属性。

5. エントリに指定する、許可されているその他の属性。

userpassword 属性の値を入力するときは、パスワードをクリアテキストで指定します。サーバーはこの値を暗号化し、暗号化された値だけが格納されます。LDIF ファイルに表示されるクリアテキストのパスワードを保護するために、読み取りアクセス権を制限してください。

-a オプションを必要としない、別の形式の LDIF をコマンド行に指定することもできます。この形式の利点は、エントリを追加する文と、次の例で説明するエントリを変更する文を組み合わせて指定できることです。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password: 
dn: ou=People,dc=example,dc=com
changetype: add
objectclass: top
objectclass: organizationalUnit
ou: People
description: Container for user entries

dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgPerson
uid: bjensen
givenName: Barbara
sn: Jensen
cn: Barbara Jensen
telephoneNumber: (408) 555-3922
facsimileTelephoneNumber: (408) 555-4000
mail: bjensen@example.com
userPassword: secret

changetype: add キーワードは、指定の DN を持つエントリが、それ以後のすべての属性を持った状態で作成されることを示します。それ以外のすべてのオプションと LDIF の表記は、この節の前のほうで説明した表記と同じです。

どちらの例でも、-f filename オプションを使うことで、端末からの入力の代わりにファイルから LDIF を読み取ることができます。LDIF ファイルには、-a オプションの使用の有無に応じて、端末から入力する場合と同じ形式で情報を指定する必要があります。

ldapmodify によるエントリの変更

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

既存のエントリの属性と属性値を追加、置換、または削除するときは、changetype: modify キーワードを使います。changetype: modify を指定する場合は、エントリの変更方法を示す、1 つまたは複数の変更操作も指定する必要があります。次の例には、3 種類の LDIF 変更操作が指定されています。

dn: entryDN
changetype: modify
add: attribute 
attribute: value...
-
replace: attribute 
attribute: newValue...
-
delete: attribute 
[attribute: value]
...

同じエントリに対する操作を区切るときはハイフン (-) を使い、異なるエントリに対する操作セットを区切るときは空白行を使います。各操作の対象となる attribute: value ペアを複数指定することもできます。

属性値の追加

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

次の例は、同じ add LDIF 文を使用して、既存の複数値属性と、まだ存在しない属性に値を追加する方法を示しています。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: cn
cn: Babs Jensen
-
add: mobile
mobile: (408) 555-7844

次のいずれかの場合は、処理が失敗し、エラーが返されることがあります。

• 指定した値がその属性にすでに存在する。

• 値が、属性に定義されている構文に準拠していない。

• エントリのオブジェクトクラスが、その属性タイプを必要としないか、許可しない。

• 属性タイプが複数値ではなく、その属性にすでに値が存在する。

バイナリ属性サブタイプの使用

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

attribute ;binary サブタイプは、実際の構文にかかわらず、値がバイナリデータとして LDAP 上を転送されることを示しています。このサブタイプは、userCertificate など、LDAP 文字列表現を持たない複雑な構文用に設計されたものです。この目的以外でバイナリサブタイプを使用しないでください。

ldapmodify コマンドで使用する場合は、どの LDIF 文でも、属性名に適切なサブタイプを追加できます。

バイナリ値を入力するには、LDIF テキストに直接入力するか、別のファイルから読み取ります。次の例は、ファイルから読み取る LDIF の構文を示しています。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
version: 1
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///local/cert-file

ファイル名の指定に :< 構文を使用するには、LDIF 文を version: 1 という行から開始する必要があります。ldapmodify がこの文を処理するときに、このツールは、指定ファイルの内容全体から読み取った値を属性に設定します。

言語サブタイプを持つ属性の追加

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

属性の言語とふりがなのサブタイプは、ローカライズされた値を特定します。属性に対して言語サブタイプを指定すると、そのサブタイプが属性名に次のように追加されます。

attribute;lang-CC

ここで、attribute は既存の属性タイプを示し、cc は言語を特定する 2 文字の国コードを示します。オプションとして、言語サブタイプにふりがなのサブタイプを追加し、ローカライズされた値の発音表記を指定することもできます。この場合、属性名は次のようになります。

attribute;lang-CC;phonetic

サブタイプを持つ属性に対して処理を行うには、そのタイプを明示的に一致させる必要があります。たとえば、lang-fr の言語サブタイプを持つ属性値を変更する場合は、次の例に示すように、変更操作に lang-fr を含める必要があります。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: homePostalAddress;lang-fr
homePostalAddress;lang-fr: 34, rue de la Paix

属性値に ASCII 以外の文字が含まれている場合は、UTF-8 で符号化する必要があります。

属性値の変更

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

次の例に、LDIF で replace 構文を使用して属性の値を変更する方法を示します。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
replace: sn
sn: Morris
-
replace: cn
cn: Barbara Morris
cn: Babs Morris

指定された属性の現在の値が削除され、指定された値が追加されます。

属性値を変更した後、ldapsearch コマンドで変更を確認します。

属性値内の後続の空白文字

属性値を変更する場合、値末尾の後ろに空白文字を残さないでください。値の後ろに空白文字を残すと、その値が base-64 方式で表示される場合があります (34xy57eg など)。

属性値の後ろに空白文字がある場合、その空白文字は属性値の一部としてエンコードされます。DSCC コンソールまたは ldapsearch コマンドを使用して変更を確認する場合、値はプレーンテキストで表示されますが、base-64 方式のテキストで表示される場合もあります。これは、使用している Directory Server クライアントにより異なります。

属性値の削除

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

次の例は、属性全体、または複数値属性の 1 つの値だけを削除する方法を示しています。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
delete: facsimileTelephoneNumber
-
delete: cn
cn: Babs Morris

attribute: value のペアを指定せずに delete 構文を使用すると、属性のすべての値が削除されます。attribute: value のペアを指定した場合は、その値だけが削除されます。

複数値属性の 1 つの値の変更

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

ldapmodify コマンドを使用して、複数値属性の 1 つの値を変更するには、次の例に示すように、2 段階の処理が必要です。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
delete: mobile
mobile: (408) 555-7845
-
add: mobile
mobile: (408) 555-5487

ldapdelete によるエントリの削除

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

ディレクトリからエントリを削除するときは、ldapdelete コマンド行ユーティリティーを使います。このユーティリティーは、ディレクトリサーバーにバインドし、DN を基にした 1 つまたは複数のエントリを削除します。指定のエントリを削除する権限を持つバインド DN を指定する必要があります。

子エントリのあるエントリは削除できません。LDAP プロトコルでは、親を持たない子エントリが存在する状況を禁止しています。たとえば、組織単位に属するすべてのエントリを先に削除しない限り、組織単位エントリは削除できません。

次の例では、組織単位には 1 つのエントリしか存在しません。このエントリを削除すれば、その親エントリを削除できます。

$ ldapdelete -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
uid=bjensen,ou=People,dc=example,dc=com
ou=People,dc=example,dc=com

ldapmodify によるエントリの削除

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

ldapmodify ユーティリティーを使用する場合は、changetype: delete キーワードを利用してエントリを削除することもできます。前の節で説明したように、ldapdelete の利用時と同じ制限事項がすべて適用されます。LDIF 構文を使用してエントリを削除する利点は、1 つの LDIF ファイルで複数の処理を組み合わせて実行できることです。

次の例は、前述の例と同じ削除処理を行います。

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: delete

dn: ou=People,dc=example,dc=com
changetype: delete

ldapsearch によるエントリの検索

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

ldapsearch コマンド行ユーティリティーは、ディレクトリエントリの検索と取得に使用できます。ldapsearch ユーティリティーは Solais プラットフォームに付属しているユーティリティーではありませんが、Directory Server Resource Kit の一部です。

ldapsearch の使い方、共通の ldapsearch オプション、受け入れられる形式、および例については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

ldapmodify を使用してエントリを移動または名前変更する

この手順では、DN 変更操作を使用します。この操作を始める前に、「DN の変更操作に関するガイドラインと制限」の節に記載されている内容を十分に理解してください。

この手順の一部として、DSCC を使用してこの作業を実行できます。詳細については、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。手順のその他の部分は、コマンド行を使用した場合にのみ実行できます。

グループの uniquemember であるエントリのDNを変更するときは、参照の完全性プラグインを有効にしておいてください。参照の完全性により、エントリが移動されたときにグループメンバーが調整されます。参照の完全性を有効にし、設定する方法の詳細は、「参照の完全性プラグインを設定する」を参照してください。

1. エントリをある親から別の親に移動する場合は、親エントリの ACI 権限を拡張します。

   • 移動するエントリの現在の親エントリでは、ACI で export 操作が許可されていることを、allow (export ...) 構文を使用して確認します。

   • エントリの移動先の親エントリでは、ACI で import 操作が許可されていることを、allow (import ...) 構文を使用して確認します。

   ACIU の使い方については、第 6 章「Directory Server のアクセス制御」を参照してください。

2. DN 変更操作がグローバルに有効か、少なくとも移動操作で影響を受けるサフィックスに対して有効であることを確認します。

   Directory Server の以前のリリースとの互換性を保つため、デフォルトでは DN 変更操作は有効ではありません。

   すでに DN 変更操作があらかじめ有効になっている場合は、次の手順に進みます。

   DN 変更操作をサーバーに対してグローバルに有効にするには、次のコマンドを使用します。

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

3. ldapmodify コマンドを実行します。

   この手順では、DN 変更操作を使用します。次のいずれかの操作を行います。

   • エントリを移動します。

     たとえば、次のコマンドで、エントリ uid=bjensen がパート社員のサブツリーで ある ou=Contractors,dc=example,dc=com から、従業員のサブツリーである ou=People,dc=example,dc=com に移動します。

     $ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=Contractors,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 0 newsuperior: ou=People,dc=example,dc=com

   • エントリの名前を変更します。

     たとえば、次のコマンドで、エントリ uid=bbjensen の名前が uid=bjensen に変更されます。

     $ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bbjensen,ou=People,dc=example,dc=com changetype: modrdn newrdn: uid=bjensen deleteoldrdn: 1

   LDIF 文を作成する際は、次の属性に注意してください。

   • dn - 名前変更または移動するエントリを指定します。

   • changetype: modrdn - DN の変更操作の使用を指定します。

   • newrdn - 新しいネーミング属性を指定します。

   • deleteoldrdn - 以前のネーミング属性をエントリから削除するかどうかを指定しま す (1 であれば削除、0 であれば削除しない)。

     ネーミング属性がエントリ定義で必須である場合、この属性はエントリから削除できないことに注意してください。

   • newsuperior: エントリの新しい上位属性を指定します。

   ldapmodify コマンドとそのオプションの詳細は、ldapmodify(1) のマニュアルページを参照してください。

4. 多数のエントリが含まれているサブツリーを移動したり名前変更したりするときに、リソース制限エラーが発生した場合は、データベースで使用できるロック数を増やします。

   $ dsconf set-server-prop -h host -p port db-lock-count:value

   このプロパティーを変更する場合は、変更を有効にするためにサーバーを再起動する必要があります。

DN の変更操作に関するガイドラインと制限

DN の変更操作を、前の節で説明したように使用する場合は、次の節で説明するガイドラインにしたがってください。

DN の変更操作に関する一般的なガイドライン

• DN の変更操作は、エントリのサフィックス間の移動や、ルートサフィックスの名前変更または移動には使用しないでください。

• 実行中の Directory Server が 5.2 2005Q1 以降であることを確認してください。Directory Server 5.2 2005Q1 以前のバージョンの Directory Server では、DN の変更操作を使用できません。

• entryid オペレーショナル属性は、内部使用専用の属性のため、DN 変更操作では使用しないでください。エントリの entryid オペレーショナル属性は、エントリが移動する際に変更される可能性があります。

• DN の変更操作はサーバー上のすべてのサフィックスに対してグローバルに、または操作を実行する各サフィックスで個別に有効にすることができます。デフォルトでは、DN の変更操作は無効になっています。

• サフィックス上で、DN の変更操作を実行するには、そのサフィックスの ACI 権限を拡張します。Import アクセス権を許可すると、指定された DN にエントリをインポートすることができます。Export アクセス権を許可すると、指定された DN からエントリをエクスポートすることができます。

• DN の変更操作を実行する前に、この操作によってクライアント認証が無効にならないことを確認してください。クライアント証明書を参照しているエントリを移動すると、クライアント認証が無効になってしまいます。エントリの移動によって、証明書が無効になっていないかどうかを確認してください。

• DN の変更操作を実行する前に、この操作によってアプリケーションが中断されることがないようにしてください。エントリの名前変更または移動によりいくつかのサフィックスに影響が及ぶ場合があります。あるいはエントリの次の特性が変更される可能性があります。

  • エントリのフィルタが適用されたロールの範囲。

  • エントリの入れ子のロール。入れ子のロールにはフィルタ化されたロールが格納されます。

  • エントリのダイナミックグループのメンバーシップ。

レプリケーション環境での DN の変更操作に関する一般的なガイドライン

次の要件を満たさずに DN の変更操作を実行すると、レプリケーションが中断され、ディレクトリサービスが停止する可能性があります。

• レプリケーショントポロジのすべてのサーバーが Directory Server 5.2 以降を実行していることを確認します。Directory Server 5.2 より前のバージョンの Directory Server では、DN の変更操作を使用できません。

• レプリケーショントポロジのすべてのサーバーで、DN の変更操作を有効にします。DN の変更操作がマスターサーバーでサポートされていてもコンシューマサーバーでサポートされていない場合、レプリケーションは失敗します。サプライヤサーバーのエラーログに、次のようなメッセージが書き込まれます。

  Unable to start a replication session with MODDN enabled

  レプリケーションを再開するには、レプリケーショントポロジを再設定してすべてのサーバーで DN の変更操作を有効にします。そのあと、次のいずれかの方法で、レプリケーションセッションを開始します。

  • 「レプリケーションの更新を強制的に実行する」の手順に従います。

  • サプライヤサーバーでエントリを変更します。変更内容はコンシューマサーバーにレプリケートされます。

• トポロジのすべてのマスターレプリカで、参照の完全性プラグインを有効にし設定します。このアクションにより、サーバーがグループとロールに対して参照の完全性を維持できます。参照の完全性を有効にし、設定する方法の詳細は、「参照の完全性プラグインを設定する」を参照してください。

  DN の変更操作を実行した後で、参照の完全性プラグインにより変更内容がレプリケートされるまで待機します。

リフェラルの設定

情報をローカルに取得できない場合に、どのサーバーに接続すべきかをクライアントアプリケーションに通知するには、リフェラルを使います。リフェラルとは、リモートサフィックスへのポインタ、つまり Directory Server が結果の代わりにクライアントへ返すエントリへのポインタです。クライアントは、リフェラルで指定されたリモートサーバー上で、再度、操作を実行する必要があります。

リダイレクションは、次の 3 つの場合に行われます。

• クライアントアプリケーションがローカルサーバーに存在しないエントリを要求し、サーバーがデフォルトのリフェラルを返すよう構成されている場合。

• サフィックス全体がメンテナンスまたはセキュリティー上の理由で無効になっている場合。

  サーバーは、該当のサフィックスで定義されているリフェラルを返します。サフィックスレベルのリフェラルについては、「リフェラルを設定し、サフィックスを読み取り専用にする」を参照してください。クライアントが書き込み処理を要求する場合、サフィックスの読み取り専用レプリカも、マスターサーバーへのリフェラルを返します。

• クライアントが特にスマートリフェラルにアクセスする場合。

  スマートリフェラルは、ユーザーが作成するエントリです。サーバーは、スマートリフェラルが定義するリフェラルを返します。

いずれの場合も、リフェラルは LDAP URL であり、ホスト名、ポート番号、およびオプションとして別のサーバー上の DN を含みます。たとえば、ldap://east.example.com:389 です。

ディレクトリの配備でリフェラルを使用する方法の概念情報は、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』を参照してください。

次に、ディレクトリのデフォルトリフェラルを設定する手順と、スマートリフェラルを作成および定義する手順について説明します。

デフォルトリフェラルの設定

デフォルトリフェラルは、Directory Server で管理されているサフィックスに含まれない DN に対して操作を送信するクライアントアプリケーションに返されます。サーバーは定義されているすべてのリフェラルを返しますが、返す順序は定義されていません。

デフォルトリフェラルを設定する

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

1. 1 つ以上のデフォルトリフェラルを設定するには、dsconf コマンド行ユーティリティーを使用します。

   $ dsconf set-server-prop -h host -p port suffix-DN referral-url:referral-URL

   次に例を示します。

   $ dsconf set-server-prop -h host1 -p 1389 dc=example,dc=com \ referral-url:ldap://east.example.com:1389

スマートリフェラルの設定

スマートリフェラルを使用して、ディレクトリエントリやディレクトリツリーを、特定の LDAP URL に割り当てることができます。スマートリフェラルを使用すると、クライアントアプリケーションに、特定のサーバーや特定のサーバーにある特定のエントリを参照させることができます。

多くの場合、スマートリフェラルは別のサーバー上の同じ DN を持つ実際のエントリを指しています。ただし、同じサーバーまたは別のサーバーのあらゆるエントリに対するスマートリフェラルを定義できます。たとえば、次の DN を持つエントリをスマートリフェラルとして定義することができます。

uid=bjensen,ou=People,dc=example,dc=com

このスマートリフェラルは、east.example.com というサーバー上の次のエントリを指しています。

cn=Babs Jensen,ou=Sales,o=east,dc=example,dc=com

ディレクトリがスマートリフェラルを使用する方法は、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt) のセクション 4.1.10 に指定されている標準に準拠する必要があります。

スマートリフェラルを作成および変更する

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

1. スマートリフェラルを作成するには、referral オブジェクトクラスと extensibleObject オブジェクトクラスを持つエントリを作成します。

   referral オブジェクトクラスでは、ref 属性で LDAP URL を指定します。extensibleObject オブジェクトクラスを使用すれば、ターゲットエントリと一致させるために、任意のスキーマ属性をネーミング属性として使用することができます。

   たとえば、次のエントリを uid=bjensen エントリの代わりにスマートリフェラルを返すよう定義するには、次のコマンドを使用します。

   $ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: referral uid: bjensen ref: ldap://east.example.com/cn=Babs%20Jensen,ou=Sales,o=east,dc=example,dc=com

   ---

   注 –

   サーバーでは、LDAP URL で空白のあとに続く情報はすべて無視されます。このため、リフェラルとして使用する予定のある LDAP URL では、空白の代わりに %20 を使用する必要があります。その他の特殊文字はエスケープする必要があります。

   ---

   スマートリフェラルを定義すると、別のサーバー上の cn=Babs Jensen エントリで、uid=bjensen エントリの修正が実際に行われます。ldapmodify コマンドは、たとえば次のように、自動的にリフェラルをたどります。

   $ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: replace replace: telephoneNumber telephoneNumber: (408) 555-1234

2. (省略可能) スマートリフェラルエントリを変更するには、ldapmodify の -M オプションを使用します。

   $ ldapmodify -M -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=People,dc=example,dc=com changetype: replace replace: ref ref: ldap://east.example.com/cn=Babs%20Jensen,ou=Marketing,o=east,dc=example,dc=com

有効な属性構文のチェック

Directory Server では、次の操作を行うときは常に、属性の完全性をチェックできます。

• dsadm import または dsconf import によるデータのインポート。

• LDAP または DSML によるエントリの追加、エントリの変更、またはエントリの DN の変更。

このチェックにより、属性値を IETF 勧告に準拠させることができます。準拠していないすべての属性は拒否され、エラーログに記録されます。ログメッセージには、当てはまる場合は接続および操作 ID が含まれます。

デフォルトでは、サーバーによって前述の操作の構文が自動的にチェックされます。構文チェックをオフにする場合は、次の手順に従います。

構文チェックはスキーマチェックとは異なります。スキーマチェックの詳細は、「スキーマ検査の管理」を参照してください。

自動構文チェックをオフにする

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. 自動構文チェックをオフにするには、次のコマンドを使用します。

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

ディレクトリエントリへの変更の記録

デフォルトでは、サーバーは、新たに作成または変更されたエントリの特別な属性を LDAP v3 仕様の指定どおりに保持します。これらの特別な属性は、サフィックス内のエントリに格納され、次のものが組み込まれます。

• creatorsName — 最初にエントリを作成したユーザーの DN。

• createTimestamp — エントリが作成されたときのタイムスタンプ (GMT 形式)。

• modifiersName — エントリを最後に変更したユーザーの DN。

• modifyTimestamp — エントリが変更されたときのタイムスタンプ (GMT 形式)。

エントリ変更記録をオフにする

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

エントリの変更記録をオフにすると、データが準拠しないものになります。多くのアプリケーションはこれらの属性に依存しているため、また、これらの機能を無効にすると最低限のパフォーマンスしか得られなくなるため、エントリ変更記録はオフにしないことをお勧めします。

1. サーバーのエントリ変更記録をオフにします。

   $ dsconf set-server-prop -h host -p port suffix-DN mod-tracking-enabled:off

属性値の暗号化

属性の暗号化はディレクトリに格納されている機密データを保護します。この機能を使用すると、エントリの特定の属性を暗号化された形式で格納するように指定できます。これにより、データベースファイル、バックアップファイル、およびエクスポートされた LDIF ファイルに格納されているデータが読み取られることを防ぎます。

この機能では、属性値は Directory Server データベースに格納される前に暗号化され、クライアントに返される前に元の値に復号化されます。クライアントと Directory Server との間でやり取りを行うときに、アクセス制御を使用してクライアントがこれらの属性に許可なくアクセスすることを防ぎ、SSL を使用して属性値を暗号化する必要があります。データセキュリティー全般のアーキテクチャー上の概要と、属性の暗号化の詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

属性の暗号化は、サーバー上で SSL が設定され有効になっている場合だけアクティブになります。ただし、デフォルトでは、どの属性も暗号化されません。属性の暗号化はサフィックスレベルで設定されます。つまり、サフィックス内でその属性が現れるすべてのエントリについて、属性が暗号化されます。ディレクトリ全体で属性を暗号化するには、すべてのサフィックスでその属性の暗号化を有効にする必要があります。

属性を暗号化すると、サフィックスに関連付けられたすべてのデータとインデックスファイルが影響を受けます。既存のサフィックスについて暗号化設定を変更するときは、まずサフィックスの内容をエクスポートし、設定を変更してからその内容をふたたびインポートする必要があります。これらの手順は、DSCCを使用して実行できます。DSCC の使用については、「Directory Service Control Center のインタフェース」を参照してください。

さらにセキュリティーについて考慮するならば、属性の暗号化をオンにする際に、暗号化されていない値がまだ含まれている可能性があるデータベースキャッシュファイルとデータベースログファイルを、手動で削除してください。これらのファイルを削除する手順については、「属性の暗号化を設定する」を参照してください。

新しいサフィックスにデータを読み込むときや作成するときは、暗号化されているすべての属性を有効にしてください。

一部のエントリがネーミング属性として使用している属性を暗号化すると、DN に表示される値は暗号化されないままですが、エントリ内に格納されている値は暗号化されています。

暗号化のために userPassword 属性を選択することはできますが、パスワードがクリアテキストとして格納される必要がある場合を除き、実質的なセキュリティー上の利点はありません。これは、DIGEST-MD5 SASL 認証などの場合です。パスワードポリシーにパスワードの暗号化メカニズムが定義されている場合、それをさらに暗号化してもセキュリティーの強化にはならず、バインド操作のたびにパフォーマンスが低下するという結果になるだけです。

暗号化された上で格納されている属性には、適用された暗号化アルゴリズムを示す暗号化方式タグが最初に付けられます。DES 暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。

{CKM_DES_CBC}3hakc&jla+=snda%

データを暗号化するためにオンラインで (dsconf コマンドを使って) インポートする場合、サーバーへの認証に使用される鍵データベースのパスワードはすでに指定されているため、2 回目には要求されなくなります。データをオフラインで (dsadm コマンドを使って) インポートする場合、インポートするデータを暗号化するたびに Directory Server はパスワードを要求します。より機密性の高い操作であるデータの復号化では、エクスポートをオンライン、オフラインのどちらで行うかに関係なく、Directory Server は常に鍵データベースのパスワードを要求します。これにより、セキュリティーはさらに高まります。

証明書や非公開鍵を変更しない限り、サーバーにより引き続き同じ鍵が生成されます。そのため、両方のサーバーインスタンスが同じ証明書を使用していた場合は、データをあるサーバーインスタンスから別のサーバーインスタンスにトランスポートできます。つまりエクスポートしてからトランスポートできます。

属性の暗号化とパフォーマンス

属性を暗号化することでデータのセキュリティーは向上しますが、システムのパフォーマンスに影響が生じます。どの属性を暗号化する必要があるかを十分に検討し、特に機密にするべきと考えられる属性のみを暗号化します。

機密データはインデックスファイルから直接アクセスできるため、暗号化された属性に対応するインデックスキーを暗号化して、それらの属性を完全に保護する必要があります。インデックス付け自体がすでに Directory Server のパフォーマンスに影響しているため (インデックスキーの暗号化による負荷は含まれない)、データをインポートする、またはデータベースに初めて追加する前に属性暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。

属性暗号化の使用に関する注意点

属性暗号化機能を実装するときは、次の点を考慮してください。

• 一般に、属性暗号化の設定を変更するときは、データをエクスポートし、変更を加えた上で、新たに設定されたデータをインポートする必要があります。

  これにより、機能が喪失することなく、すべての設定変更が全体として適用されます。このような方法で行わなかった場合、一部の機能が喪失し、データのセキュリティーが危険にさらされる可能性があります。

• 既存のデータベースに対する属性暗号化の設定を変更すると、システムのパフォーマンスに大きく影響することがあります。

  たとえば、既存のデータが格納されたデータベースインスタンスについて考えてみましょう。このデータベースには、mySensitiveAttribute という属性を持つエントリが格納されています。その属性の値は、データベースとインデックスファイルにクリアテキストで格納されているものとします。この状態で、あとから、mySensitiveAttribute 属性を暗号化しようとすると、属性暗号化の設定を適用するためにサーバーがデータベースとインデックスファイルを更新する必要があり、データベースインスタンス内のすべてのデータはエクスポートされ、データベースに再びインポートされます。これにより、パフォーマンスに大きな影響が生じます。この結果生じるパフォーマンスの問題は、もし、この属性を最初から暗号化していれば回避できるはずです。

• 復号化された形式でデータをエクスポートするときに、誤ったパスワードを使用するとエクスポートが拒否されます。

  データを復号化された形式でエクスポートしようとすると、セキュリティー保護のために、ユーザーにパスワードの入力を求めるプロンプトが表示されます。ユーザーが誤ったパスワードを入力すると、サーバーにより復号化されたデータのエクスポート操作が拒否されます。パスワードは、直接入力するか、パスワードが含まれているファイルへのパスを指定することで入力できます。このファイルには、SSL パスワードファイルと同じ構文があります。「証明書データベースパスワードの設定」を参照してください。

• アルゴリズムの変更はサポートされていますが、正しく作成されていない場合、インデックス付け機能は失われる可能性があります。

  データの暗号化に使用するアルゴリズムを変更するには、データをエクスポートし、属性の暗号化設定を変更してから、データをインポートします。この手順どおりに行わない場合、内部暗号化アルゴリズムに基づいて作成されたインデックスは機能しなくなります。

  暗号化された属性は使用する暗号化アルゴリズムを指定する暗号化方式タグの前に置かれるため、データのインポートは内部サーバー操作が処理します。このため、Directory Server では、アルゴリズムを変更する前に、データを暗号化された形式でエクスポートできます。

• サーバーの SSL 証明書を変更すると、暗号化されたデータを復号化できなくなります。

  サーバーの SSL 証明書は、属性暗号化機能で独自の鍵の生成に使用され、そのあと暗号化および復号化操作の実行に使用されます。このため、SSL 証明書は暗号化されたデータの復号化に必要です。前もってデータを復号化しないで証明書を変更すると、データは復号化できません。これを回避するには、復号化された形式でデータをエクスポートし、証明書を変更してからデータをインポートしてください。

• 暗号化されたデータを伝送する、つまり、サーバーインスタンス間でエクスポートとインポートを行うには、両方のサーバーインスタンスが同じ証明書を使用する必要があります。

  詳細は、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「属性値の暗号化」を参照してください。

属性の暗号化を設定する

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

1. 属性の暗号化を設定するサフィックスに何らかのエントリが含まれるときは、最初にそのサフィックスの内容を LDIF ファイルにエクスポートします。

   暗号化されている属性がサフィックスに含まれていて、エクスポートされた LDIF ファイルを使用してサフィックスを再初期化する場合は、エクスポートされた LDIF ファイルで属性を暗号化されたままにすることができます。

2. 属性の暗号化を有効にするには、次のコマンドを使用します。

   $ dsconf create-encrypted-attr -h host -p port suffix-DN attr-name cipher-name

   cipher-name は、次のいずれかになります。

   • des: DES ブロック暗号化方式

   • des3: トリプル DES ブロック暗号化方式

   • rc2 - RC2 ブロック暗号化方式

   • rc4 - RC4 ストリーム暗号化方式

   次に例を示します。

   $ dsconf create-encrypted-attr -h host1 -p 1389 dc=example,dc=com uid rc4

3. 暗号化された属性を元の状態に戻すには、次のコマンドを使用します。

   $ dsconf delete-encrypted-attr -h host -p port suffix-DN attr-name

4. 1 つ以上の属性を暗号化するように設定を変更していて、インポート操作の前にそれらの属性に値が含まれている場合は、データベースキャッシュをクリアし、ログを削除します。

   暗号化されていない値は、データベースキャッシュとデータベースログには表示されません。

   ---

   注 –

   これらのファイルを削除すると、一部の追跡情報が失われます。また、これらのファイルを削除すると、サーバーが復旧モードになり、再起動に時間がかかる場合があります。

   ---

   データベースキャッシュをクリアし、ログを削除するには、次のように操作します。

   1. 「Directory Server インスタンスの起動、停止、および再起動」で説明するように、Directory Server を停止します。

   2. root または管理者権限を持つユーザーとして、ファイルシステムの次の場所にあるデータベースキャッシュファイルを削除します。

      # rm instance-path/db/__db.*

   3. ファイルシステムからデータベースログファイルを削除します。

      # rm instance-path/db/log.0000000001

   4. Directory Server を再起動します。

      サーバーは、新しいデータベースキャッシュファイルを自動的に作成します。ふたたびキャッシュがいっぱいになるまで、このサフィックスでの操作のパフォーマンスは、若干の影響を受ける可能性があります。

5. 「サフィックスの初期化」で説明する方法で、LDIF ファイルを使用してサフィックスを初期化します。

   このファイルが読み込まれ、対応するインデックスが作成されるときに、指定した属性の値はすべて暗号化されます。

第 5 章 Directory Server のセキュリティー

Directory Server は、ネットワークを介してセキュリティーが確保された、信頼できる通信を行ういくつかのメカニズムをサポートしています。LDAPS は LDAP の標準プロトコルで、SSL (Secure Socket Layer) 上で実行されます。LDAPS はデータを暗号化し、オプションとして認証のために証明書を使用します。この章で SSL という用語を使用する場合、サポートされているプロトコル SSL2、SSL3、および TLS 1.0 を指します。

Directory Server は StartTLS (Start Transport Layer Security) 拡張処理もサポートしているため、元は暗号化されていない LDAP 接続でも TLS を有効にできます。

さらに は、SASL (Simple Authentication and Security Layer) を介した GSSAPI (Generic Security Service API) にも対応しています。GSSAPI により、Solaris オペレーティングシステム (Solaris OS) で Kerberos Version 5 セキュリティープロトコルを利用できます。アイデンティティーマッピングメカニズムによって、Kerberos 主体とディレクトリ内のアイデンティティーが関連付けられます。

セキュリティー情報の詳細については、http://www.mozilla.org/projects/security/pki/nss/ の NSS の Web サイトを参照してください。

この章では、SSL によってセキュリティーを設定する手順について説明します。ACI については、第 6 章「Directory Server のアクセス制御」を参照してください。ユーザーアクセスとパスワードについては、第 7 章「Directory Server のパスワードポリシー」を参照してください。

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

• 「Directory Server での SSL の使用」

• 「証明書の管理」

• 「SSL 通信の設定」

• 「資格レベルと認証方法の設定」

• 「LDAP クライアントでセキュリティーを使用するための設定」

• 「パススルー認証」

Directory Server での SSL の使用

SSL (Secure Sockets Layer) は暗号化された通信と、オプションとして Directory Server とクライアントの間の認証を提供します。SSL は LDAP 上または DSML-over-HTTP で使用できます。SSL は、LDAP 上でデフォルトで有効になりますが、DSML-over-HTTP を使用している場合、簡単に SSL を有効にできます。さらに、サーバー間のセキュリティー保護された通信に SSL を使用するよう、レプリケーションを設定できます。

単純認証 (バインド DN とパスワード) で SSL を使用すると、サーバーとやり取りしたデータがすべて暗号化されます。暗号化によって、機密性とデータの完全性が保証されます。必要に応じて、クライアントは証明書を使用して Directory Server への接続の認証、および SASL (Simple Authentication and Security Layer) を利用したサードパーティー製のセキュリティーメカニズムへの接続の認証ができます。証明書ベースの認証では、公開鍵暗号方式を使用してクライアントまたはサーバーを偽装したり、認証されているユーザーになりすますことはできなくなります。

Directory Server では、SSL による通信と SSL を使用しない通信を別々のポートで同時に実行できます。また、セキュリティーのためにすべての通信をセキュリティー保護された LDAP ポートに限定することもできます。クライアント認証も設定できます。クライアント認証を必要とする、または許可するように設定できます。この設定によって、実行するセキュリティーのレベルが決定されます。

SSL によって、通常の LDAP 接続をセキュリティー保護する Start TLS 拡張処理への対応も有効になります。クライアントが通常の LDAP ポートにバインドされても、TLS (Transport Layer Security) プロトコルを使用して接続を保護できます。Start TLS 処理では、クライアントに一層の柔軟性が与えられ、ポートの割り当ても簡素化できます。

SSL が提供する暗号化メカニズムは、属性の暗号化にも使用されます。SSL を有効にすることで、サフィックスでの属性の暗号化を設定し、ディレクトリに格納するときにデータを保護することができます。詳細については、「属性値の暗号化」を参照してください。

これ以外のセキュリティーとして、アクセス制御命令 (ACI) を使用してディレクトリの内容にアクセス制御を設定できます。ACI は、特定の認証メソッドを必要としデータがセキュリティー保護されたチャネルでのみ送信します。SSL と証明書の使用を補完するように ACI を設定します。詳細については、第 6 章「Directory Server のアクセス制御」を参照してください。

SSL は LDAP 上ではデフォルトで有効になります。DSML-over-HTTP では簡単に SSL を有効にできます。さらに、次に説明するように、一部の SSL 設定は変更が可能です。

証明書の管理

この節では、Directory Server で SSL 証明書を管理する方法について説明します。

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

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

テスト目的で証明書を使用している場合、自己署名付き証明書を使用できます。しかし、本番で自己署名付き証明書を使用することはあまり安全ではありません。本番では、信頼できる証明書発行局 (CA) の証明書を使用してください。

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

この節では、Directory Server での証明書設定に関する次の情報について説明します。

• 「デフォルトの自己署名付き証明書を表示する」

• 「自己署名済み証明書を管理する」

• 「CA 署名付きサーバー証明書を要求する」

• 「CA 署名付きサーバー証明書と信頼できる CA 証明書を追加する」

• 「有効期限の切れた CA 署名付きサーバー証明書を更新する」

• 「CA 署名付きサーバー証明書をエクスポートおよびインポートする」

• 「証明書データベースパスワードの設定」

• 「Directory Server の証明書データベースのバックアップと復元」

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

Directory Server インスタンスを初めて作成した場合、これには、デフォルトの自己署名付き証明書が含まれています。自己署名付き証明書は、公開鍵と非公開鍵のペアで、公開鍵が非公開鍵によって署名されています。自己署名付き証明書は、3 か月間有効です。

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

1. デフォルトの自己署名付き証明書を表示するには、次のコマンドを使用します。

   $ dsadm show-cert instance-path defaultCert

自己署名済み証明書を管理する

Directory Server インスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。

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

1. デフォルト設定以外の自己署名付き証明書を作成するには、次のコマンドを使用します。

   $ dsadm add-selfsign-cert instance-path cert-alias

   ここで、cert-alias は、証明書を特定するために付ける名前です。

   このコマンドのオプションをすべて確認するには、dsadm(1M) のマニュアルページまたはコマンド行のヘルプを参照してください。

   $ dsadm add-selfsign-cert --help

2. 自己署名付き証明書の期限が切れた場合は、サーバーインスタンスを停止して、証明書を更新します。

   $ dsadm stop instance-path $ dsadm renew-selfsign-cert instance-path cert-alias

3. サーバーインスタンスを再起動します。

   $ dsadm start instance-path

CA 署名付きサーバー証明書を要求する

この手順は、Directory Server とともに使用するために CA 署名付きサーバー証明書を要求し、インストールする方法を説明しています。

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

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

   $ dsadm request-cert [-W cert-pwd-file] {-S DN | --name name [--org org] \ [--org-unit org-unit] [--city city] [--state state] [--country country]} \ [-o output-file] [-F format] instance-path

   たとえば、Example 社の CA 署名付きサーバー証明書を要求するには、次のコマンドを使用します。

   $ dsadm request-cert --name host1 --org Example --org-unit Marketing \ -o my_cert_request_file /local/ds

   サーバーを完全に特定するために、認証局はこの例で示す属性すべてを必要とする場合があります。各属性の説明については、dsadm(1M) のマニュアルページを参照してください。

   dsadm request-cert を使用して証明書を要求すると、出力形式として ASCII を指定しない限り、作成される証明書要求はバイナリ証明書要求になります。ASCII を指定すると、作成される証明書要求は、PEM 形式の PKCS #10 証明書要求になります。PEM (Privacy Enhanced Mail) は、RFC 1421 〜 1424 (http://www.ietf.org/rfc/rfc1421.txt ) で指定されている形式で、US-ASCII 文字を使用した base64 形式で符号化されます。要求の内容は、次の例のようになります。

   -----BEGIN NEW CERTIFICATE REQUEST----- MIIBrjCCARcCAQAwbjELMAkGA1UBhMCVXMxEzARBgNVBAgTCkNBElGT1JOSUExLD AqBgVBAoTI25ldHNjYXBlIGNvb11bmljYXRpb25zIGNvcnBvcmF0aWuMRwwGgYDV QQDExNtZWxsb24umV0c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAUAA4GNADCBiQK BgCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7u0EfgSLR0f+K41eNqqWRftGR83e mqPLDOf0ZLTLjVGJaHJn4l1gG+JDf/n/zMyahxtV7+T8GOFFigFfuxJaxMjr2j7I vELlxQ4IfZgwqCm4qQecv3G+N9YdbjveMVXW0v4XwIDAQABAAwDQYJKoZIhvcNAQ EEBQADgYEAZyZAm8UmP9PQYwNy4Pmypk79t2nvzKbwKVb97G+MT/gw1pLRsuBoKi nMfLgKp1Q38K5Py2VGW1E47/rhm3yVQrIiwV+Z8Lcc= -----END NEW CERTIFICATE REQUEST-----

2. 手順に従って、証明書要求を認証局に転送します。

   認証局証明書を入手するプロセスは、使用する認証局によって異なります。商用 CA のなかには、証明書を自動的にダウンロードできる Web サイトを備えているものもあります。その他の CA は、要求に応じて電子メールで証明書を送信します。

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

3. 認証局から受け取った証明書を保存します。

   証明書を安全な場所にバックアップします。これにより、証明書を失っても、このバックアップファイルから証明書を再インストールできます。証明書はテキストファイルに保存できます。次に、PEM 形式の PKCS #11 証明書の例を示します。

   -----BEGIN CERTIFICATE----- MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6 6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo= -----END CERTIFICATE-----

CA 署名付きサーバー証明書と信頼できる CA 証明書を追加する

この手順は、Directory Server で使用するために、CA 署名付きサーバー証明書と信頼できる CA 証明書をインストールする方法を説明しています。

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

1. CA 署名付きサーバー証明書を追加します。

   $ dsadm add-cert --ca instance-path cert-alias cert-file

   ここで、cert-alias は証明書を特定するために付ける名前です。cert-file は、PEM 形式の PKCS #11 証明書を含むテキストファイルです。

   たとえば、CA 署名付きサーバー証明書をインストールするには、次のようなコマンドを使用します。

   $ dsadm add-cert --ca /local/ds server-cert /local/safeplace/serv-cert-file

   これで、証明書がインストールされますが、まだ信頼されていません。CA 署名付きサーバー証明書を信頼するには、認証局証明書をインストールする必要があります。

2. 信頼できる認証局証明書を追加します。

   $ dsadm add-cert --ca -C instance-path cert-alias cert-file

   -C オプションは、証明書が信頼できる認証局証明書であることを示します。

   たとえば、認証局からの信頼できる証明書をインストールするには、次のようなコマンドを使用します。

   $ dsadm add-cert --ca -C /local/ds CA-cert /local/safeplace/ca-cert-file

3. (省略可能) インストールした証明書を確認します。

   • サーバー証明書をすべて一覧表示して、有効期限とエイリアスを表示するには、次のように入力します。

     $ dsadm list-certs instance-path

     次に例を示します。

     $ dsadm list-certs /local/ds1 Enter the certificate database password: Alias Valid from Expires on Self- Issued by Issued to signed? ----------- ---------- ---------- ------- ----------------- ----------------- serverCert 2000/11/10 2011/02/10 n CN=CA-Signed Cert, CN=Test Cert, 18:13 18:13 OU=CA,O=com dc=example,dc=com defaultCert 2006/05/18 2006/08/18 y CN=host1,CN=DS, Same as issuer 16:28 16:28 dc=example,dc=com 2 certificates found

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

   • 信頼できる CA 証明書を一覧表示するには、次のように入力します。

     $ dsadm list-certs -C instance-path

     次に例を示します。

     $ dsadm list-certs -C /local/ds1 Enter the certificate database password: Alias Valid from Expires on Self- Issued by Issued to signed? ------- ---------- ---------- ------- ----------------- -------------- CA-cert 2000/11/10 2011/02/10 y CN=Trusted CA Cert, Same as issuer 18:12 18:12 OU=CA,O=com 1 certificate found

   • 証明書の有効期限を含む、証明書の詳細を表示するには、次のように入力します。

     $ dsadm show-cert instance-path cert-alias

     たとえば、サーバー証明書を表示するには、次のように入力します。

     $ dsadm show-cert /local/ds1 "Server-Cert" Enter the certificate database password: Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=Server-Cert,O=Sun,C=US" Validity: Not Before: Fri Nov 10 18:12:20 2000 Not After : Thu Feb 10 18:12:20 2011 Subject: "CN=CA Server Cert,OU=ICNC,O=Sun,C=FR" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: bd:76:fc:29:ca:06:45:df:cd:1b:f1:ce:bb:cc:3a:f7: 77:63:5a:82:69:56:5f:3d:3a:1c:02:98:72:44:36:e4: 68:8c:22:2b:f0:a2:cb:15:7a:c4:c6:44:0d:97:2d:13: b7:e3:bf:4e:be:b5:6a:df:ce:c4:c3:a4:8a:1d:fa:cf: 99:dc:4a:17:61:e0:37:2b:7f:90:cb:31:02:97:e4:30: 93:5d:91:f7:ef:b0:5a:c7:d4:de:d8:0e:b8:06:06:23: ed:5f:33:f3:f8:7e:09:c5:de:a5:32:2a:1b:6a:75:c5: 0b:e3:a5:f2:7a:df:3e:3d:93:bf:ca:1f:d9:8d:24:ed Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 85:92:42:1e:e3:04:4d:e5:a8:79:12:7d:72:c0:bf:45: ea:c8:f8:af:f5:95:f0:f5:83:23:15:0b:02:73:82:24: 3d:de:1e:95:04:fb:b5:08:17:04:1c:9d:9c:9b:bd:c7: e6:57:6c:64:38:8b:df:a2:67:f0:39:f9:70:e9:07:1f: 33:48:ea:2c:18:1d:f0:30:d8:ca:e1:29:ec:be:a3:43: 6f:df:03:d5:43:94:8f:ec:ea:9a:02:82:99:5a:54:c9: e4:1f:8c:ae:e2:e8:3d:50:20:46:e2:c8:44:a6:32:4e: 51:48:15:d6:44:8c:e6:d2:0d:5f:77:9b:62:80:1e:30 Fingerprint (MD5): D9:FB:74:9F:C3:EC:5A:89:8F:2C:37:47:2F:1B:D8:8F Fingerprint (SHA1): 2E:CA:B8:BE:B6:A0:8C:84:0D:62:57:85:C6:73:14:DE:67:4E:09:56 Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: User

有効期限の切れた CA 署名付きサーバー証明書を更新する

CA 署名付きサーバー証明書 (公開鍵と非公開鍵) の有効期限が切れた場合は、次の手順に従って更新します。

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

1. 認証局から更新された CA 署名付きサーバー証明書を入手します。

2. 更新された証明書を受け取ったら、サーバーインスタンスを停止して、証明書をインストールします。

   $ dsadm stop instance-path $ dsadm renew-cert instance-path cert-alias cert-file

3. サーバーインスタンスを再起動します。

   $ dsadm start instance-path

CA 署名付きサーバー証明書をエクスポートおよびインポートする

場合によって、あとで証明書をインポートできるように、証明書の公開鍵と非公開鍵をエクスポートすることがあります。たとえば、別のサーバーで使用する証明書が必要な場合があります。

この手順のコマンドは、"cn=*,o=example" のようなワイルドカードを含む証明書で使用できます。

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

1. 証明書をエクスポートします。

   $ dsadm export-cert [-o output-file] instance-path cert-alias

   次に例を示します。

   $ dsadm export-cert -o /tmp/first-certificate /local/ds1 "First Certificate" $ dsadm export-cert -o /tmp/first-ca-server-certificate /local/ds1/ defaultCert Choose the PKCS#12 file password: Confirm the PKCS#12 file password: $ ls /tmp first-ca-server-certificate

2. 証明書をインポートします。

   $ dsadm import-cert instance-path cert-file

   たとえば、host1 上のサーバーインスタンスに証明書をインポートするには、次のように入力します。

   $ dsadm import-cert -h host1 /local/ds2 /tmp/first-ca-server-certificate Enter the PKCS#12 file password:

3. (省略可能) サーバーに証明書をインポートしたら、インポートした証明書を使用するようサーバーを設定します。

   $ dsconf set-server-prop -e -h host -p port -w - ssl-rsa-cert-name:server-cert

証明書データベースパスワードの設定

デフォルトで、Directory Server は保存されたパスワードを使用して SSL 証明書データベースのパスワードを内部的に管理します。証明書を管理する場合に、ユーザーは証明書パスワードを入力したり、パスワードファイルを指定したりする必要はありません。パスワードは暗号化されているのではなく、非表示になっているだけなので、このオプションはあまり安全ではありません。

より安全に証明書を使用したい場合には、コマンド行でユーザーがパスワード入力を求められるようにサーバーを設定できます。この場合、ユーザーは autostart、 backup、disable-service、enable-service、 info、reindex、restore、および stop 以外の dsadm のすべてのサブコマンドに対して証明書データベースのパスワードを入力する必要があります。証明書データベースは、ディレクトリ instance-path/alias にあります。

ユーザーが証明書のパスワード入力を求められるようにサーバーを設定する

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

1. サーバーを停止します。

   $ dsadm stop instance-path

2. パスワードプロンプトフラグを on に設定します。

   $ dsadm set-flags instance-path cert-pwd-prompt=on

   証明書に対してパスワードを設定するよう求められます。

3. 次のように入力して、サーバーを起動します。

   $ dsadm start instance-path

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

Directory Server のインスタンスをバックアップする場合、Directory Server の設定と証明書をバックアップします。バックアップされた証明書は archive-path/alias ディレクトリに格納されます。

Directory Server のバックアップと復元の方法については、「障害回復用のバックアップを作成する」を参照してください。

SSL 通信の設定

この節では、SSL の有効化と無効化に関する手順について説明します。

セキュリティー保護されていない接続の無効化

サーバーインスタンスが作成されると、デフォルトで LDAP クリアポートとセキュア LDAP ポート (LDAPS) が作成されます。しかし、サーバーが SSL を介してのみ通信するように SSL 以外の通信を無効にする場合もあります。

SSL 接続は、デフォルトの自己署名付き証明書で有効になります。希望する場合は、自分の証明書をインストールできます。サーバーの起動後の証明書の管理と、SSL の無効化の手順については、第 5 章「Directory Server のセキュリティー」を参照してください。証明書、証明書データベース、CA 署名付きサーバー証明書の入手の概要については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

LDAP クリアポートを無効にする

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

1. LDAP クリアポートを無効にします。

   セキュリティー保護されていないポートを無効にするには、LDAP セキュアポートにバインドします。この例は、ホストサーバー host1 上のデフォルトの LDAP セキュアポート 1636 へのバインドを示しています。

   $ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled

2. 変更内容を有効にするために、サーバーを再起動します。

   $ dsadm restart /local/ds

   これで、セキュリティー保護されていないポートにバインドすることはできなくなります。

暗号化方式の選択

暗号化方式は、データを暗号化、復号化するために使用するアルゴリズムです。一般に、暗号化に使用するビット数が多いほど、強度と安全性は高まります。SSL の暗号化方式は、使用するメッセージ認証のタイプによっても識別されます。メッセージ認証は、データの整合性を保証するチェックサムを計算する別のアルゴリズムです。

クライアントがサーバーとの SSL 接続を開始するときは、情報の暗号化にどの暗号を使用するかについて、クライアントとサーバーが合意する必要があります。双方向の暗号化プロセスでは、必ず、送信側と受信側の両方が同じ暗号化方式を使用する必要があります。使用する暗号化方式は、サーバーが保存している暗号化方式の一覧の現在の順序によって決まります。サーバーは、その一覧内でクライアントに提示された暗号化方式に一致する最初の暗号化方式を選択します。Directory Server のデフォルトの暗号化方式値は all です。これは、背後の SSL ライブラリにサポートされている既知のセキュリティー保護されたすべての暗号化方式を意味します。ただし、この値は特定の暗号化方式のみを受け入れるように変更できます。

Directory Server で使用できる暗号化方式の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

暗号化方式を選択する

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

1. サーバーに対して SSL が有効であることを確認します。

   「SSL 通信の設定」を参照してください。

2. 使用可能な SSL 暗号化方式を表示します。

   $ dsconf get-server-prop -h host -p port ssl-supported-ciphers ssl-supported-ciphers : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ssl-supported-ciphers : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ssl-supported-ciphers : TLS_DHE_RSA_WITH_AES_256_CBC_SHA ssl-supported-ciphers : TLS_DHE_DSS_WITH_AES_256_CBC_SHA ...

3. (省略可能) 暗号化されていないデータのコピーを維持する場合は、SSL 暗号化方式を設定する前にデータをエクスポートします。

   「LDIF へのエクスポート」を参照してください。

4. SSL 暗号化方式を設定します。

   $ dsconf set-server-prop -h host -p port ssl-cipher-family:cipher

   たとえば、暗号ファミリを SSL_RSA_WITH_RC4_128_MD5 と SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA に設定するには、次のように入力します。

   $ dsconf set-server-prop -h host1 -P 1636 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \ ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA Enter "cn=Directory Manager" password: Before setting SSL configuration, export Directory Server data. Do you want to continue [y/n] ? y Directory Server must be restarted for changes to take effect.

5. (省略可能) 既存のリストに SSL 暗号化方式を追加します。

   指定した暗号化方式のリストがすでに存在し、そのリストに暗号化方式を追加する場合は、次のコマンドを使用します。

   $ dsconf set-server-prop -h host -p port ssl-cipher-family+:cipher

   たとえば、SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 暗号化方式を追加するには、次のように入力します。

   $ dsconf set-server-prop -h host1 -P 1636 \ ssl-cipher-family+:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

6. 変更内容を有効にするために、サーバーを再起動します。

   $ dsadm restart /local/ds

資格レベルと認証方法の設定

クライアントに適用されるセキュリティーモデルは、資格レベルと認証方法の組み合わせで定義されます。

Directory Server では、次の資格レベルがサポートされています。

• 匿名。ディレクトリの特定部分に匿名アクセスを許可することは、そのディレクトリへのアクセス権を持つすべてのユーザーに読み取りアクセス権を与えることを意味します。

  匿名資格レベルを使用する場合、すべての LDAP ネームエントリおよび属性に読み取りアクセスを許可する必要があります。

  ---

  注意 –

  匿名でのディレクトリへの書き込みアクセスは許可しないでください。これを許可すると、どのユーザーでも、書き込みアクセス権のある DIT 内の情報 (別のユーザーのパスワードや自分自身の識別情報など) の変更が可能になります。

  ---

• プロキシ。クライアントは、プロキシアカウントを使用してディレクトリへの認証またはバインドを行います。

  このプロキシアカウントには、ディレクトリへのバインドを許可されるエントリを設定できます。このプロキシアカウントは、ディレクトリでネームサービス機能を実行するための十分なアクセス権を必要とします。プロキシ資格レベルを使用して、すべてのクライアントで proxyDN および proxyPassword を設定する必要があります。暗号化された proxyPassword はクライアントのローカルに格納されます。

• 匿名プロキシ。複数の資格レベルが定義された複数値エントリ。

  匿名プロキシレベルを割り当てられたクライアントは、最初にそのプロキシ識別情報を使用して認証を試みます。ユーザーのロックアウトやパスワードの有効期限切れなど何らかの理由でプロキシユーザーとして認証できなかった場合、クライアントは匿名アクセスを使用します。この場合、ディレクトリの構成によっては、別のサービスレベルに移行する可能性があります。

クライアント認証は、クライアントのアイデンティティーを確認するためのサーバーのメカニズムです。

クライアント認証は、次のいずれかの方法で実行できます。

• DN とパスワードを提供する。

• クライアントによって提供された証明書を使用する。

  証明書ベースの認証では、SSL プロトコルを介して入手したクライアント証明書を使用して、ユーザーエントリの識別情報が検出されます。証明書ベースの認証では、クライアントが外部メカニズムを指定する SASL バインド要求を送信します。バインド要求は、すでに確立された SSL 認証メカニズムに依存します。

• SASL ベースのメカニズムを使用する。

  • すべてのオペレーティングシステムで、DIGEST-MD5 による SASL。

  • Solaris オペレーティングシステムで、Kerberos V5 によるクライアント認証が可能である、GSSAPI メカニズムによる SASL 。

  2 つのうちどちらの SASL メカニズムを使用する場合も、アイデンティティーのマッピングを行うようにサーバーを設定する必要があります。SASL 資格は、 主体と呼ばれます。主体の内容のバインド DN を決定するために、各メカニズムに特定のマッピングが必要です。主体が 1 つのユーザーエントリにマッピングされ、SASL メカニズムがそのユーザーのアイデンティティーを検証すると、ユーザーの DN がその接続のバインド DN となります。

• SSL クライアント認証モードを使用する。

  SSL 層ですべてのクライアントが認証されるようにするには、SSL クライアント認証を使用します。クライアントアプリケーションは、SSL 証明書をサーバーに送信することで認証を行います。SSL-client-auth-mode フラグを使用して、サーバーが SSL クライアント認証を許可する、要求する、または許可しないよう指定します。デフォルトでは、クライアントは認証を許可されます。

この節では、Directory Server での 2 つの SASL メカニズムの設定に関する次の情報について説明します。

• 「Directory Server での SASL 暗号化レベルの設定」

• 「DIGEST-MD5 を利用した SASL 認証」

• 「GSSAPI を利用した SASL 認証 (Solaris OS のみ)」

セキュリティーの設定の詳細については、「LDAP クライアントでセキュリティーを使用するための設定」を参照してください。

Directory Server での SASL 暗号化レベルの設定

SASL メカニズムを設定する前に、暗号化が必要かどうかを指定する必要があります。SASL 暗号化の要件は、最大および最小 SSF (Strength Security Factor) によって設定されます。

属性 dsSaslMinSSF(5dsat) および dsSaslMaxSSF(5dsat) は、暗号化鍵の長さを示します。これらは、cn=SASL, cn=security, cn=config に保存されています。

サーバーに対しては、暗号化しないという選択肢も含めて、すべてのレベルの暗号化を設定できます。つまり、Directory Server は 256 より大きい dsSaslMinSSF 値と dsSaslMaxSSF 値を受け入れます。しかし、現在 SASL メカニズムは 128 より大きい SSF をサポートしません。Directory Server はこれらの値のネゴシエーションを行い最大限の SSF 値 (128) にします。このため、使用されるメカニズムによっては、実際の最大 SSF 値は、設定された最大値より小さい可能性があります。

SASL セキュリティーファクタ認証は、次の 2 つの主要な項目に基づきます。サーバーとクライアントアプリケーションによって要求される最小ファクタと最大ファクタ、および使用可能な暗号化メカニズム。これらは背後のセキュリティーコンポーネントによって提供されます。つまり、サーバーとクライアントは両方で設定された最大ファクタ以下で、両方で設定された最小ファクタ以上の、使用可能な中で最も大きいセキュリティーファクタを使用しようとします。

Directory Server に対するデフォルトの最小 SASL セキュリティーファクタである dsSaslMinSSF は 0 で、保護されていないことを示します。実際の最小値は、Directory Server の最小値を変更しない限り、クライアント設定によって変わります。実際は、サーバーとクライアントに使用する最低レベルに最小値を設定します。サーバーとクライアントが最低要件を満たすメカニズムのネゴシエーションに失敗した場合、接続は確立されません。

SASL 暗号化を要求する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. SASL 暗号化を要求するにはdsSaslMinSSF 値を最低限必要な暗号化に設定します。

   $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify replace: dsSaslMinSSF dsSaslMinSSF: 128 ^D

SASL 暗号化を許可しない

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. SASL 暗号化を許可しない場合は dsSaslMinSSF と dsSaslMaxSSF の両方の値をゼロに設定します。

   $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify replace: dsSaslMinSSF dsSaslMinSSF: 0 replace: dsSaslMaxSSF dsSaslMaxSSF: 0 ^D

DIGEST-MD5 を利用した SASL 認証

DIGEST-MD5 メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワードを持つ必要があります。{CLEAR} パスワードをディレクトリに保存する場合に、第 6 章「Directory Server のアクセス制御」で説明されているように、パスワード値へのアクセスが ACI によって正しく制限されていることを確認する必要があります。さらに、「属性値の暗号化」で説明しているように、サフィックスで属性の暗号化を設定する必要があります。

DIGEST-MD5 メカニズムを設定する

次の手順は、DIGEST-MD5 を使用するように Directory Server を設定する方法を説明しています。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. DIGEST-MD5 がルートエントリ上で supportedSASLMechanisms 属性の値であることを確認するには、ldapsearch コマンドを使用します。

   たとえば、次のコマンドはどの SASL メカニズムが有効であるかを表示します。

   $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -s base -b "" "(objectclass=*)" supportedSASLMechanisms Enter bind password: dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: GSSAPI ^D

2. DIGEST-MD5 が有効でない場合は、有効にします。

   $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=SASL, cn=security, cn=config changetype: modify add: dsSaslPluginsEnable dsSaslPluginsEnable: DIGEST-MD5 - replace: dsSaslPluginsPath dsSaslPluginsPath: SASL-library ^D

   ここで、SASL-library は次のいずれかです。

   JES installation

   /usr/lib/mps/sasl2

   Zip installation

   install-path/dsee6/private/lib

3. DIGEST-MD5 のデフォルトのアイデンティティーマッピングを使用するか新規作成します。

   詳細については、「DIGEST-MD5 アイデンティティーマッピング」を参照してください。

4. DIGEST-MD5 を使用する SSL 経由でサーバーにアクセスするすべてのユーザーのパスワードが {CLEAR} に含まれていることを確認します。

   パスワード保存スキーマについては、第 7 章「Directory Server のパスワードポリシー」を参照してください。

5. SASL 設定エントリまたは DIGEST-MD5 アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

DIGEST-MD5 アイデンティティーマッピング

SASL メカニズムの アイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。このメカニズムの詳細な説明については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

SASL アイデンティティーは、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。DIGEST-MD5 では、クライアントは、dn: プレフィックスと LDAP DN、または u: プレフィックスの後にクライアントが決定するテキストを続けた情報のいずれかが含まれる主体を作成すべきです。マッピング時に、クライアントが送信した主体は、${Principal}プレースホルダで使用されます。

サーバー設定内の次のエントリは、DIGEST-MD5 のデフォルト アイデンティティーマッピングです。

dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: \$1

このアイデンティティーマッピングは、主体の dn フィールドに、ディレクトリ内の既存ユーザーの正確な DN が含まれていることを前提としています。

DIGEST-MD5 用の独自のアイデンティティーマッピングを定義する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. cn=DIGEST-MD5,cn=identity mapping,cn=config の下でデフォルトのマッピングエントリを編集するか、新しいマッピングエントリを作成します。

   次のコマンドは、このマッピングを定義する方法を示しています。

   $ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping cn=config objectclass: dsIdentityMapping objectclass: dsPatternMatching objectclass: nsContainer objectclass: top cn: unqualified-username dsMatching-pattern: \${Principal} dsMatching-regexp: u:(.*)@(.*)\\.com dsSearchBaseDN: dc=\$2 dsSearchFilter: (uid=\$1)

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

GSSAPI を利用した SASL 認証 (Solaris OS のみ)

SASL 上の GSSAPI (Generic Security Service API) では、クライアントを認証するために、Kerberos V5 などのサードパーティーのセキュリティーシステムを使用できます。GSSAPI ライブラリは、Solaris OS SPARC® プラットフォームの場合にのみ使用できます。Sun Enterprise Authentication Mechanism^TM 1.0.1 サーバーに Kerberos V5 実装をインストールすることをお勧めします。

サーバーは、GSSAPI を使用してユーザーの識別情報を検証します。次に、SASL メカニズムは GSSAPI マッピングルールを適用して、この接続中のすべての操作のバインド DN となる DN を取得します。

Keberos システムを設定する

製造元の指示に従って、Kerberos ソフトウェアを設定します。Sun Enterprise Authentication Mechanism 1.0.1 サーバーを使用している場合、次の手順を使用します。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. /etc/krb5内のファイルを設定します。

2. ユーザーとサービスを保存するために Kerberos データベースを作成します。

3. データベース内で LDAP サービスの主体を作成します。

   $ ldap/server-FQDN@realm

   ここで、server-FQDN は Directory Server の完全修飾ドメイン名です。

4. Kerberos デーモンプロセスを開始します。

   ---

   注 –

   DNS は、ホストマシンに設定されている必要があります。

   ---

   各手順の詳細については、ソフトウェアのマニュアルを参照してください。「GSSAPI と SASL を使用した Kerberos 認証の設定例」も参照してください。

GSSAPI メカニズムを設定する

次の手順は、Solaris OS 上で GSSAPI を使用するよう Directory Server を設定する方法を説明しています。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. 「GSSAPI アイデンティティーマッピング」での説明に従って、GSSAPI のデフォルトアイデンティティーマッピングと任意のカスタムマッピングを作成します。

2. サービスキーを保存するために鍵タブを作成します。

   LDAP サービスキーは、鍵タブに保存されます。

   1. 鍵タブは必ず Directory Server ユーザーのみが読み取れるようにします。

   2. ファイル名をデフォルトの /etc/krb5/krb5.keytab から変更します。

   3. デフォルトの鍵タブではなく、必ず新しい鍵タブが使用されるように、環境変数 KRB5_KTNAME を設定します。

3. SASL 設定エントリまたは GSSAPI アイデンティティーマッピングエントリの 1 つを変更した場合は、Directory Server を再起動します。

   DNS は、ホストマシンに設定されている必要があります。

GSSAPI アイデンティティーマッピング

SASL メカニズムのアイデンティティーマッピングは、SASL アイデンティティーの資格をディレクトリ内のユーザーエントリと一致させようとします。マッピングによって、SASL アイデンティティーに対応する DN が見つからなかったときは、認証は失敗します。

SASL アイデンティティーは、Principal という文字列です。これは、各メカニズムに固有の形式でユーザーを表します。Kerberos で GSSAPI を使用した主体は uid [/instance][@ realm] という形式のアイデンティティーです。uid にはオプションの instance ID を含め、オプションの realm を続けることができます。これはドメイン名の場合があります。次の例は、いずれも有効なユーザー主体です。

bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM

最初は、ディレクトリ内には GSSAPI マッピングは定義されていません。デフォルトのマッピングを定義し、使用する主体をクライアントがどのように定義するかに応じてカスタムマッピングを定義する必要があります。

GSSAPI 用のアイデンティティーマッピングを定義する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. cn=GSSAPI,cn=identity mapping, cn=config の下に新しいマッピングエントリを作成します。

   アイデンティティーマッピングエントリ内の属性の定義については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。GSSAPI のマッピングの例は、instance-path/ldif/identityMapping_Examples.ldif にあります。

   このファイル内のデフォルト GSSAPI マッピングは、主体にユーザー ID のみが含まれていることを前提としています。このマッピングは、ディレクトリの固定ブランチでユーザーを決定します。

   dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config objectclass: dsIdentityMapping objectclass: nsContainer objectclass: top cn: default dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com

   このファイルに含まれるもう 1 つの例は、既知のレルムを含む主体にユーザー ID が記録されている場合に、ユーザー ID を決定する方法を示しています。

   dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config objectclass: dsIdentityMapping objectclass: dsPatternMatching objectclass: nsContainer objectclass: top cn: same_realm dsMatching-pattern: \${Principal} dsMatching-regexp: (.*)@EXAMPLE.COM dsMappedDN: uid=\$1,ou=people,dc=EXAMPLE,dc=COM

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

LDAP クライアントでセキュリティーを使用するための設定

次に、Directory Server とセキュリティー保護された接続を確立する LDAP クライアント内で SSL を設定および使用する方法を説明します。SSL 接続では、サーバーがクライアントに証明書を送信します。クライアントは、まず最初に証明書を信頼することで、サーバーが信頼できるものであることを確認します。次に、必要に応じてクライアントは独自の証明書または SASL メカニズム (2 つのうち 1 つ) の情報を送信することで、いずれかのクライアント認証メカニズムを開始できます。SASL メカニズムは、Kerberos V5 を使用した DIGEST-MD5 および GSSAPI です。

次の各項では、SSL が有効な LDAP クライアントの例として、ldapsearch ツールを使用します。

他の LDAP クライアントに SSL 接続を設定する方法については、アプリケーションに付属するマニュアルを参照してください。

クライアントアプリケーションによっては、SSL を実装しても、信頼された証明書がサーバーにあるかどうかを検証しません。これらのクライアントアプリケーションは SSL プロトコルを使用してデータの暗号化を行いますが、機密の保護を保証することも第 3 者がユーザーとして認証されることを防止することもできません。

次の項では、セキュリティーを使用するために LDAP クライアントを設定する方法を説明します。

クライアントでの SASL DIGEST-MD5 の使用

クライアントで DIGEST-MD5 メカニズムを使用している場合、ユーザー証明書をインストールする必要はありません。ただし、暗号化された SSL 接続を利用するには、「証明書の管理」で説明した方法で、サーバー証明書を信頼する必要があります。

レルムの指定

レルムは、認証アイデンティティーが選択される名前空間を定義します。DIGEST-MD5 認証では、特定のレルムに対して認証を行う必要があります。

Directory Server は、DIGEST-MD5 のデフォルトレルムとして、マシンの完全修飾ホスト名を使います。サーバーは、nsslapd-localhost 設定属性に含まれる小文字のホスト名を使用します。

レルムを指定しない場合、サーバーが提供するデフォルトのレルムが適用されます。

環境変数の指定

UNIX 環境では、LDAP ツールが DIGEST-MD5 ライブラリを見つけることができるように、SASL-PATH 環境変数を設定する必要があります。DIGEST-MD5 ライブラリは、SASL プラグインに動的に読み込まれる共有ライブラリです。SASL_PATH 環境変数を次のように設定します。

export SASL_PATH=SASL-library

このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

ldapsearch コマンドの例

SSL を使用せずに DIGEST-MD5 クライアント認証を実行することができます。次の例は、デフォルトの DIGEST-MD5 アイデンティティーマッピングを使用してバインド DN を決定します。

$ ldapsearch -h host1 -p 1389 \
 -o mech=DIGEST-MD5 [ \
 -o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -w - \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=56,maxssf=256,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

上の例は、-o (小文字の o) オプションを使用して SASL オプションを指定しています。レルムの指定は省略できますが、指定する場合は、サーバーホストマシンの完全修飾ドメイン名を指定する必要があります。プロキシ操作を対象とする authzid は使用されませんが、authid と authzid はどちらも必要であり、同じ値を指定する必要があります。-w パスワードオプションは authid に適用されます。

authid の値は、アイデンティティーマッピングで使用される主体です。authid には、ディレクトリ内の有効なユーザー DN が後に続くdn: プレフィックス か、クライアントが決定した任意の文字列が後に続く u: プレフィックスが含まれているはずです。このように authid を使用すると、「DIGEST-MD5 アイデンティティーマッピング」で説明しているマッピングを使用することができます。

最も一般的な設定は、クライアント認証のために LDAPS セキュアポートと DIGEST-MD5 を使用して暗号化を行う SSL 接続に対する設定です。次の例は、同じ処理を SSL 経由で実行します。

$ ldapsearch -h host1 -P 1636 \
 -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \
 -N "cert-example" -w - \
 -o mech=DIGEST-MD5 [-o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=0,maxssf=0,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

この例では、SSL を経由して処理を行う場合に ldapsearch コマンドに -N オプションと -w オプションが必要です。ただし、これらのオプションはクライアント認証には使用されません。その代わりに、サーバーは authid の値に含まれる主体の DIGEST-MD5 アイデンティティーマッピングを行います。

クライアントでの Kerberos SASL GSSAPI の使用

クライアントで GSSAPI メカニズムを使用する場合、ユーザー認証をインストールする必要はありませんが、Kerberos V5 セキュリティーシステムを設定する必要があります。また、暗号化された SSL 接続を使用する場合、「証明書の管理」で説明しているように、サーバー証明書を信頼します。

ホスト上で Kerberos V5 を設定する

LDAP クライアントを実行するホストマシンで Kerberos V5 を設定する必要があります。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. インストール手順に従って Kerberos V5 をインストールします。

   Sun Enterprise Authentication Mechanism 1.0.1 クライアントソフトウェアをインストールすることをお勧めします。

2. Kerberos ソフトウェアを設定します。

   Sun Enterprise Authentication Mechanism ソフトウェアを使用して、/etc/krb5 の下のファイルを設定します。この設定は、kdc サーバーを設定し、デフォルトレルムと Kerberos システムが必要とするその他の設定を定義します。

3. kerberos_v5 に関する行が先頭になるように、必要に応じて /etc/gss/mech ファイルを編集します。

Kerberos 認証の SASL オプションを設定する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. GSSAPI メカニズムで有効にするクライアントアプリケーションを使用する前に、ユーザーの主体で Kerberos セキュリティーシステムを起動します。

   $ kinit user-principal

   ここで、user-principal は、お使いの SASL アイデンティティーです。たとえば、bjensen@example.com となります。

2. Kerberos の使用を設定する SASL オプションを指定します。

   UNIX 環境では、SASL_PATH 環境変数を SASL ライブラリの正しいパスに設定します。Korn シェルでの設定例は次のようになります。

   $ export SASL_PATH=SASL-library

   このパスは、Directory Server が LDAP ツールが起動されたホストと同じホストにインストールされていることを前提としています。

   次に示す ldapsearch ツールの例は、-o (小文字の o) オプションを使用して Kerberos の使用を設定する SASL オプションを指定する方法を示しています。

   $ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \ -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

   authid は、kinit コマンドによって初期化された Kerberos キャッシュに含まれるので、省略することができます。authid を指定する場合、プロキシ操作を対象とする authzid は使用されませんが、authid と authzid にはどちらにも同じ値を指定する必要があります。authid の値は、アイデンティティーマッピングで使用される主体です。レルムを含み、主体はすべて完全な主体にする必要があります。「GSSAPI アイデンティティーマッピング」を参照してください。

GSSAPI と SASL を使用した Kerberos 認証の設定例

Directory Server に対する Kerberos の設定は、複雑な場合があります。最初に Kerberos のマニュアルを参照してください。

さらに詳細について知りたい場合は、次に示す手順例を参考にしてください。ただし、この手順は例であることを忘れないでください。自分の設定と環境に合わせて手順を変更してください。

Solaris OS での Kerberos の設定と使用の詳細については、『System Administration Guide: Security Services』を参照してください。このマニュアルは Solaris マニュアルセットの一部です。マニュアルページを参照することもできます。

この例についての情報と使用する手順は、次のとおりです。

1. 「この例の前提」

2. 「すべてのマシン: Kerberos クライアント設定ファイルの編集」

3. 「すべてのマシン: 管理サーバー ACL 設定ファイルの編集」

4. 「KDC マシン: KDC サーバー設定ファイルの編集」

5. 「KDC マシン: KDC データベースの作成」

6. 「KDC マシン: 管理の主体と鍵タブの作成」

7. 「KDC マシン: Kerberos デーモンの開始」

8. 「KDC マシン: KDC マシンと Directory Server マシンに対するホスト主体の追加」

9. 「KDC マシン: Directory Server に対する LDAP 主体の追加」

10. 「KDC マシン: KDC へのテストユーザーの追加」

11. 「Directory Server マシン: Directory Server のインストール」

12. 「Directory Server マシン: GSSAPI を有効にするための Directory Server の設定」

13. 「Directory Server マシン: Directory Server 鍵タブの作成」

14. 「Directory Server マシン: Directory Server へのテストユーザーの追加」

15. 「Directory Server マシン: テストユーザーとしての Kerberos チケットの取得」

16. 「クライアントマシン: GSSAPI による Directory Server に対する認証」

この例の前提

この手順例では、1 つ目のマシンを KDC (Key Distribution Center) として操作し、2 つ目のマシンでは Directory Server を実行できるように設定する処理について説明します。この手順の結果として、ユーザーは GSSAPI によって Kerberos 認証を実行できるようになります。

同じマシン上で KDC と Directory Server の両方を実行することもできます。両方を同じマシン上で実行することを選択した場合にも同じ手順を使用できます。この場合、KDC マシンと Directory Server マシンで重複する手順は、一度行うだけで済みます。

この手順では、使用される環境に関する多くの前提条件が発生します。手順例を使用する場合は、環境に合わせて値を変更してください。前提は次のとおりです。

• このシステムには、推奨される最新のパッチクラスタのインストールされた最新の Solaris 9 ソフトウェアをインストールします。適切な Solaris パッチがインストールされていない場合、Directory Server に対する Kerberos 認証は失敗する可能性があります。

  マニュアルに記述された手順は Solaris 10 とほとんど同じですが、いくつかの違いがあります。設定ファイルの形式が少しだけ異なるため、いくつかのコマンドの出力が同じでない場合もあります。

• Kerberos デーモンを実行するマシンには、kdc.example.com という完全修飾ドメイン名を付けます。このマシンは、ネームサービスに DNS を使用するように設定する必要があります。この設定は、Kerberos の要件です。file など、ほかのネームサービスを代わりに使用すると、特定の操作が失敗することもあります。

• Directory Server を実行するマシンには、directory.example.com という完全修飾ドメイン名を付けます。このマシンも、ネームサービスに DNS を使用するように設定する必要があります。

• Directory Server マシンは、Kerberos によって Directory Server に対する認証を行うためのクライアントシステムとしての役割を果たします。この認証は、Directory Server と Kerberos デーモンの両方と通信できる任意のシステムから実行できます。しかし、この例で必要なコンポーネントはすべて、Directory Server によって提供され、認証はこのシステムから実行されます。

• Directory Server のユーザーには、uid= username,ou=People,dc=example,dc=com という形式の DN があります。対応する Kerberos 主体は、username@EXAMPLE.COM です。別のネーミングスキームを使用する場合は、別の GSSAPI アイデンティティーマッピングを使用する必要があります。

すべてのマシン: Kerberos クライアント設定ファイルの編集

/etc/krb5/krb5.conf 設定ファイルは、KDC と通信するために Kerberos クライアントが必要とする情報を提供しています。

Kerberos を使用して Directory Server に対する認証を行う KDC マシン、Directory Server マシン、および任意のクライアントマシン上の /etc/krb5/krb5.conf 設定ファイルを編集します。

• "___default_realm___" をすべて "EXAMPLE.COM" に置き換えます。

• "___master_kdc___" をすべて "kdc.example.com" に置き換えます。

• "___slave_kdcs___" の含まれる行を削除して、Kerberos サーバーが 1 つしか存在しないようにします。

• "___domain_mapping___" を ".example.com = EXAMPLE.COM" に置き換えます (.example.com の最初のピリオドに注意)。

更新された /etc/krb5/krb5.conf 設定ファイルは、次の例の内容のようになります。

例 5–1 編集後の kerberos クライアント設定ファイル /etc/krb5/krb5.conf

#pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#

[libdefaults]
        default_realm = EXAMPLE.COM
[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }
[domain_realm]
        .example.com = EXAMPLE.COM
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {

# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
                period = 1d

# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
                versions = 10
        }

[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url =
 http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        }

すべてのマシン: 管理サーバー ACL 設定ファイルの編集

/etc/krb5/kadm5.acl 設定ファイル内で、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 5–2 編集後の管理サーバー ACL 設定ファイル

#
# Copyright (c) 1998-2000 by Sun Microsystems, Inc.
# All rights reserved.
#
# pragma ident   "@(#)kadm5.acl  1.1     01/03/19 SMI"
*/admin@EXAMPLE.COM *

KDC マシン: KDC サーバー設定ファイルの編集

/etc/krb5/kdc.conf ファイルで、"___default_realm___" を "EXAMPLE.COM" に置き換えます。更新されたファイルは、次の例のようになります。

例 5–3 編集後の KDC サーバー設定ファイル /etc/krb5/kdc.conf

# Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"

[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

KDC マシン: KDC データベースの作成

$ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database ’/var/krb5/principal’ for realm ’EXAMPLE.COM’,
master key name ’K/M@EXAMPLE.COM’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: password
Re-enter KDC database master key to verify: password
$

KDC マシン: 管理の主体と鍵タブの作成

次のコマンドを使用して、kws/admin@EXAMPLE.COM という主体の管理ユーザーと、管理デーモンによって使用されるサービス鍵を作成します。

$ /usr/sbin/kadmin.local
kadmin.local:  add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM": secret
Re-enter password for principal "kws/admin@EXAMPLE.COM": secret
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com
Entry for principal kadmin/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com

Entry for principal changepw/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:  quit$

KDC マシン: Kerberos デーモンの開始

次のコマンドを実行して、KDC および管理のデーモンを開始します。

$ /etc/init.d/kdc start
$ /etc/init.d/kdc.master start
$

KDC プロセスはプロセス一覧に /usr/lib/krb5/krb5kdc と表示されます。管理デーモンは、/usr/lib/krb5/kadmind と表示されます。

Solaris 10 OS では、デーモンは SMF (Service Management Facility) フレームワークによって管理されます。Solaris 10 OS でデーモンを起動します。

$ svcadm disable network/security/krb5kdc
$ svcadm enable network/security/krb5kdc
$ svcadm disable network/security/kadmin
$ svcadm enable network/security/kadmin
$

KDC マシン: KDC マシンと Directory Server マシンに対するホスト主体の追加

KDC の Kerberos データベースと Directory Server マシンにホスト主体を追加するには、次の一連のコマンドを使用します。ホスト主体は、klist などの特定の Kerberos ユーティリティーによって使用されます。

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal -randkey host/kdc.example.com
Principal "host/kdc.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/kdc.example.com
Entry for principal host/kdc.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  add_principal -randkey host/directory.example.com
Principal "host/directory.example.com@EXAMPLE.COM" created.
kadmin:  ktadd host/directory.example.com
Entry for principal host/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:  quit
$

KDC マシン: Directory Server に対する LDAP 主体の追加

Directory Server で認証中のユーザーが持っている Kerberos チケットを検証できるようにするには、Directory Server が独自の主体を持っている必要があります。現在、Directory Server は ldap/fqdn@realm の主体を要求するためにハードコードされています。ここで、 fqdn は Directory Server の完全修飾ドメイン名で、realm は Kerberos レルムです。fqdn は、Directory Server のインストール時に設定される完全修飾名と一致させる必要があります。この場合、Directory Server の主体は、ldap/directory.example.com@EXAMPLE.COM となります。

Directory Server の LDAP 主体を作成するには、次の一連のコマンドを使用します。

$ /usr/sbin/kadmin -p kws/admin 
Enter Password: secret 
kadmin: add_principal -randkey ldap/directory.example.com 
Principal "ldap/directory.example.com@EXAMPLE.COM" created. 
kadmin: quit 
$

KDC マシン: KDC へのテストユーザーの追加

Kerberos 認証を実行するには、Kerberos データベース内にユーザー認証が存在している必要があります。この例では、ユーザーのユーザー名を kerberos-test にします。つまり Kerberos 主体が kerberos-test@EXAMPLE.COM になります。

この例の一連のコマンドを使用してユーザーを作成します。

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM": secret

Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret

Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:  quit
$

Directory Server マシン: Directory Server のインストール

Directory Server 6.0 と最新のパッチをインストールします。設定例は次のとおりです。

Directory Server マシン: GSSAPI を有効にするための Directory Server の設定

最初に、ファイル /data/ds/shared/bin/gssapi.ldif を作成して、主体に基づいて認証を行う Kerberos ユーザーを識別するために Directory Server によって使用されるマッピングを定義します。次の例と同じ内容のファイルを作成します。

例 5–4 gssapi.ldif ファイルの内容

dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com

dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so

次に、ldapmodify コマンドを使用して、適切なマッピングで GSSAPI を有効にするために Directory Server を更新します。次の例を参照してください。

$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif
adding new entry cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config
modifying entry cn=SASL,cn=security,cn=config
$

Directory Server マシン: Directory Server 鍵タブの作成

これまでに説明したように、GSSAPI によって Kerberos ユーザーを認証するには、Directory Server は KDC 内に独自の主体が必要です。認証が正しく行われるためには、主体情報が Directory Server マシン上の Kerberos 鍵タブ内にある必要があります。この情報は、Directory Server が動作するユーザーアカウントが読み取れるファイル内にある必要があります。

正しいプロパティーを持つ鍵タブファイルを作成するには、次の一連のコマンドを使用します。

$ /usr/sbin/kadmin -p kws/admin
Enter Password: secret
kadmin:  ktadd -k //local/ds/config/ldap.keytab ldap/directory.example.com
Entry for principal ldap/directory.example.com with kvno 3, encryption type
 DES-CBC-CRC added to keytab
 WRFILE:/local/ds/config/ldap.keytab.
kadmin:  quit
$

このカスタム鍵タブのアクセス権と所有権を変更します。鍵タブを Directory Server を実行するために使用されるユーザーアカウントの所有にし、そのユーザーしか読み取れないようにします。

$ chown unixuser:unixgroup /local/ds/config /ldap.keytab
$ chmod 600 /local/ds/config/ldap.keytab
$

Directory Server は、デフォルトではファイル /etc/kerb5/krb5.keytab 内にある標準の Kerberos の鍵タブを使用しようとします。しかし、このファイルを Directory Server ユーザーが読めるようにすると、セキュリティー上のリスクが発生する可能性があります。これが、Directory Server 用のカスタム鍵タブを作成した理由です。

新しいカスタム鍵タブを使用するよう Directory Server を設定します。これは、KRB5_KTNAME 環境変数を設定して行います。

最後に Directory Server を再起動してこれらの変更を有効にします。

$ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds 

Directory Server マシン: Directory Server へのテストユーザーの追加

Kerberos ユーザーを Directory Server に対して認証するには、そのユーザーの Kerberos 主体に対応する、ユーザーのディレクトリエントリが必要です。

これまでの手順で、kerberos-test@EXAMPLE.COM という主体を持つテストユーザーが Kerberos データベースに追加されました。ディレクトリに追加されたアイデンティティーマッピング設定のために、そのユーザーに対応するディレクトリエントリには、uid=kerberos-test,ou=People,dc=example,dc=com という DN が必要です。

ユーザーをディレクトリに追加する前に、次の内容でファイル testuser.ldif を作成する必要があります。

例 5–5 新しい testuser.ldif ファイル

dn: uid=kerberos-test,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: kerberos-test
givenName: Kerberos
sn: Test
cn: Kerberos Test
description: An account for testing Kerberos authentication through GSSAPI

次に、ldapmodify を使用して、このエントリをサーバーに追加します。

$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
$

Directory Server マシン: テストユーザーとしての Kerberos チケットの取得

テストユーザーは、Kerberos データベース、Directory Server、および KDC 内に存在します。このため、Directory Server のテストユーザーとして GSSAPI を経由した Kerberos によって認証を行うことができるようになります。

まず、kinit コマンドを使用してユーザーの Kerberos チケットを取得します。次の例を参照してください。

$ kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM: secret
$

次に、klist コマンドを使用して、このチケットに関する情報を表示します。

$ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM

Valid starting            Expires                   Service principal
Sat Jul 24 00:24:15 2004  Sat Jul 24 08:24:15 2004  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until Sat Jul 31 00:24:15 2004
$

クライアントマシン: GSSAPI による Directory Server に対する認証

最後の手順は GSSAPI を使用した Directory Server に対する認証です。Directory Server の提供する ldapsearch ユーティリティーは、GSSAPI、DIGEST-MD5、および EXTERNAL メカニズムを含む SASL 認証をサポートしています。しかし、GSSAPI を使用してバインドするために、SASL ライブラリへのパスをクライアントに設定する必要があります。SASL_PATH 環境変数を lib/sasl ディレクトリに設定してパスを提供します。

$ SASL_PATH=SASL-library
$ export SASL_PATH
$

ldapsearch を使用して Directory Server に対して実際に Kerberos ベースの認証を実行するには、-o mech=GSSAPI 引数と -o authzid=principal 引数を含める必要があります。

また、ここで -h directory.example.com と表示している完全修飾ホスト名も指定する必要があります。これは、サーバーに対する cn=config 上の nsslapd-localhost 属性の値と一致する必要があります。GSSAPI 認証プロセスでは、クライアントから提供されたホスト名がサーバーから提供されたホスト名と一致する 必要があるため、ここでは -h オプションを使用する必要があります。

次の例では、これまでに作成した Kerberos テストユーザーアカウントとして認証を行なって、dc=example,dc=com エントリを取得しています。

$ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \
 -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)"
version: 1
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
$

正常に認証されたかどうか Directory Server のアクセスログを確認します。

$ tail -12 /local/ds/logs/access

[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP 
		connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97 
     nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
     scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1 
     etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$

この例は、バインドが 3 つの手順によるプロセスであることを示しています。最初の 2 つの手順で LDAP 結果 14 (SASL バインド実行中) を返し、3 番目の手順はバインドが成功したことを示します。method=sasl タグと mech=GSSAPI タグは、このバインドに GSSAPI SASL メカニズムが使用されたことを示しています。成功したバインド応答の最後の dn="uid=kerberos-test,ou=people,dc=example,dc=com" は、このバインドが適切なユーザーとして実行されたことを示しています。

パススルー認証

パススルー認証 (PTA) は、バインド要求がバインド DN によってフィルタされるメカニズムです。ある Directory Server (委任者) がバインド要求を受け取り、フィルタに基づいて別の Directory Server (被委任者) にバインド要求を認証するよう求めることができます。この機能の一部として、PTA プラグインによって委任者である Directory Server がローカルのデータベースに保存されているとは限らないエントリに対する単純なパスワードベースのバインド操作を受け入れられるようになります。

PTA プラグインは、サーバーとの非公開の通信のために DSCC にも使用されます。サーバーインスタンスが DSCC に登録されている場合、PTA プラグインが有効になり、DSCC URL が引数として追加されます。

$ dsconf get-plugin-prop -h host -p port "Pass Through Authentication" enabled argument
argument  :  ldap://DSCC_URL:DSCC_PORT/cn=dscc
enabled   :  on

可能なかぎり、PTA プラグインを変更しないようにしてください。PTA プラグインを変更すると、DSCC のアクセス問題が発生する可能性があります。

PTA プラグインを変更しなければならない場合は、次の手順に従う必要があります。

• enabled プロパティーは on のままにします。

• argument プロパティーにほかの値を追加できますが、引数内で DSCC URL を維持します。

PTA プラグインが無効になったり、DSCC URL が引数から削除されると、サーバーインスタンスが DSCC 内に inaccessible として表示されます。この場合、DSCC が PTA プラグインをリセットするオプションを自動的に提供します。

第 6 章 Directory Server のアクセス制御

安全なディレクトリを作成する上で、ディレクトリの内容へのアクセスを制御することはもっとも重要です。この章では、ディレクトリに対してどのようなアクセス権をユー ザーに許可するかを決定する ACI ( アクセス制御命令) について説明します。

ディレクトリ配備の計画段階では、全体的なセキュリティーポリシーとして利用できるアクセス制御戦略を定義します。アクセス制御戦略の計画のヒントは、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』を参照してください。

ACI の構文やバインドルールなど、ACI のその他の情報については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』を参照してください。

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

• 「ACI の作成、表示、および変更」

• 「アクセス制御の使用例」

• 「実行権限の表示」

• 「高度なアクセス制御: マクロ ACI の使用」

• 「アクセス制御情報のログ」

• 「TCP ラップによるクライアントホストのアクセス制御」

ACI の作成、表示、および変更

ACI は、Directory Service Control Center (DSCC) を使用するかコマンド行を使用することで作成できます。どちらの方法を選択するとしても、たいていの場合、新しい ACI を最初から作成するよりも、既存の ACI 値を表示しコピーするほうが簡単です。

aci 属性値は、DSCC で表示および変更できます。DSCC による ACI の変更方法については、DSCC のオンラインヘルプを参照してください。

ACI を作成、変更、および削除する

コマンド行を使用して ACI を作成するには、最初に LDIF 文を使ってファイル内に ACI を作成します。次に、ldapmodify コマンドを使用して ACI をディレクトリツリーに追加します。

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

1. LDIF ファイル内に ACI を作成します。

   dn: dc=example,dc=com changetype: modify add: aci aci: (target)(version 3.0; acl "name";permission bindrules;)

   この例は ACI の追加方法を示しています。ACI を変更または削除する場合は、add を replace または delete に置き換えます。

   よく使われるその他の ACI の例については、「アクセス制御の使用例」を参照してください。

2. LDIF ファイルを使って変更を加えます。

   $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file

ACI 属性値を表示する

ACI はエントリの aci 属性の値として格納されます。aci 属性は、複数の値を持つオペレーショナル属性であり、ディレクトリユーザーはこの属性の読み取りや変更を行うことができます。このため、ACI 属性自体が ACI で保護される必要があります。通常、管理ユーザーには、aci 属性へのすべてのアクセス権が与えられます。

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

1. 次の ldapsearch コマンドを実行して、エントリの ACI 属性値を表示します。

   $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b entryDN -s base "(objectclass=*)" aci

   このコマンドで得られた LDIF テキストを、新しい LDIF ACI 定義にコピーして編集できます。ACI の値は長い文字列なので、ldapsearch 操作からの出力は複数行にわたって表示されることがあります。この場合、最初の空白は継続マーカーになります。LDIF の出力に継続マーカーを入れないようにするには、-T オプションを使用します。LDIF の出力をコピーおよびペーストする場合は、出力形式について考慮してください。

   ---

   注 –

   値 aci が権限を与えるか拒否するかを確認する場合は、「実行権限の表示」を参照してください。

   ---

ACI をルートレベルで表示する

サフィックスを作成すると、いくつかのデフォルトの ACI が最上位またはルートレベルで作成されます。これらの ACI により、デフォルトの管理者ユーザー cn=admin,cn=Administrators,cn=config が、ディレクトリマネージャーと同じディレクトリデータへのアクセス権限を持つことができます。

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

1. デフォルトのルートレベル ACI を表示します。

   $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "" -s base "(objectclass=*)" aci

アクセス制御の使用例

この節で示す例では、架空の ISP である Example.com 社が、アクセス制御ポリシーを決定していきます。

また、インストールに付属のサンプルの LDIF ファイルに、install_path/ds6/ldif/Example.ldif というサンプルの ACI もあります。

すべての例では、LDIF ファイルを使用して、与えられたタスクをどのように処理するかを説明しています。次の図で、example.com 社のディレクトリ情報ツリーを示します。

Example.com 社の業務は、Web ホスティングサービスとインターネットアクセスの提供です。Example.com の Web ホスティングサービスには、クライアント企業のディレクトリのホスティングが含まれます。Example.com は実際に 2 つの中規模企業のディレクトリ Company333 と Company999 をホストし、部分的に管理を行なっています。また、多数の個人加入者にインターネットへのアクセスを提供しています。

現在、Example.com 社は、次のようなアクセス規則を設定しようとしています。

• Example.com 社の社員に、Example.com ツリー全体を対象とした読み取り、検索、および比較のための匿名アクセス権を与える。「匿名アクセスの許可」を参照。

• Example.com 社の社員に、homeTelephoneNumber、homeAddress などの個人情報への書き込みアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。

• Example.com 社の契約者に、会社の連絡先情報のエントリ dc=example,dc=com の読み取り権限を与える。ただし、その下のエントリの読み取り権限は与えない。「特定のレベルへのアクセスの許可」を参照。

• Example.com 社の社員が個人のエントリにロールを追加するアクセス権を与える。ただし、一部の重要なロールは除く。「重要なロールに対するアクセスの制限」を参照。

• 特定の管理者に、サフィックスに関してディレクトリマネージャーと同じ権限を与える。 「サフィックス全体に対するすべてのアクセス権のロールへの許可」を参照。

• Example.com 社の人事部グループに、People 分岐のエントリを対象としたすべての権限を与える。「サフィックスに対するすべてのアクセス権のグループへの許可」を参照。

• Example.com 社のすべての社員に対し、ディレクトリの Social Committee エントリの下にグループエントリを作成し、社員が所有するグループエントリを削除するアクセス権を与える。「グループエントリの追加および削除権限の許可」を参照。

• Example.com 社のすべての社員に対し、Social Committee エントリの下のグループエントリに、自身を追加するアクセス権を与える。「ユーザー自身の操作によるグループへの参加とグループからの退会」を参照。

• 一定の条件付きで、ディレクトリツリーのそれぞれのエントリへのアクセス権を Company333 および Company999 のディレクトリ管理者 (ロール) に与える。これらの条件には、SSL 認証、日時の制約、位置の指定などが含まれる。「グループまたはロールへの条件付きアクセスの許可」を参照。

• 個人契約者に対し、個人のエントリへのアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。

• 個人契約者が個人のエントリ内の課金情報にアクセスできないようにする。「アクセスの拒否」を参照。

• 世界のユーザーに対し、個人契約者のサブツリーへの匿名アクセス権を与える。ただし、非公開を希望している契約者は除く。ディレクトリのこの部分は、必要に応じてファイアウォール外部から読み取り専用サーバーになることがあり、毎日 1 回更新される。「匿名アクセスの許可」および「フィルタを使用したターゲットの設定」を参照。

匿名アクセスの許可

ほとんどのディレクトリは、読み取り、検索、または比較を行うために、少なくとも 1 つのサフィックスに匿名でアクセスできるように設定されています。社員が検索できる電話帳のような、企業内の個人情報を収めたディレクトリを管理している場合、そのためのアクセス権の設定が必要になることがあります。これは Example.com 社内のケースであり、「ACI「Anonymous Example.com」」にその例が示されています。

Example.com 社では、ISP として、世界中からアクセス可能な公開電話帳を作成し、契約者全員の連絡先情報を公開することも計画しています。これについては、「ACI「Anonymous World」」で例を示しています。

ACI「Anonymous Example.com」

Example.com 社の社員に Example.com ツリー全体を対象とした読み取り、検索、および比較アクセス権を与えるには、LDIF で次のような文を作成します。

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
 example"; allow (read, search, compare)
 userdn= "ldap:///anyone") ;)

この例では、aci を dc=example,dc=com エントリに追加することを仮定しています。userPassword 属性は ACI の対象に含まれていません。

機密属性や表示すべきではない属性は、前の例でパスワード属性を保護しているのと同じように、「(targetattr !="attribute-name ")」の構文を用いて保護してください。

ACI「Anonymous World」

個人契約者サブツリーの読み取りおよび検索アクセス権を世界中に与え、非公開にする契約者の情報へのアクセスを拒否するには、LDIF で次のような文を作成します。

aci: (targetfilter= "(!(unlistedSubscriber=yes))")
 (targetattr="homePostalAddress || homePhone || mail")
 (version 3.0; acl "Anonymous World"; allow (read, search)
 userdn="ldap:///anyone";)

この例では、ACI を ou=subscribers,dc=example, dc=com エントリに追加することを仮定しています。また、各契約者のエントリには、yes または no の値を持つ unlistedSubscriber 属性が設定されているものとします。非公開契約者は、この属性値に基づいて、ターゲット定義のフィルタによって除外されます。フィルタ定義については、「フィルタを使用したターゲットの設定」を参照してください。

個人のエントリへの書き込みアクセス権の許可

多くの場合、内部ユーザーが個人で変更できるエントリの属性は、ディレクトリ管理者によって一部だけに制限されています。Example.com 社のディレクトリ管理者は、ユーザーが変更できる対象を、パスワード、自宅の電話番号、自宅住所だけに制限しようとしています。これについては、「ACI「Write Example.com」」で例を示しています。

また、Example.com 社には、契約者がディレクトリに対して SSL 接続を確立することを条件に、Example.com ツリー内にある個人情報を更新できるようにするというポリシーもあります。これについては、「ACI「Write Subscribers」」で例を示しています。

ACI「Write Example.com」

このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

Example.com 社の社員が、個人の自宅の電話番号、自宅住所を変更できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="homePhone ||
 homePostalAddress")(version 3.0; acl "Write Example.com";
 allow (write) userdn="ldap:///self" ;)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

ACI「Write Subscribers」

このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

Example.com 社の契約者が個人の自宅の電話番号を変更できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="homePhone")
 (version 3.0; acl "Write Subscribers"; allow (write)
 userdn= "ldap://self" and authmethod="ssl";)

この例では、aci を ou=subscribers,dc=example, dc=com エントリに追加し、ユーザーは SSL を使用してバインドする必要があると仮定しています。

Example.com 社の契約者は、その住所の属性を削除する可能性があるため、住所への書き込みアクセス権は与えられていません。住所は Example.com 社からの請求に重要な情報です。

特定のレベルへのアクセスの許可

ディレクトリツリー内のさまざまなレベルに影響を及ぼす ACI の範囲を設定して、許可するアクセスのレベルを微調整できます。対象の ACI の範囲は、次のいずれかに設定できます。

base

エントリ自体

onelevel

エントリ自体と 1 レベル下のすべてのエントリ

subtree

エントリ自体と、そのエントリの下のすべてのエントリ

ACI 「Read Example.com only」

Example.com 社の契約者に、会社の連絡先情報についてのエントリ dc=example,dc=com の読み取り権限は与えても、その下にあるエントリへのアクセスは許可しないようにするには、LDIF で次のような文を作成します。

aci: (targetscope="base") (targetattr="*")(version 3.0;
 acl "Read Example.com only";  allow (read,search,compare)
 userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)

この例では、ACI を dc=example,dc=com エントリに追加することを仮定しています。

重要なロールに対するアクセスの制限

ディレクトリ内のロール定義を使用して、ネットワークやディレクトリの管理などの業務に重要な機能を特定できます。

たとえば、国際的な企業のサイトで特定の時間と曜日に有効なシステム管理者のサブセットを指定する superAdmin ロールを作成する必要があるかもしれません。あるいは、特定のサイト上に、応急手当のトレーニングを受けたすべてのスタッフを含む First Aid ロールの作成が必要になることもあるかもしれません。ロール定義の作成については、「ロールの管理」を参照してください。

ロールによって、業務上あるいはビジネス上重要な機能に関するユーザー特権を与える場合は、そのロールに対するアクセス制限を考慮してください。たとえば、次の例で示すように、Example.com の社員は、superAdmin ロール以外の任意のロールを個人のエントリに追加できます。

ACI「Roles」

Example.com の社員が、superAdmin 以外の任意のロールを個人のエントリに追加できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targattrfilters="add=nsRoleDN:
 (nsRoleDN !="cn=superAdmin, dc=example, dc=com")")
 (version 3.0; acl "Roles"; allow (write)
 userdn= "ldap:///self" ;)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

サフィックス全体に対するすべてのアクセス権のロールへの許可

一部のユーザーに、サフィックスに対してディレクトリマネージャーと同じ権限を許可すると、便利な場合があります。Example.com 社の Kirsten Vaughan は Directory Server の管理者です。彼女は superAdmin のロールを持っています。このロールには、次のような利点があります。

• 管理者としてバインドし、SSL のような強力な認証を強制的に使用できることによって、セキュリティーが向上する

• ディレクトリマネージャーパスワードを知っている人が減ることによって、セキュリティーが向上する

• ログによる追跡容易性の向上

Kirsten Vaughan を cn=Administrators,cn=config グループに追加すると、ディレクトリマネージャーと同じ権限が与えられます。

サーバー全体に対してディレクトリマネージャーと同じ権限をユーザーに与える際は、「ルートアクセス権を持つ管理ユーザーを作成する」の手順に従ってください。

ACI「Full Access」

Kirsten Vaughan という管理者にディレクトリマネージャーと同じ権限を許可するには、LDIF で次のような文を使用します。

aci: (targetattr="*") (version 3.0; acl "Full Access";
 allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com"
 and authmethod="ssl" ;)

この例では、ACI がルートエントリ "" (テキストなし) に追加されると仮定しています。

サフィックスに対するすべてのアクセス権のグループへの許可

ほとんどのディレクトリには、業務上の固有の職務を特定するためのグループがあります。グループには、ディレクトリのすべてまたは一部に対してアクセス権を与えることができます。グループにアクセス権限を与えることにより、グループメンバーに個別にアクセス権限を設定する必要がなくなります。代わりに、グループにメンバーを追加することで、アクセス権限をそのメンバーに与えることができます。

たとえば、Directory Server インスタンスを作成すると、ディレクトリへのすべてのアクセス権を持つ cn=Administrators,cn=config という管理者グループがデフォルトで作成されます。

Example.com 社の人事部グループには、ディレクトリの ou=People エントリへのすべてのアクセス権が許可されています。これによって、このグループのメンバーは、「ACI 「HR」」に示すように社員のディレクトリを更新できます。

ACI 「HR」

ディレクトリの employee エントリに対するすべての権限を HR のグループに与えるには、LDIF で次のような文を作成します。

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
  groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)

この例では、ACI を次のエントリに追加することを仮定しています。

ou=People,dc=example,dc=com

グループエントリの追加および削除権限の許可

一部の企業では、業務の効率化や企業全体の活力向上につなげるため、社員自身がツリー内にエントリを作成できるようにしています。たとえば、Example.com 社には、テニス、水泳、スキー、演劇などのさまざまなクラブが組織された社内委員会があります。

Example.com 社の社員はだれでも、「ACI「Create Group」」に示すように、新しいクラブを表すグループエントリを作成できます。

「ユーザー自身の操作によるグループへの参加とグループからの退会」に示すように、Example.com 社の社員であれば、これらのグループのどれか 1 つのメンバーになることができます。

「ACI「Delete Group」」に示すように、グループエントリの変更や削除ができるのは、グループの所有者のみです。

ACI「Create Group」

Example.com 社の社員が ou=Social Committee エントリの下にグループエントリを作成できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targattrfilters="add=objectClass: 
(|(objectClass=groupOfNames)(objectClass=top))") 
(version 3.0; acl "Create Group"; allow (read,search,add) 
userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") 
and dns="*.Example.com";)

この例では、ACI を ou=Social Committee, dc=example,dc=com エントリに追加することを仮定しています。

• この ACI は、書き込みアクセス権を与えないので、エントリを変更できません。

• サーバーが top という値を追加するので、targattrfilters キーワードで objectClass=top を指定する必要があります。

• この ACI は、example.com ドメイン内のクライアントマシンにのみ適用されます。

ACI「Delete Group」

Example.com 社の社員が ou=Social Committee エントリの下に属しているグループエントリを変更または削除できるようにするには、LDIF で次のような文を作成します。

aci: (targetattr = "*") (targattrfilters="del=objectClass:
(objectClass=groupOfNames)")
 (version 3.0; acl "Delete Group"; allow (write,delete)
 userattr="owner#GROUPDN";)

この例では、aci を ou=Social Committee, dc=example,dc=com エントリに追加しています。

DSCC を使用してこの ACI を作成すると、手動編集モードでのターゲットフィルタの作成とグループ所有権の確認が必要なので、あまり効率的ではありません。

ユーザー自身の操作によるグループへの参加とグループからの退会

多くのディレクトリの ACI は、ユーザーがメーリングリストなどのグループへの参加とグループからの退会を自分で設定できるようになっています。

Example.com 社では、「ACI「Group Members」」に示すように、社員であれば ou=Social Committee サブツリーの下のどのグループエントリにも参加できます。

ACI「Group Members」

Example.com 社の社員が自分でグループへの参加を設定できるようにするには、LDIF で次のような文を作成します。

aci: (targettattr="member")(version 3.0; acl "Group Members";
 allow (selfwrite)
 (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)

この例では、ACI を ou=Social Committee,dc=example,dc=com エントリに追加することを仮定しています。

グループまたはロールへの条件付きアクセスの許可

多くの場合、ディレクトリへのアクセス特権をグループやロールに与える場合、それらの特権が、特権ユーザーになりすました侵入者から保護されていることを確認する必要があります。したがって、多くの場合、グループまたはロールへの重要なアクセス権を与えるようなアクセス制御規則には、数多くの条件が付けられます。

たとえば、Example.com 社では、ホスティングサービスの提供先企業である Company333 および Company999 に対して、それぞれ Directory Administrator ロールを作成しました。Example.com 社では、侵入者からデータを保護するために、それぞれの企業が各自でデータを管理し、独自のアクセス制御規則を決定することを求めています。

このため、Company333 と Company999 は、ディレクトリツリーのそれぞれのエントリに関してすべての権限を持っていますが、このアクセス権を行使するには次の条件を満たす必要があります。

• 証明書を使用して、SSL 経由の接続が認証されること

• アクセス要求は月曜日から木曜日の午前 8 時から午後 6 時までの間に限ること

• それぞれの企業に割り当てられた特定の IP アドレスからアクセスが要求されること

これらの条件は、各社の ACI である「Company333」と「Company999」に示されています。これらの ACI の内容は同等なので、「Company333」という ACI だけを次に示します。

ACI「Company333」

Company333 に対して、前述した条件に従ったディレクトリの自社のエントリへのすべてのアクセス権を与えるには、LDIF で次のような文を作成します。

aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all)
 (roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
 ou=corporate clients,dc=example,dc=com") and (authmethod="ssl")
 and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
 timeofday <= "1800") and (ip="255.255.123.234"); )

この例では、ACI を ou=Company333,ou=corporate-clients,dc=example,dc=com エントリに追加することを仮定しています。

アクセスの拒否

サフィックスの大半の部分に対してのアクセスをすでに許可している場合に、既存の ACI の配下にあるサフィックスの限定された範囲に対してアクセスを拒否させることもできます。

アクセスを拒否すると、アクセス制御の振る舞いが予期しないものや複雑なものになる可能性があるため、可能な限り回避してください。アクセスは、範囲、属性リスト、ターゲットフィルタなどの組み合わせを使って制限してください。

また、アクセス拒否 ACI を削除しても、権限が削除されるのではなく、ほかの ACI で設定された権限の幅が広げられます。

Directory Server は、アクセス権限を評価するとき、最初に deny 権限を読み取り、次に allow 権限を読み取ります。

次の例で、Example.com 社では、すべての契約者に対し、契約者自身のエントリにある接続時間や料金内訳などの課金情報の読み取りアクセス権を与えています。また、Example.com 社では、その情報に対する書き込みアクセス権は拒否するようにしています。読み取りアクセス権については、「ACI「Billing Info Read」」で例を示しています。deny アクセス権については、「ACI「Billing Info Deny」」で例を示しています。

ACI「Billing Info Read」

個人のエントリ内にある課金情報の読み取りアクセス権を契約者に与えるには、LDIF で次のような文を作成します。

aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Read"; allow (search,read)
  userdn="ldap:///self";)

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

ACI「Billing Info Deny」

各契約者に対し、契約者個人のエントリ内にある課金情報の変更アクセス権を拒否するには、LDIF で次のような文を作成します。

aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Deny";
 deny (write) userdn="ldap:///self";)

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

プロキシ承認

プロキシ承認方式は、特殊な形式の認証です。自分のアイデンティティーでディレクトリにバインドしたユーザーに、プロキシ承認を使用して他のユーザの権限が与えられます。

プロキシ要求を許可するように Directory Server を設定するには、次のことを行う必要があります。

• 管理者には、ほかのユーザーとしてのプロキシ権限を与える。

• 一般ユーザーには、アクセス制御ポリシーで定義されている通常のアクセス権限を与える。

ディレクトリマネージャーを除く、ディレクトリのすべてのユーザーにプロキシ権限を与えることができます。また、ディレクトリマネージャーの DN をプロキシ DN として使用することはできません。プロキシ権限により、すべての DN (ディレクトリマネージャー DN を除く) をプロキシ DN として指定する権限が与えられるので、プロキシ権限を与える場合には十分な注意が必要です。同じ操作中に Directory Server が複数のプロキシ認証の制御を受け取った場合は、クライアントアプリケーションにエラーが返され、操作の試行は失敗します。

プロキシ認証の例

Example.com 社は、MoneyWizAcctSoftware としてバインドするクライアントアプリケーションに、Accounting Administrator と同じ LDAP データへのアクセス権限を与えようとしています。

次の条件が適用されます。

• クライアントアプリケーションのバインド DN は uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com。

• クライアントアプリケーションがアクセスを要求するターゲットサブツリーは ou=Accounting,dc=example,dc=com。

• ディレクトリ内に、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持つ Accounting Administrator が存在する。

クライアントアプリケーションが Accounting サブツリーへのアクセス権を取得するには、Accounting Administrator と同じアクセス権を使用して、次の条件を満たす必要があります。

• Accounting Administrator は、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持っている必要がある。たとえば、次の ACI は Accounting Administrator エントリに対するすべての権限を与えます。

  aci: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)

• クライアントアプリケーションに対するプロキシ権限を与える次の ACI が、ディレクトリ内に存在する必要がある。

  aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware"; allow (proxy) userdn= "ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)

この ACI が設定されていれば、MoneyWizAcctSoftware クライアントアプリケーションがディレクトリにバインドしてから、プロキシ DN のアクセス権限を要求する ldapsearch や ldapmodify などの LDAP コマンドを送信できます。

この例で、クライアントが ldapsearch コマンドを実行する場合は、このコマンドに次の制御が含まれます。

$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
 -y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

クライアントはそのままバインドしますが、プロキシエントリの特権が与えられます。クライアントには、プロキシエントリのパスワードは必要ありません。

フィルタを使用したターゲットの設定

ディレクトリ内に分散した多数のエントリに対して、アクセス制御の設定が必要な場合は、フィルタを使用してターゲットを設定することもできます。

フィルタを使って HR のすべてのユーザーに従業員エントリへのアクセスを許可するには、LDIF で次のような文を作成します。

aci: (targetattr="*") (targetfilter=(objectClass=employee))
 (version 3.0; acl "HR access to employees";
 allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)

この例では、ACI を ou=People,dc=example,dc=comエントリに追加することを仮定しています。

検索フィルタは、アクセス管理の対象となるオブジェクトを直接指定するわけではないので、誤ったオブジェクトへのアクセスを許可または拒否しないようにしてください。ディレクトリ構造が複雑になるほど、誤ったオブジェクトへのアクセスを許可または拒否してしまうリスクが大きくなります。さらに、フィルタによって、ディレクトリ内のアクセス制御に関する問題解決が難しくなる場合もあります。

コンマを含む DN のアクセス権の定義

DN にコンマが含まれている場合、LDIF ACI 文の中で特別な処理が必要です。ACI 文のターゲット部分とバインドルール部分で、1 つの円記号 (\) を使用して、コンマをエスケープする必要があります。次に、この構文の例を示します。

dn: o=Example.com Bolivia\, S.A. 
objectClass: top 
objectClass: organization 
aci: (target="ldap:///o=Example.com Bolivia\,S.A.") (targetattr="*") 
(version 3.0; acl "aci 2"; allow (all) groupdn = 
"ldap:///cn=Directory Administrators, o=Example.com Bolivia\, S.A.";)

実行権限の表示

ディレクトリのエントリに対するアクセスポリシーを管理するとき、定義した ACI がセキュリティーに与える影響を把握しておく必要があります。Directory Server は、ACI が特定のエントリに対して特定のユーザーに与える実行権限を確認することで、既存の ACI を評価します。

この実行権限の取得制御は検索操作で使用でき、Directory Server はそれに対して応答します。この制御に対する応答として、エントリと属性に対する実行権限の情報が検索結果の中で返されます。この追加情報としては、各エントリとその中の各属性に対する読み取り権限および書き込み権限などがあります。検索に使用されるバインド DN や任意の DN では権限を要求することができます。これを選択することで、管理者はディレクトリユーザーの権限を検査できます。

実行権限を表示する機能は、LDAP 制御を利用しています。リモートサーバーとのバインドに使用されるプロキシアイデンティティーにも、実行権限の属性へのアクセスが許可されていることを確認してください。

実行権限取得制御へのアクセスの制限

実行権限を表示するという操作はディレクトリ操作であり、保護し、適切に制限する必要があります。

実行権限情報へのアクセスを制限するには、getEffectiveRights 属性のデフォルトの ACI を変更します。次に、getEffectiveRightsInfo 属性に新しい ACI を作成します。

たとえば、次の ACI では、ディレクトリ管理者グループのメンバーのみが実行権限取得へのアクセスを許可されます。

aci: (targetattr != "aci")(version 3.0; acl
 "getEffectiveRights"; allow(all) groupdn =
 "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

実行権限情報を取得するには、実行権限制御を使用するためのアクセス制御権と、aclRights 属性に対する読み取りアクセス権が必要です。このような二重の層に成すアクセス制御により、基本的なセキュリティーを必要に応じて微調整できます。プロキシ承認のように、aclRights に対する読み取りアクセス権があれば、エントリと属性に対するどのユーザーの権限に関する情報でも要求することができます。つまり、リソースを管理するユーザーは、だれがそのリソースに対する権限を持つかを決定できます。これは、そのユーザーが実際にはその権限を使って管理していない場合も同様です。

権限情報を照会しようとしているユーザーが実行権限制御を使用する権限を持たない場合、操作は失敗し、エラーメッセージが返されます。一方、権限情報を照会しようとしているユーザーがこの制御を使用する権限は持つが、aclRights 属性に対する読み取りアクセス権を持たない場合は、返されるエントリから aclRights 属性が省略されます。この動作は、Directory Server の通常の検索動作を反映しています。

実行権限の取得制御の使用

実行権限の取得制御を指定するには、ldapsearch コマンドに -J"1.3.6.1.4.1.42.2.27.9.5.2" オプションを指定して実行します。デフォルトでは、エントリと属性に対してバインド DN エントリが持っている実行権限が検索結果の中で返されます。

デフォルトの動作を変更するには、次のオプションを使用します。

• -c "dn: bind DN " — 検索結果には、指定された DN にバインドされているユーザーの実行権限が表示されます。管理者はこのオプションを使用して、別のユーザーの実行権限を確認できます。-c "dn:" オプションを指定すると、匿名認証用の実行権限が表示されます。

• -X "attributeName ..."— 検索結果には、指定された属性に対する実行権限も表示されます。このオプションは、検索結果に表示されない属性を指定する場合に使用します。たとえば、このオプションを使用すると、現在はエントリに存在していない属性について、ユーザーがその属性を追加する権限を持っているかどうかを調べることができます。

• -c オプションまたは -X オプション、あるいはその両方を使用するときは、-J オプションに実行権限の取得制御の OID が暗黙的に指定されるため、このオプションを指定する必要はありません。実行権限制御に NULL 値を指定すると、現在のユーザーの権限を取得できます。また、現在の ldapsearch 操作によって返される属性とエントリの権限も取得できます。

  次に、表示する情報の種類を選択する必要があります。権限だけを表示するか、権限がどのように許可または拒否されているかを示す詳細なログ情報を表示するか、いずれかを選択します。情報の種類を指定するには、検索結果で返す属性として aclRights または aclRightsInfo を追加します。両方の属性を要求すると、実行権限の情報をすべて取得できます。ただし、単純な権限情報は基本的には詳細なログ情報の写しです。

aclRights 属性と aclRightsInfo 属性は、仮想オペレーショナル属性のように動作します。これらの属性はディレクトリには格納されず、明示的に要求された場合以外は返されません。これらの属性は、実行権限の取得制御に対する応答として Directory Server で生成されます。

このため、これらの属性を、フィルタや何らかの検索操作に使用することはできません。

実行権限機能は、アクセス制御に影響を与えるその他のパラメーターを継承します。これらのパラメータには、時刻、認証方法、マシンアドレス、名前が含まれます。

次の例は、Carla Fuente というユーザーがディレクトリでの自身の権限を確認する方法を示しています。結果の中で、1 は権限が与えられていることを示し、0 は拒否されていることを示します。

$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2 -h host1.Example.com -p 389 \
 -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

この結果は、Carla Fuente にはディレクトリ内のエントリに少なくとも読み取り権限が与えられていて、自分のエントリを変更できることを示しています。実行権限制御は、通常のアクセス権をバイパスしないため、ユーザーは読み取り権限が与えられていないエントリを見ることはできません。次の例で、ディレクトリマネージャーは、Carla Fuente に読み取り権限が与えられていないエントリを確認できます。

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

上記の出力で、ディレクトリマネージャーは、Carla Fuente がディレクトリツリーの Special Users エントリと Directory Administrators エントリのどちらも表示できないことを確認できます。次の例では、ディレクトリマネージャーは、Carla Fuente が自身のエントリの mail 属性と manager 属性を変更できないことを確認できます。

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(uid=cfuente)" aclRights "*"
Enter bind password:
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@Example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
 compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

高度なアクセス制御: マクロ ACI の使用

同じようなディレクトリツリー構造を持つ組織では、マクロによってディレクトリ内で使用する ACI の数を最適化できます。ディレクトリツリー内の ACI の数を減らすことによって、アクセス制御ポリシーの管理が簡単になります。また、ACI によるメモリー使用の効率も向上します。

マクロは、ACI の中で DN、または DN の一部を表現するために使用される可変部分です。マクロを使用すると、ACI のターゲット部分またはバインドルール部分、あるいはその両方の DN を表すことができます。実際の処理では、Directory Server が LDAP 操作を受け取ると、LDAP 操作のターゲットとなるリソースに対して ACI マクロのマッチングが行われます。このマッチングは、一致する部分文字列の存在を確認するために行われます。一致が検出された場合は、一致した部分文字列を使用してバインドルール側のマクロが展開され、その展開バインドルールを評価してリソースにアクセスします。

この節では、マクロ ACI の例とマクロ ACI 構文についての情報を示します。

マクロ ACI の例

マクロ ACI の利点ともっとも効果的に機能させる方法を、例を示しながら説明します。図 6–1 は、全体的な ACI の数を減らすために、マクロ ACI を効果的に利用しているディレクトリツリーです。

この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています (ou=groups,ou=people)。Example.com ディレクトリツリーには、dc=hostedCompany2,dc=example,dc=com および dc=hostedCompany3,dc=example,dc=com という 2 つのサフィックスが格納されているので、このパターンはツリー内でも繰り返されています。ただし、図には示されていません。

ディレクトリツリーにある ACI でも、同じパターンが繰り返されています。たとえば、次の ACI は dc=hostedCompany1,dc=example,dc=com ノード上に置かれています。

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))(version 3.0;
 acl "Domain access"; allow (read,search) groupdn=
 "ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,
 dc=example,dc=com";)

この ACI は、dc=hostedCompany1,dc=example,dc=com ツリー内のすべてのエントリに対する読み取りおよび検索権限を DomainAdmins グループに与えます。

図 6–1 マクロ ACI のディレクトリツリーの例

次の ACI は、dc=hostedCompany1,dc=example,dc=com ノード上に置かれています。

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

次の ACI は、dc=subdomain1,dc=hostedCompany1, dc=example,dc=com ノード上に置かれています。

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,
  dc=example,dc=com";)

次の ACI は、dc=hostedCompany2,dc=example,dc=com ノード上に置かれています。

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)

次の ACI は、dc=subdomain1,dc=hostedCompany2, dc=example,dc=com ノード上に置かれています。

aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,
 dc=example,dc=com";)

前述の 4 つの ACI の違いは、groupdn キーワード内で指定されている DN だけです。DN 用のマクロを使用することによって、これらの ACI を、1 つの ACI にまとめてルートツリーの dc=example,dc=com ノードに置くことができます。このマクロ ACI は次のようになります。

aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search) 
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

前述の個々の ACI では使われていなかった target キーワードをここでは新たに使っていることに注意してください。

この例では、ACI の数が 4 つから 1 つに減っています。ただし、本当の利点はそれだけではなく、ディレクトリツリー全体で複数繰り返されているパターンをまとめることができるところにあります。

マクロ ACI の構文

ここでは、わかりやすくするために、userdn、roledn、groupdn、userattr などのバインド資格を与えるために使用される ACI キーワードをまとめて、「サブジェクト」と呼びます。サブジェクトは、ACI の適用対象を決定します。

次の表に、特定の ACI キーワードの置換に使用できるマクロを示します。

マクロ ACI キーワードには、次のような制限が適用されます。

• サブジェクトで ($dn) マクロや [$dn] マクロを使用するときは、($dn) マクロを含む target 文を定義する必要があります。

• サブジェクトで ($attr.attrName ) マクロと ($dn) マクロを組み合わせることはできますが、[$dn] マクロと組み合わせることはできません。

ターゲットエントリでの ($dn) とのマッチング処理

ACI の target 文に含まれる ($dn) マクロを、LDAP 要求のターゲットとなるエントリと比較することによって、実際に置き換えられる値が決定します。たとえば、このエントリをターゲットとする LDAP 要求があるとします。

cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com

また、次のような target 文を定義している ACI もあるとします。

(target="ldap:///ou=Groups,($dn),dc=example,dc=com")

この場合、($dn) マクロは dc=subdomain1, dc=hostedCompany1 と一致します。ACI のサブジェクト内で ($dn) はこの部分文字列に置き換えられます。

サブジェクト内での ($dn) の置換

ACI のサブジェクト内では、($dn) マクロはターゲット内で一致する部分文字列全体に置き換えられます。次に例を示します。

groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"

サブジェクトは次のようになります。

groupdn="ldap:///cn=DomainAdmins,ou=Groups,
 dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"

マクロが展開されると、通常のプロセスに続いて Directory Server が ACI を評価し、アクセス権が与えられるかどうかを決定します。

標準の ACI とは異なり、マクロ置換を使った ACI はターゲットエントリの子へのアクセスを許可する必要はありません。これは、子の DN がターゲットとなった場合に、置換によってサブジェクト文字列内に有効な DN が作成されない可能性があるためです。

サブジェクト内での [$dn] の置換

[$dn] の置換メカニズムは ($dn) のものと少し異なります。一致する対象が見つかるまで、一番左にある RDN コンポーネントを外しながらマクロの展開を継続して行い、ターゲットリソースの DN の検証を繰り返します。

たとえば、cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com サブツリーをターゲットとする LDAP 要求で、次のような ACI があるとします。

aci: (targetattr="*")
 (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],
 dc=example,dc=com";)

サーバーは次のように処理を続け、この ACI を展開します。

1. target 文の ($dn) が dc=subdomain1,dc=hostedCompany1 に一致します。

2. サブジェクトの [$dn] を dc=subdomain1,dc=hostedCompany1 で置き換えます。

   この結果、サブジェクトは groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com" になります。バインド DN がそのグループのメンバーであるためにアクセスが許可される場合は、マクロの展開を停止し、ACI を評価します。バインド DN がメンバーでない場合は、処理を継続します。

3. サブジェクトの [$dn] を dc=hostedCompany1 で置き換えます。

   この結果、サブジェクトは groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com" になります。バインド DN がこのグループのメンバーであるかどうかが再び検証され、メンバーである場合は ACI が完全に評価されます。バインド DN がメンバーでない場合は、マクロの展開は最後に一致した RDN で置き換えたところで終了し、この ACI に対する評価は終了します。

[$dn] マクロの利点は、ドメインレベルの管理者に対して、ディレクトリツリー内のすべてのサブドメインへのアクセス権を柔軟な方法で与えることができることです。したがって、[$dn] マクロは、ドメイン間の階層的な関係を表す場合に便利です。

たとえば、次のような ACI があるとします。

aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain)) 
(version 3.0; acl "Domain access"; allow (read,search) groupdn= 
"ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

この ACI は、cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com のすべてのメンバーに対して、 dc=hostedCompany1 の下にあるすべてのサブドメインへのアクセス権を与えます。したがって、そのグループに属する管理者は、サブツリー ou=people,dc=subdomain1.1,dc=subdomain1 などにアクセスできます。

ただし、同時に、cn=DomainAdmins,ou=Groups, dc=subdomain1.1 のメンバーの ou=people,dc=subdomain1, dc=hostedCompany1 および ou=people,dc=hostedCompany1 ノードに対するアクセスは拒否されます。

($attr.attrName ) に対するマクロマッチング

($attr.attrname) マクロは、常に DN のサブジェクト部分で使用されます。たとえば、次のような roledn を定義できます。

roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1,dc=example,dc=com"

ここで、サーバーが次のエントリをターゲットとする LDAP 操作を受け取ったとします。

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales
...

ACI の roledn 部分を評価するために、サーバーはターゲットエントリの ou 属性の値を読み取ります。そのあと、サブジェクト内でこの値を置換してマクロを展開します。この例では、roledn は次のように展開されます。

roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"

続いて、通常の ACI 評価アルゴリズムに従って、Directory Server が ACI を評価します。

マクロ内で指定された属性が複数の値を持つ場合は、それぞれの値でマクロが展開されます。最初にマッチングに成功した値が使用されます。

アクセス制御情報のログ

エラーログに記録されているアクセス制御に関する情報を取得するには、適切なログレベルを設定する必要があります。

ACI のログを設定する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. ACI の処理を考慮に入れるようにログレベルを設定します。

   $ dsconf set-log-prop -h host -p port error level:err-acl

TCP ラップによるクライアントホストのアクセス制御

接続が TCP レベルで受け入れまたは拒否されるホストや IP アドレスは、TCP ラッパーを使用して制御できます。TCP ラップにより、クライアントホストのアクセスを制限できます。これにより、Directory Server への初期の TCP 接続に対する、ホストベースではない保護が可能になります。

Directory Server に対して TCP ラップを設定することはできますが、TCP ラップは、特にサービス拒否攻撃の際に、パフォーマンスを著しく低下させる可能性があります。最良のパフォーマンスは、Directory Server の外部で保守されるホストベースのファイアウォールを使用するか、IP ポートのフィルタリングによって得られます。

TCP ラップを使用可能にする

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. インスタンスパス内のどこかに hosts.allow ファイルまたは hosts.deny ファイルを作成します。

   たとえば、このファイルを instance-path/config 内に作成します。作成するファイルの形式は、必ず hosts_access(4) に従うようにしてください。

2. アクセスファイルへのパスを設定します。

   $ dsconf set-server-prop -h host -p port host-access-dir-path:path-to-file

   次に例を示します。

   $ dsconf set-server-prop -h host -p port host-access-dir-path:/local/ds1/config "host-access-dir-path" property has been set to "/local/ds1/config". The "/local/ds1/config" directory on host1 must contain valid hosts.allow and/or hosts.deny files. Directory Server must be restarted for changes to take effect.

TCP ラップを使用不可にする

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. ホストアクセスパスを "" に設定します。

   $ dsconf set-server-prop -h host -p port host-access-dir-path:""

第 7 章 Directory Server のパスワードポリシー

ユーザーが Directory Server に接続すると、認証されます。ディレクトリは、認証時に設定された識別情報に応じて、ユーザーに対してアクセス権限を与え、リソースを制限することができます。この章でのアカウントとは、大まかにはユーザーエントリを指しています。アカウントは、ユーザーがディレクトリに対して実行する操作の権限も示します。ここでのパスワードポリシーの説明では、すべてのアカウントがユーザーエントリとパスワードに関連付けられています。

さらに、この章では、パスワードポリシーの一面であるアカウントのアクティブ化についても説明します。ディレクトリ管理者は、パスワードポリシーと関係なく、アカウントを直接ロックおよびロック解除できます。

この章では、認証方法については取り上げていません。SASL GSSAPI やクライアント SSL 証明書ベースの認証などの認証方法では、パスワードを使用しないこともあります。この章のパスワードポリシーに関する情報はそのような認証方法には適用しません。認証メカニズムの設定については、第 5 章「Directory Server のセキュリティー」を参照してください。

また、この章では、Directory Server 6.2 と以前のバージョンの Directory Server とのパスワードポリシーの互換性についても取り上げていません。 Directory Server 6.2 のインスタンスを作成すると、以前のバージョンからのアップグレードを容易にするために、パスワードポリシー実装はデフォルトで Directory Server 5 互換モードに設定されます。この章で説明するパスワードポリシー機能を十分に活用するには、パスワードポリシー互換モードを変更する必要があります。パスワードポリシー互換モードの設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide』の「Password Policy Compatibility」を参照してください。

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

• 「パスワードポリシーとワークシート」

• 「デフォルトのパスワードポリシーの管理」

• 「特別なパスワードポリシーの管理」

• 「pwdSafeModify が TRUE の場合のコマンド行からのパスワードの変更」

• 「期限切れパスワードのリセット」

• 「アカウントプロパティーの設定」

• 「アカウントの手動でのロック」

パスワードポリシーとワークシート

この節ではパスワードポリシー設定について説明し、要件に合うパスワードポリシーの定義に役立つワークシートを提供します。

デフォルトのパスワードポリシーを使用するには、「デフォルトのパスワードポリシーの管理」を参照してください。

パスワードポリシー設定

Directory Server でパスワードポリシーを指定する場合、オブジェクトクラス pwdPolicy(5dsoc) を含むエントリを変更するか作成します。

特定のタイプのユーザーのパスワードポリシーを定義する場合は、次のことを考慮する必要があります。

• 侵入者がパスワードをクラックしようとしているように見える場合にアカウントをロックアウトする方法。

  詳細については、「アカウントロックアウトのポリシー」を参照してください。

• パスワードの変更方法。

  詳細については、「パスワード変更のポリシー」を参照してください。

• 許可するパスワードの値。

  詳細については、「パスワードコンテンツのポリシー」を参照してください。

• パスワードの有効期限の処理方法。

  詳細については、「パスワード有効期限のポリシー」を参照してください。

• 最後に認証に成功した時間をサーバーが記録するかどうか。

  「最後の認証時間の追跡のポリシー」を参照してください。

この章のあとの節で、パスワードポリシーのこれらの点の処理方法を説明します。実装を計画している各パスワードポリシーを明確にするには、「パスワードポリシーを定義するためのワークシート」を使用します。

アカウントロックアウトのポリシー

この節では、アカウントロックアウトを制御するポリシー属性について説明します。

Directory Server のアカウントとは、大まかにはユーザーのエントリとそのユーザーがディレクトリに対して操作を実行するために必要な権限を指します。各アカウントはバインド DN とユーザーパスワードに関連付けられています。侵入者がパスワードをクラックしようとしているように見える場合、Directory Server でアカウントをロックする必要があります。ロックにより、侵入者はそのアカウントを使用してバインドできなくなります。さらに、ロックにより、侵入者が攻撃を続けることができなくなります。

管理者は、ロールを共有するすべてのユーザーのアカウントを手動で非アクティブ化することもできます。手順については、「アカウントの手動でのロック」を参照してください。さらに、パスワードポリシーを指定する際に重要なことは、Directory Server が管理者の介入なしにアカウントを自動的にロックするのはどのような条件かを指定することです。

まず、バインドの失敗が著しく多く発生する場合は、Directory Server で pwdLockout(5dsat) を使用して、自動的にアカウントがロックされるように指定する必要があります。Directory Server は連続して失敗したアカウントへのバインド試行を追跡します。pwdMaxFailure(5dsat) を使用して、何回連続して失敗したら Directory Server がアカウントをロックするかを指定します。

Directory Server はパスワードポリシーに従って、厳密にアカウントをロックします。操作は完全に機械的です。アカウントは、侵入者がアカウントに対して攻撃を仕掛けようとしているためでなく、ユーザーが誤ったパスワードを入力したことによりロックされることもあります。pwdFailureCountInterval(5dsat) を使用して、失敗した試行の間隔がどれだけ空いたら Directory Server がそれまでの失敗した試行の記録を消去するかを指定できます。pwdLockoutDuration(5dsat) を使用してDirectory Server がアカウントのロックを自動的に解除するまで、ロックアウトを継続する期間を指定します。管理者は、悪意なく正当なミスをしたユーザーのアカウントのロックを解除するために介入する必要はありません。

ユーザーデータがレプリケーショントポロジにレプリケートされる場合、ロックアウト属性は、ほかのエントリデータとともにレプリケートされます。pwdIsLockoutPrioritized(5dsat) 属性のデフォルト設定は TRUE です。この設定では、ロックアウト属性の更新は高い優先順位でレプリケートされます。したがって、ユーザーが、ロックアウトされるまでにレプリカの 1 つへのバインド試行を連続して失敗できるのは、pwdMaxFailure で設定された回数までです。ユーザーのバインド試行の失敗がほかのレプリカに対してもカウントされることで、全体として試行できる回数はさらに少なくなる可能性があります。ユーザーが、レプリケートされたトポロジ全体でロックアウトされるまで、pwdMaxFailure で設定された回数だけ試行できるようにする方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』の「グローバルアカウントロックアウトを使用した認証の防止」を参照してください。

パスワード変更のポリシー

この節では、パスワードの変更を制御するポリシーについて説明します。

多くの配備で、Directory Server はアイデンティティーデータのリポジトリになります。pwdAllowUserChange(5dsat) を有効にし、ユーザーが自身のパスワードを変更できるようにすることをお勧めします。これにより、管理者が各ユーザーのパスワードを変更する必要がなくなります。

ユーザーが自分のパスワードを変更できるようにしたら、次に必要な作業として、ユーザーがどのように自分のパスワードを変更できるかを制御することが考えられます。pwdSafeModify(5dsat) を使用して、パスワード変更の前に、ユーザーに既存のパスワードを正しく入力することを求めるように設定できます。パスワードの変更方法の例については、「pwdSafeModify が TRUE の場合のコマンド行からのパスワードの変更」を参照してください。pwdInHistory(5dsat) を使用して、Directory Server が記憶するパスワード数を指定して、ユーザーがパスワードを再利用できないようにすることができます。さらに、pwdMinAge(5dsat) を設定して、ユーザーが著しく頻繁にパスワードを変更できないようにすることもできます。

管理者でも、または管理するアプリケーションでも、たいていの場合、ユーザーエントリをディレクトリに作成します。ユーザーが初めて新しいアカウントにバインドしたときに変更するユーザーパスワード値を割り当てることができます。さらに、ユーザーパスワードのリセットが必要になる場合もあります。リセット後、ユーザーは次にアカウントを使用するときにパスワードを変更する必要があります。Directory Server には、特定の属性 pwdMustChange(5dsat) があります。これを使用して、他のユーザーによってパスワード値がリセットされた後に、ユーザーがパスワードを変更する必要があるかどうかを指定することができます。

さらに、passwordRootdnMayBypassModsChecks(5dsat) を設定して、ディレクトリ管理者がパスワードを変更する場合に、ポリシーが適用されないように指定することもできます。

パスワードコンテンツのポリシー

この節では、パスワードコンテンツを制御するポリシー属性について説明します。

ディレクトリ検索で一般にパスワード値は返されませんが、攻撃者はディレクトリデータベースへのアクセス権を取得する可能性があります。そのため、パスワード値は一般に、passwordStorageScheme(5dsat) で指定した、サポートされるハッシュ形式で保存します。

さらに、pwdCheckQuality(5dsat) を設定して、パスワードが最低限のパスワード品質の定義を満たしているかをチェックすることもできます。その場合、サーバーは、パスワードが cn、givenName、mail、ou、sn、または uid 属性のどの値とも一致しないことをチェックします。パスワードとこれらのいずれかの属性との比較では、大文字と小文字は区別されません。

pwdCheckQuality(5dsat) を設定して、追加のチェックを行うことができます。pwdMinLength(5dsat) を設定して、パスワードを指定した文字数以上にすることを強制できます。また、強力なパスワードチェックプラグインが有効にされている場合、Directory Server はパスワードにプラグインが使用する辞書ファイルの文字列が含まれていないことをチェックします。さらに、パスワードにさまざまなタイプの文字が適切に混在して含まれていることもチェックします。

強力なパスワードチェックを有効にするには、dsconf set-server-prop コマンドを使用します。pwd-strong-check-enabled プロパティーを使用して、プラグインを有効にし、サーバーを再起動して、変更を有効にします。パスワードに含める必要がある文字セットを指定するには、pwd-strong-check-require-charset プロパティーを使用します。pwd-strong-check-require-charset プロパティーは次の値のマスクを使用します。

lower

新しいパスワードには、小文字を含める必要があります。

upper

新しいパスワードには、大文字を含める必要があります。

digit

新しいパスワードには、数字を含める必要があります。

special

新しいパスワードには、特殊文字を含める必要があります。

any-two

新しいパスワードには、上記の 2 つ以上の文字セットから、それぞれ 1 文字以上含める必要があります。

any-three

新しいパスワードには、上記の 3 つ以上の文字セットから、それぞれ 1 文字以上含める必要があります。

pwd-strong-check-require-charset プロパティーのデフォルトの設定は lower && upper && digit && special です。

パスワード有効期限のポリシー

この節では、パスワードの有効期限を制御するポリシー属性について説明します。

ユーザーがパスワードを定期的に変更するように、Directory Server で、パスワードが特定の経過時間に達すると、有効期限が切れるように設定できます。このためには、pwdMaxAge(5dsat) を設定します。

パスワードの有効期限が切れそうであることをユーザーに通知する必要があります。バインドに使用するパスワードの有効期限が切れそうであるという警告を返すように、Directory Server を設定できます。pwdExpireWarning(5dsat) を使用して、有効期限のどれくらい前からクライアントがバインドしたときに警告を返すかを定義します。クライアントアプリケーションが警告を受け取ることに注意してください。ユーザーが直接警告を受け取るわけではありません。クライアントアプリケーションは、パスワードの有効期限が切れそうであるという警告を受け取ったら、エンドユーザーに通知する必要があります。

ユーザーが有効期限切れのパスワードで1 回以上バインドを試みることを許可するには、pwdGraceAuthNLimit(5dsat) を設定します。ユーザーは、期限内にパスワードの変更に失敗した場合でも、パスワードを変更するためにバインドできます。この猶予認証でログインした場合、パスワードの有効期限が切れていないときと同様にユーザーはすべての操作を実行できます。

Directory Server は、エントリのパスワードが変更されるたびにオペレーショナル属性 pwdChangedTime(5dsat) を更新します。結果として、パスワードの有効期限を有効にするために待機している場合、パスワードの有効期限を有効にすると、すでに古くなったユーザーパスワードはすぐに期限切れとなります。この動作が意図と反する場合は、ユーザーに猶予認証でのログインを許可し、すぐにパスワードを変更させるようにしてください。

最後の認証時間の追跡のポリシー

この節では、パスワードポリシー属性 pwdKeepLastAuthTime(5dsat) の使用について説明します。

pwdKeepLastAuthTime を設定すると、Directory Server はユーザーが認証するたびに、最後にバインドに成功した時間を追跡します。時間は、ユーザーのエントリの pwdLastAuthTime(5dsat) オペレーショナル属性に記録されます。

この操作によって、バインド操作が成功するたびに更新が追加されるため、pwdKeepLastAuthTime 機能はデフォルトで無効にされています。配備でこの機能を使用する場合は、明示的に有効にする必要があります。

パスワードポリシーを定義するためのワークシート

ワークシートは、コマンド行インタフェースまたは Directory Service Control Center (DSCC) を使用して実装するパスワードポリシーの定義に役立つように設計されています。パスワードポリシーごとに 1 つのワークシートを使用します。

パスワードポリシーエントリの DN を記録したら、各ポリシー領域の属性の設定についての決定を記録します。それらの設定の理由も記録します。

pwdCheckQuality 属性を 2 に設定すると、サーバーは追加のチェックを実行できます。パスワードチェックプラグインも有効にすると、新しいパスワードの値をチェックする際に、プラグインの設定内容も考慮されます。

デフォルトのパスワードポリシーの管理

デフォルトのパスワードポリシーは、専用のポリシーが定義されていない、ディレクトリインスタンスのすべてのユーザーに適用されます。ただし、デフォルトのパスワードポリシーはディレクトリマネージャーには適用されません。ポリシーの範囲の詳細については、「どのパスワードポリシーを適用するか」を参照してください。

デフォルトのパスワードポリシーは、dsconf コマンドを使用して設定できるポリシーの 1 つです。デフォルトのパスワードポリシーを表示するには、cn=Password Policy,cn=configを読み取ります。

この節では、各ポリシー領域のポリシー属性と関連の dsconf サーバープロパティーについて説明します。さらに、デフォルトのパスワードポリシー設定を表示して変更する方法についても説明します。

パスワードポリシー属性と dsconf サーバープロパティーの相関関係

次の表に、各パスワードポリシー領域のパスワードポリシー属性と関連する dsconf サーバープロパティーを示します。

pwdCheckQuality に関連するプロパティーはパスワードチェックプラグインを設定します。そのため、サーバーインスタンス全体に 5 つのプロパティーが適用されます。さらに、この 5 つのプロパティーは pwdCheckQuality: 2 であるほかのパスワードポリシーにも適用されます。

デフォルトのパスワードポリシー設定を表示する

dsconf コマンドを使用して、デフォルトのパスワードポリシー設定を表示できます。

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

1. デフォルトのパスワードポリシー設定を読み取ります。

   $ dsconf get-server-prop -h host -p port | grep ^pwd- pwd-accept-hashed-pwd-enabled : N/A pwd-check-enabled : off pwd-compat-mode : DS5-compatible-mode pwd-expire-no-warning-enabled : on pwd-expire-warning-delay : 1d pwd-failure-count-interval : 10m pwd-grace-login-limit : disabled pwd-keep-last-auth-time-enabled : off pwd-lockout-duration : 1h pwd-lockout-enabled : off pwd-lockout-repl-priority-enabled : on pwd-max-age : disabled pwd-max-failure-count : 3 pwd-max-history-count : disabled pwd-min-age : disabled pwd-min-length : 6 pwd-mod-gen-length : 6 pwd-must-change-enabled : off pwd-root-dn-bypass-enabled : off pwd-safe-modify-enabled : off pwd-storage-scheme : SSHA pwd-strong-check-dictionary-path : /local/ds6/plugins/words-english-big.txt pwd-strong-check-enabled : off pwd-strong-check-require-charset : lower pwd-strong-check-require-charset : upper pwd-strong-check-require-charset : digit pwd-strong-check-require-charset : special pwd-supported-storage-scheme : CRYPT pwd-supported-storage-scheme : SHA pwd-supported-storage-scheme : SSHA pwd-supported-storage-scheme : NS-MTA-MD5 pwd-supported-storage-scheme : CLEAR pwd-user-change-enabled : on

デフォルトのパスワードポリシー設定を変更する

デフォルトのパスワードポリシーを変更するには、dsconf コマンドを使用して、サーバーのプロパティーを設定します。

この手順を実行する前に、「パスワードポリシーを定義するためのワークシート」を参照して、記入してください。

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

1. ワークシートの設定を元にして、dsconf コマンドでどのプロパティーを設定すればよいかを確認します。

2. dsconf set-server-prop コマンドを使用して、デフォルトのパスワードポリシープロパティーを適切に変更します。

   たとえば、次のコマンドを使用すると、ディレクトリマネージャーがパスワードを変更するときに、デフォルトのポリシーに違反してもよいことになります。

   $ dsconf set-server-prop -h host -p port pwd-root-dn-bypass-enabled:on

特別なパスワードポリシーの管理

特別なパスワードポリシーは pwdPolicy(5dsoc) エントリに定義します。ポリシーはディレクトリツリーの任意の場所に定義できますが、一般にポリシーで管理するアカウントでレプリケートされるサブツリーに定義します。ポリシーは cn=policy name、subtree の形式の DN を持ちます。

パスワードポリシーを定義したら、目的のユーザーエントリに pwdPolicySubentry(5dsat) 属性を設定して、パスワードポリシーを割り当てます。

ここで説明する内容は次のとおりです。

• 「どのパスワードポリシーを適用するか」

• 「パスワードポリシーを作成する」

• 「各アカウントにパスワードポリシーを割り当てる」

• 「ロールと CoS を使用してパスワードポリシーを割り当てる」

• 「初回ログインパスワードポリシーを設定する」

どのパスワードポリシーを適用するか

Directory Server では、複数のパスワードポリシーを設定できます。この節では、デフォルトのパスワードポリシーと特別なパスワードポリシーについて説明します。さらに、この節では、特定のアカウントに複数のパスワードポリシーを適用できる場合に、どのポリシーを強制するかについても説明します。

初めて Directory Server インスタンスを作成すると、そのインスタンスにはデフォルトのパスワードポリシーが適用されます。デフォルトのパスワードポリシーは、設定エントリ cn=PasswordPolicy,cn=config に示されています。デフォルトのパスワードポリシーはディレクトリマネージャーを除くディレクトリのすべてのアカウントに適用されます。

すべての Directory Server パスワードポリシーと同様に、cn=PasswordPolicy,cn=config はオブジェクトクラス pwdPolicy(5dsoc) とオブジェクトクラス sunPwdPolicy(5dsoc) を持ちます。

Directory Server インスタンスを作成すると、パスワードポリシー属性は Directory Server 5 互換モードのままであるため、以前のバージョンからのアップグレードが簡単です。Directory Server 5 互換モードでは、Directory Server はオブジェクトクラス passwordPolicy(5dsoc) を持つパスワードポリシーエントリも処理します。

アップグレードが完了すると、『Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide』で説明するように、新しいパスワードポリシーの機能をすべて使用できます。管理上の移動は、ディレクトリアプリケーションには認識されません。

この章では、新しいパスワードポリシー機能を使用したパスワードポリシー設定について説明します。

デフォルトのパスワードポリシーを変更して、デフォルトの設定を上書きできます。dsconf(1M) コマンドを使用して、デフォルトのパスワードポリシーに関連する、サーバーのプロパティーを設定できます。それらのサーバープロパティー名は一般に pwd- プレフィックスから始まります。それらのプロパティーの設定を変更する場合、インスタンスのデフォルトのパスワードポリシーを上書きします。ただし、レプリケーションでは変更がレプリカにコピーされません。デフォルトのパスワードポリシーの変更は、ディレクトリデータではなく、インスタンスの設定に含まれます。

デフォルトのパスワードポリシーを設定するほかに、特別なパスワードポリシーも設定できます。特別なパスワードポリシーは、ディレクトリツリーのエントリによって定義します。特別なパスワードポリシーエントリは、デフォルトのパスワードポリシーと同じオブジェクトクラス pwdPolicy(5dsoc) を持つため、同じポリシー属性を持ちます。特別なパスワードポリシーは、正規のディレクトリエントリであるため、通常のディレクトリエントリと同じ方法でポリシーエントリがレプリケートされます。

ユーザーエントリは、オペレーショナル属性 pwdPolicySubentry(5dsat) の値によって特別なパスワードポリシーを参照します。ユーザーエントリによって参照した場合、特別なパスワードポリシーはインスタンスのデフォルトのパスワードポリシーを上書きします。多くの配備で、ユーザーロールを割り当てます。pwdPolicySubentry 値を設定して、サービスクラス (CoS) と連携して、ユーザーアカウントに適用するパスワードポリシーを決定するようにロールを設定できます。ロールによってパスワードポリシーセットを上書きするには、そのユーザーのエン トリディレクトリの pwdPolicySubentry 値を変更します。

この節を要約すると、最初にデフォルトのパスワードポリシーが適用されます。デフォルトのパスワードポリシーを変更して、デフォルトを上書きできます。次に、特別なパスワードポリシーエントリを作成して、デフォルトのパスワードポリシーを上書きできます。ロールと CoS によってパスワードポリシーを割り当てる場合に、各エントリにパスワードポリシーを指定して、CoS によって割り当てられたポリシーを上書きできます。

パスワードポリシーを作成する

他のディレクトリエントリの作成や変更と同じ方法で、特別なパスワードポリシーを作成、変更できます。次の手順では、テキストエディタを使用して、LDIF にパスワードポリシーエントリを書き込む方法を示します。次に-a オプションを使用して、ldapmodify コマンドを実行し、ディレクトリにパスワードポリシーエントリを追加します。

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

始める前に

ほかに指示がない限り、ここに示すデータの例は Example.ldif から抜粋したものです。

1. 作成するポリシーについて、パスワードポリシーワークシートを完成させます。

   サンプルについては、「パスワードポリシーを定義するためのワークシート」を参照してください。

2. ワークシートに基づいて、パスワードポリシーエントリを LDIF に書き込みます。

   たとえば、次のポリシーエントリは、Example.com の臨時従業員のパスワードポリシーを指定します。この従業員のサブツリーのルートは dc=example,dc=com です。

   dn: cn=TempPolicy,dc=example,dc=com
   objectClass: top
   objectClass: pwdPolicy
   objectClass: sunPwdPolicy
   objectClass: LDAPsubentry
   cn: TempPolicy
   pwdAttribute: userPassword
   pwdCheckQuality: 2
   pwdLockout: TRUE
   pwdLockoutDuration: 300
   pwdMaxFailure: 3
   pwdMustChange: TRUE

   デフォルトのパスワードポリシー設定に加えて、ここに示すポリシーは追加の動作を指定します。パスワード品質チェックを実行します。3 回連続してバインドが失敗すると、アカウントは 5 分間 (300 秒) ロックされます。パスワードのリセット後に、パスワードを変更する必要があります。ポリシーをユーザーアカウントに割り当てると、ここに明示的に指定した設定で、デフォルトのパスワードポリシーが上書きされます。

3. ディレクトリにパスワードポリシーエントリを追加します。

   たとえば、次のコマンドは Example.com の臨時従業員のパスワードポリシーを dc=example,dc=com の下に追加します。パスワードポリシーは pwp.ldif というファイルに保存されています。

   $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: adding new entry cn=TempPolicy,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w --b dc=example,dc=com \ "(&(objectclass=ldapsubentry)(cn=temppolicy))" Enter bind password: version: 1 dn: cn=TempPolicy,dc=example,dc=com objectClass: top objectClass: pwdPolicy objectClass: LDAPsubentry cn: TempPolicy pwdCheckQuality: 2 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxFailure: 3 pwdMustChange: TRUE $

   Example.ldif に示すように、kvaughan は dc=example,dc=com エントリを変更するアクセス権を持つ人事マネージャーです。Example.ldif に示すように、Vaughan のバインドパスワードは bribery です。

参照

定義したポリシーによって管理されるユーザーアカウントを定義するには、「各アカウントにパスワードポリシーを割り当てる」または 「ロールと CoS を使用してパスワードポリシーを割り当てる」を参照してください。

各アカウントにパスワードポリシーを割り当てる

次の手順で、既存のパスワードポリシーを 1 つのユーザーアカウントに割り当てます。

この手順を実行するには、特別なパスワードポリシーを作成している必要があります。「パスワードポリシーを作成する」を参照してください。

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

ここに示す例は、ほかに指示がない限り、Example.ldif から抜粋したものです。

1. ユーザーエントリの pwdPolicySubentry 属性の値にパスワードポリシー DN を追加します。

   たとえば、次のコマンドは、「パスワードポリシーを作成する」で定義しているパスワードポリシーを David Miller のエントリに割り当てます。David Miller の DN は uid=dmiller,ou=people,dc=example,dc=com です。

   $ cat pwp.ldif dn: uid=dmiller,ou=people,dc=example,dc=com changetype: modify add: pwdPolicySubentry pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $ ldapmodify -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: modifying entry uid=dmiller,ou=people,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - -b dc=example,dc=com \ "(uid=dmiller)" pwdPolicySubentry Enter bind password: version: 1 dn: uid=dmiller, ou=People, dc=example,dc=com pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $

   Example.ldif に示すように、kvaughan は人事マネージャーで、dc=example,dc=com エントリを変更するアクセス権を持ちます。Example.ldif に示すように、Vaughan のバインドパスワードは bribery です。

ロールと CoS を使用してパスワードポリシーを割り当てる

次の手順では、ロールとサービスクラス (CoS) を適用して、既存の特別なパスワードポリシーをユーザーのセットに割り当てます。ロールと CoS の詳細については、第 9 章「Directory Server のグループ、ロール、および CoS」を参照してください。

この手順を実行するには、特別なパスワードポリシーを作成している必要があります。「パスワードポリシーを作成する」を参照してください。

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

ここに示す例は、ほかに指示がない限り、Example.ldif から抜粋したものです。

1. パスワードポリシーによって管理されるエントリのロールを作成します。

   たとえば、次のコマンドは Example.com の臨時従業員のフィルタを適用されたロールを作成します。

   $ cat tmp.ldif dn: cn=TempFilter,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: TempFilter nsRoleFilter: (&(objectclass=person)(status=contractor)) description: filtered role for temporary employees $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f tmp.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $

   Example.ldif に示すように、kvaughan は人事マネージャーで、dc=example,dc=com エントリを変更するアクセス権を持ちます。Example.ldif に示すように、Vaughan のバインドパスワードは bribery です。

2. パスワードポリシーエントリの DN を生成するサービスクラスを作成します。

   この DN は、作成したロールを持つユーザーの pwdPolicySubentry 属性の値となります。

   たとえば、次のコマンドは、Example.com の臨時従業員のフィルタを適用したロールを作成します。コマンドはロールを持つユーザーに cn=TempPolicy,dc=example,dc=com を割り当てます。

   $ cat cos.ldif dn: cn=PolTempl,dc=example,dc=com objectclass: top objectclass: nsContainer dn: cn="cn=TempFilter,ou=people,dc=example,dc=com", cn=PolTempl,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: LDAPsubentry objectclass: costemplate cosPriority: 1 pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com dn: cn=PolCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDN: cn=PolTempl,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f cos.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $

   これにより、ステータスが contractor であるユーザーは、cn=TempPolicy,dc=example,dc=com パスワードポリシーの対象となります。

初回ログインパスワードポリシーを設定する

多くの配備で、新しいアカウントに適用するパスワードポリシーは、既存のアカウントに適用するパスワードポリシーと異なります。この節では、初回ログインパスワードポリシーについて説明します。このポリシーでは、ユーザーが新しく作成されたアカウントを 3 日間使用でき、アカウントがロックされる前に、自身の新しいパスワードを設定するようにします。このポリシーは、パスワードがリセットされたユーザーについても同様に機能するように設計されています。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. 新しく作成されたアカウント用に特別なパスワードポリシーを作成します。

   たとえば、有効期限を 3 日間、つまり 259,200 秒に設定するパスワードポリシーエントリを追加します。さらに、このパスワードポリシーでは、pwdMustChange(5dsat) に TRUE を設定し、ユーザーが初めてバインドしたときに、自身のパスワードを変更する必要があることを示します。

   $ cat firstLogin.ldif dn: cn=First Login,dc=example,dc=com objectClass: top objectClass: LDAPsubentry objectClass: pwdPolicy objectClass: sunPwdPolicy cn: First Login passwordStorageScheme: SSHA pwdAttribute: userPassword pwdInHistory: 0 pwdExpireWarning: 86400 pwdLockout: TRUE pwdMinLength: 6 pwdMaxFailure: 3 pwdMaxAge: 259200 pwdFailureCountInterval: 600 pwdAllowUserChange: TRUE pwdLockoutDuration: 3600 pwdMinAge: 0 pwdCheckQuality: 2 pwdMustChange: TRUE $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f firstLogin.ldif Enter bind password: adding new entry cn=First Login,dc=example,dc=com $

2. 新しく作成されたすべてのアカウントを含むロールを作成します。

   このロールの作成では、新しく作成したアカウントを既存のアカウントと区別するいくつかの方法を設定します。

   1. pwdReset(5dsat) 属性が TRUE に設定されているアカウントが新しいアカウントであると定義します。

      ユーザーのパスワードがパスワード管理者などの別のユーザーによって変更された場合、 pwdReset が TRUE に設定されます。

   2. 新しいアカウントを識別するロールを作成します。

      たとえば、次のコマンドは、パスワードがリセットされたアカウントのロールを作成します。

      $ cat newRole.ldif dn: cn=First Login Role,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: First Login Role nsRoleFilter: (pwdReset=TRUE) description: Role to assign password policy for new and reset accounts $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f newRole.ldif Enter bind password: adding new entry cn=First Login Role,ou=people,dc=example,dc=com $

3. サービスクラスによって、新しく作成したアカウントのパスワードポリシーを割り当てます。

   $ cat newCoS.ldif dn: cn=First Login Template,dc=example,dc=com objectClass: top objectClass: nsContainer dn: cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com objectClass: top objectClass: extensibleObject objectClass: LDAPSubEntry objectClass: CoSTemplate cosPriority: 1 pwdPolicySubentry: cn=First Login,dc=example,dc=com dn: cn=First Login CoS,dc=example,dc=com objectClass: top objectClass: LDAPSubEntry objectClass: CoSSuperDefinition objectClass: CoSClassicDefinition cosTemplateDN: cn=First Login Template,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -f newCoS.ldif Enter bind password: adding new entry cn=First Login Template,dc=example,dc=com adding new entry cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com adding new entry cn=First Login CoS,dc=example,dc=com $

例 7–1 パスワードポリシーの割り当ての確認

追加したロールに適合する新しいユーザーを追加します。ユーザーを追加してみて、新しいユーザーが新しいパスワードポリシーの対象となり、既存のユーザーが対象とならないことを確認します。

$ cat quentin.ldif
dn: uid=qcubbins,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: qcubbins
givenName: Quentin
sn: Cubbins
cn: Quentin Cubbins
mail: quentin.cubbins@example.com
userPassword: ch4ngeM3!
description: New account

$ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f quentin.ldif
Enter bind password: 
adding new entry uid=qcubbins,ou=People,dc=example,dc=com

$ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - \
-b dc=example,dc=com uid=qcubbins nsrole pwdPolicySubentry
Enter bind password:
version: 1
dn: uid=qcubbins,ou=People,dc=example,dc=com
nsrole: cn=first login role,ou=people,dc=example,dc=com
pwdPolicySubentry: cn=First Login,dc=example,dc=com
$ ldapsearch -b dc=example,dc=com uid=bjensen nsrole pwdPolicySubentry
version: 1
dn: uid=bjensen, ou=People, dc=example,dc=com
$ 

Barbara Jensen の既存のアカウントにはデフォルトのパスワードポリシーが適用されます。しかし、Quentin Cubbins の新しいアカウントには、定義したパスワードポリシーが適用されます。

pwdSafeModify が TRUE の場合のコマンド行からのパスワードの変更

ユーザーのパスワードポリシーの pwdSafeModify が TRUE に設定されている場合、パスワードを変更するには、新しいパスワードと共に古いパスワードを指定する必要があります。コマンド dsconf set-server-prop pwd-safe-modify-enabled:on は、デフォルトのパスワードポリシーと同じ効果を持ちます。

ldappasswd(1) コマンドを使用してパスワードを変更できます。このコマンドは、安全なパスワードの変更をサポートしています。このコマンドは RFC 3062「LDAP Password Modify Extended Operation」を実装します。

ldapmodify(1) コマンドを使用して、パスワードを変更できます。その場合に ldapmodify コマンドに渡す LDIF は次のようにする必要があります。

dn: パスワードを変更するユーザーの DN
changetype: modify
delete: userPassword
userPassword: 古いパスワード
-
add: userPassword
userPassword: 新しいパスワード

さらに、LDAP パスワード変更拡張操作を使用することもできます。拡張操作のサポートの設定については、「パスワード変更拡張操作によりパスワードをリセットする」で説明しています。

期限切れパスワードのリセット

パスワードポリシーによってパスワードの有効期限を適用している場合、期間内にパスワードを変更しないユーザーもいます。この節では、期限切れになったパスワードを変更する方法を示します。

Directory Server は、エントリのパスワードが変更されるたびにオペレーショナル属性 pwdChangedTime(5dsat) を更新します。結果として、パスワードの有効期限を有効にするために待機している場合、パスワードの有効期限を有効にすると、すでに古くなったユーザーパスワードはすぐに期限切れとなります。この動作が意図と反する場合は、ユーザーに猶予認証でのログインを許可し、すぐにパスワードを変更させるようにしてください。

この節では、パスワード変更拡張操作によってパスワードをリセットする手順と、パスワードの期限が切れた場合に、猶予認証を許可する手順を説明します。

この節で説明するメカニズムは、管理者か、または実際のユーザーとディレクトリとのやり取りを処理するアプリケーションで使用することを意図しています。一般に、エンドユーザーに、意図したとおりにメカニズムを実際に使用させるのは、アプリケーションの役割です。

パスワード変更拡張操作によりパスワードをリセットする

パスワードの有効期限が切れると、ユーザーアカウントがロックされます。パスワードをリセットすると、アカウントのロックが解除されます。パスワードは管理者などのほかのユーザーによってリセットできます。パスワードをリセットすると、Directory Server によってユーザーアカウントのロックが解除されます。Directory Server では、RFC 3062「LDAP Password Modify Extended Operation」をサポートしています。拡張操作を使用して、ディレクトリ管理者またはディレクトリアプリケーションがパスワードのリセットによりアカウントのロックを解除することを許可することができます。

次の手順に示すように、パスワード変更拡張操作の使用を許可する場合は、注意してください。信頼する管理者とアプリケーションにのみアクセスを制限します。ネットワーク上でパスワードをテキストで送受信しないでください。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. パスワード管理者またはパスワード管理アプリケーションにユーザーアクセス権を与えます。

2. パスワード管理者がパスワード変更拡張操作にアクセスして使用できるようにします。

   次のコマンドは、Password Managers ロールのメンバーが SSL で接続した場合にパスワード変更拡張操作を使用できるようにする ACI を設定します。

   $ cat exop.ldif dn: oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.4203.1.11.1 cn: Password Modify Extended Operation aci: (targetattr != "aci")(version 3.0; acl "Password Modify Extended Operation "; allow( read, search, compare, proxy ) (roledn = " ldap:///cn=Password Managers,dc=example,dc=com" and authmethod = "SSL");) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f exop.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config $

   cn=features,cn=config の下のエントリにより、パスワード変更拡張操作を使用する操作へのアクセスを管理します。

3. パスワード管理者にユーザーパスワードをリセットしてもらいます。

   この手順は、ユーザーアカウントのロックを解除し、ldappasswd(1) コマンドで実行できます。

4. (省略可能) ユーザーがパスワードを変更する必要がある場合は、パスワード管理者にユーザーに通知してもらいます。

   ユーザーエントリを管理するパスワードポリシーに pwdMustChange: TRUE が含まれる場合、リセット後にユーザーは自身のパスワードを変更する必要があります。

パスワードの期限が切れた場合に猶予認証を許可する

次の手順では、ユーザーに猶予認証を与え、ユーザーが期限切れになったパスワードを変更できるようにする方法を説明します。

猶予認証は、パスワードポリシーの要求および応答コントロールを処理するアプリケーションによって管理することを意図しています。この手順では、アプリケーションでコントロールを使用する方法の単純な例を示します。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. ユーザーがパスワードポリシーの要求および応答コントロールを使用するアプリケーションに対するアクセス権を持つことを確認します。

   アプリケーションでは、ユーザーが猶予認証を適切に処理していることを確認する必要があります。

2. アプリケーションでパスワードポリシーコントロールを使用できるようにします。

   次のコマンドは、Password Managers ロールのメンバーがパスワードポリシーコントロールを使用できるようにする ACI を設定します。

   $ cat ctrl.ldif dn: oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.42.2.27.8.5.1 cn: Password Policy Controls aci: (targetattr != "aci")(version 3.0; acl "Password Policy Controls "; allow( read, search, compare, proxy ) roledn = " ldap:///cn=Password Managers,dc=example,dc=com";) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f ctrl.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config $

   cn=features,cn=config の下のエントリの目的は、パスワードポリシーの要求および応答コントロールを使用する操作へのアクセスを管理できるようにすることだけです。

3. パスワードポリシーの pwdGraceAuthNLimit 属性で、パスワードの期限が切れたあとに猶予認証によるログインを何回許可するかを設定します。

4. アプリケーション側では、ユーザーに対して猶予認証の許可されている回数内で期限の切れているパスワードをすみやかに変更しなければならないことを指示する必要があります。

アカウントプロパティーの設定

次の各節で、アカウントの検索制限、サイズ制限、時間制限、およびアイドルタイムアウトの設定方法について説明します。

アカウントに対する検索制限を設定する

1. ldapmodify コマンドを使用して、nsLookThroughLimit の値を設定します。

   次のコマンドで、Barbara Jensen の検索制限が解除されます。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsLookThroughLimit nsLookThroughLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

アカウントに対するサイズ制限を設定する

1. ldapmodify コマンドを使用して、nsSizeLimit の値を設定します。

   次のコマンドで、Barbara Jensen のサイズ制限が解除されます。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsSizeLimit nsSizeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

アカウントに対する時間制限を設定する

1. ldapmodify コマンドを使用して、nsTimeLimit の値を設定します。

   次のコマンドで、Barbara Jensen の時間制限が解除されます。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsTimeLimit nsTimeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

アカウントに対するアイドルタイムアウトを設定する

1. ldapmodify コマンドを使用して、nsIdleTimeout の値を設定します。

   次のコマンドで、Barbara Jensen のアイドルタイムアウトが 5 分 (300 秒) に設定されます。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsIdleTimeout nsIdleTimeout: 300 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

アカウントの手動でのロック

Directory Server では、指定した回数のバインド試行が失敗した後に、アカウントを強制的にロックアウトするパスワードポリシーを設定できます。詳細については、「アカウントロックアウトのポリシー」を参照してください。この節では、ディレクトリマネージャーが使用できる手動のアカウントロックおよびアクティブ化ツールについて説明します。

ディレクトリマネージャーは、ロックアウト期間タイマーを使用せずに、アカウントロックアウトを管理できます。ロックされたアカウントは、パスワードを手動でリセットするまで、ロックされます。ディレクトリマネージャーは、無期限で特定のアカウントを無効化することもできます。

この節では、アカウントのステータスを確認し、アカウントを無効化して、再びアクティブ化する方法を説明します。

アカウントのステータスを確認する

次に示すように、アカウントのステータスを確認します。

ディレクトリマネージャーとしてバインドする必要があります。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. アカウントまたはロールのステータスを確認するには、ns-accountstatus コマンドを使用します。

   次のコマンドは、Barbara Jensen のアカウントのステータスを確認します。

   $ ns-accountstatus -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated. $

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

アカウントを無効化する

次に示すように、アカウントまたはロールを無効化します。

ディレクトリマネージャーとしてバインドする必要があります。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. アカウントまたはロールを無効化するには、ns-inactivate コマンドを使用します。

   次のコマンドでは、Barbara Jensen のアカウントを無効化します。

   $ ns-inactivate -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com inactivated. $

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

アカウントをふたたびアクティブ化する

次に示すように、アカウントまたはロールのロックを解除します。

ディレクトリマネージャーとしてバインドする必要があります。

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

1. アカウントまたはロールをふたたびアクティブ化するには、ns-activate コマンドを使用します。

   次のコマンドは、Barbara Jensen のアカウントをふたたびアクティブ化します。

   $ ns-activate -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated. $

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

第 8 章 Directory Server のバックアップと復元

Directory Server で管理されるデータは、まとめてインポートされることがよくあります。Directory Server Enterprise Edition には、サフィックス全体のインポートとエクスポートを行うツールが用意されています。また、一度にすべてのサフィックスのバックアップを作成したり、すべてのデータをバックアップから復元したりするツールも用意されています。

バックアップや復元の操作を始める前に、現在の状況に合うバックアップおよび復元戦略を設計するようにしてください。さまざまなバックアップオプション、考慮事項、バックアップおよび復元戦略を計画する際のガイドラインの詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 配備計画ガイド』の「バックアップと復元のポリシーの設計」を参照してください。

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

• 「バイナリバックアップ」

• 「LDIF へのバックアップ」

• 「バイナリ復元」

• 「LDIF ファイルからのデータのインポート」

• 「レプリケートされたサフィックスの復元」

• 「障害からの回復」

バイナリバックアップ

この節では、ディレクトリデータのバイナリバックアップを実行する方法について説明します。この節で説明するバイナリバックアップ手順以外にも、サフィックスをレプリケーショントポロジで初期化するためのバイナリコピーを作成できます。「バイナリコピーを使用したレプリケートされたサフィックスの初期化」を参照してください。

ディレクトリデータのみのバックアップ

バイナリデータのバックアップでは、あとでデータベースファイルが破損したり削除されたりする場合に使用できる、ディレクトリデータのコピーを保存できます。この操作では、設定データはバックアップされません。障害回復のために Directory Server 全体をバックアップする場合は、「障害からの回復」を参照してください。

バックアップの処理中には、サーバーを停止しないでください。

バックアップは、「削除の遅延」よりも頻繁に実行する必要があります。nsDS5ReplicaPurgeDelay 属性によって指定される削除の遅延は、更新履歴ログに対して内部削除操作を開始するまでの期間 (秒単位) です。デフォルトの削除の遅延は 604800 秒 (1 週間) です。更新履歴ログは、レプリケートが完了している、またはレプリケートが完了していない更新の記録を保持しています。

更新の頻度が削除の遅延より低い場合、バックアップを行う前に更新履歴ログの内容がクリアされてしまう可能性があります。この場合、バックアップからデータを復元しようとしても、バックアップ前にクリアされた更新記録は失われています。

この節で説明するバックアップ手順では、サーバーファイルのコピーがデフォルトで同じホスト上に格納されます。セキュリティー強化のために、このバックアップを別のマシンや別のファイルシステムにコピーして格納してください。

ディレクトリデータをバックアップする

Directory Server を停止して dsadm backup コマンドを実行する必要があります。

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

1. ディレクトリデータをバックアップします。

   $ dsadm backup instance-path archive-dir

   次に例を示します。

   $ dsadm backup /local/ds /local/tmp/20051205

   ---

   注 –

   サーバーの稼働中は、dsconf backup コマンドを使用してディレクトリデータをバックアップできます。ただし、バックアップの実行中にディレクトリデータに変更を加えると、適切に復旧することが難しくなります。dsconf backup の使用時にこの問題を回避するには、レプリケーションのリフェラルを設定するか、サーバーを読み取り専用にします。

   ---

   dsadm コマンドと dsconf コマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

dse.ldif ファイルをバックアップする

サーバーを復元する場合、dse.ldif 設定ファイルに、サーバーのバックアップ時と同じ設定情報を指定する必要があります。

1. dse.ldif 設定ファイルをバックアップします。

   $ cp instance-path/config/dse.ldif archive-dir

   次の操作を実行すると、Directory Server は自動的に dse.ldif 設定ファイルのバックアップをディレクトリ instance-path/config に作成します。

   • Directory Server を起動すると、dse.ldif ファイルのバックアップが、dse.ldif.startOK というファイルに作成されます。

   • cn=config ブランチの内容を変更する場合は、サーバーが dse.ldif ファイルに変更を書き込む前に、ファイルが onfigディレクトリの dse.ldif.bak ファイルにバックアップされます。

ファイルシステムのバックアップ

この手順では、「凍結モード」機能を使用します。凍結モードでは、ディスク上のデータベース更新を停止できるため、ファイルシステムのスナップショットを安全に撮ることができます。堅固なバックアップを確実にするため、凍結モードを追加の手段として使用できます。

ファイルシステムのバックアップの進行中は、サーバーでディスク上のユーザーデータを書き込むことはできません。特定の時間内に更新が行われないことが確実な場合は、この時間内にバックアップを行います。更新が行われないことを保証できない場合は、バックアップを行う前にサーバーを凍結モードにします。

凍結モードのサーバーでは、アクセスログとエラーログへの書き込みが継続されます。シングルサーバーのトポロジでは、凍結モードがオンの場合に受信される操作によって LDAP エラーが返されます。ログに記録されるエラーメッセージは、オフラインのデータベースに対する標準的なエラーです。レプリケートされたトポロジでは、リフェラルが返されます。凍結モードを適切に機能させるには、データベース上でほかのタスクを実行しないようにしてください。

凍結モードのサーバーのデータベースは、読み取り専用モードのデータベースより安定しています。凍結モードとは異なり、読み取り専用モードでは、タスクの作成と設定エントリの変更ができます。凍結モードがオンの場合、設定されたすべてのデータベースはオフラインになります。進行中の内部操作には、オフラインになるデータベースが通知されます。進行中の LDAP 操作は完了し、データベース環境はフラッシュします。ユーザーデータの検索を含むそれ以降の着信操作は、凍結モードがオフに設定されるまで拒否されます。ただし、凍結モードがオンの場合でも設定パラメータの検索はできます。

ファイルシステムをバックアップする

この手順の一部として、DSCC を使用してこの作業を実行できます。詳細については、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。手順のその他の部分は、コマンド行を使用した場合にのみ実行できます。

1. (省略可能) サーバーを凍結モードにします。

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

2. ファイルシステムのタイプに合うツールを使って、ファイルシステムをバックアップします。

3. サーバーが凍結モードになっている場合は、再度サーバーを読み書き可能にします。

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

   サーバーがレプリケーションの更新を別のサーバーから受け取った場合は、凍結モードがオフになるとすぐにレプリケーションの更新が始まります。

LDIF へのバックアップ

LDIF へのバックアップにより、ディレクトリデータを書式付き LDF ファイルにバックアップできます。

LDIF へのエクスポート

LDIF でサフィックスの内容をエクスポートすることで、ディレクトリデータをバックアップできます。データのエクスポートは、次のような場合に便利です。

• サーバー上のデータのバックアップ。

• 他のディレクトリサーバーへのデータのコピー。

• 他のアプリケーションへのデータのエクスポート。

• ディレクトリトポロジ変更後のサフィックスの再生成。

エクスポート処理を実行しても、設定情報 (cn=config) はエクスポートされません。

エクスポート処理の実行中には、サーバーを停止しないでください。

サフィックスを LDIF にエクスポートする

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

1. サフィックスを LDIF ファイルにエクスポートするには、次のコマンドのいずれかを使用します。

   • サーバーがローカルにあり、停止している場合は、次のように入力します。

     $ dsadm export instance-path suffix-DN LDIF-file

   • サーバーがリモートにあり、実行中の場合は、次のように入力します。

     $ dsconf export -h host -p port suffix-DN LDIF-file

   次の例では、dsconf export を使用して、2 つのサフィックスを単一の LDIF ファイルにエクスポートします。

   $ dsconf export -h host1 -p 1389 ou=people,dc=example,dc=com \ ou=contractors,dc=example,dc=com /local/ds/ldif/export123.ldif

   dsadm export コマンドと dsconf export コマンドでは、--no-repl オプションを指定して、レプリケーション情報がエクスポートされないように指定することもできます。デフォルトでは、レプリケートされたサフィックスはレプリケーション情報とともに LDIF ファイルにエクスポートされます。結果として作成される LDIF ファイルには、レプリケーションメカニズムで使用される属性サブタイプが含まれています。あとでこの LDIF ファイルをコンシューマサーバーにインポートして、コンシューマレプリカを初期化できます。この手順については、「レプリカの初期化」を参照してください。

   これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

バイナリ復元

次に示す手順では、サフィックスをディレクトリに格納する方法を示します。サーバーは、「ディレクトリデータのみのバックアップ」で説明した手順で、あらかじめバックアップされている必要があります。レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」をお読みください。

復元の処理中には、サーバーを停止しないでください。サーバーを復元すると既存のデータベースファイルが上書きされるため、バックアップのあとに行なった変更は失われます。

サーバーを復元する

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

1. サーバーを復元するには、次のコマンドのいずれかを使用します。

   • サーバーがローカルにあり、停止している場合は、次のように入力します。

     $ dsadm restore instance-path archive-dir

     たとえば、バックアップをバックアップディレクトリから復元するには、次のように入力します。

     $ dsadm restore /local/ds/ local/ds/bak/2006_07_01_11_34_00

   • サーバーがリモートにあり、実行中の場合は、次のように入力します。

     $ dsconf restore -h host -p port archive-dir

     たとえば、バックアップをバックアップディレクトリから復元するには、次のように入力します。

     $ dsconf restore -h host1 -p 1389 /local/ds/bak/2006_07_01_11_34_00

   これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

dse.ldif 設定ファイルの復元

Directory Server では、次のディレクトリ内に、dse.ldif ファイルのバックアップコピーが 2 つ作成されます。

instance-path/config

dse.ldif.startOK ファイルには、サーバー起動時に dse.ldif ファイルのコピーが記録されます。dse.ldif.bak ファイルには、dse.ldif ファイルに加えられた最新の変更内容のバックアップが含まれます。最新の変更内容を含むファイルを自分のディレクトリにコピーします。

dse.ldif 設定ファイルを作成する

この手順の一部として、DSCC を使用してこの作業を実行できます。詳細については、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。手順のその他の部分は、コマンド行を使用した場合にのみ実行できます。

1. サーバーを停止します。

   $ dsadm stop instance-path

2. 設定ファイルが入っているディレクトリに移動します。

   $ cd instance-path/config

3. 有効であることがわかっているバックアップ設定ファイルで dse.ldif ファイルを上書きします。たとえば、次のように入力します。

   $ cp dse.ldif.startOK dse.ldif

4. 次のコマンドでサーバーを起動します。

   $ dsadm start instance-path

LDIF ファイルからのデータのインポート

次のような方法で、データを Directory Server サフィックスにインポートできます。

• LDIF ファイルからサフィックスを初期化します。この操作により、サフィックス内の現在のデータが削除され、LDIF ファイルの内容と置き換えられます。

• ldapadd、 ldapmodify、または ldapdelete 操作をまとめて実行するには、LDIF ファイルを使用します。これにより、ディレクトリ内の任意のサフィックスについて、そのエントリをまとめて追加、変更、削除できます。

次の表は、サフィックスの初期化と、エントリの一括の追加、変更、削除の違いを示しています。

サフィックスの初期化

サフィックスを初期化すると、サフィックスに含まれている既存のデータが、追加するエントリだけを含む LDIF ファイルの内容によって上書きされます。

サフィックスを初期化するユーザーは、ディレクトリマネージャーまたは管理者としての認証を受けている必要があります。

サーバーが実行中の場合、ルートエントリを含む LDIF ファイルをインポートできるのは、ディレクトリマネージャーと管理者のみです。セキュリティー上の理由により、これらのユーザーのみが、たとえば dc=example,dc=com. のようなサフィックスのルートエントリへのアクセス権を持ちます。

レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」をお読みください。

サフィックスを初期化する

インポートする LDIF ファイルでは、UTF-8 文字セットエンコードが使用されている必要があります。

サフィックスを初期化するときは、ルートエントリと、対応するサフィックスのすべてのディレクトリツリーノードが LDIF ファイルに含まれている必要があります。

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

1. 次のコマンドのいずれかを使用して、LDIF ファイルからサフィックスを初期化します。つまり、データベースの内容を LDIF ファイルにインポートします。

   ---

   注意 –

   次のコマンドで、サフィックスのデータを上書きします。

   ---

   • サーバーがローカルにあり、停止している場合は、次のように入力します。

     $ dsadm import instance-path LDIF-file suffix-DN

     次の例では、dsadm import コマンドを使用して、LDIF ファイルを 1 つのサフィックスにインポートします。

     $ dsadm import /local/ds /local/file/example/demo1.ldif \ /local/file/example/demo2.ldif dc=example,dc=com

   • サーバーがリモートにあり、実行中の場合は、次のように入力します。

     $ dsconf import -h host -p port LDIF-file suffix-DN

     次の例では、dsconf import を使用して LDIF ファイルをインポートします。このコマンドを実行するために root 権限は必要ありませんが、ディレクトリマネージャーなどの root 権限を持つユーザーとして認証される必要があります。

     $ dsconf import -h host1 -p 1389 /local/file/example/demo1.ldif \ ou=People,dc=example,dc=com

   ---

   注 –

   dsconf import か dsconf reindex のいずれか、または複数のサフィックスで並行して両方のコマンドを実行すると、トランザクションログが大きくなり、パフォーマンスに悪影響を及ぼすことがあります。

   ---

   これらのコマンドの詳細については、dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

エントリの一括の追加、変更、削除

ldapmodify 操作を実行すると、エントリをまとめて追加、変更、削除できます。エントリは、既存のエントリを変更または削除するための更新文を含む LDIF ファイルに指定されています。この操作では、すでに存在しているエントリは消去されません。

変更されたエントリは、Directory Server で管理されるサフィックスの対象となることがあります。エントリを追加するほかの処理と同様に、インポートされた新しいエントリすべてにインデックスが付けられます。

ldapmodify コマンドにより、LDAP によって LDIF ファイルがインポートされ、このファイルに含まれるすべての操作が実行されます。このコマンドを使用すると、すべてのディレクトリサフィックスのデータを同時に変更できます。

レプリケーションアグリーメントに関連するサフィックスを復元する前に、「レプリケートされたサフィックスの復元」を参照してください。

エントリをまとめて追加、変更、削除する

インポートする LDIF ファイルでは、UTF-8 文字セットエンコードが使用されている必要があります。

LDIF をインポートするときは、ディレクトリ内に親エントリが存在するか、ファイルから親エントリを最初にコピーする必要があります。

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

1. LDIF ファイルからまとめて追加、変更、または削除します。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -B baseDN -f LDIF-file

   次の例では、ldapmodify コマンドを使用してインポートが実行されます。このコマンドを実行するために root 権限は必要ありませんが、cn=Directory Manager や cn=admin,cn=Administrators,cn=config などの root 権限を持つユーザーとして認証される必要があります。最後のパラメータは、インポートする LDIF ファイルの名前を指定するものです。

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - \ -B dc=example,dc=com -f /local/ds/ldif/demo.ldif

レプリケートされたサフィックスの復元

サプライヤサーバーとコンシューマサーバーの間でレプリケートされるサフィックスを復元する場合は、特別な注意が必要です。可能な場合は、サフィックスをバックアップから復元するのではなく、レプリケーションメカニズムにより更新するようにしてください。

サプライヤまたはハブインスタンスを復元する場合、サーバーはバックアップ時と同じ設定にする必要があります。これを確実に実行するには、Directory Server データを復元する前に、dse.ldif ファイルを復元します。「dse.ldif 設定ファイルの復元」を参照してください。

ここでは、レプリカを復元すべき場合とその方法、および復元後にほかのレプリカとの同期を確保する方法について説明します。レプリカの初期化については、「レプリカの初期化」を参照してください。

レプリケートされたサフィックスが大規模で、多数のエントリを追加し、レプリケーションの更新を確実に正しく追加されるようにする場合は、「大量のレプリケートされたサフィックスへの多数のエントリの段階的追加」を参照してください。

この節では、次の情報について説明します。

• 「シングルマスターモデルでのサプライヤの復元」

• 「マルチマスターモデルでのサプライヤの復元」

• 「ハブの復元」

• 「専用コンシューマの復元」

• 「マルチマスターモデルでのマスターの復元」

シングルマスターモデルでのサプライヤの復元

シングルマスターサプライヤであるサフィックスには、レプリケーショントポロジ全体に対して重要なデータ (authoritative data) が含まれています。したがって、このサフィックスを復元することは、トポロジ全体のすべてのデータを初期化し直すことと同じです。シングルマスターを復元するのは、復元するバックアップの内容ですべてのデータを初期化し直す場合に限定してください。

エラーのためにシングルマスターのデータを復旧できない場合は、コンシューマ上のデータを使用することも検討してください。これは、バックアップされたデータより新しい更新がコンシューマ上のデータに含まれている可能性があるためです。この場合は、コンシューマレプリカから LDIF ファイルにデータをエクスポートし、この LDIF ファイルを使用してマスターを初期化し直します。

バックアップから復元する場合でも、LDIF ファイルをインポートする場合でも、このマスターレプリカから更新を受け取るすべてのハブレプリカとコンシューマレプリカをあとで初期化し直す必要があります。コンシューマの再初期化が必要であることを示すメッセージが、サプライヤサーバーのログファイルに記録されます。

マルチマスターモデルでのサプライヤの復元

マルチマスターレプリケーションでは、ほかの各マスターも、レプリケートされるデータに対してコピーする権限を持っています。現在のレプリカの内容が反映されていない可能性があるため、古いバックアップを復元することはできません。可能な場合は、レプリケーションメカニズムにより、ほかのマスターの内容を使用してマスターを更新するようにしてください。

それが不可能な場合は、次のどちらかの方法でマルチマスターレプリカを復元してください。

• もっとも簡単な方法として、バックアップから復元する代わりに、ほかのマスターの 1 つを使用して目的のマスターを初期化し直します。これにより、目的のマスターに最新のデータが送られ、データはすぐにレプリケートできる状態になります。「LDIF からのレプリカの初期化」を参照してください。

• 数百万のエントリを持つレプリカの場合は、バイナリコピーを作成して、ほかのマスターの 1 つから作成したより新しいバックアップから復元することで、時間を短縮できます。「バイナリコピーを使用したレプリケートされたサフィックスの初期化」を参照してください。

• このマスターのバックアップが、ほかのどのマスターに対しても更新履歴ログの最長保存期間を過ぎていない場合は、このバックアップを使用してマスターを復元できます。更新履歴ログの保存期間については、「マスターレプリカの更新履歴ログ設定を変更する」を参照してください。このようにバックアップからマスターを復元すると、ほかのマスターはそれぞれの更新履歴ログを使用して、このマスターを更新します。これにより、バックアップの作成時以降に加えられた変更内容がすべてこのマスターに反映されます。

復元や再初期化の方法にかかわらず、初期化後のマスターレプリカは読み取り専用モードになります。この動作により、このレプリカとほかのマスターとの同期をとったあとに、書き込み操作を許可できます。詳細は、「マルチマスターモデルでのマスターの復元」を参照してください。

復元または初期化し直したマスターに書き込み操作を許可する前に、すべてのレプリカを反映させることができるので、ハブサーバーやコンシューマサーバーを初期化し直すことが不要になるという利点があります。

ハブの復元

この節の内容は、レプリケーションメカニズムで自動的にハブレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、ハブレプリカを復元または初期化し直す必要があります。

• もっとも簡単な方法として、バックアップから復元する代わりに、ほかのマスターレプリカの 1 つを使用してハブを初期化し直します。これにより、ハブに最新のデータが送られ、データはすぐにレプリケートできる状態になります。「サフィックスの初期化」を参照してください。

• 数百万のエントリを持つレプリカの場合は、バイナリコピーを作成して、別のハブのレプリカサフィックスから作成したより新しいバックアップから復元することで、所要時間を短縮できます。「バイナリコピーを使用したレプリケートされたサフィックスの初期化」を参照してください。コピーできるほかのハブレプリカがない場合は、前の項目で説明した方法でハブを初期化し直すか、可能な場合は、次の項目で説明するようにハブを復元します。

• このハブのバックアップが、そのサプライヤ (ハブレプリカまたはマスターレプリカ) のどちらに対しても更新履歴ログの最長保存期間を過ぎていない場合は、このバックアップを使用してハブを復元できます。ハブが復元されると、そのサプライヤはそれぞれの更新履歴ログを使用して、このハブを更新します。これにより、バックアップの作成時以降に加えられた変更内容が、すべてこのハブに反映されます。

ハブレプリカの復元や再初期化の方法にかかわらず、あとでこのハブのコンシューマをすべて初期化し直す必要があります。ほかのレベルのハブもすべて初期化し直す必要があります。

専用コンシューマの復元

この節の内容は、レプリケーションメカニズムで自動的に専用コンシューマレプリカを更新できない場合だけに適用されます。このような状況として、データベースファイルが破損した場合や、レプリケーションが長時間にわたって中断された場合が含まれます。このような場合は、次のいずれかの方法で、コンシューマを復元または初期化し直す必要があります。

• もっとも簡単な方法として、バックアップから復元する代わりに、そのサプライヤの 1 つ (マスターレプリカまたはハブレプリカ) を使用してコンシューマを初期化し直します。これにより、コンシューマに最新のデータが送られ、データはすぐにレプリケートできる状態になります。「LDIF からのレプリカの初期化」を参照してください。

• 数百万のエントリを持つレプリカの場合は、バイナリコピーを作成して、別のコンシューマのレプリカサフィックスから作成したより新しいバックアップから復元することで、所要時間を短縮できます。「バイナリコピーを使用したレプリケートされたサフィックスの初期化」を参照してください。コピーできるほかのコンシューマレプリカがない場合は、前の項目で説明した方法でレプリカを初期化し直すか、可能な場合は、次の項目で説明するようにハブを復元します。

• このコンシューマのバックアップが、そのサプライヤ (ハブレプリカまたはマスターレプリカ) のどちらに対しても更新履歴ログの最長保存期間を過ぎていない場合は、このバックアップを使用してこのコンシューマを復元できます。このようにコンシューマを復元すると、そのサプライヤはそれぞれの更新履歴ログを使用して、コンシューマを更新します。これにより、バックアップの作成時以降に加えられた変更内容が、すべてこのコンシューマに反映されます。

マルチマスターモデルでのマスターの復元

マルチマスターレプリケーションでは、あるマスターの復元中に他のマスターが変更を処理することもあります。このため、復元が完了した時点で、新しいマスターは復元データに含まれていなかった新しい更新を受け取る必要があります。マスターの復元には時間がかかるため、その間に発生する未適用の更新の数も問題となることがあります。

これらの未適用更新が適用されるように、新たに復元されたマスターは、復元後、クライアント側からの操作に対して自動的に読み取り専用モードに設定されます。これは、コマンド行で LDIF ファイルからデータをインポートするか、バックアップを使用してバイナリコピーを実行することで、マスターを復元する場合のみに当てはまります。

したがって、マルチマスター設定の復元後のマスターは、レプリケーションの更新を処理し、クライアントからの読み取り操作を受け付けますが、すべての書き込み操作に対してはリフェラルを返します。

更新を許可する前に、新しいマスターがほかのマスターと完全に同期していることを確認するには、初期化されたマスターを手動で更新できるようにします。

この新しい対応方法によってマスターレプリカがリフェラルを送信する場合、書き込み処理を待機しているクライアントのホップ回数が、制限回数に達してしまうことも考えられます。利用可能なマスターにアクセスできるように、クライアントのホップ制限の設定を変更する必要があるかもしれません。すべてのマスターレプリカを初期化または再初期化するときは、どのレプリカもクライアントからの更新を受け付けられないため、すべての書き込み処理が失敗します。

サーバーの応答を最大化するには、いかなる場合も初期化したマスターを注意深く監視し、リフェラルの属性を適切に設定してください。

コマンド行による更新の受け付けを開始する

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

次のコマンドは、マルチマスターレプリカの初期化プロセスを自動化するスクリプトで使用できます。

1. insync ツールを使用して、レプリカの状態が他のすべてのマスターと一致していることを確認します。

   すべてのサーバーで変更の遅れがゼロである場合、またはそのレプリカに適用する更新がなかった場合 (遅れが -1 となる場合) は、すべてのレプリカが同期しています。詳細については、insync(1) のマニュアルページを参照してください。

2. 更新の受け付けを始めます。

   $ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on

   このコマンドは、サーバーを自動的に読み書きモードに設定します。

障害からの回復

Directory Server を障害回復の目的でバックアップまたは復元する場合は、次の手順に従います。

障害回復用のバックアップを作成する

この手順の一部として、DSCC を使用してこの作業を実行できます。詳細については、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。手順のその他の部分は、コマンド行を使用した場合にのみ実行できます。

1. dsadn backup コマンドまたは dsconf backup コマンドを使用して、データベースファイルのバックアップを作成します。

   「バイナリバックアップ」で説明する手順に従い、バックアップファイルを安全な場所に保管します。

2. 設定ディレクトリ instance-path /config を安全な場所にコピーします。

3. スキーマディレクトリ instance-path/config/schema を安全な場所にコピーします。

4. 別名ディレクトリ instance-path/alias を安全な場所にコピーします。

障害回復のために復元する