第 2 章ディレクトリエントリの管理

この章では、Directory Server コンソールと LDAP コマンド行ユーティリティを使用してディレクトリの内容を管理する方法について説明します。また、オプションの属性暗号化機能を使用して属性を保存する方法と、DSML を使用してディレクトリにアクセスする方法についても説明します。ディレクトリの導入を計画する場合には、ディレクトリに格納するデータの種類を把握する必要があります。エントリを作成したり、デフォルトのスキーマを変更したりする前に、『Directory Server 配備計画ガイド』の第 2 章にある「ディレクトリデータの計画とアクセス」を参照してください。

この章は、LDAP スキーマ、オブジェクトクラス、およびオブジェクトクラスに定義される属性について、ある程度の知識が読者にあることを前提としています。スキーマと、すべてのオブジェクトクラスの定義、および Directory Server で指定される属性の概要については、『Directory Server Administration Reference』の「Object Class Reference」および「Attribute Reference」の章を参照してください。

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

設定エントリ

Directory Server は、すべての設定情報を次のファイルに保存します。

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

Directory Server では、LDAP を通じてすべての設定を読み取り、書き込むことができます。デフォルトでは、ディレクトリの cn=config ブランチには、管理サーバーに定義されているディレクトリ管理者と、Directory Manager だけがアクセスできます。これらの管理ユーザーは、他のディレクトリエントリと同様に、設定エントリを表示、変更できます。

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

コンソールからの設定の変更

設定を変更するときは、Directory Server コンソールの最上位にある「設定」タブを使用することをお勧めします。このタブのパネルとダイアログには、タスクベースの制御が用意されており、迅速かつ効率的な設定に役立ちます。また、コンソールのインタフェースは、設定の複雑さや相互依存の解決に役立ちます。

このマニュアルで、コンソールのインタフェースを使った設定手順を説明するときは、「コンソールからの～」という見出しで示されます。これらの手順は、「設定」タブのパネルとダイアログを使用して特定の管理タスクを実行する方法を説明します。変更を適用するためにサーバーの再起動が必要な場合は、設定の保存方法がインタフェース自体にも明示されます。

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

cn=config サブツリーには LDAP を通じてアクセスできるので、ldapsearch、ldapmodify、ldapdelete コマンドを使用して、サーバーの設定を表示、変更することができます。cn=config エントリとその下のすべてのエントリは、「コマンド行からのエントリの管理」で説明する手順と LDIF 形式を使用して変更できます。

ただし、これらのエントリの意味、および許容される属性と値の目的を理解しておくことは重要です。このマニュアルでは、「コマンド行からの～」という見出しがつけられた手順で、重要な注意点を説明します。これらの手順には、設定エントリの例や、設定できる属性が示されます。すべての設定エントリとその属性、および属性に設定できる値の範囲について詳細は、『Directory Server Administration Reference』を参照してください。

コマンド行からの設定の変更は、コンソールを利用した変更ほど単純ではありません。しかし、一部の設定は、コンソールから変更することができず、コマンド行からの操作だけを受け付けます。また、コマンド行からの手順を利用する場合は、コマンド行ツールを使ったスクリプトを記述することで、設定タスクを自動化することができます。

dse.ldif ファイルの変更

dse.ldif ファイルには、サーバーの起動時または再起動時に読み取られ、適用される設定が含まれます。このファイルの LDIF コンテンツは、cn=config エントリとそのサブツリーです。ファイルの読み取りと書き込みが許可されているのは、インストール時に定義されたシステムユーザーだけです。

このファイルの内容を直接編集して設定を変更することは、エラーが生じる可能性が高くなるため、お勧めできません。次の点に注意が必要です。

コンソールからのエントリの管理

Directory Server コンソールの「ディレクトリ」タブとエントリエディタダイアログを使用して、エントリの追加、変更、または削除を個別に行うことができます。複数のエントリに対して同時に処理を行う方法については、「コンソールからの一括処理」を参照してください。

Directory Server コンソールの起動およびユーザーインタフェースの使用方法については、「Directory Server コンソールの使用」を参照してください。

ディレクトリエントリの作成

Directory Server コンソールには、ディレクトリエントリの作成に使用できる、カスタムテンプレートがいくつか用意されています。それぞれのテンプレートは、オブジェクトクラスの種類に固有のカスタムエディタです。表 2-1 は、各カスタムエディタで使用されるオブジェクトクラスを示しています。

表 2-1 エントリテンプレートと対応するオブジェクトクラス
テンプレート	オブジェクトクラス
ユーザー	inetOrgPerson (作成および編集用) organizationalPerson (編集用) person (編集用)
グループ	groupOfUniqueNames およびその他のダイナミックグループおよび証明書グループ
組織単位	organizationalUnit
ロール	nsRoleDefinition、および管理されたロール、フィルタリングされたロール、または入れ子のロールのいずれかを選択するかに応じてその他のクラス
サービスクラス	cosSuperDefinition、およびサービスクラスのタイプに応じてその他のクラス
パスワードポリシー	passwordPolicy
リフェラル	referral

これらのカスタムエディタには、対応するオブジェクトクラスのすべての必須属性と、共通して使用される一部のオプション属性を表すフィールドが含まれています。いずれかのテンプレートを使用してエントリを作成する方法については、「カスタムエディタを使用したエントリの作成」を参照してください。その他のタイプのエントリを作成する方法については、「その他のタイプのエントリの作成」を参照してください。

カスタムエディタを使用したエントリの作成

Directory Server コンソールの最上位にある「ディレクトリ」タブで、ディレクトリツリーを展開して、新しいエントリの親となるエントリを表示します。

親エントリをマウスの右ボタンでクリックし、「新規」メニューを選び、サブメニューの「ユーザー」、「グループ」、「組織単位」、「ロール」、「サービスクラス」、「パスワードポリシー」、「リフェラル」の中からエントリのタイプを選択します。あるいは、親エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「新規」を選びます。選択したエントリタイプのカスタムエディタダイアログが表示されます。

カスタムエディタの左側の列には複数のタブがあり、各タブのフィールドが右側に表示されます。デフォルトでは、すべてのカスタムエディタは、「ユーザー」タブまたは「一般」タブが選択された状態で表示されます。これらのタブには、新しいエントリの名前と説明を入力するためのフィールドが含まれます。

次の図はユーザーエントリのカスタムエディタを示しています。

図 2-1 Directory Server コンソール : ユーザーエントリのカスタムエディタ
名前、ユーザー ID、パスワード、電話番号、その他のユーザー情報を入力するフィールドの表示された「新規ユーザーの作成」ウィンドウ

カスタムエディタで、設定する属性のフィールドに値を入力します。フィールド名の隣にアスタリスク (*) が表示されたすべての必須属性には値を入力する必要があります。その他のフィールドには何も入力しなくても問題ありません。複数の値を入力できるフィールドでは、Return で値を区切ります。

指定したエントリタイプのカスタムエディタの各フィールドについて、説明を表示するときは「ヘルプ」ボタンをクリックします。「ユーザー」エディタと「組織単位」エディタの「言語」タブの説明については、「言語サポートの属性の設定」を参照してください。

サービスエントリのグループ、ロール、クラスを作成する方法については、第 5 章「ID とロールの管理」を参照してください。パスワードポリシーの作成については、第 7 章「ユーザーアカウントとパスワードの管理」を参照してください。リフェラルの作成については、「リフェラルの設定」を参照してください。

「了解」をクリックして新しいエントリを作成し、カスタムエディタダイアログを閉じます。新しいエントリがディレクトリツリーに表示されます。

カスタムエディタダイアログには、対応するオブジェクトクラスのすべてのオプション属性のフィールドが表示されるわけではありません。カスタムエディタに表示されないオプション属性を追加する方法については、「汎用エディタによるエントリの変更」を参照してください。

その他のタイプのエントリの作成

表 2-1 に示されるオブジェクトクラス以外のオブジェクトクラスのエントリを作成するには、次の手順を実行します。この手順を実行して、ディレクトリスキーマに定義したカスタムオブジェクトクラスのエントリを作成することもできます。

親エントリをマウスの右ボタンでクリックして「新規」を選び、サブメニューから「その他」を選択します。あるいは、親エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「新規」、「その他」を順に選択することもできます。

「新規オブジェクト」ダイアログが表示されます。

「新規オブジェクト」ダイアログに表示されるオブジェクトクラスのリストから、新しいエントリを定義するオブジェクトクラスを選び、「了解」をクリックします。

表 2-1 に示されるオブジェクトクラスを選択した場合は、対応するカスタムエディタが表示されます (「カスタムエディタを使用したエントリの作成」を参照)。それ以外の場合は、汎用エディタが表示されます。

新規エントリを作成するときは、汎用エディタには選択しているオブジェクトクラスの必須属性に対応するフィールドが表示されます。すべての必須属性に値を設定する必要があります。一部のフィールドには、「新規」などの汎用のプレースホルダが表示されます。これは、作成するエントリに適した値で置き換える必要があります。

選択しているオブジェクトクラスで利用できるその他の属性を定義するには、それを明示的に追加する必要があります。オプション属性の値を設定するには、次の手順を実行します。

「属性の追加」ボタンをクリックして、利用できる属性のリストを表示します。

「属性の追加」ダイアログで 1 つまたは複数の属性を選択し、「了解」をクリックします。

汎用エディタで、新しい属性の名前の隣に値を入力します。

