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 using the CWSource entity type, which we discuss there.
It is possible to add as many LDAP sources as wanted, which translates in as many CWSource entities as needed.
The general principle of the LDAP source is, given a proper configuration, to create local users matching the users available in the directory and deriving local user attributes from directory users attributes. Then a periodic task ensures local user information synchronization with the directory.
Users handled by such a source should not be edited directly from within the application instance itself. Rather, updates should happen at the LDAP server level.
Credential checks are _always_ done against the LDAP server.
Note
There are currently two ldap source types: the older ldapuser and the newer ldapfeed. The older will be deprecated anytime soon, as the newer has now gained all the features of the old and does not suffer from some of its illnesses.
The ldapfeed creates real CWUser entities, and then activate/deactivate them depending on their presence/absence in the corresponding LDAP source. Their attribute and state (activated/deactivated) are hence managed by the source mechanism; they should not be altered by other means (as such alterations may be overridden in some subsequent source synchronisation).
Additional sources are created at cube creation time or later through the user interface.
Configure an ldapfeed source from the user interface under Manage then data sources:
Let us enumerate the options by categories (LDAP server connection, LDAP schema mapping information).
LDAP server connection options:
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. Beware that the LDAP server might hide attributes such as “userPassword” while the rest of the attributes remain visible through an anonymous binding.
LDAP schema mapping options: