rfc2251.txt

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

   simplifies server implementation.)  Authentication from earlier binds
   are subsequently ignored, and so if the bind fails, the connection
   will be treated as anonymous. If a SASL transfer encryption or
   integrity mechanism has been negotiated, and that mechanism does not
   support the changing of credentials from one identity to another,
   then the client MUST instead establish a new connection.

4.2.2. Authentication and Other Security Services

   The simple authentication option provides minimal authentication
   facilities, with the contents of the authentication field consisting
   only of a cleartext password.  Note that the use of cleartext
   passwords is not recommended over open networks when there is no
   authentication or encryption being performed by a lower layer; see
   the "Security Considerations" section.

   If no authentication is to be performed, then the simple
   authentication option MUST be chosen, and the password be of zero
   length.  (This is often done by LDAPv2 clients.)  Typically the DN is
   also of zero length.

   The sasl choice allows for any mechanism defined for use with SASL
   [12].  The mechanism field contains the name of the mechanism.  The
   credentials field contains the arbitrary data used for
   authentication, inside an OCTET STRING wrapper.  Note that unlike
   some Internet application protocols where SASL is used, LDAP is not
   text-based, thus no base64 transformations are performed on the
   credentials.

   If any SASL-based integrity or confidentiality services are enabled,
   they take effect following the transmission by the server and
   reception by the client of the final BindResponse with resultCode
   success.

   The client can request that the server use authentication information
   from a lower layer protocol by using the SASL EXTERNAL mechanism.





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


4.2.3. Bind Response

   The Bind Response is defined as follows.

        BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

    BindResponse consists simply of an indication from the server of he
   status of the client's request for authentication.

   f the bind was successful, the resultCode will be success, therwise
   it will be one of:

   - operationsError: server encountered an internal error,

   - protocolError: unrecognized version number or incorrect PDU
     structure,

   - authMethodNotSupported: unrecognized SASL mechanism name,

   - strongAuthRequired: the server requires authentication be
     performed with a SASL mechanism,

   - referral: this server cannot accept this bind and the client
     should try another,

   - saslBindInProgress: the server requires the client to send a
     new bind request, with the same sasl mechanism, to continue the
     authentication process,

   - inappropriateAuthentication: the server requires the client
     which had attempted to bind anonymously or without supplying
     credentials to provide some form of credentials,

   - invalidCredentials: the wrong password was supplied or the SASL
     credentials could not be processed,

   - unavailable: the server is shutting down.

   If the server does not support the client's requested protocol
   version, it MUST set the resultCode to protocolError.

   If the client receives a BindResponse response where the resultCode
   was protocolError, it MUST close the connection as the server will be
   unwilling to accept further operations.  (This is for compatibility
   with earlier versions of LDAP, in which the bind was always the first
   operation, and there was no negotiation.)



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


   The serverSaslCreds are used as part of a SASL-defined bind mechanism
   to allow the client to authenticate the server to which it is
   communicating, or to perform "challenge-response" authentication. If
   the client bound with the password choice, or the SASL mechanism does
   not require the server to return information to the client, then this
   field is not to be included in the result.

4.3. Unbind Operation

   The function of the Unbind Operation is to terminate a protocol
   session.  The Unbind Operation is defined as follows:

        UnbindRequest ::= [APPLICATION 2] NULL

   The Unbind Operation has no response defined. Upon transmission of an
   UnbindRequest, a protocol client may assume that the protocol session
   is terminated. Upon receipt of an UnbindRequest, a protocol server
   may assume that the requesting client has terminated the session and
   that all outstanding requests may be discarded, and may close the
   connection.

4.4. Unsolicited Notification

   An unsolicited notification is an LDAPMessage sent from the server to
   the client which is not in response to any LDAPMessage received by
   the server. It is used to signal an extraordinary condition in the
   server or in the connection between the client and the server.  The
   notification is of an advisory nature, and the server will not expect
   any response to be returned from the client.

   The unsolicited notification is structured as an LDAPMessage in which
   the messageID is 0 and protocolOp is of the extendedResp form.  The
   responseName field of the ExtendedResponse is present. The LDAPOID
   value MUST be unique for this notification, and not be used in any
   other situation.

   One unsolicited notification is defined in this document.

