abartlet@samba.org wrote:
Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137)
From thread on opendlap-technical:
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'.
Otherwise, if I had 'by * read' then this also allowed the module to operate correctly (but without the secrecy I desired)
Few considerations:
1) having a rootdn in the global database (technically, in the frontend database) is not a bad thing, since it manages no data. Moreover, having a rootdn without password means that unless anyone can authorize as it (authzTo, authz-regexp and so) there is no way anyone can take that identity. As a consequence, it's there only for the purpose of performing internal operations with a privileged identity. We have discussed many times about the possibility to define a per-operation, possibly per-database flag that states the operation is being performed as a privileged identity, but so far we sticked with the rootdn as the client's identity.
What comes to my mind right now is that we could define special interfaces for internal operations, something like sockurl=privileged:// to indicate internal operations; in those cases, an otherwise anonymous operation could be identified as privileged and thus bypass access control much like it would without the need to set a rootdn.
2) you don't need to add "by dn=cn=manager manage" to global ACL rules, since that's implied. This allows you to get rid of the warning messages. You'll need to add it to rules within each database, unless cn=manager is also the rootdn of those databases.
3) adding "by dn=cn=samba-admin,cn=samba manage" to all access rules can be annoying, but that's the right way, IMHO, to deal with your specific problem; you could work it around by adding a rule like
access to * by dn=cn=samba-admin,cn=samba manage by * break
early enough in each database's ACLs (right after the rule that allows anonymous to bind :) This rule seems a bit to open, since it gives cn=samba-admin,cn=samba privileges comparable to those of a global rootdn. Perhaps you want to restrict them to what data is actually pertinent to Samba4?
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 -----------------------------------