Network Working Group B. Neal-Joslin, Ed.
Request for Comments: 4876 HP
Category: Informational L. Howard
PADL
M. Ansari
Infoblox
May 2007
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
基于轻量级目录访问协议（LDAP）的代理的配置文件模式
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不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅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.
本文档由两个主要组件组成，一个是使用轻量级目录访问协议（LDAP）的代理模式，另一个是该模式的建议用例，用于类似目录用户代理的分布式配置。提出了一组属性类型和一个对象类。在提议的用例中，目录用户代理（DUA）可以使用此模式来确定它们支持的特定服务的目录数据位置和访问参数。此外，在建议的用例中，属性和对象类映射允许DUA重新配置其预期（默认）模式，以匹配最终用户环境的模式。本文档旨在为将来描述特定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
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]已经使目录服务器几乎无处不在。正在创建的许多客户端应用程序（DUA）为许多不同的服务使用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的实现者。在开发这些代理的过程中，我们觉得有几个问题仍然需要解决，以简化这些DUA的大型网络的部署和配置。
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.
这些挑战之一源于缺乏乌托邦模式。乌托邦模式是每个应用程序开发人员都能同意并支持每个应用程序的模式。不幸的是，今天许多DUA定义了自己的模式，即使它们提供类似的服务（如RFC2307与Microsoft的Unix服务[MSSFU]）。这些模式包含相似的属性，但使用不同的属性名称。这可能导致目录条目中的数据冗余，并导致目录管理员遇到不必要的挑战，更新架构和同步数据。或者，在更常见的情况下，两个或多个应用程序可能会在公共模式元素上达成一致，但会为应用程序之间可能共享的其他数据元素选择不同的模式。虽然存在数据同步和翻译工具，但本文的作者认为，在目录用户代理本身中提供这种功能是有价值的。
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.
除了提出一个供一般使用的模式外，本文档的一个目标是通过让DUA将自己配置为部署目录的模式，而不是在目录上强制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.
最后，本文档旨在描述一种DUA的配置方法，该方法可以在不同平台上的多个DUA之间共享，并提供一个配置概要文件。本概要文件的目的是集中和简化DUA的管理。
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
本文档旨在为将来的文档提供框架，这些文档将描述DUA提供的特定服务的各个实现细节。这个
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或其继任者描述）开发此类文件。
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.
我们预计，由于DUA利用了此配置方案，每个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）组织（3）国防部（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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身份验证方法credentialLevel服务搜索描述符服务credentialLevel服务身份验证方法属性映射对象类映射searchTimeLimit bindTimeLimit FollowReferences解除引用别名配置文件TTL
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 |
+---------------------------+---------------------------------------+
+---------------------------+---------------------------------------+
| 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 )
（1.3.6.1.4.1.11.1.3.1.1.0名称'defaultServerList'DESC'默认服务器的列表'EQUALITY caseIgnoreMatch SubStrings匹配caseIgnoreMatch语法1.3.6.1.4.1.1466.115.121.1.15单值）
( 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名称'defaultSearchBase'描述'Default base for searches'相等区分名称匹配语法1.3.6.1.4.1.1466.115.121.1.12单值）
( 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 )
（1.3.6.1.4.1.11.1.3.1.1.2名称'preferredServerList'DESC'首选服务器的列表'EQUALITY caseIgnoreMatch SubStrings匹配caseIgnoreMatch语法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名称'searchTimeLimit'描述'代理或服务允许搜索完成的最大时间'EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27单值）
( 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名称'bindTimeLimit'描述'代理或服务允许绑定操作完成'EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27单值的最长时间）
( 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代理或服务的名称“followReferrals”DESC确实或应该遵循referrals的等式布尔匹配语法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“标识服务或对等方使用、需要或提供的身份验证方法的类型”EQUALITY caseIgnoreMatch SUBSTR caseIgnoreMatch SubStrings匹配语法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 )
（1.3.6.1.4.1.11.1.3.1.1.7名称'profileTTL'DESC'配置文件被视为过时前的生存时间'EQUALITY integerMatch ORDERING integerOrderingMatch语法1.3.6.1.4.1.1466.115.121.1.27单值）
( 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代理或服务使用、需要或支持的名称'attributeMap'描述'属性映射'EQUALITY CaseIgnoreA5Match语法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名称'credentialLevel'DESC'标识代理或服务使用、需要或支持的凭据类型'EQUALITY CaseIgnoreA5Match语法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 '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代理或服务使用、需要或支持的名称'objectclassMap'描述'对象类映射'EQUALITY CaseIgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26）
( 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执行搜索时使用的名称'defaultSearchScope'DESC'默认范围'EQUALITY CaseIgnoreA5Match 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 '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名称'serviceCredentialLevel'DESC'指定特定服务使用、需要或支持的凭据类型'EQUALITY CaseIgnoreA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
( 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名称'serviceSearchDescriptor'DESC'指定特定服务或代理所需、使用或支持的搜索描述符'EQUALITY caseExactMatch SUBSTR CaseExactSubStrings匹配语法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.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.4.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
( 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名称“DereferenceAlias”DESC指定服务或代理是否需要、支持或使用别名的去引用。“相等布尔匹配语法1.3.6.1.4.1.1466.115.121.1.7单值”）
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.
下面的对象类由第3.1节中定义的属性构成，但[RFC4519]中定义的“cn”属性除外。“cn”用于表示DUA配置配置文件的名称，建议用于相对可分辨名称（RDN）[RFC4514]命名属性。该对象类由第4节中描述的DUA专门使用。[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名称“DUA配置文件”SUP top STRUCTURAL DESC“DUA基本配置的抽象”必须（cn）可以（defaultServerList$preferredServerList$defaultSearchBase$defaultSearchScope$searchTimeLimit$bindTimeLimit$credentialLevel$authenticationMethod$FollowReferences$DeReferenceAlias$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，则必须检查defaultServerList属性，如第4.2节所述。由标识的服务器
the preferredServerList MUST be contacted before attempting to contact any of the servers specified by the defaultServerList.
在尝试联系defaultServerList指定的任何服务器之前，必须先联系preferredServerList。
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
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属性，或者DUA无法与preferredServerList指定的任何DSA建立连接时，才能检查defaultServerList属性。
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
一旦确定了服务器地址的顺序，DUA就会联系由列表中第一个服务器地址指定的DSA。如果
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.
如果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。仅当未提供preferredServerList属性时，才会联系默认DSA。
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
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可以跳过一个或多个方法。更多信息请参见第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使用指定的sasl机制和选项执行LDAP简单身份验证和安全层（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执行LDAP StartTLS操作，然后执行指定的绑定方法（有关更多信息，请参阅[RFC4511]第4.14节）。
Syntax:
语法：
authMethod = method *(";" method)
authMethod = method *(";" method)
method = none / simple / sasl / tls
method = none / simple / sasl / tls
none = "none"
none = "none"
simple = "simple"
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:" (none / simple / 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.
注意：虽然可以在语法中指定多个身份验证方法，但每种类型最多允许一种。也就是说，“简单；简单”是无效的。
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身份验证方法都意味着仅服务器（DSA端凭据）身份验证，以及用于DUA端身份验证的其他SASL方法。
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:simple;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属性定义DUA在联系DSA时必须使用的凭据类型。serviceCredentialLevel覆盖特定服务的此值（第4.16节）。credentialLevel可以包含多个凭证类型，由空格分隔。
anonymous The DUA SHOULD NOT use a credential when binding to the DSA.
匿名DUA在绑定到DSA时不应使用凭据。
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.
代理DUA在绑定到DSA时应使用已知的代理标识。代理身份是为表示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.
self当DUA代表已知身份行事时，DUA必须尝试作为该身份绑定到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.
如果凭证级别包含多个凭证类型，则DUA必须按照指定的顺序使用凭证类型。但是，DUA可以跳过一个或多个凭证类型。一旦DUA能够成功绑定到DSA，DUA就不应尝试使用剩余的凭据类型进行绑定。
Syntax:
语法：
credentialLevel = level *(SP level)
证书级别=级别*（SP级别）
level = self / proxy / anonymous
level = self / proxy / anonymous
self = "self"
self = "self"
proxy = "proxy"
proxy = "proxy"
anonymous = "anonymous"
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.
注意：虽然可以在语法中指定多个凭据级别，但每种类型最多允许一个。有关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属性，则DUA在绑定到DSA（也称为匿名）时不应使用凭据。
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
serviceSearchDescriptor属性定义DUA应如何以及在何处搜索特定服务的信息。serviceSearchDescriptor包含一个serviceID，后跟一个或多个基本作用域筛选器三元组。这些基本作用域筛选器三元组仅用于定义特定服务的搜索。多个基本作用域筛选器允许DUA在目录信息树（DIT）的多个位置搜索数据。尽管此语法与LDAP URL[RFC3986]非常相似，但本文档要求能够提供多个主机作为
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.
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 = serviceID ":" serviceSearchDesc *(";"
serviceSearchDesc)
serviceSearchDesc = confReferral / searchDescriptor
serviceSearchDesc = confReferral / searchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]]
searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]]
confReferral = "ref:" distinguishedName
confReferral=“ref:“DifferentiedName
base = distinguishedName / relativeBaseName
base = distinguishedName / relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
relativeBaseName = 1*(relativeDistinguishedName ",")
filter = UTF-8 encoded string
filter = UTF-8 encoded string
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、base、relativeBaseName或filter包含“；”（ASCII 0x3B）、“？”（ASCII 0x3F）、“”（ASCII 0x22）或“\”（ASCII 0x5C）字符，则必须对这些字符进行转义（前面是“\”字符）。或者，DN可以用引号（ASCII 0x22）包围。请参阅RFC 4514。如果confReferral、base、relativeBaseName或filter被引号括起，则只需转义“”字符。任何不需要转义但前面有“\”字符的字符都会产生“\”字符和字符本身。
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.
仅供参考：服务搜索描述符并不完全遵循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.
base-与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，则该服务在执行搜索时必须至少使用一个基本作用域筛选器。如果为每个服务定义了多个基本作用域筛选器三元组，则应该对该服务执行多个搜索。
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.
serviceID对于任何可能使用给定概要文件的DUA范围内的给定服务是唯一的，并且应该由该服务定义。本文档不涉及ServiceID的注册。但是，根据第1节末尾的指导，当DUA开发人员定义他们对DUAConfigProfile模式的使用时，他们将定义该DUA使用的ServiceID。
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的开发主要是为了支持将搜索操作与服务关联起来。可以使用同一配置文件配置多个服务，因此需要将serviceID与搜索描述符信息一起指定。不使用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.
需要使用“ref:”语法指定备用配置文件。
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.
作者认为，用户社区更熟悉RFC4515描述的搜索过滤器语法，而不是enhancedSearchGuide语法描述的搜索过滤器语法。
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: email:ou=people,ou=org1,?
one;ou=contractor,?one;
ref:cn=profile,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=people，ou=org1，dc=mycompany，dc=com”中搜索。然后，DUA应在“ou=承包商，dc=mycompany，dc=com”中搜索，最后应搜索“cn=profile，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中的每个服务，因此需要一个“serviceID”作为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可能会在原始语法和新语法之间执行转换。当DUA支持属性值转换时，应在DUA服务的描述中记录方法和可转换的列表。
Syntax:
语法：
attributeMap = serviceID ":" origAttribute "=" attributes
attributeMap = serviceID ":" origAttribute "=" attributes
origAttribute = attribute
origAttribute = attribute
attributes = wattribute *( SP wattribute )
属性=瓦数*（SP瓦数）
wattribute = WSP newAttribute WSP
wattribute = WSP newAttribute WSP
newAttribute = descr / "*NULL*"
newAttribute = descr / "*NULL*"
attribute = descr
attribute = 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服务使用的属性。DUA不应映射属性，除非它由attributeMap属性显式定义。
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.
假定serviceID对于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. 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
假设DUA代表电子邮件服务。默认情况下，“电子邮件”服务使用“邮件”、“cn”和“sn”属性来发现邮件地址。但是，电子邮件服务已部署在使用“employeeName”而不是“cn”的环境中。此外，还使用了“电子邮件”属性，而不是电子邮件地址的“邮件”属性。在这种情况下
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]):
属性“cn”可以映射到“employeeName”，允许DUA使用“employeeName”属性（而不是“cn”）作为搜索筛选器的一部分来执行搜索。此外，在尝试检索电子邮件地址时，“邮件”可以映射到“电子邮件”。此映射通过将attributeMap属性添加到配置概要文件条目中来执行，如下所示（在LDIF[RFC2849]中表示）：
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
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: email:cn=firstName lastName
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。
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@domain". 在本例中，uid和domain是目录中独立的属性。电子邮件服务可以定义，如果“邮件”属性映射到两个不同的属性，它将把电子邮件地址构造为两个属性（uid和domain）的串联，并在它们之间放置“@”字符。
attributeMap: email:mail=uid domain
attributeMap: email:mail=uid domain
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属性仅包含应映射的属性名称列表，而不包含应如何执行语法转换的定义。用于执行属性值语法转换（例如将uid转换为DN）和/或连接多个属性值以形成目标语法（例如在上面的电子邮件示例中）的过程由服务决定。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属性未定义或为零，则DUA不应强制执行searchTimeLimit。
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属性未定义或为零，则DUA不应强制bindTimeLimit。
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.
如果未将DeReferenceAlias属性设置或设置为无效值，则默认值为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中的每个服务，因此需要一个“serviceID”作为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 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.
DUA可能需要也可能不需要对象类映射。通常，在搜索筛选器中使用objectclass属性。第4.7节建议不要将属性映射应用于serviceSearchDescriptor。因此，如果DUA部署中未使用默认对象类，通常只需要定义serviceSearchDescriptor来反映该映射。但是，如果未提供服务搜索描述符，并且该服务的默认搜索筛选器包含objectclass属性，则应通过对象类映射（如果已定义）重新定义该搜索筛选器。如果未使用默认搜索筛选器，则应通过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.
应该使用objectclassMap的一个条件是DUA提供网关功能。在这种情况下，DUA代表另一个服务，该服务可能会传入搜索筛选器本身。在这种类型的DUA中，DUA可以根据适当的attributeMap和objectclassMap值更改搜索过滤器。在这种情况下，还假定未定义serviceSearchDescriptor。
Syntax:
语法：
objectclassMap = serviceID ":" origObjectclass "=" objectclass
objectclassMap = serviceID ":" origObjectclass "=" objectclass
origObjectclass = objectclass
origObjectclass = objectclass
objectclass = keystring
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必须支持使用objectclass OID映射对象类。它应该支持基于对象类名的对象类映射。
It is assumed the serviceID is unique to a given service within the scope of the DSA.
假定serviceID对于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代表电子邮件服务。默认情况下，“email”服务使用“mail”、“cn”和“sn”属性来发现使用inetOrgPerson对象类[RFC2789]创建的条目中的邮件地址。但是，电子邮件服务已部署在使用使用“employee”对象类创建的条目的环境中。在这种情况下，属性“cn”可以映射到“employeeName”，而“inetOrgPerson”可以映射到“employee”，从而允许DUA使用目录中存在的条目执行LDAP操作。通过将attributeMap和objectclassMap属性添加到配置概要文件条目中来执行此映射，如下所示（在LDIF[RFC2849]中表示）：
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
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 = "base" / "one" / "sub"
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 = serviceID ":" method *(";" method)
Note: Although multiple authentication methods may be specified in the syntax, at most one of each type is allowed.
注意：虽然可以在语法中指定多个身份验证方法，但每种类型最多允许一种。
Default Value:
默认值：
If the serviceAuthenticationMethod attribute is not provided, the authenticationMethod SHOULD be followed, or its default.
如果未提供serviceAuthenticationMethod属性，则应遵循authenticationMethod或其默认值。
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: email:tls:simple;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属性定义DUA在联系特定服务的DSA时应使用的凭据类型。该属性的解释和使用与第4.5节相同。
Syntax:
语法：
svCredentialLevel = serviceID ":" level *(SP level)
svCredentialLevel = serviceID ":" level *(SP level)
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.
注意：虽然可以在语法中指定多个凭据级别，但每种类型最多允许一个。
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属性；如果未提供此属性，则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
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
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:credLevel是一个给定服务的serviceCredentialLevel（第4.16节）中定义的凭证级别列表。如果未定义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:authMethod是serviceAuthenticationMethod（第4.15节）中为给定服务定义的身份验证方法列表。如果未定义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属性包含“Self”，但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.
有时，DUA连接到多个目录服务器以支持潜在的高可用性和/或性能要求。因此，在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.
本文件还有几位作者。然而，我们选择在标题中每个公司只代表一位作者。我们要感谢Roberto Tam在Sun的第一个LDAP名称服务产品上的设计工作以及他对本文档的投入。我们要感谢惠普公司的Dave Binder，感谢他为构建惠普公司的LDAP名称服务产品所做的工作，以及他对本文档的设计指导。我们还要感谢HP的Grace Lu，感谢她对HP configuration profile manager代码的输入和实施。
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"
联系人和电子邮件地址以了解更多信息：请参阅“作者/变更控制者”
Usage: object class
用法：对象类
Specification: RFC 4876
规格：RFC4876
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
Bob Neal Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino，CA 95014美国电话：+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、，和取消引用会消除属性类型。
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"
联系人和电子邮件地址以了解更多信息：请参阅“作者/变更控制者”
Usage: attribute type
用法：属性类型
Specification: RFC 4876
规格：RFC4876
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
Bob Neal Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino，CA 95014美国电话：+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
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]Bradner，S.，“RFC中用于表示需求水平的关键词”，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]Berners Lee，T.，Fielding，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]Crocker，D.，Ed.和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）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]Smith，M.和T.Howes，“轻量级目录访问协议（LDAP）：统一资源定位器”，RFC4516，2006年6月。
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519]Sciberras，A.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，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]微软公司，“适用于Unix 3.5的Windows服务”<http://www.microsoft.com/windows/sfu/>.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[RFC2307]Howard，L.，“将LDAP用作网络信息服务的方法”，RFC 2307，1998年3月。
[RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789, March 2000.
[RFC2789]Freed，N.和S.Kille，“邮件监控MIB”，RFC 27892000年3月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，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]Smith，M.和T.Howes，“轻量级目录访问协议（LDAP）：搜索过滤器的字符串表示”，RFC4515，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.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
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.
在本节中，我们将描述一个虚构的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]。默认情况下，“email”服务期望口语名称存储在“cn”属性中，而它期望电子邮件地址存储在“mail”属性中（正如inetOrgPerson对象类所定义的那样）。
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”属性已映射到两个或多个属性，“email”服务将解析请求的搜索字符串，并将每个空格分隔的标记分别映射到映射的属性中。
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:
“电子邮件”服务的默认搜索筛选器为“（objectclass=inetOrgPerson）”。电子邮件服务还定义，当它执行从名称到地址的查找时，它会将搜索筛选器包装在一个复杂的搜索筛选器中，如下所示：
(&(<filter>)(cn~=<name string>))
(&(<filter>)(cn~=<name string>))
Or, if "cn" has been mapped to multiple attributes, that wrapping would appear as follows:
或者，如果“cn”已映射到多个属性，则包装将如下所示：
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
（&（<filter>）（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".
此外，对于所有示例，我们假设已请求“电子邮件”服务来发现“Jane Hernandez”的电子邮件地址。
Example 1:
例1：
serviceSearchDescriptor: email:"ou=marketing,"
serviceSearchDescriptor: email:"ou=marketing,"
base: ou=marketing,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
base: ou=marketing,o=airius.com
scope: sub
filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
Example 2:
例2：
serviceSearchDescriptor: email:"ou=marketing,"?one?
(&(objectclass=inetOrgPerson)(c=us))
attributeMap: email:cn=2.5.4.42 sn
serviceSearchDescriptor: email:"ou=marketing,"?one?
(&(objectclass=inetOrgPerson)(c=us))
attributeMap: email: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.
在本例中，电子邮件服务执行如上所述的<name string>解析以生成复杂的搜索过滤器。上面的示例将导致一次搜索。
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))
(2.5.4.42~=Jane)(sn~=Hernandez))
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))
(2.5.4.42~=Jane)(sn~=Hernandez))
Example 3:
例3：
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap: email:cn=name
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap: email:cn=name
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: email:ou=\\mar\\\\keting,\\"?base
attributeMap: email:cn=name
base: ou=\\mar\\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
base: ou=\\mar\\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
Example 5:
例5：
serviceSearchDescriptor: email:ou="marketing",o=supercom
serviceSearchDescriptor: email:ou="marketing",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: email:??(&(objectclass=person)
(ou=Org1 \\\\(temporary\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
(cn~=Jane Henderson)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
(cn~=Jane Henderson)))
Example 7:
例7：
serviceSearchDescriptor: email:"ou=funny?org,"
serviceSearchDescriptor: email:"ou=funny?org,"
base: ou=funny?org,o=airius.com
scope: sub
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
base: ou=funny?org,o=airius.com
scope: sub
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
Authors' Addresses
作者地址
Bob Neal-Joslin (editor) Hewlett-Packard Company 19420 Homestead RD M/S 4029 Cupertino, CA 95014 US
Bob Neal Joslin（编辑）惠普公司19420 Homestead路M/S 4029 Cupertino，加利福尼亚州，美国95014
Phone: +1 408 447 3044
EMail: bob_joslin@hp.com
URI: http://www.hp.com
Phone: +1 408 447 3044
EMail: bob_joslin@hp.com
URI: http://www.hp.com
Luke Howard PADL Software Pty. Ltd. PO Box 59 Central Park, Vic 3145 AU
卢克·霍华德·帕德尔软件公司。维多利亚州中央公园59号邮政信箱3145 AU
EMail: lukeh@padl.com
URI: http://www.padl.com
EMail: lukeh@padl.com
URI: http://www.padl.com
Morteza Ansari Infoblox 475 Potrero Avenue Sunnyvale, CA 94085 US
美国加利福尼亚州桑尼维尔市波特雷罗大道475号莫特扎·安萨里信息大厦，邮编94085
Phone: +1 408 716 4300
EMail: morteza@infoblox.com
Phone: +1 408 716 4300
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。