Re: problem with access by set and group membership (posixgroup, groupofnames)

[Pierangelo Masarati <ando@sys-net.it>]

Dr. Hansjörg Maurer wrote:

> I am trying to garnt users access to a group by there group membership.
> Because the groups are posixgroups and not groupofnames
> I have tried the following ACL's according to
> (running openldap-2.3.27-5)
> 
> http://www.openldap.org/faq/data/cache/1133.html
> and
> http://www.mail-archive.com/openldap-software@openldap.org/msg08524.html
> 
> access to dn.sub="cn=Domain Admins,ou=Groups,dc=byn,dc=drv"
>        by set="([uid=] + ([cn=domain
> admins,ou=groups,dc=byn,dc=drv])/memberUid  + [,ou=users,dc=byn,dc=drv])
> & user" write
>        by * none
> 
> or
> 
> by set="user/uid & [cn=Domain Admins,ou=Groups,dc=byn,dc=drv]/memberUid"
> write
> 
> The group has the folowing members
> 
> dn: cn=Domain Admins,ou=Groups,dc=byn,dc=drv
> memberUid: NetAdmin1
> memberUid: Netadmin5
> memberUid: NT_IEXPLORE
> memberUid: Siadmin
> memberUid: Netadmin3
> memberUid: NT_FSecure
> 
> but a search as uid=Netadmin3,ou=Users,dc=byn,dc=drv
> 
> does not succeedd

<snip>

> If I use something simple like
> by set="([uid=] + user/uid + [,ou=users,dc=byn,dc=drv]) & user " write
> in order to test if by set works, the search works

<snip>

> It seems that the
> ([cn=domain admins,ou=groups,dc=byn,dc=drv])/memberUid
> is not expanded to all members
> I have tried several cases (Groups or groups) with no success.
> 
> Is this the correct way of using posixgroups for ldap acl's?
> If not, what is the right way?
> If yes, what am I doing wrong?

I'm just guessing, as I realize that sets' logging is not enough to
investigate this type of issues (we may need to add some more verbose
logging about sets' expansion).  However, it seems to me that you're
intermixing uid and memberUid; the two have rather different syntaxes
and EQUALITY matchin rules:

- uid: directoryString and caseIgnoreMatch

- memberUid: IA5string and caseExactIA5Match

This may result in issues like: DNs containing an uid expanded from a
memberUid value are normalized according to uid's matching, and thus
lowercase; while DNs constructed using memberUid directly hold the value
with uppercase chars, thus failing the final case-sensitive match.  This
could explain why the second rule, which uses uid to build a DN that's
compared to the user's DN, works, while the first one, containing
memberUid values, fails.  And this is yet another example that shows why
using posix membership for access control "Is Bad" (TM).

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
Email:   pierangelo.masarati@sys-net.it
---------------------------------------