Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdm smartcard login fails with "system error 4" in case of multiple identities #7109

Closed
thecommandingheights opened this issue Dec 22, 2023 · 9 comments
Labels
Closed: Fixed Issue was closed as fixed.

Comments

@thecommandingheights
Copy link

Hi,
I seem to have some issue when logging on using a smartcard with multiple identities. Surprising, because this works just fine:

root@fedora:~# sssctl user-checks -s gdm-smartcard "testuser" -a auth
user: testuser
action: auth
service: gdm-smartcard

SSSD nss user lookup result:
 - user name: testuser
 - user id: 1001
 - group id: 1001
 - gecos: 
 - home directory: /home/testuser
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: testuser
 - uidNumber: 1001
 - gidNumber: 1001
 - gecos: not set
 - homeDirectory: /home/testuser
 - loginShell: /bin/bash

testing pam_authenticate

Please select a certificate by typing the corresponding number

[1]:
testuser_crt
CN=testuser,OU=Example Test,O=Example

[2]:
testuser2_crt
CN=testuser,OU=Example Test,O=Example
2
Certificate ‘02’ selected
PIN for MyEID (testuser): 
pam_authenticate for user [testuser]: Success

PAM Environment:
 - PKCS11_LOGIN_TOKEN_NAME=MyEID (testuser)

I can also logon when connected to a text tty. In such case I get prompted to select a certificate, type the PIN and the login succeeds.

In GDM however I get prompted to select one of the two certificates, I type the PIN and then nothing happens and I just get presented the two certificates again. In the logs I see:

Dec 22 12:32:20 fedora.home gdm-smartcard][75787]: pam_sss(gdm-smartcard:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=testuser@localdomain
Dec 22 12:32:20 fedora.home gdm-smartcard][75787]: pam_sss(gdm-smartcard:auth): received for user testuser@localdomain: 4 (System error)

I attach some logs. Any idea what might be happening here?

Thanks

sssd_pam.log
p11_child.log

@thecommandingheights thecommandingheights changed the title gdm smartcard login fails with "system error 4" in case of multiple identies gdm smartcard login fails with "system error 4" in case of multiple identities Dec 22, 2023
@alexey-tikhonov
Copy link
Member

This

