Bug 1204864

Summary:	Let SSSD prompt non-local users for passwords
Product:	Red Hat Enterprise Linux 7	Reporter:	Sumit Bose <sbose>
Component:	authconfig	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Dalibor Pospíšil <dapospis>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	ebenes, extras-qa, jlieskov, pkis, tmraz
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	authconfig-6.2.8-10.el7	Doc Type:	Enhancement
Doc Text:	The authconfig utility has been modified to configure the Pluggable Authentication Module (PAM) stack differently when support for the System Security Service Daemon (SSSD) is enabled implicitly or explicitly. Previously, only the pam_unix module was set to prompt non-local users for password, which prevented SSSD from properly prompting for two-factor authentication credentials. With this update, it is possible to update the PAM configuration with authconfig, so that only SSSD prompts non-local users for the password. This enhancement results in better user experience with SSSD two-factor authentication.	Story Points:	---
Clone Of:	1195817	Environment:
Last Closed:	2015-11-19 12:44:14 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:
Bug Depends On:	1195817
Bug Blocks:

Description Sumit Bose 2015-03-23 16:19:03 UTC

+++ This bug was initially created as a clone of Bug #1195817 +++

Description of problem:
The next version of SSSD will be able to prompt users with 2-Factor-Authentication (2FA) separately for the two factors. This way the first factor (long term password) can be used e.g. to unlock the users keyring or for offline authentication.

With the current configuration pam_unix will always prompt the user for a password. Letting SSSD ask users of 2FA again for the password will lead to a bad user experience. Letting SSSD only ask for the second factor will make it hard for applications like gdm to show specific 2FA dialogs.

It would be best if pam_unix would only ask for password for local users and let SSSD prompt SSSD users. To achieve this pam_localuser could be added to the PAM configuration like in the following example:

auth        required  pam_env.so
auth        sufficient pam_fprintd.so
auth        [default=1 success=ok] pam_localuser.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 forward_pass
auth        required      pam_deny.so

To allow to configure the old version without pam_localuser as well the new line should only be added if --enableforcelegacy is not set.

--- Additional comment from Sumit Bose on 2015-02-24 11:18:10 EST ---

I'd be happy to help here. Please tell me if you want me to provide a patch or if I shall test patches.

--- Additional comment from Sumit Bose on 2015-03-23 12:10:20 EDT ---



--- Additional comment from Sumit Bose on 2015-03-23 12:10:56 EDT ---



--- Additional comment from Sumit Bose on 2015-03-23 12:17:29 EDT ---

Please find attached a patch which adds a new option --enableSSSDAuthPrompting which adds the pam_localuser line and  changes the option of pam_sss to forward_pass in the auth section if SSSD authentication is enabled (explicit or implicit).

Since with this approach no existing behavior is changed and the new behavior must be enabled explicitly (e.g. by ipa-client-install) I would like to ask you if you can consider to include the patch in the Fedora 22 version of authconfig.

Comment 1 Tomas Mraz 2015-07-03 09:51:51 UTC

We made this change non-optional (except it is disabled when --enablenis is present) in Fedora. I think it is fairly safe to make it non-optional in RHEL-7 as well.

Comment 4 errata-xmlrpc 2015-11-19 12:44:14 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://rhn.redhat.com/errata/RHBA-2015-2403.html