Bug 1389796 - Smartcard authentication with UPN as logon name might fail
Summary: Smartcard authentication with UPN as logon name might fail
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd   
(Show other bugs)
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Scott Poore
Marc Muehlfeld
URL:
Whiteboard:
Keywords:
: 1377322 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-28 16:39 UTC by Sumit Bose
Modified: 2017-08-01 09:00 UTC (History)
11 users (show)

Fixed In Version: sssd-1.15.2-37.el7
Doc Type: Known Issue
Doc Text:
*GDM* fails to authenticate using a smart card When using smart card authentication, the System Security Services Daemon's (SSSD) PAM responder does not verify if the login name is a Kerberos user principal name (UPN). As a consequence, the *gdm-password* pluggable authentication module (PAM) shows the password prompt instead of the smart card PIN prompt when using a user principal name (UPN) as login name. As a result, smart card authenticating to the GNOME display manager (GDM) fails.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 09:00:03 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:2294 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Sumit Bose 2016-10-28 16:39:57 UTC
Description of problem:
During Smartcard authentication SSSD's PAM responder does not check if the logon name is a UPN. In general this is not an issue because most login programs like /bin/logon or sshd canonicalize the name before calling the PAM stack. Currently it looks that only gdm-password does send the original name the user entered to the PAM stack (this is good and should not be changed). 

Version-Release number of selected component (if applicable):
sssd-1.14.0-43.el7

How reproducible:


Steps to Reproduce:
1. Prepare a system for Smartcard authentication with SSSD but do not enable the Smartcard support in GDM
2. Try Smartcard authentication and use a UPN which is different from the actual user name returned by 'getent passwd'


Actual results:
Password prompt is shown

Expected results:
Smartcard PIN prompt should be shown

Additional info:
Issue originally reported in https://bugzilla.redhat.com/show_bug.cgi?id=1377322

Comment 1 Sumit Bose 2016-10-28 16:42:49 UTC
*** Bug 1377322 has been marked as a duplicate of this bug. ***

Comment 3 Jakub Hrozek 2016-11-10 21:25:33 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3240

Comment 7 Scott Poore 2017-05-04 16:25:05 UTC
This partially worked:

So far:

Make sure GDM is not set to use smartcards:

authconfig --enablesssdauth --enablesssd --disablesmartcard --updateall

Make sure sssd is set to use certs with pam:

vi /etc/sssd/sssd.conf
# add pam_cert_auth = True to [pam] section

reboot

insert card

GDM should not prompt for pin right away.

Entered:  scuser107@TESTRELM.TEST

Prompted for pin, entered,

login successful.

Making sure user is correct:

[root@dhcp129-184 ~]# getent passwd scuser107
scuser107:*:576400135:576400135:f l:/home/scuser107:/bin/sh

[root@dhcp129-184 ~]# getent passwd scuser107@TESTRELM.TEST
scuser107:*:576400135:576400135:f l:/home/scuser107:/bin/sh

Comment 8 Scott Poore 2017-05-04 16:25:39 UTC
The part that failed:

Changed pricipal alias to alias_scuser107@TESTRELM.TEST

[root@dhcp129-184 ~]# ipa user-mod scuser107 --principal alias_scuser107@TESTRELM.TEST
-------------------------
Modified user "scuser107"
-------------------------
  User login: scuser107
  First name: f
  Last name: l
  Home directory: /home/scuser107
  Login shell: /bin/sh
  Principal name: scuser107@TESTRELM.TEST
  Principal alias: alias_scuser107@TESTRELM.TEST
  Email address: scuser107@testrelm.test
  UID: 576400135
  GID: 576400135
  Certificate: MII...,
               MIID...
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

logged out.

entered user:  alias_scuser107@TESTRELM.TEST

Did not ask for pin...

Comment 9 Jakub Hrozek 2017-05-23 09:34:29 UTC
Additional patches:
 * 29d063505c07127f7747405b1a61d8f782673645
 * ec9ac22d699a17d590b1d4ba9ba3750eb719f340
 * 870b58a6cc6b5cf92a6503c1578e5c21617c8d40

Comment 11 Scott Poore 2017-05-23 18:30:19 UTC
This is still failing.

