Fedora Directory Server: the Evolution of Linux Authentication

Check out Fedora Directory Server to authenticate your clients without licensing fees.

In most enterprise networks today, centralized authentication is a basic security paradigm. In the Linux realm, OpenLDAP has been king of the hill for many years, but for those unfamiliar with the LDAP command-line interface (CLI), it can be a painstaking process to deploy. Enter the Fedora Directory Server (FDS). Released under the GPL in June 2005 as Fedora Directory Server 7.1 (changed to version 1.0 in December of the same year), FDS has roots in both the Netscape Directory Server Project and its sister product, the Red Hat Directory Server (RHDS). Some of FDS's notable features are its easy-to-use Java-based Administration Console, support for LDAP3 and Active Directory integration. By far, the most attractive feature of FDS is Multi-Master Replication (MMR). MMR allows for multiple servers to maintain the same directory information, so that the loss of one server does not bring the directory down as it would in a master-slave environment.

Getting an FDS server up and running has its ups and downs. Once the server is operational, however, Red Hat makes it easy to administer your directory and connect native Fedora clients. In addition to providing network authentication, you easily can extend FDS functionality across other applications, such as NFS, Samba, Sendmail, Postfix and others. In this article, we focus solely on using FDS for network authentication and implementing MMR.


To begin, download a Fedora 6 ISO readily available from one of the many Fedora mirrors. FDS has low hardware requirements—500MHz with 256MB RAM and 3GB or more space. I recommend at least a 1GHz processor or above with 512MB or more memory and 20GB or more of disk space. This configuration should perform well enough to support small businesses up to enterprises with thousands users. As for supported operating systems, not surprisingly, Red Hat lists Fedora and Red Hat flavors of Linux. HP-UX and Solaris also are supported. With your bootable ISO CD, start the Fedora 6 installation process, and select your desired system preferences and packages. Make sure to select Apache during installation. Set your host and DNS information during the install, using a fully qualified domain name (FQDN). You also can set this information post-install, but it is critical that your host information is configured properly. If you plan to use a firewall, you need to enter two ports to allow LDAP (389 default) and the Admin Console (default is random port). For the servers used here, I chose ports 3891 and 3892 because of an existing LDAP installation in my environment. Fedora also natively supports Security-Enhanced Linux (SELinux), a policy-based lock-down tool, if you choose to use it. If you want to use SELinux, you must choose the Permissive Policy.

Once your Fedora 6 server is up, download and install the latest RPM of Fedora Directory Server from the FDS site (it is not included in the Fedora 6 distribution). Running the RPM unpacks the program files to /opt/fedora-ds. At this point, download and install the current Java Runtime Environment (JRE) .bin file from Sun before running the local setup of FDS. To keep files in the same place, I created an /opt/java directory and downloaded and ran the .bin file from there. After Java is installed, replace the existing soft link to Java in /etc/alternatives with a link to your new Java installation. The following syntax does this:

cd /etc/alternatives
rm ./java
ln -sf /opt/java/jre1.5.0_09/bin/java java  

Next, configure Apache to start on boot with the chkconfig command:

chkconfig -level 345 httpd on

Then, start the service by typing:

service httpd start

Now, with the useradd command, create an account named fedorauser under which FDS will run. After creating the account, run /opt/fedora-ds/setup/setup to launch the FDS installation script. Before continuing, you may be presented with several error messages about non-optimal configuration issues, but in most cases, you can answer yes to get past them and start the setup process. Once started, select the default Install Mode 2 - Typical. Accept all defaults during installation except for the Server and Group IDs, for which we are using the fedorauser account (Figure 1), and if you want to customize the ports as we have here, set those to the correct numbers (3891/3892). You also may want to use the same passwords for both the configuration Admin and Directory Manager accounts created during setup.

Figure 1. Install Options

When setup is complete, use the syntax returned from the script to access the admin console (./startconsole -u admin http://fullyqualifieddomainname:port) using the Administrator account (default name is Admin) you specified during the FDS setup. You always can call the Admin console using this same syntax from /opt/fedora-ds.

At this point, you have a functioning directory server. The final step is to create a startup script or directly edit /etc/rc.d/rc.local to start the slapd process and the admin server when the machine starts. Here is an example of a script that does this:

/opt/fedora-ds/start-admin &



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

fds with ldap

manohar's picture

i m done with installing FDS successfully.
can please help how can i authenticate the windows users using FDS.

Password policy problem between FDS and ADS

selvakumar.a's picture

I have configured FDS and Syncronized with ADS.Every thing working fine.The password also syncronized between FDS server and ADS.When I change the password in windows client it is replicated to the FDS through ADS.But when I change the password in Linux client machine it does not replicated to the ADS. I need some clarification between FDS and ADS password policy.I hope some one will guide me.Thanks in advance.

el fedora es de maricones

Brunito's picture

es re penca la wea de fedora ds
es como una agenda ql
mas dificil de usar la mierda
ademas que el guru guru ql

LDAP isn't best suited for authentication

Anonymous's picture

Just to note, the directory usage that you describe (using LDAP for authentication) is a painfully wide-spread misconception.

Properly, you should use LDAP for publishing authorization data (e.g. group memberships), while authentication should be best implemented with use of Kerberos protocol.

By using LDAP for authentication, you throw away the possibility to provide single sign-on for your users.

You can use the Heimdal Kerberos server to store the data used by it in an LDAP directory - provided that it supports LDAPI connections and, as a result, it resides on the same machine that the LDAP server.

The version of Fedora Directory Server from CVS supports LDAPI.

BTW, IMHO the Kerberos and LDAP protocols should be merged in the future since they are so easily misused because of the distinction between them.

merge LDAP and Kerberos. LDAP

Anonymous's picture

merge LDAP and Kerberos. LDAP is a fully fledged directory access protocol not just an authentication widget. This is like saying SQL should be merged with Kerberos.

BTW, LDAPI support is now

Anonymous's picture

BTW, LDAPI support is now available with the latest stable version 1.1 of Fedora Directory Server.

Updating Alternatives (for Java and such)

Christopher Cashell's picture

Just a note, Red Hat provides a command, update-alternatives, for updating and maintaining links in /etc/alternatives.