20
LDAP to UNIX user proxy (lemmy.ml)
submitted 3 months ago by kevincox@lemmy.ml to c/selfhosted@lemmy.world
33 comments fedilink hide all child comments

Is there any service that will speak LDAP but just respond with the local UNIX users?

Right now I have good management for local UNIX users but every service wants to do its own auth. This means that it is a pain of remembering different passwords, configuring passwords on setting up a new service and whatnot.

I noticed that a lot of services support LDAP auth, but I don't want to make my UNIX user accounts depend on LDAP for simplicity. So I was wondering if there was some sort of shim that will talk the LDAP protocol but just do authentication against the regular user database (PAM).

The closest I have seen is the services.openldap.declarativeContents NixOS option which I can probably use by transforming my regular UNIX settings into an LDAP config at build time, but I was wondering if there was anything simpler.

(Related note: I really wish that services would let you specify the user via HTTP header, then I could just manage auth at the reverse-proxy without worrying about bugs in the service)

all 34 comments
sorted by: hot top controversial new old
[-] just_another_person@lemmy.world 11 points 3 months ago

I think you're missing the point of LDAP then. It's a centralized directory used for querying information. It's not necessarily about user information, but can be anything.

What you're asking for is akin to locally hosting a SQL server that other machines can talk to? Then it's just a server. Start an LDAP server somewhere, then talk to it. That's how it works.

If you don't want a network service for this purpose, then don't use LDAP. If you want a bunch of users to exist on many machines without having to manually create them, then use LDAP, or a system configuration tool that creates and keeps them all eventually consistent.

[-] kevincox@lemmy.ml 3 points 3 months ago

Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I'm not really interested in storing other data.

I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase ... I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I'm not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn't a goal).

[-] just_another_person@lemmy.world 2 points 3 months ago

Then it's the same situation. Find a box, setup an LDAP service, populate it, and you're good to go. That's it.

[-] kevincox@lemmy.ml 1 points 3 months ago

The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn't be an issue.

[-] just_another_person@lemmy.world 2 points 3 months ago

You're thinking too hard about this.

There needs to be a source of truth. LDAP is just a simple protocol that can be backed by whatever. You're worried about the LDAP server going down, but guess what? It's all in flat files. Go ahead and set it up in a bit repo for config management service for the server/protocol portion, and backup the DB. Easy peasy.

You can also cluster your LDAP service amongst all of your nodes if you have 3+ nodes and un-even number of them to ensure consensus amongst them. You can even back LDAP with etcd if you really want to go down that road.

You're being paranoid about what happens if LDAP goes down, so solve for that. Any consumer of LDAP should be smart enough to work on cached info, and if not, it's badly implemented. Solve for the problem you have, not for what MIGHT happen, or else you're going to paranoid spiral like you are now because there is no such thing as a 100% effective solution to anything.

[-] BearOfaTime@lemm.ee 5 points 3 months ago

What's wrong with LDAP for users? (I'm trying to think of a negative, and can't).

[-] kevincox@lemmy.ml 3 points 3 months ago

Yet another service to maintain. If the server is crashing you can't log in, so you need backup UNIX users anyways.

[-] BearOfaTime@lemm.ee 9 points 3 months ago

You need backup local admin accounts, not Backups for each user.

Which is how enterprise does things. There are local accounts with root access, but the id's and passwords are tightly controlled.

[-] just_another_person@lemmy.world 5 points 3 months ago

Then you don't understand how it works with local auth services.

[-] cybersandwich@lemmy.world 4 points 3 months ago

Would you mind educating us plebs then? I had a similar question to op, and I can assure you, I definitely don't understand local auth services the way I probably should.

[-] just_another_person@lemmy.world 5 points 3 months ago

Your local auth services are configured to use LDAP as a source, whatever your local auth mechanism is checks credentials, and then you're auth'd or not. Some distros have easy to use interfaces to configure this, some don't, but mostly it's just configuring pam.d (for Linux), and a caching daemon of some sort to keep locally cached copies of the shadow info so you can auth when the LDAP server can't be contacted (if you've previously authenticated once). You can set up many different authentication sources and backends as well, and set their preferences, restrictions, options...etc.

RHEL/Fedora examples: https://www.redhat.com/sysadmin/pam-authconfig

Debian examples: https://wiki.debian.org/LDAP/PAM

[-] AllYourSmurf@lemmy.world 4 points 3 months ago

Look into Single Sign-On services (SSO) like Authelia, Authentik, or KeyCloak. Most SSO tools do the sorts of things you’re looking for. Some will talk to the native UNIX user store. I do agree with the others, though: if you’re this far along, then it’s time to spin up LDAP and SSO, but this might be the same tool in your case.

[-] kevincox@lemmy.ml 3 points 3 months ago

But the problem is that most self-hosted apps don't integrate well with these. For example qBittorrent, Jellyfin, Metabase and many other common self-hosted apps.

[-] Shimitar@feddit.it 4 points 3 months ago

They actually do, i am down the same path recently and installing authelia was the best choice I made. Still working on it.

But most stvies support either basic auth, headers auth, oidc or similar approaches. Very few don't.

[-] kevincox@lemmy.ml 1 points 3 months ago