このダイアログのその他のコントロールについて詳細は、「汎用エディタによるエントリの変更」を参照してください。

デフォルトでは、必須属性の 1 つがネーミング属性として選択され、汎用エディタにエントリの DN として表示されます。ネーミング属性を変更するには、次の手順を実行します。

「変更」ボタンをクリックして、「ネーミング属性の変更」ダイアログを表示します。

属性のテーブルで、新しいエントリの DN として使用する 1 つまたは複数の属性の隣にあるチェックボックスを選択します。

「了解」をクリックして「ネーミング属性の変更」ダイアログを閉じます。汎用エディタの DN には、選択したネーミング属性による新しい DN が表示されます。

汎用エディタの「了解」をクリックして新しいエントリを保存します。

新しいエントリは、ディレクトリツリー内の親エントリの子として表示されます。

カスタムエディタによるエントリの変更

表 2-1 に示されるオブジェクトクラスでは、対応するカスタムエディタまたは汎用エディタを使用してエントリを編集できます。カスタムエディタを使う場合は、最も一般的なフィールドに簡単にアクセスできます。また、このインタフェースを使えば、ロールやサービスクラスの定義などに関連する複雑な属性も簡単に設定できます。

汎用エディタでは、オブジェクトクラスの追加、許可されている属性の追加、複数値属性の処理など、エントリに対してより高度な設定を行えます。汎用エディタを使用してエントリを編集する方法については、「汎用エディタによるエントリの変更」を参照してください。

カスタムエディタの起動


注	カスタムエディタは、表 2-1 に示されるオブジェクトクラスだけの編集に使用できます。たとえば、inetorgperson から継承するカスタムクラスなど、その他の構造化オブジェクトクラスを含むエントリの編集には、汎用エディタを使う必要があります。リストに含まれるオブジェクトクラスのほかに auxiliary オブジェクトクラスを含むエントリは、カスタムエディタを使用して管理できます。ただし、auxiliary クラスによって定義される属性はカスタムエディタには表示されません。auxiliary オブジェクトクラスの定義については、『Directory Server Administration Reference』の第 8 章にある「Object Classes」を参照してください。

オブジェクトクラスが表 2-1 に一覧表示されているエントリを編集するには、次の手順を実行します。

Directory Server コンソールの最上位にある「ディレクトリ」タブでディレクトリツリーを展開し、編集するエントリを表示します。

エントリをダブルクリックします。これ以外の方法でエントリのカスタムエディタを呼び出すこともできます。

エントリをマウスの右ボタンでクリックし、「カスタムエディタで編集」を選択する

エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「カスタムエディタで編集」を選択する

エントリをマウスの左ボタンでクリックして選択し、キーボードショートカットの Control-P を使用する

エントリのオブジェクトクラスに対応するカスタムエディタが表示されます。たとえば、図 2-1 はユーザーエントリのカスタムエディタを示しています。

デフォルトでは、すべてのカスタムエディタは、「ユーザー」タブまたは「一般」タブが選択された状態で表示されます。これらのタブには、新しいエントリの名前と説明を入力するためのフィールドが含まれます。カスタムエディタで、変更する属性のフィールドに値を入力するか、値を削除します。フィールド名の隣にアスタリスク (*) が表示された必須属性の値は、変更することはできますが、削除することはできません。その他のフィールドは何も入力しなくても問題ありません。複数の値を入力できるフィールドでは、Return で値を区切ります。

左側の列のその他のタブを選択し、対応するパネルで値を変更します。指定したエントリタイプのカスタムエディタの各フィールドについて、説明を表示するときは「ヘルプ」ボタンをクリックします。

「ユーザー」エディタと「組織単位」エディタの「言語」タブの説明については、「言語サポートの属性の設定」を参照してください。ユーザーエントリまたはグループエントリの「アカウント」タブのフィールドについては、第 7 章「ユーザーアカウントとパスワードの管理」を参照してください。「NT ユーザー」タブと「Posix ユーザー」タブが、Directory Server Synchronization Service 用に用意されています。詳細については、Sun の担当者までお問い合わせください。

サービスエントリのグループ、ロール、クラスを変更する方法については、第 5 章「ID とロールの管理」を参照してください。パスワードポリシーの変更については、第 7 章「ユーザーアカウントとパスワードの管理」を参照してください。リフェラルの変更については、「リフェラルの設定」を参照してください。

「了解」をクリックしてエントリに加えた変更を保存し、カスタムエディタダイアログを閉じます。ユーザーエントリの共通名など、ネーミング属性を変更した場合は、ディレクトリツリーに変更が反映されます。

言語サポートの属性の設定

ユーザーエントリと組織単位エントリのカスタムエディタには、国際化ディレクトリ用に言語サポートが用意されています。

「カスタムエディタの起動」で説明している方法で、エントリのカスタムエディタを開きます。

左側の列で「言語」タブをクリックします。

ユーザーエントリでは、ドロップダウンリストから適切な言語を選択できます。

ユーザーエントリと組織単位エントリのどちらでも、指定のフィールドに、リストに示される任意の言語を使用してローカライズされた値を入力できます。「利用可能な言語」リストから言語を選択し、1 つまたは複数の値をその言語で入力します。ローカライズされた値を定義すると、その言語がリストに太字で表示されます。

一部の言語では、ローカライズされた値の発音表記のために、発音 (ふりがな) を入力するフィールドが表示されます。

「了解」をクリックしてエントリに加えた変更を保存し、カスタムエディタダイアログを閉じます。

汎用エディタによるエントリの変更

汎用エディタでは、コンソールへのログインに使用したバインド DN に応じて、エントリの読み取り可能なすべての属性を表示し、書き込み可能なすべての属性を編集できます。また、属性の追加と削除、複数値属性の設定、エントリのオブジェクトクラスの管理も行えます。属性を追加するときは、バイナリ属性のサブタイプと言語サポートを定義できます。

汎用エディタの起動

ディレクトリ内の任意のエントリの汎用エディタを呼び出すには、次の手順を実行します。

Directory Server コンソールの最上位にある「ディレクトリ」タブでディレクトリツリーを展開し、編集するエントリを表示します。

エントリをマウスの右ボタンでクリックし、「汎用エディタで編集」を選択します。これ以外の方法でも汎用エディタを呼び出すことができます。

エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「汎用エディタで編集」を選択します。

オブジェクトクラスが表 2-1 に示されていない場合は、エントリをダブルクリックします。カスタムエディタを持たないオブジェクトクラスの編集には、デフォルトで汎用エディタが使用されます。

次の図に示すように、汎用エディタが表示されます。

図 2-2 Directory Server コンソール : 汎用エディタ
ユーザーエントリの属性フィールドと変更用のコントロールの表示された「汎用エディタ - uid=bjensen,ou=People,dc=example,dc=com」ウィンドウ

汎用エディタでは、エントリの属性はアルファベット順に表示され、それぞれの値がテキストボックスに表示されます。読み取り専用属性やオペレーショナル属性などのすべての属性が表示されます。右側のコントロールを使うことで、エディタの表示を変更したり、属性のリストを編集することができます。

必要に応じて、「表示」ボックスのコントロールを使用して汎用エディタの表示を変更できます。

属性の名前をスキーマに最初に定義したとおりに表示するときは、「属性の名前を表示」オプションを選択します。属性リストの表示が更新され、属性が名前のアルファベット順に表示されます。

スキーマに属性の別名が定義されている場合に、属性を別名順にリスト表示するときは、「属性の説明を表示」オプションを選択します。通常、別名は属性を明示的に説明します。属性リストの表示が更新され、属性が別名 (説明) のアルファベット順に表示されます。

エントリのオブジェクトクラスのスキーマで明示的に許可されているすべての属性を表示するときは、「値が設定された属性のみを表示」チェックボックスの選択を解除します。エントリに extensibleObject オブジェクトクラスが含まれる場合、暗黙的にすべての属性が許可されますが、それは表示されません。デフォルトでは、値が定義されている属性だけが表示されます。

属性の下のエントリの識別名の表示と非表示を切り替えるときは、「DN を表示」チェックボックスを選択または選択解除します。

「再表示」ボタンをクリックすると、そのエントリの現在の内容に基づいて、すべての属性の値が更新されます。



警告	「再表示」ボタンをクリックすると、保存する前に汎用エディタで行なっていたすべての変更が直ちに削除されます。

属性値の設定、オブジェクトクラスの管理、エントリのネーミング属性の変更に関連するコントロールについては後述します。

属性値の変更

複数値属性の編集

ディレクトリスキーマで複数値として定義されている属性は、汎用エディタの 1 つのフィールドに複数の値を設定できます。詳細は、第 9 章「ディレクトリスキーマの拡張」を参照してください。

複数値属性に新しい値を追加するには、次の手順を実行します。

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

属性のリストをスクロールし、属性またはその値をクリックします。選択した属性が強調表示され、「値の追加」ボタンが有効になります。このボタンが有効にならないときは、選択している属性が複数値として定義されていないか、読み取り専用である、または値の変更に必要な書き込み権限がありません。

「値の追加」ボタンをクリックします。リスト内の属性名の隣に、新しい空白のテキストフィールドが表示されます。

新しいテキストフィールドに、この属性の新しい値を入力します。システムのクリップボードを使用して、このフィールドのテキストのコピー、カット、ペーストを行うことができます。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

属性の追加

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

「値が設定された属性のみを表示」オプションが選択されていることを確認します。

