Bug 2055634

Summary: Verify that no code paths evaluate AD domain local groups so that members of these groups don't end up in the cache
Product: Red Hat Enterprise Linux 9 Reporter: Thorsten Scherf <tscherf>
Component: sssdAssignee: sssd-maint
Status: NEW --- QA Contact: sssd-qe
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: aboscatt, atikhono, grajaiya, lslebodn, mzidek, pasik, pbrezina, tscherf
Target Milestone: rcKeywords: Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-17 07:28:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thorsten Scherf 2022-02-17 12:26:50 UTC
Description of problem:

Even though SSSD filters out AD domain local groups, members from those groups from time to time end up in the SSSD cache. This results in inconsistent group memberships across different systems. The ask is to verify that no code path in SSSD is evaluating those AD domain local groups.

This is related to https://bugzilla.redhat.com/show_bug.cgi?id=2025667 and specifically to https://bugzilla.redhat.com/show_bug.cgi?id=2025667#c21:

"""
About "why does it sometimes work?", SSSD will read all groups from AD even "domain local" groups, e.g. to map the SID to the group name or other purposes. Additionally if we only have the SID the group must be read to determine the scope. If the scope is "domain local" SSSD ignored this group on purpose when determine the group memberships of the user. But it might be possible that during other request which involve the group the group members are read an associated with the group, although they should have been ignored.
"""


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 RHEL Program Management 2023-08-17 07:28:40 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.