Creating my own LDAP Directory – part 2

Introduction

In part 1 I talked about installing OpenLDAP on FreeBSD, creating a basic DIT, inserting some useful data and using this data as an address book in Mozilla Thunderbird.

In this part I’ll describe how to use the information stored in LDAP to authenticate sessions in Apache.

But before I do that, I want to let you in on how to change information you uploaded into your LDAP.

Changing and deleting information

Normally this is done with ldapmodify, and ldif files, just like ldapadd works. In fact, ldapadd IS ldapmodify.

Say, if I wanted to delete an object (with all its attributes), I would create an ldif file, and put something in like this:

dn: cn=Unwanted Dude,ou=people,dc=boosten,dc=org
changetype: delete

The command ldapmodify -f thefileyoujustcreated would remove the object entirely.

Modifying information would work the same way:

dn: cn=Peter Boosten,ou=people,dc=boosten,dc=org
changetype: modify
add: title
title: Cool Dude

One could combine these into one ldif file.

While this is quite useful, I think having a utility around that is kinda graphical would enlighten my job. There are many free tools around, but I like ldapbrowser. This small tool is quite old, as far as I can tell not maintained anymore, based on Java, but still handy. With this tool you can add all objects you want, however you need to create templates for that. ldapbrowser can be downloaded here. If it doesn’t seem to be connecting to your LDAP server, don’t forget to switch to LDAP version 3.

Compiling Apache

In order to use LDAP authentication from within Apache, you will need to add the modules for LDAP authentication in the configuration (if not done already). Since I’m using FreeBSD I’ll only talk about installation from the ports collection, however installing Apache from source is quite easy.

If you already installed Apache, you will have to reinstall. I use portupgrade for that, but other tools can be used as well. My installation is based on Apache 22, I haven’t tested this with older versions of Apache.

The first thing to do is to go to the Apache port:

cd /usr/ports/www/apache22

and configure it:

make config

apache1

Make sure you checked the LDAP and AUTHNZ_LDAP options. Other options could be checked as well, but are left out of this picture.

In a fresh installation you would

make all install clean

but in my situation I did a

portupgrade -f apache22

This forced a reinstallation (including the new modules) for Apache. When (re)installation is done, you will have to modify the configuration file /usr/local/etc/apache22/httpd.conf and add the two modules:

LoadModule authnz_ldap_module libexec/apache22/mod_authnz_ldap.so
LoadModule ldap_module libexec/apache22/mod_ldap.so

Restarting Apache is necessary to load these modules. I found that issueing an

apachectl graceful

would crash my httpd processes, not to come back again. So you better can issue an

/usr/local/etc/rc.d/apache22 restart

This will completely shutdown httpd and start a fresh one. Apache is now ready to do some LDAP authentication.

.htaccess or Directory?

From a LDAP point of view this is really the same: one could put the authentication information in one of both, but to make Apache read .htaccess files, you would have to issue some overrides in the configuration file (AllowOverride). I use both configuration options.

The commands needed in either are:

AuthName "Private Directory"
AuthType Basic
AuthBasicAuthoritative Off
AuthzLDAPAuthoritative off
AuthBasicProvider ldap
AuthLDAPURL "ldap://ra.boosten.org/dc=boosten,dc=org?uid?sub"
Require ldap-user peter

According to the Apache documentation this would be enough:

AuthName "Private Directory"
AuthType Basic
AuthLDAPURL "ldap://ra.boosten.org/dc=boosten,dc=org?uid?sub"
Require ldap-user peter

however, this didn’t work.So after some googling I found the right combination. What I basically do is tell Apache to ask LDAP only.

That brings me to that part. The AuthLDAPURL entry tells Apache where to look for the information needed. In my case it tries to connect to ra.boosten.org, and implicitely on port 389 (the default port for LDAP). It knows about port 389, because I wrote ldap:// in front of it. If you configured TLS, then it would have been ldaps:// (I will do that in a later stage) and it would connect to port 636. If you configured (normal) LDAPon port 2000, then the connection string would look like this:

ldap://ra.boosten.org:2000/...

After the last forward slash (/) there’s some more information:

dc=boosten,dc=org?uid?sub

This information tells Apache where to look further, and what to look for:

it start searching at dc=boosten,dc=org. As you may remember, there were two Organizational Units underneath that level: ‘ou=people’ and ‘ou=groups’. I do not yet use groups for authentication, but I might in future, so I took them already into account.

The next part of the string tells Apache what to look for: the uid, or UserID. Each of my objects have an uid, and mine is peter. You might even search for email, or cn if you like, but you will have to adjust your authentication requests accordingly: if I use cn to authenticate, I would have to enter ‘Peter Boosten’ as login name, if I used email, I would have to enter ‘peter@boosten.org’. Since I use uid, I just enter ‘peter’.

I found the cn authentication rather cool, but it messed up my Apache logfiles (and the scripts I’m running on it’.

The last part of the string tells Apache how deep to look for the information needed: ‘sub’ means ‘search as deep as you need’. The other possible value would be ‘one’: ‘search one level deep’. ‘sub’ is the default, so I really didn’t have to mention it at all.

After you tell Apache where to look and what to look for, you have to tell it (him/her?) who’s actually authorized to see the information you’re trying to hide in the first place. In my example I only want me to look at it:

Require ldap-user peter

More users can be added to such a Require statement:

Require ldap-user peter john sue

You could even grant everyone access:

Require valid-user

This concludes this part.

This entry was posted on Wednesday, November 26th, 2008 at 11:00 pm and is filed under freebsd. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

boosten.org