「属性の追加」ボタンをクリックして、属性のリストを示すダイアログを表示します。このリストには、そのエントリに定義されているオブジェクトクラスで使用できる属性だけが表示されます。

「属性の追加」ダイアログで、追加する 1 つまたは複数の属性を選択します。

必要に応じて、ダイアログ上部のドロップダウンリストから次のいずれか、または両方のサブタイプを選択できます。

言語サブタイプ : 属性の値に適用される言語を指定するときは、このサブタイプを選択します。異なる言語で 1 つの属性を複数回追加し、ディレクトリにローカライゼーション情報を保存できます。

オプションとして、言語のほかに「ふりがな」サブタイプを選択し、この属性の値に指定の言語の値に対応する発音表記が含まれていることを示すことができます。

バイナリサブタイプ : 属性にバイナリサブタイプを割り当てるということは、実際の構文にかかわらず、値がバイナリデータ (不透明なチャンクデータ) として LDAP 上を転送されることを示しています。このオプションは慎重に使用する必要があります。これは、userCertificateなど、LDAP 文字列表現を持たない複雑な構文用に設計されたものです。値がすでにバイナリであるとみなされている属性にバイナリサブタイプを使用することはできません。

属性とオプションサブタイプの選択が完了したら、「了解」をクリックします。汎用エディタの属性のリストに、属性がアルファベット順に追加されます。

新しい属性の名前の隣にある空白のテキストフィールドに、この属性の新しい値を入力します。システムのクリップボードを使用して、このフィールドのテキストのコピー、カット、ペーストを行うことができます。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

属性の削除

属性とすべての値をエントリから削除するには、次の手順を実行します。

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

属性のリストをスクロールし、削除する属性の名前をクリックします。選択した属性が強調表示され、「属性の削除」ボタンが有効になります。このボタンが有効にならないときは、選択している属性が読み取り専用であるか、値の変更に必要な書き込み権限がありません。



注	汎用エディタでは、この属性に定義されているオブジェクトクラスが必要とする属性も削除できます。必須属性を含まないエントリを保存しようとすると、サーバーはオブジェクトクラス違反を返します。すべてのオブジェクトクラスの必須属性がエントリに含まれることを確認してください。

「属性の削除」ボタンをクリックします。属性と、その属性のすべてのテキストフィールドが削除されます。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

オブジェクトクラスの管理

エントリのオブジェクトクラスは、複数値の objectclass 属性によって定義されます。この属性を変更する場合に、定義されているオブジェクトクラスを管理できるように、汎用エディタには特別なダイアログがあります。

オブジェクトクラスをエントリに追加するには、次の手順を実行します。

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

属性のリストをスクロールし、オブジェクトクラスまたは objectclass 属性を選択します。「値の追加」ボタンが有効になります。このボタンが有効にならないときは、このエントリのオブジェクトクラスの変更に必要な権限がありません。

「値の追加」ボタンをクリックします。

「オブジェクトクラスの追加」ダイアログが表示されます。このウィンドウには、エントリに追加できるオブジェクトクラスのリストが表示されます。

このエントリに追加するオブジェクトクラスを 1 つまたは複数選択し、「了解」をクリックします。選択したオブジェクトクラスが、objectclass 属性の値のリストに表示されます。

新しいオブジェクトクラスが、エントリに含まれない属性を必要とする場合は、汎用エディタはそれを自動的に追加します。すべての必須属性に値を設定する必要があります。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

エントリからオブジェクトクラスを削除するには、次の手順を実行します。

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

属性のリストをスクロールし、削除する objectclass 属性の値をクリックします。選択しているオブジェクトクラスの削除がスキーマで許可され、このエントリのオブジェクトクラスを変更する権限がある場合は、「値の削除」ボタンが有効になります。

「値の削除」ボタンをクリックします。指定したオブジェクトクラスが削除されます。

オブジェクトクラスを削除すると、汎用エディタは残りのオブジェクトクラスが許可しないか、必要としないすべての属性を自動的に削除します。いずれかのネーミング属性が削除されると、別のネーミング属性が自動的に選択されます。コンソールは、この変更を示すメッセージを表示します。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

エントリ名の変更

ネーミング属性は、識別名 (DN) に表示されるエントリの属性値のペアです。ネーミング属性は、エントリの既存の属性から選択されます。ネーミング属性を変更してエントリの名前を変更するには、次の手順を実行します。

「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。

「変更」ボタンの隣のテキストは、このエントリの現在のネーミング属性を示します。「DN を表示」チェックボックスが選択されている場合、これらの属性が属性値リストの下の DN に表示されます。

「変更」ボタンをクリックします。このボタンが有効にならないときは、このエントリの名前を変更する権限がありません。

「ネーミング属性の変更」ダイアログが表示されます。

属性のリストをスクロールし、このエントリの DN にする属性を選択します。属性の隣のチェックボックスを選択してネーミング属性に追加するか、選択解除して削除します。

同じ親の下のエントリの DN は、一意なものにする必要があります。このため、値または値の組み合わせが一意となるネーミング属性を選択する必要があります。DN が重複している場合、そのエントリを保存しようとすると、サーバーがこれを拒否します。たとえば、ユーザーを示すすべてのエントリでは、同じネーミング属性を使用する必要があります。

「了解」をクリックして「ネーミング属性の変更」ダイアログを閉じます。汎用エディタには、このエントリの新しい DN が表示されます。

このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。

ディレクトリエントリの削除

Directory Server コンソールを使用してディレクトリエントリを削除するには、次の手順を実行します。

Directory Server コンソールの最上位にある「ディレクトリ」タブでディレクトリツリーを展開し、削除するエントリを表示します。

サブツリーのルートノードを選択することで、ディレクトリのブランチ全体を削除することもできます。

エントリをマウスの右ボタンでクリックし、「削除」を選択します。これ以外の方法でエントリを削除することもできます。

エントリをマウスの左ボタンでクリックして選択し、「編集」メニューから「削除」を選択します。このエントリをディレクトリ内の別の場所にペーストするときは、「編集」メニューから「カット」を選択することもできます。

エントリをマウスの左ボタンでクリックして選択し、キーボードショートカットの Control-D を使用します。

「表示」メニューから「レイアウト」オプションを選択して Directory Server コンソールの右側のパネルに子を表示しているときは、Control または Shift を押しながらクリックすることで、複数のエントリを選択できます。

エントリまたはサブツリーとそのすべての内容を削除することを確認します。

選択したエントリがただちに削除されます。この処理を元に戻すことはできません。複数のエントリを削除した場合、削除したエントリの数を示すダイアログが表示されます。また、削除時にエラーが発生した場合は、エラーを示すダイアログが表示されます。

コンソールからの一括処理

LDIF ファイルを使用することで、複数エントリの追加、組み合わせ操作の実行、サフィックス全体のインポートを行うことができます。LDIF ファイルと Directory Server コンソールを使用してエントリを追加するには、次の手順を実行します。

コマンド行からのエントリの管理

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

ldapmodify コマンドと ldapdelete コマンドは、このマニュアル全体の手順で使用されます。次に、これらの管理手順の実行に必要なすべての基本操作について説明します。機能の詳細、すべてのコマンド行オプション、これらのコマンドの戻り値については、『Directory Server Resource Kit Tools Reference』の第 4 章にある「ldapmodify」および第 5 章にある「ldapdelete」を参照してください。

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

LDIF 入力の実行

コマンド行ユーティリティに LDIF 入力を行うときは、コマンド行入力、特殊文字、スキーマ検査、エントリの順序とサイズについて特別な注意を払う必要があります。ディレクトリデータはすべて、Unicode の UTF-8 エンコーディングを使用して保存されています。したがって、LDIF 入力もすべて UTF-8 で符号化されている必要があります。LDIF 形式についての詳細は、『Directory Server Administration Reference』の第 7 章にある「LDAP Data Interchange Format Reference」を参照してください。

コマンド行での LDIF 入力の終了


注	LDIF 属性値文字列の末尾に、不用意に空白を残さないでください。Directory Server が属性値の末尾で空白を読み取ると、Base 64 方式によって値が符号化されます。

ldapmodify ユーティリティと ldapdelete ユーティリティは、ファイルから読み取るのとまったく同様に、ユーザーがコマンドの後に入力した LDIF 文を読み取ります。入力が終了したら、ファイルの最後 (EOF) を示すエスケープシーケンスとしてシェルに認識される文字を入力します。

次の例は、ldapmodify コマンドの入力の終了方法を示しています。

表記を単純かつわかりやすくするために、このマニュアルの例には EOF シーケンスは表示されません。

特殊文字の使い方

コマンド行にコマンドオプションを指定するときは、コマンド行インタープリタにとって特別な意味を持つエスケープ文字の入力が必要になることがあります。このような文字には、空白 ( )、アスタリスク (*)、円記号 (¥) などが含まれます。たとえば、多くの DN には空白文字が含まれ、ほとんどの UNIX シェルでは値を二重引用符 ("") で囲む必要があります。

一重引用符または二重引用符のどちらを使用するかは、コマンド行インタープリタのタイプによって異なります。詳細は、オペレーティングシステムのマニュアルを参照

さらに、コンマを含む DN を使用する場合は、円記号 (¥) でコンマをエスケープする必要があります。たとえば、次のようにします。

ldapmodify コマンドの後の LDIF 文はシェルではなく、コマンドによって解釈されるため、特別な注意が必要ないことに注意してください。

