Open Source LDAP Projects

OpenLDAP (originally based on the University of Michigan code base) used to be the only Open Source LDAP system available - this is no longer the case. There is now 389 Directory Server (the ex-Fedora Directory Server), another University of Michigan derivative, OpenDJ (a fork of OpenDS a Sun-led Java-based LDAP implementation which now appears inactive), and ApacheDS (Apache Directory) another Java-based LDAP project. All appear excellent projects and together with OpenLDAP provide an embarrassment of riches in the Open Source LDAP space - driving forward capabilities, features and functionality.

In our view the presence of multiple projects can do nothing but good to move forward wide-spread implementation of directories. We have elected to add documentation on ApacheDS (in addition to the OpenLDAP information) in this guide as being representative of the second generation of LDAP servers and with, in our view, some unique capabilities that may point a way forward in this space.

We note with sadness some spats and bad manners between certain members of the projects since we see nothing but good coming from the presence of multiple projects - both for the user and development communities. Here is our general assessment of the projects - but hasten to add that we understand all the projects have unique capabilities and many committed users - this assessment merely reflects our point of view at this moment in time and space. And besides, what do we know?

Note: If you don't like what we say we would prefer you just clicked away from this page and write us off as hopeless cases but if you feel you must contact us - because we misunderstood something or overlooked something - there are two links on every page by which you may do so. We will respond in the same spirit in which you write.

OpenLDAP is widely regarded as the reference implementation and is historically based on the original University of Michigan code base. The original code base has been substantially upgraded, re-structured and changed over the years. It is written in C and consequently, in our view as C guys, will always run faster than Java based implementations. We may be proven wrong over time on this (with Java compilers etc., etc.) but we doubt it. Others will argue that as CPU resources increase this is a factor of declining importance, yet others will argue that I/O performance is the real limiting factor in all cases. OpenLDAP until fairly recently (2.2ish) was focussed on standards implementation and devoted few resources to operational capabilities. Things are changing significantly with features such as run-time configuration, improved replication and even multi-master capabilities (2.4+). OpenLDAP, because it does almost everything defined in the standards, can be complicated to configure and operate - especially if you are trying to integrate into a heterogeneous AD environment. The project has a disconcerting habit of changing things with every release. A config file that loaded without a problem in version x, croaks in version y and the revised version croaks again in version z. This is in marked contrast with software such as Apache where configuration tranquility seems to reign supreme. Nevertheless, it remains our position that for large scale implementations where sufficient operational resources (people/skill) are available and where operational resources are an issue it will remain the implementation of choice and will probably run like the wind on (relatively) modest hardware resources.

The 389 Directory Services (ex Fedora Directory Server) project also derives from the original University of Michigan code base and has morphed, as far as we can tell, through life as Netscape's Directory Server, Redhat's Directory Server into its current 389 manifestation. It is written in C and should exhibit the same (ish) performance characteristics as OpenLDAP. It must be credited with driving forward operational functionality such as real-time configuration and multi-mastering and we remain convinced it will continue to innovate. We note that during the first 18 months or so of 389 Directory Server's existance the majority of changes were bug fixes and performance improvements rather than functional enhancements. Both worthy and commendable goals.

We are not big Java fans - seeing it as having the worst characteristics of C++ without pointers (that is meant to be a humorous statement in case you are entirely devoid of a sense of humour - remember, or feel pity if you must, we are C - and Ruby - guys). Java is, however, a very productive language and virtually ubiquitous which means that significant amounts of functionality can be written very quickly and can be run on virtually any platform out of the box - as long as you are prepared to overlook its more modest (vs C) run-time performance and huge memory footprint. Both of the newest Open Source LDAP entrants (OpenDS and ApacheDS) have elected to use Java.

We see the real advantages of Open Source LDAP (directories) as being focussed on simplifying the install and configuration of secure directories capable of being tightly integrated with AD to provide Identity management and other capabilities for heterogeneous environments. This means, for us, the ideal solution should be a single-click install (LDAP, database, kerberos, ssl), a canned out-of the box operational configuration and trivial to extend (functionally and operationally) through high level tools. We see this as being a basic requirement supporting perhaps up to 100- 200,000 records. Above this number of records we suspect resources are available to support more complexity and run-time performance considerations will start to dominate. Standards based LDAP provides relatively painless migration - a major attribute - allowing users to select an implementation with optimal characteristics - functional or performance related - based on changing needs.

We have elected to focus on ApacheDS to represent the newer generation of LDAP servers moving toward this level of functionality. In particular, we note Directory Studio (an Eclipse based tool) and the project ideas about optimization of back-end access through the use of classic transaction DB capabilities such as stored procedures and triggers. The decision to focus on ApacheDS is in no sense meant to be a negative reflection on OpenDS which we continue to monitor with great interest.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.