On Thu, 28 Apr 2016, Janne Peltonen wrote:
As we're building a proxy configuration, this requires some reordering 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, correct?
Yes, that would make sense in this scenario.
by group/groupOfUniqueNames/uniqueMember.exact="cn=somegroup,ou=somebranch,dc=dom,dc=ain" read
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 backend 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.