Hi!
I was thinking about giving the users a different set of their own attributes, depending on whether they accessed the server from a well-known IP address or not. Is this possible using OpenLDAP? I know how to form a WHO clause to grant access to self; I know how to form a WHO clause to grant access from a certain IP address; what I don't know is how to grant access to "self if and only if it hails from a certain IP address", i.e. so that the given rights would require both that we're considering "self" and "IP address" at the same time, but if either doesn't match, then the clause wouldn't apply.
I'be glad if anybody could provide any help upon this. Also a simple "can't be done" would be appreciated.
--Janne Peltonen University of Helsinki
On Wed, Apr 27, 2016 at 12:10:31PM -0400, Aaron Richton wrote:
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, 28 Apr 2016, Janne Peltonen wrote:
Yes, that would make sense in this scenario.
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.
On Thu, Apr 28, 2016 at 09:15:09AM -0400, Aaron Richton wrote:
It matches.
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:
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, 28 Apr 2016, Janne Peltonen wrote:
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?
On Thu, Apr 28, 2016 at 11:05:03AM -0400, Aaron Richton wrote:
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
openldap-technical@openldap.org
-
Aaron Richton -
Janne Peltonen