rfc4511.txt

samba最新软件

   For certain result codes (typically, but not restricted to
   noSuchObject, aliasProblem, invalidDNSyntax, and
   aliasDereferencingProblem), the matchedDN field is set (subject to
   access controls) to the name of the last entry (object or alias) used
   in finding the target (or base) object.  This will be a truncated
   form of the provided name or, if an alias was dereferenced while
   attempting to locate the entry, of the resulting name.  Otherwise,
   the matchedDN field is empty.

4.1.10.  Referral

   The referral result code indicates that the contacted server cannot
   or will not perform the operation and that one or more other servers
   may be able to.  Reasons for this include:

   - The target entry of the request is not held locally, but the server
     has knowledge of its possible existence elsewhere.

   - The operation is restricted on this server -- perhaps due to a
     read-only copy of an entry to be modified.

   The referral field is present in an LDAPResult if the resultCode is
   set to referral, and it is absent with all other result codes.  It
   contains one or more references to one or more servers or services
   that 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 URI MUST be
   present in the Referral.

   During a Search operation, after the baseObject is located, and
   entries are being evaluated, the referral is not returned.  Instead,
   continuation references, described in Section 4.5.3, are returned
   when other servers would need to be contacted to complete the
   operation.

        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI

        URI ::= LDAPString     -- limited to characters permitted in
                               -- URIs

   If the client wishes to progress the operation, it contacts one of
   the supported services found in the referral.  If multiple URIs are
   present, the client assumes that any supported URI may be used to
   progress the operation.

   Clients that follow referrals MUST ensure that they do not loop
   between servers.  They MUST NOT repeatedly contact the same server
   for the same request with the same parameters.  Some clients use a



Sermersheim                 Standards Track                    [Page 12]

RFC 4511                         LDAPv3                        June 2006


   counter that is incremented each time referral handling occurs for an
   operation, and these kinds of clients MUST be able to handle at least
   ten nested referrals while progressing the operation.

   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
   v6) [RFC793][RFC791] is written as an LDAP URL according to
   [RFC4516].

   Referral values that are LDAP URLs follow these rules:

   - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
     present, with the new target object name.

   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.

   - If the <dn> part is present, the client uses this name in its next
     request to progress the operation, and if it is not present the
     client uses the same name as in the original request.

   - Some servers (e.g., participating in distributed indexing) may
     provide a different filter in a URL of a referral for a Search
     operation.

   - If the <filter> part of the LDAP URL is present, the client uses
     this filter in its next request to progress this Search, and if it
     is not present the client uses the same filter as it used for that
     Search.

   - For Search, it is RECOMMENDED that the <scope> part be present to
     avoid ambiguity.

   - If the <scope> part is missing, the scope of the original Search is
     used by the client to progress the operation.

   - Other aspects of the new request may be the same as or different
     from the request that generated the referral.

   Other kinds of URIs may be returned.  The syntax and semantics of
   such URIs is left to future specifications.  Clients may ignore URIs
   that they do not support.

   UTF-8 encoded characters appearing in the string representation of a
   DN, search filter, or other fields of the referral value may not be
   legal for URIs (e.g., spaces) and MUST be escaped using the % method
   in [RFC3986].






Sermersheim                 Standards Track                    [Page 13]

RFC 4511                         LDAPv3                        June 2006


4.1.11.  Controls

   Controls provide a mechanism whereby the semantics and arguments of
   existing LDAP operations may be extended.  One or more controls may
   be attached to a single LDAP message.  A control only affects the
   semantics of the message it is attached to.

   Controls sent by clients are termed 'request controls', and those
   sent by servers are termed 'response controls'.

        Controls ::= SEQUENCE OF control Control

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

   The controlType field is the dotted-decimal representation of an
   OBJECT IDENTIFIER that uniquely identifies the control.  This
   provides unambiguous naming of controls.  Often, response control(s)
   solicited by a request control share controlType values with the
   request control.

   The criticality field only has meaning in controls attached to
   request messages (except UnbindRequest).  For controls attached to
   response messages and the UnbindRequest, the criticality field SHOULD
   be FALSE, and MUST be ignored by the receiving protocol peer.  A
   value of TRUE indicates that it is unacceptable to perform the
   operation without applying the semantics of the control.
   Specifically, the criticality field is applied as follows:

   - If the server does not recognize the control type, determines that
     it is not appropriate for the operation, or is otherwise unwilling
     to perform the operation with the control, and if the criticality
     field is TRUE, the server MUST NOT perform the operation, and for
     operations that have a response message, it MUST return with the
     resultCode set to unavailableCriticalExtension.

   - If the server does not recognize the control type, determines that
     it is not appropriate for the operation, or is otherwise unwilling
     to perform the operation with the control, and if the criticality
     field is FALSE, the server MUST ignore the control.

   - Regardless of criticality, if a control is applied to an
     operation, it is applied consistently and impartially to the
     entire operation.





