Writing access rules in OpenLDAP

Written by
Shubhra Prakash Nandi's picture

OpenLDAP is a popular open source lightweight directory access protocol server. It's available on many platforms like BSD, GNU/Linux, Windows and many UNIX flavors. It is used to setup directory services for an organization and/or for authentication purposes. Given it's purpose and the critical information which an OpenLDAP server holds, it becomes important to define correct access rules for it to allow only authorized access to information inside it.

Let's now see how an access rule looks like in OpenLDAP.

to dn.subtree="dc=example,dc=com" by dn.exact="cn=admin,dc=example,dc=com" manage by self read by * none

In OpenLDAP access is given to an entry's distinguished name (DN) in the directory with scope to one or multiple entities with the required privilege. For example in the above example dn.subtree keyword tells the server to grant access to DN "dc=example,dc=com" and all it's children entries like "uid=user@example.com,ou=IT,dc=example,dc=com".

Keyword by is used to specify entities who will have access to the DN like in the above example, access is provided to the entity who's DN is "cn=admin,dc=example,dc=com". Immediately after this the level of access given to the entity is specified for example manage in this case. There can be multiple by clauses in an access rule one each for a different entity. Keywords self, users can be used to specify special cases. When an entry and entity are the same self keyword can be used and when any bound entity (non anonymous entity) accesses the directory users can be used.

The last directive of by * none tells the server that if none of the previously specified entities match in the rule, then donot grant any privileges to any entity.

Access rules in OpenLDAP are executed in the order they are written. An access rule match happens when to clause is matched and not a combination of to and by clause. The default behaviour is, further processing of the access rules is stopped after the first match. This can be overridden by keywords break or continue. Break keyword allows further rules to be processed down the line after the current match and continue keyword allows more entities to be evaluated in a given access rule. If none of the access rules match then no privilege is granted unless specified by a default rule in the end of the list.

Let's see another example with some more options.

 to 
 attrs=userPassword,
 shadowLastChange 
 by 
 tls_ssf=256 
 ssf=256 
 peername.regex="10\.0\.0\..*|127\.0\.0\.1" 
 anonymous 
 auth 
 by 
 tls_ssf=128 
 ssf=128 
 peername.regex="10\.0\.0\..*|127\.0\.0\.1" 
 self 
 write 
 by 
 peername.regex=127\.0\.0\.1 
 dn.exact="cn=admin,dc=example,dc=com" 
 write 
 by 
 * 
 none

In the above example userPassword attribute which is used to store passwords in encrypted format and shadowLastChange which stores the days since epoch when userPassword attribute was last changed can be accessed for any entry by an anonymous user for authentication purposes but only when the anonymous user has established a TLS connection with the server with strength factor of 256 and is accessing the server from IP addresses which match the regular expression defined in peername.regex expression. Also it allows a bound user to change his/her password with the required TLS strength factor and IP address match and allows an admin user having DN "cn=admin,dc=example,dc=com" also to update passwords from localhost. Finally it denies all access to any other entity.

For more documentation and examples refer the following link http://www.openldap.org/doc/admin24/access-control.html

Zircon - This is a contributing Drupal Theme
Design by WeebPal.