Red Hat Bugzilla – Full Text Bug Listing
|Summary:||SSO: Logged in with kerberos user id, asking smart card pin while unlocking a locked screen.|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Asha Akkiangady <aakkiang>|
|Component:||pam_krb5||Assignee:||Robbie Harwood <rharwood>|
|Status:||NEW ---||QA Contact:||Asha Akkiangady <aakkiang>|
|Version:||7.0||CC:||aakkiang, dpal, jmagne, nalin, nsoman, pkis, prc, rrelyea, tmraz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Asha Akkiangady 2012-01-12 18:11:37 EST
Description of problem: Version-Release number of selected component (if applicable): gdm-2.16.0-59.el5 gnome-screensaver-2.16.1-8.el5_7.5 pam_krb5-2.2.14-22.el5 authconfig-5.3.21-7.el5 How reproducible: Steps to Reproduce: 1. This user is not in the /etc/passwd file, authentication is configured with userDatabase to LDAP server, kerberos support enabled, the KDC information is provided and smart card support is enabled. Use smart card: ON Enforce smart card: OFF Log out behavior configured to: Ignore smart card removal 2. Login to desktop with Kerberos userid and password. 3. Kerberos credential issued successfully. 4. Insert an enrolled smartcard for the user and perform e-mail signing or encryption/decryption. 5. Lock the screen by selecting menu option System -> Lock Screen and leave the smartcard in the card reader. 6. Move the mouse, this request for a password. 7. Enter the correct kerberos password. Actual results: Smart card PIN is requested. Entering kerberos password again on the PIN prompt unlocks the locked screen. Expected results: Screen should be unlocked. Additional info: [root@dhcp231-57 ~]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth [success=3 default=ignore] pam_succeed_if.so service notin login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid auth [success=ok ignore=2 default=die] pam_pkcs11.so wait_for_card auth optional pam_krb5.so use_first_pass no_subsequent_prompt auth sufficient pam_permit.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account [default=bad success=ok auth_err=ignore user_unknown=ignore ignore=ignore] pam_krb5.so account required pam_permit.so password optional pam_pkcs11.so password requisite pam_cracklib.so authtok_type=LDAP try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so session optional pam_ldap.so
Comment 1 Ray Strode [halfline] 2012-01-12 18:31:08 EST
This is not a gnome-screensaver bug. It's either a pam_pkcs11 bug or a pam_krb5 bug, but we fixed it in pam_pkcs11 several years ago, so it's probably pam_krb5 pkinit-y bug. Basically pam_pkcs11 has something like: /* bail if the user didn't log in with smart card */ if (getenv("PKCS11_LOGIN_TOKEN_NAME") is empty) return PAM_IGNORE; So my guess is the second pam_krb5 line in the auth section is getting run and it's not ignoring the smartcard like it should.
Comment 2 Nalin Dahyabhai 2012-03-21 18:38:49 EDT
Punting forward, as the underpinnings of this setup have changed and we're not making big changes in this area in EL5 at this point.
Comment 5 Nalin Dahyabhai 2013-07-16 13:22:39 EDT
(In reply to Ray Strode [halfline] from comment #1) > Basically pam_pkcs11 has something like: > > /* bail if the user didn't log in with smart card */ > if (getenv("PKCS11_LOGIN_TOKEN_NAME") is empty) return PAM_IGNORE; > > So my guess is the second pam_krb5 line in the auth section is getting run > and it's not ignoring the smartcard like it should. With that configuration, then, a "no_subsequent_prompt" option added to that second invocation should also disable any attempts to gather PINS or passwords for PKINIT credentials.
Comment 6 Tomas Mraz 2013-07-17 05:25:30 EDT
I slightly wonder why the no_subsequent_prompt option was needed when use_first_pass should have basically the same meaning. However if I add this option in authconfig, should it be always added or only in case the smartcard authentication is enabled?
Comment 7 Nalin Dahyabhai 2013-10-07 09:51:57 EDT
(In reply to Tomas Mraz from comment #6) > I slightly wonder why the no_subsequent_prompt option was needed when > use_first_pass should have basically the same meaning. > > However if I add this option in authconfig, should it be always added or > only in case the smartcard authentication is enabled? Only for the smart card case, please. Distinguishing between a user's long-term password (which use_first_pass affects) and non-password information that we may have to ask for (smart card PINs, OTP values) is... well, kind of a mess when the PAM_AUTHTOK can be any of those things, so no_subsequent_prompt, in combination with use_first_pass/try_first_pass, lets you control whether or not the module will allow the library to trigger an additional prompt, and whether or not it will just hand back the PAM_AUTHTOK if it does.