Access module - using LDAP

Centralizing user/group management

Overview

This is a short tutorial on setting up the access module to interface with an external X500 LDAP server to provide centralized user/group management. Before working through this tutorial, webmasters should be very familiar with their LDAP setup, and using the access control module rules.

Configuration

First, setup your LDAP server. For the purposes of this tutorial, we used the OpenLDAP slapd server (http://www.openldap.org) with the following configuration:

Our `minimal' slapd.conf file contained:

  schemacheck     off
  database        ldbm
  suffix          "o=Zeus Technology, c=UK"
  directory       /tmp
  defaultaccess   read
  rootdn          "cn=root, o=Zeus Technology, c=UK"
  rootpw          secret

All access was disabled to the LDAP server unless the client provided the rootdn/rootpw. Different access control rules between the web server and your LDAP server will probably apply to your setup.

The database we used, in `ldif' format was:

  dn: o=Zeus Technology, c=UK
  o: Zeus Technology

  dn: cn=damian_reeves, ou=People, o=Zeus Technology, c=UK
  cn: damian_reeves
  userid: damian.reeves
  password: wXX9feG20NOWE

  dn: cn=adam_twiss, ou=People, o=Zeus Technology, c=UK
  cn: adam_twiss
  userid: adam.twiss
  password: fdsHKw4etXEHW

  dn: cn=appgroup1, ou=SecurityGroup, o=Zeus Technology, c=UK
  cn: appgroup1
  uniquemember: damian.reeves
  uniquemember: adam.twiss

  dn: cn=appgroup2, ou=SecurityGroup, o=Zeus Technology, c=UK
  cn: appgroup2
  uniquemember: damian.reeves

This defined two users, and also two groups. Each user is a member of `appgroup1', but only Damian is a member of `appgroup2'.

URLs for LDAP queries

The web server needs to be able to perform two queries to the LDAP server. First the web server needs to be able to find the password of a given user-name. Secondly, the web server needs to be able to find the groups to which a given user-name belongs.

These two queries are encoded in the standard LDAP URL format (see http://search.ietf.org/rfc/rfc2255.txt for a full specification).

Each URL can contain the special string $u, which is expanded dynamically to the user-name provided by the client.

The user->password query result should have 1 entry, with 1 attribute and 1 value. The value is used for the password. By default, this value is assumed to be a standard unix crypted password. However the password may be prefixed with a digest method, for example, `{digest method}xxxxx'. Digest methods currently supported are `crypt', `MD5' and `SHA'. Thus the password `abc' stored SHA encoded would look like {SHA}qZk+NkcGgWq6PiVxeFDCbJzQ2J0=.

The user->groups query result should have n entries, with 1 attribute and 1 value. The value(s) are used for the groups.

Using our example database schema above, and the knowledge that our test LDAP server was setup on a machine named `olympus', the URLs we need are:

ldap://olympus/o=Zeus Technology, c=UK?password?sub?userid=$u
ldap://olympus/o=Zeus Technology, c=UK?cn?sub?uniquemember=$u
The first URL will retrieve a password for a given user, the second URL will retrieve the list of groups a given member is in.

Thus for the user `damian.reeves', these two URLs would return

{
 {dn=cn=damian_neeves, ou=People, o=Zeus Technology, c=UK,
  {
   {attribute=password,{{value=wXX9feG20NOWE}}}
  }
 }
}
and
{
 {dn=cn=appgroup2, ou=SecurityGroup, o=Zeus Technology, c=UK,
  {
   {attribute=cn,{{value=appgroup2}}}
  }
 },
 {dn=cn=appgroup1, ou=SecurityGroup, o=Zeus Technology, c=UK,
  {
   {attribute=cn,{{value=appgroup1}}}
  }
 }
}
Which would mean `damian.reeves' has a password of wXX9feG20NOWE and is a member of both "appgroup1" and "appgroup2".

Setting up Zeus

Now we know the LDAP URLs we need to query the LDAP server, we are ready to configure the web server!