スキーマ検査

エントリを追加または変更する場合、使用する属性は、エントリのオブジェクトクラスが必要とするか、許可する属性である必要があり、その属性には、定義されている構文に準拠する値が含まれている必要があります。

エントリを変更すると、Directory Server は変更される属性だけでなく、エントリ全体に対してスキーマ検査を行います。このため、エントリのいずれかのオブジェクトクラスまたは属性がスキーマに準拠していない場合、変更処理は失敗します。詳細は、「スキーマ検査」を参照してください。

LDIF エントリの順序

エントリを追加するための LDIF テキストのシーケンスでは、コマンド行に指定する場合も、ファイルに指定する場合も、親エントリを子の前に指定する必要があります。これにより、サーバーが LDIF テキストを処理するときに、子エントリの前に親エントリが作成されます。

たとえば、ディレクトリに存在しない People サブツリーにエントリを作成する場合、サブツリー内のエントリの前に People コンテナを表すエントリを指定します。

ldapmodify コマンド行ユーティリティを使用してディレクトリ内にエントリを作成することができますが、サフィックスまたはサブサフィックスのルートは、必要な設定エントリと関連付ける必要のある特別なエントリです。新しいルートサフィックスまたはサブサフィックス、およびそれに関連する設定エントリを追加する手順については、「コマンド行からのサフィックスの作成」を参照してください。

大規模なエントリの管理

極端に大きな属性値を持つエントリを追加または変更するときは、それを受け入れることができるように、事前にサーバーの設定が必要になることがあります。サーバーのオーバロードを防ぐために、デフォルトでは、クライアントは 2M バイトを超えるデータを送信できないように制限されています。

これを超えるエントリを追加するか、属性をこれ以上の値に変更しようとすると、サーバーはその処理を拒否し、直ちに接続を閉じます。たとえば、1 つのエントリの 1 つまたは複数の属性にマルチメディアコンテンツなどのバイナリデータが含まれると、この制限を超える可能性があります。

また、多数のメンバーを含む大規模なスタティックグループを定義するエントリも、この制限を超える可能性があります。ただし、パフォーマンスを考慮すると、このようなグループはお勧めできません。ディレクトリ構造の再設計を考慮する必要があります。詳細は、「グループの管理」を参照してください。

クライアントが送信するデータにサーバーが適用するサイズ制限を変更するには、次の手順を実行します。

cn=config エントリの nsslapd-maxbersize 属性に新しい値を設定します。

この処理をコンソールから行うには、管理者または Directory Manager としてログオンし、「汎用エディタによるエントリの変更」で説明する方法で、cn=config エントリを編集します。nsslapd-maxbersize 属性の値を、クライアントが一度に送信できる最大バイト数に設定します。

この処理をコマンド行から行うには、次のコマンドを実行します。

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=config
changetype:modify
replace:nsslapd-maxbersize
nsslapd-maxbersize:sizeLimitInBytes
^D

詳細については、『Directory Server Administration Reference』の第 2 章にある「nsslapd-maxbersize」を参照してください。

「Directory Server の起動と停止」で説明している手順を実行してサーバーを再起動します。

エラーの処理

コマンド行ツールは、LDIF 入力に含まれるすべてのエントリまたは変更を順番に処理します。最初のエラーが発生した場合のデフォルトの対応は、処理の停止です。エラーに関係なくすべての入力の処理を継続するときは、-c オプションを指定します。エラーの状態は、ツールの出力に表示されます。

上記注意点のほかに一般的なエラーには、次のようなものがあります。

エラー状態とそれを回避する方法については、『Directory Server Resource Kit Tools Reference』の第 4 章にある「ldapmodify」および第 5 章にある「ldapdelete」を参照してください。

ldapmodify によるエントリの追加

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

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

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

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

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

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

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

ldapmodify によるエントリの変更

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

同じエントリに対する操作を区切るときはハイフン (-) を使い、異なるエントリに対する操作セットを区切るときは空白文字を使います。各操作の対象となる attribute:value のペアを複数指定して、それを一度に追加、置換、または削除することもできます。

属性値の追加

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

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

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

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

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

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

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

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

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

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

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

属性値の変更

次の例は、LDIF の replace 文を使用して、単一値の属性と、複数値属性のすべての値を変更する方法を示しています。

replace 文を使うときは、指定した属性のすべての現在値が削除され、指定した値が追加されます。

属性値の削除

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

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

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

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

ldapmodify によるエントリ名の変更

エントリの名前を変更するときは、関連識別名 (RDN) を変更します。RDN は、エントリの DN に含まれる、いちばん左の attribute=value のペアです。この属性はネーミング属性と呼ばれ、エントリのすべての属性に同じ値が存在する必要があります。

エントリの名前を変更するときは、エントリが別のサブツリーに移動するような、DN の別の部分を変更することはできません。エントリを異なるブランチに移動するには、別のサブツリー内にそのエントリの属性を使用して新しいエントリを作成してから、元のエントリを削除する必要があります。

また、親の RDN は子の DN で使われており、すべてのエントリに DN が含まれる必要があるため、子を持つエントリの名前を変更することはできません。ツリー全体を移動するには、新しい場所でそのツリーを再作成する必要があります。

LDIF 文を使用してエントリの名前を変更するには、changetype: modrdn キーワードを使います。次の例では、Barbara Morris の uid ネーミング属性の名前を変更します。

newrdn 行は、attribute=value 構文を使用して新しいネーミング属性を指定します。deleteoldrdn 行は、同時に以前のネーミング属性を削除するかどうかを指定します (1 であれば削除、0 であれば削除しない)。いずれの場合も、エントリに新しいネーミング属性が追加されます。

ldapdelete によるエントリの削除

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

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

次の例では、組織単位には 1 つのエントリしか含まれていないため、そのエントリを削除すれば、親エントリを削除できます。

ldapmodify によるエントリの削除


警告	サフィックス o=NetscapeRoot は削除しないでください。管理サーバーは、このサフィックスを使用してインストールした Sun Java System サーバーに関する情報を格納します。このサフィックスを削除すると、Directory Server を含むすべての Sun Java System サーバーの再インストールが必要になります。

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

リフェラルの設定

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

クライアントアプリケーションがローカルサーバーに存在しないエントリを要求し、サーバーがデフォルトのリフェラルを返す場合

サフィックス全体がメンテナンスまたはセキュリティ上の理由でオフラインになり、サーバーがサフィックスに定義されているリフェラルを返す場合。サフィックスレベルのリフェラルについては、「アクセス権とリフェラルの設定」を参照。クライアントが書き込み処理を要求する場合、サフィックスの読み取り専用レプリカも、マスターサーバーにリフェラルを返す

スマートリフェラルと呼ばれるエントリを作成できる。クライアントがスマートリフェラルにアクセスすると、サーバーは定義されているリフェラルを返す。Directory Server コンソールは、スマートリフェラルを自動的にたどるように設定できるため、最上位の「ディレクトリ」タブでローカルエントリのように見える

いずれの場合も、リフェラルは LDAP URL であり、ホスト名、ポート番号、およびオプションとして別のサーバー上の DN を含みます。詳細については、『Directory Server Administration Reference』の第 6 章にある「LDAP URL Reference」を参照してください。ディレクトリの導入におけるリフェラルの使用方法に関する概念については、『Directory Server 配備計画ガイド』の第 5 章にある「分散、連鎖、およびリフェラル」を参照してください。

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

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

デフォルトリフェラルは、ディレクトリで管理されているサフィックスのどれにも含まれない DN に対して、操作を送信するクライアントアプリケーションに返されます。デフォルトリフェラルはディレクトリ内のすべてのサフィックスに適用されるため、グローバルリフェラルとも呼ばれます。サーバーは定義されているすべてのリフェラルを返しますが、返す順序は定義されていません。

コンソールからのデフォルトリフェラルの設定

コマンド行からのデフォルトリフェラルの設定

ディレクトリ設定ファイルの cn=config エントリに 1 つまたは複数のデフォルトリフェラルを追加するか、交換するときは、ldapmodify コマンド行ユーティリティを使います。たとえば、次のようにします。

スマートリフェラルの作成

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

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

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

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

コンソールからのスマートリフェラルの作成

Directory Server コンソールの最上位にある「ディレクトリ」タブでディレクトリツリーを展開し、スマートリフェラルの親となるエントリを表示します。

親エントリをマウスの右ボタンでクリックし、「新規」メニューの「リフェラル」を選択します。あるいは、親エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「新規」、「リフェラル」を順に選択することもできます。

リフェラルのエントリのカスタムエディタダイアログが表示されます。

エディタの「一般」タブで、リフェラルの名前を入力し、ドロップダウンリストからネーミング属性を選択します。名前は、選択したネーミング属性の値となります。必要に応じて、このリフェラルを説明する文字列も入力できます。

エディタの「URL」タブで、「構成」ボタンをクリックしてスマートリフェラルの URL を定義します。表示されるダイアログに LDAP URL の要素を入力します。

URL の要素には、リフェラルエントリを保持するディレクトリサーバーのホスト名と LDAP ポート番号、およびサーバー上のターゲットエントリの DN が含まれています。デフォルトでは、ターゲット DN はスマートリフェラルエントリと同じ DN となります。しかし、ターゲット DN には、任意のサフィックス、サブツリー、または最下位エントリを指定できます。

LDAP URL の構成ダイアログで「了解」をクリックします。新しいリフェラルのテキストボックスに URL が表示されます。

