| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
この用語集ではLDAPおよびディレクトリ・サービスの説明に使用される用語を定義しており、Oracle Unified Directory固有の用語も含まれます。
LDAP中止操作は、未処理リクエストの処理をサーバーが停止するようにリクエストするために使用できます。中止リクエストのプロトコルopは次のとおりです:
AbandonRequest ::= [APPLICATION 16] MessageID
リクエストで指定されたメッセージIDは、中止する操作のメッセージIDです。
中止操作にはレスポンスがないため、中止操作が正しく実行されたかどうかをクライアントが確認する方法はありません。同様に、操作が中止された場合は、それに対するレスポンスはありません。そのため、クライアントは送信されないレスポンスを長い間待っている可能性があります。どちらの問題も取消し拡張操作で説明されています。
バインド、アンバインド、中止およびTLS起動拡張操作は中止できません。
抽象オブジェクト・クラスは、エントリで直接は使用できませんが、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。そのサブクラスは、抽象クラスで定義される必須またはオプション、あるいはその両方の属性タイプを継承します。
LDAPで定義される最も重要な抽象オブジェクト・クラスのうちの1つがtopオブジェクト・クラスで、サーバー・スキーマで仮想的に定義されるその他すべてのオブジェクト・クラスのルート・クラスです。
抽象構文表記法1 (ASN.1)は、バイナリ形式でデータをエンコーディングするメカニズムです。各要素がタイプ、長さおよび値を保有するTLV構造を使用します。タイプ・コンポーネントは、要素内に保存される情報の種類を示し、値をエンコードする方法を示すデータ・タイプです。長さコンポーネントは値のバイト数を指定し、値コンポーネントは要素で保持される実データです。
ASN.1要素の例を次に示します:
Null要素はどのような値も保持しません。通常、値の不要な要素を必要とする場合にプレースホルダとして使用されます。
Octet string要素は0オクテット(バイト)以上のデータ・セットを保持します。文字列データまたはバイナリ・データの保持に使用できます。
Boolean要素は、trueまたはfalseのいずれかを表す値を保持します。
Integer要素は、整数値を表す値を保持します。
Enumerated要素は、各値が特定の意味を保有する整数値を表す値を保持します。
Sequence要素は、0個以上のSequence要素以外のASN.1要素を保持するコンテナで、要素の順序が重要な方式です。
Set要素は、0個以上のSet要素以外のASN.1要素を保持するコンテナで、要素の順序は重要ではない方式です。
ASN.1はバイナリ・コーディング用の一般的なフレームワークですが、データのエンコード方法を実際には定義しないことに注意してください。エンコード方法はエンコーディング・ルールで処理され、多数の様々な種類のASN.1エンコーディング・ルールが存在します。LDAPでは基本エンコーディング・ルールエンコーディングが使用されますが、別のタイプではDistinguished Encoding Rules (DER)、Canonical Encoding Rules (CER)およびPacked Encoding Rules (PER)があります。
アクセス制御は、ディレクトリ・サーバー内の様々な種類の情報にアクセスできるユーザーを制限するメカニズムを提供します。アクセス制御プロバイダは、次のような様々な事柄を制御するために使用できます:
クライアントがサーバーからエントリを取得できるかどうか。
クライアントが取得を許可されたエントリ内の属性の種類。
クライアントが取得を許可された属性の値。
クライアントがディレクトリ内でデータを操作できる方法。
アクセス制御の決定には、次のような様々な事柄を考慮できます:
認証されたユーザーとしてのDN。
クライアントがサーバーへの認証を行った方法。
ユーザーがメンバーである任意のグループ。
認証されたユーザーのエントリのコンテンツ。
ターゲット・エントリのコンテンツ。
クライアント・システムのアドレス。
クライアントとサーバーの間の通信が保護されているかどうか。
試行の時刻または曜日、あるいはその両方。
アクセス制御構文の詳細は、第25章「データへのアクセス制御」を参照してください。
アクセス制御サブシステムに加えて、ディレクトリ・サーバーには、ユーザーに対する許可内容を制御するために使用できる特権もあります。使用可能な特権の1つはbypass-acl特権で、この特権がなければアクセス制御サブシステムにより強制される制限を、クライアントがバイパスできるようにするために使用できます。
「アクセス制御ルール」を参照してください。
アクセス制御ルール(アクセス制御命令またはACIとも呼ばれる)は、サーバーで数種類の操作を実行するユーザーまたはユーザー・セットに対してアクセス権限を与えるか、または拒否するために使用できるルールです。ディレクトリ・サーバーのアクセス制御ポリシーは、サーバーで定義されるアクセス制御ルールのセット全体で構成されます。
アクセス制御ルールで使用される構文、およびアクセス制御ルールを使用して許可または拒否できる操作の詳細は、第25章「データへのアクセス制御」を参照してください。
ディレクトリ・サーバーのアクセス・ログは、すべての受信されたリクエストおよび返されたレスポンスを含め、サーバーにより処理されたすべての操作を追跡するメカニズムを提供します。サーバー内で実行された内部操作についての情報の取得にも使用される場合があります。
ディレクトリ・サーバーは、アクセス・ロガー(同様にエラー・ログおよびデバッグ・ログのロガー)を実装するための拡張可能なフレームワークを提供します。デフォルトのアクセス制御ログを実装すると、1つの操作ごとに2つのレコードを使用して情報をログ・ファイルに書き込みます。最初のレコードはクライアントから受信したリクエストを反映し、2番目のレコードは操作処理の結果の情報を提供します。
すべてのメッセージには、次のような要素の共通セットが含まれます:
メッセージのログが記録された時間。
処理される操作のタイプ。
操作をリクエストしたクライアント接続の接続ID。
クライアント接続上の操作の操作ID。
操作のリスエストに使用されたメッセージのメッセージID。
中止操作の場合は、リクエスト・ログ・メッセージには中止する操作のメッセージIDが含まれます。中止操作に対するレスポンスがなくても、サーバーは、中止が正しく実行されたかどうか、およびミリ秒単位の処理時間を示す結果メッセージをログに記録します。
追加操作の場合は、リクエスト・ログ・メッセージには追加するエントリの識別名が含まれます。応答ログ・メッセージには、操作の結果コード、診断メッセージ、一致したDN、認証IDおよびミリ秒単位の処理時間が含まれる場合があります。
バインド操作の場合は、リクエスト・ログ・メッセージには認証タイプ(SIMPLEまたはSASLとそれに続くメカニズム名)およびバインドDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認証ID、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
比較操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNおよび属性タイプが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
削除操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
拡張操作の場合は、リクエスト・ログ・メッセージには拡張されるリクエストのオブジェクト識別子が含まれます。レスポンス・ログ・メッセージには、拡張されたレスポンスのOID、結果コード、診断メッセージ、一致したDNおよびミリ秒単位の処理時間が含まれる場合があります。
変更操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
DN変更操作の場合は、リクエスト・ログ・メッセージにはターゲット・エントリDN、新規RDN、旧RDN値を削除するかどうかを示すフラグおよび新規上位DNが含まれます。レスポンス・ログ・メッセージには、結果コード、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
検索操作の場合は、リクエスト・ログ・メッセージには検索ベースDN、検索範囲、LDAP検索フィルタおよび検索属性が含まれます。レスポンス・ログ・メッセージには、結果コード、返されたエントリ数、診断メッセージ、一致したDN、認可IDおよびミリ秒単位の処理時間が含まれる場合があります。
アンバインド操作の場合は、リクエスト・メッセージは、アンバインド・リクエストが受信されたことを示すのみです。アンバインド・リクエストに対するレスポンスおよび結果ログ・メッセージはありません。
アカウント有効期限は、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、指定された日付を過ぎると、それ以降アカウントを使用できないことを示すために使用できます。この機能は、指定された日付の後で期限切れとなる一時的なユーザー・アカウント(契約者、インターンまたはその他の一時的な職員用など)の作成に役立ちます。
アカウント有効期限を有効化するには、ターゲット・ユーザーのエントリにds-pwp-account-expiration-time操作属性を追加します。この属性の値は、アカウントの有効期限とする時刻を指定する、一般的な時刻形式のタイムスタンプです。アカウント有効期限の時刻が過ぎると、ユーザーはサーバーに対する認証を許可されません。
アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、バインドの試行に何度も失敗した後でユーザー・アカウントをロックするために使用できます。アカウントがロックされると、ユーザーは認証を許可されません。ロックアウトは、一時的(指定された期間の後で自動的に終了)または永続的(管理者がユーザーのパスワードをリセットするまで有効)にできます。
アカウント・ステータス通知は、サーバーのパスワード・ポリシーに関わる重要な方法でユーザー・アカウントが変更されたことを示すために使用できるメカニズムです。
サーバーで使用可能なアカウント・ステータス通知のタイプには次のものがあります:
ユーザーのアカウントがアカウント・ロックアウトになった場合
ユーザーのアカウントがアカウント・ロックアウトになった場合
ユーザーのアカウントが管理者にロック解除された場合
ユーザーのアカウントが管理者に手動で無効化または再有効化された場合
ユーザーのアカウント有効期限を過ぎている場合
ユーザーのパスワード有効期限を過ぎているか、間もなく有効期限となる場合
ユーザーのパスワードがパスワードのリセットをされた場合
ユーザーのパスワードがエンド・ユーザーにより変更された場合
ディレクトリ・サーバーは、アカウント・ステータス通知を処理するために拡張可能なフレームワークを提供します。デフォルトのハンドラはサーバーのエラー・ログにメッセージを書き出しますが、フレームワークを使用して電子メール・メッセージを送信したり、必要なその他のアクションを実行したりできます。
アカウント・ユーザビリティ制御は、ユーザー・アカウントがサーバーに対する認証に使用できるかどうかを判断するための1組のリクエストとレスポンスの制御を提供します。
リクエスト制御のOIDは1.3.6.1.4.1.42.2.27.9.5.8で、値はありません。検索操作メッセージに含まれるのみです。
対応するレスポンス制御のOIDは1.3.6.1.4.1.42.2.27.9.5.8(リクエスト制御と同様)で、アカウント・ユーザビリティ・リクエスト制御を含む検索リクエストに対する検索結果エントリ・メッセージに含まれます。
アカウント・ユーザビリティ・レスポンス制御の値は、次のようにエンコードされます:
ACCOUNT_USABLE_RESPONSE ::= CHOICE {
is_available [0] INTEGER, -- Seconds before expiration --
is_not_available [1] MORE_INFO }
MORE_INFO ::= SEQUENCE {
inactive [0] BOOLEAN DEFAULT FALSE,
reset [1] BOOLEAN DEFAULT FALSE,
expired [2] BOOLEAN DEFAULT_FALSE,
remaining_grace [3] INTEGER OPTIONAL,
seconds_before_unlock [4] INTEGER OPTIONAL }
ユーザー・アカウントが使用可能な場合は、制御にはユーザーのパスワード有効期限までの秒数または-1(パスワード有効期限が有効ではない場合)が含まれます。ユーザー・アカウントが使用可能でない場合は、制御には使用可能でない理由が示されます。
検索リクエストでこの制御を使用する例は、「アカウント・ユーザビリティ・リクエスト制御を使用した検索」を参照してください。
ACIDは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)および永続性(Durability)を略した頭字語です。この用語は、データベースのトランザクション特性を使用して実現できる特質に関する標準データベース用語です。次の要素があります:
データベースで実行される各トランザクションは原子的です。つまり、完全に成功または完全に失敗のいずれかです。トランザクションの一部の変更が適用されてそれ以外は適用されないような変更は、部分的な成功ではありません。
データベースは常に一貫性のある状態で、コンテンツの整合性が保たれています。トランザクションの成功または失敗に対して、データベースを一貫性のない状態にできないようにする必要があります。
トランザクションの一部として実行される操作は、データベース内で同時に実行されるその他の操作から独立しています。あるトランザクションがデータベース・コンテンツに対するいくつかの変更に使用される場合は、別のトランザクション操作は変更がコミットされるまで変更の結果を確認できないようにする必要があります。
データベースにより、正常に完了し、コミット済と報告されたトランザクションはいずれも、永続的な記憶域での保存が保証されます。ディレクトリ・サーバー、基礎となるJVM、オペレーティング・システムまたはハードウェアで、コミット完了の通知の直後に障害が発生しても、変更は失われません。
主要なバック・エンドのデータ・ストアとして使用されるBerkeley DB Java Editionは、ACID準拠をフル・サポートします。ただし、パフォーマンスの理由により必要があれば、これらの制約に対する準拠を緩和する方法もあります。ディレクトリ・サーバーは、このような柔軟性、特に変更を永続的に保持するための構成に関して公開しています(たとえば、変更をすぐにディスクに出力しないようにサーバーを構成することも可能です。これにより、書出しのパフォーマンスを向上させることができますが、ハードウェアまたはソフトウェアの障害が発生した場合にいくつかの変更を消失する原因になる可能性があります)。
LDAP追加操作は、ディレクトリ・サーバーでのエントリの作成に使用できます。追加リクエストのプロトコルopは次のように定義されます:
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
このリクエストに含まれる要素には、追加するエントリの識別名およびそのエントリに含まれる属性のセットがあります。
LDAP追加操作に対するレスポンスはLDAP結果要素で、次のように定義されます:
AddResponse::= [APPLICATION 9] LDAPResult
別名は、サーバー内の別のエントリを参照する特別なタイプのエントリで、UNIXファイル・システムのシンボリック・リンクによく似ています。aliasオブジェクト・クラス、および別名が参照するエントリのDNと等しい値を持つaliasedObjectName属性が含まれています。
別名は、主に検索操作で使用されます。特に、検索リクエストには、別名を検出する際に使用される間接参照ポリシーを指定する要素が含まれています。使用できる間接参照ポリシーの値には次のものがあります:
サーバーは別名エントリを間接参照しません。
サーバーは、考えられる検索結果エントリのセットで検出した別名エントリを間接参照しますが、検索ベースDNが別名エントリを指定する場合は、間接参照しません。
サーバーは、検索ベース・エントリが別名の場合は間接参照しますが、考えられる検索結果エントリのセット内の別名は間接参照しません。
サーバーは、検索ベース・エントリまたは考えられる検索結果エントリのセットのどちらかで検出された別名を間接参照します。
別名はLDAPv3プロトコルのオプション部分であり、ディレクトリ・サーバーは現在、別名をサポートしていないことに注意してください。
AND検索フィルタは、0個以上のその他の検索フィルタを保持するコンテナとして機能するための、LDAP検索フィルタのタイプです。エントリがANDフィルタと一致するには、ANDフィルタに含まれるすべてのフィルタと一致する必要があります。
ANDフィルタは、フィルタ全体をカッコで囲み、左カッコの直後にアンパサンドを配置した文字列で表すことができます。たとえば、フィルタ(&(objectClass=person)(uid=john.doe))は、(objectClass=person)および(uid=john.doe)の等価フィルタが埋め込まれたAND検索フィルタを表します。
埋込みフィルタを含まないANDフィルタは、LDAP trueフィルタと呼ばれます。LDAP trueフィルタの文字列表現はアンパサンド(&)で、LDAP trueフィルタは常に任意のターゲット・エントリと一致します。
匿名バインドはバインド操作のタイプで、長さ0のバインドDNおよび長さ0のパスワードを使用する簡易認証を使用します。ある接続で実行された直前の認証を破棄し、未認証のステータスを返すために使用できます。
同じ結果となるANONYMOUS SASLメカニズムがありますが、通常は匿名バインドという用語はDNおよびパスワードなしの簡易バインド操作を指すことに注意してください。
ANONYMOUS SASLメカニズムは、Simple Authentication and Security Layer認証メカニズムのタイプです。その他のSASLメカニズムとは未認証セッションの作成に使用される点で異なっており、接続で実行された可能性のある直前の認証を破棄します。
ANONYMOUS SASLメカニズムは、サーバーのアクセス・ログに含めることのできるリクエストに追跡情報を追加する機能があります。この追跡情報は、バインドを実行するクライアントの情報を提供できます。ただし、認証が実行されていないため、追跡情報の有効性は保証できません。
近似索引は、指定されたアサーション値におおよそ等しいエントリを効率的に識別するために使用される索引のタイプです。近似索引は、対応する近似一致ルールを保有する属性に対してのみ維持できます。この一致ルールは索引キーとして使用する正規化された値に対して使用され、そのキーの値は、正規化された値におおよそ等しい値を持つエントリのエントリIDを含むIDリストです。
近似検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値におおよそ等しい、指定された属性の値を含むエントリを識別するために使用できます。サーバーは、近似一致ルールを使用して判断します。
LDAP近似フィルタの文字列表現は、左カッコに続く属性名、チルダ記号、等号、属性値および右カッコで構成されます。たとえば、近似フィルタ(givenName~=John)は、Johnとおおよそ等しい値を含むgivenName属性のエントリと一致します。
「抽象構文表記法1」を参照してください。
属性は値の名前付きセットです。属性は属性説明を保有し、その内容には、その属性の名前(属性タイプに関連付けられた名前)、属性オプションのオプション・セットおよび1つ以上の値の集合が含まれます。
エントリには属性の集合が含まれます。エントリが、同じ属性タイプで異なるオプション・セットを伴う複数の属性を持つことは可能です。
属性説明は、エントリ内で指定された属性を識別するために使用されます。属性説明には、属性タイプに関連付けられた名前またはOID、および0個以上の属性オプションが含まれます。属性説明に任意の属性オプションが含まれている場合は、属性名またはOIDとはセミコロンで区切られ、その属性説明に複数のオプションが含まれている場合は、個々の属性オプションもセミコロンを使用して区切られます。
属性オプションは、属性の解釈方法についての追加情報を指定するタグの種類です。属性説明には、属性名またはオブジェクト識別子とそれに続く0個以上の属性オプションが含まれます。属性オプションが複数存在する場合は、属性名と、および各属性オプションとは互いにセミコロンを使用して区切られます。たとえば、属性説明userCertificate;binaryでは、属性名はuserCertificateで、属性オプションはbinaryです。
属性オプションは、サーバーが属性を取り扱う方法についての情報(RFC 4522 (http://www.ietf.org/rfc/rfc4522.txt)で説明されるバイナリ・エンコーディング・オプションなど)の提供を含め、いくつかの目的に使用できます。また、属性オプションはいくつかの形式でクライアントにも利点があります(たとえば、RFC 3866 (http://www.ietf.org/rfc/rfc3866.txt)で説明される言語タグ・オプションは、異なる言語での属性値の指定を可能にします)。
属性構文は、スキーマ要素であり、属性値に保存できる情報の種類を指定するためのデータ・タイプの種類を定義します。関連付けられた属性タイプの構文に違反する属性値を保存しようとすると、却下されます。
一般的な属性の構文には次のものがあります:
テキスト情報かどうかにかかわらず、任意の種類のデータを保持することが可能で、バイト対バイト・ベースで比較する必要があります。オクテット文字列構文が優先され、バイナリ構文は非推奨になっていることに注意してください。
TRUEまたはFALSEのいずれかの値を保持できます。
任意の種類の文字列値を保持できます(技術的にはバイナリ値も許容されますが、通常、ディレクトリ文字列値は文字列です)。
有効な識別名の値を保持できます。
タイムゾーン情報および有効桁数が変化するタイムスタンプ(時から秒の小数部までの任意の部分)を含む値を保持できます。たとえば、値20070525222745Zは、UTCタイムゾーンで2007年5月25日午後10時27分45秒のタイムスタンプを表します。
ASCII文字列を含む値を保持できます(つまり、非ASCII文字の使用は許可されません)。
整数値を保持できます。正数、負数および0の値も可能です。
任意の種類のデータの保持が可能で、バイト対バイト・ベースで比較する必要があります。
複数行の住所の保持が可能で、住所の行はドル記号で区切られます。
印刷可能な文字を任意に組合せた文字列を保持できます。印刷可能な文字には、すべてのASCII文字の大文字と小文字、数字、空白および記号'()+,-.=/:?が含まれます。
電話番号の値を保持できます。
サーバーで定義される属性構文のセットは、サブスキーマ・サブエントリのldapSyntaxes属性を取得して確認できます。属性構文の詳細は、「属性構文の理解」を参照してください。
属性タイプはスキーマ要素であり、オブジェクト識別子、属性構文を伴う名前のセットおよび一致ルールのセットに関連付けられます。
属性タイプのコンポーネントの定義は次のとおりです:
属性タイプを一意に識別するために使用されるOID。
属性タイプの参照をより容易にするために使用できる0個以上の名前のセット。
属性の値に対する等価一致の実行方法を指定する、オプションの等価一致ルール。等価一致ルールが指定されない場合は、デフォルトの等価ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの等価一致ルールが存在しない場合は、その属性に対する等価操作は許可されません。
属性の値に対する順序付け操作の実行方法を指定する、オプションの順序付け一致ルール。順序付け一致ルールが指定されない場合は、デフォルトの順序付けルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの順序付け一致ルールが存在しない場合は、その属性に対する順序付け操作は許可されません。
属性の値に対する部分文字列一致の実行方法を指定する、オプションの部分文字列一致ルール。部分文字列一致ルールが指定されない場合は、デフォルトの部分文字列ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの部分文字列一致ルールが存在しない場合は、その属性に対する部分文字列操作は許可されません。
属性の値に対する構文を指定する、オプションの構文OID。構文が指定されない場合は、ディレクトリ文字列構文にデフォルト設定されます。
属性が複数の値を持つことを許可されているかどうかを示すフラグ。
属性が使用されるコンテキストを示す、オプションの属性使用方法文字列。
外部クライアントが属性を変更できるかどうかを示す、オプションのフラグ。
サーバーで定義される属性タイプのセットは、サブスキーマ・サブエントリのattributeTypes属性を取得して確認できます。属性タイプの詳細は、「属性タイプの理解」を参照してください。
属性タイプの属性使用方法は、属性タイプを使用できるコンテキストを定義します。属性使用方法には、次の4つのタイプがあります:
ユーザー定義データの保持に使用するためのすべての属性タイプで使用されます。
サーバー内の暗黙的な処理のための属性タイプで使用されます。
ディレクトリ環境全体に配布する必要のある操作データ(つまりレプリケーション)を保管する属性タイプで使用されます。
1台のサーバーのみで保管し、ディレクトリ環境全体にレプリケートしてはならない操作データを保管する属性タイプで使用されます。
使用方法userApplicationsを持つ属性は、いわゆるユーザー属性です。使用方法directoryOperation、distributedOperationまたはdSAOperationを持つ属性は、いわゆる操作属性です。
属性値は、属性により保持される実データの要素を示します。関連付けられた属性タイプにより許可された場合は、属性は複数値を保有できます。サーバーが属性値と相互に作用する方法は、属性の属性構文および一致ルールにより制御されます。
属性値アサーション(AVA)は、属性説明および属性値の組合せです。アサーション値は、判断のために一致ルールとともに使用されます。一致ルールが等価一致ルールの場合は、属性に指定された値が含まれているかどうかの判断に使用されます。順序付け一致ルールの場合は、AVAは、アサーション値以上の値または以下の値が属性に含まれているかどうかの判断に使用されます。近似一致ルールの場合は、AVAは、アサーション値におおよそ等しい値が属性に含まれているかどうかの判断に使用されます。部分文字列一致はより複雑で、簡易アサーション値ではなく部分文字列アサーションを使用します。
属性値アサーションはLDAP比較操作および等価検索フィルタ、大きいか等しい検索フィルタ、小さいか等しい検索フィルタおよび近似検索フィルタの検索フィルタで使用されます。
監査ログは特別なタイプのアクセス・ログで、サーバーで実行されるすべての変更の情報をログに記録するために使用されます。これらの変更のログはLDAPデータ変換形式で記録され、管理者は実行された変更を正確に確認できます。この情報は、問題を調査する際に診断のために使用可能で、アプリケーションがディレクトリで実行する可能性のある変更の種類をより理解しやすくし、別のリポジトリに対するリプレイの変更について正しい情報を得るために役立ちます。
監査ログという名前は、Netscape Directory Serverでの監査ログの使用を指すレガシー用語です。セキュリティ監査で使用される場合のあるログと混同しないでください。監査ログは、ディレクトリ・データに対する変更を記録するのみで、認証の試行の成功または失敗などは追跡しません。ただし、多くの場合、従来のアクセス・ログおよび監査ログの内容を組み合せて使用し、このような種類の情報を取得できます。必要に応じて、管理者はカスタム・アクセス・ログを実装して、希望する種類の情報の追跡もできます。
認証は、クライアントがクライアント自体をディレクトリ・サーバーに認証要求し、アイデンティティを証明するプロセスです。LDAPでは、バインド操作を使用して実行されます。
認証プロセスには次の2つのフェーズがあります:
クライアントは、いくつかの方法でクライアント自体をサーバーに認証要求します。簡易認証では、バインド・リクエストで指定されたDNがこのために使用されます。Simple Authentication and Security Layer認証では、クライアントのアイデンティティはその他いくつかの方法(証明書、Kerberosプリンシパルまたはその他数種類の識別子の使用など)で取得されます。
クライアントは、クライアント自体の認証要求をしたユーザーが誰であるかを十分に証明する必要があります。簡易認証では、パスワードを使用して実行されます。SASL認証では、この検証は関連付けられたメカニズム固有の方法で取得されます(パスワード、証明書またはその他の証明の形式の場合があります)。
他のメカニズムよりも厳格であるとみなされる認証メカニズムもあります。たとえば、クライアントの保有するパスワードの推測やその他の方法による取得が容易である場合は、簡易認証はより信頼性が低いと考えられ、証明書またはKerberos資格証明を使用した認証はより厳格でねつ造は困難であると考えられる可能性があります。ディレクトリ・サーバーのアクセス制御を実装すると、リクエストされた操作を許可するかどうかを判断する際に、クライアントの認証メカニズムを考慮するように構成できます。
認証IDは、Simple Authentication and Security Layerメカニズムの特定の種類(CRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズムおよびPLAIN SASLメカニズムなど)で、クライアント自体をディレクトリ・サーバーに認証要求するクライアントに使用される識別子です。認証IDを使用して、識別名ではなくユーザー名(またはその他のわかりやすい識別子)でクライアントがクライアント自体を認証要求できます。
多くの場合、認証IDは次の形式のうちの1つに指定されます:
文字列dn:とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認証アイデンティティとする必要がある場合は、文字列dn:のみ)。
文字列u:とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。
認証パスワード構文は、サーバーの記憶域用のユーザー・パスワードをエンコードする標準メソッドを定義します。パスワードのクリアテキスト値の確認を困難あるいは不可能にする方法をお薦めします。
認証パスワード構文はRFC 3112 (http://www.ietf.org/rfc/rfc3112.txt)で説明されており、そこではauthPassword属性タイプ、およびその属性が使用可能な、対応するauthPasswordObject補助オブジェクト・クラスを定義します。
認証パスワード構文を使用してエンコードされるパスワードの基本的な形式は次のとおりです:
scheme $authInfo $ authValue
schemeは値のエンコードに使用されるスキームの名前、authInfoはエンコーディング処理で使用される数種類の修飾子(saltなど)、およびauthValueはエンコードされるパスワードの情報です。たとえば、値SHA1$RzqH67DY3uQ=$atAcDs1eS+IJwPy7V4UDXEoBrDI=を認証パスワード構文を使用してエンコードします。スキームはSHA1、authInfo要素はRzqH67DY3uQ=、authValue要素はatAcDs1eS+IJwPy7V4UDXEoBrDI=です。
ディレクトリ・サーバーでサポートされている認証パスワード・スキームには、次のものがあります:
MD5メッセージ・ダイジェストを使用します。
セキュア・ハッシュ・アルゴリズムのSHA-1バリアントを使用します。
セキュア・ハッシュ・アルゴリズムの256ビットSHA-2バリアントを使用します。
セキュア・ハッシュ・アルゴリズムの384ビットSHA-2バリアントを使用します。
セキュア・ハッシュ・アルゴリズムの512ビットSHA-2バリアントを使用します。
認可は、リクエストされた操作の実行をユーザーが許可されているかどうかを判断するプロセスです。次のような様々なサーバー・コンポーネントが認可プロセスに関わっています:
認可IDは、クライアントに使用される識別子で、代替認可アイデンティティの下で実行される1つ以上の操作を示します。この代替認可アイデンティティは、1つの操作の間(プロキシ認可制御とともに使用される場合)または認証セッションが継続している期間(DIGEST-MD5 SASLメカニズム、GSSAPI SASLメカニズムまたはPLAIN SASLメカニズムなどのSASLに近いメカニズムとともに使用される場合)、継続できます。
多くの場合、認可IDは次の形式のうちの1つに指定されます:
文字列dn:とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認可IDとする必要がある場合は、文字列dn:のみ)。
文字列u:とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。
代替認可アイデンティティを使用するクライアントの機能は、proxied-auth特権で制御されます。追加のアクセス制御権限が要求される場合もあります。
認可アイデンティティ制御は、RFC 3829 (http://www.ietf.org/rfc/rfc3829.txt)で定義される1組のリクエスト制御とレスポンス制御で、バインド操作とともに使用して、クライアント接続のための認可アイデンティティをクライアントが確認できるようにします。
認可アイデンティティ・リクエスト制御のオブジェクト識別子は2.16.840.1.113730.3.4.16で、値はありません。認可アイデンティティ・レスポンス制御のOIDは2.16.840.1.113730.3.4.15で、その制御の値は、その接続の認可アイデンティティを表す文字列(または匿名ユーザーの認可アイデンティティの場合は空の文字列)です。レスポンス制御は、認証が成功した場合にのみ、レスポンスに追加されます。
認可アイデンティティ制御は、LDAPバインド操作と一緒の場合にのみ使用できるため、クライアントが認可された後は使用できないことに注意してください。Who Am I拡張操作を使用して、バインドが完了した後でいつでも、認可アイデンティティを取得できます。
検索リクエストでこの制御を使用する例は、「認可アイデンティティ・リクエスト制御を使用した検索」を参照してください。
補助オブジェクト・クラスは、エントリのコア・タイプを定義するものではありませんが、エントリの追加特性を定義します。1つのエントリは、0個以上の補助オブジェクト・クラスを持つことができます。エントリで使用できる補助クラスのセットは、エントリの構造オブジェクト・クラスに関連付けられたDITコンテンツ・ルールにより制御される場合があります。
「属性値アサーション」を参照してください。
ディレクトリ・サーバーのバックエンドは、データを保管するリポジトリ、およびデータと相互に作用するためのロジックのセットを提供します。通常バックエンドには数種類のデータベースがあり、様々な操作でバックエンドが迅速にエントリを見つけられるように索引のセットが維持される場合があります。すべてのバックエンドには次のような特質があります:
バックエンドIDは、サーバー内のその他すべてのバックエンドから、該当のバックエンドを一意に識別します。
1つ以上のベース識別名のセットは、バックエンドが保持するデータを示します。
書込み可能モードは、バックエンドが書込み操作を許可するかどうかを示します。
バックエンドが提供するロジックには次のものがあります:
DNに基づき、指定されたエントリが存在するかどうかを判断するメソッド
DNに基づき、エントリを取得するメソッド
データベースに新規のエントリを追加するメソッド(LDAP追加操作の処理の一部として)
データベースから既存のエントリを削除するメソッド(LDAP削除操作の処理の一部として)
データベースでエントリを置換するメソッド(LDAP変更操作の処理の一部として)
データベースでエントリの名前を変更するメソッド(LDAP DN変更操作の処理の一部として)
LDAP検索操作を処理するメソッド
LDAPデータ変換形式でデータベースのコンテンツをエクスポートするメソッド
LDAPデータ変換形式でデータベースにデータをインポートするメソッド
データのバックアップを実行するメソッド
以前のバックアップの復元を実行するメソッド
バックアップは、ディレクトリ・サーバーのバックエンド内でデータが移動可能であることを表します。各バックエンドは、そのコンテンツのバックアップが可能かどうかを制御し、バックアップ情報が後で実行される復元に適していることを確認します。バックアップする(back up)という用語は動詞(バックエンドのコンテンツをバックアップするアクション)であり、バックアップ(backup)は名詞(バックアップを実行して取得されるもの)であることに注意してください。
バックエンドがバックアップ・メカニズムを提供できない理由がいくつかあります。理由には次のものがあります:
バックエンドには一時的な、ある時点の情報のみが存在し、この情報をアーカイブしたり、後で復元を試みたりすることは意味がありません(ルートDSEまたは監査バックエンドなど)。
バックエンドは直接アーカイブできないリモート・リポジトリに情報を保存します。このような場合は、外部リポジトリには通常、それ自体のバックアップおよび復元メカニズムがあります。
ディレクトリ・サーバーが使用する主要なバックエンドは、Berkeley DB Java Editionを使用しており、その基礎となるデータベースおよびバックエンドは完全なバックアップ機能と復元機能を提供します。また、そのバックアップ・メカニズムは移植性が高く、異なるプラットフォーム、異なるファイルシステムの場所に転送が可能で、バイナリ・コピー・メカニズムとしての使用に適しています。
Base64エンコーディングは、テキストのみの形式でバイナリ・データを表す方法です。通常、非ASCII文字を含む値または不明瞭になる可能性のある値(空白で開始または終了する値など)に対して、LDAPデータ変換形式で使用されます。また、証明書のコンテンツや、MD5またはセキュア・ハッシュ・アルゴリズムなどのメッセージ・ダイジェストの出力をエンコードするために頻繁に使用されます。base64エンコーディングは、RFC 1341 (http://www.ietf.org/rfc/rfc1341.txt)の第5.2項で説明されています。
base64エンコーディングの基本原則は、次の文字を含む64文字のアルファベットを指定された順序で定義することです:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
これらの各文字に、リスト内の位置に基づいて0から63の間の数値が割り当てられています(つまり、Aは0、Bは1、Cは2、...+は62および/は63)。値は6ビットのセグメントに細分化され、各6ビットのセグメントは0から63の間の数値に変換され、前述のように指定されたアルファベットから指定された文字に置換されます。これは、バイナリ値の各3バイトがbase64アルファベットの4文字に変換されることを意味します。バイナリ値の長さが3バイトの倍数でない場合は、0を充当し、base64でエンコードされた値の最後に1つまたは2つの等号を付与します。
基本エンコーディング・ルール(BER)は、抽象構文表記法1エンコーディング・ルールのセットで、情報をバイナリ形式でエンコードする特定の方法を定義します。メッセージをエンコードする基礎的なメカニズムとして使用されます。
多くのネットワーク・プロトコルはテキストベースで、ネットワークのトラフィックを調べる場合に比較的理解しやすいという利点があります。多くの場合、ターゲット・サーバーにtelnet接続して適切なコマンドを入力することによって、ターゲット・サーバーと対話することさえできます。ただし、一般的に、必要以上に冗長で解析が非効率であることなど短所もあります。一方、その他のプロトコルでは、より簡潔で効率的なバイナリ・エンコーディングを使用しています。LDAPはこのカテゴリに属しており、ASN.1(抽象構文表記法1)メカニズム、具体的にはASN.1の種類であるBER(基本エンコーディング・ルール)を使用します。その他にもASN.1に含まれる多くのエンコーディング・ルール(DER、PERおよびCERなど)がありますが、LDAPではBERを使用します。
この項では特にLDAPで使用されるBERのサブセットについて説明し、その他の場合については説明していません。
BER要素はTLV構造を使用し、TLVはタイプ(type)、長さ(length)および値(value)の略です。つまり、次の項で説明するとおり、各BER要素は、1バイト以上で示される要素のデータ・タイプ(通常LDAPでは1バイトのみ)、1バイト以上で示される値の長さ、0バイト以上の値自体のエンコードされた値(エンコードされた値の形式はデータ・タイプに依存)を保有します:
BERタイプ
BERの長さ
BERの値
BERタイプは要素の値のデータ・タイプを示します。BERの仕様では数種類のデータ・タイプがありますが、LDAPで最も一般的に使用されるものにはOCTET STRING(テキスト文字列またはバイナリ・データのいずれも可能)、INTEGER、BOOLEAN、NULL、ENUMERATED (integerと似ているが、各値が特別な意味を保有)、SEQUENCE(配列のように、順序付けられたその他の要素の集合)およびSET(順序に意味を持たない点を除けばsequenceと同様)があります。CHOICE要素もありますが、通常、複数の異なる種類の要素のうち1つを許可します。
通常、BERタイプは1バイトのみで、このバイトにエンコードされたデータが含まれています。2つの最も重要なビット(一番左の2ビット、BERではビッグ・エンディアン/ネットワーク順序を使用するため)が、次のクラス値により、要素のクラスを示すために使用されます:
ユニバーサル・クラス。ほとんどのBER要素はユニバーサル・タイプを保有するため、ユニバーサル・タイプを保有する要素は保持するデータの種類を指定します。ユニバーサル・タイプの例には、0x01 (BOOLEAN)、0x02 (INTEGER)、0x04 (OCTET STRING)、0x05 (NULL)、0x0A (ENUMERATED)、0x30 (SEQUENCE)および0x31 (SET)があります。これらのタイプの値すべてのバイナリ・エンコーディングで、一番左の2ビットを0に設定します。
アプリケーション固有クラス。このクラスは、アプリケーション全体を通して一貫性のある独自のタイプを、アプリケーションで定義できます。このコンテキストでは、LDAPはアプリケーションとみなされます。たとえば、LDAPで0x42が出現した場合は、アンバインド・リクエスト・プロトコルopを示します。なぜなら、RFC 2251の第4.3項(https://tools.ietf.org/html/rfc2251#section-4.3)で説明されるように、アンバインド・リクエスト・プロトコルopには[APPLICATION 2]タイプがあるためです。
コンテキスト固有クラス。このクラスは、指定されたアプリケーション内の特定の使用方法に固有のタイプであることを示します。指定された状況で、適用するコンテキストを判断するための情報が十分であれば、同じタイプを同じアプリケーションの異なるコンテキストで再使用することもできます。たとえば、バインド・リクエスト・プロトコルopの資格証明のコンテキストで、コンテキスト固有のタイプ0x80がバインド・パスワードの保持に使用されますが、拡張操作のコンテキストでリクエストOIDの保持に同じタイプが使用される場合があります。
プライベート・クラス。LDAPでは通常使用されません。
次のビット(左から3番目)はプリミティブ/コンストラクテッド・ビットです。0(オフ)に設定されている場合は、その要素はプリミティブとみなされ、データ・タイプのルールに応じて値がエンコードされます。1(オン)に設定されている場合は、エンコードされた形式で一緒に連結された0個以上のほかのASN.1要素から、値が構築されることを意味します。たとえば、ユニバーサルSEQUENCEタイプの0x30の場合は、バイナリ・エンコーディングは00110000で、プリミティブ/コンストラクテッド・ビットは1に設定されており、sequenceの値が0個以上のエンコードされた要素から構築されることを示します。
BERタイプのバイトの最後の5ビットはそのタイプの値を指定し、単純な整数値として取り扱われます(00000は0、00001は1、00010は2、00011は3など)。唯一の特別な値は11111で、タイプの値が、使用可能な5ビットに収まらない大きな値であり、複数のバイトが必要であることを意味します。この値はLDAPでは使用されません。
BER要素のTLV構造で、2番目のコンポーネントは長さです。これは、エンコードされた値のサイズをバイト単位で指定します。ほとんどの場合は、ここでは整数値のバイナリ・エンコーディングをそのまま使用します(たとえば、エンコードされた値が5バイト長の場合は、バイナリで00000101または16進数で0x05とエンコードされます)が、値が127バイトよりも長い場合は、長さのエンコーディングに複数のバイトが必要です。その場合、第1バイトの一番左のビットを1に設定し、残りの7ビットを長さ全体のエンコーディングに必要なバイト数を指定するために使用します。たとえば、500バイトの長さ(16進数で0x01F4)の場合は、エンコードされた長さは実際には次の3バイトで構成されます: 82 01 F4。
長さをエンコードするための別の形式として、いわゆる不特定形式があることに注意してください。このメカニズムでは、長さの一部のみが一度に指定され、HTTP 1.1で使用可能なチャンク・エンコーディングに似ています。ただし、RFC 2251第5.1項(https://tools.ietf.org/html/rfc2251#section-5.1)で説明されるように、LDAPではこの形式は使用されません。
BER要素には要素の実データが含まれます。BERはバイナリ・エンコーディングのため、このエンコーディングには、データを簡潔な形式で表現できるという利点があります。したがって、各データ・タイプは、次のようにデータ・タイプ自体のエンコードされた形式を持っています:
NULLNULL要素には値がなく、そのため長さは常に0です。
OCTET STRINGこの要素の値は、表現するデータの未処理のバイトを連結したものとしてエンコードされます。たとえば、文字列Helloを表すには、エンコードされた値は48 65 6C 6C 6Fになります。値の長さを0バイトにすることもできます。
BOOLEANこの要素の値は常に1バイトです。そのバイトのすべてのビットが0 (0x00)に設定されている場合は、値はFALSEです。1つ以上のビットが1に設定されている場合は、値はTRUEです。その結果、TRUEのBOOLEAN値をエンコードする方法が255通りありますが、実際には、通常0xFF(つまりすべてのビットを1に設定)としてエンコードされます。
INTEGERこの要素の値は、2の補数形式のバイナリ整数としてエンコードされます。BER自体はエンコードできる値の大きさに制限を設けていませんが、多くのソフトウェアの実装では4バイトまたは8バイト(つまり32ビットまたは64ビットの整数値)の制限があり、通常LDAPでは最大4バイトを使用します(プラスマイナス20億の範囲で値をエンコードできます)。値には常に少なくとも1バイトがあります。
ENUMERATEDこの要素の値は、INTEGER要素の値とまったく同じ方法でエンコードされます。
SEQUENCEこの要素の値は、sequenceに含まれるエンコードされたBER要素を単純に連結したものです。たとえば、テキストHelloおよびthereをエンコードする2つのオクテット文字列要素を持つsequenceをエンコードすると、エンコードされたsequence値は04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65です。sequenceに要素がない場合は、sequence値は0バイトになります。
SETこの要素の値は、SEQUENCE要素の値とまったく同じ方法でエンコードされます。
前述のSEQUENCE値のエンコーディングの例では、2つの完全なBER要素が連結されています。文字列HelloおよびthereのOCTET STRING表現は次のとおりです:
04 05 48 65 6C 6C 6F 04 05 74 68 65 72 65
どちらのケースでも、最初のバイトはタイプ(0x04、ユニバーサル・プリミティブOCTET STRINGタイプ)で、2番目のバイトは長さ(0x05、値が5バイトであることを示す)です。残りの5バイトは文字列Helloおよびthereをエンコードした表現です。
次の例では、ユニバーサルINTEGERタイプのかわりにコンテキスト固有のタイプ値である5を使用して、整数値3をエンコードします:
85 01 03
次の例では、RFC 2251第4.2項(https://tools.ietf.org/html/rfc2251#section-4.2)で定義されるLDAPバインド・リクエスト・プロトコルopをエンコードします。この要素の簡易BNF表現は次のとおりです:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name OCTET STRING,
authentication CHOICE {
simple [0] OCTET STRING,
sasl [3] SEQUENCE {
mechanism OCTET STRING,
credentials OCTET STRING OPTIONAL } } }
この例では、パスワードpasswordを持つユーザーcn=testに対する簡易認証を使用したバインド・リクエストをエンコードします。このバインド・リクエスト・プロトコルopの完成したエンコーディングは次のとおりです:
60 16 02 01 03 04 07 63 6E 3D 74 65 73 74 80 08 70 61 73 73 77 6F 72 64
分析すると、このバイト文字列には次の情報が含まれています:
最初のバイトは0x60で、バインド・リクエスト・プロトコルopのBERタイプです。定義の一部である[APPLICATION 0] SEQUENCEに由来します。アプリケーション固有であることから、クラス・バイトは01、SEQUENCEであることから、コンストラクテッドです。タイプ値0と合せると、バイナリ表現では01100000、16進数では0x60です。
2番目のバイトは0x16で、バインド・リクエスト・シーケンスの長さを示しています。16進数0x16は10進数の22で、0x16の後のバイト数は22です。
次の3バイトは02 01 03で、3のユニバーサルINTEGER値です。バインド・リクエスト・シーケンスのバージョン・コンポーネントに対応し、LDAPv3バインド・リクエストであることを示しています。
次の9バイトは04 07 63 6E 3D 74 65 73 74で、テキストcn=testを含むユニバーサルOCTET STRINGです。バインド・リクエスト・シーケンスの名前コンポーネントに対応しています。
最後のコンポーネントは80 08 70 61 73 73 77 6F 72 64で、タイプcontext-specific primitive 0、長さ8バイトの要素です。バインド・リクエスト・プロトコルopの定義の説明に従って、context-specificは簡易認証タイプにマップされ、OCTET STRINGとして取り扱う必要があります。値の8バイトはエンコードされた文字列passwordを表します。
「基本エンコーディング・ルール」を参照してください。
Berkeley DB Java Edition (Berkeley DB JE、BDBJEまたはJEとも呼ばれる)は、オラクル社が買収したSleepycat Software社により設計されたpure Javaデータベースです。高いスケーラビリティおよびパフォーマンス、完全なACIDセマンティクスをサポートしたトランザクションBツリー・データベースを提供し、ユーザー・データの保管のための主要なデータベースとして使用されます。
ディレクトリ・サーバーは、情報の保管のために、Berkeley DB Java Editionを使用するバックエンドを提供します。このバックエンドはJEバックエンドまたは単にJEBとよく呼ばれます。バックエンドは、複数の個別のデータベースで構成されるBerkeley DB Java Edition環境を使用します。id2entryデータベースは、エントリIDの値をエントリのコンテンツにマッピングするためのメカニズムを提供します。その他のデータベースは、様々なタイプの操作を処理するエントリ・コンテンツを迅速に見つけるために使用できる索引として機能します。
バイナリ・コピーは、1つのサーバー・インスタンスのディレクトリ・サーバー・バックエンドのバックアップおよびサーバーの別のインスタンスへのバックエンドの復元を実行するプロセスを指します。これにより、迅速な障害時リカバリ・メカニズムを実現し、レプリカ初期化メカニズムとしても使用できます。
すべてのディレクトリ・サーバー・バックエンドがバイナリ・コピーの使用をサポートする必要はなく、状況によってはサポートしない場合もあります。ディレクトリ・サーバーで使用される主要なバックエンドのタイプはBerkeley DB Java Editionの使用に基づいており、Berkeley DB Java Editionは、異なるオペレーティング・システム、CPUアーキテクチャ間で、異なるファイルシステム上の場所を使用する、バイナリ・コピー・メカニズムの使用をサポートします。ただし、どちらのサーバーも同じベース識別名のセットおよび定義された同じ索引のタイプを持つ必要があります。
LDAPバインド操作は、ディレクトリ・サーバーへの認証に使用できます。バインド操作には次の2つの基本的なタイプがあります:
簡易バインド操作は、サーバーへの認証にバインドDNおよびパスワードを必要とする簡易認証を使用します。
SASLバインド操作は、クライアントを認証するSimple Authentication and Security Layerを使用し、選択されたSASLメカニズムに基づく様々なタイプの資格証明を使用できます。
バインド・リクエストのプロトコルopは次のように定義されます:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
リクエストの要素には次のものがあります:
LDAPプロトコルのバージョン。使用可能な値は2および3です。ただし、LDAPv2は旧式のプロトコルとして分類されており、使用はお薦めしません。
バインドDN。簡易認証では常に使用され(ただし、匿名の簡易認証では文字列の長さが0の場合もあります)、一般にSASL認証では使用されません。
資格証明。提供される資格証明のタイプは、認証のタイプに基づいて変わります。
簡易認証では、資格証明はターゲット・バインドDNに対するパスワード、または匿名の簡易認証では空の文字列です。
SASL認証では、資格証明には使用するSASLメカニズムの名前が含まれ、オプションで、SASLメカニズムに適したエンコード済の資格証明情報が含まれる場合もあります。
LDAPバインド操作に対するレスポンスは、次のように定義されます:
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
バインド・レスポンスにはLDAP結果オブジェクトの要素が含まれ、認証のタイプが該当すれば、サーバーSASL資格証明のセットも含まれる場合があることを示します。
LDAP取消し拡張操作は、実行中の操作の処理をサーバーが停止するようにリクエストするために使用できるという点で、コアLDAP中止操作に類似した機能を提供する拡張操作です。中止操作より優れた取消し拡張操作の主要な利点は、取消しリクエストおよび取り消される操作の両方に対してレスポンスの取得が保証されることです。しかし、中止リクエストに対するレスポンスはなく、中止される操作に対するレスポンスがない場合があります。
取消し拡張操作はRFC 3909 (http://www.ietf.org/rfc/rfc3909.txt)で定義されています。取消しリクエスト拡張操作の値は次のようにエンコードされます:
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
-- MessageID is as defined in [RFC2251]
}
証明書は、非対称暗号化を実行するために使用できる公開鍵暗号の要素です。特に証明書は、1組の鍵(それぞれ公開鍵および秘密鍵と呼ばれる)で構成され、公開鍵で暗号化された任意のデータを秘密鍵で復号化できるように関連付けられています。RSAなど多くの公開鍵アルゴリズムを使用して、秘密鍵で暗号化された任意のデータを公開鍵で復号化できるように、その反対も可能です。
証明書という用語には、使用されるコンテキストに基づいて異なる意味があります。多くの場合、公開鍵のみを指します(特に、サーバーがクライアントに証明書を提示する場合は常に、またはクライアントがサーバーに証明書を提示する場合は、公開鍵のみが含まれます)。ただし、その他のケースでは、秘密鍵を含みます(たとえば、サーバーがクライアントとの保護された通信チャネルを確立するために秘密鍵の使用を要求したり、クライアントがサーバーに対してクライアント自体の証明書を送信するために秘密鍵へのアクセスを必要としたりします)。
ディレクトリ・サーバーでは、証明書には2つの主要な用途があります。1つ目は、通常、Secure Sockets LayerまたはTLS起動拡張操作の使用を介して、保護された通信メカニズムを提供するためです。この場合は、ネゴシエーション・プロセスで、サーバーのみが公開鍵を使用して復号化できるように、サーバーの公開鍵を使用したクライアントの暗号化情報が必要とされ、その情報は通信を確認できる可能性のあるサード・パーティには公開されません。証明書はデータの署名にも使用される場合があり、この場合は、サーバーが秘密鍵を使用して情報を暗号化し、クライアントはサーバーの公開鍵を使用してその情報を復号化できた場合に、サーバーからの正当なデータであることを確認します。
証明書マッパーは、指定されたクライアント証明書に対応する、ディレクトリ・サーバーのユーザーを識別するために必要なロジックを提供します。マッピングでは証明書に含まれる情報を使用する可能性があります。ただし、証明書マッパーの多くは、主に証明書のサブジェクト(証明書の名前で、多くの属性値のペアで構成されており、LDAP識別名とよく似ています)に基づいています。
ディレクトリ・サーバーで使用可能な証明書マッパーの詳細は、Certificate Mapper Configuration(http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/certificate-mapper.html)を参照してください。
チェーンは、ローカル・サーバーの一部のように見えるリモート・ディレクトリ・サーバー・インスタンスでのデータ作成のメカニズムを提供します。つまり、チェーンを使用して、別のサーバーからのデータを使用したディレクトリ情報ツリーの一部を表示します。DITのチェーン部分のデータに対してサーバーが受信するリクエストは、そのリクエストを実際に含むサーバーに透過的に転送されます。
変更ログは特別な種類のデータベースで、ディレクトリ・サーバー・インスタンスで発生する変更の追跡に使用されます。変更ログには、次の2つの異なる種類があります:
レプリケーション変更ログは、レプリケーションに必要な形式で変更情報を保管します。
LDAPアクセスの可能な変更ログは、ディレクトリ環境で発生した変更をクライアントが確認できるdraft-good-ldap-changelogで指定される形式でデータを表示します。
「ディレクトリ・マネージャ」を参照してください。
集合属性は特別なタイプの仮想属性で、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)で定義されています。集合属性を使用して、サブエントリ内のエントリのメンバーシップに基づく属性に対して、割り当てる値を定義できます。
Common Development and Distribution License (CDDL)は、OSI (http://www.opensource.org/)に承認されたオープン・ソース・ライセンスで、Oracle Unified DirectoryのOpenDSプロジェクトで使用されます。
CDDLはファイルベースのライセンスで、プロジェクト内のファイルに対するすべての変更は、CDDLの下でライセンスされている必要があることを意味します。ただし、新規のファイルは、作成者の選択する任意のライセンス(クローズドソース・ライセンスも含む)の下でライセンスされる場合があります。CDDLはMozilla Public License (MPL)に基づき、特許権の対象となる技術がこのコードを使用するその他のプロジェクトに対して許可されるように、特許許可条項を含んでいます。
CDDLライセンスの内容は、http://www.opensource.org/licenses/cddl1.php (http://www.opensource.org/licenses/cddl1.php)を参照してください。
LDAP比較操作は、特定のエントリに指定された属性値が含まれるかどうかの判断に使用できます。比較リクエストのプロトコルopは次のように定義されます:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
リクエストの要素には次のものがあります:
比較が実行されるエントリのDN。
比較が実行される属性の名前。
指定された属性で検索するアサーション値。
LDAP比較操作に対するレスポンスは、LDAP結果要素で、次のように定義されます:
CompareResponse ::= [APPLICATION 15] LDAPResult
接続ハンドラはディレクトリ・サーバーのコンポーネントで、クライアントからの接続の許可、クライアントにより実行されたリクエストの読取りと解析、サーバーによる処理の確認およびクライアントに返す対応するレスポンスの送信を実行します。接続ハンドラはクライアントとの通信をすべて管理するため、関連付けられたプロトコルのサポートを実装する必要があります。
ディレクトリ・サーバーが現在提供するのは、Lightweight Directory Access ProtocolおよびJava Management Extensionsを使用する通信が可能な接続ハンドラ、および操作を実行するためのサーバーのコンポーネント(プラグインおよびその他の種類の拡張など)を使用できる、内部使用のための特別な接続ハンドラです。サーバーは、追加のネットワーク・プロトコルのサポートを実装するために使用できる拡張可能な接続ハンドラAPIも提供します。
接続IDは、一意の整数の識別子で、ディレクトリ・サーバー内で維持される各接続に割り当てられます。主にロギングの用途に使用して、指定された接続で実行される様々な操作を関連付けることができます。
接続IDカウンタは、サーバーが受信した最初の接続で0から開始され、接続が追加されるごとに1ずつ増分します。カウンタは、サーバーが再起動されるたびにリセットされます。
内部操作の処理で使用される内部接続には、外部クライアントからの接続と区別するために負の値が割り当てられます。
LDAP制御は、メッセージに含めることのできる要素です。リクエスト・メッセージに含まれる場合は、操作の処理方法の追加情報を提供するために使用できます。レスポンス・メッセージに含まれる場合は、操作が処理された方法の追加情報を提供するために使用できます。
LDAP制御の例を次に示します:
アカウント・ユーザビリティ制御 - アカウントがサーバーに対して認証できるかどうかを示す1組のリクエストとレスポンスの制御です。
認可アイデンティティ制御 - バインド操作の一部として、ユーザーに対する認可アイデンティティを判断するための1組のリクエストとレスポンスの制御です。
エントリ変更通知制御 - エントリが更新された方法を示す永続検索の一部として実行された検索結果エントリ・メッセージに追加される制御です。
実効権限取得制御 - 指定されたエントリにアクセスするためにユーザーが保有する権限についての情報の取得に使用できるリクエスト制御です。
LDAPアサーション制御 - ターゲット・エントリが指定されたアサーション・フィルタと一致した場合にのみ操作が処理されることを保証するために使用できるリクエスト制御です。
LDAP no-op制御 - サーバー内の情報を実際には変更しない書込み操作が実行された場合は、操作が成功するかどうかの判断を試みることを確認するために使用できるリクエスト制御です。
LDAP読込み後制御 - 追加、変更またはDN変更操作を実行した直後に発生したエントリを取得するために使用できる、1組のリクエストとレスポンスの制御です。
LDAP読込み前制御 - 削除、変更またはDN変更操作を実行する直前に発生したエントリを取得するために使用できる、1組のリクエストとレスポンスの制御です。
Manage DSA IT制御 - サーバーがリフェラルとしてではなく通常のエントリとしてスマート・リフェラルを扱うように要求するために使用できるリクエスト制御です。
一致値制御 - 検索操作から返されたエントリに、指定されたフィルタと一致する値のみが含まれるように要求するために使用できるリクエスト制御です。
永続検索制御 - サーバー内で、指定された基準のセットに一致するエントリが更新される場合に、通知を受信するために使用できるリクエスト制御です。
プロキシ認可制御 - 別のユーザーの認可で操作を実行するように要求するために使用できるリクエスト制御です。
サーバー側ソート制御 - クライアントに結果を返す前に、サーバーで結果をソートするように要求するために使用できるリクエスト制御です。
単純なページングの結果制御 - サーバーは結果のサブセットのみを取得し、結果が繰り返し使用される場合に、結果セット全体をクライアントがページングできるように要求するために使用できるリクエスト制御です。
仮想一覧表示制御 - サーバーから検索結果の任意のページを取得するために使用できる1組のリクエストとレスポンスの制御です。
LDAP制御は次のように定義されます:
Control ::= SEQUENCE {
controlType LDAPOID,
.... criticality BOOLEAN DEFAULT FALSE,
.... controlValue OCTET STRING OPTIONAL }
制御には次の要素があります:
制御のタイプを指定するオブジェクト識別子。
クリティカル度。制御が操作の重要な部分とみなされるかどうかを示します(つまり、サーバーが制御を処理できない場合は、操作は失敗します)。
オプション値。制御の処理方法についての追加情報を提供するために使用できます。
CRAM-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。
CRAM-MD5 SASLメカニズムは、draft-ietf-sasl-crammd5-10 (http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10)のInternet Draftで説明されています。このプロセスは、次のとおりです:
クライアントは、メカニズム名がCRAM-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・プロトコルopタイプを含むメッセージをサーバーへ送信します。
サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(challenge)を含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。
クライアントは、メカニズム名CRAM-M5を使用して、2番目のSASLバインド・リクエスト・メッセージに応じてサーバーに応答します。今回は、ユーザーを識別するために使用される認証IDを含むSASL資格証明、およびサーバーから送られたchallengeとクリアテキスト・パスワードを組み合せて計算されたMD5ダイジェストを提供します。
サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常successまたはinvalid credentialsの結果とともに)クライアントに送信します。
CRAM-MD5 SASLメカニズムはDIGEST-MD5 SASLメカニズムとよく似ていますが、DIGEST-MD5がクライアントとサーバーの両方からのランダム・データを含めるのに対して、CRAM-MD5はサーバーからのみであるため、多少脆弱です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。
「UNIX暗号化アルゴリズム」を参照してください。
データベースは、情報の保管に使用されるリポジトリです。ディレクトリ・サーバーでは、データベースはバックエンドでデータを保管するメカニズムとして使用されます。異なる補助記憶装置を使用して他のバックエンドを作成できますが、Berkeley DB Java Editionは、ディレクトリ・サーバーで使用される主要なデータベースです。
データベース・キャッシュは、基礎となるデータベースからのコンテンツを保持するために予約されるメモリーの部分です。データベースからの情報の取得を試行する場合は常に、データベースはディスクにアクセスする前に、最初にこのキャッシュをチェックします。データベース・キャッシュは、負荷のかかるディスクI/Oを回避して、パフォーマンスを大幅に改善するために役立ちます。
データベース・キャッシュは、サーバーのエントリ・キャッシュのかわりに、またはこれに加えて使用できます。データベース・キャッシュは、より簡潔なデータ表現を頻繁に作成しますが(つまり、システムの限られたメモリーで、より多くのデータをキャッシュに保持できます)、通常、エントリ・キャッシュは、サーバーでより効率的に使用できる形式でデータを保持します。
デバッグ・ログは、サーバーで発生する可能性のある問題のデバッグに使用できる、情報を取得するためのメカニズムを提供します。通常、デバッグ情報は問題の発生時にのみ役立つデータで、量が多いため通常の運用では維持できない場合が頻繁に発生します。デバッグ・ログは、次のような情報のレポートに使用できます:
サーバー内でスローされた例外の詳細情報
ネットワーク上のクライアントから読み取られたデータまたはクライアントに書き込まれたデータの情報
データベースから読み取られたデータまたはデータベースに書き込まれたデータの情報
アクセス制御またはパスワード・ポリシーの処理などの領域で実行された判断についての情報
LDAP削除操作は、サーバー(またはサブツリー削除制御とともに使用する場合はサブツリー)からのエントリの削除に使用できます。削除リクエスト・プロトコルopは次のように定義されます:
DelRequest ::= [APPLICATION 10] LDAPDN
リクエストには、削除されるエントリのDNのみが含まれます。
LDAP削除操作に対するレスポンスは、LDAP結果要素で次のように定義されます:
DelResponse ::= [APPLICATION 11] LDAPResult
非推奨パスワード記憶スキームは、サーバーで使用可能なパスワード記憶スキームですが、主に移行時の使用を意図しています。非推奨の記憶スキームでエンコードされたパスワードを所有している場合は、ユーザーは認証を許可されますが、パスワードはパスワード・ポリシーで定義されるデフォルトの記憶スキームのセットを使用して再エンコードされます。
このメカニズムは、(デフォルトのスキームよりも脆弱であるなどの理由で)使用を継続しないパスワード記憶スキームを使用する別のサーバーから、ディレクトリ・サーバーへデータを移行する場合を主に意図しています。サーバーに対するユーザー認証と同様、パスワードは非推奨のスキームからデフォルトのスキームに移行されます。
間接参照ポリシーは検索操作の要素で、検索処理の間に検出される場合のある別名エントリのサーバーでの処理方法を指定します。使用可能な別名間接参照ポリシーの値には次のものがあります:
サーバーは、検索処理中に検出する別名の間接参照を試みることはできません。
サーバーは、エントリが検索基準に一致するかどうかを判断する検索操作の範囲内で、エントリを間接参照します。検索ベースDNとして指定されるエントリは間接参照されません。
サーバーは、エントリが別名の場合は、検索ベースDNとして参照されるエントリを間接参照する必要がありますが、検索操作の範囲内にあるその他の別名エントリは間接参照されません。
サーバーは、検索操作の範囲内で別名エントリを間接参照し、ベース・エントリが別名の場合も間接参照します。
DIGEST-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。
DIGEST-MD5 SASLメカニズムはRFC 2831 (http://www.ietf.org/rfc/rfc2831.txt)で説明されていますが、改訂された仕様がdraft-ietf-sasl-rfc2831bisに記載されています。このプロセスは、次のとおりです:
クライアントは、メカニズム名がDIGEST-MD5で資格証明なしの認証タイプSASLを使用して、バインド・リクエスト・プロトコルopタイプを含むメッセージをサーバーへ送信します。
サーバーは、結果コード14 (SASLバインドが進行中です)およびランダムに生成されたデータ(nonce)、その他のものを含むサーバーSASL資格証明要素とともにバインド・レスポンス・メッセージをクライアントに返信します。
クライアントはサーバーから送信されたnonce、クライアント自体がランダムに生成したデータ(cnonce)、認証ID、オプション認可ID、ユーザーのクリアテキスト・パスワードおよびその他の情報を取得し、それを使用してMD5ダイジェストを作成します。次にクライアントは、そのダイジェストおよびその他のクリアテキスト情報を含む2番目のバインド・リクエスト・メッセージをサーバーに返信します。
サーバーは認証IDを使用してユーザーを識別し、そのユーザー用のクリアテキスト・パスワードを取得して(クリアテキスト・パスワードを取得できない場合は、認証は失敗します)、指定されたダイジェストが有効かどうかを判断するために使用します。サーバーは、認証が成功したかどうかを示す適切なレスポンスを(通常successまたはinvalid credentialsの結果とともに)クライアントに送信します。
完全性または機密性、あるいはその両方で接続を保護する必要があることを示す保護品質(QoP)の値をクライアントが要求した場合は、サーバーはクライアントとの必要なネゴシエーションを開始します。現在、ディレクトリ・サーバーでは、完全性または機密性保護を使用するDIGEST-MD5メカニズムの使用をサポートしていないことに注意してください。
DIGEST-MD5 SASLメカニズムはCRAM-MD5 SASLメカニズムとよく似ていますが、CRAM-MD5がサーバーからのランダム・データのみを含めるのに対して、DIGEST-MD5はクライアントとサーバーの両方からであるため、多少厳格です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。
ディレクトリ情報ツリーすなわちDITは、ディレクトリ・サーバーのデータの階層構造を指します。DITには、サーバーに対するベース・エントリであるネーミング・コンテキストが1つ以上あり、その他のエントリはすべて、これらのネーミング・コンテキスト・エントリの1つの下位にあります。つまり、ネーミング・コンテキスト・エントリは親エントリを持たないという点で特殊です。
次のシナリオについて考えます。エントリdc=example,dc=comはネーミング・コンテキストで、2つの直属の子を保有し、その子のDNはそれぞれou=People,dc=example,dc=comおよびou=Groups,dc=example,dc=comで、それらの各エントリはそれ自体の下位エントリを保有しています。ディレクトリ・ツリーの最大の深さについて事前に定義された制限はなく、どのエントリも1つ以上の下位エントリを保有する可能性があります。下位エントリを保有しないエントリはリーフ・エントリと呼ばれ、少なくとも1つの下位エントリを保有するエントリはリーフ以外のエントリと呼ばれます。
directory managerという用語は、ディレクトリ・サーバーでルートDNユーザーを指すために使用される共通の名前です。通常、デフォルトのルート・ユーザーはcn=Directory Managerのバインド識別名を使用するため、このように名付けられています。多くのディレクトリ・サーバー以外のタイプとは異なり、ディレクトリ・サーバーでは、デフォルトのルートDNはcn=Directory Managerですが、複数のルートDNを定義できます。
ディレクトリ・サーバーは、外部クライアントがアクセスできる方法でデータを保管するネットワーク・デーモンのタイプです。一部のサーバーでは、DAPまたはNDSなどその他のプロトコルを使用しますが、通常、ディレクトリ・サーバーでは、クライアントとの通信にLightweight Directory Access ProtocolまたはDirectory Services Markup Languageを使用します。
ディレクトリ・サーバーは、(ディレクトリ情報ツリーと呼ばれる)階層形式でデータを保管し、クライアントがその情報と相互に作用するための次のような機能を提供します:
追加操作。サーバーへの新規のエントリの追加を可能にします。
削除操作。サーバーからのエントリの削除を可能にします。
変更操作。サーバー内の既存の情報の更新を可能にします。
DN変更操作。サーバー内のエントリの名前の変更を可能にします。
バインド操作。サーバーに対するユーザー認証を可能にします。
比較操作。エントリが特定の属性値の組を保有しているかどうかの判断を可能にします。
ディレクトリ・サーバーは、ネットワーク上のクライアントとの通信にLDAPv3を使用し、DSMLリクエストの処理に使用できるDSMLゲートウェイを提供します。
ディレクトリ・サーバー・エージェント(DSA)はディレクトリ・サーバーの単一インスタンスです。
Directory Services Markup Language (DSML)は、ディレクトリ・サーバーとの通信に使用できるプロトコルです。DSMLはLightweight Directory Access Protocolに代わるもので、LDAPで使用される基本エンコーディング・ルールによるエンコーディングのかわりにXMLベースの表現のリクエストおよびレスポンスを使用します。
通常、DSMLは、LDAPのかわりとしては比較的脆弱であると考えられています。LDAPで使用されるBERエンコーディングと比較すると、XML表現はより冗長で処理が高価で、利点があまりなく大きなコストが発生するためです。多くの場合、サーバーとの対話にはDSMLのかわりにLDAPの使用をお薦めします。
識別名(DNと呼ばれることが多い)は、ディレクトリ・サーバー内のエントリを一意に識別する文字列です。ディレクトリ情報ツリー内のエントリの場所を識別する、0個以上の識別名(RDN)コンポーネントから構成されています。エントリの識別名は、名前と階層的な位置の両方を指定するという点で、ファイルシステムの絶対パスに類似のものとして考えられます。
識別名のRDNコンポーネントはカンマで区切られ、右から左に順序付けられます。DNの一番右のコンポーネントはサーバーのネーミング・コンテキストに一番近く、一番左のコンポーネントはリーフ・エントリに一番近いところにあります。つまり、ディレクトリ階層を、最上位にネーミング・コンテキストがあり、枝を下向きに伸ばすピラミッドのようなものとしてとらえると、DNのRDNコンポーネントの順序は一番下から一番上へとリストされています。
DNが一連のRDNコンポーネントで構成されていても、1つのコンポーネントがエントリのRDNを参照していれば、一番左のRDNコンポーネントを参照していることになります。エントリのRDNに含まれる属性は、エントリにも含まれる必要があります。
DITでは、最上位のエントリはネーミング・コンテキストであり、そのDNはdc=example,dc=comです。スペースを節約するために下位エントリのRDNのみが表示されますが、完全なDNはRDNコンポーネントを一番下から一番上まで連結して取得できます。たとえば、一番下の行で一番左のエントリのDNは、uid=ann,ou=People,dc=example,dc=comです。
LDAP識別名およびLDAP識別名を文字列として表示する方法の詳細は、RFC 4514 (http://www.ietf.org/rfc/rfc4514.txt)を参照してください。
分散は、データをパーティションに分割するプロキシ・デプロイメントのタイプです。データの分割は分散アルゴリズムで決定されます。
「ディレクトリ情報ツリー」を参照してください。
DITコンテンツ・ルールはスキーマ要素で、構造オブジェクト・クラスに基づき、エントリとともに使用できる補助オブジェクト・クラス、およびエントリとともに使用することを要求、許可および禁止されている属性タイプを指定します。
DITコンテンツ・ルールのコンポーネントの定義は次のとおりです:
DITコンテンツ・ルールが関連付けられる構造オブジェクト・クラスのオブジェクト識別子を数字で表したもの。
DITコンテンツ・ルールのオプション・セットの名前。
関連付けられた構造クラスを含むエントリとともに使用可能な補助クラスの補助オブジェクト・クラス名またはOIDのオプション・セット。
関連付けられた構造クラスとともにエントリ内に存在する必要のある、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、必須です。
関連付けられた構造クラスを持つエントリ内に、オプションで存在できる属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、許可されます。
関連付けられた構造クラスを持つエントリ内での存在を禁止されている、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されている場合でも、禁止されます。
サーバーで定義されるDITコンテンツ・ルールのセットは、サブスキーマ・サブエントリのdITContentRules属性を取得して確認できます。DITコンテンツ・ルールの詳細は、「DITコンテンツ・ルールの理解」を参照してください。
DIT構造ルールはスキーマ要素で、エントリ間の階層関係の定義に使用できます。特に、親エントリの種類を(構造オブジェクト・クラスに基づいて)、指定された構造クラスを持つエントリを保有できるものと定義します。
DIT構造ルールのコンポーネントの定義には次のものがあります:
ルールを一意に識別するために使用される整数のルールID値。
DIT構造ルールのオプション・セットの名前。
DIT構造ルールが関連付けられる名前書式の名前またはオブジェクト識別子。名前書式は、DIT構造ルールを構造オブジェクト・クラスに順に関連付けます。
上位のルールIDのオプション・セット。上位ルールのセットが定義されている場合は、ルールの名前書式に関連付けられている構造クラスがその下に存在を許可されている構造クラスの定義に使用されます。
サーバーで定義されるDIT構造ルールのセットは、サブスキーマ・サブエントリのdITStructureRules属性を取得して確認できます。DIT構造ルールの詳細は、「DIT構造ルールの理解」を参照してください。
「識別名」を参照してください。
「ディレクトリ・サーバー・エージェント」を参照してください。
DSA固有のエントリ(DSE)は特別なタイプのエントリで、ディレクトリ・サーバーのシノニムであるディレクトリ・サーバー・エージェントの情報を提供します。
Lightweight Directory Access Protocolは、サーバー内にある情報およびサポートされる操作のタイプについての情報を提供するルートDSEと呼ばれる特別なエントリを定義します。
「DSA固有のエントリ」を参照してください。
「Directory Services Markup Language」を参照してください。
DSMLゲートウェイ(またはDSML-to-LDAPゲートウェイ)は、特別なタイプのネットワーク・デーモンで、Directory Services Markup LanguageおよびLightweight Directory Access Protocolの間の変換に使用されます。通常、DSMLゲートウェイはクライアントからのDSMLリクエストを許可し、処理のためにディレクトリ・サーバーに転送するLDAPリクエストに変換します。次に、ディレクトリ・サーバーから返信するLDAPレスポンスをDSMLへ変換し、クライアントに返します。
ディレクトリ・サーバーは、アプリケーション・サーバーで実行可能なWebアプリケーションとして実装されるDSMLゲートウェイを介してDSMLをサポートします。
構成プロパティには、許可された値として期間を指定するものがあります。
期間には、整数、および週(w)、日(d)、時(h)、分(m)、秒(s)またはミリ秒(ms)で指定される単位、または複数の指定子の組合せが含まれます。たとえば1週間は、1w、7d、168h、10080mまたは604800sと指定できます。また、10日と半日は1w3d12h0m0sと指定できます。
期間を必要とするすべてのプロパティが、すべての期間の指定子(w、d、h、m、sおよびms)をサポートしているわけではありません。
次のような期間プロパティもあります:
期間プロパティの値の指定に使用可能な最小粒度を指定します。たとえば、基本単位が秒の場合は、ミリ秒で表された値は許可されません。
期間プロパティの値の指定に使用可能な最大期間の単位を指定します。この単位よりも大きい単位で表された値は許可されません。
プロパティにより許可された最小期間を指定します。
プロパティにより許可された最大期間を指定します。
無制限の期間を指定できるプロパティもあります。-1にデコードされた値またはエンコードされた文字列値unlimitedを使用して表されます。
エントリは、ディレクトリ・サーバーで情報を保持する構造体です。次のコンポーネントから構成されています:
サーバーのその他すべてのエントリから、該当のエントリを一意に識別する識別名。
エントリのコンテンツ制御に使用されるオブジェクト・クラス値の集合。
エントリの実データを含む属性の集合。
エントリには、エントリのタイプを定義する構造オブジェクト・クラスが常に1つ必要です。エントリのその他の特性を識別するために使用できる補助オブジェクト・クラスを0個以上保有する場合があります。構造クラスと補助クラスがともに、エントリ内に存在する必要のある必須の属性のセット、およびエントリ内に含めることができるが必須ではないオプション属性を定義します。
エントリ・キャッシュはエントリの保持にシステム・メモリーを使用するメカニズムで、エントリを必要とする際は常に、データベースからデコードする必要なく迅速にエントリにアクセスできるようにする方法です。エントリ・キャッシュ・メカニズムは、連続した操作で同じエントリに複数回アクセスするアプリケーションとともに使用すると特に効果的です。たとえば、最初にユーザー・エントリを検出する検索操作、次にそのユーザーがパスワードを検証するためのバインド操作というアプリケーションは、きわめて一般的な使用のパターンです。
エントリ・キャッシュは、サーバーのデータベース・キャッシュのかわりに、またはこれに加えて使用できます。通常、データベース・キャッシュは簡潔なデータ表現を使用しますが、エントリ・キャッシュはサーバーで効率的に使用できる形式でデータを保持します。
基礎となるデータベースにより維持されるデータベース・キャッシュとは異なり、エントリ・キャッシュはディレクトリ・サーバー自体に管理されます。使用可能な様々なエントリ・キャッシュの実装が多数あります。
エントリ変更通知制御は、永続検索制御を使用する検索操作に対するレスポンス内で、クライアントに返される検索結果エントリに含まれる制御です。この制御には、実行された変更のタイプ、変更番号(サーバーが変更ログをサポートする場合は、サーバーの変更ログのアイテムに対応)、およびエントリの名前が変更された場合は変更前のエントリのDNなど、エントリに対する変更の追加情報が含まれます。この制御はdraft-ietf-ldapext-psearch-03 (http://tools.ietf.org/html/draft-ietf-ldapext-psearch-03)で説明されており、OIDは2.16.840.1.113730.3.4.7です。
この制御は次のように定義されます:
EntryChangeNotification ::= SEQUENCE {
changeType ENUMERATED {
add (1),
delete (2),
modify (4),
modDN (8)
},
previousDN LDAPDN OPTIONAL, -- modifyDN ops. only
changeNumber INTEGER OPTIONAL -- if supported
}
エントリDNは、エントリの現在の識別名のコピーを提供する操作属性です。DNはエントリの属性ではないため、属性値アサーションの実行には使用できません。エントリDNはエントリのDNにアクセスするメカニズムを提供し、RFC 5020で説明されています。
エントリIDは、ディレクトリ・サーバー・バックエンド内のエントリを一意に識別するために使用される整数値です。エントリの識別名はこの用途に使用できますが、数値のエントリIDはより簡潔で効率的なデコードが可能なため、幅広い用途により適しています。
エントリIDは、id2entryデータベースの実際のエントリ・データに対するキーとして使用され、関連付けられた索引キーと一致するエントリを識別するIDリストで使用されます。
エントリUUIDは、entryUUID操作属性に含まれる全体で一意となる識別子で、ディレクトリ・サーバーの各エントリに割り当てられます。RFC 4530 (http://www.ietf.org/rfc/rfc4530.txt)で説明されており、エントリが存続する間は変更されない一意の識別子を意図しています(DN変更操作の結果として変更可能な識別名とは対照的です)。エントリUUIDは十分に安定しているため、DNが変更された場合でも、エントリを追跡するレプリケーション・サブシステムで使用されます。
等価索引は、指定されたアサーション値に等しいエントリを効率的に識別するために使用される索引のタイプです。等価索引は、対応する等価一致ルールを保有する属性用にのみ保持できます。この一致ルールは索引キーとして使用する正規化された値に対して使用され、そのキーの値は、正規化された値に等しい値を持つエントリのエントリIDを含むIDリストです。
等価検索フィルタはLDAP検索フィルタのタイプで、指定された属性の固有の値を含むエントリの識別に使用できます。サーバーは、等価一致ルールを使用して判断します。
LDAP等価フィルタの文字列表現は、左カッコに続く属性名、等号、属性値および右カッコで構成されます。たとえば、等価フィルタの(uid=john.doe)は、john.doeの値を含むuid属性のエントリと一致します。
エラー・ログは、エラー、警告およびその他サーバーの使用期間に発生する重大なイベントをレポートするメカニズムを提供します。エラー・ログに書き込まれる各メッセージには、(メッセージが生成されたサーバーの領域を示す)カテゴリ、(メッセージの相対的な重要性を示す)重大度および関連付けられるメッセージ文字列を一意に識別する整数値が含まれます。
「LDIFエクスポート」を参照してください。
LDAP拡張操作は、コア・プロトコル仕様で定義されていないリクエスト操作をクライアントに許可することにより、LDAPプロトコルに対する拡張度を提供します。LDAP拡張操作の例を次に示します:
この操作は、以前にリクエストされた操作の取消しに使用できます。
この操作は、ユーザー・パスワードの変更に使用できます。
この操作は、既存の接続上での保護された通信チャネルの開始に使用できます。
この操作は、クライアント接続に関連付けられる認可アイデンティティの判断に使用できます。
拡張リクエストのプロトコルopは次のように定義されます:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
拡張リクエストの要素には次のものがあります:
実行する操作のタイプを示すために使用されるオブジェクト識別子。
リクエスト処理が進行する間に使用する、追加情報を含むオプション値。
LDAP拡張操作に対するレスポンスは次のように定義されます:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
拡張レスポンスには次の要素があります:
結果オブジェクトの要素。
レスポンスのタイプを示すために使用されるオプションOID。
レスポンスに含まれる追加情報を含むオプションのエンコードされた値。
拡張可能な一致索引は、拡張可能な一致検索フィルタを使用する検索操作の処理速度を上げるために使用される索引のタイプです。索引キーは、指定された一致規則を使用する正規化された値で、対応するIDリストには、一致ルールに従って値が一致するすべてのエントリのエントリIDが含まれます。
拡張可能な一致検索フィルタはLDAP検索フィルタのタイプで、指定された一致ルールを使用して一致したエントリの識別に使用できます。
拡張可能な一致フィルタには次のコンポーネントがあります:
判断に使用する一致ルールのOID。これはオプション要素で、指定されない場合は属性タイプの指定が必要となり、属性タイプのデフォルトの等価一致ルールが使用されます。
ターゲット設定される属性タイプの名前。指定されない場合は、エントリに含まれるすべての属性が調べられます。
エントリの識別名の属性およびエントリに含まれる属性に対して一致が実行されるかどうかを示すフラグ。
一致ルール用のターゲットとして使用されるアサーション値。
LDAP拡張可能な一致フィルタの文字列表現は、次のコンポーネントで順に構成されています:
左カッコ
属性タイプの名前または指定されなかった場合は空の文字列
dnAttributesフラグが設定されている場合は文字列:dn、または設定がない場合は空の文字列
一致ルールIDが使用可能な場合はコロンとそれに続くOIDで構成される文字列、または一致ルールIDがない場合は空の文字列
文字列:=
アサーション値の文字列表現
右カッコ
EXTERNAL Simple Authentication and Security Layerメカニズムは、LDAPプロトコル・レベルで実行される通信の外部で使用可能な情報を使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。EXTERNAL認証(現在、ディレクトリ・サーバーがサポートする唯一の形式)の最も一般的な使用方法は、Secure Sockets LayerまたはTLS起動拡張操作のネゴシエーションの間にクライアントが提示した証明書に基づく、サーバーでのクライアントの識別です。ディレクトリ・サーバーは、証明書マッパーを使用してクライアントの証明書をディレクトリのユーザーにマッピングし、オプションで追加検証を実行する場合があります(たとえば、提示された証明書がユーザーのエントリに実際に存在していることを確認します)。
すべてのクライアントのリクエストをメイン・リモートLDAPデータ・ソースに送信するロード・バランシング・アルゴリズム。メイン・リモートLDAPが停止する場合は、リクエストはセカンダリ・リモートLDAPサーバーなどに転送されます。このように、1つ以上のリモートLDAPサーバーの障害後、サービスの継続を保証します。
「LDAP falseフィルタ」を参照してください。
一般的な時刻は、タイムスタンプおよびタイムゾーン情報の表現に使用できる形式です。一般的な時刻の値には、次のコンポーネントがあります:
年を表す4桁の数。
月を表す2桁の数(01は1月、02は2月、...、12は12月)。
該当月の日を表す2桁の数(月およびうるう年かどうかによって01から28、29、30または31まで)。
該当日の時を表す2桁の数(午前0時の00から午後11時の23まで)。
オプションで、時間の分を指定する2桁の数(00から59まで)。
オプションで、分の秒を指定する2桁の数(00から59まで、またはうるう秒の場合は60まで)。これは、タイムスタンプ値にも時間の分が含まれる場合にのみ追加できます。
オプションで、秒の小数部を指定する1桁以上の数を続けて表す期間。これは、タイムスタンプ値に分および秒の情報が含まれる場合にのみ追加できます。
タイムゾーン・インジケータ。UTCタイムゾーンの値を示す大文字のZ、またはプラス記号かマイナス記号とそれに続く2桁または4桁の数で、この数はUTCタイムゾーンからの時差を指定します。
一般化された時刻形式のタイムスタンプの例として、20070508200557Zは、(UTCタイムゾーンで)2007年5月28日午後8時5分57秒の時刻を指定します。米国中部時間サマータイムで等しい値(UTCから5時間の時差)は、20070508150557-0500です。
実効権限取得制御は、指定されたエントリと相互に作用する際に、指定されたユーザーが保有する権限を判断するために使用できる制御のタイプです。この制御のオブジェクト識別子は1.3.6.1.4.1.42.2.27.9.5.2で、次の定義を使用します:
GetRightsControl ::= SEQUENCE {
authzId authzId
attributes SEQUENCE OF AttributeType
}
-- Only the "dn:DN form is supported.
検索リクエストでこの制御を使用する例は、「実効権限取得制御を使用した検索」を参照してください。
プロキシ・デプロイメントで、グローバル索引はデータ・エントリをデータが保管されている分散パーティションにマッピングします。グローバル索引は特定の属性(telephonenumberなど)をマッピングします。たとえば、グローバル索引はtelephonenumber=5551212を分散パーティション1に、telephonenumber=4441212をパーティション2にマッピングできます。
グローバル索引カタログには、1つ以上のグローバル索引が含まれます。グローバル索引カタログは、属性の値でエントリが保持するパーティションにマッピングされるものもあるため、ブロードキャストの必要性を減らすために分散デプロイメントとともに使用できます。
大きいか等しい検索フィルタは、指定されたアサーション値以上の、指定された属性の特定の値を含むエントリの識別に使用できるLDAP検索フィルタのタイプです。サーバーでは、順序付け一致ルールを判断に使用します。
LDAP大きいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、大なり記号、等号、アサーション値および右カッコで構成されます。たとえば、大きいか等しいフィルタの(createTimestamp>=20070101000000Z)は、20070101000000Z以上のcreateTimestamp値を保有するエントリと一致します。
グループは特別なタイプのディレクトリ・サーバーのエントリで、サーバーのユーザーのセットの表示に使用されます。グループは、アクセス制御l、仮想属性など、サーバー内でいくつかの異なる方法で使用可能で、クライアントによる様々な用途にも使用できます。
サーバーで定義されるグループには、次のようないくつかの異なるタイプがあります:
GSSAPI Simple Authentication and Security Layerメカニズムは、Kerberos V5セッションを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。Kerberosは通常シングル・サインオン用途に使用されるプロトコルで、クライアントとサーバーの間の通信を保護するための完全性または機密性、あるいはその両方を使用するオプションを提供します(現在、ディレクトリ・サーバーではネットワーク・コンテンツ保護用のGSSAPIをサポートしていませんが、クライアントの認証の場合のみサポートします)。
GSSAPI SASLメカニズムは、RFC 4752 (http://www.ietf.org/rfc/rfc4752.txt)で説明されています。
IDリストは、ディレクトリ・サーバー索引の値として使用されます。関連付けられた索引キーと一致するすべてのエントリのエントリIDのセットが含まれます。
IDリストは、索引エントリ制限により許可されている数よりも多くの索引キーと一致するエントリが存在することを示す、特別な値を保有できる場合があります。その場合は、それ以降索引キーは維持されません。
id2entryデータベースは、エントリIDを対応するエントリのコンテンツにマッピングするデータベースのタイプです。エントリIDは、索引内のIDリストで使用されます。
アイデンティティ・マッパーは、認証IDまたは認可IDの値を対応するユーザー・エントリにマッピングするために使用できるロジックを提供します。アイデンティティ・マッパーは、多くのSimple Authentication and Security Layerメカニズム、プロキシ認可制御およびパスワード変更拡張操作とともに使用されます。
アイドル・アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーの一部で、長期間使用されないままになっているユーザー・アカウントのロックに使用できます。ユーザー認証時刻が記録されるように最終ログイン時刻機能の有効化が必要で、指定された期間内に認証されなかったユーザーによるいずれのバインド操作も拒否します。
長期間アイドルのままであったためにユーザーのアカウントがロックされた場合は、管理者のパスワードのリセットによりロック解除できます。
インコア再起動は、サーバーの実行に使用されるJVMが実在しない状態でサーバーの再起動を可能にするプロセスです。JVM引数の変更を必要としない、サーバー再起動の必要な変更を適用するために使用できます。インコア再起動は、サーバー・プロセスを停止して再起動するよりも迅速で、JVM内で実行される処理の確認を蓄積したJITキャッシュを維持するという別の利点もあります。
索引はディレクトリ・サーバー・データベースで使用されるメカニズムで、検索基準に一致するエントリの効率的な検出に使用できます。索引は、索引キーと一致するエントリのエントリIDのセットであるIDリストにキーをマッピングします。
ディレクトリ・サーバーは、次の6つの主要な索引のタイプを使用します:
索引エントリ制限は、指定された索引キーと一致可能なエントリの最大数(つまり、IDリストの最大サイズ)の制御に使用できる構成制限です。サーバー内のエントリと高い割合で一致する索引キーを維持するために、パフォーマンスの影響を制限するメカニズムを提供します。大きなIDリストを必要とする可能性がある場合は、索引なし検索を実行すると、索引を使用するよりも速度を向上できる場合がよくあります。
ディレクトリ・サーバーの索引エントリ制限は、Oracle Directory Server Enterprise EditionのALL IDしきい値に類似のものです。
「LDAP中間レスポンス」を参照してください。
Internet Draftは、IETF (http://www.ietf.org/)を介して定義される仕様の形式です。Internet draftは、通常複数の改訂を経る一時的な仕様で、改訂の間に大幅に変更される場合があります。Internet Draftが安定するとrequest for commentsに昇格します。それ以外のdraftは、サーバーで実装する価値のある、存続可能な機能が記述されている場合もありますが、進展はなく、その後維持されなくなります。
Java Management Extensions (JMX)は、監査情報および構成情報へのアクセスに使用できるJavaテクノロジのフレームワークです。
Oracle Unified Directoryでは、監視エントリからの情報を公開するためにJMXを使用します。重大な問題のイベントまたはサーバーでのイベントの際の管理アラートのため、JMX通知メカニズムも使用します。
「Java Management Extension」を参照してください。
キー・マネージャ・プロバイダは、サーバー証明書の秘密鍵情報へのアクセスを提供できるサーバーのコンポーネントです。
サーバーで使用可能なキー・マネージャ・プロバイダには次のものがあります:
JKSキーストアでキー情報にアクセスするためのメカニズム
PKCS#12ファイルでキー情報にアクセスするためのメカニズム
PKCS#11トークンでキー情報にアクセスするためのメカニズム
ディレクトリ・サーバーの最終ログイン時刻機能は、バインド操作を使用してサーバーへの認証をユーザーが最後に実行した時刻を記録するために使用できるメカニズムです。最終ログイン時刻は、ユーザー定義のフォーマットにより、指定された属性に書き込むことができます。
多くのサーバーで、お薦めする最終ログイン時刻フォーマットの定義では、日付のみで時刻は含めないことに注意してください。このフォーマットを使用すると値の更新が1日に一度となり、1日に何度も認証するユーザーは、パフォーマンスへの影響の可能性を削減できます。
最終ログイン時刻は情報提供を目的に維持できますが、アイドル・アカウント・ロックアウト機能の有効化にも使用できます。
最終変更プラグインは、追加操作の一部としてエントリにcreatorsName属性およびcreateTimestamp属性を追加するため、あるいは変更操作またはDN変更操作の一部としてエントリのmodifiersName属性およびmodifyTimestamp属性を更新するために使用できる操作前アイドル・アカウント・ロックアウトです。
LDAPアサーション制御は、ターゲット・エントリが指定されたアサーション・フィルタと一致する場合にのみ操作を実行するために使用できる制御のタイプです。比較操作、削除操作、変更操作、DN変更操作および検索操作とともに使用できます。
LDAPアサーション制御は、RFC 4528 (http://www.ietf.org/rfc/rfc4528.txt)で説明されており、OIDは1.3.6.1.1.12です。制御の値は、LDAPのLDAP検索フィルタとしてエンコードされます。
検索リクエストでこの制御を使用する例は、「LDAPアサーション制御を使用した検索」を参照してください。
ldapcompareコマンドは、LDAP比較操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapcompare」を参照してください。
LDAPデータ変換形式(LDIF)は、テキスト形式でディレクトリ・データを表すメカニズム形式です。LDIFの仕様はRFC 2849 (http://www.ietf.org/rfc/rfc2849.txt)に記載されており、ディレクトリ・データの表現形式のみならず、そのデータを変更するメカニズムについても説明されています。
通常、LDIFレコードは一連の名前/値ペアで構成されています。名前の後に1つのコロン、0個以上の空白および関連付けられた値を続けます。または、2つのコロン、0個以上の空白および値のbase64エンコーディング表現を続けることもできます。各名前/値ペアは、個別の行に指定され、長い行の場合は、行端文字と次の行の先頭に続く1つの空白を使用して2行以上に行送りされます。複数のLDIFレコードは、互いに少なくとも1行の空白行で区切られます。ナンバー(#)記号で開始される行はコメントとして取り扱われ、無視されます。
エントリのLDIF表現の場合は、1行目にエントリの識別名を含む必要があります。LDIFレコードの残りの行は、名前として使用される属性説明とともに、エントリの属性を表します。複数値属性は値ごとに個別の行で表されます。
LDAPデータ変換形式で表されるユーザー・エントリの例を次に示します:
dn: uid=john.doe,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: john.doe
givenName: John
sn: Doe
cn: John Doe
mail: john.doe@example.com
userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M
QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT
AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ
KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy
YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg
k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN
bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd
Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf
qemCf7o3+Cp00OmF5ey
userPassword: {SSHA}s4Bd9M0tCpRDr8/U+IXetRcAbd8bJY3AFKsn+A==
LDIFでLDAP追加操作を表すには、次の例で示すように、DN直後の行でaddのchangetypeを示すこと以外は、エントリの表現とまったく同じフォーマットです:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: john.doe givenName: John sn: Doe cn: John Doe mail: john.doe@example.com userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf qemCf7o3+Cp00OmF5ey userPassword: password
LDIFでLDAP削除操作を表すには、フォーマットは次のように、エントリのDNを含む行とそれに続くdeleteのchangetypeを示す行のみです:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: delete
LDIFでLDAP変更操作を表すには、もう少し複雑なフォーマットになります。1行目にはエントリのDNを含み、2行目にはmodifyのchangetypeを含みます。3行目で属性変更タイプ(変更、削除、置換または増分)を指定し、これに属性説明が続き、属性説明の名前部分および対応する属性値の値を含む、変更のための指定値を指定する行が追加される場合があります。単一の変更レコードで説明される複数の属性変更では、次の例で示すようにダッシュのみの行で各変更内容を区切ります:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: modify replace: userPassword userPassword: newpassword - replace: description description: This is the first description value description: This is the second description value
LDIFでLDAP DN変更操作を表すには、1行目にはエントリのDNを含み、2行目にはmoddnのchangetypeを含みます。3行目には、エントリに割り当てる新規RDNに等しい値を含むnewrdnの名前が含まれ、4行目にはdeleteoldrdnの名前に値1 (deleteOldRDNフラグがtrueの場合)または0 (falseの場合)が続きます。オプションで5行目にnewsuperiorの名前およびリクエストに含まれている場合は新規上位DNの値を含めることができます。例:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=johnathan.doe deleteoldrdn: 1
LDAP falseフィルタは特別なタイプのOR検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP falseフィルタと呼ばれるのは、常にfalseと評価され、いずれのエントリとも一致しないためです。
LDAP trueフィルタの文字列表現は、(|)です。LDAP falseフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されています。
LDAP中間レスポンス・メッセージは、特別なタイプのプロトコルopで、処理の完了前および最終のレスポンス・メッセージが送信される前に、操作の状態の情報を提供する追加メッセージをサーバーが送信できるようにします。RFC 3771 (http://www.ietf.org/rfc/rfc3771.txt)の中間レスポンスの導入前は、検索操作のみが複数レスポンスを送信できました。
中間レスポンス・プロトコルopは次のように定義されます:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
現在ディレクトリ・サーバーでは、中間レスポンス・メッセージを使用する操作をサポートしていません。
LDAPメッセージは、LDAP通信用の基本的なプロトコル・データ・ユニットです。すべてのリクエストとレスポンスの要素の保持に使用されるコンテナです。
LDAPメッセージは、次の例で示すように定義されます:
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
LDAPメッセージには次の要素があります:
LDAP DN変更操作は、ディレクトリ・サーバーでのエントリの識別名を変更するために使用できます。エントリの相対識別名の変更、またはそのエントリの新しい親の下への移動、あるいはその両方ができます。ターゲット・エントリが下位エントリを保有する場合は、サブツリーの移動または名前の変更に使用する場合があります。
DN変更リクエストのプロトコルopは次のように定義されます:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
変更DNリクエストには次の要素があります:
名前の変更または移動、あるいはその両方を行うエントリのDN。
エントリで使用する新規RDN。エントリが新しい親の下に移動するのみであれば、現在のRDNと同じ場合があります。
現在のRDN属性値をエントリから削除するかどうかを示すフラグ。
エントリの新しい親を指定する、オプションのDN。
LDAP DN変更操作に対するレスポンスは、LDAP結果で次のように定義されます:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult}
LDAP変更操作は、ディレクトリ・サーバーの既存のエントリの変更に使用できます。変更リクエストのプロトコルopは次のように定義されます:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
変更リクエストには次の要素があります:
変更するエントリのDN
エントリで実行される変更を示す1つ以上の変更要素
LDAP変更操作に対するレスポンスは、LDAP結果で次のように定義されます:
ModifyResponse ::= [APPLICATION 7] LDAPResult
ldapmodifyコマンドは、LDAPの追加操作、削除操作、変更操作およびDN変更操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapmodify」を参照してください。
LDAP no-op制御は、LDAPの追加操作、削除操作、変更操作またはDN変更操作に追加して、サーバーのコンテンツに対する変更が実際には実行されないことを示す制御のタイプです。
LDAP no-op制御はdraft-zeilenga-ldap-noopで定義されています。これはまだ作成中の仕様ですが、ディレクトリ・サーバーはオブジェクト識別子に1.3.6.1.4.1.4203.1.10.2を使用してこの制御の基本的なサポートをしています。この制御には値がありません。
ldapmodify操作でのno-op制御の使用例を次に示します。
ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ -J 1.3.6.1.4.1.4203.1.10.2 dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 3333 Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com MODIFY operation failed Result Code: 16654 (No Operation) Additional Information: The modify operation was not actually performed in the Directory Server back end because the LDAP no-op control was present in the request
LDAP読込み後制御は、LDAPの追加操作、変更操作またはDN変更操作に追加して、その操作に対する処理の終了時点とまったく同じターゲット・エントリのコピーを、サーバーが返すようにリクエストする制御のタイプです。RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)で定義されるLDAP読込みエントリ制御の1つです。
読込み後リクエスト制御のOIDは1.3.6.1.1.13.2で、その値は検索操作の検索属性と同じ方法でエンコードされます。そのレスポンス制御のOIDは1.3.6.1.1.13.2(リクエスト制御のOIDと同じ)で、その値は検索結果エントリと同じ方法でエンコードされます。
ldapmodifyリクエストでの読込み後制御の使用例を次に示します:
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ --postReadAttributes=telephoneNumber dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 3333 Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com Target entry after the operation: dn: uid=aaltay,ou=People,dc=example,dc=com telephoneNumber: +1 995 589 3333
LDAP読込み前制御は、LDAPの削除操作、変更操作またはDN変更操作に追加して、その操作に対する処理直前とまったく同じターゲット・エントリのコピーを、サーバーが返すようにリクエストする制御のタイプです。RFC 4527 (http://www.ietf.org/rfc/rfc4527.txt)で定義されるLDAP読込みエントリ制御の1つです。
読込み前リクエスト制御のOIDは1.3.6.1.1.13.1で、その値は検索操作の検索属性と同じ方法でエンコードされます。そのレスポンス制御のOIDは1.3.6.1.1.13.1(リクエスト制御のOIDと同じ)で、その値は検索結果エントリと同じ方法でエンコードされます。
ldapmodifyリクエストでの読込み前制御の使用例を次に示します:
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ --preReadAttributes=telephoneNumber dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 4444 Processing MODIFY request for uid=user.199,ou=People,dc=exampele,dc=com MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com Target entry before the operation: dn: uid=aaltay.199,ou=People,dc=example,dc=com telephoneNumber: +1 995 589 3333
LDAP結果要素は、様々なタイプのLDAP操作のレスポンスに使用される汎用プロトコルopです。LDAP結果の基本的な定義は次のとおりです:
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80), ... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
LDAP結果の要素は次のとおりです:
操作の結果についての汎用情報を提供する整数値。前述の定義ではいくつかの結果コードが指定されますが、別の仕様では多くの別の値が定義されています。
リクエストが存在しないエントリを指定した場合に、見つかった最も近い上位エントリのDNを指定するDN値。一致したDN要素がレスポンスに対して適切でなければ、空のDNの場合があります。
処理の結果についての追加情報を提供する判読可能なメッセージ。通常、エラー・メッセージに使用されますが、正常な操作で表示される場合もあります。メッセージがなければ、空の文字列の場合があります。
クライアントが操作を試行できる他のサーバーのLDAP URLのセット。リフェラルがなければ、この要素は欠落する場合があります。
LDAPSは、Secure Sockets Layer上のLightweight Directory Access Protocol通信を指すために使用される用語です。
検索フィルタは、LDAP検索操作で、一致するエントリの定義のための基準を定義するメカニズムを提供します。LDAPで定義される検索フィルタには、次の10種類のタイプがあります:
0個以上の検索フィルタ要素を保持するコンテナとして機能します。ANDフィルタに含まれるすべての検索フィルタは、一致するANDフィルタのターゲット・エントリと一致する必要があります。
0個以上の検索フィルタ要素を保持するコンテナとして機能します。ORフィルタに含まれる少なくとも1つの検索フィルタは、一致するORフィルタのターゲット・エントリと一致する必要があります。
1つの検索フィルタ要素のコンテナとして機能します。埋込みフィルタは、一致するNOTフィルタのターゲット・エントリとは一致しません。
指定された属性に対して指定された値を含むエントリを識別するためのメカニズムを提供します。
指定された部分文字列と一致する属性値を含むエントリを識別するためのメカニズムを提供します。
指定された値以上の属性値を含むエントリを識別するためのメカニズムを提供します。
指定された値以下の属性値を含むエントリを識別するためのメカニズムを提供します。
指定された属性に少なくとも1つの値を含むエントリを識別するためのメカニズムを提供します。
指定された値におおよそ等しい属性値を含むエントリを識別するためのメカニズムを提供します。
拡張可能なメカニズムを使用して、一致するエントリを識別するために一致ルールを使用するメカニズムを提供します。
LDAP検索フィルタおよび検索フィルタを文字列として表現するメカニズムの詳細は、RFC 4515 (http://www.ietf.org/rfc/rfc4515.txt)を参照してください。
ldapsearchコマンドは、LDAP検索操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapsearch」を参照してください。
LDAP trueフィルタは特別なタイプのAND検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP trueフィルタと呼ばれるのは、常にtrueと評価され、エントリのいずれかと一致するためです。
LDAP trueフィルタの文字列表現は、(&)です。LDAP trueフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されています。
LDAPサブエントリは、ldapSubEntryオブジェクト・クラスを含むエントリのタイプです。これらのエントリでは、サーバー用の操作データを保持することを意味します。OIDが1.3.6.1.4.1.7628.5.101.1で値のないリクエスト制御を含めて明示的にリクエストしない場合は、クライアントに返されないという点で操作属性に似ています。この動作はdraft-ietf-ldup-subentryで説明されています。
検索でこの制御を使用する例は、「LDAPサブエントリ制御を使用した検索」を参照してください。
LDAP URLは、エントリまたは検索基準のセットの参照に使用できるURLのタイプです。LDAP URLのフォーマットは、RFC 4516 (http://www.ietf.org/rfc/rfc4516.txt)に説明されており、次の要素を含む場合があります:
ディレクトリ・サーバーのアドレス
ディレクトリ・サーバーのポート番号
検索属性のセット
検索する検索範囲
一致するエントリを識別するLDAP検索フィルタ
検索の処理方法についての情報を提供する拡張セット
これらの要素はすべてオプションです。技術的には、LDAP URLに必要なものは文字列ldap://のみです。ただし、より完全なURLはldap://directory.example.com:389/dc=example,dc=com?cn,givenName,sn?sub?(uid=john.doe)です。
LDIFエクスポート操作は、ディレクトリ・サーバー・バックエンドのコンテンツのすべてまたは一部をLDAPデータ変換形式を使用してファイルに書き込む処理です。LDIFエクスポートは、export-ldifコマンドまたはLDIFエクスポート・タスクを使用して開始できます。
LDIFインポート操作は、LDAPデータ変換形式の情報を保有するファイルからディレクトリ・サーバー・バックエンドへデータを追加する処理です。LDIFインポートは、LDAP追加操作よりもきわめて効率的にサーバーへ大量のエントリを追加する方法を提供します。
LDIFインポート操作は、import-ldifコマンドまたはLDIFインポート・タスクを使用して開始できます。
リーフ・エントリは、サーバー内に下位エントリを持たないエントリです。
小さいか等しい検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値以下の、指定された属性の特定の値を含むエントリの識別に使用できます。サーバーは、順序付け一致ルールを判断に使用します。
LDAP小さいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、小なり記号、等号、アサーション値および右カッコで構成されます。たとえば、小さいか等しいフィルタの(createTimestamp<=20070101000000Z)は、20070101000000Z以下のcreateTimestamp値を保有するエントリと一致します。
プロキシ分散アルゴリズム。アルファベットの範囲設定に基づいてデータをパーティションに分割します。たとえば、[A-E[が1つのパーティションで、[E-H[が次のパーティションです。
Lightweight Directory Access Protocol (LDAP)は、ディレクトリ・サーバーとの通信に使用できるプロトコルです。抽象構文表記法1の基本エンコーディング・ルールのサブセットを使用して、通信をメッセージにエンコードするオープン規格です。
コアLDAPv3の仕様は、実際のプロトコル用エンコーディングを定義するRFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)とともに、RFC 4510 (http://www.ietf.org/rfc/rfc4510.txt)で説明されています。その他多くの仕様が、多くのrequest for commentsおよびInternet Draftで定義されています。
LDAPは、いくつかの異なるタイプの操作を次のように定義します:
進行中の操作の処理を中止する方法を提供
サーバーに新規エントリを追加する方法を提供
サーバーへの認証の方法を提供
エントリが指定された属性値アサーションを保有するかどうかを判断する方法を提供
サーバーからエントリを削除する方法を提供
コアLDAPプロトコルに対する拡張として実装されるカスタム処理を実行する方法を提供
サーバー内のエントリのコンテンツを変更する方法を提供
サーバー内のエントリの名前を変更する方法を提供
指定された基準のセットに一致するすべてのエントリを識別する方法を提供
サーバーから切断するクライアントを示す方法を提供
ロード・バランシングはプロキシ・デプロイメントのタイプで、レプリケートされたリモートLDAPサーバーのセットへのシングル・アクセスを提供します。クライアントのリクエストの送信先であるリモートLDAPサーバーの選択は、ロード・バランシング・アルゴリズムにより決定されます。
検索制限は、ディレクトリ・サーバー内の構成オプションで、検索操作処理の進行中にサーバーが調べるエントリ数の制限を実施するために使用できます。この制限は、指定された検索基準に一致するかどうかにかかわらず、サーバーが調べるすべてのエントリに適用されます。
検索制限の構成属性は、索引なし検索またはきわめて大きな候補リストを伴う検索の影響を制限するために使用できます。
検索制限の構成の詳細は「ユーザー・アカウントへのリソース制限の設定」および「ルート・ユーザーのリソース制限の設定」を参照してください。
MakeLDIFコマンドは、LDAPデータ変換形式でエントリを生成するメカニズムを提供します。エントリは、データを生成する方法の制御に使用できる多くのタグを含む、テンプレートに基づいて生成されます。
このコマンドの使用方法の詳細は、「make-ldif」を参照してください。「MakeLDIFテンプレート・ファイルの作成」では、MakeLDIFテンプレート・ファイルの有効な構造およびコンテンツについて説明します。
Manage DSA IT制御は、サーバーがスマート・リフェラルを通常のエントリとして扱うようにリクエストするために、使用できる制御のタイプです。削除操作、変更操作またはDN変更操作に追加して、クライアントに返信されたリフェラルではなくスマート・リフェラルを含むエントリに対して操作を適用するようにサーバーにリクエストできます。検索操作にも追加して、検索結果の参照ではなく検索結果エントリとして、スマート・リフェラルを含むエントリをサーバーが返す必要があることを示します。
Manage DSA IT制御はRFC 3296 (http://www.ietf.org/rfc/rfc3296.txt)で定義されています。オブジェクト識別子は2.16.840.1.113730.3.4.2で、値はありません。
検索リクエストでこの制御を使用する例は、「DSA ITの管理制御を使用した検索」を参照してください。
一致したDNは、LDAP結果オブジェクトの要素で、サーバーで見つかった最も近い一致するエントリの追加情報を提供できます。通常、リクエストがターゲット設定したエントリが存在しない場合に使用され、この場合は、一致したDNには、サーバーに存在しており指定されたエントリに最も近い祖先であるエントリの識別名が含まれます。たとえばある操作が存在しないエントリのuid=doesnt.exist,ou=People,dc=example,dc=comをターゲット設定し、エントリのou=People,dc=example,dc=comがサーバーに存在する場合は、これが一致したDNとして返されます。
存在しないエントリをターゲット設定した操作から一致したDNが返される保証はなく、この場合は、LDAP結果の一致したDN要素は空の文字列です。たとえば、サーバー内でその他のエントリとの階層関係を持たないエントリに、リクエストがターゲット設定した場合に使用できます。
一致値制御は、検索操作に追加して、クライアントに返されるエントリに、指定されたフィルタと一致する値のみを含む必要があることを示す制御のタイプです。RFC 3876 (http://www.ietf.org/rfc/rfc3876.txt)で説明されています。
リクエスト制御のOIDは1.2.826.0.1.3344810.2.3です。値は次のようにエンコードされます:
ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
SimpleFilterItem ::= CHOICE {
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] SimpleMatchingAssertion }
SimpleMatchingAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
--- at least one of the above must be present
matchValue [3] AssertionValue}
対応するレスポンス制御はありません。
検索リクエストでこの制御を使用する例は、「一致値フィルタ制御を使用した検索」を参照してください。
一致ルールは、サーバーが属性の値と相互に作用する方法を定義するスキーマ要素です。一致ルールには、次の3つの標準タイプがあります:
等価一致ルールは、1つの属性値が別の属性値に等しいかどうかを判断するために使用されます。通常、この判断は正規化された値に基づいて実行され、重要ではない相違(大文字と小文字の相違または余分な空白など)は無視されます。
順序付け一致ルールは、ソート済リストの2つの値の間の相対的な順序を判断するために使用されます。この判断はサーバー側ソート制御の実行の際に使用されますが、大きいか等しい検索フィルタおよび小さいか等しい検索フィルタのフィルタ・コンポーネントでも使用されます。
部分文字列一致ルールは、指定された部分文字列検索フィルタが値に含まれるかどうかの判断に使用されます。
これらの標準一致ルールに加えて、ディレクトリ・サーバーは4番目のタイプ、近似一致ルールを定義します。これは、ある値が別の値におおよそ等しいかどうかの判断に使用されます。おおよそ等しいという定義には幅がありますが、一般的に使用される定義では、類似する、ということです。
一般的な一致ルールの例を次に示します:
2つのブール値が互いに等しいかどうかを判断する等価一致ルール。
大文字と小文字の相違を無視せず、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。
大文字と小文字の相違を無視せず、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。
大文字と小文字の相違を無視せず、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。
大文字と小文字の相違を無視して、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。
大文字と小文字の相違を無視して、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。
大文字と小文字の相違を無視して、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。
RDNコンポーネントを区切るカンマの前後の余分な空白、およびRDN名と値を区切る等号を無視して、2つの識別名が互いに等しいかどうかを判断する等価一致ルール。個別のRDN値は、対応するRDN属性に関連付けられる一致ルールに基づいて比較されます。
2つの一般的な時刻値が互いに等しいかどうかを判断する等価一致ルール。
2つの一般的な時刻値の間で相対的な順序を判断するために使用される順序付け一致ルール。
2つの整数値が互いに等しいかどうかを判断する等価一致ルール。
2つの整数値の間で相対的な順序を判断するために使用される順序付け一致ルール。
2つの値が互いに等しいかどうかをバイト対バイト比較で判断する等価一致ルール。
多くの場合、ディレクトリ・サーバーは、クライアントが認識する必要のない、完全に暗黙的な方法で一致ルールを使用します。クライアントが指定された属性タイプを参照する際は常に、サーバーはその属性に対する適切な一致ルールを自動的に認識して使用します。ただし、拡張可能な一致検索フィルタを使用して操作を実行する際に、サーバーが特定の一致ルールを使用するように、クライアントがリクエストすることも可能です。
サーバーで定義される一致ルールのセットは、サブスキーマ・サブエントリのmatchingRules属性を取得して確認できます。一致ルールの詳細は、「一致ルールの理解」を参照してください。
一致ルールの使用はスキーマ要素で、指定された一致ルールとともに使用可能な属性タイプを判断するために使用できます。拡張可能な一致検索フィルタを使用する場合にのみ適用されることに注意してください。
一致ルールの使用の定義には、適用する一致ルールのオブジェクト識別子、および一致ルールとともに使用できる属性タイプの名前またはOIDのリストが含まれます。属性がこのリストに含まれない場合は、関連付けられた一致ルールはともに使用できません。指定された一致ルールに対して定義される一致ルールの使用がない場合は、その一致ルールは任意の属性タイプとともに使用できるとみなされます。
サーバーで定義される一致ルールの使用のセットは、サブスキーマ・サブエントリのmatchingRuleUse属性を取得して確認できます。一致ルールの使用の詳細は、「一致ルールの使用の理解」を参照してください。
MD5は、RFC 1321 (http://www.ietf.org/rfc/rfc1321.txt)で定義される一方向メッセージ・ダイジェスト・アルゴリズムです。任意の長さの値を128ビット値にエンコードして、元のクリアテキストに戻して特定できないようにするために使用できます。通常、データのチェックサム用のメカニズムとして使用され、パスワードやその他機密情報のエンコードにも使用されます。
最近の暗号化技術の進歩により、MD5アルゴリズムの脆弱性が見つかっていることに注意してください。これらの発見は、ディレクトリ・サーバーによるMD5アルゴリズムの使用方法のセキュリティに直接は影響しませんが、セキュア・ハッシュ・アルゴリズムなどのより厳格なメカニズムを使用することをお薦めします。
「LDAPメッセージ」を参照してください。
メッセージIDは、メッセージに含まれる整数値で、リクエスト・メッセージとレスポンス・メッセージの関連付けに使用されます。クライアントはリクエスト・メッセージに含めるメッセージID値を選択し、サーバーはすべてのレスポンス・メッセージで同じメッセージIDを使用します。これによりクライアントは、いつでも同じ接続上で複数のリクエストを進行させることができます。すべての進行中のリクエストは常に、異なるメッセージIDを保有する必要があります。通常、クライアントはすべてのリクエスト・メッセージを対象にカウンタを順に増分し続けており、各リクエストは前回のリクエストとは異なるメッセージIDを取得します。
未承諾通知メッセージは、常にメッセージID値が0であることに注意してください。その他のすべてのLDAPメッセージのメッセージID値は、1から2147483647の間です。
変更は、単一の属性に対する変更を記述するLDAP変更操作の要素です。変更リクエストには、ターゲット・エントリに対する1つ以上の変更を含めることができます。
変更は、変更のタイプ(追加、削除、置換または増分)を記述する変更タイプ、および属性説明と0個以上の属性値を含む属性で構成されます。
変更タイプは、変更が実行された属性値を属性が保有できるようにする4つの方法のうちの1つを説明します。定義された変更タイプは次のとおりです:
1つ以上の値がターゲット属性に追加されます。属性がターゲット・エントリに存在しない場合は、指定された値が追加されます。そうでない場合は、指定された値は、その属性に対してすでに定義された値のセットに追加されます。追加変更タイプは常に少なくとも1つの値を指定する必要があります。
1つ以上の値がターゲット属性から削除されるか、その属性全体がターゲット・エントリから削除されます。1つ以上の特定の値が指定される場合は、それらの値のみがターゲット属性から削除されます(指定される値がその属性の値のセット全体を表す場合は、その属性がエントリから削除されます)。値が指定されない場合は、(含まれる値の数にかかわらず)属性全体がエントリから削除されます。
ターゲット属性の値のセットを指定された値のセットで置換します。置換は0個以上の値を保有し、その動作は次のとおりです:
エントリのターゲット属性に1つ以上の値が存在し、置換変更に値が含まれない場合は、ターゲット属性はエントリから削除されます。
エントリのターゲット属性に1つ以上の値が存在し、置換変更に1つ以上の値が含まれる場合は、既存の値のセットは新しい値のセットに置換されます。
エントリにターゲット属性が存在せず、置換変更に値が含まれない場合は、アクションは発生しません。
エントリにターゲット属性が存在せず、置換変更に1つ以上の値が含まれる場合は、指定された値のセットを保有する属性がエントリに作成されます。
ターゲット属性の値が指定された量により増分されます。ターゲット属性は1つの値のみを保有してエントリに存在し、その値は整数である必要があります。増分変更も1つの値のみを含み、その値は整数である必要があります。既存の値が増分値で指定された量により増分されます。増分値が負数の場合は、既存の値から、増分値の絶対値に等しい量が減じられます。
「LDAP DN変更操作」を参照してください。
「LDAP変更操作」を参照してください。
監視エントリは、サーバー・コンポーネントの情報を提供するサーバーのエントリのタイプです。監視の実施に関する統計情報、サーバーのヘルスの情報または値などその他の情報を提供できます。
ディレクトリ・サーバーは、汎用監視エントリに識別名のcn=monitorを指定します。その他多くの次のような監視エントリがその下に存在します:
名前書式はスキーマ要素で、どの属性タイプを構造オブジェクト・クラスに基づいたエントリの相対識別名で使用するかを制御するために使用できます。
名前書式の定義には次のコンポーネントがあります:
名前書式を一意に識別するために使用されるオブジェクト識別子。
名前書式の参照をより容易にするために使用可能な0個以上の名前のセット。
名前書式が関連付けられる構造オブジェクト・クラスの名前またはOID。構造クラスを持つエントリは、名前書式の要件に準拠したRDNを保有する必要があります。
関連付けられた構造クラスを含むエントリのRDNに存在する必要のある属性の、属性タイプ名またはOIDの1つ以上のセット。
関連付けられた構造クラスを含むエントリのRDNにオプションで存在する場合のある属性の、1つ以上の属性タイプ名またはOIDのオプション・セット。
サーバーで定義される名前書式のセットは、サブスキーマ・サブエントリのnameForms属性を取得して確認できます。名前書式の詳細は、「名前書式の理解」を参照してください。
ネーミング・コンテキストは接尾辞とも呼ばれ、サーバーのディレクトリ情報ツリーで最上位のエントリです。このエントリには親はありません。
サーバーで定義されるネーミング・コンテキストのセットは、ルートDSEのnamingContexts属性にリストされます。ネーミング・コンテキストは、ワークフローを介して参照可能です。
ネットワーク・グループには、クライアント接続のカテゴリを定義する基準のセットが含まれています。サーバーに送信されたクライアント・リクエストがネットワーク・グループにアタッチされたポリシーに適合している場合は、ネットワーク・グループはそのリクエストをワークフローに転送します。
リーフ以外のエントリは、サーバー内に少なくとも1つの下位エントリを保有するエントリです。
正規化された値は、他の値と効率的に比較できるようにする方法で処理された値です。正規化処理は、一致ルールを使用して実行され、一致ルールのタイプに基づいて変わります。実行できる変換の種類には次のものがあります:
大文字と小文字の区別による重要ではない相違を排除するため、すべての文字を小文字(または大文字)に変換
値の不要な空白を排除
複数の表現を持つ値を共通の形式に変換
切断の通知は、なんらかの理由(サーバーが停止される、またはクライアントが長時間アイドル状態であるなど)により、クライアントとの接続をサーバーが閉じようとしていることを示すために使用できる未承諾通知のタイプです。
切断の通知を含む拡張レスポンスのOIDは1.3.6.1.4.1.1466.20036です。レスポンス値はありませんが、結果コードにより切断の理由が示され、診断メッセージにより判読可能な説明が提供されます。
NOT検索フィルタは、1つの埋込み検索フィルタを保持するコンテナとして機能するためのLDAP検索フィルタのタイプです。NOTフィルタは基本的に逆操作で、エントリがNOTフィルタと一致するには、埋込みフィルタとは一致しません。
NOTフィルタは、フィルタ全体をカッコで囲み、左カッコの直後に感嘆符を配置した文字列で表されます。たとえば、フィルタ(!(objectClass=person))は、オブジェクト・クラス値がpersonではないエントリのみ一致します。
数値の範囲設定に基づいてデータをパーティションに分割するプロキシ分散アルゴリズム。たとえば、[1-1000[が1つのパーティションで、[1000-2000[が次のパーティションです。
オブジェクト・クラスはスキーマ要素で、オブジェクト識別子および名前のセットを、必須およびオプションの属性タイプのセットと関連付けます。
オブジェクト・クラスのコンポーネントの定義には次のものがあります:
オブジェクト・クラスを一意に識別するために使用されるOID。
オブジェクト・クラスの参照をより容易にするために使用できる0個以上の名前のセット。
オプションの上位クラス。必須またはオプション、あるいはその両方の追加する属性タイプを定義できます。
オプションのオブジェクト・クラス・タイプ値。オブジェクト・クラスが構造オブジェクト・クラス、補助オブジェクト・クラスまたは抽象オブジェクト・クラスのいずれであるかを示します。
属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリに存在する必要があります。
属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリにオプションで存在する場合があります。
各エントリに1つの構造オブジェクト・クラスを必要とし、0個以上の補助クラスが存在する場合もあります。エントリのオブジェクト・クラスの一連のセットは、必須または存在できる属性タイプのセットを定義します。構造クラスは、名前書式、DITコンテンツ・ルールまたはDIT構造ルール、あるいはその両方とエントリを関連付けるためにも使用できます。
サーバーで定義されたオブジェクト・クラスのセットは、サブスキーマ・サブエントリのobjectClasses属性を取得して確認できます。オブジェクト・クラスの詳細は、「オブジェクト・クラスの理解」ドキュメントを参照してください。
オブジェクト・クラス・タイプは、オブジェクト・クラスのカテゴリの定義に使用されます。次の3つのオブジェクト・クラス・タイプ値があります:
構造オブジェクト・クラスは、エントリの主要なタイプの定義に使用されます。各エントリは構造クラスを1つ必要とし、構造クラスはエントリを説明するオブジェクトの主要なタイプを定義します。
補助オブジェクト・クラスは、エントリの特性の定義に使用されます。1つのエントリは、0個以上の補助クラスを保有できます。エントリが保有できる補助クラスのセットは、エントリの構造クラスに関連付けられたDITコンテンツ・ルールにより制御できます。
抽象オブジェクト・クラスは、エントリでは直接使用せず、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。
LDAPオブジェクト・クラスで使用される継承モデルは、Javaクラスの継承モデルとよく似ています。エントリに構造オブジェクト・クラスが1つのみ必要なように、Javaクラスにもスーパークラスが1つ必要です。同様に、エントリは複数の補助クラスを保有できますが、Javaクラスは複数のインタフェースを実装できます。最後に、抽象オブジェクト・クラスのみを含むエントリを作成できないように、抽象Javaクラスのインスタンス化はできません。
オブジェクト識別子(OID)は、ピリオドで区切られた一連の整数で構成される文字列です。ディレクトリ・サーバーでは、次のような様々な要素のタイプの一意の識別子として使用されます:
操作IDは、クライアント接続で実行される各操作に割り当てられる整数の識別子です。主にロギングのために使用して、レスポンス・ログ・メッセージを対応するリクエスト・メッセージと関連付けることができます。
クライアント接続で最初に実行される操作には操作IDに0が割り当てられ、クライアント接続上で受信される各追加リクエストのために操作IDが1ずつ増分されます。
ユーザー属性は、directoryOperation、distributedOperationまたはdSAOperationの属性使用方法を持つ属性タイプです。操作属性は、サーバー自体で処理を行ったり、サーバーで維持されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。
操作属性は、検索属性のリストに明示的に含まれる場合を除き、検索操作で返されたエントリには含まれません。明示的な値として+(プラス記号)もすべての操作属性を返すリクエストに含める場合があります。
順序付け索引は、属性の値の相対的な順序を追跡するために使用される索引のタイプです。正規化された値に対して等価一致ルールのかわりに順序付け一致ルールを使用することを除けば、等価索引とよく似ています。順序付け索引は、対応する順序付け一致ルールを持たない属性に対しては維持できません。
OR検索フィルタは、0個以上のその他の検索フィルタを保持するコンテナとして機能するためのLDAP検索フィルタのタイプです。エントリがORフィルタと一致するには、そのORフィルタに含まれる少なくとも1つのフィルタと一致する必要があります。
ORフィルタは、フィルタ全体をカッコで囲み、左カッコの直後にパイプ記号(|)を配置した文字列で表されます。たとえば、フィルタ(|(uid=john.doe)(uid=jane.doe))は、(uid=john.doe)および(uid=jane.doe)の等価フィルタを埋め込んだOR検索フィルタを表します。
埋込みフィルタを含まないORフィルタは、LDAP falseフィルタと呼ばれます。LDAP falseフィルタの文字列表現は(|)で、LDAP falseフィルタはいずれのターゲット・エントリとも一致しません。
OID検索件数リクエスト制御には、データが含まれていません。検索リクエストとともに送信する必要があります。
OID検索件数レスポンス制御のデータには、検索に関連したエントリの数を示す、BERでエンコードされたインテグレータが含まれます。検索によって戻されるエントリはありません。検索に関連したエントリの数を示す制御のみが戻されます。
プロキシ分散デプロイメントでは、データは、パーティションと呼ばれるより小さなデータ・チャンクに分割されます。通常、データのパーティションは、高可用性を保証するために、個別のリモートLDAPサーバーまたはレプリケートされたリモートLDAPサーバーのセットに保管されます。
パスワードは、一部の認証メカニズムでアイデンティティの証明に使用できる非公開の値です。特に、パスワードは簡易認証、およびCRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズム、PLAIN SASLメカニズムのSimple Authentication and Security Layerメカニズムで使用されます。
パスワードによるセキュリティは、パスワードの所有者のみがパスワードの内容を認識するという事実に完全に基づいています。別の者がなんらかの方法であるユーザーのパスワードを知ることがあれば、その第三者はユーザーを偽装し、ユーザーが使用可能な操作を実行できます。
ディレクトリ・サーバーには多くのパスワード・ポリシー機能があり、パスワードが第三者個人に知られないことを保証する支援に使用できますが(たとえば、脆弱なパスワードの使用をユーザーに許可しないことを保証する支援をしたり、総当たり攻撃から保護したり、保護された方法で実行される認証の試行およびパスワードの変更を要求したりします)、多くの場合、パスワードは証明書のような別の種類の識別よりも脆弱な保護の形式であるとみなされます。
パスワード有効期限は、ディレクトリ・サーバー・パスワード・ポリシーの要素で、ユーザーが同じパスワードを継続して使用できる期間の長さを制限するために使用できます。パスワード有効期限が有効化されている場合は、ユーザーがパスワードを変更すると、最大パスワード経過時間として指定された期間、パスワードを使用できます。パスワード有効期限が近づくと、ユーザーはバインド・レスポンスの制御の形式で警告メッセージを受け取ることができます。パスワードの有効期限が切れると、それ以降、ユーザーは認証を許可されません。
ユーザーのパスワードの有効期間が切れると、アカウントを使用するには、管理者がパスワードのリセットを実行する必要があります。または、パスワード・ポリシーが適切に構成されている場合は、パスワード変更拡張操作を使用して、ユーザーが自分の有効期限の切れたパスワードを変更することもできます。
パスワード・ジェネレータは、パスワード変更拡張操作の一部として、ユーザーのパスワードを生成するために使用できるロジックの部分です。パスワード変更リクエストに新しいパスワードが含まれていない場合に使用されます。
パスワード変更拡張操作は、ユーザーのパスワードの変更またはパスワードのリセットに使用できる拡張操作のタイプです。RFC 3062 (http://www.ietf.org/rfc/rfc3062.txt)で説明されており、リクエスト操作およびレスポンス操作のOIDは両方とも1.3.6.1.4.1.4203.1.11.1です。
パスワード変更リクエストの値は次のとおりです:
PasswdModifyRequestValue ::= SEQUENCE {
userIdentity [0] OCTET STRING OPTIONAL
oldPasswd [1] OCTET STRING OPTIONAL
newPasswd [2] OCTET STRING OPTIONAL }
パスワード変更レスポンスの値は次のとおりです:
PasswdModifyResponseValue ::= SEQUENCE {
genPasswd [0] OCTET STRING OPTIONAL }
ディレクトリ・サーバー・パスワード・ポリシーは、サーバーでのパスワードの保管と維持の方法、およびユーザーの認証を許可する方法を制御するメカニズムを提供します。
パスワード・ポリシーの要素には次のものがあります:
ユーザー・パスワードの保管に使用される属性。デフォルトでは、userPassword属性です。
サーバーで保管されたパスワードのエンコードに使用されるパスワード記憶スキームのデフォルトのセット。
非推奨パスワード記憶スキームのセット。ユーザーの認証に使用できますが、正常なバインド上のデフォルトのスキームを使用してパスワードを再エンコードします。
ユーザーが自分のパスワードを変更できるかどうかを示すフラグ。
パスワード有効期限に関連する多くの設定。最大パスワード経過期間、有効期限前の警告およびユーザーがパスワードの有効期限切れ後にパスワードを変更できるかどうかが含まれます。
アカウント・ロックアウトに関連する多くの設定。認証を試行して何度も失敗した後で、ユーザーの認証を妨げるために使用できます。
ユーザーが初めて認証するパスワードの変更が必要かどうか、または管理者にリセットされた後でパスワードの変更が必要かどうか、あるいはその両方を示すフラグ。
パスワード・バリデータのセット。提案された新しいパスワードの値の使用が許可されるかどうかの判断に使用できます。
パスワードの変更を許可するために、現在のパスワードの入力をユーザーに要求するかどうかを示すフラグ。
新しいパスワードがサーバーで定義されるパスワード記憶スキームの1つを使用してすでにエンコードされている場合、そのパスワードの指定をクライアントに許可するかどうかを示すフラグ。事前にエンコードされたパスワードの許可が必要なアプリケーションもありますが、パスワード・バリデータのように、適用される可能性のある制限をユーザーがバイパスできる場合もあります。
最終ログイン時刻の維持に関する設定。値の保管に使用する属性、タイムスタンプで使用するフォーマットおよび認証なしで長時間経過したアカウントをロックするかどうかが含まれます。
保護された方法による認証をユーザーに要求するのかどうか、または保護された方法によるパスワードの変更をユーザーに要求するのかどうか、あるいはその両方を制御するフラグ。
パスワード・ポリシー・リクエスト制御はLDAP制御のタイプで、ユーザー・エントリに対する現在のパスワード・ポリシーの状態についての情報をリクエストするために使用できます。draft-sisbehera-ldap-password-policy (https://opends.dev.java.net/public/standards/draft-behera-ldap-password-policy.txt)で定義されています。リクエスト制御およびレスポンス制御のOIDは両方とも1.3.6.1.4.1.42.2.27.8.5.1です。リクエスト制御には値がありません。レスポンス制御の値は次のようにエンコードされます:
PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
error [1] ENUMERATED {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
insufficientPasswordQuality (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) } OPTIONAL }
検索リクエストでこの制御を使用する例は、「パスワード・ポリシー制御を使用した検索」を参照してください。
パスワードのリセットは、ユーザーのパスワードを変更するサーバー管理者の行為です。パスワードのリセットは、アカウントの保有者以外の任意のユーザーにより実行されるパスワードの変更です。
パスワード記憶スキームは、サーバーで保管されるユーザー・パスワードをエンコードするためのメカニズムを提供します。ユーザーが入力したパスワードが正しいかどうかをサーバーは判断できますが、多くの場合、パスワードは、クリアテキスト・パスワードの内容をユーザーに決定させない方法でエンコードされます。現在使用可能なパスワード記憶スキームには次のものがあります:
パスワードはトリプルDESを使用してエンコードされます。トリプルDESは、データ暗号化規格(DES)のバリエーションで、以前のものよりも3倍時間がかかりますが、厳格な信頼性があります。このアルゴリズムでは、1つの長さ192ビットの組合せキーのために3つの64ビットのキーを使用します。データは、第一の鍵で暗号化され、第二の鍵で復号化され、さらに第三の鍵で再度暗号化されます。3つの鍵すべて、第一のキーと第二のキー、または第二のキーと第三のキーが同一でないことを確認する必要があります。
Advanced Encryption Standardは、128 (AES-128)ビット、192 (AES-192)ビットおよび256 (AES-256)ビットの長さの暗号鍵を使用して、128ビットのデータ・ブロックを処理できる、Rijndaelアルゴリズムに基づいた対称型ブロック暗号です。
パスワードはbase64エンコーディングで、保護の形式はたいへん脆弱で、クライアントがこの記憶スキームを要求する場合にのみ使用されます。
パスワードはキーの長さが128ビットのBlowFishアルゴリズムを使用してエンコードされます。
パスワードは、不明瞭化されることなくクリア・テキストで格納されます。このスキームには、{CLEAR}という記憶スキーム名のユーザー・パスワード構文の実装のみが含まれます。したがって、まったく保護がないため、このスキームは、クライアントがこの記憶スキームを要求した場合にのみ使用されます。
ただし、ClearPassowrdScheme構成パラメータを構成して、パスワードを戻す際にサーバーで中カッコ内のスキーム名を不明瞭化することができます。この構成パラメータは、クリア・テキスト・パスワード記憶スキームでスキーム名を不明瞭化するかどうかを指定します。
サーバーでスキーム名を不明瞭化する場合は、不明瞭化フラグをtrueに構成できます。デフォルト値はfalseです。
パスワードはUNIX暗号化アルゴリズムを使用してエンコードされます。一方向アルゴリズムですが、現在の標準よりも脆弱であるとみなされており、通常、この記憶スキームを要求するクライアントにのみ使用されます。
パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。saltハッシュをお薦めしますが、比較的安全で、セキュア・ハッシュ・アルゴリズムのバリアントはMD5よりも厳格であるとみなされます。
パスワードは、キーサイズが変更可能で、バイト単位で操作するストリーム暗号のRC4を使用してエンコードされます。このアルゴリズムは、ランダムな置換の使用に基づいています。
パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSalt付きバージョンを使用してエンコードされます。
パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。このアルゴリズムではSalt付きのバリアントをお薦めします。
パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSalt付きバージョンを使用してエンコードされます。これは、ディレクトリ・サーバーで使用されるデフォルトのパスワード記憶スキームです。
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き256ビット・バージョンを使用してエンコードされます。
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き384ビット・バージョンを使用してエンコードされます。
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き512ビット・バージョンを使用してエンコードされます。
ディレクトリ・サーバーでは認証パスワード構文の使用もサポートしていることに注意してください。
パスワード・バリデータはディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、提案されたパスワードの使用を許可できるかどうかを判断するために使用されます。ディレクトリ・サーバーはカスタム・パスワード・バリデータの開発のために拡張可能なAPIを提供しますが、そのAPIは、次のようないくつかの異なるタイプのパスワード・バリデータに使用されます:
ユーザーのエントリに含まれる属性の値の中にパスワードの値が存在する場合は、パスワードを拒否するために使用できるバリデータ。
パスワードの値が許可された文字セットの範囲にある文字を含まない場合は、パスワードを拒否するために使用できるバリデータ。
パスワードが辞書に存在する言葉である場合は、拒否するために使用できるバリデータ。
パスワードが長すぎるか短すぎる場合は、拒否するために使用できるバリデータ。
パスワードが何度も繰り返される文字による文字列を含む場合は、拒否するために使用できるバリデータ。
パスワードがユーザーの現在のパスワードに酷似している場合は、拒否するために使用できるバリデータ。
パスワードが十分に一意となる文字を含まない場合は、拒否するために使用できるバリデータ。
永続検索制御はLDAP制御のタイプで、関連付けられたLDAP検索操作の基準に一致するエントリに対する変更をクライアントに通知するために使用できます。永続検索制御はdraft-ietf-ldapext-psearch (https://opends.dev.java.net/public/standards/draft-ietf-ldapext-psearch.txt)で説明されており、OIDは2.16.840.1.113730.3.4.3です。次のように定義されます:
PersistentSearch ::= SEQUENCE {
changeTypes INTEGER,
changesOnly BOOLEAN,
returnECs BOOLEAN
}
この検索の一部として返される検索結果エントリは、オプションで、エントリが変更した方法を説明するエントリ変更通知制御を含む場合があります。検索でこの制御を使用する例は、「永続検索制御を使用した検索」を参照してください。
PLAIN Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。一般的に、識別名ではなくユーザー名でクライアントがクライアント自体を認証要求できることを除けば、簡易認証とよく似ています。別の認可IDを指定する機能もクライアントに提供します。
簡易認証と同様、PLAIN SASLメカニズムはユーザー・パスワードを保護する形式を提供しないため、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルの場合のみ、この認証方法の使用をお薦めします。
プラグインは、ディレクトリ・サーバーが処理を実行する過程に、カスタム・ロジックを挿入するために使用できるコードの部分です。ディレクトリ・サーバーは、次のような様々なタイプのプラグインを多数サポートします:
事前解析プラグイン。サーバーがリクエストの処理を開始する前に、リクエストのコンテンツを変更できるようにします。事前解析プラグインは、すべてのタイプの操作で使用可能です。
操作前プラグイン。操作の中心となる処理の前に、サーバーがいくつかのアクションを実行できるようにします。操作前プラグインは、中止操作およびアンバインド操作を除くすべてのタイプの操作で使用可能です。
操作後プラグイン。操作の中心となる処理の直後でレスポンスがクライアントに送信される前に、サーバーがいくつかのアクションを実行できるようにします(クライアントへのレスポンスの変更に使用される場合もあります)。操作後プラグインは、すべてのタイプの操作で使用可能です。
レスポンス後プラグイン。完了した操作のすべての処理の後で、サーバーがいくつかのアクションを実行できるようにします。レスポンス後プラグインは、中止およびアンバインドを除くすべてのタイプの操作で使用可能です。
検索結果参照プラグイン。検索操作の一部として送信される検索結果参照のコンテンツを変更します。
中間レスポンス・プラグイン。クライアントに送信されるLDAP中間レスポンスのコンテンツを変更します。
起動プラグイン。サーバーが最初に起動する際にいくつかの処理を実行します。
停止プラグイン。サーバーが正常に停止する際にいくつかの処理を実行します。
接続後プラグイン。新しいクライアント接続の許可の一部としていくつかの処理を実行します。
切断後プラグイン。接続の終了直後にいくつかの処理を実行します。
LDIFインポート・プラグイン。LDAPデータ変換形式ファイルからインポートされるエントリのコンテンツを変更します。
LDIFエクスポート・プラグイン。サーバー・バックエンドからエクスポートされるエントリのコンテンツを変更します。
プレゼンス索引は、指定された属性の値を少なくとも1つ保有するエントリの追跡に使用される索引のタイプです。属性ごとにプレゼンス索引キーが1つのみ存在し、そのIDリストには、指定された属性を含むすべてのエントリのエントリIDが含まれます。
プレゼンス検索フィルタは、LDAP検索フィルタのタイプで、指定された属性の値を少なくとも1つ保有するエントリの識別に使用できます。LDAPプレゼンス・フィルタの文字列表現は、左カッコに続く属性名、等号、アスタリスクおよび右カッコで構成されます。たとえば、等価フィルタ(aci=*)は、aci属性の値を少なくとも1つ含むエントリと一致します。
ディレクトリ・サーバーには特権サブシステムがあり、ユーザーに権限を付与する機能の定義に使用できます。特権サブシステムは、ユーザーが操作の実行を許可されているかどうかを判断するプロセスで、アクセス制御実装とともに動作します。
ディレクトリ・サーバーで定義される特権には、次のものがあります:
bypass-aclアクセス制御の評価のバイパスをユーザーに許可
modify-aclサーバーで定義されるアクセス制御ルールの変更をユーザーに許可
config-readサーバー構成の読取りアクセス権の保有をユーザーに許可
config-writeサーバー構成の書込みアクセス権の保有をユーザーに許可
server-shutdownサーバーの停止をユーザーがリクエストすることを許可
server-restartサーバーのインコア再起動実行のリクエストをユーザーに許可
proxied-auth異なる認可IDによる操作のリクエストをユーザーに許可
unindexed-search索引なし検索のリクエストをユーザーに許可
password-resetその他のユーザーに対するパスワードのリセットをユーザーに許可
update-schemaサーバー・スキーマの更新をユーザーに許可
特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」を参照してください。
クライアントのリクエストをレプリケートされたリモートLDAPサーバーのセットに配布するプロキシ・ロード・バランシング・アルゴリズム。各リモートLDAPサーバーに送信されるリクエストの数は、重み設定により決定されます。
プロトコル・データ・ユニット(PDU)は、ネットワーク通信の単一の完全な要素です。LDAPの場合は、PDUはメッセージです。
プロトコルopは、リクエストまたはレスポンスの核を含むメッセージの要素です。つまり、メッセージのタイプを示します。プロトコルop要素には、次のようないくつかの異なる種類があります:
プロキシ認可制御は、関連付けられた操作を別のユーザーの認可で実行するリクエストに使用できる制御のタイプです。
2つの異なる形式のプロキシ認可制御があり、いずれも追加操作、比較操作、削除操作、変更操作、DN変更操作または検索操作に追加できるリクエスト制御です。
プロキシ認可v1制御は、初期のバージョンのdraft-weltman-ldapv3-proxyで定義されています。OIDは2.16.840.1.113730.3.4.12で、制御値は次のようにエンコードされます:
proxyAuthValue::= SEQUENCE {
proxyDN LDAPDN
}
プロキシ認可v2制御は、RFC 4370 (http://www.ietf.org/rfc/rfc4370.txt)で定義されています。OIDは2.16.840.1.113730.3.4.18で、値は必要な認可IDに含まれる文字列です。
検索リクエストでこの制御を使用する例は、「プロキシ設定された認可制御を使用した検索」を参照してください。
保護品質(QoP)は、特定のSimple Authentication and Security Layerメカニズム(特にDIGEST-MD5 SASLメカニズムおよびGSSAPI SASLメカニズム)のプロパティで、クライアントとサーバーの間の通信を保護するために使用できます。
次のように、3つの異なるQoPレベルがあります:
auth関連付けられたSASLメカニズムがクライアント接続の認証にのみ使用されることを示します。クライアントサーバー通信のためのその他の保護は行いません。
auth-int関連付けられたSASLメカニズムが認証に使用され、完全性保護もクライアントとサーバーの間の通信に提供されることを示します。完全性保護では第3者が通信を解読することを防ぎませんが、検出不可能な方法での介在者による通信の変更を不可能にすることを保証します。
auth-conf関連付けられたSASLメカニズムが認証に使用され、完全性および機密性の保護もクライアントとサーバーの間の通信に提供されることを示します。第3者が通信を解読できないことを保証します。
現在、ディレクトリ・サーバーではauth保護品質のみをサポートしています。auth-intまたはauth-confのいずれのレベルもサポートしていません。
実在属性専用制御は、サーバーが実在する属性のみを一致するエントリに含めるように要求するために使用できる制御です。つまり、仮想属性は検索結果エントリから除外されます。
実在属性専用制御のリクエスト・オブジェクト識別子は2.16.840.1.113730.3.4.17で、値はありません。
次の検索で、numsubordinates仮想属性がリクエストされ、返されます:
$ ldapsearch -D "cn=directory manager" -j pwd-file -b "ou=people,dc=example,dc=com" \ -s base "objectclass=*" numsubordinates version: 1 dn: ou=People,dc=example,dc=com numSubordinates: 50
次の検索で、numsubordinates仮想属性がリクエストされますが、実在属性専用制御が使用されるため、返されません:
$ ldapsearch -D "cn=directory manager" -j pwd-file -J "2.16.840.1.113730.3.4.17" \ -b "ou=people,dc=example,dc=com" -s base "objectclass=*" numsubordinates version: 1 dn: ou=People,dc=example,dc=com
参照整合性は、エントリの削除や変更の際は常に、エントリへの参照が更新されることを保証するメカニズムです。従来から、参照整合性は主に、識別名構文を持つ属性(特にmemberおよびuniqueMemberなどのグループ・メンバーシップ属性)が削除操作およびDN変更操作のイベントで正しく維持されることを保証するために使用されます。削除操作の場合は、ターゲット・エントリの参照は削除されます。DN変更操作の場合は、ターゲット・エントリに対する参照は操作に応じて名前が変更されます。
ディレクトリ・サーバーは、dsconfigコマンドを使用してインストールできる、構成可能な参照整合性プラグインを提供します。
リフェラルは、操作を処理できる別の場所への参照を提供します。リフェラルは、結果コードに10、および適切なLDAP URLのセットを保有するLDAP結果オブジェクトに含めることができます。検索結果参照でクライアントにも返すことができます。
相対識別名すなわちRDNは、識別名内の単一のコンポーネントです。1つ以上の名前/値ペアで構成され、名前/値ペアの名前と値は等号で区切られます(たとえば、RDN uid=annの場合は、名前はuidで値はann)。複数の名前/値ペアが存在する場合は、プラス記号で区切られます(たとえば、RDN cn=Jon Doe+employeeNumber=12345の場合は、名前/値ペアはcn=John DoeおよびemployeeNumber=12345)。実際には、複数の名前/値ペアを含むRDN(複数値RDNと呼ばれる)はまれですが、エントリに一意の属性がない場合、または役立つ識別情報がエントリのDNに含まれていることを確認する場合に役立ちます。
DNが複数のRDNコンポーネントから構成されている場合も、通常、一番左のコンポーネントがエントリのRDNとして参照されます。たとえば、DN uid=john.doe,ou=People,dc=example,dc=comでは、RDNはuid=john.doeです。エントリのRDNで指定された属性値は、そのエントリに含まれる必要があるため、エントリuid=john.doe,ou=People,dc=example,dc=comは、uidの値john.doeを保有します。
レプリカは、レプリケーションに参加するディレクトリ・サーバー・インスタンスです。
レプリケーションはデータ同期の形式で、ディレクトリ環境の変更がサーバーの各インスタンスに反映されることを保証するために使用されます。つまり、1つのディレクトリ・サーバー・インスタンスで実行される変更は常に、同じ変更がその他の各インスタンスでも実行されます。
レプリケーション修復制御は、トポロジ内の単一のサーバーで、レプリケーションの非一貫性を解決するために使用できる制御です。
レプリケーション修復制御のリクエスト・オブジェクト識別子は1.3.6.1.4.1.26027.1.5.2で、値はありません。
レプリケーション修復制御を使用する例は、「レプリケーションの非一貫性の検出および解決」を参照してください。
request for comments (RFC)は、Internet Draftから昇格したIETF (http://www.ietf.org/)の仕様で、Draftと比較して十分安定していると考えられます。
復元操作は、ディレクトリ・サーバー・バックエンドのコンテンツを以前のバックアップから取得した情報で置換するメカニズムを提供します。障害時リカバリ・メカニズムとして機能し、レプリカのバイナリ・コピーの初期化にも使用できる場合があります。
「LDAP結果」を参照してください。
結果コードは、操作の結果についての汎用情報を提供する整数値です。定義された結果コードには次のものがあります:
| 値 | 名前 | 説明 |
|---|---|---|
|
0 |
成功 |
関連付けられた操作が正常に完了したことを示すために使用されます。 |
|
1 |
操作エラー |
関連付けられたリクエストと進行中の別の操作の順序が間違っていたことを示すために使用されます(マルチステージSASLバインドの途中の非バインド・リクエストなど)。 |
|
2 |
プロトコル・エラー |
クライアントがサーバーに送信したデータが、有効なLDAPリクエストを構成していなかったことを示すために使用されます。 |
|
3 |
時間制限を超過しました |
関連付けられたリクエストの処理を、時間がかかりすぎて完了できないために終了したことを示すために使用されます。検索操作では、時間制限に達した際に一致するエントリの一部が返されている場合もあります。 |
|
4 |
サイズ制限を超過しました |
検索操作に含まれる基準に一致するエントリが、サイズ制限の構成により返すことのできるエントリよりも多く存在することを示すために使用されます。 |
|
5 |
Falseを比較 |
比較操作は正常に終了しましたが、指定された属性値アサーションはターゲット・エントリと一致しなかったことを示すために使用されます。 |
|
6 |
Trueを比較 |
比較操作は正常に終了し、指定された属性値アサーションはターゲット・エントリと一致したことを示すために使用されます。 |
|
7 |
認証方法がサポートされていません |
ディレクトリ・サーバーはリクエストされた認証方法をサポートしていないことを示すために使用されます。 |
|
8 |
強い認証が必要です |
ディレクトリ・サーバーはクライアントに強い認証メカニズムを使用する要求をしていることを示すために使用されます。 |
|
10 |
リフェラル |
リクエストされた操作はターゲット・サーバーでは処理できませんでしたが、別の場所で試行する可能性があることを示すために使用されます。 |
|
11 |
管理上の制限を超過しました |
リクエストされた操作の処理は、管理上の制限に達したため完了できなかったことを示すために使用されます。検索操作では、管理上の制限に達した際に一致するエントリの一部が返されている場合もあります。 |
|
12 |
クリティカルな拡張機能を使用できません |
リクエストがサーバーで処理できないクリティカルな制御を含んでいたことを示すために使用されます。 |
|
13 |
機密性が必要です |
リクエストされた操作は、クライアントとサーバーとの間に保護された通信チャネルを必要とすることを示すために使用されます。 |
|
14 |
SASLバインドが進行中です |
SASLバインド操作が複数のステージを要求し、この結果コードを含むレスポンスは中間ステージの1つであることを示すために使用されます。 |
|
16 |
そのような属性はありません |
関連付けられたリクエストは、指定されたエントリに存在しない属性または属性値をターゲット設定したことを示すために使用されます。 |
|
17 |
未定義の属性タイプ |
関連付けられたリクエストは、サーバー・スキーマで定義されていない属性タイプを含んでいたことを示すために使用されます。 |
|
18 |
不正な照合 |
関連付けられた検索リクエストに含まれたフィルタに、適切な一致ルールで定義されていない属性タイプをターゲットとするコンポーネントが存在したことを示すために使用されます。 |
|
19 |
制約違反 |
リクエストされた操作は、サーバーで定義された制約に違反したため(一意の属性の値を複製したなど)、完了できなかったことを示すために使用されます。 |
|
20 |
属性または値が存在します |
エントリにすでに存在するエントリの属性値の作成、または単一値の属性に対する追加の値を作成する操作が試行されたことを示すために使用されます。 |
|
21 |
無効な属性構文 |
リクエストされた操作により、関連付けられた属性タイプの構文に違反した値の指定が試行されたことを示すために使用されます。 |
|
32 |
該当するオブジェクトがありません |
リクエストされた操作は、サーバーに存在しないエントリをターゲット設定したことを示すために使用されます。 |
|
33 |
エイリアスの問題 |
操作は別名エントリをターゲット設定し、その操作は別名エントリに対して許可されていないことを示すために使用されます。 |
|
34 |
無効なDN構文 |
リクエストされた操作は、不正な形式のエントリDNを含んでいたことを示すために使用されます。 |
|
35 |
リーフ |
リクエストされた操作はリーフ・エントリをターゲット設定しましたが、その操作はリーフでないエントリを要求することを示すために使用されます。 |
|
36 |
エイリアス間接参照の問題 |
関連付けられた検索操作が、適切に間接参照できない別名を検出したことを示すために使用されます。 |
|
48 |
不正な認証 |
クライアントが、ターゲット・ユーザーに対して適切でない方法でバインドを試みたことを示すために使用されます(ユーザーは簡易認証を試みたがパスワードを保有していない場合など)。 |
|
49 |
無効な資格証明 |
クライアントが無効な資格証明を使用して認証を試行したことを示すために使用されます(ターゲットDNまたはパスワードが不正であった場合など)。 |
|
50 |
不十分なアクセス権限 |
クライアントがリクエストされた操作の実行を許可されなかったことを示すために使用されます。 |
|
51 |
ビジー |
サーバーがビジーのため、リクエストされた操作を処理できないことを示すために使用されます。 |
|
52 |
使用不可 |
サーバーは操作の処理に使用できないことを示すために使用されます。 |
|
53 |
実行要求を拒否 |
なんらかの理由により、リクエストされた操作の実行をサーバーが拒否していることを示すために使用されます。 |
|
54 |
ループを検出 |
なんらかのタイプのループ(チェーン・ループまたは別名ループなど)をサーバーが検出したことを示すために使用されます。 |
|
60 |
ソート制御がありません |
サーバー側ソート制御を含まない仮想一覧表示制御を含む検索操作を、クライアントがリクエストしたことを示すために使用されます。 |
|
61 |
オフセット範囲エラー |
無効なオフセットを指定した仮想一覧表示制御をリクエストに含んでいたことを示すために使用されます(結果セットの最後以外の場所など)。 |
|
64 |
ネーミング違反 |
ネーミングの制約に違反したDNを持つエントリの作成が、操作により試行されたことを示すために使用されます(たとえば、関連付けられた名前書式により許可されていないRDN属性の使用など)。 |
|
65 |
オブジェクト・クラス違反 |
エントリに含まれる属性のセットが関連付けられたオブジェクト・クラス定義に違反する、エントリの作成または変更が、操作により試行されたことを示すために使用されます(許可されていない属性の追加または必要な属性の欠落など)。 |
|
66 |
非リーフでは許可されない |
関連付けられた操作はリーフでないエントリに対して許可されなかったことを示すために使用されます(1つ以上の下位エントリを保有するエントリの削除の試行など)。 |
|
67 |
RDNでは許可されない |
関連付けられた操作はエントリのRDN属性に対して許可されていないことを示すために使用されます。 |
|
68 |
エントリはすでに存在します |
追加またはDN変更の操作が、サーバーにすでに存在するDNを持つエントリで実行されたことを示すために使用されます。 |
|
69 |
オブジェクト・クラスの変更は禁止されています |
リクエストされた操作により、許可されていない方法でエントリの構造オブジェクト・クラスの変更が試行されたことを示すために使用されます。 |
|
71 |
複数のDSAに影響があります |
リクエストされた操作は、複数のサーバーに影響が及んだ可能性があることを示すために使用されます(たとえば、DN変更操作はチェーン・バックエンドを介してあるサーバーから別のサーバーにエントリを移動させる場合があります)。 |
|
76 |
仮想一覧表示エラー |
仮想一覧表示リクエストの処理中に問題が発生したため、関連付けられた検索操作は正常に完了できなかったことを示すために使用されます。 |
|
80 |
その他 |
定義された結果コードでは適切に分類されないなんらかの理由により操作が失敗したことを示します。 |
|
81 |
サーバー停止 |
確立された接続が使用できないことをクライアントが検出したことを示すために使用される、クライアント側の結果コードです。 |
|
82 |
ローカル・エラー |
なんらかのクライアント側の問題が発生し、関連付けられた処理を正常に完了できないことを示すために使用される、クライアント側の結果コードです。 |
|
83 |
符号化エラー |
サーバーに送信するリクエストのエンコードを試行中に、エラーが発生したことを示すために使用される、クライアント側の結果コードです。 |
|
84 |
デコード・エラー |
サーバーから受信したレスポンスのデコードを試行中に、エラーが発生したことを示すために使用される、クライアント側の結果コードです。 |
|
85 |
タイムアウト |
許可された時間内にクライアントがレスポンスを受信しなかったことを示すために使用される、クライアント側の結果コードです。 |
|
86 |
認証タイプが不明です |
リクエストされた認証方法をクライアントがサポートしていないことを示すために使用される、クライアント側の結果コードです。 |
|
87 |
フィルタ・エラー |
指定されたフィルタ文字列を有効なフィルタとして解析できなかったことを示すために使用される、クライアント側の結果コードです。 |
|
88 |
ユーザーにより取り消されました |
クライアントによりリクエストが取り消されたことを示すために使用される、クライアント側の結果コードです。 |
|
89 |
パラメータ・エラー |
リクエスト要素として指定されたパラメータに問題があったことを示すために使用される、クライアント側の結果コードです。 |
|
90 |
メモリー不足 |
リクエストされた操作の処理を試行中(検索結果エントリのキューイング中など)に、クライアントのメモリーが不足したことを示すために使用される、クライアント側の結果コードです。 |
|
91 |
接続エラー |
クライアントがターゲット・サーバーとの接続を確立できなかったことを示すために使用される、クライアント側の結果コードです。 |
|
92 |
サポートされていません |
リクエストされた操作はクライアントにサポートされていないことを示すために使用される、クライアント側の結果コードです。 |
|
93 |
制御が見つかりません |
レスポンスに予想された制御が含まれていなかったことを示すために使用される、クライアント側の結果コードです。 |
|
94 |
結果は返されませんでした |
検索リクエストに対して少なくとも1つの結果が返されることを予想したが、サーバーから結果が返されなかったことを示すために使用される、クライアント側の結果コードです。 |
|
95 |
結果をさらに返します |
すでに取得された結果よりも、返されるべき多くの結果が存在することを示すために使用される、クライアント側の結果コードです。 |
|
96 |
クライアント・ループ |
クライアントがリフェラル・ループを検出したことを示すために使用される、クライアント側の結果コードです。 |
|
97 |
リフェラル制限を超過しました |
リクエスト処理の進行中に、クライアントが受信したリフェラルが多すぎることを示すために使用される、クライアント側の結果コードです。 |
|
100 |
無効なレスポンス |
関連付けられた操作に対して受信した結果が無効であることを示すために使用される、クライアント側の結果コードです。 |
|
101 |
あいまいなレスポンス |
サーバーから受信した結果があいまいであった(関連付けられた操作に対して受信したレスポンスが複数存在したなど)ことを示すために使用される、クライアント側の結果コードです。 |
|
112 |
TLSはサポートされていません |
サーバーはTLS起動拡張操作をサポートしていないことを示すために使用されます。 |
|
113 |
中間レスポンス |
結果コードは、リクエスト処理の進行中にサーバーにより送信された中間レスポンス・メッセージで使用されます。 |
|
114 |
不明なタイプ |
無効または不明なプロトコルopタイプのリクエストをサーバーが受信したことを示すために使用されます。 |
|
118 |
取り消されました |
クライアントのリクエストに応じてサーバーによりリクエストに対する処理が取り消されたことを示すために使用されます。 |
|
119 |
そのような操作はありません |
サーバーに対して不明なリクエスト(たとえば、すでに処理が完了しているため)の取消しをクライアントが試行したことを示すために使用されます。 |
|
120 |
遅すぎます |
以降の取消しができなくなった時点の後で、すでに処理されたリクエストの取消しをクライアントが試行したことを示すために使用されます。 |
|
121 |
取り消せません |
取消しできない操作(バインド、アンバインド、中止、取消しまたはTLS起動の各リクエストなど)の取消しをクライアントが試行したことを示すために使用されます。 |
|
122 |
アサーションに失敗しました |
ターゲット・エントリと一致しないアサーション・フィルタを持つLDAPアサーション制御をリクエストが含んでいたため、関連付けられた操作が処理されなかったことを示すために使用されます。 |
|
123 |
認可が拒否されました |
リクエストにプロキシ認可制御を含んでいたがクライアントがその制御の使用を許可されなかったため、関連付けられた操作が処理されなかったことを示すために使用されます。 |
ルートDN(すなわちルート・ユーザー)はディレクトリ・サーバーに存在するアカウントのタイプで、UNIXシステムのルート・ユーザーのように、通常、サーバー内のすべてのデータへの完全アクセス権を付与されます。ルート・ユーザーはデフォルトでアクセス制御の評価をバイパス可能で、サーバー構成への完全アクセス権を保有し、大部分のタイプの操作を実行します。
ディレクトリ・サーバーはルート・ユーザーに関して、次の2つの重要な点で他の大部分のサーバーとは異なります:
ディレクトリ・サーバーでは複数のルート・ユーザーを構成できます。すべての管理者により共有される単一のアカウントではなく、その他のアカウントから独立している個別のルート・アカウントを各管理者が保有できるように各ルート・ユーザーは異なる資格証明のセットを保有できるため、利点になります。
ルート・ユーザーに付与されるすべての権限は、特権を介して割り当てられます。特権サブシステムを使用して、通常、ルート・ユーザーのみが使用可能な一部またはすべての機能を持つroot以外のユーザーを作成できます。必要な場合はルート・ユーザーから特権を取り去ることもできます。
ルート・ユーザーおよび特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」ドキュメントを参照してください。
ルートDSEは特別なエントリで、サーバーのコンテンツおよび機能の情報を提供します。識別名は相対識別名コンポーネントを持たない長さ0の文字列で、null DNとも呼ばれます。
ルートDSEに含まれる属性には次のものがあります:
namingContextsサーバーのネーミング・コンテキストをリスト
supportedAuthPasswordSchemes認証パスワード構文を使用してサポートされるパスワード記憶スキームの オブジェクト識別子をリスト
supportedControlサーバーでサポートされている制御のOIDをリスト
supportedExtensionサーバーでサポートされている拡張のOIDをリスト
supportedFeaturesサーバーでサポートされている機能のOIDをリスト
supportedSASLMechanismsサーバーでサポートされているSimple Authentication and Security LayerメカニズムのOIDをリスト
vendorNameサーバーのベンダー名を提供
vendorVersion製品バージョンの文字列を提供
ldapsearchコマンドを使用してルートDSEを読み取る方法の例を次に示します。この例では、ファイル/tmp/pwd.txtにDirectory Managerのパスワードが含まれています。サーバーはポート1389でLDAPリクエストをリスニングします。
$ ldapsearch -D "cn=Directory Manager" -j /tmp/pwd.txt -p 1389 -b "" \ -s base "(objectclass=*)" + dn: supportedLDAPVersion: 2 supportedLDAPVersion: 3 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.26027.1.6.1 supportedExtension: 1.3.6.1.4.1.26027.1.6.3 supportedExtension: 1.3.6.1.4.1.26027.1.6.2 supportedExtension: 1.3.6.1.1.8 supportedExtension: 1.3.6.1.4.1.1466.20037 vendorName: Oracle Corporation entryDN: ds-private-naming-contexts: cn=admin data ds-private-naming-contexts: cn=ads-truststore ds-private-naming-contexts: cn=backups ds-private-naming-contexts: cn=config ds-private-naming-contexts: cn=monitor ds-private-naming-contexts: cn=schema ds-private-naming-contexts: cn=tasks supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.3.6.1.1.12 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.4.1.26027.1.5.2 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.1.10.2 supportedControl: 1.3.6.1.4.1.7628.5.101.1 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.9 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 subschemaSubentry: cn=schema hasSubordinates: true entryUUID: d41d8cd9-8f00-3204-a980-0998ecf8427e numSubordinates: 1 namingContexts: dc=example,dc=com vendorVersion: Oracle Unified Directory 11.1.1.5.0 supportedAuthPasswordSchemes: MD5 supportedAuthPasswordSchemes: SHA1 supportedAuthPasswordSchemes: SHA256 supportedAuthPasswordSchemes: SHA384 supportedAuthPasswordSchemes: SHA512
ルートDSEエントリの検索方法の詳細は、「拡張検索機能の使用方法」を参照してください。
プロキシ・モードで、ロード・バランシング・アルゴリズムを使用する際に、リクエストが送信されるリモートLDAPサーバーへのパス。
saltはランダム・データの集合で、クリアテキスト・データ(パスワードであることが多い)と組み合せて、クリアテキストをエンコードする方法を変更するために使用できます。特に、saltはエンコード処理に不規則性を導入して、辞書攻撃を防ぐために使用されます。通常、saltはクリアテキスト・パスワードに追加され、そのパスワードは必要とするメッセージ・ダイジェスト・アルゴリズムを使用してエンコードされます。クリアテキストsaltはメッセージ・ダイジェストに追加され、最終的な値はbase64エンコーディングでエンコードされます。このようにしてsaltの内容の判断が可能になり、ユーザーの指定したパスワードが正しいかどうかの判断に使用できます。
UNIX暗号化アルゴリズムは比較的弱い12ビットのsaltを使用しており、それは、値をエンコードする方法が4096通りのみであることを意味します。これは比較的低い数字で、このためユーザー・パスワードの解読に使用する広い範囲の値をすべてエンコードした辞書を構築できます。その他のディレクトリ・サーバーのパスワード記憶スキームでは64ビットのsaltを使用しており、1つの値を18446744073709551616通りにエンコードできます。
クライアントのリクエストを優先リモートLDAPサーバーにルーティングするプロキシ・ロード・バランシング・アルゴリズム。メイン・リモートLDAPサーバーが飽和しきい値に達した場合は、リクエストはセカンダリ・リモートLDAPサーバーにルーティングされます。
リモートLDAPサーバーがオーバーロードであることを示すために、管理者に通知を送信する際の制限値。通常、飽和アラートは飽和しきい値よりも高く設定されています。
飽和しきい値は、データ・ソースがオーバーロードとみなされ、これ以上の着信リクエストを適切な方法で処理できないという制限値です。飽和しきい値は、プロキシ飽和アルゴリズムの一部として使用されます。
ディレクトリ・サーバーのスキーマは、サーバーが保持できる情報の種類を制御するルールのセットを定義します。ディレクトリ・スキーマには、次のように様々な要素が多数あります:
属性で保管できる情報の種類についての情報を提供します。
属性値との比較方法の情報を提供します。
特定の一致ルールとともに使用できる属性タイプを示します。
指定された属性の参照に使用できるオブジェクト識別子および名前のセットを定義し、その属性を構文および一致ルールのセットと関連付けます。
名前付きの属性の集合を定義し、必須およびオプションの属性のセットに分類します。
エントリの相対識別名に含まれる属性のセットに対するルールを定義します。
エントリとともに使用できるオブジェクト・クラスおよび属性についての追加の制約を定義します。
指定されたエントリが保有できる下位エントリの種類を制御するルールを定義します。
属性はディレクトリに情報を保管するための要素で、スキーマは、エントリ内で使用できる属性のルール、これらの属性が保有できる値の種類、クライアントがこれらの値と相互に作用する方法を定義します。
クライアントは、適切なサブスキーマ・サブエントリを取得して、サーバーがサポートするスキーマ要素を確認できます。
スキーマ検査は、エントリがサーバー・スキーマで定義された制約に準拠していることを確認する処理です。内容は次のとおりです:
エントリに1つの構造オブジェクト・クラスが含まれることを確認します。
エントリの構造クラスのDITコンテンツ・ルールが存在する場合は、すべての補助オブジェクト・クラスが定義されていることを確認します。
エントリに含まれるすべてのオブジェクト・クラスがスキーマで定義されていることを確認します。
エントリに含まれるすべての属性がスキーマで定義されており、オブジェクト・クラスまたはDITコンテンツ・ルール、あるいはその両方により許可されていることを確認します。
エントリのオブジェクト・クラスまたはDITコンテンツ・ルール、あるいはその両方により要求されたすべての属性が存在することを確認します。
エントリに含まれるすべての単一値属性が値を1つのみ保有していることを確認します。
ディレクトリ情報ツリー内のエントリの位置が、DIT構造ルールの定義に準拠していることを確認します。
検索操作の検索属性要素は、検索結果エントリに含まれる属性を表す方法を指定します。通常、検索属性のセットは、返す属性の0個以上の属性説明のリストです。値が指定されている場合は、すべてのユーザー属性が返され、操作属性は返されません。
特定の属性説明に加えて、多くの特別な値に次のように様々な意味を持たせることができます:
文字列1.1は一致するエントリに含まれる属性が存在しないことを示します。
文字列*(アスタリスク)は、一致するエントリにすべてのユーザー属性が含まれることを示します。1つ以上の操作属性に加えて、すべてのユーザー属性をサーバーが返す場合に必要です。
文字列+(プラス記号)は、一致するエントリに操作属性が含まれることを示します。
オブジェクト・クラス名は、接頭辞として文字@を付けた形式で指定できます。オブジェクト・クラスにより参照されるすべての属性は一致するエントリに含まれることを示します。
検索ベースDNは検索操作の要素で、検索範囲とともに動作し、検索操作の処理対象として考慮するエントリのサブツリーを定義します。検索ベースDNのエントリまたはその下のエントリ、およびその範囲内のエントリのみが、LDAP検索フィルタと一致する候補とみなされます。
「LDAP検索フィルタ」を参照してください。
LDAP検索操作は、指定された基準のセットに一致するディレクトリ・サーバーのエントリの識別に使用できます。0個以上のエントリ、また0個以上のリフェラルを返す場合があります。
検索リクエスト・プロトコルopは次のように定義されます:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
次のような検索リクエストの要素があります:
検索ベースDN。検索を実行するディレクトリ情報ツリー内の場所を指定します。
検索範囲。検索処理の対象として考慮する、ベースDNのエントリまたはその下のエントリの範囲を指定します。
処理中に別名を検出した場合に使用する間接参照ポリシー。
サイズ制限。検索から返されるエントリの最大数を指定します(または、エントリの最大数を指定しない場合は0)。
時間制限。サーバーが検索処理に費やす時間の最大の長さを秒単位で指定します(または、エントリの最大数を指定しない場合はゼロ)。
typesOnlyフラグ。返されたエントリが属性タイプのみまたは属性タイプと属性値の両方を含むかどうかを示します。
LDAP検索フィルタ。一致するエントリの識別に使用する基準を指定します。
検索リクエストに対するレスポンスで返すことのできる次の3つの結果要素のタイプがあります。0個以上の検索結果エントリ、0個以上の検索結果参照および1つの検索結果終了メッセージです。エントリおよび参照は任意の順序で返され(検索エントリと参照がばらばらに挿入された状態で)、検索結果終了メッセージは最後に発生してこれ以上の結果は存在しないことを示します。
検索結果エントリ・プロトコルopは次のように定義されます:
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
各検索結果エントリには、検索属性リストで定義されたように、エントリのDNおよび0個以上の属性が含まれます(リクエストのtypesOnly要素がtrueの場合は、値なしで属性タイプ名のみが含まれる場合があります)。
検索結果参照プロトコルopは次のように定義されます:
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
各検索結果参照には、クライアントが別の一致するエントリを検索する別の場所を指定する1つ以上のLDAP URLが含まれます。
検索結果終了メッセージは、次のように定義されるLDAP結果です:
SearchResultDone ::= [APPLICATION 5] LDAPResult
検索結果エントリは、検索操作の一部として返されるエントリです。少なくともエントリの識別名を含み、0個以上の属性を含めることができます。属性には、(検索リクエストのtypesOnlyフラグの値に基づいて)属性タイプ名のみ、または属性のタイプおよび値の両方を含めることができます。返された属性は、クライアント・リクエストの検索属性に基づいていますが、サーバーのアクセス制御構成に基づいて削減できます。
検索結果参照は、検索操作の一部としてクライアントに情報を返すメカニズムを提供し、その情報は、クライアントが別の一致するエントリを見つけるための検索を実行する、別の場所を示します。別の場所は、LDAP URLの形式で指定されます。
LDAP検索範囲は、検索操作で一致する可能性を検討する検索ベースDNのエントリまたはその下のエントリのセットを示します。
検索範囲の値には次の4つの定義があります:
検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。
DITのシナリオを考えます。このDITは、検索ベースDNにdc=example,dc=comを持つbaseObject範囲を保有しています。
検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。
検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。
検索操作は、深さにかかわらず検索ベースのすべての下位エントリに対して実行されますが、検索ベース・エントリ自体は含まれません。
セキュア・ハッシュ・アルゴリズム(SHA)は、一方向のメッセージ・ダイジェスト・アルゴリズムです。セキュア・ハッシュ・アルゴリズムには、実際には次の2つの異なる形式があります:
SHA-1はRFC 3174 (http://www.ietf.org/rfc/rfc3174.txt)で定義されており、160ビットのダイジェストを生成します。
SHA-2はRFC 4634 (http://www.ietf.org/rfc/rfc4634.txt)で定義されており、256ビット、384ビットまたは512ビットのダイジェストの生成に使用できます。
セキュア・ハッシュ・アルゴリズムのすべての形式はMD5アルゴリズムよりも厳格であるとみなされます。最近の進歩により、SHA-1バリアントの脆弱性が示される場合がありますが、ディレクトリ・サーバーでの使用方法が危険であることを示す証拠はなく、SHA-2エンコーディングの問題もありません。
Secure Sockets Layer (SSL)はセキュリティ層でネットワーク通信をラップするメカニズムで、クライアントとサーバーの間の通信を暗号化するために使用できます。クライアントとサーバーとの間で通信が変更されないことを保証する、整合性メカニズムも提供します。暗号化は、証明書を使用した暗号化に基づいています。
SSLは元々、Netscape Communications社が開発したプロプライエタリ・プロトコルです。その後標準化されましたが、名前はTransport Security Layerに変更されました。しかし、SSLはこの機能を指すために現在でも一般的に使用される用語で、StartTLS拡張操作との混同を避けるためにディレクトリ・サーバーで使用される用語です。
サーバー側ソート制御は、検索操作に追加して、結果がクライアントに返される前に結果がソートされるようにリクエストする制御のタイプです。RFC 2891 (http://www.ietf.org/rfc/rfc2891.txt)で定義されています。
リクエスト制御のオブジェクト識別子は1.2.840.113556.1.4.473で、値は次のようにエンコードされます:
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
検索リクエストでこの制御を使用する例は、「サーバー側ソート制御を使用した検索」を参照してください。
レスポンス制御のOIDは1.2.840.113556.1.4.474で、値は次のようにエンコードされます:
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- results are sorted
operationsError (1), -- server internal failure
timeLimitExceeded (3), -- timelimit reached before
-- sorting was completed
strongAuthRequired (8), -- refused to return sorted
-- results via insecure
-- protocol
adminLimitExceeded (11), -- too many matching entries
-- for the server to sort
noSuchAttribute (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refused to return sorted
-- results to this client
busy (51), -- too busy to process
unwillingToPerform (53), -- unable to sort
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }
簡易認証は、識別名およびパスワードを使用するディレクトリ・サーバーに対する認証の処理です。バインド操作を使用して実行されます(簡易認証を使用してバインドが実行された場合は、多くの場合、簡易バインドと呼ばれます)。クライアントは指定されたDNを使用してクライアント自体をサーバーに認証要求し、クライアントが誰だと主張しているのかを検証するためにパスワードが使用されます。
簡易認証ではパスワードを保護する方法がないことに注意してください。そのため、通常、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルで使用される場合のみ簡易認証をお薦めします。
Simple Authentication and Security Layer (SASL)は、主にユーザー認証のために使用される拡張フレームワークですが、基礎となる通信チャネルの保護に使用される場合もあります。SASLの中核機能はRFC 4422 (http://www.ietf.org/rfc/rfc4422.txt)で説明されていますが、多くのSASLメカニズムが別の仕様で説明されています。
ディレクトリ・サーバーでサポートされているSASLメカニズムには、次のものがあります:
このメカニズムは実際にはサーバーに対してユーザーを認証しませんが、以前の認証セッションの破棄に使用できます。
このメカニズムは、パスワード自体を公開しない方法でパスワードを使用して、ユーザーがサーバーへの認証を行う方法を提供します。DIGEST-MD5 SASLメカニズムに似ていますが、より脆弱で、接続の完全性または機密性を保証する方法がありません。
このメカニズムは、パスワード自体を公開しない方法でパスワードを使用して、ユーザーがサーバーへの認証を行う方法を提供します。CRAM-MD5 SASLメカニズムに似ていますが、より厳格で、接続の完全性または機密性、あるいはその両方を保証する方法も提供します。
このメカニズムは、実行されるLDAP通信の外で入手できる情報(Secure Sockets LayerまたはTLS起動拡張操作のネゴシエーションを実行する際にクライアントが提示した証明書など)を使用して、ユーザーがサーバーへの認証を行う方法を提供します。
このメカニズムは、Kerberos V5セッションを使用してユーザーがサーバーへの認証を行う方法を提供します。接続の完全性または機密性、あるいはその両方を保証するために使用できるメカニズムも提供します。
このメカニズムは、ユーザー名およびパスワードを使用し、ユーザーがサーバーへの認証を行う方法を提供します。簡易認証で提供される保護とよく似ていますが、識別名ではなくユーザー名でユーザーが自分自身を認証要求できるという点でより便利です。
単純なページングの結果制御は、検索操作に追加して、結果のサブセットのみを返すことを示す制御のタイプです。検索結果を一度に1ページずつ繰り返し取り出すために使用できます。結果がソートされている必要はなく、検索結果を順に取り出すためにのみ使用できることを除けば、仮想一覧表示制御に似ています。
単純なページングの結果制御はRFC 2696 (http://www.ietf.org/rfc/rfc2696.txt)で定義されています。同じ制御が検索リクエストおよび検索結果終了メッセージの両方で使用されます。オブジェクト識別子は1.2.840.113556.1.4.319で、値は次のようにエンコードされます:
realSearchControlValue ::= SEQUENCE {
size INTEGER (0..maxInt),
-- requested page size from client
-- result set size estimate from server
cookie OCTET STRING
}
検索リクエストでこの制御を使用する例は、「単純なページングの結果制御を使用した検索」を参照してください。
サーバーのサイズ制限は構成オプションで、単一の検索操作から返すことのできるエントリの最大数を制御します。サーバー全体に関わる設定で、ユーザーのエントリのds-rlim-size-limit操作属性でユーザーごとの構成によりオーバーライドできます。
サーバーのサイズ制限(またはユーザーごとの値)は、検索リクエスト・メッセージのサイズ制限要素により制限される場合もあります。
スマート・リフェラルは特別なタイプのエントリで、別のサーバーまたは別のDITの場所、あるいはその両方のコンテンツを参照するディレクトリ情報ツリーに配置できます。スマート・リフェラル・エントリには、リフェラルで使用されるLDAP URLを含むref属性の1つ以上のインスタンスを持つreferralオブジェクト・クラスが含まれます。
TLS起動拡張操作は、クリアテキスト接続上で、Transport Security Layerで保護された通信チャネルの開始に使用できる拡張操作のタイプです。クライアントは、保護された通信と保護されない通信の両方で同じネットワーク・ポートを使用できます。
TLS起動拡張操作は、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)で定義されており、RFC 4513 (http://www.ietf.org/rfc/rfc4513.txt)で詳細が説明されています。OIDは1.3.6.1.4.1.1466.20037で、値はありません。レスポンスのOIDは1.3.6.1.4.1.1466.20037(リクエストOIDと同じ)で、値はありません。
静的グループはディレクトリ・サーバーのグループのタイプで、グループのメンバーであるエントリの識別名の明示的なセットを提供することにより、メンバーシップを定義します。
静的グループは外部のクライアントにより十分サポートされますが、大量のメンバーを処理する際は、動的グループほどスケーラブルではありません。
構造オブジェクト・クラスは、主要なオブジェクト・クラス・タイプの1つです。構造オブジェクト・クラスは、このオブジェクト・クラスを含むのエントリのコア・タイプを定義するという点で特別です。エントリは1つの構造クラスを保有する必要があります(その構造クラスは他の構造クラスまたは抽象オブジェクト・クラスから継承する場合もあります)。
エントリの構造オブジェクト・クラスは、ディレクトリ・データの制限を定義するための他のスキーマ要素により使用される場合もあります。エントリの相対識別名で使用される属性を制御する名前書式の定義により使用される場合があります。また、親エントリを保有する場合、そのタイプを制御するDIT構造ルールにより使用される場合があります。構造オブジェクト・クラスは、DITコンテンツ・ルールによっても使用され、補助オブジェクト・クラスのセット、および必須の、使用可能な、禁止されたエントリの属性タイプを制御します。
「LDAPサブエントリ」を参照してください。
サブスキーマ・サブエントリはディレクトリ・サーバー内の特別なエントリで、サーバーで定義されるスキーマ要素の情報を提供します。このエントリの属性には次のものがあります:
ldapSyntaxesサーバー・スキーマで定義された属性構文のセット。
matchingRulesサーバー・スキーマで定義された一致ルールのセット。
matchingRuleUseサーバー・スキーマで定義された一致ルールの使用のセット。
attributeTypesサーバー・スキーマで定義された属性タイプのセット。
objectClassesサーバー・スキーマで定義されたオブジェクト・クラスのセット。
nameFormsサーバー・スキーマで定義された名前書式のセット。
dITContentRulesサーバー・スキーマで定義されたDITコンテンツ・ルールのセット。
dITStructureRulesサーバー・スキーマで定義されたDIT構造ルールのセット。
これらはすべて操作属性であるため、明示的にリクエストされない場合は返されないことに注意してください。
また、ディレクトリ・サーバーでは、ディレクトリ情報ツリーの異なる部分を制御するスキーマ定義の異なるセットを持つ、複数のサブスキーマ・サブエントリを、技術的には保有できることに注意してください。指定されたエントリに適用するスキーマは、エントリからsubschemaSubentry仮想属性を取得して確認できます。現在ディレクトリ・サーバーは単一のスキーマのみをサポートしますが、デフォルトでcn=schemaでそのスキーマを公開します。
部分文字列アサーションは、属性が指定された部分文字列と一致する属性値を保有するかどうかを判断する処理で、部分文字列一致ルールに指定される引数です。
部分文字列アサーションには、次のセットのうち少なくとも1つのコンポーネントが含まれます:
0または1つのsubInitial要素。ターゲット値の先頭に指定する必要があります。
0または1つのsubAny要素。値の先頭および最後以外の場所に指定できます。複数のsubAny要素が存在する場合は、一致する属性値には、重複なく部分文字列アサーションに設定された順序ですべてのsubAny要素が含まれる必要があります(つまり、属性値に文字を含まない場合は、2つの異なる部分文字列アサーションのコンポーネントの部分である可能性があります)。subInitialコンポーネントまたはsubFinalコンポーネント、あるいはその両方が存在する場合は、subAny要素がそのいずれかと重複することはできません。
0または1つのsubFinal要素。ターゲット値の最後に指定する必要があります。
部分文字列アサーションは、部分文字列検索フィルタを処理する際に使用されます。
部分文字列索引は、特定の部分文字列を含むエントリを追跡するために使用される索引のタイプです。部分文字列索引の索引キーは、属性値から取得された6文字の部分文字列で構成され、対応する値はこれらの部分文字列を含むエントリのエントリIDを含むIDリストです。属性の部分文字列一致ルールは、索引キーの正規化された値に使用され、部分文字列索引は部分文字列一致ルールを含まない属性には定義できません。
部分文字列検索フィルタはLDAP検索フィルタのタイプで、指定された部分文字列と一致する、指定された属性の値を含むエントリを識別するために使用できます。サーバーは、部分文字列一致ルールを使用して判断します。
部分文字列検索フィルタは部分文字列アサーションを含む必要があり、次のタイプのうち少なくとも1つのコンポーネントを保有します:
subInitialコンポーネント。このコンポーネントの値は一致する値の先頭に含まれます。部分文字列フィルタには、0または1つのsubInitialコンポーネントが存在する可能性があります。
subAnyコンポーネントのセット。このセットの値は一致する値の任意の場所に含まれます。部分文字列フィルタには0個以上のsubAnyコンポーネントが存在する可能性があり、これらのコンポーネントは、subInitialコンポーネントの後およびsubFinalコンポーネントの前で部分文字列フィルタに指定される順に値を含む必要があります。
subFinalコンポーネント。このコンポーネントの値は一致する値の最後に含まれます。部分文字列フィルタには、0または1つのsubFinalコンポーネントが存在する可能性があります。
LDAP部分文字列フィルタの文字列表現は、左カッコに続く属性名、等号、アスタリスクで個別のコンポーネントを区切った部分文字列アサーションおよび右カッコで構成されます。たとえば、部分文字列フィルタの(cn=ab*def*mno*stu*yz)には、subInitialコンポーネントのab、subAnyコンポーネントのdef、mnoおよびstu、およびsubFinalコンポーネントのyzが含まれます。
サブツリーという用語には2つの定義があります。
この用語の一般的な定義は、エントリおよびすべての下位エントリを含むディレクトリ情報ツリーの部分です。
サブツリーという用語は、RFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)でも、サブツリーの形式の仕様の中で説明されています。サブツリーの仕様は、指定された基準のセットに基づき、エントリをグループ化するメカニズムを提供します。
サブツリー削除制御は、削除操作に追加して、エントリおよびその下位エントリすべての削除を許可する制御のタイプです。通常の削除操作は、リーフ・エントリのみをターゲット設定できますが、サブツリー削除制御はリーフ以外のエントリをターゲット設定するために使用できます。
サブツリー削除リクエスト制御のOIDは1.2.840.113556.1.4.805で、値はありません。対応するレスポンス制御はありません。
この制御を使用して、ou=People,dc=example,dc=comサブツリーを削除する例を次に示します。
$ ldapdelete -p 1389 -h localhost -D cn=directory manager -j pwd-file \ -J 1.2.840.113556.1.4.805 ou=People,dc=example,dc=com Processing DELETE request for ou=People,dc=example,dc=com
サポートされている制御は、ディレクトリ・サーバーによりサポートされているリクエスト制御を識別するメカニズムです。これらの制御のオブジェクト識別子は、サーバーのルートDSEのsupportedControl属性にリストされています。
Oracle Unified Directoryで現在サポートされているすべての制御のリストは、「サポートされているLDAP制御」を参照してください。
サポートされている拡張は、ディレクトリ・サーバーによりサポートされている拡張操作を識別するメカニズムです。これらの拡張操作のオブジェクト識別子は、サーバーのルートDSEのsupportedExtension属性にリストされています。
ディレクトリ・サーバーでサポートされているすべての拡張のリストは、「サポートされている拡張操作」を参照してください。
サポートされている機能は、ディレクトリ・サーバーによりサポートされているオプション機能を識別するメカニズムです。サーバーでサポートされている多くの機能は、サーバーのルートDSEのsupportedFeatures属性でリストされており、そこではサポートされている機能のオブジェクト識別子がリストされています。
ディレクトリ・サーバーでサポートされている機能には次のものがあります:
RFC 3673 (http://www.ietf.org/rfc/rfc3673.txt)で説明されているように、すべての操作属性をリクエストする際に、+インジケータの使用をサーバーがサポートすることを示します。
RFC 4529 (http://www.ietf.org/rfc/rfc4529.txt)で説明されているように、検索属性のセットに1つ以上のオブジェクト・クラス名を含める機能をサーバーがサポートすることを示します。
RFC 4525 (http://www.ietf.org/rfc/rfc4525.txt)で説明されているように、増分変更拡張の一部である増分変更タイプをサーバーがサポートすることを示します。
RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt)で説明されているように、LDAP trueフィルタおよびLDAP falseフィルタをサーバーがサポートすることを示します。
データ同期は、ディレクトリ環境内の変更を追跡し、他の場所に反映できるようにするメカニズムです。
ディレクトリ・サーバーで提供されるデータ同期の主要なタイプはレプリケーションです。
タスクは、サーバーでいくつかのタイプの処理を実行するためのロジックのセットを提供します。通常、タスクはサーバー内の管理機能の実行に使用されます。使用可能なタスクの例を次に示します:
サーバー・スキーマへの新しいファイルの追加
以前のバックアップを復元
LDIFインポート操作の実行
LDIFエクスポート操作の実行
インコア再起動の実行
サーバー停止の実行
タスクは繰り返し実行可能で、特定のスケジュールに従って定期的に実行するようにスケジュールされます。たとえば、バックアップ・タスクは、サーバー・データを定期的にバックアップするために繰り返し実行できます。タスクのスケジューリングの詳細は、「タスクのスケジュールと構成」を参照してください。
サーバーの時間制限は構成オプションで、サーバーが検索操作の処理に費やすことができる時間の最大の長さを秒単位で制御します。サーバー全体に関わる設定で、ユーザーのエントリのds-rlim-time-limit操作属性でユーザーごとの構成によりオーバーライドできます。
サーバーの時間制限(またはユーザーごとの値)は、検索リクエスト・メッセージの時間制限要素により制限される場合もあります。
トランザクションは、データベース内で発生する読取りまたは書込みの操作、あるいはその両方の1つ以上の集合です。トランザクションはACIDという頭字語で説明される場合があり、それは、原子性、一貫性、独立性および永続性の略です。ディレクトリ・サーバーはBerkeley DB Java Editionでトランザクションを使用し、単一のLDAP操作の一部として実行される複数の変更を保証します(id2entryデータベースおよび索引の両方に対する更新など)。
ディレクトリ・サーバーがデータベースの操作のために内部でトランザクションを使用しても、クライアントが単一の原子ユニットとして複数の操作を実行できるトランザクション・メカニズムは現在は公開されていません。トランザクションを公開する可能性のあるメカニズムを説明するInternet Draftもありますが(draft-zeilenga-ldap-txn)、現在、ディレクトリ・サーバーではこの機能をサポートしていません。
Transport Security Layer (TLS)は、クライアントとサーバーの間のネットワーク通信を保護するメカニズムです。Secure Sockets Layerの標準化された形式に対して付与された名前です。
通常、TLSよりSSLという用語をお薦めするのは、SSLの方がより一般的な用語であり、また、TLS起動拡張操作との混同を避けるためでもあります。
「LDAP trueフィルタ」を参照してください。
信頼マネージャ・プロバイダはサーバーのコンポーネントで、サーバーに提示される証明書を信頼するかどうかの判断に使用可能な情報を提供できます。
ディレクトリ・サーバーで使用できる信頼マネージャ・プロバイダの詳細は、Trust Manager Provider Configuration (http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/trust-manager-provider.html)を参照してください。
LDAPアンバインド操作は、クライアントがサーバーからの切断を実行しようとしていることを示すために使用されます。
アンバインド操作は、基礎となる接続が確立されたままになっている場合に、認証セッションの破棄には使用できないことに注意してください。クライアントがアンバインド・リクエストを送信した後で接続を終了しない場合は、サーバーが実行します。接続を認証されていない状態に戻す必要がある場合は、匿名バインド操作が実行されます。
LDAPアンバインド・リクエスト・プロトコルopは次のように定義されます:
UnbindRequest ::= [APPLICATION 2] NULL
アンバインド・リクエストはいずれの要素も持たず、サーバーはアンバインド・リクエストに対してレスポンスを送信しません。
索引なし検索は、サーバーで定義された索引のセットを使用する処理ができない検索です。データベースのほとんどまたはすべてのエントリを繰り返し処理する必要があります。
索引なし検索はサーバーにとって高い処理コストがかかる可能性があり、ユーザーは、unindexed-search特権を保有する場合にのみ、索引なし検索の実行を許可されます。
詳細は、「ディレクトリ・データへの索引付け」を参照してください。
UNIX暗号化アルゴリズムは、最終的に一方向メッセージ・ダイジェストを作成するDESベースの暗号化スキームを使用し、ユーザー・パスワードをエンコードする標準メカニズムです。UNIXベースのシステムでパスワードをエンコードするデフォルトのメカニズムとして従来から使用されているため、UNIX暗号化アルゴリズムと呼ばれます。
UNIX暗号化アルゴリズムは、56ビットの暗号化アルゴリズムに基づき、12ビットのみのsaltを使用するため、脆弱であるとみなされていることに注意してください。このため、バインド操作を使用して値の検証を試行するかわりに、サーバーからパスワードを取得してユーザーが入力した値と比較することをクライアントが必要とする場合にのみ使用されます。
未承諾通知は、拡張操作メッセージのタイプで、対応するクライアントからのリクエストのない種類のメッセージをサーバーが生成するという点で特殊です。重要な情報をクライアントに通知するために使用される場合もあります。
現在、ディレクトリ・サーバーでは、次の未承諾通知1つをサポートしています。それは切断の通知未承諾通知で、サーバーが接続を閉じようとしていることをクライアントに通知するために使用できます。
「URL」を参照してください。
仮想属性は、その属性値は実際にはバックエンドに保管されませんが、そのかわりになんらかの方法で動的に生成される属性のタイプです。仮想属性のタイプにより、値は様々な方法で取得できます。属性の値はある種のロジックに基づいて実行時に計算されますが、仮想属性にはハードコードされた値を使用するものもあります。
ディレクトリ・サーバーで使用できる仮想属性のタイプの詳細は、Virtual Attribute Configuration (http://www.opends.org/promoted-builds/latest/OpenDS/build/docgen/configuration_guide/virtual-attribute.html)を参照してください。
仮想属性専用制御は、サーバーが仮想属性のみを一致するエントリに含めるように要求します。つまり、実在属性は検索結果エントリから除外されます。
仮想属性専用制御のリクエスト・オブジェクト識別子は2.16.840.1.113730.3.4.19で、値はありません。
仮想属性専用制御を使用しないベースDN上の検索の例を次に示します:
$ ldapsearch -p 1389 -D "cn=directory manager" -j pwd-file -b "dc=example,dc=com" \ -s base "objectclass=*" version: 1 dn: dc=example,dc=com objectClass: domain objectClass: top dc: example
仮想属性専用制御を使用する同じ検索の例を次に示します:
$ ldapsearch -p 1389 -D "cn=directory manager" -j pwd-file \ -J "2.16.840.1.113730.3.4.19" -b "dc=example,dc=com" -s base "objectclass=*" version: 1 dn: dc=example,dc=com
仮想ディレクトリはネットワーク・デーモンのタイプで、Lightweight Directory Access Protocolを使用してクライアントと通信しますが、異なるソースの組合せから基礎となるデータを取得します。仮想ディレクトリには、次のように様々な機能が数多くあります:
リレーショナル・データベースまたはフラット・ファイルのように、異なるリポジトリに対してLDAPフロントエンドを提供します。
複数のリポジトリのデータをマージするメカニズムを提供します。
仮想一覧表示(VLV)は、検索操作に追加して、結果のサブセットのみを返す予定であることを示す制御です。検索結果全体を一度に1ページずつ取り出すために使用できます。サーバーから任意の結果のサブセットを取得するために使用できることを除けば、単純なページングの結果制御に似ており、リクエスト全体にわたり結果が正しくソートされていることを保証するために、検索リクエストにサーバー側ソート制御を含める必要があります。
VLV制御はdraft-ietf-ldapext-ldapv3-vlv-09 (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09)で定義されます。リクエスト制御のオブジェクト識別子は2.16.840.1.113730.3.4.9で、値は次のようにエンコードされます:
VirtualListViewRequest ::= SEQUENCE {
beforeCount INTEGER (0..maxInt),
afterCount INTEGER (0..maxInt),
target CHOICE {
byOffset [0] SEQUENCE {
offset INTEGER (1 .. maxInt),
contentCount INTEGER (0 .. maxInt) },
greaterThanOrEqual [1] AssertionValue },
contextID OCTET STRING OPTIONAL }
レスポンス制御のOIDは2.16.840.1.113730.3.4.10で、値は次のようにエンコードされます:
VirtualListViewResponse ::= SEQUENCE {
targetPosition INTEGER (0 .. maxInt),
contentCount INTEGER (0 .. maxInt),
virtualListViewResult ENUMERATED {
success (0),
operationsError (1),
protocolError (3),
unwillingToPerform (53),
insufficientAccessRights (50),
timeLimitExceeded (3),
adminLimitExceeded (11),
innapropriateMatching (18),
sortControlMissing (60),
offsetRangeError (61),
other(80),
... },
contextID OCTET STRING OPTIONAL }
検索リクエストでこの制御を使用する例は、「仮想リスト表示制御を使用した検索」を参照してください。
仮想静的グループは特別なタイプのグループで、外部のクライアントには静的グループのように見えますが、メンバーシップ情報をサーバーの別のグループ(動的グループなど)から取得します。
仮想静的グループはクライアント・アプリケーションが静的グループのみをサポートする場合に主に使用されますが、動的グループでの維持により適している大量のメンバーを保有します。
Who Am I拡張操作は、クライアント接続の認可アイデンティティを判断するための拡張操作を提供します。RFC 4532 (http://www.ietf.org/rfc/rfc4532.txt)で定義されています。
Who Am I拡張操作のリクエスト・オブジェクト識別子は1.3.6.1.4.1.4203.1.11.3で、リクエスト値はありません。レスポンスにはレスポンスOIDはなく、その値は、クライアントの認可アイデンティティを含む文字列(または匿名ユーザーの認可アイデンティティの場合は空の文字列)です。
認可アイデンティティ制御はバインド・リクエストにのみ含まれますが、Who Am I拡張操作により提供される情報はクライアントが認証された後ならいつでも使用できることを除けば、認可アイデンティティ制御により提供される情報と似ています。
ディレクトリ・サーバー・ワーク・キューは、未処理リクエストを追跡し、適切な方法で処理されていることを確認するために使用するメカニズムです。ワーク・キューの機能は拡張可能なAPIにより提供されますが、デフォルトの実装は比較的単純で、キューは多くのワーカー・スレッドのサービスを受けます。空きワーカー・スレッドが存在する場合は、通常、キューは空のままです。すべてのワーカー・スレッドがビジーの場合は、後続のリクエストがワーク・キューに配置され、FIFO方式で処理されます。
ワーカー・スレッドは、ディレクトリ・サーバーでのリクエスト処理に使用されるスレッドです。ワーカー・スレッドはワーク・キューと関連付けられ、(必要に応じてリクエストの到着を待っている)キューからリクエストを取得し、適切にリクエストを処理し、次のリクエストのためにキューへ返すというループで動作します。
ワークフローは、指定されたネーミング・コンテキストの処理を定義します。全体的な処理はタスクの順序付けと同期化に分けられ、ワークフロー要素により定義されます。
ワークフロー要素は、ワークフロー処理の重要な構築ブロックです。サーバーへ送信されたクライアント・リクエストの取扱方法を定義します。ロード・バランシングや分散など、ワークフロー要素のメイン・タスクはプロキシ・サーバーに実装されます。
ディレクトリ・サーバーの書込み可能モードは、書込み操作が許可されるかどうかを制御するために使用されます。書込み可能モードの構成は、単一のバックエンドに制限するか、またはサーバー全体に適用できます。
使用可能な書込み可能モードは次のとおりです:
サーバーはすべての書込み操作の処理を試行します。
サーバーはすべての書込み操作を却下します。
サーバーは、内部操作として、または同期によって開始される書込み操作の処理を試行しますが、外部クライアントからのリクエストは却下します。
エントリDNは、エントリの現在のDNのコピーを提供する操作属性です。DNはエントリの属性ではないため、属性値アサーションの実行には使用できません。RFC 5020 (http://www.ietf.org/rfc/rfc5020.txt)で説明されるように、エントリDNはエントリのDNにアクセスするメカニズムを提供します。
