Bug 1389796
Summary: | Smartcard authentication with UPN as logon name might fail | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Sumit Bose <sbose> |
Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
Status: | CLOSED ERRATA | QA Contact: | Scott Poore <spoore> |
Severity: | unspecified | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
Priority: | unspecified | ||
Version: | 7.3 | CC: | grajaiya, jhrozek, lslebodn, mkosek, mmuehlfe, mzidek, pbrezina, rpattath, sbose, sgoveas, spoore |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sumit Bose
2016-10-28 16:39:57 UTC
*** Bug 1377322 has been marked as a duplicate of this bug. *** Upstream ticket: https://fedorahosted.org/sssd/ticket/3240 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 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 scuser107:*:576400135:576400135:f l:/home/scuser107:/bin/sh The part that failed: Changed pricipal alias to alias_scuser107 [root@dhcp129-184 ~]# ipa user-mod scuser107 --principal alias_scuser107 ------------------------- Modified user "scuser107" ------------------------- User login: scuser107 First name: f Last name: l Home directory: /home/scuser107 Login shell: /bin/sh Principal name: scuser107 Principal alias: alias_scuser107 Email address: scuser107 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 Did not ask for pin... Additional patches: * 29d063505c07127f7747405b1a61d8f782673645 * ec9ac22d699a17d590b1d4ba9ba3750eb719f340 * 870b58a6cc6b5cf92a6503c1578e5c21617c8d40 This is still failing. [root@dhcp129-184 sssd]# ipa user-mod scuser107 --principal alias_scuser107 ------------------------- Modified user "scuser107" ------------------------- User login: scuser107 First name: f Last name: l Home directory: /home/scuser107 Login shell: /bin/sh Principal name: scuser107 Principal alias: alias_scuser107 Email address: scuser107 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 (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 (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] and returned UPN [scuser107] 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] 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. 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] and returned UPN [scuser107] 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) Upstream ticket: https://pagure.io/SSSD/sssd/issue/3408 master: * ca95807a9060e454ee68f6f30558d6f7ee968c39 FYI, I didn't seem to have any more luck with the sssd option: krb5_use_enterprise_principal = True Still failed with alias_scuser107 anything else I could try? or just wait for the SSSD update? (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 > > 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.. 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 by (uid=0) May 26 14:21:19 dhcp129-184 gdm-password]: pam_unix(gdm-password:session): session opened for user alias_scuser107 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 Principal alias: alias_scuser107 Email address: scuser107 UID: 576400135 GID: 576400135 Certificate: MII.... Account disabled: False Password: True Member of groups: ipausers Roles: hostadmin Kerberos keys available: True Created attachment 1282762 [details]
sssd logs from 3 successful logins from upn test
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] 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 > (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] 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 > > The server-side issue is tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1457942. Moving back to Verified and will handle the server side issue in bug #1457942 Thanks, Scott 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 |