Bug 781203

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:	CLOSED WONTFIX	QA Contact:	Asha Akkiangady <aakkiang>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0	CC:	aakkiang, dpal, jmagne, nalin, nsoman, pkis, prc, rrelyea, tmraz
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-17 19:24:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Asha Akkiangady 2012-01-12 23:11:37 UTC

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 23:31:08 UTC

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 22:38:49 UTC

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 17:22:39 UTC

(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 09:25:30 UTC

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 13:51:57 UTC

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