What were you trying to do that didn't work?

The environment has thousands of NFS shares and users. Users are software developers and frequently change groups. When developers change AD groups, the NFS shares sometimes take days to enforce permissions based on the new group membership - or sometimes never enforces the changes at all. This creates two problems. 1. developers cannot access shares they need. 2. Developers keep access to shares they should no longer access. This introduces a security problem.

What is the impact of this issue to you?

Thousands of developers either cannot access projects they need, or keep permissions to projects they're no longer supposed to access.

Please provide the package NVR for which the bug is seen:

RHEL 8.10 and newer NFS client with Vintela Authentication Services. Also testing with SSSD. The NFS server is Netapp.

How reproducible is this bug?:

At will

Steps to reproduce

1. Set up a RHEL workstation as a member of an AD domain named GregDomain.
2. From a Windows Server, use Active Directory Users and Computers to create an AD user named GregDomain\gregs and an AD group named GregDomain\GregGroup. Do not add gregs to GregGroup yet.
3. Set up an NFS v3 share named GregShare on an NFS server. Grant full RWX permissions to Active Directory group GregDomain\GregGroup. 
4. From a RHEL workstation with NFS Share GregShare mounted as /mnt/GregShare, login as Active Directory user GregDomain\gregs.
5. do "ls /mnt/GregShare" This should return access denied. So far so good. Stay logged in as user GregDomain\gregs.
6. On a Windows Server, use Active Directory Users and Computers to add AD user GregDomain\gregs to AD group GregDomain\GregGroup.
7. From that same RHEL workstation logged in as GregDomain\gregs, use the id command to verify that AD user GregDomain\gregs is part of AD group GregDomain\GregGroup.
8. From the same RHEL workstation as above, still logged in as GregDomain\gregs, do "ls /mnt/GregShare". Keep trying this for several days. It will incorrectly keep returning "Access denied" even though user GregDomain\gregs is now part of group GregDomain\GregGroup.
9. From another ssh or console session on that same RHEL workstation, umount and then mount /mnt/GregShare.
10. For logged-in user, GregDomain\gregs, ls /mnt/GregShare now returns output from the ls command as expected. Stay logged into that RHEL workstation as user GregDomain\gregs.
11. On a Windows Server, use Active Directory Users and Computers to remove AD user GregDomain\gregs from AD group GregDomain\GregGroup.
12. From that same RHEL workstation logged in as GregDomain\gregs, use the id command to verify that AD user GregDomain\gregs is no longer part of AD group GregDomain\GregGroup.
13. As user GregDomain\gregs on that same RHEL workstation, "ls /mnt/GregShare" continues to return output, even several days later, when it should return "Access denied."
14. From another ssh or console session on that same RHEL workstation, umount and mount /mnt/GregShare.
15. ls /mnt/GregShare now returns "Access denied" as expected for user GregDomain\gregs.

Expected results

After a few minutes, user GregDomain\gregs should be able to access GregShare after adding user GregDomain\gregs to group GregDomain\GregGroup. And then after removing user GregDomain\gregs from group GregDomain\GregGroup, GregDomain\gregs should see "Access denied" when trying to access GregShare. I should not have to umount and mount the NFS share to generate the proper results.

Actual results

Need to umount and mount GregShare for permissions to work as expected. This is impractical because multiple users might need access to the same NFS share on a workstation - and so umounting it will mess up other users on that workstation who need it.