新しいリフェラルの隣にある「追加」をクリックして、リフェラルをリストに追加します。

このエントリのリフェラルとして返される、複数の URL を定義できます。「リフェラルリスト」を作成および管理するには、「構成」、「追加」、「削除」、「変更」ボタンを使います。

「リフェラル認証」ボタンをクリックして、ダイアログを表示します。このダイアログでは、リモートサーバーを指すリフェラルをたどるときに、Directory Server コンソールがバインドに使用する証明情報を設定できます。サーバーへのアクセス時に使われるバインド DN とパスワードを定義できます。同じサーバーを指すすべてのリフェラルは、同じ証明情報を使います。

サーバー、および対応する証明情報のリストを管理するには、「追加」、「編集」、「削除」ボタンを使います。設定が完了したら、「了解」をクリックします。

リフェラルのカスタムエディタで「了解」をクリックし、スマートリフェラルエントリを保存します。

コンソールのディレクトリツリーには、スマートリフェラルエントリのターゲットサブツリーまたはエントリが表示されます。スマートリフェラルエントリに黄色の警告アイコンが表示されるときは、URL または証明情報が無効です。エントリをダブルクリックし、「リフェラルエラー」が表示されていたら「継続」をクリックして、「URL」または「リフェラル認証」を変更してエラーを修正します。

コマンド行からのスマートリフェラルの作成

スマートリフェラルを作成するには、referral オブジェクトクラスと extensibleObject オブジェクトクラスを持つエントリを作成します。referral オブジェクトクラスは、LDAP URL を含むことになる ref 属性を許可します。extensibleObject オブジェクトクラスは、ターゲットエントリと一致させるために、任意のスキーマ属性をネーミング属性として使用することを許可します。

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


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

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

スマートリフェラルエントリを変更するには、たとえば次のように、ldapmodify の -M オプションを使う必要があります。

属性値の暗号化

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

この機能では、属性値は Directory Server データベースに格納される前に暗号化され、クライアントに返される前に元の値に復号化されます。クライアントと Directory Server との間でやり取りを行うときに、アクセス制御を使用してクライアントがこれらの属性に許可なくアクセスすることを防ぎ、SSL を使用して属性値を暗号化する必要があります。データセキュリティ一般と、属性暗号化のアーキテクチャの概要については、『Directory Server 配備計画ガイド』の第 7 章にある「アクセス制御、認証、および暗号化」を参照してください。

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



警告	属性を暗号化すると、サフィックスに関連付けられたすべてのデータとインデックスファイルが影響を受けます。既存のサフィックスについて暗号化設定を変更するときは、まずサフィックスの内容をエクスポートし、設定を変更してからその内容をふたたびインポートする必要があります。この手順は、コンソールを使用して簡単に実行できます。さらに、暗号化を有効にするときは、暗号化されていない値を含んでいる可能性のあるデータベースキャッシュファイルを手動で削除する必要があります。新しいサフィックスにデータを読み込むときや作成するときは、暗号化されているすべての属性をあらかじめ有効にする必要があります。

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

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

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

コンソールからの属性の暗号化設定

Directory Server コンソールで「設定」タブを選択し、「データ」ノードを展開します。次に、属性値を暗号化する対象のサフィックスを選択します。右側のパネルで「属性の暗号化」タブを選択します。

このタブには、このサフィックスで現在暗号化されているすべての属性の名前と暗号化スキームを示すテーブルがあります。

属性の暗号化を有効にするには、次の手順を実行します。

「属性の追加」ボタンをクリックして、属性のリストを表示します。

暗号化する属性をリストから選択し、「了解」をクリックします。この属性が、テーブルの「属性名」列に追加されます。

この属性の暗号化スキーマを、属性名の隣にあるドロップダウンリストから選択します。

属性が暗号化されないようにするには、テーブルから属性名を選択し、「属性の削除」ボタンをクリックします。

「保存」をクリックします。暗号化設定を変更する前にサフィックスの内容を LDIF ファイルにエクスポートするように促すメッセージが表示されます。

「サフィックスをエクスポート」をクリックして、エクスポートダイアログを開きます。エクスポートを行わない場合は、「継続」をクリックして、属性の暗号化設定を変更します。新しい設定が保存されます。

サフィックスをまだエクスポートしていないときは、内容を保存するために、この時点でエクスポートします。暗号化されている属性がサフィックスに含まれてる場合、次の手順でこの LDIF ファイルを使用してサフィックスを再初期化するのであれば、暗号化された状態のままこれを LDIF にエクスポートすることもできます。

LDIF ファイルを使用してサフィックスを初期化するように促すメッセージが表示されます。

「ただちにサフィックスを初期化」をクリックして初期化ダイアログを開き、ディレクトリに読み込む LDIF ファイルの名前を入力します。

サフィックスを再初期化すると、暗号化された値を復元できなくなるため、前の手順で、暗号化された属性をそのままサフィックスからエクスポートした場合は、そのファイル使用してこの時点で初期化を行う必要があります。このファイルが読み込まれ、インデックスが作成されるときに、指定した属性の値はすべて暗号化されます。

この時点でサフィックスの初期化を行わない場合は、「閉じる」をクリックします。データを後からインポートする手順については、「データのインポート」を参照してください。

1 つまたは複数の属性を暗号化するように設定を変更し、インポート処理の前にその属性が値を持っていた場合、暗号化されていない一部の値は、データベースキャッシュに判読可能な状態で残ることがあります。データベースキャッシュをクリアするには、次の手順を実行します。

「Directory Server の起動と停止」で説明している方法で、Directory Server を停止します。

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

ServerRoot/slapd-serverID/db/__db.*

Directory Server を再起動します。サーバーは、新しいデータベースキャッシュファイルを自動的に作成します。

コマンド行からの属性の暗号化設定

属性の暗号化を設定するサフィックスに何らかのエントリが含まれるときは、最初にそのサフィックスの内容を LDIF ファイルにエクスポートします。詳細は、「データのエクスポート」を参照してください。

暗号化されている属性がサフィックスに含まれる場合、手順 5 でこの LDIF ファイルを使用してサフィックスを再初期化するのであれば、暗号化された状態のままこれを LDIF にエクスポートします。

属性の暗号化を有効にするときは、ldapmodify コマンドを使用して次の設定エントリを追加します。

ldapmodify -a -h host -p port -D cn=Directory Manager -p password
dn: cn=attributeName, cn=encrypted attributes, cn=databaseName,
cn=ldbm database, cn=plugins, cn=config
objectclass:top
objectclass:dsAttributeEncryption
cn: attributeName
dsEncryptionAlgorithm:cipherName

ここで、attributeName は暗号化する属性のタイプ名で、databaseName はサフィックスに対応するデータベースの識別名です。cipherName は次のいずれかです。

ckm_des_cbc : DES ブロック暗号化方式

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

ckm_rc2_cbc : RC2 ブロック暗号化方式

ckm_rc4 : RC4 ストリーム暗号化方式

属性が暗号化されないようにするには、ldapmodify コマンドを使用して次の設定エントリを変更します。

ldapmodify -h host -p port -D cn=Directory Manager -p password
dn: cn=attributeName, cn=encrypted attributes, cn=databaseName,
cn=ldbm database, cn=plugins, cn=config
changetype:modify
replace:dsEncryptionAlgorithm
dsEncryptionAlgorithm:clearText

ここで、attributeName は暗号化する属性のタイプ名で、databaseName はサフィックスに対応するデータベースの識別名です。



注	属性暗号化の設定エントリを削除しないでください。これは、サフィックスを次に初期化したときに自動的に削除されます。

「Directory Server の起動と停止」で説明している方法で、Directory Server を停止します。

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

ServerRoot/slapd-serverID/db/__db.*

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

「データのインポート」で説明する方法で、LDIF ファイルを使用してサフィックスを初期化します。

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

参照整合性の管理

参照整合性は、関連するエントリ間の関係を保持するプラグインメカニズムです。グループのメンバーシップなど、一部のタイプの属性には別のエントリの DN が含まれています。参照整合性を利用することで、エントリを削除したときに、そのエントリの DN を含むすべての属性も削除できます。

たとえば、参照整合性が有効になっているときに、あるユーザーのエントリがディレクトリから削除されると、そのユーザーは、所属しているあらゆるグループからも削除されます。参照整合性が無効な状態では、管理者はグループからユーザーを手動で削除する必要があります。Directory Server と、ユーザーとグループの管理をディレクトリに頼っているその他の Sun Java System 製品を統合する場合には、この機能がとても重要です。

参照整合性のしくみ

参照整合性検査プラグインが有効になっているときに削除操作や名前変更の操作を実行すると、指定された属性に対する整合性更新がただちに実行されます。ただし、デフォルトでは、参照整合性検査プラグインは無効になっています。

ディレクトリ内にあるユーザーエントリまたはグループエントリの削除や名前変更のたびに、その操作が次の参照整合性ログファイルに記録されます。

更新間隔と呼ばれる指定した時間が経過すると、参照整合性が有効になっているすべての属性が検索され、検索結果のエントリと、ログファイル内に記録された削除または変更されたエントリの DN が照合されます。特定のエントリが削除されたことがログファイルに記録されている場合は、対応する属性が削除されます。特定のエントリが変更されたことがログファイルに記録されている場合は、対応する属性値が記録に従って変更されます。

