Bug 1329598
| Summary: | authconfig breaks PAM system-auth-ac password-auth-ac for sssd in RHEL7.2 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Dennis Ortsen <dortsen> |
| Component: | authconfig | Assignee: | Pavel Březina <pbrezina> |
| Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | afarley, bugzilla.redhat.com, dortsen, herrold, jhrozek, pkis, sbose, tmraz, vondruch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 07:27:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dennis Ortsen
2016-04-22 10:28:59 UTC
Can you add the PAM related messages from /var/log/secure as well? 'journalctl -r -t sudo' should show them, too. 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. 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. 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. Please use regular Red Hat support channels to report the issue so it can be properly prioritized for fixing. https://www.redhat.com/support/ Please try to add '--enablenis' to the authconfig options, this should generate the old version of the PAM configuration @ 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") 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). 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 |