Skip to main content

5. Bind Operation

The Bind operation ([RFC4511], Section 4.2) allows authentication information to be exchanged between the client and server to establish a new authorization state.

The Bind request typically specifies the desired authentication identity. Some Bind mechanisms also allow the client to specify the authorization identity. If the authorization identity is not specified, the server derives it from the authentication identity in an implementation-specific manner.

If the authorization identity is specified, the server MUST verify that the client's authentication identity is permitted to assume (e.g., proxy for) the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized.

5.1. Simple Authentication Method​

The simple authentication method of the Bind Operation provides three authentication mechanisms:

  - An anonymous authentication mechanism (Section 5.1.1).

  - An unauthenticated authentication mechanism (Section 5.1.2).

  - A name/password authentication mechanism using credentials
    consisting of a name (in the form of an LDAP distinguished name
    [RFC4514]) and a password (Section 5.1.3).

5.1.1. Anonymous Authentication Mechanism of Simple Bind​

An LDAP client may use the anonymous authentication mechanism of the simple Bind method to explicitly establish an anonymous authorization state by sending a Bind request with a name value of zero length and specifying the simple authentication choice containing a password value of zero length.

5.1.2. Unauthenticated Authentication Mechanism of Simple Bind​

An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing a password value of zero length.

The distinguished name value provided by the client is intended to be used for trace (e.g., logging) purposes only. The value is not to be authenticated or otherwise validated (including verification that the DN refers to an existing directory object). The value is not to be used (directly or indirectly) for authorization purposes.

Unauthenticated Bind operations can have significant security issues (see Section 6.3.1). In particular, users intending to perform Name/Password Authentication may inadvertently provide an empty password and thus cause poorly implemented clients to request Unauthenticated access. Clients SHOULD be implemented to require user selection of the Unauthenticated Authentication Mechanism by means other than user input of an empty password. Clients SHOULD disallow an empty password input to a Name/Password Authentication user interface. Additionally, Servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform.

5.1.3. Name/Password Authentication Mechanism of Simple Bind​

An LDAP client may use the name/password authentication mechanism of the simple Bind method to establish an authenticated authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and specifying the simple authentication choice containing an OCTET STRING password value of non-zero length.

Servers that map the DN sent in the Bind request to a directory entry with an associated set of one or more passwords used with this mechanism will compare the presented password to that set of passwords. The presented password is considered valid if it matches any member of this set.

A resultCode of invalidDNSyntax indicates that the DN sent in the name value is syntactically invalid. A resultCode of invalidCredentials indicates that the DN is syntactically correct but not valid for purposes of authentication, that the password is not valid for the DN, or that the server otherwise considers the credentials invalid. A resultCode of success indicates that the credentials are valid and that the server is willing to provide service to the entity these credentials identify.

Server behavior is undefined for Bind requests specifying the name/password authentication mechanism with a zero-length name value and a password value of non-zero length.

The name/password authentication mechanism of the simple Bind method is not suitable for authentication in environments without confidentiality protection.

5.2. SASL Authentication Method​

The sasl authentication method of the Bind Operation provides facilities for using any SASL mechanism including authentication mechanisms and other services (e.g., data security services).

5.2.1. SASL Protocol Profile​

LDAP allows authentication via any SASL mechanism [RFC4422]. As LDAP includes native anonymous and name/password (plain text) authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN] SASL mechanisms are typically not used with LDAP.

Each protocol that utilizes SASL services is required to supply certain information profiling the way they are exposed through the protocol ([RFC4422], Section 4). This section explains how each of these profiling requirements is met by LDAP.

5.2.1.1. SASL Service Name for LDAP​

The SASL service name for LDAP is "ldap", which has been registered with the IANA as a SASL service name.

5.2.1.2. SASL Authentication Initiation and Protocol Exchange​

SASL authentication is initiated via a BindRequest message ([RFC4511], Section 4.2) with the following parameters:

  - The version is 3.
  - The AuthenticationChoice is sasl.
  - The mechanism element of the SaslCredentials sequence contains
    the value of the desired SASL mechanism.
  - The optional credentials field of the SaslCredentials sequence
    MAY be used to provide an initial client response for mechanisms
    that are defined to have the client send data first (see
    [RFC4422], Sections 3 and 5).

