With mounting issues in the the recent Fedoras (33 & 34), I tried several alternative desktop and window managers and found that with the latest version a number of them do no longer show/list the cached SSSD user names. Since all of these attempts are clean client installs (using the server ISO and then installing Cinnamon, GNOME, i3 or KDE), I wonder what has changed and/or what needs to be edited in order to get cached SSSD users resolved and listed on the DM’s login screen.
Just to be clear:
I can log in using an SSSD-based user, by choosing the “Not listed?” option in GDM, the “Other…” option in KDE (using “sddm”) or using the “manual login” after setting greeter-show-manual-login to “true”.
However, that means to type in both, the user AND password, every single time.
I would rather like to select the user (after having logged on once) and then simply type in the password (like before).
Using this server install plus GUI uplift, do I miss a package, which used to be installed, but is no longer installed? Did a related config file change?
Thanks! Though before writing I tried getent passwd <my_user> and it returns my user. However, running getent passwd (to get the entire list) does not list my user among the ones displayed, but this may as well be expected behavior.
Trying busctl get-property org.freedesktop.Accounts /org/freedesktop/Accounts/User<UID> org.freedesktop.Accounts.User SystemAccount returns “b false”, which I translate to “boolean false” and is the expected result for my user.
Concerning the “DM-related issue”, I would tend to agree if a single DM would start doing this, but not all I tried. For that I must assume an issue further down the rabbit hole.
Apart from the above, I also tried authselect select sssd just to make sure that the settings are correct. Furthermore I went through “/etc/nsswitch.conf” manually to verify that all settings appear to be proper. No changes had been applied during that step as all appeared to be correct.
In order to continue, I would need to know the answers on the following questions:
How does the DM query SSSD-based users?
Which files are involved (so I can verify their contents)?
Just to make it extra clear: All this worked pre-Fedora 34 without having to touch any of the above. If I am not mistaken, this even worked on Fedora 34 in the beginning, but stopped working after I re-installed the machine the other day (mid-September 2021).
Joining the domain (through Cockpit) was all that was needed and all started to work thereafter. So, essentially, I am trying to track down what changed since.
Check if the problem persists when switching SELinux to permissive mode.
I think it’s best to refer to the source code for troubleshooting a particular DM.
SELinux is set to permissive as part of a script I run following the installation of the ISO. Using scripts for installations is the best way to see when something changed as theoretically the installation shall be the same every time.
Considering the suggestion about the source code: It would be a great step… if I were a programmer and understood what is going on when reading it.
Also again: While it cannot be ruled out to be a DM issue, seeing that basically all others normally reading out and showing the cached users no longer do it as well, I tend to think that the issue is further down rather than at the surface.
In my case root reason was absence of default shell for SSSD (actually AD) users. Seems to me that AccountService uses emptiness of this field as a criteria of system account. After adding “override_shell=/bin/bash” to domain section of sssd.conf and restarting sssd.service all freshly logging AD users appeared to become non-system and were happily shown in the greeter thereafter.
I guess, I should have marked this topic as “solved” some time ago. In the meantime I unfortunately do not know if there was an update which fixed it (at least for LightDM, which I use) or something else. Using Fedora 36 in the meantime. So, the issue is outdated.
@contras, setting “override_shell” within “sssd.conf” may have adverse effects for administration as you shift the focus from centrally managed (the very reason a directory exists) to decentralized management. It may be worth setting the appropriate AD property and propagate it to LDAP, so SSSD can pick it up.
From the man page:
override_shell (string)
Override the login shell for all users. This option supersedes any other shell options if it takes effect and can be set either in the
[nss] section or per-domain.
Default: not set (SSSD will use the value retrieved from LDAP)
Anyway: While this very post did not lead to solve the issue, I will use it to mark it as solved. Thanks everyone for their inputs!