Network Working Group M. Wahl
Request for Comments: 2251 Critical Angle Inc.
Category: Standards Track T. Howes
Netscape
Communications Corp.
S. Kille
Isode Limited

 

Lightweight Directory Access Protocol (v3)

 

1 このメモの位置付け  

本文書は、インターネットコミュニティのための標準化プロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。本プロトコルの標準化状態、および、ステータスについては「Internet Official Protocol Standards」(STD 1)の最新版を参照してほしい。このメモの配布に制限は無い。

著作権について

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

IESGノート

本文書では、読み出しおよび更新アクセスを提供するディレクトリアクセスプロトコルについて述べる。更新アクセスには安全な認証が必要であるが、本文書は十分な認証機構の実装についてはなにも指示しない。

このような制限は存在するが、本仕様書は、RFC 2026のセクション4.4.1に従って、Proposed StandardとしてIESGに認可されている。その理由は次の通りである:

  1. 配備される前に、(更新アクセスの有無に関わらず)本プロトコルの実装と相互運用性の試験を奨励するため。

  2. 読み出し専用のアプリケーション中で、これらのプロトコルの配備と利用を奨励するため。(例えば、LDAP以外の安全な方法で更新されるディレクトリに対して、LDAPv3が問い合わせ言語として使用されているアプリケーション)

  3. LDAPv3ディレクトリサーバへの問い合わせ機能が必要であるが、更新を必要としない他の標準化過程にあるプロトコルの配備、あるいは進歩を遅らせないため。

必須の認証機構が標準化されるまで、本仕様に従って書かれた更新機能を利用するクライアントとサーバは相互運用できない、あるいは、認証レベルが受け入れ難いレベルにまで下げられる場合に限り相互運用できる、という可能性があることを読者にあらかじめ警告する。

実装者は、LDAPv3で必須となる認証のためのProposed Standardが認められ、RFCとして発行されるまで、更新機能を実装するLDAPv3クライアント、およびサーバの配備を行わないことが望ましい。

目次

1. このメモの位置付け
著作権について
IESGノート
2. 要約
3. モデル
3.1. プロトコルモデル
3.2. データモデル
3.2.1. エントリの属性
3.2.2. サブスキーマエントリとサブエントリ
3.3. X.500との関係
3.4. サーバ固有データの必要条件
4. プロトコルの要素
4.1. 共通の要素
4.1.1. Message Envelope
4.1.1.1 メッセージID
4.1.2. 文字列の型
4.1.3. 識別名と相対識別名
4.1.4. 属性型
4.1.5. Attribute Description
4.1.5.1 Binaryオプション
4.1.6. Attribute Value
4.1.7. Attribute Value Assertion
4.1.8. Attribute
4.1.9. Matching Rule Identifier
4.1.10. 結果メッセージ
4.1.11. 参照
4.1.12. コントロール
4.2. バインドオペレーション
4.2.1. バインド要求の順序制御
4.2.2. 認証と他のセキュリティサービス
4.2.3. バインド応答
4.3. アンバインドオペレーション
4.4. 余計な通知
4.4.1. 切断の通知
4.5. 検索オペレーション
4.5.1. 検索要求
4.5.2. 検索結果
4.5.3. 検索結果での継続参照
4.5.3.1
4.6. 修正オペレーション
4.7. 追加オペレーション
4.8. 削除オペレーション
4.9. DN修正オペレーション
4.10. 比較オペレーション
4.11. 破棄オペレーション
4.12. 拡張オペレーション
5. プルトコル要素符号化(Element Encodings)と転送
5.1. BERに基づいたトランスポートサービスヘのマッピング
5.2. 転送プロトコル
5.2.1. Transmission Control Protocol (TCP)
6. 実装ガイドライン
6.1. サーバ実装
6.2. クライアント実装
7. セキュリティに関する考察
8. 謝辞
9. 参考文献
10. 著者の連絡先
Appendix A - Complete ASN.1 Definition
Full Copyright Statement

2 要約  

本文書で述べられるプロトコルは、X.500モデルをサポートするディレクトリに対するアクセスを提供するために設計され、一方で、X.500ディレクトリアクセスプロトコル(Directory Access Protocol : DAP)の資源要求は課されない。本プロトコルは、ディレクトリに対する対話的な読み込み/書き込み(read/write)アクセスを提供する管理アプリケーションやブラウザアプリケーションを特に対象とする。X.500プロトコルをサポートするディレクトリと共に使用する際に、X.500のDAPを補完するものとなることが意図されている。

この文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"は、RFC 2119[10] に記述されたように解釈されるべきである。

LDAPのこのバーションは、以下のような特徴を備えている:

3 モデル  

インターネットにおけるX.500[1]ディレクトリ技術への関心が持たれたことで、この技術を利用する際にかかる高価な「参入コスト」を削減する努力が行われるようになっ た。本文書は、その替わりとなり得るディレクトリプロトコルを定義する努力を継続し、LDAP[2]プロトコル仕様を更新する。

3.1. プロトコルモデル  

本プロトコルで採用された一般モデルは、クライアントの一つがサーバに対してプロトコルオペレーションを実行するというものである。このモデルでは、クライアントは、 実行されるべき操作を記述したプロトコル要求をサーバに送信する。サーバは、ディレクトリ内で必要な操作を実行することに対して責任を持つ。操作の完了後、サーバ は要求してきたクライアントに対して、何らかの結果、あるいはエラーを含む応答を返す。

ディレクトリの利用にかかるコストを軽減するという目的に沿って、ディレクトリを利用できるアプリケーションの広範囲の普及を推進するために、クライアントの複雑さを最小限にとどめることが、本プロトコルの目的である。

プロトコルで応答が定義されている場合にはいつも、サーバは、必ずそれを返すよう要求されているが、クライアントあるいはサーバのいずれに対しても、同期的な動作が要求されているわけではないことに注意。複数の操作に対する要求や応答は、クライアント-サーバ間で、どんな順序で交換されても良く、最終的にクライアントは、行ったすべての要求に対する応答を受け取る。

LDAPのバーション1とバーション2のプロトコルでは、クライアントへの参照の差し戻しについては何も考慮されていない。しかし、このバーションのプロトコルでは、性能向上と分散化のために、サーバがクライアントに対して他のサーバへの参照を返すことを認めている。これによって、操作を進めるために、サーバが他のサーバと連絡を取ることによる負荷が削減される。 本文書で定義される核となるプロトコルオペレーションは、X.500(1997)ディレクトリ抽象サービスの完全なサブセットにマッピングできるため、DAPによって明確に提供され得ることに注意。しかし、LDAPプロトコルオペレーションとDAPオペレーションの間には一対一のマッピングはない:X.500ディレクトリのゲートウェイとして動作するサーバ実装は、複数のDAP要求を行う必要があるかもしれない。

3.2. データモデル  

本セクションでは、LDAPで使用されるX.500データモデルについて簡単に述べる。LDAPプロトコルは、Directory Information Tree(DIT)に共同でアクセスを提供する一つ以上のサーバがあると仮定している。そのツリーはエントリから構成されている。エントリには名前がある:エントリ中の一つ以上の属性値が相対識別名(relative distinguished name: RDN)を形成する。各RDNは、その兄弟関係において一意でなければならない(MUST)。あるエントリからツリーのルート直下までのエントリ列上での相対識別名を連結したものが識別名(Distinguished Name: DN)を形成し、これはツリー構造中で一意である。識別名の例を以下に示す:

   CN=Steve Kille, O=Isode Limited, C=GB

サーバは、エントリのキャッシュやシャドウコピーを保持でき、それらは検索および比較の要求に答えるために使用できる。しかし、修正操作が要求された場合は、参照を返すか、もしくは他のサーバと連絡を取る。
キャッシュやシャドウをするサーバは、オリジナルのサーバによってデータにかけられたアクセス制御の制約を破らないことを保証しなければならない(MUST)
あるサーバによって管理されるエントリから始まって、そのすべての下位と、さらに それらの下位を含み、異なるサーバに管理されるエントリまで下にたどっていって得られるエントリ集合のうち最大のものはネーミングコンテキストと呼ばれる。DITのルートはDSA固有のエントリ(DSA-specific Entry: DSE)であって、ネーミングコンテキストの一部ではない:それぞれのサーバは、そのルートDSE中に異なった属性値を持っている。(DSAはディレクトリサーバを表すX.500用語である)

3.2.1. エントリの属性  

エントリは属性の集合から成り立つ。属性は一つ以上の関連づけられた値をもつ型である。属性型は、短い記述名とOID(オブジェクト識別子)によって識別される。属性型は、エントリ中にその型の属性値が一つ以上存在し得るかどうか、その値が従わなくてはならない構文、その属性の値に対して適用し得る適合の種類、およびその他の機能を管理する。

