How Authentication Works

This section identifies which authentication methods are available. This section also describes how Directory Server handles authentication to identify clients. Consider the Directory Server model described in this section when writing plug-ins to modify the mechanism.

Support for Standard Methods

Directory Server supports the two authentication methods described in RFC 4511. One method is simple authentication, which is rendered more secure through the use of Secure Socket Layer (SSL) for transport. The other method is SASL, whose technology is further described in RFC 2222, Simple Authentication and Security Layer (SASL). Through SASL, Directory Server supports Kerberos authentication to the LDAP server and the Directory System Agent (DSA, an X.500 term) as described in RFC 1777, Lightweight Directory Access Protocol.

Client Identification During the Bind

For LDAP clients, Directory Server keeps track of client identity through the DN the client used to connect. The server also keeps track through the authentication method and external credentials that the client uses to connect. The parameter block holds the relevant client connection information. The DN can be accessed through the SLAPI_CONN_DN and SLAPI_CONN_AUTHTYPE parameters to slapi_pblock_set() and slapi_pblock_get().

For DSML clients that connect over HTTP, Directory Server performs identity mapping for the bind. As a result, plug-ins have the same view of the client bind, regardless of the front—end protocol.

Bind Processing in Directory Server

Before Directory Server calls a preoperation bind plug-in, Directory Server completes authentication for anonymous binds, binds by the Directory Manager, and binds by replication users before calling preoperation bind functions. Thus, the server completes the bind without calling the plug-in.

For SASL authentication mechanisms, preoperation and postoperation bind functions can be called several times during processing of a single authentication request.

In fact, multiple LDAP bind operations can be used to implement the authentication mechanism, as is the case for DIGEST-MD5, for example.

How Directory Server Processes the Bind

To process the bind, Directory Server, does the following:

1. Parses the bind request

2. Determines the authentication method

3. Determines whether the bind DN is handled locally

4. Adds request information to the parameter block

5. Determines whether to handle the bind in the front end or to call preoperation bind plug-in functions

6. Performs the bind or not, using information about the bind DN entry from the server back end

Following is a description of each action:

• Parsing the bind request. When a bind request arrives, Directory Server retrieves the DN, the authentication method used, and any credentials sent, such as a password. The processing can involve a mapping if the client accesses the server by using DSML over HTTP. If the request calls for SASL authentication, LDAP_AUTH_SASL, Directory Server retrieves the SASL mechanism. Next, Directory Server normalizes the DN that is retrieved from the request. The server also retrieves any LDAP v3 controls that are included in the request.

• Determining the authentication method. In some cases, the method is simple authentication, but the DN or credentials are empty or missing. Directory Server then assumes that the client is binding anonymously, sets SLAPI_CONN_DN to NULL and SLAPI_CONN_AUTHTYPE to SLAPD_AUTH_NONE, and sends an LDAP_SUCCESS result to the client. If the method is SASL authentication, Directory Server first determines whether the mechanism is supported. If not, the server sends an LDAP_AUTH_METHOD_NOT_SUPPORTED result to the client.

• Determining whether the DN is handled locally. If the DN is not stored in the local instance, but Directory Server refers clients by default, the server sends the client an LDAP_REFERRAL result. Otherwise, the server sends an LDAP_NO_SUCH_OBJECT result to the client.

• Adding request information to the parameter block.Directory Server puts bind request information into the parameter block:

  • SLAPI_BIND_TARGET to the DN retrieved from the request

  • SLAPI_BIND_METHOD to the authentication method requested

  • SLAPI_BIND_CREDENTIALS to the credentials retrieved from the request

  • SLAPI_BIND_MECHANISM to the name of the SASL mechanism, if applicable

• Determining whether to handle the Bind or call a plug-in.Directory Server authenticates bind requests from the directory superuser or the replication manager, sending an LDAP_SUCCESS result on success or an LDAP_INVALID_CREDENTIALS result on failure.

  After completing all this work, the server calls preoperation bind functions.

  Directory Server does not call preoperation bind functions for bind requests from the directory manager, the replication manager, nor for anonymous binds.

• Performing the back-end bind.When preoperation bind functions return 0, Directory Server completes the bind operation. The server checks the bind against the information in the directory database. The server then sets SLAPI_CONN_DN and SLAPI_CONN_AUTHTYPE appropriately. If necessary, Directory Server sends password-related result controls to the client. The server always sends an LDAP_SUCCESS result on success or a non zero result on failure.