OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/5625
Full headers

From: abartlet@samba.org
Subject: memberOf search ACLs
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 23 Jul 2008 01:04:04 GMT
From: abartlet@samba.org
To: openldap-its@OpenLDAP.org
Subject: memberOf search ACLs
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)


Followup 1

Download message
Date: Mon, 20 Oct 2008 21:56:36 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: abartlet@samba.org
CC: openldap-its@openldap.org
Subject: 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
-----------------------------------


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org