Bug 1238342

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?

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

I'm not going to be able to get to this for RHEL 7.2, OK for RHEL 7.3..

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Arg, I didn't intend to have the bug closed, only push it out to rhel 7.3

> 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

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.

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

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).

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.

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?

[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: 
-----------------------------------------------------------

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

moving to 7.4 with the expectation that it will be closed as a configuration issue.

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.

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

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

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.

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

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

If further information is required of me feel free to contact me at david.w.wheeler.

David

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

Created attachment 1282324 [details]
Script to setup local CAC login

*** Bug 1432655 has been marked as a duplicate of this bug. ***

did anyone find a fix for this? seeing the same issue on RHEL 7.9

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