属性の一つの例は"mail"である。この属性には一つ以上の値があり得る。それらはIA5(ASCII)文字列でなければならず、それらは大文字小文字を区別しない(たとえば"foo@bar.com"は"FOO@BAR.COM"と一致する)。

スキーマは、属性型定義、オブジェクトクラス定義、および、それらがフィルタに対してどのように適合するか、エントリの属性に対する(比較操作における)属性値宣言、追加や修正オペレーションを許可するかどうかを決めるためにサーバが使う他の情報の集合である。LDAPで使用されるスキーマの定義は[5][6]で与えられている。追加のスキーマ要素は他の文書で定義されてもよい。

それぞれのエントリは、オブジェクトクラス属性を持たなければならない(MUST)。オブジェクトクラス属性はエントリのオブジェクトクラスを指定し、システムおよびユーザのスキーマは、それに沿ってエントリに許された属性を決定する。この属性の値はクライアントによって修正されても良い。しかし、オブジェクトクラス属性を取り去ることはできない。サーバは、エントリの基本的な構造的クラスを変更できないようにこの属性の修正を制限してもよい(例:人を国に変えることはできない)。エントリの作成時、あるいはエントリにオブジェクトクラスの値を加える際、指定されたクラスのすべてのスーパークラスが存在しなければ暗黙のうちに追加され、クライアントは新しいスーパークラスの必須属性値を与えなければならない。

ディレクトリシステムを管理するためにサーバによって使用される属性は、オペレーション属性と呼ばれる。それらは、名前で明確に要求されない限り、捜索結果としては返されない。「mail」のような、オペレーション属性ではない属性は、そのスキーマとサーバによって課される構文の制約を受ける。しかし、サーバは一般にそれらの値を利用しない。

オブジェクトクラス定義によってその属性が許可されていて、そのスキーマがエントリをコントロールする場合(サブスキーマによって指定される:以下を参照)、あるいは、サーバに知られているオペレーション属性であり管理目的に使用されるものである場合以外は、サーバは、クライアントがエントリに属性を追加することを許可してはならない(MUST NOT)[5]で定義される特別なobjectClass、'extensibleObject'が存在し、エントリ中にすべてのユーザ属性が存在することを認めていることに注意。

エントリは[5]で定義された次のオペレーション属性を含むことができる(MAY)。これらの属性はサーバで自動的に維持され、クライアントによって修正されない:

3.2.2. サブスキーマエントリとサブエントリ

サブスキーマエントリは、ディレクトリスキーマ、特にディレクトリサーバでサポートされるオブジェクトクラスと属性型についての情報を管理するために使用される。一つのサブスキーマエントリは、ディレクトリツリーの特定の部分のエントリで使用されるすべてのスキーマ定義を含んでいる。

X.500(93)モデルに従うサーバは、X.500サブスキーマ機構を用いてサブスキーマを実装するべきである(SHOULD)。そして、これらのサブスキーマは通常のエントリではない。 LDAPクライアントは、サーバがX.500サブスキーマの他の側面についても実装していると仮定するべきでない(SHOULD NOT)。エントリを管理し、クライアントによるそれらのエントリの修正を認めるサーバは、クライアントが、存在することが認められている属性とオブジェクトクラスを発見するために、これらのサブスキーマエントリを実装しアクセスを提供しなければならない(MUST)。すべてのサーバが同様にこれを実装することを強く推奨する。

次の四つの属性はすべてのサブスキーマエントリに存在しなければならない(MUST)

これらは[5]で定義されている。サブスキーマエントリ中には、追加サポートされる機能を反映するために、他の属性が存在してもよい(MAY)

これらは matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms, ldapSyntaxesを含んでいる。

サーバはクライアントが自身のスキーマ情報のキャッシュを保守できるように、サブスキーマエントリ中にcreateTimestampとmodifyTimestamp属性を提供するべきである(SHOULD)

クライアントは、エントリのベースオブジェクト検索要求によってのみ、サブスキーマエントリの属性を検索しなければならず(MUST)、検索フィルタは「(objectClass=subschema)」とする。(これは X.500(93)とのゲートウェイとなるLDAPv3サーバが、サブエントリ情報の要求を検知することを可能にする。)

3.3. X.500との関係 

本文書は、X.500アクセス機構として、X.500用語によってLDAPを定義する。LDAPサーバは、サービスを提供する際、X.500(1993)シリーズのITU勧告に従って動作しなければならない(MUST)。しかし、このサービスの提供中に、LDAPサーバがX.500プロトコルを使用することは要求されていない。例えば、LDAPで使用されたX.500のデータとサービスモデルがLDAPインタフェースに反しない限り、LDAPは他のディレクトリシステムにマッピングされ得る。

3.4. サーバ固有データの必要条件 

LDAPサーバは、それ自身についての情報、および、それぞれのサーバ固有のその他の情報を提供しなければならない(MUST)。これはルートDSE(DSA-Specific Entry)中で属性のグループとして表され、長さゼロのLDAPDNで名付けられる。これらの属性は、クライアントが "(objectClass=*)"フィルタを用いてルートのベースオブジェクト検索を行う場合に検索できるが、これらはアクセス制御の制約を受けている。クライアントがルートからのサブツリー検索を行う際には、ルートDSEは含まれてはならない(MUST NOT)

サーバは、クライアントがこれらの属性を修正することを認めても良い。

ルートDSEの次のような属性が[5]のセクション5で定義されている。追加の属性は他の文書で定義され得る。

サーバがエントリを管理しておらず、スキーマ情報の場所を知らない場合、subschemaSubentry属性はルートDSEに存在しない。サーバが複数のスキーマ規則の配下にあるディレクトリエントリを管理する場合、ルートDSEのsubschemaSubentry属性の値はいくつでもあり得る。

4 プロトコルの要素 

LDAPプロトコルはAbstract Syntax Notation 1(ASN.1)[3]を用いて記述され、一般的にASN.1基本符号化規則[11]のサブセットを用いて転送される。本プロトコルの将来の拡張をサポートするために、クライアントとサーバは、それらが認識しないタグをもつSEQUENCE符号化の要素を無視しなければならない(MUST)

X.500と異なり、拡張機構によるもの以外のLDAPプロトコルへの変更は、それぞれが異なるバージョン番号を持つ。セクション4.2で記述されるように、クライアントはバインド要求の一部として、サポートしているバージョンを示す。クライアントがバインド要求を送っていないなら、サーバは、クライアントではバージョン3がサポートされるものと想定しなければならない(MUST)(バージョン2では、クライアントが最初にバインドすることを必要としたため)。

クライアントは、ルートDSEからsupportedLDAPVersion属性を読み取ることによって、サーバがサポートするプロトコルバージョンを決定することができる。 バージョン3以降のバージョンを実装するサーバはこの属性を提供しなければならない(MUST)。バージョン2だけを実装するサーバはこの属性を提供しなくてもよい。

4.1. 共通の要素 

このセクションでは、LDAPMessageエンベロープPDU(Protocol Data Unit)のフォーマット、およびプロトコルオペレーションで用いるデータ型定義を記述する。

4.1.1. Message Envelope 

プロトコルの交換を行う際、すべてのプロトコルオペレーションは、LDAPMessageという共通のエンベロープに入れられる。これは、次のように定義されている:

        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 },
                 controls       [0] Controls OPTIONAL }

        MessageID ::= INTEGER (0 .. maxInt)

        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

LDAPMessageの役割は、すべてのプロトコル交換に必要な共通のフィールドを含んだエンベロープを提供することである。現時点での唯一の共通のフィールドは、メッセージIDとコントロールである。

サーバは、クライアントから以下に述べるPDUを受けとるときには、resultCode protocolErrorを用いて、セクション4.4.1で記述される切断の告知を返して、直ちに接続を閉じなければならない(MUST)。 — LDAPMessage SEQUENCEタグが認識できない、messageIDを解析できない、protocolOpのタグが要求として認識されない、符号化構造あるいはデータフィールド長が誤っている — サーバがクライアントから受取った要求を解析できない他の場合は、サーバはresultCodeをprotocolErrorに設定し、要求に対する適切な応答を返さなければならない(MUST)

クライアントがサーバから解析できないPDUを受取った場合、クライアントは、PDUを破棄しても良い、もしくは、告知せずに接続を閉じてもよい。

ASN.1型コントロールは、セクション4.1.2で定義されている。

4.1.1.1. メッセージID  

応答をカプセル化しているすべての LDAPMessageエンベロープは、要求LDAPMessageに対応するmessageIDを含んでいる。

要求メッセージIDの値は、そのメッセージが属しているLDAPセッションの、他の未処理の要求メッセージの値とは異なったものでなくてはならない(MUST)

クライアントは以前の要求に対する最終的な応答を受けていない限り、同じコネクション上で以前の要求と同じメッセージIDである要求を送ってはならない(MUST NOT)。そうでない場合の動作は未定義である。一般的なクライアントはそれぞれの要求に対してカウンタの値を増加させる。

