[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Troubleshoot ACLs
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
> <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