Share all details related to your problem, including any error messages you may have received.
When our role management team was testing assignment rule based business role assignments/de-assignments, they have noticed that when the user criteria changes and when they no longer qualify for a role, users aren’t getting processed for a removal. Upon checking, our team has noticed two things :
attributeAssignments tag created in identity xml for the entitlements provisioned to the user under this assignment rule based business role ( birthright business role )
Entry key assignment with a value true passed under the attribute request for memberOf attribute for AD target in the provisioning transaction xml. Below is a sample
Need help understanding why business role assignment is causing a sticky attributeassignment and how can we fix this ?
Two questions :
Are you using any custom workflows for these lifecycle changes?-Ensure the correct workflows are in place
Are these de-provisioning requests getting generated but not getting completed?
if its the second case you can try running this task and then perform a Identity refresh I guess.
Please let me know if it works for you
Which worklows would an identity refresh process use to process role assignments/deassignments ? I assume ‘Identity Refresh’ and if that is it, we have not customized it.
We are not seeing any deprovisioning requests getting processed because the entitlements that are assigned based on these roles are getting tagged under attributeassignments in the identity xml in which case sailpoint would assume they are assigned at the entitlement level so even when the business role is removed when user HR criteria changes, entitlements are getting retained per attributeassignments tag which is expected. But I am unable to understand why attributeassignments tag is getting added in identity xml for a role based assignment.
Yes I have seen this and similar posts to cleanup such unwanted attribute assignments, but I do not want to introduce customization to fix an anomaly in an ootb process. My goal is to figure out what existing config/customization is contributing to this anomaly, so we can just fix it. Thank you for the input though
OOTB behavior per my understanding on this is that when a birthright role is de-assigned when a user no longer meets the criteria, associated required IT roles and in turn downstream entitlements must be processed for a removal.
