Re: Troubleshoot ACLs

["Torsten Schlabach (Tascel eG)" <tschlabach@tascel.net>]

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
<marcel@van-dorp.nl>
>> 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:
>>>
>>> 1) What is it I do wrong?
>>> 2) How can I troubleshoot these issues (ACL validator available?)
>>>
>>>
>>> If more info is needed, please let me know.
>>>
>>> Marcel