9

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

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
McGovernTheory
  • 6,556
  • 4
  • 41
  • 75
  • Examples of customizing the schema for reasons other than extending inetOrgPerson are greatly appreciated. – McGovernTheory Apr 15 '09 at 12:22
  • In my own testing, I have found that extending LDAP with non-user objectClasses is more performant than using a relational database. Sadly, many developers are living in the past and need to rethink dated assumptions. – McGovernTheory May 27 '09 at 10:39
  • 1
    implementing your own RBAC backing store, rather than integrating against LDAP, seems like one of those living in the past steps... as well as violating DRY on a network services level. – Tetsujin no Oni Jun 05 '09 at 13:21
  • I use it for the product catalogue as well, as our products are hierarchical. LDAP is widely used for Internet domain and X509 certificate purposes. – user207421 Jul 09 '19 at 04:23

5 Answers5

5
  • 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.
HMM
  • 2,987
  • 1
  • 20
  • 30
4

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).

tvanfosson
  • 524,688
  • 99
  • 697
  • 795
3

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

jwilleke
  • 10,467
  • 1
  • 30
  • 51
2

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.

Mark Brittingham
  • 28,545
  • 12
  • 80
  • 110
0

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.

duffymo
  • 305,152
  • 44
  • 369
  • 561