These routines provide various interfaces to the LDAP bind operation.
After an association with an LDAP server is made using ldap_init(3),
an LDAP bind operation should be performed before other operations
are attempted over the connection. An LDAP bind is required when
using Version 2 of the LDAP protocol; it is optional for Version 3
but is usually needed due to security considerations.
There are three types of bind calls, ones providing simple
authentication, ones providing SASL authentication, and general
routines capable of doing either simple or SASL authentication.
SASL (Simple Authentication and Security Layer) can negotiate one of
many different kinds of authentication. Both synchronous and
asynchronous versions of each variant of the bind call are provided.
All routines take ld as their first parameter, as returned from
The simplest form of the bind call is ldap_simple_bind_s(). It takes
the DN to bind as in who, and the userPassword associated with the
entry in passwd. It returns an LDAP error indication (see
ldap_error(3)). The ldap_simple_bind() call is asynchronous, taking
the same parameters but only initiating the bind operation and
returning the message id of the request it sent. The result of the
operation can be obtained by a subsequent call to ldap_result(3).
The ldap_bind() and ldap_bind_s() routines can be used when the
authentication method to use needs to be selected at runtime. They
both take an extra method parameter selecting the authentication
method to use. It should be set to LDAP_AUTH_SIMPLE to select simple
authentication. ldap_bind() returns the message id of the request it
initiates. ldap_bind_s() returns an LDAP error indication.
For SASL binds the server always ignores any provided DN, so the dn
parameter should always be NULL. ldap_sasl_bind_s() sends a single
SASL bind request with the given SASL mechanism and credentials in
the cred parameter. The format of the credentials depends on the
particular SASL mechanism in use. For mechanisms that provide mutual
authentication the server's credentials will be returned in the
servercredp parameter. The routine returns an LDAP error indication
(see ldap_error(3)). The ldap_sasl_bind() call is asynchronous,
taking the same parameters but only sending the request and returning
the message id of the request it sent. The result of the operation
can be obtained by a subsequent call to ldap_result(3). The result
must be additionally parsed by ldap_parse_sasl_bind_result() to
obtain any server credentials sent from the server.
Many SASL mechanisms require multiple message exchanges to perform a
complete authentication. Applications should generally use
ldap_sasl_interactive_bind_s() rather than calling the basic
ldap_sasl_bind() functions directly. The mechs parameter should
contain a space-separated list of candidate mechanisms to use. If
this parameter is NULL or empty the library will query the
supportedSASLMechanisms attribute from the server's rootDSE for the
list of SASL mechanisms the server supports. The flags parameter
controls the interaction used to retrieve any necessary SASL
authentication parameters and should be one of:
use defaults if available, prompt otherwise
The interact function uses the provided defaults to handle requests
from the SASL library for particular authentication parameters. There
is no defined format for the defaults information; it is up to the
caller to use whatever format is appropriate for the supplied
interact function. The sasl_interact parameter comes from the
underlying SASL library. When used with Cyrus SASL this is an array
of sasl_interact_t structures. The Cyrus SASL library will prompt for
a variety of inputs, including:
the realm for the authentication attempt
the username to authenticate
the password for the provided username
the username to use for proxy authorization
generic prompt for input with input echoing disabled
generic prompt for input with input echoing enabled
indicates the end of the array of prompts
See the Cyrus SASL documentation for more details.
Applications which need to manage connections asynchronously may use
ldap_sasl_interactive_bind() instead of the synchronous version. A
valid mechs parameter must be supplied, otherwise the library will be
forced to query the server for a list of supported mechanisms, and
this query will be performed synchronously. The other parameters are
the same as for the synchronous function, with three additional
parameters. The actual SASL mechanism that was used, and the message
ID for use with ldap_result() will be returned in rmechp and msgidp,
respectively. The value in rmechp must not be modified by the caller
and must be passed back on each subsequent call. The message obtained
from ldap_result() must be passed in the result parameter. This
parameter must be NULL when initiating a new Bind. The caller must
free the result message after each call using ldap_msgfree(). The
ldap_sasl_interactive_bind() function returns an LDAP result code. If
the code is LDAP_SASL_BIND_IN_PROGRESS then the Bind is not complete
yet, and this function must be called again with the next result from
The ldap_set_rebind_proc function() sets the process to use for
binding when an operation returns a referral. This function is used
when an application needs to bind to another server in order to
follow a referral or search continuation reference.
The function takes ld, the rebind function, and the params, the
arbitrary data like state information which the client might need to
properly rebind. The LDAP_OPT_REFERRALS option in the ld must be set
to ON for the libraries to use the rebind function. Use the
ldap_set_option function to set the value.
The rebind function parameters are as follows:
The ld parameter must be used by the application when binding to the
referred server if the application wants the libraries to follow the
The url parameter points to the URL referral string received from the
LDAP server. The LDAP application can use the ldap_url_parse(3)
function to parse the string into its components.
The request parameter specifies the type of request that generated
The msgid parameter specifies the message ID of the request
generating the referral.
The params parameter is the same value as passed originally to the
The LDAP libraries set all the parameters when they call the rebind
function. The application should not attempt to free either the ld or
the url structures in the rebind function.
The application must supply to the rebind function the required
authentication information such as, user name, password, and
certificates. The rebind function must use a synchronous bind method.
The ldap_unbind() call is used to unbind from the directory,
terminate the current association, and free the resources contained
in the ld structure. Once it is called, the connection to the LDAP
server is closed, and the ld structure is invalid. The
ldap_unbind_s() call is just another name for ldap_unbind(); both of
these calls are synchronous in nature.
The ldap_unbind_ext() and ldap_unbind_ext_s() allows the operations
to specify controls.
Asynchronous routines will return -1 in case of error, setting the
ld_errno parameter of the ld structure. Synchronous routines return
whatever ld_errno is set to. See ldap_error(3) for more information.
If an anonymous bind is sufficient for the application, the rebind
process need not be provided. The LDAP libraries with the
LDAP_OPT_REFERRALS option set to ON (default value) will
automatically follow referrals using an anonymous bind.
If the application needs stronger authentication than an anonymous
bind, you need to provide a rebind process for that authentication
method. The bind method must be synchronous.
This page is part of the OpenLDAP (an open source implementation of
the Lightweight Directory Access Protocol) project. Information
about the project can be found at ⟨http://www.openldap.org/⟩. If you
have a bug report for this manual page, see
⟨http://www.openldap.org/its/⟩. This page was obtained from the
project's upstream Git repository
⟨git://git.openldap.org/openldap.git⟩ on 2017-03-13. If you discover
any rendering problems in this HTML version of the page, or you
believe there is a better or more up-to-date source for the page, or
you have corrections or improvements to the information in this
COLOPHON (which is not part of the original manual page), send a mail
OpenLDAP LDVERSION RELEASEDATE LDAP_BIND(3)