OpenLDAP/slapd/back-sql

From PALDAP

OpenLDAP's back-sql offers an SQL schema which you can use (and modify) to serve as a slapd back-end. This is most useful when you want to provide access to data within an SQL database through the LDAP protocol.

It is said using an SQL database as a general purpose slapd back-end would be very unsatisfying performance-wise. SQL backing an LDAP directory is primarily recommended if you want to make existing data in an SQL database available to LDAP clients without having to duplicate data and efforts.

Contents 1 Mapping LDAP operations to SQL statements 1.1 Mapping search and compare operations 1.2 Mapping update operations 1.3 Mapping delete operations 2 Mapping meta information 2.1 Mapping LDAP object classes to SQL relations (tables or views) 3 Weaknesses of OpenLDAP's back-sql 4 Further reading and references

[edit] Mapping LDAP operations to SQL statements

back-sql works by mapping LDAP operations to SQL database statements.

[edit] Mapping search and compare operations

Searching an LDAP tree is very different than searching an SQL database. As in an SQL SELECT statement, an LDAP search operation can be constrained with a given set of conditions called LDAP search filters. Also as in SQL, the names of attributes to include in the search result can be given. LDAP without

[edit] Mapping update operations

[edit] Mapping delete operations

[edit] Mapping meta information

[edit] Mapping LDAP object classes to SQL relations (tables or views)

The SQL query to retrieve the mappings of LDAP object classes to SQL relations is configured by **oc_query** configuration directive. The default query is "SELECT id, name, keytbl, keycol, create_proc, delete_proc, expect_return FROM ldap_oc_mappings". The following is the table structure which fits this default query. This is also the table structure which is created if you use the standard schema from the OpenLDAP CVS repository.

id INTEGER UNIQUE 

id is the unique numeric identifier of an objectClass mapping.

name VARCHAR(64) 

name is the name of the objectClass.

keytbl VARCHAR(64) 

keytbl is the name of the table (or view) where entries of this object class are to be found.

keycol VARCHAR(64) 

keycol is the name of the column in keytbl that holds the primary key.

create_proc VARCHAR(255)

create_proc VARCHAR(255)

expect_return INTEGER

[edit] Weaknesses of OpenLDAP's back-sql

I've found the combination of OpenLDAP's backsql, iODBC/UnixODBC and PostgreSQL to be extremely fragile and unreliable. Once, on a particular system, it would work. But, I've never been able to reproduce this even though I've tried it with different versions of OpenLDAP, *ODBC and Postgres. –Rowan Rodrik van der Molen 2006/07/22 15:28

[edit] Further reading and references

• The OpenLDAP-PostgreSQL How To by gilles@darold.net is a document about configuring an OpenLDAP server with a PostgreSQL database as backend instead of the standard Bekerley DB.

• The most up-to-date official text on configuring OpenLDAP with an SQL backend is probably The SQL backend (How do I setup/configure back-sql?) from the OpenLDAP FAQ.

• There's also the slapd-sql manual page.

• The /servers/slapd/back-sql/rdbms/depend directory in OpenLDAP's CVS repository contains configuration examples and SQL schema creation code for most supported RDBMS.