Andreas Ntaflos <[email protected]> writes: > I am trying to "protect" our users from dealing with more than one > password which is why I try to make password changes to different > applications as seamless as possible. It seems however that the > Windows/Samba/LDAP/Kerberos integration is still not really possible to > do seamlessly without AD (and even then ...). Interestingly, Samba and > smbclient know how to honour Kerberos tickets (smbclient -k) but that > obviously only works with Linux clients, somewhat defeating the point.
Well, usually when seamlessly integrating multiple systems you do want to use PAM. My worry is that it surprises me that smbpasswd would use PAM, since I'd expect a command like that to bypass PAM and just change the password directly in Samba. Or maybe it's that the Samba server has some way of passing any password change it receives through an additional PAM layer on the server? >> But what you want to do is both, so something like: >> >> password requisite pam_krb5.so minimum_uid=1000 >> password required pam_smbpass.so use_authtok use_first_pass >> >> would normally be what you'd do. This stacks the two modules so that both >> have to succeed, and tells pam_smbpass to use the old password >> (use_first_pass) and new password (use_authtok) stored in the PAM data by >> pam-krb5. > Ah, great, thanks for explaining! I'll see if I can use such a > configuration, but doesn't it mean that the passwd call needs to occur > locally on the Samba server? Meaning users have to log into to Samba > server directly before they can make use of the PAM stack configured > this way? The idea here is that you'd put that PAM configuration on each of your client systems and then tell users to just use passwd as normal. (Ideally, you only want users to be giving their password to the system they're sitting in front of, and only cryptographic keys to be sent over the wire. That's what Kerberos does.) -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