(12:32:11): [pam_forwarder_lookup_by_cert_done] (0x4000): [CID#3] Found [2] certificates and [2] related users.
(12:32:11): [add_pam_cert_response] (0x0020): [CID#3] Unable to parse name '' [1432158288]: The internal name format cannot be parsed, using full name.
(12:32:11): [add_pam_cert_response] (0x0020): [CID#3] Unable to parse name '' [1432158288]: The internal name format cannot be parsed, using full name.

looks weird.

(12:32:20): [sss_dp_get_account_send] (0x0400): [CID#3] Creating request for [localDomain][0x3][BE_REQ_INITGROUPS][name=testuser@localdomain:-]
...
(12:32:20): [cache_req_done] (0x0400): [CID#3] CR #6: Finished: Success
(12:32:20): [pd_set_primary_name] (0x0400): [CID#3] User's primary name is testuser@localdomain
(12:32:20): [pam_initgr_check_timeout] (0x4000): [CID#3] User [testuser@localdomain] not found in PAM cache.
(12:32:20): [pam_initgr_cache_set] (0x2000): [CID#3] [testuser@localdomain] added to PAM initgroup cache
(12:32:20): [pam_dom_forwarder] (0x3f7c0): [CID#3] Local auth only set, skipping online auth
(12:32:20): [pam_reply] (0x4000): [CID#3] pam_reply initially called with result [4]: System error. this result might be changed during processing
(12:32:20): [pam_reply] (0x0400): [CID#3] Local auth policy allowed: smartcard [True], passkey [True]
(12:32:20): [filter_responses_env] (0x4000): [CID#3] Found PAM ENV filter for variable [KRB5CCNAME] and service [sudo].
(12:32:20): [filter_responses_env] (0x4000): [CID#3] Found PAM ENV filter for variable [KRB5CCNAME] and service [sudo-i].
(12:32:20): [pam_reply] (0x0200): [CID#3] blen: 234
(12:32:20): [pam_reply] (0x0200): [CID#3] Returning [4]: System error to the client

At the moment I don't understand the reason for '[4]: System error to the client'...

@alexey-tikhonov
Copy link
Member

Flow hits this code:

DEBUG(SSSDBG_IMPORTANT_INFO, "Local auth only set, skipping online auth\n");

It requires preq->cert_auth_local to be set to 'true' to set pam_status = PAM_SUCCESS for SSS_PAM_AUTHENTICATE.

But it looks like it's only set here:

preq->cert_auth_local = true;

-- but there is no "Backend cannot handle Smartcard authentication" in the log.

@thecommandingheights, can you please attach 'sssd.conf'?

@sumit-bose, where 'cert_auth_local' should be set in this case?

@thecommandingheights
Copy link
Author

Thanks for feedback.

Attached the sssd.conf. It's just a quick test setup I made to simulate the issue.

sssd.conf.txt

@alexey-tikhonov
Copy link
Member

Hi @thecommandingheights,

what sssd version is this?

@thecommandingheights
Copy link
Author

Hello @alexey-tikhonov

I'm currently testing it on Fedora 39 with sssd 2.9.3 where it fails. It works well on RHEL 9.3 with sssd 2.9.1.

@sumit-bose
Copy link
Contributor

Hi.

you've mentioned that Smartcard authentication is working as expect when using y tty for login. Can you attach the related logs as well?

bye,
Sumit

@alexey-tikhonov
Copy link
Member

(just tagging @thecommandingheights)

sumit-bose added a commit to sumit-bose/sssd that referenced this issue Jan 18, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: SSSD#7109
@sumit-bose
Copy link
Contributor

Hi,

thanks for making us aware of the issue. I was able to reproduce it and prepared a fix.

The scenario was working if the deprecated/removed files provider was used but does not work with the new proxy provider based solution if local_auth_policy = only.

A workaround might be to replace local_auth_policy = enable:smartcard but now you have to add a proper auth_provider setting to the proxy domain as well. In my tests I used e,g. auth_provider = ldap without any additional settings. But I would expect that a proxy configuration which will always return an error would work as well.

bye,
Sumit

alexey-tikhonov pushed a commit that referenced this issue Jan 19, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: #7109

Reviewed-by: Justin Stephenson <[email protected]>
Reviewed-by: Scott Poore <[email protected]>
(cherry picked from commit 44ec3e4)
@alexey-tikhonov
Copy link
Member

Pushed PR: #7139

  • master
    • 44ec3e4 - pam: fix SC auth with multiple certs and missing login name
  • sssd-2-9
    • 50077c3 - pam: fix SC auth with multiple certs and missing login name

@alexey-tikhonov alexey-tikhonov added the Closed: Fixed Issue was closed as fixed. label Jan 19, 2024
alexey-tikhonov pushed a commit to alexey-tikhonov/sssd that referenced this issue Nov 13, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: SSSD#7109

Reviewed-by: Justin Stephenson <[email protected]>
Reviewed-by: Scott Poore <[email protected]>
(cherry picked from commit 44ec3e4)
(cherry picked from commit 50077c3)
alexey-tikhonov pushed a commit to alexey-tikhonov/sssd that referenced this issue Nov 15, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: SSSD#7109

Reviewed-by: Justin Stephenson <[email protected]>
Reviewed-by: Scott Poore <[email protected]>
(cherry picked from commit 44ec3e4)
(cherry picked from commit 50077c3)
alexey-tikhonov pushed a commit to alexey-tikhonov/sssd that referenced this issue Nov 15, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: SSSD#7109

Reviewed-by: Justin Stephenson <[email protected]>
Reviewed-by: Scott Poore <[email protected]>
(cherry picked from commit 44ec3e4)
(cherry picked from commit 50077c3)
alexey-tikhonov pushed a commit to alexey-tikhonov/sssd that referenced this issue Nov 15, 2024
While introducing the local_auth_policy option a quite specific use-case
was not covered correctly. If there are multiple matching certificates
on the Smartcard, 'local_auth_policy = only' is set and GDM's Smartcard
mode was used for login, i.e. there is no user name given and the user
has to be derived from the certificate used for login, authentication
failed. The main reason for the failure is that in this case the
Smartcard interaction and the user mapping has to be done first to
determine the user before local_auth_policy is evaluated. As a result
when checking if the authentication can be finished the request was in
an unexpected state because the indicator for local Smartcard
authentication was not enabled.

Resolves: SSSD#7109

Reviewed-by: Justin Stephenson <[email protected]>
Reviewed-by: Scott Poore <[email protected]>
(cherry picked from commit 44ec3e4)
(cherry picked from commit 50077c3)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed: Fixed Issue was closed as fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants