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 ------------------------------------------
Pierangelo Masarati wrote:
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:
- privileged connections are treated some way
- idassert connections are treated separately
- 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...
Perhaps just use a new acl-bind keyword that means "same as idassert" ?
This is has definitely been a confusing area. I've been working on adding per-instance TLS configuration support here, and I wasn't quite convinced how many separate TLS contexts were needed. Your email helped clarify things, thanks.
Also on the topic of separate TLS contexts - currently the main slapd TLS context is only used for incoming connections. The syncrepl consumer and any other outbound connections use the TLS info in ldap.conf by default, not slapd.conf. Some folks have suggested that it makes more sense for the default to come from the main slapd settings instead. Any thoughts on that?
Also on the topic of separate TLS contexts - currently the main slapd TLS context is only used for incoming connections. The syncrepl consumer and any other outbound connections use the TLS info in ldap.conf by default, not slapd.conf. Some folks have suggested that it makes more sense for the default to come from the main slapd settings instead. Any thoughts on that?
From a libldap perspective, I'd say respect system-wide ldap.conf and
treat the syncrepl consumer as an application-level override thereof. I don't think anybody on openldap-devel would have trouble with this.
However, I could see this getting messy to explain to newcomers on openldap-software and other end users of slapd(8), especially in the face of ugprades from "server-only" installations that never previously gave thought to ldap.conf. I think it might be happy medium to:
1. have overrides available in slapd.conf 2. one of the settings for the slapd.conf directives should be "use ldap.conf" which should be the default, however, 3. in the absence of (1) or (2), print something along the lines of "warning, no TLS configuration specified, using /foo/bar/ldap.conf" (if it's even possible to query that path from libldap?)
That way, there's still the complete flexibility, and unknowing users get a hint as to where that previously-unused configuration file might be biting them.
-
Aaron Richton -
Howard Chu -
Pierangelo Masarati