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