RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1668

We propagate the ghost users within the nested group structure in order for the parent groups to inherit members from their siblings inside the memberof plugin. However, the memberof plugin does not implement the reverse operation - deleting the members when the sibling is removed from the directory.

This leads to users being reported as group members forever if their direct parent is removed from LDAP.

Steps to reproduce:
1. create two groups - mid and top
2. create a user
3. make the user a direct member of mid group
4. add the mid group as a member of top level group
5. getent group top
   -- you should see the user reported as a member
6. delete the mid group
7. sss_cache -g mid to speed force a lookup from LDAP next time
8. getent group mid to attempt the LDAP lookup
   -- the LDAP lookup will fail and will remove the group from the directory
9. getent group top

Expected:
mid is no longer present, so top should not contain mid's members

Actual:
top still contains the members inherited from mid

Verified in version 1.9.2-59

Report from beaker automation execution:
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: 2307bis_007 - bz 880159 - delete operation is not implemented for ghost users
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   LOG    ] :: Sleeping for 5 seconds
:: [   PASS   ] :: Running 'getent group mofuser5_grp_top | grep mof_user5'
:: [   PASS   ] :: Running 'sss_cache -g mofuser5_grp_mid'
:: [   PASS   ] :: Expected: mofuser5_grp_mid group lookup fails
:: [   PASS   ] :: Running 'getent group mofuser5_grp_top | grep -v mof_user5'
:: [   LOG    ] :: Duration: 11s
:: [   LOG    ] :: Assertions: 4 good, 0 bad
:: [   PASS   ] :: RESULT: 2307bis_007 - bz 880159 - delete operation is not implemented for ghost users

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0508.html