Cannot change a local user's password when sssd is enabled

[Tim Miller]

Ubuntu 11.10 system. I have sssd set up. Using pam-auth-update I enable both sssd and Unix style authentication. The sssd uses LDAP only for user account lookup. Users defined in sssd can change passwords OK, however, local user accounts cannot, e.g. when logged in as a local user (btmiller):

btmiller@hostname:~$ passwd
Current Password:
New Password:
Reenter new Password:
passwd: Authentication token manipulation error
passwd: password unchange

The following appears in /var/log/auth.log:

Mar 16 18:18:05 hostname passwd[20544]: pam_sss(passwd:chauthtok): Authentication failed for user btmiller: 10 (User not known to the underlying authentication module)
Mar 16 18:18:10 hostname passwd[20544]: pam_sss(passwd:chauthtok): Password change failed for user btmiller: 10 (User not known to the underlying authentication module)

It looks like PAM has been set up to call pam_sss for ALL password changes, regardless of whether the user is local or has been defined through sss.

[Timo Aaltonen (tjaalton)]

Bump the priority to, say, 512 in /usr/share/pam-configs/sss. Then run 'pam-auth-update'. Does it fix things?

[Tim Miller (btamiller)]

I'm afraid that did not help. The priority level in /usr/share/pam-configs/sss was already set quite high (912 or so, whereas the priority for Unix was 256). I changed the sss priority to 512 (so now Unix is 256 and SSS is 512). The only other file in /usr/share/pam-configs is for ConsoleKit, which has a priority of 0. However, I disable ConsoleKit in pam-auth-update.

[Timo Aaltonen (tjaalton)]

So if you comment out the pam_sss line on /etc/pam.d/common-password then changing password for a local user works?

Please attach common-password, bump the debug_level on sssd.conf and attach the relevant part of /var/log/auth.log where it fails.

[Timo Aaltonen (tjaalton)]

Uh oh, here we go again.. I reproduced your issue on precise. The pam-configs priorities have cause me a lot of grey hair before, and now it looks like the priority should again be _lower_ than 256 (pam_unix). Now it all makes perfect sense, but for some reason I was under the impression that on the password stack pam_sss should be _on top_, but that fails for local users.

So looks like I need to drop the priority back to 128 again. Could you check if that fixes things for you? Test auth & password change for both local and remote users.

[Tim Miller (btamiller)]

OK, making the priority changed allowed my to change a local user's password. However, it appears to break SSSD users. When I try to change myu password using a LDAP account (LDAP is accessed via sssd), I get:

tim@de8:~$ passwd
Current Password: <I type my password here>
passwd: Authentication token manipulation error
passwd: password unchanged

And /var/log/auth.log shows:

Mar 23 18:40:35 de8 passwd[13503]: pam_unix(passwd:chauthtok): user "tim" does not exist in /etc/passwd
Mar 23 18:40:46 de8 passwd[13503]: pam_unix(passwd:chauthtok): user "tim" does not exist in /etc/passwd
Mar 23 18:40:46 de8 passwd[13503]: pam_sss(passwd:chauthtok): Password change failed for user tim: 4 (System error)

I've set the SSD LDAP log to 10, but there's a lot of cruft in there. As far as I can tell, the relevant part seems to be a few lines:

(Fri Mar 23 18:40:46 2012) [sssd[be[default]]] [sdap_pam_chpass_handler] (2): starting password change request for user [tim].
(Fri Mar 23 18:40:46 2012) [sssd[be[default]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, <NULL>) [Internal Error (System error)]
(Fri Mar 23 18:40:46 2012) [sssd[be[default]]] [be_pam_handler_callback] (4): Sending result [4][default]
(Fri Mar 23 18:40:46 2012) [sssd[be[default]]] [be_pam_handler_callback] (4): Sent result [4][default]

What is really odd here is that this almost make it sound like it's an issue with the LDAP back-end. However, if I revert to the old configuration (i.e. with the sss priority set to 512), password changing starts working again, so it seems like my back-end is working OK.

Here are the contents of /etc/pam.d/common-password (when I had the sss priority at 128):

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_unix.so obscure sha512
password sufficient pam_sss.so use_authtok
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more...

[Timo Aaltonen (tjaalton)]

Thanks for the info. For me it's failing even if pam_sss is on top (precise), but I'll look at it closer next week. So it's not necessarily the same bug, but the one I'm interested in :) It's confirmed now that pam_sss should be with a lower priority, but from what I can tell that has never worked so the priority got bumped..

[Timo Aaltonen (tjaalton)]

never worked on ubuntu, that is.

[Timo Aaltonen (tjaalton)]

Dropped the priority in git.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 1.8.2-0ubuntu1

---------------
sssd (1.8.2-0ubuntu1) precise; urgency=low

  * Merge from Debian git, remaining changes:
    - control, rules: Drop libsemanage-dev from build-depends, it's not
      in main and will not be for precise. Configure --with-semanage=no.

sssd (1.8.2-1) UNRELEASED; urgency=low

  * New upstream bugfix release 1.8.2.
    - Several fixes to case-insensitive domain functions
    - Fix for GSSAPI binds when the keytab contains unrelated
      principals
    - Fixed several segfaults
    - Workarounds added for LDAP servers with unreadable RootDSE
    - SSH knownhostproxy will no longer enter an infinite loop
      preventing login
    - The provided SYSV init script now starts SSSD earlier at startup
      and stops it later during shutdown
    - Assorted minor fixes for issues discovered by static analysis
      tools
  * control: Move the dependency of libsasl2-modules-gssapi-mit to
    Recommends.
  * control: sssd works with Heimdal gssapi modules too, add
    libsasl2-modules-gssapi-mit as an option for the Recommends.
    (LP: #966146)
  * libpam-sss.pam-auth-update: Drop the dependency to 128, since pam_sss
    should always be below pam_unix. (LP: #957486)
  * sssd.postrm: Try to remove /etc/sssd only if it exists.
    (Closes: #666226)
 -- Timo Aaltonen <email address hidden> Wed, 11 Apr 2012 11:48:56 +0300

[DJ (ke7mbz)]

This bug still exists in 13.04. After installing SSSD, I can no longer change the password for any user, including root. Uinstalling SSSD didn't fix the problem. How can I revert PAM to how it was before I installed SSSD?

[DJ (ke7mbz)]

I changed common-password to be identical to what it is on another machine that doesn't have sssd installed, and everything works now. That involved deleting the sssd line, as well as some pam_unix options. Seems like this ought to be done when SSSD is removed. In any event, SSSD is still blocking local password changes in 13.04, even for the root account.