A directory schema is not a one-size-fits-all solution. Creating customized “views” of a directory can be an effective way to meet one-off requirements.

The Solution

The translucent overlay allows a server to present a modified view of a directory which resides on a remote server. All local search requests are first forwarded to the remote server; if an entry also exists in the local directory, any matching attributes will override those returned from the remote directory. Because entries in the local directory may be incomplete skeletons, schema checking is disabled for the local database.

For example, a regional office might have a different phone system than the corporate headquarters; an ldap directory in that regional office could proxy requests to the headquarters directory server and replace the telephoneNumber attribute for these users. Lookups within the regional office would return the “right” answer without any need for changes to the master directory.

Similarly, one workgroup might use a handful of additional attributes that aren’t relevant to the rest of the company. The translucent overlay would allow this group to superimpose a skeleton directory containing their special attributes over the master corporate directory, eliminating the need to make changes to the main directory. A translucent server might also be useful for an internal applications group who could experiment with schema additions before company-wide deployment. Because the translucent proxy server is local, there is no need for access to the production server; similarly, any client which doesn’t access the translucent server will see an unmodified directory.

The translucent overlay requires back-ldap in addition to the local backend database which holds the skeletal entries. As such, the configuration keywords documented in the slapd-ldap(5) manual page are necessary to configure access to the remote directory.

Typical Configuration

modulepath /opt/symas/lib/openldap
moduleload back_bdb.la
moduleload translucent.la

database bdb
cachesize 10000
suffix “dc=symas,dc=com”

rootdn “cn=Manager,dc=symas,dc=com”
rootpw Secret

index default eq
index objectClass,uid,dc,o,ou

overlay translucent
uri ldap://remote-server
lastmod off
binddn uid=bind-user,dc=symas,dc=com
bindpw remote-secret
map objectclass * *
map attribute * *

Here, the local database (containing the skeletal entries which will be superimposed over the remote data) is bdb, while the remote server is specified using the uri, binddn, and bindpw keywords. The map directives shown here will cause objectClasses and attributeTypes to retain their values when proxied from the remote server.

Currently, the translucent overlay implements very simple-minded access controls: add, modrdn, and delete requests may only be made against the local database if bound as the root user. A modify request will first check to see whether the target entry exists in the remote database; if not, the request will fail. Otherwise, a skeleton of the entry will be stored in the local database. Search operations will be proxied to the remote database, after which any matching entries from the local database will be used to override individual attributes returned from the remote database.

The translucent_strict option, if specified, causes modify requests which attempt to delete non-existent attributes to result in an error; these modifications are otherwise silently ignored.

NOTE: Gavin Henry supplied the following on March 20, 2007:

According to man slapo-translucent(5):

suffixmassage, map, rewrite*
These directives are no longer supported by  back-ldap;
their functionality is now delegated to the rwm overlay.
Essentially, add a statement

overlay rwm

first,  and  prefix  all  rewrite/map  statements  with  rwm-  to
obtain the original behavior.  See slapo-rwm(5) for details.

So you can’t use the map keywords specified here. I think

Gavin.