OpenLDAP Faq-O-Matic : OpenLDAP Software FAQ : Configuration : SLAPD Configuration : How can I ... setup something unusual? :
How can I divert binds to a remote server?
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
uid=user,ou=People,dc=example,dc=comwill actually be presented to the remote DSA listening on "ldaps://bind.example.com" as
uid=user,ou=People,dc=bind
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).
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_SUCCESSin 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_CONTINUEif control is to be left to the underlying database and optional overlay list in case authentication couldn't be performed.
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().