参照整合性プラグインのデフォルトの設定が有効な場合は、削除操作や名前変更の操作を実行すると、member、uniquemember、owner、seeAlso、および nsroledn の各属性に対する整合性更新がただちに実行されます。ただし、参照整合性検査プラグインの動作は、次のような用途に合わせてユーザーが自由に設定できます。

参照整合性の設定

Directory Server コンソールから参照整合性を有効化または無効化したり、プラグインを設定するときは、次の手順を実行します。

コンソールからの参照整合性の設定

Directory Server コンソールの最上位の「設定」タブで「プラグイン」ノードを展開し、「referential integrity postoperation」プラグインを選択します。

プラグインの設定が右側のパネルに表示されます。

プラグインを有効にする場合は、「プラグインを有効に」チェックボックスを選択します。プラグインを無効にする場合は、このチェックボックスの選択を解除します。

更新間隔を秒単位で変更するときは、「引数 1」に値を設定します。一般的な値は次のとおりです。

0 - 処理の終了後、毎回直ちに更新する。これはデフォルト値である。変更処理のたびに、その直後に参照整合性検査を行うことは、サーバーのパフォーマンスに重大な影響を及ぼすため、注意する必要がある

90 - 90 秒ごとに更新する

3,600 - 1 時間ごとに更新する

10,800 - 3 時間ごとに更新する

28,800 - 8 時間ごとに更新する

86,400 - 1 日に 1 回更新する

604,800 - 1 週間に 1 回更新する

整合性と全体的なパフォーマンスとの兼ね合いを見極めて、正の値を設定します。

使用する参照整合性ログファイルのパスを「引数 2」に設定します。

「引数 3」は使用されませんが、表示されている必要があります。

参照整合性が監視される属性は、「引数 4」の最初にリスト表示されます。このリストの管理、および独自の属性の追加には、「追加」ボタンと「削除」ボタンを使います。



注	最適なパフォーマンスを得るには、参照整合性プラグインによって更新される属性にもインデックスを設定する必要があります。詳細は、第 10 章「ディレクトリデータのインデックス作成」を参照してください。

「保存」をクリックして、変更内容を保存します。

変更を適用するには、Directory Server を再起動する必要があります。

レプリケーションにおける参照整合性の使用

レプリケーション環境では、次のようないくつかの参照整合性検査プラグインの使用に関連付けられた制限があります。

レプリケーショントポロジで参照整合性プラグインを設定するには、次の手順を実行します。

旧バージョンのレプリケーションにおける参照整合性の使用

参照整合性を有効にした状態で、4.x マスターから 5.x コンシューマへレプリケートする場合、4.x マスター上の参照整合性プラグインを設定し直して、参照整合性への変更を 4.x の更新履歴ログに書き込めるようにする必要があります。これによって、参照整合性への変更がレプリケートできるようになります。プラグインを設定し直さないと、参照整合性は正しく機能しません。

この環境で参照整合性プラグインを再設定するには、次の手順を実行します。

4.x サーバーを停止します。

ServerRoot/slapd-ServerID/config/ にある slapd.ldbm.conf ファイルを開きます。

次の記述で始まる行を検出します。

plugin postoperation on "referential integrity postoperation"

この行で、属性のリストの直前に表示される引数を 0 から 1 に変更します。

たとえば、次のようにします。

plugin postoperation on "referential integrity postoperation" "ServerRoot/lib/referint-plugin.dll" referint_postop_init 0 "ServerRoot/slapd-serverID/logs/referint" 0 "member" "uniquemember" "owner" "seeAlso"

この行を次のように変更します。

slapd.ldbm.conf ファイルを保存します。

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

5.x コンシューマを 4.x サプライヤから再初期化します。

ディレクトリの検索

LDAP クライアントを使用して、ディレクトリ内のエントリを検出できます。ほとんどのクライアントには、ディレクトリを検索してエントリ情報を取得できるようにするために何らかの形式の検索インタフェースが用意されています。

ディレクトリに設定されたアクセス制御が、検索結果を決定します。通常、一般ユーザーにはディレクトリの多くは「表示」されず、設定を含む全データへのすべてのアクセス権を持っているのはディレクトリ管理者です。

ldapsearch によるディレクトリの検索

ldapsearch コマンド行ユーティリティを使用して、ディレクトリエントリを検出および取得することができます。この節で説明する ldapsearch ユーティリティは、Solaris プラットフォームで提供されるユーティリティではなく、Directory Server Resource Kit の一部です。このユーティリティについては、『Directory Server Resource Kit Tools Reference』を参照してください。

このユーティリティは、指定されたユーザー ID (通常は識別名) とパスワードによってサーバーへの接続を開き、検索フィルタに基づいてエントリを検出します。検索範囲には、単一のエントリ、エントリの直接のサブエントリ、またはエントリツリーやサブツリーを含むことができます。

ldapsearch コマンド行の形式

ldapsearch を使用する場合は、次の形式を使用してコマンドを入力する必要があります。

ldapsearch [optional_options] [search_filter] [optional_list_of_attributes]

optional_options は、一連のコマンド行オプションを表しています。検索フィルタが存在する場合は、検索フィルタより前に指定する必要があります。

search_filter は、「LDAP 検索フィルタ」で説明するように、LDAP 検索フィルタを表しています。-f オプションを使用してファイル内で検索フィルタを指定していない場合は、検索フィルタを指定する必要があります。

optional_list_of_attributes は、空白で区切られた属性のリストを表しています。属性のリストを指定すると、検索結果で返される属性の数が減少します。この属性のリストは、必ず検索フィルタの後に表示されます。「属性のサブセットの表示」に示されている例を参照してください。属性のリストを指定しない場合は、ディレクトリ内に設定されたアクセス制御によって許可されたすべての属性 (オペレーショナル属性を除く) の値が検索によって返されます。



注	検索操作の結果としてオペレーショナル属性を返すようにする場合は、検索コマンド内でこれらを明示的に指定する必要があります。明示的に指定されたオペレーショナル属性に加えて通常の属性も取得するには、ldapsearch コマンドの属性リスト内でアスタリスク (*) を使用します。

特殊文字の使い方

ldapsearch コマンド行ユーティリティを使用する場合に、コマンド行インタープリタにとって特別な意味を持つ文字 (空白 [ ]、アスタリスク [*]、円記号 [¥] など) を含む値を指定が必要になることがあります。特殊文字を指定する場合は、その値を引用符 ("") で囲みます。たとえば、次のようにします。

一重引用符または二重引用符のどちらを使用するかは、コマンド行インタープリタのタイプによって異なります。詳細は、シェルのマニュアルを参照してください。

一般に使用される ldapsearch オプション

ここでは、非常によく使用される ldapsearch コマンド行オプションを一覧表示します。空白 [ ] を含む値を指定する場合は、その値を二重引用符で囲む必要があります。たとえば、-b "ou=groups, dc=example,dc=com" のようになります。


-b	検索の開始点を指定します。ここで指定される値は、データベース内に現在存在している識別名である必要があります。このオプションは、ベース DN が LDAP_BASEDN 環境変数に設定されている場合に指定します。このオプションで指定する値は、二重引用符で囲む必要があります。たとえば、次のようにします。 -b "cn=Charlene Daniels, ou=People, dc=example,dc=com"
-D	サーバーに対する認証に使用する識別名を指定します。このオプションは、サーバーが匿名アクセスをサポートしている場合に指定します。このオプションを指定すると、値は Directory Server によって認識される DN になり、エントリを検索するための権限を持つようになります。たとえば、次のようにします。 -D "uid=cdaniels, dc=example,dc=com"
-h	Directory Server がインストールされているマシンのホスト名あるいは IP アドレスを指定します。ホストを指定しない場合は、ldapsearch によって localhost が使用されます。たとえば、-h myServer のように指定します。
-l	検索要求が完了するのを待機する最大秒数を指定します。ここで指定した値にかかわらず、ldapsearch は、サーバーの nsslapd-timelimit 属性によって許可された秒数より長く待機することはありません (持続検索の実行時を除く)。持続検索については、『Directory Server Resource Kit Tools Reference』の第 3 章にある「ldapsearch」を参照してください。たとえば、-l 300 のように指定します。nsslapd-timelimit 属性のデフォルト値は、3,600 秒 (1 時間) です。
-p	Directory Server が使用する TCP のポート番号を指定します。たとえば、-p 5201 のように指定します。デフォルト値は 389 で、SSL オプションが使用されている場合は 636 になります。
-s	検索範囲を指定します。次のいずれかの範囲です。 base : -b オプションで指定されたエントリ、または LDAP_BASEDN 環境変数で定義されたエントリのみを検索する one : -b オプションで指定されたエントリのすぐ下の子だけを検索する。検索されるのは子だけであり、-b オプションで指定された実際のエントリは検索されない sub : -b オプションで指定されたエントリと、そのすべての子孫を検索する。つまり、-b オプションで指定された地点からサブツリー検索を開始する。これはデフォルトの設定である
-w	-D オプションで指定された識別名に関連付けられたパスワードを指定します。このオプションを指定しない場合は、匿名アクセスが使用されます。たとえば、-w diner892 のように指定します。
-x	検索結果が、クライアント上ではなくサーバー上でソートされるように指定します。国際的な検索などのように、マッチングルールに従ってソートする場合に便利です。一般的に、クライアント上よりサーバー上でソートした方が高速ですが、サーバー側のソートはサーバーのリソースを消費します。
-z	検索要求に対して返す最大エントリ数を指定します。たとえば、-z 1000 のようになります。通常、ここで指定した値にかかわらず、サーバーの nsslapd-sizelimit 属性によって許可された数を超えるエントリが ldapsearch によって返されることはありません。ただし、このコマンド行引数を使用するときにルート DN としてバインドすることで、この制約を無効にできます。ルート DN としてバインドする場合、このオプションのデフォルト値はゼロ (0) になります。nsslapd-sizelimit 属性のデフォルト値は 2,000 エントリです。

