GNOME Bugzilla – Bug 736222
Cannot log into GNOME with FreeIPA account after successfully joining the domain (F21)
Last modified: 2021-06-09 16:12:39 UTC
To reproduce: * Use a system in a position to join a FreeIPA domain * Do a clean install of a current F21 Workstation, set system hostname correctly (say FreeIPA domain is example.com, set hostname to test.example.com during install) * Create a temporary local user (in anaconda or g-i-s, doesn't matter) * Log in as that user * Go to Control Center / Users * Add a user * Click Enterprise Login * Select the domain from the drop-down and enter a correct Username and Password for the domain * Enter admin credentials and click Enroll when prompted if necessary * Check /etc/sssd/sssd.conf , and you will note that it contains: use_fully_qualified_names = True * Try to login as 'user' (assuming 'user' is a valid user in the FreeIPA domain) * Now try to login as 'user@example.com' the effect of "use_fully_qualified_names = True" is that you cannot log into the machine with username 'user' (assuming 'user' is a valid username on the domain). You must login as 'user@example.com'. This is unexpected and confusing behaviour, users are likely to assume that the system is simply broken. Indeed, the entry that will be added to GDM for the username you entered in the control center will not use the 'user@domain.com' form, and fails if you try to use it. The option is documented by sssd as being intended for cases where the machine is joined to more than one domain, which seems unlikely to be the case the design should optimize for. However, realmd claims to set it to avoid conflicts with locally-defined users (see below). I believe this is caused by a default setting in realmd, because if you enrol the system using ipa-client-install directly, it doesn't happen, and realmd mentions it in 'man realmd.conf': fully-qualified-names This option is on by default. If turned off then realm user and group names are not qualified their name. This may cause them to conflict with local user and group names. its interaction with GNOME is obviously unfortunate, though.
hmm, now I look, it may be that the use of use_fully_qualified_names is 'as intended', as the account that shows up in GDM after joining the domain seems to use the fully-qualified form of the user name. The reason it doesn't actually work to login is something else, but I'm still narrowing down what.
After following the steps above to enrol the system and rebooting, when I try to log in as my 'adamw@domain.com' account I get: Sep 06 23:39:22 test.domain.com gdm-password][1981]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=adamw@domain.com Sep 06 23:39:22 test.domain.com gdm-password][1981]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=adamw@domain.com Sep 06 23:39:22 test.domain.com gdm-password][1981]: pam_sss(gdm-password:account): Access denied for user adamw@domain.com: 6 (Permission denied) If I just restart sssd.service, it still fails the same way. But very strangely, if I edit the file /etc/sssd/sssd.conf but *do not touch anything*, save it, then restart sssd.service , auth now succeeds: Sep 06 23:42:41 test.happyassassin.net gdm-password][2304]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=adamw@happyassassin.net Sep 06 23:42:42 test.happyassassin.net gdm-password][2304]: pam_sss(gdm-password:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=adamw@happyassassin.net Sep 06 23:42:42 test.happyassassin.net kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Sep 06 23:42:42 test.happyassassin.net systemd-logind[612]: New session 4 of user adamw@happyassassin.net. However, login still fails: it hits the "Oh no! Something has gone wrong." scren, with a "Choose password for new keyring" dialog overlaid on it. In the logs, 25 seconds after the "New session" message, an error appears: Sep 06 23:43:07 test.happyassassin.net gdm-password][2304]: pam_systemd(gdm-password:session): Failed to create session: Connection timed out the system continues to try and start the session, but doesn't manage it successfully. I'll attach the rest of the log.
Grr, forgot to sanitize the second section of logs :( Here comes spam! The domain doesn't *actually* change between the two sections of log, I was just hand-editing it to try and avoid exposing my address. Note that after I do the 'edit sssd.conf but don't restart it' trick, I can login at a console successfully using the fully-qualified form of the name.
Created attachment 285605 [details] full journalctl log extract from failed login attempt with successful authentication This contains the full log extract from the case where authentication succeeds, but the login fails (i.e. after I do the 'edit sssd.conf but don't change it, and restart sssd.service' trick).
the "Access denied for user" bug appears to be slightly slippery to reproduce (sometimes I hit it, sometimes I don't) but the failed-login-after-successful-auth case seems to be 100% reproducible.
It seems this is a Fedora bug, and perhaps interaction between sssd, selinux, and oddjob-mkhomedir has gone awry. Have you opened a bugzilla bug there? Should we try and diagnose this at that bug?
Not yet, but I don't mind doing that if it seems advised. I do recall seeing an SELinux denial as a tooltip in g-i-s(!) though I could find no trace of it later, and I retried the enrolment process after running 'setenforce Permissive' as root with no result. I'll look into it more tomorrow.
oh, I forgot that https://bugzilla.redhat.com/show_bug.cgi?id=975008 constitutes a downstream bug, though I did not create it.
(In reply to comment #8) > oh, I forgot that https://bugzilla.redhat.com/show_bug.cgi?id=975008 > constitutes a downstream bug, though I did not create it. That seems like a different issue (to do with polkit and gnome-initial-setup).
god, you're right, it's really time I went to bed. sorry, confusing two issues. so no, I don't have a downstream report for this one (it may be that someone else has filed it, but I haven't).
NEEDINFO on root causing the actual problem. Seems to me that the realmd code, or the SSSD configuration could be at fault here, and I don't see anything pointing towards a control-center bug.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.