Issue

We have a FreeIPA instance running in a container in a small network in a research lab, and use it basically only as convenient LDAP server & GUI. Advanced features like Kerberos and DogTag are currently not used at all.
The container version in use is:
quay.io/freeipa/freeipa-server centos-9-stream f0a90ae49439

Somehow, after an update, the clients running sssd "forget" about group associations for users, so users suddenly loose all their groups, leading to people being unable to log in (as login permissions are based on groups). This is likely due to sssd requesting new information from FreeIPA/389ds and receiving wrong information.
A workaround we implemented is to delete the sssd cache evers 15 minutes and to restart sssd on the clients. This originally led us to believe this to be an sssd bug, but that has been clearly ruled out by now: We had this issue in the past, then a FreeIPA update fixed it, and now another update reintroduced it again.
(we were chasing this in sssd for a while)

Unfortunately I have no idea which container version update caused the reintroduction of this issue, as we didn't record the old version and once the bug was discovered, our backup keeping the old data had already expired (lesson learned for the future here...).
Given that version 4.10.2-1.el9 has this issue, I assume that an upgrade from 4.10.1-1.el9 --> 4.10.2-1.el9 reintroduced it, but since data downgrades are AFAIK not possible, I can't revert to the previous version to test this.

Steps to Reproduce

Unfortunately I don't know how to cause this behavior in other systems, but we can consistently reproduce it here. I can provide any information or logs needed.

Actual behavior

Sssd on the client side forgets all user groups after ~15min with FreeIPA providing LDAP. A database reset & sssd restart brings the groups back. No errors are recorded by sssd.
The issue started to appear after a FreeIPA upgrade.

Expected behavior

All groups are permanently kept, even if sssd requests incremental updates later.

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

ipa-server-4.10.2-1.el9.x86_64
ipa-client-4.10.2-1.el9.x86_64
389-ds-base-2.3.4-2.el9.x86_64
package pki-ca is not installed
krb5-server-1.20.1-8.el9.x86_64

Additional info:

This is the /etc/sssd/sssd.conf file used on clients (information anonymized a bit):

[sssd]
config_file_version = 2
domains = default
reconnection_retries = 10
[sudo]
[nss]
filter_groups = root, postfix, postmaster, postdrop, prometheus
filter_users = root, postfix, postmaster, prometheus
default_shell = /bin/bash
[domain/default]
#debug_level = 0x3ff0
enumerate = true
cache_credentials = true
override_shell = /bin/bash
id_provider = ldap
ldap_uri = ldap://ldap.server.domain.local
ldap_search_base = dc=blah,dc=test-domain,dc=com
ldap_schema = ipa
ldap_tls_cacert = /etc/sssd/ca.crt
auth_provider = ldap
access_provider = simple
simple_allow_groups = allowed_access_group1,allowed_access_group2,allowed_access_group3
ldap_default_bind_dn = uid=sys_search,cn=sysaccounts,cn=etc,dc=blah,dc=test-domain,dc=com
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = <token>
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=blah,dc=test-domain,dc=com

Workaround: Run sssctl cache-remove -ops on the client systems every 15 minutes (of course, that's a very error-prone and annoying workaround).

Thank you very much for looking into this issue, it had me puzzled for many months, and attempts to debug it have so far lead nowhere (but I also don't know the IPA codebase and 389ds well).