| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
Directory ServerはLDAP Data Interchange Format (LDIF)を使用して、ディレクトリおよびそのエントリをテキスト形式で記述します。LDIFを使用して、初期ディレクトリ・データベースを構築したり、ディレクトリに多数のエントリを追加することができます。またLDIFを使用して、ディレクトリ・エントリへの変更を記述することもできます。多くのコマンドライン・ユーティリティは、入力または出力についてはLDIFに基づいています。
すべてのディレクトリ・データはユニコードのUTF-8エンコーディングを使用することによって格納され、したがってLDIFファイルはUTF-8でエンコードされる必要があります。
この章では、ディレクトリの検索およびLDAP検索フィルタについても説明します。
LDIFおよびディレクトリの検索の詳細は、次の項を参照してください。
LDIFファイルは、空白行によって区切られた1つ以上のディレクトリ・エントリから構成されます。各LDIFエントリは、次の部分から構成されています。
エントリID(オプション)
識別名(必須)
1つ以上のオブジェクト・クラス
複数の属性定義
LDIF形式は、RFC 2849で定義されています。
次の例は、LDIFの基本的なディレクトリ・エントリを示しています。
例4-1 LDIFのディレクトリ・エントリ
dn: distinguished_name objectClass: object_class objectClass: object_class ... attribute_type[;subtype]: attribute_value attribute_type[;subtype]: attribute_value ...
他のすべての属性およびオブジェクト・クラスは、オプションです。オブジェクト・クラスおよび属性は、任意の順序に指定できます。コロンの後ろのスペースは、任意です。
次の表では、LDIFファイルのフィールドについて説明します。
表4-1 LDIFのフィールド
| フィールド | 定義 |
|---|---|
|
[id] |
オプション。エントリIDを示す、正の10進数。データベース作成ツールによって、このIDが生成されます。この値を、ユーザー自身で追加または編集しないでください。 |
|
エントリの識別名。 |
|
|
このエントリで使用するオブジェクト・クラス。このオブジェクト・クラスは、エントリについて許可され、必要である属性またはスキーマのタイプを識別します。 |
|
|
エントリで使用される記述属性。この属性は、スキーマで定義されます。 |
|
|
[subtype] |
オプション。次のタイプの1つのサブタイプ。
|
|
属性タイプとともに使用される属性値。 |
ディレクトリ内のエントリに対する変更を示すLDIF構文は、前述の構文とは異なります。
LDIFを指定すると、改行および行の継続、または1スペースによって行の継続位置をインデントすることによって行を折り返すことができます。たとえば、次の2つの文は同一です。
dn: cn=Babs Jensen,dc=example,dc=com dn: cn=Babs J ensen,dc=exam ple,dc=com
LDIF行の改行および継続は必須ではありません。ただし、LDIFファイルが読みやすくなります。
次の方法のいずれかを使用して、LDIFにおけるバイナリ・データを表すことができます。
標準LDIF表記で、より小さいの意の、<記号
コマンドライン・ユーティリティでldapmodify (-bオプションあり)
Base 64エンコード
次の例では、バイナリ・データについての標準のLDIF表記が示されています。
jpegphoto:< file:/path/to/photo
この例ではパスは、サーバーではなくクライアントに関連しています。標準の表記を使用するには、ldapmodify -bパラメータを指定する必要はありません。ただし、次の行をLDIFファイルの最初またはLDIFのUPDATE文に追加する必要があります。
version:1
たとえば次のように、ldapmodifyコマンドを使用できます。
$ ldapmodify -D userDN -w passwd version: 1 dn: cn=Barbara Jensen,ou=People,dc=example,dc=com changetype: modify add: userCertificate userCertificate;binary:< file:BabsCert
ldapmodify -bコマンドを使用したバイナリ・データの表現Directory Serverの以前のバージョンとの下位互換性については、ldapmodify -bコマンドを使用して、バイナリ・データを表現できます。ただし可能な場合は、標準のLDIF表記を使用してバイナリ・データを表現します。
Directory Serverは、-bパラメータのあるldapmodifyコマンドおよび次のLDIF表記を受け入れます。
jpegphoto: /path/to/photo
この表記は、属性値がスラッシュで始まる場合に、ldapmodifyコマンドがバイナリ値に関する参照ファイルを読み取る必要があることを示しています。
Base 64でエンコードされたデータは、この例で示されているように::記号で表現されます。
jpegPhoto:: encoded_data
バイナリ・データに加えて、次の値もBase 64でエンコードされている必要があります。
セミコロン;で始まるすべての値、またはスペース
ASCII以外のデータを含むすべての値(新規行を含む)
次のように、-bパラメータのあるldifコマンドを使用して、バイナリ・データをLDIF形式に変換します。
$ ldif -b attributeName
ldifコマンドの使用方法の詳細は、ldifについての説明のマニュアル・ページを参照してください。
前述の例においてattributeNameは、ユーザーがバイナリ・データを提供する属性名です。バイナリ・データは標準入力から読み込まれ、この結果は標準出力に書き込まれます。リダイレクト演算子を使用して、入力および出力ファイルを選択します。
このコマンドによって、あらゆる入力が取得され、正しい行の継続および適切な属性情報が書式設定されます。このコマンドによって、入力にBase 64エンコードが必要がどうかも判断されます。次の例では、jpegPhotoと命名された属性について、JPEGイメージを含むバイナリ・ファイルを取得してLDIF形式に変換します。この出力はout.ldifに保存されます。
$ ldif -b jpegPhoto < aphoto.jpg> out.ldif
-bオプションによって、ユーティリティが入力全体を単一のバイナリ値として解釈することを指定します。-bオプションがない場合、各行は個別の入力値としてみなされています。
出力ファイルを編集して、バイナリ値を含むディレクトリ・エントリの作成または変更が必要なLDIF文を追加できます。たとえば、テキスト・エディタでファイルout.ldifを開いて、ファイルの最上部に次の行を追加できます。
dn: cn=Barbara Jensen,ou=People,dc=example,dc=com
changetype: modify
add: jpegPhoto
jpegPhoto:: encoded_data
この例ではencoded_dataは、コマンドによって作成されたout.ldifファイルの内容を示しています。
この項の内容は次のとおりです。
ディレクトリには、1つ以上の組織エントリが含まれる場合が多くなっています。通常、組織エントリは、ディレクトリにおける最初または、最上位のエントリです。組織エントリは多くの場合、ディレクトリのサフィックスに対応します。たとえば多くの場合、サフィックスo=example.comを使用するために定義されたディレクトリには、o=example.comと命名された組織エントリがあります。
組織エントリを定義するLDIFは、次のように表示されます。
dn: distinguished_name objectClass: top objectClass: organization o: organization_namelist_of_optional_attributes...
次は、LDIF形式における組織エントリの例です。
dn: o=example.com objectclass: top objectclass: organization o: example.com Corporation description: Fictional company for example purposes telephonenumber: 555-5555
次の例における組織名には、カンマが使用されています。
dn: o=example.com Chile\, S.A. objectclass: top objectclass: organization o: example.com Chile\, S.A. description: Fictional company for example purposes telephonenumber: 555-5556
次の表には、組織エントリの各要素が記載されています。
表4-2 LDIFにおける組織エントリ
| LDIF要素 | 説明 |
|---|---|
|
|
必須。エントリの識別名を指定します。 |
|
|
必須。最上位のオブジェクト・クラスを指定します。 |
|
|
組織のオブジェクト・クラスを指定します。この行は、組織としてエントリを定義します。 |
|
|
組織の名前を指定します。組織名にカンマが含まれる場合、単一のバックスラッシュによってカンマをエスケープするか、または組織の引数全体を引用符で囲む必要があります。ただしUNIXシェルで作業している場合は、バックスラッシュもエスケープする必要があります。したがって、バックスラッシュを2つ使用する必要があります。たとえばサフィックスを |
|
list_of_attributes |
このエントリに関して保持する属性(オプション)のリストを指定します。 |
ディレクトリ・ツリーにおいて、組織単位は主なサブディレクトリを示しています。ディレクトリ・ツリーには通常、複数の組織単位が含まれています。組織単位エントリを定義するLDIFファイルは、次のように表示されます。
dn: distinguished_name objectClass: top objectClass: organizationalUnit ou: organizational_unit_namelist_of_optional_attributes...
次の例は、LDIF形式における組織単位エントリを示しています。
dn: ou=people, o=example.com objectclass: top objectclass: organizationalUnit ou: people description: Fictional organizational unit for example purposes
次の表では、組織単位エントリの各要素を定義しています。
表4-3 LDIFにおける組織単位エントリ
| LDIF要素 | 説明 |
|---|---|
|
|
必須。エントリの識別名を指定します。 DNにカンマが含まれている場合は、バックスラッシュ(\)でカンマをエスケープする必要があります。次に例を示します。
|
|
|
必須。 |
|
|
|
|
|
組織単位の名前を含む属性を指定します。 |
|
list_of_attributes |
このエントリに関して保持する属性(オプション)のリストを指定します。 |
ディレクトリ内のエントリの多くは、組織の人々を示しています。LDIFでは、組織の個人の定義は次のようになっています。
dn: distinguished_name objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: common_name sn: surname list_of_optional_attributes
次の例は、LDIF形式における組織の個人エントリを示しています。
dn: uid=bjensen,ou=people,o=example.com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenname: Babs
uid: bjensen
ou: Marketing
ou: people
description: Fictional person for example purposes
telephonenumber: 555-5557
userpassword: {sha}dkfljlk34r2kljdsfk9
次の表では、LDIFの個人エントリの各要素を定義しています。
表4-4 LDIFにおける組織の個人エントリ
|
LDIF要素 |
説明 |
|
|
必須。エントリの識別名を指定します。 DNにカンマが含まれている場合は、バックスラッシュ(\)でカンマをエスケープする必要があります。たとえば |
|
|
必須。 |
|
|
|
|
|
|
|
|
|
|
|
必須。個人の共通名(通常、個人によって使用されているフルネーム)を指定します。たとえば |
|
|
必須。個人の姓を指定します。たとえば |
|
list_of_attributes |
このエントリに関して保持する属性(オプション)のリストを指定します。 |
次のガイドラインに従って、LDIFを使用してディレクトリを作成します。
LDIF形式に追加するエントリを含む、ASCIIファイルを作成します。
単一の空白行のあるエントリを分離します。ファイルの最初の行を空白にしないでください(さもなければldapmodifyコマンドが終了します)。
データベースにおいて、各ファイルを最上位またはルート・エントリから開始します。ルート・エントリは、データベースに含まれるサフィックスまたはサブサフィックスを示している必要があります。たとえば、ご使用のデータベースにサフィックスdc=example,dc=comがある場合、ディレクトリの最初のエントリは、次となります。
dn: dc=example,dc=com
サブツリー内へ移動するエントリを作成する前に、サブツリーに対する分岐点を作成します。
次の方法のいずれかを使用して、LDIFファイルからディレクトリを作成します。
Directory Service Control Centerの使用
dsadmコマンドおよびdsconfコマンドの使用
-aオプションまたは-Bオプションのあるldapmodifyコマンドの使用
現在、ディレクトリ・データベースがあってこのデータベースに新規サブツリーを追加している場合、ldapmodifyコマンドを使用してディレクトリを作成します。LDIFファイルからディレクトリを作成するその他の方法とは異なり、ldapmodifyコマンドを使用してサブツリーを追加できるようになる前にDirectory Serverを動作させておく必要があります。
次の例は、組織エントリが1つ、組織単位エントリが2つ、および組織の個人エントリが3つあるLDIFファイルを示しています。
例4-2 組織、組織単位、および組織の個人のエントリがあるLDIFファイルの例
dn: o=example.com Corp
objectclass: top
objectclass: organization
o: example.com Corp
description: Fictional organization for example purposes
dn: ou=People,o=example.com Corp
objectclass: top
objectclass: organizationalUnit
ou: People
description: Fictional organizational unit for example purposes
tel: 555-5559
dn: cn=June Rossi,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: June Rossi
sn: Rossi
givenName: June
mail: rossi@example.com
userPassword: {sha}KDIE3AL9DK
ou: Accounting
ou: people
telephoneNumber: 2616
roomNumber: 220
dn: cn=Marc Chambers,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Marc Chambers
sn: Chambers
givenName: Marc
mail: chambers@example.com
userPassword: {sha}jdl2alem87dlacz1
telephoneNumber: 2652
ou: Manufacturing
ou: People
roomNumber: 167
dn: cn=Robert Wong,ou=People,o=example.com Corp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Robert Wong
cn: Bob Wong
sn: Wong
givenName: Robert
givenName: Bob
mail: bwong@example.com
userPassword: {sha}nn2msx761
telephoneNumber: 2881
roomNumber: 211
ou: Manufacturing
ou: people
dn: ou=Groups,o=example.com Corp
objectclass: top
objectclass: organizationalUnit
ou: groups
description: Fictional organizational unit for example purposes
単一言語を含むディレクトリの場合、ディレクトリに新規エントリを追加するために特別なことをする必要はありません。ただし多国籍の組織の場合、様々なロケールのユーザーが自身の言語でディレクトリ情報を表示できるようにするために、複数言語で情報を格納する必要があります。
情報が複数言語で示される際に、サーバーは言語タグを属性値と関連付けます。新規エントリが追加される際に、RDN(相対識別名)で使用される属性値は言語コードなしで追加される必要があります。
単一の属性に複数言語を格納できます。属性タイプは同じですが、各属性値の言語コードが異なっています。言語タグは、ディレクトリ内に文字列が格納される方法については影響しません。すべてのオブジェクト・クラスおよび属性の文字列は、UTF-8を使用して格納されます。
Directory Serverおよびその関連する言語タグによってサポートされる言語のリストについては、「サポートされるロケールの識別」を参照してください。
たとえば、example.com社は米国およびフランスにオフィスがあります。この企業は、従業員が各自の母国語でディレクトリ情報を表示することを希望しています。ディレクトリ・エントリが新規従業員のBabs Jensen向けに追加される際に、管理者はLDIFでこのエントリを作成します。管理者は、英語およびフランス語で次のように、personalTitle属性に関する値を作成します。
dn: uid=bjensen,ou=people, o=example.com Corp objectclass: top objectclass: person objectclass: organizationalPerson name: Babs Jensen cn: Babs Jensen sn: Jensen uid: bjensen personalTitle: Miss personalTitle;lang-en: Miss personalTitle;lang-fr: Mlle preferredLanguage: fr
優先言語を英語に設定しているLDAPクライアントでディレクトリ・エントリにアクセスしているユーザーには、個人の敬称がMissと表示されます。優先言語をフランス語に設定しているLDAPクライアントでディレクトリにアクセスしているユーザーには、個人の敬称がMlleと表示されます。
すべてのディレクトリ・データは、ユニコードのUTF-8エンコーディングを使用することによって格納されます。したがってLDIFのすべての入力は、UTF-8でエンコードされる必要があります。LDIF形式の詳細は、LDAP Data Interchange Format (LDIF) - 技術仕様についての説明に記載されています。
LDIF入力を行うときは、次の点を考慮してください。
オブジェクトは空白行で、dn:で開始する行が続きます。この行は、オブジェクトの識別名です。他のすべての行は、このオブジェクトの属性です。
コメントは#で始まります(EOLで終了します)。
シングル・スペースで始まる行は、前の行を継続しています。
バイナリ値はBase 64でエンコードされており、属性名の後ろに二重コロン(::)で表されています。
改行および行送りによって、LDIFエントリに安全でない文字を追加します。
ldapmodifyコマンドを使用して属性値を変更する場合、誤って属性値の最後にスペースを入れないでください。たとえば、末尾にスペースがあるjensenは、末尾にスペースがないjensenとは異なるものです。
ldapmodifyおよびldapdeleteユーティリティによって、ファイルからの読取りとまったく同じように、コマンドの後に入力するLDIF文が読み取られます。入力の完了後に、ファイルの終了(EOF)のエスケープ・シーケンスとしてシェルが認識する文字を入力します。
通常は、EOFエスケープ・シーケンスは[Ctrl]キーを押しながら[D]キーを押します(^D)。
次の例では、ldapmodifyコマンドへの入力を終了する方法を示します。
prompt\> ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Barry Nixon,ou=People,dc=example,dc=com changetype: modify delete: telephonenumber ^D prompt\>
簡潔性および移植性の点から、このドキュメントの例では、プロンプトまたはEOFシーケンスを示していません。
コマンドラインにコマンド・オプションを入力する際に、コマンドライン・インタプリタに対して特別な意味を持つ文字(スペース( )、アスタリスク(*)、バックスラッシュ(\\)など)をエスケープする必要となる場合があります。たとえばDNの多くはスペースを含み、多くのUNIXシェルの場合には二重引用符("")で値を囲む必要があります。
このため、ご使用のコマンドライン・インタプリタに応じて、一重引用符または二重引用符のいずれかを使用する必要があります。詳細は、オペレーティング・システムのドキュメントを参照してください。
ldapmodifyコマンドの後ろのLDIF文が、シェルではなくコマンドによって解釈されており、したがって特別な考慮事項は不要であることに留意してください。
属性OIDは属性名において、デフォルトではサポートされていません。これは、Directory Serverの一部の旧バージョンには該当しません。属性OIDをDirectory Serverの旧バージョンで属性名として使用していた場合、受入れ対象の属性OIDについて、属性nsslapd-attribute-name-exceptionsをonに設定する必要があります。
エントリを追加または変更する場合、使用する属性はエントリのオブジェクト・クラスによって要求されるかまたは許可される必要があり、定義された構文と一致する値を含んでいる必要があります。
エントリを変更する際に、Directory Serverでは変更する属性のみでなく、エントリ全体でスキーマ・チェックを実行します。したがって、エントリのいずれかのオブジェクト・クラスまたは属性がスキーマに準拠しない場合、操作が失敗する場合もあります。
エントリを追加する場合のLDIFテキストの順序では、コマンドラインまたはファイルのいずかにおいて、親エントは子エントリの前に記述される必要があります。サーバーがLDIFテキストを処理する際に、このように子エントリの前に親エントリを作成します。
たとえばご使用のディレクトリに存在しないPeopleのサブツリーにエントリを作成する場合、サブツリー内のエントリの前にPeopleコンテナを示すエントリを記述します。
dn: dc=example,dc=com dn: ou=People,dc=example,dc=com ... People subtree entries... dn: ou=Group,dc=example,dc=com ... Group subtree entries...
ldapmodifyコマンドライン・ユーティリティを使用して、ディレクトリに任意のエントリを作成できますが、サフィックスのルートまたはサブサフィックスは、必要な構成エントリと関連付ける必要のある特別なエントリです。
極端に大きな属性値を持つエントリを追加または変更するときは、これを受け入れることができるように、事前にサーバーの構成が必要になることがあります。サーバーのオーバロードを防ぐために、デフォルトでは、クライアントは2MBを超えるデータを送信できないように制限されています。
これを超えるエントリを追加するか、属性をこれよりも大きい値に変更しようとすると、サーバーはその動作の実行を拒否し、ただちに接続を閉じます。たとえば、1つのエントリの1つ以上の属性にマルチメディア・コンテンツなどのバイナリ・データが含まれると、この制限を超える可能性があります。
また、大規模なスタティック・グループを定義するエントリに、表記がこの制限を超える多数のメンバーが含まれる可能性があります。ただしパフォーマンス上の理由からこのようなグループはお薦めできず、ディレクトリ構造の再設計を考慮する必要があります。
コマンドライン・ツールは、LDIF入力に含まれるすべてのエントリまたは変更を、順番に処理します。最初のエラーが発生すると、デフォルトの動作では処理を停止することになっています。エラーに関係なくすべての入力の処理を継続するときは、-cオプションを使用します。エラーの状態は、ツールの出力に表示されます。
前述の考慮事項に加え、一般的なエラーには、次のようなものがあります。
実行する操作に対する適切なアクセス権限がない。
ディレクトリにすでに存在するDNで、エントリを追加。
存在しない親の下にエントリを追加。
LDAPクライアントを使用して、ディレクトリ内のエントリを検索できます。ほとんどのクライアントには、ディレクトリを検索してエントリ情報を取得できるようにするために、なんらかの形式の検索インタフェースが用意されています。
ディレクトリに設定されたアクセス制御が、検索結果を決定します。通常、一般ユーザーにはディレクトリの多くは表示されず、ディレクトリ管理者が、全データへのすべてのアクセス権(構成を含む)を持っています。
ldapsearchコマンドライン・ユーティリティを使用して、ディレクトリ・エントリを検索および取得できます。この項で説明するldapsearchユーティリティは、Solarisプラットフォームで提供されるユーティリティではなく、Directory Server Resource Kitの一部です。
このユーティリティは、指定されたユーザーID(通常は識別名)とパスワードによってサーバーへの接続を開き、検索フィルタに基づいてエントリを検索します。検索範囲には、単一のエントリ、エントリの直接のサブエントリ、またはエントリ・ツリーやサブツリーを含むことができます。
検索結果はLDIF形式で返されます。
ldapsearchを使用する場合は、次の形式を使用してコマンドを入力する必要があります。
ldapsearch [optional_options] [search_filter] [optional_list_of_attributes]
各項目の意味は次のとおりです。
optional_optionsは、一連のコマンドラインのオプションを表しています。検索フィルタが存在する場合は、これよりも前に指定する必要があります。
search_filterは、-fオプションを使用しているファイルにおいて、LDAP検索フィルタを表しています。
optional_list_of_attributesは、スペースで区切られた属性のリストを表しています。属性のリストを指定すると、検索結果で返される属性の数が減少します。この属性のリストは、必ず検索フィルタの後に表示されます。属性のリストを指定しない場合は、ディレクトリ内に設定されたアクセス制御によって許可されたすべての属性(操作属性を除く)の値が検索によって返されます。
|
注意: 検索操作の結果として操作属性を返すようにする場合は、検索コマンドでこれらを明示的に指定する必要があります。明示的に指定された操作属性に加えて通常の属性も取得するには、ldapsearchコマンドの属性リスト内でアスタリスク(*)を使用します。 |
ldapsearchコマンドライン・ユーティリティを使用する場合に、コマンドライン・インタープリタにとって特別な意味を持つ文字(空白[ ]、アスタリスク[*]、バックスラッシュ[\\]など)を含む値の指定が必要になることがあります。特殊文字を指定する場合は、その値を引用符("")で囲みます。次に例を示します。
-D "cn=Charlene Daniels,ou=People,dc=example,dc=com"
このために、ご使用のコマンドライン・インタプリタに応じて、一重引用符または二重引用符のいずれかを使用します。詳細は、ご使用のシェルのドキュメントを参照してください。
ディレクトリ内のすべてのエントリの検索を実行しようとしています。
サーバーのホスト名はmyServerです。
このサーバーが使用しているポート番号は、5201です。
ディレクトリにname="DirAdminDN" content="cn=admin,cn=Administrators,cn=config"としてバインドされています。記号"-"の使用は、コマンドラインにパスワードの入力を求められることを示しています。
SSLが、ポート636(デフォルトのSSLポート番号)のサーバーで有効です。
すべてのデータの格納されているサフィックスは、dc=example,dc=comです。
前述の情報が提供された場合は、次の呼出しによってディレクトリ内のすべてのエントリを返すことができます。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -b "dc=example,dc=com" -s sub "(objectclass=*)"
"(objectclass=*)"は、ディレクトリ内のすべてのエントリと一致する検索フィルタです。
検索フィルタはコマンドラインから直接指定できます。この場合、フィルタを引用符で囲むことを忘れないでください("filter")。また、-fオプションは指定しません。
次に例を示します。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - -b "dc=example,dc=com" "(cn=Charlene Daniels)"
ルートDSEエントリは、サポートされているサフィックスのリストや使用可能な認証メカニズムなど、現在のサーバー・インスタンスに関連する情報を含む特別なエントリです。検索ベース""を指定することで、このエントリを検索できます。また、検索範囲base、およびフィルタ"(objectclass=*)"を指定する必要があります。
次に例を示します。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - -b "" -s base "(objectclass=*)"
Directory Serverでは、特別なcn=schemaエントリ内にすべての Directory Serverスキーマが格納されています。このエントリには、ご使用のディレクトリ・サーバーに対して定義されたすべてのオブジェクト・クラスと属性に関する情報が含まれています。
このエントリの内容を調べるには、次のように指定します。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -b "cn=schema" -s base "(objectclass=*)"
|
注意: 厳密に準拠する場合は、指定されたエントリのスキーマ・サブエントリの場所は、 |
検索を簡単に行うために、LDAP_BASEDN環境変数を使用して検索ベースを設定できます。これによって、-bオプションによる検索ベースの指定を省略できます(環境変数の設定方法については、オペレーティング・システムのドキュメントを参照)。
通常、ディレクトリのサフィックスの値にはLDAP_BASEDNを設定します。ディレクトリのサフィックスはルート、つまりディレクトリの最上位のエントリと等しいため、この設定によってすべての検索がディレクトリのルート・エントリから開始されます。
たとえばLDAP_BASEDNをdc=example,dc=comに設定した場合、次のコマンドラインの呼出しを使用すると、ディレクトリ内で(cn=Charlene Daniels)を検索することができます。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - "(cn=Charlene Daniels)"
この例では範囲の指定に-sオプションが使用されていないので、subのデフォルト範囲が使用されます。
ldapsearchコマンドでは、すべての検索結果がLDIF形式で返されます。デフォルトではldapsearchは、エントリの識別名と読取りを許可されたすべての属性を返します。指定したディレクトリ・エントリの属性のサブセットの読取りのみが許可されるように、ディレクトリのアクセス制御を設定できます。操作属性のみが返されません。検索操作の結果として操作属性を返すようにする場合は、検索コマンドでこれらを明示的に指定する必要があります。操作属性の詳細は、TODO: AdminServerAdminGuideの不使用に関する説明を参照してください。
検索結果で返された属性のすべてを表示するわけではない場合を考えてみます。返された属性をいくつかの特定の属性に制限するには、検索フィルタのすぐ後のコマンドラインで、必要な属性を指定します。たとえば、ディレクトリのすべてのエントリについてcn属性とsn属性を表示するには、次のコマンドを使用します。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - "(objectclass=*)" sn cn
この例では、LDAP_BASEDNを使用して検索ベースを設定することを前提としています。
Directory Serverは検索時に、複数値属性を必ずしもソート順で返すわけではありません。たとえば、変更を適用する前にサーバーを再起動することを要求するcn=configで、構成属性を検索する場合を考えてみます。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - -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)"
検索フィルタは、検索操作に対して返されるエントリを選択します。これらは一般的に、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属性を使用して特定の共通名を持つ人を検索することができます。
人のエントリが含まれる属性の例には、次のようなものが挙げられます。
cn(その人の共通名)
sn(その人の姓)
telephoneNumber(その人の電話番号)
buildingName(その人が居住する建物名)
l(その人が存在する場所)
表4-5は、検索フィルタで使用できる演算子をリスト表示したものです。
表4-5 検索フィルタの演算子
dn属性に対する検索機能を拡張し(たとえばcn:dn:=John)、国際的な検索をサポートするために拡張された演算子も存在します。
LDAPv3を使用すると、特定の属性に対してマッチ演算子とルールを構築することができます。一致ルールは、属性の値を特定の構文と比較する方法を定義しています。すなわち一致ルールとは、一致する可能性のある属性を比較する方法を定義したものです。たとえば一致ルールは、属性を比較するときにテキストの大文字小文字を考慮するかどうかを定義できます。
ルールが作成されると、検索フィルタで参照されます。
たとえば次の検索フィルタは、OID2.5.13.5で指定される一致ルールを使用して、姓Jensenを含むエントリを比較します。
(sn:2.5.13.5:=Jensen)
次の例では、:dn表記を使用して、比較時にOID2.5.13.5を使用することと、一致を評価する場合にエントリ\qsの識別名の属性をエントリの一部として考慮することを示しています。
(sn:dn:2.5.13.5:=Jensen)
プリフィクス表記内で次のように表現されるブール演算子を使用して、複数の検索フィルタ・コンポーネントを組み合せることができます。
(Boolean-operator(filter)(filter)(filter)...)
このBoolean-operatorは、表4-6に一覧表示されているブール演算子のいずれかになります。
ブール演算子を組み合せて相互にネストすることで、次のような複雑な式を作成できます。
(Boolean-operator(filter)(Boolean-operator(filter)(filter)))
検索フィルタで使用できるブール演算子には、次のようなものがあります。
表4-6 検索フィルタのブール演算子
| 演算子 | 記号 | 説明 |
|---|---|---|
|
AND |
& |
文がtrueになるためには、指定したすべてのフィルタがtrueである必要があります。次に例を示します。
|
|
OR |
| |
文がtrueになるには、指定したフィルタの少なくとも1つがtrueである必要があります。次に例を示します。
|
|
NOT |
! |
文がtrueになるためには、指定した文がtrueではない必要があります。NOT演算子によって影響を受けるのは、1つのフィルタだけです。次に例を示します。
NOT演算子を使用すると、索引付けされていない検索となります。 |
ブール式は、次の順序で評価されます。
内側のカッコでくくられた式から外側のカッコでくくられた式へ
すべての式を左から右へ
検索フィルタは、コマンドラインではなく、ファイルに入力できます。この場合、各検索フィルタをファイル内の個別の行に指定します。ldapsearchコマンドは、ファイル内に現れる順序で各検索を実行します。
たとえば、ファイルに次が含まれているとします。
(sn=Daniels) (givenname=Charlene)
この場合、ldapsearchは最初にDanielsという姓を持つすべてのエントリを検索し、次にCharleneという名を持つすべてのエントリを検索します。両方の検索条件に一致するエントリが見つかると、そのエントリは2回返されます。
たとえば、前述の検索フィルタをsearchdbという名前のファイル内で指定して、LDAP_BASEDNを使用して検索ベースを設定したとします。次によって、どちらかの検索フィルタに一致するすべてのエントリが返されます。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - -f searchdb
ここで返される属性セットを制限するには、検索行の末尾で属性名を指定します。たとえば、次のldapsearchコマンドは両方の検索を実行しますが、各エントリのDNと、givenname、およびsn属性だけを返します。
ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - -f searchdb sn givenname
検索フィルタの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)"
表4-7にリスト表示されている特殊文字は、検索フィルタで使用された場合、次の方法で表現される必要があります。
表4-7 検索フィルタの特殊文字
| 特殊文字 | 特殊文字を使用した値 | フィルタの例 |
|---|---|---|
|
* |
|
|
|
\\ |
|
|
|
() |
|
|
|
null |
|
|
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=admin,cn=Administrators,cn=config -w - "(objectclass=*)" aci
明示的に指定された操作属性に加えて通常の属性も取得するには、操作属性にアスタリスク(*)を追加して指定します。次に例を示します。
$ ldapsearch -h myServer -p 5201 -D cn=admin,cn=Administrators,cn=config -w - "(objectclass=*)" aci *
