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.

Requirements

To understand what we did, you first have to understand our requirement: we wanted every user to have the same username/password combination for every managed system. Our Linux and Solaris systems would be fine, since both can use LDAP for user information and both use the same schemas (despite being different in every other aspect of their setup). Our Windows systems would be more difficult, but we know we can set up Samba to talk to LDAP. Samba can become a Windows domain controller, so we can enable Windows single sign-on to a domain across all our Windows systems. That way, our Macs will be able to log in to Windows file servers, which might in reality be Unix systems.

There are other services we'd also like to be able to organise through LDAP: on Solaris, the LDAP service can be configured using LDAP - in other words, you can store the profile for your LDAP services in the directory itself, and a Solaris machine can fetch it and use that profile to configure the LDAP setup. Clever? Yes. Easy to set up given the Solaris manual? No. Also on the Unix systems we'd like to manage automount, a system by which each user's home directory can follow them around the different machines they login from - very similar to a Windows roaming profile. There's also a service called sudo that allows an ordinary user to execute a definable set of privileged commands as super-user. You can accomplish such things using groups and roles, but sudo remains a simpler and more overt method of obtaining the same result. Finally, we wanted the ability to add other systems we can administer via LDAP in the future - for example, to manage our Nagios servers and our RT Request Tracker system.

All this being the case, we were going to need to set up our OpenLDAP server with a complete collection of schemas for all these services, starting with the one that came with GOsa itself.

Making a start

The first thing was to set up our LDAP servers, which we decided to put onto a pair of Solaris machines running at different sites. We used OpenLDAP 2.4.11 from Sunfreeware, but if you're using Linux you may not be able to use the version with your distribution. Red Hat 5, for example, supplies only version 2.3.27, and that doesn't support Mirror Mode. However, packages are available from other places, and compiling one yourself is easy enough using the usual configure/make/make install combination. When configuring OpenLDAP, you have to create a slapd.conf file, and we'd recommend starting out from someone else's!

This configuration file is made up of several parts - a collection of schema files that define what this server will support. You should follow the documentation for GOsa here, to make sure you get all the schema files you need for the management interface. If you're running Solaris and want to use its auto-configuration feature, you'll need some extra schema files, and the best place to learn how to make them is at Gary Tay's homepage (http://web.singnet.com.sg/~garyttt/), which also offers good guides to setting up OpenLDAP on certain Linux systems. Unfortunately, that page doesn't detail how to set up Samba with an LDAP server, so you'll also need to read the Samba documentation - check out the chapter in Samba Guide called "Making Happy Users".

Once you've assembled your schema definitions, you should look at various examples to see how to set up the LDAP databases. The first thing you have to decide is the domain components for your database. Most examples say something like dc=example,dc=com, which you can change to your own needs, so dc=pcpro,dc=co,dc=uk will work. You'll need to set up a privileged user for your LDAP server, something like cn=Manager,dc=widearea,dc=co,dc=uk, and give them a password using the slappasswd command. Again, the guides tell you how to do this.