.. _LDAP:

LDAP integration

================

Overview

--------

Using LDAP as a source for user credentials and information is quite

easy. The most difficult part lies in building an LDAP schema or

using an existing one.

At cube creation time, one is asked if more sources are wanted. LDAP

is one possible option at this time. Of course, it is always possible

to set it up later in the `source` configuration file, which we

discuss there.

It is possible to add as many LDAP sources as wanted, which translates

in as many [ldapxxx] sections in the `source` configuration file.

The general principle of the LDAP source is, given a proper

configuration, to create local users matching the users available in

the directory, deriving local user attributes from directory users

attributes. Then a periodic task ensures local user information

synchronization with the directory.

Credential checks are _always_ done against the LDAP server.

The base functionality for this is in

Configurations options

----------------------

Let us enumerate the options (but please keep in mind that the

authoritative source for these is in the aforementioned python

module), by categories (LDAP server connection, LDAP schema mapping

information, LDAP source internal configuration).

LDAP server connection options:

  for the later being partial as of now)

  used to respond to rql queries)

  ldap (eg used to respond to rql queries)

If the LDAP server accepts anonymous binds, then it is possible to

leave data-cnx-dn and data-cnx-password empty. This is, however, quite

unlikely in practice.

LDAP schema mapping:

LDAP source internal configuration:

  default. You can set multiple groups by separating them by a comma

  ldap directory in seconds (default to once a day)