-
-Application Working Group M. Ansari
-INTERNET-DRAFT Infoblox
-Expires January 2005 L. Howard
- PADL Software Pty. Ltd.
- B. Neal-Joslin [ed.]
+INTERNET-DRAFT M. Ansari
+draft-joslin-config-schema-10.txt Infoblox
+Category: Informational L. Howard
+Expires: September 2005 PADL Software Pty. Ltd.
+ B. Neal-Joslin, Editor
Hewlett-Packard Company
-
- August 17th, 2004
-Intended Category: Informational
+ 4 March, 2005
A Configuration Schema for LDAP Based
Directory User Agents
- <draft-joslin-config-schema-08.txt>
Status of this Memo
- This memo provides information for the Internet community. This
- memo does not specify an Internet standard of any kind. Distribu-
- tion of this memo is unlimited.
+ Copyright (C) The Internet Society (2005). 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.
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ 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 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.
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
Internet-Drafts are draft documents valid for a maximum of six
- months. Internet-Drafts may be updated, replaced, or made obsolete
- by other documents at any time. It is not appropriate to use
- Internet-Drafts as reference material or to cite them other than as
- a "working draft" or "work in progress".
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts
+ as reference material or to cite them other than as "work in
+ progress."
- To learn the current status of any Internet-Draft, please check the
- 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
- Directories on ds.internic.net (US East Coast), nic.nordu.net
- (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
- Rim).
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
- Distribution of this document is unlimited.
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
-Abstract
+IPR Statement
- This document describes a mechanism for global configuration of
- similar directory user agents. This document defines a schema for
+ By submitting this Internet-Draft, I certify that any applicable
Neal-Joslin [Page 1]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ patent or other IPR claims of which I am aware have been disclosed,
+ or will be disclosed, and any of which I become aware will be
+ disclosed, in accordance with RFC 3668.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Abstract
+
+ This document describes a mechanism for distributed configuration
+ of similar directory user agents. This document defines a schema
+ for configuration of these DUAs that may be discovered using the
+ Lightweight Directory Access Protocol in RFC 2251[1]. A set of
+ attribute types and an objectclass are proposed, along with
+ specific guidelines for interpreting them. A proposal of using
+ attribute and objectclass mapping allows DUAs to re-configure their
+ schema to 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.
+
+
- configuration of these DUAs that may be discovered using the Light-
- weight Directory Access Protocol in RFC 2251[17]. A set of attri-
- bute types and an objectclass are proposed, along with specific
- guidelines for interpreting them. A significant feature of the
- global configuration policy for DUAs is a mechanism that allows
- DUAs to re-configure their schema to that of the end user's
- environment. This configuration is achieved through attribute and
- objectclass mapping. This document is intended to be a skeleton
- for future documents that describe configuration of specific DUA
- services.
+
+
+
+
+
+Neal-Joslin [Page 2]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Table of Contents
+
+ 1. Background & Motivation ...................................... 4
+ 2. General Issues ............................................... 5
+ 2.1 Terminology .................................................. 5
+ 2.2 Attributes ................................................... 5
+ 2.3 Object Classes ............................................... 6
+ 2.4 Syntax Definitions ........................................... 6
+ 3. Attribute Definitions ........................................ 6
+ 4. Class Definition ............................................. 8
+ 5. Implementation Details ....................................... 9
+ 5.1.1 Interpreting the preferredServerList attribute ............. 9
+ 5.1.2 Interpreting the defaultServerList attribute ............... 10
+ 5.1.3 Interpreting the defaultSearchBase attribute ............... 11
+ 5.1.4 Interpreting the authenticationMethod attribute ............ 12
+ 5.1.5 Interpreting the credentialLevel attribute ................. 13
+ 5.1.6 Interpreting the serviceSearchDescriptor attribute ......... 14
+ 5.1.7 Interpreting the attributeMap attribute .................... 17
+ 5.1.8 Interpreting the searchTimeLimit attribute ................. 20
+ 5.1.9 Interpreting the bindTimeLimit attribute ................... 20
+ 5.1.10 Interpreting the followReferrals attribute ................ 21
+ 5.1.11 Interpreting the dereferenceAliases attribute ............. 21
+ 5.1.12 Interpreting the profileTTL attribute ..................... 21
+ 5.1.13 Interpreting the objectclassMap attribute ................. 22
+ 5.1.14 Interpreting the defaultSearchScope attribute ............. 24
+ 5.1.15 Interpreting the serviceAuthenticationMethod attribute .... 24
+ 5.1.16 Interpreting the serviceCredentialLevel attribute ......... 25
+ 5.2 Binding to the Directory Server .............................. 26
+ 6. Security Considerations ...................................... 26
+ 7. Acknowledgments .............................................. 27
+ 8. References ................................................... 27
+ 8.1 Normative References ......................................... 27
+ 8.2 Informative References ....................................... 28
+ 9. Examples ..................................................... 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neal-Joslin [Page 3]
+\f
+Internet-Draft DUA Configuration Schema March 2005
1. Background & Motivation
The LDAP protocol has brought about a new and nearly ubiquitous
acceptance of the directory server. Many new client applications
- (DUAs) are being created that use LDAP directories for many dif-
- ferent services. And although the LDAP protocol has eased the
+ (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
- RFC 2307 [14]. In developing these agents, we felt there are
- several issues that still need to be addressed to ease the deploy-
- ment and configuration of a large network of these DUAs.
+ RFC 2307 [2]. In developing these agents, we felt there are
+ 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 (like RFC 2307 vs.
- Microsoft's Services for Unix [13]) containing similar attributes,
- but with different attribute names. This can lead to data redun-
- dancy within directory entries and give directory administrators
- unwanted challenges, updating schemas and synchronizing data.
+ Microsoft's Services for Unix [3]) containing similar attributes,
+ but with different attribute names. This can lead to data
+ redundancy within directory entries and give directory
+ administrators unwanted challenges, updating schemas and
+ synchronizing data.
So, 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 it's own schema on the directory.
+ directory, instead of forcing its 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
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 is to cen-
- tralize and simplify management of DUAs.
-
-
-
-Neal-Joslin [Page 2]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
+ providing as such, a configuration profile, the purpose is to
+ centralize and simplify management of DUAs.
This document is intended to provide the skeleton framework for
future drafts, which will describe the individual implementation
details for the particular services provided by that DUA. The
authors of this document plan to develop such a document for the
- Network Information Service DUA, described by RFC 2307 or its suc-
- cessor.
+ 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 auxili-
- ary object classes, containing 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. And that by joining various auxiliary objectclasses for
- different DUA services, that configuration of various DUA services
- can be controlled by a single configuration profile entry.
+ specified by this document. Thus, we would expect that new
+
+
+
+Neal-Joslin [Page 4]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ auxiliary object classes, containing 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. And that by joining various auxiliary objectclasses
+ for different DUA services, that configuration of various DUA
+ services can be controlled by a single configuration profile entry.
2. General Issues
- The schema defined by this document is defined under the "DUA Con-
- figuration Schema." This schema is derived from the 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"
+ The schema defined by this document is defined under the "DUA
+ Configuration Schema." This schema is derived from the 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 Terminology
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 RFC 2119 [15].
+ this document are to be interpreted as described in BCP 14 (RFC
+ 2119) [4].
2.2 Attributes
authenticationMethod
credentialLevel
serviceSearchDescriptor
-
-
-
-Neal-Joslin [Page 3]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
serviceCredentialLevel
serviceAuthenticationMethod
attributeMap
dereferenceAliases
profileTTL
+
+
+Neal-Joslin [Page 5]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
2.3 Object Classes
The following object class is defined in this document:
The following syntax definitions are used throughout this document.
This document does not define new syntaxes that must be supported
- by the directory server. The string encoding used by the attri-
- butes defined in this document can be found section 5.
+ by the directory server. The string encoding used by the
+ attributes defined in this document can be found section 5.
- keystring as defined by RFC 2252 [2]
+ keystring as defined by RFC 2252 [5]
descr as defined by RFC 2252 section 4.1
a as defined by RFC 2252 section 4.1
d as defined by RFC 2252 section 4.1
space as defined by RFC 2252 section 4.1
whsp as defined by RFC 2252 section 4.1
- base as defined by RFC 2253 [3]
+ base as defined by RFC 2253 [6]
DistinguishedName as defined by RFC 2253 section 2
RelativeDistinguishedName as defined by RFC 2253 section 2
- scope as defined by RFC 2255 [5]
- IPv4address as defined by RFC 2396 [9]
- hostport as defined by RFC 2396 section 3.2.2
- port as defined by RFC 2396 section 3.2.2
- ipv6reference as defined by RFC 2732 [10]
- host as defined by RFC 2732 section 3
+ scope as defined by RFC 2255 [7]
+ host as defined by RFC 3986
+ section 3.2.2 [8]
+ hostport host [":" port ]
+ port as defined by RFC 3986
+ section 3.2.3 [8]
serviceID = keystring
discovering their configuration.
( DUAConfSchemaOID.1.0 NAME 'defaultServerList'
- DESC 'Default LDAP server host address used by a DUA'
-
-
-
-Neal-Joslin [Page 4]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
+ DESC 'Default LDAP server host addresses used by a DUA'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
+
+
+
+Neal-Joslin [Page 6]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
DESC 'Preferred LDAP server host addresses to be used by a
DUA'
( DUAConfSchemaOID.1.5 NAME 'followReferrals'
DESC 'Tells DUA if it should follow referrals
- returned by a DSA search result'
- EQUALITY booleanMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
- SINGLE-VALUE )
-
- ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
- DESC 'Tells DUA if it should dereference aliases'
+ returned by a DSA result'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
DESC 'A keystring which identifies the type of
- authentication method used to contact the DSA'
+ authentication methods used to contact the DSA'
EQUALITY caseIgnoreMatch
-
-
-
-Neal-Joslin [Page 5]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
- ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
- DESC 'LDAP search descriptor list used by a DUA'
- EQUALITY caseExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
( DUAConfSchemaOID.1.9 NAME 'attributeMap'
DESC 'Attribute mappings used by a DUA'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
+
+
+
+Neal-Joslin [Page 7]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
DESC 'Identifies type of credentials a DUA should
use when binding to the LDAP server'
EQUALITY caseIgnoreIA5Match
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+ ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
+ DESC 'LDAP search descriptor list used by a DUA'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
- DESC 'Authentication method used by a service of the DUA'
+ DESC 'Identifies type of authentication method a DUA
+ should use when binding to the LDAP server for a
+ specific service'
EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
+ DESC 'Tells DUA if it should dereference aliases'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
-Neal-Joslin [Page 6]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+4. Class Definition
+ The objectclass below is constructed from the attributes defined in
+ 3, with the exception of the cn attribute, which is defined in RFC
+ 2256 [9]. cn is used to represent the name of the DUA
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-4. Class Definition
+Neal-Joslin [Page 8]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- The objectclass below is constructed from the attributes defined in
- 3, with the exception of the cn attribute, which is defined in RFC
- 2256 [8]. cn is used to represent the name of the DUA configura-
- tion profile.
+
+ configuration profile.
( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile'
SUP top STRUCTURAL
Interpretation:
As described by the syntax, the preferredServerList parameter
- is a white-space separated list of server addresses and asso-
- ciated port numbers. When the DUA needs to contact a 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 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 remain-
- ing DSAs.
+ is a white-space separated list of server addresses and
+ associated port numbers. When the DUA needs to contact a 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[10] 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
the preferredServerList MUST be contacted before attempting to
contact any of the servers specified by the defaultServerList.
+ Syntax:
+ serverList = hostport *(space [hostport])
-Neal-Joslin [Page 7]
-\f
-Internet-Draft DUA Configuration Schema October 2002
- Syntax:
+Neal-Joslin [Page 9]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- serverList = host *(space [host])
Default Value:
Other attribute notes:
- This attribute is used in conjunction with the defaultServer-
- List attribute. Please see section 5.1.2 for additional
- implementation notes. Determining how the DUA should query
- the DSAs also depends on the additional configuration attri-
- butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ This attribute is used in conjunction with the
+ defaultServerList attribute. Please see section 5.1.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.2 for details on how a Posix DUA should prop-
- erly bind to a DSA.
+ review section 5.2 for details on how a DUA should properly
+ bind to a DSA.
Example:
- preferredServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
- [1080::8:800:200C:417A]:1389
+ preferredServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:389
5.1.2 Interpreting the defaultServerList attribute
The defaultServerList attribute MUST only be examined if the
preferredServerList attribute is not provided, or the DUA is
- unable to establish a connection with one of the DSAs speci-
- fied by the preferredServerList.
+ unable to establish a connection with one of the DSAs
+ specified by the preferredServerList.
If more than one address is provided, the DUA may choose to
either accept the order provided, or choose to create its own
"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 con-
- tacts the DSA specified by the first server address in the
+ Once the order of server addresses is determined, the DUA
+ contacts the DSA specified by the first server address in the
list. If that DSA is unavailable, the remaining DSAs SHOULD
be queried until an available DSA is found or no more DSAs are
+ available. If a server address or port is invalid, the DUA
+ SHOULD proceed to the next server address as described just
+ above.
-Neal-Joslin [Page 8]
+Neal-Joslin [Page 10]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- available. If a server address or port is invalid, the DUA
- SHOULD proceed to the next server address as described just
- above.
-
Syntax:
- serverList = host *(space [host])
+ serverList = hostport *(space [hostport])
Default Value:
- If a defaultServerList attribute is not provided, the DUA
- should xxx attempt to contact the same DSA that provided the
- configuration profile entry itself. The default DSA is con-
- tacted 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:
- This attribute is used in conjunction with the preferredSer-
- verList attribute. Please see section 5.1.1 for additional
- implementation notes. Determining how the DUA should query
- the DSAs also depends on the additional configuration attri-
- butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ This attribute is used in conjunction with the
+ preferredServerList attribute. Please see section 5.1.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.2 for details on how a DUA should properly
contact a DSA.
Example:
- defaultServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
- [1080::8:800:200C:417A]:1389
+ defaultServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:5912
5.1.3 Interpreting the defaultSearchBase attribute
Interpretation:
When a DUA needs to search the DSA for information, this
- attribute provides the "base" for the search. This parameter
+ attribute provides the base for the search. This parameter
can be overridden or appended by the serviceSearchDescriptor
attribute. See section 5.1.6.
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.12
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [5]
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.
-Neal-Joslin [Page 9]
+
+Neal-Joslin [Page 11]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- MAY define its own method for determining the search base, if
- the defaultSearchBase is not provided.
-
Other attribute notes:
- This attribute is used in conjunction with the serviceSear-
- chDescriptor attribute. See section 5.1.6.
+ This attribute is used in conjunction with the
+ serviceSearchDescriptor attribute. See section 5.1.6.
Example:
The authenticationMethod attribute defines an ordered list of
LDAP bind methods to be used when attempting to contact a
- DSA[1]. The serviceAuthenticationMethod overrides this value
- for a particular service (see 5.1.15.) Each method MUST be
- attempted in the order provided by the attribute, until a suc-
- cessful LDAP bind is performed ("none" is assumed to always be
- successful.) However the DUA MAY skip over one or more
+ DSA[11]. The serviceAuthenticationMethod overrides this
+ value for a particular service (see 5.1.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.2 for more information.
none - The DUA does not perform an LDAP bind.
simple - The DUA performs an LDAP simple bind.
- sasl - The DUA performs an LDAP SASL bind using the
+ sasl - The DUA performs an LDAP SASL[12] bind using the
specified SASL mechanism and options.
tls - The DUA performs an LDAP StartTLS operation
followed by the specified bind method (for more
- information refer to section 5.1 of RFC 2830 [12]).
+ information refer to section 5.1 of RFC 2830 [13]).
Syntax:
- authMethod = method *(";" method)
- method = none | simple | sasl | tls
- none = "none"
- simple = "simple"
- sasl = "sasl/" saslmech [ ":" sasloption ]
- sasloption = "auth-conf" | "auth-int"
- tls = "tls:" (none | simple | sasl)
- saslmech = SASL mechanism name as defined in
- RFC 2222[7], section 3
+ authMethod = method *(";" method)
+ method = none | simple | sasl | tls
+ none = "none"
+ simple = "simple"
+ sasl = "sasl/" saslmech [ ":" sasloption ]
+ sasloption = "auth-conf" | "auth-int"
+ tls = "tls:" (none | simple | sasl)
+ saslmech = SASL mechanism name as defined in [18]
- Note: Although multiple authentication methods may be speci-
- fied in the syntax, at most one of each type is allowed.
+ Note: Although multiple authentication methods may be
+ specified in the syntax, at most one of each type is allowed.
+ I.E. "simple;simple" is invalid.
+ Default Value:
+ If the authenticationMethod or serviceAuthenticationMethod
-Neal-Joslin [Page 10]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+Neal-Joslin [Page 12]
+\f
+Internet-Draft DUA Configuration Schema March 2005
- 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 servi-
- ceAuthenticationMethod are provided, the DUA MUST only use the
- methods specified.
+ the DUA. However, if either authenticationMethod or
+ serviceAuthenticationMethod are provided, the DUA MUST only
+ use the methods specified.
Other attribute notes:
When using TLS, the string "tls:sasl/EXTERNAL" implies that
- two way authentication is to be performed. Any other TLS
- authentication method implies one way (DSA side credential)
- authentication.
+ two way (DSA and DUA) authentication is to be performed. Any
+ other TLS authentication method implies one way (DSA side
+ credential) authentication.
Determining how the DUA should bind to the DSAs also depends
on the additional configuration attributes, credentialLevel,
Example:
authenticationMethod: tls:simple;sasl/DIGEST-MD5
- (see [11])
+ (see [14])
5.1.5 Interpreting the credentialLevel attribute
Interpretation:
The credentialLevel attribute defines what type(s) of
- credential(s) the DUA SHOULD use when contacting the DSA. The
+ credential(s) the DUA MUST use when contacting the DSA. The
serviceCredentialLevel overrides this value for a particular
service (5.1.16.) The credentialLevel can contain more than
one credential type, separated by white space.
should determine what the proxy user's credential is. This
functionality is up to each implementation.
- self - When the DUA is acting on behalf of a "real user" the
+ 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 that identity can be authenticated by the
-Neal-Joslin [Page 11]
+Neal-Joslin [Page 13]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- DUA SHOULD attempt to bind to the DSA as that user. The DUA
- SHOULD map the user's identity to a credential used in the
- directory.
+ directory server using the defined authentication methods.
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 creden-
- tial types.
+ the DUA SHOULD NOT attempt to bind using the remaining
+ credential types.
Syntax:
Other attribute notes:
Determining how the DUA should bind to the DSAs also depends
- on the additional configuration attributes, authentication-
- Method, serviceAuthenticationMethod, serviceCredentialLevel
- and bindTimeLimit. Please review section 5.2 for details on
- how to properly bind to a DSA.
+ on the additional configuration attributes,
+ authenticationMethod, serviceAuthenticationMethod,
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
Example:
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-
-Neal-Joslin [Page 12]
+Neal-Joslin [Page 14]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- 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 of the DIT. Although
- this syntax is very similar to the LDAP URL[6], this draft
+ this syntax is very similar to the LDAP URL[8], this draft
requires the ability to supply multiple hosts as part of the
configuration of the DSA. In addition, an ordered list of
- search descritors is required, which can not be specified by
+ search descriptors is required, which can not be specified by
the LDAP URL.
In addition to the triples, serviceSearchDescriptor might also
- contain the DN of an entry that will contain an alternate pro-
- file. The DSA SHOULD re-evaluate the alternate profile and
+ 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.
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. The DUA MUST define the search
- base by appending the relative base with the defaultSear-
- chBase.
+ base by appending the relative base with the
+ defaultSearchBase.
Syntax:
0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those
characters MUST be escaped (preceded with the "\" character.)
Alternately the DN may be surrounded by quotes (ASCII 0x22.)
- Refer to RFC 2253, section 4. If the base or filter are sur-
- rounded by quotes, only the """ character needs to be escaped.
- Any character that is preceded by the "\" character, which
- does not need to be escaped results in both "\" character and
- the character itself.
+ Refer to RFC 2253, section 4. If the base or filter are
+ surrounded by quotes, only the """ character needs to be
+ escaped. Any character that is preceded by the "\" character,
+ which does not need to be escaped results in both "\"
+ character and the character itself.
The usage and syntax of the filter string MUST be defined by
the DUA service. A suggested syntax would be that as defined
by RFC 2254.
+ If a DUA is performing a search for a particular service,
-Neal-Joslin [Page 13]
+
+Neal-Joslin [Page 15]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- If a DUA is performing a search for a particular service,
which 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 serviceSear-
- chDescriptor, the DUA SHOULD perform multiple search requests
- and in that case it MUST be in the order specified by the ser-
- viceSearchDescriptor.
+ 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.
FYI: Service search descriptors do not exactly follow the LDAP
- URL syntax [5]. The reasoning for this difference is to
+ URL syntax [7]. 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 provider.
+ DUA to have a more flexible solution in choosing its DSA.
Default Values:
Other attribute notes:
If a serviceSearchDescriptor exists for a given service, the
- service MUST use at least one base-scope-filter triple in per-
- forming searches. It SHOULD perform multiple searches per
+ 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.
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 [4]. Furthermore,
+ NOT REQUIRED to be a legal LDAP filter [15]. Furthermore,
determining how attribute and objectclass mapping affects that
search filter MUST be defined by the service. I.E. The DUA
- SHOULD specify if the filter has been assumed to already have
- been mapped, or if it is expected that mapping would be
- applied to the filter. In general practice, implementation
- and usability suggests that attribute and objectclass mapping
- (sections 5.1.7 and 5.1.13) SHOULD NOT be applied to the
+ SHOULD specify if the attributes in the filter have assumed to
+ already have been mapped, or if it is expected that attribute
+ mapping (see 5.1.7) would be applied to the filter. In
+ general practice, implementation and usability suggests that
+ attribute and objectclass mapping (sections 5.1.7 and 5.1.13)
+ SHOULD NOT be applied to the filter defined in the
-Neal-Joslin [Page 14]
+Neal-Joslin [Page 16]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- filter defined in the serviceSearchDescriptor.
+ serviceSearchDescriptor.
It is assumed the serviceID is unique to a given service
within the scope of any DUA that might use the given profile.
syntax. I.E. not all DUA services should necessarily perform
the same attribute mapping.
- Attribute mapping in general is expected be used to map attri-
- butes of similar syntaxes as specified by the service sup-
- ported 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 list of capabable transla-
- tions SHOULD be documented in a description of the DUA ser-
- vice.
+ Attribute mapping in general is expected 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 list of
+ capable translations SHOULD be documented in a description of
+ the DUA service.
Syntax:
-Neal-Joslin [Page 15]
+Neal-Joslin [Page 17]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
attributes = wattribute *( space wattribute )
newAttribute = descr | "*NULL*"
attribute = descr
- Values of the origAttribute are defined by and SHOULD be docu-
- mented for the DUA service, as a list of known supported
+ Values of the origAttribute are defined by and SHOULD be
+ documented for the DUA service, as a list of known supported
attributes.
Default Value:
It is assumed the serviceID is unique to a given service
within the scope of the DSA.
- A DUA SHOULD support attribute mapping. If it does, the fol-
- lowing additional rules apply:
+ A DUA SHOULD support attribute mapping. If it does, the
+ following additional rules apply:
1) The list of attributes that are allowed to be mapped SHOULD
defined by and documented for the service.
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 evaluated. Furthermore, the resulting
- translated syntax of the combined attributes MUST be the same
- as the attribute being mapped.
+ attribute value will be constructed. Furthermore, the
+ resulting translated syntax of the combined attributes MUST be
+ the same as the attribute being mapped.
- 4) A DUA MUST support mapping of attributes using the attri-
- bute OID. It SHOULD support attribute mapping based on the
- attribute name.
+ 4) A DUA MUST support mapping of attributes using the
+ attribute OID. It SHOULD support attribute mapping based on
+ the attribute name.
5) It is recommended that attribute mapping not be applied to
-Neal-Joslin [Page 16]
+Neal-Joslin [Page 18]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
parents of the target entries.
6) Attribute mapping is not recursive. In other words, if an
- attribute has been mapped to a target attribute, that new tar-
- get attribute MUST NOT be mapped to a third attribute.
+ attribute has been mapped to a target attribute, that new
+ target attribute MUST NOT be mapped to a third attribute.
- 7) A given attribute MUST only be mapped once for a given ser-
- vice.
+ 7) A given attribute MUST only be mapped once for a given
+ service.
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 "employ-
- eeName" instead of "cn." And also instead of using the "mail"
- attribute for email addresses, the "email" attribute is used
- for that purpose. In this case, the attribute "cn" can be
- mapped to "employeeName," allowing the DUA to perform searches
- using the "employeeName" attribute as part of the search
- filter, instead of "cn". And "mail" can be mapped to "email"
- when attempting to retrieve the email address. This mapping
- is performed by adding the attributeMap attributes to the con-
- figuration profile entry as follows (represented in LDIF[18]):
+ service has been deployed in an environment that uses
+ "employeeName" instead of "cn." And also instead of using the
+ "mail" attribute for email addresses, the "email" attribute is
+ used for that purpose. In this case, the attribute "cn" can
+ be mapped to "employeeName," allowing the DUA to perform
+ searches using the "employeeName" attribute as part of the
+ search filter, instead of "cn". And "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[16]):
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
attributeMap: email:cn=firstName lastName
- In the above example, the DUA creates the new value by gen-
- erating 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 section 9.
+ In the above example, the DUA creates the new value by
+ generating 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 section
+ 9.
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". And 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
-Neal-Joslin [Page 17]
+Neal-Joslin [Page 19]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- attributes, it will construct the email address as a concate-
- nation of the uid and domain attributes, placing the "@" char-
- acter between them.
+ 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 uid and domain attributes, placing the
+ "@" character between them.
attributeMap: email:mail=uid domain
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. [5]
Default Value:
Default Value:
- If the bindTimeLimit attribute is not defined or is zero, the
- bind time limit is not enforced by the DUA.
-Neal-Joslin [Page 18]
+Neal-Joslin [Page 20]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ If the bindTimeLimit attribute is not defined or is zero, the
+ bind time limit is not enforced by the DUA.
Other attribute notes:
Syntax:
- Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. [5]
Default Value:
Interpretation:
- If set to TRUE, the DUA SHOULD enable alias dereferening.
+ If set to TRUE, the DUA SHOULD enable alias dereferencing.
If set to FALSE, the DUA MUST NOT enable alias dereferencing.
5.1.12 Interpreting the profileTTL attribute
- Interpretation:
- The profileTTL attribute defines how often the DUA SHOULD re-
-
-Neal-Joslin [Page 19]
+Neal-Joslin [Page 21]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
- load and reconfigure itself using the corresponding configura-
- tion profile entry. The value is represented in seconds.
- Once a DUA reloads the profile entry, it SHOULD re-configure
- itself with the new values.
+ Interpretation:
+
+ The profileTTL attribute defines how often the DUA SHOULD re-
+ load and reconfigure itself using the corresponding
+ configuration profile entry. The value is represented in
+ seconds. Once a DUA reloads the profile entry, it SHOULD re-
+ configure itself with the new values.
Syntax:
Default Value:
- If not specified the DUA MAY use its own reconfiguration pol-
- icy.
+ If not specified the DUA MAY use its own reconfiguration
+ policy.
Other attribute notes:
- If the profileTTL value is zero, the DUA SHOULD NOT automati-
- cally re-load the configuration profile.
+ If the profileTTL value is zero, the DUA SHOULD NOT
+ automatically re-load the configuration profile.
5.1.13 Interpreting the objectclassMap attribute
objectclassMap syntax. I.E. Not all DUA services should
necessarily perform the same objectclass mapping.
- Objectclass mapping SHOULD be used in conjunction with attri-
- bute mapping to map the required schema by the service to an
- equivalent schema that is available in the directory.
-
- Objectclass mapping may or may not be required by a DUA. In
- general, the objectclass attribute is used primarily in search
- filters. If a service search descriptor is provided, it is
- expected that the search filter contains a "correct" search
- filter (though this is not a requirement,) which does not need
- to be re-mapped. However, when the service search descriptor
- is not provided, and the default search filter for that ser-
- vice contains the objectclass attribute, that search filter
- SHOULD be re-defined by objectclass mapping. If a default
- search filter is not used, it SHOULD be re-defined through the
+ Objectclass mapping SHOULD be used in conjunction with
+ attribute mapping to map the required schema by the service to
+ an equivalent schema that is available in the directory.
+
+ Objectclass mapping may or may not be required by a DUA.
+ Often, the objectclass attribute is used in search filters.
+ If a service search descriptor is provided, it is expected
+ that the search filter contains a "correct" search filter
+ (though this is not a requirement,) which does not need to be
+ re-mapped. 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 re-defined by objectclass mapping. If a default search
+ filter is not used, it SHOULD be re-defined through the
serviceSearchDescriptor. If a serviceSearchDescriptor is
- defined for a particular service, it SHOULD NOT be re-mapped
- by either the objectclassMap or attributeMap values.
-
-Neal-Joslin [Page 20]
+Neal-Joslin [Page 22]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+ defined for a particular service, it SHOULD NOT be re-mapped
+ by either the objectclassMap or attributeMap values.
+
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 attribu-
- teMap and objectclassMap values. And in this case, it is also
- assumed that a serviceSearchDescriptor is not defined.
+ alter the search filter according to the appropriate
+ attributeMap and objectclassMap values. And in this case, it
+ is also assumed that a serviceSearchDescriptor is not defined.
Syntax:
origObjectclass = objectclass
objectclass = keystring
- Values of the origObjectclass depend on the type of DUA Ser-
- vice using the objectclass mapping feature.
+ Values of the origObjectclass depend on the type of DUA
+ Service using the objectclass mapping feature.
Default Value:
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 objectclass [16]. However, the email service
- has been deployed in an environment that uses entries created
+ inetOrgPerson objectclass[17]. However, the email service has
+ been deployed in an environment that uses entries created
using "employee" objectclass. 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[18]):
-
-Neal-Joslin [Page 21]
+Neal-Joslin [Page 23]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+ objectclassMap attributes to the configuration profile entry
+ as follows (represented in LDIF[16]):
+
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
Interpretation:
The serviceAuthenticationMethod attribute defines an ordered
- list of LDAP bind methods to be used when attempting to con-
- tact a DSA for a particular service. Interpretation and use
- of this attribute is the same as 5.1.4, but specific for each
- service.
+ 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 5.1.4, but specific for
+ each service.
Syntax:
svAuthMethod = service ":" method *(";" method)
- Note: Although multiple authentication methods may be speci-
- fied in the syntax, at most one of each type is allowed.
+ 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.
-
- Other attribute notes:
-Neal-Joslin [Page 22]
+Neal-Joslin [Page 24]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ the authenticationMethod SHOULD be followed, or its default.
+ 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 sec-
- tion 5.2 for details on how to properly bind to a DSA.
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
Example:
Other attribute notes:
Determining how the DUA should bind to the DSAs also depends
- on the additional configuration attributes, serviceAuthentica-
- tionMethod, authenticationMethod and bindTimeLimit. Please
- review section 5.2 for details on how to properly bind to a
- DSA.
+ on the additional configuration attributes,
+ serviceAuthenticationMethod, authenticationMethod and
+ bindTimeLimit. Please review section 5.2 for details on how
+ to properly bind to a DSA.
Example:
- serviceCredentialLevel: email:proxy anonymous
-
+Neal-Joslin [Page 25]
+\f
+Internet-Draft DUA Configuration Schema March 2005
-Neal-Joslin [Page 23]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+ serviceCredentialLevel: email:proxy anonymous
5.2 Binding to the Directory Server
6. Security Considerations
- The profile entries MUST be protected against unauthorized modifi-
- cation. Since the profile is most useful if its content is avail-
- able broadly, it is recommended that the profile entries will be
- readable anonymously. However, ultimately each service needs to
- consider implications of providing its service configuration as
+ The profile entries MUST be protected against unauthorized
+ modification. Each service needs to consider implications of
-Neal-Joslin [Page 24]
+Neal-Joslin [Page 26]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ providing its service configuration as part of this profile and
+ limit access to the profile entries accordingly.
- part of this profile and limit access to the profile entries
- accordingly. Additionally, the management of the authentication
- credentials for the DUA is outside the scope of this document and
- needs to be handled by the DUA.
+ The management of the authentication credentials for the DUA is
+ outside the scope of this document and needs to be handled by the
+ DUA.
- The algorithm described by section 5.2 also has security considera-
- tions. Altering that design will alter the security aspectes of
- the configuration profile.
+ 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.
+
+ The algorithm described by section 5.2 also has security
+ considerations. Altering that design will alter the security
+ aspects of the configuration profile.
7. Acknowledgments
8. References
-[1]
- M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
- Methods for LDAP", RFC 2828, May 2000
+8.1 Normative References
-[2]
- M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
+
+[4] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+
+[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,
December 1997.
-[3]
- M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+
+[6] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+
+
+
+Neal-Joslin [Page 27]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
-[4]
- T. Howes, "The String Representation of LDAP Search Filters", RFC
- 2254, December 1997.
-[5]
- T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
+[7] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
-[6]
- T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
+[8] R. Hinden, B. Carpenter, L. Masinter, "Uniform Resource Identifier
+ (URI): Generic Syntax", RFC 3986, January 2005.
-Neal-Joslin [Page 25]
-\f
-Internet-Draft DUA Configuration Schema October 2002
+[9] M. Wahl, "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
- Locators (URL)", RFC 1738, December 1994.
+[11] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
+ Methods for LDAP", RFC 2828, May 2000
-[7]
- J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
- 2222, October 1997
-[8]
- M. Wahl, "A Summary of the X.500(96) User Schema for use with
- LDAPv3", RFC 2256, December 1997.
+[13] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
+ Protocol [v3]: Extension for Transport Layer Security", RFC 2830,
+ May 2000
+
-[9]
- T. Berners-Lee, R. Fielding, R. Fielding, "Uniform Resource Iden-
- tifiers (URI): Generic Syntax", RFC 2396, August 1998.
+[18] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS",
+ http://www.iana.org/assignments/sasl-mechanisms, April 2004
-[10]
- R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6
- Addresses in URL's, RFC 2732, December 1999.
-[11]
- P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechan-
- ism", RFC 2831, May 2000
+8.2 Informative References
-[12]
- J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto-
- col [v3]: Extension for Transport Layer Security", RFC 2830, May
- 2000
-[13]
- Microsoft Corporation, "Services for Unix 2.0",
- http://www.microsoft.com/WINDOWS2000/sfu/default.asp
+[1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
+ (v3)", RFC 2251, December 1997.
+
-[14]
- L. Howard, "An Approach for Using LDAP as a Network Information
+[2] L. Howard, "An Approach for Using LDAP as a Network Information
Service", RFC 2307, March 1998.
-[15]
- S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
- els", RFC 2119, March 1997.
-[16]
- M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
- 2789, April 2000
+[3] Microsoft Corporation, "Windows Services for Unix 3.5",
+ http://www.microsoft.com/windows/sfu/default.asp
-[17]
- M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
- (v3)", RFC 2251, December 1997.
-[18]
+[12] J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
+ 2222, October 1997
+[14] P. Leach, C. Newman, "Using Digest Authentication as a SASL
-Neal-Joslin [Page 26]
+
+
+Neal-Joslin [Page 28]
\f
-Internet-Draft DUA Configuration Schema October 2002
+Internet-Draft DUA Configuration Schema March 2005
+
+ Mechanism", RFC 2831, May 2000
+
+
+[15] T. Howes, "The String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
- G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
+
+[16] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000.
+[17] M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
+ 2789, April 2000
+
+
9. Examples
In this section we will describe a fictional DUA which 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 col-
- loquial name.
+ addresses based on a textual representation of the recipient's
+ colloquial name.
This email service is defined by default to expect that users with
email addresses will be of the "inetOrgPerson" objectclass type
- [16]. And by default, the "email" service expects the colloquial
+ [17]. 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 objectclass.)
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
+
+
+
+Neal-Joslin [Page 29]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
The below examples show how the "email" service builds it search
requests, based on the defined profile. In all cases, the
defaultSearchBase is "o=airius.com" and the defaultSearchScope is
undefined.
In addition, for all examples, we assume that the "email" service
- has been requested to discover the email address for "Jane Hernan-
- dez."
+ has been requested to discover the email address for "Jane
+ Hernandez."
Example 1:
-
-
-Neal-Joslin [Page 27]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
serviceSearchDescriptor: email:"ou=marketing,"
base: ou=marketing,o=airius.com
serviceSearchDescriptor: email:ou=\mar\\keting,\"?base
attributeMap: email:cn=name
+
+
+Neal-Joslin [Page 30]
+\f
+Internet-Draft DUA Configuration Schema March 2005
+
+
base: ou=\mar\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
This example is invalid, since the quote was not a leading quote,
and thus should have been escaped.
-
-
-
-Neal-Joslin [Page 28]
-\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
Example 6:
serviceSearchDescriptor: email:??(&(objectclass=person)
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
-10. Author's Addresses
+Author's Addresses
Luke Howard
PADL Software Pty. Ltd.
USA
Phone: +1 408 447-3044
- EMail: bob_joslin@hp.com
-
-
- Morteza Ansari
- Infoblox
- 1313 Geneva Drive
- Sunnyvale, CA 94089
- USA
-
- Phone: +1 408-716-4300
- EMail: morteza@infoblox.com
-Neal-Joslin [Page 29]
+Neal-Joslin [Page 31]
\f
-Internet-Draft DUA Configuration Schema October 2002
-
-
-
-
-
-
-
-
-
+Internet-Draft DUA Configuration Schema March 2005
+ EMail: bob_joslin@hp.com
+ Morteza Ansari
+ Infoblox
+ 475 Potrero Avenue
+ Sunnyvale, CA 94085
+ USA
+ Phone: +1 408-716-4300
+ EMail: morteza@infoblox.com
+ Expires September 2005
-Neal-Joslin [Page 30]
+Neal-Joslin [Page 32]
+\f
--- /dev/null
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: April 24, 2005 October 24, 2004
+
+
+
+ Distributed Procedures for LDAP Operations
+ draft-sermersheim-ldap-distproc-01.txt
+
+
+Status of this Memo
+
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+ This Internet-Draft will expire on April 24, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+ This document provides the data types and procedures used while
+ servicing Lightweight Directory Application Protocol (LDAP) user
+ operations in order to participate in a distributed directory. In
+ particular, it describes the way in which an LDAP user operation in a
+ distributed directory environment finds its way to the proper DSA(s)
+ for servicing.
+
+
+Discussion Forum
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 1]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext@ietf.org>. Please send
+ editorial comments directly to the author.
+
+
+Table of Contents
+
+
+ 1. Distributed Operations Overview . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5
+ 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . . 5
+ 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3 Chained Response . . . . . . . . . . . . . . . . . . . . . . 11
+ 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 14
+ 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . . 16
+ 4.3 Populating the ContinuationReference . . . . . . . . . . . . 19
+ 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . . 21
+ 4.5 Emulating the Sending of a ChainedRequest . . . . . . . . . 23
+ 4.6 Receiving a ChainedRequest . . . . . . . . . . . . . . . . . 24
+ 4.7 Returning a Chained Response . . . . . . . . . . . . . . . . 25
+ 4.8 Receiving a Chained Response . . . . . . . . . . . . . . . . 26
+ 4.9 Returning a Referral or Intermediate Referral . . . . . . . 27
+ 4.10 Acting on a Referral or Intermediate Referral . . . . . . . 30
+ 4.11 Ensuring non-existence of an entry under an nssr . . . . . . 31
+ 4.12 Mapping a referralURI to an LDAP URI . . . . . . . . . . . . 31
+ 4.13 Using the ManageDsaIT control . . . . . . . . . . . . . . . 32
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 33
+ 6. Normative References . . . . . . . . . . . . . . . . . . . . 33
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . 34
+ A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
+ A.1 LDAP Object Identifier Registrations . . . . . . . . . . . . 35
+ A.2 LDAP Protocol Mechanism Registrations . . . . . . . . . . . 35
+ A.3 LDAP Descriptor Registrations . . . . . . . . . . . . . . . 37
+ A.4 LDAP Result Code Registrations . . . . . . . . . . . . . . . 38
+ Intellectual Property and Copyright Statements . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 2]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+1. Distributed Operations Overview
+
+
+ One characteristic of X.500-based directory systems [X500] is that,
+ given a distributed Directory Information Tree (DIT), a user should
+ potentially be able to have any service request satisfied (subject to
+ security, access control, and administrative policies) irrespective
+ of the Directory Service Agent (DSA) to which the request was sent.
+ To accommodate this requirement, it is necessary that any DSA
+ involved in satisfying a particular service request have some
+ knowledge (as specified in {TODO: Link to future Distributed Data
+ Model doc}) of where the requested information is located and either
+ return this knowledge to the requester or attempt to satisfy the
+ request satisfied on the behalf of the requester (the requester may
+ either be a Directory User Agent (DUA) or another DSA).
+
+
+ Two modes of operation distribution are defined to meet these
+ requirements, namely "chaining" and "returning referrals".
+ "Chaining" refers to the attempt by a DSA to satisfy a request by
+ sending one or more chained operations to other DSAs. "Returning
+ referrals", is the act of returning distributed knowledge information
+ to the requester, which may then itself interact with the DSA(s)
+ identified by the distributed knowledge information. It is a goal of
+ this document to provide the same level of service whether the
+ chaining or referral mechanism is used to distribute an operation.
+
+
+ The processing of an operation is talked about in two major phases,
+ namely "name resolution", and "operation evaluation". Name
+ resolution is the act of locating a local DSE held on a DSA given a
+ distinguished name (DN). Operation evaluation is the act of
+ performing the operation after the name resolution phase is complete.
+
+
+ While distributing an operation, a request operation may be
+ decomposed into several sub-operations.
+
+
+ The distributed directory operation procedures described in this
+ document assume the absense of the ManageDsaIT control defined in
+ [RFC3296] and described in Section 4.13.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 3]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+2. Conventions
+
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+
+ All Basic Encoding Rules (BER) [X690] encodings follow the
+ conventions found in Section 5.1 of [RFC2251].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 4]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3. Distributed Operation Data Types
+
+
+ The data types in this section are used by the chaining and referral
+ distributed operation mechanisms described in Section 4
+
+
+3.1 ContinuationReference
+
+
+ As an operation is being processed by a DSA, it is useful to group
+ the information passed between various procedures as a collection of
+ data. The ContinuationReference data type is introduced for this
+ purpose. This data type is populated and consumed by various
+ procedures discussed in various sections of this document. In
+ general, a ContinuationReference is used when indicating that
+ directory information being acted on is not present locally, but may
+ be present elsewhere.
+
+
+ A ContinuationReference consists of one or more addresses which
+ identify remote DSAs along with other information pertaining both to
+ the distributed knowledge information held on the local DSA as well
+ as information relevant to the operation. This data type is
+ expressed here in Abstract Syntax Notation One (ASN.1) [X680].
+
+
+ ContinuationReference ::= SET {
+ referralURI [0] SET SIZE (1..MAX) OF URI,
+ localReference [2] LDAPDN,
+ referenceType [3] ReferenceType,
+ remainingName [4] RelativeLDAPDN OPTIONAL,
+ searchScope [5] SearchScope OPTIONAL,
+ searchedSubtrees [6] SearchedSubtrees OPTIONAL,
+ failedName [7] LDAPDN OPTIONAL,
+ ... }
+
+
+ <Editor's Note: Planned for addition is a searchCriteria field which
+ is used both for assuring that the remote object is in fact the
+ object originally pointed to (this mechanism provides a security
+ measure), and also to allow moved or renamed remote entries to be
+ found. Typically the search criteria would have a filter value of
+ (entryUUID=<something>)>
+
+
+ URI ::= LDAPString -- limited to characters permitted in URIs
+ [RFC2396].
+
+
+ ReferenceType ::= ENUMERATED {
+ superior (0),
+ subordinate (1),
+ cross (2),
+ nonSpecificSubordinate (3),
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 5]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ suplier (4),
+ master (5),
+ immediateSuperior (6),
+ self (7),
+ ... }
+ SearchScope ::= ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ subordinateSubtree (3),
+ ... }
+
+
+ SearchedSubtrees ::= SET OF RelativeLDAPDN
+
+
+ LDAPDN, RelativeLDAPDN, and LDAPString, are defined in [RFC2251].
+
+
+ The following subsections introduce the fields of the
+ ContinuationReference data type, but do not provide in-depth
+ semantics or instructions on the population and consumption of the
+ fields. These topics are discussed as part of the procedural
+ instructions.
+
+
+3.1.1 ContinuationReference.referralURI
+
+
+ The list of referralURI values is used by the receiver to progress
+ the operation. Each value specifies (at minimum) the protocol and
+ address of one or more remote DSA(s) holding the data sought after.
+ URI values which are placed in ContinuationReference.referralURI must
+ allow for certain elements of data to be conveyed. Section 3.1.1.1
+ describes these data elements. Furthermore, a mapping must exist
+ which relates the parts of a specified URI to these data elements.
+ This document provides such a mapping for the LDAP URL [RFC2255] in
+ Section 4.12.
+
+
+ In some cases, a referralURI will contain data which has a
+ counterpart in the fields of the ContinuationReference (an example is
+ where the referralURI is an LDAP URL, holds a <scope> value, and the
+ ContinuationReference.searchScope field is also present). In these
+ cases, the data held on the referralURI overrides the field in the
+ ContinuationReference. Specific examples of this are highlighted in
+ other sections. Providing a means for these values to exist as
+ fields of the ContinuationReference allows one value to be applied to
+ all values of referralURI (as opposed to populating duplicate data on
+ all referralURI values).
+
+
+ If a referralURI value identifies an LDAP-enabled DSA [RFC3377], the
+ LDAP URL form is used.
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 6]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3.1.1.1 Elements of referralURI Values
+
+
+ The following data elements must be allowed and identified for a
+ specified URI type to be used to convey referral information. Each
+ element is given a name which begins with 'referralURI.' for clarity
+ when referencing the elements conceptually in other parts of this
+ document.
+
+
+ o referralURI.protocolIdentifier. There must be an indication of
+ the protocol to be used to contact the DSA identified by the URI.
+ o referralURI.accessPoint. The URI must identify a DSA in a manner
+ that can be used to contact it using the protocol specified in
+ protocolIdentifier.
+ o referralURI.targetObject. Holds the name to be used as the base
+ DN of the operation being progressed. This field must be allowed
+ by the URI specification, but may be omitted in URI instances for
+ various reasons.
+ o referralURI.localReference. See Section 3.1.2. This field must
+ be allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.searchScope. See Section 3.1.5. This field must be
+ allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.searchedSubtrees. See Section 3.1.6. This field must
+ be allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.failedName. See Section 3.1.7. This field must be
+ allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+
+
+3.1.2 ContinuationReference.localReference
+
+
+ This names the DSE which was found to hold distributed knowledge
+ information, and thus which caused the ContinuationReference to be
+ formed. This field is primarily used to help convey the new target
+ object name, but may also be used for purposes referential integrity
+ (not discussed here). In the event that the root object holds the
+ distributed knowledge information, this field is present and is
+ populated with an empty DN.
+
+
+3.1.3 ContinuationReference.referenceType
+
+
+ Indicates the DSE Type of the ContinuationReference.localReference.
+ This field may be used to determine how to progress an operations
+ (i.e. if the value is nonSpecificSubordinate, a search continuation
+ will exclude the ContinuationReference.referenceType).
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 7]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3.1.4 ContinuationReference.remainingName
+
+
+ In certain scenarios, the localReference does not completely name the
+ DSE to be used as the new target object name. In these cases,
+ remainingName is populated with the RDNSequence relative to the
+ localReference of the target object name being resolved. Some
+ examples of these scenarios include (but are not restricted to):
+
+
+ o During name resolution, the name is not fully resolved, but a DSE
+ holding distributed knowledge information is found, causing a
+ ContinuationReference to be generated.
+ o While searching, an alias is dereferenced. The aliasedObjectName
+ points to a DSE of type glue which is subordinate to a DSE holding
+ distributed knowledge information.
+
+
+3.1.5 ContinuationReference.searchScope
+
+
+ Under certain circumstances, when progressing a search operation, a
+ search scope different than that of the original search request must
+ be used. This field facilitates the conveyance of the proper search
+ scope to be used when progressing the distributed operation.
+
+
+ The scope of subordinateSubtree has been added to the values allowed
+ by the LDAP SearchRequest.scope field. This scope includes the
+ subtree of entries below the base DN, but does not include the base
+ DN itself. This is used here when progressing distributed search
+ operations caused by the existence of a DSE of type nssr.
+
+
+ If a referralURI.searchScope is present, it overrides this field
+ while that referralURI is being operated upon.
+
+
+3.1.6 ContinuationReference.searchedSubtrees
+
+
+ For ContinuationReferences generated while processing a search
+ operation with a scope of wholeSubtree, each value of this field
+ indicates that a particular subtree below the target object has
+ already been searched. Consumers of this data use it to cause the
+ progression of the search operation to exclude these subtrees as a
+ mechanism to avoid receiving duplicate entries.
+
+
+ If a referralURI.searchedSubtrees is present, it overrides this field
+ while that referralURI is being operated upon.
+
+
+3.1.7 ContinuationReference.failedName
+
+
+ When an operation requires that multiple names be resolved (as is the
+ case with the ModifyDN operation), this field is used to specify
+ which name was found to be non-local.
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 8]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ If a referralURI.failedName is present, it overrides this field while
+ that referralURI is being operated upon.
+
+
+3.2 ChainedRequest
+
+
+ The Chained Request is sent as an LDAP extended operation. The
+ requestName is IANA-ASSIGNED-OID.1. The requestValue is the BER
+ encoding of the following ChainedRequestValue ASN.1 definition:
+
+
+ ChainedRequestValue ::= SEQUENCE {
+
+
+ chainingArguments ChainingArguments,
+ operationRequest OperationRequest }
+
+
+ ChainingArguments ::= SEQUENCE {
+
+
+ targetObject [0] LDAPDN OPTIONAL,
+ referenceType [1] ReferenceType,
+ traceInformation [2] ChainingTraceInformation,
+ searchScope [3] SearchScope OPTIONAL,
+ searchedSubtrees [4] SearchedSubtrees OPTIONAL}
+
+
+ ChainingTraceInformation ::= SET OF LDAPURL
+
+
+ OperationRequest ::= SEQUENCE {
+
+
+ Request ::= CHOICE {
+
+
+ bindRequest BindRequest,
+ searchRequest SearchRequest,
+ modifyRequest ModifyRequest,
+ addRequest AddRequest,
+ delRequest DelRequest,
+ modDNRequest ModifyDNRequest,
+ compareRequest CompareRequest,
+ extendedReq ExtendedRequest,
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ BindRequest, SearchRequest, ModifyRequest, AddRequest, DelRequest,
+ ModifyDNRequest, CompareRequest, ExtendedRequest and Controls are
+ defined in [RFC2251].
+
+
+3.2.1 ChainedRequestValue.chainingArguments
+
+
+ In general, these fields assist in refining the original operation as
+ it is to be executed on the receiving DSA.
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 9]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3.2.1.1 ChainedRequestValue.chainingArguments.targetObject
+
+
+ This field contains the new target (or base) DN for the operation.
+
+
+ The sending DSA populates this under different scenarios including
+ the case where an alias has been dereferenced while resolving the DN,
+ and also the case where a referral carries a target name different
+ from the reference object that caused the referral.
+
+
+ This field can be omitted only if it would be the the same value as
+ the object or base object parameter in the
+ ChainedRequestValue.operationRequest, in which case its implied value
+ is that value.
+
+
+ The receiving DSA examines this field and (if present) uses it rather
+ than the base DN held in the ChainedRequestValue.operationRequest.
+
+
+3.2.1.2 ChainedRequestValue.chainingArguments.referenceType
+
+
+ See Section 3.1.3.
+
+
+ If the receiver encounters a value of nonSpecificSubordinate in this
+ field, it indicates that the operation is being chained due to DSE of
+ type nssr. In this case, the receiver allows (and expects) the base
+ DN to name the immediate superior of a context prefix.
+
+
+3.2.1.3 ChainedRequestValue.chainingArguments.traceInformation
+
+
+ This contains a set of URIs. Each value represents the address of a
+ DSA and DN that has already been contacted while attempting to
+ service the operation. This field is used to detect looping while
+ servicing a distributed operation.
+
+
+ The sending DSA populates this with its own URI, and also the URIs of
+ any DSAs that have already been chained to. The receiving DSA
+ examines this list of URIs and returns a loopDetect error if it finds
+ that any of the addresses and DNs in the listed URI's represent it's
+ own.
+
+
+3.2.1.4 ChainedRequestValue.chainingArguments.searchScope
+
+
+ See Section 3.1.5.
+
+
+3.2.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees
+
+
+ See Section 3.1.6.
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 10]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3.2.2 ChainedRequestValue.operationRequest
+
+
+ This holds the original LDAP operation request. This is restricted
+ to a subset of all LDAP operations. Namely, the following LDAP
+ operation types are not allowed:
+
+
+ o Abandon/Cancel operations. When an abandon or cancel operation
+ needs to be chained, it is sent to the remote DSA as-is. This is
+ because there is no need to track it for loop detection or pass on
+ any other information normally found in ChainingArguments.
+ o Unbind. Again, there is no need to send chaining-related
+ information to a DSA to perform an unbind. DSAs which chain
+ operations maintain connections as they see fit.
+ o Chained Operation. When a DSA receives a chained operation, and
+ must again chain that operation to a remote DSA, it sends a
+ ChainedRequest where the ChainedRequestValue.operationRequest is
+ that of the incoming ChainedRequestValue.operationRequest.
+
+
+3.3 Chained Response
+
+
+ The Chained Response is sent as an LDAP IntermediateResponse
+ [RFC3771], or LDAP ExtendedResponse [RFC2251], depending on whether
+ the operation is complete or not. In either case, the responseName
+ is omitted. For intermediate responses, the
+ IntermediateResponse.responseValue is the BER encoding of the
+ ChainedIntermediateResponseValue ASN.1 definition. For completed
+ operations, the ExtendedResponse.value is the BER encoding of the
+ ChainedFinalResponseValue ASN.1 definition.
+
+
+ ChainedIntermediateResponseValue ::= SEQUENCE {
+
+
+ chainedResults ChainingResults,
+ operationResponse IntermediateResponse }
+
+
+ ChainedFinalResponseValue ::= SEQUENCE {
+
+
+ chainedResults ChainingResults,
+ operationResponse FinalResponse }
+
+
+ ChainingResults ::= SEQUENCE {
+
+
+ searchedSubtrees [0] SearchedSubtrees OPTIONAL,
+ ... }
+
+
+ IntermediateResponse ::= SEQUENCE {
+
+
+ Response ::= CHOICE {
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 11]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+
+ searchResEntry SearchResultEntry,
+ searchResRef SearchResultReference,
+ intermediateResponse IntermediateResponse
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ FinalResponse ::= SEQUENCE {
+
+
+ Response ::= CHOICE {
+
+
+ bindResponse BindResponse,
+ searchResDone SearchResultDone,
+ modifyResponse ModifyResponse,
+ addResponse AddResponse,
+ delResponse DelResponse,
+ modDNResponse ModifyDNResponse,
+ compareResponse CompareResponse,
+ extendedResp ExtendedResponse,
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ BindResponse, SearchResultEntry, SearchResultDone,
+ SearchResultReference, ModifyResponse, AddResponse, DelResponse,
+ ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls are
+ defined in [RFC2251]. IntermediateResponse is defined in [RFC3771].
+
+
+3.3.1 ChainingResults
+
+
+ In general, this is used to convey additional information that may
+ needed in the event that the operation needs to be progressed
+ further.
+
+
+3.3.1.1 ChainingResults.searchedSubtrees
+
+
+ Each value of this field indicates that a particular subtree below
+ the target object has already been searched. This is particularly
+ useful while chaining search operations during operation evaluation
+ caused by the presence of a DSA of type nssr. Each DSA referenced by
+ the nssr holds one or more naming contexts subordinate to the nssr
+ DSE. The ChainingResults.searchedSubtrees field allows the DSA being
+ chained to, to inform the sending DSA which subordinate naming
+ contexts have been searched. This information may be passed to
+ further DSAs listed on the nssr in order to reduce the possibility of
+ duplicate entries being returned.
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 12]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+3.3.2 ChainedIntermediateResponseValue.intermediateResponse and
+ ChainedFinalResponseValue.finalResponse
+
+
+ This holds the directory operation response message tied to the
+ ChainedRequestValue.operationRequest.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 13]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4. Distributed Procedures
+
+
+ For the purposes of describing a distributed operation, operations
+ are said to consist of two major phases -- name resolution and
+ operation evaluation. These terms are adopted from [X518]. Name
+ resolution is the act of locating a DSE said to be held locally by a
+ DSA given a distinguished name (DN). Operation evaluation is the act
+ of performing the operation after the name resolution phase is
+ complete.
+
+
+ Furthermore, there are two modes of distributing an operation --
+ chaining, and returning referrals. Chaining is the act of forwarding
+ an unfinished operation to another DSA for completion (this may
+ happen during name resolution or operation evaluation). In this
+ case, the forwarding DSA sends a chained operation to a receiving
+ DSA, which attempts to complete the operation. Alternately, the DSA
+ may return a referral (or intermediate referral), and the client may
+ use that referral in order to forward the unfinished operation to
+ another DSA. Whether the operation is distributed via chaining or
+ referrals is a decision left to the DSA and or DUA.
+
+
+ The term 'intermediate referral' describes a referral returned during
+ the operation evaluation phase of an operation. These include
+ searchResultReferences, referrals returned with an
+ intermediateResponse [RFC3771], or future referrals which indicate
+ that they are intermediate referrals.
+
+
+ An operation which is distributed while in the operation evaluation
+ phase is termed a 'sub-operation'.
+
+
+ This document inserts a step between the two distributed operation
+ phases in order to commonize the data and processes followed prior to
+ chaining an operation or returning a referral. This step consists of
+ populating a ContinuationReference data type.
+
+
+4.1 Name resolution
+
+
+ Before evaluating (enacting) most directory operations, the DSE named
+ by the target (often called the base DN) of the operation must be
+ located . This is done by evaluating the RDNs of the target DN one
+ at a time, starting at the rootmost RDN. Each RDN is compared to the
+ DSEs held by the DSA until the set of RDNs is exhausted, or an RDN
+ cannot be found.
+
+
+ If the DSE named by the target is found to be local, the name
+ resolution phase of the operation completes and the operation
+ evaluation phase begins.
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 14]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ If it is found that the target does not name a local DSE nor a DSE
+ that may held by another DSA, it is said that the target does not
+ exist, and the operation fails with noSuchObject (subject to local
+ policy).
+
+
+ If it is found that the DSE named by the target is non-local to the
+ DSA, but may reside elsewhere, name resolution is said to be
+ incomplete. In this case, the operation may be distributed by
+ creating a ContinuationReference (Section 4.3) and either chaining
+ the operation (Section 4.4 and Section 4.5)or returning a referral
+ (Section 4.9).
+
+
+4.1.1 Determining that a named DSE is local to a DSA
+
+
+ If a DSE held by a DSA falls within a naming context held by the DSA,
+ or is the root DSE on a first-level DSA, it is said to be local to
+ that DSA
+
+
+4.1.2 Determining that a named DSE does not exist
+
+
+ A named DSE is said to not exist if, during name resolution the DSE
+ is not found, but if found it would fall within a naming context held
+ by the DSA.
+
+
+4.1.3 Determining that a named DSE is non-local
+
+
+ If a named DSE is niether found to be local to the DSA, nor found to
+ not exist, it is said to be non-local to a DSA. In this case, it is
+ indeterminate whether the named DSE exists.
+
+
+ When a named DSE is found to be non-local, there should be
+ distributed knowledge information available to be used to either
+ return a referral or chain the operation.
+
+
+4.1.3.1 Locating distributed knowledge information for a non-local
+ target
+
+
+ If it has been determined that a target names a non-local DSE,
+ distributed knowledge information may be found by first examining the
+ DSE named by the target, and subsequently all superior DSEs beginning
+ with the immediate superior and ending with the root, until an
+ examined DSE is one of types:
+
+
+ {TODO: should DSE types be all caps? It would be easier to read.}
+ o subr
+ o supr
+ o immsupr
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 15]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ o xr
+ o nssr
+
+
+ The examined DSE which is of one of these types holds the distributed
+ knowledge information for the non-local named target. This DSE is
+ said to be the found distributed knowledge information of the
+ non-local target. This found distributed knowledge information may
+ then be used to distribute the operation.
+
+
+ If no examined DSEs are of any of these types, the distributed
+ knowledge information is mis-configured, and the error
+ invalidReference is returned.
+
+
+4.1.4 Special case for the Add operation
+
+
+ During the name resolution phase of the Add operation, the immediate
+ parent of the base DN is resolved.
+
+
+ If the immediate parent of the entry to be added is a DSE of type
+ nssr, then further interrogation is needed to ensure that the entry
+ to be added does not exist. Methods for doing this are found in
+ Section 4.11. {TODO: don't make this mandatory. Also, it doesn't
+ work without transaction semantics. Same prob in the mod dn below.}.
+
+
+4.1.5 Special case for the ModifyDN operation
+
+
+ When the modifyDN operation includes a newSuperior name, it must be
+ resolved as well as the base DN being modified. If either of these
+ result in a non-local name, the name causing the operation to be
+ distributed should be conveyed (Section 4.3.5). {TODO: also mention
+ access control problems, and mention (impl detail) that
+ affectsmultidsa can be used.}
+
+
+ If during operation evaluation of a ModifyDN operation, the
+ newSuperior names a DSE type of nssr, then further interrogation is
+ needed to ensure that the entry to be added does not exist. Methods
+ for doing this are found in Section 4.11.
+
+
+4.2 Operation Evaluation
+
+
+ Once name resolution has completed. The DSE named in the target has
+ been found to be local to a DSA. At this point the operation can be
+ carried out. During operation evaluation distributed knowledge
+ information may be found that may cause the DSA to distribute the
+ operation. When this happens, the operation may be distributed by
+ creating a ContinuationReference (Section 4.3) and either chaining
+ the operation (Section 4.4 and Section 4.5)or returning a referral
+ (Section 4.9).
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 16]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ If, during the location of the distributed knowledge information, the
+ distributed knowledge information is found to be mis-configured,
+ operation semantics are followed (some operations may call for an
+ error to be returned, while others call for the error to be ignored).
+ {TODO: either make this more specific, or less specific, or just toss
+ it out.}
+
+
+4.2.1 Search operation
+
+
+ During operation evaluation of a search operation, the DSA must
+ determine whether there is distributed knowledge information in the
+ scope of the search. Any DSE in the search scope which is of the
+ following types is considered to be 'found distributed knowledge
+ information' {TODO: use a better term than found distributed
+ knowledge information} in the search scope:
+
+
+ o subr
+ o nssr (see nssr note)
+ o xr {TODO: I think xr only qualifies when an alias is dereferenced
+ to an xr. Otherwisw, there should always be a subr above the xr
+ if it falls in the search scope.}
+
+
+ Note that due to alias dereferencing, the search scope may expand to
+ include entries outside of the scope originally specified in the
+ search operation.
+
+
+ Nssr Note: A DSE of type nssr is only considered to be found
+ distributed knowledge information when the scope of the search
+ includes entries below it. For example, when the search scope is
+ wholeSubtree or subordinateSubtree and a DSE of type nssr is found in
+ the scope, or if the search scope is singleLevel and the target
+ object names a DSE of type nsssr.
+
+
+ {TODO: The following sections are talking about how the continuation
+ reference is to be populated. Move to next secion. Can probably
+ just say that whole subtree or subordinare subtree encountering nssr,
+ and single level rooted at nssr result in a continuation reference.
+ base at, and single level above do not result in a continuation
+ reference.}
+
+
+4.2.1.1 Search operation with singleLevel scope
+
+
+ If distributed knowledge information is found during operation
+ evaluation of a search with a singleLevel scope, it will cause the
+ resulting ContinuationReference.searchScope to be set to baseObject.
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 17]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4.2.1.2 Search operation encountering nssr knowledge reference
+
+
+ When a search operation encounters distributed knowledge information
+ which is a DSE type of nssr during operation evaluation, the
+ following instructions are followed:
+
+
+ Note that when a search operation is being progressed due to nssr
+ knowledge information, the subsequent distributed progression of the
+ search is caused to be applied to each DSA listed as non-specific
+ knowledge information (This is talked about in Section 4.3.2). In
+ the event that multiple DSAs listed in the knowledge information hold
+ copies of the same directory entries, the 'already searched' and
+ 'duplicate elimination' mechanisms SHOULD be used to prevent
+ duplicate search result entries from ultimately being returned.
+
+
+4.2.1.2.1 wholeSubtree search scope
+
+
+ When the search scope is wholeSubtree, the
+ ContinuationReference.searchScope is set to subordinateSubtree.
+ Because the ContinuationReference.referrenceType is set to
+ nonSpecificSubordinate, the receiving protocol peer allows (and
+ expects) name resolution to stop at an immsupr DSE type which is
+ treated as a local DSE. The subordinateSubtree scope instructs the
+ receiving protocol peer to exclude the target object from the
+ sub-search.
+
+
+4.2.1.2.2 singleLevel search scope
+
+
+ When the search scope is singleLevel, and the base DN is resolved to
+ a DSE of type nssr, subsequent distributed progressions of the search
+ are caused to use the same base DN, and a scope of singleLevel.
+ Receiving protocol peers will only apply the search to entries below
+ the target object.
+
+
+ When the search scope is singleLevel and an evaluated DSE is of type
+ nssr, no special handling is required. The search is applied to that
+ DSE if it is of type entry.
+
+
+4.2.1.2.3 baseObject search scope
+
+
+ No special handling is needed when the search scope is baseObject and
+ the base DN is an nssr DSEType. The search is applied to that DSE if
+ it is of type entry.
+
+
+4.2.1.3 Search operation rooted at an nssr DSE type
+
+
+ (TODO: a subordinateSubtree scope needs to change to wholeSubtree if
+ references are found.)
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 18]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4.3 Populating the ContinuationReference
+
+
+ When an entry is found to be non-local to a DSA (whether during name
+ resolution or operation evaluation), the DSA prepares for operation
+ distribution by generating a ContinuationReference. This is a
+ conceptual step, given to help explain the interactions that occur
+ between discovering that an operation must be distributing, and
+ actually invoking the operation distribution mechanism.
+ Implementations are not required to perform this step, but will
+ effectively work with the same information.
+
+
+ After the ContinuationReference has been created, the DSA may choose
+ to chain the operation or return a referral (or intermediate
+ referral(s)).
+
+
+ the ContinuationReference is made up of data held on the found
+ distributed knowledge information, as well as state information
+ gained during name resolution or operation evaluation.
+
+
+4.3.1 Conveying the Target Object
+
+
+ The consumer of the ContinuationReference will examine various fields
+ in order to determine the target object name of the operation being
+ progressed. The fields examined are the localReference and
+ remainingName.
+
+
+ If name resolution did not complete, and the found distributed
+ knowledge information names the same DSE as the base DN of the
+ operation, the ContinuationReference MAY omit the localReference
+ and/or remainingName fields.
+
+
+ localReference is populated with the name of the found distributed
+ knowledge information DSE. In the event that the root object holds
+ the distributed knowledge information, this field will be populated
+ with an empty DN. Contrast this with the omission of this field.
+
+
+ referenceType is populated with a value reflecting the reference type
+ of the localReference DSE.
+
+
+ remainingName is populated with the RDNSequence which has not yet
+ been resolved. This is the difference between the localReference
+ value and the name of the DSE to be resolved.
+
+
+ In cases where the DSE named by the {TODO, use a dash or different
+ term to make 'found distributed knowledge' more like a single term}
+ found distributed knowledge is not the same as the base DN of the
+ operation, the ContinuationReference must contain the localReference
+ and/or remainingName fields. Such cases include but are not limited
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 19]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ to:
+
+
+ o Distributed knowledge information is found during operation
+ evaluation.
+ o Aliases were dereferenced during name resolution.
+ o Name resolution did not complete and there were remaining RDNs to
+ be resolved.
+
+
+4.3.2 Conveying the Remote DSA
+
+
+ The referralURI field must contain at least one value. Each
+ referralURI value must hold a referralURI.accessPoint. Other
+ requirements on this field as noted may also apply.
+
+
+ Note for nssr DSE types: During operation evaluation, if a DSE of
+ type nssr causes the operation to be distributed (the scenarios in
+ Section 4.2.1.2 are an example), then an intermediate referral {TODO:
+ this is talking about referral/intermediate referral, but this
+ section is only dealing with populating continuation reference} is
+ returned for each value of the ref attribute, where each intermediate
+ referral only holds a single referralURI value.
+
+
+4.3.3 Conveying new search scope
+
+
+ During the evaluation of the search operation, the instructions in
+ Section 4.2.1.2.1 and Section 4.2.1.2.2 are followed and the
+ searchScope field is updated with the new search scope.
+
+
+4.3.4 Preventing duplicates
+
+
+ In order to prevent duplicate entries from being evaluated while
+ progressing a search operation, the searchedSubtrees field is
+ populated with any naming context below the
+ ContinuationReference.targetObject which have been fully searched.
+
+
+ During the evaluation of the search operation, if the scope is
+ wholeSubtree, it is possible that the DSA may search the contents of
+ a naming context which is subordinate to another naming context which
+ is subordinate to the search base (See figure).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 20]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ O X
+ / \
+ / \
+ / \
+ / \
+ \_______O Y
+ /|\
+ / | \
+ / | \
+ / | \
+ A B O C
+ / \
+ / \
+ / \
+ / \
+ \_______/
+
+
+ In this figure, the DSA holds the naming context X and C,Y,X, but not
+ Y,X. If the search base was X, an intermediate referral would be
+ returned for Y,X. The DSA holding Y,X may also hold a copy of C,Y,X.
+ In this case, the receiver of the ContinuationReference benefits by
+ knowing that the DSA already searched C,Y,X so that it can prevent
+ other DSAs from returning those entries again.
+
+
+ Data already searched is in the form of an RDNSequence, consisting of
+ the RDNs relative to the target object.
+
+
+4.3.5 Conveying the Failed Name
+
+
+ At least one DS operation (modifyDN) requires that multiple DNs be
+ resolved (the entry being modified and the newSuperior entry). In
+ this case, the failedName field will be populated with the DN being
+ resolved which failed name resolution. This may aid in the
+ determination of how the operation is to be progressed. If both
+ names are found to be non-local, this field is omitted.
+
+
+4.4 Sending a ChainedRequest
+
+
+ When an entry is found to be non-local to a DSA (whether during name
+ resolution or operation evaluation), the DSA may progress the
+ operation by sending a chained operation to another DSA (or DSAs).
+ The instructions in this section assume that a ContinuationReference
+ has been generated which will be used to form the ChainedRequest. It
+ is also assumed that it can be determined whether the operation is
+ being progressed due to name resolution or due to operation
+ evaluation.
+
+
+ A DSA which is able to chain operations may advertise this by
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 21]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures
+ attribute on the root DSE. {TODO: does this and discovery of the
+ extended op belong in a new 'discovery mechanisms' sections.}
+
+
+4.4.1 Forming a ChainedRequest
+
+
+ The following fields are populated as instructed:
+
+
+4.4.1.1 ChainedRequestValue.chainingArguments.targetObject
+
+
+ The ContinuationReference may convey a new target object. If
+ present, the ContinuationReference.localReference field becomes the
+ candidate target object. Otherwise the candidate target object is
+ assumed to be that of the original directory operation. Note that an
+ empty value in the ContinuationReference.localReference field denotes
+ the root object.
+
+
+ After performing the above determination as to the candidate target
+ object, any RDNSequence in ContinuationReference.remainingName is
+ prepended to the determined candidate target object. This value
+ becomes the ChainedRequestValue.chainingArguments.targetObject. If
+ this value matches the value of the original operation, this field
+ may be omitted.
+
+
+4.4.1.2 ChainedRequestValue.chainingArguments.referenceType
+
+
+ This is populated with the
+ ContinuationReference.referralURI.referenceType.
+
+
+4.4.1.3 ChainedRequestValue.chainingArguments.traceInformation
+
+
+ This is populated as specified in Section 3.2.1.3.
+
+
+4.4.1.4 ChainedRequestValue.chainingArguments.searchScope
+
+
+ This is populated with the
+ ContinuationReference.referralURI.searchScope if present, otherwise
+ by the ContinuationReference.searchScope if present, and not
+ populated otherwise.
+
+
+4.4.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees
+
+
+ This is populated with ContinuationReference.searchedSubtrees, as
+ well as any previously received values of
+ ChainedFinalResponseValue.chainingResults.searchedSubtrees or
+ ChainedIntermediateResponseValue.chainingResults.searchedSubtrees
+ which are subordinate, relative to the target object. (If thsi is
+ relative to the target object, it can't contain non-relative
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 22]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ subtrees)
+
+
+4.4.1.6 ChainedRequestValue.operationRequest
+
+
+ This is populated with the original directory operation request.
+
+
+4.4.2 Attempting Each Referral URI
+
+
+ A ContinuationReference consists of one or more referralURIs which
+ represent(s a) remote DSA(s). The chaining DSA attempts to chain to
+ each of these DSAs until one succeeds in completing the operation.
+ An operation is considered to be completed if it reaches the remote
+ DSA and a response is sent back that indicates that the operation was
+ executed. Operations which are sent to the remote DSA, but don't
+ complete are indicated by a result code of unavailable or busy. A
+ result code of protocolError may indicate that the DSA does not
+ support the chained operation, and in this case, it is also treated
+ as an uncompleted operation. Other errors may in the future specify
+ that they also indicate non-completion. Note that the response may
+ itself contain referral(s), these are still considered completed
+ operations and thus would subsequently be handled and chained.
+ {TODO: could use soft/hard, or transient/permanent
+ referral/non-referral error terms here.}
+
+
+4.4.3 Loop Prevention
+
+
+ Prior to sending a ChainedRequest, the DSA may attempt to prevent
+ looping scenarios by comparing {TODO: what matching rule is used?
+ Suggest we don't convert dns names to ip addresses due to NATs} the
+ address of the remote DSA and target object to the values of
+ ChainedRequestValue.chainingArguments.traceInformation. If a match
+ is found, the DSA returns a loopDetect error. Note that while this
+ type of loop prevention aids in detecting loops prior to sending data
+ to a remote DSA, it is not a substitute for loop detection (Section
+ Section 4.6.2). This is because the sending DSA is only aware of a
+ single address on which the receiving DSA accepts connections.
+
+
+4.5 Emulating the Sending of a ChainedRequest
+
+
+ When it is determined that the operation cannot be distributed by
+ means of the ChainedRequest, the chaining DSA may instead emulate the
+ steps involved in chaining the operation. These steps consist of
+ performing loop prevention, forming a new directory operation request
+ from the original request and possibly updating the base DN, search
+ scope, and search filter(in order to emulate searchedSubtrees), and,
+ similar to the steps in Section 4.4.2, attempting to send the
+ operation request to each DSA listed in the
+ ContinuationReference.referralURI until one succeeds in completing
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 23]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ the operation.
+
+
+ {TODO: We need a way (control) to tell the receiver to allow name
+ resolution to end on the parent of a cp (typically an immsupr). This
+ would be sent when the ContinuationReference.referenceType is
+ nonSpecificSubordinate}
+
+
+4.5.1 Emulated Loop Detection
+
+
+ For this step, the loop prevention instructions in Section 4.4.3 are
+ followed. Note that this method of loop detection may actually allow
+ some looping to occur before the loop is detected.
+
+
+4.5.2 Forming the New Request
+
+
+ The new directory operation request is formed from the fields of the
+ original request, and the following fields may be updated:
+
+
+ o The base DN is formed from the new target object as determined by
+ following the instructions in Section 4.4.1.1 and using the value
+ which would have been placed in
+ ChainedRequestValue.chainingArguments.targetObject.
+ o For the search operation, the scope is populated with
+ ContinuationReference.searchScope if present, otherwise the scope
+ of the original operation request is used.
+ o For the search operation, if the
+ ContinuationReference.searchedSubtrees field is present, causes
+ the search filter to be augmented by adding a filter item of the
+ 'and' CHOICE. The filter consists of {TODO: weasel Kurt into
+ finishing his entryDN draft and reference the appropriate section
+ there. See
+ <http://www.openldap.org/lists/ietf-ldapext/200407/msg00000.html>
+ for context}
+ o Other fields (such as the messageID, and non-critical controls)
+ may also need to be updated or excluded.
+
+
+ If the service being chained to does not support directory
+ operations, other operations may be used as long as they provide the
+ same level as service as those provided by the analogous directory
+ operation.
+
+
+4.6 Receiving a ChainedRequest
+
+
+ A DSA which is able to receive and service a ChainedRequest may
+ advertise this feature by returning a value of IANA-ASSIGNED-OID.1 in
+ the supportedExtension attribute of the root DSE. {TODO: move?}
+
+
+ The ChainedRequestValue data type is the requestValue of an
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 24]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ extendedRequest.
+
+
+ In general, receiving and servicing a ChainedRequest consists of
+ performing loop detection and, using components of the
+ ChainedRequestType.chainingArguments along with the
+ ChainedRequestType.operationRequest, service the request.
+
+
+4.6.1 Target Object determination
+
+
+ Prior to checking for a loop condition, the target object must be
+ determined. If the ChainedRequestType.chainingArguments.targetObject
+ field is present, its value becomes the target object. Otherwise,
+ the base DN found in the ChainedRequestType.operationRequest becomes
+ the target object.
+
+
+4.6.2 Loop Detection
+
+
+ The loop detection check happens when a DSA receives a chained
+ operation, prior to acting on the operation. The DSA compares {TODO:
+ matching rule? DNS expansion?} each value of
+ ChainedRequestValue.traceInformation to the list of addresses at
+ which it accepts directory communications. A value of
+ ChainedRequestValue.traceInformation matches when the DSA accepts
+ directory communications on the address found in the
+ ChainedRequestValue.traceInformation value, and the target object (as
+ determined in Section 4.6.1 matches the DN {TODO: using DN matching?}
+ value found in the ChainedRequestValue.traceInformation value. If a
+ match is found the DSA returns a loopDetect result.
+
+
+4.6.3 Processing the ChainedRequestValue.operationRequest
+
+
+ In processing the operationRequest, the DSA uses the target object
+ determined in Section 4.6.1. For search operations, it uses the
+ scope found in ChainedRequestValue.chainingArguments.searchScope, and
+ excludes any subtrees relative to the target object indicated in
+ ChainedRequestValue.chainingArguments.searchedSubtrees.
+
+
+ Responses are returned in the form of a Chained Response.
+
+
+4.7 Returning a Chained Response
+
+
+ When returning responses to a ChainedRequest, the Chained Response as
+ documented in Section 3.3 is used. If the
+ ChainedFinalResponseValue.operationResponse is a searchResultDone,
+ the ChainedFinalResponseValue.chainingResults.searchedSubtrees field
+ is populated with values consisting of the RDNSequence relative to
+ the target object of naming contexts that the DSA searched. See
+ Section 3.3.1.1 for details on why this is done.
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 25]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4.7.1 Chained Response resultCode
+
+
+ The resultCode for the Chained Response is distinct from the result
+ code of the ChainedIntermediateResponseValue.intermediateResponse or
+ ChainedFinalResponseValue.finalResponse. If the act of chaining the
+ operation completed, then this value will be success. Other result
+ codes refer to the chained operation itself, and not the result of
+ the embedded operation.
+
+
+4.7.2 Returning referrals in the Chained Response
+
+
+ {TODO: it would be less complicated if rather than using the simple
+ LDAP URL, we used the ContinuationReference type to return referrals
+ and intermediate referrals.} {TODO: We need an example of why we
+ should allow referrals on a chained response. Why not just use the
+ referral field in the operation?}
+
+
+4.8 Receiving a Chained Response
+
+
+ Processing a received Chained Response is generally straight forward
+ -- typically the response is simply extracted and returned, but there
+ are some extra steps to be taken when chaining sub-operations.
+
+
+4.8.1 Handling Sub-operation controls and result codes
+
+
+ When sub-operations are chained, there is the possibility that
+ different result codes will be encountered. Similarly, if controls
+ which elicit response controls were attached to the operation, it's
+ possible that multiple response controls will be encountered. Both
+ of these possibilities require that the chaining DSA take appropriate
+ steps to ensure that the response being returned is correct.
+
+
+ In general, when a result code indicating an error is received, the
+ operation will terminate and the error will be returned. In cases
+ where multiple sub-operations are being concurrently serviced, the
+ operation will terminate and the most relevant, or first received
+ result code is returned -- determining the result code to be returned
+ in this case is a local matter.
+
+
+ A DSA which chains an operation having a control (or controls)
+ attached must ensure that a properly formed response is returned.
+ This requires that the DSA understand and know how to aggrigate the
+ results of all controls which it allows to remain attached to an
+ operation being chained. If the DSA does not understand or support a
+ control which is marked non-critical, it removes the control prior to
+ chaining the operation. The DSA may return
+ unavailableCriticalExtension for critical controls that it cannot or
+ will not chain. {TODO: give SSS as an example?}
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 26]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4.8.1.1 Handling referrals during sub-operations
+
+
+ If a referral is returned in response to a sub-operation, the sending
+ DSA may attempt to further chain the operation. In the event that
+ the DSA does not further chain the sub-operation, it will use the
+ referral to construct an intermediate referral, and return it
+ appropriately. When using a referral to construct an intermediate
+ referral, certain transformations may have to happen. For example,
+ when using a referral to construct a searchResultReference, it must
+ be assured that the <dn> field is present, and that the <scope> field
+ is properly updated.
+
+
+4.8.2 Duplicate Elimination
+
+
+ When search result references cause the DSA to chain a search, it is
+ possible that duplicate objects will be returned by different remote
+ DSAs. These duplicate objects must be sensed and not returned.
+
+
+ {TODO: Even though there are costs associated with returning
+ duplicates, is it a worthy exercise to build in an allowance for them
+ to be returned? In other words, do we want to add a way for a client
+ (or administrator) to say "it's ok, return the duplicates, let the
+ client deal with them"? Allowing is seen as a cost benefit to the
+ DSA.}
+
+
+4.9 Returning a Referral or Intermediate Referral
+
+
+ There are two ways in which the fields of the ContinuationReference
+ may be conveyed in a response containing or consisting of referral or
+ intermediate referral. A paired control is introduced for the
+ purpose of soliciting and returning a ContinuationReference. In
+ absence of this control, a referral or intermediate referral may be
+ returned which conveys the information present in the
+ ContinuationReference. A method of converting a
+ ContinuationReference to an LDAP URL is provided for referrals and
+ intermediate referrals which identify LDAP-enabled DSAs. Methods for
+ converting a ContinuationReference to URIs which identify non-LDAP
+ servers is not provided here, but may be specified in future
+ documents, as long as they can represent the data needed to provide
+ the same level of service.
+
+
+4.9.1 ReturnContinuationReference controls
+
+
+ This control is sent when a client wishes to receive a
+ ContinuationReference in the event that a referral or intermediate
+ referral is being returned. If returned, the ContinuationReference
+ will hold all data but the referralURI field. the referralURI values
+ will be held in the referral or intermediate referral (Referral,
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 27]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ SearchResultReference, etc.).
+
+
+4.9.1.1 ReturnContinuationReference request control
+
+
+ Solicits the return of a ReturnContinuationReference response control
+ on messages consisting of (or carrying) a referral or intermediate
+ referral. The controlType is IANA-ASSIGNED-OID.3, the criticality is
+ set at the sender's discretion, the controlValue is omitted.
+
+
+4.9.1.2 ReturnContinuationReference response control
+
+
+ In response to the ReturnContinuationReference request control, this
+ holds a ContinuationReference for messages consisting of (or
+ carrying) a referral or intermediate referral. The controlType is
+ IANA-ASSIGNED-OID.3, the controlValue is the BER-encoding of a
+ ContinuationReference. Note that the referralURI field is optionally
+ omitted when the ContinuationReference is sent in this control value.
+ In this event, the URI(s) found in the referral or intermediate
+ referral (Referral, SearchContinuationReference, etc.) are to be used
+ in its stead. {TODO: is returining the referralURI outside an
+ unneeded complication?}
+
+
+4.9.2 Converting a ContinuationReference to an LDAP URL
+
+
+ This section details the way in which an LDAP URL (from the referral
+ or intermediate referral) is used to convey the fields of a
+ ContinuationReference. Where existing LDAP URL fields are
+ insufficient, extensions are introduced. Note that further
+ extensions to the ContinuationReference type require further
+ specifications here. {TODO: explain that each ldap url in the
+ continuation refrerence is examined and converted}
+
+
+ These instructions must be applied to each LDAP URL value within the
+ referral or intermediate referral.
+
+
+4.9.2.1 Conveying the target name
+
+
+ If the <dn> part of the LDAP URL is already present, it is determined
+ to be the candidate target object. Otherwise, the candidate target
+ object comes from the ContinuationReference.localReference. Once the
+ candidate target object is determined, the value of
+ ContinuationReference.remainingName is prepended to the candidate
+ target object. This new value becomes the target object and its
+ string value (as specified by <distinguishedName> in [RFC2253]) is
+ placed in the <dn> part of the LDAP URL.
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 28]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+4.9.2.2 ContinuationReference.localReference
+
+
+ This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.4
+ or the descriptor 'localReference', and the exvalue is the string DN
+ encoding (as specified by <distinguishedName> in [RFC2253]) of the
+ ContinuationReference.localReference value.
+
+
+4.9.2.3 ContinuationReference.referenceType
+
+
+ This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.5
+ or the descriptor 'referenceType'. If the
+ ContinuationReference.referenceType is one of superior, subordinate,
+ cross, nonSpecificSubordinate, suplier, master, immediateSuperior, or
+ self, the exvalue 'superior', 'subordinate', 'cross',
+ 'nonSpecificSubordinate', 'suplier', 'master', 'immediateSuperior',
+ or 'self' respectively.
+
+
+4.9.2.4 ContinuationReference.searchScope
+
+
+ If the search scope is one of baseObject, singleLevel, or
+ wholeSubtree, then it may be conveyed in the 'scope' part of the LDAP
+ URL as 'base', 'one', or 'sub' respectively. If the search scope is
+ subordinateSubtree, then it may be conveyed in the <extension> form
+ as documented in [LDAP-SUBORD]. If this extension is present, it
+ MUST be marked critical. This ensures that a receiver which is
+ unaware of this extension uses the proper search scope, or fails to
+ progress the operation.
+
+
+4.9.2.5 ContinuationReference.searchedSubtrees
+
+
+ This field is conveyed as an extension. The extype is
+ IANA-ASSIGNED-OID.6 or the descriptor 'searchedSubtrees', and the
+ exvalue is the ContinuationReference.searchedSubtree value encoded
+ according to the following searchedSubtrees ABNF:
+
+
+ searchedSubtrees = 1*(LANGLE searchedSubtree RANGLE)
+ searchedSubtree = <distinguishedName> from [RFC2253]
+ LANGLE = %x3C ; left angle bracket ("<")
+ RANGLE = %x3E ; right angle bracket (">")
+
+
+ Each searchedSubtree represents one RDNSequence value in the
+ ContinuationReference.searchedSubtree field. An example of a
+ searchedSubtrees value containing two searched subtrees is:
+ <dc=example,dc=com><cn=ralph,dc=users,dc=example,dc=com>.
+
+
+4.9.2.6 ContinuationReference.failedName
+
+
+ This field is conveyed as an extension. The extype is
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 29]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue
+ is the string DN encoding (as specified in [RFC2253]) of the
+ ContinuationReference.failedName value.
+
+
+4.10 Acting on a Referral or Intermediate Referral
+
+
+ When a protocol peer receives a referral or intermediate referral, it
+ may distribute the operation either by sending a ChainedRequest, or
+ by emulating the ChainedRequest. Prior to taking these steps, the
+ protocol peer effectively converts the referral or intermediate
+ referral into a ContinuationReference. Then, acting in the same
+ manner as a DSA would, follows the directions in Section 4.4 if
+ sending a ChainedRequest, or Section 4.5 otherwise.
+
+
+4.10.1 Converting a Referral or Intermediate Referral to a
+ ContinuationReference
+
+
+ A referral or intermediate referral may be converted (or conceptually
+ converted) to a ContinuationReference type in order to follow the
+ distributed operation procedures in Section 4.4, or Section 4.5. The
+ following steps may only be used to convert a referral or
+ intermediate referral containing LDAP URL values. Converting other
+ types of URIs may be specified in future documents as long as the
+ conversion provides the same level of service found here.
+
+
+ o The ContinuationReference.referralURI is populated with all LDAP
+ URL values in the referral or intermediate referral.
+ o The ContinuationReference.localReference populate with the value
+ of the localReference extension value (Section 4.9.2.2) if one
+ exists. Otherwise it is omitted.
+ o The ContinuationReference.referenceType populate with the value of
+ the referenceType extension value (Section 4.9.2.3) if one exists.
+ Otherwise it is omitted.
+ o The ContinuationReference.remainingName is omitted.
+ o The ContinuationReference.searchScope is populated with
+ subordinateSubtree if the subordScope LDAP URL extension
+ [LDAP-SUBORD] is present. If the <scope> field contains te value
+ 'base', 'one', 'sub', or 'subordinates', this filed is populated
+ with baseObject, singleLevel, wholeSubtree, or subordinateSubtree
+ respectively. Otherwise this field is omitted.
+ o The ContinuationReference.searchedSubtrees is populated with any
+ searchedSubtrees LDAP URI extension Section 4.9.2.5 value found on
+ an LDAP URI in the referral or intermediate referral. If none
+ exist, this field is omitted.
+ o The ContinuationReference.failedName is populated with any
+ failedName LDAP URI extension Section 4.9.2.6 value found on an
+ LDAP URI in the referral or intermediate referral. If none exist,
+ this field is omitted.
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 30]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ Note that many fields are simply omitted. This is either because
+ they are conveyed within the LDAP URL values themselves, and
+ subsequent instructions will check for their presence, or because
+ they are not needed (they are redundant or not used in further
+ instructions).
+
+
+4.11 Ensuring non-existence of an entry under an nssr
+
+
+ {TODO: add a huge disclaimer here that says without transactional
+ semantics, you can never be sure that the entry didn't get added.
+ Maybe we should just punt on this and say it's a local matter} In
+ order to ensure there are no entries matching the name of the entry
+ to be added or renamed immediately subordinate to an nssr, these
+ steps may be followed.
+
+
+ If the DSA is able and allowed to chain operations, it may contact
+ each of the DSAs listed as access points in the nssr (in the ref
+ attribute) and using a base-level search operation it will determine
+ whether or not the object to be added exists. Note that access
+ control or other policies may hide the entry from the sending DSA.
+ If the entry does not exist on any of the DSAs listed in the nssr,
+ the operation may progress on the local DSA.
+
+
+ If the DSA cannot make this determination, the operation fails with
+ affectsMultipleDSAs.
+
+
+4.12 Mapping a referralURI to an LDAP URI
+
+
+ As with any URI specification which is intended to be used as a URI
+ which conveys referral information, the LDAP URI specification is
+ given a mapping to the elements of a referralURI as specified in.
+ Section 3.1.1.1. These mappings are given here using the ABNF
+ identifiers given in [RFC2255].
+
+
+ referralURI to LDAP URI mapping:
+
+
+ +---------------------------------+---------------------------------+
+ | referralURI element | LDAP URL element |
+ +---------------------------------+---------------------------------+
+ | protocolIdentifier | <scheme> |
+ | | |
+ | accessPoint | <hostport> |
+ | | |
+ | targetObject | <dn>. This must be encoded as a |
+ | | <distinguishedName> as |
+ | | specified in [RFC2253] |
+ | | |
+ | localReference | LDAP URL localReference |
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 31]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ | | extension as specified in |
+ | | Section 4.9.2.2 |
+ | | |
+ | referenceType | LDAP URL referenceType |
+ | | extension as specified in |
+ | | Section 4.9.2.3 |
+ | | |
+ | searchScope | <scope> or LDAP URL subordScope |
+ | | extension as specified in |
+ | | Section 4.9.2.4 |
+ | | |
+ | searchedSubtrees | LDAP URL searchedSubtrees |
+ | | extension as specified in |
+ | | Section 4.9.2.5 |
+ | | |
+ | failedName | LDAP URL failedName extension |
+ | | as specified in Section 4.9.2.6 |
+ +---------------------------------+---------------------------------+
+
+
+
+ 4.13 Using the ManageDsaIT control
+
+
+ This control, defined in [RFC3296], allows the management of the
+ distributed knowledge information held by a DSA, and thus overrides
+ the determinations made during name resolution and operation
+ evaluation. When this control is attached to an operation, all
+ resolved and acted upon DSEs are treated as being local to the DSA.
+ This is true regardless of the phase the operation is in. Thus
+ referrals are never returned and chaining never occurs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 32]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+5. Security Considerations
+
+
+ This document introduces a mechanism (chaining) which can be used to
+ propagate directory operation requests to servers which may be
+ inaccessible otherwise. Implementers and deployers of this
+ technology should be aware of this and take appropriate steps such
+ that firewall mechanisms are not compromised.
+
+
+ This document introduces the ability to return auxiliary data when
+ returning referrals. Measures should be taken to ensure proper
+ protection of this data.
+
+
+ Implementers must ensure that any specified time, size, and
+ administrative limits are not circumvented due to the mechanisms
+ introduced here.
+
+
+6 Normative References
+
+
+ [LDAP-SUBORD]
+ Sermersheim, J., "Subordinate Subtree Search Scope for
+ LDAP", draft-sermersheim-ldap-subordinate-scope-xx (work
+ in progress), July 2004.
+
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+
+ [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight
+ Directory Access Protocol (LDAP) Directories", RFC 3296,
+ July 2002.
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 33]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+ [RFC3771] Harrison, R. and K. Zeilenga, "The Lightweight Directory
+ Access Protocol (LDAP) Intermediate Response Message", RFC
+ 3771, April 2004.
+
+
+ [X500] International Telephone and Telegraph Consultative
+ Committee, "The Directory - overview of concepts, models
+ and services", ITU-T Recommendation X.500, November 1993.
+
+
+ [X518] International Telephone and Telegraph Consultative
+ Committee, "The Directory - The Directory: Procedures for
+ distributed operation", ITU-T Recommendation X.518,
+ November 1993.
+
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+
+ [X690] International Telecommunications Union, "Information
+ Technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", ITU-T Recommendation
+ X.690, July 2002.
+
+
+
+Author's Address
+
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+
+ Phone: +1 801 861-3088
+ EMail: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 34]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+Appendix A. IANA Considerations
+
+
+ Registration of the following values is requested [RFC3383].
+
+
+A.1 LDAP Object Identifier Registrations
+
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Seven delegations will be made under the assigned OID:
+ IANA-ASSIGNED-OID.1 ChainedRequest LDAP Extended Operation
+ IANA-ASSIGNED-OID.2 Supported Feature: Can Chain Operations
+ IANA-ASSIGNED-OID.3 ReturnContinuationReference LDAP Controls
+ IANA-ASSIGNED-OID.4 localReference: LDAP URL Extension
+ IANA-ASSIGNED-OID.6 searchedSubtree: LDAP URL Extension
+ IANA-ASSIGNED-OID.7 failedName: LDAP URL Extension
+
+
+A.2 LDAP Protocol Mechanism Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration templates are given:
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: ChainedRequest LDAP Extended Operation
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Description: Can Chain Operations Supported Feature
+ Person & email address to contact for further information:
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 35]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Feature
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Description: ReturnContinuationReference LDAP Controls
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Control
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Description: localReference LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Description: referenceType LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.6
+ Description: searchedSubtree LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 36]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.7
+ Description: failedName LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+A.3 LDAP Descriptor Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): localReference
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): referenceType
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): searchedSubtree
+ Object Identifier: IANA-ASSIGNED-OID.6
+ Person & email address to contact for further information:
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 37]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): failedName
+ Object Identifier: IANA-ASSIGNED-OID.7
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+A.4 LDAP Result Code Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ result codes described in this document. The following registration
+ templates are given:
+
+
+ Subject: Request for LDAP Result Code Registration
+ Result Code Name: invalidReference
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 38]
+Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+
+
+
+Intellectual Property Statement
+
+
+ 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.
+
+
+ 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.
+
+
+ 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.
+
+
+
+Disclaimer of Validity
+
+
+ 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 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.
+
+
+
+Copyright Statement
+
+
+ Copyright (C) The Internet Society (2004). 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.
+
+
+
+Acknowledgment
+
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+Sermersheim Expires April 24, 2005 [Page 39]
\ No newline at end of file
projects / openldap / commitdiff