On Thu, 28 Apr 2016, Janne Peltonen wrote:
As we're building a proxy configuration, this requires some
of the ACLs. Until now, the ACLs have all resided on the backend
servers, and the proxy hasn't had anything (it has been configured as a
read only meta database).
This would require moving at least some of the ACLs to the proxy,
because the backend sees all the connections as coming from the proxy,
Yes, that would make sense in this scenario.
But if I put this kind of an ACL entry to my proxy, when a member of the group
"cn=somegroup,ou=somebranch,dc=dom,dc=ain" tries to access somethingPrivate,
the ACL checker falls all the way through to the "by * none" WHO clause and no
access is granted.
I think I'd start with some basics here: what does ldapcompare(1) show
about group membership (or lack thereof)? Does it match/disagree with
slapd "acl" debugging output?
I have added the acl-authcDN and acl-passwd config lines to my meta
config after the URI, but they don't seem to have any effect. Moreover, I found
I believe that back-meta, like back-ldap, is transitioning toward the
acl-bind directive. For now, this appears (perhaps unfortunately) to only
be documented in the slapd-ldap(5) man page. So take a look at that too.
I'm running 2.4.39 from the RHEL 7 distribution.
I don't know how many patches RHEL may (or may not) backport for you, but
I know that some significant improvements have been made since 2.4.39,
including some back-meta logging enhancements that might make this process
a bit easier. You should consider using the latest 2.4 release instead.