Using SSSD, PAM error when exiting su session

there was a proposed patch from upstream that was thought to fix this, but after testing it the error is still the same.

A way to reproduce it is to copy the example config from /usr/share/doc/sssd/examples/ and modify it to enable a 'fake' ldap domain, start sssd and run 'su <localuser>; exit'. I did try to debug it with gdb to see why pam_close_session returns garbage, but it needs further work..

This seems to be fixed in upstream 1.9.0~beta6.

This bug was fixed in the package sssd - 1.9.0~beta6-0ubuntu1

---------------
sssd (1.9.0~beta6-0ubuntu1) quantal; urgency=low

  * Merge from unreleased debian git. (LP: #1012900)

sssd (1.9.0~beta6-1) UNRELEASED; urgency=low

  * New upstream prerelease 1.9.0beta6. Highlights:
    - Add native support for autofs to the IPA provider
    - Support for ID-mapping when connecting to Active Directory
    - Support for handling very large (> 1500 users) groups in Active
      Directory
    - Support for sub-domains (will be used for dealing with trust
      relationships)
    - Add a new fast in-memory cache to speed up lookups of cached data
      on repeated requests
    - Add support for the Kerberos DIR cache for storing multiple TGTs
      automatically
    - Major performance enhancement when storing large groups in the cache
    - Major performance enhancement when performing initgroups() against
      Active Directory
    - SSSDConfig data file default locations can now be set during
      configure for easier packaging
    - Add a new PAC responder for dealing with cross-realm Kerberos trusts
    - Terminate idle connections to the NSS and PAM responders
    - Switch from libunistring to glib2 for unicode support
    - Add a new AD provider to improve integration with Active Directory
      2008 R2 or later servers
    - SUDO integration was completely rewritten. The new implementation
      works with multiple domains and uses an improved refresh mechanism to
      download only the necessary rules
    - The IPA authentication provider now supports subdomains
    - Fixed regression for setups that were setting default_tkt_enctypes
      manually by reverting a previous workaround.
    - Many fixes for the support for setting default SELinux user context
      from FreeIPA, most notably fixed the specificity evaluation
    - Fixed an incorrect default in the krb5_canonicalize option of the AD
      provider which was preventing password change operation
    - The shadowLastChange attribute value is now correctly updated with the
      number of days since the Epoch, not seconds
    - A new option, override_shell was added. If this option is set, all
      users managed by SSSD will have their shell set to its value.
    - Many fixes for the support for setting default SELinux user context
      from FreeIPA. Most notably, the SELinux mappings can now link to HBAC
      rules as the source of users and hosts they apply to.
    - Fixed a regression introduced in beta 5 that prevented LDAP SASL binds
      from working unless the value of ldap_sasl_minssf was explicitly
      specified.
    - The SSSD supports the concept of a Primary Server and a Back Up
      Server. Certain servers in the fail over list can be marked as back up
      only. If the SSSD switches to a back up server because a primary server
      is not available, it would later try to re-establish a connection to the
      primary server. This feature would mainly benefit users who configure
      fail over servers from different data centers or geographies.
    - A new command-line tool sss_seed is available. This tool is able to
      prime the internal cache with a use...

would be nice to backport the commit that fixes this to precise too.

Agreed, this is indeed somewhat critical in my opinion. It breaks, for example, the Pacemaker resource agent for PostgreSQL (ocf:heartbeat:pgsql), which uses "su" to start and stop a PostgreSQL instance. Some packages' postinst scripts also fail because "su" doesn't exit correctly, for example Monkeysphere.

A fix for Precise would be most welcome. That, or a PPA build of 1.9.0. for Precise. *looks at Timo* :)

Andreas, if it helps in the meanwhile, it can be pretty easily worked around. The pam_sss module doesn't really serve any purpose on Ubuntu at the moment. You can comment the pam_sss line out of /etc/pam.d/common-session and the error should go away.

Mark, thanks for the suggestion, will look into that. I was under the impression that pam_sss in /etc/pam.d/common-session was needed for access control as provided by SSSD, but I was wrong, apparently.

Confirmed that backporting 7016947229 fixed this.

sent a subset of that commit upstream to be included in 1.8.x, will add it for precise one way or another.

Uploaded a new package for precise to https://launchpad.net/~sssd/+archive/updates

please test, it'll get SRU'd next.

Tested the new package, but the bug still exists for me.

Nathan,

Could we get your auth.log and any reproducer steps that would help us track this down?

Thanks,
Adam

I have sssd configured to authenticate against AD.

Here I have my user properly authenticating and su works fine.

<snip>
root@host:~# su - nhuisman
root@host:~# exit
logout

auth.log entries
Nov 5 17:56:25 host sshd[8417]: pam_unix(sshd:session): session opened for user root by (uid=0)
Nov 5 17:56:28 host su[8494]: Successful su for nhuisman by root
Nov 5 17:56:28 host su[8494]: + /dev/pts/0 root:nhuisman
Nov 5 17:56:31 host su[8494]: pam_unix(su:session): session opened for user nhuisman by root(uid=0)
Nov 5 17:57:43 host su[8494]: pam_unix(su:session): session closed for user nhuisman

</snip>

