Issue 5625 - memberOf search ACLs
Summary: memberOf search ACLs
Status: UNCONFIRMED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: 2.7.0
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-23 01:04 UTC by abartlet@samba.org
Modified: 2024-02-01 16:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description abartlet@samba.org 2008-07-23 01:04:04 UTC
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)

Comment 1 ando@openldap.org 2008-10-20 19:56:36 UTC
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
-----------------------------------

Comment 2 ando@openldap.org 2008-10-20 19:57:50 UTC
changed notes
changed state Open to Suspended
Comment 3 OpenLDAP project 2014-08-01 21:03:34 UTC
need a means to specify privileged internal operations
Comment 4 Quanah Gibson-Mount 2017-03-27 23:30:14 UTC
moved from Incoming to Software Enhancements