RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1238342 - GNOME Screen does not reliably respond to unlock with smart card
Summary: GNOME Screen does not reliably respond to unlock with smart card
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pam_pkcs11
Version: 7.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Bob Relyea
QA Contact: Asha Akkiangady
URL:
Whiteboard:
: 1432655 (view as bug list)
Depends On:
Blocks: 1420851 1467835 1472344
TreeView+ depends on / blocked
 
Reported: 2015-07-01 16:13 UTC by Michael Moore
Modified: 2023-05-03 16:02 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
The issue is not a Red Hat. There is not redhat fix.
Last Closed: 2017-10-03 18:54:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Script to setup local CAC login (2.22 KB, application/x-shellscript)
2017-05-25 16:46 UTC, David Wheeler
no flags Details

Description Michael Moore 2015-07-01 16:13:38 UTC
Description of problem:
Smart Card properly set up and allowing login with Card plus PIN.  Screen locks on card removal, but PIN credentials not always recognized on replacement of smart card and attempt to login.  This is intermittent

Version-Release number of selected component (if applicable):

RHEL 7.1 updated
How reproducible:
Inconsistent reproducible--It first appeared to be a numlock problem but it is deeper than that.  It happens on test machine with workstation but not (so far) on Desktop install of RHEL 7.0 (updated)

Steps to Reproduce:
1.Set up Smart card with CA and mapping of credentials to account.
2.Log in with smart card in Gnome-classic
3.Remove Smart card and screen locks
4.Replace smart card and it asks for PIN, but does not recognize PIN
5.remove smart card and login as user--it works (Smart card not set as required.  When it was set as required, it required cold boot to log on.)


Actual results:
Unlock denied especially after several hours of screen lock

Expected results:
Unlock granted

Additional info:
Still playing with parameters.  Will update.
Close Bug 1237350 where it was mis-reported.

Comment 2 Ray Strode [halfline] 2015-07-01 17:42:48 UTC
this is likely a problem in pam_pkcs11 or the smartcard driver. the unlock screen (which is actually provided by gnome-shell not gnome-screensaver) just ferries questions and answers around, without analyzing what those questions or answers are. reassigning to pam_pkcs11.

Somethings that might be useful:

1) the output of 
# modutil -dbdir /etc/pki/nssdb -list

2) the output of 
# certutil -d /etc/nssdb -L -h all

3) turning debugging on in /etc/pam_pkc11/pam_pkcs11.conf

4) when the problem happens, if you switch to a tty (with ctrl-alt-f6), if you use " " (i mean just hit spacebar), for the username, does it detect the smartcard? what messages does it print?

Comment 3 Michael Moore 2015-07-02 17:19:34 UTC
Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB

  2. CoolKey PKCS #11 Module
        library name: libcoolkeypk11.so
         slots: 1 slot attached
        status: loaded

         slot: Dell Dell Smart Card Reader Keyboard 00 00
        token:
-----------------------------------------------------------
0 ✓ wstation@wstation ~ $

wstation@wstation ~ $ certutil -d /etc/pki/nssdb -L -h all

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

noaa va root                                                 CT,C,C
NWSAR.GOV IPA CA                                             CT,C,C
dodca28                                                      CT,C,C
root CA cert                                                 CT,C,C

I am turning on debugging in pam_pksc11.conf and will follow with info on the output from alt-f6 " "
when the event next occurs

Comment 4 Bob Relyea 2015-07-06 21:53:26 UTC
I'm not going to be able to get to this for RHEL 7.2, OK for RHEL 7.3..

Comment 5 RHEL Program Management 2015-07-06 21:58:05 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 6 Bob Relyea 2015-07-07 02:43:53 UTC
Arg, I didn't intend to have the bug closed, only push it out to rhel 7.3

Comment 8 Bob Relyea 2016-01-12 19:30:09 UTC
> I am turning on debugging in pam_pksc11.conf and will follow with info on 
> the output from alt-f6 " "
> when the event next occurs

Have you been able to reproduce the problem with the debug output?

thanks,

bob

Comment 9 Bob Relyea 2016-01-21 23:33:54 UTC
OK, I'm having problems getting the screen-lock to work with the smart card. I've used authconfig-gtk to set the remove setting to 'lock', but I it doesn't seem to lock when I remove my token.

That being said, I believe this issue is related to gnome-terminal doing the locking.

This shows up in 2 places:

1) /etc/pam.d/system_auth has a line:

auth        [success=3 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid

Just before the pam_pkcs11 line. this prevents pam_pkcs11 from getting involved in things like su or ssh or telnet. Basically all the services you want pam_pkcs11 involved with should be listed. If gnome-shell doesn't use one of these strings when talking to pam, then the smart card will not be recognized at all.

system-config-authentication writes this file and line, so it needs to be updated to include whatever gnome-shell uses for unlocking the screen.


2) /etc/pam_pkcs11/pam_pkcs11.conf has a line:


        screen_savers = gnome-screensaver, xscreensaver, kscreensaver;

