Can't get session id/info if user name was typed in wrong case

[lo1ol]

Environment:

OS: Ubuntu 24.04 + (service systemd-userdb is running)
SSSD: 2.9.4
Domains: tested on ad and freeipa

sssd config:

[sssd]
domains = adrtkn.test
config_file_version = 2
services = nss, pam
certificate_verification=soft_ocsp,soft_crl

[pam]
pam_cert_auth=True
pam_cert_db_path=/etc/rtlogon/ca.pem

[domain/adrtkn.test]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = ADRTKN.TEST
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = adrtkn.test
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
case_sensitive=Preserving
use_fully_qualified_names=True
cache_credentials=True
krb5_store_password_if_offline=True

I have a user [email protected]. If I try to login by user [email protected] -- everything is ok and if I try to get info about user session -- everything is works:

$ loginctl session-status
207 - [email protected] (1467800500)
  Since: Thu 2025-01-30 07:33:28 UTC; 27min ago
  State: active
 Leader: 225381 (login)
   Seat: seat0; vc5
    TTY: tty5
 Remote: no
Service: login
   Type: tty
  Class: user
   Idle: no
   Unit: session-207.scope
         ├─225381 /bin/login -p --
         ├─226046 -bash
         └─229841 loginctl session-status

But if I try to login by user [email protected] -- I still can authenticate successfully, but couldn't get session info:

$ loginctl session-status
Failed to get path for session 'auto': Caller does not belong to any known session and doesn't own any suitable session.

on some OSs it could be:

$ loginctl session-status
Could not get properties: Unknown object '/org/freedesktop/login1/session/auto'.

Also, the problem could be reproduced id set use_fully_qualified_names=False and try to auth with fully qualified name: [email protected]

I looked at log and found out that problem is caused by systemd-userdb:

pam_systemd(lightdm:session): Failed to get user record: No such process

So, pam_systemd is failed but, because it's marked as optional module -- this fail doesn't stop authentication.

If you stop the service systemd-userdb (before authentication), the command loginctl session-status starts to work

So, my questions

1. Why I could auth if type username in wrong case? I tried different values for case_sensitive option -- I still can auth. Also I found out that I couldn't case starts to matter is set use_fully_qualified_names=False and case_sensitive=True, but I can't set use_fully_qualified_names=False and case_sensitive=True (it doesn't work for AD) in my scenarios. It's a bug?
2. Why session section of pam_systemd and pam_sss marked as optional? I saw a lot of distros. they are marked as optional everywhere.
3. Is there workaround that we could implement in our pam module to stop authentication if name doesn't match a case expected case? I thinking about adding call of userdbctl user $USERNAME@DOMAIN_NAME, to check that user could be found by systemd-userdb

If conclude everything. I think that there are this bugs:

1. if use_fully_qualified_names=True set, than case_sensitive=True option is ignored
2. there is no opportunity to stop authentication for AD users with wrong username case. Even if use_fully_qualified_names=False option is set. It's consequence of the fact that we can't set case_sensitive=True for AD domains.
3. pam_systemd fails if username was provided with wrong case or with domain specified (if use_fully_qualified_names=False is set). It's looks like systemd-userdb problem, but I still want to inform you about it. Should I create a bug in systemd-userdb for it?

[sumit-bose]

Hi,

thank you for the report. I think this is something which can be handled by SSSD's PAM module. When starting the authentication and authorization process a login application like lightdm will provide the user name you entered at the related prompt. This name is send by SSSD's PAM module to the SSSD's processes and depending on the configured backend a given user can use more than one name to log in. This might be and email address a Kerberos principal or just the name in a different case. This is not only internal but SSSD's NSS handling does that same, i.e. an application can call getpwnam("username") or getpwnam("Username") and get the same result. Even the name in the result will be the same canonical name and not the one provided as input. It looks like userdb is more strict here and only allows a single name.

What pam_sss can do is to check if the current user name known to PAM is the same as the canonical name of the user after successful authentication and if not replace it with the canonical name so that other PAM modules can now directly use the canonical name. pam_sss is currently doing this only in cases where there is no user name at all known to PAM which might happen during Smartcard authentication.

bye,
Sumit

[lo1ol]

Thank you for your response and hint! So, I did this in my pam module:

auto pw = getpwnam(passed_username);
if (pw)
    pam_set_item(pam_handle, PAM_USER, &pw->pw_name);

and it fix the problem)

Will you do something like that in new version's of pam_unix?

[sumit-bose]

Hi,

it will be pam_sss instead of pam_unix and most probably the SSSD PAM responder will send back the canonical name with the indication that the authentication was successful. This will avoid the dependency to NSS.

bye,
Sumit