abandonRequest自身は応答をもたないので、クライアントはabandonRequestの次に実行されたもう1つの要求に対する応答を受け取るまで、abandonRequestあるいは破棄されたオペレーションのメッセージIDを再利用してはならない(MUST NOT)

4.1.2. 文字列の型 

LDAPStringは表記上の便宜を図ったものであり、これが示しているのは、LDAPString型の文字列はOCTET STRING型として符号化されるが、ISO 10646[13]文字集合(Unicodeのスーパーセット)が使用されていることであり、UTF-8アルゴリズム[14]に従って符号化されていることである。UTF-8アルゴリズムでは、ASCII(0x0000 から 0x007Fまで)文字は1バイトの同じASCIIキャラクタとして表現されることに注意。他のバイト値は他の任意の文字の可変長符号化に使用される。

        LDAPString ::= OCTET STRING

LDAPOIDは表記上の便宜を図ったものである。これが示しているのは、この文字列に許されている値は、OBJECT IDENTIFIERの(UTF-8によって符号化された)ドットで区切られた10進表記であるということである。

        LDAPOID ::= OCTET STRING

例えば

        1.3.6.1.4.1.1466.1.2.3

4.1.3. 識別名と相対識別名 

LDAPDNと相対LDAPDN は、それぞれ以下のように、[4]の仕様に従って符号化された後の識別名と相対識別名の表記であると定義されている。

        <distinguished-name> ::= <name>

        <relative-distinguished-name> ::= <name-component>

ここで<name>と<name-component>は[4]で定義された通りである。

        LDAPDN ::= LDAPString

        RelativeLDAPDN ::= LDAPString

相対識別名の構成要素には属性型だけが存在し得る;属性記述(次のセクション)のオプションは識別名を指定する際には使用してはならない(MUST NOT)

4.1.4. 属性型 

属性型は、その仕様中のAttributeTypeに関連付けられているテキスト文字列を、その値として取る。

        AttributeType ::= LDAPString

それぞれの属性型は、割当てられた一意のOBJECT IDENTIFIERを持っている。 このIDは構成要素がドットで区切られた10進数で書かれ得る。例えば "2.5.4.10".

仕様ではまた、属性型に一つ以上のテキスト名を割当ててもよい。これらの名前は、ASCII英字、数字およびハイフンだけを含み、文字で始まらなければならない(MUST)。それらは大文字小文字を区別しない。(これらのASCII文字は、UTF-8符号化が0x00から0x7Fまでの一バイトだけであるISO 10646文字と同じである)

サーバは、属性型がテキスト名を持っている場合、検索結果で返される属性のためにテキスト名を使わなければならない(MUST)。属性型のテキスト名がない場合だけに、10進数のOBJECT IDENTIFIERが使用される。

(標準化トラックのRFCでない)二つの異なった仕様が同じ名前を選択する可能性があるため、属性型のテキスト名は一意ではない。

エントリを管理、あるいはシャドウするサーバは、サブスキーマエントリでサポートするすべての属性型をattributeTypes属性を用いてリストアップするべきである(SHOULD)。 属性のopen-ended setをサポートするサーバは、少なくとも「objectClass」属性のためのattributeTypes値を含むべきである(SHOULD)。クライアントはOBJECT IDENTIFIERや属性型と関連する他の情報を得るために、サブスキーマエントリからattributeTypes値を検索してもよい(MAY)

LDAPのこのバージョンで使用される属性型のいくつかの名前は[5]に記述されている。サーバは追加の属性型を実装してもよい。

4.1.5. AttributeDescription 

AttributeDescriptionはAttributeType定義のスーパーセットである。それは同じASN.1定義であるが、追加のオプションを指定することを認めており、それらは大文字小文字を区別しない。

        AttributeDescription ::= LDAPString

AttributeDescriptionの値は次のBNFに基づいている:

        <AttributeDescription> ::= <AttributeType> [ ";" <options> ]

        <options>  ::= <option> | <option> ";" <options>

         <option>   ::= <opt-char> <opt-char>*

         <opt-char> ::=  ASCII-equivalent letters, numbers and hyphen

正規のAttributeDescriptionの例

         cn

         userCertificate;binary

本文書では一つのオプション「binary」が定義されている。追加のオプションはIETFの標準化過程、もしくは実験的RFC中で定義されてもよい。"x-"で始まるオプションは私的実験のために予約されている。サーバではすべての組み合わせがサポートされないかもしれないが、どんなオプションがどんなAttrbuteTypeに関連付けられてもよい。

一つ以上のオプションをもつAttributeDescriptionは、オプションなしに属性型のサブタイプとして扱われる。AttributeDescription中のオプションは決して相互排除しない。実装は昇順にソートされた<options>のリストを生成しなければならない(MUST)。そして、サーバは同じAttributeTypeとオプションに対するどのふたつのAttributeTypeDescriptionも同じに扱わなければならない(MUST)。サーバは実装していないオプションを持つAttributeDescriptionは認識しない属性型として扱う。

データ型、"AttributeDescriptionList"は、0以上の属性型のリストを記述する。(要素を持たないリストは検索要求中で特別な意味を持つ)

        AttributeDescriptionList ::= SEQUENCE OF AttributeDescriptio

4.1.5.1 Binaryオプション 

AttributeDescription中に「binary」オプションが存在するなら、それは[5]でその属性のために定義されたどの文字列ベースの符号化に対しても優先する。その代わりに、属性は基本符号化規則 [11]を用いてbinary値として符号化されて転送される。binary値の構文は、属性型定義の「SYNTAX」部分で参照されるASN.1データ型定義である。

「binary」オプションの存在、あるいは不在は、プロトコルにおける属性値の転送のみに影響する;サーバはどんな特別な属性も1つのフォーマットだけで格納する。クライアントがサーバにbinaryフォーマットで属性を返すことを要求するときに、サーバがそのフォーマットを生成することができない場合は、サーバはこの属性型を認識されない属性型として扱わなければならない(MUST)。同様に、クライアントがbinaryオプションなしに名前でその属性を要求した場合、サーバがbinaryフォーマットで属性を返すことを期待してはならない(MUST NOT)

このオプションは、構文が複雑なASN.1データ型であり、その型の値の構造がクライアントによって必要とされる属性に対して使用されることが意図されている。「Certificate」と「CertificateList」がこの種の構文の例である。

4.1.6. Attribute Value 

AttributeValue型のフィールドは、AttributeValueデータ型の文字列符号化、あるいは、符号化されたbinary値を含むOCTET STRINGをその値として取り、それは、このAttributeValueに付随するAttributeDescription中に「binary」オプションが存在しているかどうかに依存する。

異なる構文と型に対する文字列符号化の定義は、他の文書、特に[5]のような関連文書に見ることができる。

        AttributeValue ::= OCTET STRING

この符号化の大きさの限界に関する定義はないことに注意;したがってプロトコル値はマルチメガバイトの属性を含んでもよい(たとえば写真)。

任意の、かつ印刷できない構文を持つ属性が定義され得る。構文がわからない場合、実装は、ただ表示を行うことやASN.1として復号化することを行ってはならない(MUST NEITHER)。実装は、元のエントリのサブスキーマを探し、そこからattributeTypesの値を検索することを試みてもよい。

クライアントは、その属性に対して定義された構文によって無効であるとされている要求中で属性値を送ってはならない(MUST NOT)

4.1.7. Attribute Value Assertion

AttributeValueAssertion型の定義は、X.500ディレクトリ標準のものと似ている。それは属性記述とその型に適した適合規則宣言値を含んでいる。

        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                assertionValue  AssertionValue }

        AssertionValue ::= OCTET STRING

attributeDescに「binary」オプションが存在する場合、それは、assertionValueが宣言値のbinary符号化であることをサーバに知らせている。

[5]で記述された値として文字列をとるすべてのユーザ属性にとって、宣言値構文は値構文と同じである。クライアントは比較要求と検索フィルタで属性値を宣言値として用いても良い。

しかし、宣言構文は、他の属性あるいは非同等適合規則の値構文とは異なっていてもよいことに注意。これらは値の部分だけを含む宣言構文を持っていてもよい。例として、X.501[6]のセクション20.2.1.8を参照

4.1.8. Attribute 

属性は、型とその型の一つ以上の値から成り立つ。(属性は、格納時に少なくとも一つの値を持たなければならない(MUST)、しかし、アクセス制御の結果として、その集合は、プロトコル中で転送される時点では空であってもよい。これはPartialAttributeList型に関するセクション4.5.2に記述されている。)

        Attribute ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

それぞれの属性値はセットの中で別個なものである(複製は許されない)。vals集合内の属性値の順序は未定義であり実装に依存する、そのためそれを頼ってはならない(MUST NOT)

