Cannot change Kerberos password with passwd(1)

[Daniel Richard G.]

This concerns libpam-krb5 version 4.2-1 in Ubuntu Natty, and is a revisiting of an issue previously addressed in bug 334795.

    $ passwd
    Current Kerberos password:
    passwd: Authentication token manipulation error
    passwd: password unchanged

Previous reports I've filed described issues encountered on an Ubuntu installation configured to use Kerberos, LDAP and AFS, a large number of moving parts which tended to confuse the issue at hand. This time, however, I've managed to reproduce the bug on a minimal Ubuntu install, with libpam-krb5, and a local user (uid=1000) with the same name as an existing Kerberos user. The Kerberos and PAM configs are stock; Kerberos server information is being pulled from DNS. LDAP and AFS are completely out of the picture.

I can log into the system as the Kerberos user without issue, but if I attempt to change the password, I get the above error. If I add the "debug" option to the pam_krb5 invocation in /etc/pam.d/common-password, and then try again, I see this in /var/log/auth.log:

Aug 15 17:46:31 test-linux passwd[935]: pam_krb5(passwd:chauthtok): pam_sm_chauthtok: entry (0x4000)
Aug 15 17:46:31 test-linux passwd[935]: pam_krb5(passwd:chauthtok): (user dgomez) attempting authentication as <email address hidden>
Aug 15 17:46:34 test-linux passwd[935]: pam_krb5(passwd:chauthtok): pam_sm_chauthtok: exit (success)
Aug 15 17:46:34 test-linux passwd[935]: pam_unix(passwd:chauthtok): authentication failure; logname=daniel uid=1000 euid=0 tty= ruser= rhost= user=daniel

So, what's the deal with this error?

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> I can log into the system as the Kerberos user without issue, but if I
> attempt to change the password, I get the above error. If I add the
> "debug" option to the pam_krb5 invocation in /etc/pam.d/common-password,
> and then try again, I see this in /var/log/auth.log:

> Aug 15 17:46:31 test-linux passwd[935]: pam_krb5(passwd:chauthtok): pam_sm_chauthtok: entry (0x4000)
> Aug 15 17:46:31 test-linux passwd[935]: pam_krb5(passwd:chauthtok): (user dgomez) attempting authentication as <email address hidden>
> Aug 15 17:46:34 test-linux passwd[935]: pam_krb5(passwd:chauthtok): pam_sm_chauthtok: exit (success)
> Aug 15 17:46:34 test-linux passwd[935]: pam_unix(passwd:chauthtok): authentication failure; logname=daniel uid=1000 euid=0 tty= ruser= rhost= user=daniel

> So, what's the deal with this error?

You have some other PAM module stacked with pam-krb5 that's rejecting
password changes for that user. Probably pam_unix without /etc/shadow
data.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Daniel Richard G. (skunk)]

The shadow database has a non-hashable password field for the user. Kerberos is the only way this user can log in. Why wouldn't the behavior of a password change then simply update the Kerberos password, and leave the Unix one alone?

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> The shadow database has a non-hashable password field for the user.
> Kerberos is the only way this user can log in. Why wouldn't the behavior
> of a password change then simply update the Kerberos password, and leave
> the Unix one alone?

Because you don't have PAM configured to do that? I'd have to see the PAM
configuration to be sure, but generally PAM is configured to require the
various stacked modules to succeed, so if pam_unix fails, it fails the
stack. You have to ensure that the module is configured so that the ones
you're not interested in using are skipped properly and their exit status
doesn't contribute to the result.

It's hard to be more specific without knowing the behavior that you want,
but there are several examples in the libpam-krb5 documentation that try
to cover some of the common cases.

What's clear from your trace, though, is that this is not a libpam-krb5
problem. Everything about libpam-krb5 in your trace succeeded; some other
module is failing.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Daniel Richard G. (skunk)]

Okay, here is /etc/pam.d/common-auth:

auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

And here is /etc/pam.d/common-password:

password requisite pam_krb5.so minimum_uid=1000
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password requisite pam_deny.so
password required pam_permit.so

(Both of these were produced by pam-auth-update, from stock PAM profiles.)

In the auth stack, pam_krb5 succeeding is enough to allow login. Why doesn't the PAM profile for libpam-krb5 likewise specify "[success=end default=ignore]" for the password stack? As things are, you get inconsistent behavior between the two stacks.

[Russ Allbery (rra-debian)]

"Daniel Richard G." <email address hidden> writes:

> Okay, here is /etc/pam.d/common-auth:

> auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
> auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass
> auth requisite pam_deny.so
> auth required pam_permit.so

> And here is /etc/pam.d/common-password:

> password requisite pam_krb5.so minimum_uid=1000
> password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512

Yeah, I suspect it would do what you want if you made this match the
common-auth configuration.

> password requisite pam_deny.so
> password required pam_permit.so

> (Both of these were produced by pam-auth-update, from stock PAM
> profiles.)

> In the auth stack, pam_krb5 succeeding is enough to allow login. Why
> doesn't the PAM profile for libpam-krb5 likewise specify "[success=end
> default=ignore]" for the password stack? As things are, you get
> inconsistent behavior between the two stacks.

It was the way Steve implemented this originally, and I remember that he
had some rationale for it, but I don't remember what it is. :/ I'll ask
him separately. It may be that they should change.

Thanks, that gets me pointed in the right direction.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

[Daniel Richard G. (skunk)]

Much appreciated, Russ. The only way the current stock config makes sense to me is if Steve intended for the local Unix password to be kept in sync with Kerberos, which isn't how things are supposed to work. (And conversely, Kerberos plus a disabled Unix password *should* work.)

[Daniel Richard G. (skunk)]

Just wanted to confirm that modifying the password stack's pam_krb5 line to "[success=N default=ignore]" does yield the desired behavior (Kerberos password changed successfully while ignoring the disabled Unix password).

[Launchpad Janitor (janitor)]

This bug was fixed in the package libpam-krb5 - 4.4-3

---------------
libpam-krb5 (4.4-3) unstable; urgency=low

  * Change the pam-auth-update configuration to skip remaining password
    stack by default modules if the Kerberos password change succeeds.
    This is more useful behavior for the common case of Kerberos accounts
    not having local passwords. See README.Debian.gz for information
    about how to synchronize Kerberos and local passwords. (LP: #826989)
  * Update README.Debian.gz documentation with more current options for
    pam_unix and document password synchronization configuration.
  * Convert to multiarch. Depend on the multiarch version of libpam0g,
    install the modules into the multiarch version of /lib/security, and
    declare the packages Multi-Arch: same.
  * Update to debhelper compatibility level V9 (experimental).
    - Build-Depend on debhelper 8.9.4 or later for hardening flags.
    - Add Pre-Depends: ${misc:Pre-Depends}.
  * Update standards version to 3.9.2 (no changes required).
  * Fix formal name of the GPL in debian/copyright. (This will also be
    done upstream in the next release.)

 -- Russ Allbery <email address hidden> Mon, 26 Sep 2011 08:40:43 -0700