There might have been some confusion recently and not so far in the mind of at least one of the developers of the proxy backends (me). Especially back-ldap allows few slecial identities to be configured, which may serve some of the special purposes this backend is required to implement.
One of them is the "acl-bind" identity (see slapd-ldap(5)), which is used for operations that are privileged, meaning internal operations used by special internal features, or operations performed using the rootdn identity. If this is enabled, and an operation occurs on a connection that's authenticated as the rootdn of the database (either because this is true, or because it is pretended by the code that called that operation of back-ldap), binding to the remote server occurs with the identity specified in the "acl-bind" statement, either using SASL or simple bind.
Another one is the "idassert-bind" identity. This is used, if configured, whenever an authenticated connection tries to perform an operation thru back-ldap (this was recently added to back-meta as well) and that back-ldap database is not the authorizing database for the connection, and thus there is no other means to inform the remote server that the connection is authenticated.
Privileged connections get cached. Connections used for idassert should be cached as well, as they always use the same identity, and typically assert that of the client by way of the proxyAuthz control. The latter didn't quite happen until a recent fix, though.
The point is that there used to be (and there is, I haven't committed recent fixes yet, since I'm trying to convince myself that everything is now fixed :) some confusion about those special identities. What I came out so far is that in the internal handling of those special connections:
1) privileged connections are treated some way 2) idassert connections are treated separately 3) in case a connection ought to be privileged, but acl-bind is not set and idassert-bind is set, the latter identity is used for privileged connections as well
I'm not 100% convinced about (3), though, because that would obfuscate what identity is used for what purpose. The reason for (3) is that if one doesn't need to have privileged connections, he shouldn't set acl-bind at all; however, there might be cases where one wants to have identity assertion in place, and if acl-bind is not configured, connections as the rootdn wouldn't exploit it (this may happen, for example, when using slapo-chain(5) on top of a database that needs to have the rootdn in place).
So the point is: is it preferable to explicitly configure twice the same identity, or have a "sane" default if one only sets idassert-bind and not acl-bind? All in all, the identity that's used for identity assertion is not likely to be more privileged than the privileged one...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------