[要約] RFC 2251は、LDAP（Lightweight Directory Access Protocol）のバージョン3に関する仕様を定めたものであり、ディレクトリサービスへのアクセスを容易にするためのプロトコルです。このRFCの目的は、LDAPの機能や動作の詳細を定義し、ディレクトリサービスの効率的な利用を促進することです。
Network Working Group M. Wahl
Request for Comments: 2251 Critical Angle Inc.
Category: Standards Track T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997
Lightweight Directory Access Protocol (v3)
ライトウェイトディレクトリアクセスプロトコル（v3）
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
IESG Note
IESG Note
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
このドキュメントでは、読み取りアクセスと更新アクセスの両方を提供するディレクトリアクセスプロトコルについて説明します。更新アクセスには安全な認証が必要ですが、このドキュメントでは満足できる認証メカニズムの実装を義務付けていません。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
RFC 2026のセクション4.4.1に従って、この仕様は次の理由により、この制限にもかかわらず、提案された標準としてIESGによって承認されています。
a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and
a。展開する前に、これらのプロトコルの実装と相互運用性テスト（更新アクセスありまたはなし）を促進するため。
b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and
b。読み取り専用アプリケーションでのこれらのプロトコルの導入と使用を促進するため。 （たとえば、LDAPv3がLDAP以外の安全なメカニズムによって更新されるディレクトリのクエリ言語として使用されるアプリケーション）、および
c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.
c。 LDAPv3ディレクトリサーバーを更新するのではなく、照会する機能を必要とする他のインターネット標準トラックプロトコルの進歩と展開の遅延を回避するため。
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
読者は、必須の認証メカニズムが標準化されるまで、更新機能を利用するこの仕様に従って作成されたクライアントとサーバーは、相互運用が不可能であるか、認証が許容できない弱いレベルに低下した場合にのみ相互運用が可能であることを警告します。
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
これにより、実装者は、LDAPv3での必須認証の提案された標準が承認され、RFCとして公開されるまで、更新機能を実装するLDAPv3クライアントまたはサーバーのデプロイを推奨しません。
Table of Contents
目次
1. Status of this Memo .................................... 1
Copyright Notice ....................................... 1
IESG Note .............................................. 1
2. Abstract ............................................... 3
3. Models ................................................. 4
3.1. Protocol Model ........................................ 4
3.2. Data Model ............................................ 5
3.2.1. Attributes of Entries ............................... 5
3.2.2. Subschema Entries and Subentries .................... 7
3.3. Relationship to X.500 ................................. 8
3.4. Server-specific Data Requirements ..................... 8
4. Elements of Protocol ................................... 9
4.1. Common Elements ....................................... 9
4.1.1. Message Envelope .................................... 9
4.1.1.1. Message ID ........................................ 11
4.1.2. String Types ........................................ 11
4.1.3. Distinguished Name and Relative Distinguished Name .. 11
4.1.4. Attribute Type ...................................... 12
4.1.5. Attribute Description ............................... 13
4.1.5.1. Binary Option ..................................... 14
4.1.6. Attribute Value ..................................... 14
4.1.7. Attribute Value Assertion ........................... 15
4.1.8. Attribute ........................................... 15
4.1.9. Matching Rule Identifier ............................ 15
4.1.10. Result Message ..................................... 16
4.1.11. Referral ........................................... 18
4.1.12. Controls ........................................... 19
4.2. Bind Operation ........................................ 20
4.2.1. Sequencing of the Bind Request ...................... 21
4.2.2. Authentication and Other Security Services .......... 22
4.2.3. Bind Response ....................................... 23
4.3. Unbind Operation ...................................... 24
4.4. Unsolicited Notification .............................. 24
4.4.1. Notice of Disconnection ............................. 24
4.5. Search Operation ...................................... 25
4.5.1. Search Request ...................................... 25
4.5.2. Search Result ....................................... 29
4.5.3. Continuation References in the Search Result ........ 31
4.5.3.1. Example ........................................... 31
4.6. Modify Operation ...................................... 32
4.7. Add Operation ......................................... 34
4.8. Delete Operation ...................................... 35
4.9. Modify DN Operation ................................... 36
4.10. Compare Operation .................................... 37
4.11. Abandon Operation .................................... 38
4.12. Extended Operation ................................... 38
5. Protocol Element Encodings and Transfer ................ 39
5.1. Mapping Onto BER-based Transport Services ............. 39
5.2. Transfer Protocols .................................... 40
5.2.1. Transmission Control Protocol (TCP) ................. 40
6. Implementation Guidelines .............................. 40
6.1. Server Implementations ................................ 40
6.2. Client Implementations ................................ 40
7. Security Considerations ................................ 41
8. Acknowledgements ....................................... 41
9. Bibliography ........................................... 41
10. Authors' Addresses ..................................... 42
Appendix A - Complete ASN.1 Definition ..................... 44
Full Copyright Statement ................................... 50
The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. When used with a directory supporting the X.500 protocols, it is intended to be a complement to the X.500 DAP.
このドキュメントで説明するプロトコルは、X.500モデルをサポートするディレクトリへのアクセスを提供するように設計されていますが、X.500ディレクトリアクセスプロトコル（DAP）のリソース要件は発生しません。このプロトコルは、ディレクトリへの読み取り/書き込みインタラクティブアクセスを提供する管理アプリケーションおよびブラウザアプリケーションを特に対象としています。 X.500プロトコルをサポートするディレクトリで使用する場合、X.500 DAPを補完することを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [10].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、および「MAY」は、次のように解釈されますRFC 2119 [10]に記述されています。
Key aspects of this version of LDAP are:
このバージョンのLDAPの主な側面は次のとおりです。
- All protocol elements of LDAPv2 (RFC 1777) are supported. The protocol is carried directly over TCP or other transport, bypassing much of the session/presentation overhead of X.500 DAP.
- LDAPv2（RFC 1777）のすべてのプロトコル要素がサポートされています。プロトコルは、TCPまたは他のトランスポートを介して直接伝送され、X.500 DAPのセッション/プレゼンテーションオーバーヘッドの多くをバイパスします。
- Most protocol data elements can be encoded as ordinary strings (e.g., Distinguished Names).
- ほとんどのプロトコルデータ要素は、通常の文字列（識別名など）としてエンコードできます。
- Referrals to other servers may be returned.
- 他のサーバーへの紹介が返される場合があります。
- SASL mechanisms may be used with LDAP to provide association security services.
- SASLメカニズムをLDAPとともに使用して、関連付けセキュリティサービスを提供できます。
- Attribute values and Distinguished Names have been internationalized through the use of the ISO 10646 character set.
- 属性値と識別名は、ISO 10646文字セットを使用して国際化されています。
- The protocol can be extended to support new operations, and controls may be used to extend existing operations.
- プロトコルは、新しい操作をサポートするように拡張でき、コントロールを使用して既存の操作を拡張できます。
- Schema is published in the directory for use by clients.
- スキーマは、クライアントが使用できるようにディレクトリに公開されます。
Interest in X.500 [1] directory technologies in the Internet has led to efforts to reduce the high cost of entry associated with use of these technologies. This document continues the efforts to define directory protocol alternatives, updating the LDAP [2] protocol specification.
インターネットでのX.500 [1]ディレクトリテクノロジーへの関心により、これらのテクノロジーの使用に関連する高額なエントリコストを削減する取り組みが進んでいます。このドキュメントは、LDAP [2]プロトコル仕様を更新して、ディレクトリプロトコルの代替を定義する取り組みを続けています。
The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the directory. Upon completion of the operation(s), the server returns a response containing any results or errors to the requesting client.
このプロトコルで採用されている一般的なモデルは、サーバーに対してプロトコル操作を実行するクライアントの1つです。このモデルでは、クライアントは実行する操作を記述したプロトコル要求をサーバーに送信します。サーバーは、ディレクトリで必要な操作を実行する責任があります。操作が完了すると、サーバーは結果またはエラーを含む応答を要求元のクライアントに返します。
In keeping with the goal of easing the costs associated with use of the directory, it is an objective of this protocol to minimize the complexity of clients so as to facilitate widespread deployment of applications capable of using the directory.
ディレクトリの使用に関連するコストを軽減するという目標に沿って、このプロトコルの目的は、クライアントの複雑さを最小限に抑え、ディレクトリを使用できるアプリケーションの広範な展開を容易にすることです。
Note that although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behavior on the part of either clients or servers. Requests and responses for multiple operations may be exchanged between a client and server in any order, provided the client eventually receives a response for every request that requires one.
サーバーで応答がプロトコルで定義されている場合は常に応答を返す必要がありますが、クライアントまたはサーバー側での同期動作の要件はありません。複数の操作の要求と応答は、クライアントとサーバーの間で任意の順序で交換できます。ただし、クライアントが最終的に要求を必要とするすべての要求に対する応答を受信する場合に限ります。
In LDAP versions 1 and 2, no provision was made for protocol servers returning referrals to clients. However, for improved performance and distribution this version of the protocol permits servers to return to clients referrals to other servers. This allows servers to offload the work of contacting other servers to progress operations.
LDAPバージョン1および2では、クライアントに紹介を返すプロトコルサーバーの準備は行われていませんでした。ただし、パフォーマンスと配信を向上させるために、このバージョンのプロトコルでは、サーバーが他のサーバーへのクライアントの紹介に戻ることができます。これにより、サーバーは他のサーバーに接続して操作を進める作業をオフロードできます。
Note that the core protocol operations defined in this document can be mapped to a strict subset of the X.500(1997) directory abstract service, so it can be cleanly provided by the DAP. However there is not a one-to-one mapping between LDAP protocol operations and DAP operations: server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests.
このドキュメントで定義されているコアプロトコル操作は、X.500（1997）ディレクトリ抽象サービスの厳密なサブセットにマップできるため、DAPによって明確に提供できることに注意してください。ただし、LDAPプロトコル操作とDAP操作の間には1対1のマッピングはありません。X.500ディレクトリへのゲートウェイとして機能するサーバー実装は、複数のDAP要求を行う必要がある場合があります。
This section provides a brief introduction to the X.500 data model, as used by LDAP.
このセクションでは、LDAPで使用されるX.500データモデルの概要を説明します。
The LDAP protocol assumes there are one or more servers which jointly provide access to a Directory Information Tree (DIT). The tree is made up of entries. Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. The concatenation of the relative distinguished names of the sequence of entries from a particular entry to an immediate subordinate of the root of the tree forms that entry's Distinguished Name (DN), which is unique in the tree. An example of a Distinguished Name is
LDAPプロトコルは、ディレクトリ情報ツリー（DIT）へのアクセスを共同で提供する1つ以上のサーバーがあることを前提としています。ツリーはエントリで構成されています。エントリには名前があります。エントリからの1つまたは複数の属性値がその相対識別名（RDN）を形成し、すべての兄弟間で一意である必要があります。特定のエントリからツリーのルートのすぐ下までの一連のエントリの相対識別名を連結すると、そのエントリの識別名（DN）が形成されます。これは、ツリー内で一意です。識別名の例は次のとおりです。
CN=Steve Kille, O=Isode Limited, C=GB
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested.
一部のサーバーは、エントリのキャッシュまたはシャドウコピーを保持している場合があります。これは、検索および比較クエリへの応答に使用できますが、変更操作が要求された場合、参照を返すか、他のサーバーに連絡します。
Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
キャッシングまたはシャドウイングを実行するサーバーは、元のサーバーによってデータに課されたアクセス制御制約に違反しないことを確認する必要があります。
The largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries which are mastered by different servers, is termed a naming context. The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context: each server has different attribute values in the root DSE. (DSA is an X.500 term for the directory server).
特定のサーバーによってマスターされているエントリーから始まり、そのすべての従属サーバーとその従属サーバーを含み、さまざまなサーバーによってマスターされているエントリーまでの、エントリーの最大のコレクションは、ネーミングコンテキストと呼ばれます。 DITのルートはDSA固有のエントリ（DSE）であり、ネーミングコンテキストの一部ではありません。各サーバーのルートDSEには異なる属性値があります。 （DSAは、ディレクトリサーバーのX.500用語です）。
Entries consist of a set of attributes. An attribute is a type with one or more associated values. The attribute type is identified by a short descriptive name and an OID (object identifier). The attribute type governs whether there can be more than one value of an attribute of that type in an entry, the syntax to which the values must conform, the kinds of matching which can be performed on values of that attribute, and other functions.
エントリは一連の属性で構成されます。属性は、1つ以上の関連する値を持つタイプです。属性タイプは、短い記述名とOID（オブジェクト識別子）で識別されます。属性タイプは、エントリにそのタイプの属性の値が複数存在するかどうか、値が準拠する必要のある構文、その属性の値に対して実行できるマッチングの種類、およびその他の関数を管理します。
An example of an attribute is "mail". There may be one or more values of this attribute, they must be IA5 (ASCII) strings, and they are case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").
属性の例は「メール」です。この属性には1つ以上の値があり、IA5（ASCII）文字列でなければならず、大文字と小文字は区別されません（たとえば、「foo@bar.com」は「FOO@BAR.COM」と一致します）。
Schema is the collection of attribute type definitions, object class definitions and other information which a server uses to determine how to match a filter or attribute value assertion (in a compare operation) against the attributes of an entry, and whether to permit add and modify operations. The definition of schema for use with LDAP is given in [5] and [6]. Additional schema elements may be defined in other documents.
スキーマは、属性タイプ定義、オブジェクトクラス定義、およびサーバーがフィルターまたは属性値のアサーション（比較操作）をエントリの属性と照合する方法、および追加と変更を許可するかどうかを決定するために使用するその他の情報のコレクションです。操作。 LDAPで使用するスキーマの定義は、[5]および[6]に記載されています。追加のスキーマ要素が他のドキュメントで定義されている場合があります。
Each entry MUST have an objectClass attribute. The objectClass attribute specifies the object classes of an entry, which along with the system and user schema determine the permitted attributes of an entry. Values of this attribute may be modified by clients, but the objectClass attribute cannot be removed. Servers may restrict the modifications of this attribute to prevent the basic structural class of the entry from being changed (e.g. one cannot change a person into a country). When creating an entry or adding an objectClass value to an entry, all superclasses of the named classes are implicitly added as well if not already present, and the client must supply values for any mandatory attributes of new superclasses.
各エントリには、objectClass属性が必要です。 objectClass属性は、エントリのオブジェクトクラスを指定します。これは、システムおよびユーザースキーマとともに、エントリの許可される属性を決定します。この属性の値はクライアントによって変更される可能性がありますが、objectClass属性は削除できません。サーバーは、この属性の変更を制限して、エントリの基本的な構造クラスが変更されないようにすることができます（たとえば、人を国に変更することはできません）。エントリを作成するか、objectClass値をエントリに追加すると、指定されたクラスのすべてのスーパークラスがまだ存在しない場合は暗黙的に追加され、クライアントは新しいスーパークラスの必須属性の値を提供する必要があります。
Some attributes, termed operational attributes, are used by servers for administering the directory system itself. They are not returned in search results unless explicitly requested by name. Attributes which are not operational, such as "mail", will have their schema and syntax constraints enforced by servers, but servers will generally not make use of their values.
運用属性と呼ばれる一部の属性は、ディレクトリシステム自体を管理するためにサーバーによって使用されます。名前で明示的に要求されない限り、検索結果には返されません。 「メール」などの機能しない属性には、スキーマと構文の制約がサーバーによって強制されますが、サーバーは通常、その値を使用しません。
Servers MUST NOT permit clients to add attributes to an entry unless those attributes are permitted by the object class definitions, the schema controlling that entry (specified in the subschema - see below), or are operational attributes known to that server and used for administrative purposes. Note that there is a particular objectClass 'extensibleObject' defined in [5] which permits all user attributes to be present in an entry.
サーバーは、オブジェクトクラス定義、そのエントリを制御するスキーマ（サブスキーマで指定-下記を参照）、またはそのサーバーで認識され、管理目的で使用される操作属性でない限り、クライアントがエントリに属性を追加することを許可してはなりません（MUST NOT）。 。 [5]で定義されている特定のobjectClass 'extensibleObject'があることに注意してください。これにより、すべてのユーザー属性をエントリに含めることができます。
Entries MAY contain, among others, the following operational attributes, defined in [5]. These attributes are maintained automatically by the server and are not modifiable by clients:
エントリには、特に、[5]で定義されている次の運用属性が含まれる場合があります。これらの属性はサーバーによって自動的に維持され、クライアントは変更できません。
- creatorsName: the Distinguished Name of the user who added this entry to the directory.
- creatorsName：このエントリをディレクトリに追加したユーザーの識別名。
- createTimestamp: the time this entry was added to the directory.
- createTimestamp：このエントリがディレクトリに追加された時刻。
- modifiersName: the Distinguished Name of the user who last modified this entry.
- modifiersName：このエントリを最後に変更したユーザーの識別名。
- modifyTimestamp: the time this entry was last modified.
- modifyTimestamp：このエントリが最後に変更された時刻。
- subschemaSubentry: the Distinguished Name of the subschema entry (or subentry) which controls the schema for this entry.
- subschemaSubentry：このエントリのスキーマを制御するサブスキーマエントリ（またはサブエントリ）の識別名。
Subschema entries are used for administering information about the directory schema, in particular the object classes and attribute types supported by directory servers. A single subschema entry contains all schema definitions used by entries in a particular part of the directory tree.
サブスキーマエントリは、ディレクトリスキーマに関する情報、特にディレクトリサーバーがサポートするオブジェクトクラスと属性タイプを管理するために使用されます。 1つのサブスキーマエントリには、ディレクトリツリーの特定の部分のエントリで使用されるすべてのスキーマ定義が含まれています。
Servers which follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms, and so these subschemas are not ordinary entries. LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. A server which masters entries and permits clients to modify these entries MUST implement and provide access to these subschema entries, so that its clients may discover the attributes and object classes which are permitted to be present. It is strongly recommended that all other servers implement this as well.
X.500（93）モデルに準拠するサーバーは、X.500サブスキーマメカニズムを使用してサブスキーマを実装する必要があるため（SHOULD）、これらのサブスキーマは通常のエントリではありません。 LDAPクライアントは、サーバーがX.500サブスキーマの他の側面を実装していることを想定してはなりません（SHOULD NOT）。エントリをマスターし、クライアントがこれらのエントリを変更できるようにするサーバーは、これらのサブスキーマエントリへのアクセスを実装および提供する必要があるため、クライアントは、存在を許可されている属性とオブジェクトクラスを検出できます。他のすべてのサーバーにもこれを実装することを強くお勧めします。
The following four attributes MUST be present in all subschema entries:
次の4つの属性は、すべてのサブスキーマエントリに存在する必要があります。
- cn: this attribute MUST be used to form the RDN of the subschema entry.
- cn：この属性は、サブスキーマエントリのRDNを形成するために使用する必要があります。
- objectClass: the attribute MUST have at least the values "top" and "subschema".
- objectClass：属性には少なくとも「top」と「subschema」の値が必要です。
- objectClasses: each value of this attribute specifies an object class known to the server.
- objectClasses：この属性の各値は、サーバーに認識されているオブジェクトクラスを指定します。
- attributeTypes: each value of this attribute specifies an attribute type known to the server.
- attributeTypes：この属性の各値は、サーバーに認識されている属性タイプを指定します。
These are defined in [5]. Other attributes MAY be present in subschema entries, to reflect additional supported capabilities.
これらは[5]で定義されています。追加のサポートされている機能を反映するために、他の属性がサブスキーマエントリに存在する場合があります。
These include matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, nameForms and ldapSyntaxes.
これらには、matchingRules、matchingRuleUse、dITStructureRules、dITContentRules、nameForms、およびldapSyntaxesが含まれます。
Servers SHOULD provide the attributes createTimestamp and modifyTimestamp in subschema entries, in order to allow clients to maintain their caches of schema information.
サーバーは、クライアントがスキーマ情報のキャッシュを維持できるようにするために、サブスキーマエントリに属性createTimestampおよびmodifyTimestampを提供する必要があります（SHOULD）。
Clients MUST only retrieve attributes from a subschema entry by requesting a base object search of the entry, where the search filter is "(objectClass=subschema)". (This will allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested.)
クライアントは、検索フィルターが「（objectClass = subschema）」であるエントリの基本オブジェクト検索を要求することによって、サブスキーマエントリからのみ属性を取得する必要があります。 （これにより、X.500（93）へのゲートウェイであるLDAPv3サーバーは、サブエントリー情報が要求されていることを検出できます。）
This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.
このドキュメントでは、X.500の観点からLDAPをX.500アクセスメカニズムとして定義しています。 LDAPサーバーは、サービスを提供するときに、ITU勧告のX.500（1993）シリーズに従って動作する必要があります。ただし、このサービスの提供にLDAPサーバーがX.500プロトコルを使用する必要はありません。 LDAPで使用されているX.500データおよびサービスモデルがLDAPインターフェースで違反されていない限り、LDAPは他の任意のディレクトリシステムにマップできます。
An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root.
LDAPサーバーは、それ自体に関する情報と、各サーバーに固有のその他の情報を提供する必要があります。これは、長さ0のLDAPDNで名前が付けられているルートDSE（DSA固有のエントリ）にある属性のグループとして表されます。これらの属性は、クライアントがフィルター「（objectClass = *）」を使用してルートの基本オブジェクト検索を実行する場合に取得できますが、アクセス制御制限の対象になります。クライアントがルートから開始してサブツリー検索を実行する場合、ルートDSEを含めることはできません。
Servers may allow clients to modify these attributes.
サーバーでは、クライアントがこれらの属性を変更できるようにする場合があります。
The following attributes of the root DSE are defined in section 5 of [5]. Additional attributes may be defined in other documents.
ルートDSEの以下の属性は、[5]のセクション5で定義されています。追加の属性が他のドキュメントで定義されている場合があります。
- namingContexts: naming contexts held in the server. Naming contexts are defined in section 17 of X.501 [6].
- namingContexts：サーバーに保持されているネーミングコンテキスト。名前付けコンテキストは、X.501 [6]のセクション17で定義されています。
- subschemaSubentry: subschema entries (or subentries) known by this server.
- subschemaSubentry：このサーバーが認識しているサブスキーマエントリ（またはサブエントリ）。
- altServer: alternative servers in case this one is later unavailable.
- altServer：このサーバーが後で利用できない場合の代替サーバー。
- supportedExtension: list of supported extended operations.
- supportedExtension：サポートされている拡張操作のリスト。
- supportedControl: list of supported controls.
- supportedControl：サポートされているコントロールのリスト。
- supportedSASLMechanisms: list of supported SASL security features.
- supportedSASLMechanisms：サポートされているSASLセキュリティ機能のリスト。
- supportedLDAPVersion: LDAP versions implemented by the server.
- supportedLDAPVersion：サーバーによって実装されたLDAPバージョン。
If the server does not master entries and does not know the locations of schema information, the subschemaSubentry attribute is not present in the root DSE. If the server masters directory entries under one or more schema rules, there may be any number of values of the subschemaSubentry attribute in the root DSE.
サーバーがエントリをマスターしておらず、スキーマ情報の場所を認識していない場合、subschemaSubentry属性はルートDSEに存在しません。サーバーが1つ以上のスキーマルールの下でディレクトリエントリをマスターしている場合、ルートDSEにsubschemaSubentry属性の値がいくつあってもかまいません。
The LDAP protocol is described using Abstract Syntax Notation 1 (ASN.1) [3], and is typically transferred using a subset of ASN.1 Basic Encoding Rules [11]. In order to support future extensions to this protocol, clients and servers MUST ignore elements of SEQUENCE encodings whose tags they do not recognize.
LDAPプロトコルは、Abstract Syntax Notation 1（ASN.1）[3]を使用して記述され、通常、ASN.1 Basic Encoding Rules [11]のサブセットを使用して転送されます。このプロトコルの将来の拡張をサポートするために、クライアントとサーバーは、認識しないタグを持つSEQUENCEエンコーディングの要素を無視する必要があります。
Note that unlike X.500, each change to the LDAP protocol other than through the extension mechanisms will have a different version number. A client will indicate the version it supports as part of the bind request, described in section 4.2. If a client has not sent a bind, the server MUST assume that version 3 is supported in the client (since version 2 required that the client bind first).
X.500とは異なり、拡張メカニズム以外でLDAPプロトコルを変更すると、バージョン番号が異なることに注意してください。クライアントは、セクション4.2で説明されているように、バインド要求の一部としてサポートするバージョンを示します。クライアントがバインドを送信していない場合、サーバーはバージョン3がクライアントでサポートされていると想定する必要があります（バージョン2ではクライアントが最初にバインドする必要があるため）。
Clients may determine the protocol version a server supports by reading the supportedLDAPVersion attribute from the root DSE. Servers which implement version 3 or later versions MUST provide this attribute. Servers which only implement version 2 may not provide this attribute.
クライアントは、ルートDSEからsupportedLDAPVersion属性を読み取ることにより、サーバーがサポートするプロトコルバージョンを決定できます。バージョン3以降のバージョンを実装するサーバーは、この属性を提供する必要があります。バージョン2のみを実装するサーバーは、この属性を提供しない場合があります。
This section describes the LDAPMessage envelope PDU (Protocol Data Unit) format, as well as data type definitions which are used in the protocol operations.
このセクションでは、LDAPMessageエンベロープPDU（プロトコルデータユニット）形式と、プロトコル操作で使用されるデータ型定義について説明します。
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows:
プロトコル交換の目的で、すべてのプロトコル操作は、次のように定義される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) --
The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges. At this time the only common fields are the message ID and the controls.
LDAPMessageの機能は、すべてのプロトコル交換で必要な共通フィールドを含むエンベロープを提供することです。現時点では、共通のフィールドはメッセージIDとコントロールのみです。
If the server receives a PDU from the client in which the LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the tag of the protocolOp is not recognized as a request, or the encoding structures or lengths of data fields are found to be incorrect, then the server MUST return the notice of disconnection described in section 4.4.1, with resultCode protocolError, and immediately close the connection. In other cases that the server cannot parse the request received by the client, the server MUST return an appropriate response to the request, with the resultCode set to protocolError.
LDAPMessage SEQUENCEタグを認識できないクライアントからサーバーがPDUを受信した場合、messageIDを解析できないか、protocolOpのタグが要求として認識されないか、またはデータフィールドのエンコード構造または長さが正しくない場合、サーバーはセクション4.4.1で説明されている切断の通知をresultCode protocolErrorとともに返し、すぐに接続を閉じる必要があります。サーバーがクライアントが受信した要求を解析できない他の場合、サーバーは、resultCodeをprotocolErrorに設定して、要求に対して適切な応答を返さなければなりません（MUST）。
If the client receives a PDU from the server which cannot be parsed, the client may discard the PDU, or may abruptly close the connection.
クライアントが解析できないサーバーからPDUを受信した場合、クライアントはPDUを破棄するか、接続を突然閉じます。
The ASN.1 type Controls is defined in section 4.1.12.
ASN.1タイプのコントロールはセクション4.1.12で定義されています。
All LDAPMessage envelopes encapsulating responses contain the messageID value of the corresponding request LDAPMessage.
応答をカプセル化するすべてのLDAPMessageエンベロープには、対応する要求LDAPMessageのmessageID値が含まれています。
The message ID of a request MUST have a value different from the values of any other requests outstanding in the LDAP session of which this message is a part.
要求のメッセージIDは、このメッセージが含まれるLDAPセッションで未解決のその他の要求の値とは異なる値を持つ必要があります。
A client MUST NOT send a second request with the same message ID as an earlier request on the same connection if the client has not received the final response from the earlier request. Otherwise the behavior is undefined. Typical clients increment a counter for each request.
クライアントが以前のリクエストから最終応答を受信していない場合、クライアントは同じ接続で以前のリクエストと同じメッセージIDを持つ2番目のリクエストを送信してはなりません（MUST NOT）。それ以外の場合の動作は未定義です。一般的なクライアントは、要求ごとにカウンターを増分します。
A client MUST NOT reuse the message id of an abandonRequest or of the abandoned operation until it has received a response from the server for another request invoked subsequent to the abandonRequest, as the abandonRequest itself does not have a response.
abandonRequest自体には応答がないため、クライアントはabandonRequestの後に呼び出された別の要求に対するサーバーからの応答を受信するまで、abandonRequestまたは破棄された操作のメッセージIDを再利用してはなりません（MUST NOT）。
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as OCTET STRING types, the ISO 10646 [13] character set (a superset of Unicode) is used, encoded following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm characters which are the same as ASCII (0x0000 through 0x007F) are represented as that same ASCII character in a single byte. The other byte values are used to form a variable-length encoding of an arbitrary character.
LDAPStringは表記上の便宜です。LDAPStringタイプの文字列はOCTET STRINGタイプとしてエンコードされますが、UTF-8アルゴリズム[14]に従ってエンコードされたISO 10646 [13]文字セット（Unicodeのスーパーセット）が使用されます。 UTF-8アルゴリズムでは、ASCIIと同じ文字（0x0000から0x007F）は、同じバイトの1つのASCII文字として表されることに注意してください。他のバイト値は、任意の文字の可変長エンコーディングを形成するために使用されます。
LDAPString ::= OCTET STRING
The LDAPOID is a notational convenience to indicate that the permitted value of this string is a (UTF-8 encoded) dotted-decimal representation of an OBJECT IDENTIFIER.
LDAPOIDは、この文字列の許可された値がオブジェクト識別子の（UTF-8でエンコードされた）ドット付き10進表記であることを示すための表記上の便宜です。
LDAPOID ::= OCTET STRING
For example,
例えば、
1.3.6.1.4.1.1466.1.2.3
１。３。６。１。４。１。１４６６。１。２。３
An LDAPDN and a RelativeLDAPDN are respectively defined to be the representation of a Distinguished Name and a Relative Distinguished Name after encoding according to the specification in [4], such that
LDAPDNとRelativeLDAPDNはそれぞれ、[4]の仕様に従ってエンコードした後の識別名と相対識別名の表現となるように定義されています。
<distinguished-name> ::= <name>
<relative-distinguished-name> ::= <name-component>
where <name> and <name-component> are as defined in [4].
ここで、<name>と<name-component>は、[4]で定義されているとおりです。
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
Only Attribute Types can be present in a relative distinguished name component; the options of Attribute Descriptions (next section) MUST NOT be used in specifying distinguished names.
相対識別名コンポーネントに存在できるのは属性タイプのみです。属性の説明（次のセクション）のオプションは、識別名の指定に使用してはなりません（MUST NOT）。
An AttributeType takes on as its value the textual string associated with that AttributeType in its specification.
AttributeTypeは、その仕様としてそのAttributeTypeに関連付けられているテキスト文字列を値として受け取ります。
AttributeType ::= LDAPString
Each attribute type has a unique OBJECT IDENTIFIER which has been assigned to it. This identifier may be written as decimal digits with components separated by periods, e.g. "2.5.4.10".
各属性タイプには、割り当てられた一意のオブジェクトIDENTIFIERがあります。この識別子は、コンポーネントがピリオドで区切られた10進数として書くことができます。 「2.5.4.10」。
A specification may also assign one or more textual names for an attribute type. These names MUST begin with a letter, and only contain ASCII letters, digit characters and hyphens. They are case insensitive. (These ASCII characters are identical to ISO 10646 characters whose UTF-8 encoding is a single byte between 0x00 and 0x7F.)
仕様では、属性タイプに1つ以上のテキスト名を割り当てることもできます。これらの名前は文字で始まる必要があり、ASCII文字、数字、ハイフンのみを使用できます。大文字と小文字は区別されません。 （これらのASCII文字は、UTF-8エンコーディングが0x00と0x7Fの間の1バイトであるISO 10646文字と同一です。）
If the server has a textual name for an attribute type, it MUST use a textual name for attributes returned in search results. The dotted-decimal OBJECT IDENTIFIER is only used if there is no textual name for an attribute type.
サーバーに属性タイプのテキスト名がある場合、検索結果で返される属性にはテキスト名を使用する必要があります。ドット付き10進数のOBJECT IDENTIFIERは、属性タイプのテキスト名がない場合にのみ使用されます。
Attribute type textual names are non-unique, as two different specifications (neither in standards track RFCs) may choose the same name.
属性タイプのテキストの名前は一意ではありません。2つの異なる仕様（どちらも標準化トラックのRFCではない）が同じ名前を選択する可能性があるためです。
A server which masters or shadows entries SHOULD list all the attribute types it supports in the subschema entries, using the attributeTypes attribute. Servers which support an open-ended set of attributes SHOULD include at least the attributeTypes value for the 'objectClass' attribute. Clients MAY retrieve the attributeTypes value from subschema entries in order to obtain the OBJECT IDENTIFIER and other information associated with attribute types.
エントリをマスターまたはシャドウイングするサーバーは、attributeTypes属性を使用して、サブスキーマエントリでサポートするすべての属性タイプをリストする必要があります（SHOULD）。制限のない属性のセットをサポートするサーバーは、少なくとも 'objectClass'属性のattributeTypes値を含める必要があります（SHOULD）。クライアントは、OBJECT IDENTIFIERおよび属性タイプに関連するその他の情報を取得するために、サブスキーマエントリからattributeTypes値を取得してもよい（MAY）。
Some attribute type names which are used in this version of LDAP are described in [5]. Servers may implement additional attribute types.
このバージョンのLDAPで使用されるいくつかの属性タイプ名は、[5]で説明されています。サーバーは追加の属性タイプを実装できます。
An AttributeDescription is a superset of the definition of the AttributeType. It has the same ASN.1 definition, but allows additional options to be specified. They are also case insensitive.
AttributeDescriptionは、AttributeTypeの定義のスーパーセットです。 ASN.1定義は同じですが、追加のオプションを指定できます。また、大文字と小文字は区別されません。
AttributeDescription ::= LDAPString
A value of AttributeDescription is based on the following BNF:
AttributeDescriptionの値は、次のBNFに基づいています。
<AttributeDescription> ::= <AttributeType> [ ";" <options> ]
<options> ::= <option> | <option> ";" <options>
<option> ::= <opt-char> <opt-char>*
<opt-char> ::= ASCII-equivalent letters, numbers and hyphen
Examples of valid AttributeDescription:
有効なAttributeDescriptionの例：
cn userCertificate;binary
cn userCertificate;バイナリ
One option, "binary", is defined in this document. Additional options may be defined in IETF standards-track and experimental RFCs. Options beginning with "x-" are reserved for private experiments. Any option could be associated with any AttributeType, although not all combinations may be supported by a server.
このドキュメントでは、1つのオプション「バイナリ」を定義しています。 IETF標準トラックと実験的RFCで追加のオプションを定義できます。 「x-」で始まるオプションは、プライベートな実験用に予約されています。すべての組み合わせがサーバーでサポートされるわけではありませんが、任意のオプションを任意のAttributeTypeに関連付けることができます。
An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. Options present in an AttributeDescription are never mutually exclusive. Implementations MUST generate the <options> list sorted in ascending order, and servers MUST treat any two AttributeDescription with the same AttributeType and options as equivalent. A server will treat an AttributeDescription with any options it does not implement as an unrecognized attribute type.
1つ以上のオプションを持つAttributeDescriptionは、オプションのない属性タイプのサブタイプとして扱われます。 AttributeDescriptionにあるオプションは、相互に排他的ではありません。実装は昇順でソートされた<options>リストを生成する必要があり、サーバーは同じAttributeTypeとオプションを持つ任意の2つのAttributeDescriptionを同等として扱う必要があります。サーバーは、実装していないオプションを持つAttributeDescriptionを、認識されない属性タイプとして扱います。
The data type "AttributeDescriptionList" describes a list of 0 or more attribute types. (A list of zero elements has special significance in the Search request.)
データ型「AttributeDescriptionList」は、0個以上の属性タイプのリストを記述します。 （ゼロ要素のリストは、検索リクエストで特別な意味を持ちます。）
AttributeDescriptionList ::= SEQUENCE OF
AttributeDescription
If the "binary" option is present in an AttributeDescription, it overrides any string-based encoding representation defined for that attribute in [5]. Instead the attribute is to be transferred as a binary value encoded using the Basic Encoding Rules [11]. The syntax of the binary value is an ASN.1 data type definition which is referenced by the "SYNTAX" part of the attribute type definition.
「バイナリ」オプションがAttributeDescriptionに存在する場合、[5]でその属性に対して定義された文字列ベースのエンコーディング表現をオーバーライドします。代わりに、属性は、基本エンコーディングルール[11]を使用してエンコードされたバイナリ値として転送されます。バイナリ値の構文は、属性タイプ定義の「SYNTAX」部分で参照されるASN.1データタイプ定義です。
The presence or absence of the "binary" option only affects the transfer of attribute values in protocol; servers store any particular attribute in a single format. If a client requests that a server return an attribute in the binary format, but the server cannot generate that format, the server MUST treat this attribute type as an unrecognized attribute type. Similarly, clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option.
「バイナリ」オプションの有無は、プロトコルの属性値の転送にのみ影響します。サーバーは、特定の属性を単一の形式で格納します。クライアントがサーバーにバイナリ形式の属性を返すように要求したが、サーバーがその形式を生成できない場合、サーバーはこの属性タイプを認識されない属性タイプとして扱わなければなりません（MUST）。同様に、クライアントがバイナリオプションなしで名前で属性を要求した場合、クライアントはサーバーが属性をバイナリ形式で返すことを期待してはなりません（MUST NOT）。
This option is intended to be used with attributes whose syntax is a complex ASN.1 data type, and the structure of values of that type is needed by clients. Examples of this kind of syntax are "Certificate" and "CertificateList".
このオプションは、構文が複雑なASN.1データ型であり、その型の値の構造がクライアントに必要な属性で使用することを目的としています。この種の構文の例は、「Certificate」および「CertificateList」です。
A field of type AttributeValue takes on as its value either a string encoding of a AttributeValue data type, or an OCTET STRING containing an encoded binary value, depending on whether the "binary" option is present in the companion AttributeDescription to this AttributeValue.
タイプAttributeValueのフィールドは、「バイナリ」オプションがこのAttributeValueのコンパニオンAttributeDescriptionに存在するかどうかに応じて、AttributeValueデータタイプの文字列エンコーディング、またはエンコードされたバイナリ値を含むOCTET STRINGを値として受け取ります。
The definition of string encodings for different syntaxes and types may be found in other documents, and in particular [5].
さまざまな構文とタイプの文字列エンコーディングの定義は、他のドキュメント、特に[5]に記載されています。
AttributeValue ::= OCTET STRING
Note that there is no defined limit on the size of this encoding; thus protocol values may include multi-megabyte attributes (e.g. photographs).
このエンコードのサイズに定義された制限はないことに注意してください。したがって、プロトコル値にはマルチメガバイトの属性（写真など）が含まれる場合があります。
Attributes may be defined which have arbitrary and non-printable syntax. Implementations MUST NEITHER simply display nor attempt to decode as ASN.1 a value if its syntax is not known. The implementation may attempt to discover the subschema of the source entry, and retrieve the values of attributeTypes from it.
任意で非印刷可能な構文を持つ属性を定義できます。実装は、その構文が不明な場合、ASN.1として値を表示したり、デコードしたりしないでください。実装は、ソースエントリのサブスキーマを検出し、そこからattributeTypesの値を取得しようとする場合があります。
Clients MUST NOT send attribute values in a request which are not valid according to the syntax defined for the attributes.
クライアントは、属性に対して定義された構文に従って無効な属性値をリクエストで送信してはなりません（MUST NOT）。
The AttributeValueAssertion type definition is similar to the one in the X.500 directory standards. It contains an attribute description and a matching rule assertion value suitable for that type.
AttributeValueAssertionタイプの定義は、X.500ディレクトリ標準の定義に似ています。これには、属性の説明と、そのタイプに適したマッチングルールアサーション値が含まれています。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
If the "binary" option is present in attributeDesc, this signals to the server that the assertionValue is a binary encoding of the assertion value.
「バイナリ」オプションがattributeDescにある場合、これはassertionValueがアサーション値のバイナリエンコーディングであることをサーバーに通知します。
For all the string-valued user attributes described in [5], the assertion value syntax is the same as the value syntax. Clients may use attribute values as assertion values in compare requests and search filters.
[5]で説明されているすべての文字列値のユーザー属性について、アサーション値の構文は値の構文と同じです。クライアントは、比較要求と検索フィルターのアサーション値として属性値を使用できます。
Note however that the assertion syntax may be different from the value syntax for other attributes or for non-equality matching rules. These may have an assertion syntax which contains only part of the value. See section 20.2.1.8 of X.501 [6] for examples.
ただし、アサーション構文は、他の属性の値構文または不等一致ルールの値構文とは異なる場合があることに注意してください。これらには、値の一部のみを含むアサーション構文がある場合があります。例については、X.501 [6]のセクション20.2.1.8を参照してください。
An attribute consists of a type and one or more values of that type. (Though attributes MUST have at least one value when stored, due to access control restrictions the set may be empty when transferred in protocol. This is described in section 4.5.2, concerning the PartialAttributeList type.)
属性は、タイプとそのタイプの1つ以上の値で構成されます。 （属性は格納時に少なくとも1つの値を持つ必要がありますが、アクセス制御の制限により、プロトコルで転送されるとセットが空になる場合があります。これについては、PartialAttributeListタイプについてセクション4.5.2で説明します。）
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon.
各属性値はセット内で異なります（重複はありません）。 valsセット内の属性値の順序は定義されておらず、実装に依存するため、依存してはなりません（MUST NOT）。
A matching rule is a means of expressing how a server should compare an AssertionValue received in a search filter with an abstract data value. The matching rule defines the syntax of the assertion value and the process to be performed in the server.
マッチングルールは、サーバーが検索フィルターで受け取ったAssertionValueを抽象データ値と比較する方法を表現する手段です。マッチングルールは、アサーション値の構文とサーバーで実行されるプロセスを定義します。
An X.501(1993) Matching Rule is identified in the LDAP protocol by the printable representation of its OBJECT IDENTIFIER, either as one of the strings given in [5], or as decimal digits with components separated by periods, e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
X.501（1993）マッチングルールは、[5]で指定された文字列の1つとして、またはピリオドで区切られたコンポーネントを持つ10進数として、OBJECT IDENTIFIERの印刷可能な表現によってLDAPプロトコルで識別されます。 「caseIgnoreIA5Match」または「1.3.6.1.4.1.453.33.33」。
MatchingRuleId ::= LDAPString
Servers which support matching rules for use in the extensibleMatch search filter MUST list the matching rules they implement in subschema entries, using the matchingRules attributes. The server SHOULD also list there, using the matchingRuleUse attribute, the attribute types with which each matching rule can be used. More information is given in section 4.4 of [5].
extensibleMatch検索フィルターで使用するマッチングルールをサポートするサーバーは、matchingRules属性を使用して、サブスキーマエントリに実装するマッチングルールをリストする必要があります。サーバーは、matchingRuleUse属性を使用して、各マッチングルールを使用できる属性タイプもそこにリストする必要があります（SHOULD）。詳細は、[5]のセクション4.4に記載されています。
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. In response to various requests servers will return responses containing fields of type LDAPResult to indicate the final status of a protocol operation request.
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 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 --
authMethodNotSupported（7）、strongAuthRequired（8）、-9予約済み-紹介（10）、-新しいadminLimitExceeded（11）、-新しいunavailableCriticalExtension（12）、-新しい機密性必須（13）、-新しいsaslBindInProgress（ 14）、-新しいnoSuchAttribute（16）、undefinedAttributeType（17）、appropriateMatching（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 }
noSuchObject（32）、aliasProblem（33）、invalidDNSyntax（34）、-35未定義のisLeaf用に予約済み-aliasDereferencingProblem（36）、-37-47未使用-不適切な認証（48）、invalidCredentials（49）、不十分なアクセス権（50 ）、ビジー（51）、使用不可（52）、unwillingToPerform（53）、loopDetect（54）、-55-63未使用-namingViolation（64）、objectClassViolation（65）、notAllowedOnNonLeaf（66）、notAllowedOnRDN（67）、 entryAlreadyExists（68）、objectClassModsProhibited（69）、-70はCLDAP用に予約済み-ImpactMultipleDSAs（71）、-新規-72-79未使用-その他（80）}、-81-90はAPI用に予約済み- matchedDN LDAPDN、errorMessage LDAPString、紹介[3]紹介オプション}
All the result codes with the exception of success, compareFalse and compareTrue are to be treated as meaning the operation could not be completed in its entirety.
成功、compareFalse、compareTrueを除くすべての結果コードは、操作を完全に完了できなかったことを意味するものとして扱われます。
Most of the result codes are based on problem indications from X.511 error data types. Result codes from 16 to 21 indicate an AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem, codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54 indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an UpdateProblem.
ほとんどの結果コードは、X.511エラーデータタイプからの問題表示に基づいています。結果コード16〜21はAttributeProblemを示し、コード32、33、34および36はNameProblemを示し、コード48、49および50はSecurityProblemを示し、コード51〜54はServiceProblemを示し、コード64〜69および71はUpdateProblemを示します。 。
If a client receives a result code which is not listed above, it is to be treated as an unknown error condition.
クライアントが上記にリストされていない結果コードを受け取った場合、それは不明なエラー状態として扱われます。
The errorMessage field of this construct may, at the server's option, be used to return a string containing a textual, human-readable (terminal control and page formatting characters should be avoided) error diagnostic. As this error diagnostic is not standardized, implementations MUST NOT rely on the values returned. If the server chooses not to return a textual diagnostic, the errorMessage field of the LDAPResult type MUST contain a zero length string.
この構成のerrorMessageフィールドは、サーバーのオプションで、人間が読めるテキスト（端末制御とページのフォーマット文字は避ける必要があります）のエラー診断を含む文字列を返すために使用できます。このエラー診断は標準化されていないため、実装は返された値に依存してはなりません（MUST NOT）。サーバーがテキスト診断を返さないことを選択した場合、LDAPResultタイプのerrorMessageフィールドには長さがゼロの文字列が含まれている必要があります。
For result codes of noSuchObject, aliasProblem, invalidDNSyntax and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the directory that was matched. If no aliases were dereferenced while attempting to locate the entry, this will be a truncated form of the name provided, or if aliases were dereferenced, of the resulting name, as defined in section 12.5 of X.511 [8]. The matchedDN field is to be set to a zero length string with all other result codes.
noSuchObject、aliasProblem、invalidDNSyntax、aliasDereferencingProblemの結果コードの場合、matchedDNフィールドは、一致したディレクトリ内の最も低いエントリ（オブジェクトまたはエイリアス）の名前に設定されます。 X.511 [8]のセクション12.5で定義されているように、エントリの検索中にエイリアスが逆参照されなかった場合、これは提供された名前の切り詰められた形式、または結果の名前のエイリアスが逆参照された場合です。 matchedDNフィールドは、他のすべての結果コードで長さがゼロの文字列に設定されます。
The referral error indicates that the contacted server does not hold the target entry of the request. The referral field is present in an LDAPResult if the LDAPResult.resultCode field value is referral, and absent with all other result codes. It contains a reference to another server (or set of servers) which may be accessed via LDAP or other protocols. Referrals can be returned in response to any operation request (except unbind and abandon which do not have responses). At least one URL MUST be present in the Referral.
紹介エラーは、接続されたサーバーがリクエストのターゲットエントリを保持していないことを示します。 LDAPResult.resultCodeフィールドの値が参照である場合、紹介フィールドはLDAPResultに存在し、他のすべての結果コードにはありません。 LDAPまたは他のプロトコルを介してアクセスできる別のサーバー（またはサーバーのセット）への参照が含まれています。リフェラルは、任意の操作要求に応答して返すことができます（応答のないバインド解除と破棄を除く）。少なくとも1つのURLが紹介に存在する必要があります。
The referral is not returned for a singleLevel or wholeSubtree search in which the search scope spans multiple naming contexts, and several different servers would need to be contacted to complete the operation. Instead, continuation references, described in section 4.5.3, are returned.
参照は、検索範囲が複数のネーミングコンテキストにまたがる単一レベルまたは全体サブツリー検索では返されません。操作を完了するには、いくつかの異なるサーバーに接続する必要があります。代わりに、セクション4.5.3で説明されている継続参照が返されます。
Referral ::= SEQUENCE OF LDAPURL -- one or more
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
If the client wishes to progress the operation, it MUST follow the referral by contacting any one of servers. All the URLs MUST be equally capable of being used to progress the operation. (The mechanisms for how this is achieved by multiple servers are outside the scope of this document.)
クライアントが操作を続行したい場合は、いずれかのサーバーに接続することにより、参照を追跡する必要があります。すべてのURLは、操作を進めるために等しく使用できる必要があります。 （これが複数のサーバーによってどのように実現されるかのメカニズムは、このドキュメントの範囲外です。）
URLs for servers implementing the LDAP protocol are written according to [9]. If an alias was dereferenced, the <dn> part of the URL MUST be present, with the new target object name. If the <dn> part is present, the client MUST use this name in its next request to progress the operation, and if it is not present the client will use the same name as in the original request. Some servers (e.g. participating in distributed indexing) may provide a different filter in a referral for a search operation. If the filter part of the URL is present in an LDAPURL, the client MUST use this filter in its next request to progress this search, and if it is not present the client MUST use the same filter as it used for that search. Other aspects of the new request may be the same or different as the request which generated the referral.
LDAPプロトコルを実装するサーバーのURLは、[9]に従って記述されています。エイリアスが逆参照された場合、URLの<dn>部分が、新しいターゲットオブジェクト名とともに存在している必要があります。 <dn>部分が存在する場合、クライアントは次の要求でこの名前を使用して操作を続行する必要があります。存在しない場合、クライアントは元の要求と同じ名前を使用します。一部のサーバー（分散インデックス作成に参加しているなど）は、検索操作の参照で異なるフィルターを提供する場合があります。 URLのフィルター部分がLDAPURLに存在する場合、クライアントはこのフィルターを次のリクエストで使用してこの検索を続行する必要があり、存在しない場合、クライアントはその検索に使用したものと同じフィルターを使用する必要があります。新しいリクエストの他の側面は、紹介を生成したリクエストと同じか異なる場合があります。
Note that UTF-8 characters appearing in a DN or search filter may not be legal for URLs (e.g. spaces) and MUST be escaped using the % method in RFC 1738 [7].
DNまたは検索フィルターに表示されるUTF-8文字はURL（スペースなど）では無効であり、RFC 1738の％メソッドを使用してエスケープする必要があることに注意してください[7]。
Other kinds of URLs may be returned, so long as the operation could be performed using that protocol.
そのプロトコルを使用して操作を実行できる限り、他の種類のURLが返されることがあります。
A control is a way to specify extension information. Controls which are sent as part of a request apply only to that request and are not saved.
コントロールは、拡張情報を指定する方法です。リクエストの一部として送信されるコントロールは、そのリクエストにのみ適用され、保存されません。
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
The controlType field MUST be a UTF-8 encoded dotted-decimal representation of an OBJECT IDENTIFIER which uniquely identifies the control. This prevents conflicts between control names.
controlTypeフィールドは、コントロールを一意に識別するOBJECT IDENTIFIERのUTF-8エンコードのドット付き10進表記である必要があります。これにより、コントロール名間の競合が防止されます。
The criticality field is either TRUE or FALSE.
重要度フィールドはTRUEまたはFALSEのいずれかです。
If the server recognizes the control type and it is appropriate for the operation, the server will make use of the control when performing the operation.
サーバーがコントロールの種類を認識し、それが操作に適している場合、サーバーは操作を実行するときにコントロールを利用します。
If the server does not recognize the control type and the criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
サーバーがコントロールタイプを認識せず、重要度フィールドがTRUEの場合、サーバーは操作を実行してはならず（MUST NOT）、代わりにresultCode unsupportedCriticalExtensionを返さなければなりません（MUST）。
If the control is not appropriate for the operation and criticality field is TRUE, the server MUST NOT perform the operation, and MUST instead return the resultCode unsupportedCriticalExtension.
コントロールが操作に適しておらず、重要度フィールドがTRUEの場合、サーバーは操作を実行してはならず（MUST NOT）、代わりにresultCode unsupportedCriticalExtensionを返さなければなりません（MUST）。
If the control is unrecognized or inappropriate but the criticality field is FALSE, the server MUST ignore the control.
コントロールが認識されないか不適切であるが、重要度フィールドがFALSEの場合、サーバーはコントロールを無視する必要があります。
The controlValue contains any information associated with the control, and its format is defined for the control. The server MUST be prepared to handle arbitrary contents of the controlValue octet string, including zero bytes. It is absent only if there is no value information which is associated with a control of its type.
controlValueには、コントロールに関連するすべての情報が含まれており、そのフォーマットはコントロールに対して定義されています。サーバーは、ゼロバイトを含む、controlValueオクテット文字列の任意のコンテンツを処理できるように準備する必要があります。そのタイプのコントロールに関連付けられている値情報がない場合にのみ存在します。
This document does not define any controls. Controls may be defined in other documents. The definition of a control consists of:
このドキュメントでは、コントロールを定義していません。コントロールは他のドキュメントで定義できます。コントロールの定義は以下で構成されます。
- the OBJECT IDENTIFIER assigned to the control,
- コントロールに割り当てられたオブジェクトIDENTIFIER
- whether the control is always noncritical, always critical, or critical at the client's option,
- コントロールが常に非クリティカル、常にクリティカル、またはクライアントのオプションでクリティカルであるかどうか
- the format of the controlValue contents of the control.
- コントロールのcontrolValueコンテンツの形式。
Servers list the controls which they recognize in the supportedControl attribute in the root DSE.
サーバーは、ルートDSEのsupportedControl属性で、それらが認識するコントロールをリストします。
The function of the Bind Operation is to allow authentication information to be exchanged between the client and server.
バインド操作の機能は、クライアントとサーバー間で認証情報を交換できるようにすることです。
The Bind Request is defined as follows:
バインド要求は次のように定義されています。
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 }
Parameters of the Bind Request are:
バインド要求のパラメーターは次のとおりです。
- version: A version number indicating the version of the protocol to be used in this protocol session. This document describes version 3 of the LDAP protocol. Note that there is no version negotiation, and the client just sets this parameter to the version it desires. If the client requests protocol version 2, a server that supports the version 2 protocol as described in [2] will not return any v3-
- version：このプロトコルセッションで使用されるプロトコルのバージョンを示すバージョン番号。このドキュメントでは、LDAPプロトコルのバージョン3について説明します。バージョンネゴシエーションはなく、クライアントはこのパラメーターを必要なバージョンに設定するだけであることに注意してください。クライアントがプロトコルバージョン2を要求した場合、[2]で説明されているようにバージョン2プロトコルをサポートするサーバーはv3-を返しません。
specific protocol fields. (Note that not all LDAP servers will support protocol version 2, since they may be unable to generate the attribute syntaxes associated with version 2.)
特定のプロトコルフィールド。 （バージョン2に関連付けられた属性構文を生成できない場合があるため、すべてのLDAPサーバーがプロトコルバージョン2をサポートするわけではないことに注意してください。）
- name: The name of the directory object that the client wishes to bind as. This field may take on a null value (a zero length string) for the purposes of anonymous binds, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the LDAPDN in the credentials.
- name：クライアントがバインドするディレクトリオブジェクトの名前。このフィールドは、認証が下位層で実行されている場合、または資格情報にLDAPDNを含むメカニズムでSASL資格情報を使用している場合に、匿名バインドの目的でnull値（長さがゼロの文字列）になることがあります。
- authentication: information used to authenticate the name, if any, provided in the Bind Request.
- authentication：バインド要求で提供された名前がある場合、それを認証するために使用される情報。
Upon receipt of a Bind Request, a protocol server will authenticate the requesting client, if necessary. The server will then return a Bind Response to the client indicating the status of the authentication.
バインド要求を受信すると、プロトコルサーバーは、必要に応じて要求元のクライアントを認証します。サーバーは、認証のステータスを示すバインド応答をクライアントに返します。
Authorization is the use of this authentication information when performing operations. Authorization MAY be affected by factors outside of the LDAP Bind request, such as lower layer security services.
認可とは、操作を実行するときにこの認証情報を使用することです。承認は、下位層のセキュリティサービスなど、LDAPバインド要求以外の要素の影響を受ける場合があります。
For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times. If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection. Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage bind.
一部のSASL認証メカニズムでは、クライアントがBindRequestを複数回呼び出す必要がある場合があります。いずれかの段階でクライアントがバインドプロセスを中止したい場合は、バインドを解除して、基になる接続をドロップする場合があります。クライアントは、マルチステージバインドの一部として行われた2つのBindリクエスト間のオペレーションを呼び出してはなりません（MUST NOT）。
A client may abort a SASL bind negotiation by sending a BindRequest with a different value in the mechanism field of SaslCredentials, or an AuthenticationChoice other than sasl.
クライアントは、SaslCredentialsのメカニズムフィールドに異なる値を持つBindRequest、またはsasl以外のAuthenticationChoiceを送信することにより、SASLバインドネゴシエーションを中止できます。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with authMethodNotSupported as the resultCode. This will allow clients to abort a negotiation if it wishes to try again with the same SASL mechanism.
クライアントがsaslメカニズムフィールドを空の文字列としてBindRequestを送信する場合、サーバーはauthMethodNotSupportedをresultCodeとしてBindResponseを返す必要があります。これにより、クライアントは、同じSASLメカニズムで再試行する場合にネゴシエーションを中止できます。
Unlike LDAP v2, the client need not send a Bind Request in the first PDU of the connection. The client may request any operations and the server MUST treat these as unauthenticated. If the server requires that the client bind before browsing or modifying the directory, the server MAY reject a request other than binding, unbinding or an extended request with the "operationsError" result.
LDAP v2とは異なり、クライアントは接続の最初のPDUでバインド要求を送信する必要はありません。クライアントは任意の操作を要求でき、サーバーはこれらを認証されていないものとして扱う必要があります。サーバーがクライアントがディレクトリを閲覧または変更する前にバインドする必要がある場合、サーバーはバインド、バインド解除、または "operationsError"結果を伴う拡張リクエスト以外のリクエストを拒否してもよい（MAY）。
If the client did not bind before sending a request and receives an operationsError, it may then send a Bind Request. If this also fails or the client chooses not to bind on the existing connection, it will close the connection, reopen it and begin again by first sending a PDU with a Bind Request. This will aid in interoperating with servers implementing other versions of LDAP.
リクエストを送信する前にクライアントがバインドせず、operationsErrorを受け取った場合、クライアントはバインドリクエストを送信します。これも失敗した場合、またはクライアントが既存の接続にバインドしないことを選択した場合は、接続を閉じて再度開き、最初にBind要求でPDUを送信することから始めます。これは、LDAPの他のバージョンを実装するサーバーとの相互運用に役立ちます。
Clients MAY send multiple bind requests on a connection to change their credentials. A subsequent bind process has the effect of abandoning all operations outstanding on the connection. (This simplifies server implementation.) Authentication from earlier binds are subsequently ignored, and so if the bind fails, the connection will be treated as anonymous. If a SASL transfer encryption or integrity mechanism has been negotiated, and that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection.
クライアントは、資格情報を変更するために、接続で複数のバインド要求を送信する場合があります。後続のバインドプロセスには、接続で未解決のすべての操作を破棄する効果があります。 （これにより、サーバーの実装が簡略化されます。）その後、以前のバインドからの認証は無視されるため、バインドが失敗した場合、接続は匿名として扱われます。 SASL転送暗号化または整合性メカニズムがネゴシエートされ、そのメカニズムが1つのIDから別のIDへの資格情報の変更をサポートしない場合、クライアントは代わりに新しい接続を確立する必要があります。
The simple authentication option provides minimal authentication facilities, with the contents of the authentication field consisting only of a cleartext password. Note that the use of cleartext passwords is not recommended over open networks when there is no authentication or encryption being performed by a lower layer; see the "Security Considerations" section.
単純な認証オプションは最小限の認証機能を提供し、認証フィールドの内容はクリアテキストのパスワードのみで構成されます。下位層で認証または暗号化が実行されていない場合、オープンネットワークでのクリアテキストパスワードの使用は推奨されないことに注意してください。 「セキュリティに関する考慮事項」を参照してください。
If no authentication is to be performed, then the simple authentication option MUST be chosen, and the password be of zero length. (This is often done by LDAPv2 clients.) Typically the DN is also of zero length.
認証を実行しない場合は、単純な認証オプションを選択する必要があり、パスワードの長さはゼロでなければなりません。 （これはしばしばLDAPv2クライアントによって行われます。）通常、DNも長さがゼロです。
The sasl choice allows for any mechanism defined for use with SASL [12]. The mechanism field contains the name of the mechanism. The credentials field contains the arbitrary data used for authentication, inside an OCTET STRING wrapper. Note that unlike some Internet application protocols where SASL is used, LDAP is not text-based, thus no base64 transformations are performed on the credentials.
saslを選択すると、SASL [12]で使用するために定義されたメカニズムが許可されます。メカニズムフィールドには、メカニズムの名前が含まれます。資格情報フィールドには、OCTET STRINGラッパー内の認証に使用される任意のデータが含まれています。 SASLが使用される一部のインターネットアプリケーションプロトコルとは異なり、LDAPはテキストベースではないため、資格情報に対してbase64変換は実行されないことに注意してください。
If any SASL-based integrity or confidentiality services are enabled, they take effect following the transmission by the server and reception by the client of the final BindResponse with resultCode success.
SASLベースの整合性サービスまたは機密性サービスが有効になっている場合、サーバーによる送信とクライアントによる受信の結果、resultCodeが成功した最終的なBindResponseが有効になります。
The client can request that the server use authentication information from a lower layer protocol by using the SASL EXTERNAL mechanism.
クライアントは、SASL EXTERNALメカニズムを使用して、サーバーが下位層プロトコルからの認証情報を使用することを要求できます。
The Bind Response is defined as follows.
Bind Responseは次のように定義されています。
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse consists simply of an indication from the server of he status of the client's request for authentication.
BindResponseは、クライアントからの認証要求のステータスを示すサーバーからの指示で構成されます。
f the bind was successful, the resultCode will be success, therwise it will be one of:
バインドが成功した場合、resultCodeは成功し、そうでなければ次のいずれかになります。
- operationsError: server encountered an internal error,
- operationsError：サーバーで内部エラーが発生しました
- protocolError: unrecognized version number or incorrect PDU structure,
- protocolError：認識されないバージョン番号または不正なPDU構造、
- authMethodNotSupported: unrecognized SASL mechanism name,
- authMethodNotSupported：認識されないSASLメカニズム名、
- strongAuthRequired: the server requires authentication be performed with a SASL mechanism,
- strongAuthRequired：サーバーは、SASLメカニズムを使用して認証を実行する必要があります。
- referral: this server cannot accept this bind and the client should try another,
- 紹介：このサーバーはこのバインドを受け入れることができず、クライアントは別のバインドを試行する必要があります。
- saslBindInProgress: the server requires the client to send a new bind request, with the same sasl mechanism, to continue the authentication process,
- saslBindInProgress：サーバーは、クライアントが認証プロセスを続行するために、同じsaslメカニズムで新しいバインド要求を送信することを要求します。
- inappropriateAuthentication: the server requires the client which had attempted to bind anonymously or without supplying credentials to provide some form of credentials,
- 不適切な認証：サーバーは、匿名で、または資格情報を提供せずにバインドしようとしたクライアントに、何らかの形式の資格情報を提供するよう要求します。
- invalidCredentials: the wrong password was supplied or the SASL credentials could not be processed,
- invalidCredentials：間違ったパスワードが指定されたか、SASL資格情報を処理できませんでした、
- unavailable: the server is shutting down.
- 使用不可：サーバーはシャットダウンしています。
If the server does not support the client's requested protocol version, it MUST set the resultCode to protocolError.
サーバーがクライアントの要求されたプロトコルバージョンをサポートしていない場合は、resultCodeをprotocolErrorに設定する必要があります。
If the client receives a BindResponse response where the resultCode was protocolError, it MUST close the connection as the server will be unwilling to accept further operations. (This is for compatibility with earlier versions of LDAP, in which the bind was always the first operation, and there was no negotiation.) The serverSaslCreds are used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating, or to perform "challenge-response" authentication. If the client bound with the password choice, or the SASL mechanism does not require the server to return information to the client, then this field is not to be included in the result.
クライアントがresultCodeがprotocolErrorであるBindResponse応答を受信した場合、サーバーはそれ以上の操作を受け入れたくないため、接続を閉じる必要があります。 （これは、バインドが常に最初の操作であり、ネゴシエーションがなかった以前のバージョンのLDAPとの互換性のためです。）serverSaslCredsは、SASL定義のバインドメカニズムの一部として使用され、クライアントがサーバーを認証できるようにします。通信中、または「チャレンジ/レスポンス」認証を実行します。クライアントがパスワードの選択にバインドされている場合、またはSASLメカニズムでサーバーがクライアントに情報を返す必要がない場合、このフィールドは結果に含まれません。
The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation is defined as follows:
バインド解除操作の機能は、プロトコルセッションを終了することです。バインド解除操作は次のように定義されています。
UnbindRequest ::= [APPLICATION 2] NULL
The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded, and may close the connection.
バインド解除操作には応答が定義されていません。 UnbindRequestを送信すると、プロトコルクライアントは、プロトコルセッションが終了したと見なします。 UnbindRequestを受信すると、プロトコルサーバーは、要求元のクライアントがセッションを終了したと想定し、すべての未処理の要求が破棄され、接続を閉じる場合があります。
An unsolicited notification is an LDAPMessage sent from the server to the client which is not in response to any LDAPMessage received by the server. It is used to signal an extraordinary condition in the server or in the connection between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.
非送信請求通知は、サーバーが受信したLDAPMessageに応答しない、サーバーからクライアントに送信されるLDAPMessageです。サーバーまたはクライアントとサーバー間の接続で異常な状態を通知するために使用されます。通知は助言的な性質のものであり、サーバーはクライアントから応答が返されることを期待しません。
The unsolicited notification is structured as an LDAPMessage in which the messageID is 0 and protocolOp is of the extendedResp form. The responseName field of the ExtendedResponse is present. The LDAPOID value MUST be unique for this notification, and not be used in any other situation.
非送信請求通知は、messageIDが0でprotocolOpがextendedResp形式のLDAPMessageとして構造化されています。 ExtendedResponseのresponseNameフィールドが存在します。 LDAPOID値はこの通知に対して一意である必要があり、他の状況では使用しないでください。
One unsolicited notification is defined in this document.
このドキュメントでは、一方的な通知が1つ定義されています。
This notification may be used by the server to advise the client that the server is about to close the connection due to an error condition. Note that this notification is NOT a response to an unbind requested by the client: the server MUST follow the procedures of section 4.3. This notification is intended to assist clients in distinguishing between an error condition and a transient network failure. As with a connection close due to network failure, the client MUST NOT assume that any outstanding requests which modified the directory have succeeded or failed.
サーバーはこの通知を使用して、サーバーがエラー状態のために接続を閉じようとしていることをクライアントに通知することができます。この通知はクライアントによって要求されたバインド解除に対する応答ではないことに注意してください。サーバーはセクション4.3の手順に従う必要があります。この通知は、クライアントがエラー状態と一時的なネットワーク障害を区別するのに役立つことを目的としています。ネットワーク障害による接続のクローズと同様に、クライアントは、ディレクトリを変更した未解決の要求が成功または失敗したと想定してはなりません（MUST NOT）。
The responseName is 1.3.6.1.4.1.1466.20036, the response field is absent, and the resultCode is used to indicate the reason for the disconnection.
responseNameは1.3.6.1.4.1.1466.20036で、responseフィールドはありません。resultCodeは、切断の理由を示すために使用されます。
The following resultCode values are to be used in this notification:
この通知では、次のresultCode値が使用されます。
- protocolError: The server has received data from the client in which the LDAPMessage structure could not be parsed.
- protocolError：サーバーがクライアントからデータを受信しましたが、LDAPMessage構造を解析できませんでした。
- strongAuthRequired: The server has detected that an established underlying security association protecting communication between the client and server has unexpectedly failed or been compromised.
- strongAuthRequired：サーバーは、クライアントとサーバー間の通信を保護する確立された基礎となるセキュリティアソシエーションが予期せず失敗したか、侵害されたことを検出しました。
- unavailable: This server will stop accepting new connections and operations on all existing connections, and be unavailable for an extended period of time. The client may make use of an alternative server.
- 使用不可：このサーバーは、既存のすべての接続での新しい接続と操作の受け入れを停止し、長期間使用できません。クライアントは、代替サーバーを利用できます。
After sending this notice, the server MUST close the connection. After receiving this notice, the client MUST NOT transmit any further on the connection, and may abruptly close the connection.
この通知を送信した後、サーバーは接続を閉じる必要があります。この通知を受け取った後、クライアントは接続でこれ以上送信してはならず、突然接続を閉じる場合があります。
The Search Operation allows a client to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately below a particular entry, or a whole subtree of entries.
検索操作を使用すると、クライアントはサーバーに代わって検索を実行するように要求できます。これは、単一のエントリ、特定のエントリのすぐ下のエントリ、またはエントリのサブツリー全体から属性を読み取るために使用できます。
The Search Request is defined as follows:
検索リクエストは次のように定義されています。
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 }
Parameters of the Search Request are:
検索リクエストのパラメータは次のとおりです。
- baseObject: An LDAPDN that is the base object entry relative to which the search is to be performed.
- baseObject：検索が実行される基準となるベースオブジェクトエントリであるLDAPDN。
- scope: An indicator of the scope of the search to be performed. The semantics of the possible values of this field are identical to the semantics of the scope field in the X.511 Search Operation.
- スコープ：実行される検索のスコープのインジケーター。このフィールドの可能な値のセマンティクスは、X.511検索操作のスコープフィールドのセマンティクスと同じです。
- derefAliases: An indicator as to how alias objects (as defined in X.501) are to be handled in searching. The semantics of the possible values of this field are:
- derefAliases：（X.501で定義されている）エイリアスオブジェクトが検索でどのように処理されるかに関するインジケーター。このフィールドの可能な値の意味は次のとおりです。
neverDerefAliases: do not dereference aliases in searching or in locating the base object of the search;
neverDerefAliases：検索時または検索のベースオブジェクトの検索時にエイリアスを逆参照しないでください。
derefInSearching: dereference aliases in subordinates of the base object in searching, but not in locating the base object of the search;
derefInSearching：検索ではベースオブジェクトの下位のエイリアスを逆参照しますが、検索のベースオブジェクトを見つけることはできません。
derefFindingBaseObj: dereference aliases in locating the base object of the search, but not when searching subordinates of the base object;
derefFindingBaseObj：検索のベースオブジェクトを見つけるときにエイリアスを逆参照しますが、ベースオブジェクトの下位オブジェクトを検索するときはそうではありません。
derefAlways: dereference aliases both in searching and in locating the base object of the search.
derefAlways：検索時と検索のベースオブジェクトの検索時の両方でエイリアスを逆参照します。
- sizelimit: A sizelimit that restricts the maximum number of entries to be returned as a result of the search. A value of 0 in this field indicates that no client-requested sizelimit restrictions are in effect for the search. Servers may enforce a maximum number of entries to return.
- sizelimit：検索の結果として返されるエントリの最大数を制限するsizelimit。このフィールドの値が0の場合、クライアントが要求したサイズ制限の制限が検索に対して有効になっていないことを示します。サーバーは、返されるエントリの最大数を強制できます。
- timelimit: A timelimit that restricts the maximum time (in seconds) allowed for a search. A value of 0 in this field indicates that no client-requested timelimit restrictions are in effect for the search.
- timelimit：検索に許可される最大時間（秒単位）を制限する制限時間。このフィールドの値が0の場合、クライアントが要求した制限時間制限が検索に対して有効になっていないことを示します。
- typesOnly: An indicator as to whether search results will contain both attribute types and values, or just attribute types. Setting this field to TRUE causes only attribute types (no values) to be returned. Setting this field to FALSE causes both attribute types and values to be returned.
- typesOnly：検索結果に属性タイプと値の両方が含まれるか、属性タイプのみが含まれるかに関するインジケーター。このフィールドをTRUEに設定すると、属性タイプのみ（値なし）が返されます。このフィールドをFALSEに設定すると、属性タイプと値の両方が返されます。
- filter: A filter that defines the conditions that must be fulfilled in order for the search to match a given entry.
- フィルター：検索が特定のエントリーと一致するために満たす必要がある条件を定義するフィルター。
The 'and', 'or' and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. The others match against individual attribute values of entries in the scope of the search. (Implementor's note: the 'not' filter is an example of a tagged choice in an implicitly-tagged module. In BER this is treated as if the tag was explicit.)
「and」、「or」、「not」の選択肢を使用して、フィルターの組み合わせを形成できます。少なくとも1つのフィルター要素が「and」または「or」の選択肢に存在する必要があります。その他は、検索範囲内のエントリの個々の属性値と照合されます。 （実装者の注：「not」フィルターは、暗黙的にタグ付けされたモジュールのタグ付けされた選択肢の例です。BERでは、これはタグが明示的であるかのように扱われます。）
A server MUST evaluate filters according to the three-valued logic of X.511(93) section 7.8.1. In summary, a filter is evaluated to either "TRUE", "FALSE" or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the search.
サーバーは、X.511（93）セクション7.8.1の3値論理に従ってフィルターを評価する必要があります。要約すると、フィルターは「TRUE」、「FALSE」、または「Undefined」のいずれかに評価されます。フィルターが特定のエントリーに対してTRUEと評価された場合、そのエントリーの属性が検索結果の一部として返されます（該当するアクセス制御制限がある場合）。フィルターの評価がFALSEまたは未定義の場合、そのエントリーは検索で無視されます。
A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and otherwise Undefined. A filter of the "or" choice is FALSE if all of the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the "not" choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined.
「and」を選択したフィルターは、SET OFのすべてのフィルターがTRUEと評価された場合はTRUE、少なくとも1つのフィルターがFALSEの場合はFALSE、それ以外の場合は未定義になります。 「または」の選択肢のフィルターは、SET OF内のすべてのフィルターがFALSEに評価される場合はFALSE、少なくとも1つのフィルターがTRUEの場合はTRUE、そうでない場合はUndefinedです。 "not"選択のフィルターは、否定されるフィルターがFALSEの場合はTRUE、TRUEの場合はFALSE、Undefinedの場合はUndefinedです。
The present match evaluates to TRUE where there is an attribute or subtype of the specified attribute description present in an entry, and FALSE otherwise (including a presence test with an unrecognized attribute description.)
現在の一致は、指定された属性の説明の属性またはサブタイプがエントリに存在する場合はTRUE、それ以外の場合はFALSE（認識されない属性の説明を含む存在テストを含む）と評価されます。
The extensibleMatch is new in this version of LDAP. If the matchingRule field is absent, the type field MUST be present, and the equality match is performed for that type. If the type field is absent and matchingRule is present, the matchValue is compared against all attributes in an entry which support that matchingRule, and the matchingRule determines the syntax for the assertion value (the filter item evaluates to TRUE if it matches with at least one attribute in the entry, FALSE if it does not match any attribute in the entry, and Undefined if the matchingRule is not recognized or the assertionValue cannot be parsed.) If the type field is present and matchingRule is present, the matchingRule MUST be one permitted for use with that type, otherwise the filter item is undefined. If the dnAttributes field is set to TRUE, the match is applied against all the attributes in an entry's distinguished name as well, and also evaluates to TRUE if there is at least one attribute in the distinguished name for which the filter item evaluates to TRUE. (Editors note: The dnAttributes field is present so that there does not need to be multiple versions of generic matching rules such as for word matching, one to apply to entries and another to apply to entries and dn attributes as well).
extensibleMatchは、このバージョンのLDAPの新機能です。 matchingRuleフィールドが存在しない場合は、typeフィールドが存在している必要があり、そのタイプに対して等価一致が実行されます。 typeフィールドがなく、matchingRuleが存在する場合、matchValueは、そのmatchingRuleをサポートするエントリ内のすべての属性と比較され、matchingRuleがアサーション値の構文を決定します（フィルター項目は、少なくとも1つと一致する場合にTRUEと評価されますエントリ内の属性、エントリ内のどの属性とも一致しない場合はFALSE、matchingRuleが認識されない場合、またはassertionValueを解析できない場合はUndefined。）typeフィールドが存在し、matchingRuleが存在する場合、matchingRuleは許可されている必要があります。そのタイプで使用する場合、それ以外の場合、フィルター項目は未定義です。 dnAttributesフィールドがTRUEに設定されている場合、一致はエントリの識別名のすべての属性に対しても適用され、フィルタ項目がTRUEと評価される識別名に少なくとも1つの属性がある場合はTRUEと評価されます。 （編集者注：dnAttributesフィールドが存在するため、単語照合などの一般的な照合ルールの複数のバージョンが必要ではありません。1つはエントリに適用し、もう1つはエントリとdn属性にも適用します）。
A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. If an attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter is not recognized by the server, a matching rule id in the extensibleMatch is not recognized by the server, the assertion value cannot be parsed, or the type of filtering requested is not implemented, then the filter is Undefined. Thus for example if a server did not recognize the attribute type shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
アサーション値がエントリと一致するかどうかをサーバーが判断できない場合、フィルターアイテムは未定義と評価されます。 equalityMatch、substrings、greaterOrEqual、lessOrEqual、approxMatch、またはextensibleMatchフィルターの属性の説明がサーバーで認識されない場合、extensibleMatchの一致するルールIDがサーバーで認識されない、アサーション値を解析できない、または要求されたフィルタリングが実装されていない場合、フィルターは未定義です。したがって、たとえばサーバーが属性タイプshoeSizeを認識しなかった場合、（shoeSize = *）のフィルターはFALSEと評価され、フィルター（shoeSize = 12）、（shoeSize> = 12）および（shoeSize <= 12）は未定義に評価されます。
Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, or assertion values cannot be parsed. More details of filter processing are given in section 7.8 of X.511 [8].
属性の説明または一致するルールIDが認識されない場合、またはアサーション値を解析できない場合、サーバーはエラーを返してはなりません（MUST NOT）。フィルター処理の詳細は、X.511 [8]のセクション7.8に記載されています。
- attributes: A list of the attributes to be returned from each entry which matches the search filter. There are two special values which may be used: an empty list with no attributes, and the attribute description string "*". Both of these signify that all user attributes are to be returned. (The "*" allows the client to request all user attributes in addition to specific operational attributes).
- attributes：検索フィルターに一致する各エントリから返される属性のリスト。使用できる特別な値は2つあります。属性のない空のリストと属性の説明文字列 "*"です。これらは両方とも、すべてのユーザー属性が返されることを意味します。 （「*」を使用すると、クライアントは特定の操作属性に加えてすべてのユーザー属性を要求できます）。
Attributes MUST be named at most once in the list, and are returned at most once in an entry. If there are attribute descriptions in the list which are not recognized, they are ignored by the server.
属性は、リスト内で最大1回指定する必要があり、エントリ内で最大1回返されます。認識されない属性の説明がリストにある場合、それらはサーバーによって無視されます。
If the client does not want any attributes returned, it can specify a list containing only the attribute with OID "1.1". This OID was chosen arbitrarily and does not correspond to any attribute in use.
クライアントが属性を返さない場合は、OID "1.1"の属性のみを含むリストを指定できます。このOIDは任意に選択されたものであり、使用中の属性には対応していません。
Client implementors should note that even if all user attributes are requested, some attributes of the entry may not be included in search results due to access control or other restrictions. Furthermore, servers will not return operational attributes, such as objectClasses or attributeTypes, unless they are listed by name, since there may be extremely large number of values for certain operational attributes. (A list of operational attributes for use in LDAP is given in [5].)
クライアントの実装者は、すべてのユーザー属性が要求された場合でも、アクセス制御またはその他の制限により、エントリの一部の属性が検索結果に含まれない場合があることに注意する必要があります。さらに、サーバーは、名前でリストされていない限り、objectClassesやattributeTypesなどの操作属性を返しません。これは、特定の操作属性の値が非常に多い場合があるためです。 （LDAPで使用する操作属性のリストは、[5]に記載されています。）
Note that an X.500 "list"-like operation can be emulated by the client requesting a one-level LDAP search operation with a filter checking for the existence of the objectClass attribute, and that an X.500 "read"-like operation can be emulated by a base object LDAP search operation with the same filter. A server which provides a gateway to X.500 is not required to use the Read or List operations, although it may choose to do so, and if it does must provide the same semantics as the X.500 search operation.
X.500の「リスト」のような操作は、objectClass属性の存在をチェックするフィルターを使用して1レベルのLDAP検索操作を要求するクライアントによってエミュレートでき、X.500の「読み取り」のような操作に注意してください。同じフィルターを使用して、ベースオブジェクトのLDAP検索操作でエミュレートできます。 X.500へのゲートウェイを提供するサーバーは、読み取りまたはリスト操作を使用する必要はありませんが、X.500検索操作と同じセマンティクスを提供する必要がある場合は、使用することができます。
The results of the search attempted by the server upon receipt of a Search Request are returned in Search Responses, which are LDAP messages containing either SearchResultEntry, SearchResultReference, ExtendedResponse or SearchResultDone data types.
検索要求の受信時にサーバーが試行した検索の結果は、検索応答で返されます。これは、SearchResultEntry、SearchResultReference、ExtendedResponse、またはSearchResultDoneのいずれかのデータ型を含むLDAPメッセージです。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN, attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the PartialAttributeList may
-- have zero elements (if none of the attributes of that entry
-- were requested, or could be returned), and that the vals set
-- may also have zero elements (if types only was requested, or
-- all values were excluded from the result.)
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultDone ::= [APPLICATION 5] LDAPResult
Upon receipt of a Search Request, a server will perform the necessary search of the DIT.
サーバーは検索リクエストを受信すると、DITの必要な検索を実行します。
If the LDAP session is operating over a connection-oriented transport such as TCP, the server will return to the client a sequence of responses in separate LDAP messages. There may be zero or more responses containing SearchResultEntry, one for each entry found during the search. There may also be zero or more responses containing SearchResultReference, one for each area not explored by this server during the search. The SearchResultEntry and SearchResultReference PDUs may come in any order. Following all the SearchResultReference responses and all SearchResultEntry responses to be returned by the server, the server will return a response containing the SearchResultDone, which contains an indication of success, or detailing any errors that have occurred.
LDAPセッションがTCPなどのコネクション型トランスポートで動作している場合、サーバーは一連の応答を個別のLDAPメッセージでクライアントに返します。検索中に見つかったエントリごとに1つずつ、SearchResultEntryを含むゼロ以上の応答が存在する場合があります。検索中にこのサーバーによって探索されなかった各領域に対して1つずつ、SearchResultReferenceを含むゼロ以上の応答が存在する場合もあります。 SearchResultEntry PDUとSearchResultReference PDUは、どのような順序でもかまいません。サーバーから返されるすべてのSearchResultReference応答とすべてのSearchResultEntry応答に続いて、サーバーは、成功を示すSearchResultDoneを含む応答、または発生したエラーの詳細を含む応答を返します。
Each entry returned in a SearchResultEntry will contain all attributes, complete with associated values if necessary, as specified in the attributes field of the Search Request. Return of attributes is subject to access control and other administrative policy. Some attributes may be returned in binary format (indicated by the AttributeDescription in the response having the binary option present).
SearchResultEntryで返される各エントリには、すべての属性が含まれ、検索リクエストの属性フィールドで指定されているように、必要に応じて値が関連付けられます。属性の返却は、アクセス制御およびその他の管理ポリシーの対象となります。一部の属性は、バイナリ形式で返される場合があります（バイナリオプションが存在する応答のAttributeDescriptionで示されます）。
Some attributes may be constructed by the server and appear in a SearchResultEntry attribute list, although they are not stored attributes of an entry. Clients MUST NOT assume that all attributes can be modified, even if permitted by access control.
一部の属性はサーバーによって作成され、SearchResultEntry属性リストに表示される場合がありますが、それらはエントリの格納された属性ではありません。クライアントは、アクセス制御で許可されている場合でも、すべての属性が変更可能であると想定してはなりません。
LDAPMessage responses of the ExtendedResponse form are reserved for returning information associated with a control requested by the client. These may be defined in future versions of this document.
ExtendedResponseフォームのLDAPMessage応答は、クライアントによって要求されたコントロールに関連する情報を返すために予約されています。これらは、このドキュメントの将来のバージョンで定義される可能性があります。
If the server was able to locate the entry referred to by the baseObject but was unable to search all the entries in the scope at and under the baseObject, the server may return one or more SearchResultReference, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference if it has not located the baseObject and thus has not searched any entries; in this case it would return a SearchResultDone containing a referral resultCode.
サーバーがbaseObjectによって参照されるエントリを見つけることができたが、baseObjectおよびその下のスコープ内のすべてのエントリを検索できなかった場合、サーバーは1つ以上のSearchResultReferenceを返すことがあり、それぞれに別のサーバーのセットへの参照が含まれています。操作を続行します。サーバーは、baseObjectが見つからなかったためにエントリを検索しなかった場合、SearchResultReferenceを返してはなりません（MUST NOT）。この場合、参照のresultCodeを含むSearchResultDoneを返します。
In the absence of indexing information provided to a server from servers holding subordinate naming contexts, SearchResultReference responses are not affected by search filters and are always returned when in scope.
下位の名前付けコンテキストを保持するサーバーからサーバーに提供されるインデックス情報がない場合、SearchResultReference応答は検索フィルターの影響を受けず、スコープ内にある場合は常に返されます。
The SearchResultReference is of the same data type as the Referral. URLs for servers implementing the LDAP protocol are written according to [9]. The <dn> part MUST be present in the URL, with the new target object name. The client MUST use this name in its next request. Some servers (e.g. part of a distributed index exchange system) may provide a different filter in the URLs of the SearchResultReference. If the filter part of the URL is present in an LDAP URL, the client MUST use the new filter in its next request to progress the search, and if the filter part is absent the client will use again the same filter. Other aspects of the new search request may be the same or different as the search which generated the continuation references.
SearchResultReferenceは、紹介と同じデータ型です。 LDAPプロトコルを実装するサーバーのURLは、[9]に従って記述されています。 <dn>部分は、新しいターゲットオブジェクト名とともに、URLに存在する必要があります。クライアントは、次のリクエストでこの名前を使用する必要があります。一部のサーバー（分散インデックス交換システムの一部など）は、SearchResultReferenceのURLに異なるフィルターを提供する場合があります。 URLのフィルター部分がLDAP URLに存在する場合、クライアントは次の要求で新しいフィルターを使用して検索を進める必要があります。フィルター部分がない場合、クライアントは同じフィルターを再び使用します。新しい検索リクエストの他の側面は、継続参照を生成した検索と同じまたは異なる場合があります。
Other kinds of URLs may be returned so long as the operation could be performed using that protocol.
そのプロトコルを使用して操作を実行できる限り、他の種類のURLが返されることがあります。
The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
SearchResultReferenceの未探索のサブツリーの名前は、ベースオブジェクトに従属する必要はありません。
In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Note that the abandon operation described in section 4.11 applies only to a particular operation sent on a connection between a client and server, and if the client has multiple outstanding search operations to different servers, it MUST abandon each operation individually.
検索を完了するために、クライアントは、返されるSearchResultReferenceごとに新しい検索操作を発行する必要があります。セクション4.11で説明されている破棄操作は、クライアントとサーバー間の接続で送信される特定の操作にのみ適用され、クライアントが異なるサーバーに対して未処理の検索操作を複数持っている場合は、各操作を個別に破棄する必要があります。
For example, suppose the contacted server (hosta) holds the entry "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that either LDAP-capable servers (hostb) or (hostc) hold "OU=People,O=MNN,C=WW" (one is the master and the other server a shadow), and that LDAP-capable server (hostd) holds the subtree "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is requested to the contacted server, it may return the following:
たとえば、接続されたサーバー（hosta）がエントリ「O = MNN、C = WW」とエントリ「CN = Manager、O = MNN、C = WW」を保持しているとします。 LDAP対応サーバー（hostb）または（hostc）のいずれかが "OU = People、O = MNN、C = WW"（1つはマスター、もう1つはシャドウ）を保持し、その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)
Client implementors should note that when following a SearchResultReference, additional SearchResultReference may be generated. Continuing the example, if the client contacted the server (hostb) and issued the search for the subtree "OU=People,O=MNN,C=WW", the server might respond as follows:
クライアントの実装者は、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)
If the contacted server does not hold the base object for the search, then it will return a referral to the client. For example, if the client requests a subtree search of "O=XYZ,C=US" to hosta, the server may return only a SearchResultDone containing a referral.
接続されたサーバーが検索のベースオブジェクトを保持していない場合、クライアントに紹介を返します。たとえば、クライアントがhostaに「O = XYZ、C = US」のサブツリー検索を要求した場合、サーバーは参照を含むSearchResultDoneのみを返すことがあります。
SearchResultDone (referral) {
ldap://hostg/
}
The Modify Operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows:
変更操作を使用すると、クライアントは、サーバーに代わってエントリの変更を実行するように要求できます。変更要求は次のように定義されます。
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 }
Parameters of the Modify Request are:
変更リクエストのパラメータは次のとおりです。
- object: The object to be modified. The value of this field contains the DN of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified.
- object：変更するオブジェクト。このフィールドの値には、変更するエントリのDNが含まれています。サーバーは、変更するオブジェクトを決定するときに別名の逆参照を実行しません。
- modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively:
- 変更：エントリで実行される変更のリスト。エントリ変更のリスト全体は、単一のアトミック操作として、リストされている順序で実行する必要があります。個々の変更はディレクトリスキーマに違反する可能性がありますが、変更のリスト全体が実行された後の結果のエントリは、ディレクトリスキーマの要件に準拠している必要があります。各変更構成の「操作」フィールドが取る値には、それぞれ次のセマンティクスがあります。
add: add values listed to the given attribute, creating the attribute if necessary;
add：指定された属性にリストされた値を追加し、必要に応じて属性を作成します。
delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion;
削除：指定された属性からリストされた値を削除します。値がリストされていない場合、または属性の現在の値がすべて削除対象としてリストされている場合は、属性全体を削除します。
replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist.
replace：指定された属性の既存のすべての値をリストされた新しい値で置き換え、属性がまだ存在しない場合は作成します。値のない置換では、属性が存在する場合は属性全体が削除され、属性が存在しない場合は無視されます。
The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows:
変更要求の受信時にサーバーによって試行された変更の結果は、次のように定義された変更応答で返されます。
ModifyResponse ::= [APPLICATION 7] LDAPResult
Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT.
変更要求を受信すると、サーバーはDITに必要な変更を行います。
The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Note that due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation. If the connection fails, whether the modification occurred or not is indeterminate.
サーバーは、DIT変更が正常に完了したこと、または変更が失敗した理由を示す単一の変更応答をクライアントに返します。変更要求内の変更のリストを適用する際の原子性の要件により、クライアントは、受信した変更応答が何らかのエラーを示し、要求されたすべての変更が完了している場合、DITの変更が実行されていないことを期待できます。変更応答が変更操作の正常終了を示している場合に実行されます。接続が失敗した場合、変更が行われたかどうかは不確定です。
The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 4.9 is used to rename an entry.
変更操作を使用して、エントリからその識別値（エントリの相対識別名を形成する値）を削除することはできません。そうしようとすると、サーバーはエラーnotAllowedOnRDNを返します。セクション4.9で説明されているDNの変更操作は、エントリの名前を変更するために使用されます。
If an equality match filter has not been defined for an attribute type, clients MUST NOT attempt to delete individual values of that attribute from an entry using the "delete" form of a modification, and MUST instead use the "replace" form.
等式一致フィルターが属性タイプに対して定義されていない場合、クライアントは変更の「削除」形式を使用してエントリーからその属性の個々の値を削除しようとしてはならず、代わりに「置換」形式を使用しなければなりません。
Note that due to the simplifications made in LDAP, there is not a direct mapping of the modifications in an LDAP ModifyRequest onto the EntryModifications of a DAP ModifyEntry operation, and different implementations of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical.
LDAPで行われた簡素化のため、LDAP ModifyRequestでの変更はDAP ModifyEntry操作のEntryModificationsに直接マッピングされず、LDAP-DAPゲートウェイの実装が異なれば、変更を表す別の方法が使用される場合があります。成功した場合、エントリに対する操作の最終的な効果は同じでなければなりません。
The Add Operation allows a client to request the addition of an entry into the directory. The Add Request is defined as follows:
Addオペレーションにより、クライアントはディレクトリへのエントリの追加をリクエストできます。追加要求は次のように定義されます。
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
Parameters of the Add Request are:
追加リクエストのパラメータは次のとおりです。
- entry: the Distinguished Name of the entry to be added. Note that the server will not dereference any aliases in locating the entry to be added.
- entry：追加するエントリの識別名。サーバーは、追加するエントリを見つけるときにエイリアスを逆参照しないことに注意してください。
- attributes: the list of attributes that make up the content of the entry being added. Clients MUST include distinguished values (those forming the entry's own RDN) in this list, the objectClass attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply the createTimestamp or creatorsName attributes, since these will be generated automatically by the server.
- attributes：追加されるエントリのコンテンツを構成する属性のリスト。クライアントは、このリストの識別値（エントリ自体のRDNを形成するもの）、objectClass属性、およびリストされたオブジェクトクラスの必須属性の値を含める必要があります。クライアントはcreateTimestampまたはcreatorsName属性を提供してはなりません。これらはサーバーによって自動的に生成されるためです。
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The parent of the entry to be added MUST exist. For example, if the client attempted to add "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the "C=US" entry did exist, then the server would return the error noSuchObject with the matchedDN field containing "C=US". If the parent entry exists but is not in a naming context held by the server, the server SHOULD return a referral to the server holding the parent entry.
AddRequestが成功するためには、AddRequestのエントリフィールドで指定されたエントリが存在してはなりません。追加するエントリの親が存在している必要があります。たとえば、クライアントが「CN = JS、O = Foo、C = US」を追加しようとした場合、「O = Foo、C = US」エントリは存在せず、「C = US」エントリは存在していました。サーバーは、「C = US」を含むmatchedDNフィールドでエラーnoSuchObjectを返します。親エントリは存在するが、サーバーが保持するネーミングコンテキスト内にない場合、サーバーは親エントリを保持するサーバーへの参照を返す必要があります（SHOULD）。
Servers implementations SHOULD NOT restrict where entries can be located in the directory. Some servers MAY allow the administrator to restrict the classes of entries which can be added to the directory.
サーバーの実装では、ディレクトリ内のエントリを配置できる場所を制限してはなりません（SHOULD NOT）。一部のサーバーでは、管理者がディレクトリに追加できるエントリのクラスを制限できる場合があります。
Upon receipt of an Add Request, a server will attempt to perform the add requested. The result of the add attempt will be returned to the client in the Add Response, defined as follows:
サーバーは、追加要求を受信すると、要求された追加を実行しようとします。追加試行の結果は、次のように定義された追加応答でクライアントに返されます。
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry is present in the directory.
成功の応答は、新しいエントリがディレクトリに存在することを示します。
The Delete Operation allows a client to request the removal of an entry from the directory. The Delete Request is defined as follows:
削除操作により、クライアントはディレクトリからのエントリの削除を要求できます。削除リクエストは次のように定義されています。
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists of the Distinguished Name of the entry to be deleted. Note that the server will not dereference aliases while resolving the name of the target entry to be removed, and that only leaf entries (those with no subordinate entries) can be deleted with this operation.
削除リクエストは、削除するエントリの識別名で構成されています。削除するターゲットエントリの名前を解決している間、サーバーはエイリアスを逆参照しないことに注意してください。また、この操作で削除できるのはリーフエントリ（下位エントリのないもの）だけです。
The result of the delete attempted by the server upon receipt of a Delete Request is returned in the Delete Response, defined as follows:
削除リクエストの受信時にサーバーによって試行された削除の結果は、次のように定義された削除応答で返されます。
DelResponse ::= [APPLICATION 11] LDAPResult
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested. The result of the delete attempt will be returned to the client in the Delete Response.
削除要求を受信すると、サーバーは要求されたエントリの削除を実行しようとします。削除試行の結果は、削除応答でクライアントに返されます。
The Modify DN Operation allows a client to change the leftmost (least significant) component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory. The Modify DN Request is defined as follows:
DNの変更操作により、クライアントはディレクトリ内のエントリの名前の左端（最下位）のコンポーネントを変更したり、エントリのサブツリーをディレクトリ内の新しい場所に移動したりできます。 DN変更要求は次のように定義されます。
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
Parameters of the Modify DN Request are:
DN変更要求のパラメーターは次のとおりです。
- entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries.
- entry：変更するエントリの識別名。このエントリには、下位エントリがある場合とない場合があります。
- newrdn: the RDN that will form the leftmost component of the new name of the entry.
- newrdn：エントリの新しい名前の左端のコンポーネントを形成するRDN。
- deleteoldrdn: a boolean parameter that controls whether the old RDN attribute values are to be retained as attributes of the entry, or deleted from the entry.
- deleteoldrdn：古いRDN属性値をエントリの属性として保持するか、エントリから削除するかを制御するブールパラメータ。
- newSuperior: if present, this is the Distinguished Name of the entry which becomes the immediate superior of the existing entry.
- newSuperior：存在する場合、これは既存のエントリのすぐ上位になるエントリの識別名です。
The result of the name change attempted by the server upon receipt of a Modify DN Request is returned in the Modify DN Response, defined as follows:
DNの変更要求を受信したときにサーバーが試みた名前変更の結果は、次のように定義されたDNの変更応答で返されます。
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change. The result of the name change attempt will be returned to the client in the Modify DN Response.
ModifyDNRequestを受信すると、サーバーは名前の変更を実行しようとします。名前変更試行の結果は、DN変更応答でクライアントに返されます。
For example, if the entry named in the "entry" parameter was "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the newSuperior parameter was absent, then this operation would attempt to rename the entry to be "cn=John Cougar Smith,c=US". If there was already an entry with that name, the operation would fail with error code entryAlreadyExists.
たとえば、「entry」パラメータで指定されたエントリが「cn = John Smith、c = US」であり、newrdnパラメータが「cn = John Cougar Smith」であり、newSuperiorパラメータが存在しない場合、この操作はエントリの名前を「cn = John Cougar Smith、c = US」に変更します。その名前のエントリが既に存在する場合、操作はエラーコードentryAlreadyExistsで失敗します。
If the deleteoldrdn parameter is TRUE, the values forming the old RDN are deleted from the entry. If the deleteoldrdn parameter is FALSE, the values forming the old RDN will be retained as non-distinguished attribute values of the entry. The server may not perform the operation and return an error code if the setting of the deleteoldrdn parameter would cause a schema inconsistency in the entry.
deleteoldrdnパラメータがTRUEの場合、古いRDNを形成する値がエントリから削除されます。 deleteoldrdnパラメータがFALSEの場合、古いRDNを形成する値は、エントリの識別されていない属性値として保持されます。 deleteoldrdnパラメータの設定によってエントリのスキーマに矛盾が生じる場合、サーバーは操作を実行せず、エラーコードを返すことがあります。
Note that X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs will be returned if this error occurred. In general clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers.
X.500は、ModifyDN操作を制限して、単一のサーバー内に含まれるエントリにのみ影響を与えることに注意してください。 LDAPサーバーがDAPにマップされている場合、この制限が適用され、このエラーが発生した場合は、resultCode effectsMultipleDSAが返されます。一般に、クライアントは、サーバー間でエントリとサブツリーの任意の移動を実行できると期待してはなりません。
The Compare Operation allows a client to compare an assertion provided with an entry in the directory. The Compare Request is defined as follows:
比較操作により、クライアントはディレクトリ内のエントリで提供されるアサーションを比較できます。比較要求は次のように定義されます。
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
Parameters of the Compare Request are:
比較要求のパラメーターは次のとおりです。
- entry: the name of the entry to be compared with.
- entry：比較するエントリの名前。
- ava: the assertion with which an attribute in the entry is to be compared.
- ava：エントリの属性と比較されるアサーション。
The result of the compare attempted by the server upon receipt of a Compare Request is returned in the Compare Response, defined as follows:
比較要求の受信時にサーバーによって試行された比較の結果は、次のように定義された比較応答で返されます。
CompareResponse ::= [APPLICATION 15] LDAPResult
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison. The result of the comparison will be returned to the client in the Compare Response. Note that errors and the result of comparison are all returned in the same construct.
比較要求を受信すると、サーバーは要求された比較を実行しようとします。比較の結果は、比較応答でクライアントに返されます。エラーと比較結果はすべて同じ構成で返されることに注意してください。
Note that some directory systems may establish access controls which permit the values of certain attributes (such as userPassword) to be compared but not read. In a search result, it may be that an attribute of that type would be returned, but with an empty set of values.
一部のディレクトリシステムでは、特定の属性（userPasswordなど）の値を比較できるが読み取れないようにするアクセス制御を確立している場合があります。検索結果では、そのタイプの属性が返されても、値のセットが空である場合があります。
The function of the Abandon Operation is to allow a client to request that the server abandon an outstanding operation. The Abandon Request is defined as follows:
破棄操作の機能は、クライアントがサーバーに未処理の操作を破棄するよう要求できるようにすることです。放棄リクエストは次のように定義されます。
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID MUST be that of a an operation which was requested earlier in this connection.
MessageIDは、この接続で以前に要求された操作のものでなければなりません。
(The abandon request itself has its own message id. This is distinct from the id of the earlier operation being abandoned.)
（破棄リクエスト自体に独自のメッセージIDがあります。これは、破棄される以前の操作のIDとは異なります。）
There is no response defined in the Abandon Operation. Upon transmission of an Abandon Operation, a client may expect that the operation identified by the Message ID in the Abandon Request has been abandoned. In the event that a server receives an Abandon Request on a Search Operation in the midst of transmitting responses to the search, that server MUST cease transmitting entry responses to the abandoned request immediately, and MUST NOT send the SearchResponseDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
破棄操作で定義された応答はありません。破棄操作の送信時に、クライアントは、破棄要求のメッセージIDで識別される操作が破棄されたことを予期する場合があります。サーバーが検索への応答を送信している最中に検索操作で放棄要求を受信した場合、そのサーバーは放棄された要求へのエントリ応答の送信を直ちに停止しなければならず（MUST）、SearchResponseDoneを送信してはならない（MUST NOT）。もちろん、サーバーは適切にエンコードされたLDAPMessage PDUのみが送信されるようにする必要があります。
Clients MUST NOT send abandon requests for the same operation multiple times, and MUST also be prepared to receive results from operations it has abandoned (since these may have been in transit when the abandon was requested).
クライアントは、同じ操作に対する放棄要求を複数回送信してはならず（MUST）、放棄した操作から結果を受信する準備もしなければなりません（放棄が要求されたときにこれらが転送中であった可能性があるため）。
Servers MUST discard abandon requests for message IDs they do not recognize, for operations which cannot be abandoned, and for operations which have already been abandoned.
サーバーは、認識できないメッセージID、破棄できない操作、および既に破棄された操作に対する破棄要求を破棄する必要があります。
An extension mechanism has been added in this version of LDAP, in order to allow additional operations to be defined for services not available elsewhere in this protocol, for instance digitally signed operations and results.
このバージョンのLDAPには、デジタル署名された操作や結果など、このプロトコルの他の場所では利用できないサービスに対して追加の操作を定義できるようにする拡張メカニズムが追加されています。
The extended operation allows clients to make requests and receive responses with predefined syntaxes and semantics. These may be defined in RFCs or be private to particular implementations. Each request MUST have a unique OBJECT IDENTIFIER assigned to it.
拡張操作により、クライアントは事前定義された構文とセマンティクスでリクエストを作成し、レスポンスを受信できます。これらは、RFCで定義されるか、特定の実装にプライベートである場合があります。各リクエストには、一意のOBJECT IDENTIFIERが割り当てられている必要があります。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
requestNameは、リクエストに対応するOBJECT IDENTIFIERのドット付き10進表記です。 requestValueは、そのリクエストによって定義された形式の情報で、OCTET STRING内にカプセル化されています。
The server will respond to this with an LDAPMessage containing the ExtendedResponse.
サーバーは、ExtendedResponseを含むLDAPMessageでこれに応答します。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL }
If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code.
サーバーが要求名を認識しない場合、プロトコルエラーの結果コードを含むLDAPResultからの応答フィールドのみを返す必要があります。
One underlying service is defined here. Clients and servers SHOULD implement the mapping of LDAP over TCP described in 5.2.1.
ここでは、1つの基盤となるサービスが定義されています。クライアントとサーバーは、5.2.1で説明されているTCPを介したLDAPのマッピングを実装する必要があります（SHOULD）。
The protocol elements of LDAP are encoded for exchange using the Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the high overhead involved in using certain elements of the BER, the following additional restrictions are placed on BER-encodings of LDAP protocol elements:
LDAPのプロトコル要素は、ASN.1 [3]のBasic Encoding Rules（BER）[11]を使用して交換のためにエンコードされます。ただし、BERの特定の要素を使用するとオーバーヘッドが高くなるため、LDAPプロトコル要素のBERエンコードに次の追加の制限が課されます。
(1) Only the definite form of length encoding will be used.
（1）明確な形式の長さエンコーディングのみが使用されます。
(2) OCTET STRING values will be encoded in the primitive form only.
（2）OCTET STRING値はプリミティブ形式でのみエンコードされます。
(3) If the value of a BOOLEAN type is true, the encoding MUST have its contents octets set to hex "FF".
（3）BOOLEAN型の値がtrueの場合、エンコーディングではコンテンツのオクテットを16進数の "FF"に設定する必要があります。
(4) If a value of a type is its default value, it MUST be absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition.
（4）タイプの値がそのデフォルト値である場合、それは存在してはなりません（MUST）。このプロトコル定義では、一部のBOOLEANおよびINTEGERタイプのみにデフォルト値があります。
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise noted.
これらの制限は、特に記載がない限り、属性値などのOCTET STRING値の内部にカプセル化されたASN.1タイプには適用されません。
This protocol is designed to run over connection-oriented, reliable transports, with all 8 bits in an octet being significant in the data stream.
このプロトコルは、接続指向の信頼性の高いトランスポートで実行するように設計されており、オクテットの8ビットすべてがデータストリームで重要です。
The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It is recommended that server implementations running over the TCP MAY provide a protocol listener on the assigned port, 389. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
LDAPMessage PDUは、TCPバイトストリームに直接マップされます。 TCPを介して実行されるサーバー実装は、割り当てられたポート389にプロトコルリスナーを提供する場合があります。サーバーは、代わりに別のポート番号にリスナーを提供する場合があります。クライアントは、有効なTCPポートでのサーバーへの接続をサポートする必要があります。
This document describes an Internet protocol.
このドキュメントでは、インターネットプロトコルについて説明します。
The server MUST be capable of recognizing all the mandatory attribute type names and implement the syntaxes specified in [5]. Servers MAY also recognize additional attribute type names.
サーバーは、必須の属性タイプ名をすべて認識でき、[5]で指定された構文を実装できる必要があります。サーバーは追加の属性タイプ名も認識してもよい（MAY）。
Clients which request referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same target entry name, scope and filter. Some clients may be using a counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle a DIT with at least ten layers of naming contexts between the root and a leaf entry.
紹介を要求するクライアントは、サーバー間でループしないようにする必要があります。それらは、同じターゲットエントリ名、スコープ、およびフィルターを使用して、同じサーバーに繰り返しアクセスして同じリクエストを行うことはできません。一部のクライアントは、操作の参照処理が発生するたびに増加するカウンターを使用している場合があります。これらの種類のクライアントは、ルートエントリとリーフエントリの間に少なくとも10層の名前付けコンテキストを持つDITを処理できる必要があります。
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schemas beyond those referenced in section 6.1. Different schemas can have different attribute types with the same names. The client can retrieve the subschema entries referenced by the subschemaSubentry attribute in the server's root DSE or in entries held by the server.
サーバーとの事前の合意がない場合、クライアントは、サーバーがセクション6.1で参照されているスキーマ以外の特定のスキーマをサポートすることを想定してはなりません（SHOULD NOT）。スキーマが異なれば、同じ名前の異なる属性タイプを持つことができます。クライアントは、サーバーのルートDSEまたはサーバーが保持するエントリ内のsubschemaSubentry属性によって参照されるサブスキーマエントリを取得できます。
When used with a connection-oriented transport, this version of the protocol provides facilities for the LDAP v2 authentication mechanism, simple authentication using a cleartext password, as well as any SASL mechanism [12]. SASL allows for integrity and privacy services to be negotiated.
このバージョンのプロトコルは、コネクション型トランスポートで使用すると、LDAP v2認証メカニズム、クリアテキストパスワードを使用した単純な認証、およびSASLメカニズムの機能を提供します[12]。 SASLにより、整合性とプライバシーサービスの交渉が可能になります。
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
サーバーが資格情報をクライアントに返すことを選択した場合は、それを返すことも許可されています。
Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
クリアテキストパスワードの使用は、基になるトランスポートサービスが機密性を保証できず、権限のない者にパスワードが開示される可能性がある場合は、お勧めできません。
When used with SASL, it should be noted that the name field of the BindRequest is not protected against modification. Thus if the distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field.
SASLで使用する場合、BindRequestの名前フィールドは変更から保護されないことに注意してください。したがって、クライアントの識別名（LDAPDN）が資格情報のネゴシエーションを通じて合意された場合、保護されていない名前フィールドの値よりも優先されます。
Implementations which cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies which prevent the return of entries or attributes in search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be cache.
LDAPを介して取得した属性とエントリをキャッシュする実装では、その情報が複数のクライアントに提供される場合、アクセス制御が確実に維持されるようにしなければなりません。 。たとえば、キャッシュは結果情報を、リクエストをキャッシュにしたクライアントにのみ提供できます。
This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes, and Steve Kille. Design ideas included in this document are based on those discussed in ASID and other IETF Working Groups. The contributions of individuals in these working groups is gratefully acknowledged.
このドキュメントは、Wengyik Yeong、Tim Howes、およびSteve KilleによるRFC 1777の更新版です。このドキュメントに含まれる設計のアイデアは、ASIDおよびその他のIETFワーキンググループで議論されたものに基づいています。これらのワーキンググループの個人の貢献はありがたく認められています。
[1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.
[1] ITU-T Rec。 X.500、「ディレクトリ：概念、モデル、およびサービスの概要」、1993年。
[2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[2] Yeong、W.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。
[3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994.
[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.
[4] Kille、S.、Wahl、M。、およびT. Howes、「Lightweight Directory Access Protocol（v3）：UTF-8 String Representation of Distinguished Names」、RFC 2253、1997年12月。
[5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[5] Wahl、M.、Coulbeck、A.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（v3）：Attribute Syntax Definitions」、RFC 2252、1997年12月。
[6] ITU-T Rec. X.501, "The Directory: Models", 1993.
[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.
[7] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[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.
[9] ハウズ、T。、およびM.スミス、「LDAP URL形式」、RFC 2255、1997年12月。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[10] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994.
[11] ITU-T Rec。 X.690、「ASN.1エンコードルールの仕様：基本、正規、および識別エンコードルール」、1994年。
[12] Meyers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.
[12] Meyers、J。、「Simple Authentication and Security Layer」、RFC 2222、1997年10月。
[13] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
[13] Universal Multi-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.
[14] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換フォーマット」、RFC 2044、1996年10月。
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
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
電話：+1 512 372-3160 Eメール：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
Steve Kille Isode Limited The Dome、The SquareリッチモンドTW9 1DT UK
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
Appendix A - Complete ASN.1 Definition
付録A-ASN.1の完全な定義
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 }
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.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。