Correct we are using AC_NewParent/AC_NewName
And process wise. Yes we are not moving the OU outside sailpoint.
And correlation config?
Hi, I am seeing this same stickiness problem, but with a different flavor. An entitlement was created in AD and was added to a user by an access request. The entitlement was later moved (outside of SailPoint) to another OU in AD, and now SailPoint is trying to re-provision the original entitlement location. We are getting the same “Add Entitlement Failed” and “Create Account Failed” messages. How can we cancel these “sticky” requests and stop the failures?
Hi @regilicha WADR that’s a different issue. Someone has removed (in ISC’s understanding) an AD Entitlement but not instructed ISC to stop assigning access to it.
Hello Jeremy, thank you for your response. I understand that it is a different issue, but the symptoms are the exact same. Would you happen to know how to instruct ISC to stop assigning access to the entitlement? That is what I’m looking to solve… WADR.
Hi @regilicha it would be best if you opened a new post for a new problem.
this occurs;
- when isc cannot correlate the AD account to the identity.
sol:
- verify that the account correlation configuration, native identity/unique identifier, and aggregation results correctly link the AD account to the identity.
- If uncorrelated, ISC treats it as missing and issues Create Account requests.
- Reaggregate the source and confirm the account appears as a correlated account .
@rahulks88 I don’t think it is sticky entitlements issue . Pls check below points. I am not too sure about the answers.
pls check below points.
- AD account move process
- AC_NewParent handling
- Native Identity updates after move
- Correlation after aggregation
- Whether the moved account remains within AD source search scope