Now I try and su - to a local user which isn't in AD

<snip>

root@host:~# su - vikingtest
vikingtest@host:~$ exit
logout
su: User not known to the underlying authentication module

Nov 5 17:54:30 host su[22464]: Successful su for vikingtest by root
Nov 5 17:54:30 host su[22464]: + /dev/pts/0 root:vikingtest
Nov 5 17:54:30 host su[22464]: pam_unix(su:session): session opened for user vikingtest by root(uid=0)
Nov 5 17:54:31 host su[22464]: pam_unix(su:session): session closed for user vikingtest
Nov 5 17:54:31 host su[22464]: pam_close_session: User not known to the underlying authentication module

</snip>

Is there some way to increase the verbosity of the logs? I added debug to the pam config but got nothing more than the same error.

Confirmed with precise. This bug is the reason for everyday cronjob messages containing this:

/etc/cron.daily/lighttpd:
su: User not known to the underlying authentication module
su: User not known to the underlying authentication module
run-parts: /etc/cron.daily/lighttpd exited with return code 1

"2>/dev/null" and "exit 0" is a workaround in this case, but...

Tested the package from Timo's PPA. Fixed the bug on my Precise system.

Iggywig,

Would you be willing to share your setup/configs so that we can help Nathan figure out if this is a configuration issue, different bug, or the same bug?

So far only one reported it as not fixing their issue.

Thanks to everyone who have tested this so far, I'll work on getting it through the proper process to be reviewed for SRU.

Adam
What setup/config are you after? Sorry only just seen this comment after I hit the bug again on Precise and 1.8.2-0ubuntu1.

I'm using sssd in PAM to do LDAP auth against a 389 directory server.

Prior to upgrade I saw this in logs:

Jan 11 14:50:41 webdev01 su[28656]: pam_unix(su:session): session opened for user testuser by ian.mordey(uid=0)
Jan 11 14:50:44 webdev01 su[28656]: pam_unix(su:session): session closed for user testuser
Jan 11 14:50:44 webdev01 su[28656]: pam_close_session: User not known to the underlying authentication module

After upgrade I see this:
Jan 11 15:04:52 webdev01 su[6477]: pam_unix(su:session): session opened for user testuser by ian.mordey(uid=0)
Jan 11 15:04:52 webdev01 su[6477]: pam_unix(su:session): session closed for user testuser

No pam_close_session error.

Cheers

Hello Mark, or anyone else affected,

Accepted sssd into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/sssd/1.8.6-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

verified it myself

Verification passed on 12.04:
Linux Mark-Aurel 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
sssd Version: 1.8.6-0ubuntu0.2
libpam-sss Version: 1.8.6-0ubuntu0.2

Fixes pam error problem caused by libpam-sss and sssd (User not known to the underlying authentication module) for /etc/passwd users. Fixes also amavis-new cron job failure caused by su call in script in /usr/sbin/amavisd-new-cronjob.

1.8.6-0ubuntu0.2 solved the "User not known to the underlying authentication module" for /etc/passwd users for me.

​​This bug was fixed in the package sssd - 1.8.6-0ubuntu0.2

---------------
sssd (1.8.6-0ubuntu0.2) precise-proposed; urgency=low

  * rules: Really install the new pam-auth-update file for password
    changes. (LP: #1086272)
  * rules: Pass --datadir, so the path in autogenerated python files is
    correctly substituted. (LP: #1079938)

I'm still getting the error with the new package. What kind of config items would I need submit to re-open a diff bug?

foo:/root # apt-get install sssd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libipa-hbac0
Suggested packages:
  sssd-tools
The following packages will be upgraded:
  libipa-hbac0 sssd
2 upgraded, 0 newly installed, 0 to remove and 107 not upgraded.
Need to get 3,002 kB of archives.
After this operation, 66.6 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://bar/us-archive/ precise-updates/universe sssd amd64 1.8.6-0ubuntu0.2 [2,990 kB]
Get:2 http://bar/us-archive/ precise-updates/universe libipa-hbac0 amd64 1.8.6-0ubuntu0.2 [12.6 kB]
Fetched 3,002 kB in 0s (34.1 MB/s)
(Reading database ... 36881 files and directories currently installed.)
Preparing to replace sssd 1.8.2-0ubuntu1 (using .../sssd_1.8.6-0ubuntu0.2_amd64.deb) ...
sssd stop/waiting
Unpacking replacement sssd ...
Preparing to replace libipa-hbac0 1.8.2-0ubuntu1 (using .../libipa-hbac0_1.8.6-0ubuntu0.2_amd64.deb) ...
Unpacking replacement libipa-hbac0 ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up libipa-hbac0 (1.8.6-0ubuntu0.2) ...
Setting up sssd (1.8.6-0ubuntu0.2) ...
Installing new version of config file /etc/init/sssd.conf ...
sssd start/running, process 15249
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
foo:/root # /etc/init.d/sssd restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service sssd restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop sssd ; start sssd. The restart(8) utility is also available.
sssd stop/waiting
sssd start/running, process 15272
foo:/root # su - oneadmin
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

oneadmin@oreg1:~$ exit
logout
su: User not known to the underlying authentication module