Network Working Group B. Neal-Joslin, Ed.
Request for Comments: 4876 HP
Category: Informational L. Howard
PADL
M. Ansari
Infoblox
May 2007
A Configuration Profile Schema for
Lightweight Directory Access Protocol (LDAP)-Based Agents
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
Abstract
抽象
This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services.
この文書は、2つの主要コンポーネント、同様のディレクトリユーザーエージェントの分散構成のためのライトウェイトディレクトリアクセスプロトコル（LDAP）とそのスキーマの提案されたユースケース、を利用するエージェントのためのスキーマで構成されています。属性タイプとオブジェクトクラスのセットが提案されています。提案されたユースケースでは、ディレクトリ・ユーザ・エージェント（のDUAs）は、それらがサポートする特定のサービスのディレクトリデータの場所とアクセスパラメータを決定するために、このスキーマを使用することができます。また、提案された使用の場合には、属性とオブジェクトクラスマッピングがのDUAsは、エンドユーザーの環境のそれと一致するように彼らの予想（デフォルト）スキーマを再設定することができます。この文書は、特定のDUAサービスの設定について説明し、今後のドキュメントのスケルトンであることを意図しています。
Table of Contents
目次
1. Background and Motivation . . . . . . . . . . . . . . . . . . 3
2. General Information . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2.2. Attributes Summary . . . . . . . . . . . . . . . . . . . . 5
2.3. Object Classes Summary . . . . . . . . . . . . . . . . . . 5
2.4. Common Syntax/Encoding Definitions . . . . . . . . . . . . 5
3. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 6
3.2. Class Definition . . . . . . . . . . . . . . . . . . . . . 9
4. DUA Implementation Details . . . . . . . . . . . . . . . . . . 10
4.1. Interpreting the preferredServerList Attribute . . . . . . 10
4.2. Interpreting the defaultServerList Attribute . . . . . . . 11
4.3. Interpreting the defaultSearchBase Attribute . . . . . . . 12
4.4. Interpreting the authenticationMethod Attribute . . . . . 13
4.5. Interpreting the credentialLevel Attribute . . . . . . . . 15
4.6. Interpreting the serviceSearchDescriptor Attribute . . . . 16
4.7. Interpreting the attributeMap Attribute . . . . . . . . . 20
4.8. Interpreting the searchTimeLimit Attribute . . . . . . . . 23
4.9. Interpreting the bindTimeLimit Attribute . . . . . . . . . 23
4.10. Interpreting the followReferrals Attribute . . . . . . . . 24
4.11. Interpreting the dereferenceAliases Attribute . . . . . . 24
4.12. Interpreting the profileTTL Attribute . . . . . . . . . . 24
4.13. Interpreting the objectclassMap Attribute . . . . . . . . 25
4.14. Interpreting the defaultSearchScope Attribute . . . . . . 27
4.15. Interpreting the serviceAuthenticationMethod Attribute . . 27
4.16. Interpreting the serviceCredentialLevel Attribute . . . . 28
5. Binding to the Directory Server . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. Registration of Object Classes . . . . . . . . . . . . . . 31
8.2. Registration of Attribute Types . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35
LDAP [RFC4510] has brought about a nearly ubiquitous acceptance of the directory server. Many client applications (DUAs) are being created that use LDAP directories for many different services. And although the LDAP protocol has eased the development of these applications, some challenges still exist for both developers and directory administrators.
LDAP [RFC4510]は、ディレクトリサーバのほぼユビキタス受け入れをもたらしました。多くのクライアントアプリケーション（のDUAs）は、多くの異なるサービスのためのLDAPディレクトリを使用するように作成されています。 LDAPプロトコルは、これらのアプリケーションの開発を緩和しているものの、そして、いくつかの課題がまだ開発者やディレクトリの管理者の両方のために存在します。
The authors of this document are implementers of DUAs described by [RFC2307]. In developing these agents, we felt there were several issues that still need to be addressed to ease the deployment and configuration of a large network of these DUAs.
本書の著者は、[RFC2307]で説明したのDUAsの実装です。これらの薬剤の開発では、我々はまだこれらのDUAsの大規模なネットワークの展開と構成を容易にするために対処する必要があるいくつかの問題があったと感じました。
One of these challenges stems from the lack of a utopian schema. A utopian schema would be one that every application developer could agree upon and that would support every application. Unfortunately today, many DUAs define their own schema, even when they provide similar services (like RFC 2307 vs. Microsoft's Services for Unix [MSSFU]). These schemas contain similar attributes, but use different attribute names. This can lead to data redundancy within directory entries and cause directory administrators unwanted challenges, updating schemas and synchronizing data. Or, in a more common case, two or more applications may agree on common schema elements, but choose a different schema for other elements of data that might also be shareable between the applications. While data synchronization and translation tools exist, the authors of this document believe there is value in providing this capability in the directory user agent itself.
これらの課題の一つは、ユートピアスキーマの欠如に由来します。ユートピアスキーマは、すべてのアプリケーション開発者が合意可能性があり、それはすべてのアプリケーションをサポートするものであろう。残念ながら、今日、多くのDUAsは（Unix用のMicrosoftのサービス[MSSFU]対RFC 2307のように）、彼らが同様のサービスを提供しても、自分自身のスキーマを定義します。これらのスキーマは、同様の属性が含まれているが、異なる属性名を使用します。これは、スキーマを更新し、データを同期、ディレクトリエントリ内のデータの冗長性につながるとディレクトリ管理者が不要な課題を引き起こす可能性があります。または、より一般的な場合には、二つ以上のアプリケーションが共通のスキーマ要素に同意するだけでなく、アプリケーション間で共有可能であるかもしれないデータの他の要素のために異なるスキーマを選択することができます。データの同期や翻訳ツールが存在するが、この文書の著者は、ディレクトリユーザーエージェント自体にこの機能を提供する上で価値があると考えています。
Aside from proposing a schema for general use, one goal of this document is to eliminate data redundancy by having DUAs configure themselves to the schema of the deployed directory, instead of forcing the DUA's own schema on the directory.
別に一般的な使用のためのスキーマを提案から、この文書の一つの目標は、のDUAsが展開されたディレクトリのスキーマに自分自身を設定した、代わりのディレクトリにDUA独自のスキーマを強制することにより、データの冗長性を排除することです。
Another goal of this document is to provide the DUA with enough configuration information so that it can discover how to retrieve its data in the directory, such as what locations to search in the directory tree.
本書のもう一つの目標は、それがこのような場所は、ディレクトリツリーで検索するどのように、ディレクトリ内のデータを取得する方法を発見できるように、十分なコンフィギュレーション情報をDUAを提供することです。
Finally, this document intends to describe a configuration method for DUAs that can be shared among many DUAs on various platforms, providing, as such, a configuration profile. The purpose of this profile is to centralize and simplify management of DUAs.
最後に、この文書では、このような、構成プロファイルとして、提供し、様々なプラットフォーム上で多くのDUAs間で共有することができるのDUAsのための設定方法を説明していきます。このプロファイルの目的は、集中とのDUAsの管理を簡素化することです。
This document is intended to provide the skeleton framework for future documents that will describe the individual implementation details for the particular services provided by that DUA. The authors of this document plan to develop such a document for the Network Information Service DUA, described by RFC 2307 or its successor.
この文書は、そのDUAが提供する特定のサービスのために、個々の実装の詳細を説明します将来のドキュメントのスケルトンフレームワークを提供することを意図しています。この文書案の作成者は、RFC 2307やその後継で説明ネットワーク情報サービスDUAのために、このような文書を、開発します。
We expect that as DUAs take advantage of this configuration scheme, each DUA will require additional configuration parameters, not specified by this document. Thus, we would expect that new auxiliary object classes that contain new configuration attributes will be created and then joined with the structural class defined by this document to create a configuration profile for a particular DUA service. By joining various auxiliary object classes for different DUA services, the configuration of various DUA services can be controlled by a single configuration profile entry.
私たちは、のDUAsは、このコンフィギュレーション手法を活用するよう、各DUAはこの文書で指定されていない追加の設定パラメータを、必要になることを期待しています。したがって、我々は、新しい構成属性が含まれている新しい補助オブジェクトクラスを作成し、特定のDUAサービスの構成プロファイルを作成するには、この文書で定義された構造クラスに参加されることを期待します。異なるDUAサービスのための様々な補助オブジェクトクラスを接合することにより、様々なDUAサービスのコンフィギュレーションは、単一の構成プロファイル・エントリによって制御することができます。
The schema defined by this document is defined under the "DUA Configuration Schema". This schema is derived from the object identifier (OID): iso (1) org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett-Packard Company (11) directory (1) LDAP-UX Integration Project (3) DUA Configuration Schema (1). This OID is represented in this document by the keystring "DUAConfSchemaOID" (1.3.6.1.4.1.11.1.3.1).
この文書で定義されたスキーマは、「DUA構成スキーマ」の下に定義されます。このスキーマは、オブジェクト識別子（OID）から誘導される：ISO（1）ORG（3）DOD（6）インターネット（1）プライベート（4）企業（1）ヒューレット・パッカード・カンパニー（11）ディレクトリ（1）LDAP-UX統合プロジェクト（3）DUA構成スキーマ（1）。このOIDは、キー文字列「DUAConfSchemaOID」（1.3.6.1.4.1.11.1.3.1）によって、この文書で表されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following attributes are defined in this document:
以下の属性は、この文書で定義されています。
preferredServerList defaultServerList defaultSearchBase defaultSearchScope authenticationMethod credentialLevel serviceSearchDescriptor serviceCredentialLevel serviceAuthenticationMethod attributeMap objectclassMap searchTimeLimit bindTimeLimit followReferrals dereferenceAliases profileTTL
preferredServerList defaultServerListにに、defaultSearchBase defaultSearchScope AuthenticationMethodがcredentialLevelをserviceSearchDescriptorにserviceCredentialLevelのserviceAuthenticationMethodのattributeMapのobjectclassMap searchTimeLimit bindTimeLimit followReferrals dereferenceAliases profileTTL
The following object class is defined in this document:
以下のオブジェクトクラスは、この文書で定義されています。
DUAConfigProfile
DUAConfigProfile
The proposed string encodings used by the attributes defined in this document can be found in Section 4. This document makes use of ABNF [RFC4234] for defining new encodings.
この文書で定義された属性で使用される提案した文字列のエンコーディングは、第4節で見つけることができます。この文書は、新しいエンコーディングを定義するためのABNF [RFC4234]を使用しています。
The following syntax definitions are used throughout this document.
次の構文定義は、この文書全体で使用されています。
The list of used syntaxes are:
使用済みの構文のリストは以下のとおりです。
+---------------------------+---------------------------------------+
| Key | Source |
+---------------------------+---------------------------------------+
| keystring | as defined by [RFC4512] Section 1.4 |
| descr | as defined by [RFC4512] Section 1.4 |
| SP | as defined by [RFC4512] Section 1.4 |
| WSP | as defined by [RFC4512] Section 1.4 |
| base | as defined by distinguishedName in |
| | [RFC4514] |
| distinguishedName | as defined by [RFC4514] Section 2 |
| relativeDistinguishedName | as defined by [RFC4514] Section 2 |
| scope | as defined by [RFC4516] Section 2 |
| host | as defined by [RFC3986] Section 3.2.2 |
| hostport | host [":" port ] |
| port | as defined by [RFC3986] Section 3.2.3 |
| serviceID | same as keystring |
+---------------------------+---------------------------------------+
This document does not define new syntaxes that must be supported by the directory server. Instead, these syntaxes are merely expected to be interpreted by the DUA. As referenced in the schema definition in Section 3, most encodings are expected to be stored in attributes using common syntaxes, such as the Directory String syntax, as defined in Section 3.3.6 of [RFC4517]. Refer to RFC 4517 for additional syntaxes used by this schema.
この文書では、ディレクトリサーバによってサポートされている必要があり、新たな構文を定義していません。代わりに、これらの構文は単にDUAによって解釈されることが期待されます。第3のスキーマ定義で参照されるように、ほとんどのエンコーディングは、[RFC4517]のセクション3.3.6で定義されるように、そのようなディレクトリ文字列構文などの一般的な構文を使用して、属性に格納されることが期待されます。このスキーマで使用される追加の構文については、RFC 4517を参照してください。
This section defines a proposed schema. This schema does not require definition of new matching rules or syntaxes, and it may be used for any purpose seen. A proposed use of this schema to support elements of configuration of a directory user agent is described in Section 4.
このセクションでは、提案されたスキーマを定義します。このスキーマは、新しいマッチングルールや構文の定義を必要としない、それは見てどのような目的のために使用することができます。ディレクトリユーザエージェントの構成要素をサポートするために、このスキーマの提案された使用は、セクション4に記載されています。
This section contains attribute definitions used by agents. The syntax used to describe these attributes is defined in [RFC4512], Section 4.1.2. Individual syntaxes and matching rules used within these descriptions are described in [RFC4517], Sections 3.3 and 4.2, respectively.
このセクションでは、エージェントが使用する属性の定義が含まれています。これらの属性を記述するために使用する構文は、[RFC4512]、セクション4.1.2で定義されています。それぞれ個々の構文およびこれらの記述内で使用されるマッチング規則[RFC4517]に記載されており、セクション3.3および4.2。
( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' DESC 'List of default servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerListに' DESC 'デフォルトサーバのリスト' 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE）
( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' DESC 'Default base for searches' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.1 NAME平等distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE 'に、defaultSearchBase' DESC '検索のデフォルト基地'）
( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC 'List of preferred servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC '好適なサーバの一覧' 1.3.6.1.4.1.1466.115.121.1.15単一値）
( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' DESC 'Maximum time an agent or service allows for a search to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.3 NAME「searchTimeLimit」DESC平等integerMatchがintegerOrderingMatch SYNTAXに1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUEオーダー「最大時間エージェントまたはサービスが完了するまでに検索することができます」 ）
( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' DESC 'Maximum time an agent or service allows for a bind operation to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.4 NAME「bindTimeLimit」DESC平等integerMatchがintegerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27オーダー「最大時間エージェントまたはサービスが完了するのバインド操作が可能になります」シングルVALUE）
( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' DESC 'An agent or service does or should follow referrals' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.5 NAME「followReferrals」DESC「エージェントまたはサービスがないか照会従うべき」平等booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7単一値）を
( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' DESC 'Identifies the types of authentication methods either used, required, or provided by a service or peer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.6 NAME「AuthenticationMethodが」DESC「は認証方法の種類を識別いずれか、使用に必要な、またはサービスまたはピアによって提供される」平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115。 121.1.15単一値）
( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' DESC 'Time to live, in seconds, before a profile is considered stale' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
平等integerMatchがintegerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27シングルオーダーのプロファイルが無効と見なされる前に、秒単位の生存時間、 '（1.3.6.1.4.1.11.1.3.1.1.7 NAME「profileTTL」DESC VALUE）
( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' DESC 'Attribute mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.3.1.1.9 NAME「のattributeMap」DESC「属性のマッピングは、使用する必要、または薬剤またはサービスによってサポートされる」平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials either used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.10 NAME「credentialLevelを」DESCの資格情報の識別型のいずれエージェントまたはサービスによって、使用に必要な、またはサポートされている「平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE -VALUE）
( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' DESC 'Object class mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.3.1.1.11 NAME「のobjectclassMap」DESC 1.3.6.1.4.1.1466.115.121.1.26平等caseIgnoreIA5Match SYNTAX「オブジェクトクラスマッピングはエージェントまたはサービスによって、使用に必要な、またはサポートされています」）
( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' DESC 'Default scope used when performing a search' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.12 NAME平等caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE 'defaultSearchScope' DESC '検索を実行する場合に使用するデフォルトのスコープ'）
( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' DESC 'Specifies the type of credentials either used, required, or supported by a specific service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.3.1.1.13 NAME「serviceCredentialLevel」DESCは1.3.6.1.4.1.1466.115.121.1.26平等caseIgnoreIA5Match SYNTAX「のいずれか特定のサービスによって、使用に必要な、またはサポートされている資格情報のタイプを指定します」）
( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' DESC 'Specifies search descriptors required, used, or supported by a particular service or agent' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.4.1.11.1.3.1.1.14 NAME「serviceSearchDescriptorに」DESC「の使用に必要な検索記述子を、指定、または特定のサービスまたはエージェントでサポートされている」平等CaseExactMatchのSUBSTR caseExactSubstringsMatch SYNTAXは1.3.6.1.4.1.1466.115.121.1.15 ）
( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' DESC 'Specifies types authentication methods either used, required, or supported by a particular service' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.4.1.11.1.3.1.1.15 NAME「serviceAuthenticationMethodを」DESC「はタイプの認証方法を指定するいずれかの特定のサービスによって、使用に必要な、またはサポートされている」平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ）
( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases' DESC 'Specifies if a service or agent either requires, supports, or uses dereferencing of aliases.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.3.1.1.16 NAME「dereferenceAliases」DESC「はサービスまたはエージェントは、必要がサポートしている、または別名の間接参照を使用してのいずれかどうかを指定します。」平等booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE）
The object class below is constructed from the attributes defined in Section 3.1, with the exception of the "cn" attribute, which is defined in [RFC4519]. "cn" is used to represent the name of the DUA configuration profile and is recommended for the relative distinguished name (RDN) [RFC4514] naming attribute. This object class is used specifically by the DUA described in Section 4. The syntax used to describe this object class is defined in [RFC4512], Section 4.1.1.
オブジェクト・クラスは、以下の[RFC4519]で定義される「CN」属性を除いて、セクション3.1で定義された属性から構成されています。 「CN」はDUA構成プロファイルの名前を表すために使用される属性を命名する相対識別名（RDN）[RFC4514]のために推奨されています。このオブジェクトクラスは、DUAは、セクション4 RFC4512]で定義され、このオブジェクトのクラスを記述するために使用する構文、セクション4.1.1に記載することにより具体的に使用されます。
( 1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile' SUP top STRUCTURAL DESC 'Abstraction of a base configuration for a DUA' MUST ( cn ) MAY ( defaultServerList $ preferredServerList $ defaultSearchBase $ defaultSearchScope $ searchTimeLimit $ bindTimeLimit $ credentialLevel $ authenticationMethod $ followReferrals $ dereferenceAliases $ serviceSearchDescriptor $ serviceCredentialLevel $ serviceAuthenticationMethod $ objectclassMap $ attributeMap $ profileTTL ) )
（1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile' SUPトップMUST（CN）STRUCTURAL DESC 'DUAのための基本構成を抽象化' は、（defaultServerListに$ preferredServerList $に、defaultSearchBase $ defaultSearchScope $ searchTimeLimit $ bindTimeLimit $ credentialLevelを$ AuthenticationMethodが$ followReferrals $ dereferenceAliases $ serviceSearchDescriptorに$ serviceCredentialLevel $ serviceAuthenticationMethodを$のobjectclassMap $のattributeMap $ profileTTL））
This section describes an implementation of the schema described in Section 3. Details about how a DUA should format and interpret the defined attributes are described below. Agents that make use of the DUAConfigProfile object class are expected to follow the specifications in this section.
このセクションでは、3詳細DUAをフォーマットし、定義された属性は、以下に説明されていると解釈すべきかについてのセクションで説明したスキーマの実装について説明します。 DUAConfigProfileオブジェクトクラスを利用する薬剤は、このセクションの仕様に従うことが期待されています。
Note: Many of the subsections below contain examples. Unless otherwise specified, these examples are rendered using the LDAP Data Interchange Format (LDIF) [RFC2849].
注意：サブセクションの多くは、以下の例が含まれています。特に断らない限り、これらの例は、LDAPデータ交換フォーマット（LDIF）[RFC2849]を使用してレンダリングされます。
Interpretation:
解釈：
As described by the syntax, the preferredServerList parameter is a whitespace-separated list of server addresses and associated port numbers. When the DUA needs to contact a directory server agent (DSA), the DUA MUST first attempt to contact one of the servers listed in the preferredServerList attribute. The DUA MUST contact the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs MUST be queried in the order provided (left to right) until a connection is established with a DSA. Once a connection with a DSA is established, the DUA SHOULD NOT attempt to establish a connection with the remaining DSAs. The purpose of enumerating multiple DSAs is not for supplemental data, but for high availability of replicated data. This is also the main reason why an LDAP URL [RFC3986] syntax was not selected for this document.
構文によって記載されるように、preferredServerListパラメータは、サーバのアドレスと関連付けられたポート番号の空白で区切られたリストです。 DUAはディレクトリサーバーエージェント（DSA）に連絡する必要がある場合、DUAは、最初のpreferredServerList属性に記載されているサーバーのいずれかに連絡しようとしなければなりません。 DUAは、リストの最初のサーバアドレスで指定されたDSAに連絡しなければなりません。そのDSAが使用できない場合、接続がDSAと確立されるまで、残りのDSAは、（左から右に）設けられた順に照会しなければなりません。 DSAとの接続が確立されると、DUAは残りのDSAとの接続を確立することを試みるべきではありません。複数のDSAを列挙する目的は、補足データのためではなく、複製されたデータの高可用性のため。また、これは、LDAP URL [RFC3986]構文は、このドキュメントのために選択されなかった主な理由です。
If the DUA is unable to contact any of the DSAs specified by the preferredServerList, the defaultServerList attribute MUST be examined, as described in Section 4.2. The servers identified by
DUAはpreferredServerListで指定のDSAのいずれかに連絡できない場合、セクション4.2で説明したように、defaultServerListに属性は、検査されなければなりません。で識別されるサーバ
the preferredServerList MUST be contacted before attempting to contact any of the servers specified by the defaultServerList.
preferredServerListはdefaultServerListにで指定されたサーバーのいずれかに連絡しようとする前に接触させなければなりません。
Syntax:
構文：
serverList = hostport *(SP [hostport])
いるserverList =のHostPort *（SP【のHostPort]）
Default Value:
デフォルト値：
The preferredServerList attribute does not have a default value. Instead a DUA MUST examine the defaultServerList attribute.
preferredServerList属性はデフォルト値はありません。代わりに、DUAはdefaultServerListに属性を調べる必要があります。
Other attribute notes:
他の属性の注意事項：
This attribute is used in conjunction with the defaultServerList attribute. Please see Section 4.2 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod. Please review Section 5 for details on how a DUA should properly bind to a DSA.
この属性は、defaultServerListに属性と組み合わせて使用されます。追加の実装の注意事項については、セクション4.2を参照してください。 DUAはのDSAを照会する方法を決定することも、追加の構成属性、credentialLevelを、serviceCredentialLevel、bindTimeLimit、serviceAuthenticationMethodを、とはAuthenticationMethodに依存します。 DUAが正しくDSAにバインドする方法の詳細については、第5章をご覧ください。
Example:
例：
preferredServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:389
Interpretation:
解釈：
The defaultServerList attribute MUST only be examined if the preferredServerList attribute is not provided, or the DUA is unable to establish a connection with any of the DSAs specified by the preferredServerList.
preferredServerList属性が提供されない場合defaultServerListに属性のみを検討しなければならない、またはDUAはpreferredServerListで指定のDSAのいずれかとの接続を確立することができません。
If more than one address is provided, the DUA may choose either to accept the order provided or to create its own order, based on what the DUA determines is the "best" order of DSAs to query. For example, the DUA may choose to examine the server list and to query the DSAs in order based on the "closest" server or the server with the least amount of "load". Interpretation of the "best" server order is entirely up to the DUA, and not part of this document.
複数のアドレスが提供されている場合は、DUAは選ぶことができるいずれかの提供順序を受け入れることや、独自の順序を作成するには、DUAが決定した内容に基づいて照会するのDSAの「最良の」ためです。たとえば、DUAは、サーバーのリストを調べるすることもできますし、「最も近い」サーバーまたは「負荷」の量が最も少ないサーバーに基づく順序でのDSAを照会します。 「最良」のサーバの順序の解釈は、この文書の一部ではない、完全にDUA次第です、と。
Once the order of server addresses is determined, the DUA contacts the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs SHOULD be queried until an available DSA is found, or no more DSAs are available. If a server address or port is invalid, the DUA SHOULD proceed to the next server address as described just above.
サーバーのアドレスの順序が決定されると、DUAの連絡先DSAは、リストの最初のサーバアドレスで指定されました。そのDSAが使用できない場合、利用可能なDSAが発見されるまで、残りのDSAが照会されるべきである、またはそれ以上のDSAが用意されていません。サーバーのアドレスまたはポートが無効である場合だけで上記のように、DUAは、次のサーバアドレスに進めるべき。
Syntax:
構文：
serverList = hostport *(SP [hostport])
いるserverList =のHostPort *（SP【のHostPort]）
Default Value:
デフォルト値：
If a defaultServerList attribute is not provided, the DUA MAY attempt to contact the same DSA that provided the configuration profile entry itself. The default DSA is contacted only if the preferredServerList attribute is also not provided.
defaultServerListに属性が提供されていない場合、DUAは、構成プロファイルのエントリー自体を提供する同じDSAに連絡しようとすることができます。デフォルトのDSAは、preferredServerList属性も用意されていない場合にのみ接触されます。
Other attribute notes:
他の属性の注意事項：
This attribute is used in conjunction with the preferredServerList attribute. Please see Section 4.1 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod. Please review Section 5 for details on how a DUA should properly contact a DSA.
この属性は、preferredServerList属性と組み合わせて使用されます。追加の実装の注意事項については、セクション4.1を参照してください。 DUAはのDSAを照会する方法を決定することも、追加の構成属性、credentialLevelを、serviceCredentialLevel、bindTimeLimit、serviceAuthenticationMethodを、とはAuthenticationMethodに依存します。 DUAが正しくDSAに連絡する方法の詳細については、第5章をご覧ください。
Example:
例：
defaultServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:5912
Interpretation:
解釈：
When a DUA needs to search the DSA for information, this attribute provides the base for the search. This parameter can be overridden or appended by the serviceSearchDescriptor attribute. See Section 4.6.
DUAは情報のためのDSAを検索する必要がある場合、この属性は、検索のための基盤を提供します。このパラメータは、serviceSearchDescriptor属性によって上書きまたは追加することができます。 4.6節を参照してください。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517].
OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
There is no default value for the defaultSearchBase. A DUA MAY define its own method for determining the search base, if the defaultSearchBase is not provided.
defaultSearchBaseのためのデフォルト値はありません。 defaultSearchBaseが提供されていない場合DUAは、検索ベースを決定するための独自の方法を定義してもよいです。
Other attribute notes:
他の属性の注意事項：
This attribute is used in conjunction with the serviceSearchDescriptor attribute. See Section 4.6.
この属性はserviceSearchDescriptor属性と組み合わせて使用されます。 4.6節を参照してください。
Example:
例：
defaultSearchBase: dc=mycompany,dc=com
defaultSearchBase：DC = mycompanyの、dc = comの
Interpretation:
解釈：
The authenticationMethod attribute defines an ordered list of LDAP bind methods to be used when attempting to contact a DSA. The serviceAuthenticationMethod overrides this value for a particular service (see Section 4.15). Each method MUST be attempted in the order provided by the attribute, until a successful LDAP bind is performed ("none" is assumed to always be successful). However, the DUA MAY skip over one or more methods. See Section 5 for more information.
AuthenticationMethodが属性はDSAに連絡しようとするときに使用するLDAPバインドメソッドの順序付きリストを定義します。 serviceAuthenticationMethodを（セクション4.15を参照）、特定のサービスのために、この値を上書きします。成功したLDAPバインドが実行されるまで、それぞれの方法には、（「なし」が常に成功すると想定されていない）、属性によって提供順序で試行されなければなりません。しかし、DUAは、1つまたは複数のメソッドをスキップするかもしれません。詳細については、セクション5を参照してください。
none - The DUA does not perform an LDAP bind.
どれも - DUAは、LDAPバインドを行いません。
simple - The DUA performs an LDAP simple bind.
シンプル - DUAは、LDAP簡易バインドを実行します。
sasl - The DUA performs an LDAP Simple Authentication and Security Layer (SASL) [RFC4422] bind using the specified SASL mechanism and options.
SASLは - DUAは、LDAP簡易認証セキュリティー層（SASL）指定されたSASLメカニズムとオプションを使用して、[RFC4422]のバインドを実行します。
tls - The DUA performs an LDAP StartTLS operation followed by the specified bind method (for more information refer to Section 4.14 of [RFC4511]).
TLS - DUA（詳細については[RFC4511]のセクション4.14を参照）指定されたバインド方法に続いたLDAP StartTLSを演算を行います。
Syntax:
構文：
authMethod = method *(";" method)
AuthMethod =メソッド*（ ";" 方法）
method = none / simple / sasl / tls
方法=なし/シンプル/ SASL / TLS
none = "none"
なしは=「なし」
simple = "simple"
シンプル=「シンプル」
sasl = "sasl/" saslmech [ ":" sasloption ]
SASL = "SASL /" saslmechの[ "：" sasloption]
sasloption = "auth-conf" / "auth-int"
sasloption = "のauth-confの" / "のauth-int型"
tls = "tls:" (none / simple / sasl)
TLS = "TLS："（なし/シンプル/ SASL）
saslmech = SASL mechanism name as defined in [SASLMECH]
【SASLMECH]で定義されるようsaslmech = SASL機構名
Note: Although multiple authentication methods may be specified in the syntax, at most one of each type is allowed. That is, "simple;simple" is invalid.
注：複数の認証方法は、構文で指定することができるが、各タイプの多くても1つが許可されています。無効です。「シンプルシンプル」それは、あります。
Default Value:
デフォルト値：
If the authenticationMethod or serviceAuthenticationMethod (for that particular service) attributes are not provided, the DUA MAY choose to bind to the DSA using any method defined by the DUA. However, if either authenticationMethod or serviceAuthenticationMethod is provided, the DUA MUST only use the methods specified.
AuthenticationMethodがまたはserviceAuthenticationMethodを（その特定のサービスのための）属性が用意されていない場合は、DUAはDUAによって定義された任意の方法を使用してDSAにバインドするために選ぶかもしれません。 AuthenticationMethodがまたはserviceAuthenticationMethodをどちらかが提供される場合は、DUAは、指定されたメソッドを使用しなければなりません。
Other attribute notes:
他の属性の注意事項：
When using TLS, the string "tls:sasl/EXTERNAL" implies that both client and server (DSA and DUA) authentications are to be performed. Any other TLS authentication method implies server-only (DSA side credential) authentication, along with the other SASL method used for DUA-side authentication.
TLSを使用する場合は、文字列「TLS：SASL / EXTERNAL」は、そのクライアントとサーバー（DSAとDUA）の両方を意味認証を行うことになっています。他のTLS認証方法はDUA側認証に使用される他のSASL方式と共に、サーバーのみ（DSA側クレデンシャル）認証を暗示します。
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, serviceAuthenticationMethod, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAものDSAにバインドする方法を決定することは、追加の構成属性、credentialLevelを、serviceCredentialLevel、serviceAuthenticationMethodを、そしてbindTimeLimitに依存します。適切DSAにバインドする方法の詳細については、第5章をご覧ください。
Example:
例：
authenticationMethod: tls:simple;sasl/DIGEST-MD5
AuthenticationMethodが：TLS：シンプル、SASL / DIGEST-MD5
(see [RFC2831])
（[RFC2831]を参照）
Interpretation:
解釈：
The credentialLevel attribute defines what type(s) of credential(s) the DUA MUST use when contacting the DSA. The serviceCredentialLevel overrides this value for a particular service (Section 4.16). The credentialLevel can contain more than one credential type, separated by whitespace.
credentialLevelを属性は、DSAと接触するときDUAを使用しなければならないクレデンシャル（複数可）の種類（複数可）を定義します。 serviceCredentialLevelは、特定のサービス（セクション4.16）のために、この値を上書きします。 credentialLevelを空白で区切って、複数の資格情報の種類を含めることができます。
anonymous The DUA SHOULD NOT use a credential when binding to the DSA.
DSAに結合する際に匿名ザ・DUAは、資格情報を使用しないでください。
proxy The DUA SHOULD use a known proxy identity when binding to the DSA. A proxy identity is a specific credential that was created to represent the DUA. This document does not define how the proxy user should be created, or how the DUA should determine what the proxy user's credential is. This functionality is up to each implementation.
DSAに結合するときにプロキシDUAが知られているプロキシIDを使用すべきです。プロキシIDはDUAを表すために作成された特定の資格です。この文書では、プロキシ・ユーザーを作成する方法を定義していない、またはDUAは、プロキシ・ユーザーの資格情報が何であるかを判断する必要がありますか。この機能は、各実装に任されています。
self When the DUA is acting on behalf of a known identity, the DUA MUST attempt to bind to the DSA as that identity. The DUA should contain methods to determine the identity of the user such that the identity can be authenticated by the directory server using the defined authentication methods.
DUAが知られているアイデンティティを代表して行動している自己は、DUAは、そのIDとDSAにバインドしようとしなければなりません。 DUAはアイデンティティが定義された認証方式を使用して、ディレクトリサーバで認証することができるように、ユーザーの身元を決定するためのメソッドが含まれている必要があります。
If the credentialLevel contains more than one credential type, the DUA MUST use the credential types in the order specified. However, the DUA MAY skip over one or more credential types. As soon as the DUA is able to successfully bind to the DSA, the DUA SHOULD NOT attempt to bind using the remaining credential types.
credentialLevelを複数の資格情報の種類が含まれている場合は、DUAは、指定された順序でクレデンシャルタイプを使用しなければなりません。しかし、DUAは、一つ以上のクレデンシャルタイプをスキップするかもしれません。すぐDUAが正常にDSAに結合することができるよう、DUAは残りのクレデンシャルタイプを使用してバインドを試みるべきではありません。
Syntax:
構文：
credentialLevel = level *(SP level)
credentialLevelを=レベル*（SPレベル）
level = self / proxy / anonymous
レベル=自己/プロキシ/匿名
self = "self"
自己=「自己」
proxy = "proxy"
プロキシ=「プロキシ」
anonymous = "anonymous"
匿名=「匿名」
Note: Although multiple credential levels may be specified in the syntax, at most one of each type is allowed. Refer to implementation notes in Section 5 for additional syntax requirements for the credentialLevel attribute.
注：複数の資格レベルは、構文で指定することができるが、各タイプの多くても1つが許可されています。 credentialLevelを属性の追加の構文の要件については、セクション5で実装ノートを参照してください。
Default Value:
デフォルト値：
If the credentialLevel attribute is not defined, the DUA SHOULD NOT use a credential when binding to the DSA (also known as anonymous).
credentialLevelを属性が定義されていない場合（匿名として知られている）DSAに結合したときに、DUAは、資格を使用しないでください。
Other attribute notes:
他の属性の注意事項：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, authenticationMethod, serviceAuthenticationMethod, serviceCredentialLevel, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAものDSAにバインドする方法を決定することは、追加の構成属性、AuthenticationMethodが、serviceAuthenticationMethodを、serviceCredentialLevel、およびbindTimeLimitに依存します。適切DSAにバインドする方法の詳細については、第5章をご覧ください。
Example:
例：
credentialLevel: proxy anonymous
credentialLevelを：匿名プロキシ
Interpretation:
解釈：
The serviceSearchDescriptor attribute defines how and where a DUA SHOULD search for information for a particular service. The serviceSearchDescriptor contains a serviceID, followed by one or more base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service. Multiple base-scope-filters allow the DUA to search for data in multiple locations in the directory information tree (DIT). Although this syntax is very similar to the LDAP URL [RFC3986], this document requires the ability to supply multiple hosts as part of the configuration of the DSA. In addition, an ordered list of search descriptors is required, which cannot be specified by the LDAP URL.
どのように、どこDUAは、特定のサービスに関する情報を検索するserviceSearchDescriptor属性を定義します。 serviceSearchDescriptorには、1つ以上のベーススコープフィルタトリプル続いているServiceIDを含んでいます。これら塩基スコープフィルタトリプルは、特定のサービスの検索を定義するために使用されます。複数のベース - スコープフィルタDUAはディレクトリ情報ツリー（DIT）内の複数の場所にデータを検索することを可能にします。この構文はLDAPのURL [RFC3986]に非常によく似ていますが、この文書は、DSAの構成の一部として、複数のホストを供給する能力が必要です。また、検索記述子の順序付きリストは、LDAP URLで指定することができない、必要とされます。
The serviceSearchDescriptor might also contain the DN of an entry that will contain an alternate profile. The DSA SHOULD re-evaluate the alternate profile and perform searches as specified by that profile.
serviceSearchDescriptorにはまた別のプロファイルが含まれていますエントリのDNが含まれている場合があります。 DSAは、別のプロファイルを再評価し、そのプロファイルによって指定される検索を実行する必要があります。
If the base, as defined in the serviceSearchDescriptor, is followed by the "," (ASCII 0x2C) character, this base is known as a relative base. This relative base may be constructed of one or more RDN components. In this case, the DUA MUST define the search base by appending the relative base with the defaultSearchBase.
塩基が、でserviceSearchDescriptorで定義されるように、「」（ASCII 0x2C）文字が続く場合、この基は、相対ベースとして知られています。この相対的な塩基は、一つ以上のRDNのコンポーネントで構成されてもよいです。この場合、DUAはに、defaultSearchBase相対塩基を付加することによって、検索ベースを定義しなければなりません。
Syntax:
構文：
serviceSearchList = serviceID ":" serviceSearchDesc *(";" serviceSearchDesc)
serviceSearchList =サービスID "：" serviceSearchDescの*（ ";" serviceSearchDesc）
serviceSearchDesc = confReferral / searchDescriptor
serviceSearchDesc = confReferral /たSearchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]]
たSearchDescriptor = [ベース] [ "？" [scopeSyntax] [ "？" [フィルタ]]]
confReferral = "ref:" distinguishedName
confReferral = "参照：" distinguishedNameの
base = distinguishedName / relativeBaseName
基地= distinguishedNameの/ relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
relativeBaseName = 1 *（relativeDistinguishedName ""）
filter = UTF-8 encoded string
フィルタ= UTF-8でエンコードされた文字列
If the confReferral, base, relativeBaseName, or filter contains the ";" (ASCII 0x3B), "?" (ASCII 0x3F), """ (ASCII 0x22), or "\" (ASCII 0x5C) characters, those characters MUST be escaped (preceded by the "\" character). Alternately, the DN may be surrounded by quotes (ASCII 0x22). Refer to RFC 4514. If the confReferral, base, relativeBaseName, or filter are surrounded by quotes, only the """ character needs to be escaped. Any character that does not need to be escaped, and yet is preceded by the "\" character, results in both the "\" character and the character itself.
confReferral場合、ベース、relativeBaseName、またはフィルタが含まれています「;」 （ASCII 0x3B）、 "？" （ASCIIは0x3F）、 ""」（アスキーの0x22）、または "\"（\ "文字（ASCII 0x5Cを）文字は、これらの文字がが先行）エスケープしなければならない"。代わりに、DNは、引用符で囲まれていてもよい（ASCIIの0x22 ）。RFC 4514.を参照してくださいconfReferral、ベース、relativeBaseName、またはフィルタは、唯一の「」」文字をエスケープする必要があり、引用符で囲まれている場合。エスケープする必要はありませんし、まだ「\」の文字が付いている任意の文字は、「\」の文字と文字自体の両方になります。
The usage and syntax of the filter string MUST be defined by the DUA service. A suggested syntax would be that defined by [RFC4515].
フィルタ文字列の使用法と構文は、DUAサービスによって定義されなければなりません。提案構文は、[RFC4515]で定義されたということでしょう。
If a DUA is performing a search for a particular service that has a serviceSearchDescriptor defined, the DUA MUST set the base, scope, and filter as defined. Each base-scope-filter triple represents a single LDAP search operation. If multiple base-scope-filter triples are provided in the serviceSearchDescriptor, the DUA SHOULD perform multiple search requests, and in that case, it MUST be in the order specified by the serviceSearchDescriptor.
DUA定義でserviceSearchDescriptorを有する特定のサービスの検索を実行している場合に定義されるように、DUAは、ベース、スコープ、およびフィルタを設定しなければなりません。各ベース・スコープ・フィルタは、トリプル単一のLDAP検索操作を表します。複数のベース - スコープフィルタトリプルをserviceSearchDescriptorに設けられている場合、DUAは、複数の検索要求を実行する必要があり、その場合には、値は、serviceSearchDescriptorによって指定された順序である必要があります。
FYI: Service search descriptors do not exactly follow the LDAP URL syntax [RFC4516]. The reasoning for this difference is to separate the host name(s) from the filter. This allows the DUA to have a more flexible solution in choosing its DSA.
FYI：サービス検索記述子は、正確にLDAP URL構文[RFC4516]を従っていません。この違いの理由は、フィルタからのホスト名（複数可）を分離することです。これは、DUAはそのDSAを選択する際に、より柔軟なソリューションを持つことができます。
Default Value:
デフォルト値：
If a serviceSearchDescriptor, or an element thereof, is not defined for a particular service, the DUA SHOULD create the base, scope, and filter as follows:
serviceSearchDescriptorに、またはそれらの要素は、特定のサービスのために定義されていない場合、次のように、DUAは、ベース、スコープ、およびフィルタを作成する必要があります。
base - Same as the defaultSearchBase.
ベース - に、defaultSearchBaseと同じ。
scope - Same as the defaultSearchScope.
スコープ - defaultSearchScopeと同じ。
filter - Use defaults as defined by DUA's service.
フィルタ - DUAのサービスで定義されたデフォルトを使用します。
If the defaultSearchBase or defaultSearchScope is not defined, then the DUA service MAY use its own default.
defaultSearchBaseまたはdefaultSearchScopeが定義されていない場合は、DUAサービスは、独自のデフォルトを使用するかもしれません。
Other attribute notes:
他の属性の注意事項：
If a serviceSearchDescriptor exists for a given service, the service MUST use at least one base-scope-filter triple in performing searches. It SHOULD perform multiple searches per service if multiple base-scope-filter triples are defined for that service.
serviceSearchDescriptorには、所与のサービスのために存在している場合、サービスは、検索を実行する際に三重少なくとも1つの塩基スコープ・フィルタを使用しなければなりません。複数のベース - スコープフィルタトリプルは、そのサービスのために定義されている場合には、サービスごとに複数の検索を実行しなければなりません。
The details of how the "filter" is interpreted by each DUA's service is defined by that service. This means the filter is NOT REQUIRED to be a legal LDAP filter [RFC4515]. Furthermore, determining how attribute and object class mapping affects that search filter MUST be defined by the service. That is, the DUA SHOULD specify if the attributes in the filter are assumed to already have been mapped, or if it is expected that attribute mapping (see Section 4.7) would be applied to the filter. In general practice, implementation and usability suggests that attribute and object class mapping (Sections 4.7 and 4.13) SHOULD NOT be applied to the filter defined in the serviceSearchDescriptor.
「フィルタ」の各DUAのサービスがどのように解釈するかの詳細は、そのサービスによって定義されます。これは、フィルタは、法的LDAPフィルタ[RFC4515]である必要はないことを意味します。さらに、属性とオブジェクトクラスのマッピングが検索フィルタがサービスによって定義されなければならないことをどのように影響するかを決定します。フィルタの属性がすでにマップされていると想定されている場合つまり、DUAは指定する必要があり、またはそれを属性マッピングは（4.7節を参照）、フィルタに適用されることが期待されている場合。一般的に、インプリメンテーションとユーザビリティは、属性およびオブジェクト・クラス・マッピング（セクション4.7および4.13）はserviceSearchDescriptorにで定義されたフィルタに適用されるべきではないことを示唆しています。
The serviceID is unique to a given service within the scope of any DUA that might use the given profile, and should be defined by that service. Registration of serviceIDs is not addressed by this document. However, as per the guidance at the end of Section 1, when DUA developers define their use of the DUAConfigProfile schema, they will define the serviceIDs used by that DUA.
サービスIDは、特定のプロファイルを使用する可能性のあるすべてのDUAの範囲内で特定のサービスに固有であり、そのサービスによって定義されるべきです。 serviceIDsの登録は、この文書によって対処されていません。しかし、DUA開発者はDUAConfigProfileスキーマの使用を定義する第1節の終わりに指導、あたりとして、彼らはそのDUAによって使用されるserviceIDsを定義します。
searchGuide and enhancedSearchGuide [RFC4517]:
searchGuideとenhancedSearchGuide [RFC4517]：
There are a few reasons why the authors chose not to take advantage of the existing searchGuide and enhancedSearchGuide attributes and related syntaxes. While the enhancedSearchGuide met a number of the serviceSearchDescriptor requirements, serviceSearchDescriptor was developed primarily to support associating search operations with services. Multiple services could be configured using the same profile, thus requiring the serviceID to be specified together with the search descriptor information. A few other reasons for not using enhancedSearchGuide include:
著者らは、既存のsearchGuideを利用しないことを選択したとenhancedSearchGuide属性および関連構文いくつかの理由があります。 enhancedSearchGuideがserviceSearchDescriptorに要件の数を満たしながら、serviceSearchDescriptorには、主にサービスを検索操作を関連付けるサポートするために開発されました。複数のサービスは、このように検索記述情報とともに指定するサービスIDを必要と同じプロファイルを使用して構成することができます。 enhancedSearchGuideを使用していないため、いくつかの他の理由は、次のとおりです。
The need to specify alternate search bases, including the ability to specify search bases that are relative to the parent defaultSearchBase.
親に、defaultSearchBaseに関連している検索ベースを指定する機能など、代替検索ベースを指定する必要があります。
The need to specify alternate profiles using the "ref:" syntax.
構文：「参照」を使用して別のプロファイルを指定する必要があります。
The ability for individual services to specify their own syntaxes for the format of the search filter.
個々のサービスのための能力は、検索フィルタの形式のために、独自の構文を指定します。
The authors' belief that the user community is more familiar with the search filter syntax described by RFC 4515 than with that described by the enhancedSearchGuide syntax.
著者の信念は、ユーザーコミュニティはenhancedSearchGuide構文によって記載されたものよりも、RFC 4515で説明した検索フィルタの構文に精通していること。
Example:
例：
defaultSearchBase: dc=mycompany,dc=com
defaultSearchBase：DC = mycompanyの、dc = comの
serviceSearchDescriptor: email:ou=people,ou=org1,? one;ou=contractor,?one; ref:cn=profile,dc=mycompany,dc=com
serviceSearchDescriptorに：Eメール：OU =人、OU = ORG1 ,? 1; OU =請負業者、1？; REF：CN =プロファイル、DC = mycompanyの、dc = comの
In this example, the DUA MUST search in "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then SHOULD search in "ou=contractor,dc=mycompany,dc=com", and finally it SHOULD search other locations as specified in the profile described at "cn=profile,dc=mycompany,dc=com". For more examples, see Appendix A.
この例では、DUAは、 "OU =人、OU = ORG1、DC = mycompanyの、dc = comの" 最初に検索する必要があります。 DUAは、 "OU =請負業者、DC = mycompanyの、dc = comの" で検索すると、 "CN =プロファイル、DC = mycompanyの、dc = comの" で説明したプロファイルに指定されている最終的にそれは他の場所を検索する必要があります。その他の例については、付録Aを参照してください。
Interpretation:
解釈：
A DUA SHOULD perform attribute mapping for all LDAP operations performed for a service that has an attributeMap entry. Because attribute mapping is specific to each service within the DUA, a "serviceID" is required as part of the attributeMap syntax. That is, not all DUA services should necessarily perform the same attribute mapping.
DUAはのattributeMapエントリを持っているサービスのために実行されたすべてのLDAP操作のための属性マッピングを実行する必要があります。属性マッピングがDUA内の各サービスに固有であるため、「サービスIDは」のattributeMap構文の一部として要求されます。つまり、すべてのDUAサービスが必ずしも同じ属性のマッピングを実行する必要がありません、です。
Attribute mapping in general is expected to be used to map attributes of similar syntaxes as specified by the service supported by the DUA. However, a DUA is NOT REQUIRED to verify syntaxes of mapped attributes. If the DUA does discover that the syntax of the mapped attribute does not match that of the original attribute, the DUA MAY perform translation between the original syntax and the new syntax. When DUAs do support attribute value translation, the method and list of capable translations SHOULD be documented in a description of the DUA service.
一般的な属性マッピングがDUAでサポートされているサービスを指定することで、同様の構文の属性をマップするために使用されることが期待されます。しかし、DUAは、マッピングされた属性の構文を検証する必要はありません。 DUAがマッピングされた属性の構文は、元の属性と一致しないことを発見した場合は、DUAは、元の構文と新しい構文の間の変換を行うことができます。 DUAsは、属性値の変換をサポートして行うと、できる翻訳の方法とリストがDUAサービスの説明に文書化する必要があります。
Syntax:
構文：
attributeMap = serviceID ":" origAttribute "=" attributes
attributeMap =サービスID "：" origAttribute "=" 属性
origAttribute = attribute
origAttribute =属性
attributes = wattribute *( SP wattribute )
属性= wattributeの*（SPのwattribute）
wattribute = WSP newAttribute WSP
wattribute newAttribute WSP WSP =
newAttribute = descr / "*NULL*"
newAttribute = DESCR / "* NULLの*"
attribute = descr
属性= DESCR
Values of the origAttribute are defined by and SHOULD be documented for the DUA service, as a list of known supported attributes.
origAttributeの値は、で定義されていると知られているサポートされる属性のリストとして、DUAサービスのために文書化する必要があります。
Default Value:
デフォルト値：
By default, attributes that are used by a DUA service are not mapped unless mapped by the attributeMap attributes. The DUA SHOULD NOT map an attribute unless it is explicitly defined by an attributeMap attribute.
attributeMap属性によってマッピングされない限り、デフォルトでは、DUAサービスによって使用される属性がマップされません。それが明示的のattributeMap属性によって定義されていない限り、DUAは、属性をマッピングしてはなりません。
Other attribute notes:
他の属性の注意事項：
When an attribute is mapped to the special keystring "*NULL*", the DUA SHOULD NOT request that attribute from the DSA, when performing a search or compare request. If the DUA is also capable of performing modification on the DSA, the DUA SHOULD NOT attempt to modify any attribute which has been mapped to "*NULL*".
属性は、特別なキー文字列「* NULLの*」にマッピングされている場合は、DUAは、検索を実行するとき、DSAからその属性を要求したり、要求を比較を行うべきではありません。 DUAはまた、DSAの修正を行うことが可能であるならば、DUAは「* NULLの*」にマッピングされている任意の属性を変更しないでください。
It is assumed the serviceID is unique to a given service within the scope of the DSA.
サービスIDは、DSAの範囲内で特定のサービスに固有のものであると想定されます。
A DUA SHOULD support attribute mapping. If it does, the following additional rules apply:
DUAは、属性マッピングをサポートする必要があります。それがない場合は、次の追加規則が適用されます。
1. The list of attributes that are allowed to be mapped SHOULD be defined by and documented for the service.
1.マップすることが許可されている属性のリストは以下のように定義し、サービスのために文書化する必要があります。
2. Any supported translation of mapping from attributes of dissimilar syntax SHOULD also be defined and documented.
2.非類似の構文の属性からのマッピングサポートされる任意の翻訳も定義し、文書化する必要があります。
3. If an attribute may be mapped to multiple attributes, the DSA SHOULD define a syntax or usage statement for how the new attribute value will be constructed. Furthermore, the resulting translated syntax of the combined attributes MUST be the same as the attribute being mapped.
3.属性は複数の属性にマッピングすることができる場合は、DSAは、新しい属性値を構築する方法の構文や使用法ステートメントを定義する必要があります。属性がマッピングされるようにまた、合成属性の結果として生じる翻訳構文は同じでなければなりません。
4. A DUA MUST support mapping of attributes using the attribute OID. It SHOULD support attribute mapping based on the attribute name.
4. A DUAは、属性のOIDを使用して属性のマッピングをサポートしなければなりません。これは、属性名に基づいて属性マッピングをサポートする必要があります。
5. It is recommended that attribute mapping not be applied to parents of the target entries.
5.属性マッピングがターゲットエントリの親に適用されないことをお勧めします。
6. Attribute mapping is not recursive. In other words, if an attribute has been mapped to a target attribute, that new target attribute MUST NOT be mapped to a third attribute.
6.属性マッピングは再帰的ではありません。換言すれば、属性は、新しいターゲット属性が三属性にマップされてはならないことを、ターゲット属性にマッピングされています。
7. A given attribute MUST only be mapped once for a given service.
7.与えられた属性は、特定のサービスのために一度マッピングする必要があります。
Example:
例：
Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn", and "sn" attributes to discover mail addresses. However, the email service has been deployed in an environment that uses "employeeName" instead of "cn". Also, instead of using the "mail" attribute for email addresses, the "email" attribute is used. In this case, the attribute "cn" can be mapped to "employeeName", allowing the DUA to perform searches using the "employeeName" attribute as part of the search filter, instead of "cn". Also, "mail" can be mapped to "email" when attempting to retrieve the email address. This mapping is performed by adding the attributeMap attributes to the configuration profile entry as follows (represented in LDIF [RFC2849]):
DUAは、電子メールサービスに代わって行動していると仮定します。デフォルトでは、「電子メール」サービスは、「メール」、「CN」を使用し、「SNは、」メールアドレスを発見するための属性。しかし、電子メールサービスではなく、「CN」の「employeeName」を使用する環境で展開されています。また、代わりにメールアドレスを「メール」属性を使用しての、「電子メール」属性が使用されています。この場合には、属性「CN」が代わりに「CN」の、DUAは、検索フィルタの一部として「employeeName」属性を使用して検索を実行することができ、「employeeName」にマッピングすることができます。電子メールアドレスを取得しようとしたときにも、「メール」「メール」にマッピングすることができます。このマッピングは、（LDIF [RFC2849]で表される）は、以下のようにのattributeMap構成プロファイルエントリに属性を追加することによって行われます。
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
As described above, the DUA MAY also map a single attribute to multiple attributes. When mapping a single attribute to more than one attribute, the new syntax or usage of the mapped attribute must be intrinsically defined by the DUAs service.
前述したように、DUAは、複数の属性に単一の属性をマッピングすることができます。複数の属性への単一の属性をマッピングする場合、マッピングされた属性の新しい構文や使用方法は、本質のDUAsサービスによって定義されなければなりません。
attributeMap: email:cn=firstName lastName
attributeMap：メール：CN =姓
In the above example, the DUA creates the new value by generating a space-separated string using the values of the mapped attributes. In this case, a special mapping must be defined so that a proper search filter can be created. For further information on this example, please refer to Appendix A.
上記の例では、DUAは、マップされた属性の値を使用して、スペースで区切られた文字列を生成することによって、新しい値を作成します。適切な検索フィルタを作成することができるように、この場合には、特別なマッピングが定義されなければなりません。この例の詳細については、Aを付録Aを参照してください。
Another possibility for multiple attribute mapping might come in when constructing returned attributes. For example, perhaps all email addresses are of a guaranteed syntax of "uid@domain". In this example, the uid and domain are separate attributes in the directory. The email service may define that if the "mail" attribute is mapped to two different attributes, it will construct the email address as a concatenation of the two attributes (uid and domain), placing the "@" character between them.
返される属性を構築する際に、複数の属性マッピングのための別の可能性がでてくるかもしれません。例えば、おそらくすべての電子メールアドレスは「UID @ドメイン」の保証構文です。この例では、uidとドメインは、ディレクトリ内の別の属性です。メールサービスは、「メール」属性が2つの異なる属性にマップされている場合、それはそれらの間の「@」の文字を配置し、二つの属性（uidとドメイン）の連結として電子メールアドレスを作成することを定義することもできます。
attributeMap: email:mail=uid domain
attributeMap：電子メール：メール= uidのドメイン
Note: The attributeMap attribute contains only a list of attribute names that should be mapped, not the definition of how syntax translation should be performed. The process used to perform attribute value syntax translation (such as translating a uid to a DN) and/or joining of multiple attribute values to form the target syntax (such as in the above email example) is up to the service. The attribute list defined in the attributeMap merely provides the attributes that would be used as inputs to the translation function provided by the service.
注意：のattributeMap属性がマッピングされるべき属性名のリストだけではなく、構文の変換を実行すべきかの定義が含まれています。及び/又は（例えば、上記電子メールの例のように）標的構文を形成するために、複数の属性値の結合（例えば、DNにUIDを変換など）属性値構文変換を実行するために使用されるプロセスは、サービスまでです。 attributeMapで定義された属性リストは単にサービスが提供する翻訳機能への入力として使用される属性を提供します。
Interpretation:
解釈：
The searchTimeLimit attribute defines the maximum time, in seconds, that the DUA SHOULD allow for a search request to complete.
searchTimeLimit属性はDUAが完了するために、検索要求を可能にすべきであること、最大時間を秒単位で定義します。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517].
OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
If the searchTimeLimit attribute is not defined or is zero, the searchTimeLimit SHOULD NOT be enforced by the DUA.
searchTimeLimit属性が定義されたか、ゼロであるされていない場合は、searchTimeLimitはDUAによって強制されるべきではありません。
Other attribute notes:
他の属性の注意事項：
This time limit only includes the amount of time required to perform the LDAP search operation. If other operations are required, they do not need to be considered part of the search time. See bindTimeLimit for the LDAP bind operation.
この時間制限はLDAP検索操作を実行するのに必要な時間の量を含んでいます。他の操作が必要な場合は、検索時間の一部と見なされる必要はありません。 LDAPバインド操作のためのbindTimeLimitを参照してください。
Interpretation:
解釈：
The bindTimeLimit attribute defines the maximum time, in seconds, that a DUA SHOULD allow for the bind request to complete when performed against each server on the preferredServerList or defaultServerList.
bindTimeLimit属性はDUAがpreferredServerListまたはdefaultServerListに上の各サーバーに対して行われたときに完了するためにバインド要求を可能にすべきであること、最大時間を秒単位で定義します。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID 1.3.6.1.4.1.1466.115.121.1.27によって定義されています。
Default Value:
デフォルト値：
If the bindTimeLimit attribute is not defined or is zero, the bindTimeLimit SHOULD NOT be enforced by the DUA.
bindTimeLimit属性が定義されたか、ゼロであるされていない場合は、bindTimeLimitはDUAによって強制されるべきではありません。
Other attribute notes:
他の属性の注意事項：
This time limit only includes the amount of time required to perform the LDAP bind operation. If other operations are required, those operations do not need to be considered part of the bind time. See searchTimeLimit for the LDAP search operation.
この時間制限はLDAPバインド操作を実行するのに必要な時間の量を含んでいます。他の操作が必要な場合は、これらの操作は、バインド時間の一部と見なされる必要はありません。 LDAP検索操作のためのsearchTimeLimitを参照してください。
Interpretation:
解釈：
If set to TRUE, the DUA SHOULD follow any referrals if discovered.
TRUEに設定すると発見した場合、DUAは、任意の照会に従ってください。
If set to FALSE, the DUA MUST NOT follow referrals.
FALSEに設定すると、DUAは、紹介に従わてはなりません。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517].
OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
If the followReferrals attribute is not set or set to an invalid value, the default value is TRUE.
followReferralsが設定または無効な値に設定されていない属性場合、既定値はTRUEです。
Interpretation:
解釈：
If set to TRUE, the DUA SHOULD enable alias dereferencing.
TRUEに設定すると、DUAは別名間接参照を有効にする必要があります。
If set to FALSE, the DUA MUST NOT enable alias dereferencing.
FALSEに設定すると、DUAは別名の間接参照を有効にしないでください。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
OID 1.3.6.1.4.1.1466.115.121.1.7によって定義されています。
Default Value:
デフォルト値：
If the dereferenceAliases attribute is not set or set to an invalid value, the default value is TRUE.
dereferenceAliasesが設定または無効な値に設定されていない属性場合、既定値はTRUEです。
Interpretation:
解釈：
The profileTTL attribute defines how often the DUA SHOULD reload and reconfigure itself using the corresponding configuration profile entry. The value is represented in seconds. Once a DUA reloads the profile entry, it SHOULD reconfigure itself with the new values.
profileTTL属性はDUAをリロードし、対応する構成プロファイルのエントリを使用して自分自身を再構成する頻度を定義します。値は秒単位で表されます。 DUAは、プロファイルエントリを再ロードしたら、それは新しい値で自身を再構成する必要があります。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID 1.3.6.1.4.1.1466.115.121.1.27によって定義されています。
Default Value:
デフォルト値：
If not specified, the DUA MAY use its own reconfiguration policy.
指定しない場合、DUAは独自の再構成ポリシーを使用するかもしれません。
Other attribute notes:
他の属性の注意事項：
If the profileTTL value is zero, the DUA SHOULD NOT automatically reload the configuration profile.
profileTTL値がゼロの場合、DUAは自動的に構成プロファイルをリロードすべきではありません。
Interpretation:
解釈：
A DUA MAY perform object class mapping for all LDAP operations performed for a service that has an objectclassMap entry. Because object class mapping is specific for each service within the DUA, a "serviceID" is required as part of the objectclassMap syntax. That is, not all DUA services should necessarily perform the same object class mapping.
DUAはのobjectclassMapエントリを持っているサービスのために実行されたすべてのLDAP操作のためのオブジェクトクラスのマッピングを行うことができます。オブジェクトクラスのマッピングはDUA内の各サービスに固有であるため、「サービスIDは」のobjectclassMap構文の一部として要求されます。つまり、すべてのDUAサービスが必ずしも同じオブジェクトクラスのマッピングを実行する必要がありません、です。
Object class mapping SHOULD be used in conjunction with attribute mapping to map the schema required by the service to an equivalent schema that is available in the directory.
Objectクラスのマッピングは、ディレクトリにあり同等のスキーマにサービスに必要なスキーマをマップする属性マッピングと組み合わせて使用する必要があります。
Object class mapping may or may not be required by a DUA. Often, the objectclass attribute is used in search filters. Section 4.7 recommends that attribute mapping not be applied to the serviceSearchDescriptor. Thus, if the default object classes are not used in a DUA deployment, typically only the serviceSearchDescriptor needs to be defined to reflect that mapping. However, when the service search descriptor is not provided, and the default search filter for that service contains the objectclass attribute, that search filter SHOULD be redefined by object class mapping, if defined. If a default search filter is not used, it SHOULD be redefined through the serviceSearchDescriptor. If a serviceSearchDescriptor is defined for a particular service, it SHOULD NOT be remapped by either the objectclassMap or attributeMap values.
Objectクラスのマッピングは、またはDUAによって必要とされない場合があります。多くの場合、オブジェクトクラス属性が検索フィルタで使用されています。 4.7節は、属性マッピングがserviceSearchDescriptorにに適用されないことをお勧めします。デフォルトのオブジェクトクラスは、DUAの展開で使用されていない場合はこのように、一般的にだけでserviceSearchDescriptorは、そのマッピングを反映するように定義する必要があります。しかし、サービス検索記述子が用意されていない場合、そのサービスのデフォルトの検索フィルタが定義されている場合、検索フィルタは、オブジェクトクラスマッピングによって再定義されるべきである、オブジェクトクラス属性が含まれています。デフォルトの検索フィルタを使用しない場合、その値は、serviceSearchDescriptorを通じて再定義する必要があります。 serviceSearchDescriptorには、特定のサービスのために定義されている場合、それはのobjectclassMapかのattributeMap値のいずれかによって再マップされるべきではありません。
One condition where the objectclassMap SHOULD be used is when the DUA is providing gateway functionality. In this case, the DUA is acting on behalf of another service, which may pass in a search filter itself. In this type of DUA, the DUA may alter the search filter according to the appropriate attributeMap and objectclassMap values. In this case, it is also assumed that a serviceSearchDescriptor is not defined.
DUAは、ゲートウェイ機能を提供しているときのobjectclassMapを使用すべき一の条件です。この場合、DUAは、検索フィルタ自体に渡すことができ、他のサービスに代わって行動しています。 DUAのこのタイプでは、DUAは適切なのattributeMapとのobjectclassMap値に従って検索フィルタを変更することができます。この場合、またserviceSearchDescriptorには定義されていないことが想定されます。
Syntax:
構文：
objectclassMap = serviceID ":" origObjectclass "=" objectclass
objectclassMap =サービスID "：" origObjectclass "=" オブジェクトクラス
origObjectclass = objectclass
origObjectclass =オブジェクトクラス
objectclass = keystring
オブジェクトクラス=キー文字列
Values of the origObjectclass depend on the type of DUA Service using the object class mapping feature.
origObjectclassの値は、オブジェクトクラスのマッピング機能を使用してDUAサービスの種類によって異なります。
Default Value:
デフォルト値：
The DUA MUST NOT remap an object class unless it is explicitly defined by an objectclassMap attribute.
それが明示的のobjectclassMap属性によって定義されていない限り、DUAは、オブジェクトクラスを再マップしてはなりません。
Other attribute notes:
他の属性の注意事項：
A DUA SHOULD support object class mapping. If it does, the DUA MUST support mapping of object classes using the objectclass OID. It SHOULD support object class mapping based on the object class name.
DUAは、オブジェクトクラスのマッピングをサポートする必要があります。それがない場合は、DUAは、オブジェクトクラスOIDを使用してオブジェクトクラスのマッピングをサポートしなければなりません。これは、オブジェクトのクラス名に基づいてオブジェクトクラスのマッピングをサポートする必要があります。
It is assumed the serviceID is unique to a given service within the scope of the DSA.
サービスIDは、DSAの範囲内で特定のサービスに固有のものであると想定されます。
Example:
例：
Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn", and "sn" attributes to discover mail addresses in entries created using inetOrgPerson object class [RFC2789]. However, the email service has been deployed in an environment that uses entries created using "employee" object class. In this case, the attribute "cn" can be mapped to "employeeName", and "inetOrgPerson" can be mapped to "employee", allowing the DUA to perform LDAP operations using the entries that exist in the directory. This mapping is performed by adding attributeMap and objectclassMap attributes to the configuration profile entry as follows (represented in LDIF [RFC2849]):
DUAは、電子メールサービスに代わって行動していると仮定します。デフォルトでは、「電子メール」サービスは、inetOrgPersonオブジェクトクラス[RFC2789]を使用して作成したエントリにメールアドレスを発見するために、「メール」、「CN」、および「SN」の属性を使用しています。しかし、電子メールサービスは、「従業員」オブジェクトクラスを使用して作成されたエントリを使用する環境で展開されています。この場合は、「CN」は「employeeName」、および「inetOrgPersonの」にマッピングできる属性は、DUAはディレクトリ内に存在するエントリを使用してLDAP操作を実行できるように、「従業員」にマッピングすることができます。このマッピングは、（LDIF [RFC2849]で表される）のattributeMapを添加することにより行い、以下の通りのobjectclassMapは、構成プロファイル・エントリに属性れます。
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
Interpretation:
解釈：
When a DUA needs to search the DSA for information, this attribute provides the "scope" for the search. This parameter can be overridden by the serviceSearchDescriptor attribute. See Section 4.6.
DUAは情報のためのDSAを検索する必要がある場合、この属性は、検索のための「スコープ」を提供します。このパラメータは、serviceSearchDescriptor属性で上書きすることができます。 4.6節を参照してください。
Syntax:
構文：
scopeSyntax = "base" / "one" / "sub"
scopeSyntax = "ベース" / "1" / "サブ"
Default Value:
デフォルト値：
The default value for the defaultSearchScope SHOULD be defined by the DUA service. If the default search scope for a service is not defined, then the scope SHOULD be for the DUA to perform a subtree search.
defaultSearchScopeのデフォルト値はDUAサービスによって定義されるべきです。サービスのデフォルトの検索範囲が定義されていない場合DUAがサブツリー検索を実行するために、スコープはする必要があります。
Interpretation:
解釈：
The serviceAuthenticationMethod attribute defines an ordered list of LDAP bind methods to be used when attempting to contact a DSA for a particular service. Interpretation and use of this attribute is the same as Section 4.4, but specific for each service.
serviceAuthenticationMethodを属性は、特定のサービスのためのDSAに連絡しようとするときに使用するLDAPバインドメソッドの順序付きリストを定義します。この属性の解釈と使用は、セクション4.4が、各サービスの特定のと同じです。
Syntax:
構文：
svAuthMethod = serviceID ":" method *(";" method)
svAuthMethod =サービスID "：" メソッド*（ ";" 方法）
Note: Although multiple authentication methods may be specified in the syntax, at most one of each type is allowed.
注：複数の認証方法は、構文で指定することができるが、各タイプの多くても1つが許可されています。
Default Value:
デフォルト値：
If the serviceAuthenticationMethod attribute is not provided, the authenticationMethod SHOULD be followed, or its default.
serviceAuthenticationMethodを属性が用意されていない場合は、AuthenticationMethodがが続く、またはそのデフォルトされるべきである（SHOULD）。
Other attribute notes:
他の属性の注意事項：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAものDSAにバインドする方法を決定することは、追加の構成属性、credentialLevelを、serviceCredentialLevel、およびbindTimeLimitに依存します。適切DSAにバインドする方法の詳細については、第5章をご覧ください。
Example:
例：
serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
serviceAuthenticationMethodを：電子メール：TLS：シンプル、SASL / DIGEST-MD5
Interpretation:
解釈：
The serviceCredentialLevel attribute defines what type(s) of credential(s) the DUA SHOULD use when contacting the DSA for a particular service. Interpretation and use of this attribute are the same as Section 4.5.
serviceCredentialLevel属性は、特定のサービスのためのDSAを接触させるときにDUAが使用する資格（複数可）の種類（複数可）を定義します。この属性の解釈と使用は4.5節と同じです。
Syntax:
構文：
svCredentialLevel = serviceID ":" level *(SP level)
svCredentialLevel =サービスID "：" レベル*（SPレベル）
Refer to implementation notes in Section 5 for additional syntax requirements for the credentialLevel attribute.
credentialLevelを属性の追加の構文の要件については、セクション5で実装ノートを参照してください。
Note: Although multiple credential levels may be specified in the syntax, at most one of each type is allowed.
注：複数の資格レベルは、構文で指定することができるが、各タイプの多くても1つが許可されています。
Default Value:
デフォルト値：
If the serviceCredentialLevel attribute is not defined, the DUA MUST examine the credentialLevel attribute, or if one is not provided, the DUA must follow its default.
serviceCredentialLevel属性が定義されていない場合、DUAはcredentialLevelを属性を検討しなければならない、または1つが提供されていない場合は、DUAはデフォルトに従わなければなりません。
Other attribute notes:
他の属性の注意事項：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, serviceAuthenticationMethod, authenticationMethod, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAものDSAにバインドする方法を決定することは、追加の構成属性、serviceAuthenticationMethodを、AuthenticationMethodが、そしてbindTimeLimitに依存します。適切DSAにバインドする方法の詳細については、第5章をご覧ください。
Example:
例：
serviceCredentialLevel: email:proxy anonymous
serviceCredentialLevel：メール：匿名プロキシ
The DUA SHOULD use the following algorithm when binding to the server:
サーバーにバインドするときにDUAは、次のアルゴリズムを使用する必要があります。
for (clevel in credLevel) [see Note 1] if (clevel is "anonymous") for (host in hostnames) [see Note 2] if (server is responding) return success return failure else for (amethod in authMethod) [see Note 3] if (amethod is none) for (host in hostnames) if (server is responding) return success return failure else for (host in hostnames) authenticate using amethod and clevel if (authentication passed) return success return failure
（credLevelでclevel）のために（ホスト名でホスト）のための（clevelは「匿名」である）場合は、[注1を参照]注[2]（AuthMethodの中amethod）のために、他の成功リターン失敗を返す（サーバーが応答している）[注を参照してください場合3]（ホスト名でホスト）のための他のリターンの成功リターン障害があればamethodとclevelを使用して認証（サーバーが応答している）場合（ホスト名でホスト）のために（amethodはなし）（認証が渡される）復帰成功リターン故障の場合
Note 1: The credLevel is a list of credential levels as defined in serviceCredentialLevel (Section 4.16) for a given service. If the serviceCredentialLevel is not defined, the DUA MUST examine the credentialLevel attribute.
注1：特定のサービスのためにserviceCredentialLevel（セクション4.16）で定義されるようcredLevelは、資格レベルのリストです。 serviceCredentialLevelが定義されていない場合、DUAはcredentialLevelを属性を調べる必要があります。
Note 2: hostnames is the list of servers to contact as defined in Sections 4.1 and 4.2.
注2：ホスト名セクション4.1と4.2で定義されているように連絡するサーバのリストです。
Note 3: The authMethod is a list of authentication methods as defined in serviceAuthenticationMethod (Section 4.15) for a given service. If the serviceAuthenticationMethod is not defined, the DUA MUST examine the authenticationMethod attribute.
注3：指定されたサービスのserviceAuthenticationMethodを（セクション4.15）で定義されるようにをAuthMethodが認証方式のリストです。 serviceAuthenticationMethodをが定義されていない場合、DUAはAuthenticationMethodが属性を調べる必要があります。
The profile entries MUST be protected against unauthorized modification. Each service needs to consider implications of providing its service configuration as part of this profile and limit access to the profile entries accordingly.
プロファイルエントリは不正な変更から保護されなければなりません。各サービスは、このプロファイルの一部として、そのサービス構成を提供するの影響を考慮し、それに応じてプロファイルエントリへのアクセスを制限する必要があります。
The management of the authentication credentials for the DUA is outside the scope of this document and needs to be handled by the DUA.
DUAのための認証資格情報の管理は、この文書の範囲外であるとDUAによって処理する必要があります。
Since the DUA needs to know how to properly bind to the directory server, the access control configuration of the DSA MUST assure that the DSA can view all the elements of the DUAConfigProfile attributes. For example, if the credentialLevel attribute contains "Self", but the DSA is unable to access the credentialLevel attribute, the DUA will instead attempt an anonymous connection to the directory server.
DUAが正しく、ディレクトリサーバーにバインドする方法を知っておく必要があるので、DSAのアクセス制御の設定は、DSAがDUAConfigProfile属性のすべての要素を見ることができることを保証しなければなりません。 credentialLevelを属性が「自己」が含まれていますが、DSAはcredentialLevelを属性にアクセスすることができない場合、例えば、DUAではなく、ディレクトリサーバーへの匿名の接続を試みます。
The algorithm described by Section 5 also has security considerations. Altering that design will alter the security aspects of the configuration profile.
第5節で説明したアルゴリズムは、セキュリティ上の考慮事項があります。その設計を変更すると、構成プロファイルのセキュリティ面を変更します。
At times, DUAs connect to multiple directory servers in order to support potential high-availability and/or performance requirements. As such, each directory server specified in the preferredServer list and defaultServerList MUST contain the same (replicated) data and be part of the same security domain. This means the directory-supported authentication methods, authentication policies, and access control policies for directory data are exactly the same across all the defined directory servers.
時にはするDuasは、潜在的な高可用性および/または性能要件をサポートするために複数のディレクトリ・サーバーに接続します。このように、preferredServerリストとdefaultServerListにで指定された各ディレクトリ・サーバーが同じ（複製）データを含み、同じセキュリティドメインの一部でなければなりません。これは、ディレクトリデータ用のディレクトリがサポートする認証方法、認証ポリシー、およびアクセス制御ポリシーが正確に定義されたすべてのディレクトリサーバー間で同じであることを意味します。
There were several additional authors of this document. However, we chose to represent only one author per company in the heading. From Sun, we would like to acknowledge Roberto Tam for his design work on Sun's first LDAP name service product and his input for this document. From Hewlett-Packard, we'd like to acknowledge Dave Binder for his work architecting Hewlett-Packard's LDAP name service product as well as his design guidance on this document. We'd also like to acknowledge Grace Lu from HP, for her input and implementation of HP's configuration profile manager code.
このドキュメントのいくつかの追加の作者がありました。しかし、我々は見出しに会社ごとに1つだけの著者を表現することを選びました。日から、我々はSunの最初のLDAPネームサービス製品および本文書のための彼の入力に彼のデザインの仕事のためにロベルト・タムを確認したいと思います。ヒューレット・パッカードから、我々は、Hewlett-PackardのLDAPネームサービスの製品だけでなく、この文書に彼の設計指針を設計彼の仕事のためにデーブバインダーを確認したいと思います。また、HPの構成プロファイルマネージャのコードの彼女の入力および実装のために、HPからグレース呂を確認したいと思います。
This document defines new LDAP attributes and an object class for object identifier descriptors. As specified by Section 3.4 and required by Section 4 of [RFC4520], this document registers new descriptors as follows per the Expert Review.
この文書は、新しいLDAP属性とオブジェクト識別子記述子のためのオブジェクトクラスを定義します。 3.4節で指定し、[RFC4520]のセクション4で必要とされる専門家レビューごとに次のように、この文書は、新しい記述子を登録します。
Subject: Request for LDAP Descriptor Registration
件名：LDAP記述子の登録要求
Descriptor (short name): DUAConfigProfile
記述子（ショートネーム）：DUAConfigProfile
Object Identifier: 1.3.6.1.4.1.11.1.3.1.2.5
オブジェクト識別子：1.3.6.1.4.1.11.1.3.1.2.5
Person & email address to contact for further information: See "Author/Change Controller"
詳細のために連絡する人とEメールアドレス：「著者/変更コントローラ」を参照してください。
Usage: object class
使用法：オブジェクトクラス
Specification: RFC 4876
仕様：RFC 4876
Author/Change Controller:
著者/変更コントローラ：
Bob Neal-Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino, CA 95014 USA Phone: +1 408-447-3044 EMail: bob_joslin@hp.com
ボブ・ニール・ジョスリン米国Hewlett-Packard Company 19420ホームステッドRDクパチーノ、CA 95014 USA電話：+1 408-447-3044電子メール：bob_joslin@hp.com
Comments:
コメント：
See also the associated request for the defaultServerList, defaultSearchBase, preferredServerList, searchTimeLimit, bindTimeLimit, followReferrals, authenticationMethod, profileTTL, attributeMap, credentialLevel, objectclassMap, defaultSearchScope, serviceCredentialLevel, serviceSearchDescriptor, serviceAuthenticationMethod, and dereferenceAliases attribute types.
またdefaultServerListに、に、defaultSearchBase、preferredServerList、searchTimeLimit、bindTimeLimit、followReferrals、AuthenticationMethodが、profileTTL、のattributeMap、credentialLevelを、のobjectclassMap、defaultSearchScope、serviceCredentialLevel、serviceSearchDescriptorに、serviceAuthenticationMethodをするための関連要求を参照してください、とdereferenceAliasesは属性タイプ。
Subject: Request for LDAP Descriptor Registration
件名：LDAP記述子の登録要求
Descriptor (short name): See comments
記述子（ショートネーム）：コメントを参照してください。
Object Identifier: See comments
オブジェクト識別子：コメントを参照してください。
Person & email address to contact for further information: See "Author/Change Controller"
詳細のために連絡する人とEメールアドレス：「著者/変更コントローラ」を参照してください。
Usage: attribute type
使用法：属性タイプ
Specification: RFC 4876
仕様：RFC 4876
Author/Change Controller:
著者/変更コントローラ：
Bob Neal-Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino, CA 95014 USA Phone: +1 408-447-3044 EMail: bob_joslin@hp.com
ボブ・ニール・ジョスリン米国Hewlett-Packard Company 19420ホームステッドRDクパチーノ、CA 95014 USA電話：+1 408-447-3044電子メール：bob_joslin@hp.com
Comments:
コメント：
The following object identifiers and associated attribute types have been registered.
以下のオブジェクト識別子と関連付けられた属性タイプが登録されています。
OID Attribute Type
-------------------------- ---------------------------
1.3.6.1.4.1.11.1.3.1.1.0 defaultServerList
1.3.6.1.4.1.11.1.3.1.1.1 defaultSearchBase
1.3.6.1.4.1.11.1.3.1.1.2 preferredServerList
1.3.6.1.4.1.11.1.3.1.1.3 searchTimeLimit
1.3.6.1.4.1.11.1.3.1.1.4 bindTimeLimit
1.3.6.1.4.1.11.1.3.1.1.5 followReferrals
1.3.6.1.4.1.11.1.3.1.1.6 authenticationMethod
1.3.6.1.4.1.11.1.3.1.1.7 profileTTL
1.3.6.1.4.1.11.1.3.1.1.9 attributeMap
1.3.6.1.4.1.11.1.3.1.1.10 credentialLevel
1.3.6.1.4.1.11.1.3.1.1.11 objectclassMap
1.3.6.1.4.1.11.1.3.1.1.12 defaultSearchScope
1.3.6.1.4.1.11.1.3.1.1.13 serviceCredentialLevel
1.3.6.1.4.1.11.1.3.1.1.14 serviceSearchDescriptor
1.3.6.1.4.1.11.1.3.1.1.15 serviceAuthenticationMethod
1.3.6.1.4.1.11.1.3.1.1.16 dereferenceAliases
Please also see the associated registration request for the DUAConfigProfile object class.
またDUAConfigProfileオブジェクトクラスの関連する登録要求を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"、RFC 4514、2006年6月。
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]スミス、M.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユニフォームリソースロケータ"、RFC 4516、2006年6月。
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]レッグ、S.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：構文と一致規則"、RFC 4517、2006年6月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユーザー・アプリケーションのためのスキーマ"、RFC 4519、2006年6月。
[SASLMECH] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", July 2006, <http://www.iana.org/assignments/sasl-mechanisms>.
[SASLMECH] IANA、 "簡易認証セキュリティー層（SASL）メカニズム"、2006年7月、<http://www.iana.org/assignments/sasl-mechanisms>。
[MSSFU] Microsoft Corporation, "Windows Services for Unix 3.5", <http://www.microsoft.com/windows/sfu/>.
[MSSFU]マイクロソフトコーポレーション、 "Windows Services for UNIX 3.5に"、<http://www.microsoft.com/windows/sfu/>。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[RFC2307]ハワード、L.、1998年3月、RFC 2307 "ネットワーク情報サービスとしてLDAPを使用するためのアプローチ"。
[RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789, March 2000.
[RFC2789]フリード、N.およびS. Kille、 "メールの監視MIB"、RFC 2789、2000年3月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831]リーチ、P.とC.ニューマン、 "SASLメカニズムとしてダイジェスト認証を使用する"、RFC 2831、2000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]グッド、G.、 "LDAPデータ交換フォーマット（LDIF） - 技術仕様"、RFC 2849、2000年6月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515]スミス、M.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：検索フィルタの文字列表現"、RFC 4515、2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
Appendix A. Examples
付録A.例
In this section, we will describe a fictional DUA that provides one service, called the "email" service. This service would be similar to an email client that uses an LDAP directory to discover email addresses based on a textual representation of the recipient's colloquial name.
このセクションでは、「電子メール」サービスと呼ばれる、1つのサービスを提供して架空のDUAを説明します。このサービスは、受信者の口語名のテキスト表現に基づいて電子メールアドレスを発見するためにLDAPディレクトリを使用するメールクライアントと同様です。
This email service is defined by default to expect that users with email addresses will be of the "inetOrgPerson" object class type [RFC2789]. And by default, the "email" service expects the colloquial name to be stored in the "cn" attribute, while it expects the email address to be stored in the "mail" attribute (as one would expect as defined by the inetOrgPerson object class).
このメールサービスは、電子メールアドレスを持つユーザーは、「inetOrgPersonの」オブジェクトのクラス型[RFC2789]のものであろうことを期待するのは、デフォルトで定義されています。それは予想されるようにinetOrgPersonオブジェクトクラスによって定義されているメールアドレスは（「メール」属性に格納されることを期待しながら、デフォルトでは、「電子メール」サービスは、口語名は「CN」属性に格納されることを想定してい）。
As a special feature, the "email" service will perform a special type of attribute mapping when performing searches. If the "cn" attribute has been mapped to two or more attributes, the "email" service will parse the requested search string and map each whitespace-separated token into the mapped attributes, respectively.
検索を行うときに特別な機能として、「電子メール」サービスは、属性マッピングの特殊なタイプを実行します。 「CN」属性が2つの以上の属性にマップされている場合は、「電子メール」サービスは、それぞれ、要求された検索文字列を解析し、マッピングされた属性にそれぞれ空白で区切られたトークンをマッピングします。
The default search filter for the "email" service is "(objectclass=inetOrgPerson)". The email service also defines that when it performs a name-to-address discovery, it will wrap the search filter inside a complex search filter as follows:
「電子メール」サービスのデフォルトの検索フィルタがある「（オブジェクトクラス= inetOrgPersonの）」。電子メールサービスはまた、名前とアドレスの検出を実行する場合、以下のように、それは複雑な検索フィルタ内の検索フィルタをラップすることを定義しています。
(&(<filter>)(cn~=<name string>))
（＆（<フィルター>）（CN〜= <name文字列>））
Or, if "cn" has been mapped to multiple attributes, that wrapping would appear as follows:
「CN」は複数の属性にマッピングされている場合は、次のようにか、そのラッピングが表示されます：
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
（＆（<フィルター>）（ATTR1〜= <TOKEN1>）（ATTR2〜= <token2>）...）
The below examples show how the "email" service builds its search requests, based on the defined profile. In all cases, the defaultSearchBase is "o=airius.com", and the defaultSearchScope is undefined.
以下の例は、「電子メール」サービスが定義されたプロファイルに基づいて、その検索要求を構築する方法を示しています。全ての場合において、に、defaultSearchBaseは「O = airius.com」であり、defaultSearchScopeは未定義です。
In addition, for all examples, we assume that the "email" service has been requested to discover the email address for "Jane Hernandez".
また、すべての例のために、私たちは、「電子メール」サービスは、「ジェーン・ヘルナンデス」のための電子メールアドレスを発見するために要求されていることを前提としています。
Example 1:
例1：
serviceSearchDescriptor: email:"ou=marketing,"
serviceSearchDescriptorに：Eメール： "OU =マーケティング、"
base: ou=marketing,o=airius.com scope: sub filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
ベース：OU =マーケティング、O = airius.comスコープ：サブフィルター：（＆（オブジェクトクラス= inetOrgPersonの）（CN〜=ジェーン・ヘルナンデス））
Example 2:
例2：
serviceSearchDescriptor: email:"ou=marketing,"?one? (&(objectclass=inetOrgPerson)(c=us)) attributeMap: email:cn=2.5.4.42 sn
serviceSearchDescriptorに：Eメール： "OU =マーケティング、" 1？ （＆（オブジェクトクラス= inetOrgPersonの）（C = US））のattributeMap：メール：CN = 2.5.4.42 SN
Note: 2.5.4.42 is the OID that represents the "givenName" attribute.
注意：2.5.4.42は、「givenName属性」属性を表しOIDです。
In this example, the email service performs <name string> parsing as described above to generate a complex search filter. The above example results in one search.
この例では、電子メールサービスは、複雑な検索フィルタを生成するために、上記のように解析<名列>行います。上記の例は、1件の検索になります。
base: ou=marketing,o=airius.com scope: one filter: (&(&(objectclass=inetOrgPerson)(c=us)) (2.5.4.42~=Jane)(sn~=Hernandez))
ベース：OU =マーケティング、O = airius.com範囲：1つのフィルター：（＆（＆（オブジェクトクラス= inetOrgPersonの）（C = US））（2.5.4.42〜=ジェーン）（SN〜=ヘルナンデス））
Example 3:
例3：
serviceSearchDescriptor: email:ou=marketing,"?base attributeMap: email:cn=name
serviceSearchDescriptorに：Eメール：OU =マーケティング、 "ベースのattributeMap：？Eメール：CN =名前
This example is invalid, because either the quote should have been escaped, or there should have been a leading quote.
この例では、引用符のどちらかがエスケープされているはずですので、無効である、または主要な引用があったはずです。
Example 4:
例4：
serviceSearchDescriptor: email:ou=\\mar\\\\keting,\\"?base attributeMap: email:cn=name
serviceSearchDescriptorに：Eメール：OU = \\傷\\\\ keting、\\ "ベースのattributeMap：？Eメール：CN =名前
base: ou=\\mar\\keting," scope: base filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
ベース：OU = \\傷\\ keting、」スコープ：基本フィルタ（＆（オブジェクトクラス= inetOrgPersonの）（名〜=ジェーン・ヘルナンデス））
Example 5:
例5：
serviceSearchDescriptor: email:ou="marketing",o=supercom
serviceSearchDescriptorに：Eメール：OU = "マーケティング"、O = supercom
This example is invalid, since the quote was not a leading quote, and thus should have been escaped.
この例では、引用が有力引用符ではなかったので、エスケープされている必要があるため、無効です。
Example 6:
例6：
serviceSearchDescriptor: email:??(&(objectclass=person) (ou=Org1 \\\\(temporary\\\\)))
serviceSearchDescriptorに：Eメール：??（＆（オブジェクトクラス=人）（OU = ORG1 \\\\））\\\\（一時的な）
base: o=airius.com scope: sub filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\))) (cn~=Jane Henderson)))
ベース：O = airius.comスコープ：サブフィルター：（＆（（＆（オブジェクトクラス=人）（OU = ORG1 \\（一時\\）））（CN〜=ジェーン・ヘンダーソン）））
Example 7:
例7：
serviceSearchDescriptor: email:"ou=funny?org,"
serviceSearchDescriptorに：Eメール： "？OU =面白いORG、"
base: ou=funny?org,o=airius.com scope: sub filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
ベース：OU =面白いORG、O = airius.com範囲：？サブフィルタ（＆（オブジェクトクラス= inetOrgPersonの）〜=ジェーン・ヘルナンデス（CN））
Authors' Addresses
著者のアドレス
Bob Neal-Joslin (editor) Hewlett-Packard Company 19420 Homestead RD M/S 4029 Cupertino, CA 95014 US
ボブ・ニール・ジョスリン（編集者）、米国Hewlett-Packard Company 19420ホームステッドRD M / S 4029クパチーノ、CA 95014米国
Phone: +1 408 447 3044 EMail: bob_joslin@hp.com URI: http://www.hp.com
電話：+1 408 447 3044 Eメール：bob_joslin@hp.com URI：http://www.hp.com
Luke Howard PADL Software Pty. Ltd. PO Box 59 Central Park, Vic 3145 AU
ルークハワードPADLソフトウェアのPty。株式会社私書箱59セントラルパーク、VIC 3145 AU
EMail: lukeh@padl.com URI: http://www.padl.com
電子メール：lukeh@padl.com URI：http://www.padl.com
Morteza Ansari Infoblox 475 Potrero Avenue Sunnyvale, CA 94085 US
モーテッサ・アンサリのInfoblox 475ポトレロアベニューサニーベール、CA 94085米国
Phone: +1 408 716 4300 EMail: morteza@infoblox.com
電話：+1 408 716 4300 Eメール：morteza@infoblox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。