Apache Web Server (mod_auth_ldap)

Reader Rating    from ratings

The following text was modified by Novell. The original version is owned by Alexander Mayrhofer and is available on http://nona.net/software/ldap/compile/

This section describes how to enable authentication against a Directory Services using LDAP Authentication Module for Apache (mod_auth_ldap).

mod_auth_ldap

This module allows you to authenticate users against an LDAP tree. It is based on mod_auth_dbm. You can get the latest version of this module at http://nona.net/software/ldap/.

Compile with Apache

Prerequisites.  You need both Apache and mod_auth_ldap source archives. If you can't find Apache on your favourite ftp archive see http://www.apache.org. mod_auth_ldap is available at http://nona.net/software/ldap/. Additionally, you will need to have LDAP libraries installed, if you don't already have them, check out http://www.openldap.org for a free LDAP implementation. Finally, you need a working build environment on your machine.

Unpacking the stuff.  Unpack Apache as usual, and change into its "modules" directory:

% gzip -dc ../path/to/archive/apache_1.3.6.tar.gz | tar -xv<BR>
...
% cd apache_1.3.6/src/modules

Then, unpack the mod_auth_ldap archive into the modules directory.

% gzip -dc ../path/to/archive/mod_auth_ldap-0.5.tar.gz | tar -xv

Configuring, Building, and Installing.  Change into the newly created mod_auth_ldap directory, and configure the module itself (some parts of the sha algorithm are endian-dependent, and endianess is not checked by the Apache configure script, so the module comes with it's own autoconf script).

% cd mod_auth_ldap; ./configure

Now it's time to choose your favorite apache Config options, and additionally activate the LDAP authentication module.

% cd ../../..; ./configure --prefix=/var/apps/apache \
--activate-module=src/modules/mod_auth_ldap/mod_auth_ldap.c

After Apache has been configured, make and install it as usual:

% make
...
% make install

Configuring the module.  After installtion we need to configure it for operation. For general Apache configuration issues, refer to the Apache documentation. We will focuse on the directives introduced by mod_auth_ldap and associated standard directives.

In this exampe we want to protect the location "/internal" on our server, and use a LDAP directory to store user's credentials. Let's start by adding the following lines to our httpd.conf:

<Location "/internal">
AuthName "very confidential information"
AuthType Basic

Note:

Do this for any other type of password protection with Apache.

Now we tell mod_auth_ldap where it can reach our LDAP server(s) and how to bind to the directory:

AuthLDAPHosts "ldapserver otherserver:1234"

You can specify more than one LDAP server (as the line above shows), if you're doing this, multiple hosts have to be seperated by spaces. If one of the LDAP daemons doesn't listen on the standard port (389), you can add the port number as shown above. Of course, you can also use FQDN's and IP addresses.

By default, mod_auth_ldap tries to bind anonymously to the LDAP directory. If you want the module to use specific credentials for binding, you can do that by specifying them in the config section:

AuthLDAPBindDN "reader=web,type=access,o=nonanet,c=at"
AuthLDAPBindPassword abc123

Warning: Keep in mind that anyone being able to read those credentials may be able to use them to gain unauthorized access to your LDAP directory.

Double-check the permissions on the config file. Use the credentials supported by the browser by adding the following lines to the config:

AuthLDAPBindAsUser on
AuthLDAPBaseDN "type=luser,o=nonanet,c=at"
AuthLDAPUserKey lusername

The module will construct a DN like "lusername=<username>,type=luser,o=nonanet,c=at", and try to bind to the directory using that DN and the browser-supported password. If that succeeds, no more password checks are done, and the browser supported credentials are believed to be correct.

If we don't use "AuthLDAPBindAsUser" (and therefore didn't add the above lines to the config file), we'll now have to tell the module where and how to find the user's credentials in the LDAP directory. If all your users are at the same level of the directory (e.g. exactly one level below "type=luser,o=nonanet,c=at"), and they all have the same key in their RDN (e.g. "webuser=<username>", the story is rather simple:

AuthLDAPBaseDN "type=luser,o=nonanet,c=at"
AuthLDAPSearchScope base
AuthLDAPUserKey webuser
AuthLDAPPassKey webpassword

(The last line above tells the module that the user's password is stored in the attribute named "webpassword". The module will search below "webuser=<username>,type=luser,o=nonanet,c=at", in other words, it can directly "hit" the entry, which is fast, but sometimes not flexible enough.

Imagine, all your users are still below the same base DN as above, but some of them have different RDNs. For example, there may be one department storing all their users using the RDN "surname=<name>", maybe another department chose "extension=<number>". If all of those entries have their Web credentials stored in the same attributes (e.g. "webuser" and "webpassword" again), you will have to change one line of the config snippet above:

AuthLDAPSearchScope onelevel

If your users are *not* at exactly on level below the base DN, but scattered through a specific subtree, you can use:

AuthLDAPSearchScope subtree

Again, all those users need to have their credentials in the same attributes, once again "webuser" and "webpassword". We go now into comparing the password supplied by the browser against the value from the user's node in the LDAP directory.

If we're using AuthLDAPBindAsUser, the password check is being skipped, because the password has already been checked (hopefully) by the LDAP server. For clear text password strings (generally a very bad idea), you don't have to add anything to the configuration. If your password strings are crypted, you'll have to add

AuthLDAPCryptPasswords on

to your config snippet. Be aware, that if you have crypted passwords in the directory, and don't set this option to "on", users will be able to authenticate successfully using the crypted password string which my not be what you want.

There is a third alternative: use scheme prefixed passwords as described in RFC 2307. This seems to be the preferred method to store passwords in Netscape's directory server. You can enable scheme prefixed passwords by setting AuthLDAPSchemePrefix on.(Pretty straight forward, isn't it?) mod_auth_ldap will then be able to check passwords prefixed with "{crypt}" (Un*X crypt) and "{sha}" (Base64 encodced SHA1 digests as described in FIPS-180-1). Case of the prefix strings doesn't matter.

We've finally checked the user's password, we can open the gates. Expect if only members of specific groups are permitted to enter. In this case, we need to tell mod_auth_ldap the name of the attribute listing the user's memberships, by adding:

AuthLDAPGroupKey webgroup

and listing the user's groups comma separated

<Limit GET POST>
require valid-user
</Limit>

or

<Limit GET POST>
require group beerdrinking
</Limit>

before you close the Location with

</Location>

Bug Reports and Patches.  In case you found any bug, have a question, or did enhance the module, please drop me a mail at axelm+ldap@nona.net.

© Alexander Mayrhofer. The original version of this article is available on http://nona.net/software/ldap/compile/. The previous text was modified by Novell.