(Answer) (Category) OpenLDAP Faq-O-Matic : (Category) OpenLDAP Software FAQ : (Category) Configuration : (Category) SLAPD Configuration : (Category) How can I ... setup something unusual? : (Answer) How can I divert binds to a remote server?
With OpenLDAP 2.3 and above this can be obtained by rewriting the DN of of bind requests before the database that will perform the operation is requested. OpenLDAP 2.3 or above is requested, because to perform DN rewriting before database selection, the slapo-rwm(5) overlay must be instantiated as global, a feature that was not available before OpenLDAP 2.3.

Consider, for example, a DSA with a local database serving the dc=example,dc=com naming context, while simple bind requests should be redirected to a remote DSA serving the dc=bind naming context. The following essential slapd.conf(5) does the trick:

# before any database
overlay                 rwm
# only massage the bindDN, let the rest pass thru
rwm-rewriteContext      bindDN
rwm-rewriteRule         "^(.+,)?dc=example,dc=com$" "$1dc=bind" ":@"

# The "real", local database
database                bdb
suffix                  "dc=example,dc=com"
# ...

# The "bind" database
database                ldap
suffix                  "dc=bind"
uri                     "ldaps://bind.example.com"
# only allow binds
restrict                read write extended
# ...
Note that a client that binds to the above DSA with a DN of
will actually be presented to the remote DSA listening on "ldaps://bind.example.com" as

Be sure you carefully read slapd.conf(5), slapo-rwm(5) and the man pages of the backends you use, so that you understand all the implications of the above configuration.

Replace the ldap database with a perl or shell database to delegate authentication to some custom scripting code, or write your own backend and load it as a dynamic module (see moduleload in slapd.conf(5) for details).

Another solution (OpenLDAP 2.2 and above) consists in writing an overlay that provides (at least) the bi_op_bind hook. The overlay can be stacked on top of the database so that it intercepts bind requests. The bi_op_bind hook should return:
  • LDAP_SUCCESS in case of successful authentication; the frontend will take care of sending response to the client;
  • an appropriate error code (typically LDAP_INVALID_CREDENTIALS, to avoid disclosure of valuable info) in case of error, after calling send_ldap_result() to send a response containing that error;
  • optionally, SLAP_CB_CONTINUE if control is to be left to the underlying database and optional overlay list in case authentication couldn't be performed.

Yet another solution (OpenLDAP 2.3 and above) consists in writing an overlay that provides (at least) the bi_op_bind hook and can be instantiated as global, which means "before any database instance". The overlay intercepts bind requests before database selection occurs, so it serves all bind operations. This case differs from the above in that the overlay itself must take care of some internal operations in case of successful bind; in OpenLDAP 2.4 a dedicated helper is provided: fe_op_bind_success().
Overlays work great on a per-backend model. If you're looking to send remote binds on a per-entry model, for instance mixing in-directory and remote server binds, it might be worth looking at making a new hash scheme that accesses the remote server. Look at contrib/slapd-modules/passwd/kerberos.c for an example of this. userPassword: {KERBEROS}foo will bind to the remote server, whereas userPassword: {SHA1}* will bind within slapd, and these can all live happily in the same backend.
[Append to This Answer]
This document is: http://www.openldap.org/faq/index.cgi?file=1299
[Search] [Appearance]
This is a Faq-O-Matic 2.721.test.
© Copyright 1998-2013, OpenLDAP Foundation, info@OpenLDAP.org