On Wed, Apr 27, 2016 at 12:10:31PM -0400, Aaron Richton wrote:

Yes, this should be possible, something along the lines of:

access to attrs=somethingPrivate by self none break by * none

access to attrs=somethingPrivate by peername.ip="1.2.3.0%255.255.255.0" write by * none

Thanks for the tip, this really does seem to work. :)

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?

But this introduces an additional problem. Some of the attributes that require "self" from a certain IP address should also work when a member of a certain group accesses the attribute from anywhere.

So something like this should work:

--clip-- access to attrs=somethingPrivate by group/groupOfUniqueNames/uniqueMember.exact="cn=somegroup,ou=somebranch,dc=dom,dc=ain" read by self none break by * none

access to attrs=somethingPrivate by peername.ip="1.2.3.0%255.255.255.0" write by * none --clip--

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 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 this:

http://www.openldap.org/lists/openldap-devel/201208/msg00002.html

which says

--clip-- I see a few puzzling inconsistencies, like the existence of acl-passwd and acl-authcDN keywords that don't actually have any functional code behind them. I would guess they should have been replaced with acl-bind but there's no implementation of that anywhere either. --clip--

Wonder if that's still true? If so, what'd be a working method to check group based ACLs on the proxy?

I'm running 2.4.39 from the RHEL 7 distribution.

--Janne Peltonen University of Helsinki

On Thu, Apr 28, 2016 at 09:15:09AM -0400, Aaron Richton wrote:

...

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?

It matches.

...

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.

I can't use back-ldap because I have two mirroring backend servers I want to connect to (in case one of them fails) and that is precisely the functionality I require from back-meta.

Looking at the code, my version of back-meta doesn't know anything about acl-bind (back-ldap does). It does know about acl-authcdn and acl-passwd, though. From back-meta/config.c:

--clip-- case LDAP_BACK_CFG_ACL_AUTHCDN: case LDAP_BACK_CFG_ACL_PASSWD: /* FIXME no point here, there is no code implementing * their features. Was this supposed to implement * acl-bind like back-ldap? */ rc = 1; break; --clip--

So, um. Maybe I'll have a look at the latest 2.4 code next. Thanks for the reply.

--Janne

On Thu, Apr 28, 2016 at 10:35:27AM -0400, Aaron Richton wrote:

...

So, um. Maybe I'll have a look at the latest 2.4 code next. Thanks for the reply.

Hmm, no, the latest RE24 checkout from git has that too. Looks like back-meta isn't quite there yet.

Yeah, just looked at it myself.

Now, if your only goal is multiple backend servers, do note that back-ldap supports multiple URIs for this scenario?

When our new LDAP system is up and running and everybody uses that, then it will be the only goal. And I checked, acl-bind (and those legacy acl-authcDN/acl-passwd and even binddn/bindpw) seem to work as they should with back-ldap, so at the end, back-ldap should be a perfect match for what we need.

But we're having a migration phase during which we need to proxy one subtree of our database from an old backend service. So everything else comes from those two backends but one branch; it comes from a third one. And that would require back-meta, I think. So apparently we'll have to think a way around that, maybe by just copying those entries over using a perl script or something...

Thanks again!

--Janne

On Thu, Apr 28, 2016 at 11:05:03AM -0400, Aaron Richton wrote:

...

But we're having a migration phase during which we need to proxy one subtree of our database from an old backend service. So everything else comes from those two backends but one branch; it comes from a third one. And that would require back-meta, I think. So apparently we'll have to think a way around that, maybe by just copying those entries over using a perl script or something...

Depends what you're doing. Perhaps multiple subordinate back-ldap's (maybe with a back-null at the top to glue everything together)? And/or create the three back-ldap's under (perhaps unpublished) unique suffix, then back-relay everything together?

I tried subordinate back-ldaps, sth like this:

--- database ldap suffix ou=foo,ou=bar,dc=dom,dc=ain uri ldap://migration.server/ overlay rwm rwm-suffixmassage "ou=foo,ou=bar,dc=dom,dc=ain" "ou=some,o=thing" tls propagate

database ldap suffix dc=dom,dc=ain uri ldap://backend-1.server/ ldap://backend-2.server/ tls propagate ---

And it mostly worked. Except when I tried to do a subtree search like so:

ldapsearch -xZZH ldap://ldap-proxy.server -b ou=bar,dc=dom,dc=ain 'uid=sth_in_migr_server'

it returned nothing, whereas

ldapsearch -xZZH ldap://ldap-proxy.server -b ou=foo,ou=bar,dc=dom,dc=ain 'uid=sth_in_migr_server'

returned the entry. With back-meta, I can base the search on a branch that resides on one backend server and it also searches other backend servers that contain sub-branches of that branch; the first kind of search worked.

Then I tried gluing things together with back-relay. Sth like this.

--- database relay suffix o=testing overlay rwm rwm-suffixmassage "ou=really,o=testing" "ou=some,o=thing" rwm-suffixmassage "o=testing" "ou=bar,dc=dom,dc=ain"

database ldap suffix ou=some,o=thing uri ldap://migration.server/ tls propagate

database ldap suffix dc=dom,dc=ain uri ldap://backend-1.server/ ldap://backend-2.server/ tls propagate ---

But the result was similar.

ldapsearch -xZZH ldap://ldap-proxy.server -b o=testing 'uid=sth_in_migr_server'

->nothing found

ldapsearch -xZZH ldap://ldap-proxy.server -b ou=really,o=testing 'uid=sth_in_migr_server'

->found entry

(and of course, if I put the rwm-suffixmassage lines in the reverse order, -b ou=really,o=testing resulted in "no such object" because there really isn't a subtree 'ou=really,ou=bar,dc=dom,dc=ain" on the backend servers)

So apparently, I can use back-ldap to proxy a separate branch of my database to a separate server, but I cannot expect subtree searches based on somewhere else to contain that separate branch?

Thanks again for the suggestions.

--Janne