Directory services made easy with Fedora Directory Server

457

Author: Paul Virijevich

Directory services play a vital part in today’s networks by helping administrators manage network users and resources. Until recently, the only choice for deploying a secure and easy-to-use open source directory server was OpenLDAP. While it gets the job done, it lacks the polish of commercial alternatives. Now Fedora Directory Server (FDS), Red Hat’s open source LDAP server, makes setting up an enterprise directory server on Linux simple.

FDS started its life in 1999 as the Netscape Directory Server. In 2004, Red Hat purchased Netscape Directory Server with a promise to make it open source. FDS is the fruit of that labor. Red Hat also sells a supported version, called Red Hat Directory Server, whose business model is to that of FDS as Red Hat Enterprise Linux is to Fedora Core. FDS does not come with any support options.

I decided to give FDS a try to implement single sign-on for a network of Linux computers. My only requirements were that the software I used be open source and easy to set up and administer. I chose FDS based on the second requirement, but the impressive feature list did not hurt either. Here are just a few of the key features as listed on the FDS project page:

  • Four-way multi-master replication, to provide fault tolerance and high write performance
  • Scalability: thousands of operations per second, tens of thousands of concurrent users, tens of millions of entries, hundreds of gigabytes of data
  • Secure authentication and transport (SSLv3, TLSv1, and SASL)
  • Active Directory user and group synchronization

FDS is meant to be installed on Fedora, Red Hat’s community-driven Linux distribution. If you’re hoping to install it on another Linux distribution, good luck. I used a Fedora Core 5 (FC5) install on an old PC. A default install of FC5 gives you everything you need except Java, which you can add easily. After that, FDS installation is painless. First, apply all security updates. Second, install Java. Third, install FDS:


yum update
chmod + x jre-1_5_0_09-linux-i586-rpm.bin; ./jre-1_5_0_09-linux-i586-rpm.bin
rpm -ivh fedora-ds-1.0.4-1.FC5.i386.opt.rpm

That’s it. FDS is now installed in /opt/fedora-ds.

Next, point Fedora Core to the correct version of Java. There is a symbolic link to GNU’s Java Runtime Environment (JRE) in /etc/alternatives. This version of Java will not run the FDS console; that’s why you have to install Sun’s JRE. Delete /etc/alternatives/java and create a link to the Sun JRE with:

ln -s /usr/java/jre1.5.0_09/bin/java /etc/alternatives/

Now, configure FDS for your environment by going to the /opt/fedora-ds directory and running:

./setup/setup

This launches an interactive setup script that asks a few questions about your environment. You can choose from an Express, Typical, or Custom install; I chose Typical. The installer will provide sensible defaults for all of its questions and provides good documentation on what each step is doing. All in all, it takes less than five minutes to set up the server. At the end of the process, you will see a message that looks something like this:

./startconsole -u admin -a http://localhost.localdomain:43131/

In this example, localhost.localdomain would be replaced by the hostname and domain name you entered during the setup process. The port number seems to be randomly chosen, so you will want to take note. This command launches the Java-based management GUI. Administration of FDS can be 100% graphical if you so choose.

Once the console is up, you are presented with two tabs, one labeled Servers and Applications, the other Users and Groups. The first provides management functions for both the Administrative and Directory servers. Particularly impressive is the backup feature under Directory Server. Just click the backup button, enter a directory, and in a few seconds you have a complete backup of all the LDAP information stored by FDS. Even better, a simple click of the restore button prompts for a directory containing the information you just saved. If you copy your backups to a remote server, restoring from scratch is as simple as copying back the data and restoring.

The Users and Groups tab is where most of the action is. Start by adding a user. FDS makes it pretty straightforward. The only things to take note of are the NT User and Posix User attributes. These allow FDS to act as a centralized login server for both Windows and Unix environments.

Try setting up a user named Bob Smith. His username, BSmith, will be filled in automatically when you enter the first and last names.

After setting up the user, go into the Posix User attributes. Here, you can set the user ID, group ID, home directory, and login shell of the user. Fill them in with 2222, 2222, /home/BSmith, and /bin/bash respectively. Make sure to use a user ID that is not in use. The 2222 for the group ID is just an example; you can go back and add the group later. This is everything you need setup for FDS to act as a centralized login server for this user.

The next step is configuring a client to access this server. On the client side, you need to do four things.

  • Install the nss_ldap and pam_ldap modules.
  • Modify the name service switch configuration file /etc/nsswitch.conf to
    allow LDAP.
  • Modify /etc/ldap.conf to suit your environment.
  • Modify the PAM settings for SSH to allow LDAP authentication.

It’s likely the nss and pam modules are already installed. Look for the files /lib/libnss_ldap.so.2 and /lib/security/pam_ldap.so. If you don’t find them, install the modules using your distribution’s package manager.

Modify /etc/nsswitch.conf to allow LDAP as an option. Change the password, group, and shadow directives to look like this:


passwd: files ldap
group: files ldap
shadow: files ldap

Next, edit the file /etc/ldap.conf to include the following:


base dc=localhost, dc=localdomain
host IP of host

Where localhost is the hostname of the FDS server, and localdomain is the LDAP domain you chose during setup. The host directive takes the IP address of the FDS server.

Finally, tell SSH to allow authentication from an LDAP source. To do this, add these three lines to the file /etc/pam.d/sshd:


auth sufficient /lib/security/pam_ldap.so
account sufficient /lib/security/pam_ldap.so
password sufficient /lib/security/pam_ldap.so

That’s all it takes for a basic FDS configuration.

You can now SSH into your client machine as BSmith with the password you set on FDS. Remember, we are using FDS only for centralized password information, so there may be no local home directory for BSmith. If that’s the case, the user is dropped into / and is not able to do a whole lot. You will want to create a home directory for BSmith on every machine he logs into, or store home directories on an NFS mount.

One thing I found surprising is FDS’s lack of supplied startup and shutdown scripts to have the service come up on boot. However, the scripts provided here seem to work just fine.

We really haven’t touched the surface of what FDS can do. This basic configuration proves that FDS works and shows off its ease of use. From this point on, you can explore the documentation on how to add other features.