Hi again!
In the concrete case you explain, maybe the group thing doesn't work as expected.
Here is our (anonymized) entry for that:
{3}to dn.regex="o=([^,]+),o=planet" by self write by group.expand="cn=admins2,o=$1,o=planet" write by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write by * search
What that does is:
In each o=something,o=planet subtree we have a group called cn=admins2,o=something,o=planet. Each member of that group has write access to o=something,o=planet.
The lines
by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
are needed to make sure that our two superusers cn=admin,o=planet and uid=someoneelse,ou=user,o=anyorg,o=planet also keep having access.
One nasty thing about how ACLs work is:
As soon as the "to" portion machtes, no further entries are scanned.
So if we would say
{4}to * by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
later, the entry {3} would still result in cn=admin and uid=someoneelse not having *any* access to o=...,o=planet if they would not be explicitely mentioned in entry {3}.
This is what many people stumble on.
Regards, Torsten
On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp marcel@van-dorp.nl wrote:
Torsten Schlabach (Tascel eG) wrote:
Hi Marcel!
Your setup is exactly what we also do.
My question:
What works and what doesn't?
It is quite a lot now, and I did not document properly what did and did not work; sorry! I am working with a copy of a real configuration (thanks to virtualization!), so basically I can start from scratch with the ACLs.
How do you test it? Manually?
With PHPldapadmin (PLA). I have a linux workplace, with 2 screens (X-windows). On each screen I have a browser open. In the left browser I log on as cn=admin,cn=config, and there I do the tweaking. On the right browser I login as a user. This way the session cookies remain separate, and do not conflict with each other (which happens if you use 2 tabs within the same browser). I did some (obvious) abbreviation in my original post. As a normal user I use something like:
cn=testuser,ou=cust1,ou=customers,ou=people,dc=example,dc=com
In this example I would like to have read rights to anything from:
ou=cust1,ou=customers,ou=people,dc=example,dc=com
this DN included, and all children (my own entry is there as well).
If I am also a member of the group
cn=cust1,ou=groups,dc=example,dc=com
then I would like to have write rights as well in beformentioned parts of the directory.
I tried a zillion combinations, but all I get, is access to my own entry (in many cases, I can login, but cannot read the directory, not even my own entry).
When I log in in PLA, I get the two toplevel DNs: cn=config dc=example,dc=com
Which I cannot expand. Just above this my own DN is displayed, and when I click on the left-most field, I get my entry, and I then can expand the tree (number of children between parenthesis):
dc=example,dc=com (1) ou=people (1) ou=customers (1) ou=cust1 (1) cn=testuser
When I open the parent (ou=cust1), I do not see any content (there is an objectclass definition, the ou attribute (obviously) and an extra 'description' attribute (for testing only). In my own entry (cn=testuser), I can see all attributes.
The debug output says a few things about matching and masking, but it is not very clear which ACL-line is processed, and if this is about the 'to' or the 'by' part.
Hope this clearifies things a bit. Any suggestions?
Marcel
Regards, Torsten
On Wed, 15 Sep 2010 09:36:38 +0200, Marcel van Dorp
wrote:
Hi,
I try to implement certain ACLs, but apparently something goes wrong.
I
read a lot about ACLs, and I do not understand what I do wrong. Maybe someone on this list can help.
I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with phpldapadmin as frontend. I use cn=config
I try to achieve the following:
*) No anonymous access *) Users can change their own attributes/children *) LDAP managers are listed in a groupOfNames *) Customers should have READ access to their parent entry, and all children of their parent (siblings) *) Specific users below a customer should have WRITE access to their parent, and all siblings (users are member of a specific groupOfNames)
I have the following ACLs in olcAccess (sanitized, on multiple lines
for
readability, with group/groupOfNames/member abbt. to g/gON/m below):
{0}to attrs=userPassword,shadowLastChange by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read by anonymous auth by self write by * none
{1}to dn.base="" by * read
{2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com" by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com"
read
by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write by * none
{3}to attrs=mail,entry by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by self write by * read
{4}to * by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by anonymous search by self write by * none
Explanation:
{0} superuser, admins and self can change passwords. Replicators can read, anonymous can authenticate, and others have no access.
{1} Is added to get some result, gives read access to the top level of the directory. It shows 'cn=config', and 'dc=exm,dc=com'
{2} Is the ACL which I expected to work. The 'to' clause matches any customer in that branch The first 'by' matches any member in a group with the same name The second 'by' matches any entry below this customer The last 'by' denies other access
{3} Is there, because the email address is used for login (matching dn is looked up, and then used to bind. See documentation of
phpldapadmin).
{4} Is there, so I can actually do something (My dn is in the
mentioned
group)
I played with a different order and the like, but I do not get what I want. When I enable logging (olcLogLevel = ACL), I get some info, but
it
is hard to determine where it goes wrong.
Regarding {2}: *) I also prepended the 'to' with '.+,' to match everything below, but to no avail. *) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact'
Questions:
- What is it I do wrong?
- How can I troubleshoot these issues (ACL validator available?)
If more info is needed, please let me know.
Marcel
Torsten Schlabach (Tascel eG) wrote:
Hi again!
In the concrete case you explain, maybe the group thing doesn't work as expected.
Here is our (anonymized) entry for that:
{3}to dn.regex="o=([^,]+),o=planet" by self write by group.expand="cn=admins2,o=$1,o=planet" write by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write by * search
What that does is:
In each o=something,o=planet subtree we have a group called cn=admins2,o=something,o=planet. Each member of that group has write access to o=something,o=planet.
The lines
by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
are needed to make sure that our two superusers cn=admin,o=planet and uid=someoneelse,ou=user,o=anyorg,o=planet also keep having access.
One nasty thing about how ACLs work is:
As soon as the "to" portion machtes, no further entries are scanned.
So if we would say
{4}to * by dn.base="cn=admin,o=planet" write by dn.base="uid=someoneelse,ou=user,o=anyorg,o=planet" write
later, the entry {3} would still result in cn=admin and uid=someoneelse not having *any* access to o=...,o=planet if they would not be explicitely mentioned in entry {3}.
This is what many people stumble on.
Yes, I stumbled upon this as well, but I recognised it myself, and corrected it. Thanks for pointing it out.
I was not aware of the slapacl command. I tried it, and the output looks similar as found in the logfile. I still cannot see which line of the ACLs is being processed, but I only took a short look (will dig into this later today).
I used:
slapacl -d ACL -D"dn of user who is connecting" -F /etc/ldap/slapd.d -v -b"dn of object I try to access"
I'll let you know how I progress. Thanks so far for the info!
Marcel
Regards, Torsten
On Wed, 15 Sep 2010 14:58:43 +0200, Marcel van Dorp marcel@van-dorp.nl wrote:
Torsten Schlabach (Tascel eG) wrote:
Hi Marcel!
Your setup is exactly what we also do.
My question:
What works and what doesn't?
It is quite a lot now, and I did not document properly what did and did not work; sorry! I am working with a copy of a real configuration (thanks to virtualization!), so basically I can start from scratch with the ACLs.
How do you test it? Manually?
With PHPldapadmin (PLA). I have a linux workplace, with 2 screens (X-windows). On each screen I have a browser open. In the left browser I log on as cn=admin,cn=config, and there I do the tweaking. On the right browser I login as a user. This way the session cookies remain separate, and do not conflict with each other (which happens if you use 2 tabs within the same browser). I did some (obvious) abbreviation in my original post. As a normal user I use something like:
cn=testuser,ou=cust1,ou=customers,ou=people,dc=example,dc=com
In this example I would like to have read rights to anything from:
ou=cust1,ou=customers,ou=people,dc=example,dc=com
this DN included, and all children (my own entry is there as well).
If I am also a member of the group
cn=cust1,ou=groups,dc=example,dc=com
then I would like to have write rights as well in beformentioned parts of the directory.
I tried a zillion combinations, but all I get, is access to my own entry (in many cases, I can login, but cannot read the directory, not even my own entry).
When I log in in PLA, I get the two toplevel DNs: cn=config dc=example,dc=com
Which I cannot expand. Just above this my own DN is displayed, and when I click on the left-most field, I get my entry, and I then can expand the tree (number of children between parenthesis):
dc=example,dc=com (1) ou=people (1) ou=customers (1) ou=cust1 (1) cn=testuser
When I open the parent (ou=cust1), I do not see any content (there is an objectclass definition, the ou attribute (obviously) and an extra 'description' attribute (for testing only). In my own entry (cn=testuser), I can see all attributes.
The debug output says a few things about matching and masking, but it is not very clear which ACL-line is processed, and if this is about the 'to' or the 'by' part.
Hope this clearifies things a bit. Any suggestions?
Marcel
Regards, Torsten
On Wed, 15 Sep 2010 09:36:38 +0200, Marcel van Dorp
wrote:
Hi,
I try to implement certain ACLs, but apparently something goes wrong.
I
read a lot about ACLs, and I do not understand what I do wrong. Maybe someone on this list can help.
I use the Debian (lenny) version of openLDAP (version 2.4.11-1), with phpldapadmin as frontend. I use cn=config
I try to achieve the following:
*) No anonymous access *) Users can change their own attributes/children *) LDAP managers are listed in a groupOfNames *) Customers should have READ access to their parent entry, and all children of their parent (siblings) *) Specific users below a customer should have WRITE access to their parent, and all siblings (users are member of a specific groupOfNames)
I have the following ACLs in olcAccess (sanitized, on multiple lines
for
readability, with group/groupOfNames/member abbt. to g/gON/m below):
{0}to attrs=userPassword,shadowLastChange by dn.base="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by g/gON/m.exact="cn=repl,ou=roles,dc=exm,dc=com" read by anonymous auth by self write by * none
{1}to dn.base="" by * read
{2}to dn.regex="ou=([^,]+),ou=cust,ou=people,dc=exm,dc=com" by dn.exact,expand="cn=[^,]+,ou=$1,ou=cust,ou=people,dc=exm,dc=com"
read
by g/gON/m.exact,expand="cn=$1,ou=cust,ou=people,dc=exm,dc=com" write by * none
{3}to attrs=mail,entry by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by self write by * read
{4}to * by dn.exact="cn=admin,ou=roles,dc=exm,dc=com" write by g/gON/m.exact="cn=ldapadm,ou=groups,dc=exm,dc=com" write by anonymous search by self write by * none
Explanation:
{0} superuser, admins and self can change passwords. Replicators can read, anonymous can authenticate, and others have no access.
{1} Is added to get some result, gives read access to the top level of the directory. It shows 'cn=config', and 'dc=exm,dc=com'
{2} Is the ACL which I expected to work. The 'to' clause matches any customer in that branch The first 'by' matches any member in a group with the same name The second 'by' matches any entry below this customer The last 'by' denies other access
{3} Is there, because the email address is used for login (matching dn is looked up, and then used to bind. See documentation of
phpldapadmin).
{4} Is there, so I can actually do something (My dn is in the
mentioned
group)
I played with a different order and the like, but I do not get what I want. When I enable logging (olcLogLevel = ACL), I get some info, but
it
is hard to determine where it goes wrong.
Regarding {2}: *) I also prepended the 'to' with '.+,' to match everything below, but to no avail. *) I also tried the 'by' clauses with 'dn=regex' instead of 'dn.exact'
Questions:
- What is it I do wrong?
- How can I troubleshoot these issues (ACL validator available?)
If more info is needed, please let me know.
Marcel
openldap-technical@openldap.org
-
Marcel van Dorp -
Torsten Schlabach (Tascel eG)