4.1.9. Matching Rule Identifier

適合規則は、サーバが検索フィルタ中で受け取ったAssertionValueを、如何にして抽象データ値と比較するべきであるかを表す方法である。適合規則は宣言値の構文とサーバで行われるプロセスを定義する。

LDAPプロトコルでは、X.501(1993)の適合規則は[5]で与えられる文字列の一つ、または各部がピリオドで区切られた10進数値として、そのOBJECT IDENTIFIERの印刷可能な表記によって識別される。例えば、「caseIgnoreIA5Match」または「1.3.6.1.4.1.453.33.33」。

        MatchingRuleId ::= LDAPString

extensibleMatch検索フィルタで使用される適合規則をサポートするサーバは、matchingRules属性を用いて、それが実装している適合規則をサブスキーマエントリ中に列挙しなければならない(MUST)。サーバは、matchingRuleUse属性を用いて、属性型とそれぞれの使用され得る適合規則も列挙するべきである(SHOULD)。より豊富な情報が[5]のセクション4.4で与えられている。

4.1.10. 結果メッセージ 

LDAPResultは、本プロトコルで使用される構造体であり、サーバからクライアントに、成功か失敗かの指標を返すために使用される。サーバは種々の要求に対して、型フィールドを含むLDAPResult応答を返し、プロトコルオペレーション要求に対する最終的なステータスを示す。

        LDAPResult ::= SEQUENCE {
                resultCode      ENUMERATED {
                             success                    (0),
                             operationsError             (1),
                             protocolError               (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                (5),
                             compareTrue                 (6),

                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                                        -- 9 予約される --
                             referral                  (10), -- new
                             adminLimitExceeded          (11), -- new
                             unavailableCriticalExtension (12),  -- new
                             confidentialityRequired      (13),  -- new
                             saslBindInProgress          (14),  -- new
                             noSuchAttribute             (16),
                             undefinedAttributeType       (17),
                             inappropriateMatching        (18),
                             constraintViolation          (19),
                             attributeOrValueExists       (20),
                             invalidAttributeSyntax       (21),
                                        -- 22-31 使われていない --


                             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), -- new
                                        -- 72-79 unused --
                             other                      (80) },
                             -- 81-90 reserved for APIs --
                matchedDN       LDAPDN,
                errorMessage    LDAPString,
                referral        [3] Referral OPTIONAL }

success、compareFalseおよびcompareTrue以外のすべての結果コードは、オペレーションが完全に終了できなかったという意味として取り扱われるべきである。

結果コ−ドの大部分は、X.511エラーデータ型の問題指標に基づいたものである。16から21までの結果コードはAttributeProblemを示す、コード32,33,34と36がNameProblemを示す、コード48,49と50がSecurityProblemを示す、コード51から54までがServiceProblemを示す、そしてコード64から69までと71がUpdateProblemを示す。

クライアントが上に列挙されてない結果コードを受け取る場合、それは未知のエラー状態として取り扱われるべきである。

この構造体のerrorMessageフィールドは、サーバのオプションであるが、人間が読める形のテキストによるエラー診断を含む文字列を返すために使用してよい(端末制御とページフォーマット文字は避けるべきである)。このエラー診断は標準化されていないため、各実装では返される値を当てにしてはならない(MUST NOT)。サーバがテキストによる診断を返さない場合、LDAPResult型のerrorMessageフィールドは、長さゼロの文字列を含まなければならない(MUST)

noSuchObject、aliasProblem、invalidDNSyntax、およびaliasDereferencingProblemといったresultCodesの場合、matchedDNフィールドには、合致したエントリの中からディレクトリ中の最も下位のエントリ(オブジェクトや別名)の名前が設定される。エントリの場所を突き止めようと試みる際に、別名が実名参照されていなかった場合は、それは提供された名前の短縮形になる。あるいは、実名参照されていた場合には、X.511[8]のセクション12.5で定義されているように、その結果として得られる名前の短縮形になる。その他のresultCodesの場合はすべて、matchedDNフィールドは長さゼロの文字列に設定される。

4.1.11. 参照 

参照エラーは、問い合わせを行ったサーバが要求のターゲットエントリを持たないことを表す。LDAPResult.resultCodeフィールド値が参照なら、LDAPResultに参照フィールドが存在する。そして、他のすべてのresultCodeは存在しない。それはLDAPあるいは他のプロトコルによってアクセスできる他のサーバへの参照を含んでいる。参照はあらゆるオペレーション要求(応答のないアンバインドと破棄以外)に対する応答として返され得る。参照には少なくとも一つのURLが存在しなければならない(MUST)

参照は、singleLevelあるいは、wholeSubtree検索に対しては返されない。この場合、検索範囲が多数のネーミングコンテキストにかかり、オペレーションを終了するためにいくつかの異なったサーバとコンタクトを取らなければならないことになる。その代わりに、セクション4.5.3で記述されるように、継続参照が返される。

        Referral ::= SEQUENCE OF LDAPURL  -- one or more

        LDAPURL ::= LDAPString -- limited to characters permitted in URLs

クライアントがそのオペレーションを進めたい場合、いずれかのサーバとコンタクトを取り、参照をたどらなければならない(MUST)。すべてのURLは、同様にオペレーションを進める能力を持たなければならない(MUST)。(これが多数のサーバによってどのように成し遂げられるかは、この文書の範囲外である。)

LDAPプロトコルを実装するサーバのためのURLは[9]に従って記述される。別名が実名参照されていた場合にはURLの<dn>部分は、新しいターゲットオブジェクト名とともに存在しなければならない(MUST)。<dn>部分が存在するなら、クライアントは、オペレーションを進行させるための次の要求にこの名前を使わなければならず(MUST)、それが存在しない場合には、クライアントは元の要求中のものと同じ名前を使用する。サーバ(例えば、分散インデックスに参加している)は検索オペレーションに対する参照の中で異なるフィルタを提供してもよい。URLのフィルタ部分がLDAPURLに存在するなら、クライアントは検索を進めるための次の要求にこのフィルタを使わなければならない(MUST)。また、存在しなければ、クライアントはその検索のために使われたフィルタと同じフィルタを使わなければならない(MUST)。新しい要求の他の部分は、参照を生成した要求と同じでも異なっていても良い。

DNあるいは検索フィルタに現われているUTF-8文字(例えば、空白)はURLに関して不正である可能性があり、RFC 1738[7]で定められている通り、%を使ってエスケープされなければならない(MUST)

そのプロトコルを使ってオペレーションが行われ得るなら、他の種類のURLが返されてもよい。

4.1.12. コントロール 

コントロールは拡張情報を指定する方法である。要求の一部として送られるコントロールはその要求だけに該当し、保存されない。

        Controls ::= SEQUENCE OF Control

        Control ::= SEQUENCE {
                controlType             LDAPOID,
                criticality             BOOLEAN DEFAULT FALSE,
                controlValue            OCTET STRING OPTIONAL }

ControlTypeフィールドは、そのコントロールを一意に識別するドットで区切られた10進表記のOBJECT IDENTIFIERをUTF-8で符号化したものでなければならない(MUST)。これはコントロール名間の衝突を防ぐ。

criticalityフィールドはTRUEまたはFALSEのいずれかである。

サーバがControlTypeを認識することができ、そのControlTypeがオペレーションに適切であるなら、サーバはオペレーションを行う際にそのコントロールを利用する。

サーバがControlTypeを認識できず、criticalityフィールドがTRUEであるなら、サーバはオペレーションを行ってはならない(MUST NOT)、そして、代わりにresultCodeとしてunsupportedCriticalExtensionを返さなければならない(MUST)

コントロールがオペレーションのために適切ではなくて、criticalityフィールドがTRUEであるなら、サーバはオペレーションを行ってはならない(MUST NOT)、そして、代わりにresultCodeとしてunsupportedCriticalExtensionを返さなければならない(MUST)

コントロールが認識できない、あるいは、不適当であるがcriticalityフィールドがFALSEであるなら、サーバはコントロールを無視しなければならない(MUST)

ControlValueはコントロールに関するあらゆる情報を含み、そのフォーマットはコントロールのために定義される。サーバは、ゼロバイトを含む、controlValueオクテット文字列の任意の内容を処理するための用意をしなければならない(MUST)。その型のコントロールに関する値情報がない場合に限り、これは空となる。

本文書はどんなコントロールも定義しない。コントロールは他の文書で定義されても良い。コントロールの定義は以下の要素で成り立つ:

サーバはルートDSEのsupportedControl属性を用いて、認識されるコントロールを列挙する。

4.2. バインドオペレーション 

バインドオペレーションの役割は、クライアントとサーバ間で認証情報を交換できるようにすることである。

バインド要求は、次のように定義される:

        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バインド要求以外の要因に影響されてもよい(MAY)、例えば、下位の層のセキュリティサービスなどである。

