ahh, OpenLDAP, I've a weird Stockholm syndrome with that piece of software. It's probably one of the most reliable nosql DB out there. And you can actually imp

ahh, OpenLDAP, I've a weird Stockholm syndrome with that piece of software. It's probably one of the most reliable nosql DB out there. And you can actually implement schemas to ensure data formatting \o/ (provided you like OIDs...). It can support quite rich ACLs, but those are a little hard to debug and fix. But it's nice it is there. You also have an interesting query language using polish notations (okay, I prefer to slapcat the complete directory and do '|less' or '|grep' if I've direct access to the server and if it's not too big, I could never remember the options names in ldapsearch). Lastly the ldif syntax is so great, I always have to google it even for the most basic edits... More seriously, ldap is somewhat painful to deploy: * Indeed the documentation is a bit lacking, the zytrax one is great but somewhat dated (specially with the cn=config paradigm). * If you are doing complex setups like n-way multi-masters replication the documentation is somewhat verbose and really hard to understand (https://www.openldap.org/doc/admin24/replication.html https://www.openldap.org/doc/admin24/replication.html). Generally it involves a lot of trial and errors in a lab to figure it out. * There can be traps if you are not aware of the internals. For example, in one of our deployments we were maintaining large groups, and batch updates were taking a really long time. After digging, I finally understood why: each time you add or remove an entry in a group, it rewrites the complete group entry (at least with the BDB backend), rewritting 100000 entries each time you update one is somewhat costly... Not sure if it's still the case with the lmdb backend however. * The source code is not really easy to read in my opinion. I did try it once (debugging the issue mentioned above), but was not successful at roughly understanding how it worked from reading the source code, at least in the few hours I devoted to it (I know, it's not necessarily a lot). * Usually, with replication, schema tweaking, backups, monitoring and some testing, deploying OpenLDAP can easily be a one or two months project. * deploying all the integrations correctly is also quite hard (ldap auth for ssh or web authentication on each web applications), That being said, 389 Directory/RedHat Directory Server is not much better, the setup is done through a weird perl script. Setup ssl/tls is a pain (I learn to hate certutil, and its certs/ca/private keys in DBs, deploying flat pem files is so much easier and convenient). The "rich" client looks like it has not changed in years (or removed all together), and it looks so much like the Old Sun One I'm wondering if it has changed since the Netscape days apart from code maintenance. Also, I'm not sure if it's still the case, but IIRC RDS is a separate subscription from RedHat, it doesn't come with a basic RHEL OS subscription (I recall having to recompile the srpm my self when 6.0 went out). RHEL was also not a really great maintainer of their OpenLDAP packages, I remember for example a breaking change because they went from 2.4.38 to 2.4.41 (I'm expecting a stable distro like RHEL to not introduce breaking changes, and to not update software like a rolling release, Debian does a far better job at it for example). After all this 'praise' of the ldap world, you must think I actually hate it. No, I actually kind of like it (to the point of maintaining an ldap web UI). Having a centralized user DB makes things so much easier for everybody, the user only has one password, the security officer can trustfully enable/disable accesses, the sysadmin as one source of truth. If you maintain local accounts for each of your applications you are in for a lot of troubles down the line. It's also an authentication method that is widely supported by most applications, and if it's not, there is probably a ticket/PR/patch somewhere to add it. Lastly once it's setup and configured, it's generally quite reliable even with complex replication setups, this makes it relatively low maintenance. And at least for reads, it has quite good performances. OpenLdap: I love to hate you, but I love you.