A.4 Oracle Unified Directory用語集
A.4.1 A
A.4.1.1 中止操作
LDAP中止操作は、未処理リクエストの処理をサーバーが停止するようにリクエストするために使用できます。中止リクエストのプロトコルopは次のとおりです:
AbandonRequest ::= [APPLICATION 16] MessageID
リクエストで指定されたメッセージIDは、中止する操作のメッセージIDです。
中止操作にはレスポンスがないため、中止操作が正しく実行されたかどうかをクライアントが確認する方法はありません。同様に、操作が中止された場合は、それに対するレスポンスはありません。そのため、クライアントは送信されないレスポンスを長い間待っている可能性があります。どちらの問題も取消し拡張操作で説明されています。
バインド、アンバインド、中止およびTLS起動拡張操作は中止できません。
A.4.1.2 抽象オブジェクト・クラス
抽象オブジェクト・クラスは、エントリで直接は使用できませんが、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。そのサブクラスは、抽象クラスで定義される必須またはオプション、あるいはその両方の属性タイプを継承します。
LDAPで定義される最も重要な抽象オブジェクト・クラスのうちの1つがtop
オブジェクト・クラスで、サーバー・スキーマで仮想的に定義されるその他すべてのオブジェクト・クラスのルート・クラスです。
A.4.1.3 抽象構文表記法1
抽象構文表記法1 (ASN.1)は、バイナリ形式でデータをエンコーディングするメカニズムです。各要素がタイプ、長さおよび値を保有するTLV構造を使用します。タイプ・コンポーネントは、要素内に保存される情報の種類を示し、値をエンコードする方法を示すデータ・タイプです。長さコンポーネントは値のバイト数を指定し、値コンポーネントは要素で保持される実データです。
ASN.1要素の例を次に示します:
-
Null
Null要素はどのような値も保持しません。通常、値の不要な要素を必要とする場合にプレースホルダとして使用されます。
-
Octet string
Octet string要素は0オクテット(バイト)以上のデータ・セットを保持します。文字列データまたはバイナリ・データの保持に使用できます。
-
Boolean
Boolean要素は、
true
またはfalse
のいずれかを表す値を保持します。 -
Integer
Integer要素は、整数値を表す値を保持します。
-
Enumerated
Enumerated要素は、各値が特定の意味を保有する整数値を表す値を保持します。
-
Sequence
Sequence要素は、0個以上のSequence要素以外のASN.1要素を保持するコンテナで、要素の順序が重要な方式です。
-
Set
Set要素は、0個以上のSet要素以外のASN.1要素を保持するコンテナで、要素の順序は重要ではない方式です。
ノート:
ASN.1はバイナリ・コーディング用の一般的なフレームワークですが、データのエンコード方法を実際には定義しません。エンコード方法はエンコーディング・ルールで処理され、様々な種類のASN.1エンコーディング・ルールが存在します。LDAPでは基本エンコーディング・ルール・エンコーディングが使用されますが、別のタイプではDistinguished Encoding Rules (DER)、Canonical Encoding Rules (CER)およびPacked Encoding Rules (PER)があります。
A.4.1.4 アクセス制御
アクセス制御は、ディレクトリ・サーバー内の様々な種類の情報にアクセスできるユーザーを制限するメカニズムを提供します。アクセス制御プロバイダを使用して、次のような様々な事柄を制御できます。
-
クライアントがサーバーからエントリを取得できるかどうか。
-
クライアントが取得を許可されたエントリ内の属性の種類。
-
クライアントが取得を許可された属性の値。
-
クライアントがディレクトリ内でデータを操作できる方法。
アクセス制御の決定には、次のような様々な事柄を考慮できます:
-
認証されたユーザーとしてのDN。
-
クライアントがサーバーへの認証を行った方法。
-
ユーザーがメンバーである任意のグループ。
-
認証されたユーザーのエントリのコンテンツ。
-
ターゲット・エントリのコンテンツ。
-
クライアント・システムのアドレス。
-
クライアントとサーバーの間の通信がセキュアかどうか。
-
試行の時刻または曜日、あるいはその両方。
アクセス制御構文の詳細は、「データへのアクセス制御」を参照してください。
アクセス制御サブシステムに加えて、ディレクトリ・サーバーには、ユーザーに対する許可内容を制御するために使用できる特権もあります。使用可能な特権の1つはbypass-acl
特権で、この特権がなければアクセス制御サブシステムにより強制される制限を、クライアントがバイパスできるようにするために使用できます。
A.4.1.6 アクセス制御ルール
アクセス制御ルール(アクセス制御命令またはACIとも呼ばれる)は、サーバーで数種類の操作を実行するユーザーまたはユーザー・セットに対してアクセス権限を与えるか、または拒否するために使用できるルールです。ディレクトリ・サーバーのアクセス制御ポリシーは、サーバーで定義されるアクセス制御ルールのセット全体で構成されます。
アクセス制御ルールで使用される構文、およびアクセス制御ルールを使用して許可または拒否できる操作の詳細は、「データへのアクセス制御」を参照してください。
A.4.1.7 アクセス・ログ
ディレクトリ・サーバーのアクセス・ログは、すべての受信されたリクエストおよび返されたレスポンスを含め、サーバーにより処理されたすべての操作を追跡するメカニズムを提供します。サーバー内で実行された内部操作についての情報の取得にも使用される場合があります。
ディレクトリ・サーバーは、アクセス・ロガー(同様にエラー・ログおよびデバッグ・ログのロガー)を実装するための拡張可能なフレームワークを提供します。デフォルトのアクセス制御ログを実装すると、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およびミリ秒単位の処理時間が含まれる場合があります。
アンバインド操作の場合は、リクエスト・メッセージは、アンバインド・リクエストが受信されたことを示すのみです。アンバインド・リクエストに対するレスポンスおよび結果ログ・メッセージはありません。
接続操作の場合、ログ・メッセージには、サーバーとクライアントのIPアドレス、およびプロトコルが含まれます。クライアントがセキュアなチャネルを介して接続する場合、log-connection-details
フラグがtrue
に設定されていると、TLSバージョン、ネゴシエートされた暗号スイートなどの追加の詳細が別の行に記録されます。conn=value
を使用して、リクエストの他のログをマップできます。ここでのvalueは接続IDです。
A.4.1.8 アカウント有効期限
アカウント有効期限は、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、指定された日付を過ぎると、それ以降アカウントを使用できないことを示すために使用できます。この機能は、指定された日付の後で期限切れとなる一時的なユーザー・アカウント(契約者、インターンまたはその他の一時的な職員用など)の作成に役立ちます。
アカウント有効期限を有効化するには、ターゲット・ユーザーのエントリにds-pwp-account-expiration-time
操作属性を追加します。この属性の値は、アカウントの有効期限とする時刻を指定する、一般的な時刻形式のタイムスタンプです。アカウント有効期限の時刻が過ぎると、ユーザーはサーバーに対する認証を許可されません。
A.4.1.9 アカウント・ロックアウト
アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、バインドの試行に何度も失敗した後でユーザー・アカウントをロックするために使用できます。アカウントがロックされると、ユーザーは認証を許可されません。ロックアウトは、一時的(指定された期間の後で自動的に終了)または永続的(管理者がユーザーのパスワードをリセットするまで有効)にできます。
A.4.1.10 アカウント・ステータス通知
アカウント・ステータス通知は、サーバーのパスワード・ポリシーに関わる重要な方法でユーザー・アカウントが変更されたことを示すために使用できるメカニズムです。
サーバーで使用可能なアカウント・ステータス通知のタイプには次のものがあります:
-
ユーザーのアカウントがアカウント・ロックアウトになった場合
-
ユーザーのアカウントがアカウント・ロックアウトになった場合
-
ユーザーのアカウントが管理者にロック解除された場合
-
ユーザーのアカウントが管理者に手動で無効化または再有効化された場合
-
ユーザーのアカウント有効期限を過ぎている場合
-
ユーザーのパスワード有効期限を過ぎているか、間もなく有効期限となる場合
-
ユーザーのパスワードがパスワードのリセットをされた場合
-
ユーザーのパスワードがエンド・ユーザーにより変更された場合
ディレクトリ・サーバーは、アカウント・ステータス通知を処理するために拡張可能なフレームワークを提供します。デフォルトのハンドラはサーバーのエラー・ログにメッセージを書き出しますが、フレームワークを使用して電子メール・メッセージを送信したり、必要なその他のアクションを実行したりできます。
A.4.1.11 アカウント・ユーザビリティ制御
アカウント・ユーザビリティ制御は、ユーザー・アカウントがサーバーに対する認証に使用できるかどうかを判断するための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(パスワード有効期限が有効ではない場合)が含まれます。ユーザー・アカウントが使用可能でない場合は、制御には使用可能でない理由が示されます。
検索リクエストでこの制御を使用する例は、「アカウント・ユーザビリティ・リクエスト制御を使用した検索」を参照してください。
A.4.1.12 ACID
ACIDは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)および永続性(Durability)を略した頭字語です。この用語は、データベースのトランザクション特性を使用して実現できる特質に関する標準データベース用語です。次の要素があります。
-
原子性
データベースで実行される各トランザクションは原子的です。つまり、完全に成功または完全に失敗のいずれかです。トランザクションの一部の変更が適用されてそれ以外は適用されないような変更は、部分的な成功ではありません。
-
一貫性
データベースは常に一貫性のある状態で、コンテンツの整合性が保たれています。トランザクションの成功または失敗に対して、データベースを一貫性のない状態にできないようにする必要があります。
-
独立性
トランザクションの一部として実行される操作は、データベース内で同時に実行されるその他の操作から独立しています。あるトランザクションがデータベース・コンテンツに対するいくつかの変更に使用される場合は、別のトランザクション操作は変更がコミットされるまで変更の結果を確認できないようにする必要があります。
-
永続性
データベースにより、正常に完了し、コミット済と報告されたトランザクションはいずれも、永続的な記憶域での保存が保証されます。ディレクトリ・サーバー、基礎となるJVM、オペレーティング・システムまたはハードウェアで、コミット完了の通知の直後に障害が発生しても、変更は失われません。
主要なバック・エンドのデータ・ストアとして使用されるBerkeley DB Java Editionは、ACID準拠をフル・サポートします。ただし、パフォーマンスの理由により必要があれば、これらの制約に対する準拠を緩和する方法もあります。ディレクトリ・サーバーは、このような柔軟性、特に変更を永続的に保持するための構成に関して公開しています(たとえば、変更をすぐにディスクに出力しないようにサーバーを構成することも可能です。これにより、書出しのパフォーマンスを向上させることができますが、ハードウェアまたはソフトウェアの障害が発生した場合にいくつかの変更を消失する原因になる可能性があります)。
A.4.1.14 別名
別名は、サーバー内の別のエントリを参照する特別なタイプのエントリで、UNIXファイル・システムのシンボリック・リンクによく似ています。alias
オブジェクト・クラス、および別名が参照するエントリのDNと等しい値を持つaliasedObjectName
属性が含まれています。
別名は、主に検索操作で使用されます。特に、検索リクエストには、別名を検出する際に使用される間接参照ポリシーを指定する要素が含まれています。使用できる間接参照ポリシーの値には次のものがあります:
-
neverDerefAliases
サーバーは別名エントリを間接参照しません。
-
dereflnSearching
サーバーは、考えられる検索結果エントリのセットで検出した別名エントリを間接参照しますが、検索ベースDNが別名エントリを指定する場合は、間接参照しません。
-
derefFindingBaseObj
サーバーは、検索ベース・エントリが別名の場合は間接参照しますが、考えられる検索結果エントリのセット内の別名は間接参照しません。
-
derefAlways
サーバーは、検索ベース・エントリまたは考えられる検索結果エントリのセットのどちらかで検出された別名を間接参照します。
ノート:
別名はLDAPv3プロトコルのオプション部分であり、ディレクトリ・サーバーは現在、別名をサポートしていません。
A.4.1.15 AND検索フィルタ
AND検索フィルタは、0個以上のその他の検索フィルタを保持するコンテナとして機能するための、LDAP検索フィルタのタイプです。エントリがANDフィルタと一致するには、ANDフィルタに含まれるすべてのフィルタと一致する必要があります。
ANDフィルタは、フィルタ全体をカッコで囲み、左カッコの直後にアンパサンドを配置した文字列で表すことができます。たとえば、フィルタ(&(objectClass=person)(uid=john.doe))
は、(objectClass=person)
および(uid=john.doe)
の等価フィルタが埋め込まれたAND検索フィルタを表します。
埋込みフィルタを含まないANDフィルタは、LDAP trueフィルタと呼ばれます。LDAP trueフィルタの文字列表現はアンパサンド(&)
で、LDAP trueフィルタは常に任意のターゲット・エントリと一致します。
A.4.1.16 匿名バインド
匿名バインドはバインド操作のタイプで、長さ0のバインドDNおよび長さ0のパスワードを使用する簡易認証を使用します。ある接続で実行された直前の認証を破棄し、未認証のステータスを返すために使用できます。
同じ結果となるANONYMOUS SASLメカニズムがありますが、通常は匿名バインドという用語はDNおよびパスワードなしの簡易バインド操作を指すことに注意してください。
A.4.1.17 ANONYMOUS SASLメカニズム
ANONYMOUS SASLメカニズムは、Simple Authentication and Security Layer認証メカニズムのタイプです。その他のSASLメカニズムとは未認証セッションの作成に使用される点で異なっており、接続で実行された可能性のある直前の認証を破棄します。
ANONYMOUS SASLメカニズムは、サーバーのアクセス・ログに含めることのできるリクエストに追跡情報を追加する機能があります。この追跡情報は、バインドを実行するクライアントの情報を提供できます。ただし、認証が実行されていないため、追跡情報の有効性は保証できません。
A.4.1.19 近似検索フィルタ
近似検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値におおよそ等しい、指定された属性の値を含むエントリを識別するために使用できます。サーバーは、近似一致ルールを使用して判断します。
LDAP近似フィルタの文字列表現は、左カッコに続く属性名、チルダ記号、等号、属性値および右カッコで構成されます。たとえば、近似フィルタ(givenName~=John)
は、John
とおおよそ等しい値を含むgivenName
属性のエントリと一致します。
A.4.1.24 属性オプション
属性オプションは、属性の解釈方法についての追加情報を指定するタグの種類です。属性説明には、属性名またはオブジェクト識別子とそれに続く0個以上の属性オプションが含まれます。属性オプションが複数存在する場合は、属性名と、および各属性オプションとは互いにセミコロンを使用して区切られます。たとえば、属性説明userCertificate;binary
では、属性名はuserCertificate
で、属性オプションはbinary
です。
属性オプションは、サーバーが属性を取り扱う方法についての情報(RFC 4522 (http://www.ietf.org/rfc/rfc4522.txt
)で説明されるバイナリ・エンコーディング・オプションなど)の提供を含め、いくつかの目的に使用できます。また、属性オプションはいくつかの形式でクライアントにも利点があります(たとえば、RFC 3866 (http://www.ietf.org/rfc/rfc3866.txt
)で説明される言語タグ・オプションは、異なる言語での属性値の指定を可能にします)。
A.4.1.25 属性構文
属性構文は、スキーマ要素であり、属性値に保存できる情報の種類を指定するためのデータ・タイプの種類を定義します。関連付けられた属性タイプの構文に違反する属性値を保存しようとすると、却下されます。
一般的な属性の構文には次のものがあります:
-
Binary
テキスト情報かどうかにかかわらず、任意の種類のデータを保持することが可能で、バイト対バイト・ベースで比較する必要があります。
ノート:
オクテット文字列構文が優先され、バイナリ構文は非推奨になりました。
-
Boolean
TRUE
またはFALSE
のいずれかの値を保持できます。 -
Directory String
任意の種類の文字列値を保持できます(技術的にはバイナリ値も許容されますが、通常、ディレクトリ文字列値は文字列です)。
-
Distinguished Name
有効な識別名の値を保持できます。
-
Generalized Time
タイムゾーン情報および有効桁数が変化するタイムスタンプ(時から秒の小数部までの任意の部分)を含む値を保持できます。たとえば、値
20070525222745Z
は、UTCタイムゾーンで2007年5月25日午後10時27分45秒のタイムスタンプを表します。 -
IA5 String
ASCII文字列を含む値を保持できます(つまり、非ASCII文字の使用は許可されません)。
-
Integer
整数値を保持できます。正数、負数および0の値も可能です。
-
Octet String
任意の種類のデータの保持が可能で、バイト対バイト・ベースで比較する必要があります。
-
Postal Address
複数行の住所の保持が可能で、住所の行はドル記号で区切られます。
-
Printable String
印刷可能な文字を任意に組合せた文字列を保持できます。印刷可能な文字には、すべてのASCII文字の大文字と小文字、数字、空白および記号
'()+,-.=/:?
が含まれます。 -
Telephone Number
電話番号の値を保持できます。
サーバーで定義される属性構文のセットは、サブスキーマ・サブエントリのldapSyntaxes
属性を取得して確認できます。属性構文の詳細は、「属性構文の概要」を参照してください。
A.4.1.26 属性タイプ
属性タイプはスキーマ要素であり、オブジェクト識別子、属性構文を伴う名前のセットおよび一致ルールのセットに関連付けられます。
属性タイプのコンポーネントの定義は次のとおりです:
-
属性タイプを一意に識別するために使用されるOID。
-
属性タイプの参照をより容易にするために使用できる0個以上の名前のセット。
-
属性の値に対する等価一致の実行方法を指定する、オプションの等価一致ルール。等価一致ルールが指定されない場合は、デフォルトの等価ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの等価一致ルールが存在しない場合は、その属性に対する等価操作は許可されません。
-
属性の値に対する順序付け操作の実行方法を指定する、オプションの順序付け一致ルール。順序付け一致ルールが指定されない場合は、デフォルトの順序付けルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの順序付け一致ルールが存在しない場合は、その属性に対する順序付け操作は許可されません。
-
属性の値に対する部分文字列一致の実行方法を指定する、オプションの部分文字列一致ルール。部分文字列一致ルールが指定されない場合は、デフォルトの部分文字列ルールが関連付けられた属性構文で使用されます。関連付けられた構文にデフォルトの部分文字列一致ルールが存在しない場合は、その属性に対する部分文字列操作は許可されません。
-
属性の値に対する構文を指定する、オプションの構文OID。構文が指定されない場合は、ディレクトリ文字列構文にデフォルト設定されます。
-
属性が複数の値を持つことを許可されているかどうかを示すフラグ。
-
属性が使用されるコンテキストを示す、オプションの属性使用方法文字列。
-
外部クライアントが属性を変更できるかどうかを示す、オプションのフラグ。
サーバーで定義される属性タイプのセットは、サブスキーマ・サブエントリのattributeTypes
属性を取得して確認できます。属性タイプの詳細は、「属性タイプの理解」を参照してください。
A.4.1.27 属性使用方法
属性タイプの属性使用方法は、属性タイプを使用できるコンテキストを定義します。属性使用方法には、次の4つのタイプがあります:
-
userApplications
ユーザー定義データの保持に使用するためのすべての属性タイプで使用されます。
-
directoryOperation
サーバー内の暗黙的な処理のための属性タイプで使用されます。
-
distributedOperation
ディレクトリ環境全体に配布する必要のある操作データ(つまりレプリケーション)を保管する属性タイプで使用されます。
-
dSAOperation
1台のサーバーのみで保管し、ディレクトリ環境全体にレプリケートしてはならない操作データを保管する属性タイプで使用されます。
使用方法userApplications
を持つ属性は、いわゆるユーザー属性です。使用方法directoryOperation
、distributedOperation
またはdSAOperation
を持つ属性は、いわゆる操作属性です。
A.4.1.29 属性値アサーション
属性値アサーション(AVA)は、属性説明および属性値の組合せです。アサーション値は、判断のために一致ルールとともに使用されます。一致ルールが等価一致ルールの場合は、属性に指定された値が含まれているかどうかの判断に使用されます。順序付け一致ルールの場合は、AVAは、アサーション値以上の値または以下の値が属性に含まれているかどうかの判断に使用されます。近似一致ルールの場合は、AVAは、アサーション値におおよそ等しい値が属性に含まれているかどうかの判断に使用されます。部分文字列一致はより複雑で、簡易アサーション値ではなく部分文字列アサーションを使用します。
属性値アサーションはLDAP比較操作および等価検索フィルタ、大きいか等しい検索フィルタ、小さいか等しい検索フィルタおよび近似検索フィルタの検索フィルタで使用されます。
A.4.1.30 監査ログ
監査ログは特別なタイプのアクセス・ログで、サーバーで実行されるすべての変更の情報をログに記録するために使用されます。これらの変更のログはLDAPデータ変換形式で記録され、管理者は実行された変更を正確に確認できます。この情報は、問題を調査する際に診断のために使用可能で、アプリケーションがディレクトリで実行する可能性のある変更の種類をより理解しやすくし、別のリポジトリに対するリプレイの変更について正しい情報を得るために役立ちます。
監査ログという名前は、Netscape Directory Serverでの監査ログの使用を指すレガシー用語です。監査ログは、ディレクトリ・データに対する変更を記録するのみで、認証の試行の成功または失敗などは追跡しないため、セキュリティ監査で使用される場合のあるログと混同しないでください。ただし、多くの場合、従来のアクセス・ログおよび監査ログの内容を組み合せて使用し、このような種類の情報を取得します。必要に応じて、管理者はカスタム・アクセス・ログを実装して、希望する種類の情報の追跡もできます。
A.4.1.31 認証
認証は、クライアントがクライアント自体をディレクトリ・サーバーに認証要求し、アイデンティティを証明するプロセスです。LDAPでは、バインド操作を使用して実行されます。
認証プロセスには次の2つのフェーズがあります:
-
識別
クライアントは、いくつかの方法でクライアント自体をサーバーに認証要求します。簡易認証では、バインド・リクエストで指定されたDNがこのために使用されます。Simple Authentication and Security Layer認証では、クライアントのアイデンティティはその他いくつかの方法(証明書、Kerberosプリンシパルまたはその他数種類の識別子の使用など)で取得されます。
-
アイデンティティの検証
クライアントは、クライアント自体の認証要求をしたユーザーが誰であるかを十分に証明する必要があります。簡易認証では、パスワードを使用して実行されます。SASL認証では、この検証は関連付けられたメカニズム固有の方法で取得されます(パスワード、証明書またはその他の証明の形式の場合があります)。
他のメカニズムよりも厳格であるとみなされる認証メカニズムもあります。たとえば、クライアントの保有するパスワードの推測やその他の方法による取得が容易である場合は、簡易認証はより信頼性が低いと考えられ、証明書またはKerberos資格証明を使用した認証はより厳格でねつ造は困難であると考えられる可能性があります。ディレクトリ・サーバーのアクセス制御を実装すると、リクエストされた操作を許可するかどうかを判断する際に、クライアントの認証メカニズムを考慮するように構成できます。
A.4.1.32 認証ID
認証IDは、Simple Authentication and Security Layerメカニズムの特定の種類(CRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズムおよびPLAIN SASLメカニズムなど)で、クライアント自体をディレクトリ・サーバーに認証要求するクライアントに使用される識別子です。認証IDを使用して、識別名ではなくユーザー名(またはその他のわかりやすい識別子)でクライアントがクライアント自体を認証要求できます。
多くの場合、認証IDは次の形式のうちの1つに指定されます:
-
文字列
dn:
とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認証アイデンティティとする必要がある場合は、文字列dn:
のみ)。 -
文字列
u:
とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。
A.4.1.33 認証パスワード構文
認証パスワード構文は、サーバーの記憶域用のユーザー・パスワードをエンコードする標準メソッドを定義します。パスワードのクリアテキスト値の確認を困難あるいは不可能にする方法をお薦めします。
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
MD5メッセージ・ダイジェストを使用します。
-
SHA1
セキュア・ハッシュ・アルゴリズムのSHA-1バリアントを使用します。
-
SHA256
セキュア・ハッシュ・アルゴリズムの256ビットSHA-2バリアントを使用します。
-
SHA384
セキュア・ハッシュ・アルゴリズムの384ビットSHA-2バリアントを使用します。
-
SHA512
セキュア・ハッシュ・アルゴリズムの512ビットSHA-2バリアントを使用します。
A.4.1.34 認可
A.4.1.35 認可ID
認可IDは、クライアントに使用される識別子で、代替認可アイデンティティの下で実行される1つ以上の操作を示します。この代替認可アイデンティティは、1つの操作の間(プロキシ認可制御とともに使用される場合)または認証セッションが継続している期間(DIGEST-MD5 SASLメカニズム、GSSAPI SASLメカニズムまたはPLAIN SASLメカニズムなどの適切なSASLメカニズムとともに使用される場合)、継続できます。
多くの場合、認可IDは次の形式のうちの1つに指定されます:
-
文字列
dn:
とそれに続くターゲット・ユーザーの識別名(または匿名ユーザーの認可IDとする必要がある場合は、文字列dn:
のみ)。 -
文字列
u:
とそれに続くユーザーの認証要求に使用されるユーザー名。アイデンティティ・マッパーを使用して、入力されたユーザー名を対応するユーザー・エントリにマッピングします。
代替認可アイデンティティを使用するクライアントの機能は、proxied-auth
特権で制御されます。追加のアクセス制御権限が要求される場合もあります。
A.4.1.36 認可アイデンティティ制御
認可アイデンティティ制御は、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拡張操作を使用して、バインドが完了した後でいつでも、認可アイデンティティを取得できます。
検索リクエストでこの制御を使用する例は、「認可アイデンティティ・リクエスト制御を使用した検索」を参照してください。
A.4.1.37 補助オブジェクト・クラス
補助オブジェクト・クラスは、エントリのコア・タイプを定義するものではありませんが、エントリの追加特性を定義します。1つのエントリは、0個以上の補助オブジェクト・クラスを持つことができます。エントリで使用できる補助クラスのセットは、エントリの構造オブジェクト・クラスに関連付けられたDITコンテンツ・ルールにより制御される場合があります。
A.4.2 B
A.4.2.1 バックエンド
ディレクトリ・サーバーのバックエンドは、データを保管するリポジトリ、およびデータと相互に作用するためのロジックのセットを提供します。通常バックエンドには数種類のデータベースがあり、様々な操作でバックエンドが迅速にエントリを見つけられるように索引のセットが維持される場合があります。すべてのバックエンドには次のような特質があります:
-
バックエンドIDは、サーバー内のその他すべてのバックエンドから、該当のバックエンドを一意に識別します。
-
1つ以上のベース識別名のセットは、バックエンドが保持するデータを示します。
-
書込み可能モードは、バックエンドが書込み操作を許可するかどうかを示します。
バックエンドが提供するロジックには次のものがあります:
-
DNに基づき、指定されたエントリが存在するかどうかを判断するメソッド
-
DNに基づき、エントリを取得するメソッド
-
データベースに新規のエントリを追加するメソッド(LDAP追加操作の処理の一部として)
-
データベースから既存のエントリを削除するメソッド(LDAP削除操作の処理の一部として)
-
データベースでエントリを置換するメソッド(LDAP変更操作の処理の一部として)
-
データベースでエントリの名前を変更するメソッド(LDAP DN変更操作の処理の一部として)
-
LDAP検索操作を処理するメソッド
-
LDAPデータ変換形式でデータベースのコンテンツをエクスポートするメソッド
-
LDAPデータ変換形式でデータベースにデータをインポートするメソッド
-
データのバックアップを実行するメソッド
-
以前のバックアップの復元を実行するメソッド
A.4.2.2 バックアップ
バックアップは、ディレクトリ・サーバーのバックエンド内でデータが移動可能であることを表します。各バックエンドは、そのコンテンツのバックアップが可能かどうかを制御し、バックアップ情報が後で実行される復元に適していることを確認します。
ノート:
バックアップする(back up)という用語は動詞(バックエンドのコンテンツをバックアップするアクション)であり、バックアップ(backup)は名詞(バックアップを実行して取得されるもの)です。
バックエンドがバックアップ・メカニズムを提供できない理由がいくつかあります。理由には次のものがあります。
-
バックエンドには一時的な、ある時点の情報のみが存在し、この情報をアーカイブしたり、後で復元を試みたりすることは意味がありません(ルートDSEまたは監査バックエンドなど)。
-
バックエンドは直接アーカイブできないリモート・リポジトリに情報を保存します。このような場合は、外部リポジトリには通常、それ自体のバックアップおよび復元メカニズムがあります。
ディレクトリ・サーバーが使用する主要なバックエンドは、Berkeley DB Java Editionを使用しており、その基礎となるデータベースおよびバックエンドは完全なバックアップ機能と復元機能を提供します。また、そのバックアップ・メカニズムは移植性が高く、異なるプラットフォーム、異なるファイルシステムの場所に転送が可能で、バイナリ・コピー・メカニズムとしての使用に適しています。
A.4.2.3 base64エンコーディング
Base64エンコーディングは、テキストのみの形式でバイナリ・データを表す方法です。通常、非ASCII文字を含む値または不明瞭になる可能性のある値(空白で開始または終了する値など)に対して、LDAPデータ変換形式で使用されます。また、証明書のコンテンツや、MD5またはセキュア・ハッシュ・アルゴリズムなどのメッセージ・ダイジェストの出力をエンコードするために頻繁に使用されます。RFC 1341 (http://www.ietf.org/rfc/rfc1341.txt
)の第5.2項にbase64エンコーディングについて記載されています。
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つの等号を付与します。
A.4.2.4 基本エンコーディング・ルール
基本エンコーディング・ルール(BER)は、抽象構文表記法1エンコーディング・ルールのセットで、情報をバイナリ形式でエンコードする特定の方法を定義します。メッセージをエンコードする基礎的なメカニズムとして使用されます。「基本エンコーディング・ルールの概要」を参照してください
A.4.2.6 Berkeley DB Java Edition
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の値をエントリのコンテンツにマッピングするためのメカニズムを提供します。その他のデータベースは、様々なタイプの操作を処理するエントリ・コンテンツを迅速に見つけるために使用できる索引として機能します。
A.4.2.7 バイナリ・コピー
バイナリ・コピーは、1つのサーバー・インスタンスのディレクトリ・サーバー・バックエンドのバックアップおよびサーバーの別のインスタンスへのバックエンドの復元を実行するプロセスを指します。これにより、迅速な障害時リカバリ・メカニズムを実現し、レプリカ初期化メカニズムとしても使用できます。
すべてのディレクトリ・サーバー・バックエンドがバイナリ・コピーの使用をサポートする必要はなく、状況によってはサポートしない場合もあります。ディレクトリ・サーバーで使用される主要なバックエンドのタイプはBerkeley DB Java Editionの使用に基づいており、Berkeley DB Java Editionは、異なるオペレーティング・システム、CPUアーキテクチャ間で、異なるファイルシステム上の場所を使用する、バイナリ・コピー・メカニズムの使用をサポートします。ただし、どちらのサーバーも同じベース識別名のセットおよび定義された同じ索引のタイプを持つ必要があります。
A.4.2.8 バインド操作
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資格証明のセットも含まれる場合があることを示します。
A.4.3 C
A.4.3.1 取消し拡張操作
LDAP取消し拡張操作は、実行中の操作の処理をサーバーが停止するようにリクエストするために使用できるという点で、コアLDAP中止操作に類似した機能を提供する拡張操作です。中止操作より優れた取消し拡張操作の主要な利点は、取消しリクエストおよび取り消される操作の両方に対してレスポンスの取得が保証されることです。しかし、中止リクエストに対するレスポンスはなく、中止される操作に対するレスポンスがない場合があります。
取消し拡張操作はRFC 3909 (http://www.ietf.org/rfc/rfc3909.txt
)で定義されています。取消しリクエスト拡張操作の値は次のようにエンコードされます:
cancelRequestValue ::= SEQUENCE { cancelID MessageID -- MessageID is as defined in [RFC2251] }
A.4.3.3 証明書
証明書は、非対称暗号化を実行するために使用できる公開キー暗号の要素です。特に証明書は、1組のキー(それぞれ公開キーおよび秘密キーと呼ばれる)で構成され、公開キーで暗号化された任意のデータを秘密キーで復号化できるように関連付けられています。RSAなど多くの公開キー・アルゴリズムを使用して、秘密キーで暗号化された任意のデータを公開キーで復号化できるように、その反対も可能です。
証明書という用語には、使用されるコンテキストに基づいて異なる意味があります。多くの場合、公開キーのみを指します(特に、サーバーがクライアントに証明書を提示する場合は常に、またはクライアントがサーバーに証明書を提示する場合は、公開キーのみが含まれます)。ただし、その他のケースでは、秘密キーを含みます(たとえば、サーバーがクライアントとの保護された通信チャネルを確立するために秘密キーの使用を要求したり、クライアントがサーバーに対してクライアント自体の証明書を送信するために秘密キーへのアクセスを必要としたりします)。
ディレクトリ・サーバーでは、証明書には2つの主要な用途があります。1つ目は、通常、Secure Sockets LayerまたはTLS起動拡張操作を介して、保護された通信メカニズムを提供するためです。この場合は、ネゴシエーション・プロセスで、サーバーのみが公開キーを使用して復号化できるように、サーバーの公開キーを使用したクライアントの暗号化情報が必要とされ、その情報は通信を確認できる可能性のあるサード・パーティには公開されません。証明書はデータの署名にも使用される場合があり、この場合は、サーバーが秘密キーを使用して情報を暗号化し、クライアントはサーバーの公開キーを使用してその情報を復号化できた場合に、サーバーからの正当なデータであることを確認します。
A.4.3.5 チェーン
チェーンは、ローカル・サーバーの一部のように見えるリモート・ディレクトリ・サーバー・インスタンスでのデータ作成のメカニズムを提供します。つまり、チェーンを使用して、別のサーバーからのデータを使用したディレクトリ情報ツリー(DIT)の一部を表示します。DITのチェーン部分のデータに対してサーバーが受信するリクエストは、そのリクエストを実際に含むサーバーに透過的に転送されます。
A.4.3.8 集合属性
集合属性は特別なタイプの仮想属性で、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt
)で定義されています。集合属性を使用して、サブエントリ内のエントリのメンバーシップに基づく属性に対して、割り当てる値を定義できます。
A.4.3.9 Common Development and Distribution License
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
を参照してください。
A.4.3.10 比較操作
LDAP比較操作は、特定のエントリに指定された属性値が含まれるかどうかの判断に使用できます。比較リクエストのプロトコルopは次のように定義されます:
CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } AttributeValueAssertion ::= SEQUENCE { attributeDesc AttributeDescription, assertionValue AssertionValue }
リクエストの要素には次のものがあります:
-
比較が実行されるエントリのDN。
-
比較が実行される属性の名前。
-
指定された属性で検索するアサーション値。
LDAP比較操作に対するレスポンスは、LDAP結果要素で、次のように定義されます:
CompareResponse ::= [APPLICATION 15] LDAPResult
A.4.3.11 接続ハンドラ
接続ハンドラはディレクトリ・サーバーのコンポーネントで、クライアントからの接続の許可、クライアントにより実行されたリクエストの読取りと解析、サーバーによる処理の確認およびクライアントに返す対応するレスポンスの送信を実行します。接続ハンドラはクライアントとの通信をすべて管理するため、関連付けられたプロトコルのサポートを実装する必要があります。
ディレクトリ・サーバーが現在提供するのは、Lightweight Directory Access ProtocolおよびJava Management Extensionsを使用する通信が可能な接続ハンドラ、および操作を実行するためのサーバーのコンポーネント(プラグインおよびその他の種類の拡張など)を使用できる、内部使用のための特別な接続ハンドラです。サーバーは、追加のネットワーク・プロトコルのサポートを実装するために使用できる拡張可能な接続ハンドラAPIも提供します。
A.4.3.12 接続ID
接続IDは、一意の整数の識別子で、ディレクトリ・サーバー内で維持される各接続に割り当てられます。主にロギングの用途に使用して、指定された接続で実行される様々な操作を関連付けることができます。
接続IDカウンタは、サーバーが受信した最初の接続で0から開始され、接続が追加されるごとに1ずつ増分します。カウンタは、サーバーが再起動されるたびにリセットされます。
内部操作の処理で使用される内部接続には、外部クライアントからの接続と区別するために負の値が割り当てられます。
A.4.3.13 制御
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 }
制御には次の要素があります:
-
制御のタイプを指定するオブジェクト識別子。
-
クリティカル度。制御が操作の重要な部分とみなされるかどうかを示します(つまり、サーバーが制御を処理できない場合は、操作は失敗します)。
-
オプション値。制御の処理方法についての追加情報を提供するために使用できます。
A.4.3.14 CRAM-MD5 SASLメカニズム
CRAM-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。
CRAM-MD5 SASLメカニズムはDIGEST-MD5 SASLメカニズムとよく似ていますが、DIGEST-MD5がクライアントとサーバーの両方からのランダム・データを含めるのに対して、CRAM-MD5はサーバーからのみであるため、多少脆弱です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。「CRAM-MD5 SASLメカニズムを私用した認証」を参照してください
A.4.3.15 暗号化アルゴリズム
暗号化アルゴリズムは、LinuxシステムおよびUNIXシステムでユーザー・パスワードをエンコードするためのメカニズムです。CRYPTパスワード記憶スキームは、すべてのモジュラ暗号化パスワード・エンコーディングのアンブレラであり、既存の実装との互換性を確保します。
モジュラ暗号化パスワード・エンコーディングの形式は、$<ID>$<SALT>$<PWD>
または$<ID>$rounds=<N>$<SALT>$<PWD>
です。これにより、同じCRYPTパスワード記憶スキームで複数のアルゴリズムが可能になります。サポートされているモジュラ・アルゴリズムは、MD5、SHA256およびSHA512です。
既存のUNIX暗号化アルゴリズムは引き続きサポートされており、既存のデプロイメントとの互換性を確保するデフォルトのスキームです。
CRYPTパスワード記憶スキームを使用したエンコード時に使用するアルゴリズムを選択できます。サポートされているアルゴリズムですでにエンコードされているパスワードは、現在構成されているアルゴリズムに関係なく引き続き機能します。オプションで、SHAベースのアルゴリズムのラウンド数を構成することもできます。これは、別のシステムからインポートされた既存のパスワードとキー・ストレッチのカスタム・ラウンド数を使用するスキームは互換性があるためです。
カスタムの長さのsaltもサポートされていますが、一方向の互換性のみを対象としています。つまり、カスタムの長さのsaltを使用した既存のパスワードはサポートされますが、新しいパスワードは常に各アルゴリズムに指定された最大長のsaltを使用します。
「パスワード記憶スキーム」も参照してください。
A.4.4 D
A.4.4.1 データベース
データベースは、情報の保管に使用されるリポジトリです。ディレクトリ・サーバーでは、データベースはバックエンドでデータを保管するメカニズムとして使用されます。異なる補助記憶装置を使用して他のバックエンドを作成できますが、Berkeley DB Java Editionは、ディレクトリ・サーバーで使用される主要なデータベースです。
A.4.4.2 データベース・キャッシュ
データベース・キャッシュは、基礎となるデータベースからのコンテンツを保持するために予約されるメモリーの部分です。データベースからの情報の取得を試行する場合は常に、データベースはディスクにアクセスする前に、最初にこのキャッシュをチェックします。データベース・キャッシュは、負荷のかかるディスクI/Oを回避して、パフォーマンスを大幅に改善するために役立ちます。
データベース・キャッシュは、サーバーのエントリ・キャッシュのかわりに、またはこれに加えて使用できます。データベース・キャッシュは、より簡潔なデータ表現を頻繁に作成しますが(つまり、システムの限られたメモリーで、より多くのデータをキャッシュに保持できます)、通常、エントリ・キャッシュは、サーバーでより効率的に使用できる形式でデータを保持します。
A.4.4.3 デバッグ・ログ
デバッグ・ログは、サーバーで発生した問題のデバッグに使用できる情報を取得するためのメカニズムです。通常、デバッグ情報は問題の発生時にのみ役立つデータで、量が多いため通常の運用では維持できない場合が頻繁に発生します。デバッグ・ログでは次のような情報が報告されます。
-
サーバー内でスローされた例外の詳細情報
-
ネットワーク上のクライアントから読み取られたデータまたはクライアントに書き込まれたデータの情報
-
データベースから読み取られたデータまたはデータベースに書き込まれたデータの情報
-
アクセス制御またはパスワード・ポリシーの処理などの領域で実行された判断についての情報
A.4.4.5 非推奨パスワード記憶スキーム
非推奨パスワード記憶スキームは、サーバーで使用可能なパスワード記憶スキームですが、主に移行時の使用を意図しています。非推奨の記憶スキームでエンコードされたパスワードを所有している場合は、ユーザーは認証を許可されますが、パスワードはパスワード・ポリシーで定義されるデフォルトの記憶スキームのセットを使用して再エンコードされます。
このメカニズムは、(デフォルトのスキームよりも脆弱であるなどの理由で)使用を継続しないパスワード記憶スキームを使用する別のサーバーから、ディレクトリ・サーバーへデータを移行する場合を主に意図しています。サーバーに対するユーザー認証と同様、パスワードは非推奨のスキームからデフォルトのスキームに移行されます。
A.4.4.6 間接参照ポリシー
間接参照ポリシーは検索操作の要素で、検索処理の間に検出される場合のある別名エントリのサーバーでの処理方法を指定します。使用可能な別名間接参照ポリシーの値には次のものがあります:
- neverDerefAliases
-
サーバーは、検索処理中に検出する別名の間接参照を試みることはできません。
- derefInSearching
-
サーバーは、エントリが検索基準に一致するかどうかを判断する検索操作の範囲内で、エントリを間接参照します。検索ベースDNとして指定されるエントリは間接参照されません。
- derefFindingBaseObj
-
サーバーは、エントリが別名の場合は、検索ベースDNとして参照されるエントリを間接参照する必要がありますが、検索操作の範囲内にあるその他の別名エントリは間接参照されません。
- derefAlways
-
サーバーは、検索操作の範囲内で別名エントリを間接参照し、ベース・エントリが別名の場合も間接参照します。
A.4.4.7 DIGEST-MD5 SASLメカニズム
DIGEST-MD5 Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。クリアテキスト・パスワードを公開しない方法であるため、クライアントとサーバーの間の接続が保護されていない場合は、簡易認証またはPLAIN SASLメカニズムよりも安全性に優れています。
DIGEST-MD5 SASLメカニズムはCRAM-MD5 SASLメカニズムとよく似ていますが、CRAM-MD5がサーバーからのランダム・データのみを含めるのに対して、DIGEST-MD5はクライアントとサーバーの両方からであるため、多少厳格です。DIGEST-MD5では、接続の完全性または機密性、あるいはその両方を保証するプロビジョニングも提供されますが、CRAM-MD5では提供されません。「DIGEST-MD5 SASLメカニズムについて」を参照してください
A.4.4.8 ディレクトリ情報ツリー(DIT)
ディレクトリ情報ツリーすなわちDITは、ディレクトリ・サーバーのデータの階層構造を指します。DITには、サーバーに対するベース・エントリであるネーミング・コンテキストが1つ以上あり、その他のエントリはすべて、これらのネーミング・コンテキスト・エントリの1つの下位にあります。つまり、ネーミング・コンテキスト・エントリは親エントリを持たないという点で特殊です。
次のシナリオについて考えます。エントリdc=example,dc=com
はネーミング・コンテキストで、2つの直属の子を保有し、その子のDNはそれぞれou=People,dc=example,dc=com
およびou=Groups,dc=example,dc=com
で、それらの各エントリはそれ自体の下位エントリを保有しています。ディレクトリ・ツリーの最大の深さについて事前に定義された制限はなく、どのエントリも1つ以上の下位エントリを保有する可能性があります。下位エントリを保有しないエントリはリーフ・エントリと呼ばれ、少なくとも1つの下位エントリを保有するエントリはリーフ以外のエントリと呼ばれます。
A.4.4.10 ディレクトリ・サーバー
ディレクトリ・サーバーは、外部クライアントがアクセスできる方法でデータを保管するネットワーク・デーモンのタイプです。一部のサーバーでは、DAPまたはNDSなどその他のプロトコルを使用しますが、通常、ディレクトリ・サーバーでは、クライアントとの通信にLightweight Directory Access ProtocolまたはDirectory Services Markup Language (DSML)を使用します。
ディレクトリ・サーバーは、(ディレクトリ情報ツリー(DIT)と呼ばれる)階層形式でデータを保管し、クライアントがその情報と相互に作用するための次のような機能を提供します。
-
追加操作。サーバーへの新規のエントリの追加を可能にします。
-
削除操作。サーバーからのエントリの削除を可能にします。
-
変更操作。サーバー内の既存の情報の更新を可能にします。
-
DN変更操作。サーバー内のエントリの名前の変更を可能にします。
-
バインド操作。サーバーに対するユーザー認証を可能にします。
-
比較操作。エントリが特定の属性値の組を保有しているかどうかの判断を可能にします。
ディレクトリ・サーバーは、ネットワーク上のクライアントとの通信にLDAPv3を使用し、DSMLリクエストの処理に使用できるDSMLゲートウェイを提供します。
A.4.4.12 Directory Services Markup Language (DSML)
Directory Services Markup Language (DSML)は、ディレクトリ・サーバーとの通信に使用できるプロトコルです。DSMLはLightweight Directory Access Protocolに代わるもので、LDAPで使用される基本エンコーディング・ルールによるエンコーディングのかわりにXMLベースの表現のリクエストおよびレスポンスを使用します。
通常、DSMLは、LDAPのかわりとしては比較的脆弱であると考えられています。LDAPで使用されるBERエンコーディングと比較すると、XML表現はより冗長で処理が高価で、利点があまりなく大きなコストが発生するためです。多くの場合、サーバーとの対話にはDSMLのかわりにLDAPの使用をお薦めします。
A.4.4.13 識別名
識別名(DN
と呼ばれることが多い)は、ディレクトリ・サーバー内のエントリを一意に識別する文字列です。ディレクトリ情報ツリー(DIT)内のエントリの場所を識別する、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
)を参照してください。
A.4.4.16 DITコンテンツ・ルール
DITコンテンツ・ルールはスキーマ要素で、構造オブジェクト・クラスに基づき、エントリとともに使用できる補助オブジェクト・クラス、およびエントリとともに使用することを要求、許可および禁止されている属性タイプを指定します。
DITコンテンツ・ルールのコンポーネントの定義は次のとおりです:
-
DITコンテンツ・ルールが関連付けられる構造オブジェクト・クラスのオブジェクト識別子を数字で表したもの。
-
DITコンテンツ・ルールのオプション・セットの名前。
-
関連付けられた構造クラスを含むエントリとともに使用可能な補助クラスの補助オブジェクト・クラス名またはOIDのオプション・セット。
-
関連付けられた構造クラスとともにエントリ内に存在する必要のある、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、必須です。
-
関連付けられた構造クラスを持つエントリ内に、オプションで存在できる属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されていない場合でも、許可されます。
-
関連付けられた構造クラスを持つエントリ内での存在を禁止されている、属性タイプの属性タイプ名またはOIDのオプション・セット。これらの属性は、エントリのオブジェクト・クラスのいずれかにより許可されている場合でも、禁止されます。
サーバーで定義されるDITコンテンツ・ルールのセットは、サブスキーマ・サブエントリのdITContentRules
属性を取得して確認できます。DITコンテンツ・ルールの詳細は、「DITコンテンツ・ルールの概要」を参照してください。
A.4.4.17 DIT構造ルール
DIT構造ルールはスキーマ要素で、エントリ間の階層関係の定義に使用できます。特に、親エントリの種類を(構造オブジェクト・クラスに基づいて)、指定された構造クラスを持つエントリを保有できるものと定義します。
DIT構造ルールのコンポーネントの定義には次のものがあります:
-
ルールを一意に識別するために使用される整数のルールID値。
-
DIT構造ルールのオプション・セットの名前。
-
DIT構造ルールが関連付けられる名前書式の名前またはオブジェクト識別子。名前書式は、DIT構造ルールを構造オブジェクト・クラスに順に関連付けます。
-
上位のルールIDのオプション・セット。上位ルールのセットが定義されている場合は、ルールの名前書式に関連付けられている構造クラスがその下に存在を許可されている構造クラスの定義に使用されます。
サーバーで定義されるDIT構造ルールのセットは、サブスキーマ・サブエントリのdITStructureRules
属性を取得して確認できます。DIT構造ルールの詳細は、「DIT構造ルールの理解」を参照してください。
A.4.4.20 DSA固有のエントリ
DSA固有のエントリ(DSE)は特別なタイプのエントリで、ディレクトリ・サーバーのシノニムであるディレクトリ・サーバー・エージェント(DSA)の情報を提供します。
Lightweight Directory Access Protocolは、サーバー内にある情報およびサポートされる操作のタイプについての情報を提供するルートDSEと呼ばれる特別なエントリを定義します。
A.4.4.23 DSMLゲートウェイ
DSMLゲートウェイ(またはDSML-to-LDAPゲートウェイ)は、特別なタイプのネットワーク・デーモンで、Directory Services Markup Language (DSML)およびLightweight Directory Access Protocolの間の変換に使用されます。通常、DSMLゲートウェイはクライアントからのDSMLリクエストを許可し、処理のためにディレクトリ・サーバーに転送するLDAPリクエストに変換します。次に、ディレクトリ・サーバーから返信するLDAPレスポンスをDSMLへ変換し、クライアントに返します。
ディレクトリ・サーバーは、アプリケーション・サーバーで実行可能なWebアプリケーションとして実装されるDSMLゲートウェイを介してDSMLをサポートします。
A.4.4.24 期間
構成プロパティには、許可された値として期間を指定するものがあります。
期間には、整数、および週(w)、日(d)、時(h)、分(m)、秒(s)またはミリ秒(ms)で指定される単位、または複数の指定子の組合せが含まれます。たとえば1週間は、1w
、7d
、168h
、10080m
または604800s
と指定できます。また、10日と半日は1w3d12h0m0s
と指定できます。
期間を必要とするすべてのプロパティが、すべての期間の指定子(w
、d
、h
、m
、s
およびms
)をサポートしているわけではありません。
次のような期間プロパティもあります:
-
基本単位
期間プロパティの値の指定に使用可能な最小粒度を指定します。たとえば、基本単位が秒の場合は、ミリ秒で表された値は許可されません。
-
最大単位(オプション)
期間プロパティの値の指定に使用可能な最大期間の単位を指定します。この単位よりも大きい単位で表された値は許可されません。
-
下限
プロパティにより許可された最小期間を指定します。
-
上限(オプション)
プロパティにより許可された最大期間を指定します。
-
無制限の期間
無制限の期間を指定できるプロパティもあります。-1にデコードされた値またはエンコードされた文字列値
unlimited
を使用して表されます。
A.4.5 E
A.4.5.1 エントリ
エントリは、ディレクトリ・サーバーで情報を保持する構造体です。次のコンポーネントから構成されています:
-
サーバーのその他すべてのエントリから、該当のエントリを一意に識別する識別名。
-
エントリのコンテンツ制御に使用されるオブジェクト・クラス値の集合。
-
エントリの実データを含む属性の集合。
エントリには、エントリのタイプを定義する構造オブジェクト・クラスが常に1つ必要です。エントリのその他の特性を識別するために使用できる補助オブジェクト・クラスを0個以上保有する場合があります。構造クラスと補助クラスがともに、エントリ内に存在する必要のある必須の属性のセット、およびエントリ内に含めることができるが必須ではないオプション属性を定義します。
A.4.5.2 エントリ・キャッシュ
エントリ・キャッシュはエントリの保持にシステム・メモリーを使用するメカニズムで、エントリを必要とする際は常に、データベースからデコードする必要なく迅速にエントリにアクセスできるようにする方法です。エントリ・キャッシュ・メカニズムは、連続した操作で同じエントリに複数回アクセスするアプリケーションとともに使用すると特に効果的です。たとえば、最初にユーザー・エントリを検出する検索操作、次にそのユーザーがパスワードを検証するためのバインド操作というアプリケーションは、きわめて一般的な使用のパターンです。
エントリ・キャッシュは、サーバーのデータベース・キャッシュのかわりに、またはこれに加えて使用できます。通常、データベース・キャッシュは簡潔なデータ表現を使用しますが、エントリ・キャッシュはサーバーで効率的に使用できる形式でデータを保持します。
基礎となるデータベースにより維持されるデータベース・キャッシュとは異なり、エントリ・キャッシュはディレクトリ・サーバー自体に管理されます。使用可能な様々なエントリ・キャッシュの実装がいくつかあります。
A.4.5.3 エントリ変更通知制御
エントリ変更通知制御は、永続検索制御を使用する検索操作に対するレスポンス内で、クライアントに返される検索結果エントリに含まれる制御です。この制御には、実行された変更のタイプ、変更番号(サーバーが変更ログをサポートする場合は、サーバーの変更ログのアイテムに対応)、およびエントリの名前が変更された場合は変更前のエントリの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 }
A.4.5.5 エントリID
エントリIDは、ディレクトリ・サーバー・バックエンド内のエントリを一意に識別するために使用される整数値です。エントリの識別名はこの用途に使用できますが、数値のエントリIDはより簡潔で効率的なデコードが可能なため、幅広い用途により適しています。
エントリIDは、id2entryデータベースの実際のエントリ・データに対するキーとして使用され、関連付けられた索引キーと一致するエントリを識別するIDリストで使用されます。
A.4.5.6 エントリUUID
エントリUUIDは、entryUUID
操作属性に含まれる全体で一意となる識別子で、ディレクトリ・サーバーの各エントリに割り当てられます。RFC 4530 (http://www.ietf.org/rfc/rfc4530.txt
)で説明されており、エントリが存続する間は変更されない一意の識別子を意図しています(DN変更操作の結果として変更可能な識別名とは対照的です)。エントリUUIDは十分に安定しているため、DNが変更された場合でも、エントリを追跡するレプリケーション・サブシステムで使用されます。
A.4.5.8 等価検索フィルタ
等価検索フィルタはLDAP検索フィルタのタイプで、指定された属性の固有の値を含むエントリの識別に使用できます。サーバーは、等価一致ルールを使用して判断します。
LDAP等価フィルタの文字列表現は、左カッコに続く属性名、等号、属性値および右カッコで構成されます。たとえば、等価フィルタの(uid=john.doe)
は、john.doe
の値を含むuid
属性のエントリと一致します。
A.4.5.9 エラー・ログ
エラー・ログは、エラー、警告およびその他サーバーの使用期間に発生する重大なイベントをレポートするメカニズムを提供します。エラー・ログに書き込まれる各メッセージには、(メッセージが生成されたサーバーの領域を示す)カテゴリ、(メッセージの相対的な重要性を示す)重大度および関連付けられるメッセージ文字列を一意に識別する整数値が含まれます。
A.4.5.11 拡張操作
LDAP拡張操作は、コア・プロトコル仕様で定義されていないリクエスト操作をクライアントに許可することにより、LDAPプロトコルに対する拡張度を提供します。LDAP拡張操作の例を次に示します:
- 取消し拡張操作
-
この操作は、以前にリクエストされた操作の取消しに使用できます。
- パスワード変更拡張操作
-
この操作は、ユーザー・パスワードの変更に使用できます。
- StartTLS拡張操作
-
この操作は、既存の接続上での保護された通信チャネルの開始に使用できます。
- Who Am I拡張操作
-
この操作は、クライアント接続に関連付けられる認可アイデンティティの判断に使用できます。
拡張リクエストのプロトコル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。
-
レスポンスに含まれる追加情報を含むオプションのエンコードされた値。
A.4.5.13 拡張可能な一致検索フィルタ
拡張可能な一致検索フィルタはLDAP検索フィルタのタイプで、指定された一致ルールを使用して一致したエントリの識別に使用できます。
拡張可能な一致フィルタには次のコンポーネントがあります:
-
判断に使用する一致ルールのOID。これはオプション要素で、指定されない場合は属性タイプの指定が必要となり、属性タイプのデフォルトの等価一致ルールが使用されます。
-
ターゲット設定される属性タイプの名前。指定されない場合は、エントリに含まれるすべての属性が調べられます。
-
エントリの識別名の属性およびエントリに含まれる属性に対して一致が実行されるかどうかを示すフラグ。
-
一致ルール用のターゲットとして使用されるアサーション値。
LDAP拡張可能な一致フィルタの文字列表現は、次のコンポーネントで順に構成されています:
-
左カッコ
-
属性タイプの名前または指定されなかった場合は空の文字列
-
dnAttributes
フラグが設定されている場合は文字列:dn
、または設定がない場合は空の文字列 -
一致ルールIDが使用可能な場合はコロンとそれに続くOIDで構成される文字列、または一致ルールIDがない場合は空の文字列
-
文字列
:=
-
アサーション値の文字列表現
-
右カッコ
A.4.5.14 EXTERNAL SASLメカニズム
EXTERNAL Simple Authentication and Security Layerメカニズムは、LDAPプロトコル・レベルで実行される通信の外部で使用可能な情報を使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。EXTERNAL認証(現在、ディレクトリ・サーバーがサポートする唯一の形式)の最も一般的な使用方法は、Secure Sockets LayerまたはTLS起動拡張操作のネゴシエーションの間にクライアントが提示した証明書に基づく、サーバーでのクライアントの識別です。ディレクトリ・サーバーは、証明書マッパーを使用してクライアントの証明書をディレクトリのユーザーにマッピングし、オプションで追加検証を実行する場合があります(たとえば、提示された証明書がユーザーのエントリに実際に存在していることを確認します)。
A.4.6 F
A.4.6.1 フェイルオーバー・アルゴリズム
すべてのクライアントのリクエストをメイン・リモートLDAPデータ・ソースに送信するロード・バランシング・アルゴリズム。メイン・リモートLDAPが停止する場合は、リクエストはセカンダリ・リモートLDAPサーバーなどに転送されます。このように、1つ以上のリモートLDAPサーバーの障害後、サービスの継続を保証します。
A.4.7 G
A.4.7.1 一般的な時刻
一般的な時刻は、タイムスタンプおよびタイムゾーン情報の表現に使用できる形式です。一般的な時刻の値には、次のコンポーネントがあります:
-
年を表す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
です。
A.4.7.2 実効権限取得制御
実効権限取得制御は、指定されたエントリと相互に作用する際に、指定されたユーザーが保有する権限を判断するために使用できる制御のタイプです。この制御のオブジェクト識別子は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.
検索リクエストでこの制御を使用する例は、「実効権限取得制御を使用した検索」を参照してください。
A.4.7.3 グローバル索引
プロキシ・デプロイメントで、グローバル索引はデータ・エントリをデータが保管されている分散パーティションにマッピングします。グローバル索引は特定の属性(telephonenumber
など)をマッピングします。たとえば、グローバル索引はtelephonenumber=5551212
を分散パーティション1に、telephonenumber=4441212
をパーティション2にマッピングできます。
A.4.7.4 グローバル索引カタログ
グローバル索引カタログには、1つ以上のグローバル索引が含まれます。属性の値にはエントリが保持されるパーティションにマッピングされるものもあるため、グローバル索引カタログを分散デプロイメントとともに使用し、ブロードキャストの必要性を減らすことができます。
A.4.7.5 大きいか等しい検索フィルタ
大きいか等しい検索フィルタは、指定されたアサーション値以上の、指定された属性の特定の値を含むエントリの識別に使用できるLDAP検索フィルタのタイプです。サーバーでは、順序付け一致ルールを判断に使用します。
LDAP大きいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、大なり記号、等号、アサーション値および右カッコで構成されます。たとえば、大きいか等しいフィルタの(createTimestamp>=20070101000000Z)
は、20070101000000Z
以上のcreateTimestamp
値を保有するエントリと一致します。
A.4.7.7 GSSAPI SASLメカニズム
GSSAPI Simple Authentication and Security Layerメカニズムは、Kerberos V5セッションを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。Kerberosは通常シングル・サインオン用途に使用されるプロトコルで、クライアントとサーバーの間の通信を保護するための完全性または機密性、あるいはその両方を使用するオプションを提供します(現在、ディレクトリ・サーバーではネットワーク・コンテンツ保護用のGSSAPIをサポートしていませんが、クライアントの認証の場合のみサポートします)。
RFC 4752 (http://www.ietf.org/rfc/rfc4752.txt
)にGSSAPI SASLメカニズムについて記載されています。
A.4.8 I
A.4.8.3 アイデンティティ・マッパー
アイデンティティ・マッパーは、認証IDまたは認可IDの値を対応するユーザー・エントリにマッピングするために使用できるロジックを提供します。アイデンティティ・マッパーは、いくつかのSimple Authentication and Security Layerメカニズム、プロキシ認可制御およびパスワード変更拡張操作とともに使用されます。
A.4.8.4 アイドル・アカウント・ロックアウト
アイドル・アカウント・ロックアウトは、ディレクトリ・サーバー・パスワード・ポリシーの一部で、長期間使用されないままになっているユーザー・アカウントのロックに使用できます。ユーザー認証時刻が記録されるように最終ログイン時刻機能の有効化が必要で、指定された期間内に認証されなかったユーザーによるいずれのバインド操作も拒否します。
長期間アイドルのままであったためにユーザーのアカウントがロックされた場合は、管理者のパスワードのリセットによりロック解除できます。
A.4.8.5 インコア再起動
インコア再起動は、サーバーの実行に使用されるJVMが実在しない状態でサーバーの再起動を可能にするプロセスです。JVM引数の変更を必要としない、サーバー再起動の必要な変更を適用するために使用できます。インコア再起動は、サーバー・プロセスを停止して再起動するよりも迅速で、JVM内で実行される処理の確認を蓄積したJITキャッシュを維持するという別の利点もあります。
A.4.8.6 索引
索引はディレクトリ・サーバー・データベースで使用されるメカニズムで、検索基準に一致するエントリの効率的な検出に使用できます。索引は、索引キーと一致するエントリのエントリIDのセットであるIDリストにキーをマッピングします。
ディレクトリ・サーバーは、次の6つの主要な索引のタイプを使用します:
A.4.8.9 Internet Draft
Internet Draftは、IETF (http://www.ietf.org/
)を介して定義される仕様の形式です。Internet draftは、通常複数の改訂を経る一時的な仕様で、改訂の間に大幅に変更される場合があります。Internet Draftが安定するとrequest for commentsに昇格します。それ以外のdraftは、サーバーで実装する価値のある、存続可能な機能が記述されている場合もありますが、進展はなく、その後維持されなくなります。
A.4.9 J
A.4.9.1 Java Management Extensions
Java Management Extensions (JMX)は、監査情報および構成情報へのアクセスに使用できるJavaテクノロジのフレームワークです。
Oracle Unified Directoryでは、モニター・エントリからの情報を公開するためにJMXを使用します。サーバーで重大な問題またはイベントが発生した場合の管理アラートにもJMX通知メカニズムを使用します。
A.4.10 K
A.4.10.1 キー・マネージャ・プロバイダ
キー・マネージャ・プロバイダは、サーバー証明書の秘密キー情報へのアクセスを提供できるサーバーのコンポーネントです。
サーバーで使用可能なキー・マネージャ・プロバイダには次のものがあります:
-
JKSキーストアでキー情報にアクセスするためのメカニズム
-
PKCS#12ファイルでキー情報にアクセスするためのメカニズム
-
PKCS#11トークンでキー情報にアクセスするためのメカニズム
A.4.11 L
A.4.11.1 最終ログイン時刻
ディレクトリ・サーバーの最終ログイン時刻機能は、バインド操作を使用してサーバーへの認証をユーザーが最後に実行した時刻を記録するために使用できるメカニズムです。最終ログイン時刻は、ユーザー定義のフォーマットにより、指定された属性に書き込むことができます。
多くのサーバーで、お薦めする最終ログイン時刻フォーマットの定義では、日付のみで時刻は含めないことに注意してください。このフォーマットを使用すると値の更新が1日に一度となり、1日に何度も認証するユーザーは、パフォーマンスへの影響の可能性を削減できます。
最終ログイン時刻は情報提供を目的に維持できますが、アイドル・アカウント・ロックアウト機能の有効化にも使用できます。
A.4.11.2 最終変更プラグイン
最終変更プラグインは、追加操作の一部としてエントリにcreatorsName
属性およびcreateTimestamp
属性を追加するため、あるいは変更操作またはDN変更操作の一部としてエントリのmodifiersName
属性およびmodifyTimestamp
属性を更新するために使用できる操作前アイドル・アカウント・ロックアウトです。
A.4.11.3 LDAPアサーション制御
LDAPアサーション制御は、ターゲット・エントリが指定されたアサーション・フィルタと一致する場合にのみ操作を実行するために使用できる制御のタイプです。比較操作、削除操作、変更操作、DN変更操作および検索操作とともに使用できます。
RFC 4528 (http://www.ietf.org/rfc/rfc4528.txt
)にLDAPアサーション制御について記載されており、OIDは1.3.6.1.1.12
です。制御の値は、LDAPのLDAP検索フィルタとしてエンコードされます。
検索リクエストでこの制御を使用する例は、「LDAPアサーション制御を使用した検索」を参照してください。
A.4.11.4 ldapcompareコマンド
ldapcompareコマンドは、LDAP比較操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapcompare」を参照してください。
A.4.11.5 LDAPデータ変換形式
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
A.4.11.6 ldapdeleteコマンド
ldapdeleteコマンドは、LDAP削除操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapdelete」を参照してください。
A.4.11.7 LDAP falseフィルタ
LDAP falseフィルタは特別なタイプのOR検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP falseフィルタと呼ばれるのは、常にfalse
と評価され、いずれのエントリとも一致しないためです。
LDAP trueフィルタの文字列表現は、(|)
です。LDAP falseフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt
)で説明されています。
A.4.11.8 LDAP中間レスポンス
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 }
現在ディレクトリ・サーバーでは、中間レスポンス・メッセージを使用する操作をサポートしていません。
A.4.11.9 LDAPメッセージ
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メッセージには次の要素があります:
A.4.11.10 LDAP DN変更操作
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}
A.4.11.11 LDAP変更操作
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
A.4.11.13 LDAP no-op制御
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
A.4.11.14 LDAP読込み後制御
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
A.4.11.15 LDAP読込み前制御
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
A.4.11.16 LDAP結果
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要素がレスポンスに対して適切でなければ、空のDNの場合があります。
- 診断メッセージ
-
処理の結果についての追加情報を提供する判読可能なメッセージ。通常、エラー・メッセージに使用されますが、正常な操作で表示される場合もあります。メッセージがなければ、空の文字列の場合があります。
- リフェラル
-
クライアントが操作を試行できる他のサーバーのLDAP URLのセット。リフェラルがなければ、この要素は欠落する場合があります。
A.4.11.17 LDAPS
LDAPSは、Secure Sockets Layer上のLightweight Directory Access Protocol通信を指すために使用される用語です。
A.4.11.18 LDAP検索フィルタ
検索フィルタは、LDAP検索操作で、一致するエントリの定義のための基準を定義するメカニズムを提供します。LDAPで定義される検索フィルタには、次の10種類のタイプがあります:
- AND検索フィルタ
-
0個以上の検索フィルタ要素を保持するコンテナとして機能します。ANDフィルタに含まれるすべての検索フィルタは、一致するANDフィルタのターゲット・エントリと一致する必要があります。
- OR検索フィルタ
-
0個以上の検索フィルタ要素を保持するコンテナとして機能します。ORフィルタに含まれる少なくとも1つの検索フィルタは、一致するORフィルタのターゲット・エントリと一致する必要があります。
- NOT検索フィルタ
-
1つの検索フィルタ要素のコンテナとして機能します。埋込みフィルタは、一致するNOTフィルタのターゲット・エントリとは一致しません。
- 等価検索フィルタ
-
指定された属性に対して指定された値を含むエントリを識別するためのメカニズムを提供します。
- 部分文字列検索フィルタ
-
指定された部分文字列と一致する属性値を含むエントリを識別するためのメカニズムを提供します。
- 大きいか等しい検索フィルタ
-
指定された値以上の属性値を含むエントリを識別するためのメカニズムを提供します。
- 小さいか等しい検索フィルタ
-
指定された値以下の属性値を含むエントリを識別するためのメカニズムを提供します。
- プレゼンス検索フィルタ
-
指定された属性に少なくとも1つの値を含むエントリを識別するためのメカニズムを提供します。
- 近似検索フィルタ
-
指定された値におおよそ等しい属性値を含むエントリを識別するためのメカニズムを提供します。
- 拡張可能な一致検索フィルタ
-
拡張可能なメカニズムを使用して、一致するエントリを識別するために一致ルールを使用するメカニズムを提供します。
LDAP検索フィルタおよび検索フィルタを文字列として表現するメカニズムの詳細は、RFC 4515 (http://www.ietf.org/rfc/rfc4515.txt
)を参照してください。
A.4.11.19 ldapsearchコマンド
ldapsearch
コマンドは、LDAP検索操作のリクエストに使用できます。
このコマンドの使用方法の詳細は、「ldapsearch」を参照してください。
A.4.11.20 LDAP trueフィルタ
LDAP trueフィルタは特別なタイプのAND検索フィルタで、埋込みフィルタ・コンポーネントを含みません。LDAP trueフィルタと呼ばれるのは、常にtrue
と評価され、エントリのいずれかと一致するためです。
LDAP trueフィルタの文字列表現は、(&)
です。LDAP trueフィルタは、RFC 4526 (http://www.ietf.org/rfc/rfc4526.txt
)で説明されています。
A.4.11.21 LDAPサブエントリ
LDAPサブエントリは、ldapSubEntry
オブジェクト・クラスを含むエントリのタイプです。これらのエントリでは、サーバー用の操作データを保持することを意味します。OIDが1.3.6.1.4.1.7628.5.101.1で値のないリクエスト制御を含めて明示的にリクエストしない場合は、クライアントに返されないという点で操作属性に似ています。この動作はdraft-ietf-ldup-subentryで説明されています。
検索でこの制御を使用する例は、「LDAPサブエントリ制御を使用した検索」を参照してください。
A.4.11.22 LDAP URL
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)
です。
A.4.11.23 LDIFエクスポート
LDIFエクスポート操作は、ディレクトリ・サーバー・バックエンドのコンテンツのすべてまたは一部をLDAPデータ変換形式を使用してファイルに書き込む処理です。LDIFエクスポートは、export-ldifコマンドまたはLDIFエクスポート・タスクを使用して開始できます。
A.4.11.24 LDIFインポート
LDIFインポート操作は、LDAPデータ変換形式の情報を保有するファイルからディレクトリ・サーバー・バックエンドへデータを追加する処理です。LDIFインポートは、LDAP追加操作よりもきわめて効率的にサーバーへ大量のエントリを追加する方法を提供します。
LDIFインポート操作は、import-ldifコマンドまたはLDIFインポート・タスクを使用して開始できます。
A.4.11.26 小さいか等しい検索フィルタ
小さいか等しい検索フィルタはLDAP検索フィルタのタイプで、指定されたアサーション値以下の、指定された属性の特定の値を含むエントリの識別に使用できます。サーバーは、順序付け一致ルールを判断に使用します。
LDAP小さいか等しい検索フィルタの文字列表現は、左カッコに続く属性名、小なり記号、等号、アサーション値および右カッコで構成されます。たとえば、小さいか等しいフィルタの(createTimestamp<=20070101000000Z)
は、20070101000000Z
以下のcreateTimestamp
値を保有するエントリと一致します。
A.4.11.27 辞書編集アルゴリズム
プロキシ分散アルゴリズム。アルファベットの範囲設定に基づいてデータをパーティションに分割します。たとえば、[A-E[が1つのパーティションで、[E-H[が次のパーティションです。
A.4.11.28 Lightweight Directory Access Protocol
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プロトコルに対する拡張として実装されるカスタム処理を実行する方法を提供
- 変更操作
-
サーバー内のエントリのコンテンツを変更する方法を提供
- DN変更操作
-
サーバー内のエントリの名前を変更する方法を提供
- 検索操作
-
指定された基準のセットに一致するすべてのエントリを識別する方法を提供
- アンバインド操作
-
サーバーから切断するクライアントを示す方法を提供
A.4.11.29 ロード・バランシング
ロード・バランシングはプロキシ・デプロイメントのタイプで、レプリケートされたリモートLDAPサーバーのセットへのシングル・アクセスを提供します。クライアントのリクエストの送信先であるリモートLDAPサーバーの選択は、ロード・バランシング・アルゴリズムにより決定されます。
A.4.11.30 検索制限
検索制限は、ディレクトリ・サーバー内の構成オプションで、検索操作処理の進行中にサーバーが調べるエントリ数の制限を実施するために使用できます。この制限は、指定された検索基準に一致するかどうかにかかわらず、サーバーが調べるすべてのエントリに適用されます。
検索制限の構成属性は、索引なし検索またはきわめて大きな候補リストを伴う検索の影響を制限するために使用できます。
検索制限の構成の詳細は「ユーザー・アカウントへのリソース制限の割当て」および「ルート・ユーザーのリソース制限の設定」を参照してください。
A.4.12 M
A.4.12.1 MakeLDIFコマンド
MakeLDIFコマンドは、LDAPデータ変換形式でエントリを生成するメカニズムを提供します。エントリは、データを生成する方法の制御に使用できるいくつかのタグを含む、テンプレートに基づいて生成されます。
このコマンドの使用方法の詳細は、「make-ldif」を参照してください。「MakeLDIFテンプレート・ファイルの作成について」では、MakeLDIFテンプレート・ファイルの有効な構造およびコンテンツについて説明します。
A.4.12.2 Manage DSA IT制御
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の管理制御を使用した検索」を参照してください。
A.4.12.3 一致したDN
一致したDNは、LDAP結果オブジェクトの要素で、サーバーで見つかった最も近い一致するエントリの追加情報を提供できます。通常、リクエストがターゲット設定したエントリが存在しない場合に使用され、この場合は、一致したDNには、サーバーに存在しており指定されたエントリに最も近い祖先であるエントリの識別名が含まれます。たとえばある操作が存在しないエントリのuid=doesnt.exist,ou=People,dc=example,dc=com
をターゲット設定し、エントリのou=People,dc=example,dc=com
がサーバーに存在する場合は、これが一致したDNとして返されます。
存在しないエントリをターゲット設定した操作から一致したDNが返される保証はなく、この場合は、LDAP結果の一致したDN要素は空の文字列です。たとえば、サーバー内でその他のエントリとの階層関係を持たないエントリに、リクエストがターゲット設定した場合に使用できます。
A.4.12.4 一致値制御
一致値制御は、検索操作に追加して、クライアントに返されるエントリに、指定されたフィルタと一致する値のみを含む必要があることを示す制御のタイプです。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}
対応するレスポンス制御はありません。
検索リクエストでこの制御を使用する例は、「一致値フィルタ制御を使用した検索」を参照してください。
A.4.12.5 一致ルール
一致ルールは、サーバーが属性の値と相互に作用する方法を定義するスキーマ要素です。一致ルールには、次の3つの標準タイプがあります:
-
等価一致ルールは、1つの属性値が別の属性値に等しいかどうかを判断するために使用されます。通常、この判断は正規化された値に基づいて実行され、重要ではない相違(大文字と小文字の相違または余分な空白など)は無視されます。
-
順序付け一致ルールは、ソート済リストの2つの値の間の相対的な順序を判断するために使用されます。この判断はサーバー側ソート制御の実行の際に使用されますが、大きいか等しい検索フィルタおよび小さいか等しい検索フィルタのフィルタ・コンポーネントでも使用されます。
-
部分文字列一致ルールは、指定された部分文字列検索フィルタが値に含まれるかどうかの判断に使用されます。
これらの標準一致ルールに加えて、ディレクトリ・サーバーは4番目のタイプ、近似一致ルールを定義します。これは、ある値が別の値におおよそ等しいかどうかの判断に使用されます。おおよそ等しいという定義には幅がありますが、一般的に使用される定義では、類似する、ということです。
一般的な一致ルールの例を次に示します:
-
booleanMatch
2つのブール値が互いに等しいかどうかを判断する等価一致ルール。
-
caseExactMatch
大文字と小文字の相違を無視せず、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。
-
caseExactOrderingMatch
大文字と小文字の相違を無視せず、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。
-
caseExactSubstringsMatch
大文字と小文字の相違を無視せず、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。
-
caseIgnoreMatch
大文字と小文字の相違を無視して、2つの文字列値が互いに等しいかどうかを判断する等価一致ルール。
-
caseIgnoreOrderingMatch
大文字と小文字の相違を無視して、2つの文字列値の間で相対的な順序を判断するために使用される順序付け一致ルール。
-
caseIgnoreSubstringsMatch
大文字と小文字の相違を無視して、指定された部分文字列が文字列値に含まれるかどうかの判断に使用される部分文字列一致ルール。
-
distinguishedNameMatch
RDNコンポーネントを区切るカンマの前後の余分な空白、およびRDN名と値を区切る等号を無視して、2つの識別名が互いに等しいかどうかを判断する等価一致ルール。個別のRDN値は、対応するRDN属性に関連付けられる一致ルールに基づいて比較されます。
-
generalizedTimeMatch
2つの一般的な時刻値が互いに等しいかどうかを判断する等価一致ルール。
-
generalizedTimeOrderingMatch
2つの一般的な時刻値の間で相対的な順序を判断するために使用される順序付け一致ルール。
-
integerMatch
2つの整数値が互いに等しいかどうかを判断する等価一致ルール。
-
integerOrderingMatch
2つの整数値の間で相対的な順序を判断するために使用される順序付け一致ルール。
-
octetStringMatch
2つの値が互いに等しいかどうかをバイト対バイト比較で判断する等価一致ルール。
多くの場合、ディレクトリ・サーバーは、クライアントが認識する必要のない、完全に暗黙的な方法で一致ルールを使用します。クライアントが指定された属性タイプを参照する際は常に、サーバーはその属性に対する適切な一致ルールを自動的に認識して使用します。ただし、拡張可能な一致検索フィルタを使用して操作を実行する際に、サーバーが特定の一致ルールを使用するように、クライアントがリクエストすることも可能です。
サーバーで定義される一致ルールのセットは、サブスキーマ・サブエントリのmatchingRules
属性を取得して確認できます。一致ルールの詳細は、「一致ルールの概要」を参照してください。
A.4.12.6 一致ルールの使用
一致ルールの使用はスキーマ要素で、指定された一致ルールとともに使用可能な属性タイプを判断するために使用できます。拡張可能な一致検索フィルタを使用する場合にのみ適用されることに注意してください。
一致ルールの使用の定義には、適用する一致ルールのオブジェクト識別子、および一致ルールとともに使用できる属性タイプの名前またはOIDのリストが含まれます。属性がこのリストに含まれない場合は、関連付けられた一致ルールとともに使用できません。指定された一致ルールに対して定義される一致ルールの使用がない場合は、その一致ルールは任意の属性タイプとともに使用できるとみなされます。
サーバーで定義される一致ルールの使用のセットは、サブスキーマ・サブエントリのmatchingRuleUse
属性を取得して確認できます。一致ルールの使用の詳細は、「一致ルールの使用の理解」を参照してください。
A.4.12.7 MD5
MD5は、RFC 1321 (http://www.ietf.org/rfc/rfc1321.txt
)で定義される一方向メッセージ・ダイジェスト・アルゴリズムです。任意の長さの値を128ビット値にエンコードして、元のクリアテキストに戻して特定できないようにするために使用できます。通常、データのチェックサム用のメカニズムとして使用され、パスワードやその他機密情報のエンコードにも使用されます。
最近の暗号化技術の進歩により、MD5アルゴリズムの脆弱性が見つかっていることに注意してください。これらの発見は、ディレクトリ・サーバーによるMD5アルゴリズムの使用方法のセキュリティに直接は影響しませんが、セキュア・ハッシュ・アルゴリズムなどのより厳格なメカニズムを使用することをお薦めします。
A.4.12.9 メッセージID
メッセージIDは、メッセージに含まれる整数値で、リクエスト・メッセージとレスポンス・メッセージの関連付けに使用されます。クライアントはリクエスト・メッセージに含めるメッセージID値を選択し、サーバーはすべてのレスポンス・メッセージで同じメッセージIDを使用します。これによりクライアントは、いつでも同じ接続上で複数のリクエストを進行させることができます。すべての進行中のリクエストは常に、異なるメッセージIDを保有する必要があります。通常、クライアントはすべてのリクエスト・メッセージを対象にカウンタを順に増分し続けており、各リクエストは前回のリクエストとは異なるメッセージIDを取得します。
未承諾通知メッセージは、常にメッセージID値が0であることに注意してください。その他のすべてのLDAPメッセージのメッセージID値は、1から2147483647の間です。
A.4.12.11 変更タイプ
変更タイプは、変更が実行された属性値を属性が保有できるようにする4つの方法のうちの1つを説明します。定義された変更タイプは次のとおりです:
-
add
1つ以上の値がターゲット属性に追加されます。属性がターゲット・エントリに存在しない場合は、指定された値が追加されます。そうでない場合は、指定された値は、その属性に対してすでに定義された値のセットに追加されます。追加変更タイプは常に少なくとも1つの値を指定する必要があります。
-
delete
1つ以上の値がターゲット属性から削除されるか、その属性全体がターゲット・エントリから削除されます。1つ以上の特定の値が指定される場合は、それらの値のみがターゲット属性から削除されます(指定される値がその属性の値のセット全体を表す場合は、その属性がエントリから削除されます)。値が指定されない場合は、(含まれる値の数にかかわらず)属性全体がエントリから削除されます。
-
replace
ターゲット属性の値のセットを指定された値のセットで置換します。置換は0個以上の値を保有し、その動作は次のとおりです:
-
エントリのターゲット属性に1つ以上の値が存在し、置換変更に値が含まれない場合は、ターゲット属性はエントリから削除されます。
-
エントリのターゲット属性に1つ以上の値が存在し、置換変更に1つ以上の値が含まれる場合は、既存の値のセットは新しい値のセットに置換されます。
-
エントリにターゲット属性が存在せず、置換変更に値が含まれない場合は、アクションは発生しません。
-
エントリにターゲット属性が存在せず、置換変更に1つ以上の値が含まれる場合は、指定された値のセットを保有する属性がエントリに作成されます。
-
-
increment
ターゲット属性の値が指定された量により増分されます。ターゲット属性は1つの値のみを保有してエントリに存在し、その値は整数である必要があります。増分変更も1つの値のみを含み、その値は整数である必要があります。既存の値が増分値で指定された量により増分されます。増分値が負数の場合は、既存の値から、増分値の絶対値に等しい量が減じられます。
A.4.12.14 モニター・エントリ
モニター・エントリは、サーバー・コンポーネントの情報を提供するサーバーのエントリのタイプです。モニタリングの実施に関する統計情報、サーバーのヘルスの情報または値などその他の情報を提供できます。
ディレクトリ・サーバーは、汎用モニター・エントリに識別名のcn=monitor
を指定します。その他多くの次のようなモニター・エントリがその下に存在します:
A.4.13 N
A.4.13.1 名前書式
名前書式はスキーマ要素で、どの属性タイプを構造オブジェクト・クラスに基づいたエントリの相対識別名で使用するかを制御するために使用できます。
名前書式の定義には次のコンポーネントがあります:
-
名前書式を一意に識別するために使用されるオブジェクト識別子。
-
名前書式の参照をより容易にするために使用可能な0個以上の名前のセット。
-
名前書式が関連付けられる構造オブジェクト・クラスの名前またはOID。構造クラスを持つエントリは、名前書式の要件に準拠したRDNを保有する必要があります。
-
関連付けられた構造クラスを含むエントリのRDNに存在する必要のある属性の、属性タイプ名またはOIDの1つ以上のセット。
-
関連付けられた構造クラスを含むエントリのRDNにオプションで存在する場合のある属性の、1つ以上の属性タイプ名またはOIDのオプション・セット。
サーバーで定義される名前書式のセットは、サブスキーマ・サブエントリのnameForms
属性を取得して確認できます。名前書式の詳細は、「名前書式の理解」を参照してください。
A.4.13.2 ネーミング・コンテキスト
ネーミング・コンテキストは接尾辞とも呼ばれ、サーバーのディレクトリ情報ツリー(DIT)で最上位のエントリです。このエントリには親はありません。
サーバーで定義されるネーミング・コンテキストのセットは、ルートDSEのnamingContexts
属性にリストされます。ネーミング・コンテキストは、ワークフローを介して参照可能です。
A.4.13.3 ネットワーク・グループ
ネットワーク・グループには、クライアント接続のカテゴリを定義する基準のセットが含まれています。サーバーに送信されたクライアント・リクエストがネットワーク・グループにアタッチされたポリシーに適合している場合は、ネットワーク・グループはそのリクエストをワークフローに転送します。
A.4.13.5 正規化された値
正規化された値は、他の値と効率的に比較できるようにする方法で処理された値です。正規化処理は、一致ルールを使用して実行され、一致ルールのタイプに基づいて変わります。実行できる変換の種類には次のものがあります:
-
大文字と小文字の区別による重要ではない相違を排除するため、すべての文字を小文字(または大文字)に変換
-
値の不要な空白を排除
-
複数の表現を持つ値を共通の形式に変換
A.4.13.7 NOT検索フィルタ
NOT検索フィルタは、1つの埋込み検索フィルタを保持するコンテナとして機能するためのLDAP検索フィルタのタイプです。NOTフィルタは基本的に逆操作で、エントリがNOTフィルタと一致するには、埋込みフィルタとは一致しません。
NOTフィルタは、フィルタ全体をカッコで囲み、左カッコの直後に感嘆符を配置した文字列で表されます。たとえば、フィルタ(!(objectClass=person))
は、オブジェクト・クラス値がperson
ではないエントリのみ一致します。
A.4.13.8 数値アルゴリズム
数値の範囲設定に基づいてデータをパーティションに分割するプロキシ分散アルゴリズム。たとえば、[1-1000[が1つのパーティションで、[1000-2000[が次のパーティションです。
A.4.14 O
A.4.14.1 オブジェクト・クラス
オブジェクト・クラスはスキーマ要素で、オブジェクト識別子および名前のセットを、必須およびオプションの属性タイプのセットと関連付けます。
オブジェクト・クラスのコンポーネントの定義には次のものがあります:
-
オブジェクト・クラスを一意に識別するために使用されるOID。
-
オブジェクト・クラスの参照をより容易にするために使用できる0個以上の名前のセット。
-
オプションの上位クラス。必須およびオプションの属性タイプを定義できます。
-
オプションのオブジェクト・クラス・タイプ値。オブジェクト・クラスが構造オブジェクト・クラス、補助オブジェクト・クラスまたは抽象オブジェクト・クラスのいずれであるかを示します。
-
属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリに存在する必要があります。
-
属性の1つ以上の属性タイプ名またはOIDのオプション・セット。属性は、オブジェクト・クラスに含まれるエントリにオプションで存在する場合があります。
各エントリに1つの構造オブジェクト・クラスを必要とし、0個以上の補助クラスが存在する場合もあります。エントリのオブジェクト・クラスの一連のセットは、必須または存在できる属性タイプのセットを定義します。構造クラスを使用して、エントリと次のいずれか(1つ以上)とをリンクすることもできます。
サーバーで定義されたオブジェクト・クラスのセットは、サブスキーマ・サブエントリのobjectClasses
属性を取得して確認できます。オブジェクト・クラスの詳細は、「オブジェクト・クラスの理解」を参照してください。
A.4.14.2 オブジェクト・クラス・タイプ
オブジェクト・クラス・タイプは、オブジェクト・クラスのカテゴリの定義に使用されます。次の3つのオブジェクト・クラス・タイプ値があります:
-
構造オブジェクト・クラスは、エントリの主要なタイプの定義に使用されます。各エントリは構造クラスを1つ必要とし、構造クラスはエントリを説明するオブジェクトの主要なタイプを定義します。
-
補助オブジェクト・クラスは、エントリの特性の定義に使用されます。1つのエントリは、0個以上の補助クラスを保有できます。エントリが保有できる補助クラスのセットは、エントリの構造クラスに関連付けられたDITコンテンツ・ルールにより制御できます。
-
抽象オブジェクト・クラスは、エントリでは直接使用せず、構造オブジェクト・クラスまたは補助オブジェクト・クラスのサブクラスとする必要があります。
LDAPオブジェクト・クラスで使用される継承モデルは、Javaクラスの継承モデルとよく似ています。エントリに構造オブジェクト・クラスが1つのみ必要なように、Javaクラスにもスーパークラスが1つ必要です。同様に、エントリは複数の補助クラスを保有できますが、Javaクラスは複数のインタフェースを実装できます。最後に、抽象オブジェクト・クラスのみを含むエントリを作成できないように、抽象Javaクラスのインスタンス化はできません。
A.4.14.3 オブジェクト識別子
オブジェクト識別子(OID)は、ピリオドで区切られた一連の整数で構成される文字列です。ディレクトリ・サーバーでは、次のような様々な要素のタイプの一意の識別子として使用されます:
A.4.14.4 操作ID
操作IDは、クライアント接続で実行される各操作に割り当てられる整数の識別子です。主にロギングのために使用して、レスポンス・ログ・メッセージを対応するリクエスト・メッセージと関連付けることができます。
クライアント接続で最初に実行される操作には操作IDに0が割り当てられ、クライアント接続上で受信される各追加リクエストのために操作IDが1ずつ増分されます。
A.4.14.7 OR検索フィルタ
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フィルタはいずれのターゲット・エントリとも一致しません。
A.4.15 P
A.4.15.1 パーティション
プロキシ分散デプロイメントでは、データは、パーティションと呼ばれるより小さなデータ・チャンクに分割されます。通常、データのパーティションは、高可用性を保証するために、個別のリモートLDAPサーバーまたはレプリケートされたリモートLDAPサーバーのセットに保管されます。
A.4.15.2 パスワード
パスワードは、一部の認証メカニズムでアイデンティティの証明に使用できる非公開の値です。特に、パスワードは簡易認証、およびCRAM-MD5 SASLメカニズム、DIGEST-MD5 SASLメカニズム、PLAIN SASLメカニズムのSimple Authentication and Security Layerメカニズムで使用されます。
パスワードによるセキュリティは、パスワードの所有者のみがパスワードの内容を認識するという事実に完全に基づいています。別の者がなんらかの方法であるユーザーのパスワードを知ることがあれば、その第三者はユーザーを偽装し、ユーザーが使用可能な操作を実行できます。
ディレクトリ・サーバーにはパスワード・ポリシー機能があり、パスワードが第三者個人に知られないことを保証する支援に使用できますが(たとえば、脆弱なパスワードの使用をユーザーに許可しないことを保証する支援をしたり、総当たり攻撃から保護したり、保護された方法で実行される認証の試行およびパスワードの変更を要求したりします)、多くの場合、パスワードは証明書のような別の種類の識別よりも脆弱な保護の形式であるとみなされます。
A.4.15.3 パスワード有効期限
パスワード有効期限は、ディレクトリ・サーバー・パスワード・ポリシーの要素で、ユーザーが同じパスワードを継続して使用できる期間の長さを制限するために使用できます。パスワード有効期限が有効化されている場合は、ユーザーがパスワードを変更すると、最大パスワード経過時間として指定された期間、パスワードを使用できます。パスワード有効期限が近づくと、ユーザーはバインド・レスポンスの制御の形式で警告メッセージを受け取ることができます。パスワードの有効期限が切れると、それ以降、ユーザーは認証を許可されません。
ユーザーのパスワードの有効期間が切れると、アカウントを使用するには、管理者がパスワードのリセットを実行する必要があります。または、パスワード・ポリシーが適切に構成されている場合は、パスワード変更拡張操作を使用して、ユーザーが自分の有効期限の切れたパスワードを変更することもできます。
A.4.15.4 パスワード・ジェネレータ
パスワード・ジェネレータは、パスワード変更拡張操作の一部として、ユーザーのパスワードを生成するために使用できるロジックの部分です。パスワード変更リクエストに新しいパスワードが含まれていない場合に使用されます。
A.4.15.5 パスワード変更拡張操作
パスワード変更拡張操作は、ユーザーのパスワードの変更またはパスワードのリセットに使用できる拡張操作のタイプです。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 }
A.4.15.6 パスワード・ポリシー
ディレクトリ・サーバー・パスワード・ポリシーは、サーバーでのパスワードの保管と維持の方法、およびユーザーの認証を許可する方法を制御するメカニズムを提供します。
パスワード・ポリシーの要素には次のものがあります:
-
ユーザー・パスワードの保管に使用される属性。デフォルトでは、
userPassword
属性です。 -
サーバーで保管されたパスワードのエンコードに使用されるパスワード記憶スキームのデフォルトのセット。
-
非推奨パスワード記憶スキームのセット。ユーザーの認証に使用できますが、正常なバインド上のデフォルトのスキームを使用してパスワードを再エンコードします。
-
ユーザーが自分のパスワードを変更できるかどうかを示すフラグ。
-
パスワード有効期限に関連する多くの設定。最大パスワード経過期間、有効期限前の警告およびユーザーがパスワードの有効期限切れ後にパスワードを変更できるかどうかが含まれます。
-
アカウント・ロックアウトに関連する多くの設定。認証を試行して何度も失敗した後で、ユーザーの認証を妨げるために使用できます。
-
ユーザーの初めての認証時にパスワードの変更が必要かどうか、または管理者にリセットされた後でパスワードの変更が必要かどうか、あるいはその両方を示すフラグ。
-
パスワード・バリデータのセット。提案された新しいパスワードの値の使用が許可されるかどうかの判断に使用できます。
-
パスワードの変更を許可するために、現在のパスワードの入力をユーザーに要求するかどうかを示すフラグ。
-
新しいパスワードがサーバーで定義されるパスワード記憶スキームの1つを使用してすでにエンコードされている場合、そのパスワードの指定をクライアントに許可するかどうかを示すフラグ。事前にエンコードされたパスワードの許可が必要なアプリケーションもありますが、パスワード・バリデータのように、適用される可能性のある制限をユーザーがバイパスできる場合もあります。
-
最終ログイン時刻の維持に関する設定。値の保管に使用する属性、タイムスタンプで使用するフォーマットおよび認証なしで長時間経過したアカウントをロックするかどうかが含まれます。
-
保護された方法による認証をユーザーに要求するのかどうか、または保護された方法によるパスワードの変更をユーザーに要求するのかどうか、あるいはその両方を制御するフラグ。
A.4.15.7 パスワード・ポリシー制御
パスワード・ポリシー・リクエスト制御はLDAP制御のタイプで、ユーザー・エントリに対する現在のパスワード・ポリシーの状態についての情報をリクエストするために使用できます。これはdraft-sisbehera-ldap-password-policy (https://tools.ietf.org/html/draft-behera-ldap-password-policy-10
)に定義されています。リクエスト制御およびレスポンス制御の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 }
検索リクエストでこの制御を使用する例は、「パスワード・ポリシー制御を使用した検索」を参照してください。
A.4.15.8 パスワードのリセット
パスワードのリセットは、ユーザーのパスワードを変更するサーバー管理者の行為です。パスワードのリセットは、アカウントの保有者以外の任意のユーザーにより実行されるパスワードの変更です。
A.4.15.9 パスワード記憶スキーム
パスワード記憶スキームは、サーバーで保管されるユーザー・パスワードをエンコードするためのメカニズムを提供します。ユーザーが入力したパスワードが正しいかどうかをサーバーは判断できますが、多くの場合、パスワードは、クリアテキスト・パスワードの内容をユーザーに決定させない方法でエンコードされます。
ノート:
下位互換性を考慮して、MD5、RC4、SHA1などの古いまたは弱いハッシュ・アルゴリズムを次に示します。パスワード記憶域スキームの新しいまたは強力なアルゴリズムを使用することを強くお薦めします。現在使用可能なパスワード記憶スキームには次のものがあります:
-
3DES
パスワードはトリプルDESを使用してエンコードされます。トリプルDESは、データ暗号化規格(DES)のバリエーションで、以前のものよりも3倍時間がかかりますが、厳格な信頼性があります。このアルゴリズムでは、1つの長さ192ビットの組合せキーのために3つの64ビットのキーを使用します。データは、第一のキーで暗号化され、第二のキーで復号化され、さらに第三のキーで再度暗号化されます。3つのキーすべて、第一のキーと第二のキー、または第二のキーと第三のキーが同一でないことを確認する必要があります。
-
AES
Advanced Encryption Standardは、128 (AES-128)ビット、192 (AES-192)ビットおよび256 (AES-256)ビットの長さの暗号キーを使用して、128ビットのデータ・ブロックを処理できる、Rijndaelアルゴリズムに基づいた対称型ブロック暗号です。
-
BASE64
パスワードはbase64エンコーディングで、保護の形式はたいへん脆弱で、クライアントがこの記憶スキームを要求する場合にのみ使用されます。
-
BlowFish
パスワードはキーの長さが128ビットのBlowFishアルゴリズムを使用してエンコードされます。
-
CLEAR
パスワードは、不明瞭化されることなくクリア・テキストで格納されます。このスキームには、
{CLEAR}
という記憶スキーム名のユーザー・パスワード構文の実装のみが含まれます。したがって、まったく保護がないため、このスキームは、クライアントがこの記憶スキームを要求した場合にのみ使用されます。ただし、
ClearPassowrdScheme
構成パラメータを構成して、パスワードを戻す際にサーバーで中カッコ内のスキーム名を不明瞭化することができます。この構成パラメータは、クリア・テキスト・パスワード記憶スキームでスキーム名を不明瞭化するかどうかを指定します。サーバーでスキーム名を不明瞭化する場合は、不明瞭化フラグを
true
に構成できます。デフォルト値はfalse
です。 -
CRYPT
パスワードは暗号化アルゴリズムを使用してエンコードされます。暗号化アルゴリズムは、LinuxシステムおよびUNIXシステムでユーザー・パスワードのエンコードをサポートする一方向アルゴリズムです。
新しいモジュラ暗号化アルゴリズム(MD5、SHA256およびSHA512をサポート)は、UNIX暗号化アルゴリズムより安全です。UNIX暗号化アルゴリズムは現在の標準よりも脆弱であるとみなされているため、通常は、このパスワード記憶スキームを要求するユーザーにのみ使用する必要があります。ただし、既存のデプロイメントとの互換性を確保するため、UNIX暗号化アルゴリズムは、CRYPTパスワード記憶スキームのデフォルトのアルゴリズムです。
-
MD5
パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。saltハッシュをお薦めしますが、比較的安全で、セキュア・ハッシュ・アルゴリズムのバリアントはMD5よりも厳格であるとみなされます。
-
PBKDF2 HMAC SHA-1
パスワードは、キーハッシュ・メッセージ認証コード(HMAC) SHA-1とパスワード・ベース・キー導出関数2 (PBKDF2)を使用してエンコードされます。
-
PBKDF2 HMAC SHA-256
パスワードは、キーハッシュ・メッセージ認証コード(HMAC) SHA-256とパスワード・ベース・キー導出関数2 (PBKDF2)を使用してエンコードされます。
-
PBKDF2 HMAC SHA-512
パスワードは、キーハッシュ・メッセージ認証コード(HMAC) SHA-512とパスワード・ベース・キー導出関数2 (PBKDF2)を使用してエンコードされます。
ノート:
Oracle Unified Directory Serverでは、PBKF2 HMACSHAベースのパスワード記憶スキームにsaltの反復数およびバイト数のデフォルト値が使用されます。必要に応じて、PBKF2 HMACSHAベースのパスワード記憶スキームに使用されるsaltの反復数およびバイト数を更新するには、
dsconfig set-password-storage-scheme-prop --advanced
コマンドを使用します(プロパティ名:pbkdf2hmacsha-iteration-count
、pbkdf2hmacsha-num-salt-bytes
)。この構成ステップは慎重に実行する必要があります。Oracle Unified DirectoryインスタンスでいずれかのPBKDF2ベースのスキームが使用されており、これらのスキームのいずれかを使用する既存のユーザー・パスワードがある場合は、構成の更新後に古いパスワードの検証が失敗し、古いパスワードをリセットする必要があります。saltの反復数またはバイト数が更新された場合は、Oracle Unified Directory Serverを再起動する必要があります。
-
RC4
パスワードは、キーサイズが変更可能で、バイト単位で操作するストリーム暗号のRC4を使用してエンコードされます。このアルゴリズムは、ランダムな置換の使用に基づいています。
-
Salt MD5
パスワードはMD5メッセージ・ダイジェスト・アルゴリズムのSalt付きバージョンを使用してエンコードされます。
-
Salt SHA-1
パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSalt付きバージョンを使用してエンコードされます。これは、ディレクトリ・サーバーで使用されるデフォルトのパスワード記憶スキームです。
-
Salt SHA-256
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き256ビット・バージョンを使用してエンコードされます。
-
Salt SHA-384
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き384ビット・バージョンを使用してエンコードされます。
-
Salt SHA-512
パスワードはSHA-2セキュア・ハッシュ・アルゴリズムのSalt付き512ビット・バージョンを使用してエンコードされます。
-
SHA
パスワードはSHA-1セキュア・ハッシュ・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。このアルゴリズムではSalt付きのバリアントをお薦めします。
-
SHA-256
パスワードはSHA-256セキュア・ハッシュ・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。このアルゴリズムではSalt付きのバリアントをお薦めします。
-
SHA-512
パスワードはSHA-512セキュア・ハッシュ・アルゴリズムのSaltなしのバージョンを使用してエンコードされます。このアルゴリズムではSalt付きのバリアントをお薦めします。
- ユーザー定義
Oracle Unified Directory (OUD)のユーザー定義のパスワード記憶スキームは、カスタムのパスワード・ハッシング・スキームを実装してサーバーにデプロイする機能を提供します。カスタム・スキームを実装することで、OUDでパスワードを格納および管理する方法を制御できます。このフレームワークは、OUDで即時利用可能できないスキームを実装する機能を提供します。ユーザー定義のパスワード記憶スキームを使用するには、『Oracle Unified Directoryプラグインの開発』ガイドのOracle Unified Directoryでのユーザー定義のパスワード記憶スキームの構築およびデプロイに関する項を参照してください。
-
EUS PBKDF2 SHA-512
このパスワード記憶スキームは、Oracle RDBMS用に設計されたSHA-512ベースの固有のアルゴリズムを使用して、ユーザー・パスワードをエンコードするメカニズムを提供します。Oracle Database 12c (
Multi-Round SHA-512
)パスワード検証の生成に使用する同じアルゴリズムを使用して、パスワードがエンコードされます。
ディレクトリ・サーバーでは認証パスワード構文の使用もサポートしていることに注意してください。
A.4.15.10 パスワード・バリデータ
パスワード・バリデータはディレクトリ・サーバー・パスワード・ポリシーのコンポーネントで、提案されたパスワードの使用を許可できるかどうかを判断するために使用されます。ディレクトリ・サーバーはカスタム・パスワード・バリデータの開発のために拡張可能なAPIを提供しますが、次のようないくつかの異なるタイプのパスワード・バリデータが用意されています。
-
ユーザーのエントリに含まれる属性の値の中にパスワードの値が存在する場合は、パスワードを拒否するために使用できるバリデータ。
-
パスワードの値が許可された文字セットの範囲にある文字を含まない場合は、パスワードを拒否するために使用できるバリデータ。
-
パスワードが辞書に存在する言葉である場合は、拒否するために使用できるバリデータ。
-
パスワードが長すぎるか短すぎる場合は、拒否するために使用できるバリデータ。
-
パスワードが何度も繰り返される文字による文字列を含む場合は、拒否するために使用できるバリデータ。
-
パスワードがユーザーの現在のパスワードに酷似している場合は、拒否するために使用できるバリデータ。
-
パスワードが十分に一意となる文字を含まない場合は、拒否するために使用できるバリデータ。
A.4.15.11 永続検索制御
永続検索制御はLDAP制御のタイプで、関連付けられたLDAP検索操作の基準に一致するエントリに対する変更をクライアントに通知するために使用できます。永続検索制御はdraft-ietf-ldapext-psearch
に記述されており、2.16.840.1.113730.3.4.3というOIDが指定されています。次のように定義されます:
PersistentSearch ::= SEQUENCE { changeTypes INTEGER, changesOnly BOOLEAN, returnECs BOOLEAN }
この検索の一部として返される検索結果エントリは、オプションで、エントリが変更した方法を説明するエントリ変更通知制御を含む場合があります。検索でこの制御を使用する例は、「永続検索制御を使用した検索」を参照してください。
A.4.15.12 PLAIN SASLメカニズム
PLAIN Simple Authentication and Security Layerメカニズムは、ユーザー名およびパスワードを使用して、クライアントがディレクトリ・サーバーへの認証を行う方法を提供します。一般的に、識別名ではなくユーザー名でクライアントがクライアント自体を認証要求できることを除けば、簡易認証とよく似ています。別の認可IDを指定する機能もクライアントに提供します。
簡易認証と同様、PLAIN SASLメカニズムはユーザー・パスワードを保護する形式を提供しないため、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルの場合のみ、この認証方法の使用をお薦めします。
A.4.15.13 プラグイン
プラグインは、ディレクトリ・サーバーが処理を実行する過程に、カスタム・ロジックを挿入するために使用できるコードの部分です。ディレクトリ・サーバーは、次のような様々なタイプのプラグインをいくつかサポートします。
-
事前解析プラグイン。サーバーがリクエストの処理を開始する前に、リクエストのコンテンツを変更できるようにします。事前解析プラグインは、すべてのタイプの操作で使用可能です。
-
操作前プラグイン。操作の中心となる処理の前に、サーバーがいくつかのアクションを実行できるようにします。操作前プラグインは、中止操作およびアンバインド操作を除くすべてのタイプの操作で使用可能です。
-
操作後プラグイン。操作の中心となる処理の直後でレスポンスがクライアントに送信される前に、サーバーがいくつかのアクションを実行できるようにします(クライアントへのレスポンスの変更に使用される場合もあります)。操作後プラグインは、すべてのタイプの操作で使用可能です。
-
レスポンス後プラグイン。完了した操作のすべての処理の後で、サーバーがいくつかのアクションを実行できるようにします。レスポンス後プラグインは、中止およびアンバインドを除くすべてのタイプの操作で使用可能です。
-
検索結果参照プラグイン。検索操作の一部として送信される検索結果参照のコンテンツを変更します。
-
中間レスポンス・プラグイン。クライアントに送信されるLDAP中間レスポンスのコンテンツを変更します。
-
起動プラグイン。サーバーが最初に起動する際にいくつかの処理を実行します。
-
停止プラグイン。サーバーが正常に停止する際にいくつかの処理を実行します。
-
接続後プラグイン。新しいクライアント接続の許可の一部としていくつかの処理を実行します。
-
切断後プラグイン。接続の終了直後にいくつかの処理を実行します。
-
LDIFインポート・プラグイン。LDAPデータ変換形式ファイルからインポートされるエントリのコンテンツを変更します。
-
LDIFエクスポート・プラグイン。サーバー・バックエンドからエクスポートされるエントリのコンテンツを変更します。
A.4.15.15 プレゼンス検索フィルタ
プレゼンス検索フィルタは、LDAP検索フィルタのタイプで、指定された属性の値を少なくとも1つ保有するエントリの識別に使用できます。LDAPプレゼンス・フィルタの文字列表現は、左カッコに続く属性名、等号、アスタリスクおよび右カッコで構成されます。たとえば、等価フィルタ(aci=*)
は、aci
属性の値を少なくとも1つ含むエントリと一致します。
A.4.15.16 特権
ディレクトリ・サーバーには特権サブシステムがあり、ユーザーに権限を付与する機能の定義に使用できます。特権サブシステムは、ユーザーが操作の実行を許可されているかどうかを判断するプロセスで、アクセス制御実装とともに動作します。
ディレクトリ・サーバーで定義される特権には、次のものがあります。
-
bypass-acl
アクセス制御の評価のバイパスをユーザーに許可
-
modify-acl
サーバーで定義されるアクセス制御ルールの変更をユーザーに許可
-
config-read
サーバー構成の読取りアクセス権の保有をユーザーに許可
-
config-write
サーバー構成の書込みアクセス権の保有をユーザーに許可
-
server-shutdown
サーバーの停止をユーザーがリクエストすることを許可
-
server-restart
サーバーのインコア再起動実行のリクエストをユーザーに許可
-
proxied-auth
異なる認可IDによる操作のリクエストをユーザーに許可
-
unindexed-search
索引なし検索のリクエストをユーザーに許可
-
password-reset
その他のユーザーに対するパスワードのリセットをユーザーに許可
-
update-schema
サーバー・スキーマの更新をユーザーに許可
特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」を参照してください。
A.4.15.17 比例アルゴリズム
クライアントのリクエストをレプリケートされたリモートLDAPサーバーのセットに配布するプロキシ・ロード・バランシング・アルゴリズム。各リモートLDAPサーバーに送信されるリクエストの数は、重み設定により決定されます。
A.4.15.20 プロキシ認可制御
プロキシ認可制御は、関連付けられた操作を別のユーザーの認可で実行するリクエストに使用できる制御のタイプです。
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に含まれる文字列です。
検索リクエストでこの制御を使用する例は、「プロキシ設定された認可制御を使用した検索」を参照してください。
A.4.16 Q
A.4.16.1 保護品質
保護品質(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
のいずれのレベルもサポートしていません。
A.4.17 R
A.4.17.1 実在属性専用制御
実在属性専用制御は、サーバーが実在する属性のみを一致するエントリに含めるように要求するために使用できる制御です。つまり、仮想属性は検索結果エントリから除外されます。
実在属性専用制御のリクエスト・オブジェクト識別子は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
A.4.17.4 相対識別名
相対識別名すなわちRDNは、識別名内の単一のコンポーネントです。1つ以上の名前/値ペアで構成され、名前/値ペアの名前と値は等号で区切られます(たとえば、RDN uid=ann
の場合は、名前はuid
で値はann
)。複数の名前/値ペアが存在する場合は、プラス記号で区切られます(たとえば、RDN cn=John 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
を保有します。
A.4.17.6 レプリケーション
レプリケーションはデータ同期の形式で、ディレクトリ環境の変更がサーバーの各インスタンスに反映されることを保証するために使用されます。つまり、1つのディレクトリ・サーバー・インスタンスで実行される変更は常に、同じ変更がその他の各インスタンスでも実行されます。レプリケーションは通常ソースと宛先が同じ製品内にある(両方ともOracle Unified Directoryなど)状況で行われます。
A.4.17.7 レプリケーション修復制御
レプリケーション修復制御は、トポロジ内の単一のサーバーで、レプリケーションの非一貫性を解決するために使用できる制御です。
レプリケーション修復制御のリクエスト・オブジェクト識別子は1.3.6.1.4.1.26027.1.5.2
で、値はありません。
レプリケーション修復制御を使用する例は、「レプリケーションの非一貫性の検出および解決」を参照してください。
A.4.17.8 request for comments
request for comments (RFC)は、Internet Draftから昇格したIETF (http://www.ietf.org/
)の仕様で、Draftと比較して十分安定していると考えられます。
A.4.17.11 結果コード
結果コードは、操作の結果についての汎用情報を提供する整数値です。定義された結果コードには次のものがあります:
値 | 名前 | 説明 |
---|---|---|
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 |
認可が拒否されました |
リクエストにプロキシ認可制御を含んでいたがクライアントがその制御の使用を許可されなかったため、関連付けられた操作が処理されなかったことを示します。 |
A.4.17.12 ルートDN
ルートDN(すなわちルート・ユーザー)はディレクトリ・サーバーに存在するアカウントのタイプで、UNIXシステムのルート・ユーザーのように、通常、サーバー内のすべてのデータへの完全アクセス権を付与されます。ルート・ユーザーはデフォルトでアクセス制御の評価をバイパス可能で、サーバー構成への完全アクセス権を保有し、大部分のタイプの操作を実行します。
ディレクトリ・サーバーは、ルート・ユーザーについて次の2つの点で他のほとんどのサーバーと異なります。
-
複数のルート・ユーザーを使用してディレクトリ・サーバーを構成できます。これによって各ルート・ユーザーは異なる資格証明のセットを持つことができます。各管理者が、すべての管理者で共有される1つのアカウントではなく、個別の独立したルート・アカウントを持つこともできます。
-
ルート・ユーザーに付与されるすべての権限は、特権を介して割り当てられます。特権サブシステムを使用して、通常、ルート・ユーザーのみが使用可能な一部またはすべての機能を持つroot以外のユーザーを作成できます。必要な場合はルート・ユーザーから特権を取り去ることもできます。
ルート・ユーザーおよび特権サブシステムの詳細は、「ルート・ユーザーと特権サブシステム」を参照してください。
A.4.17.13 ルートDSE
ルート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エントリの検索方法の詳細は、「拡張検索機能の使用方法」を参照してください。
A.4.18 S
A.4.18.1 salt
saltはランダム・データの集合で、クリアテキスト・データ(パスワードであることが多い)と組み合せて、クリアテキストをエンコードする方法を変更するために使用できます。特に、saltはエンコード処理に不規則性を導入して、辞書攻撃を防ぐために使用されます。通常、saltはクリアテキスト・パスワードに追加され、そのパスワードは必要とするメッセージ・ダイジェスト・アルゴリズムを使用してエンコードされます。クリアテキストsaltはメッセージ・ダイジェストに追加され、最終的な値はbase64エンコーディングでエンコードされます。このようにしてsaltの内容の判断が可能になり、ユーザーの指定したパスワードが正しいかどうかの判断に使用できます。
UNIX暗号化アルゴリズムは比較的弱い12ビットのsaltを使用しており、それは、値をエンコードする方法が4096通りのみであることを意味します。これは比較的低い数字で、このためユーザー・パスワードの解読に使用する広い範囲の値をすべてエンコードした辞書を構築できます。その他のディレクトリ・サーバーのパスワード記憶スキームでは64ビットのsaltを使用しており、1つの値を18446744073709551616通りにエンコードできます。
「暗号化アルゴリズム」も参照してください。
A.4.18.2 飽和アルゴリズム
クライアントのリクエストを優先リモートLDAPサーバーにルーティングするプロキシ・ロード・バランシング・アルゴリズム。メイン・リモートLDAPサーバーが飽和しきい値に達した場合は、リクエストはセカンダリ・リモートLDAPサーバーにルーティングされます。
A.4.18.4 飽和しきい値
飽和しきい値は、データ・ソースがオーバーロードとみなされ、これ以上の着信リクエストを適切な方法で処理できないという制限値です。飽和しきい値は、プロキシ飽和アルゴリズムの一部として使用されます。
A.4.18.5 スキーマ
ディレクトリ・サーバーのスキーマは、サーバーが保持できる情報の種類を制御するルールのセットを定義します。ディレクトリ・スキーマには、次のような様々な要素があります。
-
属性で保管できる情報の種類についての情報を提供します。
-
属性値との比較方法の情報を提供します。
-
特定の一致ルールとともに使用できる属性タイプを示します。
-
指定された属性の参照に使用できるオブジェクト識別子および名前のセットを定義し、その属性を構文および一致ルールのセットと関連付けます。
-
名前付きの属性の集合を定義し、必須およびオプションの属性のセットに分類します。
-
エントリの相対識別名に含まれる属性のセットに対するルールを定義します。
-
エントリとともに使用できるオブジェクト・クラスおよび属性についての追加の制約を定義します。
-
指定されたエントリが保有できる下位エントリの種類を制御するルールを定義します。
属性はディレクトリに情報を保管するための要素で、スキーマは、エントリ内で使用できる属性のルール、これらの属性が保有できる値の種類、クライアントがこれらの値と相互に作用する方法を定義します。
クライアントは、適切なサブスキーマ・サブエントリを取得して、サーバーがサポートするスキーマ要素を学習できます。
A.4.18.6 スキーマ検査
スキーマ検査は、エントリがサーバー・スキーマで定義された制約に準拠していることを確認する処理です。次のものが含まれます。
-
エントリに1つの構造オブジェクト・クラスが含まれることを確認します。
-
エントリの構造クラスのDITコンテンツ・ルールが存在する場合は、各補助オブジェクト・クラスが定義されていることを確認します。
-
エントリに含まれる各オブジェクト・クラスがスキーマで定義されていることを確認します。
-
エントリに含まれる各属性がスキーマで定義されており、オブジェクト・クラスまたはDITコンテンツ・ルール、あるいはその両方により許可されていることを確認します。
-
エントリのオブジェクト・クラスまたはDITコンテンツ・ルールにより要求されたすべての属性が存在することを確認します。
-
エントリに含まれるすべての単一値属性が値を1つのみ保有していることを確認します。
-
ディレクトリ情報ツリー (DIT)内のエントリの位置が、DIT構造ルールの定義に準拠していることを確認します。
A.4.18.7 検索属性
検索操作の検索属性要素は、検索結果エントリに含まれる属性を表す方法を指定します。通常、検索属性のセットは、返す属性の0個以上の属性説明のリストです。値が指定されている場合は、すべてのユーザー属性が返され、操作属性は返されません。
特定の属性説明に加えて、それぞれ異なる意味を持つ次の特別な値を指定できます。
-
文字列
1.1
は一致するエントリに含まれる属性が存在しないことを示します。 -
文字列
*
(アスタリスク)は、一致するエントリにすべてのユーザー属性が含まれることを示します。1つ以上の操作属性に加えて、すべてのユーザー属性をサーバーが返す場合に必要です。 -
文字列
+
(プラス記号)は、一致するエントリに操作属性が含まれることを示します。 -
オブジェクト・クラス名は、接頭辞として文字
@
を付けた形式で指定できます。オブジェクト・クラスにより参照されるすべての属性は一致するエントリに含まれることを示します。
A.4.18.8 検索ベースDN
検索ベースDNは検索操作の要素で、検索範囲とともに動作し、検索操作の処理対象として考慮するエントリのサブツリーを定義します。検索ベースDNのエントリまたはその下のエントリ、およびその範囲内のエントリのみが、LDAP検索フィルタと一致する候補とみなされます。
A.4.18.10 検索操作
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。検索を実行するディレクトリ情報ツリー(DIT)内の場所を指定します。
-
検索範囲。検索処理の対象として考慮する、ベース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
A.4.18.14 検索範囲
LDAP検索範囲は、検索操作で一致する可能性を検討する検索ベースDNのエントリまたはその下のエントリのセットを示します。
検索範囲の値には次の4つの定義があります:
-
baseObject
検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。
DITのシナリオを考えます。このDITは、検索ベースDNに
dc=example,dc=com
を持つbaseObject範囲を保有しています。 -
singleLevel
検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。
-
wholeSubtree
検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。
-
subordinateSubtree
検索操作は、深さにかかわらず検索ベースのすべての下位エントリに対して実行されますが、検索ベース・エントリ自体は含まれません。
A.4.18.15 セキュア・ハッシュ・アルゴリズム
セキュア・ハッシュ・アルゴリズム(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エンコーディングの問題もありません。
A.4.18.16 Secure Sockets Layer
Secure Sockets Layer (SSL)はセキュリティ層でネットワーク通信をラップするメカニズムで、クライアントとサーバーの間の通信を暗号化するために使用できます。クライアントとサーバーとの間で通信が変更されないことを保証する、整合性メカニズムも提供します。暗号化は、証明書を使用した暗号化に基づいています。
SSLは元々、Netscape Communications社が開発したプロプライエタリ・プロトコルです。その後標準化されましたが、名前はTransport Security Layerに変更されました。しかし、SSLはこの機能を指すために現在でも一般的に使用される用語で、TLS起動拡張操作との混同を避けるためにディレクトリ・サーバーで使用される用語です。
A.4.18.17 サーバー側ソート制御
サーバー側ソート制御は、検索操作に追加して、結果がクライアントに返される前に結果がソートされるようにリクエストする制御のタイプです。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 }
A.4.18.18 簡易認証
簡易認証は、識別名およびパスワードを使用するディレクトリ・サーバーに対する認証の処理です。バインド操作を使用して実行されます(簡易認証を使用してバインドが実行された場合は、多くの場合、簡易バインドと呼ばれます)。クライアントは指定されたDNを使用してクライアント自体をサーバーに認証要求し、クライアントが誰だと主張しているのかを検証するためにパスワードが使用されます。
簡易認証ではパスワードを保護する方法がないことに注意してください。そのため、通常、Secure Sockets LayerまたはTLS起動拡張操作で提供されるような保護された通信チャネルで使用される場合のみ簡易認証をお薦めします。
A.4.18.19 Simple Authentication and Security Layer
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セッションを使用してユーザーがサーバーへの認証を行う方法を提供します。接続の完全性および機密性を保証するために使用できるメカニズムも提供します。
-
このメカニズムは、ユーザー名およびパスワードを使用し、ユーザーがサーバーへの認証を行う方法を提供します。簡易認証で提供される保護とよく似ていますが、識別名ではなくユーザー名でユーザーが自分自身を認証要求できるという点でより便利です。
A.4.18.20 単純なページングの結果制御
単純なページングの結果制御は、検索操作に追加して、結果のサブセットのみを返すことを示す制御のタイプです。検索結果を一度に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 }
検索リクエストでこの制御を使用する例は、「単純なページングの結果制御を使用した検索」を参照してください。
A.4.18.22 スマート・リフェラル
スマート・リフェラルは特別なタイプのエントリで、別のサーバーまたは別のDITの場所、あるいはその両方のコンテンツを参照するディレクトリ情報ツリー (DIT)に配置できます。スマート・リフェラル・エントリには、リフェラルで使用されるLDAP URLを含むref
属性の1つ以上のインスタンスを持つreferral
オブジェクト・クラスが含まれます。
A.4.18.23 StartTLS拡張操作
TLS起動拡張操作は、クリアテキスト接続上で、Transport Security Layerで保護された通信チャネルの開始に使用できる拡張操作のタイプです。クライアントは、保護された通信と保護されない通信の両方で同じネットワーク・ポートを使用できます。
StartTLS拡張操作は、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と同じ)で、値はありません。
A.4.18.25 構造オブジェクト・クラス
構造オブジェクト・クラスは、主要なオブジェクト・クラス・タイプの1つです。構造オブジェクト・クラスは、このオブジェクト・クラスを含むのエントリのコア・タイプを定義するという点で特別です。エントリは1つの構造クラスを保有する必要があります(その構造クラスは他の構造クラスまたは抽象オブジェクト・クラスから継承する場合もあります)。
エントリの構造オブジェクト・クラスは、ディレクトリ・データの制限を定義するための他のスキーマ要素により使用される場合もあります。エントリの相対識別名で使用される属性を制御する名前書式の定義により使用される場合があります。また、親エントリを保有する場合、そのタイプを制御するDIT構造ルールにより使用される場合があります。構造オブジェクト・クラスは、DITコンテンツ・ルールによっても使用され、補助オブジェクト・クラスのセット、および必須の、使用可能な、禁止されたエントリの属性タイプを制御します。
A.4.18.27 サブスキーマ・サブエントリ
サブスキーマ・サブエントリはディレクトリ・サーバー内の特別なエントリで、サーバーで定義されるスキーマ要素の情報を提供します。このエントリの属性には次のものがあります:
-
ldapSyntaxes
サーバー・スキーマで定義された属性構文のセット。
-
matchingRules
サーバー・スキーマで定義された一致ルールのセット。
-
matchingRuleUse
サーバー・スキーマで定義された一致ルールの使用のセット。
-
attributeTypes
サーバー・スキーマで定義された属性タイプのセット。
-
objectClasses
サーバー・スキーマで定義されたオブジェクト・クラスのセット。
-
nameForms
サーバー・スキーマで定義された名前書式のセット。
-
dITContentRules
サーバー・スキーマで定義されたDITコンテンツ・ルールのセット。
-
dITStructureRules
サーバー・スキーマで定義されたDIT構造ルールのセット。
これらはすべて操作属性であるため、明示的にリクエストされない場合は返されないことに注意してください。
また、ディレクトリ・サーバーでは、ディレクトリ情報ツリー(DIT)の異なる部分を制御するスキーマ定義の異なるセットを持つ、複数のサブスキーマ・サブエントリを、技術的には保有できます。指定されたエントリに適用するスキーマは、エントリからsubschemaSubentry
仮想属性を取得して確認できます。現在ディレクトリ・サーバーは単一のスキーマのみをサポートしますが、デフォルトでcn=schema
でそのスキーマを公開します。
A.4.18.28 部分文字列アサーション
部分文字列アサーションは、属性が指定された部分文字列と一致する属性値を保有するかどうかを判断する処理で、部分文字列一致ルールに指定される引数です。
部分文字列アサーションには、次のセットのうち少なくとも1つのコンポーネントが含まれます:
-
0または1つのsubInitial要素。ターゲット値の先頭に指定する必要があります。
-
0または1つのsubAny要素。値の先頭および最後以外の場所に指定できます。複数のsubAny要素が存在する場合は、一致する属性値には、重複なく部分文字列アサーションに設定された順序ですべてのsubAny要素が含まれる必要があります(つまり、属性値に文字を含まない場合は、2つの異なる部分文字列アサーションのコンポーネントの部分である可能性があります)。subInitialコンポーネントまたはsubFinalコンポーネント、あるいはその両方が存在する場合は、subAny要素がそのいずれかと重複することはできません。
-
0または1つのsubFinal要素。ターゲット値の最後に指定する必要があります。
部分文字列アサーションは、部分文字列検索フィルタを処理する際に使用されます。
A.4.18.30 部分文字列検索フィルタ
部分文字列検索フィルタは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
が含まれます。
A.4.18.31 サブツリー
サブツリーという用語には2つの定義があります。
この用語の一般的な定義は、エントリおよびすべての下位エントリを含むディレクトリ情報ツリー(DIT)の部分です。
サブツリーという用語は、RFC 3672 (http://www.ietf.org/rfc/rfc3672.txt
)でも、サブツリーの形式の仕様の中で説明されています。サブツリーの仕様は、指定された基準のセットに基づき、エントリをグループ化するメカニズムを提供します。
A.4.18.32 サブツリー削除制御
サブツリー削除制御は、削除操作に追加して、エントリおよびその下位エントリすべての削除を許可する制御のタイプです。通常の削除操作は、リーフ・エントリのみをターゲット設定できますが、サブツリー削除制御はリーフ以外のエントリをターゲット設定するために使用できます。
サブツリー削除リクエスト制御の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
A.4.18.33 サポートされている制御
サポートされている制御は、ディレクトリ・サーバーによりサポートされているリクエスト制御を識別するメカニズムです。これらの制御のオブジェクト識別子は、サーバーのルートDSEのsupportedControl
属性にリストされています。
Oracle Unified Directoryで現在サポートされているすべての制御のリストは、「サポートされているLDAP制御」を参照してください。
A.4.18.34 サポートされている拡張
サポートされている拡張は、ディレクトリ・サーバーによりサポートされている拡張操作を識別するメカニズムです。これらの拡張操作のオブジェクト識別子は、サーバーのルートDSEのsupportedExtension
属性にリストされています。
ディレクトリ・サーバーでサポートされているすべての拡張のリストは、「サポートされている拡張操作」を参照してください。
A.4.18.35 サポートされている機能
サポートされている機能は、ディレクトリ・サーバーによりサポートされているオプション機能を識別するメカニズムです。サーバーでサポートされている一部の機能は、サーバーのルートDSEのsupportedFeatures
属性でリストされており、そこではサポートされている機能のオブジェクト識別子がリストされています。
ディレクトリ・サーバーでサポートされている機能には次のものがあります。
-
1.3.6.1.4.1.4203.1.5.1
RFC 3673 (
http://www.ietf.org/rfc/rfc3673.txt
)で説明されているように、すべての操作属性をリクエストする際に、+
インジケータの使用をサーバーがサポートすることを示します。 -
1.3.6.1.4.1.4203.1.5.2
RFC 4529 (
http://www.ietf.org/rfc/rfc4529.txt
)で説明されているように、検索属性のセットに1つ以上のオブジェクト・クラス名を含める機能をサーバーがサポートすることを示します。 -
1.3.6.1.1.14
RFC 4525 (
http://www.ietf.org/rfc/rfc4525.txt
)で説明されているように、増分変更拡張の一部である増分変更タイプをサーバーがサポートすることを示します。 -
1.3.6.1.4.1.4203.1.5.3
RFC 4526 (
http://www.ietf.org/rfc/rfc4526.txt
)で説明されているように、LDAP trueフィルタおよびLDAP falseフィルタをサーバーがサポートすることを示します。
A.4.18.36 同期
データ同期は、ディレクトリ環境内の変更を追跡し、他の場所に反映できるようにするメカニズムです。
同期は、異なるベンダー製品(Active DirectoryとOracle Unified Directoryなど)の間で行うことができる点でレプリケーションと異なります。
A.4.19 T
A.4.19.1 タスク
タスクは、サーバーでいくつかのタイプの処理を実行するためのロジックのセットを提供します。通常、タスクはサーバー内の管理機能の実行に使用されます。使用可能なタスクの例を次に示します:
-
サーバー・スキーマへの新しいファイルの追加
-
以前のバックアップを復元
-
LDIFインポート操作の実行
-
LDIFエクスポート操作の実行
-
インコア再起動の実行
-
サーバー停止の実行
タスクは繰り返し実行可能で、特定のスケジュールに従って定期的に実行するようにスケジュールされます。たとえば、バックアップ・タスクは、サーバー・データを定期的にバックアップするために繰り返し実行できます。タスクのスケジューリングの詳細は、「タスクのスケジュールと構成」を参照してください。
A.4.19.3 トランザクション
トランザクションは、データベース内で発生する読取りまたは書込みの操作、あるいはその両方の1つ以上の集合です。トランザクションはACIDという頭字語で説明される場合があり、それは、原子性、一貫性、独立性および永続性の略です。ディレクトリ・サーバーはBerkeley DB Java Editionでトランザクションを使用し、単一のLDAP操作の一部として実行される複数の変更を保証します(id2entryデータベースおよび索引の両方に対する更新など)。
ディレクトリ・サーバーがデータベースの操作のために内部でトランザクションを使用しても、クライアントが単一の原子ユニットとして複数の操作を実行できるトランザクション・メカニズムは現在は公開されていません。トランザクションを公開する可能性のあるメカニズムを説明するInternet Draftもありますが(draft-zeilenga-ldap-txn)、現在、ディレクトリ・サーバーではこの機能をサポートしていません。
A.4.19.4 Transport Security Layer
Transport Security Layer (TLS)は、クライアントとサーバーの間のネットワーク通信を保護するメカニズムです。Secure Sockets Layerの標準化された形式に対して付与された名前です。
通常、TLSよりSSLという用語をお薦めするのは、SSLの方がより一般的な用語であり、また、TLS起動拡張操作との混同を避けるためでもあります。
A.4.20 U
A.4.20.1 アンバインド操作
LDAPアンバインド操作は、クライアントがサーバーからの切断を実行しようとしていることを示すために使用されます。
ノート:
アンバインド操作は、基礎となる接続が確立されたままになっている場合に、認証セッションの破棄には使用できません。クライアントがアンバインド・リクエストを送信した後で接続を終了しない場合は、サーバーが実行します。接続を認証されていない状態に戻す必要がある場合は、匿名バインド操作を実行します。
LDAPアンバインド・リクエスト・プロトコルopは次のように定義されます:
UnbindRequest ::= [APPLICATION 2] NULL
アンバインド・リクエストはいずれの要素も持たず、サーバーはアンバインド・リクエストに対してレスポンスを送信しません。
A.4.20.2 索引なし検索
索引なし検索は、サーバーで定義された索引のセットを使用する処理ができない検索です。データベースのほとんどまたはすべてのエントリを繰り返し処理する必要があります。
索引なし検索はサーバーにとって高い処理コストがかかる可能性があり、ユーザーは、unindexed-search
特権を保有する場合にのみ、索引なし検索の実行を許可されます。
詳細は、「ディレクトリ・データへの索引付け」を参照してください。
A.4.20.3 UNIX暗号化アルゴリズム
UNIX暗号化アルゴリズムは、最終的に一方向メッセージ・ダイジェストを作成するDESベースの暗号化スキームを使用し、ユーザー・パスワードをエンコードする標準メカニズムです。UNIXベースのシステムでパスワードをエンコードするデフォルトのメカニズムとして従来から使用されているため、UNIX暗号化アルゴリズムと呼ばれます。
UNIX暗号化アルゴリズムは、56ビットの暗号化アルゴリズムに基づき、12ビットのみのsaltを使用するため、脆弱であるとみなされます。このため、バインド操作を使用して値の検証を試行するかわりに、サーバーからパスワードを取得してユーザーが入力した値と比較することをクライアントが必要とする場合にのみ使用されます。
「暗号化アルゴリズム」も参照してください。
A.4.20.4 未承諾通知
未承諾通知は、拡張操作メッセージのタイプで、対応するクライアントからのリクエストのない種類のメッセージをサーバーが生成するという点で特殊です。重要な情報をクライアントに通知するために使用される場合もあります。
現在、ディレクトリ・サーバーでは、次の未承諾通知1つをサポートしています。それは切断の通知未承諾通知で、サーバーが接続を閉じようとしていることをクライアントに通知するために使用できます。
A.4.21 V
A.4.21.2 仮想属性専用制御
仮想属性専用制御は、サーバーが仮想属性のみを一致するエントリに含めるように要求します。つまり、実在属性は検索結果エントリから除外されます。
仮想属性専用制御のリクエスト・オブジェクト識別子は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
A.4.21.3 仮想ディレクトリ
仮想ディレクトリはネットワーク・デーモンのタイプで、Lightweight Directory Access Protocolを使用してクライアントと通信しますが、異なるソースの組合せから基礎となるデータを取得します。仮想ディレクトリには、次のように様々な機能があります。
-
リレーショナル・データベースまたはフラット・ファイルのように、異なるリポジトリに対してLDAPフロントエンドを提供します。
-
複数のリポジトリのデータをマージするメカニズムを提供します。
A.4.21.4 仮想リスト表示制御
仮想一覧表示(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 }
検索リクエストでこの制御を使用する例は、「仮想リスト表示制御を使用した検索」を参照してください。
A.4.22 W
A.4.22.1 Who Am I拡張操作
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拡張操作により提供される情報はクライアントが認証された後ならいつでも使用できることを除けば、認可アイデンティティ制御により提供される情報と似ています。
A.4.22.2 ワーク・キュー
ディレクトリ・サーバー・ワーク・キューは、未処理リクエストを追跡し、適切な方法で処理されていることを確認するために使用するメカニズムです。ワーク・キューの機能は拡張可能なAPIにより提供されますが、デフォルトの実装は比較的単純で、キューはいくつかのワーカー・スレッドのサービスを受けます。空きワーカー・スレッドが存在する場合は、通常、キューは空のままです。すべてのワーカー・スレッドがビジーの場合は、後続のリクエストがワーク・キューに配置され、FIFO方式で処理されます。
A.4.22.3 ワーカー・スレッド
ワーカー・スレッドは、ディレクトリ・サーバーでのリクエスト処理に使用されるスレッドです。ワーカー・スレッドはワーク・キューと関連付けられ、(必要に応じてリクエストの到着を待っている)キューからリクエストを取得し、適切にリクエストを処理し、次のリクエストのためにキューへ返すというループで動作します。
A.4.22.5 ワークフロー要素
ワークフロー要素は、ワークフロー処理の重要な構築ブロックです。サーバーへ送信されたクライアント・リクエストの取扱方法を定義します。ロード・バランシングや分散など、ワークフロー要素のメイン・タスクはプロキシ・サーバーに実装されます。
A.4.22.6 書込み可能モード
ディレクトリ・サーバーの書込み可能モードは、書込み操作が許可されるかどうかを制御するために使用されます。書込み可能モードの構成は、単一のバックエンドに制限するか、またはサーバー全体に適用できます。
使用可能な書込み可能モードは次のとおりです:
-
enabled
サーバーはすべての書込み操作の処理を試行します。
-
無効
サーバーはすべての書込み操作を却下します。
-
内部のみ
サーバーは、内部操作として、または同期によって開始される書込み操作の処理を試行しますが、外部クライアントからのリクエストは却下します。
エントリDNは、エントリの現在のDNのコピーを提供する操作属性です。DNはエントリの属性ではないため、属性値アサーションの実行には使用できません。RFC 5020 (http://www.ietf.org/rfc/rfc5020.txt
)で説明されるように、エントリDNはエントリのDNにアクセスするメカニズムを提供します。