Why nobody uses LDAP(blog.whats-your.name)
blog.whats-your.name
Why nobody uses LDAP
http://blog.whats-your.name/post/2010/04/18/%E2%80%83
37 comments
While I agree that LDAP is confusing - it is very widely used so I don't think it is realistic to say that "nobody uses it".
To be fair, though, that's sort of how the RFC process works. For example, TCP is kind of a rat's nest of documents too: http://www.networksorcery.com/enp/protocol/tcp.htm#RFCs
As someone who has had to maintain a midsized openldap setup I can only agree wholeheartly: The day the LDAP dinosaur dies will be a happy day.
LDIF is sort of bearable once you found proper tooling (ldapvi!) and overall the whole thing looks quite sensible and usable at first. For a few minutes. Right after installing slapd and adding your first organizationalPerson.
A few hours later, after wiring up a few applications, things will unfortunately have changed for the worse. Your schema is now cluttered with insane amounts of cruft and redundancy, because every application that supports LDAP (which is not the most common feat in first place) seems to have a slightly different idea of what your schema should look like or what a good password hash is.
Getting to the point of true single-signon is a major undertaking. And during large parts of that journey you will feel a lot like Indiana Jones. You get to puzzle together fragments of ancient documentation while fighting off a mythologic multi-headed hound. You get to spend hours in endless dungeons of subtle incompatibilities and meaningless error messages. And if you ever get bored there's always a fair share of cryptology waiting for the inquiring archeologist, sometimes humorously declared as "documentation" - but usually just in the form of brief S.O.S-messages carved into a usenet stone-wall somewhere on the internet. Sometime in 1983. By some other poor soul stumbling around in a similar - but of course not compatible and long deprecated - maze.
Yea, lots of fun can be had with LDAP. Not.
LDIF is sort of bearable once you found proper tooling (ldapvi!) and overall the whole thing looks quite sensible and usable at first. For a few minutes. Right after installing slapd and adding your first organizationalPerson.
A few hours later, after wiring up a few applications, things will unfortunately have changed for the worse. Your schema is now cluttered with insane amounts of cruft and redundancy, because every application that supports LDAP (which is not the most common feat in first place) seems to have a slightly different idea of what your schema should look like or what a good password hash is.
Getting to the point of true single-signon is a major undertaking. And during large parts of that journey you will feel a lot like Indiana Jones. You get to puzzle together fragments of ancient documentation while fighting off a mythologic multi-headed hound. You get to spend hours in endless dungeons of subtle incompatibilities and meaningless error messages. And if you ever get bored there's always a fair share of cryptology waiting for the inquiring archeologist, sometimes humorously declared as "documentation" - but usually just in the form of brief S.O.S-messages carved into a usenet stone-wall somewhere on the internet. Sometime in 1983. By some other poor soul stumbling around in a similar - but of course not compatible and long deprecated - maze.
Yea, lots of fun can be had with LDAP. Not.
The Kerberos reference is a nice touch.
I recently integrated my companies LDAP server with OpenSSO, which also meant integrating Suns LDAP schema and everything, and it was working just fine.
Maybe it's openldap that sucks? Never used it, though.
I don't know why LDAP is bad, it's quite a perfect tool for certain situations, that would be a nightmare with SQL and even more so with NoSQL.
That there are a lot of RFCs is the major negative point the OP makes and there is no reason this is a bad thing, too. The OP just had his first look into RFCs i guess. There are plenty of RFCs for every protocol in use (IMAP for example, even sieve filters have several RFCs).
It's good to have RFCs to look things up, i don't see the negative point here.
Could be that the Sun impl is better, but many problems seemed to be inherent. Like pretty much every app expecting a different or redundant schema.
What does that look like in your setup? Do you have ssh/kerberos, samba etc. all under one umbrella without nasty hacks?
What does that look like in your setup? Do you have ssh/kerberos, samba etc. all under one umbrella without nasty hacks?
I have used OpenLDAP and Sun LDAP on several occasions and while the initial learning curve for the whole "LDAP thing" might be steep for both, it was pretty obvious that OpenLDAP simply doesn't offer a lot of features that Sun's LDAP server has.
And I agree with you, OpenSSO is a product where Sun really got it right and I am more than happy it got opensourced.
Yes. But apparently Oracle abandoned the project.
Looks like it is continued by ForgeRock: http://forgerock.com/openam.html
All that a few weeks after i recommended OpenSSO to a client.. sheez.. :P
All that a few weeks after i recommended OpenSSO to a client.. sheez.. :P
So, in the same spirit...
Why nobody uses DNS: http://www.faqs.org/rfcs/np.html#DNS
Why nobody uses DNS: http://www.faqs.org/rfcs/np.html#DNS
Hmm, roughly half of those concern either DNSSEC or DDNS... which, in fact, no one uses.
LDAP doesn't pass the Global Disaster test. That is, if some global disaster happened and we lost most of our computing resources and had to rebuild from the ground up we would not rebuild LDAP. We'd do something much better.
I'd also put SMTP, POP3, and IMAP in this category.
I'd also put SMTP, POP3, and IMAP in this category.
Pretty sure that Zimbra's email server uses LDAP "under the covers". The Zimbra mail server is behind Comcast's email system, and many other ISPs and hosting companies use it as well.
And the L in LDAP means "Lightweight"! Maybe its just in there for comedic effect.
Probably from the same people who put the "S" in SOAP
LDAP was derived from X.500. By comparison, it is lightweight. LDAP contained just the barest minimum structure to express X.500 data. It was originally a protocol meant for clients that were too limited to speak X.500 protocols.
Look at it this way: LDAP is to X.500 as SNTP is to NTP.
SNTP is simple, because NTP is pretty simple. LDAP is a little bit hairy because X.500 was really, really, really hairy.
Look at it this way: LDAP is to X.500 as SNTP is to NTP.
SNTP is simple, because NTP is pretty simple. LDAP is a little bit hairy because X.500 was really, really, really hairy.
It's a lightweight implementation of X500 DAP. Compared to a full implementation, it is indeed cut down.
Ahem...I use my school's LDAP directory, and it's very useful.
Lots of people I know use LDAP working just fine.
Are there any free OpenLDAP alternatives out there worth mentioning?
Although not used myself, Suns OpenDS:
http://www.opends.org/
Just for reference, other directories:
Just for reference, other directories:
IBM Tivoli
Microsoft Active Directory
Novell eDirectory
Red Hat Directory Server
Critical Path Directory ServerFedora DS is an open source fork of Netscape 5.1. RHDS is basically the same product. High-performance -- if you need tens of thousands of accounts, hundreds or thousands of simultaneous queries, a netscape derivative is what you want.
Sun ONE DS is free-as-in-beer. It's a newer derivative of the same codebase (Netscape) that became FDS.
Apache DS is something I've been experimenting with. Java-based. Easy to get up and running, comes with a really great default schema.
Sun OpenDS looked cool, but since the oracle acquisition, I can't bring myself to be interested in it.
Sun ONE DS is free-as-in-beer. It's a newer derivative of the same codebase (Netscape) that became FDS.
Apache DS is something I've been experimenting with. Java-based. Easy to get up and running, comes with a really great default schema.
Sun OpenDS looked cool, but since the oracle acquisition, I can't bring myself to be interested in it.
I never understood why these services are not simply working over HTTP.
There's nothing in principle stopping you from storing that data in Redis or CouchDB.
Some NoSQL system might make a very interesting replacement for LDAP.
LDAP is a protocol, not a data store. I agree that you could implement a LDAP directory services server using a NoSQL database.
It's a particularly ugly protocol, if you ask me. I hacked and slashed and swore and got it working for a company I worked for several years ago, but it was not a pleasant experience.
You probably had no experience, the wrong tools and thus a negative experience.
Do you have specific things in mind?
Do you have specific things in mind?
I know my way around Unix, and am a fast learner, so "no experience" is not something that generally scares me. I know I'll make some mistakes and waste a bit of time.
That said, there are plenty of systems that I have encountered in my years that are much friendlier to a new user. Specifically, I recall awful command line queries, kind of wonky tools in general, and, generally, a fiddly feeling to the whole thing. I did get things working, but I was never really happy with the whole setup. We ended up calling in a consultant to check over my work and see if there were ways to improve it, and aside from a few things, there really weren't.
That said, there are plenty of systems that I have encountered in my years that are much friendlier to a new user. Specifically, I recall awful command line queries, kind of wonky tools in general, and, generally, a fiddly feeling to the whole thing. I did get things working, but I was never really happy with the whole setup. We ended up calling in a consultant to check over my work and see if there were ways to improve it, and aside from a few things, there really weren't.
Yes, but honestly, in my world "a strange feeling" doesn't qualify for ojective proof that a system is bad.
There are plenty of powerful tools, and if you don't like the commandline (although you say you use unix a lot, ldap commands are straight forward), you probably could've used GUIs in the most cases. My "feeling" of this thread is that people were unsatisfied with openldap and now blame a protocol.
The major enterprise directories have a lot of additional commands/features/web interfaces to fiddle with.
It's not the protocols problem when a specific implementation is hard to use, isn't it?
What you'd really want is something like IMS.
That'd be awful:
LDAP is a protocol. NoSQL is a shitload of software that works extremely different and has no protocol or common data scheme. LDAP is probably most used for organizing a companies data (employees) and works quite well for that. It's proven, it has major software products that are stable and used in worldwide deployments.
Just exchanging LDAP with NoSQL makes no sense and is a move only driven by "LDAP sounds soo old. Let's use that NoSQL everyone is talking about!". And maybe slap XML, Web2.0 and HTML5 on top of it. Just, you know.. it's state of the art!
I've yet to see a comment on this page that relates to the problems of the protocol. Mostly vague points without objective data.
Basing all those criticism on the fact that this protocol has been around or a while and thus has more than one RFC is just stupid.
LDAP is a protocol. NoSQL is a shitload of software that works extremely different and has no protocol or common data scheme. LDAP is probably most used for organizing a companies data (employees) and works quite well for that. It's proven, it has major software products that are stable and used in worldwide deployments.
Just exchanging LDAP with NoSQL makes no sense and is a move only driven by "LDAP sounds soo old. Let's use that NoSQL everyone is talking about!". And maybe slap XML, Web2.0 and HTML5 on top of it. Just, you know.. it's state of the art!
I've yet to see a comment on this page that relates to the problems of the protocol. Mostly vague points without objective data.
Basing all those criticism on the fact that this protocol has been around or a while and thus has more than one RFC is just stupid.
No, more just idly wondering if it'd be possible to build something that is a less shitty experience than LDAP - see above/below. I'm not particularly interested in the NoSQL stuff, by and large, because for what I do, Postgres is more than enough, however, I'm curious enough to wonder "what could be", and think that with all the different new systems out there, whether it'd be possible to build something new and better.
I don't have the answers, I just didn't really like my experience with LDAP, and was idly wondering whether it'd be possible to build something better these days.
I don't have the answers, I just didn't really like my experience with LDAP, and was idly wondering whether it'd be possible to build something better these days.
Nobody as in "every company, small and large, I've ever worked for in the software, automotive, telco and banking industry". Also, ActiveDirectory is an LDAP at the end of the day. RedHat just started their own LDAP server with the old Netscape sources a few years ago.
I agree that getting started with LDAP when you are only used to relational databases is a real pain. On top of that, a lot of software with "LDAP support" is pretty bad at it. But once you have it up and running, you can integrate it with almost everything. I'm a big fan of the Sun LDAP Server and all its features like multi-master replication, ACLs and all those neat ways it offers you for modeling your directory data.
Also: "LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack." (wikipedia) So that's what that lightweight is all about.
DO NOT mix up LDAP and "single signon" (e.g. kerberos) which are two separate things. You can use LDAP, however, to store your users and passwords and have all kinds of systems use that for authentication and authorization but that is not single signon. Most SSO products I know use LDAP as their datastore, though.
I have always liked LDAP for its strong standardization and simplicity and LDIF is a plain, simple format that you can easily generate or type by hand. There is not a lot of overhead.
I agree that getting started with LDAP when you are only used to relational databases is a real pain. On top of that, a lot of software with "LDAP support" is pretty bad at it. But once you have it up and running, you can integrate it with almost everything. I'm a big fan of the Sun LDAP Server and all its features like multi-master replication, ACLs and all those neat ways it offers you for modeling your directory data.
Also: "LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack." (wikipedia) So that's what that lightweight is all about.
DO NOT mix up LDAP and "single signon" (e.g. kerberos) which are two separate things. You can use LDAP, however, to store your users and passwords and have all kinds of systems use that for authentication and authorization but that is not single signon. Most SSO products I know use LDAP as their datastore, though.
I have always liked LDAP for its strong standardization and simplicity and LDIF is a plain, simple format that you can easily generate or type by hand. There is not a lot of overhead.
Exactly. My company is selling its own directory and of the telcos and other major ISPs worldwide we have as clients everyone uses LDAP. Nobody really just comes down to people coding alone in their basement. Enterprises typically have a whole, distributed, companywide infrastructure where LDAP plays an important role. And LDAP is doing the work just fine for a lot of years now.
Having worked with over 40 start-ups over the past three years who use LDAP, I have to ask how you define the term "Nobody". That being said, I think LDAP is just as awful as all of the other centralized technologies that came out of old-guard academia in the '80s and '90s.