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 one part of the configuration that took us some time to figure out was how to set up Mirror Mode replication. To do this, you must set up a syncrepl provider in your configuration file, and to do this read the manual carefully and make sure you do exactly what it says. You'll also need to put some information into your server, so we followed the instructions in the Samba documentation to set up a few users, which involved using the smb-ldap-tools package to create all the users and groups for both Windows and Unix. The final stage of this process involved executing a command called smbldap-populate, for which you need to have your OpenLDAP server running.

If you've followed all the documentation you should now have created a single instance of an OpenLDAP server with some information in it, and before using it we recommend setting up replication. To do this, you'll need an LDAP query tool, of which there are many. We found various command-line interfaces hard to use, but settled for the Directory Studio from the Apache Directory Server project, which is available either as a standalone application or as a plug-in for Eclipse.

Once you have OpenLDAP running, connect into your LDAP server and browse its directory tree and edit records. To get replication up and running, you'll need to set up the Mirror Mode user from above, which you can do using the smb-useradd utility that comes in the tools package just mentioned. This made the user too general, because it included Unix and Windows components that we didn't need, but it did get the user set up. At this point, we stopped our LDAP server and took a backup using the slapcat command, then moved this file over to the other server and used slapadd to load a replica. Make sure you use slapadd's -w switch on the replicant to ensure that the replication is up to date for the new server.

Now for the moment of truth! We started both servers with debugging enabled and used the Directory Studio to make a small change to a record in one server, checked the log files and then checked the other server to be sure that change had been propagated. Once we were sure it was working one way, we then tried it the other way round. We did hit a couple of problems with this, but most of them boiled down to having set the options wrong in our slapd.conf.

And finally GOsa

Installing GOsa was a two-stage process: first install the software following the instructions on the website for our operating system, and then use a web browser to go to its setup page. Following the steps outlined on the website enabled us to set up our system, letting GOsa do all the things it wanted to do, and we were then able to log in as an administrator. If you install all the GOsa options, you'll soon see the scope of the facilities that GOsa can manage in the directory. The online documentation is the first place to look for more information, but here are two things from our experience that you'll need to know.

The first is the facility by which you create templates that are then used to create objects. For example, we've set up a user template to create an internal member of staff, which puts them into all the correct groups and the Windows domain. One particularly useful feature of this system is that the template can refer to other things in the directory - so, for example, we can set a user's email address based on a first name and surname provided earlier by writing %givenname.%sn@domain.co.uk in the appropriate field. The second feature you need to know about is Access Control Lists (ACL), without which your users won't be able to access GOsa. A key job you need to do here is set up an ACL, so your users can change their own passwords - there's an example on the website about allowing a user to change their mobile phone number, and if you copy this you should be okay.