Use Fedora Directory Server For Manageable LDAP (Part 1)

By: Carla Schroder
Monday, August 28, 2006 10:59:27 AM EST
URL: http://www.linuxplanet.com/linuxplanet/tutorials/6303/1/

What Is LDAP?

Raise your hand if you've had this conversation with your buzzword-vulnerable boss:

PHB: "We need to move to LDAP."
Long-suffering admin: "For what exactly?"
PHB: "We need to move to LDAP."

So, before we get into exploring the wonders of Fedora Directory Server, let's give that question a meaningful answer. Why should you consider using LDAP? Here are some nice tidy bullet points to consider:

  • You have a lot of fairly static data to access
  • You want to store this data in a cross-platform future-proof format
  • You want this data to be available to many different applications
  • Your data do not need a full-blown relational database, but will fit nicely in a flat table

What sort of data does this include?

  • User data, like profiles, preferences, email addresses, and logins
  • Customer contacts
  • SSL certificates
  • Asset tracking

Perhaps you want other features like blazing-fast performance and single-sign-on authentication. LDAP is optimized for fast read-speeds, far faster than any other type of data store, and lends itself nicely to cross-platform single-sign-on. Yes, you can even make Windows play nice, no matter how much it doesn't want to.

Terminology pedants go all nutso over incorrect expressions like "LDAP database" and suffer dangerously high blood pressure as a result, so let's be nice to the pedants and use the correct words. LDAP--Lightweight Directory Access Protocol--is a protocol that stores and retrieves information from a directory, which for both OpenLDAP and Fedora Directory Services is stored in a Berkeley DB. I think you're pretty safe using "LDAP directory" as a shortcut.

LDAP is TCP/IP-aware and widely supported. These days it's unusual to find network applications that don't support it. This means you won't need special client software to access an LDAP directory.

Fedora Directory Server

Whatever your primary computing platform is, chances are you're going to have to support some form of LDAP. If you have a choice, give Fedora Directory Server a good close look. Probably the most common question about it is "Why use this? What's wrong with plain old OpenLDAP?" Nothing, really, it gets the job done. Just a few rough edges--it is a bit of a pain to set up, has incomplete documentation, and a GPL-unfriendly license. It doesn't have all the features of Fedora Directory Server, but it is sturdy and reliable. Some of the features present in FDS that you don't get in OpenLDAP are:

  • Abundant--indeed, nearly over-abundant--documentation
  • Friendly user community
  • Multi-master replication
  • Reliable hot-backups and restores
  • Integration utility for Active Directory users and groups
  • Secure authentication and transport via Mozilla NSS
  • Most changes don't need a server restart
  • Nice graphical management console
  • HTTP-based Admin Server

FDS scales nicely from tiny test systems to huge enterprise systems, which comes as no surprise to anyone who knows its history. It began life as the Netscape Directory Server (NDS), then became the iPlanet Directory Server, and then the SunONE directory server. You'll find all of these ancestral LDAP servers still in service, handling very large loads with ease. To quote the FDS Web site: "The Fedora Directory Server is hardened by real world use, full featured, scales like a banshee, and already handles many of the largest LDAP deployments in the world." So you could start your LDAP education with FDS, and stick with it as your needs grow.

Multi-master replication is designed for very large deployments. This allows up to four master servers that synchronize with each other, for fault-tolerance and speed. Some folks think multi-master replication is asking for trouble, and putting your data at risk. (See the FAQ entry). You don't have to use multiple masters, because FDS supports the standard master/slave arrangement (or primary/secondary, if you prefer).

FDS uses the NSS (Network Security Services) crytography backend. This replaces OpenSSL and GnuTLS, which FDS does not support. NSS provides a mechanism for central encryption certificate management, which in these here modern times has become quite a chore, since it seems that every application from word processors to mail and Web clients to IRC/ICQ clients to remote access utilities all support certificates. If you already have a batch of OpenSSL certificates and don't feel like re-generating the whole works, NSS comes with a utility to convert them to an NSS-friendly format.

FDS supports policies, which can be applied globally, or as finely-tuned as you want.

Just like OpenLDAP, FDS uses the Berkeley DB from Sleepycat Software. You may use something else if you really really want to, but I warn you it's not a trivial job. You'll probably have to write your own plugin.

User Authentication

One of the biggest dreams of network admins is cross-platform single-sign-on authentication that is not a nightmare to administer. On a Unix-based network--Linux, the BSDs, Mac OS X, commercial Unixes--no sweat. Throw Windows into the brew and suddenly what should be a fundamental operation that works the same everywhere becomes a big fat pain. With an FDS backend, the obnoxious becomes tolerable. Samba has long supported using an LDAP backend. If you've resisted using Samba + LDAP because it looked too difficult, try it with FDS. Samba's default tdbsam database doesn't scale up for large deployments very well, and maintaining duplicate Samba/Unix user account stores is a useless duplication of effort. And don't forget that LDAP is the universal network backend, or very nearly so, so once you figure it out it solves a lot of problems.

Another option is to add the excellent pGINA to the brew. This replaces the Windows login manager with its own login manager that allows Windows clients to authenticate against whatever server you jolly well want them to. So you can easily add some Windows hosts to a Linux or Mac OS X LAN without Samba.

Next week we'll construct a simple authentication backend, which can be used with Samba, or any other way you like.

Resources

This article originally appeared on Enterprise Networking Planet, a JupiterWeb site.

Copyright Jupitermedia Corp. All Rights Reserved.