Created attachment 1689994 [details] journalctl -u gdm Description of problem: Attempting to log in to a FreeIPA account on Fedora 32, regardless of fresh install or upgrade, results in GDM showing "last login" time, as if login was successful, then fading to a gray screen, before returning to the login screen. Note that console logins to FreeIPA accounts are not effected. Version-Release number of selected component (if applicable): freeipa-client 4.8.6-1 gdm-3.36.2-2 How reproducible: Every time Steps to Reproduce: 1. Install Fedora 32 2. Select Enterprise Login and register with FreeIPA 3. Attempt to log in Actual results: GDM shows "last login" time, fades to a gray screen, and returns to the login screen Expected results: GDM shows "last login" time, fades to a gray screen, and enters a user session Additional info: I've tested with an allow_all HBAC rule to rule that out. I've attached the output of `journalctl -u gdm` as gdm.log. That log shows both GNOME and GNOME on Xorg login attempts.
I forgot to mention that I tried turning off SELinux as mentioned in bug 1814749, but this had no effect.
I'd suggest turning up the sssd log level, https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
Created attachment 1690035 [details] sssd.log (debug_level=6)
Created attachment 1690036 [details] sssd_pam.log (debug_level=6)
Created attachment 1690037 [details] sssd_nss.log (debug_level=6) I've added sssd logs with debug-level 6 to the attachments.
Re-assigning to sssd team to review the logs.
The key point, I think is here: 0. User is actually a user from Active Directory, in fully qualified form, user@domain. In SSSD logs we can see that the PAM session opening uses FQDN logon name: (Tue May 19 18:32:42 2020) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is <user>@<domain> (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): domain: <domain> (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): user: <user>@<domain> (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): service: gdm-password (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/tty2 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 3288 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): logon name: <user>@<domain> (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_print_data] (0x0100): flags: 0 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_dp_send_req_done] (0x0200): received: [0 (Success)][<domain>] (Tue May 19 18:32:42 2020) [sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal. (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_reply] (0x0200): blen: 27 (Tue May 19 18:32:42 2020) [sssd[pam]] [pam_reply] (0x0200): Returning [0]: Success to the client 1. pam_systemd complaints that it was unable to get a user record (EINVAL) May 18 18:50:38 f32test.central.xn gdm-password][1784]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 uid=0 tty=/dev/tty1 ruser= rhost= user=<user> May 18 18:50:38 f32test.central.xn gdm-password][1784]: gkr-pam: unable to locate daemon control file May 18 18:50:38 f32test.central.xn gdm-password][1784]: gkr-pam: stashed password to try later in open session May 18 18:50:38 f32test.central.xn gdm-password][1784]: pam_systemd(gdm-password:session): Failed to get user record: Invalid argument May 18 18:50:38 f32test.central.xn gdm-password][1784]: pam_unix(gdm-password:session): session opened for user <user> by (uid=0) May 18 18:50:38 f32test.central.xn gdm-password][1784]: gkr-pam: unable to locate daemon control file May 18 18:50:38 f32test.central.xn gdm-password][1784]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring May 18 18:50:41 f32test.central.xn /usr/libexec/gdm-wayland-session[1801]: dbus-daemon[1801]: [session uid=1260800001 pid=1801] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=1260800001 pid=1799 comm="/usr/libexec/gdm-wayland-session /usr/bin/gnome-se" label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") May 18 18:50:41 f32test.central.xn /usr/libexec/gdm-wayland-session[1801]: dbus-daemon[1801]: [session uid=1260800001 pid=1801] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 May 18 18:50:41 f32test.central.xn /usr/libexec/gdm-wayland-session[1799]: Unable to register display with display manager The message comes from /* Request the record ourselves */ r = userdb_by_name(username, 0, &ur); if (r < 0) { pam_syslog(handle, LOG_ERR, "Failed to get user record: %s", strerror_safe(r)); return PAM_USER_UNKNOWN; } In systemd v245 branch the userdb_by_name does if (!valid_user_group_name_compat(name)) return -EINVAL; This function call expands to: static inline bool valid_user_group_name_compat(const char *u) { return valid_user_group_name_full(u, false); } The code in valid_user_group_name_full() does not allow anything but [a-zA-Z0-9] and '_'/'-'. It particular, it does not allow '@'. There is a fix in systemd done in April: https://github.com/systemd/systemd/issues/15149 that removes systemd limitations which are unnecessary too tight for any environment where Active Directory is in use together with Linux systems. However, there is no systemd release with that fix. 2. Note that while pam_systemd failed session opening due to this check, the session still got opened by pam_unix (user exists in the system according to getpwnam(), after all). However, the session is not setup properly because pam_systemd didn't do its job of session setup and user session isn't configured, so systemd1 service couldn't use it, thus failing and failing wayland session. I think this has to be looked at and acted upon by the systemd maintainers.
Based on what I've read, I tried installing systemd-245.5-2.fc33.x86_64 from Rawhide in my test vm, and that did allow me to log in. Let me know if I can provide any more logs to help the systemd maintainers.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.