Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I cannot log in to my FreeIPA account via GDM or console using sssd. This started following in an upgrade to Fedora 44. Version-Release number of selected component (if applicable): sssd-common-2.13.0-1.fc44.x86_64 How reproducible: Consistently, after reboot. Steps to Reproduce: 1. Reboot. 2. Attempt to log in with password. Actual results: Access denied. Expected results: Access granted. Additional info: Normal service can be restored by clearing the sss cache, then restarting sssd.
# journalctl -b -u sssd May 03 21:09:12 flexo.cb.ettle.org.uk systemd[1]: Starting sssd.service - System Security Services Dae> May 03 21:09:12 flexo.cb.ettle.org.uk sssd[1783]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_be[1869]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_autofs[1970]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_sudo[1968]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_ssh[1967]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_pam[1966]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_pac[1971]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_nss[1965]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk systemd[1]: Started sssd.service - System Security Services Daem> May 03 21:09:30 flexo.cb.ettle.org.uk krb5_child[4526]: Permission denied May 03 21:09:12 flexo.cb.ettle.org.uk systemd[1]: Starting sssd.service - System Security Services Dae> May 03 21:09:12 flexo.cb.ettle.org.uk sssd[1783]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_be[1869]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_autofs[1970]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_sudo[1968]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_ssh[1967]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_pam[1966]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_pac[1971]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk sssd_nss[1965]: Starting up May 03 21:09:12 flexo.cb.ettle.org.uk systemd[1]: Started sssd.service - System Security Services Daem> May 03 21:09:30 flexo.cb.ettle.org.uk krb5_child[4526]: Permission denied May 03 21:09:36 flexo.cb.ettle.org.uk krb5_child[4909]: Permission denied May 03 21:09:46 flexo.cb.ettle.org.uk krb5_child[4920]: Permission denied May 03 21:09:56 flexo.cb.ettle.org.uk krb5_child[5158]: Permission denied Here's where I restarted sssd: May 03 21:10:26 flexo.cb.ettle.org.uk systemd[1]: Stopping sssd.service - System Security Services Dae> May 03 21:10:26 flexo.cb.ettle.org.uk sssd_pam[1966]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_ssh[1967]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_pac[1971]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_sudo[1968]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_autofs[1970]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_be[1869]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk sssd_nss[1965]: Shutting down (status = 0) May 03 21:10:26 flexo.cb.ettle.org.uk systemd[1]: sssd.service: Deactivated successfully. May 03 21:10:26 flexo.cb.ettle.org.uk systemd[1]: Stopped sssd.service - System Security Services Daem> May 03 21:10:26 flexo.cb.ettle.org.uk systemd[1]: sssd.service: Consumed 1.192s CPU time over 1min 14.> May 03 21:10:38 flexo.cb.ettle.org.uk systemd[1]: Starting sssd.service - System Security Services Dae> May 03 21:10:38 flexo.cb.ettle.org.uk sssd[5484]: Starting up May 03 21:10:38 flexo.cb.ettle.org.uk sssd_be[5485]: Starting up May 03 21:10:38 flexo.cb.ettle.org.uk sssd_pac[5492]: Starting up May 03 21:10:38 flexo.cb.ettle.org.uk sssd_pam[5488]: Starting up May 03 21:10:38 flexo.cb.ettle.org.uk sssd_ssh[5489]: Starting up May 03 21:10:38 flexo.cb.ettle.org.uk sssd_autofs[5491]: Starting up
(In reply to James from comment #1) > May 03 21:09:30 flexo.cb.ettle.org.uk krb5_child[4526]: Permission denied Could you please attach `/var/log/sssd/krb5_child.log`?
Created attachment 2139368 [details] krb5_child.log
(In reply to James from comment #0) > This started following in an upgrade to Fedora 44. What version did you upgrade from? > [krb5_child[4496]] [validate_tgt] (0x0020): [RID#646] error reading keytab [/etc/krb5.keytab], not verifying TGT. > [krb5_child[4496]] [debug_and_log] (0x0020): [RID#646] 2587: [13][Permission denied] This is likely due to a bug in the logic that drops `cap_dac_read_search` soon after process started, but: - IIUC, it should have been seen with sssd-2.12 as well - maybe it's not the reason of an actual fail: ``` [krb5_child[4683]] [sss_krb5_auth_methods_answer] (0x4000): [RID#633] Got question [password]. [krb5_child[4683]] [debug_and_log] (0x0020): [RID#633] 2540: [-1765328360][Preauthentication failed] ``` Could you please make a quick check if bug is still observed with `krb5_validate = false` in the domain section of 'sssd.conf'?
(In reply to Alexey Tikhonov from comment #4) > > > [krb5_child[4496]] [validate_tgt] (0x0020): [RID#646] error reading keytab [/etc/krb5.keytab], not verifying TGT. > > [krb5_child[4496]] [debug_and_log] (0x0020): [RID#646] 2587: [13][Permission denied] > > This is likely due to a bug in the logic that drops `cap_dac_read_search` > soon after process started ``` * (2026-04-30 23:06:48): [krb5_child[4517]] [unpack_buffer] (0x0100): [RID#632] cmd [249 (pre-auth)] uid [1367600004] gid [1367600004] validate [true] enterprise principal [false] offline [true] UPN [james.ORG.UK] * (2026-04-30 23:07:02): [krb5_child[4517]] [unpack_buffer] (0x0100): [RID#632] cmd [241 (auth)] uid [1367600004] gid [1367600004] validate [true] enterprise principal [false] offline [false] UPN [james.ORG.UK] ``` Since `krb5_child[4517]` is started with `offline [true]`, `copy_keytab_into_memory()` isn't executed: https://github.com/SSSD/sssd/blob/e5b65979f11e10ffafa398fe38e4d1cf63cd99bf/src/providers/krb5/krb5_child.c#L4224 But 'auth' in the same session is called with `offline [false]` (and `validate [true]`) -- TGT validation fails because keytab isn't available. Perhaps it is a race condition: auth attempt is started before SSSD goes online and completes when it is already discovered & connected to IPA server... If that's the case, then cache removal is a red herring -- simply delaying an auth attempt after reboot should hide an issue as well.
(In reply to Alexey Tikhonov from comment #4) > (In reply to James from comment #0) > > This started following in an upgrade to Fedora 44. > > What version did you upgrade from? > > > [krb5_child[4496]] [validate_tgt] (0x0020): [RID#646] error reading keytab [/etc/krb5.keytab], not verifying TGT. > > [krb5_child[4496]] [debug_and_log] (0x0020): [RID#646] 2587: [13][Permission denied] > > This is likely due to a bug in the logic that drops `cap_dac_read_search` > soon after process started, but: > - IIUC, it should have been seen with sssd-2.12 as well > - maybe it's not the reason of an actual fail: > ``` > [krb5_child[4683]] [sss_krb5_auth_methods_answer] (0x4000): [RID#633] Got > question [password]. > [krb5_child[4683]] [debug_and_log] (0x0020): [RID#633] 2540: > [-1765328360][Preauthentication failed] > ``` > > Could you please make a quick check if bug is still observed with > `krb5_validate = false` in the domain section of 'sssd.conf'? The most recent upgrade history was: sssd-krb5-0:2.12.0-1.fc43.x86_64 -> sssd-krb5-0:2.12.0-4.fc44.x86_64 (f43 -> 44 upgrade), then most recently to sssd-krb5-common-0:2.13.0-1.fc44.x86_64 -- however I don't know which particular step was the cause. I'll try downgrading to 2.12 and see if that makes it work again. The bug goes away with krb5_valid = false.
Things are OK with sssd-krb5-0:2.12.0-4.fc44.x86_64.
(In reply to James from comment #7) > Things are OK with sssd-krb5-0:2.12.0-4.fc44.x86_64. Hm... this doesn't match my understanding of a bug and this bothers me... Thanks for help so far. Could you may be conduct two other test (with default `krb5_validate = true`): (1) let SSSD to go online after reboot (perhaps just waiting few minutes after reboot should be enough) and check the auth (2) check if copr build https://dashboard.packit.dev/jobs/copr/3537954 resolves an issue This is a build of fix candidate - https://github.com/SSSD/sssd/pull/8671
I think you're right about the cache purge being a red herring, I was able to get it working by just restarting sssd (on a fresh F44 install). (1) Waiting a few minutes also works. (2) Looks like this has fixed it (tested across 3 reboots).
Upstream PR: https://github.com/SSSD/sssd/pull/8671
Fixed upstream as of https://github.com/SSSD/sssd/commit/b070171e8371ce9be20c0554617b35d13a2ef17c
sssd-2-13 backport: https://github.com/SSSD/sssd/pull/8687
(In reply to Alexey Tikhonov from comment #12) > sssd-2-13 backport: https://github.com/SSSD/sssd/pull/8687 https://github.com/SSSD/sssd/commit/6e2b87aa43e15f18c10d859bbed59dab314ffed1
Is there a target build number for this so I can confirm the fix?
(In reply to James from comment #14) > Is there a target build number for this so I can confirm the fix? No Fedora update yet.
It would be really appreciated to get an update out. this effects multiple systems for me none of which I can log into without restarting sssd first
Will be solved via rebases: - https://src.fedoraproject.org/rpms/sssd/pull-request/88 - https://src.fedoraproject.org/rpms/sssd/pull-request/87
FEDORA-2026-851bc3ae6a (sssd-2.13.1-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-851bc3ae6a
FEDORA-2026-851bc3ae6a has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-851bc3ae6a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-851bc3ae6a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-851bc3ae6a (sssd-2.13.1-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.