On 2011-09-02 01:32, Russ Allbery wrote: > 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?
Samba has a "pam password change" option, described this way in the manpage: With the addition of better PAM support in Samba 2.2, this parameter, it is possible to use PAM´s password change control flag for Samba. If enabled, then PAM will be used for password changes when requested by an SMB client instead of the program listed in passwd program. It should be possible to enable this without changing your passwd chat parameter for most setups. End quote. How exactly this is implemented and what other conditions must apply for this to work, I don't know. It may well have something to do with the way Samba handles encrypted passwords but the most current information I can find about this was written in 2003 in the PAM chapter of the Samba HOWTO collection. A follow-up on the Samba list seems unavoidable. >>> 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.) This is the way we have our user's workstations set up. They use passwd to change their Kerberos passwords. I have now tried to incorporate this PAM configuration into our shell server (so there is a central place users can change their passwords) but I have seem to hit a bug in libgcrypt: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601667 This results in users not being able to successfully change their Samba password with PAM/passwd, with Samba complaining: "pam_smbpass(passwd:chauthtok): Cannot access samba password database, not running as root." Which is ridiculous, especially since everything is stored in LDAP. Using "sudo passwd testuser" works correctly through PAM. The whole thing is a mess and each step opens a further can of worms. Also this is getting off topic, for which I apologize. Russ, thanks again for your input and help! Andreas
signature.asc
Description: OpenPGP digital signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
