rfc3296.txt

samba最新软件


RFC 3296    Named Subordinate References in LDAP Directories   July 2002


   Example: If the client issues an add request where the target object
      has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
      return:

         AddResponse (referral) {
             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
         }

      Note that the DN part of the LDAP URL is modified such that it
      refers to the appropriate entry in the referenced server.

5.3.  Base Object Considerations

   This section details referral handling for base object processing
   within search operations.  Like target object considerations for
   non-search operations, there are the four cases.

   In cases where the URI to be returned is a LDAP URL, the server MUST
   provide an explicit scope specifier from the LDAP URL prior to
   returning it.  In addition, the DN part MUST be modified such that it
   refers to the appropriate target in the referenced server (as
   detailed below).

   If aliasing dereferencing was necessary in finding the referral
   object, the DN part of the URI MUST be replaced with the base DN as
   modified by the alias dereferencing such that the return URL refers
   to the new target object per [RFC2251, 4.1.11].

   Critical extensions MUST NOT be trimmed nor modified.

   Case 1: The base object is not held by the server and is not within
      nor subordinate to any naming context held by the server.

      The server SHOULD process the request normally as appropriate for
      a non-existent base which not within any naming context of the
      server (generally return a superior referral or noSuchObject).
      This document does not detail management or processing of superior
      knowledge references.

   Case 2: The base object is held by the server and is a referral
      object.

      The server SHOULD return the URI value contained in the ref
      attribute of the referral object appropriately modified as
      described above.






Zeilenga                    Standards Track                     [Page 8]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


   Example: If the client issues a subtree search in which the base
      object is "OU=Roles,O=MNN,C=WW", the server will return

         SearchResultDone (referral) {
             ldap://hostd/OU=Roles,O=MNN,C=WW??sub
         }

      If the client were to issue a base or oneLevel search instead of
      subtree, the returned LDAP URL would explicitly specify "base" or
      "one", respectively, instead of "sub".

   Case 3: The base object is not held by the server, but the nearest
      naming context contains no referral object which the base object
      is subordinate to.

      If the nearest naming context contains no referral object which
      the base is subordinate to, the request SHOULD be processed
      normally as appropriate for a nonexistent base (generally return
      noSuchObject).

   Case 4: The base object is not held by the server, but the nearest
      naming context contains a referral object which the base object is
      subordinate to.

      If a client requests an operation for which the target object is
      not held by the server and the nearest naming context contains a
      referral object which the target object is subordinate to, the
      server SHOULD return a referral response which is constructed from
      the URI portion of the ref value of the referral object.

   Example: If the client issues a base search request for
      "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return

         SearchResultDone (referral) {
             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
         }

      If the client were to issue a subtree or oneLevel search instead
      of subtree, the returned LDAP URL would explicitly specify "sub"
      or "one", respectively, instead of "base".

      Note that the DN part of the LDAP URL is modified such that it
      refers to the appropriate entry in the referenced server.








Zeilenga                    Standards Track                     [Page 9]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


5.4.  Search Continuation Considerations

   For search operations, once the base object has been found and
   determined not to be a referral object, the search may progress.  Any
   entry matching the filter and scope of the search which is not a
   referral object is returned to the client normally as described in
   [RFC2251].

   For each referral object within the requested scope, regardless of
   the search filter, the server SHOULD return a SearchResultReference
   which is constructed from the URI component of values of the ref
   attribute.  If the URI component is not a LDAP URL, it should be
   returned as is.  If the LDAP URL's DN part is absent or empty, the DN
   part must be modified to contain the DN of the referral object.  If
   the URI component is a LDAP URL, the URI SHOULD be modified to add an
   explicit scope specifier.

   Subtree Example:

      If a client requests a subtree search of "O=MNN,C=WW", then in
      addition to any entries within scope which match the filter, hosta
      will also return two search references as the two referral objects
      are within scope.  One possible response might be:

          SearchEntry for O=MNN,C=WW
          SearchResultReference {
              ldap://hostb/OU=People,O=MNN,C=WW??sub
              ldap://hostc/OU=People,O=MNN,C=WW??sub
          }
          SearchEntry for CN=Manager,O=MNN,C=WW
          SearchResultReference {
              ldap://hostd/OU=Roles,O=MNN,C=WW??sub
          }
          SearchResultDone (success)

   One Level Example:

      If a client requests a one level search of "O=MNN,C=WW" then, in
      addition to any entries one level below the "O=MNN,C=WW" entry
      matching the filter, the server will also return two search
      references as the two referral objects are within scope.  One
      possible sequence is shown:









Zeilenga                    Standards Track                    [Page 10]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


          SearchResultReference {
              ldap://hostb/OU=People,O=MNN,C=WW??base
              ldap://hostc/OU=People,O=MNN,C=WW??base
          }
          SearchEntry for CN=Manager,O=MNN,C=WW
          SearchResultReference {
              ldap://hostd/OU=Roles,O=MNN,C=WW??base
          }
          SearchResultDone (success)

   Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
      URLs returned with the SearchResultReference messages contain, as
      required by this specification, an explicit scope specifier.

5.6.  Other Considerations

   This section details processing considerations for other operations.

5.6.1 Bind

   Servers SHOULD NOT return referral result code if the bind name (or
   authentication identity or authorization identity) is (or is
   subordinate to) a referral object but MAY use the knowledge
   information to process the bind request (such as in support a future
   distributed operation specification).  Where the server makes no use
   of the knowledge information, the server processes the request
   normally as appropriate for a non-existent authentication or
   authorization identity (e.g., return invalidCredentials).

5.6.2 Modify DN

   If the newSuperior is a referral object or is subordinate to a
   referral object, the server SHOULD return affectsMultipleDSAs.  If
   the newRDN already exists but is a referral object, the server SHOULD
   return affectsMultipleDSAs instead of entryAlreadyExists.

6.  Security Considerations

   This document defines mechanisms that can be used to tie LDAP (and
   other) servers together.  The information used to tie services
   together should be protected from unauthorized modification.  If the
   server topology information is not public information, it should be
   protected from unauthorized disclosure as well.








Zeilenga                    Standards Track                    [Page 11]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


7.  Acknowledgments

   This document borrows heavily from previous work by IETF LDAPext
   Working Group.  In particular, this document is based upon "Named
   Referral in LDAP Directories" (an expired Internet Draft) by
   Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
   Mark Wahl.

8. Normative References

   [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.

   [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
             "Lightweight Directory Access Protocol (v3): Attribute
             Syntax Definitions", RFC 2252, 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.

   [X.501]   ITU-T, "The Directory: Models", X.501, 1993.

9. Informative References

   [X.500]   ITU-T, "The Directory: Overview of Concepts, Models, and
             Services", X.500, 1993.

   [X.511]   ITU-T, "The Directory: Abstract Service Definition", X.500,
             1997.







Zeilenga                    Standards Track                    [Page 12]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


10.  Author's Address

   Kurt D. Zeilenga
   OpenLDAP Foundation

   EMail: [e-mail]













































Zeilenga                    Standards Track                    [Page 13]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Zeilenga                    Standards Track                    [Page 14]