When changing a group membership does not change a user's access, the most common cause is that another membership path still grants the same access. Nested groups mean removal from one group rarely proves the user is out of the hierarchy.
The three usual causes#
Before assuming a sync problem, rule out the structural explanations. In practice they account for most of these incidents.
- Another path exists: the user reaches the resource-granting group through a second nested chain you have not found yet.
- Overlapping license assignment: a different group also assigns the same SKU, so the license survives the removal.
- Processing lag: group-based licensing and app assignment changes are applied asynchronously after the membership change, so very recent changes may simply not have landed yet.
Proving which one it is#
The deciding question is whether the user still transitively reaches any group that grants the access. Manually:
Connect-MgGraph -Scopes "User.Read.All"
# Does the user still reach the granting group through any path?
Get-MgUserTransitiveMemberOf -UserId user@contoso.com |
Where-Object { $_.Id -eq "<granting-group-id>" }VisualizerEngine
How VisualizerEngine answers it
Because VisualizerEngine draws the hierarchy as a graph, a second membership path is visible instead of deduced. License inheritance mapping shows every group still granting a SKU to the user, and the change-history panel shows what actually changed and when, so a processing delay is distinguishable from a structural cause in one look.