Thank you, Andrew. Combining the two ACLs that allowed writing solved the
problem! As you correctly observed, I then didn't need the earlier ACL
granting access to objectClass and uniqueMember.

Best regards

Philip



On 1 February 2013 19:27, Andrew Findlay <[email protected]>wrote:

> On Fri, Feb 01, 2013 at 04:56:18PM +0000, Philip Colmer wrote:
>
> > 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.one="dc=example,dc=com"
> >     by users read
> >     by * none
>
> If your users are also stored in a subtree of dc=example,dc=com
> 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.
>
> > access to dn.one="ou=groups,dc=example,dc=com"
> >     by users read
> >     by * none
>
> OK so far.
>
> > access to dn.sub="ou=groups,dc=example,dc=com"
> >     attrs=objectClass,uniqueMember
> >     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"
> >     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
>
> Here you have a problem, as the second clause will never be used.
>
> 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" write
>     by * 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.
>
> > (I know that having 'by users none' is redundant but it is there to be
> > explicit)
>
> OK - and you can add it to the merged version if you like.
>
> > 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.
>
> It may not do that. Do you want everyone to see all the OUs, or
> 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.
>
> > 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.
>
> Slapd will read whatever it needs for internal use in
> 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.
>
> > 4. Allow directly mentioned owners to write, nothing to everyone else.
> > 5. Allow indirectly mentioned owners to write, nothing to everyone else.
>
> With the change given above, that bit should work.
>
> 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     |
> -----------------------------------------------------------------------
>

Reply via email to