This is the list of screen savers. pam_pkcs11 behaves differently for login screens and screen savers. For login screens, it will allow pam_pkcs11 to go on if it can't authenticate. For screen savers, it looks to see PK11_LOGIN_TOKEN_NAME is set, and if it's not, then it allows password login. If it is then it requires login by the token.

This file is supplied by the pam_pkcs11 package and is modifiable by the user.

Two questions for Ray:

1) What dows gnome-shell pass as the 'application' to pam when unlocking the screen (hopefully it's different than what it passes when loging in [I'm pretty sure it is, otherwise smartcard login wouldn't work])

2) What config file should I look at to make sure the lock config on removal stuff is working? I'm pretty sure it's an environmental issue on my machine since the customer is getting that part to work.

Comment 10 Michael Moore 2016-01-25 16:38:44 UTC
OK well, now we know how to reproduce.

Here as we migrated to 7.2, almost everyone did not want GNOME-Classic so I set up some scripts to configure VNC local only to run other desktops on top of GNOME.  With the VNC in use, and nothing happening on GNOME except screen lock with token removal and with the expiration of an idle period, it worked reliably, so I thought the matter had been resolved.

I wish the best to you folk in resolving the issue.

Michael Moore

Comment 11 Bob Relyea 2016-01-26 01:57:05 UTC
Adding need into for rstrode to answer my gnome-shell questions (got cancelled as Michael supplied valuable information about  the current customer situation with the issue).

Comment 12 evan.hisey 2016-06-10 22:26:37 UTC
I am encountering the same issue with RHEL 7.2. Smartcard can login from GDM fine so that part works.

 When using Gnome-shell and the built in screen lock, pulling the smart card locks the screen, but you can not log back in. It requires doing a switch user and login back in as the original user with smartcard. 

When using XFCE with gnome-screensaver pulling the card does not lock the screen. You can lock the screen manually, and then unlocking with smartcard works as expected. 

It appears the smartcard reader is either not passing the trigger on to gnome-screensaver, or gnome-screensaver is looking some place other than dconf for it's settings.

Comment 13 Bob Relyea 2016-06-29 21:51:12 UTC
OK, I've configured my system and verified that lock/unlock is working on a base system.

I've seen issues on both RHEL 7 and RHEL 6 when /etc/pki/nssdb does is not configured correctly.

What does:
modutil -list -dbdir dbm:/etc/pki/nssdb
and
modutil -list -dbdir sql:/etc/pki/nssdb


as root produce?

Comment 14 evan.hisey 2016-06-29 22:08:50 UTC
[root@rhel-d-4178821 ~]# modutil -list -dbdir dbm:/etc/pki/nssdb

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
	 slots: 2 slots attached
	status: loaded

	 slot: NSS Internal Cryptographic Services
	token: NSS Generic Crypto Services

	 slot: NSS User Private Key and Certificate Services
	token: NSS Certificate DB

  2. Centrify PKCS #11 Module
	library name: /usr/lib64/pkcs11/libcentrifypkcs11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Dell Dell Smart Card Reader Keyboard 00 00
	token: 
-----------------------------------------------------------
[root@rhel-d-4178821 ~]# modutil -list -dbdir sql:/etc/pki/nssdb

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal Crypto Services
	 slots: 2 slots attached
	status: loaded

	 slot: NSS Internal Cryptographic Services
	token: NSS Generic Crypto Services

	 slot: NSS User Private Key and Certificate Services
	token: NSS Certificate DB

  2. CoolKey PKCS #11 Module
	library name: libcoolkeypk11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Dell Dell Smart Card Reader Keyboard 00 00
	token: 
-----------------------------------------------------------

Comment 15 Bob Relyea 2016-06-30 22:12:25 UTC
OK if you add coolkey to /etc/pki/nssdb:

modutil -add "CoolKey PKCS #11 Module" -libfile libcoolkeypk11.so -dbdir dbm:/etc/pki/nssdb

