Hi All,

Been banging my head against the wall with this one and desperate for some help!

We have an issue occurring across many servers using SSSD for authentication/integration with Active Directory during which the user is denied access to something they've been granted. When we perform an "id -Gn <username>" on the server, a group association is missing. I discovered that it appears (from what I can interpret) SSSD finds the group in AD and begins making the assoication, but expects the group to be in the ldb cache (which it isn't apparently) and because it can't find it, doesn't associate the group. The following is an example of the debug log (username has been replaced by <username>, while group name has been replaced with <groupname>):

(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [save_rfc2307bis_user_memberships] (0x2000): Updating memberships for <username>@ent.ad.mre
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [ldb] (0x4000): start ldb transaction (nesting: 2)
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [sss_domain_get_state] (0x1000): Domain ENT.AD.MRE is Active
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [ldb] (0x4000): start ldb transaction (nesting: 3)
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x555d730e5140
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [ldb] (0x4000): Entry not found (name=<group_name>@ent.ad.mre,cn=groups,cn=ENT.AD.MRE,cn=sysdb)
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [ldb] (0x4000): cancel ldb transaction (nesting: 3)
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object (32)]
(Fri Nov 29 16:16:05 2019) [sssd[be[ENT.AD.MRE]]] [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)

I'm at a loss for why this is occurring, and randomly with different users differnt servers. Especially given they all have the same configuration (as far as I can tell).

Any assistance would be greatly appreciated.

Regards,

Greg

I figured this out for all those that may encounter a similar issue.... someone added "krb5_validate=True" in our SSSD.conf. I had to remove this setting and force a deletion/rebuild of the cache. There were some other issues, but this appears to be the most widespread.

Regards,