It's why everyone uses JSON and not ASN.1. Why people will save a single number in a file rather than standing up Oracle database. Or why they still use random invented rot-level "encryption" for messages rather than pgp.

LDAP doesn't expose operations like "create new user", "verify password", "deactivate user", "set encryption method to ...". It's a database where you "bind" your user description against your hierarchy of objects/attributes - explain that to a guy who just wants to get his new app idea working ASAP... It's got its own query language too. You can even do LDAP query injections - just like in SQL!

Like you said - LDAP is a beast. It's great and I'd use it as soon as number of users goes over 10k, or employees on different levels over 10. But otherwise, no way. A new component with its own security issues is just not worth it.

And that's just when you're using the recommended connectors (ODBC/ADO.NET). FSM help you if you're using JDBC and the vendor of the $20k+ product hasn't tested against Server 2012.

I wonder if there's any money in providing an LDAP/AD -> REST server.

http://stackoverflow.com/questions/2453769/active-directory-... might be an idea, too.

Unless you escape your "(cn=$username)" properly, the users can do a lot of fun things.

More importantly, an LDAP search filter only goes with an LDAP search request, which is read-only. You cannot use silly parser games like this to destroy a database, like you can in SQL with Little Bobby Tables. https://xkcd.com/327/

Playing games with LDAP search filters can't return you more information than the app was originally authorized to see. It most often won't even return you more than a single record, since most apps that make LDAP queries and expect only a single entry to be returned won't even look at any subsequent entries if they happen to be in the reply.

Canonical LDAP application code to search for a user record, for authentication/authorization purposes, sets the LDAP search sizelimit to 1. Getting more than 1 matching result is an error.

But it does exist. Saying that LDAP auth[nz] code should set sizelimit to 1 is like saying SQL auth[nz] code should set LIMIT 1. Correct and defensive code does that. But there's still code out there which doesn't and is vulnerable.

Then again, I don't think you understood the second example. It's not for auth, but rather user search - which is the probably the second most common corporate ldap usage.

As for LDAP injection being nonsense, how about searching some CVEs:

- LDAP injection and resulting STORED Cross Site Scripting in Events Planner - SmarterMail 7.x (7.2.3925) - https://www.exploit-db.com/exploits/15189/

- Graylog2 before 0.92 allows remote attackers to bypass LDAP authentication via crafted wildcards. - CVE-2014-9217

- PowerDNS before 2.9.18, when running with an LDAP backend, does not properly escape LDAP queries, which allows remote attackers to cause a denial of service (failure to answer ldap questions) and possibly conduct an LDAP injection attack. - CVE-2005-2301

And many many more...

I concede the point that there's poorly written code out there that is vulnerable. Still, to lump this into the label of "injection attack" along the lines of SQL injection attacks is grossly misleading. An SQL injection attack can cause destruction of data, invocation of arbitrary commands on the backend, and innumerable kinds of other mischief. A misparsed LDAP filter can do none of these things.

I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there.

Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired.

If you want to go deep on identity management, the NIST documents are pretty much the canonical source of information. http://csrc.nist.gov/projects/iden_ac.html

In any case, don't reinvent the wheel. Just because bozos implement user auth in a MySQL table doesn't mean solutions don't exist. It just means that they are bozos. It's one of the reasons I disapprove use of SaaS apps that don't support federated identity at work.

I get the impression that OpenLDAP is a big beast that does much, much more.

I'm wanting a fast motorbike and you're pointing at a 16 wheel heavy hauler saying "see, same thing, the hauler has at least two wheels and an engine".

You also said:

"Another problem is that developers roll their own user and password management systems and get things like salting and hashing wrong, making the data vulnerable."

You're asking for a distributed, secure system for processing user data and credentials. The most common systems in production globally for doing this (Microsoft Active Directory) are based on technologies developed in the 80's and only being supplanted in recent years. There's a reason for that, and if it were a trivial problem, we wouldn't have pervasive solutions using 1980s RPC in 2015 still running most businesses!

If you want a secure system you shouldn't be prioritising a "minimal solution". As the previous poster said, don't reinvent the wheel.

I'm not even sure about a meaningful way. For sake of portability the DB will need to have some way to dump everything. And if a server admin can do that, then someone who can get the same access as a server admin can do it, and we're back to square one.

It supports a lot of backends (SQL and NoSQL alike) (openLDAP has nice proxy features)

It also supports role based authentication.

But at the opposite of actual NoSQL data bases, even though it has no structures, it is strongly typed and secure.

You map your NoSQL structures to structured backend through a mapping.

It is awesome but most devs hates it, because they are (at my opinions) ignorants. And developers hates it because they are lazy.

There is a need for something secure by default that is easy to use, easy to set up, easy to deploy, etc. Where this will be difficult is https://xkcd.com/927/.

I can find no clear answer after a few minutes of searching.

So, practically speaking - does it matter?

[0] And equivalent for each country with >70M people

http://symas.com/docs/2014-LOADays-jkozyra.pdf

80% of the US population that owns cellphones are OpenLDAP users, whether they realize it or not. 90% of the US population that subscribes to cable TV (Comcast, Time-Warner, etc.) as well. Nothing else actually works for hundreds of millions of users. These companies know, they've tried a lot of "solutions" already.

My own personal experience with LDAP in general (and some with OpenLDAP in particular) dates back to 2000 or so -- and at some point I just gave up on the complex and unreliable beast that it was (for whatever reason, BDB would occasionally lock up or get corrupted) - but I know a lot has changed since, LMDB is amazing -- I guess it is time for another look.