4.4.1. Notice of Disconnection

   This notification may be used by the server to advise the client that
   the server is about to close the connection due to an error
   condition.  Note that this notification is NOT a response to an
   unbind requested by the client: the server MUST follow the procedures
   of section 4.3. This notification is intended to assist clients in
   distinguishing between an error condition and a transient network





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


   failure.  As with a connection close due to network failure, the
   client MUST NOT assume that any outstanding requests which modified
   the directory have succeeded or failed.

   The responseName is 1.3.6.1.4.1.1466.20036, the response field is
   absent, and the resultCode is used to indicate the reason for the
   disconnection.

   The following resultCode values are to be used in this notification:

   - protocolError: The server has received data from the client in
   which
     the LDAPMessage structure could not be parsed.

   - strongAuthRequired: The server has detected that an established
     underlying security association protecting communication between
     the client and server has unexpectedly failed or been compromised.

   - unavailable: This server will stop accepting new connections and
     operations on all existing connections, and be unavailable for an
     extended period of time.  The client may make use of an alternative
     server.

   After sending this notice, the server MUST close the connection.
   After receiving this notice, the client MUST NOT transmit any further
   on the connection, and may abruptly close the connection.

4.5. Search Operation

   The Search Operation allows a client to request that a search be
   performed on its behalf by a server.  This can be used to read
   attributes from a single entry, from entries immediately below a
   particular entry, or a whole subtree of entries.

4.5.1. Search Request

   The Search Request is defined as follows:

        SearchRequest ::= [APPLICATION 3] SEQUENCE {
                baseObject      LDAPDN,
                scope           ENUMERATED {
                        baseObject              (0),
                        singleLevel             (1),
                        wholeSubtree            (2) },
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),
                        derefInSearching        (1),
                        derefFindingBaseObj     (2),



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


                        derefAlways             (3) },
                sizeLimit       INTEGER (0 .. maxInt),
                timeLimit       INTEGER (0 .. maxInt),
                typesOnly       BOOLEAN,
                filter          Filter,
                attributes      AttributeDescriptionList }

        Filter ::= CHOICE {
                and             [0] SET OF Filter,
                or              [1] SET OF Filter,
                not             [2] Filter,
                equalityMatch   [3] AttributeValueAssertion,
                substrings      [4] SubstringFilter,
                greaterOrEqual  [5] AttributeValueAssertion,
                lessOrEqual     [6] AttributeValueAssertion,
                present         [7] AttributeDescription,
                approxMatch     [8] AttributeValueAssertion,
                extensibleMatch [9] MatchingRuleAssertion }

        SubstringFilter ::= SEQUENCE {
                type            AttributeDescription,
                -- at least one must be present
                substrings      SEQUENCE OF CHOICE {
                        initial [0] LDAPString,
                        any     [1] LDAPString,
                        final   [2] LDAPString } }

        MatchingRuleAssertion ::= SEQUENCE {
                matchingRule    [1] MatchingRuleId OPTIONAL,
                type            [2] AttributeDescription OPTIONAL,
                matchValue      [3] AssertionValue,
                dnAttributes    [4] BOOLEAN DEFAULT FALSE }

   Parameters of the Search Request are:

   - baseObject: An LDAPDN that is the base object entry relative to
     which the search is to be performed.

   - scope: An indicator of the scope of the search to be performed. The
     semantics of the possible values of this field are identical to the
     semantics of the scope field in the X.511 Search Operation.

   - derefAliases: An indicator as to how alias objects (as defined in
     X.501) are to be handled in searching.  The semantics of the
     possible values of this field are:

             neverDerefAliases: do not dereference aliases in searching
             or in locating the base object of the search;



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


             derefInSearching: dereference aliases in subordinates of
             the base object in searching, but not in locating the
             base object of the search;

             derefFindingBaseObj: dereference aliases in locating
             the base object of the search, but not when searching
             subordinates of the base object;

             derefAlways: dereference aliases both in searching and in
             locating the base object of the search.

   - sizelimit: A sizelimit that restricts the maximum number of entries
     to be returned as a result of the search. A value of 0 in this
     field indicates that no client-requested sizelimit restrictions are
     in effect for the search.  Servers may enforce a maximum number of
     entries to return.

   - timelimit: A timelimit that restricts the maximum time (in seconds)
     allowed for a search. A value of 0 in this field indicates that no
     client-requested timelimit restrictions are in effect for the
     search.

   - typesOnly: An indicator as to whether search results will contain
     both attribute types and values, or just attribute types.  Setting
     this field to TRUE causes only attribute types (no values)