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

Re: Help with ACL's

On 05/06/09 21:29, Tyler Gates wrote:

On 04.06.2009 14:24, Tyler Gates wrote:
Tyler Gates wrote:
     I'm having a hard time setting some ACL's for my particular setup. I
have a structure as follows: dn: uid=*,ou=people,dc=example,dc=com #
uid contains several unix/linux user ids dn:
cn=*,ou=groups,dc=example,dc=com # cn contains several unix/linux
groups. uid's (not the complete dn) are supplied to the memberUid fields

What I would like to do is place an organizationalRole in each group
and have ACL's setup so that it's uniqueMembers have access to certain
attrs (say for example sn) for the uid's (which correspond to those in
ou=people) specified in the memberUid fields of the group in which the
organizationalRole is placed.

psuedo code would be something as follows:

access to
attrs sn by



you can use sets for this:

      access to dn.regex="^(cn=[^,]+,ou=groups,dc=example,dc=com)$"
         by set.expand="[cn=admin,$1]/memberUid&   user/uid" write


Hi Christian,
      I think I get the set's but that ACL doesn't work, and I'm not sure
if regex's or set's will even do the job. A conditional statement if
possible may be the only way.  Again I'm looking for members of an
organizational role
(cn=admin,cn=groupname,ou=group,dc=example,dc=com) placed in a group
(cn=groupname,ou=group,dc=example,dc=com) to be able to access ONLY the
people listed in that group
and nobody else. The people listed in that group are the memberUid and
should match up to the complete dn as defined in


You can use ACL sets to do this, as follows. I have adapted the example
to use organizationalRole's roleOccupant attribute, instead of memberUid.

access to dn.children="ou=people,dc=my-domain,dc=com" attrs=sn,entry
+ user/entryDN + [))])/entryDN)/-1)/memberUid&  this/uid" read

Quick description:
1) Find all entries under "ou=group,dc=my-domain,dc=com" that match the
user's DN>", and get their DN ("/entryDN") - this is all the admin
groups the current user is a member of.
2) For each of them, go up one level ("/-1"), thus getting the group
that they are an admin of.
3) Get the memberUid attributes of this group ("/memberUid")
4) Match them with the uid of the object we're trying to read.

See http://www.openldap.org/faq/data/cache/1133.html for more info on
sets syntax.

Of course, for this to work, you must allow auth access to the admin
user accounts, and search access to objects in ou=People.

Jonathan Clarke - jonathan@phillipoux.net
Ldap Synchronization Connector (LSC) - http://lsc-project.org

Holy hell, that works perfect! Thanks so much Jonathan!

No problem :)

But could you help me understand a portion of it a little better?
+ user/entryDN + [))])/entryDN)
The way I'm reading the set, that particular chunk seems unneeded
because the dn should already be expanded and ready for memberUid to be
stripped out by the remaining chunk.
Does it mean process each roleOccupant? And Why the '[))]'.

As you can see from the syntax, we're building up a ldap search URL here, of the form


So we have:
- base = ou=group,dc=my-domain,dc=com
- attrs = nothing
- scope = sub
- filter = (&(objectclass=organizationalRole)(cn=admin)(roleOccupant=DN))

The "[" and "]" operators indicate string literals.
The "+" operator concatenates strings.

So to build up the URL, we take the first part, concatenate "user/entryDN" and then concatenate the end of the filter "))".

However, the syntax in sets to perform a search is the following, as described in the FAQ page:

In other words, the search is only performed if a "/<attr>" is found at the end of the URL. This is why I add "/entryDN" after building up the search URL.

Last but not least, this does work for *all* groups the user is part of, since as sets' name indicated, they work on groups of elements. This works for one or many elements, and only for 0 will it refuse access.

Hope this clears some things up...