rfc2251.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,487 行 · 第 1/5 页

Wahl, et. al.               Standards Track                    [Page 16]

RFC 2251                         LDAPv3                    December 1997


                             noSuchObject                 (32),
                             aliasProblem                 (33),
                             invalidDNSyntax              (34),
                             -- 35 reserved for undefined isLeaf --
                             aliasDereferencingProblem    (36),
                                        -- 37-47 unused --
                             inappropriateAuthentication  (48),
                             invalidCredentials           (49),
                             insufficientAccessRights     (50),
                             busy                         (51),
                             unavailable                  (52),
                             unwillingToPerform           (53),
                             loopDetect                   (54),
                                        -- 55-63 unused --
                             namingViolation              (64),
                             objectClassViolation         (65),
                             notAllowedOnNonLeaf          (66),
                             notAllowedOnRDN              (67),
                             entryAlreadyExists           (68),
                             objectClassModsProhibited    (69),
                                        -- 70 reserved for CLDAP --
                             affectsMultipleDSAs          (71), -- new
                                        -- 72-79 unused --
                             other                        (80) },
                             -- 81-90 reserved for APIs --
                matchedDN       LDAPDN,
                errorMessage    LDAPString,
                referral        [3] Referral OPTIONAL }

   All the result codes with the exception of success, compareFalse and
   compareTrue are to be treated as meaning the operation could not be
   completed in its entirety.

   Most of the result codes are based on problem indications from X.511
   error data types.  Result codes from 16 to 21 indicate an
   AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
   codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
   indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
   UpdateProblem.

   If a client receives a result code which is not listed above, it is
   to be treated as an unknown error condition.

   The errorMessage field of this construct may, at the server's option,
   be used to return a string containing a textual, human-readable
   (terminal control and page formatting characters should be avoided)
   error diagnostic. As this error diagnostic is not standardized,




Wahl, et. al.               Standards Track                    [Page 17]

RFC 2251                         LDAPv3                    December 1997


   implementations MUST NOT rely on the values returned.  If the server
   chooses not to return a textual diagnostic, the errorMessage field of
   the LDAPResult type MUST contain a zero length string.

   For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
   aliasDereferencingProblem, the matchedDN field is set to the name of
   the lowest entry (object or alias) in the directory that was matched.
   If no aliases were dereferenced while attempting to locate the entry,
   this will be a truncated form of the name provided, or if aliases
   were dereferenced, of the resulting name, as defined in section 12.5
   of X.511 [8]. The matchedDN field is to be set to a zero length
   string with all other result codes.

4.1.11. Referral

   The referral error indicates that the contacted server does not hold
   the target entry of the request.  The referral field is present in an
   LDAPResult if the LDAPResult.resultCode field value is referral, and
   absent with all other result codes.  It contains a reference to
   another server (or set of servers) which may be accessed via LDAP or
   other protocols.  Referrals can be returned in response to any
   operation request (except unbind and abandon which do not have
   responses). At least one URL MUST be present in the Referral.

   The referral is not returned for a singleLevel or wholeSubtree search
   in which the search scope spans multiple naming contexts, and several
   different servers would need to be contacted to complete the
   operation. Instead, continuation references, described in section
   4.5.3, are returned.

        Referral ::= SEQUENCE OF LDAPURL  -- one or more

        LDAPURL ::= LDAPString -- limited to characters permitted in URLs

   If the client wishes to progress the operation, it MUST follow the
   referral by contacting any one of servers.  All the URLs MUST be
   equally capable of being used to progress the operation.  (The
   mechanisms for how this is achieved by multiple servers are outside
   the scope of this document.)

   URLs for servers implementing the LDAP protocol are written according
   to [9].  If an alias was dereferenced, the <dn> part of the URL MUST
   be present, with the new target object name.  If the <dn> part is
   present, the client MUST use this name in its next request to
   progress the operation, and if it is not present the client will use
   the same name as in the original request.  Some servers (e.g.
   participating in distributed indexing) may provide a different filter
   in a referral for a search operation.  If the filter part of the URL



Wahl, et. al.               Standards Track                    [Page 18]

RFC 2251                         LDAPv3                    December 1997


   is present in an LDAPURL, the client MUST use this filter in its next
   request to progress this search, and if it is not present the client
   MUST use the same filter as it used for that search.  Other aspects
   of the new request may be the same or different as the request which
   generated the referral.

   Note that UTF-8 characters appearing in a DN or search filter may not
   be legal for URLs (e.g. spaces) and MUST be escaped using the %
   method in RFC 1738 [7].

   Other kinds of URLs may be returned, so long as the operation could
   be performed using that protocol.

