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

Re: ACLs by netgroup?

On Mon, 2006-02-06 at 10:20 -0800, samuel gipe wrote:

> Here's a more specific example of what I'd like to do:
> Suppose we have a manager whose DN is
> uid=benevolentmanager,ou=People,dc=example,dc=com
> and worker bees who report to benevolentmanager (earlier I referred to these
> people as 'reports').  Their DNs are:
> dn: uid=workerbee1,ou=People,dc=example,dc=com
> dn: uid=workerbee2,ou=People,dc=example,dc=com
> dn: uid=workerbee3,ou=People,dc=example,dc=com
> The workerbees are grouped in netgroups like so:
> # storage, Netgroup, example.com
> dn: cn=storage,ou=Netgroup,dc=example,dc=com
> objectClass: nisNetgroup
> objectClass: top
> cn: storage
> nisNetgroupTriple: (-,workerbee1,)
> nisNetgroupTriple: (-,workerbee2,)
> nisNetgroupTriple: (-,workerbee3,)
> and in Groups, like so:
> # storage, Groups, example.com
> dn: cn=storage,ou=Groups,dc=example,dc=com
> cn: storage
> objectClass: groupOfUniqueNames
> objectClass: top
> uniqueMember: uid=workerbee1,ou=People,dc=example,dc=com
> uniqueMember: uid=workerbee2,ou=People,dc=example,dc=com
> uniqueMember: uid=workerbee3,ou=People,dc=example,dc=com
> As you would guess, we also have many more managers, workerbees, netgroups, and
> groups.
> In slapd.conf, we currently allow 2 people to change the workerbees' passwords:
> manager and self.  "manager" is the ldap manager, not the benevolentmanager.
> slapd.conf looks like so:
> access to attr=userPassword
>         by self write
>         by dn.base="cn=Manager,dc=example,dc=com" write
>         by anonymous auth
>         by * none

This ACL is incorrect, as indicated everywhere in the documentation, if
by "ldap manager" you mean the "rootdn"; a correct one would be

access to attr=userPassword
        by self write
        by anonymous auth

> I'd like to expand access to attr=userPassword so that benevolentmanager may
> write the values of attr=userPassword for those workerbees reporting to
> him/her. 
> The best I can come up with is this:
> access   to
> dn.regex="uid=(workerbee1|workerbee2|workerbee3),ou=People,dc=example,dc=com"
>          attr=userPassword
>          by self write
>          by dn.base="cn=Manager,dc=example,dc=com" write
>          by dn.base="uid=benevolentmanager,ou=People,dc=example,dc=com"
>          by anonymous auth
>          by * none
> It is important to specify which of the workerbees' passwords our
> benevolentmanager may update, so that we don't give him/her excessive access.
> Specifying the workerbees' various DNs by regex works, but also has drawbacks. 
> Grouping the workerbees' DNs via regex is redundant with our existing groupings
> (in netgroups and groups)...and the redundant configurations open opportunity
> for configuration error.  Ideally,  we would specify the "what" portion of the
> ACL via netgroup.  To do so, I believe we need to use an ldapfilter to return
> the dn of each uid specified in a given netgroup.  Unfortunately, I haven't
> figured out how to do that.  Do you have suggestions?
> An alternative would be to use "groups" to specify the DN of the workerbees in
> the "to what" portion of the ACL.  Unfortunately,  that task also eludes me.  
> Do you have suggestions?
> In the "by who" portion of the ACL, I see that you can specify DNs by using
> groups (with the syntax below).   If the same capability existed for the "to
> what" portion of the ACL, it would be very convenient/useful (albeit more than 
>  what rfc2254 outlines).
> by
> group/groupOfUniqueNames/uniqueMember="cn=someGroup,ou=Groups,dc=example,dc=com"
> write 

I wouldn't consider netgroups right now; also, note that there's no need
to use groupOfUniqueNames; groupOfNames is more appropriate.  I'll also
assume that each group has a "owner" attribute containing the related
benevolent manager DN.  Let "cn=Group" be the DN of one of these groups.
An ACL that does what you need would be

access to attrs=userPassword
    by self =xw
    by set="([cn=group]/member & this) & ([cn=group]/owner & user)" =xw
    by * =x

If the name of the group can be partially inferred by the DN of the
"what" part, you may use a regex in the "what" part and an expand in the
set, namely

access to dn.regex="^cn=[^,]+,ou=([^,]+),dc=suffix" attrs=userPassword
    by self=xw
    by set.expand="([cn=Group,ou=$1,dc=suffix]/member & this) &
([cn=Group,ou=$1,dc=suffix]/owner & user)" =xw
    by * =x

In a more general case, you could do something like

access to attrs=userPassword
    by self =xw
    by set.expand="[ldap:///dc=suffix??sub?(&
(objectClass=groupOfNames)(member=$0))]/owner & user" =xw
    by * =x

Anonymous must have search access to the attributes used in the filter
of the URL.  This may be considered a bug or a feature; I think it's
debated whether low-level access to data required to compute aggregated
access rights should be granted by default or not.  I think this might
be changed if consensus is reached.  Note that since the entire DN of
the <what> is used in the filter, it is accessed by "$0" without the
need to use a regex style for the <what> part.


Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it