Use Fedora Directory Server For Manageable LDAP (Part 1) - page 2
What Is LDAP?
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.