Fedora Account System
Red Hat Associate
Red Hat Customer
After upgrading to sssd version 2.10.2, on hosts running both Fedora 41 and 42, sssd "forgets" group membership information after about an hour. After this occurs, the "id" command shows the user's password information and local (/etc/group) information but does not include groups that come from freeipa. Likewise, the getent group <freeipa groupname> command shows the group number and name, but does not include group members. Restarting sssd does not fix the problem, and neither does clearing the cache, even deleting the cache files. Forcing the sssd to switch ipa servers does cause group membership information to return, but again it disappears after an hour. I have confirmed that group membership information is correct when queried directly from freeipa when sssd does not display it. I initially thought that reverting sssd version 2.10.0 fixed the problem but I now have one reverted server that failed. This bug is causing havoc with applications that depend on particular group membership. Reproducible: Always Steps to Reproduce: 1.Start sssd for the first time (or force it to switch ipa servers) 2.Wait about an hour 3.Perform group query: getent group homeassistant (or any other freeipa group) Actual Results: homeassistant:*:637200008: Expected Results: homeassistant:*:637200008:user1,user2,user3 Additional Information: I have not been able to find errors in the logs that would explain this behavior.
Hi, would it be possible to add `debug_level = 9` to the [nss] and [domain/...] section, restart SSSD, wait until the issue occurs, call sss_cache -E getent group homeassistant and send the SSSD debug logs? bye, Sumit
Created attachment 2086740 [details] sssd level 9 debug logs Debug logs during group failure, as requested.
Hi, it looks like you have set `ldap_search_base` in sssd.conf to the baseDN of the IPA server and the compat tree in enabled on the IPA server as well. As a result a search for a user or a group will find two entries, one in the main IPA LDAP tree in `cn=accounts,baseDN` and the other in the compat tree. Is there a reason to set `ldap_search_base`? If not, I would suggest to remove this option from sssd.conf and check if the behavior is more consistent. HTH bye, Sumit
I might have had a reason for setting ldap_search_base years ago when I did it. I believe it was related to initial attempts to make autofs work. However, I haven't thought about it in years, and it never would have occurred to me that it could cause this issue. I removed it several hours ago on multiple machines, and none of them has forgotten group members since that time. I believe it's fixed, and I deeply appreciate your help. I still wonder why it worked for years and only recently became a problem, but it probably doesn't really matter.
Hi, glad to hear it is working for you. In recent versions of SSSD some performance improvements related to group lookups and processing group members were added. Although I currently cannot point to the exact change which might have led to the change in behavior your are seeing I suspect it is coming from those changes. On the other hand I'm surprised that it was working for you so long before because in general SSSD does not expect that multiple results are returned from an LDAP server when searching for a single user or group. bye, Sumit
Hi Sumit, (In reply to Sumit Bose from comment #5) > > In recent versions of SSSD some > performance improvements related to group lookups and processing group > members were added. Although I currently cannot point to the exact change > which might have led to the change in behavior your are seeing I suspect it > is coming from those changes. JFTR: if you mean - https://github.com/SSSD/sssd/pull/7841 - https://github.com/SSSD/sssd/pull/7866 - https://github.com/SSSD/sssd/pull/7872 then none of those were shipped in Fedora yet / not a part of sssd-2.10.2 (or any other upstream release).