OpenLDAP TechTip:
Translucent Overlay
Abstract
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.
| 