Fedora Directory Server on RHEL 4 and 5, Pt. 1

The last time I had to do a NIS->LDAP migration, it was in a heterogenous environment with Solaris and Linux boxes, and it was around 2004 or so. Although I hit some rough patches adjusting to changes in how FDS is packaged, the community was awesome, and helped me get back up to speed in no time. We shouldn’t forget that the community was what drove me from OpenLDAP to FDS in the first place.

But I digress. The purpose of this article (first of a series) is to share with you some technical information about how to get things going. How, exactly, do you get RHEL 4, and RHEL 5 to utilize Fedora Directory Server’s data to support NSS and PAM for user information and authentication, and autofs for automounting directories? There are documents on this, written by people who clearly do (or did) care, but at times they can be a little disjointed, a little outdated, and require some tweaking.

This document talks specifically about installing the fedora-ds-1.1.2-1.fc6 package on RHEL 5.2, populating the People and Groups trees, and testing that it actually works. Later posts will deal with getting RHEL 4 and 5 clients to talk to it for various purposes, using TLS (with certificate verification, btw).

If your real issue is understanding how LDAP data works, why it looks the way it does, or you need a refresher, I would urge you to look at two other articles I wrote for O’Reilly, devoted completely to the topic: here, and here.

Get it installed

There is no precompiled binary package of Fedora Directory Server built specifically for Red Hat
Enterprise Server (because Red Hat, of course, provides that, with support, for a fee). If you want to run FDS for free on a RHEL server, the installation process is somewhat non-trivial.  First, you must add a couple of new package repositories to your yum configuration:

cd /etc/yum.repos.d/
sudo wget http://directory.fedoraproject.org/sources/idmcommon.repo
sudo wget http://directory.fedoraproject.org/sources/dirsrv.repo

Then, you’ll need to import a couple of keys in order to verify signatures of the packages we’ll install
later:

sudo rpm --import \
http://archives.fedoraproject.org/pub/archive/fedora/linux/core/6/i386/os/RPM-GPG-KEY-fedora
sudo rpm --import \
http://archives.fedoraproject.org/pub/archive/fedora/linux/core/6/i386/os/RPM-GPG-KEY-Fedora-Extras

Next, install some prerequisite packages (you could do this first – these come from standard
repositories, not the new ones we added):

sudo yum install svrcore mozldap perl-Mozilla-LDAP libicu

You’ll need jss, and I wasn’t able to get it via a repository, so I downloaded it using a URL directly:

sudo rpm -ivh http://download.fedoraproject.org/pub/fedora/linux/extras/6/x86_64/jss-4.2.5-1.fc6.x86_64.rpm

Next, install ldapjdk (used by the FDS console application), and finally, the directory server itself:

sudo yum install ldapjdk
sudo yum install fedora-ds

WIth these packages installed, the next thing to check is that permissions are set up correctly, otherwise the initial setup script will fail:

sudo chown -R nobody:nobody /var/lock/dirsrv; sudo chmod -R u=rwX,go=
/var/lock/dirsrv
sudo chown nobody:nobody /var/run/dirsrv; sudo chmod -R u=rwX,go= /var/run/dirsrv

Finally, run the setup script which was installed with the fedora-ds package:

sudo /usr/sbin/setup-ds-admin.pl

Populating the Direcotory

The directory initially consists of a top-level entry representing the domain, and by default, FDS creates for you two “organizational units”, which are subtrees representing “People” and “Groups”. I’ll create an LDIF file for the Groups first, but there’s no reason to go in any particular order. We’re just adding data, and LDAP isn’t relational: you can add People objects who are members of Groups that aren’t in the tree yet. Here’s my LDIF file for the groups:

dn: cn=wheel,ou=Groups,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: wheel
gidNumber: 1000
memberUid: jonesy
memberUid: tasha
memberUid: molly 

dn: cn=eng,ou=Groups,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: eng
gidNumber: 1001

For the moment, only ‘wheel’ contains any actual members. No biggie, you can add members to groups later, or add more groups later whenever you want. Once the clients are configured, there’s no restarting of anything to get them to pick up changes to data in the LDAP data.

It’s easy to use the OpenLDAP tools to add data to FDS, but I’m going to use the FDS-supplied tool here to insert this data:

/usr/lib64/mozldap/ldapmodify -a -D "cn=Directory Manager" -w - -h localhost -p 389
-f ~/groups.ldif -c

If you’re familiar with the OpenLDAP tools, this probably doesn’t look too scary. The OpenLDAP tools require a ‘-x’ flag to bypass SASL. Aside from that, pretty straightforward.

To populate the “People” tree in FDS, or any other LDAP product, I wrote a really cheesy awk script that I can pipe the contents of /etc/passwd or ‘ypcat passwd’ through and get good results with only minor tweaking. Redirect the output to a file called ‘people.ldif’, and then you can populate your “People” tree:

/usr/lib64/mozldap/ldapmodify -a -D "cn=Directory Manager" -w - -h localhost -p 389
-f ~/people.ldif

At any time, you can verify that your FDS installation is returning results by running a query like this:

/usr/lib64/mozldap/ldapsearch -b dc=example,dc=com objectclass=organizationalUnit

I have a few more posts to follow this one. One is one getting SSL/TLS working (either one, perhaps both), creating a root CA and setting things up with certutil, another on getting the RHEL 4 and 5 clients to use LDAP, and another separate one for configuring autofs to talk to LDAP, which is a little different between RHEL 4 and 5. Subscribe to this blog in your reader to be updated as those posts come out over the next 2 weeks.

  • Marco Rojas

    I would be interested in learning how to join a windows or authenticate anything to FD. I already installed it on a CentOS 5.3 but my windows machine can’t join the domain. No SRV record found.

    Thanks.

  • m0j0

    You have the wrong product :)

    FDS is not a domain controller. You’re looking for the Samba project, not FDS (or 389 – the new name for FDS). See http://samba.org for information about running a Linux Domain Controller. Once you have a working domain controller, you *can* connect it to your FDS installation to authenticate users if you wish.

  • Marco Rojas

    Thank you very much for your prompt response. Can you give me an example where FDS can be used? I am using Windows Active Directory to authenticate users to some applications like alfresco and Moodle (using LDAP), for that I should be able to use FDS right? I guess I don’t need it as a domain controller if I can accomplish the above.

    Thanks you again.

  • m0j0

    Alfresco and Moodle both use “generic” LDAP authentication, which you can do very easily with FDS (or OpenLDAP, or eDirectory, or any other LDAP server). The idea of domain membership is somewhat separate from the idea of authentication. If all you need is authentication, either AD (which, at the protocol level, is LDAP) or FDS will work. It’s only when you specifically require domain membership that you need anything else.

    A more precise answer, of course, requires more information about the problem. As this isn’t a support forum (per se), I recommend joining the samba and/or FDS mailing lists and irc channels to get the help you need — not because I’m too lazy to answer, but because others who might need the same type of information are more likely to find it on a mailing list than in the comment section of my blog :)

    Good luck!