Created upstream ticket https://fedorahosted.org/sssd/ticket/2925

* master: e9c42ec738c213bd5f351567c20d404a280b32d0
* sssd-1-13: 58e388cded594c64f9d094a2b3ac374bbd860fe5

[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

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.

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.

Should the bug be moved back to ON_QA then?

Checked the case in comment 7 and seeing expected result. Marking the bug verified

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