Ok … very long story that boils down to us trying to help a customer out. I am trying to avoid the “lets just add another user to /etc/passwd” or similar such thing. And they aren’t quite ready to hook into AD or similar.
So we have this issue.
I want to enable their nodes to use ldap. I’ve done this before for other customers with older tools (pam_ldap, etc.). But it was somewhat crazy (as in non-trivial), involving gnashing of teeth, gums, etc.
Folks, this should be an easily … and I mean easily … solved problem. Authentication, if done right, is a document database with a secure transport layer. You can transmit a crypted password to an API endpoint, and get a response (yay/nay/other). Oauth and similar sorta kinda do this.
But you can’t quite use those for private (as in behind company firewall) systems. LDAP and LDAP/AD/Kerberos (shudder) are you choices.
LDAP is painful to set up, and generally, I just use a VM appliance for it to simplify it.
But its the LDAP client side, the interface with PAM where … well … there may be dragons residing there.
And there are.
The original LDAP bits in Linux never worked well. So a new generation of scripts were created. Which sorta kinda worked (and we’ve implemented with this). Then someone from Red Hat noted that they blew chunks, and instead created sssd. Which, as someone working on implementing this now … I can tell you … also blows chunks, though in a different way.
This should not be a hard problem. Really, it should be an easy problem. If I weren’t running the $day_job, I’d give serious consideration to writing code to solve this, nicely, simply, for once and for all. Yeah, I know. AD (Microsoft Active Directory that is). Not everyone uses it, and it is a royal pain to set up as well. Actually even worse than a royal pain. Getting things talking to it, nicely, is non-trivial. There are a few adapter solutions out there to AD, but none actually solve the problem.
The problem is that authentication/authorization/SSO for Linux is still ridiculously hard/brittle to implement. And the tools that we have for it are fundamentally challenged. When they should not be.
Maybe its time for local, on-prem AaaS (Authentication/Authorization as a Service) that actually works, is simple to configure/interact with, and is not a simple connector to AD (which then breaks in mysterious ways).
Viewed 16388 times by 2062 viewers