How are you configuring this? I checked for Jellyfin and their are third-party plugins which don't look too mature, but none of them seem to work with apps. qBittorrent doesn't support much (actually I may be able to put reverse-proxy auth in front... I'll look into that) and Metabase locks SSO behind a premium subscription.

IDK why but it does seem that LDAP is much more widely supported. Or am I missing some method to make it work

[-] Shimitar@feddit.it 1 points 3 months ago

You might use LDAP, but its total overkill.

I have not yet worked jellyfin with authelia, but its more or less the last piece and I don't really care so far if its left out.

A good reverse proxy with https is mandatory, so start with that one. I mean, from all point of views, not login.

I have all my services behing nginx, then authelia linked to nginx. Some stuff works only with basic auth. Most works with headers anyway, so natively with authelia. Some bitches don't, so I disable authelia for them. Annoying, but I have only four users so there is not much to keep in sync.

[-] kevincox@lemmy.ml 1 points 3 months ago

I do use a reverse proxy but for various reasons you can't just block off some apps. For example if you want to play Jellyfin on a Chromecast or similar, or PhotoPrism if you want to use sharing links. Unfortunately these systems are designed around the built-in auth and you can't just slap a proxy in front.

I do use nginx with basic with in front of services where I can. I trust nginx much more than 10 different services with varying quality levels. But unfortunately not all services play well.

[-] Shimitar@feddit.it 1 points 3 months ago

Never found a service that don't work with nginx reverse proxy.

My jelly fin does.

Don't run photoprims tough...

[-] kevincox@lemmy.ml 1 points 3 months ago

Are you doing auth in the reverse proxy for Jellyfin? Do you use Chromecast or any non-web interface? If so I'm very interested how you got it to work.

[-] Shimitar@feddit.it 1 points 3 months ago

This is my jellyfin nginx setup: https://wiki.gardiol.org/doku.php?id=services:jellyfin#reverse-proxy_configuration

currently i don't use any proxy related authentication because i need to find the time to work with the plugins in Jellyfin. I don't have any chromecast, but i do regularly use the Android Jellyfin app just fine.

I expect, using the OIDC plugin in jellyfin, that Jellyfin will still manage the login via Authelia itself, so i do not expect much changes in NGINX config (except, maybe, adding the endpoints).

[-] kevincox@lemmy.ml 1 points 3 months ago* (last edited 3 months ago)

Ah ok. You aren't doing auth. I don't understand how this is relevant.

[-] Shimitar@feddit.it 1 points 3 months ago

Well, here is the relevant part then, sorry if it was not clear:

  • Jellyfin will not play well with reverse proxy auth. While the web interface can be put behind it, the API endpoints will need to be excluded from the authentication (IIRC there are some examples on the web) but the web part will stil force you to double login and canot identify the proxy auth passed down to it.
  • Jellyfin do support OIDC providers such Authelia and it's perfectly possible to link the two, in this case as i was pointing out, Jellyfin will still use it's own authentication login window and user management, so the proxy does not need to be modified.

TLDR: proxy auth doesnt work with Jellyfin, OIDC yes and it bypassess proxy, so in both cases proxy will not be involved.

[-] catloaf@lemm.ee 3 points 3 months ago

Against which regular user database?

[-] moonpiedumplings@programming.dev 2 points 3 months ago* (last edited 3 months ago)

So based on what you've said in the comments, I am guessing you are managing all your users with Nixos, in the Nixos config, and want to share these users to other services?

Yeah, I don't even know sharing Unix users is possible. EDIT: It seems to be based on comments below.

But what I do know is possible, is for Unix/Linux to get it's users from LDAP. Even sudo is able to read from LDAP, and use LDAP groups to authorize users as being able to sudo.

Setting these up on Nixos is trivial. You can use the users.ldap set of options on Nixos to configure authentication against an external LDAP user. Then, you can configure sudo

After all of that, you could declaratively configure an LDAP server using Nixos, including setting up users. For example, it looks like you can configure users and groups fro the kanidm ldap server

Or you could have a config file for the openldap server

RE: Manage auth at the reverse proxy: If you use Authentik as your LDAP server, it can reverse proxy services and auth users at that step. A common setup I've seen is to run another reverse proxy in front of authentik, and then just point that reverse proxy at authentik, and then use authentik to reverse proxy just the services you want behind a login page.

[-] freddo@feddit.nu 2 points 3 months ago

There is the passwd LDAP backend, not sure if it works for full auth though.

[-] possiblylinux127@lemmy.zip 2 points 3 months ago

Yes

However, it is better just to move all users to ldap

[-] Decronym@lemmy.decronym.xyz 1 points 3 months ago* (last edited 3 months ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters More Letters
HTTP Hypertext Transfer Protocol, the Web
SSO Single Sign-On
nginx Popular HTTP server

2 acronyms in this thread; the most compressed thread commented on today has 11 acronyms.

[Thread #956 for this sub, first seen 8th Sep 2024, 13:25] [FAQ] [Full list] [Contact] [Source code]

[-] acockworkorange@mander.xyz 1 points 3 months ago

Missed LDAP, bot.

[-] suzune@ani.social 1 points 3 months ago

Are you looking for something like cached credentials?

this post was submitted on 07 Sep 2024
20 points (85.7% liked)

Selfhosted

40734 readers
713 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz