This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Directory services made easy with Fedora Directory Server

By Paul Virijevich on December 07, 2006 (8:00:00 AM)

Share    Print    Comments   

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:


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/ and /lib/security/ 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/
account sufficient /lib/security/
password sufficient /lib/security/

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.

Share    Print    Comments   


on Directory services made easy with Fedora Directory Server

Note: Comments are owned by the poster. We are not responsible for their content.

Directory newbs

Posted by: Anonymous Coward on December 08, 2006 12:13 AM
This might be fun to tinker with at home, but if you are going to deploy an enterprise class directory across linux with more than just a few thousand objects you should really consider eDirectory. I know a lot of people have some negative feelings right now towards Novell but if there is only one product they have that easily crushes any competition it's eDirectory. I've seen eDirectory trees with millions of objects that span thousands of servers in geographically distant places around the world and they are rock solid. When Redhat, or even M$ active directory for that matter, can boast something even close to that I might take a look at them for something larger than a small or medium business.


Re:Directory newbs

Posted by: Anonymous Coward on December 08, 2006 12:18 AM
Forgot to mention that eDir runs on Solaris, Unix, Linux, Windows, and Netware. It is the directory to beat, or imitate as the case is with MS AD.


Novell eDirectory? *HELL* NO!

Posted by: Anonymous Coward on December 08, 2006 06:25 AM
I wouldn't have considered Novell eDirectory even before this ridiculous patent agreement w/ Microsoft. Netscape Directory Server is what was used in the DoD for years, back when Netscape was still around, and it had similar scalability and stability that you're describing (remember the DoD is spread all over). Now that Red Hat has come in and modernized it further, I don't see any problem with it scaling to millions of objects.

Furthermore, unlike eDirectory, Fedora Directory Server, as the former Netscape Directory Server is now known, is now Free Software under the GNU GPL. I don't have to worry about the BSA coming with armed marshals and demanding an audit (<a href="" title=""></a>).

I don't see any advantage, stability-wise, scalability-wise, or freedom-wise, with going with eDirectory over Fedora/RedHat Directory Server. The patent deal that Novell made with MS just turns me off yet further than I already was about their LDAP offering.


Re:Novell eDirectory? *HELL* NO!

Posted by: Anonymous Coward on December 09, 2006 12:27 AM
Gotta agree with this one.


Re(1):Novell eDirectory? *HELL* NO!

Posted by: Anonymous [ip:] on September 07, 2007 02:17 AM
Me too.....If Novell wants to do this sort of deal, then Novell is a company I dont want to do a deal with....


Re: Novell eDirectory? *HELL* NO!

Posted by: Anonymous [ip:] on March 04, 2008 04:05 PM
Since this comment was written, a whole lot more about the Novell / Microsoft deal has submerged, and the parent poster as a lot others got the deal quite wrong. The deal includes things like Novell helping MS with .Net support on cross OS platforms (Mono), to run Silverlight, and much more.



Posted by: Anonymous Coward on December 08, 2006 02:13 AM
3 Redhat!

Thanks!<nobr> <wbr></nobr>:)


Some notes

Posted by: Anonymous Coward on December 08, 2006 06:14 AM
1) To install java on Fedora you should do it likes this: <a href="" title=""></a>
It adds an extra option to alternatives which enables you to switch between java runtimes.

2) Use the authconfig utility to enable ldap login in fedora/centos/rhel there is a cursus, gtk and commandline version of the program.


home directory

Posted by: Anonymous Coward on December 09, 2006 06:38 AM
If you want to create a home directory when they log in, you can add to your pam stack, and it will automatically create it when they log in.


OpenLDAP is the fastest and holds the most!

Posted by: Anonymous Coward on December 09, 2006 06:53 AM
"While it gets the job done, it lacks the polish of commercial alternatives."

You're joking! OpenLDAP is the fastest Directory in the world and can support hundreds of millions of entries and 150,000 searches per second!


Re:OpenLDAP is the fastest and holds the most!

Posted by: Anonymous Coward on December 11, 2006 08:44 PM
Maybe it's not that kind of polish he is referring to.


Re:OpenLDAP is the fastest and holds the most!

Posted by: Anonymous Coward on December 12, 2006 01:02 AM
You're right; he's looking for pointy-and-clicky GUI tools to do administration on it, kinda like an MCSE could handle. OpenLDAP works really well, and I've been using it for a couple of years (thanks due to David Trask for his HOWTO!).

That said, I'm glad to see Fedora Directory Server out there as well. Having more than one F/OSS, and solid, implementation of an LDAP directory is a good thing..


"create a home directory on every server"

Posted by: Anonymous Coward on December 11, 2006 04:28 PM
Is not really needed...

put this in you<nobr> <wbr></nobr>/etc/pam.d/system-auth

session required skel=/etc/skel umask=0022<nobr> <wbr></nobr>//jonas

PS: openldap has been doing this for a long time... LAM (Ldap Account Manager) will put some "polish" on it if you need to... DS


Directory services made easy with Fedora Directory Server

Posted by: Anonymous [ip:] on September 07, 2007 01:30 AM

Followed this using both local and remote clients and I get,

Sep 7 12:28:21 vuwunicvfdsm001 sshd(pam_unix)[20849]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= user=jonesst1
Sep 7 12:28:21 vuwunicvfdsm001 sshd[20849]: pam_ldap: ldap_simple_bind Can't contact LDAP server

Suggesting there is a step missing in your article or it only applies to earlier FDS versions...


Directory services made easy with Fedora Directory Server

Posted by: Anonymous [ip:] on September 26, 2007 07:22 AM
Ya,I too received the same error.Is something missing from Docuement.Plz help to get rid of this error.


Directory services made easy with Fedora Directory Server

Posted by: Anonymous [ip:] on October 01, 2007 11:48 AM
Its not working !!! I think something is missing here.I dont see any output from #getent passwd in the client Side


'proper' alternatives command?

Posted by: Anonymous [ip:] on October 01, 2007 11:56 PM
I set the alternatives 'properly' using these commands:

% alternatives --install /usr/bin/java java /usr/java/default/bin/java 1602 --slave /usr/bin/keytool keytool /usr/java/default/bin/keytool --slave /usr/bin/rmiregistry rmiregistry /usr/java/default/bin/rmiregistry --slave /usr/bin/javaws javaws /usr/java/default/bin/javaws

% alternatives --auto java

notes: /usr/java/default is a symlink created by sun jre 1.60u2 - point it to wherever the sun jre is

notes2: 1602 needs to be higher than the installed gcj java priority (mine is 1420)


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya