I've recently been trying to lock down Samba4's default ACLs, in it's generated LDAP backend configuration.
I have memberOf configured to 'error' on dangling links, which I need for Samba.
But I seem to be having some trouble with ACLs. I've attached my full config file, but the key part is:
access to dn.base="" by dn=cn=samba-admin,cn=samba manage by anonymous read by * read
access to dn.subtree="cn=samba" by anonymous auth
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by * none
If I change the last line to 'by * read', then the error is returned, but otherwise (due apparently to "" being unable to read the entry to validate it's existence).
Shouldn't the search operations happen as the rootdn or memberof-dn, or am I missing some other configuration element here?
In trying to fix this, I looked at what seemed to by typos in memberof.c, the patch of which I attach, but this didn't help.
Any thoughts?
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
In trying to fix this, I looked at what seemed to by typos in memberof.c, the patch of which I attach, but this didn't help.
Good catch, a clear example of malicious cut'n'paste. I'm fixing this, and looking at the rest of the issue in the meanwhile.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Andrew Bartlett wrote:
I've recently been trying to lock down Samba4's default ACLs, in it's generated LDAP backend configuration.
I have memberOf configured to 'error' on dangling links, which I need for Samba.
But I seem to be having some trouble with ACLs. I've attached my full config file, but the key part is:
access to dn.base="" by dn=cn=samba-admin,cn=samba manage by anonymous read by * read
access to dn.subtree="cn=samba" by anonymous auth
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by * none
If I change the last line to 'by * read', then the error is returned, but otherwise (due apparently to "" being unable to read the entry to validate it's existence).
Shouldn't the search operations happen as the rootdn or memberof-dn, or am I missing some other configuration element here?
Not sure I got the point, but what I'm sure about is that any check about dangling links is done while writing. The result of search operations is based on what values the link contain, statically. Apart from this, yes, internal ops are performed using the rootdn, in order to skip any issue related to access control.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
On Sat, 2008-07-19 at 11:33 +0200, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
I've recently been trying to lock down Samba4's default ACLs, in it's generated LDAP backend configuration.
I have memberOf configured to 'error' on dangling links, which I need for Samba.
But I seem to be having some trouble with ACLs. I've attached my full config file, but the key part is:
access to dn.base="" by dn=cn=samba-admin,cn=samba manage by anonymous read by * read
access to dn.subtree="cn=samba" by anonymous auth
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by * none
If I change the last line to 'by * read', then the error is returned, but otherwise (due apparently to "" being unable to read the entry to validate it's existence).
Shouldn't the search operations happen as the rootdn or memberof-dn, or am I missing some other configuration element here?
Not sure I got the point, but what I'm sure about is that any check about dangling links is done while writing. The result of search operations is based on what values the link contain, statically. Apart from this, yes, internal ops are performed using the rootdn, in order to skip any issue related to access control.
OK, so it's not some missing configuration (I could not see how it would be), but instead something else odd in that means that without the 'by * read' I cannot get the dangling link validated.
Hmm, I have the module loaded globally - perhaps I need a global rootdn of some kind defined?
I have one per-database (now), but the documentation strongly encourages one not to have a rootdn at all.
Andrew Bartlett
On Mon, 2008-07-21 at 08:44 +1000, Andrew Bartlett wrote:
On Sat, 2008-07-19 at 11:33 +0200, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
I've recently been trying to lock down Samba4's default ACLs, in it's generated LDAP backend configuration.
I have memberOf configured to 'error' on dangling links, which I need for Samba.
But I seem to be having some trouble with ACLs. I've attached my full config file, but the key part is:
access to dn.base="" by dn=cn=samba-admin,cn=samba manage by anonymous read by * read
access to dn.subtree="cn=samba" by anonymous auth
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by * none
If I change the last line to 'by * read', then the error is returned, but otherwise (due apparently to "" being unable to read the entry to validate it's existence).
Shouldn't the search operations happen as the rootdn or memberof-dn, or am I missing some other configuration element here?
Not sure I got the point, but what I'm sure about is that any check about dangling links is done while writing. The result of search operations is based on what values the link contain, statically. Apart from this, yes, internal ops are performed using the rootdn, in order to skip any issue related to access control.
OK, so it's not some missing configuration (I could not see how it would be), but instead something else odd in that means that without the 'by * read' I cannot get the dangling link validated.
Hmm, I have the module loaded globally - perhaps I need a global rootdn of some kind defined?
I have one per-database (now), but the documentation strongly encourages one not to have a rootdn at all.
The fix was to define rootdn globally (as the module operates globally), and then to give it explicit manage access in an ACL. eg
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by dn=cn=manager manage by * none
rootdn cn=Manager
Adding a rootdn to each database then quashed the warnings about 'rootdn can always manage'.
Shall I file an ITS?
Andrew Bartlett
Andrew Bartlett wrote:
The fix was to define rootdn globally (as the module operates globally), and then to give it explicit manage access in an ACL. eg
I didn't even know that was possible at all.
access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by dn=cn=manager manage by * none
rootdn cn=Manager
Adding a rootdn to each database then quashed the warnings about 'rootdn can always manage'.
Shall I file an ITS?
I need to investigate it a little bit more. But filing an ITS could be a starting point, as the issue could get hairy.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
openldap-technical@openldap.org
-
Andrew Bartlett -
Pierangelo Masarati