Where OpenLDAP Fits

With all the buzz about Sun and Red Hat's latest offerings, OpenLDAP has not received much attention lately. There has in fact been a steady improvement in the product, and it's had significant penetration into the enterprise over the last two years. The most significant commercial deployment has been at HP, where Katik Subbrao & Co. have made Symas's Connexitor Directory the core of their company's Identity Management infrastructure. The nice thing for the OpenLDAP community is that all of the new functionality built into Connexitor for HP can eventually wind up as part of OpenLDAP, as Symas is a major contributor to the project.

Although its nice to see OpenLDAP getting such a big boost over at a big company like HP, I see it being a strong contender in small to medium sized environments. As shipped with Red Hat Enterprise Linux 4, OpenLDAP is a reliable, seamlessly integrated and well-documented operating system service that can serve as the basis for a no frills authentication and white pages directory solution. When combined with Kerberos, it can provide a secure, standards-based identity management infrastructure. In an alternate universe where vendor and consultancy hype (as well as the corporate IT penchant for consuming licenses as easily as my co-workers do pretzels) I could easily see an enterprise the size of my own company (approximately 10,000 users) easily satisfying its identity management requirements with this software stack.

Linux Journal only recently completed yet another series focused on deploying OpenLDAP and Kerberos as an Identity Management solution. These articles got me thinking again about all the opportunities this software provides. One of my personal projects for the balance of this year will involve exploring how the latest syncrepl "pull" based replication can provide the basis for a highly available service infrastructure.

OpenLDAP is such a good fit in so many situations that I hope Red Hat will continue to ship it as an integrated part of their OS, and not deprecate it in favor of their more complex Fedora/Red Hat/Netcape Directory product. If it were any other software vendor, I'd say the odds would be against it -- but we're talking about Red Hat here, the company that bowed to pressure from its customers to finally start shipping more current MySQL packages (previously Red Hat had only shipped packages based on a legacy version), and so I'm pretty sure that OpenLDAP will continue to be an optional part of their shipping product.

Forking with Sun - Almost

With their latest version releases, the Netscape family directory products of Sun and Red Hat have finally forked significantly enough to make seamless interoperability a thing of the past. The different algorithms used for replication now make it impossible for these latest directories to replicate with each other. This was to be expected. Intellectual property law concerns really demanded it, especially if Sun's version was to remain a proprietary product.

At my company we have opted to remain with Sun, primarily because by doing so we can avoid the steep initial cost of purchasing Red Hat's commercially supported product (I opted not to push for implementation of the free Fedora Directory product sans support, which would have been too radical a step for them). I've already deployed the latest release of Sun Java Systems Directory (v5.2) in development, and hope to move quality and production over to it in good order. The demand for high availability has finally forced us to adopt a multi-master model, which is not supported by OpenLDAP, and the need to simplify sign-on has led us to begin testing Sun's Identity Synchronization for Windows, for which their directory product (among other things) is a dependancy. Red Hat/Fedora could have satisfied both these requirements with their slightly different solutions, but unfortunately the startup cost of licensing the necessary instances was prohibitive. As a long-time Sun customer our cost to implement Sun's solution was ... $0.

I don't see this as necessarily a loss for Red Hat. It may very well be that Red Hat does not have the resources to do this yet, or that they aren't yet convinced that directory services should be part of their core business. There's nothing wrong with that. Deployment of directory services has become just one step in building an Identity Managemnt infratructure, and Red Hat does not really have its own IM offering. The big players in that space are CA (with the former Netegrity SiteMinder product), Sun (with its Java Systems Identity Management Suite), Oracle and Microsoft. Of these, only CA and Sun's offerings are real end-to-end solutions, and I would argue that Sun is the more complete of these two.

Of course we run the CA solution in my work environment -- which at the time seemed to be the way to go (Sun's entire product line was in serious flux at the time). Time will tell whether any other vendor will be able to make a dent in this market. I doubt that Red Hat will try. Their best strategy is to continue concentrating on their core compentency in providing the best server OS platform available (not that I don't expect some movement toward a compelling desktop product soon -- more on that in my other blog).

The upshot of all of this is that now that we've forked with the Sun product, there's really no easy was to turn back. For all intents and purposes my company won't be exploring deployment of Red Hat Directory going forward. Barring the collapse of Sun, or its abandonment of its own directory, we're now stuck with them. There is the possibility that Sun will participate in the Fedora Directory project and contribute their own changes to it. I don't see that happening in the near term, although I think it would be a huge benefit to the entire OSS community.