Prior to f32, my sssd/krb5 setup allowed login and ensured a current krb5 ticket at login. With f32 it allows login but doesn't obtain or renew a ticket. Manual kinit works fine after login. The only error I see in the logs at the moment at login time is: [dp_target_run_constructor] (0x0010): Target [resolver] constructor failed [95]: Operation not supported
Hi, this sounds like SSSD is offline. Can you send the output of sssctl domain-status domain.name.from.sssd.conf bye, Sumit
sudo sssctl domain-status BAMBOO Online status: Online Active servers: KERBEROS: not connected Discovered KERBEROS servers: - bamboo I can confirm that the kerberos server is online and working.
Hi, is this a setup where Kerberos authentication is configured for local users? If yes, does the local user still has a password in /etc/shadow as well? Can you send the PAM related messages from /var/log/secure or the journal for an authentication attempt? bye, Sumit
Correct. And it does still have a local password. Jun 24 08:08:19 gwythsefyll audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jun 24 08:08:21 gwythsefyll gdm-password][1925]: gkr-pam: unable to locate daemon control file Jun 24 08:08:21 gwythsefyll audit[1925]: USER_AUTH pid=1925 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_localuser acct="gwyn" exe="/usr/libexec/gdm-session-worker" hostname=gwythsefyll addr=? terminal=/dev/tty1 res=success' Jun 24 08:08:21 gwythsefyll gdm-password][1925]: gkr-pam: stashed password to try later in open session
Hi, thanks for the logs. Since there is no message from pam_unix I think this is a known regression caused by the fix for https://pagure.io/SSSD/sssd/issue/4174. The regression is currently discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1815584 (sorry, this ticket is mostly private). We can use this ticket here to track the fix for Fedora. Unfortunately there is no easy work-around. One would be to change one of the passwords (I assume /etc/shadow and Kerberos password are currently the same) then pam_unix should fail if you use the Kerberos password and now SSSD has a chance to do Kerberos authentication. But this of course would only work if this affects just a few users. bye, Sumit
They were the same. I changed the local password. I've not yet tested GDM, but ssh logins work with either password.
Hi, do you get a Kerberos ticket when using the Kerberos password? bye, Sumit
Yes, and I do not when using the local password.
(In reply to Gwyn Ciesla from comment #8) > Yes, and I do not when using the local password. Hi, ok, so this works as expected. Jfyi, https://github.com/SSSD/sssd/pull/5221 should fix the issue. bye, Sumit
I built a local set of sssd packages with that patch, and it does indeed work. Thank you!
Pushed PR: https://github.com/SSSD/sssd/pull/5221 * `master` * ffb9ad1331ac5f5d9bf237666aff19f1def77871 - proxy: use 'x' as default pwfield only for sssd-shadowutils target
FEDORA-2020-63a418c824 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-63a418c824
FEDORA-2020-63a418c824 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-63a418c824` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-63a418c824 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-63a418c824 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.