Why isn't there a software that runs an LDAP server using /etc/passwd and /etc/shadow as the data?

This would be *so much easier* than wasting hours struggling with OpenLDAP, ldif files, TLS certs, NSS, PAM, SSSD, severe brain damage... this software would literally just be 1. create users as usual with useradd 2. start the server 3. everything just works™

I guess LDAP and enterprise software just always has to be brain damage...

· · Web · 1 · 0 · 2

@ta180m I can see a few reasons why, but instead of just explaining what LDAP does well (and what it could do better) I would like to know what it is that you would like to use this hypothetical LDAP server implementation for?

@loke It'd work extremely well for my current use case: centralizing account management for the exozy.me server so users only have to remember one set of username+password. A lot of services that we host don't support PAM authentication but do support LDAP, so we're kinda forced to use LDAP.

@ta180m I think the main issue with your proposal is that it's very limited, in the sense that you only have basically three pieces of information that can be made available in this hypothetical LDAP server: username, full name and password (well, OK, home directory as well).

I think the issue is that this does not make for a very useful LDAP server, except for a very specific use case which you may actually find yourself in. That it to say that I don't think enough people have had this need for someone to actually build such thing.

Also, Microsoft Active Directory already kinda is this thing. The only real problem here is that it's Windows. For me (and probably for you as well) this completely disqualifies this option, but most people seem to be OK with it.

@loke Ah, I see. I guess by distilling down the hypothetical LDAP server for my use case to the bare minimum, my proposal works perfectly for this specific case but isn't general and useful otherwise.

@ta180m Yeah, pretty much. There is certainly a case to be made for some script or podman container or something like that that can provide a one-stop solution to your problem. Someone who is familiar with OpenLDAP could probably put that together in no time.

I think the issue there is that once you know OpenLDAP well enough to do that, the problem is so easy to solve that there is no reason to automate it. You'd just think to yourself "why is that needed, just type the following commands and edit that file and problem solved".

It's been a while since I used OpenLDAP, and after working with it for a while it all made sense. But I agree it's confusing at first because there are so many concepts that are very different from other systems.

@loke Right, the thing about OpenLDAP is that it's incredibly frustrating at first with all sorts of weird jargon like cn, dn, dc, ou, schemas, and so on, but if you make a serious attempt to understand all the concepts, it begins much easier.

For instance, our repo containing our LDAP configs (git.exozy.me/exozyme/LDAP) is actually quite small, around 100 lines, but it took me days to learn all the concepts and put it together.

@loke I know that vern.cc has been trying to switch to OpenLDAP, but they've been complaining about all the work required to learn the terminology and write configs.

Actually for them, I think almost all of their services requiring accounts support PAM (Gitea and Mastodon definitely do), so it'd probably be easier for them to use PAM instead of LDAP since PAM authentication for those services basically accomplishes the same goal as what I proposed in the original post.

@ta180m Indeed. It helps if you think about LDAP as a database interface. The question one has to ask oneself is: "Do I need to store this information in a database that multiple clients can access and perform queries on?".

If all you want to do is to be accessing user information on a single system, then the answer is pretty much guaranteed to be "no".

Where LDAP really shines is when you have a large number of systems that all have to share user information, and you want to have a single source of truth that is independent of any of those systems. This also explains why LDAP has to be extensible, since different systems needs very different information associated with each object. This is where the schemas come in. They allow you to structure the information in a way that a simple key/value database could not.

Of course, if LDAP was created today, it would look very different. It would probably be some JSON nightmare that would also be bad, just in a more modern way.

@loke Revisiting my original question, github.com/glauth/glauth looks like almost what I proposed, but it's definitely a lot more generally useful since it uses YAML file for storing user data instead of /etc/passwd.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!