Learn LDAP - LDAP Proxy & Gateway Patterns
Connecting the directory to other data sources: proxying to another LDAP server with back-ldap, virtualizing multiple sources with the meta backend, and exposing a SQL database through back-sql.
#Introduction
In the previous episodes the directory was the single source of truth. In practice, organizations have many data stores — other LDAP servers, SQL databases, legacy directories. Episode 23 covers the gateway patterns: back-ldap (proxy), the meta backend (virtual directory), and back-sql (SQL bridge). These let you unify data sources without moving them.
#Proxy with back-ldap
A proxy is a front server that forwards every request to a real directory behind it. back-ldap implements this: slapd receives queries on a frontend database and relays them to the target server via a single internal connection.
dn: cn=module{0},cn=config
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_ldap.la
dn: olcDatabase=ldap,olcSuffix=dc=example,dc=com,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: ldap
olcSuffix: dc=example,dc=com
olcDbUri: ldap://ldap01.example.com
olcDbStartTLS: true
olcDbBindDN: cn=admin,dc=example,dc=com
olcDbBindPW: secret
olcDbRebindAsUser: trueolcDbUri— the target server.olcDbBindDN/olcDbBindPW— the credentials for the connection between the proxy and the target.olcDbRebindAsUser— when true, each user's own bind credentials are forwarded instead of the shared bind DN.
The proxy adds value when it exposes an alternative view: a different suffix, ACL enforcement at the edge, or a controlled entry point in a DMZ that never touches the real servers directly.
#The meta Backend
The meta backend is a virtual directory: it can present the results of many backends (LDAP servers, other meta, or databases) as if they were one tree. Requests are routed to sub-trees based on rules.
dn: cn=module{0},cn=config
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_meta.la
dn: olcDatabase=meta,olcSuffix=dc=example,dc=com,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: meta
olcSuffix: dc=example,dc=com
olcDbURI: "ldap://ldap01.example.com/dc=example,dc=com"
olcDbURI: "ldap://ldap02.example.com/ou=finance,dc=example,dc=com"- The first
olcDbURIpoints the whole tree atldap01. - The second overrides the
ou=financesub-tree toldap02, which holds the finance data.
This is how the same suffix can show a merged directory: HR data from one server, finance data from another, joined under one virtual tree.
#Combining Proxy and Meta
A powerful pattern: meta as the front, back-ldap as the leaf. Each branch of the meta routes to its own back-ldap proxy, which forwards to the physical servers. This gives you:
- Uniform access — one LDAP endpoint for the whole organization.
- Routing flexibility — different sub-trees served from different sources.
- Edge ACLs — one place to enforce policy before anything reaches the backends.
- Failure isolation — a down backend affects only its branch of the virtual tree.
The design cost is complexity: more layers means more points of failure and harder debugging when a query returns nothing.
#back-sql: Bridging SQL Databases
back-sql lets slapd serve data stored in a relational database (PostgreSQL, MySQL, SQLite) as if it were LDAP data. This is for legacy systems that must keep the database as the source of truth while exposing it to LDAP clients.
dn: cn=module{0},cn=config
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_sql.la
dn: olcDatabase=sql,olcSuffix=dc=example,dc=com,cn=config
objectClass: olcDatabaseConfig
objectClass: olcSqlConfig
olcDatabase: sql
olcSuffix: dc=example,dc=com
olcDbConnection: "host=127.0.0.1 user=ldap password=secret dbname=ldapdb"
olcDbSQLTable: ldap_entriesThe mapping tables tell back-sql how to translate entries:
| Table | Role |
|---|---|
ldap_entries | maps directory entries to database rows |
ldap_attr_mappings | maps LDAP attributes to database columns |
ldap_object_classes | maps object classes to database tables |
back-sql supports both reads and writes, but write mapping is delicate — the default is a read-mostly bridge. For most integrations, a syncing script that periodically pushes database changes into the LDAP directory is simpler and safer than a live back-sql bridge.
#Performance and Failover
Gateways inherit the performance problems of their components:
- Latency — every query now crosses a network hop to the backend; measure before scaling.
- Connection pooling — the proxy keeps a persistent bind to the backend; configure carefully to avoid exhausting backend connections.
- Failover — put
olcDbURIvalues in order and monitor the backend health; a dead backend silently turns queries into errors. - Caching — proxies can cache repeated searches at the cost of freshness; only for data that doesn't change often.
ldapsearch -x -H ldap://proxy.example.com \
-b dc=example,dc=com "(uid=budi)"#Closing
In this episode 23 you understood the gateway patterns: back-ldap proxying a single server, the meta backend virtualizing many sources under one tree, combining proxy and meta for uniform access with edge ACLs, and back-sql exposing a relational database as LDAP data, plus performance and failover considerations.
Key takeaways:
- Proxy for one source —
back-ldapadds a controlled edge to a real server. - Meta for many sources — one virtual tree, many physical backends.
- back-sql is a bridge, not a home — SQL stays authoritative, LDAP only sees a view.
- Every layer is a failure point — monitor the backend health, not just the front.
In the next episode, episode 24, we prepare for the worst case: backup & restore — the slapcat/slapadd cycle, backing up the mdb database files, and disaster recovery planning.