Quote

The OpenLDAP Proxy Server

As stated previously, an LDAP proxy server accesses services (in our case, LDAP services) on behalf of a client's request. This architecture is used frequently if the user is behind a firewall and wishes to access resources outside, normally on the Internet. More generally, the LDAP proxy provides a way of giving controlled access via the LDAP protocol to resources outside the actual domain; therefore, you may use it to join different domains in your intranet (e.g., different LANs located in different countries of your enterprise intranet).

Every LDAP server consists logically of two parts: a frontend and a backend. The frontend speaks the LDAP protocol [3] with the LDAP clients; meanwhile, the backend accesses the repository actually holding the data. Figure 1 shows the OpenLDAP architecture. The frontend speaks the LDAP protocol and contacts the backend upon the client's requests. The backend actually provides the data.

This architecture offers enormous flexibility. You can access different data stores just using different backends. If you need to access a different data store, not yet contained in the OpenLDAP framework, you can roll your own backend (and, I hope, make it available to the open source community).

OpenLDAP itself is shipped with a number of backends. The most frequently used ones seem to be the database backends BDB and LDBM. There is not much documentation available about which of these performs better under which conditions, so I won't address that here. OpenLDAP offers a backend that can store data in a RDBMS. You can also store the data in flat files using a shell backend or Perl functions. More about the available backends can be found in the documentation shipped with the OpenLDAP server.

Finally, there are the two backends this article is all about: the "ldap" module and the "meta" module. Both modules provide proxy services -- the "ldap" module is the basic module, and the "meta" module works on top of the "ldap" module and offers more sophisticated proxy services. The idea is to use the backend not to access a repository directly but to contact another LDAP server that holds the data. Figure 2 shows this architecture.