7:42 a.m.
--On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs
<airween(a)gmail.com> wrote:
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 * none
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
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.
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
I would note again that "by * none" is implicit on any ACL, there's no need
to specifically list it.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7:55 a.m.
New subject: Admin roles by group membership per OU
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.
2240
days inactive
2240
days old
openldap-technical@openldap.org
1 comments
2 participants
participants (2)
-
Ervin Hegedüs -
Quanah Gibson-Mount