[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Admin roles by group membership per OU
- To: Ervin Hegedüs <airween@gmail.com>
- Subject: Re: Admin roles by group membership per OU
- From: Quanah Gibson-Mount <quanah@symas.com>
- Date: Mon, 16 Oct 2017 09:20:38 -0700
- Cc: openldap-technical@openldap.org
- Content-disposition: inline
- In-reply-to: <WM!791d0d501b38cc44efe2d1a77cca4da4d02b81ee6c538cc919735b367fcdd618e9417beb8698961701af2a6d3d96b1e1!@mailstronghold-1.zmailcloud.com>
- References: <1e3053aa-10c0-2e89-4ecf-78b196480abb@savoirfairelinux.com> <20171012153230.GA26702@arxnet.hu> <WM!3ea8ec7098d14925dc39d957afaad62f207f43d00b4c648f2f5d4f5322d8acfa9261435931a6075dbeba167726dc6c91!@mailstronghold-3.zmailcloud.com> <755C73DF70A5217978F6B6A1@[192.168.1.30]> <20171016084524.GA877@arxnet.hu> <WM!43703ab56969c2acf0985d6545b4c4a3f566ea9735fb004c659aeac0800d62dba608b595cdc34bd0efd7fc93a125415f!@mailstronghold-1.zmailcloud.com> <583A73A35E7B9CE7720F7A3E@[192.168.1.30]> <20171016145543.GA31952@arxnet.hu> <WM!06ea65eea1dcb087206701e22b77d5ad04e2af551fca59e3cb00b5f379519dc31175976356f089d6f2ce91adaf043de9!@mailstronghold-3.zmailcloud.com> <CA63C67F317D0E55FF3B967F@[192.168.1.30]> <20171016150527.GA2973@arxnet.hu> <WM!791d0d501b38cc44efe2d1a77cca4da4d02b81ee6c538cc919735b367fcdd618e9417beb8698961701af2a6d3d96b1e1!@mailstronghold-1.zmailcloud.com>
--On Monday, October 16, 2017 6:05 PM +0200 Ervin Hegedüs
<airween@gmail.com> wrote:
Hm, yes, that's correct. You'll need to do something like utilize by *
break appropriately, or have multiple "access to userPassword" ACLs by
group, then a catchall after that.
I'm sorry - could you give me an example?
Sure, no problem. :)
One way to do it is to have an access line per subtree for those
attributes, adding the group permission, with a final access to just
userPassword itself limiting off all other access for anything outside of
those trees:
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu"
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
... Addtional subtree ACLs with groups for userPassword/shadowLastChange
access...
olcAccess: {#}to attrs=userPassword,shadowLastChange by self write by
anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read
olcAccess: {#}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: {#}to * by * read
The other option is to use "by * break", which tells slapd to continue
processing additional rules. If you do that, you'll need to be
particularly careful not to give access beyond what you intended. For that
purpose, I added a final ACL rule that says zero access to userPassword
prior to the "* by * read" ACL.
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 * break
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
... Additional subtree ACLs with groups ...
olcAccess: {#} to userPassword by * none
olcAccess: {#}to * by * read
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>