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.