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.

At work we use desktop Linux, Mac OS X and Windows machines that talk to Linux, Solaris and Windows servers, offering an ever-increasing collection of services - each of which requires its own username and password. We've ended up with an explosion in the number of usernames and passwords needed to complete our every day work. Add in all the sysadmin passwords and you end up in a mess: what sort of mess depends on how disorganised/useless/over-worked/rushed you were to start with, but a mess it will be. This mess will manifest itself one of two ways:

1) You discover that people aren't logging on as themselves but as someone else. Reason: it's easier than setting up the person with their own username. Result: something will break and no-one will have any idea how it happened or who did it. I'm not saying that giving users their own usernames is a good idea because it makes witch-hunting easier; if you give people their own usernames they tend to remember things better.

2) You discover that the administrator or super-user password is the same on every machine, which leads back to 1) as people log into each machine as administrator "because it's easier to remember".

At this point, good Windows sysadmins will be muttering to themselves "Windows domains" or "Active Directory", as indeed you should, because both offer solutions to the problem we're talking about here - some kind of Single Sign On (SSO) scheme. However, we wanted to include our Unix systems so they can all be managed together, and since this is the Open Source column we need to provide an open-source solution. Now, if you were also thinking "LDAP", you'd be right on target. In this column I'm going to outline how to implement an open-source SSO log-on system based on LDAP that will do Unix logins, Windows logins and more. And it will be easy to manage!

What is LDAP?

LDAP means Lightweight Directory Access Protocol, and it's the basis of many systems that organise resources into directory structures. LDAP forms part of Windows Active Directory and is used in most public address book systems. A full description of the protocol is well beyond the scope of this article, but a short introduction would make sense.

An LDAP server enables access to directories organised in a tree structure, and at every point of the tree there can be a collection of attributes describing what that part of the directory contains. A directory is based at a particular namespace defined by its Domain Component: if we were setting up a directory for PC Pro, this would probably be something like dc=pcpro,dc=co,dc=uk. Within that namespace are folders called Organisational Units (ou) and, typically, all the users' details are held in an ou called people, so the staff of PC Pro would be in ou=people,dc=pcpro,dc=co,dc=uk. Every entry in the LDAP directory has a Distinguished Name (dn), which is made up of from these folder attributes, so my own dn among the people who work for PC Pro would be something like:

dn: cn=Simon Brock, ou=people,dc=pcpro,dc=co,dc=uk

Using these distinguished names we can create folders of entries, where each entry is defined by a schema that says what attributes it can have. These schemas are called ObjectClasses, and a user who can login to a Windows system, say, needs to include the definitions from the sambaSamAccount schema to work with Samba Windows networking. These schemas are essential to the operation of the LDAP server.

First choose your LDAP server