4.2.1. バインド要求の順序制御 

いくつかのSASL認証機構のために、クライアントはBindRequestを多数回行う必要があるかも知れない。クライアントがバインドプロセスを中止したいときには、いつでもアンバインドを実行し、使用中のコネクションを放棄してもよい(MAY)。クライアントは、多階段にわたるバインドプロセスの一部として作られた二つのバインド要求の間にオペレーションを行ってはならない(MUST NOT)

クライアントは、SaslCredentialsの機構フィールドに異なった値を持ったBindRequest、あるいは、sasl以外のauthenticationChoiceを送ることによって、SASLバインドネゴシエーションを中止することができる。

クライアントがsasl機構フィールドとして空の文字列を設定してBindRequestを送る場合、サーバはresultCodeとして authMethodNotSupportedとなるBindResponseを返さなければならない(MUST)。これはクライアントが同じSASL機構で再試行する場合にバインドネゴシエーションを中止することを可能にする。

LDAPv2とは異なり、クライアントはコネクションの最初のPDUでBindRequestを送る必要はない。クライアントはどんなオペレーションを要求してもよい、そして、サーバでは、これらは非認証であるように扱われなければならない(MUST)。サーバが、ディレクトリを修正・閲覧する前に、クライアントがバインドすることを必要とする場合、バインド、アンバインド、および拡張要求以外の要求を、「operationsError」とともにリジェクトしてよい(MAY)

クライアントが、バインドをせずに要求を送りoperationsErrorを受け取ったなら、その後、バインド要求を送るかも知れない。これも失敗するか、あるいはクライアントが現在のコネクションではバインドしないことを選択するなら、クライアントはコネクションを閉じ、それからバインド要求(Bind Request)のPDUを送ることによってそれを再開する。これはLDAPの他のバージョンを実装しているサーバとの相互運用に役立つ。

クライアントはひとつのコネクション上で、クレデンシャルを変更するため複数のバインド要求を送ってもよい(MAY)。後のバインドプロセスは、コネクション上のすべての未処理オペレーションを破棄する効果を持っている。(これはサーバ実装を簡単にする。)前のバインドにおける認証は無視される。そしてそのバインドが失敗すれば、コネクションは匿名として扱われる。もしSASL暗号通信あるいは、完全性機構がすでに確立されており、その機構が資格を変更することをサポートしていないなら、クライアントは代わりに新しいコネクションを設定しなければならない(MUST)

4.2.2. 認証と他のセキュリティサービス

単純認証オプションは、最低限の認証機能を提供し、認証フィールドの内容は平文パスワードだけで成り立っている。認証あるいは、下のレイヤによって行われる暗号がない場合、オープンネットワークでは平文パスワードの使用は推奨されないことに注意。; "セキュリティに関する考察"セクションを参照。

認証が行われない場合、単純認証オプションを選択しなければならない(MUST)、そしてパスワードは長さゼロでなければならない(MUST)。(これはたいていLDAPv2クライアントによって行われる)。一般的にDNも長さゼロである。

SASL選択は、SASL[12]で使用するために定義されたどんな機構も容認する。機構フィールドは機構の名前を含む。クレデンシャルフィールドは、OCTET STRING中に認証のために使用される任意のデータを含む。SASLが使用されるいくつかのインタネットアプリケーションプロトコルと異なり、LDAP はテキストベースのものではないことに注意。従って、クレデンシャルフィールドに対して、base64変換は行われない。

なんらかのSASLベースの完全性あるいは機密性のあるサービスが利用可能になれば、サーバによって最終的なBindResponseとして、resultCode、successが転送され、クライアントがそれを受けた後、それらが効力を発する。

クライアントは、サーバがSASL EXTERNAL機構を使って下位レイヤのプロトコルから得られた認証情報を使うことを要求することができる。

4.2.3. バインド応答 

バインド応答は次のように定義される。

        BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

BindResponseは、単に、認証を求めるクライアント要求のステータスを示すサーバからの指示子で成り立っている。バインドが成功したなら、resultCodeはsuccessである。そうではない場合、次のうちの1つである。

サーバが、クライアントが要求したプロトコルバージョンをサポートしない場合、resultCode を protocolErrorに設定しなければならない(MUST)

クライアントが、resultCodeがprotocolErrorであるBindResponse応答を受け取るなら、サーバはそれ以上のオペレーションを受け取ることを望まないため、コネクションを閉じなければならない(MUST)。(これはLDAPの以前のバージョンと互換性のためである、前のバージョンではバインドが常に最初のオペレーションであって、ネゴシエーションがなかった。)

serverSaslCredsは、クライアントが、通信しているサーバの認証をすることを可能にするため、あるいは、"challenge response"認証を行うために、SASLで定義されたバインド機構の一部として使用される。クライアントがパスワード選択でバインドした、あるいは、SASL機構がクライアントに情報を返すようにサーバに要求しないなら、このフィールドは結果に含まれないべきである。

4.3. アンバインドオペレーション 

アンバインドオペレーションの役割は、プロトコルセッションを終了させることである。アンバインドオペレーションは、次のように定義される:

        UnbindRequest ::= [APPLICATION 2] NULL

アンバインドオペレーションには定義されている応答はない。プロトコルクライアントはUnbindRequestを送信したら、そのプロトコルセッションが終了するものと仮定することができる。プロトコルサーバはUnbindRequestを受け取ったら、要求を出したクライアントはセッションを終了しすべての未処理要求を削除できると仮定し、コネクションを閉じることができる。

4.4. 余計な通知 

余計な通知は、サーバからクライアントに送られるLDAPMessageである。これはサーバが受け取ったどんなLDAPMessageに対する応答でもない。それはサーバにおける、あるいはクライアントとサーバの間のコネクションにおける異常な状態を示すために使用される。この通知は忠告的であり、サーバはクライアントから応答が返されることを期待しない。

余計な通知は、messageIDが0であり、protocolOpがextendedResp形式のLDAPMessageとして構造化される。ExtendedResponseのresponseNameフィールドが存在する。LDAPOIDの値はこの通知のために一意でなければならない。そして他の状態で使われてはならない(MUST)

本文書で1つの余計な通知を定義する。

4.4.1. 切断の通知 

この通知は、クライアントにエラー状態のためにコネクションを閉じようとしていることを知らせるためにサーバによって使用される。この通知はクライアントのアンバインド要求に対する応答ではない:サーバはセクション4.3の手順を監視しなければならない(MUST)。この通知は、クライアントがエラー状態と一時的なネットワーク障害を識別するのを助けるためである。

ネットワーク障害のためのコネクション終了と同様に、クライアントは、未処理のディレクトリ修正要求の成功または失敗を仮定してはならない(MUST NOT)

ResponseNameは1.3.6.1.4.1.1466.20036であり、応答フィールドはない、そしてresultCodeは切断についての理由を示すために使用される。

次のresultCode値はこの通知で使用される:

この通知を送った後、サーバはコネクションを閉じなければならない(MUST)。この通知を受け取った後、クライアントはこのコネクションでこれ以上伝えてはならない(MUST NOT)、そして突然にコネクションを閉じてよい。

4.5. 検索オペレーション 

検索オペレーションは、自分の代わりにサーバが検索を行うことを、クライアントが要求できるようにするためのものである。これは、1つのエントリから、またはあるエントリの直下のエントリ群から、あるいはエントリのサブツリー全体から、属性を読み出すために使われ得る。

4.5.1. 検索要求 

