Open Source LDAP Projects

Where OpenLDAP was once the only Open Source LDAP system available this is no longer the case. There is now the Fedora Directory Server, another University of Michigan derivative, OpenDS a Sun led Java LDAP implementation, and ApacheDS (Apache Directory Server) 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 scale implementation of directories. We have elected to document ApacheDS 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 assesment - but hasten to add that we understand all the projects have unique capabities and many committed users - this assement 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 to us.

OpenLDAP is widely regarded as the reference implementation and is historically based on the original University of Michigan code base. It 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. OpenLDAP until fairly recently (2.3ish) was focussed on standards implementation and devoted few resources to operational capability. Things are changing significantly with features such as run-time configuration, improved replication and even multi-master capabilities (2.4+). OpenLDAP is however 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 everything 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 resources.

The Fedora Directory Services Project also derives from the original University of Michigan code base and has morphed as far as we can tell through a life as Netscape's Directory Server, Redhat's Directory Server into its current Fedora 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 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 the ideal solution should be a single install (LDAP, database, kerberos, ssl) and with a canned out-of the box operational configuration and trivial to extend (functionally and operationally) through various high level tools. We see this as being a basic requirement supporting perhaps up to 100- 200,000 records - above that level we suspect resources are available to support more complexity and the performance considerations may start to dominate. Users may elect to migrate to other solutions above this point. Perhaps not.

We 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 and the ideas about optimization of disc access through the use of classic transaction DB capabilities such as stored procedures and triggers. This 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.