After I log in offline with a cached password hash, sssd stays offline forever because my account requires MFA

[yrro]

I've got a FreeIPA account that is configured to require MFA (in FreeIPA terms, I can use otp or pkinit but not password).

When I suspend my laptop, and then wake it back up again, it's initially disconnected from Wi-Fi. At this point, I'm able to log in with my password alone (as expected, because offline authentication is enabled).

The problem is that once I do this, SSSD stays offline forever; after I reconnect to the network, SSSD will not go online until I restart it manually.

According to the logs, SSSD is trying to go online. As part of that process it's trying to authenticate with my password (because krb5_store_password_if_offline is true). But my FreeIPA KDCs are not allowing that, because my account is set to require otp.

SSSD seems to treat that authentication failure as a fatal error, and since authentication fails against all my KDCs, SSSD sees no online servers and so stays offline.

The behaviour I'd expect is for SSSD to recognize the authentication failure as non-fatal, and stay online, even though it can't use my stored password to get a new TGT from any KDC.

There are two workarounds:

1. Wait for the laptop to re-connect to the Wi-Fi before unlocking my session, so that SSSD can do an online authentication with both factors, as required by the KDCs
2. Disable the krb5_store_password_if_offline option on the laptop (I only noticed this option was enabled while writing up this issue, so I'm testing this right now)

Here are some log messages showing what's going on; these are logged after I run systemctl kill -s SIGUSR2 --kill-whom=main sssd which tells SSSD to try going online immediately.

1.txt
2.txt

My summary/interpretation of the logs follows. After I tell SSSD to go line, krb5_child logs:

[tokeninfo_matches] (0x0020): [RID#1781] Unsupported authtok type 1`
[get_and_save_tgt] (0x0020): [RID#1781] 2322: [11][Resource temporarily unavailable]
[map_krb5_error] (0x0040): [RID#1781] 2447: [-1765328228][Cannot contact any KDC for requested realm]

1 is SSS_AUTHTOK_TYPE_PASSWORD; I think this is being logged because no KDC will allow password authentication. After this, the backend logs:

[be[example.com]] [fo_resolve_service_done] (0x0020): [RID#1781] Failed to resolve server 'ipa6.example.com': DNS server returned answer with no data
[be[example.com]] [fo_resolve_service_send] (0x0020): [RID#1781] No available servers for service 'IPA'
[be[example.com]] [authenticate_user_done] (0x0020): [RID#1781] Failed to authenticate user [yrro@example.com].

While this looks like a DNS problem, it isn't. DNS is working fine. I believe the backend is running krb5_child for the IPv4 address for my servers, and when that fails it tries to resolve the IPv6 address, which is not present. It then marks the server as offline, and bubbles this final DNS failure up into the main backend log. The full backtraces in the linked logs above should make this clear.

I'm using sssd-ipa-2.11.1-1.fc42.x86_64. I can provide log at a higher debug level if you need them.

[sumit-bose]

Hi,

thank you for your report. I wonder if you can test a build from https://copr.fedorainfracloud.org/coprs/packit/SSSD-sssd-8176/ which contains the patches from #8176 which should fix the issue.

bye,
Sumit

[yrro]

Thank for this. I will try to test it this weekend.

[yrro]

It works! Thank you!

Test method:

Disable wifi, force an authentication attempt (sudo -k && sudo -i). sssd goes offline.

While in this state, I can see sssd trying to go online every so often & failing.

Re-enable wi-fi and sssd logs:

(2025-11-19 19:27:27): [be[example.com]] [krb5_auth_done] (0x3f7c0): [RID#282] The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
(2025-11-19 19:27:27): [be[example.com]] [authenticate_user_done] (0x0020): [RID#282] Failed to authenticate user [yrro@example.com].

... as expected, because the KDC is refusing to allow non-MFA authentication.

However, according to sssctl domain-status, the domain is now online! Hurrah!

[sumit-bose]

Hi,

thank you for the feedback, I rebased and un-drafted #8176 to get it reviewed and included.

bye,
Sumit