💾 Archived View for thrig.me › tech › ldap.gmi captured on 2023-09-08 at 16:56:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
The Lightweight Directory Access Protocol (LDAP) maintains directory information (users, groups, and so forth) and makes it accessible over the network. Mostly this is a hit piece on LDAP, as I do not like the protocol nor the implementations.
The 398-ds that ships with RedHat Linux took four bug reports and one security vulnerability to reach a usable state in production. The software did very clever things such as wedging only when exposed to production traffic. Wedging here means that the software was purportedly running, but was not responding to client requests. The software worked fine in a test environment, but that test environment did not know about all the weird clients actually being used by unsupported groups.
The wedge was debugged by capturing production traffic and then writing code to replay the saved production TCP traffic to a test server. It turned out there were some oddball clients that sent oddball traffic which then caused 389-ds to wedge. Simple and robust, the protocol and software ain't.
Even with multi-master replication--there's that complexity, again--LDAP is a single point of failure; I have seen all the LDAP servers go down, and this takes down every other service that is chained to LDAP, like a boat that heads to the bottom of the wine-dark sea. A similar thing happened at a small internet retailer where production traffic got misrouted to Active Directory; AD melted, and then everything that required AD went down. Oh, what, you need AD up to be able to login to your documentation and monitoring systems to see what is going on and work the issue? Whoops! Tee-hee!
Some sysadmins resort to running an LDAP instance on each host, so that software that requires LDAP then looks to the loopback interface. Of course all the changes will need to be replicated to all the hosts. This might be an option you find suitable, and does help avoid the "LDAP went away, now what?" problem and fallout thereof.
Password handling in LDAP is pretty poor; I invariably had Kerberos handling the passwords. This meant more complexity and therefore bugs, because who wouldn't put all their passwords into LDAP?? Was 389-ds tested with a Kerberos setup? Probably not. Bug. Maybe it was some Windows integration that resulted in plaintext passwords being slung around the LDAP server; I saw that and was like nope, nope, nope! What attacker wouldn't love to find plaintext passwords lying around?
Also, recall the four bugs and one CVE to get a working LDAP system in production. Who knows how many bugs remain to be exploited? I name these hacker-gifts.
This is not strictly related to LDAP, but the last instance of LDAP I managed was used by groups outside the control of the central IT team, so if you were like "um, hey, you folks should move to using SSL" and they were like "our sysadmin took another job so nobody can do that unless you want to add support for our group to your already somewhere north of 40 hours a week taskload." Maybe you could sunset non-SSL LDAP, but that would open up a political battle where the unsupported group would insist on support, or you could sigh and go on running non-SSL LDAP because there are unsupportable systems outside of your control who are really not patching their systems at all. Firewall them off when they do get hacked? I don't know.
https://www.nytimes.com/2023/04/08/opinion/letters/remote-work.html
Whatever America is, it is not a worker's paradise.
I usually stuffed the complexity into configuration management, where Ansible (or scripts running under CFEngine--whatever) would handle getting the appropriate users and groups onto the appropriate systems. For the legacy LDAP system, I had the users and groups in a database (which has many advantages over LDAP) and a script under configuration management would build and deploy a new LDAP server slaved to that database. This is complicated, but I would argue less complicated than trying to setup and document and maintain a multi-master LDAP cluster. Where do you want to push the complexity?
One can also export data from LDAP--the aliases, for example, so that the email servers can continue to work should LDAP fall down and go boom. Sure, a stale alias might sometimes be used, but I figure a somewhat working system is less bad than one that is busy breaking up in the water.
tags #ldap #malware