By Greg Keller Posted January 22, 2015
In my OpenLDAP directory I have a use case where I want a set of users to have special access rights. I want them to be able to read their peers’ information.
This could be done using a special group pretty simply, using a rule like
access to dn.exact="ou=Users,dc=jumpcloud,dc=com" by group.exact="cn=Administrators,dc=jumpcloud,dc=com" read
This is the classic “access to what by who”, which you can see more of in the OpenLDAP Access Control documentation. (A small quibble, shouldn’t it be “whom”?). This rule would let anyone in the Administrators group have read access to entries under the dc=jumpcloud,dc=com DN.
(Note that it only works for groups of type objectClass: groupOfNames. If the group is instead objectClass: posixGroup this doesn’t work.)
In our particular scenario, however, having a group control the access isn’t going to work for us. Instead, I want to grant access based on one of the user’s attributes.
This is where the ‘experimental’ concept of sets come in with our ACLs. Using a set we can specify that so long as my user has the attribute ‘employeeType’ with value ‘ldapAdmin’ that he read other users’ values.
access to dn.children="ou=Users,dc=jumpcloud,dc=com” by set="user/employeeType & [ldapAdmin]" read
Note that the “[“ and “]” around “ldapAdmin” are important — they cause it to be evaluated as exact text, instead of an attribute.
Now a user with that attribute can read anyone else under the Users DN.
However, since my directory is structured into separate organizations, this user should only have access rights to read into other users within the same organization. To make this work I’m going to use regex and the ‘expand’ clause to lock them into their same organization.
to dn.regex="ou=Users,o=([^,]+),dc=jumpcloud,dc=com" by set.expand="(user/employeeType + [,] + user/-1) & ([ldapAdmin,ou=Users,o=$1,dc=jumpcloud,dc=com])" read
Now I’m capturing the user’s organization, and I’m only granting access to users that are in the same organization.
This ‘set’ functionality in LDAP ACLs is very powerful and handy. I look forward to playing with it more in the future.