Sun Java™ System Directory Server 5.2 2005Q1 管理ガイド |
第 2 章
ディレクトリエントリの管理この章では、Directory Server コンソールと LDAP コマンド行ユーティリティを使用してディレクトリの内容を管理する方法について説明します。また、属性暗号化機能を使用して属性を保存する方法と、DSML を使用してディレクトリにアクセスする方法についても説明します。ディレクトリの配備を計画する場合には、ディレクトリに格納するデータの種類を把握する必要があります。エントリの作成およびデフォルトスキーマの変更に入る前に、『Directory Server 配備計画ガイド』の関連する章に目を通すようにしてください。
この章は、LDAP スキーマ、オブジェクトクラス、およびオブジェクトクラスに定義される属性について、ある程度の知識が読者にあることを前提としています。スキーマの概要と、Directory Server で提供されるすべてのオブジェクトのクラスと属性の定義については、『Directory Server Administration Reference』を参照してください。また、適切な ACI (アクセス制御命令) が定義されていない場合、ディレクトリは変更できません。詳細は、第 6 章「アクセス制御の管理」を参照してください。
この章は、次の節で構成されています。
設定エントリDirectory Server は、すべての設定情報を次のファイルに保存します。
ServerRoot/slapd-serverID/config/dse.ldif
このファイルの形式は、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 エントリとそのサブツリーです。ファイルの読み取りと書き込みが許可されているのは、インストール時に定義されたシステムユーザーだけです。
このファイルの内容を直接編集して設定を変更することは、エラーが生じる可能性が高くなるため、お勧めできません。次の点に注意が必要です。
- dse.ldif ファイルは起動時に一度だけ読み取られる読み取り専用ファイルです。このため、サーバー設定は、設定エントリのメモリ内の LDAP イメージに基づきます。サーバーの動作中に行ったファイルへの変更は削除されます。
- コンソールまたはコマンド行から設定を変更すると、設定の LDAP イメージが変更されます。一部のディレクトリ機能は、呼び出されたときに現在の設定を読み取り、サーバーの再起動を必要としません。
- サーバーは、設定の LDAP イメージが変更されるたびに dse.ldif ファイルに書き込みを行います。一部のディレクトリ機能は、サーバーの起動時にその機能の設定だけを読み取り、変更が適用されるようにファイルに書き込みを行います。
コンソールからのエントリの管理Directory Server コンソールの「ディレクトリ」タブとエントリエディタダイアログを使用して、エントリの追加、変更、または削除を個別に行うことができます。複数のエントリに対して同時に処理を行う方法については、「コンソールからの一括処理」を参照してください。
Directory Server コンソールの起動およびユーザーインタフェースの使用方法については、「Directory Server コンソールの使用」を参照してください。
ディレクトリエントリの作成
Directory Server コンソールには、ディレクトリエントリの作成に使用できる、カスタムテンプレートがいくつか用意されています。それぞれのテンプレートは、オブジェクトクラスの種類に固有のカスタムエディタです。表 2-1 は、各カスタムエディタで使用されるオブジェクトクラスを示しています。
これらのカスタムエディタには、対応するオブジェクトクラスのすべての必須属性と、共通して使用される一部のオプション属性を表すフィールドが含まれています。いずれかのテンプレートを使用してエントリを作成する方法については、「カスタムエディタを使用したエントリの作成」を参照してください。その他のタイプのエントリを作成する方法については、「その他のタイプのエントリの作成」を参照してください。
カスタムエディタを使用したエントリの作成
- Directory Server コンソールの最上位にある「ディレクトリ」タブで、ディレクトリツリーを展開して、新しいエントリの親となるエントリを表示します。
- 親エントリをマウスの右ボタンでクリックし、「新規」メニューを選び、サブメニューの「ユーザー」、「グループ」、「組織単位」、「ロール」、「サービスクラス」、「パスワードポリシー」、「リフェラル」の中からエントリのタイプを選択します。あるいは、親エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「新規」を選びます。選択したエントリタイプのカスタムエディタダイアログが表示されます。
カスタムエディタの左側の列には複数のタブがあり、各タブのフィールドが右側に表示されます。デフォルトでは、すべてのカスタムエディタは、「ユーザー」タブまたは「一般」タブが選択された状態で表示されます。これらのタブには、新しいエントリの名前と説明を入力するためのフィールドが含まれます。
次の図はユーザーエントリのカスタムエディタを示しています。
図 2-1 Directory Server コンソール: ユーザーエントリのカスタムエディタ
- カスタムエディタで、設定する属性のフィールドに値を入力します。フィールド名の隣にアスタリスク (*) が表示されたすべての必須属性には値を入力する必要があります。その他のフィールドは何も入力しなくても問題ありません。複数の値を入力できるフィールドでは、Return で値を区切ります。
指定したエントリタイプのカスタムエディタの各フィールドについて、説明を表示するときは「ヘルプ」ボタンをクリックします。「ユーザー」エディタと「組織単位」エディタの「言語」タブの説明については、「言語サポートの属性の設定」を参照してください。
サービスエントリのグループ、ロール、クラスを作成する方法については、第 5 章「ID とロールの管理」を参照してください。パスワードポリシーの作成については、第 7 章「ユーザーアカウントとパスワードの管理」を参照してください。リフェラルの作成については、「リフェラルの設定」を参照してください。
- 「了解」をクリックして新しいエントリを作成し、カスタムエディタダイアログを閉じます。新しいエントリがディレクトリツリーに表示されます。
- カスタムエディタダイアログには、対応するオブジェクトクラスのすべてのオプション属性のフィールドが表示されるわけではありません。カスタムエディタに表示されないオプション属性を追加する方法については、「汎用エディタによるエントリの変更」を参照してください。
その他のタイプのエントリの作成
表 2-1 に示されるオブジェクトクラス以外のオブジェクトクラスのエントリを作成するには、次の手順を実行します。この手順を実行して、ディレクトリスキーマに定義したカスタムオブジェクトクラスのエントリを作成することもできます。
- Directory Server コンソールの最上位にある「ディレクトリ」タブで、ディレクトリツリーを展開して、新しいエントリの親となるエントリを表示します。
- 親エントリをマウスの右ボタンでクリックして「新規」を選び、サブメニューから「その他」を選択します。あるいは、親エントリをマウスの左ボタンでクリックして選択し、「オブジェクト」メニューから「新規」、「その他」を順に選択することもできます。
「新規オブジェクト」ダイアログが表示されます。
- 「新規オブジェクト」ダイアログに表示されるオブジェクトクラスのリストから、新しいエントリを定義するオブジェクトクラスを選び、「了解」をクリックします。
表 2-1 に示されるオブジェクトクラスを選択した場合は、対応するカスタムエディタが表示されます (「カスタムエディタを使用したエントリの作成」を参照)。それ以外の場合は、汎用エディタが表示されます。
- 新規エントリを作成するときは、汎用エディタには選択しているオブジェクトクラスの必須属性に対応するフィールドが表示されます。すべての必須属性に値を設定する必要があります。一部のフィールドには、「新規」などの汎用のプレースホルダが表示されます。これは、作成するエントリに適した値で置き換える必要があります。
- 選択しているオブジェクトクラスで利用できるその他の属性を定義するには、それを明示的に追加する必要があります。オプション属性の値を設定するには、次の手順を実行します。
- 「属性の追加」ボタンをクリックして、利用できる属性のリストを表示します。
- 「属性の追加」ダイアログで 1 つまたは複数の属性を選択し、「了解」をクリックします。
- 汎用エディタで、新しい属性の名前の隣に値を入力します。
このダイアログのその他のコントロールについて詳細は、「汎用エディタによるエントリの変更」を参照してください。
- デフォルトでは、必須属性の 1 つがネーミング属性として選択され、汎用エディタにエントリの DN として表示されます。ネーミング属性を変更するには、次の手順を実行します。
- 汎用エディタの「了解」をクリックして新しいエントリを保存します。
新しいエントリは、ディレクトリツリー内の親エントリの子として表示されます。
カスタムエディタによるエントリの変更
表 2-1 に示されるオブジェクトクラスでは、対応するカスタムエディタまたは汎用エディタを使用してエントリを編集できます。カスタムエディタを使う場合は、最も一般的なフィールドに簡単にアクセスできます。また、このインタフェースを使えば、ロールやサービスクラスの定義などに関連する複雑な属性も簡単に設定できます。
汎用エディタでは、オブジェクトクラスの追加、許可されている属性の追加、複数値属性の処理など、エントリに対してより高度な設定を行えます。汎用エディタを使用してエントリを編集する方法については、「汎用エディタによるエントリの変更」を参照してください。
注
カスタムエディタは、表 2-1 に示されるオブジェクトクラスだけの編集に使用できます。たとえば、inetorgperson から継承するカスタムクラスなど、その他の構造化オブジェクトクラスを含むエントリの編集には、汎用エディタを使う必要があります。
リストに含まれるオブジェクトクラスのほかに auxiliary オブジェクトクラスを含むエントリは、カスタムエディタを使用して管理できます。ただし、auxiliary クラスによって定義される属性はカスタムエディタには表示されません。auxiliary オブジェクトクラスの定義については、『Directory Server Administration Reference』を参照してください。
カスタムエディタの起動
オブジェクトクラスが表 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 コンソール: 汎用エディタ
汎用エディタでは、エントリの属性はアルファベット順に表示され、それぞれの値がテキストボックスに表示されます。読み取り専用属性やオペレーショナル属性などのすべての属性が表示されます。右側のコントロールを使うことで、エディタの表示を変更したり、属性のリストを編集したりすることができます。
- 必要に応じて、「表示」ボックスのコントロールを使用して汎用エディタの表示を変更できます。
- 属性の名前をスキーマに最初に定義したとおりに表示するときは、「属性の名前を表示」オプションを選択します。属性リストの表示が更新され、属性が名前のアルファベット順に表示されます。
- スキーマに属性の別名が定義されている場合に、属性を別名順にリスト表示するときは、「属性の説明を表示」オプションを選択します。通常、別名は属性を明示的に説明します。属性リストの表示が更新され、属性が別名 (説明) のアルファベット順に表示されます。
- エントリのオブジェクトクラスのスキーマで明示的に許可されているすべての属性を表示するときは、「値が設定された属性のみを表示」チェックボックスの選択を解除します。エントリに extensibleObject オブジェクトクラスが含まれる場合、暗黙的にすべての属性が許可されますが、それは表示されません。デフォルトでは、値が定義されている属性だけが表示されます。
- 属性の下のエントリの識別名の表示と非表示を切り替えるときは、「DN を表示」チェックボックスを選択または選択解除します。
- 「再表示」ボタンをクリックすると、そのエントリの現在の内容に基づいて、すべての属性の値が更新されます。
属性値の設定、オブジェクトクラスの管理、エントリのネーミング属性の変更に関連するコントロールについては後述します。
属性値の変更
属性値を変更するには次の手順を行います。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、変更する値をクリックします。
選択した属性が強調表示され、選択した値を含むテキストフィールドに編集カーソルが表示されます。
- マウスとキーボードを使用してテキストを編集し、適切な値を入力します。システムのクリップボードを使用して、このフィールドのテキストのコピー、カット、ペーストを行うことができます。
テキストフィールドの内容を編集できないときは、その属性が読み取り専用であるか、値の変更に必要な書き込み権限がありません。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
複数値属性の編集
ディレクトリスキーマで複数値として定義されている属性は、汎用エディタの 1 つのフィールドに複数の値を設定できます。詳細は、第 9 章「ディレクトリスキーマの拡張」を参照してください。
複数値属性に新しい値を追加するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、属性またはその値をクリックします。選択した属性が強調表示され、「値の追加」ボタンが有効になります。このボタンが有効にならないときは、選択している属性が複数値として定義されていないか、読み取り専用である、または値の変更に必要な書き込み権限がありません。
- 「値の追加」ボタンをクリックします。リスト内の属性名の隣に、新しい空白のテキストフィールドが表示されます。
- 新しいテキストフィールドに、この属性の新しい値を入力します。システムのクリップボードを使用して、このフィールドのテキストのコピー、カット、ペーストを行うことができます。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
複数値属性の値を削除するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、削除する値をクリックします。選択した属性が強調表示され、「値の削除」ボタンが有効になります。このボタンが有効にならないときは、選択している属性が読み取り専用であるか、値の変更に必要な書き込み権限がありません。
- 「値の削除」ボタンをクリックします。選択している値を含むテキストフィールドが削除されます。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
属性の追加
エントリに属性を追加するには、その属性を必須属性または許可された属性として持つオブジェクトクラスが、対象のエントリに含まれていることが必要です。詳細は、「オブジェクトクラスの管理」および第 9 章「ディレクトリスキーマの拡張」を参照してください。
エントリに属性を追加するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 「値が設定された属性のみを表示」オプションが選択されていることを確認します。
- 「属性の追加」ボタンをクリックして、属性のリストを示すダイアログを表示します。このリストには、そのエントリに定義されているオブジェクトクラスで使用できる属性だけが表示されます。
- 「属性の追加」ダイアログで、追加する 1 つまたは複数の属性を選択します。
- 必要に応じて、ダイアログ上部のドロップダウンリストから次のいずれか、または両方のサブタイプを選択できます。
- 属性とオプションサブタイプの選択が完了したら、「了解」をクリックします。汎用エディタの属性のリストに、属性がアルファベット順に追加されます。
- 新しい属性の名前の隣にある空白のテキストフィールドに、この属性の新しい値を入力します。システムのクリップボードを使用して、このフィールドのテキストのコピー、カット、ペーストを行うことができます。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
属性の削除
属性とすべての値をエントリから削除するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、削除する属性の名前をクリックします。選択した属性が強調表示され、「属性の削除」ボタンが有効になります。このボタンが有効にならないときは、選択している属性が読み取り専用であるか、値の変更に必要な書き込み権限がありません。
注
汎用エディタでは、この属性に定義されているオブジェクトクラスが必要とする属性も削除できます。必須属性を含まないエントリを保存しようとすると、サーバーはオブジェクトクラス違反を返します。すべてのオブジェクトクラスの必須属性がエントリに含まれることを確認してください。
- 「属性の削除」ボタンをクリックします。属性と、その属性のすべてのテキストフィールドが削除されます。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
オブジェクトクラスの管理
エントリのオブジェクトクラスは、複数値の objectclass 属性によって定義されます。この属性を変更する場合に、定義されているオブジェクトクラスを管理できるように、汎用エディタには特別なダイアログがあります。
オブジェクトクラスをエントリに追加するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、オブジェクトクラスまたは objectclass 属性を選択します。「値の追加」ボタンが有効になります。このボタンが有効にならないときは、このエントリのオブジェクトクラスの変更に必要な権限がありません。
- 「値の追加」ボタンをクリックします。
「オブジェクトクラスの追加」ダイアログが表示されます。このウィンドウには、エントリに追加できるオブジェクトクラスのリストが表示されます。
- このエントリに追加するオブジェクトクラスを 1 つまたは複数選択し、「了解」をクリックします。選択したオブジェクトクラスが、objectclass 属性の値のリストに表示されます。
- 新しいオブジェクトクラスが、エントリに含まれない属性を必要とする場合は、汎用エディタはそれを自動的に追加します。すべての必須属性に値を設定する必要があります。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
エントリからオブジェクトクラスを削除するには、次の手順を実行します。
- 「汎用エディタの起動」で説明する方法で、汎用エディタを開きます。
- 属性のリストをスクロールし、削除する objectclass 属性の値をクリックします。選択しているオブジェクトクラスの削除がスキーマで許可され、このエントリのオブジェクトクラスを変更する権限がある場合は、「値の削除」ボタンが有効になります。
- 「値の削除」ボタンをクリックします。指定したオブジェクトクラスが削除されます。
オブジェクトクラスを削除すると、汎用エディタは残りのオブジェクトクラスが許可しないか、必要としないすべての属性を自動的に削除します。いずれかのネーミング属性が削除されると、別のネーミング属性が自動的に選択されます。コンソールは、この変更を示すメッセージを表示します。
- このエントリのその他の値を編集するか、その他の変更を加え、「了解」をクリックして変更を保存し、汎用エディタを閉じます。
ディレクトリエントリの削除
Directory Server コンソールを使用してディレクトリエントリを削除するには、次の手順を実行します。
- Directory Server コンソールの最上位にある「ディレクトリ」タブでディレクトリツリーを展開し、削除するエントリを表示します。
サブツリーのルートノードを選択することで、ディレクトリのブランチ全体を削除することもできます。
- エントリをマウスの右ボタンでクリックし、「削除」を選択します。これ以外の方法でエントリを削除することもできます。
- エントリまたはサブツリーとそのすべての内容を削除することを確認します。
選択したエントリがただちに削除されます。この処理を元に戻すことはできません。複数のエントリを削除した場合、削除したエントリの数を示すダイアログが表示されます。また、削除時にエラーが発生した場合は、エラーを示すダイアログが表示されます。
コンソールからの一括処理
LDIF ファイルを使用することで、複数エントリの追加、組み合わせ操作の実行、サフィックス全体のインポートを行うことができます。LDIF ファイルと Directory Server コンソールを使用してエントリを追加するには、次の手順を実行します。
- 前述の節に示される構文を使用して LDIF ファイルにエントリまたは操作を定義します。エントリを追加するだけ、またはサフィックスを初期化するだけの処理では、changetype キーワードは必要ありません。エントリだけを LDIF ファイルに指定します。組み合わせ操作を実行するときは、すべての DN に changetype を続け、必要に応じて特定の処理または属性値を指定します。
- Directory Server コンソールから LDIF ファイルをインポートします。詳細は、「LDIF ファイルのインポート」を参照してください。
組み合わせ操作を実行するときは、サーバーがすべての LDIF 処理を実行できるように、「LDIF のインポート」ダイアログで「追加のみ」が選択されていないことを確認します。
コマンド行からのエントリの管理コマンド行ユーティリティ ldapmodify および ldapdelete には、ディレクトリの内容を追加、編集、削除するための完全な機能が用意されています。これらを使用して、サーバーの設定エントリと、ユーザーエントリに含まれるデータの両方を管理できます。これらのユーティリティは、1 つまたは複数のディレクトリの一括管理を実行するためのスクリプトの作成にも利用できます。
ldapmodify コマンドと ldapdelete コマンドは、このマニュアル全体の手順で使用されます。次に、これらの管理手順の実行に必要なすべての基本操作について説明します。ldapmodify コマンドと ldapdelete コマンドの詳細は、『Directory Server Man Page Reference』を参照してください。
コマンド行ユーティリティへの入力は、常に LDIF 形式で行います。この形式の入力は、コマンド行から直接指定できるだけでなく、入力ファイルからも行うことができます。次の節では、LDIF 入力について説明し、それ以降の節では各種変更処理で使われる LDIF について説明します。
LDIF 入力の実行
ディレクトリデータはすべて、Unicode の UTF-8 エンコーディングを使用して保存されています。したがって、LDIF 入力もすべて UTF-8 で符号化されている必要があります。LDIF 形式についての詳細は、『Directory Server Administration Reference』の「LDAP Data Interchange Format Reference」を参照してください。
LDIF を入力する場合、次の点に留意してください。
- オブジェクトは dn: で始まる行の前に空白行を入れます。この行はオブジェクトの識別名に使用します。その他のすべての行はオブジェクトの属性です。
- コメントは # で始まります (EOL で終わる)。
- 2 行目は先頭を 1 文字下げます。
- バイナリ値は base-64 でエンコードし、属性値の後にダブルコロン (::) を付けて表します。
- LDIF 値では改行と行送りは固定されないため、base-64 方式を使用する必要があります。
- ldapmodify コマンドを使用して属性値を変更する場合、属性値の後に空白を残さないでください。詳細は、「属性値の変更」を参照してください。
コマンド行での LDIF 入力の終了
ldapmodify ユーティリティと ldapdelete ユーティリティは、ファイルから読み取るのとまったく同様に、ユーザーがコマンドの後に入力した LDIF 文を読み取ります。入力が終了したら、ファイルの最後 (EOF) を示すエスケープシーケンスとしてシェルに認識される文字を入力します。
次の例は、ldapmodify コマンドの入力の終了方法を示しています。
prompt> ldapmodify -h host -p port -D bindDN -w password
dn: cn=Barry Nixon,ou=People,dc=example,dc=com
changetype: modify
delete: telephonenumber
^D
prompt>表記を単純かつわかりやすくするために、このマニュアルの例には EOF シーケンスは表示されません。
特殊文字の使い方
コマンド行にコマンドオプションを指定するときは、コマンド行インタープリタにとって特別な意味を持つエスケープ文字の入力が必要になることがあります。このような文字には、空白 ( )、アスタリスク (*)、円記号 (¥) などが含まれます。たとえば、多くの DN には空白文字が含まれ、ほとんどの UNIX シェルでは値を二重引用符 ("") で囲む必要があります。
-D "cn=Barbara Jensen,ou=Product Development,dc=example,dc=com"
一重引用符または二重引用符のどちらを使用するかは、コマンド行インタープリタのタイプによって異なります。詳細は、オペレーティングシステムのマニュアルを参照してください。
さらに、コンマを含む DN を使用する場合は、円記号 (¥) でコンマをエスケープする必要があります。たとえば、次のようにします。
-D "cn=Patricia Fuentes,ou=People,o=example.com Bolivia¥,S.A."
ldapmodify コマンドの後の LDIF 文はシェルではなく、コマンドによって解釈されるため、特別な注意が必要ないことに注意してください。
属性 OID の使用
デフォルトでは、属性 OID は属性名でサポートされていません。Directory Server の一部のバージョンではサポートされていました。以前のバージョンの Directory Server で属性名として属性 OID を使用していた場合、属性 nsslapd-attribute-name-exceptions を on に設定して属性 OID が受け付けられるようにする必要があります。
スキーマ検査
エントリを追加または変更する場合、使用する属性は、エントリのオブジェクトクラスが必要とするか、許可する属性である必要があり、その属性には、定義されている構文に準拠する値が含まれている必要があります。
エントリを変更すると、Directory Server は変更される属性だけでなく、エントリ全体に対してスキーマ検査を行います。このため、エントリのいずれかのオブジェクトクラスまたは属性がスキーマに準拠していない場合、変更処理は失敗します。詳細は、「スキーマ検査」を参照してください。
LDIF エントリの順序
エントリを追加するための LDIF テキストのシーケンスでは、コマンド行に指定する場合も、ファイルに指定する場合も、親エントリを子の前に指定する必要があります。これにより、サーバーが LDIF テキストを処理するときに、子エントリの前に親エントリが作成されます。
たとえば、ディレクトリに存在しない People サブツリーにエントリを作成する場合、サブツリー内のエントリの前に People コンテナを表すエントリを指定します。
dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
...
People サブツリーのエントリ
...
dn: ou=Group,dc=example,dc=com
...
Group サブツリーのエントリ
...ldapmodify コマンド行ユーティリティを使用してディレクトリ内にエントリを作成することができますが、サフィックスまたはサブサフィックスのルートは、必要な設定エントリと関連付ける必要のある特別なエントリです。新しいルートサフィックスまたはサブサフィックス、およびそれに関連する設定エントリを追加する手順については、「コマンド行からのサフィックスの作成」を参照してください。
大規模なエントリの管理
極端に大きな属性値を持つエントリを追加または変更するときは、それを受け入れることができるように、事前にサーバーの設定が必要になることがあります。サーバーのオーバロードを防ぐために、デフォルトでは、クライアントは 2M バイトを超えるデータを送信できないように制限されています。
これを超えるエントリを追加するか、属性をこれ以上の値に変更しようとすると、サーバーはその処理を拒否し、直ちに接続を閉じます。たとえば、1 つのエントリの 1 つまたは複数の属性にマルチメディアコンテンツなどのバイナリデータが含まれると、この制限を超える可能性があります。
また、多数のメンバーを含む大規模なスタティックグループを定義するエントリも、この制限を超える可能性があります。ただし、パフォーマンスを考慮すると、このようなグループはお勧めできません。ディレクトリ構造の再設計を考慮する必要があります。詳細は、「グループの管理」を参照してください。
クライアントが送信するデータにサーバーが適用するサイズ制限を変更するには、次の手順を実行します。
- cn=config エントリの nsslapd-maxbersize 属性に新しい値を設定します。
- この処理をコンソールから行うには、管理者またはディレクトリマネージャーとしてログオンし、「汎用エディタによるエントリの変更」で説明する方法で、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』の「nsslapd-maxbersize」を参照してください。
- 「Directory Server の起動と停止」で説明している手順を実行してサーバーを再起動します。
エラーの処理
コマンド行ツールは、LDIF 入力に含まれるすべてのエントリまたは変更を順番に処理します。最初のエラーが発生した場合のデフォルトの対応は、処理の停止です。エラーに関係なくすべての入力の処理を継続するときは、-c オプションを指定します。エラーの状態は、ツールの出力に表示されます。
上記注意点のほかに一般的なエラーには、次のようなものがあります。
ldapmodify コマンドと ldapdelete コマンドで発生するエラー状況と、これらのコマンドを回避する方法の詳細は、『Directory Server Man Page Reference』を参照してください。
ldapmodify によるエントリの追加
ldapmodify の -a オプションを使用して、ディレクトリに 1 つまたは複数のエントリを追加できます。次の例では、ユーザーを含む構造化エントリを作成し、次にユーザーエントリを作成します。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w 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: clearPassword-D オプションと -w オプションは、これらのエントリの作成に必要な権限を持つユーザーのバインド DN とパスワードを指定します。-a オプションは、LDIF に指定されているすべてのエントリが追加されることを示します。各エントリには DN と属性値が指定され、エントリとエントリの間には空白行が挿入されます。ldapmodify ユーティリティは、入力されるすべてのエントリを順番に作成し、エラーが発生した場合は、それをレポートします。
慣例により、エントリの LDIF には、次の順序で属性が指定されます。
userpassword 属性の値を入力するときは、パスワードをクリアテキストで指定します。サーバーはこの値を暗号化し、暗号化された値だけが格納されます。LDIF ファイルに表示されるクリアテキストのパスワードを保護するために、読み取りアクセス権を制限してください。
-a オプションを必要としない、別の形式の LDIF をコマンド行に指定することもできます。この形式の利点は、エントリを追加する文と、次の節で説明するエントリを変更する文を組み合わせて指定できることです。
ldapmodify -h host -p port -D "cn=Directory Manager" -w 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: clearPasswordchangetype: add キーワードは、指定の DN を持つエントリが、それ以後のすべての属性を持った状態で作成されることを示します。それ以外のすべてのオプションと LDIF の表記は同じです。
どちらの例でも、-f filename オプションを使うことで、端末からの入力の代わりにファイルから LDIF を読み取ることができます。LDIF ファイルには、-a オプションを使用した場合、端末からの入力と同じ形式で情報を指定する必要があります。
ldapmodify によるエントリの変更
既存のエントリの属性と属性値を追加、置換、または削除するときは、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 のペアを複数指定して、それを一度に追加、置換、または削除することもできます。
属性値の追加
次の例は、同じ add LDIF 文を使用して、既存の複数値属性と、まだ存在しない属性に値を追加する方法を示しています。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: cn
cn: Babs Jensen
-
add: mobile
mobile: (408) 555-7844
mobile: (408) 555-7845次の場合は、処理が失敗し、エラーが返されることがあります。
バイナリ属性サブタイプの使用
attribute;binary サブタイプは、実際の構文にかかわらず、値がバイナリデータとして LDAP 上を転送されることを示しています。このサブタイプは、userCertificateなど、LDAP 文字列表現を持たない複雑な構文用に設計されたものです。この目的以外でバイナリサブタイプを使用しないでください。
ldapmodify コマンドで使用するどの LDIF 文でも、属性名に適切なサブタイプを追加できます。
バイナリ値を入力するには、LDIF テキストに直接入力するか、別のファイルから読み取ります。次の例は、ファイルから読み取る LDIF の構文を示しています。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
version: 1
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///path/certFileファイル名の指定に < 構文を利用するには、LDIF 文を version: 1 という行から開始する必要があります。ldapmodify がこの文を処理するときに、このツールは、指定ファイルの内容全体から読み取った値を属性に設定します。
言語サブタイプを持つ属性の追加
属性の言語とふりがなのサブタイプは、ローカライズされた値を特定します。属性に対して言語サブタイプを指定すると、そのサブタイプが属性名に次のように追加されます。
attribute;lang-CC
ここで、attribute は既存の属性タイプを示し、CC は言語を特定する 2 文字の国コードを示します。オプションとして、言語サブタイプにふりがなのサブタイプを追加し、ローカライズされた値の発音表記を指定することもできます。この場合、属性名は次のようになります。
attribute;lang-CC;phonetic
サブタイプを持つ属性に対して処理を行うには、そのタイプを明示的に一致させる必要があります。たとえば、lang-fr の言語サブタイプを持つ属性値を変更する場合は、次の例に示すように、変更操作に lang-fr を含める必要があります。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
replace: homePostalAddress;lang-fr
homePostalAddress;lang-fr:34¥, avenue des Champs-Elysées属性値の変更
次の例に、LDIF で replace 構文を使用して属性の値を変更する方法を示します。
ldapmodify -h host -p port -D "cn=Directory Manager" -w 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 など)。
属性値の後ろに空白文字がある場合、その空白文字は属性値の一部としてエンコードされます。コンソールまたは ldapsearch コマンドを使用して変更を確認する場合、値はプレーンテキストで表示されますが、base-64 方式のテキストで表示される場合もあります。これは、使用している Directory Server クライアントにより異なります。
属性値の削除
次の例は、属性全体、または複数値属性の 1 つの値だけを削除する方法を示しています。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
delete: facsimileTelephoneNumber
-
delete: cn
cn: Babs Morrisattribute: value のペアを指定せずに delete 構文を使用すると、属性のすべての値が削除されます。attribute: value のペアを指定した場合は、その値だけが削除されます。
複数値属性の 1 つの値の変更
ldapmodify コマンドを使用して、複数値属性の 1 つの値を変更するには、次の例に示すように、2 段階の処理が必要です。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
delete: mobile
mobile: (408) 555-7845
-
add: mobile
mobile: (408) 555-5487ldapdelete によるエントリの削除
ディレクトリからエントリを削除するときは、ldapdelete コマンド行ユーティリティを使います。このユーティリティは、ディレクトリサーバーにバインドし、DN によって指定される 1 つまたは複数のエントリを削除します。指定のエントリを削除する権限を持つバインド DN を指定する必要があります。
子エントリのあるエントリは削除できません。LDAP プロトコルでは、親を持たない子エントリが存在する状況を禁止しています。たとえば、組織単位に属するすべてのエントリを先に削除しない限り、組織単位エントリは削除できません。
警告
サフィックス o=NetscapeRoot は削除しないでください。管理サーバー は、このサフィックスを使用してインストールした Sun Java System サーバーに関する情報を格納します。このサフィックスを削除すると、Directory Server を含むすべての Sun Java System サーバーの再インストールが必要になります。
次の例では、組織単位には 1 つのエントリしか含まれていないため、そのエントリを削除すれば、親エントリを削除できます。
ldapdelete -h host -p port -D "cn=Directory Manager" -w password
uid=bjensen,ou=People,dc=example,dc=com
ou=People,dc=example,dc=comldapmodify によるエントリの削除
changetype: delete キーワードを利用することで、ldapmodify ユーティリティを使用してエントリを削除することもできます。この場合も、前述の ldapdelete と同じ制限が適用されます。LDIF 構文を使用してエントリを削除する利点は、1 つの LDIF ファイルで複数の処理を組み合わせて実行できることです。
次の例は、前述の例と同じ削除処理を行います。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: delete
dn: ou=People,dc=example,dc=com
changetype: delete
エントリの名前変更と移動この節では DN 変更操作の概要を説明し、DN 変更操作の使用に関するガイドラインを示し、コンソールとコマンド行による DN 変更操作の実行方法について説明します。
DN 変更操作の概要
Directory Server 5.2 2005Q1 以前のバージョンの Directory Server では、エントリ名を変更できました。Directory Server 5.2 2005Q1 以降、エントリ名の変更とエントリの移動が可能になりました。
DN 変更操作は、次の作業には使用できません。
名前変更操作と移動操作の違い
この節ではエントリ名の変更とエントリの移動の違いについて説明します。
エントリ名の変更
エントリ名を変更した場合、エントリの DN の左端に表示される属性のタイプ=値ペアが変更されます。この属性の type=value 属性ペアはエントリの RDN です。属性のタイプ、属性の値、または属性のタイプと値は名前の変更ができます。名前変更の操作を実行するには、新しい DN がすでに存在していてはいけません。
次の例では、属性のタイプと属性の値をどのように変更できるかを示します。
例 1: 次の DN で属性のタイプを cn から uid に変更します。
dn: cn=john,dc=california,dc=sun,dc=com
例 2: 次の DN で属性の値を john から bob に変更します。
dn: cn=john,dc=california,dc=sun,dc=com
エントリの移動
エントリを移動した場合、エントリの DN の右端に表示される属性のタイプ=値ペアが変更されます。このアクションにより、エントリが別のサブツリーに移動します。移動操作を実行するには、新しい場所に対応する DN が同じサフィックスに存在している必要があります。
例 3: 次の DN でエントリ john を california から france に移動します。
dn: cn=john,dc=california,dc=sun,dc=com
DN の変更操作に関するガイドラインと制限
DN の変更操作を使用する予定がある場合、次の節で示されるガイドラインに従ってください。
DN の変更操作に関する一般的なガイドライン
DN の変更操作を使用する場合は、次の勧告に従ってください。
- 次の作業に DN の変更操作を使用しないでください。
- 実行中の Directory Server が 5.2 2005Q1 以降であることを確認してください。Directory Server 5.2 2005Q1 以前のバージョンの Directory Server では、DN の変更操作を使用できません。レプリケートされたトポロジを使用している場合、トポロジ内のすべてのサーバーが Directory Server 5.2 2005Q1 以降を実行していることを確認してください。
- entryid オペレーショナル属性は、内部使用専用に予約されているため、アプリケーションへは使用しないでください。エントリの entryid 属性は、エントリが移動すると変更されます。
- DN の変更操作はサーバー上のすべてのサフィックスに対してグローバルに、または操作を実行する各サフィックスで個別に有効にすることができます。デフォルトでは、DN の変更操作は無効になっています。レプリケートされたトポロジを実行している場合、DN の変更操作をトポロジのすべてのサーバーで有効にします。DN の変更操作を有効にする方法の詳細は、「コンソールによる DN 変更操作の有効化」または「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- DN の変更操作を実行する各サフィックスで、ACI 権限を拡張します。Import アクセス権を使用すると、指定された DN にエントリをインポートすることができます。Export アクセス権を使用すると、指定された DN からエントリをエクスポートすることができます。ACI 権限を拡張する方法の詳細は、「コンソールによる DN 変更操作の有効化」または「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- DN の変更操作を実行する前に、この操作によってクライアント認証が無効にならないことを確認してください。クライアント証明書を参照するエントリを移動する場合、クライアント認証が無効になります。エントリの移動後に、証明書を確認してください。
- DN の変更操作を実行する前に、この操作によってアプリケーションが中断されることがないようにしてください。エントリの名前変更または移動によりいくつかのサフィックスに影響が及ぶ場合があります。あるいはエントリの次の特性が変更される可能性があります。
レプリケーションを使用した DN の変更操作に関する一般的なガイドライン
レプリケーションを使用した DN の変更操作を実行する場合、レプリケーショントポロジは次の要件に適合する必要があります。
- レプリケーショントポロジのすべてのサーバーが Directory Server 5.2 2005Q1 以降を実行していることを確認します。Directory Server 5.2 2005Q1 以前のバージョンの Directory Server では、DN の変更操作を使用できません。
- レプリケーショントポロジのすべてのサーバーで、DN の変更操作を有効にします。DN の変更操作がマスターサーバーでサポートされていてもコンシューマサーバーでサポートされていない場合、レプリケーションは失敗します。サプライヤサーバーのエラーログに、次のようなメッセージが書き込まれます。
「Unable to start a replication session with MODDN enabled」
レプリケーションを再開するには、次の手順を実行します。
1. レプリケーショントポロジを再構成し、すべてのサーバーで DN の変更操作を有効にします。
2. 次のいずれかの方法で、レプリケーションセッションを開始します。
- 「コンソールによるレプリケーションの強制的な更新」、または「コマンド行によるレプリケーションの強制的な更新」の手順に従います。
- サプライヤサーバーでエントリを変更します。変更内容はコンシューマサーバーにレプリケートされます。
- トポロジのすべてのマスターレプリカで、参照整合性プラグインを有効にし設定します。このアクションにより、サーバーがグループとロールに対して参照整合性を維持できます。参照整合性を有効にし、設定する方法の詳細は、「参照整合性の設定」を参照してください。
- DN の変更操作を実行した後で、参照整合性プラグインにより変更内容がレプリケートされるまで待機します。
コンソールによるエントリの名前変更または移動
この節ではコンソールを使用したエントリの名前変更およびエントリの移動の方法について説明します。
コンソールによる DN 変更操作の有効化
アクセス権を付与するように ACI 権限が設定されていなければ、サフィックスで DN の変更操作を実行できません。DN の変更操作はサーバー上のすべてのサフィックスに対してグローバルに有効化または無効化できます。あるいは特定の各サフィックスに対して個別に有効化または無効化できます。
次の手順は、異なる ACI 権限を設定する方法の例です。この手順では、最も適切な ACI 権限が設定されない場合があります。ACI 権限の設定方法の詳細は、『Administration Server Administration Guide』のアクセス制御手順の操作に関する説明を参照してください。
コンソールによって ACI 権限を拡張するには、次の手順を実行します。
この手順では、すべてのユーザーがサフィックス全体に DN の変更操作を実行できるように ACI 権限を設定します。
- 「ディレクトリ」タブで Directory Server コンソール を起動します。
- ACI 権限を拡張するサフィックスを左側から選択します。
- サフィックスをマウスの右ボタンでクリックし、ポップアップメニューから「アクセス権を設定」を選択します。
「アクセス制御の管理」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。
- 「アクセス制御の管理」ウィンドウで、匿名アクセス ACI を選択し、「編集」をクリックします。
アクセス制御エディタが表示されます。
- import とラベル表示されたチェックボックスを選択し、指定したサフィックスに子のエントリがインポートされるようにします。
- export とラベル表示されたチェックボックスを選択し、指定されたサフィックスの下から同じサフィックスの別の場所にエントリが移動するようにします。
- 「ACI の編集」ウィンドウで「了解」をクリックします。ウィンドウが閉じます。
- 「アクセス制御の管理」ウィンドウの「了解」ボタンをクリックします。ウィンドウが閉じます。
コンソールによる DN 変更操作のグローバルな有効化または無効化
コンソールによる特定のサフィックスに対する DN 変更操作の有効化
コンソールによるエントリの名前変更
この節ではエントリの名前を変更する方法を説明します。この操作は Directory Server 5.2 2005Q1 以前のバージョンの Directory Server でサポートされます。この操作を実行するために、DN の変更操作を有効にする必要はありません。
コンソールによるエントリの名前変更
- 「ディレクトリ」タブで Directory Server コンソール を起動します。
- ディレクトリツリーを展開して、編集するエントリを表示します。
- 名前を変更するエントリを選択し、右クリックして「汎用エディタで編集」を選択します。
汎用エディタウィンドウが表示されます。汎用エディタウィンドウを図 2-2 に示します。
- 変更する RDN に対応する属性を選択します。
- 属性ボックスのテキストを、エントリの現在の名前から新しい名前に変更します。
- 「了解」をクリックします。
コンソールによるエントリの移動
この手順は Directory Server 5.2 2005Q1 以前のバージョンの Directory Server ではサポートされていません。
コンソールによりエントリを移動するには、次の手順を実行します。
- DN の変更操作がグローバルに有効になっている、または移動するエントリを格納したサフィックスで有効になっていることを確認します。詳細は、「コンソールによる DN 変更操作の有効化」を参照してください。
- 「ディレクトリ」タブで Directory Server コンソール を起動します。
- ディレクトリツリーを展開して、編集するエントリを表示します。
- 移動するエントリを選択します。
- エントリをドラッグし、新しく親となるエントリにドロップします。
- 警告ポップアップボックスで「継続」をクリックします。
コンソールによるエントリの名前変更と移動
エントリの名前を変更して移動するには、次の両手順を実行します。
ldapmodify コマンドによるエントリの名前変更または移動
この節では ldapmodify を使用したエントリの名前変更およびエントリの移動の方法について説明します。
LDIF 文で次の属性を使用します。
LDIF 文で使用される属性の詳細は、『Directory Server Administration Reference』の「Attribute Reference」を参照してください。ldapmodify コマンドの詳細は、『Directory Server Man Page Reference』を参照してください。
ldapmodify コマンドによる DN 変更操作の有効化
DN の変更操作を使用する前に、ACI 権限を拡張して、DN の変更操作を有効にする必要があります。
ACI 権限を拡張する方法の詳細は、「コマンド行からの ACI の作成」を参照してください。
この節では DN の変更操作を有効にする方法を説明します。
ldapmodify コマンドによるグローバルな DN 変更操作の有効化
ldapmodify コマンドを実行します。たとえば、次の例では DN の変更操作を有効にしています。
ldapmodify -h <hostname> -p <port> -D <user> -w <user_password>
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-moddn-enabled
nsslapd-moddn-enabled: onldapmodify コマンドによる特定のサフィックスに対する DN 変更操作の有効化
ldapmodify コマンドを実行します。たとえば、次の例では suffix-name と呼ばれるサフィックスに DN の変更操作を有効にしています。
ldapmodify -h <hostname> -p <port> -D <user> -w <user_password>
dn: cn=<suffix-name>,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-moddn-enabled
nsslapd-moddn-enabled: onldapmodify コマンドによるエントリの名前変更
この節ではエントリの名前を変更する方法を説明します。この操作は Directory Server 5.2 2005Q1 以前のバージョンの Directory Server でサポートされます。この操作を実行するには、DN の変更操作を有効にする必要がありません。
ldapmodify コマンドによりリーフエントリ名を変更するには、次の手順を実行します。
ldapmodify コマンドを実行します。たとえば、次の例ではエントリ john の名前が bob に変更されています。
ldapmodify -h <hostname> -p <port> -D <user> -w <user_password>
dn: cn=john,dc=california,dc=sun,dc=com
changetype: modrdn
newrdn: cn=bob
deleteoldrdn: 1ldapmodify コマンドによるエントリの移動
この節ではエントリをサフィックスの別の場所に移動する方法を説明します。この操作は Directory Server 5.2 2005Q1 以前のバージョンの Directory Server ではサポートされていません。
ldapmodify コマンドによりエントリを移動するには、次の手順を実行します。
- ACI 権限が、DN の変更操作について拡張されていることを確認します。詳細は、「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- DN の変更操作が、名前変更および移動操作で影響するサフィックスについて有効になっていることを確認します。詳細は、「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- ldapmodify コマンドを実行します。たとえば、次のコマンドはエントリ john を California のサブツリーから France のサブツリーに移動します。
ldapmodify -h <hostname> -p <port> -D <user> -w <user_password>
dn: cn=john,dc=california,dc=sun,dc=com
changetype: modrdn
newrdn: cn=john
deleteoldrdn: 0
newsuperior: dc=france,dc=france,dc=sun,dc=comldapmodify コマンドによるエントリの名前変更と移動
この節ではエントリの名前を変更し、サフィックスの別の場所に移動する方法を説明します。この操作は Directory Server 5.2 2005Q1 以前のバージョンの Directory Server ではサポートされていません。
ldapmodify コマンドによりエントリの名前を変更し移動するには、次の手順を実行します。
- ACI 権限が、DN の変更操作について拡張されていることを確認します。詳細は、「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- DN の変更操作が、名前変更および移動操作で影響するサフィックスについて有効になっていることを確認します。詳細は、「ldapmodify コマンドによる DN 変更操作の有効化」を参照してください。
- ldapmodify コマンドを実行します。たとえば、次のコマンドは名前変更操作と移動操作を 1 つの操作に結合します。
ldapmodify -h <hostname> -p <port> -D <user> -w <user_password>
dn: cn=john,dc=california,dc=sun,dc=com
changetype: modrdn
newrdn: dc=bob
deleteoldrdn: 1
newsuperior: dc=france,dc=france,dc=sun,dc=com
リフェラルの設定情報をローカルに取得できない場合に、どのサーバーに接続すべきかをクライアントアプリケーションに通知するには、リフェラルを使います。リフェラルとは、リモートサフィックスへのポインタ、つまり Directory Server が結果の代わりにクライアントへ返すエントリへのポインタです。クライアントは、リフェラルで指定されたリモートサーバー上で、再度、操作を実行する必要があります。このリダイレクションは、次の 3 つの場合に行われます。
- クライアントアプリケーションがローカルサーバーに存在しないエントリを要求し、サーバーがデフォルトのリフェラルを返す場合。
- サフィックス全体がメンテナンスまたはセキュリティ上の理由でオフラインになり、サーバーがサフィックスに定義されているリフェラルを返す場合。サフィックスレベルのリフェラルについては、「アクセス権とリフェラルの設定」を参照してください。クライアントが書き込み処理を要求する場合、サフィックスの読み取り専用レプリカも、マスターサーバーへのリフェラルを返します。
- スマートリフェラルと呼ばれるエントリを作成できる場合。クライアントが特にスマートリフェラルにアクセスした場合、サーバーはスマートリフェラルの代わりにそのサーバーが定義するリフェラルを返します。Directory Server コンソールはスマートリフェラルを自動的にたどるように設定できるため、「ディレクトリ」タブではスマートリフェラルが最上位のローカルエントリのように見えます。
いずれの場合も、リフェラルは LDAP URL であり、ホスト名、ポート番号、およびオプションとして別のサーバー上の DN を含みます。詳細は、『Directory Server Administration Reference』を参照してください。ディレクトリの配備でリフェラルを使用する方法の詳細は、『Directory Server 配備計画ガイド』を参照してください。
次に、ディレクトリのデフォルトリフェラルを定義する手順と、スマートリフェラルを定義する手順について説明します。
デフォルトリフェラルの設定
デフォルトリフェラルは、ディレクトリで管理されているサフィックスのどれにも含まれない DN に対して、操作を送信するクライアントアプリケーションに返されます。デフォルトリフェラルはディレクトリ内のすべてのサフィックスに適用されるため、グローバルリフェラルとも呼ばれます。サーバーは定義されているすべてのリフェラルを返しますが、返す順序は定義されていません。
コンソールからのデフォルトリフェラルの設定
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーのルートノードを選択し、右側のパネルで「ネットワーク」タブを選択します。
- 「返すリフェラル」チェックボックスを選択し、テキストフィールドに LDAP URL を入力します。あるいは、「相対 URL」をクリックして、指示に従って LDAP URL を定義します。次に、セキュリティ保護されているポートへの LDAP URL の例を示します。
ldaps://east.example.com:636/dc=example,dc=com
複数のリフェラル URL を入力するには、次のように空白で区切って、それぞれを引用符で囲みます。
"ldap://east.example.com:389" "ldap://backup.example.com:389"
- 「保存」をクリックして変更を保存します。変更は直ちに適用されます。
コマンド行からのデフォルトリフェラルの設定
ディレクトリ設定ファイルの cn=config エントリに 1 つまたは複数のデフォルトリフェラルを追加するか、交換するときは、ldapmodify コマンド行ユーティリティを使います。たとえば、次のようにします。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
dn: cn=config
changetype: modify
replace: nsslapd-referral
nsslapd-referral: ldap://east.example.com:389
nsslapd-referral: ldap://backup.example.com:389サーバーを再起動する必要はありません。
スマートリフェラルの作成
スマートリフェラルを使用して、ディレクトリエントリおよびディレクトリツリーを、特定の 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 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 エントリの代わりにスマートリフェラルを返すには、次のエントリを定義します。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w 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 host -p port -D "cn=Directory Manager" -w password
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: replace
replace: telephoneNumber
telephoneNumber: (408) 555-1234スマートリフェラルエントリを変更するには、たとえば次のように、ldapmodify の -M オプションを使う必要があります。
ldapmodify -M -h host -p port -D "cn=Directory Manager" -w 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
属性値の暗号化属性の暗号化はディレクトリに格納されている機密データを保護します。この機能を使用すると、エントリの特定の属性を暗号化された形式で格納するように指定できます。これにより、データベースファイル、バックアップファイル、およびエクスポートされた LDIF ファイルに格納されているデータが読み取られることを防ぎます。
この機能では、属性値は Directory Server データベースに格納される前に暗号化され、クライアントに返される前に元の値に復号化されます。クライアントと Directory Server との間でやり取りを行うときに、アクセス制御を使用してクライアントがこれらの属性に許可なくアクセスすることを防ぎ、SSL を使用して属性値を暗号化する必要があります。データセキュリティ全般のアーキテクチャ上の概要と、属性の暗号化の詳細は、『Directory Server 配備計画ガイド』を参照してください。
属性の暗号化は、サーバー上で 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 -w 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 は次のいずれかです。
- 属性が暗号化されないようにするには、ldapmodify コマンドを使用して次の設定エントリを変更します。
ldapmodify -h host -p port -D cn=Directory Manager -w password
dn: cn=attributeName, cn=encrypted attributes, cn=databaseName,
cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: dsEncryptionAlgorithm
dsEncryptionAlgorithm: clearTextここで、attributeName は暗号化する属性のタイプ名で、databaseName はサフィックスに対応するデータベースの識別名です。
- 1 つまたは複数の属性を暗号化するように設定を変更し、インポート処理の前にその属性が値を持っていた場合、暗号化されていない一部の値は、データベースキャッシュに判読可能な状態で残ることがあります。データベースキャッシュをクリアするには、次の手順を実行します。
- 「Directory Server の起動と停止」で説明している方法で、Directory Server を停止します。
- root または管理者権限を持つユーザーとして、ファイルシステムの次の場所にあるデータベースキャッシュファイルを削除します。
ServerRoot/slapd-serverID/db/__db.*
- Directory Server を再起動します。サーバーは、新しいデータベースキャッシュファイルを自動的に作成します。再びキャッシュがいっぱいになるまで、このサフィックスでの操作のパフォーマンスは、若干の影響を受ける可能性があります。
- 「データのインポート」で説明する方法で、LDIF ファイルを使用してサフィックスを初期化します。
このファイルが読み込まれ、対応するインデックスが作成されるときに、指定した属性の値はすべて暗号化されます。
参照整合性の管理参照整合性は、関連するエントリ間の関係を保持するプラグインメカニズムです。グループのメンバーシップなど、一部のタイプの属性には別のエントリの DN が含まれています。参照整合性を利用することで、エントリを削除したときに、そのエントリの DN を含むすべての属性も削除できます。
たとえば、参照整合性が有効になっているときに、あるユーザーのエントリがディレクトリから削除されると、そのユーザーは、所属しているあらゆるグループからも削除されます。参照整合性が無効な状態では、管理者はグループからユーザーを手動で削除する必要があります。Directory Serverと、ユーザーとグループの管理をディレクトリに頼っているその他の Sun Java System 製品を統合する場合には、この機能がとても重要です。
参照整合性のしくみ
参照整合性プラグインが有効になっているときに削除操作や名前変更、または移動の操作を実行すると、指定された属性に対する整合性更新がただちに実行されます。ただし、デフォルトでは、参照整合性検査プラグインは無効になっています。
ディレクトリ内にあるユーザーエントリまたはグループエントリの削除や名前変更、または移動のたびに、その操作が次の参照整合性ログファイルに記録されます。
ServerRoot/slapd-serverID/logs/referint
更新間隔と呼ばれる指定した時間が経過すると、参照整合性が有効になっているすべての属性が検索され、検索結果のエントリと、ログファイル内に記録された削除または変更されたエントリの DN が照合されます。特定のエントリが削除されたことがログファイルに記録されている場合は、対応する属性が削除されます。特定のエントリが変更されたことがログファイルに記録されている場合は、対応する属性値が記録に従って変更されます。
参照整合性プラグインのデフォルトの設定が有効な場合は、削除操作や名前変更、または移動の操作を実行すると、member、uniquemember、owner、seeAlso、および nsroledn の各属性に対する整合性更新がただちに実行されます。ただし、参照整合性検査プラグインの動作は、次のような用途に合わせてユーザーが自由に設定できます。
参照整合性の設定
Directory Server コンソールから参照整合性を有効化または無効化したり、プラグインを設定するときは、次の手順を実行します。
注
参照整合性プラグインで使用される全データベースのすべての属性に、インデックスを設定する必要があります。インデックスはすべてのデータベースの設定内で作成する必要があります。旧バージョン形式の更新履歴ログが有効になっている場合、cn=changelog サフィックスにインデックスを設定する必要があります。詳細は、第 10 章「ディレクトリデータのインデックス作成」を参照してください。
コンソールからの参照整合性の設定
- Directory Server コンソールの最上位の「設定」タブで「プラグイン」ノードを展開し、「referential integrity postoperation」プラグインを選択します。
プラグインの設定が右側のパネルに表示されます。
- プラグインを有効にする場合は、「プラグインを有効に」チェックボックスを選択します。プラグインを無効にする場合は、このチェックボックスの選択を解除します。
- 更新間隔を秒単位で変更するときは、「引数 1」に値を設定します。一般的な値は次のとおりです。
- 使用する参照整合性ログファイルのパスを「引数 2」に設定します。
「引数 3」は使用されませんが、表示されている必要があります。
- 参照整合性が監視される属性は、「引数 4」の最初にリスト表示されます。このリストの管理、および独自の属性の追加には、「追加」ボタンと「削除」ボタンを使います。
- 「保存」をクリックして、変更内容を保存します。
- 変更を適用するには、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"
この行を次のように変更します。
plugin postoperation on "referential integrity postoperation" "ServerRoot/lib/referint-plugin.dll" referint_postop_init 0 "ServerRoot/slapd-serverID/logs/referint" 1 "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 (通常は識別名) とパスワードによってサーバーへの接続を開き、検索フィルタに基づいてエントリを検出します。検索範囲には、単一のエントリ、エントリの直接のサブエントリ、またはエントリツリーやサブツリーを含むことができます。
検索結果は LDIF 形式で返されます。
ldapsearch コマンド行の形式
ldapsearch を使用する場合は、次の形式を使用してコマンドを入力する必要があります。
ldapsearch [optional_options] [search_filter] [optional_list_of_attributes]
各オプションは、次のように指定します。
- optional_options は、一連のコマンド行オプションを表しています。検索フィルタが存在する場合は、検索フィルタより前に指定する必要があります。
- search_filter は、「LDAP 検索フィルタ」で説明するように、LDAP 検索フィルタを表しています。-f オプションを使用してファイル内で検索フィルタを指定していない場合は、検索フィルタを指定する必要があります。
- optional_list_of_attributes は、空白で区切られた属性のリストを表しています。属性のリストを指定すると、検索結果で返される属性の数が減少します。この属性のリストは、必ず検索フィルタの後に表示されます。「属性のサブセットの表示」に示されている例を参照してください。属性のリストを指定しない場合は、ディレクトリ内に設定されたアクセス制御によって許可されたすべての属性 (オペレーショナル属性を除く) の値が検索によって返されます。
特殊文字の使い方
ldapsearch コマンド行ユーティリティを使用する場合に、コマンド行インタープリタにとって特別な意味を持つ文字 (空白 ( )、アスタリスク (*)、円記号 (¥) など) を含む値を指定が必要になることがあります。特殊文字を指定する場合は、その値を引用符 ("") で囲みます。たとえば、次のようにします。
-D "cn=Charlene Daniels,ou=People,dc=example,dc=com"
一重引用符または二重引用符のどちらを使用するかは、コマンド行インタープリタのタイプによって異なります。詳細は、シェルのマニュアルを参照してください。
一般に使用される 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』を参照してください。
たとえば、-l 300 のように指定します。nsslapd-timelimit 属性のデフォルト値は、3,600 秒 (1 時間) です。
-p
Directory Server が使用する TCP のポート番号を指定します。たとえば、-p 5201 のように指定します。デフォルト値は 389 で、SSL オプションが使用されている場合は 636 になります。
-s
検索範囲を指定します。次のいずれかの範囲です。
-w
-D オプションで指定された識別名に関連付けられたパスワードを指定します。このオプションを指定しない場合は、匿名アクセスが使用されます。たとえば、-w diner892 のように指定します。
-x
検索結果が、クライアント上ではなくサーバー上でソートされるように指定します。国際的な検索などのように、マッチングルールに従ってソートする場合に便利です。一般的に、クライアント上よりサーバー上でソートした方が高速ですが、サーバー側のソートはサーバーのリソースを消費します。
-z
検索要求に対して返す最大エントリ数を指定します。たとえば、-z 1000 のようになります。
通常、ここで指定した値にかかわらず、サーバーの nsslapd-sizelimit 属性によって許可された数を超えるエントリが ldapsearch によって返されることはありません。ただし、このコマンド行引数を使用するときにルート DN としてバインドすることで、この制約を無効にできます。ルート DN としてバインドする場合、このオプションのデフォルト値はゼロ (0) になります。nsslapd-sizelimit 属性のデフォルト値は 2,000 エントリです。
ldapsearch ユーティリティオプションの詳細は、『Directory Server Resource Kit Tools Reference』を参照してください。
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=*)"
注
厳密に準拠する場合は、指定されたエントリのスキーマサブエントリの場所は、subschemaSubentry オペレーショナル属性によって指定されます。このバージョンの Directory Server では、この属性の値は常に cn=schema です。
LDAP_BASEDN の使用
検索を簡単に行うために、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』を参照してください。
検索結果で返された属性のすべてを表示するわけではない場合を考えてみます。返された属性をいくつかの特定の属性に制限するには、検索フィルタのすぐ後のコマンド行で表示する属性を指定します。たとえば、ディレクトリのすべてのエントリについて 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 の検索を指定しています。
(cn=Lucie Du Bois)
この検索フィルタでは、共通名 Lucie Du Bois を含むすべてのエントリが返されます。共通名の値の検索では、大文字と小文字は区別されません。
共通名属性に言語タグに関連付けられた値が存在する場合は、すべての値が返されます。したがって、次の 2 つの属性値はどちらもこのフィルタに一致します。
cn: Lucie Du Bois
cn;lang-fr: Lucie Du Bois
検索フィルタの構文
検索フィルタの基本構文は次のとおりです。
(attribute operator value)
たとえば、次のようにします。
(buildingname>=alpha)
この例では、buildingname は属性、>= は演算子、および alpha は値です。ブール演算子によって異なる属性を組み合わせて使用するようにフィルタを定義することもできます。
検索フィルタについては、次の節を参照してください。
検索フィルタでの属性の使用
エントリを検索するときに、そのエントリのタイプに関連付けられた属性を指定することができます。たとえば、人のエントリを検索する場合は、cn 属性を使用して特定の共通名を持つ人を検索することができます。
人のエントリが含まれる属性の例には次のようなものが挙げられます。
エントリのタイプに関連付けられた属性のリストについては、『Directory Server Administration Reference』を参照してください。
検索フィルタでの演算子の使用
表 2-2 は、検索フィルタで使用できる演算子を一覧表示したものです。
dn 属性に対する検索機能を拡張し (たとえば cn:dn:=John)、国際的な検索をサポートするために拡張された演算子も存在します。
検索フィルタでの OID の使用
LDAPv3 を使用すると、特定の属性に対してマッチ演算子とマッチングルールを構築することができます。マッチングルールは属性の値を特定の構文と比較する方法を定義しています。すなわち、マッチングルールとは一致する可能性のある属性を比較する方法を定義したものです。たとえば、属性を比較するときにテキストの大文字小文字を考慮するかどうかを定義するマッチングルールがあります。
規則を作成すると、検索フィルタで参照されます。
たとえば、次の検索フィルタは OID 2.5.13.5 で指定されるマッチングルールを使用して、姓「Jensen」を含むエントリを比較します。
(sn:2.5.13.5:=Jensen)
次の例では、比較する場合に OID 2.5.13.5 を使用することと、一致を評価する場合にエントリの識別名の属性をエントリの一部として考慮することを指定するために「:dn」表記を使用しています。
(sn:dn:2.5.13.5:=Jensen)
合成検索フィルタの使用
プレフィックス表記内で次のように表現されるブール演算子を使用して、複数の検索フィルタコンポーネントを組み合わせることができます。
(Boolean-operator(filter)(filter)(filter)...)
この Boolean-operator は、表 2-3 に一覧表示されているブール演算子のいずれかになります。
ブール演算子を組み合わせ、相互に入れ子にすることで、次のような複雑な式を作成できます。
(Boolean-operator(filter)(Boolean-operator(filter)(filter)))
検索フィルタで使用できるブール演算子には、次のようなものがあります。
ブール式は、次の順序で評価されます。
ファイルを使用した検索フィルタの指定
検索フィルタは、コマンド行ではなく、ファイルに入力することができます。この場合、各検索フィルタをファイル内の個別の行に指定します。ldapsearch コマンドは、ファイル内に現れる順序で各検索を実行します。
たとえば、ファイルに次の行が含まれているとします。
(sn=Daniels)
(givenname=Charlene)この場合、ldapsearch は最初に Daniels という姓を持つすべてのエントリを検索し、次に Charlene という名を持つすべてのエントリを検索します。両方の検索条件に一致するエントリが見つかったら、そのエントリは 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検索フィルタの 7 ビット以外の ASCII 文字の指定
検索フィルタの 7 ビット以外の ASCII 文字は、文字表現で置き換える必要があります。UTF-8 エンコードの各バイトの前に円記号が入ります。UTF-8 では、文字は各バイトに対して 16 進コードで表現されます。
たとえば、文字 é を UTF-8 で表現すると c3a9 になります。この場合、検索フィルタでは é を ¥c3¥a9 と指定します。したがって、cn=Véronique Martin を検索するには、次のように指定します。
ldapsearch -h myServer -b "dc=example,dc=com" "(cn=V¥c3¥a9ronique Martin)"
表 2-4 の特殊文字は、検索フィルタで使用された場合、次の方法で表現する必要があります。
表 2-4 検索フィルタの特殊文字
特殊文字
特殊文字を使用した値
フィルタ例
*
Five*Star
(cn=Five¥2aStar)
¥
c:¥File
(cn=¥5cFile)
()
John (2nd)
(cn=John ¥282nd¥29)
null
0004
(bin=¥00¥00¥00¥04)
検索フィルタ内の識別名のエスケープ文字
Directory Server の任意の箇所で DN を使用する場合、コンマとその他の特定の特殊文字は円記号 (¥) でエスケープする必要があります。検索フィルタで DN を使用する場合、DN 内の特殊文字をエスケープするための円記号 (¥) は ¥5c と表します。たとえば、次のようにします。
DN: cn=Julie Fulmer,ou=Marketing¥,Bolivia,dc=example,dc=com
検索フィルタの DN: ldapsearch -h myServer -b "dc=example,dc=com" "(manager=cn=Julie Fulmer,ou=Marketing¥5c,Bolivia,dc=example,dc=com)"
検索フィルタの例
次のフィルタでは、manager 属性について 1 つ以上の値を含むエントリを検索します。これは実在検索とも呼ばれるものです。
(manager=*)
次のフィルタでは、共通名 Ray Kultgen を含むエントリを検索します。これは等価検索とも呼ばれるものです。
(cn=Ray Kultgen)
次のフィルタでは、部分文字列 X.500 を含む description 属性を含むすべてのエントリが返されます。
(description=*X.500*)
次のフィルタでは、組織単位が Marketing で、説明フィールドに部分文字列 X.500 を含まないすべてのエントリが返されます。
(&(ou=Marketing)(!(description=*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)))次のフィルタでは、人を表さないすべてのエントリが返されます。
(!(objectClass=person))
上記のフィルタは、パフォーマンスに悪影響を及ぼすので、複雑な検索の一部として使用します。次のフィルタでは、人を表さないもので、共通名が printer3b と近似しているすべてのエントリが返されます。
(&(cn~=printer3b)(!(objectClass=person)))
オペレーショナル属性の検索
検索操作の結果としてオペレーショナル属性を返すようにする場合は、検索コマンド内でこれらを明示的に指定する必要があります。
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 *
国際化ディレクトリの検索検索操作を実行する場合、サーバーでサポートされる照合順序の言語に基づいた、ディレクトリ内での結果のソートを要求することができます。ディレクトリでサポートされる照合順序のリストについては、『Directory Server Administration Reference』を参照してください。
この節では ldapsearch 構文のマッチングルールのフィルタ部分を中心に説明します。一般的な ldapsearch 構文の詳細は、「LDAP 検索フィルタ」を参照してください。Directory Server コンソールのユーザーおよびグループ部分を使用した、国際化されたディレクトリの検索の詳細は、オンラインヘルプか『Administration Server Administration Guide』を参照してください。
この節では次の項目を扱います。
マッチングルールのフィルタ構文
マッチングルールは、検索操作の間にディレクトリで文字列が比較される方式についての特別なガイドラインとして機能します。国際的な検索では、検索操作の実行時に使用する照合順序と演算子の種類が、マッチングルールによりシステムに伝えられます。マッチングルールのフィルタの構文は次のとおりです。
attr:matchingRule:=value
各オプションは、次のように指定します。
- attr は cn や mail など、検索するエントリに属する属性です。
- matchingRule は、優先する形式により照合順序か照合順序と関係演算子のいずれかを特定する文字列です。マッチングルールの形式の詳細は、「マッチングルールの形式」を参照してください。
- value は検索する属性値か、検索する関係演算子と属性値のいずれかになります。フィルタの値部分の構文は、使用するマッチングルールの形式により異なります。
マッチングルールの形式
検索フィルタのマッチングルール部分は、次のように表されます。
これらのオプションの構文については、次の節で説明しています。
マッチングルールへの OID の使用
Directory Server でサポートされる各ロケールには、照合順序の OID が関連付けられています。サポートされるロケールとそれぞれの関連 OID のリストは、『Directory Server Administration Reference』を参照してください。
マッチングルールフィルタのマッチングルール部分で、照合順序の OID を次のように使用します。
attr:OID:=(relational_operator value)
関係演算子は、文字列の値の部分に指定されます。このとき、関係演算子と値の間に空白文字を 1 つ入れて区切ります。たとえば、スウェーデン語の照合順序で N4709 またはこのあとにあるすべての departmentNumber 属性を検索する場合は、次のフィルタを使用します。
departmentNumber:1.3.6.1.4.1.42.2.27.9.4.129.1:=>= N4709
マッチングルールへの言語タグの使用
Directory Server でサポートされる各ロケールには、言語タグが関連付けられています。サポートされるロケールとそれぞれに関連する言語タグのリストは、『Directory Server Administration Reference』を参照してください。
マッチングルールフィルタのマッチングルール部分で、言語タグを次のように使用します。
attr:language-tag:=(relational_operator value)
関係演算子は、文字列の値の部分に指定されます。このとき、関係演算子と値の間に空白文字を 1 つ入れて区切ります。たとえば、スペイン語の照合順序を使用して値 estudiante を持つすべての記述属性をディレクトリで検索するには、次のフィルタを使用します。
description:es:== estudiante
マッチングルールへの OID とサフィックスの使用
関係演算子と値のペアを使用する代わりに、フィルタのマッチングルール部分の OID に特定の演算子を表すサフィックスを追加できます。OID とサフィックスを次のように結合します。
attr:OID+suffix:=value
たとえば、ドイツ語の照合順序で値 Softwareprodukteを持つ businessCategory 属性を検索する場合、次のフィルタを使用します。
businessCategory:1.3.6.1.4.1.42.2.27.9.4.28.1.3:=Softwareprodukte
前述の例の .3 は、等号サフィックスです。
マッチングルールへの言語タグとサフィックスの使用
関係演算子と値のペアを使用する代わりに、フィルタのマッチングルール部分の言語タグに特定の演算子を表すサフィックスを追加できます。言語タグとサフィックスを次のように結合します。
attr:language-tag+suffix:=value
たとえば、フランス語の照合順序で La Salle またはこのあとにあるすべての姓を検索する場合は、次のフィルタを使用します。
sn:fr.4:=La Salle
マッチングルールフィルタのワイルドカードの使用
マッチングルールのフィルタを使用して部分文字列の検索を実行する場合、アスタリスク (*) をワイルドカードとして使用して 0 以上の文字を表すことができます。
たとえば、文字 k から始まり文字 n で終わる属性値を検索する場合、検索フィルタの値部分に k*n と入力します。同様に、文字 u で始まるすべての属性値を検索するには、検索フィルタの値部分に値 u* を入力します。
アスタリスク (*) 文字を含む値を検索するには、アスタリスク文字をエスケープする必要があります。
サポートされる検索の種類
ディレクトリサーバーは、次の種類の国際的な検索をサポートします。
近似検索、音声検索、および実在検索は、英語でのみサポートされます。
通常の ldapsearch を使用した検索操作と同様に、国際的な検索も演算子を使用して検索の種類を定義します。ただし、国際的な検索を呼び出す場合、標準演算子 (=、>=、>、<、<=) を検索文字列の値部分で使用するか、フィルタのマッチングルール部分でサフィックス (ディレクトリのサフィックスと混合しないこと) と呼ばれる特殊な種類の演算子を使用します。表 2-5 に検索、演算子、等価サフィックスの種類をまとめています。
表 2-5 検索の種類、演算子、サフィックス
検索のタイプ
演算子
サフィックス
小なり
<
.1
小さいまたは等しい
<=
.2
等価
=
.3
大きいまたは等しい
>=
.4
大なり
>
.5
部分文字列
*
.6
国際的な検索の例
次の節では、ディレクトリデータで国際的な検索を実行する方法の例を示しています。予測されるすべてのマッチングルールフィルタの形式が例ごとに示されているため、形式に慣れることができ、最も使いやすい形式を選択できます。
小なりの例
小なり演算子 (<) またはサフィックス (.1) を使用してロケール別の検索を実行する場合、指定された属性の前にあるすべての属性の値を個々の照合順序で検索します。
たとえば、スペイン語の照合順序で Marquez という姓の前にあるすべての姓を検索するには、次のマッチングルールフィルタのいずれかを使用します。
sn:1.3.6.1.4.1.42.2.27.9.4.49.1:=< Marquez
sn:es:=< Marquez
sn:1.3.6.1.4.1.42.2.27.9.4.49.1.1:=Marquez
sn:es.1:=Marquez小さいまたは等しいの例
小さいまたは等しい演算子 (<=) またはサフィックス (.2) を使用してロケール別の検索を実行する場合、指定された属性またはこのあとにあるすべての属性の値を個々の照合順序で検索します。
たとえば、ハンガリー語の照合順序で CZ422 というルーム番号またはこの前にあるすべてのルーム番号を検索するには、次のマッチングルールフィルタのいずれかを使用します。
roomNumber:1.3.6.1.4.1.42.2.27.9.4.88.1:=<= CZ422
roomNumber:hu:=<= CZ422
roomNumber:1.3.6.1.4.1.42.2.27.9.4.88.1.2:=CZ422
roomNumber:hu.2:=CZ422等価の例
等価演算子 (=) またはサフィックス (.3) を使用してロケール別の検索を実行する場合、指定された属性に一致するすべての属性の値を個々の照合順序で検索します。
たとえは、ドイツ語の照合順序で値 Softwareprodukteを持つ businessCategory 属性を検索する場合、次のマッチングルールフィルタのいずれかを使用します。
businessCategory:1.3.6.1.4.1.42.2.27.9.4.28.1:== Softwareprodukte
businessCategory:de:== Softwareprodukte
businessCategory:1.3.6.1.4.1.42.2.27.9.4.28.1.3:=Softwareprodukte
businessCategory:de.3:=Softwareprodukte大きいまたは等しいの例
大きいまたは等しい演算子 (>=) またはサフィックス (.4) を使用してロケール別の検索を実行する場合、指定された属性またはこのあとにあるすべての属性の値を個々の照合順序で検索します。
たとえば、フランス語の照合順序で Québec またはこのあとにあるすべての地域を検索するには、次のマッチングルールフィルタのいずれかを使用します。
locality:1.3.6.1.4.1.42.2.27.9.4.76.1:=>= Québec
locality:fr:=>= Québec
locality:1.3.6.1.4.1.42.2.27.9.4.76.1.4:=Québec
locality:fr.4:=Québec大なりの例
大なり演算子 (>) またはサフィックス (.5) を使用してロケール別の検索を実行する場合、指定された属性またはこのあとにあるすべての属性の値を個々の照合順序で検索します。
たとえば、チェコ語の照合順序で、ホスト schranka4 またはこのあとにあるすべてのメールホストを検索するには、次のマッチングルールフィルタのいずれかを使用します。
mailHost:1.3.6.1.4.1.42.2.27.9.4.26.1 :=> schranka4
mailHost:cs:=> schranka4
mailHost:1.3.6.1.4.1.42.2.27.9.4.26.1.5:=schranka4
mailHost:cs.5:=schranka4部分文字列の例
国際的な部分文字列検索を実行する場合、特定のパターンに一致するすべての値を、指定された照合順序で検索します。
たとえば、中国語の照合順序で、ming で終わるすべてのユーザー ID を検索するには、次のマッチングルールフィルタのいずれかを使用します。
uid:1.3.6.1.4.1.42.2.27.9.4.143.1:=* *ming
uid:zh:=* *ming
uid:1.3.6.1.4.1.42.2.27.9.4.143.1.6:=*ming
uid:zh.6:=*ming
DSMLv2 を使用したディレクトリへのアクセス次の例は、DSML 要求を使用してディレクトリにアクセスして検索する方法を示しています。DSML 関連の属性のリストと、DSMLv2 規格の詳細は、『Directory Server Administration Reference』を参照してください。
この節は、次の例で構成されています。
これらの例の content-length: ヘッダーには、DSMLv2 要求の正確な長さが指定されています。これらの例が正常に機能するためには、このコンテンツ長を正しく理解するエディタを使用するか、必要に応じて値を手動で変更する必要があります。
空の匿名 DSML Ping 要求
DSML フロントエンドは、デフォルトでは無効化されています。有効化する方法については、「DSML 要求の有効化」を参照してください。DSML フロントエンドが有効であるかを確認するには、コード例 2-1 で示すように、空の 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 要求の残りの詳細を指定します。
- content-length: 451
SOAP/DSML 要求の正確な長さを指定します。- HOST: hostMachine
Directory Server が接続するホストの名前を指定します。- SOAPAction:
必須ヘッダーです。これは、HTTP/SOAP スタックでの DSML 要求の実行をディレクトリに知らせます。ただし、このヘッダーは空のまま残すことができます。- Content-Type: text/xml
値として text/xml を持つ必要があります。これは、コンテンツが XML であることを定義します。- Connection: close
要求が成功した場合に接続を閉じることを指定します。デフォルトの HTTP/1.1 の動作では、接続は開いた状態で維持されます。残りの要求は SOAP/DSML セクションです。DSML 要求は、次の XML 序言ヘッダーから始まります。
<?xml version=.0encoding=俵TF-8>
これは、要求が UTF-8 文字セットで符号化される必要があることを示しています。ヘッダーの後には SOAP エンベロープと、必須の XML スキーマ、XML スキーマインスタンス、SOAP ネームスペースを含む本文要素が続きます。
DSML バッチ要求要素は DSML バッチ要求の開始を示し、直後に必須 DSMLv2 ネームスペースを含める要素が続きます。
xmlns='urn:oasis:names:tc:DSML:2:0:core'.
オプションとして、この要求を次の要求 ID によって指定します。
requestID='Ping!'>
空のバッチ要求
<!-- empty batch request -->
は、このようにコメントアウトされた XML です。SOAP/DSML バッチ要求は、バッチ要求の終了、SOAP 本文の終了、SOAP エンベロープ要素の終了によって閉じられます。
DSML フロントエンドが有効であれば、コード例 2-2 に示すように、空の DSML 応答が返されます。
コード例 2-2 空の匿名 DSML 応答
HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Mon, 09 Sep 2002 13:56:49 GMT
Accept-Ranges: none
Server: Sun-ONE-Directory/5.2
Content-Type: text/xml; charset="utf-8"
Content-Length: 500
<?xml version=.0encoding=俵TF-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>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
requestID='Ping!'
>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>
何も返されない場合は、フロントエンドが無効であることがわかります。
ディレクトリに同時に接続できるクライアント数と、DSML 要求のサイズには、最大制限が適用されます。クライアント数の制限は ds-dsml-poolsize 属性と ds-dsml-poolmaxsize 属性によって指定され、要求サイズの制限は ds-dsml-requestmaxsize 属性によって指定されます。DMSL 関連の属性の詳細は、『Directory Server Administration Reference』を参照してください。
特定ユーザーとしてバインドする DSML 要求の発行
DSML 要求を発行するために、特定のユーザーまたは匿名ユーザーとしてディレクトリにバインドできます。特定ユーザーとしてバインドするには、コード例 2-3 に示すように、DN にマッピングされる UID とパスワードを含む HTTP 承認ヘッダーを要求に含める必要があります。
コード例 2-3 DSML の拡張操作: 特定ユーザーとしてのバインド
POST /dsml HTTP/1.1
content-length: 578
Content-Type: text/xml; charset="utf-8"
HOST: hostMachine
Authorization: Basic ZWFzdGVyOmVnZw==
SOAPAction: ""
Connection: close
<?xml version=.0encoding=俵TF-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'>
<extendedRequest>
<requestName>1.3.6.1.4.1.4203.1.11.3</requestName>
</extendedRequest>
</batchRequest>
</soap-env:Body>
</soap-env:Envelope>
この例では、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 拡張処理が識別されます。
DSML 拡張操作への応答から、バインド要求を行ったユーザーの DN が示されます。コード例 2-4 では、行に whoami 応答 (DN を含む) が示されています。<response>dn:uid=easter,ou=people,dc=france,dc=sun,dc=com</response>
whoami 拡張処理については、http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authzid-08.txt を参照してください。
コード例 2-4 DSML 拡張操作への応答
HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Fri, 30 Jul 2004 09:15:09 GMT
Accept-Ranges: none
Server: Sun-ONE-Directory/5.2
Content-Type: text/xml; charset="utf-8"
Content-Length: 697
<?xml version=.0encoding=俵TF-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>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
>
<extendedResponse>
<resultCode code=descr=不uccess>
<responseName>1.3.6.1.4.1.4203.1.11.3</responseName>
<response>dn:uid=easter,ou=people,dc=france,dc=sun,dc=com</respo nse>
</extendedResponse>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>
匿名アクセスを行うために HTTP 承認ヘッダーは必要ありません。ただし多くの場合、匿名アクセスは厳密なアクセス制御の対象となり、データアクセスが制約される可能性が高いことに注意してください。同様に、LDAP プロキシとして LDAP 操作を実行する DSML 要求を発行することもできます。
DSML 要求はバッチベースで管理されるため、LDAP プロキシによって要求を発行する場合、発行に必要な DSML プロキシ承認要求を、指定の要求バッチの先頭に配置する必要があります。
DSML 検索要求
コード例 2-5 は、ルート DSE エントリに対して実行される DSML ベースのオブジェクト検索要求を示しています。
コード例 2-5 DSML 検索要求
POST /dsml HTTP/1.1
HOST: hostMachine
Content-Length: 1081
Content-Type: text/xml
SOAPAction: ""
Connection: close
<?xml version=.0encoding=俵TF-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>
この例では、次のような指定が行われています。
- dn=""
requestID="search on Root DSE"
検索操作が、ルート DSE エントリ (空の DN) の下にあるデータを要求し、オプションの request ID 属性によって特定されるように指定しています。- scope="baseObject"
検索がベースオブジェクト検索であることを指定しています。- derefAliases="neverDerefAliases"
ベースオブジェクトの検索または特定時に、エイリアスが間接参照されないことを指定しています。Directory Server がサポートするのは、この derefAliases 値だけです。- typesOnly="false"
属性名とその値の両方が返されることを指定しています。typesOnly="true" と指定すると、属性名のみが返されます。この属性のデフォルト値は false です。適用するフィルタには、オブジェクトクラスフィルタが次のように使用されます。
<filter>
<present name="objectClass"/>
</filter>これは、LDAP フィルタ文字列 (objectclass=*) と同じです。このフィルタの後には、目的の属性のリストが続きます。
<属性>
<attribute name="namingContexts"/>
<attribute name="supportedLDAPversion"/>
<attribute name="vendorName"/>
<attribute name="vendorVersion"/>
<attribute name="supportedSASLMechanisms"/>
</attributes>DSML の検索応答の例をコード例 2-6 に示します。
コード例 2-6 DSML 検索応答
HTTP/1.1 200 OK
Cache-control: no-cache
Connection: close
Date: Fri, 30 Jul 2004 09:21:43 GMT
Accept-Ranges: none
Server: Sun-ONE-Directory/5.2
Content-Type: text/xml; charset="utf-8"
Content-Length: 1287
<?xml version=.0encoding=俵TF-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>
<batchResponse
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='urn:oasis:names:tc:DSML:2:0:core'
requestID='Batch of search requests'
>
<searchResponse requestID=不earch on Root DSEgt;
<searchResultEntry>
<attr name=貧amingContextsgt;
<value>dc=france,dc=sun,dc=com</value>
<value>o=NetscapeRoot</value>
</attr>
<attr name=不upportedLDAPVersiongt;
<value>2</value>
<value>3</value>
</attr>
<attr name=夫endorNamegt;
<value>Sun Microsystems, Inc.</value>
</attr>
<attr name=夫endorVersiongt;
<value>Sun-ONE-Directory/5.2</value>
</attr>
<attr name=不upportedSASLMechanismsgt;
<value>EXTERNAL</value>
<value>GSSAPI</value>
<value>DIGEST-MD5</value>
</attr>
</searchResultEntry>
<searchResultDone>
<resultCode code=descr=不uccess>
</searchResultDone>
</searchResponse>
</batchResponse>
</soap-env:Body>
</soap-env:Envelope>