ldapsearch の例

すべてのエントリを返す

上記の情報が与えられた場合は、次の呼び出しのようにするとディレクトリ内のすべてのエントリを返すことができます。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-b "dc=example,dc=com" -s sub "(objectclass=*)"

"(objectclass=*)" は、ディレクトリ内のすべてのエントリと一致する検索フィルタです。

コマンド行での検索フィルタの指定

検索フィルタはコマンド行から直接指定できます。この場合、フィルタを引用符で囲むことを忘れないでください ("filter")。また、-f オプションは指定しません。たとえば、次のようにします。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-b "dc=example,dc=com" "(cn=Charlene Daniels)"

ルート DSE エントリの検索

ルート DSE エントリは、サポートされたサフィックスのリストや使用可能な認証メカニズムなど、現在のサーバーインスタンスに関連する情報を含む特別なエントリです。検索ベース "" を指定することで、このエントリを検索できます。また、検索範囲 base、およびフィルタ "(objectclass=*)" を指定する必要があります。たとえば、次のようにします。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-b "" -s base "(objectclass=*)"

スキーマエントリの検索

Directory Server では、特別な cn=schema エントリ内にすべての Directory Server スキーマが格納されています。このエントリには、Directory Server に対して定義されたすべてのオブジェクトクラスと属性に関する情報が含まれています。

このエントリの内容を調べるには、次のように指定します。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-b "cn=schema" -s base "(objectclass=*)"

LDAP_BASEDN の使用


注	厳密に準拠する場合は、指定されたエントリのスキーマサブエントリの場所は、subschemaSubentry オペレーショナル属性によって指定されます。このバージョンの Directory Server では、この属性の値は常に cn=schema です。

検索を簡単に行うために、LDAP_BASEDN 環境変数を使用して検索ベースを設定することができます。これによって、-b オプションによる検索ベースの指定を省略できます (環境変数の設定方法については、オペレーティングシステムのマニュアルを参照)。

通常、ディレクトリのサフィックスの値には LDAP_BASEDN を設定します。ディレクトリのサフィックスはルート、つまりディレクトリの最上位のエントリと等しいので、この設定によってすべての検索がディレクトリのルートエントリから開始されます。

たとえば、LDAP_BASEDN を dc=example,dc=com に設定した場合、次のコマンド行の呼び出しを使用すると、ディレクトリ内で (cn=Charlene Daniels) を検索することができます。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
"(cn=Charlene Daniels)"

この例では、範囲の指定に -s オプションが使用されていないので、sub のデフォルト範囲が使用されます。

属性のサブセットの表示

ldapsearch コマンドでは、すべての検索結果が LDIF 形式で返されます。デフォルトでは、ldapsearch は、エントリの識別名と読み取りを許可されたすべての属性を返します。指定したディレクトリエントリの属性のサブセットの読み取りだけが許可されるように、ディレクトリのアクセス制御を設定できます。オペレーショナル属性だけは返されません。検索操作の結果としてオペレーショナル属性を返すようにする場合は、検索コマンド内でこれらを明示的に指定する必要があります。オペレーショナル属性については、『Directory Server Administration Reference』の第 11 章「Operational Attributes」を参照してください。

検索結果で返された属性のすべてを表示するわけではない場合を考えてみます。返された属性をいくつかの特定の属性に制限するには、検索フィルタのすぐ後のコマンド行で表示する属性を指定します。たとえば、ディレクトリのすべてのエントリについて cn 属性と sn 属性を表示するには、次のコマンドを使用します。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
"(objectclass=*)" sn cn

この例では、LDAP_BASEDN を使用して検索ベースを設定することを前提としています。

複数値属性の検索

Directory Server は、検索時に、複数値属性を必ずしもソート順で返すわけではありません。たとえば、変更を適用する前にサーバーを再起動することを要求する cn=config で、設定属性を検索する場合を考えてみます。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-b cn=config "(objectclass=*)" nsslapd-requiresrestart

dn:cn=config
nsslapd-requiresrestart: cn=config:nsslapd-port
nsslapd-requiresrestart: cn=config:nsslapd-secureport
nsslapd-requiresrestart: cn=config:nsslapd-plugin
nsslapd-requiresrestart: cn=config:nsslapd-changelogdir
nsslapd-requiresrestart: cn=config:nsslapd-changelogsuffix
nsslapd-requiresrestart: cn=config:nsslapd-changelogmaxentries
nsslapd-requiresrestart: cn=config:nsslapd-changelogmaxage
nsslapd-requiresrestart: cn=config:nsslapd-db-locks
nsslapd-requiresrestart: cn=config:nsslapd-return-exact-case
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
  cn=config:nsslapd-allidsthreshold
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
  cn=config:nsslapd-dbcachesize
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
  cn=config:nsslapd-dbncache
nsslapd-requiresrestart: cn=config,cn=ldbm database,cn=plugins,
  cn=config:nsslapd-directory
nsslapd-requiresrestart: cn=encryption,cn=config:nssslsessiontimeout
nsslapd-requiresrestart: cn=encryption,cn=config:nssslclientauth
nsslapd-requiresrestart: cn=encryption,cn=config:nssslserverauth
nsslapd-requiresrestart: cn=encryption,cn=config:nsssl2
nsslapd-requiresrestart: cn=encryption,cn=config:nsssl3
...

このように、nsslapd-requiresrestart 属性は複数の値を取得します。ただし、これらの値はソートされていません。複数値属性をソート順に表示するアプリケーションを開発する場合は、アプリケーションでソートを実行するようにします。

検索時のクライアント認証の使用

次の例は、クライアント認証を使用してディレクトリ検索を行うユーザーの cdaniels を示しています。

ldapsearch -h myServer -p 636 -b "dc=example,dc=com"
-N "cdanielsscertname" -Z -W certdbpassword
-P /home/cdaniels/certdb/cert.db "(givenname=Richard)"

LDAP 検索フィルタ

検索フィルタは、検索操作によって返されるエントリを選択します。検索フィルタは一般的に、ldapsearch コマンド行ユーティリティによって使用されます。ldapsearch を使用する場合は、各フィルタをファイル内の個別の行にしてファイル内に複数の検索フィルタを配置するか、コマンド行で直接検索フィルタを指定することができます。

たとえば、次のフィルタでは、共通名 Lucie Du Bois の検索を指定しています。

この検索フィルタでは、共通名 Lucie Du Bois を含むすべてのエントリが返されます。共通名の値の検索では、大文字と小文字は区別されません。

共通名属性に言語タグに関連付けられた値が存在する場合は、すべての値が返されます。したがって、次の 2 つの属性値はどちらもこのフィルタに一致します。

検索フィルタの構文

この例では、buildingname は属性、>= は演算子、および alpha は値です。ブール演算子によって異なる属性を組み合わせて使用するようにフィルタを定義することもできます。

検索フィルタでの属性の使用

エントリを検索するときに、そのエントリのタイプに関連付けられた属性を指定することができます。たとえば、人のエントリを検索する場合は、cn 属性を使用して特定の共通名を持つ人を検索することができます。

人のエントリが含まれる属性の例には次のようなものが挙げられます。

検索フィルタでの演算子の使用

表 2-2 は、検索フィルタで使用できる演算子を一覧表示したものです。

表 2-2 検索フィルタの演算子
検索のタイプ	演算子	説明
等価	=	指定した値と正確に一致する属性値を含むエントリを返す。たとえば、cn=Bob Johnson
部分文字列	=string* string	指定した部分文字列を含む属性を含むエントリを返す。たとえば次のとおり cn=Bob* cn=Johnson cn=John* cn=BJohn (アスタリスク () はゼロ (0) 個以上の文字を示す)
大きいまたは等しい	>=	指定した値より大きいかそれと等しい属性を含むエントリを返す。たとえば次のとおり buildingname >= alpha
小さいまたは等しい	<=	指定した値より小さいかそれと等しい属性を含むエントリを返す。たとえば次のとおり buildingname <= alpha
実在	=*	指定した属性について 1 つ以上の値を含むエントリを返す。たとえば次のとおり cn=* telephonenumber=* manager=*
近似	~=	検索フィルタで指定した値と近似した値を持つ特定の属性を含むエントリを返す。たとえば次のとおり cn~=suret l~=san fransico 上記によって次のエントリが返される cn=sarette l=san francisco 近似演算子は試験的に使用されているもので、英語の文字列でしか使用できない。Ja や Zn など、ASCII ベース以外の文字列では動作しない

dn 属性に対する検索機能を拡張し (たとえば cn:dn:=John)、国際的な検索をサポートするために拡張された演算子も存在します。

合成検索フィルタの使用

プレフィックス表記内で次のように表現されるブール演算子を使用して、複数の検索フィルタコンポーネントを組み合わせることができます。

この Boolean-operator は、表 2-3 に一覧表示されているブール演算子のいずれかになります。

ブール演算子を組み合わせ、相互に入れ子にすることで、次のような複雑な式を作成できます。

