I would like to invite you to join in discussion, started by me on linked in, inspired from your article. I would really appreciate to put your thoughts on the topic.

Thanks and Regards,
Sagar Sonawane

In my opinion LDAP directories can still become an attractive NoSQL store, once fitted with a web friendly JSON front-end. This is what I did two years ago with an internal project, which eventually evolved into Json2Ldap, a software product which is now sold on its own.

It works well for web and cloud applications, for things like central keeping of user and group data, web app user profiles and app configs.

As for making the schema more flexible, there is the “extensibleObject” class which allows clients to store arbitrary key/value pairs in an entry.

You can manage all this data in a relational database, and applications can send their updates to that relational database. Then those updates can be pushed from your relational database to the "root" of an LDAP directory tree and on down to the leaves. Then reads can be really fast. As was mentioned, the query abilities are limited. The queries on the directory should match the directory structure, more or less.

Why do this? Because some things are written to work this way. Email clients and address books can usually tie into it. But probably more significantly, all your hosts can use your central LDAP directory in place of local files like /etc/hosts, /etc/passwd and /etc/group. Manage all that stuff from one dashboard. That's what Active Directory (Microsoft) and Open Directory (Apple) do, and there's no reason the open source world can't get a little better about doing the same.

It would also be very nice if applications, rails apps in particular since this is the engine yard blog, could be made LDAP-aware. This would make a lot of sysadmins much happier since they might then be able to manage all the roles/groups/permissions info across all applications from one place rather than having to do it on a per-application basis.

Another thing that's annoying is, at least in IBM's LDAP, there's no way to do pagination in the way that we think of pagination typically. For instance, there's no "select * from table limit 1,25" style syntax. That one might be a case specific to IBM, and I think they might even have that covered in a later version, but it's just another example where we've run into trouble with LDAP.

As I work with many large organizations and all of them have LDAP directory stores.

The LDAP vs Relational Databases has gone on for years and the answer is still the same. THey serve two different purposes.

Using a LDAP server to keep a history of who went through the card swipe and when is a poor implementation.

But expecting a card reader to authroize in real time if a person is authroized through a SQL DB with the heavy overhead of the SQL protocol and more so the client, is just as wrong.

As for access control, to imply that access control to a RDMS is simpler than LDAP is short sided. Often access control within the RDBMS is simply by-passed and the access control is perfromed within each application.

As for installing LDAP servers vs installing a RDBMS, you really think installing an Active Directory server is harder than installing Oracle?

And sure, OpenLDAP is difficult to install. In a large part due to it being OpenSource. Installing a commercial LDAP server from Novell or SUN or I am sure other vendors certainly easier than installing Oracle or many of the other commercial RDBMs.

AFAICT, Unboundid is on rail. That's good to see that there are more and more LDAP open source initiative those days.