Morning all,
Bit of a weird error.
Last year we created a process to automate AD account creation via ServiceNow. Fairly standard stuff. The engineer used a test entitlement for the process which worked fine.
This is in PROD. He then renamed the entitlement for go-live and all future account creation works fine.
The problem is that we now have 180+ identities that have the AD account created and correlated, but used the testName entitlement which no longer exists on the AD. Sailpoint is trying and failing to add this entitlement which no longer exists, for a process that has completed successfully.
I can fix the problem by asking the AD team to recreate the entitlement, but then that is just clutter on the AD source. Is there a more elegant solution to this than what I’ve suggested?
Many thanks
Hi Phil,
Instead of recreating the obsolete entitlement in AD, perform a controlled cleanup within SailPoint:
-
Identify impacted identities
- Use a report or Identity Warehouse query to list identities holding the obsolete entitlement.
-
Remove the invalid entitlement from SailPoint
-
Execute a targeted identity refresh or custom remediation rule/workflow to remove the orphaned entitlement reference.
-
Ensure provisioning is disabled for removal if the entitlement does not physically exist in AD.
-
-
Reconcile identities
- Run an Account Aggregation followed by an Identity Refresh to synchronize the correct entitlement state.
This approach ensures SailPoint’s internal state is corrected without introducing unnecessary objects into AD.
Hello @phil_awlings ,
How does “testName“ entitlement is being added to users? as part of role or access profile?
Its a ServiceNow request that adds that entitlement to the identityCube. That has been updated, the problem is, that in Sailpoint’s history, the original account create process used ‘testName’ entitlement which no longer exists to add.
I’m not sure how to implement @pkMishra idea as its part of the refresh cycle for a process that is months old
Hi Phil,
First, I would like to confirm whether the AD account creation for the 180+ users was solely based on the testName entitlement value. Additionally, it appears that this entitlement now exists only within SailPoint and is no longer present in Active Directory.
If this assumption is correct, I would suggest the following approaches:
Option 1 (Preferred):
Implement an automated remediation rule that iterates through the impacted identities, identifies the obsolete entitlement, and removes it from the identity cube. This would permanently resolve the issue without reintroducing the entitlement into AD.
Option 2 (Alternative):
Implement a Before Provisioning Rule to inspect the provisioning plan for the testName entitlement. If detected, the rule can capture the entitlement (or similar non-existent entitlements) in a custom object for tracking purposes and remove it from the provisioning plan to prevent further failures.
Please let me know your thoughts on these approaches or if you would like to discuss them in more detail.
Hi,
1 - account creation was solely based upon testName entitlement value. This entitlement no longer exists on the AD, but still persists on Sailpoint.
Option 1: the entitlement does not exist on the cubes, so it cannot be removed
Option 2: Implementing a Rule to run it just adding an enduring load to the system.
I really appreciate the thought and time that you have put into this. However, I feel that the simplest option is just to re-create the entitlement and add a ‘do not delete’ description to it. Sailpoint will add it back in and then forget about it. 1 more entitlement won’t make any difference to the 100,000+ that are already there
Yes that also can be done. But before provision rule will make sure going forward if any similar issues encountered it will remove the non-required entitlements from plan and add it to custom object for future scope.
Rest as you said re-creation will also be fine.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.