検索フィルタで使用できるブール演算子には、次のようなものがあります。

表 2-3 検索フィルタのブール演算子
演算子	記号	説明
AND	&	文が true になるためには、指定したすべてのフィルタが true である必要がある。たとえば次のとおり (&(filter)(filter)(filter)...)
OR	\|	文が true になるためには、指定したフィルタの少なくとも 1 つが true である必要がある。たとえば次のとおり (\|(filter)(filter)(filter)...)
NOT	!	文が true になるためには、指定したすべてのフィルタが true ではない必要がある。NOT 演算子によって影響を受けるのは 1 つのフィルタだけである。たとえば次のとおり (!(filter))

ファイルを使用した検索フィルタの指定

検索フィルタは、コマンド行ではなく、ファイルに入力することができます。この場合、各検索フィルタをファイル内の個別の行に指定します。ldapsearch コマンドは、ファイル内に現れる順序で各検索を実行します。

この場合、ldapsearch は最初に Daniels という姓を持つすべてのエントリを検索し、次に Charlene という名 (givenname) を持つすべてのエントリを検索します。両方の検索条件に一致するエントリが見つかったら、そのエントリは 2 回返されます。

たとえば、前述の検索フィルタを searchdb という名前のファイル内で指定して、LDAP_BASEDN を使用して検索ベースを設定したとします。次のように指定すると、どちらかの検索フィルタに一致するすべてのエントリが返されます。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-f searchdb

ここで返される属性セットを制限するには、検索行の末尾で検索する属性名を指定します。たとえば、次の ldapsearch コマンドは両方の検索を実行しますが、各エントリの DN と、givenname、および sn 属性だけを返します。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
-f searchdb sn givenname

検索フィルタ内でのコンマを含む DN の指定

検索フィルタ内の DN の値の一部にコンマが含まれる場合は、円記号 (¥) を使用して、コンマをエスケープする必要があります。たとえば、example.com Bolivia, S.A. サブツリー内の全員を検索するには、次のコマンドを使用します。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password -s base -b "o=example.com Bolivia¥, S.A.,dc=example,dc=com" "(objectclass=*)"

検索フィルタの例

次のフィルタでは、manager 属性について 1 つ以上の値を含むエントリを検索します。これは実在検索とも呼ばれるものです。

次のフィルタでは、共通名 Ray Kultgen を含むエントリを検索します。これは等価検索とも呼ばれるものです。

次のフィルタでは、部分文字列 X.500 を含む description 属性を含むすべてのエントリが返されます。

次のフィルタでは、組織単位が Marketing で、説明フィールドに部分文字列 X.500 を含まないすべてのエントリが返されます。

次のフィルタでは、組織単位が Marketing で、Julie Fulmer または Cindy Zwaska がマネージャとして存在するすべてのエントリが返されます。

(&(ou=Marketing)(|(manager=cn=Julie Fulmer,ou=Marketing,
dc=example,dc=com)(manager=cn=Cindy Zwaska,ou=Marketing,
dc=example,dc=com)))

次のフィルタでは、人を表さないすべてのエントリが返されます。

上記のフィルタは、パフォーマンスに悪影響を及ぼすので、複雑な検索の一部として使用します。次のフィルタでは、人を表さないもので、共通名が printer3b と近似しているすべてのエントリが返されます。

オペレーショナル属性の検索

検索操作の結果としてオペレーショナル属性を返すようにする場合は、検索コマンド内でこれらを明示的に指定する必要があります。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
"(objectclass=*)" aci

明示的に指定されたオペレーショナル属性に加えて通常の属性も取得するには、オペレーショナル属性にアスタリスク (*) を追加して指定します。たとえば、次のようにします。

ldapsearch -h myServer -p 5201 -D "cn=directory manager" -w password
"(objectclass=*)" aci *

DSMLv2 を使用したディレクトリへのアクセス

次の例は、DSML 要求を使用してディレクトリにアクセスして検索する方法を示しています。DSML 関連の属性の完全なリストと、DSMLv2 標準については、『Directory Server Administration Reference』の第 3 章にある「Frontend Plugin Attributes」を参照してください。

これらの例の content-length: ヘッダーには、DSMLv2 要求の具体的な長さが指定されています。これらの例が正常に機能するためには、このコンテンツ長を正しく理解するエディタを使用するか、必要に応じて値を手動で変更する必要があります。

空の匿名 DSML Ping 要求

DSML フロントエンドは、デフォルトでは無効化されています。有効化する方法については、「DSML 要求の有効化」を参照してください。DSML フロントエンドが有効であるかを確認するには、コード例 2-1 で示すように、空の DSML バッチ要求を送信します。

この DSML 要求の最初のセクションには HTTP メソッド行 (POST /dsml HTTP/1.1) が含まれており、その後に HTTP ヘッダーの番号が続きます。HTTP メソッド行は、HTTP メソッド要求と、DSML フロントエンドが使用する URL を指定します。POST は、DSML フロントエンドが受け付ける唯一の HTTP メソッド要求です。/dsml URL は Directory Server のデフォルト URL ですが、その他の任意の有効な URL を設定できます。これ以後の HTTP ヘッダーは、DSML 要求の残りの詳細を指定します。

残りの要求は SOAP/DSML セクションです。DSML 要求は、次の XML 序言ヘッダーから始まります。

これは、要求が UTF-8 文字セットで符号化される必要があることを示しています。ヘッダーの後には SOAP エンベロープと、必須の XML スキーマ、XML スキーマインスタンス、SOAP ネームスペースを含む本文要素が続きます。

DSML バッチ要求要素は DSML バッチ要求の開始を示し、直後に必須 DSMLv2 ネームスペースを含める要素が続きます。

オプションとして、この要求を次の要求 ID によって指定します。

は、このようにコメントアウトされた XML です。SOAP/DSML バッチ要求は、バッチ要求の終了、SOAP 本文の終了、SOAP エンベロープ要素の終了によって閉じられます。

DSML フロントエンドが有効であれば、空の DSML 応答が返されます。

何も返されない場合は、フロントエンドが無効であることがわかります。

ディレクトリに同時に接続できるクライアント数と、DSML 要求のサイズには、最大制限が適用されます。クライアント数の制限は ds-dsml-poolsize 属性と ds-dsml-poolmaxsize 属性によって指定され、要求サイズの制限は ds-dsml-requestmaxsize 属性によって指定されます。DSML 関連の属性については、『Directory Server Administration Reference』の第 2 章にある「Frontend Plug-In Attributes」を参照してください。

特定ユーザーとしてバインドする DSML 要求の発行

DSML 要求を発行するために、特定のユーザーまたは匿名ユーザーとしてディレクトリにバインドできます。特定ユーザーとしてバインドするには、dn にマッピングされる uid とパスワードを含む HTTP 承認ヘッダーを要求に含める必要があります。

この例では、HTTP 承認ヘッダーが、easter という uid と egg というパスワードを転送しており、これはプレーンテキスト形式で easter:egg と表示され、Base 64 で Authorization: Basic ZWFzdGVyOmVnZw== と符号化されています。

LDAP 拡張処理を指定するために、<extendedRequest> タグが使用されています。拡張処理の OID を指定するために、<requestName> タグが使用されています。この例では、OID 1.3.6.1.4.1.4203.1.11.3 によって whoami 拡張処理が識別されます。whoami 拡張処理については、http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authzid-08.txt を参照してください。

匿名アクセスを行うために HTTP 承認ヘッダーは必要ありません。ただし多くの場合、匿名アクセスは厳密なアクセス制御の対象となり、データアクセスが制約される可能性が高いことに注意してください。同様に、LDAP プロキシとして LDAP 操作を実行する DSML 要求を発行することもできます。

DSML 要求はバッチベースで管理されるため、LDAP プロキシによって要求を発行する場合、発行に必要な DSML プロキシ承認要求を、指定の要求バッチの先頭に配置する必要があります。

DSML 検索要求

コード例 2-2 は、ルート DSE エントリに対して実行される DSML ベースのオブジェクト検索要求を示しています。

POST /dsml HTTP/1.1
HOST: hostMachine
Content-Length: 1081
Content-Type: text/xml
SOAPAction: ""
Connection: close

<?xml version='1.0' encoding='UTF-8'?>
<soap-env:Envelope
   xmlns:xsd='http://www.w3.org/2001/XMLSchema'
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xmlns:soap-env='http://schemas.xmlsoap.org/soap/envelope/'
   >
   <soap-env:Body>
      <batchRequest
        xmlns='urn:oasis:names:tc:DSML:2:0:core'
        requestID='Batch of search requests'
        >
        <searchRequest
            dn=""
            requestID="search on Root DSE"
            scope="baseObject"
            derefAliases="neverDerefAliases"
            typesOnly="false"
            >
            <filter>
               <present name="objectClass"/>
            </filter>
            <attributes>
               <attribute name="namingContexts"/>
               <attribute name="supportedLDAPversion"/>
               <attribute name="vendorName"/>
               <attribute name="vendorVersion"/>
               <attribute name="supportedSASLMechanisms"/>
            </attributes>
        </searchRequest>
      </batchRequest>
   </soap-env:Body>
</soap-env:Envelope>

適用するフィルタには、オブジェクトクラスフィルタが次のように使用されます。

これは、LDAP フィルタ文字列 (objectclass=*) と同じです。このフィルタの後には、目的の属性のリストが続きます。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 管理ガイド