検索要求は、次のように定義される。

        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      AttributeDescriptionList }

        Filter ::= CHOICE {
                and             [0] SET OF Filter,
                or              [1] SET OF Filter,
                not             [2] Filter,
                equalityMatch     [3] AttributeValueAssertion,
                substrings       [4] SubstringFilter,
                greaterOrEqual    [5] AttributeValueAssertion,
                lessOrEqual       [6] AttributeValueAssertion,
                present          [7] AttributeDescription,
                approxMatch       [8] AttributeValueAssertion,
                extensibleMatch    [9] MatchingRuleAssertion }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type           [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

検索要求のパラメータは次の通りである:

X.500の「list」オペレーションは、objectClass属性の存在を調べるフィルタを用いたLDAPの1レベル検索オペレーションでエミュレートすることができ、X.500の「read」オペレーションは、同じフィルタ使ったLDAPのベースオブジェクト検索オペレーションでエミュレートできることに注意。X.500とのゲートウェイを提供するサーバは、それを行ってもよいが、readやlistオペレーションを使う必要はない、そうするなら、X.500検索オペレーションと同じ意味を提供しなければならない。

4.5.2. 検索結果 (Click to original RFC)

サーバが検索要求を受け取って行った検索の結果は検索応答で返される。この検索応答はSearchResultEntry, SearchResultReference, ExtendedResponseあるいはSearchResultDoneデータタイプを含むLDAPメッセージである。

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
                objectName      LDAPDN,

                attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

実装者はPartialAttributeListがゼロの要素(そのエントリの属性のいずれも要求されなかった、あるいは、返され得ないとき)を持つ可能性があることに注意するべきである、そしてvals集合もゼロの要素を持っているかも知れないこと(型だけで要求された場合、あるいは、すべての値が結果から除外された場合)に注意するべきである。

        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL

        -- 少なくとも1つの LDAPURL 要素が存在しなければならない。

        SearchResultDone ::= [APPLICATION 5] LDAPResult

検索要求を受け取ると、サーバは必要なDITの検索を行う。

LDAPセッションがTCPのようなコネクション指向のトランスポート上にあれば、サーバはクライアントに対し、一連の別々のLDAPメッセージによる応答を返す。それぞれが検索中に見つかった1つのエントリで構成されるゼロ個以上のSearchResultEntryを含む応答があるかも知れない。また、それぞれが検索中にこのサーバによって検索されなかった区域のためのSearchResultReferenceをもつゼロ個以上の応答もあるかも知れない。SearchResultEntryそして、SearchResultReference PDUはどんな順序で来てもよい。 サーバによって返されるすべての SearchResultReference応答とすべての SearchResultEntry応答の後に、サーバは成功を示す、あるいは発生したエラーの詳細を含んでいる、SearchResultDoneをもつ1つの応答を返す。

SearchResultEntryで返される各エントリは、検索要求の「attributes」フィールドに指定された、必要であればそれに関係する値で満たされている、すべての属性を含むことになる。属性の返り値は、アクセス制御と他の管理ポリシーに従う。ある属性はバイナリフォーマットで返されるかも知れない(バイナリオプションを持っている応答のAttributeDescriptionによって示されている)。

ある属性は、エントリの属性として格納されていなくても、サーバによって作成され、SearchResultEntry属性リストのに現われることがある。クライアントはアクセス制御によって許可されたとしてもすべての属性を修正し得ると仮定してはならない(MUST NOT)

ExtendedResponse形式のLDAPMessage応答は、クライアントによって要求されたコントロールに関連付けられた情報を返すために留保される。これらは本文書の将来のバージョンで定義されるかも知れない。

4.5.3. 検索結果での継続参照 

サーバがbaseObjectによって参照されたエントリの場所を定めることは可能であったが、baseObjectにおいて、もしくはその下の範囲で、すべてのエントリを検索することが不可能である場合、サーバは、オペレーションを続けるためにそれぞれ他のサーバの集合への参照を含んでいる1つ以上のSearchResultReferenceを返してもよい。サーバは、baseObjectの場所を定めることができず、どのエントリも検索しなかったなら、SearchResultReferenceを返してはならない(MUST NOT)。この場合それは参照resultCodeを持つSearchResultDoneを返す。

下位のネーミングコンテキストを持っているサーバから提供されているインデックス情報がないためsearchResultReference応答は検索フィルタに影響されず、検索範囲内なら常に返される。

SearchResultReferenceは参照と同じデータ型である。LDAPプロトコルを実装しているサーバのためのURLは[9]によって記述される。<dn>部は、新しいターゲットオブジェクト名であるURLでなければならない(MUST)。クライアントは次の要求でこの名前を使わなければならない(MUST)。あるサーバが(例えば分散インデックス交換システムの部分)SearchResultReferenceのURLで異なったフィルタを提供してもよい。URLのフィルタ部分が LDAP URLであるなら、クライアントは、その検索を進行するための次の要求で、新しいフィルタを使わなければならない(MUST)、そして、フィルタ部分が空なら、クライアントは再び同じフィルタを使う。新しい検索要求の他の側面は、継続参照を生成した検索と同じでも異なっていても良い。

そのプロトコルを使って、オペレーションが行われ得る限り、他の種類のURLが返されるかも知れない。

SearchResultReferenceの未探検のサブツリー名はベースオブジェクト(base object)の下位である必要はない。

検索を完了するために、クライアントは返されたそれぞれのSearchResultReferenceに対し、新しい検索オペレーションを発行しなければならない(MUST)。4.11で述べる破棄オペレーションはクライアントとサーバ間のコネクション上で送られるある特定のオペレーションにだけ適用される。そして、クライアントは、異なったサーバに対して多数の未処理検索オペレーションを持っている場合、各オペレーションを一つずつ破棄しなければならない(MUST)

4.5.3.1. 例 

例えば、接続要求のあったサーバ(hosta)にはエントリ“O=MNN,C=WW"、および、エントリ"CN=Manager, O=MNN, C=WW"があるとする。そのサーバは、LDAP機能のあるサーバ(hostb)、(hostc)のどちらかは"OU=People, O=MNN, C=WW"を持っていることを知っている(一方はマスタでもう一方はシャドウ)。そしてLDAP機能のあるサーバ(hostd)は次のサブツリー、"OU=Roles,O=MNN,C=WW"を持つ。その接続要求のあったサーバに"O=MNN, C=WW"のサブツリー検索を要求されとき、以下のような応答を返す。

     SearchResultEntry for O=MNN,C=WW
     SearchResultEntry for CN=Manager,O=MNN,C=WW
     SearchResultReference {
       ldap://hostb/OU=People,O=MNN,C=WW
       ldap://hostc/OU=People,O=MNN,C=WW
     }
     SearchResultReference {
       ldap://hostd/OU=Roles,O=MNN,C=WW
     }
     SearchResultDone (success)

SearchResultReferenceをたどる時、追加のSearchResultReferenceが生成されるかもしれないことにクライアント実装者は注意するべきである。前の例を続けると、クライアントがサーバ(hostb)とコンタクトを取ってサブツリー"OU=People,O=MNN,C=WW"の検索を発行するなら、サーバは以下のように応答するかもしれない。

SearchResultEntry for OU=People,O=MNN,C=WW
     SearchResultReference {
      ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
     }
     SearchResultReference {
      ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
     }
     SearchResultDone (success)

接続要求のあったサーバは、検索のベースオブジェクトを持たないなら、クライアントに参照を返す。例えば、クライアントが"O=XYZ,C=US"のサブツリー検索を要求するなら、サーバは参照を含むSearchResultDoneだけを返すかもしれない。

SearchResultDone (referral) {
       ldap://hostg/
     }

4.6. 修正オペレーション 

修正オペレーションは、自分の代わりにサーバがエントリの修正を行うように、クライアントが要求できるようにするためのものである。修正要求は、次のように定義される。

        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
                object          LDAPDN,
                modification    SEQUENCE OF SEQUENCE {

                        operation       ENUMERATED {
                                                add     (0),
                                                delete  (1),
                                                replace (2) },
                        modification    AttributeTypeAndValues } }

        AttributeTypeAndValues ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

修正要求のパラメータは次の通りである。

サーバが修正要求を受け取って行った修正の結果は、次のように定義された修正応答で返される。

        ModifyResponse ::= [APPLICATION 7] LDAPResult

修正要求を受け取ると、サーバはDITに対して必要な修正を行うことになる。

サーバは、クライアントに対して、DIT修正がすべて成功裏に完了したこと、あるいは修正が失敗した理由を示す、1つの修正応答を返す。ここで注意しておきたいのは、修正要求に含まれる修正リストを適用するには、全体として1つアトムオペレーションであることが要求されているため、受け取った修正応答が何らかのエラーを示している場合には、DIT修正はまったく実行されておらず、また、修正応答が修正オペレーションは成功裏に完了したことを示している場合には、要求されたすべての修正が行われたと、クライアントはみなせるということである。コネクションが失敗したら修正は行ったかどうかは不確定である。

エントリから、エントリの相対識別名を形成する識別値を削除するために修正オペレーションを使ってはならない。このオペレーションを試みると、サーバはnotAllowedOnRDNエラーを返す。セクション4.9で述べるDN修正オペレーションがエントリの改名をするために使用される。

もし等価適合フィルタが、属性型のために定義されていなければ、クライアントは修正の「削除」を用いて、エントリからその属性の個々の値を削除する試みをしてはならない(MUST NOT)。その代わりに「置換」を使わなければならない(MUST)

LDAPの簡素化のために、LDAP ModifyRequest中の修正からDAP ModifyEntry中のEntryModificationsへの直接マッピンッグはなく、異なるLDAP-DAPゲートウェイの実装ではその変換に異なった手段を使うかも知れない。操作が成功する場合は、最終的なエントリ上での効果は同一でなければならない(MUST)

4.7. 追加オペレーション 

追加オペレーションは、ディレクトリエントリを追加することを、クライアントが要求できるためのものである。追加要求は次のように定義される。

        AddRequest ::= [APPLICATION 8] SEQUENCE {
                entry           LDAPDN,
                attributes      AttributeList }

        AttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

追加要求のパラメータは、次の通りである。

