RFC4876 日本語訳
4876 A Configuration Profile Schema for Lightweight Directory AccessProtocol (LDAP)-Based Agents. B. Neal-Joslin, Ed., L. Howard, M.Ansari. May 2007. (Format: TXT=73468 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents
Status of This Memo
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.
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 Notice
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
IESG Note
IESG Note
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.
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.
Abstract
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.
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.
Neal-Joslin, et al. Informational [Page 1] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 1] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Table of Contents
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
Neal-Joslin, et al. Informational [Page 2] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 2] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
1. Background and Motivation
1. Background and Motivation
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] 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Neal-Joslin, et al. Informational [Page 3] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 3] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
authors of this document plan to develop such a document for the Network Information Service DUA, described by RFC 2307 or its successor.
authors of this document plan to develop such a document for the Network Information Service DUA, described by RFC 2307 or its successor.
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.
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.
2. General Information
2. General Information
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).
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).
2.1. Requirements Notation
2.1. Requirements Notation
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].
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].
Neal-Joslin, et al. Informational [Page 4] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 4] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
2.2. Attributes Summary
2.2. Attributes Summary
The following attributes are defined in this document:
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
2.3. Object Classes Summary
2.3. Object Classes Summary
The following object class is defined in this document:
The following object class is defined in this document:
DUAConfigProfile
DUAConfigProfile
2.4. Common Syntax/Encoding Definitions
2.4. Common Syntax/Encoding Definitions
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.
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.
The following syntax definitions are used throughout this document.
The following syntax definitions are used throughout this document.
Neal-Joslin, et al. Informational [Page 5] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 5] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
The list of used syntaxes are:
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.
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.
3. Schema Definition
3. Schema Definition
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.
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.
3.1. Attribute Definitions
3.1. Attribute Definitions
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.
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.
Neal-Joslin, et al. Informational [Page 6] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 6] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
( 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 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.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 '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.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 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.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 '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.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 '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.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 '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 )
Neal-Joslin, et al. Informational [Page 7] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 7] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
( 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 '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.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 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.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 '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.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 '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.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 '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.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 '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 )
Neal-Joslin, et al. Informational [Page 8] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 8] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
( 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 '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.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 '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.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 '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.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 '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 )
3.2. Class Definition
3.2. Class Definition
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.
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.
Neal-Joslin, et al. Informational [Page 9] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 9] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
( 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 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 ) )
4. DUA Implementation Details
4. DUA Implementation Details
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.
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.
Note: Many of the subsections below contain examples. Unless otherwise specified, these examples are rendered using the LDAP Data Interchange Format (LDIF) [RFC2849].
Note: Many of the subsections below contain examples. Unless otherwise specified, these examples are rendered using the LDAP Data Interchange Format (LDIF) [RFC2849].
4.1. Interpreting the preferredServerList Attribute
4.1. Interpreting the preferredServerList Attribute
Interpretation:
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.
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.
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
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
Neal-Joslin, et al. Informational [Page 10] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 10] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
the preferredServerList MUST be contacted before attempting to
contact any of the servers specified by the defaultServerList.
the preferredServerList MUST be contacted before attempting to contact any of the servers specified by the defaultServerList.
Syntax:
Syntax:
serverList = hostport *(SP [hostport])
serverList = hostport *(SP [hostport])
Default Value:
Default Value:
The preferredServerList attribute does not have a default value.
Instead a DUA MUST examine the defaultServerList attribute.
The preferredServerList attribute does not have a default value. Instead a DUA MUST examine the defaultServerList attribute.
Other attribute notes:
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.
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.
Example:
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
4.2. Interpreting the defaultServerList Attribute
4.2. Interpreting the defaultServerList Attribute
Interpretation:
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.
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.
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.
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.
Once the order of server addresses is determined, the DUA contacts
the DSA specified by the first server address in the list. If
Once the order of server addresses is determined, the DUA contacts the DSA specified by the first server address in the list. If
Neal-Joslin, et al. Informational [Page 11] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 11] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
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.
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.
Syntax:
Syntax:
serverList = hostport *(SP [hostport])
serverList = hostport *(SP [hostport])
Default Value:
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.
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.
Other attribute notes:
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.
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.
Example:
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
4.3. Interpreting the defaultSearchBase Attribute
4.3. Interpreting the defaultSearchBase Attribute
Interpretation:
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.
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.
Syntax:
Syntax:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517].
Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517].
Neal-Joslin, et al. Informational [Page 12] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Neal-Joslin, et al. Informational [Page 12] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
Default Value:
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.
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.
Other attribute notes:
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
4.4. Interpreting the authenticationMethod Attribute
4.4. authenticationMethod属性を解釈します。
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 MAYは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は、指定されたSASLメカニズムとオプションを使用することでLDAP Simple AuthenticationとSecurity Layer(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を参照してください)、続いて、指定されたひものメソッドを実行します。
Neal-Joslin, et al. Informational [Page 13] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[13ページ]のRFC4876
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は中で定義されるようにSASLメカニズム名と等しいです。[SASLMECH]
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 MAYは、DUAによって定義されたどんなメソッドも使用することでDSAに付くのを選びます。 しかしながら、authenticationMethodかserviceAuthenticationMethodのどちらかを提供するなら、デュアは指定されたメソッドを使用するだけでよいです。
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を使用するとき、両方のクライアントとサーバ(DSAとDUA)認証はストリング「tls: sasl/外部」が実行されるつもりであることです。 いかなる他の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がどのようにDSAsに付くはずであるかを決定するのを追加構成属性、credentialLevel、serviceCredentialLevel、serviceAuthenticationMethod、およびbindTimeLimitに依存します。 どう適切にDSAに付くかに関する詳細のためにセクション5を見直してください。
Neal-Joslin, et al. Informational [Page 14] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[14ページ]のRFC4876
Example:
例:
authenticationMethod: tls:simple;sasl/DIGEST-MD5
authenticationMethod: 簡単な状態で以下をtlsする、; sasl/ダイジェスト-MD5
(see [RFC2831])
([RFC2831]を見ます)
4.5. Interpreting the credentialLevel Attribute
4.5. credentialLevel属性を解釈します。
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に連絡するとき、デュアがどんなタイプの資格証明書を使用しなければならないかを定義します。 serviceCredentialLevelは特定のサービス(セクション4.16)のためにこの値をくつがえします。 credentialLevelは空白によって切り離された1つ以上の資格証明書のタイプを含むことができます。
anonymous The DUA SHOULD NOT use a credential when binding to the
DSA.
匿名、DSAに付くとき、DUA SHOULD NOTは資格証明書を使用します。
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 SHOULDは知られているプロキシのアイデンティティを使用します。 プロキシのアイデンティティは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が知られているアイデンティティを代表して活動させている自己When、デュアはそのアイデンティティとして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が1つ以上の資格証明書のタイプを含んでいるなら、デュアは指定されたオーダーで資格証明タイプを使用しなければなりません。 しかしながら、DUA MAYは1つ以上の資格証明タイプをスキップします。 DUAが首尾よくDSAに付くことができるとすぐに、DUA SHOULD NOTは、残っている資格証明タイプを使用することで付くのを試みます。
Neal-Joslin, et al. Informational [Page 15] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[15ページ]のRFC4876
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.
以下に注意してください。 複数の資格証明レベルが構文で指定されるかもしれませんが、高々それぞれのタイプのひとりは許容されています。 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).
DSA(また、匿名として、知られている)に付くとき、credentialLevel属性が定義されないなら、DUA SHOULD NOTは資格証明書を使用します。
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がどのようにDSAsに付くはずであるかを決定するのを追加構成属性、authenticationMethod、serviceAuthenticationMethod、serviceCredentialLevel、およびbindTimeLimitに依存します。 どう適切にDSAに付くかに関する詳細のためにセクション5を見直してください。
Example:
例:
credentialLevel: proxy anonymous
credentialLevel: プロキシ匿名です。
4.6. Interpreting the serviceSearchDescriptor Attribute
4.6. serviceSearchDescriptor属性を解釈します。
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 SHOULDがどのように、どこで特定のサービスのための情報を検索するかを定義します。 serviceSearchDescriptorはserviceIDを含んでいます、続いて、1つ以上のベース範囲フィルタ三重を含みます。 これらのベース範囲フィルタ三重は、特定のサービスだけの検索を定義するのに使用されます。 複数のベース範囲フィルタで、DUAはディレクトリ情報木(DIT)を複数の所在地をデータを検索できます。 この構文はLDAP URL[RFC3986]と非常に同様ですが、このドキュメントは複数のホストを供給する能力を必要とします。
Neal-Joslin, et al. Informational [Page 16] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[16ページ]のRFC4876
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 SHOULDは代替のプロフィールを再評価して、指定されるとしてのそのプロフィールによる検索を実行します。
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で定義されるベースが続かれている、」、」 (ASCII0x2C) キャラクタ、このベースは相対的なベースとして知られています。 この相対的なベースは1つ以上のRDNの部品について構成されるかもしれません。 この場合、デュアは、defaultSearchBaseと共に相対的なベースを追加することによって、検索ベースを定義しなければなりません。
Syntax:
構文:
serviceSearchList = serviceID ":" serviceSearchDesc *(";"
serviceSearchDesc)
「serviceSearchListはserviceIDと等しい」:、」 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、またはフィルタが含んでいる、」、;、」 (ASCII0x3B), "?" (ASCII0x3F), 「「「(ASCII0x22)、または「\」(ASCII0x5C)キャラクタ、それらのキャラクタから逃げ(「\」キャラクタによって先行されています)でなければならない」。 交互に、引用文(ASCII0x22)によってDNは囲まれるかもしれません。 RFC4514を参照してください。 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]によって定義されて、提案された構文はそれでしょう。
Neal-Joslin, et al. Informational [Page 17] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[17ページ]のRFC4876
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を定義する特定のサービスの検索を実行しているなら、デュアは定義されるようにベース、範囲、およびフィルタを設定しなければなりません。 それぞれのベース範囲フィルタは3倍ただ一つのLDAP索敵行動を表します。 複数のベース範囲フィルタ三重をserviceSearchDescriptorに提供するなら、DUA SHOULDは複数の検索要求を実行します、そして、その場合、それは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 SHOULDはベース、範囲、および以下のフィルタを作成します:
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個のベース範囲フィルタを3倍使用しなければなりません。 それ、複数のベース範囲フィルタ三重がそのサービスのために定義されるなら、SHOULDは複数の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]になるようにフィルタがNOT REQUIREDであることを意味します。 その上、属性とオブジェクトクラスマッピングがどのようにその検索フィルタに影響するかを決定するのをサービスで定義しなければなりません。 すなわち、DUA SHOULDは、フィルタの属性によって既に写像されたと思われるかどうか、または属性マッピング(セクション4.7を見る)がフィルタに適用されると予想されるかどうか指定します。 一般に、習慣、実装、およびユーザビリティは、属性とオブジェクトクラスマッピング(セクション4.7と4.13)SHOULD NOTがserviceSearchDescriptorで定義されたフィルタに適用されるのを示します。
Neal-Joslin, et al. Informational [Page 18] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[18ページ]のRFC4876
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の範囲の中の与えられたサービスにユニークです。 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は、主としてサービスで仲間に索敵行動をサポートするために開発されました。 同じプロフィールを使用することで複数のサービスを構成できるでしょう、その結果、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.
補欠を指定する必要性が使用の輪郭を描く、「審判:」 構文。
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構文で説明されるそれよりRFC4515によって説明される検索フィルタ構文に詳しいという作者の信念。
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: メール: 人々、ou=ou=org1--1; ouは契約者と等しいです--1 審判: 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.
この例では、デュアは最初に、「ouは人々、ou=org1、dc=mycompany、dc=comと等しいところ」で探さなければなりません。 DUAの当時のSHOULDは「ouが契約者と等しいです、dc=mycompany、dc=com」、および最終的にそれを「cnはプロフィールと等しいです、dc=mycompany、dc=com」で説明されたプロフィールの指定されるとしてのSHOULD検索他の位置を捜します。 より多くの例に関しては、Appendix Aを見てください。
Neal-Joslin, et al. Informational [Page 19] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[19ページ]のRFC4876
4.7. Interpreting the attributeMap Attribute
4.7. attributeMap属性を解釈します。
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 SHOULDはすべてのLDAPのためにattributeMapエントリーを持っているサービスのために実行された操作を写像する属性を実行します。 属性マッピングが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は写像している属性の構文について確かめるNOT REQUIREDです。 DUAが、写像している属性の構文が元の属性のものに合っていないと発見するなら、DUA MAYはオリジナルの構文と新しい構文の間の翻訳を実行します。 DUAsが、属性値ができる翻訳SHOULDの翻訳と、メソッドとリストであるとサポートするときには、DUAサービスの記述に記録されてください。
Syntax:
構文:
attributeMap = serviceID ":" origAttribute "=" attributes
「attributeMapはserviceIDと等しい」:、」 origAttributeは属性と「等しいです」。
origAttribute = attribute
origAttribute=属性
attributes = wattribute *( SP wattribute )
属性はwattribute*と等しいです。(SP wattribute)
wattribute = WSP newAttribute WSP
wattributeはWSP newAttribute WSPと等しいです。
newAttribute = descr / "*NULL*"
「newAttribute=descr/」*ヌル*、」
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の値は定義されました、そして、SHOULDがDUAサービスのために記録されて、aとして、知られることのリストは属性をサポートしました。
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 SHOULD NOTは属性を写像します。
Neal-Joslin, et al. Informational [Page 20] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[20ページ]のRFC4876
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*".
「属性は」 *ヌル*をkeystringする特別番組に写像される」とき、デュアが、検索を実行するとき、DSAからその属性を要求するべきではありませんし、また要求を比較するべきではありません。 「また、DUAがDSAに変更を実行できるなら、デュアSHOULDは、」 *ヌル*に写像されたどんな属性も変更するのを試みません。」
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 SHOULDサポート属性マッピング。 そうするなら、以下の付則は適用されます:
1. The list of attributes that are allowed to be mapped SHOULD be
defined by and documented for the service.
1. 定義されて、サービスのために記録された写像しているSHOULDであることが許容されている属性のリスト。
2. Any supported translation of mapping from attributes of
dissimilar syntax SHOULD also be defined and documented.
2. いずれも異なった構文の属性からまた、定義されて、記録されたSHOULDを写像する翻訳をサポートしました。
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 SHOULDは、新しい属性値がどう構成されるかために構文か用法声明を定義します。 その上、結合した属性の結果として起こる翻訳された構文は写像される属性と同じであるに違いありません。
4. A DUA MUST support mapping of attributes using the attribute
OID. It SHOULD support attribute mapping based on the
attribute name.
4. 属性OIDを使用して、デュアは属性に関するマッピングをサポートしなければなりません。 それ、SHOULDは属性名に基づく属性マッピングをサポートします。
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. 属性マッピングは再帰的ではありません。 言い換えれば、属性が目標属性に写像されたなら、その新しい目標属性を3番目の属性に写像してはいけません。
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"属性を使用します。 しかしながら、メールサービスは"cn"の代わりに"employeeName"を使用する環境で配布されました。 また、Eメールアドレスに「メール」属性を使用することの代わりに、「メール」属性も使用されています。 この場合
Neal-Joslin, et al. Informational [Page 21] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[21ページ]のRFC4876
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"の代わりに。 また、Eメールアドレスを検索するのを試みるとき、「メールする」ために「メール」を写像できます。 このマッピングは以下の(LDIF[RFC2849]では、表される)構成プロフィールエントリーにattributeMap属性を加えることによって、実行されます:
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
attributeMap: メール: cn=employeeName attributeMap: メール: メールはメールと等しいです。
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 MAYはただ一つの属性を複数の属性に写像します。 ただ一つの属性を1つ以上の属性に写像するとき、DUAsサービスで本質的に写像している属性の新しい構文か用法を定義しなければなりません。
attributeMap: email:cn=firstName lastName
attributeMap: メール: 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は、写像している属性の値を使用することでスペースで切り離されたストリングを生成することによって、新しい値を作成します。 この場合、適切な検索フィルタを作成できるように特別なマッピングを定義しなければなりません。 この例に関する詳細について、Appendix 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.
返された属性を構成するとき、複数の属性マッピングのための別の可能性は入るかもしれません。 例えば、恐らくすべてのEメールアドレスが" uid@domain "の保証された構文のものです。 この例では、uidとドメインはディレクトリの別々の属性です。 「メール」属性が2つの異なった属性に写像されるなら、メールサービスはそれを定義するかもしれなくて、2つの属性(uidとドメイン)の連結としてEメールアドレスを構成するでしょう、"@"キャラクタをそれらの間に置いて。
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属性は構文翻訳がどう実行されるべきであるかに関する定義ではなく、写像されるべきである属性名のリストだけを含んでいます。 プロセスは以前は、よく属性値構文翻訳(uidをDNに翻訳などなどの)を実行していました、そして、目標構文(上記のメールの例などの)を形成するために複数の属性値を接合するのはサービスまで達しています。 attributeMapで定義された属性リストは単に入力としてサービスで提供された翻訳機能に使用される属性を提供します。
Neal-Joslin, et al. Informational [Page 22] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[22ページ]のRFC4876
4.8. Interpreting the searchTimeLimit Attribute
4.8. searchTimeLimit属性を解釈します。
Interpretation:
解釈:
The searchTimeLimit attribute defines the maximum time, in
seconds, that the DUA SHOULD allow for a search request to
complete.
searchTimeLimit属性は秒のDUA SHOULDが終了する検索要求のために許容する最大の時間を定義します。
Syntax:
構文:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517].
OID1.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 SHOULDです。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が操作を縛るのを見てください。
4.9. Interpreting the bindTimeLimit Attribute
4.9. 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属性は秒に最大の時間を定義して、preferredServerListかdefaultServerListの上の各サーバに対して実行されると、DUA SHOULDは終了するひもの要求を考慮します。
Syntax:
構文:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID1.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 SHOULDです。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を見てください。
Neal-Joslin, et al. Informational [Page 23] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[23ページ]のRFC4876
4.10. Interpreting the followReferrals Attribute
4.10. followReferrals属性を解釈します。
Interpretation:
解釈:
If set to TRUE, the DUA SHOULD follow any referrals if discovered.
TRUEに設定されるなら、発見されるなら、DUA SHOULDはどんな紹介にも続きます。
If set to FALSE, the DUA MUST NOT follow referrals.
FALSEに設定されるなら、デュアは紹介の後をつけてはいけません。
Syntax:
構文:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517].
OID1.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です。
4.11. Interpreting the dereferenceAliases Attribute
4.11. dereferenceAliases属性を解釈します。
Interpretation:
解釈:
If set to TRUE, the DUA SHOULD enable alias dereferencing.
TRUEに設定されるなら、DUA SHOULDは別名の「反-参照をつけ」を可能にします。
If set to FALSE, the DUA MUST NOT enable alias dereferencing.
FALSEに設定されるなら、デュアは別名の「反-参照をつけ」を可能にしてはいけません。
Syntax:
構文:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
OID1.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です。
4.12. Interpreting the profileTTL Attribute
4.12. profileTTL属性を解釈します。
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 SHOULDが対応する構成プロフィールエントリーを使用することでそれ自体をどれくらいの頻度で再び積んで、再構成するかを定義します。 値は秒に表されます。 かつて、DUAはプロフィールエントリーを再び積んで、それはSHOULDです。新しさでそれ自体で値を再構成してください。
Syntax:
構文:
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID1.3によって定義されました。.6 .1 .4 .1 .1466 .115 .121 .1 .27。
Neal-Joslin, et al. Informational [Page 24] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[24ページ]のRFC4876
Default Value:
デフォルト値:
If not specified, the DUA MAY use its own reconfiguration policy.
指定されないなら、DUA MAYはそれ自身の再構成方針を使用します。
Other attribute notes:
他の属性注意:
If the profileTTL value is zero, the DUA SHOULD NOT automatically
reload the configuration profile.
profileTTL値がゼロであるなら、DUA SHOULD NOTは自動的に構成プロフィールを再び積みます。
4.13. Interpreting the objectclassMap Attribute
4.13. objectclassMap属性を解釈します。
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 MAYはすべてのLDAPのためにobjectclassMapエントリーを持っているサービスのために実行された操作を写像するオブジェクトのクラスを実行します。 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.
オブジェクトは、SHOULDを写像しながら、属します。属性マッピングに関連して使用されて、ディレクトリで利用可能な同等な図式に対するサービスで必要である図式を写像してください。
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属性を含んでいます、そして、定義されるなら、検索フィルタSHOULDはオブジェクトクラスマッピングによって再定義されます。 フィルタはデフォルト検索であるなら使用されていなくて、それはSHOULDです。serviceSearchDescriptorを通して再定義されます。 serviceSearchDescriptorはaであるなら特定のサービスのために定義されて、それはSHOULD NOTです。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.
1つがどこを条件とさせるか、objectclassMap SHOULD、使用されているのが、DUAがゲートウェイの機能性を提供している時であるということになってください。 この場合、DUAは別のサービスを代表して行動しています。サービスは検索フィルタ自体で終わるかもしれません。 DUAのこのタイプで、適切なattributeMapとobjectclassMap値に従って、DUAは検索フィルタを変更するかもしれません。 また、この場合、serviceSearchDescriptorが定義されないと思われます。
Neal-Joslin, et al. Informational [Page 25] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[25ページ]のRFC4876
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 Serviceのタイプに頼っています。
Default Value:
デフォルト値:
The DUA MUST NOT remap an object class unless it is explicitly
defined by an objectclassMap attribute.
それがobjectclassMap属性によって明らかに定義されない場合、デュアはオブジェクトのクラスをremapしてはいけません。
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 SHOULDサポートオブジェクトクラスマッピング。 そうするなら、objectclass OIDを使用して、デュアはオブジェクトのクラスに関するマッピングをサポートしなければなりません。 それはオブジェクトクラス名に基づくマッピングを分類しますSHOULDサポートが、反対する。
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がメールサービスを代表して行動していると仮定してください。 デフォルトで、「メール」サービスは、inetOrgPersonオブジェクトのクラス[RFC2789]を使用することで作成されたエントリーで郵便の宛先を発見するのに「メール」、"cn"、および"sn"属性を使用します。 しかしながら、メールサービスは「従業員」オブジェクトのクラスを使用することで作成されたエントリーを使用する環境で配布されました。 この場合、属性"cn"を"employeeName"に写像できます、そして、"inetOrgPerson"を「従業員」に写像できます、DUAがLDAP操作を実行するのをディレクトリに存在するエントリーを使用することで許容して。 このマッピングは以下の(LDIF[RFC2849]では、表される)構成プロフィールエントリーにattributeMapとobjectclassMap属性を加えることによって、実行されます:
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
attributeMap: メール: cn=employeeName objectclassMap: メール: inetOrgPersonは従業員と等しいです。
Neal-Joslin, et al. Informational [Page 26] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[26ページ]のRFC4876
4.14. Interpreting the defaultSearchScope Attribute
4.14. defaultSearchScope属性を解釈します。
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 SHOULDに関しては、DUAサービスで、定義されてください。 サービスのためのデフォルト検索範囲が定義されないなら、範囲SHOULDは下位木検索を実行するDUAのためのそうです。
4.15. Interpreting the serviceAuthenticationMethod Attribute
4.15. serviceAuthenticationMethod属性を解釈します。
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と等しい」:、」 メソッド*(「」、;、メソッド)
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 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がどのようにDSAsに付くはずであるかを決定するのを追加構成属性、credentialLevel、serviceCredentialLevel、およびbindTimeLimitに依存します。 どう適切にDSAに付くかに関する詳細のためにセクション5を見直してください。
Neal-Joslin, et al. Informational [Page 27] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[27ページ]のRFC4876
Example:
例:
serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
serviceAuthenticationMethod: メール: tls:、簡単である、; sasl/ダイジェスト-MD5
4.16. Interpreting the serviceCredentialLevel Attribute
4.16. serviceCredentialLevel属性を解釈します。
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 SHOULDがどんなタイプの資格証明書を使用するかを定義します。 この属性の解釈と使用はセクション4.5と同じです。
Syntax:
構文:
svCredentialLevel = serviceID ":" level *(SP level)
「svCredentialLevelはserviceIDと等しい」:、」 レベル*(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.
以下に注意してください。 複数の資格証明レベルが構文で指定されるかもしれませんが、高々それぞれのタイプのひとりは許容されています。
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属性が定義されないなら、デュアが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がどのようにDSAsに付くはずであるかを決定するのを追加構成属性、serviceAuthenticationMethod、authenticationMethod、およびbindTimeLimitに依存します。 どう適切にDSAに付くかに関する詳細のためにセクション5を見直してください。
Example:
例:
serviceCredentialLevel: email:proxy anonymous
serviceCredentialLevel: メール: プロキシ、匿名
Neal-Joslin, et al. Informational [Page 28] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[28ページ]のRFC4876
5. Binding to the Directory Server
5. ディレクトリサーバに付きます。
The DUA SHOULD use the following algorithm when binding to the server:
サーバに付くとき、DUA SHOULDは以下のアルゴリズムを使用します:
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)[Note1を見る]、(clevelは「匿名である」)、(ホスト名のホスト)[Note2を見る]に関しては(サーバは反応しています)リターン成功であるならほかに失敗のお返しをしてください、(authMethodのamethod)[Note3を見てください](amethodはなにもです)、(ホスト名のホスト)に関して、(ホスト名のホスト)のためのほかの(サーバは反応しています)リターン成功リターン失敗であるなら、(認証は終わりました)リターン成功リターン失敗であるならamethodを使用して、clevelを認証してください。
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が定義されないなら、デュアは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が定義されないなら、デュアはauthenticationMethod属性を調べなければなりません。
6. Security Considerations
6. セキュリティ問題
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.
権限のない変更に対してプロフィールエントリーを保護しなければなりません。 各サービスは、サービス構成を提供する含意がこのプロフィールの一部であるとみなして、それに従って、アクセスをプロフィールエントリーに制限する必要があります。
Neal-Joslin, et al. Informational [Page 29] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[29ページ]のRFC4876
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.
以来、適切にディレクトリサーバ、DSA MUSTのアクセス制御構成に付く方法を知るDUAの必要性は、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で指定されたそれぞれのディレクトリサーバは、同じように(模写される)データを含んでいて、同じセキュリティー領域の一部であるに違いありません。 認証方法、認証方針、およびディレクトリデータのためのアクセス制御方針はまさにそうです。これがディレクトリによってサポートされるのを意味する、すべての定義されたディレクトリサーバの向こう側に同じです。
7. Acknowledgments
7. 承認
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会社あたり1人の作者だけの代理をするのを選びました。 Sunから、Sunの最初のLDAP名前サービス財とこのドキュメントのための彼の入力のときに彼のデザインワークのためにロベルト・タムを承認したいと思います。 ヒューレット・パッカードから、このドキュメントにおける彼のデザイン指導と同様にヒューレット・パッカードのLDAP名前サービス財をarchitectingする彼の仕事のためにデーヴBinderを承認したいと思います。 また、ヒューレット・パッカードからグレースLuを承認したいと思って、彼女に関して、ヒューレット・パッカードの構成の入力と実装はマネージャコードの輪郭を描きます。
8. IANA Considerations
8. IANA問題
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が必要であるように、このドキュメントは以下の1Expert Reviewあたりの新しい記述子を登録します。
Neal-Joslin, et al. Informational [Page 30] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[30ページ]のRFC4876
8.1. Registration of Object Classes
8.1. オブジェクトのクラスの登録
Subject: Request for LDAP Descriptor Registration
Subject: 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
仕様: 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
ボブニール-ジョスリンヒューレット・パッカード社19420は第カルパチーノ(カリフォルニア)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、およびdereferenceAliases属性タイプを求める関連要求を見てください。
8.2. Registration of Attribute Types
8.2. 属性タイプの登録
Subject: Request for LDAP Descriptor Registration
Subject: 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
用法: 属性タイプ
Neal-Joslin, et al. Informational [Page 31] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[31ページ]のRFC4876
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
ボブニール-ジョスリンヒューレット・パッカード社19420は第カルパチーノ(カリフォルニア)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属性タイプ-------------------------- --------------------------- 1.3.6.1.4.1.11.1.3.1.1.0 defaultServerList1.3.6.1.4.1.11.1.3.1.1.1defaultSearchBase1.3.6.1.4.1.11.1.3.1.1.2preferredServerList1.3.6.1.4.1.11.1.3.1.1.3searchTimeLimit1.3.6.1.4.1.11.1.3.1.1.4bindTimeLimit1.3.6.1.4.1.11.1.3.1.1.5followReferrals1.3.6.1.4.1.11.1.3.1.1.6authenticationMethod1.3.6.1.4.1.11.1.3.1.1.7profileTTL1.3.6、.1 .4 .1 .11; 1.3.1.1.9 attributeMap1.3.6.1.4.1.11.1.3.1.1.10credentialLevel1.3.6.1.4.1.11.1.3.1.1.11objectclassMap1.3.6.1.4.1.11.1.3.1.1.12defaultSearchScope1.3.6.1.4.1.11.1.3.1.1.13serviceCredentialLevel1.3.6.1.4.1.11.1.3.1.1.14serviceSearchDescriptor1.3.6.1.4.1.11.1.3.1.1.15serviceAuthenticationMethod1.3.6.1.4.1.11.1.3.1.1.16dereferenceAliases
Please also see the associated registration request for the
DUAConfigProfile object class.
また、DUAConfigProfileオブジェクトのクラスを求める関連登録要求を見てください。
Neal-Joslin, et al. Informational [Page 32] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[32ページ]のRFC4876
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、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"、2005年10月のRFC4234。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510,
June 2006.
[RFC4510] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「仕様書ロードマップ」、RFC4510、2006年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] スミス、M.、およびT.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、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月のsasl<http://www.iana.org/課題/メカニズムの>。
Neal-Joslin, et al. Informational [Page 33] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[33ページ]のRFC4876
9.2. Informative References
9.2. 有益な参照
[MSSFU] Microsoft Corporation, "Windows Services for Unix 3.5",
<http://www.microsoft.com/windows/sfu/>.
[MSSFU]マイクロソフト社、「Windowsは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] 1998年3月のハワード、L.、「ネットワーク情報サービスとしてLDAPを使用するためのアプローチ」RFC2307。
[RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789,
March 2000.
2000年の解放された[RFC2789]とN.とS.Kille、「メールのモニターしているMIB」、RFC2789行進。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[RFC2831] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[RFC2849] いいぞ、G.、「LDAPデータは形式(LDIF)を交換します--技術的な仕様」、RFC2849、6月2000日
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、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)について議定書の中で述べます」。 「検索フィルタのストリング表現」、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)に問題を割り当てました」、BCP64、RFC4520、2006年6月。
Neal-Joslin, et al. Informational [Page 34] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[34ページ]のRFC4876
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について説明するつもりです。 このサービスは受取人の口語的な名前の原文の表現に基づくEメールアドレスを発見するのに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]にはEメールアドレスをもっているユーザがいると予想するためにデフォルトで定義されます。 そして、デフォルトで、「メール」サービスは、口語的な名前が"cn"属性で保存されると予想します、Eメールアドレスが「メール」属性で保存されると予想しますが(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"属性が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:
「メール」サービスのためのデフォルト検索フィルタは「(objectclass=inetOrgPerson)」です。 また、名前からアドレスへの発見を実行するとき、メールサービスはそれを定義して、以下の複雑な検索フィルタの中に検索フィルタを包装するでしょう:
(&(<filter>)(cn~=<name string>))
((<フィルタ>)(cn~=<名前ストリング>))
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".
さらに、すべての例に関して、私たちは、「メール」サービスが「ジェーン・ヘルナンデス」のためにEメールアドレスを発見するよう要求されていると思います。
Example 1:
例1:
serviceSearchDescriptor: email:"ou=marketing,"
serviceSearchDescriptor: メール: 「ouはマーケティングと等しいです」。
base: ou=marketing,o=airius.com scope: sub filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
以下を基礎づけてください。 ouはマーケティング、o=airius.com範囲と等しいです: 潜水艦フィルタ: ((objectclass=inetOrgPerson)(cn~はジェーン・ヘルナンデスと等しいです))
Neal-Joslin, et al. Informational [Page 35] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[35ページ]のRFC4876
Example 2:
例2:
serviceSearchDescriptor: email:"ou=marketing,"?one?
(&(objectclass=inetOrgPerson)(c=us))
attributeMap: email:cn=2.5.4.42 sn
serviceSearchDescriptor: メール: 「ouはマーケティングと等しいです」--1? ((objectclass=inetOrgPerson)(cは私たちと等しいです)) attributeMap: メール: cn=2.5.4.42sn
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個のフィルタ: (((objectclass=inetOrgPerson)(cは私たちと等しい))(2.5に、.4.42~、はジェーンと等しいです)(sn~=ヘルナンデス))
Example 3:
例3:
serviceSearchDescriptor: email:ou=marketing,"?base attributeMap: email:cn=name
serviceSearchDescriptor: 「メール: ouはマーケティングと等しいです」--attributeMapを基礎づけてください: メール: 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: 「メール: \ou=\は\\\\keting、\\を損ないます」--attributeMapを基礎づけてください: メール: cnは名前と等しいです。
base: ou=\\mar\\keting," scope: base filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
以下を基礎づけてください。 「\ou=\は\\ketingを損なう」範囲: ベースフィルタ((objectclass=inetOrgPerson)(名前~はジェーン・ヘルナンデスと等しいです))
Example 5:
例5:
serviceSearchDescriptor: email:ou="marketing",o=supercom
serviceSearchDescriptor: メール: ouは「マーケティング」、o=supercomと等しいです。
This example is invalid, since the quote was not a leading quote, and thus should have been escaped.
引用文、この例は無効であって、主な引用文でなく、その結果、逃げられるべきでした。
Neal-Joslin, et al. Informational [Page 36] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[36ページ]のRFC4876
Example 6:
例6:
serviceSearchDescriptor: email:??(&(objectclass=person)
(ou=Org1 \\\\(temporary\\\\)))
serviceSearchDescriptor: 以下をメールしますか?((objectclassは人と等しいです)(ou=Org1\\\\(一時的な\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
(cn~=Jane Henderson)))
以下を基礎づけてください。 o=airius.com範囲: 潜水艦フィルタ: ((((objectclassは人と等しいです)(ou=Org1\\(一時的な\\)))(ジェーン・cn~=ヘンダーソン)))
Example 7:
例7:
serviceSearchDescriptor: email:"ou=funny?org,"
serviceSearchDescriptor: メール:、「=おかしい状態で、orgにouします」。
base: ou=funny?org,o=airius.com scope: sub filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
以下を基礎づけてください。 ou=おかしい、org、o=airius.com範囲: 潜水艦フィルタ((objectclass=inetOrgPerson)(cn~はジェーン・ヘルナンデスと等しいです))
Neal-Joslin, et al. Informational [Page 37] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[37ページ]のRFC4876
Authors' Addresses
作者のアドレス
Bob Neal-Joslin (editor) Hewlett-Packard Company 19420 Homestead RD M/S 4029 Cupertino, CA 95014 US
ボブニール-ジョスリン(エディタ)ヒューレット・パッカード社19420はS4029カリフォルニア95014M/第カルパチーノ(米国)に入植します。
Phone: +1 408 447 3044 EMail: bob_joslin@hp.com URI: http://www.hp.com
以下に電話をしてください。 +1 3044年の408 447メール: bob_joslin@hp.com ユリ: http://www.hp.com
Luke Howard PADL Software Pty. Ltd. PO Box 59 Central Park, Vic 3145 AU
ルークハワードPADLソフトウェアPty。 株式会社PO Box59セントラルパーク、ヴィク3145AU
EMail: lukeh@padl.com URI: http://www.padl.com
メール: lukeh@padl.com ユリ: http://www.padl.com
Morteza Ansari Infoblox 475 Potrero Avenue Sunnyvale, CA 94085 US
Morteza Ansari Infoblox475Potrero Avenueカリフォルニア94085サニーベル(米国)
Phone: +1 408 716 4300 EMail: morteza@infoblox.com
以下に電話をしてください。 +1 4300年の408 716メール: morteza@infoblox.com
Neal-Joslin, et al. Informational [Page 38] RFC 4876 LDAP-Based Agent Configuration Schema May 2007
ニール-ジョスリン、他 エージェント構成図式2007年5月のLDAPベースの情報[38ページ]のRFC4876
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Neal-Joslin, et al. Informational [Page 39]
ニール-ジョスリン、他 情報[39ページ]
一覧
スポンサーリンク
