Re: Admin roles by group membership per OU

[Ervin Hegedüs <airween@gmail.com>]

Hi Quanah,

On Mon, Oct 16, 2017 at 07:42:39AM -0700, Quanah Gibson-Mount wrote:
> --On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs
> >and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu
> >can modify any attributes at any users under the ou=ABC Customer,
> >EXCEPT the userPassword - when I want to modify that, I get
> >permission error:
> 
> That would be expected, given your ACLs.

right,
 
> >How can I combine the attrs and group permissions? Should I list
> >all attributes in rule?
> 
> You need to add a rule in the userPassword ACL to allow the group to write
> to the attribute.  ACLs are processed in the order they are listed, and STOP
> at the first match.  This is clearly documented in the slapd.access(5) man
> page.
> 
> I.e., you would need:
> 
> dn: olcDatabase={1}mdb,cn=config
> olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write
> olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
> olcAccess: {2}to * by * read

without any real testing, I'm afraid that the rule{0} gives the
write access to cn=groupabcadmin to _all_ db, not just the ou=ABC Cumstomer
subtree.

Em I right?

There will be several OU's, and all OU will have an admin group.
All member of _that_ group under the own OU will have write
permission.

Note, that the users will _not_ allow the LDAP directly, they
will be use a webapp. So, if this idea is too complax and/or too
dangerous, then there will be only one dedicated user (for
webapp), who will have the admin rights. But the users will
authenticated themselves from LDAP, and the group membership will
choose, which methods allowed on which subtree.

I think that the LDAP auth and group membership checking is
more clean solution - but it needs a good and stable access
hierarcy.

What do you think about it?

> I would note again that "by * none" is implicit on any ACL, there's no need
> to specifically list it.

right, that's clear.


Thanks,


a.