One of the AD group’s OU has been changed on source, but in identitynow we able to see both groups the existing and the new one. For one of the user, identity refresh task is trying to assign this existing group which is failing. I have checked the group is not part of any access profile or role. What trigger is trying to assign this group and why the group is not removing after entitlement aggregation?
Hi @Priyanka,
Was the group assigned to that user through an entitlement request?
Hi @atarodia ,Yes the group was assigned through access request.
As per your comment the new group is still in purview of your aggregation filter and may be due to this deletion is being skipped. Try putting the ldap filter to exclude this particular changed group and see if it removes the group or not.
Thanks
Since the group was assigned through Access Request, SailPoint considers this as Sticky, i.e., if ISC can’t detect the said entitlement on Identity, it would try to assign it again and again.
Revoke the Entitlement from the identity through Access Request API -create-access-request | SailPoint Developer Community
1 Like
The reason it is not considering the OU Move is SailPoint identifier is its DN and not the guid. So as per ISC, its a different entitlement
1 Like
Did you get this figured out.? Looks like the issue here is that ISC still shows up the old AD group that should have been deleted as part of the OU move.
Entitlement stickiness should get removed if the actual entitlement is removed from the source and in your case an OU move will be considered as an entitlement delete.
Raising a revoke request for the old group should fix the issue though, but the underlying issue needs to be figured out.
Thanks for your responses! It resolved the issue, I will observe the tenant to see if there is any more similar issues.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.