In general, a SASL authentication protocol exchange consists of a series of server challenges and client responses, the contents of which are specific to and defined by the SASL mechanism. Thus, for some SASL authentication mechanisms, it may be necessary for the client to respond to one or more server challenges by sending BindRequest messages multiple times. A challenge is indicated by the server sending a BindResponse message with the resultCode set to

saslBindInProgress. This indicates that the server requires the client to send a new BindRequest message with the same SASL mechanism to continue the authentication process.

To the LDAP message layer, these challenges and responses are opaque binary tokens of arbitrary length. LDAP servers use the serverSaslCreds field (an OCTET STRING) in a BindResponse message to transmit each challenge. LDAP clients use the credentials field (an OCTET STRING) in the SaslCredentials sequence of a BindRequest message to transmit each response. Note that unlike some Internet protocols where SASL is used, LDAP is not text based and does not Base64-transform these challenge and response values.

Clients sending a BindRequest message with the sasl choice selected SHOULD send a zero-length value in the name field. Servers receiving a BindRequest message with the sasl choice selected SHALL ignore any value in the name field.

A client may abort a SASL Bind negotiation by sending a BindRequest message with a different value in the mechanism field of SaslCredentials or with 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 a resultCode of authMethodNotSupported. This will allow the client to abort a negotiation if it wishes to try again with the same SASL mechanism.

The server indicates completion of the SASL challenge-response exchange by responding with a BindResponse in which the resultCode value is not saslBindInProgress.

The serverSaslCreds field in the BindResponse can be used to include an optional challenge with a success notification for mechanisms that are defined to have the server send additional data along with the indication of successful completion.

5.2.1.3. Optional Fields​

As discussed above, LDAP provides an optional field for carrying an initial response in the message initiating the SASL exchange and provides an optional field for carrying additional data in the message indicating the outcome of the authentication exchange. As the mechanism-specific content in these fields may be zero length, SASL requires protocol specifications to detail how an empty field is distinguished from an absent field.

Zero-length initial response data is distinguished from no initial response data in the initiating message, a BindRequest PDU, by the presence of the SaslCredentials.credentials OCTET STRING (of length zero) in that PDU. If the client does not intend to send an initial response with the BindRequest initiating the SASL exchange, it MUST omit the SaslCredentials.credentials OCTET STRING (rather than include an zero-length OCTET STRING).

Zero-length additional data is distinguished from no additional response data in the outcome message, a BindResponse PDU, by the presence of the serverSaslCreds OCTET STRING (of length zero) in that PDU. If a server does not intend to send additional data in the BindResponse message indicating outcome of the exchange, the server SHALL omit the serverSaslCreds OCTET STRING (rather than including a zero-length OCTET STRING).

5.2.1.4. Octet Where Negotiated Security Layers Take Effect​

SASL layers take effect following the transmission by the server and reception by the client of the final BindResponse in the SASL exchange with a resultCode of success.

Once a SASL layer providing data integrity or confidentiality services takes effect, the layer remains in effect until a new layer is installed (i.e., at the first octet following the final BindResponse of the Bind operation that caused the new layer to take effect). Thus, an established SASL layer is not affected by a failed or non-SASL Bind.

5.2.1.5. Determination of Supported SASL Mechanisms​

Clients may determine the SASL mechanisms a server supports by reading the 'supportedSASLMechanisms' attribute from the root DSE (DSA-Specific Entry) ([RFC4512], Section 5.1). The values of this attribute, if any, list the mechanisms the server supports in the current LDAP session state. LDAP servers SHOULD allow all clients -- even those with an anonymous authorization -- to retrieve the 'supportedSASLMechanisms' attribute of the root DSE both before and after the SASL authentication exchange. The purpose of the latter is to allow the client to detect possible downgrade attacks (see Section 6.4 and [RFC4422], Section 6.1.2).

Because SASL mechanisms provide critical security functions, clients and servers should be configurable to specify what mechanisms are acceptable and allow only those mechanisms to be used. Both clients and servers must confirm that the negotiated security level meets their requirements before proceeding to use the session.

5.2.1.6. Rules for Using SASL Layers​

