This project uses existing open-source components to expose the CiviCRM contact data to LDAP enabled applications using OpenLDAP's slapd server and the SQL backend. This is a self-contained configuration that can run alone or along side an existing OpenLDAP slapd server instance.

Background on LDAP and directories

Directories are a kind of database. LDAP is a standard protocol for operating on hierarchical data in a directory service. Probably the most popular open-source directory server is OpenLDAP.

Directory services are very versatile, but they are most frequently implemented to make systems administrators' lives easier. Most tutorials and documentation for OpenLDAP assumes that the goal is to centralize identity management — authentication, authorization and accounting — for a network or set of application. It is closely related to and usually a component of Single Sign-on systems. Many common network services can use directory services as a source for user and privilege data: Samba, Postfix, Apache HTTPD Server and most other servers in those areas. Directory services are also often used as white pages, and all major email clients and desktop address book applications — Thunderbird, Outlook, Mac OS X Mail.app, Eudora — support LDAP connections to directory servers.

Additional Resources on LDAP, directories and OpenLDAP

• LDAP and OpenLDAP
• LDAP System Administration by Gerald Carter
• LDAP Directories Explained: An Introduction and Analysis by Brian Arkills

Reqirements

• OpenLDAP
• MySQL 5 or greater
• MySQL Connector/ODBC
• Non-Windows platforms require an ODBC library:
  • unixODBC
  • iODBC

Instructions

These instructions are specific to my installation on FreeBSD. Pathnames and hostnames will necessarily be different for other operating systems and configurations.

Configure ODBC driver and library

ODBC needs two configuration files. On FreeBSD, these are at /usr/local/etc.

The driver is defined in odbcinst.ini. You need to use the threaded driver when your ODBC client is threaded. OpenLDAP's slapd (the ODBC client) is threaded by default. The location of the driver will vary.

The database connection is defined in odbc.ini. Be sure to change the MySQL server host name, database name and user name.

Make sure the MySQL user has permission to connect to the database from the IP address of the OpenLDAP server.

Configure OpenLDAP

Duplicate the OpenLDAP configuration directory. On FreeBSD, these are at /usr/local/etc.

Install the civicrm LDAP schema inside the schema directory of your new civildap directory. This file creates a new auxiliary objectClass with a contactID attribute. This attribute is used in the distinguished name of the entries because it is the only guaranteed unique attribute from the civicrm database (it's the primary key).

Edit slapd.conf. Many options in this file need to be customized for your operating system and configuration. Change the pathnames for the include, pidfile, argsfile and modulepath properties. Your CiviCRM database settings should be used for dbname, dbhost, dbuser and dbpasswd.  Note that dbname is the ODBC database name given in odbc.ini ("[civicrm]" in the above example), and not the MySQL database name (though they may have the same name).

First half of Configure OpenLDAP's SQL backend

Run this SQL on your CiviCRM database.

Create views for CiviCRM data

Run this SQL script on your CiviCRM database. The script creates views that de-normalize CiviCRM's contact data. CiviCRM's contact and location tables model many-to-many relationships that cannot be reproduced using the inetOrgPerson and organization objectclasses in LDAP. These views reduce the CiviCRM data so that the mappings are simpler. Only primary locations are used for postal addresses, but all phone numbers and email addresses for all locations are mapped.

Test

You can test the configuration so far by running slaptest.

Create a startup script.

The startup script for FreeBSD is simply a duplication of the slapd startup script that has been modified to read different rc.conf variables. These variables specify the arguments to use when launching slapd. I use port 10389 and 10636 so that other instances of OpenLDAP's /slapd/ server can run on the same host.

Security

This method is currently very insecure. Because I trust my immediate network, I use this ACL to restrict usage to just my subnet. This setting is put in slapd.conf above the database definitions.

Modify the peername.ip property for your subnet.

Configuring clients

LDAP clients are going to ask for a server, search base, port and scope. You will also need to supply authentication information.

Future direction

Several serious issues remain to be addressed. The most important is security.

SSL and TLS are relatively easy to configure in OpenLDAP. This would allow secure connections to the directory server where authentication information and the data itself is transmitted with encryption. However, this document does not explain how to configure SSL/TLS. Instructions can be found at the OpenLDAP site in the administration guide.

Presently, one username and password combination is needed to read the entire directory tree. The design of LDAP directories means that authorization and authentication information is itself part of the directory entries, but with CiviCRM this is not yet possible (i.e. we cannot use Drupal passwords to connect to the directory service). In many networks, there might already be a directory service which can be used to regulate access to the CiviCRM tree. Otherwise, the only option to create different kinds of privileges in the directory is to also create a different branch that uses a different database. The OpenLDAP backends back-ldbm, back-bdb, and back-ldif would probably be used in this case. There's not much point to creating additional users, because the CiviCRM directory branch is read-only.

No support for CiviCRM groups exists. There would be many possibilities for representing groups in the LDAP entries for the contacts, as subtrees or as groupOfNames objects in a separate branch. Probably no single method would work for everyone.

This method only covers the basic inetOrgPerson and organization objectclasses. Thunderbird, Outlook and Mac OS X Mail.app can support additional attributes (birthdates, multiple postal addresses, etc.), but this requires additional mappings and the inclusion of additional LDAP schemas. Supporting every client's extended attribute set is possible but is also an extraordinary amount of work.