Gallery

Altogether now...

Posted on 30 Mar 2009 at 15:43

Simon Brock shows how to put paid to the nightmare of multiple logins with the lightweight directory access protocol.

The key to our solution had to be a reliable and resilient LDAP server - or rather, in order to be resilient it needs at least a pair of LDAP servers. There are four main open-source LDAP servers: the OpenLDAP server; Sun's OpenDS; Red Hat's Fedora Directory Server; and Apache Directory Server. The latter three are all written in Java and hence will run on most platforms, while OpenLDAP is written in C and its preferred environment is Unix. A quick Google search also suggests there are some Windows ports out there. We haven't tried all these LDAP servers ourselves - we did try OpenDS but are now using OpenLDAP, because most other people use it. For example, the schema files that define what you can put in your directory tend to be written for OpenLDAP, and if you want to add them to other servers you may have to modify them: we did try a bit of this for OpenDS, but soon became bored and decided to go with the flow to OpenLDAP.

We had set it up in the past and hadn't found it a particularly easy system to look after, the problem being that the replication system that provides the resilience was pretty awful - very much a master/slave setup. If you lost your master server and failed-over changes to your slave it kind of worked, but we never felt comfortable with it. However, all this has changed with the 2.4 release, in which the previous slurpd mechanism has been completely replaced by something called Syncrepl. Without going into too much detail, we adopted the Mirror Mode setup in which two OpenLDAP servers are arranged so changes on one are replicated whenever the second polls the first - both simple and effective. There are various ways you can incorporate this into your network to ensure your systems see a consistent view, but simple failover will work.

Getting started

So what comes first, the directory or its contents? You need a directory before you can put anything into it, but on the other hand you need to know the shape of your contents before you can make a directory. Once you've set up your directory server then the final thing you need - but the first thing you should look for - is some form of management interface. The administrator needs a simple way to access all the information in the server and, just as importantly, your users need to maintain their own information. At the very least they're going to need the ability to change their own password.

Given the huge collection of services we want to manage via our directory server, we probably don't want a desktop app because not everyone will be using the same desktop PC, and a Mac user won't want to log in to a Windows box to change their password. A common interface means a web interface to the directory server, allowing both administrators and ordinary users access to information, and it should also administer as much as possible of the directory system in one place. There aren't many suitable web interfaces - there are a few that support low-level management of the directory server, but we found only one that enabled us to manage it the way we want, and that's called GOsa.

GOsa (www.gosa-project.org) has been around for several years, and it does have a reasonably large user base. The system is written in PHP and packaged for various forms of Linux, but the really important point is that GOsa requires its own way of structuring a directory so it can manage it, which means it needs its own schema files, and the ones it provides work with OpenLDAP. GOsa expects to find certain things in certain places in your directory tree, so getting the data right is important. When you set up GOsa, it helps you with this by putting things where it wants to find them. If you intend to use GOsa (and I recommend you do), make sure you do things in the GOsa way, which means using OpenLDAP and faithfully following the installation instructions, which I'll summarise here.