4.1.12. Controls

   A control is a way to specify extension information. Controls which
   are sent as part of a request apply only to that request and are not
   saved.

        Controls ::= SEQUENCE OF Control

        Control ::= SEQUENCE {
                controlType             LDAPOID,
                criticality             BOOLEAN DEFAULT FALSE,
                controlValue            OCTET STRING OPTIONAL }

   The controlType field MUST be a UTF-8 encoded dotted-decimal
   representation of an OBJECT IDENTIFIER which uniquely identifies the
   control.  This prevents conflicts between control names.

   The criticality field is either TRUE or FALSE.

   If the server recognizes the control type and it is appropriate for
   the operation, the server will make use of the control when
   performing the operation.

   If the server does not recognize the control type and the criticality
   field is TRUE, the server MUST NOT perform the operation, and MUST
   instead return the resultCode unsupportedCriticalExtension.

   If the control is not appropriate for the operation and criticality
   field is TRUE, the server MUST NOT perform the operation, and MUST
   instead return the resultCode unsupportedCriticalExtension.

   If the control is unrecognized or inappropriate but the criticality
   field is FALSE, the server MUST ignore the control.





Wahl, et. al.               Standards Track                    [Page 19]

RFC 2251                         LDAPv3                    December 1997


   The controlValue contains any information associated with the
   control, and its format is defined for the control.  The server MUST
   be prepared to handle arbitrary contents of the controlValue octet
   string, including zero bytes.  It is absent only if there is no value
   information which is associated with a control of its type.

   This document does not define any controls.  Controls may be defined
   in other documents.  The definition of a control consists of:

     - the OBJECT IDENTIFIER assigned to the control,

     - whether the control is always noncritical, always critical, or
       critical at the client's option,

     - the format of the controlValue contents of the control.

   Servers list the controls which they recognize in the
   supportedControl attribute in the root DSE.

4.2. Bind Operation

   The function of the Bind Operation is to allow authentication
   information to be exchanged between the client and server.

   The Bind Request is defined as follows:

        BindRequest ::= [APPLICATION 0] SEQUENCE {
                version                 INTEGER (1 .. 127),
                name                    LDAPDN,
                authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 and 2 reserved
                sasl                    [3] SaslCredentials }

        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }

   Parameters of the Bind Request are:

   - version: A version number indicating the version of the protocol to
     be used in this protocol session.  This document describes version
     3 of the LDAP protocol.  Note that there is no version negotiation,
     and the client just sets this parameter to the version it desires.
     If the client requests protocol version 2, a server that supports
     the version 2 protocol as described in [2] will not return any v3-



Wahl, et. al.               Standards Track                    [Page 20]

RFC 2251                         LDAPv3                    December 1997


     specific protocol fields.  (Note that not all LDAP servers will
     support protocol version 2, since they may be unable to generate
     the attribute syntaxes associated with version 2.)

   - name: The name of the directory object that the client wishes to
     bind as.  This field may take on a null value (a zero length
     string) for the purposes of anonymous binds, when authentication
     has been performed at a lower layer, or when using SASL credentials
     with a mechanism that includes the LDAPDN in the credentials.

   - authentication: information used to authenticate the name, if any,
     provided in the Bind Request.

   Upon receipt of a Bind Request, a protocol server will authenticate
   the requesting client, if necessary.  The server will then return a
   Bind Response to the client indicating the status of the
   authentication.

   Authorization is the use of this authentication information when
   performing operations.  Authorization MAY be affected by factors
   outside of the LDAP Bind request, such as lower layer security
   services.

4.2.1. Sequencing of the Bind Request

   For some SASL authentication mechanisms, it may be necessary for the
   client to invoke the BindRequest multiple times.  If at any stage the
   client wishes to abort the bind process it MAY unbind and then drop
   the underlying connection.  Clients MUST NOT invoke operations
   between two Bind requests made as part of a multi-stage bind.

   A client may abort a SASL bind negotiation by sending a BindRequest
   with a different value in the mechanism field of SaslCredentials, or
   an AuthenticationChoice other than sasl.

   If the client sends a BindRequest with the sasl mechanism field as an
   empty string, the server MUST return a BindResponse with
   authMethodNotSupported as the resultCode.  This will allow clients to
   abort a negotiation if it wishes to try again with the same SASL
   mechanism.

   Unlike LDAP v2, the client need not send a Bind Request in the first
   PDU of the connection.  The client may request any operations and the
   server MUST treat these as unauthenticated. If the server requires
   that the client bind before browsing or modifying the directory, the
   server MAY reject a request other than binding, unbinding or an
   extended request with the "operationsError" result.




Wahl, et. al.               Standards Track                    [Page 21]

RFC 2251                         LDAPv3                    December 1997


   If the client did not bind before sending a request and receives an
   operationsError, it may then send a Bind Request.  If this also fails
   or the client chooses not to bind on the existing connection, it will
   close the connection, reopen it and begin again by first sending a
   PDU with a Bind Request.  This will aid in interoperating with
   servers implementing other versions of LDAP.

   Clients MAY send multiple bind requests on a connection to change
   their credentials.  A subsequent bind process has the effect of
   abandoning all operations outstanding on the connection.  (This