Red Hat Bugzilla – Bug 1204864
Let SSSD prompt non-local users for passwords
Last modified: 2015-11-19 07:44:14 EST
+++ 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.
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.
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.