lelapin - Hi all! I'm jumping through some hoop...
# troubleshooting
n
Yes, that is correct, and by design. We do not store a hash of the user's password, only enough data to have an interactive zero-knowledge proof that the user has the same password than when he registered
(btw, nice avatar!)
(big fan of Lewis Trondheim)
l
ah, right, the opaque thing (:) thx)
ok, hm so i guess i'll have to write a custom pam module using the graphql api?! uh
n
Haha hopefully not!
You can send the password cleartext over LDAP to validate
But you won't be able to do the validation yourself, LLDAP has to be the one doing it
l
Ah! I forgot this. Ok, i'm gonna try to write the simplest config i can for pam_ldap and report back if it works
n
After 30s of reading, it seems like setting up pam (with sssd maybe?) to authenticate to LLDAP, and then using that for opensmtpd would be the way to go
And I know that many people will be interested in a PAM config
l
indeed, that's what they seem to prefer (i looked into the ldap-table thing, but it's brittle and weird and kindof not for this)
btw i'm trying nslcd from nss-pam-ldap (it's basically sssd but only for ldap)
n
If you need help setting it up, getting the attributes working, feel free to ask
I'm not in front of a computer but I can answer questions
l
Hey, i got back to working on this again and finally got it to work (at least with pamtester, will do the real test with opensmtpd tomorrow). Custom attributes weren't needed (very glad!), the only pitfall is to disable some ldap extension for password policy (control oid 1.3.6.1.4.1.42.2.27.8.5.1).
pam_authc_ppolicy no
in
/etc/nslcd.conf
. The rest is straitforward. I'll try to contribute an example config for this soon (when my config gets stablized)
n
Oh, wow, we can get PAM without custom attributes? That's great news 🎉
l
Yes indeed! I guess it will confuse a lot of pam users (like logind) because without custom attributes there will be missing env vars, but for basic users of the
auth
chain it should work