Why aren't companies using LDAP as a central repository for other than users?

Question

In every larger company I worked for they used LDAP as a way to access the central repository of user information, but very few have taken efforts to extend the schema to include objectClasses that aren't derived from inetOrgPerson.

Microsoft's Active Directory makes extensive schema extensions but very few commercial products leverage the capabilities of LDAP.

Is it because most LDAP developers don't know how to model beyond users? Find value in it but just haven't thought deeply about it? Have tried it and ran into performance problems? Something else?l

Answer 1

I would think that it is due to A) the complexity of working with LDAP (much higher than SQL) and B) the fact that your product would be tied completely to it. That is, it would have no market outside of large organizations running LDAP. For less money and effort, I could build an app that works anywhere.

Now, internal applications written specifically for the organization that need access to other LDAP data are a different story. But you will obviously hear less about them because they are not commercially marketed.

Answer 2

• I've always thought LDAP was too high level for network administrators and too low level for software developers. Neither of them seem to be confortable with it.
• There is the perception that since almost every enterprise application will use a relational database, then adding one more data source lowers the availability and reliability for the application.
• The barrier to make custom schemas in LDAP is still high. In LDAP servers, you have to put the schema file in the schema directory, usually with root or administrative priviledges an restart the LDAP server; whereas current ORMs can create, update or verify relational database schemas when the application gets started.

Answer 3

Personally I think it's because LDAP is a directory, not a database. Directories are good for looking up people and their associated data, but they're not particularly good for tracking highly relational data -- which is what a lot of the rest of our data looks like. In fact, our use of LDAP is actually as a front-end to "people"-data, merging a lot of data streams into a single directory view. We still have the "people" data in the backend databases along with the rest of our institutional data and have only chosen LDAP (in our case ADAM) as a front-end to allow convenient lookup of the merged "people" data. Now that we're moving to web services as a means of accessing this data, I'm not sure that it even makes sense to continue down the LDAP route (except to support existing services that haven't been updated).

Answer 4

I thought LDAP was highly optimized for fast, frequent reads. I don't think they'd scale for transactional systems.

The relational model and its expression in SQL is a powerful thing. I don't think it will be easily supplanted by LDAP or object databases.

Answer 5

We have done work for some companies with 65Million LDAP records an none of the records were for people.

The data was a variety of items mostly for devices including: * DHCP * DNS * Mac Addresses * Location * SN * Brand * Model * etc....

-jim