[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5625) memberOf search ACLs

abartlet@samba.org wrote:
> Full_Name: Andrew Bartlett
> Version: CVS HEAD
> OS: Fedora 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (
>>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?


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it