LDAP is working. This page is mainly preserved for historical reasons, and to contain some of the sources of troubles we encountered.

Current state of getting LDAP with the SQL-backend to run. The major complication is that all sources (see References) work with the old-style slapd.conf mechanism whereas newer ldap has switched to the new-style cn=config mechanism.

First we install odbc:

sudo apt-get install unixodbc odbc-postgresql

And configure it via /etc/odbc.ini:

Description         = DATABASE_NAME connector for OpenLDAP's back-sql
Driver              = PostgreSQL Unicode
Trace               = No
Database            = DATABASE_NAME
Servername          = DATABASE_HOST
UserName            = cdb_admin
Port                = 5432
ReadOnly            = No
RowVersioning       = No
ShowSystemTables    = No
ShowOidColumn       = No
FakeOidIndex        = No
ConnSettings        =

The Driver must be as specified in /etc/odbcinst.ini (which should be prefilled by the Debian package). To check odbc functionality we use the following command:

isql cdb

We need some additional info inside the SQL database. The ldap specific additions reside in cdedb/database/cdedb-ldap.sql. All data which is prefilled here is static and needed for ldap to work. We use sql query views to ‘insert’ data from other existent tables in the needed format into the ldap tables. Currently, there is only one table (ldap.duas) which is filled with test specific sample data.

We now configure the SQL-backend for LDAP via two corresponding LDIF files (as is necessary according to the cn=config mechanism). The first file at related/auto-build/files/stage3/ldap-config.ldif contains all adjustments for the ldap setup process, which are mainly loading ldap modules like the sql-backend. The second file at ldap/cdedb-ldap.ldif contains the actual definition of the cdedb ldap interface.

To apply the LDIF configuration file we issue the following command:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /path/to/file

Now, one can apply the database schemas as usual by calling:

make sample-data

If the database schema is modified, ldaps slapd service needs to be stopped before and restarted afterwards. This is done in all relevant make targets automatically.

We can retrieve the data from LDAP with the following command:

sudo ldapsearch  -Y EXTERNAL -H ldapi:/// -b "dc=cde-ev,dc=de"

which lists the contents of our LDAP-directory backed by the SQL-DB.

An alternative to ldapsearch should be slapcat like the following:

sudo slapcat -n 2

However this gives the barely helpful error slapcat: database doesn't support necessary operations.. This [StackOverflow Comment[(https://serverfault.com/a/584609) suggest that slapcat is not compatible with the sql-backend.


To access the ldap in a local vm, the respective port needs to be mapped to localhost. Add something similar to this to your vm setup:


To view and query the ldap tree, Apache Directory Studio is a handsome tool.


To receive more information from LDAP in case anything goes wrong the log level can be increased with the following:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: -1

To access the error log of slapd, use:

sudo journalctl -ru slapd

To check the entries of the ldap database tables, use the psql console:

sudo -u cdb psql

To access the root DN, use:

sudo ldapsearch -H ldap:// -x -D "cn=admin,dc=cde-ev,dc=de" -b "" "+"

To view the current content of the cn=config DIT, user:

sudo ldapsearch -H ldapi:// -Y EXTERNAL -b "cn=config" -LLL -Q | less

Sanity test for ldapsearch (this should produce no errors and return some results):

sudo ldapsearch  -Y EXTERNAL -H ldapi:/// -b "dc=cde-ev,dc=de"

To drop all LDAP SQL databases, a purged reinstallation of slapd seems necessary (using an LDIF file with a delete instruction errors with ldap_delete: Server is unwilling to perform (53)):

make ldap-reset