does that make lock and unlock work correctly (you'll need to logout and log back in).

bob

Comment 16 Bob Relyea 2016-07-05 20:23:12 UTC
moving to 7.4 with the expectation that it will be closed as a configuration issue.

Comment 17 evan.hisey 2016-07-18 17:11:44 UTC
Bob-
 Sorry about the delay, I still get the same operational situation with the change. New output of modutil -list -dbdir sql:/etc/pki/nssdb

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal Crypto Services
	 slots: 3 slots attached
	status: loaded

	 slot: NSS Internal Cryptographic Services
	token: NSS Generic Crypto Services

	 slot: NSS User Private Key and Certificate Services
	token: NSS Certificate DB

	 slot: NSS Application Slot 00000004
	token: NSS system database

  2. CoolKey PKCS #11 Module
	library name: libcoolkeypk11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Dell Dell Smart Card Reader Keyboard 00 00
	token: 



And modutil -list -dbdir dbm:/etc/pki/nssdb

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
	 slots: 2 slots attached
	status: loaded

	 slot: NSS Internal Cryptographic Services
	token: NSS Generic Crypto Services

	 slot: NSS User Private Key and Certificate Services
	token: NSS Certificate DB

  2. Centrify PKCS #11 Module
	library name: /usr/lib64/pkcs11/libcentrifypkcs11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Dell Dell Smart Card Reader Keyboard 00 00
	token: 

  3. CoolKey PKCS #11 Module
	library name: /usr/lib64/pkcs11/libcoolkeypk11.so
	 slots: 1 slot attached
	status: loaded

	 slot: Dell Dell Smart Card Reader Keyboard 00 00
	token: 


Is there some documentation on how this system should work and be configured? It is a little blackbox to me at the moment.

Comment 18 Bob Relyea 2016-11-15 18:36:31 UTC
So the Centrify driver is a vendor driver, Do you know what the customer is using it for? Is the smart card a centrify smart card?

What does /etc/pam_pkcs11.conf have in it?

bob

Comment 19 Danny Ascione 2016-12-15 15:33:45 UTC
Bob,

We have quite a few RedHat 7 machines and are also using Centrify as our SC middleware, so we are plagued with this issue.  We attempted your configuration change (modutil -add "CoolKey PKCS #11 Module" -libfile libcoolkeypk11.so -dbdir dbm:/etc/pki/nssdb) but received an "Unknown PKCS#11 exception"

We're looking for anything we can do to remedy this issue until an official fix becomes available.

Thank you

Comment 20 Eugene Burger 2016-12-23 19:31:15 UTC
Some information on this issue on this ticket from PMEL:

Initial login with CAC/PIN under 7.1, 7.2, and 7.3 Beta (have not yet
tried 7.3 Release) worked fine.  However, if the screen became locked
in any fashion, either by idle timeout or by the user removing their
CAC card to go on a break, it was not possible to re-authenticate and
unlock the screen.

We also see the 'sudo' problem that David mentions, but that is not
limited to RHEL 7.x.  Under 6.x, sudo attempts go like this:

$ sudo ls /root
Found the Smart card.
Welcome BOB.USER.A.1365459858!
Smart card PIN:  (I type my PIN here)
ERROR:pam_pkcs11.c:552: no valid certificate which meets all requirements found
Smart card login is required!
Sorry, try again.
Found the Smart card.
Welcome BOB.USER.A.1365459858!
Smart card PIN:

On some machines. an 'sudo' command immediately responds with three
copies of "Smart card login is required!" without ever prompting for
the PIN at all.  I believe this happens if you log in to Machine A's
console via CAC/PIN, and then use SSH to connect from there to another
CAC based system under the same username, but I haven't tested this in
the last couple of months, so may have the details (but not the
behavior) incorrect.

Our Linux sys-admin compiled this information, but let me know if any clarification is needed.

Comment 21 David Wheeler 2016-12-24 19:58:03 UTC
Additional information on this issue on this ticket from GSD

Sys Admin: David Wheeler with GSD/ESRL/NOAA in Boulder, CO.

I juststarted working with Sebastian Dunne (sebastian)
and Dave Sirrine (dsirrine) and was recently Eugene Burger who suggested I submit my summation of work-to-date on this issue to this Bug Ticket.

Started wiith:
Dell Optiplex 9020
RHEL 7.2
NFS /home/user via autofs
Authenticating on Active Directory via CentrifyDC with machine placed in a CAC only group policy.

Login after reboot or no users currently logged on to that machine:
Never failed during three months of operation.

Re-login from lock screen:
Machine would prompt for a user PIN when CAC was inserted but would fail repeatedly without attempting to authenticate against anything so no PIN or account lock-out would occur.
Using a workaround of clicking "Log on as a different user" would usually open to previous working environment without affecting applications or processes but would hang every two to four days or after the weekend.  When 'hung' condition wouldn't go away pressing Ctrl+Alt+F7 usually accomplished the same as the "Log on as a different user" workaround and became the default action but occasionally reboot was necessary.
Multi-user login:
Though another user could log on to the machine the GUI login screen would clear but not load the second user's desktop and effectively hang the GUI for the second user.
Sudo with Gnome-Terminal or virtual terminal (Ctrl+Alt+F2 thru F6):
If card was present in the card reader the machine would prompt for the user PIN but would fail repeatedly without attempting to authenticate against anything so no PIN or account lockout would occur.
SSH login from another machine:
Not attempted yet.

RHEL 7.3:
Another Sys Admin in my office had put up a RHEL 7.3 system with Centrify installed which suffered the same issue logging back in from a lock screen but she didn't recall that it would hang.
Multiuser login wasn't an issue
Sudo failed as above
SSH from another machine not tested
Currently:

The RHEL 7.2 machine was upgraded to 7.3 using Yum without improvement of login issues and we decided that we needed to start with a clean system that did not yet have Centrify Installed.  I now have the system ready and joined to Active Directory using the 'realm join' command and expect to start working with Redhat folks following the New Years holiday. David

Comment 22 David Wheeler 2016-12-24 20:02:42 UTC
Additional information on this issue on this ticket from GSD

Sys Admin: David Wheeler with GSD/ESRL/NOAA in Boulder, CO.

I just started working with Sebastian Dunne (sebastian)
and Dave Sirrine (dsirrine) and was recently Eugene Burger who suggested I submit my summation of work-to-date on this issue to this Bug Ticket.

Started wiith:
Dell Optiplex 9020
RHEL 7.2
NFS /home/user via autofs
Authenticating on Active Directory via CentrifyDC with machine placed in a CAC only group policy.

Login after reboot or no users currently logged on to that machine:
Never failed during three months of operation.

Re-login from lock screen:
Machine would prompt for a user PIN when CAC was inserted but would fail repeatedly without attempting to authenticate against anything so no PIN or account lock-out would occur.
Using a workaround of clicking "Log on as a different user" would usually open to previous working environment without affecting applications or processes but would hang every two to four days or after the weekend.  When 'hung' condition wouldn't go away pressing Ctrl+Alt+F7 usually accomplished the same as the "Log on as a different user" workaround and became the default action but occasionally reboot was necessary.
Multi-user login:
Though another user could log on to the machine the GUI login screen would clear but not load the second user's desktop and effectively hang the GUI for the second user.
Sudo with Gnome-Terminal or virtual terminal (Ctrl+Alt+F2 thru F6):
If card was present in the card reader the machine would prompt for the user PIN but would fail repeatedly without attempting to authenticate against anything so no PIN or account lockout would occur.
SSH login from another machine:
Not attempted yet.

RHEL 7.3:
Another Sys Admin in my office had put up a RHEL 7.3 system with Centrify installed which suffered the same issue logging back in from a lock screen but she didn't recall that it would hang.
Multiuser login wasn't an issue
Sudo failed as above
SSH from another machine not tested
Currently:

The RHEL 7.2 machine was upgraded to 7.3 using Yum without improvement of login issues and we decided that we needed to start with a clean system that did not yet have Centrify Installed.  I now have the system ready and joined to Active Directory using the 'realm join' command and expect to start working with Redhat folks following the New Years holiday. David

Comment 26 David Wheeler 2017-03-23 16:26:47 UTC
If further information is required of me feel free to contact me at david.w.wheeler.

David

Comment 27 David Wheeler 2017-05-25 16:44:45 UTC
Below is the latest info that I posted to the Red Hat case as well as the Centrify case that we have open on this problem.

"We can successfully and consistently unlock the screensaver on RHEL 7.3 using a local account without Centrify.  We are not able to duplicate this test with Active Directory onsite since we can't add the machine to a zone.  I have added this information to the Centrify support case and stated that we believe this is a Centrify issue." 

The Centrify support person said said that he would pass the information along to their developers to investigate and let me know when he heard something (May 4).



Thanks, David



Steps to reproduce results:



1. Install RHEL 7.3 with Gnome 3 + Smart Card package

2. Create local user (login name will be used in cn_map file)

3. Register machine - rhel-7-workstation-rpms

4. Run setup-local-cac.sh script (see attached - Removed .sh from end to send)

5. Verify the script output and then edit the /etc/pam_pkcs11/cn_map

    file as noted on the last line of the script output using the local user

    login name at the end

6. Login as local user using smart card, lock the screen and reinsert smart

    card and enter pin after light stops flashing (Reboot may be helpful)



Centrify Support Case 170228-112817 : Still unable to unlock screen with Smart Card on RHEL 7

Comment 28 David Wheeler 2017-05-25 16:46:04 UTC
Created attachment 1282324 [details]
Script to setup local CAC login

Comment 31 Chris Williams 2017-08-14 18:33:14 UTC
*** Bug 1432655 has been marked as a duplicate of this bug. ***

Comment 44 wilson.mbochi@cesicorp.com 2023-05-03 05:56:19 UTC
did anyone find a fix for this? seeing the same issue on RHEL 7.9

Comment 45 David Wheeler 2023-05-03 16:02:32 UTC
Well this is a 'blast from the past'.

I am not aware of a fix. Even with Rhel 8 I have to use the "Log in as another user" link on the login screen.

David


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