If you cannot handle the DN /CN changes from SailPoint, here is a workaround that I’ve implemented elsewhere:
- Enable native change detection for attribute changes on the DN
- Develop a workflow that identifies that native change event, and if it does, fires off the ‘child workflow’ from this link: Workflow to remove ALL leavers' standing access so that SailPoint won’t continuously attempt to re-apply the entitlements to the old DN. This will only strip access from the old DN - any entitlements, access profiles, and roles will still be detected on the AD account and won’t be removed from the account that has had the DN updated.
- Add in a BeforeCreate connector rule, a check on a unique attribute for the organization (e.g., employee number). Pass the unique attribute through using the Services Standard Before Provisioning rule and check if the account already exists, if so, remove all attribute requests from the provisioning plan.
Ideally it would be possible to just change the unique identifier to something that doesn’t change, like the objectGUID, but this has other impacts on Roles and Entitlements needing to be reset.
Hope this helps!