pam-krb5 error when called from Samba
Russ Allbery
rra at stanford.edu
Thu Sep 1 19:32:31 EDT 2011
Andreas Ntaflos <daff at pseudoterminal.org> 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 (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the Kerberos
mailing list