Upon installing a SASL layer, the client SHOULD discard or refresh all information about the server that it obtained prior to the initiation of the SASL negotiation and that it did not obtain through secure mechanisms.

If a lower-level security layer (such as TLS) is installed, any SASL layer SHALL be layered on top of such security layers regardless of the order of their negotiation. In all other respects, the SASL layer and other security layers act independently, e.g., if both a TLS layer and a SASL layer are in effect, then removing the TLS layer does not affect the continuing service of the SASL layer.

5.2.1.7. Support for Multiple Authentications​

LDAP supports multiple SASL authentications as defined in [RFC4422], Section 4.

5.2.1.8. SASL Authorization Identities​

Some SASL mechanisms allow clients to request a desired authorization identity for the LDAP session ([RFC4422], Section 3.4). The decision to allow or disallow the current authentication identity to have access to the requested authorization identity is a matter of local policy. The authorization identity is a string of UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the following Augmented Backus-Naur Form (ABNF) [RFC4234] grammar:

  authzId = dnAuthzId / uAuthzId

  ; distinguished-name-based authz id
  dnAuthzId =  "dn:" distinguishedName

  ; unspecified authorization id, UTF-8 encoded
  uAuthzId = "u:" userid
  userid = *UTF8 ; syntax unspecified

where the distinguishedName rule is defined in Section 3 of [RFC4514] and the UTF8 rule is defined in Section 1.4 of [RFC4512].

The dnAuthzId choice is used to assert authorization identities in the form of a distinguished name to be matched in accordance with the distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15). There is no requirement that the asserted distinguishedName value be that of an entry in the directory.

The uAuthzId choice allows clients to assert an authorization identity that is not in distinguished name form. The format of userid is defined only as a sequence of UTF-8 [RFC3629] encoded [Unicode] characters, and any further interpretation is a local matter. For example, the userid could identify a user of a specific directory service, be a login name, or be an email address. A uAuthzId SHOULD NOT be assumed to be globally unique. To compare uAuthzId values, each uAuthzId value MUST be prepared as a "query" string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm, and then the two values are compared octet-wise.

The above grammar is extensible. The authzId production may be extended to support additional forms of identities. Each form is distinguished by its unique prefix (see Section 3.12 of [RFC4520] for registration requirements).

5.2.2. SASL Semantics within LDAP​

Implementers must take care to maintain the semantics of SASL specifications when handling data that has different semantics in the LDAP protocol.

For example, the SASL DIGEST-MD5 authentication mechanism [DIGEST-MD5] utilizes an authentication identity and a realm that are syntactically simple strings and semantically simple username [RFC4013] and realm values. These values are not LDAP DNs, and there is no requirement that they be represented or treated as such.

5.2.3. SASL EXTERNAL Authentication Mechanism​

A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism to request the LDAP server to authenticate and establish a resulting authorization identity using security credentials exchanged by a lower security layer (such as by TLS authentication). If the client's authentication credentials have not been established at a lower security layer, the SASL EXTERNAL Bind MUST fail with a resultCode of inappropriateAuthentication. Although this situation has the effect of leaving the LDAP session in an anonymous state (Section 4), the state of any installed security layer is unaffected.

A client may either request that its authorization identity be automatically derived from its authentication credentials exchanged at a lower security layer, or it may explicitly provide a desired authorization identity. The former is known as an implicit assertion, and the latter as an explicit assertion.

5.2.3.1. Implicit Assertion​

An implicit authorization identity assertion is performed by invoking a Bind request of the SASL form using the EXTERNAL mechanism name that does not include the optional credentials field (found within the SaslCredentials sequence in the BindRequest). The server will derive the client's authorization identity from the authentication identity supplied by a security layer (e.g., a public key certificate used during TLS layer installation) according to local policy. The underlying mechanics of how this is accomplished are implementation specific.

5.2.3.2. Explicit Assertion​

An explicit authorization identity assertion is performed by invoking a Bind request of the SASL form using the EXTERNAL mechanism name that includes the credentials field (found within the SaslCredentials sequence in the BindRequest). The value of the credentials field (an OCTET STRING) is the asserted authorization identity and MUST be constructed as documented in Section 5.2.1.8.