pam-krb5 error when called from Samba

[Andreas Ntaflos]

On 2011-09-02 01:32, Russ Allbery wrote:
> 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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20110902/dea6075f/attachment.bin