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

Re: Controlling access based on group membership



Am Tue, 21 Feb 2012 15:18:04 +0200
schrieb Nick Milas <nick@eurobjects.com>:

> On 21/2/2012 12:28 ÎÎ, Buchan Milne wrote:
> 
> > If you were to bind as the 'group'
> > cn=<someAdmins>,ou=Groups,dc=example,dc=com, this would work. But,
> > not if you bind as a 'member' of this group (which I believe is
> > what you want).
> 
> Buchan, Dieter, thank you for your feedback.
> 
> Yes, I would like to be able to bind as a user (i.e. a member of the 
> group) and not as the group itself. OK, now it's clear to me that it 
> won't work.
> 
> (Note: It seems to me that it would add a GREAT flexibility in
> privilege management if it would! Could this become a candidate for a
> feature request for future releases? What are your opinions, as more
> experienced LDAP admins?)
> 
> Could it work if the values of the AdminGroups attribute were not 
> standard groups (as those I have described until now), but a single 
> dynlist, returning user DNs? So, for example, we could define our 
> "AdminGroup" value using e.g. labeledURI of the form:
> "ldap:///ou=People,dc=example,dc=com?dn?one?(&(employeeType=admin)(ou=tech))" 
> ?

slapd.acces(5) expands group to group/groupOfNames/member as default,
but allows own definitions of objectclass and attribute, ssomething like

group/adminGroupOwnership/someAttribute=cn=<someAdmins>,ou=Groups,dc=example,dc=com
or you may add the dnstyle expand (group.expand=) in order to expand a
regular expression.

> Would this be expanded in ACLs of the form we discuss ("by 
> dnattr=AdminGroups write"), where AdminGroups now contains a single 
> dynlist entry as a value (and we want to bind as a user, not the
> dynamic "group")?
> 
> > What you want to do may be achieveable with sets
> > (http://www.openldap.org/faq/data/cache/1133.html).
> 
> I'll read about sets, thanks.

-Dieter

-- 
Dieter KlÃnter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53Â37'09,95"N
10Â08'02,42"E