[root@dhcp129-184 sssd]# ipa user-mod scuser107 --principal alias_scuser107@TESTRELM.TEST
-------------------------
Modified user "scuser107"
-------------------------
  User login: scuser107
  First name: f
  Last name: l
  Home directory: /home/scuser107
  Login shell: /bin/sh
  Principal name: scuser107@TESTRELM.TEST
  Principal alias: alias_scuser107@TESTRELM.TEST
  Email address: scuser107@testrelm.test
  UID: 576400135
  GID: 576400135
  Certificate: MII...
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Roles: hostadmin
  Kerberos keys available: True

Then attempting to login first as scuser107 now fails:

May 23 12:15:43 dhcp129-184 gdm-password]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=scuser107
May 23 12:15:43 dhcp129-184 gdm-password]: pam_sss(gdm-password:auth): received for user scuser107: 4 (System error)
May 23 12:15:43 dhcp129-184 gdm-password]: gkr-pam: no password is available for user

From sssd_pam.log:

(Tue May 23 12:15:48 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is scuser107@testrelm.test
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [scuser107] added to PAM initgroup cache
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_dom_forwarder] (0x0400): User and certificate user do not match, continue with other authentication methods.
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data:
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: testrelm.test
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): user: scuser107@testrelm.test
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): service: gdm-password
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/tty1
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 4
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 3864
(Tue May 23 12:15:48 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: scuser107
(Tue May 23 12:15:48 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x55df49bf1f60


sssd_testrelm.test.log:

(Tue May 23 12:15:43 2017) [sssd[be[testrelm.test]]] [krb5_auth_done] (0x0020): UPN used in the request [alias_scuser107@TESTRELM.TEST] and returned UPN [scuser107@TESTRELM.TEST] differ by more than just the cas
(Tue May 23 12:15:43 2017) [sssd[be[testrelm.test]]] [check_wait_queue] (0x1000): Wait queue for user [scuser107@testrelm.test] is empty.
(Tue May 23 12:15:43 2017) [sssd[be[testrelm.test]]] [krb5_auth_queue_done] (0x0040): krb5_auth_recv failed with: 22
(Tue May 23 12:15:43 2017) [sssd[be[testrelm.test]]] [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid argument


In krb5_child.log:


(Tue May 23 12:15:49 2017) [[sssd[krb5_child[3869]]]] [sss_krb5_responder] (0x4000): Got question [pkinit].
(Tue May 23 12:15:49 2017) [[sssd[krb5_child[3869]]]] [answer_pkinit] (0x4000): [0] Identity [PKCS11:module_name=/usr/lib64/pkcs11/opensc-pkcs11.so:slotid=0:token=demosc1 (OpenSC Card)] flags [0].
(Tue May 23 12:15:49 2017) [[sssd[krb5_child[3869]]]] [answer_pkinit] (0x4000): Setting pkinit_prompting.
(Tue May 23 12:15:49 2017) [[sssd[krb5_child[3869]]]] [sss_child_krb5_trace_cb] (0x4000): [3869] 1495563349.747304: Preauth module pkinit (147) (info) returned: 0/Success

(Tue May 23 12:15:50 2017) [[sssd[krb5_child[3869]]]] [sss_krb5_prompter] (0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1] EINVAL.
(Tue May 23 12:15:50 2017) [[sssd[krb5_child[3869]]]] [sss_krb5_prompter] (0x4000): Prompt [0][demosc1 (OpenSC Card)            PIN].
(Tue May 23 12:15:50 2017) [[sssd[krb5_child[3869]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts.

Comment 13 Sumit Bose 2017-05-24 09:22:59 UTC
The actual error is:

(Tue May 23 12:15:43 2017) [sssd[be[testrelm.test]]] [krb5_auth_done] (0x0020): UPN used in the request [alias_scuser107@TESTRELM.TEST] and returned UPN [scuser107@TESTRELM.TEST] differ by more than just the case.

The authentication was successful but SSSD was too picky with the returned principal. I opened https://pagure.io/SSSD/sssd/issue/3408 to track this.

(As a workaround you can set krb5_use_enterprise_principal=True in sssd.conf on the client but it might be easier to just wait for a new package with the fix)

Comment 14 Sumit Bose 2017-05-24 15:43:57 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3408

Comment 15 Lukas Slebodnik 2017-05-25 11:14:53 UTC
master:
* ca95807a9060e454ee68f6f30558d6f7ee968c39

Comment 17 Scott Poore 2017-05-25 19:03:26 UTC
FYI, I didn't seem to have any more luck with the sssd option:

krb5_use_enterprise_principal = True


Still failed with alias_scuser107@TESTRELM.TEST

anything else I could try?  or just wait for the SSSD update?

Comment 18 Jakub Hrozek 2017-05-26 11:13:37 UTC
(In reply to Scott Poore from comment #17)
> FYI, I didn't seem to have any more luck with the sssd option:
> 
> krb5_use_enterprise_principal = True
> 
> 
> Still failed with alias_scuser107@TESTRELM.TEST
> 
> anything else I could try?  or just wait for the SSSD update?

Hmm, interesting, then I suspect there might still be another bug. Could you please at any rate retest with the latest build (sssd-1.15.2-37.el7) and attach new debug messages? The fix that Sumit did with the canonicalization is correct and required either way, but chances are there is yet another issue lurking somewhere..

Comment 20 Scott Poore 2017-05-26 20:29:28 UTC
Verified.

Version ::

sssd-1.15.2-37.el7.x86_64

Results ::

Looks like GDM login with all three username options worked:


From /var/log/secure:

May 26 14:19:36 dhcp129-184 gdm-password]: pam_unix(gdm-password:session): session opened for user scuser107@TESTRELM.TEST by (uid=0)
May 26 14:21:19 dhcp129-184 gdm-password]: pam_unix(gdm-password:session): session opened for user alias_scuser107@TESTRELM.TEST by (uid=0)
May 26 14:22:31 dhcp129-184 gdm-password]: pam_unix(gdm-password:session): session opened for user scuser107 by (uid=0)

[root@dhcp129-184 sssd]# ipa user-show scuser107|sed 's/\(Certificate: MII\).*$/\1..../'
  User login: scuser107
  First name: f
  Last name: l
  Home directory: /home/scuser107
  Login shell: /bin/sh
  Principal name: scuser107@TESTRELM.TEST
  Principal alias: alias_scuser107@TESTRELM.TEST
  Email address: scuser107@testrelm.test
  UID: 576400135
  GID: 576400135
  Certificate: MII....
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Roles: hostadmin
  Kerberos keys available: True

Comment 21 Scott Poore 2017-05-26 20:30 UTC
Created attachment 1282762 [details]
sssd logs from 3 successful logins from upn test

Comment 22 Scott Poore 2017-05-26 20:54:20 UTC
Jakub,

I'm moving this back to ON_QA for now because I tried with option in the domain section again and it failed:

krb5_use_enterprise_principal = True

From krb5_child.log:

(Fri May 26 14:34:25 2017) [[sssd[krb5_child[20119]]]] [sss_child_krb5_trace_cb] (0x4000): [20119] 1495830865.808791: Response was from master KDC

(Fri May 26 14:34:25 2017) [[sssd[krb5_child[20119]]]] [sss_child_krb5_trace_cb] (0x4000): [20119] 1495830865.808832: Received error from KDC: -1765328318/Certificate mismatch

On IPA server in krb5kdc.log I see:

May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): Doing certauth authorize for [alias_scuser107\@TESTRELM.TEST@TESTRELM.TEST]
May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): Got cert filter [(|(userCertificate;binary=\30\82\04\0d...
May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): No matching entry found
May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): preauth (pkinit) verify failure: Certificate mismatch


Would you prefer to continue troubleshooting this in this bug or should I open another?

Thanks,
Scott

Comment 24 Sumit Bose 2017-05-30 11:32:41 UTC
> (In reply to Scott Poore from comment #22)
...
> 
> On IPA server in krb5kdc.log I see:
> 
> May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): Doing
> certauth authorize for [alias_scuser107\@TESTRELM.TEST@TESTRELM.TEST]

This is a server-side issue, either IPA or krb5. I have to check with Matt which component is expected to handled the conversion from the enterprise principal to the plain version.

> May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): Got
> cert filter [(|(userCertificate;binary=\30\82\04\0d...
> May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info): No
> matching entry found
> May 26 16:34:25 auto-hv-02-guest08.testrelm.test krb5kdc[21762](info):
> preauth (pkinit) verify failure: Certificate mismatch
> 
>

Comment 25 Sumit Bose 2017-06-01 15:25:38 UTC
The server-side issue is tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1457942.

Comment 26 Scott Poore 2017-06-01 21:17:10 UTC
Moving back to Verified and will handle the server side issue in bug #1457942

Thanks,
Scott

Comment 27 errata-xmlrpc 2017-08-01 09:00:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294


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