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: [EMAIL PROTECTED] ---------------------------------------