ldap_bind, ldap_bind_s, ldap_simple_bind, ldap_simple_bind_s, ldap_sasl_bind, ldap_sasl_bind_s, ldap_sasl_interactive_bind_s, ldap_parse_sasl_bind_result, ldap_unbind, ldap_unbind_s, ldap_unbind_ext, ldap_unbind_ext_s, ldap_set_rebind_proc − LDAP bind routines
OpenLDAP LDAP (libldap, −lldap)
int ldap_bind(LDAP *ld, const char *who, const char *cred,
int ldap_bind_s(LDAP *ld, const char *who, const char *cred,
int ldap_simple_bind(LDAP *ld, const char *who, const char *passwd);
int ldap_simple_bind_s(LDAP *ld, const char *who, const char *passwd);
int ldap_sasl_bind(LDAP *ld, const char *dn, const char *mechanism,
*cred, LDAPControl *sctrls,
LDAPControl *cctrls, int *msgidp);
int ldap_sasl_bind_s(LDAP *ld, const char *dn, const char *mechanism,
*cred, LDAPControl *sctrls,
LDAPControl *cctrls, struct berval **servercredp);
int ldap_parse_sasl_bind_result(LDAP *ld, LDAPMessage *res,
struct berval **servercredp, int freeit);
int ldap_sasl_interactive_bind_s(LDAP *ld, const char *dn,
LDAPControl *sctrls, LDAPControl *cctrls,
unsigned flags, LDAP_SASL_INTERACT_PROC *interact,
int ldap_sasl_interactive_bind(LDAP *ld, const char *dn,
LDAPControl *sctrls, LDAPControl *cctrls,
unsigned flags, LDAP_SASL_INTERACT_PROC *interact,
void *defaults, LDAPMessage *result,
const char **rmechp, int *msgidp);
int (LDAP_SASL_INTERACT_PROC)(LDAP *ld, unsigned flags, void *defaults, void *sasl_interact);
int ldap_unbind(LDAP *ld);
int ldap_unbind_s(LDAP *ld);
int ldap_unbind_ext(LDAP *ld, LDAPControl *sctrls,
int ldap_unbind_ext_s(LDAP *ld, LDAPControl *sctrls,
int ldap_set_rebind_proc (LDAP *ld, LDAP_REBIND_PROC *ldap_proc, void *params);
int (LDAP_REBIND_PROC)(LDAP *ld, LDAP_CONST char *url, ber_tag_t request, ber_int_t msgid, void *params);
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 ldap_init(3).
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.
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
use defaults if available, prompt otherwise
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,
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 server.
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 referral.
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 referral.
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 ldap_set_rebind_proc() function.
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.
ldap(3), ldap_error(3), ldap_open(3), ldap_set_option(3), ldap_url_parse(3) RFC 4422 (http://www.rfc-editor.org), Cyrus SASL (http://asg.web.cmu.edu/sasl/)
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from University of Michigan LDAP 3.3 Release.
More Linux Commands
startx(1) - initialize an X session - Linux manual page.....
The startx script is a front end to xinit(1) that provides a somewhat nicer user interface for running a single session of the X Window System. It is often run
auparse_goto_record_num(3) - move record cursor to specific
auparse_goto_record_num will move the internal library cursors to point to a specific physical record number. Records within the same event are numbered startin
xtrap(1x) - XTrap sample clients (Commands - Linux man page)
These commands are SAMPLE CLIENTS provided with the XTrap X Server Extension Sources, Version 3.3. XTrap is an X Server extension which facilitates the capturin
XListProperties(3) - obtain and change window properties....
The XGetWindowProperty function returns the actual type of the property; the actual format of the property; the number of 8-bit, 16-bit, or 32-bit items transfe
clrtoeol(3ncurses) - clear all or part of a curses window...
The erase and werase routines copy blanks to every position in the window, clearing the screen. The clear and wclear routines are like erase and werase, but the
fork(3am) basic process management - Linux manual page......
The fork extension adds three functions, as follows. fork() This function creates a new process. The return value is the zero in the child and the process-id nu
XCopyArea(3) - copy areas (Library - Linux man page)........
The XCopyArea function combines the specified rectangle of src with the specified rectangle of dest. The drawables must have the same root and depth, or a BadMa
XtDisplay(3) - obtain window information about a widget.....
XtDisplay returns the display pointer for the specified widget. XtDisplayOfObject returns the display pointer for the specified object. XtScreen returns the scr
ExtUtils::Mkbootstrap(3pm) - make a bootstrap file for use b
Mkbootstrap typically gets called from an extension Makefile. There is no *.bs file supplied with the extension. Instead, there may be a *_BS file which has cod
ca(1ssl) - sample minimal CA application - Linux man page...
The ca command is a minimal CA application. It can be used to sign certificate requests in a variety of forms and generate CRLs it also maintains a text databas
XShmDetach(3) - X Shared Memory extension functions.........
XShmQueryExtension checks to see if the shared memory extensions are available for the specified display. XShmQueryVersion returns the version numbers of the ex
xsd(1) - Mono's utility for generating schema or class files
xsd is a tool for intended to complement the XML serialization support of Mono. It can do the following tasks: Generate serializable classes From a given XML sc