[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) (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
-----------------------------------