Bug 781203 - SSO: Logged in with kerberos user id, asking smart card pin while unlocking a locked screen.
SSO: Logged in with kerberos user id, asking smart card pin while unlocking a...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pam_krb5 (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Robbie Harwood
Asha Akkiangady
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-12 18:11 EST by Asha Akkiangady
Modified: 2016-06-14 13:20 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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.

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