On Fri, Feb 01, 2013 at 04:56:18PM +0000, Philip Colmer wrote:If your users are also stored in a subtree of dc=example,dc=com
> I have a followup requirement where I need to be able to restrict read access
> to the groups as well as write access. I only want the owners of an object to
> be able to read and write that object.
>
> The reason for wanting to do this is to ensure that a user only sees the groups
> that they can edit when they are using LDAP Account Manager. We have quite a
> large number of groups and I am trying to head off users complaining that they
> can't find the group they need to edit.
>
> I've been experimenting with the ACLs to try to get it to work but I can only
> get it to work if the owner is explicitly mentioned, rather than indirectly
> mentioned as per the "member of a group" approach.
>
> The ACLs so far are:
>
> access to dn.> > by users read
> by * none
then you may need to give anonymous users a bit more access to
this node. It depends on how your login process works, in
particular the stage that maps from a username to a DN.
OK so far.
> access to dn.> > by users read
> by * none
I assume this is to support point (3) below - probably not needed.
> access to dn.sub="ou=groups,dc=example,dc=com"
> attrs=objectClass,uniqueMember
> by users read
> by * none
Here you have a problem, as the second clause will never be used.
> access to dn.sub="ou=groups,dc=example,dc=com"
> by dnattr="owner" write
> by users none
> by * none
>
> access to dn.sub="ou=groups,dc=example,dc=com"
> by set="this/owner/uniqueMember & user" write
> by users none
> by * none
If you want to allow both direct owners and ownership via
groups then you should merge these two - something like this:
access to dn.sub="ou=groups,dc=example,dc=com"
by dnattr="owner" write
by set="this/owner/uniqueMember & user" writeby * none
I am always a bit wary of putting both direct and indirect
references in the same attribute, just in case some entry that
you think is a user ends up with a uniqueMember attribute
somehow.
OK - and you can add it to the merged version if you like.
> (I know that having 'by users none' is redundant but it is there to be
> explicit)
It may not do that. Do you want everyone to see all the OUs, or
> The purpose of the ACLs is
>
> 1. Allow everyone to see the OU structure in the domain.
> 2. Allow everyone to see the OUs within the groups OU.
only those that they are 'owner' of?
Is there a layer of OUs under ou=groups,dc=example,dc=com with
the actual groups further down? If so, you may need to add a
clause to give access to the intermediate OUs.
Slapd will read whatever it needs for internal use in
> 3. The intention here is to grant enough access to the attributes of a group so
> that slapd can then evaluate the uniqueMember attribute. It isn't entirely
> clear to me whether slapd needs a rule like this or should be able to evaluate
> membership etc before it applies acls for the user.
evaluating ACLs so don't worry about it here.
On the other hand, you *do* need to grant adequate (auth)
access to *user* entries so that anon can authenticate.
With the change given above, that bit should work.
> 4. Allow directly mentioned owners to write, nothing to everyone else.
> 5. Allow indirectly mentioned owners to write, nothing to everyone else.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------