AddRequestが成功するためには、AddRequestのエントリフィールドで名前付けされたエントリは存在してはならない(MUST NOT)。追加されるエントリの親は存在しなければならない(MUST)。 例えば、クライアントが「CN=JS、O=Foo、C=US」を追加することを試みて、「O=Foo、C=US」エントリが存在しなかった、そして「C=US」エントリが存在した、その時サーバは「C=US」を含むmatchedDNフィールドとnoSuchObjectというエラーを返す。親エントリは存在するが、そのサーバのネーミングコンテキストにはないなら、サーバは親エントリを持っているサーバへの参照を返すべきである(SHOULD)

サーバ実装は、エントリがディレクトリ中のどこに位置するかを制限するべきではない(SHOULD NOT)。サーバは、管理者がディレクトリに追加できるエントリのクラスを制限することを容認してもよい(MAY)

追加要求を受け取ると、サーバは要求された追加を行おうとする。試みた追加の結果は、以下で定義された追加応答でクライアントに返される。

        AddResponse ::= [APPLICATION 9] LDAPResult

成功という応答はディレクトリで新しいエントリの存在を示す。

4.8. 削除オペレーション 

削除オペレーションはディレクトリからエントリを取り除くことを、クライアントが要求できるようにするためのものである。削除要求は次のように定義される:

        DelRequest ::= [APPLICATION 10] LDAPDN

削除要求は削除されるエントリの識別名だけから成り立っている。取り去るターゲットエントリの名前を解析する際、サーバは別名を実名参照しないこと、そしてこのオペレーションでは、リーフのオブジェクト(下位エントリを持っていないもの)のみを削除できることに注意しておこう。

削除要求を受け取ると、サーバが試みた削除の結果は、以下のように定義された削除応答返される。:

        DelResponse ::= [APPLICATION 11] LDAPResult

削除応答を受け取ると、サーバは要求されたエントリの削除を行おうとする。試みた削除の結果は、削除応答でクライアントに返させる。

4.9. DN修正オペレーション 

DN修正オペレーションは、ディレクトリ内で、エントリ名の一番左の構成要素を、クライアントが変更できる、あるいは、エントリのサブツリーをディレクトリの新しい場所へ移動できるようにするためのものである。

DN修正要求(Modify DN Request)は次のように定義される :

        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
                entry           LDAPDN,
                newrdn          RelativeLDAPDN,
                deleteoldrdn    BOOLEAN,
                newSuperior     [0] LDAPDN OPTIONAL }

DN修正要求のパラメータは次の通りである。

DN修正要求を受け取って、サーバが試みた名前変更の結果は、以下のように定義されるDN修正応答で返される。

        ModifyDNResponse ::= [APPLICATION 13] LDAPResult

DN修正要求を受け取って、サーバは名前変更を行なおうとする。名前変更を試みた結果は、DN修正応答でクライアントに返される。

例えば、もし“entry”パラメータで名指しされたエントリが「cn=John Smith,c=US」であり、newrdnパラメータが「cn=John Cougar Smith」であって、そしてnewSuperiorパラメータが空なら、このオペレーションはエントリに「cn=John Cougar Smith、c=US」という名を付け替えることを試みる。

既にその名前を持っているエントリがあったなら、オペレーションは、エラーコードentryAlreadyExistsとして、失敗する。

deleteoldrdnパラメータがTRUEであるなら、古いRDNを形成している値はエントリから削除される。deleteoldrdnパラメータがFALSEであるなら、古いRDNを形成している値は、エントリの非別属性値として保持される。deleteoldrdnパラメータの設定がエントリでスキーマと矛盾を起こすなら、サーバは、エラーコードを返して、オペレーションを行なわなくてもよい。

X.500は一つのサーバ中のエントリだけに影響するようにModifyDNオペレーションを制限することに注意。もしLDAPサーバがDAPにマッピングされるなら、その場合にこの制限が適用され、このエラーが発生したら、resultCodeがaffectsMultipleDSAsとして返される。一般にクライアントが、サーバ間で、エントリとサブツリーの任意の動きを行うことが可能であることを期待してはならない(MUST NOT)

4.10. 比較オペレーション 

比較オペレーションは、ディレクトリ中のエントリとともに提供される宣言を、クライアントが比較できるようにするためのものである。比較要求は、次のように定義される。

        CompareRequest ::= [APPLICATION 14] SEQUENCE {
                entry           LDAPDN,
                ava             AttributeValueAssertion }

比較要求のパラメータは次の通りである。

比較要求を受け取って、サーバが試みた比較の結果は、以下のように定義されている比較応答で返される。

        CompareResponse ::= [APPLICATION 15] LDAPResult

比較要求を受け取ると、サーバは要求された比較を行なおうとする。比較の結果は、比較応答でクライアントに返される。エラーおよび比較の結果は、同じ構造体に入れて返されることに注意。

あるディレクトリシステムは、userPasswordのような特定の属性値を比較することは認めるが、読み出すことは認めないアクセス制御を行うかも知れないことに注意。検索結果ではその型の属性が返されるかも知れないが、値が空のセットである。

4.11. 破棄オペレーション 

破棄オペレーションの役割は、未処理のオペレーションをサーバが放棄するよう、クライアントが要求できるようにすることである。破棄要求は、次のように定義される。:

        AbandonRequest ::= [APPLICATION 16] MessageID

MessageIDは、この接続で、以前に要求されたオペレーションのものでなければならならない(MUST)

(破棄要求自身がメッセージIDを持つ。これは破棄される以前のオペレーションのIDとは異なっている。)

破棄オペレーションには定義された応答はない。破棄オペレーションの転送によって、クライアントは、要求中のMessageIDで識別されるオペレーションは、破棄されたものと考えてよい。検索に対する応答を転送している最中に、サーバが、検索オペレーションに対する破棄要求を受け取るなら、そのサーバは、すぐに破棄された要求に対するエントリ応答を転送することをやめなければならない(MUST)、そしてSearchResponseDoneを送ってはならない(MUST NOT)。もちろん、サーバは、正しく符号化されたLDAPMessageのPDUだけが送られることを保証しなければならない(MUST)

クライアントは、同じオペレーションのために複数回破棄要求を送ってはならない(MUST NOT)、そして、それが破棄したオペレーションから結果を受け取る用意をしなければならない(MUST)(破棄が要求されたときこれらは転送中であったかも知れないから)。

サーバが、識別できないメッセージID、破棄されないオペレーション、そして既に破棄されたオペレーションに対する破棄要求を破棄しなければならない(MUST)

4.12. 拡張オペレーション 

本プロトコル中で他のところで利用できないサービスのために、追加のオペレーションを定義することを可能にするため、このバージョンのLDAPには、拡張機構が追加されている。例えば、電子署名されたオペレーションと結果のためである。

拡張されたオペレーションは、クライアントが、定められた構文と意味に沿って要求行い、応答を受け取ることを認める。これらはRFCで定義されるか、あるいは特定の実装の私的なものであるかも知れない。それぞれの要求はそれに割り当てられた一意のオブジェクト識別子(OBJECT IDENTIFIER)を持たなければならない(MUST)

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
                requestName      [0] LDAPOID,
                requestValue     [1] OCTET STRING OPTIONAL }

RequestNameは要求に対応しているオブジェクト識別子(OBJECT IDENTIFIER)のドットで区切られた10進数である。RequestValueは、その要求によって定義された形式で、OCTET STRINGの中にカプセル化された情報である。

サーバがこれにExtendedResponseを含むLDAPMessageで返答する。

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
                COMPONENTS OF LDAPResult,
                responseName     [10] LDAPOID OPTIONAL,
                response         [11] OCTET STRING OPTIONAL }

サーバが要求名を認識しないなら、それは、protocolError結果コードを含むLDAPResultから、応答フィールドだけを返さなければならない(MUST)

5 プルトコル要素符号化と転送 

基礎となっているサービスの1つがここで定義される。クライアントとサーバは5.2.1で記述されているLDAPのTCP上へのマッピングを実装するべきである(SHOULD)

5.1. BERに基づいたトランスポートサービスヘのマッピング 

LDAPのプロトコル要素は、やり取りを行う際、ASN.1[3]の基本符号化規則BER[11]を使って符号化される。しかし、BERのある種の要素を使うとオーバーヘッドが大きくなってしまうため、LDAPプロトコル要素のBER符号化では、次のような制約を付加している:

  1. 固定長形式の符号化のみ使用される。

  2. ブール代数型の値がTRUEであるなら、符号化はこれに含まれるオクテットを、16進数で"FF"にセットしなければならない(MUST HAVE)

  3. 型の値がそのディフォルト値であるなら、それは空でなければならない(MUST)。本プロトコル定義で、いくつかのブールと整数タイプだけがディフォルト値を持っている

別に記述されない限り、これらの制限は、属性値のようなOCTET STRING値内部のカプセル化されたASN.1型には適用されない。

