Bug 1329598 - authconfig breaks PAM system-auth-ac password-auth-ac for sssd in RHEL7.2
authconfig breaks PAM system-auth-ac password-auth-ac for sssd in RHEL7.2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: authconfig (Show other bugs)
7.2
All Linux
unspecified Severity high
: rc
: ---
Assigned To: Pavel Březina
Dalibor Pospíšil
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-22 06:28 EDT by Dennis Ortsen
Modified: 2017-08-17 09:20 EDT (History)
8 users (show)

See Also:
Fixed In Version: authconfig-6.2.8-19.el7
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 03:27:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Ortsen 2016-04-22 06:28:59 EDT
Description of problem:
When running the command to enable the use of sssd, the PAM configuration is different between versions authconfig-6.2.8-9.el7.x86_64 (PAM is OK) and authconfig-6.2.8-10.el7.x86_64 (breaks PAM).

We have sssd set up to use two domains (LDAP and LOCAL). In one domain we use LDAP for both the id_provider and auth_provider in /etc/sssd/sssd.conf. In the other domain we use LDAP as the auth_provider and the files proxy (proxy_lib_name = files) as id_provider. The idea behind this is that admin accounts are posixAccounts in LDAP and thus able to log in to each server with sssd. On certain machines, local exceptions for other user accounts are made with a local user in /etc/passwd and /etc/group but they check their password via the LOCAL domain with sssd. This concept works fine on a server we installed RHEL7.1 on. During installation, sssd is configured and authconfig is also used to set authentication. Essentially, authconfig is only run after installation of RHEL7.

On a recently deployed server with RHEL7.2 we discovered that admin accounts were able to login using the LDAP domain via sssd and use sudo commands (password check via LDAP thru sssd) just fine. Local accounts however, can login with password authentication (via LOCAL domain thru sssd), but they cannot authenticate their password for sudo.

Running sssd domains and services in debug_level lead to the difference in PAM configuration between a server that was initially deployed with RHEL7.1 and one with RHEL7.2.

When running the following command there is a difference in PAM's system-auth-ac and password-auth-ac on a RHEL7.1 and RHEL7.2 server:

"authconfig --enablesssd --enablesssdauth --enablemkhomedir --update"

This results in different contents of both /etc/pam.d/system-auth-ac (and password-auth-ac).

Working version on RHEL7.1:
########################
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha256 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
########################

different version on RHEL7.2:
########################
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha256 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
########################

Used sssd.conf:

########################

[sssd]
domains = LDAP,LOCAL
services = nss, pam, ssh
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30

[nss]
filter_users = root                                                                                                                                                                                                                                                  
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

[pam]
reconnection_retries = 3
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

[domain/LDAP]
cache_credentials = true
id_provider = ldap
auth_provider = ldap
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_id_use_start_tls = true
ldap_uri = ldap://server1.example.com,ldap://server2.example.com,ldap://server3.example.com

[domain/LOCAL]
cache_credentials = true
id_provider = proxy
auth_provider = ldap
proxy_lib_name = files
ldap_search_base = ou=users,dc=example,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_id_use_start_tls = true
ldap_uri = ldap://server1.example.com,ldap://server2.example.com,ldap://server3.example.com
ldap_user_object_class = comExamplePerson
########################




Version-Release number of selected component (if applicable):
authconfig-6.2.8-10.el7.x86_64

How reproducible:
Deploy a RHEL7.1 server and an identical RHEL7.2 server, then configure sssd using the command "authconfig --enablesssd --enablesssdauth --enablemkhomedir --update" and examine the differences between PAM's configuration for system-auth-ac and password-auth-ac for the RHEL7 versions. Using the submitted (anonymized) sssd.conf, try logging in with local account and authenticate against LDAP using the RHEL7.1 version and the RHEL7.2 version of PAM's configuration.

Steps to Reproduce:
1. Install RHEL7.1 and RHEL7.2
2. configure sssd/authconfig on both using the sssd.conf above and the authconfig command from above
3. examine the difference between system-auth-ac/password-auth-ac on the RHEL7.1 and 7.2 server in /etc/pam.d

Actual results:
Locally existing users in /etc/passwd, /etc/group can login via SSH using their password, but cannot authenticate using that same password using the same domain in sssd when using sudo.

Expected results:
no difference between RHEL7 versions and PAM configurations created with authconfig for sssd, resulting in password authentication is always possible, no matter the version of any package of RHEL7.

Additional info:

A similar bug report has been submitted at CentOS, but no mentioning of reporting this back to upstream/RH Bugzilla, so I thought I'd make that effort. The CentOS bug report in question is: https://bugs.centos.org/view.php?id=10328#bugnotes
Comment 3 Sumit Bose 2016-04-22 08:31:43 EDT
Can you add the PAM related messages from /var/log/secure as well? 'journalctl -r -t sudo' should show them, too.
Comment 4 Dennis Ortsen 2016-04-22 09:03:51 EDT
These are the lines in /var/log/secure which show what happens on a RHEL7.2 server. Authentication for ssh with password succeeds, but fails for sudo:

