On 2011-09-02 00:49, Russ Allbery wrote: > Andreas Ntaflos <[email protected]> writes: > >> Russ, thank you for your reply! > > Sorry about not following up again; it looks like the mailing list ate the > list copy of the message, so it got misfiled.
No problem, thanks for following up! >> I have only recently started trying to understand how Samba setups >> (standalone or PDC) would work together with Kerberos (and LDAP) so I am >> not even sure if calling "smbpasswd -r" from a remote machine is the >> right approach. Smbpasswd prompts for the old and new passwords so it >> seems that Samba should take care of the conversation details and >> passing the authtok. > > It's tricky to do that. PAM doesn't provide any great way to do that, > other than setting the password as auth data. It really likes you to have > a conversation function. But it may very well do it properly; I've never > used it myself. Well, Samba does have a conversation defined (mimicking the regular UNIX passwd change conversion, I think) but it gets ignored when using PAM password changes. So I don't really know what Samba does internally. I should probably head over to the Samba mailing lists for this but if I remember correctly the SNR there is usually quite low, that's why I tried the Kerberos list first. > Usually, I would expect the application-specific password programs like > kpasswd or smbpasswd to only change the password in that specific system, > and not try to use PAM or do anything generic. 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, the typical pam-krb5 configuration for password change is: > > password sufficient pam_krb5.so minimum_uid=1000 > password required pam_unix.so nullok obscure min=4 max=8 md5 > > which tries to change the Kerberos password and falls back to changing the > UNIX password if the provided password isn't the Kerberos password. 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? Andreas
signature.asc
Description: OpenPGP digital signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
