Bug 1298253 - Screen lock prompts for smartcard user password and not smartcard pin when logged in using smartcard pin
Screen lock prompts for smartcard user password and not smartcard pin when lo...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.8
Unspecified Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Sumit Bose
Steeve Goveas
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-13 10:38 EST by Roshni
Modified: 2016-05-10 16:26 EDT (History)
9 users (show)

See Also:
Fixed In Version: sssd-1.13.3-11.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 16:26:24 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 Roshni 2016-01-13 10:38:38 EST
Description of problem:
Screen lock prompts for smartcard user password and not smartcard pin when logged in using smartcard pin

Version-Release number of selected component (if applicable):
sssd-1.13.3-1.el6

How reproducible:
always

Steps to Reproduce:
1. ipa-client-install (after the required configuration changes are made)
2. Create an ipa user and add the signing certifcate on the smartcard to the ipa user
3. Change sssd.conf as follows

[pam]
pam_cert_auth = True

4. Login through gdm using the smartcard pin
5. Lock the screen

Actual results:
Locked screen prompts for smartcard user password.

Expected results:
Locked screen should prompt for smartcard pin.

Additional info:
Comment 2 Sumit Bose 2016-01-14 04:52:17 EST
Created upstream ticket https://fedorahosted.org/sssd/ticket/2925
Comment 3 Jakub Hrozek 2016-01-20 03:27:45 EST
* master: e9c42ec738c213bd5f351567c20d404a280b32d0
* sssd-1-13: 58e388cded594c64f9d094a2b3ac374bbd860fe5
Comment 5 Roshni 2016-01-21 11:19:58 EST
[root@dhcp123-129 ~]# rpm -qi sssd
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.13.3                            Vendor: Red Hat, Inc.
Release     : 11.el6                        Build Date: Thu 21 Jan 2016 04:19:26 AM EST
Install Date: Thu 21 Jan 2016 11:00:26 AM EST      Build Host: x86-032.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.13.3-11.el6.src.rpm
Size        : 35147                            License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon

[root@dhcp123-129 ~]# rpm -qi ipa-client
Name        : ipa-client                   Relocations: (not relocatable)
Version     : 3.0.0                             Vendor: Red Hat, Inc.
Release     : 50.el6                        Build Date: Thu 07 Jan 2016 03:55:55 AM EST
Install Date: Thu 14 Jan 2016 12:20:27 PM EST      Build Host: x86-032.build.eng.bos.redhat.com
Group       : System Environment/Base       Source RPM: ipa-3.0.0-50.el6.src.rpm
Size        : 318993                           License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.freeipa.org/
Summary     : IPA authentication for use on clients

Verification steps:

1. ipa-client-install --mkhomedir (after the required configuration changes are made)
2. Create an ipa user and add the signing certifcate on the smartcard to the ipa user
3. Change sssd.conf as follows

[pam]
pam_cert_auth = True

4. Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1297034 as follows
/etc/pam.d/system-auth

#auth        required      pam_env.so
#auth        sufficient    pam_fprintd.so
#auth        sufficient    pam_unix.so nullok try_first_pass
#auth        requisite     pam_succeed_if.so uid >= 500 quiet
#auth        sufficient    pam_sss.so use_first_pass
#auth        required      pam_deny.so
auth        required      pam_env.so
auth        sufficient    pam_fprintd.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

/etc/pam.d/password-auth

#auth        required      pam_env.so
#auth        sufficient    pam_unix.so nullok try_first_pass
#auth        requisite     pam_succeed_if.so uid >= 500 quiet
#auth        sufficient    pam_sss.so use_first_pass
#auth        required      pam_deny.so
auth        required      pam_env.so
auth        sufficient    pam_fprintd.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

5. Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1299066 as follows

setsebool -P allow_ypbind true

6. Login through gdm using the smartcard pin (workaround for 
7. Lock the screen
8. Locked screen prompts for smartcard pin
Comment 6 Roshni 2016-01-21 15:25:07 EST
I am changing the bug back to ASSIGNED:

I tried this scenario:

1. Login using ipa user password (no smartcard inserted)
2. After login, insert the smartcard
3. Lock the screen while the smartcard is in the inserted state

Locked screen prompts for smartcard pin and successfully accepts the smartcard pin to unlock the screen. 

The expected behaviour is ipa user password should be prompted for by the locked screen.
Comment 7 Sumit Bose 2016-01-22 02:56:36 EST
This is currently expected behavior (as the other way round) as long as the Smartcard belongs to the user. What should be checked is that the password is prompted if the Smartcard of a different user is entered.
Comment 8 Martin Kosek 2016-01-25 06:11:45 EST
Should the bug be moved back to ON_QA then?
Comment 9 Roshni 2016-01-25 12:21:32 EST
Checked the case in comment 7 and seeing expected result. Marking the bug verified
Comment 11 errata-xmlrpc 2016-05-10 16:26:24 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://rhn.redhat.com/errata/RHBA-2016-0782.html

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