5.2. 転送プロトコル 

本プロトコルは、オクテット中の全8ビットがデータストリーム中で意味を持つような、コネクション指向の信頼性のあるトランスポート層上で動作するように、設計されている。

5.2.1. Transmission Control Protocol (TCP)

LDAPMessage PDUはTCPのバイトストリームに直接マッピングすることができる。TCP上で動作するサーバの実装は、389番ポートにプロトコルリスナを用意しなければならない。 サーバはその代わりに異なったポート番号でリスナを提供してもよい(MAY)。クライアントはあらゆる有効なTCPポートに対しても通信サーバをサポートしなければならない(MUST)

6 実装ガイドライン 

この文書はインターネットプロトコルを記述する。

6.1. サーバ実装 

サーバはすべての必須属性型名を認識できる能力をもち、[5]で指定された構文を実装しなければならない。サーバは追加の属性型名を認識してもよい(MAY)

6.2. クライアント実装 

参照を要求するクライアントは、サーバ間でループしないことを保証しなければならない(MUST)。それらは、同じサーバに対して、同じターゲットエントリ名、範囲、およびフィルタで、同じ要求を繰り返してはならない(MUST NOT)。クライアントは、オペレーションの際に、参照の取扱いをするたびに増加されるカウンタを使ってもよい(MAY)。この種のクライアントはルートとリーフのエントリの間に少なくとも10層のネーミングコンテキストがあるDITを処理できなければならない(MUST)

サーバとの事前の合意がない場合は、クライアントは、サーバがセクション6.1の参考文献をこえた特別なスキーマをサポートしていることを仮定するべきではない(SHOULD)。異なったスキーマは同じ名前で異なった属性型を持つことができる。クライアントは、サブスキーマサブエントリ属性によって参照されている、サーバのルートDSE、あるいはサーバの保持するエントリにあるサブスキーマエントリを検索することができる。

7 セキュリティに関する考察 

コネクション指向のトランスポートが使用されるとき、プロトコルのこのバージョンは、LDAPv2の認証機構のために、平文パスワードを使う単純認証、およびSASL機構[12]を提供する。SASLによって、完全性とプライバシーに関するやりとりが可能になる。

もしそうすることを選ぶなら、サーバは、クライアントにそのクレデンシャルを返すことも許される。

平文パスワードの使用は、下位のトランスポートサービスが機密性を保証することができない、および、認証されていない関係者へのパスワードの公開という結果になる可能性があるところでは、まったく推奨できない。

SASLが使用される時、BindRequestの名前フィールドは修正に対して保護されていないことに注意するべきである。そのため、クライアントの識別名(LDAPDN)は、クレデンシャルのやり取りによって同意されれば、保護されていない名前フィールド内のどんな値に対しても優先権を持つ。

LDAPによって得られた属性とエントリをキャッシュする実装は、多数のクライアントに情報を供給する場合、アクセスコントロールの維持を保証しなければならない(MUST)。これは、サーバが、特定の認証されたクライアント以外に、検索結果としてエントリあるいは属性を返させないようなアクセスコントロールポリシーを持っているかも知れないからである。例えば、結果情報をキャッシュする要求を出したクライアントだけにキャッシュを提供する。

8 謝辞 

この文書はWengyik Yeong、Tim HowesおよびSteve Kille によって書かれたRFC 1777の更新である。本文書に含められたデザインのアイディアはASIDと他のIETFワーキンググループで論じられた考えに基づいている。このワーキンググループの個人の貢献に対し、こころより謝意を表明する。

9 参考文献 

[1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service",  1993.

[2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.

[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994.

[4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.

[5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[6] ITU-T Rec. X.501, "The Directory: Models", 1993.

[7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource  Locators (URL)", RFC 1738, December 1994.

[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.

[9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997. 

[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994.

[12] Meyers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.

[13] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.

[14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.

10 著者の連絡先 

   Mark Wahl
   Critical Angle Inc.
   4815 W Braker Lane #502-385
   Austin, TX 78759
   USA

   Phone:  +1 512 372-3160
   EMail:  M.Wahl@critical-angle.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd., MS MV068
   Mountain View, CA 94043
   USA

   Phone:  +1 650 937-3419
   EMail:   howes@netscape.com

   Steve Kille
   Isode Limited
   The Dome, The Square
   Richmond
   TW9 1DT
   UK

   Phone:  +44-181-332-9091
   EMail:  S.Kille@isode.com

Appendix A - Complete ASN.1 Definition

        Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
        IMPLICIT TAGS ::=

        BEGIN

        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 },
                 controls       [0] Controls OPTIONAL }

        MessageID ::= INTEGER (0 .. maxInt)

        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

        LDAPString ::= OCTET STRING

        LDAPOID ::= OCTET STRING

        LDAPDN ::= LDAPString

        RelativeLDAPDN ::= LDAPString

        AttributeType ::= LDAPString

        AttributeDescription ::= LDAPString

        AttributeDescriptionList ::= SEQUENCE OF
                AttributeDescription

        AttributeValue ::= OCTET STRING

        AttributeValueAssertion ::= SEQUENCE {
                attributeDesc   AttributeDescription,
                assertionValue  AssertionValue }

        AssertionValue ::= OCTET STRING

        Attribute ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        MatchingRuleId ::= LDAPString

        LDAPResult ::= SEQUENCE {
                resultCode      ENUMERATED {
                             success                      (0),
                             operationsError              (1),
                             protocolError                (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                 (5),
                             compareTrue                  (6),
                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                                        -- 9 reserved --
                             referral                     (10),  -- new
                             adminLimitExceeded           (11),  -- new
                             unavailableCriticalExtension (12),  -- new
                             confidentialityRequired      (13),  -- new
                             saslBindInProgress           (14),  -- new
                             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), -- new
                                        -- 72-79 unused --
                             other                        (80) },
                             -- 81-90 reserved for APIs --
                matchedDN       LDAPDN,
                errorMessage    LDAPString,
                referral        [3] Referral OPTIONAL }

        Referral ::= SEQUENCE OF LDAPURL

        LDAPURL ::= LDAPString -- limited to characters permitted in URLs

        Controls ::= SEQUENCE OF Control

        Control ::= SEQUENCE {
                controlType             LDAPOID,
                criticality             BOOLEAN DEFAULT FALSE,
                controlValue            OCTET STRING OPTIONAL }

        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 }

        BindResponse ::= [APPLICATION 1] SEQUENCE {

             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

        UnbindRequest ::= [APPLICATION 2] NULL

        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      AttributeDescriptionList }

        Filter ::= CHOICE {
                and             [0] SET OF Filter,
                or              [1] SET OF Filter,
                not             [2] Filter,
                equalityMatch   [3] AttributeValueAssertion,
                substrings      [4] SubstringFilter,
                greaterOrEqual  [5] AttributeValueAssertion,
                lessOrEqual     [6] AttributeValueAssertion,
                present         [7] AttributeDescription,
                approxMatch     [8] AttributeValueAssertion,
                extensibleMatch [9] MatchingRuleAssertion }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
                objectName      LDAPDN,
                attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL

        SearchResultDone ::= [APPLICATION 5] LDAPResult

        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
                object          LDAPDN,
                modification    SEQUENCE OF SEQUENCE {
                        operation       ENUMERATED {
                                                add     (0),
                                                delete  (1),
                                                replace (2) },
                        modification    AttributeTypeAndValues } }

        AttributeTypeAndValues ::= SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        ModifyResponse ::= [APPLICATION 7] LDAPResult

        AddRequest ::= [APPLICATION 8] SEQUENCE {
                entry           LDAPDN,
                attributes      AttributeList }

        AttributeList ::= SEQUENCE OF SEQUENCE {
                type    AttributeDescription,
                vals    SET OF AttributeValue }

        AddResponse ::= [APPLICATION 9] LDAPResult

        DelRequest ::= [APPLICATION 10] LDAPDN

        DelResponse ::= [APPLICATION 11] LDAPResult

        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
                entry           LDAPDN,
                newrdn          RelativeLDAPDN,
                deleteoldrdn    BOOLEAN,
                newSuperior     [0] LDAPDN OPTIONAL }

        ModifyDNResponse ::= [APPLICATION 13] LDAPResult

        CompareRequest ::= [APPLICATION 14] SEQUENCE {
                entry           LDAPDN,
                ava             AttributeValueAssertion }

        CompareResponse ::= [APPLICATION 15] LDAPResult

        AbandonRequest ::= [APPLICATION 16] MessageID

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
                requestName      [0] LDAPOID,
                requestValue     [1] OCTET STRING OPTIONAL }

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
                COMPONENTS OF LDAPResult,
                responseName     [10] LDAPOID OPTIONAL,
                response         [11] OCTET STRING OPTIONAL }

        END

 

 

 

Full Copyright Statement

     Copyright (C) The Internet Society (1997).  All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.