Sermersheim                 Standards Track                    [Page 14]

RFC 4511                         LDAPv3                        June 2006


   The controlValue may contain information associated with the
   controlType.  Its format is defined by the specification of the
   control.  Implementations 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 that is associated
   with a control of its type.  When a controlValue is defined in terms
   of ASN.1, and BER-encoded according to Section 5.1, it also follows
   the extensibility rules in Section 4.

   Servers list the controlType of request controls they recognize in
   the 'supportedControl' attribute in the root DSE (Section 5.1 of
   [RFC4512]).

   Controls SHOULD NOT be combined unless the semantics of the
   combination has been specified.  The semantics of control
   combinations, if specified, are generally found in the control
   specification most recently published.  When a combination of
   controls is encountered whose semantics are invalid, not specified
   (or not known), the message is considered not well-formed; thus, the
   operation fails with protocolError.  Controls with a criticality of
   FALSE may be ignored in order to arrive at a valid combination.
   Additionally, unless order-dependent semantics are given in a
   specification, the order of a combination of controls in the SEQUENCE
   is ignored.  Where the order is to be ignored but cannot be ignored
   by the server, the message is considered not well-formed, and the
   operation fails with protocolError.  Again, controls with a
   criticality of FALSE may be ignored in order to arrive at a valid
   combination.

   This document does not specify any controls.  Controls may be
   specified in other documents.  Documents detailing control extensions
   are to provide for each control:

   - the OBJECT IDENTIFIER assigned to the control,

   - direction as to what value the sender should provide for the
     criticality field (note: the semantics of the criticality field are
     defined above should not be altered by the control's
     specification),

   - whether the controlValue field is present, and if so, the format of
     its contents,

   - the semantics of the control, and

   - optionally, semantics regarding the combination of the control with
     other controls.




Sermersheim                 Standards Track                    [Page 15]

RFC 4511                         LDAPv3                        June 2006


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
   operation should be thought of as the "authenticate" operation.
   Operational, authentication, and security-related semantics of this
   operation are given in [RFC4513].

   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 }

   Fields of the BindRequest are:

   - version: A version number indicating the version of the protocol to
     be used at the LDAP message layer.  This document describes version
     3 of the protocol.  There is no version negotiation.  The client
     sets this field to the version it desires.  If the server does not
     support the specified version, it MUST respond with a BindResponse
     where the resultCode is set to protocolError.

   - name: If not empty, 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 ([RFC4513],
     Section 5.1) or when using SASL [RFC4422] authentication
     ([RFC4513], Section 5.2).  Where the server attempts to locate the
     named object, it SHALL NOT perform alias dereferencing.

   - authentication: Information used in authentication.  This type is
     extensible as defined in Section 3.7 of [RFC4520].  Servers that do
     not support a choice supplied by a client return a BindResponse
     with the resultCode set to authMethodNotSupported.






Sermersheim                 Standards Track                    [Page 16]

RFC 4511                         LDAPv3                        June 2006


     Textual passwords (consisting of a character sequence with a known
     character set and encoding) transferred to the server using the
     simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
     encoded [Unicode].  Prior to transfer, clients SHOULD prepare text
     passwords as "query" strings by applying the SASLprep [RFC4013]
     profile of the stringprep [RFC3454] algorithm.  Passwords
     consisting of other data (such as random octets) MUST NOT be
     altered.  The determination of whether a password is textual is a
     local client matter.

4.2.1.  Processing of the Bind Request

   Before processing a BindRequest, all uncompleted operations MUST
   either complete or be abandoned.  The server may either wait for the
   uncompleted operations to complete, or abandon them.  The server then
   proceeds to authenticate the client in either a single-step or
   multi-step Bind process.  Each step requires the server to return a
   BindResponse to indicate the status of authentication.

   After sending a BindRequest, clients MUST NOT send further LDAP PDUs
   until receiving the BindResponse.  Similarly, servers SHOULD NOT
   process or respond to requests received while processing a
   BindRequest.

   If the client did not bind before sending a request and receives an
   operationsError to that request, it may then send a BindRequest.  If
   this also fails or the client chooses not to bind on the existing
   LDAP session, it may terminate the LDAP session, re-establish it, and
   begin again by first sending a BindRequest.  This will aid in
   interoperating with servers implementing other versions of LDAP.