Bug 1327085

Summary:	Don't prompt for password if there is already one on the stack
Product:	Red Hat Enterprise Linux 7	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Amith <apeetham>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	dlavu, grajaiya, jhrozek, lslebodn, michal.skrivanek, mkosek, mzidek, pbrezina, sbose, sgoveas
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.15.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 08:58:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jakub Hrozek 2016-04-14 09:19:03 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2984

Some projects we integrate with (like RHEV-M) have a guest agent that the RHEV engine feeds the password the user provided to access the RHEV engine. It's expected that the guest agent then puts the password on the PAM stack in the virtualized guest and provide a kind of a single-sign-on this way.

But since recent versions, we tend to prompt for password in sssd (unless use_first_pass is used) itself to make sure we can run the preauth first and prompt for 2FA.

We should enhance pam_sss to handle this kind of a situation better and if there is a password on the stack, just try to authenticate with it.

Comment 5 Jakub Hrozek 2016-09-14 14:11:56 UTC

I'm sorry, but this bug needs to be traiged in 7.4.0 first, we can backport to 7.3.x later.

Comment 6 Lukas Slebodnik 2017-03-02 11:58:42 UTC

master:
* 6dd271fdcf6ceb0afd77e703c98897672da3671a

Comment 15 Dan Lavu 2017-05-26 18:11:43 UTC

Verified against sssd-1.15.2-30.el7.x86_64, 


May 26 14:05:25 qe gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=dlavu
May 26 14:05:26 qe gdm-ovirtcred]: pam_unix(gdm-ovirtcred:session): session opened for user dlavu by (uid=0)
May 26 14:05:26 qe polkitd[685]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.33, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
May 26 14:05:36 qe userhelper[2500]: pam_succeed_if(ovirt-locksession:auth): requirement "user = ovirtagent" was met by user "ovirtagent"
May 26 14:05:36 qe userhelper[2500]: running '/usr/share/ovirt-guest-agent/LockActiveSession.py' with root privileges on behalf of 'ovirtagent'
May 26 14:06:37 qe userhelper[3328]: pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" was met by user "ovirtagent"
May 26 14:06:37 qe userhelper[3328]: running '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf of 'ovirtagent'
May 26 14:08:38 qe userhelper[3462]: pam_succeed_if(ovirt-container-list:auth): requirement "user = ovirtagent" was met by user "ovirtagent"
May 26 14:08:38 qe userhelper[3462]: running '/usr/share/ovirt-guest-agent/container-list' with root privileges on behalf of 'ovirtagent'

Comment 16 errata-xmlrpc 2017-08-01 08:58:07 UTC

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/RHEA-2017:2294