OpenLDAP Faq-O-Matic: How can I divert binds to a remote server?

	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?
	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 uid=user,ou=People,dc=example,dc=com will 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).
	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.