Apr 22 13:05:43 kwik sshd[13392]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.1.183 user=djgw@LOCAL
Apr 22 13:05:43 kwik sshd[13390]: Accepted keyboard-interactive/pam for djgw@LOCAL from 10.1.1.183 port 56956 ssh2
Apr 22 13:05:43 kwik sshd[13390]: pam_unix(sshd:session): session opened for user djgw@LOCAL by (uid=0)
Apr 22 13:05:52 kwik unix_chkpwd[13424]: password check failed for user (djgw)
Apr 22 13:05:52 kwik sudo: pam_unix(sudo-i:auth): authentication failure; logname=djgw uid=1001 euid=0 tty=/dev/pts/2 ruser=djgw rhost=  user=djgw
Apr 22 13:05:55 kwik sudo: pam_unix(sudo-i:auth): conversation failed
Apr 22 13:05:55 kwik sudo: pam_unix(sudo-i:auth): auth could not identify password for [djgw]
Apr 22 13:05:55 kwik sudo:     djgw : pam_authenticate: Conversation error ; TTY=pts/2 ; PWD=/home/djgw ; USER=root ; COMMAND=/bin/bash

These are the lines in /var/log/secure which show a successful authentication for sudo:

Apr 22 14:55:02 kwik sshd[14004]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.1.183 user=djgw@LOCAL
Apr 22 14:55:02 kwik sshd[13997]: Postponed keyboard-interactive/pam for djgw@LOCAL from 10.1.1.183 port 58382 ssh2 [preauth]
Apr 22 14:55:02 kwik sshd[13997]: Accepted keyboard-interactive/pam for djgw@LOCAL from 10.1.1.183 port 58382 ssh2
Apr 22 14:55:02 kwik sshd[13997]: pam_unix(sshd:session): session opened for user djgw@LOCAL by (uid=0)
Apr 22 14:55:05 kwik unix_chkpwd[14036]: password check failed for user (djgw)
Apr 22 14:55:05 kwik sudo: pam_unix(sudo-i:auth): authentication failure; logname=djgw uid=1001 euid=0 tty=/dev/pts/1 ruser=djgw rhost=  user=djgw
Apr 22 14:55:05 kwik sudo: pam_sss(sudo-i:auth): authentication success; logname=djgw uid=1001 euid=0 tty=/dev/pts/1 ruser=djgw rhost= user=djgw
Apr 22 14:55:05 kwik sudo:     djgw : TTY=pts/1 ; PWD=/home/djgw ; USER=root ; COMMAND=/bin/bash

If you diff the system-auth-ac and password-auth-ac files with the RHEL7.1 and 7.2 versions and apply the differences from 7.1 to 7.2, it works as expected.
Comment 5 Tomas Mraz 2016-04-22 09:17:58 EDT
So the reason why the ssh succeeds is because the @LOCAL domain is appended to the user name.

I have to say that simply your configuration is not supported anymore by authconfig and you will have to configure the PAM stack manually.

authconfig was never intended to support all the various configurations and use-cases possible only a few selected ones.
Comment 6 Dennis Ortsen 2016-04-22 09:34:44 EDT
As a customer, that's not how I see it:

First:
I deploy RHEL7.1 and run a command to enable sssd and configure 2 domains.

I later deploy RHEL7.2 and run the same command to achieve the same thing.

Something that worked before, doesn't anymore on the recently deployed server, that's not what I expected.

Second:
When I update all RHEL7 servers to the latest release and would run just "authconfig --updateall" it would change the PAM configuration and thus break something that worked before.

That's not really desired in any production environment of any scale.

Third:
I haven't seen any remarks about unsupported, obsoleted or deprecated notices in any RHEL 7 documentation on redhat.com mentioning anything about certain configurations that will not be supported anymore from a 7.1 to 7.2 update. If such a notice, message would have been clear to me, I wouldn't have updated to 7.2 blindly or would have made a different sssd configuration. I believe I've followed the RHEL7 documentation on redhat.com, some warning about deprecation or unsupported configuration would have been helpful.
Comment 7 Tomas Mraz 2016-04-22 09:50:59 EDT
Please use regular Red Hat support channels to report the issue so it can be properly prioritized for fixing.

https://www.redhat.com/support/
Comment 8 Sumit Bose 2016-04-22 09:55:45 EDT
Please try to add '--enablenis' to the authconfig options, this should generate the old version of the PAM configuration
Comment 9 Dennis Ortsen 2016-04-25 06:38:24 EDT
@ Tomas Mraz: will do that.
@ Sumit Boze: adding that option helps a lot. It creates the system-auth-ac and password-auth-ac that looks like the one from RHEL7.1. I'll investigate whether this is a workaround for us (if you may call it that, if this is all "by design")
Comment 10 David Gardner 2016-10-06 06:56:01 EDT
Whilst this may be "intended behaviour", according to the change for 2-factor-auth in Bug 1204864, is it considered fine to change behaviour in this way for something so commonly-used during a point release of RHEL?

If so then we will need to test much more thoroughly when updating point-releases, as I would not expect a breaking change like this for adding support for a new feature in SSSD (which obviously no-one will yet be using).
Comment 22 errata-xmlrpc 2017-08-01 03:27:56 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2285

Note You need to log in before you can comment on or make changes to this bug.