14.7. 指定したコントロールでの検索
Directory Server は、DSE の
supportedControls 属性に制御を定義しています。これらの中には、レプリケーションのようなサーバーの操作を定義するものもあれば、Get Effective Rights や、クライアントが LDAP 操作でサーバーに渡すことができる制御の逆参照などの拡張操作を許可するものもあります。
これらの制御は、
-E オプションを使用して指定できます。制御 OID、ldapsearch の重大度、およびその制御操作に必要な情報を指定します。
-E '[!]control_OID:control_information'
一部の制御 (サーバー側のソートやシンプルなページングされた結果など、) には、検索操作にコントロールを渡すために使用できるエイリアスがあります。制御エイリアスを使用すると、制御がクライアントによって認識されるため、結果がフォーマットされます。
14.7.1. 効果のあるユーザー権限の取得
有効な権利を取得する検索コントロールは、コントロール OID を使用して渡されます。以下に例を示します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=jsmith,ou=people,dc=example,dc=com' "(objectclass=*)"
重要
コントロールの OID が渡されると、検索結果の形式化がされません。
Get Effective Rights の検索については、アクセス制御の章「エントリーのアクセス権利の確認 (Get Effective Rights)」で詳細に説明されています。
14.7.2. サーバー側のソートの使用
サーバー側のソートは、
-E フラグと sss 制御エイリアスを使用して、他の制御操作として実行されます。操作の構造は、結果をソートし、任意でソート順序および順序ルールである属性を設定します。
-E sss=[-]attribute_name:[ordering_rule_OID]
ダッシュ (-) は、ソート順序を元に戻す任意のフラグで、降順の降順を逆に実行します。「一致するルールの使用」 のマッチングルールテーブルには、Directory Server でサポートされる順序ルールが含まれています。
以下に例を示します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E sss=-uidNumber:2.5.13.15 "(objectclass=*)"
14.7.3. 逆参照検索の実行
逆参照 検索は、エントリーの相互参照を追跡し、参照されたエントリーに関する情報を返す簡単な方法です。たとえば、グループエントリーには、そのメンバーのユーザーエントリーへの参照が含まれます。通常検索は、最初にグループを検索し、そのメンバーをリスト表示し、各メンバーに個別の検索が必要になります。グループエントリーの逆参照検索は、メンバーに関する情報 (場所、メールアドレス、マネージャーなど) を 1 つの検索要求でグループの情報と ともに 返します。
逆参照は多くのクライアント操作を簡素化し、実行した検索操作の数を減らします。クロスリンクは、エントリー間の関係を表示します。一部の操作では、1 つのエントリーから複数のリンクのリストを取得し、後続の検索を実行してリスト上の各エントリーから情報を取得しないといけない場合があります。逆参照により、検索のシーケンスを 1 つの検索に統合することができます。
重要
逆参照操作は、OpenLDAP コマンドラインツールのバージョン 2.4.18 以降、または逆参照検索をサポートするその他のクライアントを使用して行う必要があります。
逆参照引数の形式は次のとおりです。
-E 'deref=deref_attribute:list_of_attributes'
deref_attribute は、参照が含まれる検索ターゲットの属性です。これには、member または manager などの値に DN を持つ属性を使用できます。
注記
deref_attribute の値は DN にする必要がありますが、この属性に対する実際の定義された構文は DN 構文 (1.3.6.1.4.1.1466.115.121.1.12) である必要があります。
list_of_attributes は、参照されたエントリーの 1 つ以上の属性で、プライマリーの検索結果とともに返されます。l,mail,cn のように、複数の属性をコンマで区切ることができます。
図14.1 簡単な参照検索コマンド
検索引数で要求された逆参照された情報は、残りの検索結果とともに返されます。たとえば、この逆参照検索は、検索ターゲットエントリー (エンジニアグループ) の
member 属性を deref_attribute として使用するように指示します。その後、各メンバーの locality 属性を返します。
# ldapsearch -x -D "cn=Directory Manager" -W -b "cn=Example,ou=Groups,dc=example,dc=com" -E 'deref=member:mail,cn' "(objectclass=*)" # Engineers, Groups, example.com dn: cn=Engineers,ou=Groups,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADNMIQAAAA1BAZtZW1iZXIEK2NuPURld mVsb3BlcnMsIG91PUdyb3VwcywgZGM9ZXhhbXBsZSxkYz1jb20whAAAADIEBm1lbWJlcgQoY249VG VzdGVycywgb3U9R3JvdXBzLCBkYz1leGFtcGxlLGRjPWNvbTCEAAAAVAQGbWVtYmVyBCp1aWQ9ZW5 nLCBvdT1lbmdpbmVlcmluZywgZGM9ZXhhbXBsZSxkYz1jb22ghAAAABowhAAAABQEAWwxhAAAAAsE CUNhbWJyaWRnZQ== # member: <mail=jsmith@example.com><cn=John Smith>;uid=jsmith,ou=people,dc=example,dc=com objectClass: top objectClass: inetuser objectClass: groupofnames cn: Engineers member: uid=jsmith,ou=people,dc=example,dc=com
14.7.4. 単純なページ結果の使用
検索結果は非常に大きくなる可能性があり、結果処理の一部が結果を整理することです。その方法の一つとして、ページングされた単純な結果 を使用することがあります。これは、結果を一定の長さのページに分割するコントロールです。
シンプルなページの結果で、一度に表示するエントリーの数を設定できます。結果は一度に 1 ページ経由でスクロールされるため、ダイジェストで結果が容易になります。制御の完全な動作は RFC 2696 で説明されています。
ページングされた単純な結果は、Directory Server の LDAP コントロール拡張機能として実装されます。OID は 1.2.840.113556.1.4.319 です。
簡単なページ結果の仕組み
ページ結果の簡単な検索を開始すると、以下のようになります。
- クライアントは検索をサーバーに送り、ページ付けの結果が制御し、最初のページで返すレコードの数を制御します。
- Directory Server がデータの返信を開始する前に、サーバーは合計で何件のレコードを返信できるかの見積もりを生成します。レコードの推定値は、正確な数ではありません。返されるレコードの合計数は推定値よりも小さくなります。このようなシナリオの理由は以下の通りです。
- 検索フィルターで使用される属性はインデックスに存在しません。最適な結果を得るには、クエリーされた属性をすべてインデックス化する必要があります。
- エントリーがクライアントに送信される前に、アクセス制御リスト (ACL) が検証されます。パーミッションが十分にないため、エントリーが返されなくなります。
推定値を生成した後、サーバーは最初の結果セット、Cookie、および推定レコード数を送信します。 - 返されたレコードがクライアントに表示されます。ユーザーは、次のリクエストで返されるレコードの数を入力できるようになりました。要求された番号は、Cookie と一緒にサーバーに送信されます。
- サーバーは要求された数のレコードをデータベースから取得し、それらを Cookie と共にクライアントに送信します。
- 前述の 2 つのステップは、すべてのレコードが送信されるか、検索がキャンセルされるまで繰り返されます。
シンプルなページ結および OpenLDAP ツール
ldapsearch の簡単なページの結果検索オプションの形式は以下のとおりです。
-E pg=size
size の値はページサイズまたはページごとに含むエントリー数です。以下に例を示します。
ldapsearch -x -D "cn=Directory Manager" -W -b "ou=Engineers,ou=People,dc=example,dc=com" -E pg=3 "(objectclass=*)" cn dn: uid=jsmith,ou=Engineers,ou=People,dc=example,dc=com cn: John Smith dn: uid=bjensen,ou=Engineers,ou=People,dc=example,dc=com cn: Barbara Jensen dn: uid=hmartin,ou=Engineers,ou=People,dc=example,dc=com cn: Henry Martin Results are sorted. next page size (3): 5
末尾のタグには、検索で設定されたページサイズ (カッコ内の数字) が表示されています。コロンの後に、次のページのページサイズが表示されるため、以下に示すように 5 と入力すると、次のページが 5 つのエントリーで開きます。
重要
簡素なページ結果操作は、OpenLDAP コマンドラインツールのバージョン 2.4.18 以降、または Perl Net::LDAP などの簡素なページング結果をサポートするその他のクライアントを使用して実行する必要があります。
ページングされた簡素な結果およびサーバー一致
ページングされた簡素な結果は、サーバー側のソートと併用できます。サーバー側のソートは、クライアントではなくサーバーでソートプロセスを実行する制御です。これは通常、特定のマッチングルールを使用する検索を行います。(この動作は RFC 2891 で定義されています。) OpenLDAP クライアントツールは、簡素なページングされた結果制御でサーバー側のソートをサポートしませんが、Perl Net::LDAP などのその他の LDAP ユーティリティーは両方をサポートします。
1 つの接続に複数の簡素なページングされた結果要求
一部のクライアントは Directory Server への接続を 1 つ開きますが、簡素なページングされた結果拡張を使用する複数の検索要求など、複数の操作要求を送信します。
Directory Server は、複数の簡素なページングされた検索を管理および解釈できます。各検索は、アレイ内のエントリーとして追加されます。ページングされた検索要求が最初に送信されると、Cookie が作成され、検索結果に関連付けられます。結果の各ページはその Cookie で返されます。Cookie は結果の次のページを要求するために使用されます。最後のページでは、Cookie が空になり、結果が終了したことを示します。これにより、各検索結果のセットが個別に保持されます。
1 つの接続に複数の簡素なページングされた結果がある場合、タイムアウト制限は引き続き監視されますが、すべて のオープン検索要求は、いずれか のページ検索が切断される前に、設定された時間制限に到達します。
VLV インデックスと対照的な、簡素なページングされた結果
VLV インデックスは簡素なページングされた結果に類似しているため、それらのインデックスは、結果の閲覧可能なリストも返すことになります。主な違いは、リストの生成方法です。簡素なページングされた結果は検索ごとに計算されますが、VLV インデックスは永続的なリストになります。全体的に、VLV インデックスは検索速度が速いですが、サーバー側の設定が必要で、サーバーが維持するためのオーバーヘッドがあります。
注記
シンプルなページの結果と VLV インデックスは、同じ検索では使用 できません。簡素なページングされた結果は、すでに参照しているインデックスである VLV インデックスの操作を試みます。VLV インデックスを使用した検索に制御が渡された場合、サーバーは UNWILLING_TO_PERFORM エラーを返します。
VLV インデックスの詳細は、「仮想リストビューコントロールを使用して、大規模な検索結果の連続したサブセットを要求する」を参照してください。
14.7.5. 読み取り前および後のエントリーレスポンス制御
Red Hat Directory Server は、RFC 4527 に準拠した、読み取り前および読み取り後のエントリー応答制御をサポートします。クライアントが応答制御を要求すると、LDAP 検索エントリーが返されます。これには、更新前および更新後に属性の値が含まれます。
事前読み取りの制御が使用されると、LDAP 検索クエリーには変更前に指定した属性の値が含まれます。読み取り後の制御が使用される場合、クエリーには変更後の属性の値が含まれます。両方の制御を同時に使用できます。たとえば、
description 属性を更新し、変更前および変更後に値を表示するには、次のコマンドを実行します。
#ldapmodify -D "cn=Directory Manager" -W -x \-e \!preread=description -e \!postread=descriptiondn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: description description: new description modifying entry "uid=user,ou=People,dc=example,dc=com" control: 1.3.6.1.1.13.1 false ZCkEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wAA== # ==> preread dn: uid=user,ou=People,dc=example,dc=com description: old description # <== preread control: 1.3.6.1.1.13.2 false ZEsEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wIjAgBAtkZXNjcmlwdGlvbjERBA9uZXcgZGVzY3JpcHRpb24= # ==> postread dn: uid=user,ou=People,dc=example,dc=com description: new description # <== postread
