We have the NERM module where we have the person and assignment profiles that are aggregated automatically into ISC as identities.
We also have a NERM role in ISC that provisions AD access by birthright depending on some criterias.
I have realised that every time we get a new identity from NERM in ISC, AD account creation works great, however, about 20 seconds after account creation - another AD account creation task is provisioned but failed as the exact same account already exists in AD.
The identity only has the 1 role on the cube that itself only contains 1 AD entitlement. I can’t seem to understand where this 2nd provisioning event is triggered from.
This is a common issue that can be tricky to debug. The duplicate provisioning event you’re seeing is often caused by a second identity refresh happening shortly after the initial one.
When a new identity is created from NERM, an event-based identity processing task is triggered. This assigns the birthright role and provisions the AD account. If another identity refresh (either event-based or scheduled) runs shortly after, it can re-evaluate the identity and trigger the same provisioning request again.
Here are a few things you can check:
1. Check Aggregation Schedules: The most common cause is overlapping or concurrent aggregation schedules. Make sure you don’t have multiple source aggregations running at the same time, as this can trigger multiple identity refreshes.
2. SailPoint Support Feature Flag: There is a feature flag that can be enabled by SailPoint Support to prevent these duplicate account creation requests. This is often the quickest solution. You can open a support ticket and reference this issue.
3. Review Identity Refresh Timing: Check your identity refresh schedules. If you have a scheduled refresh running very close to when new identities are created, you might want to adjust the timing.
This has been discussed in the community before. You can find more details in this thread: AD Duplicate Account Creation
I’ve seen this exact pattern a few times. It’s almost never “two roles” or “duplicate access.” It’s ISC re-processing the identity twice during NERM onboarding and firing two create-account plans before the AD link/state fully settles.
What’s likely happening
• NERM creates/updates the identity → ISC evaluates birthright and submits Create AD Account (plus any bundled group membership).
• Seconds later, a second processing pass runs (most commonly because you have overlapping jobs: NERM activity + AD aggregation + scheduled identity refresh/other processing in the same time window).
• That second pass still “thinks” there’s no AD account ready/linked yet, so it submits Create Account again. AD rejects it as “already exists,” and anything bundled with it fails too.
How to confirm quickly
• Pull the timestamps for the successful create and the next failed create. If they’re close together and you see another identity update/process event in between, you’ve got the smoking gun: two runs, same birthright, same target.
How to stop it
De-conflict your schedules
Don’t let NERM onboarding run right next to AD aggregation or any identity refresh schedule. Stagger them so onboarding has time to finish and the link is stable before the next processing pass.
The duplicate provisioning event likely stems from NERM identity aggregation triggering birthright role evaluation twice—once on initial creation and again when identity attributes update shortly after. Check if identity refresh operations or lifecycle state changes are re-triggering the role assignment logic within that ~20 second window.
Common causes: Identity attribute updates post-creation, overlapping aggregation/refresh jobs, or birthright role criteria being re-evaluated on minor identity changes.
Just a hunch:
Is the identity creation (by Person profile) trigger one refresh, and then, the correlation of the assignment profile / account into that same identity triggering another refresh?
Would you mind sharing search results, especially for Account Activity for a particular user you are seeing two accounts in AD created? For if it’s Identity Refresh that is causing the account creation ideally there would be a log for that you can at least share with support.
Thanks,
Amar
Hey. the Birthright role that provisions AD access has criterias that only derive from the assignment profile. Meaning the Person-profile never evaluates to any birthright access within itself.
Potentially a race condition could occur though…if this sequence happens (?):
Aggregated Person Profile
Create Identity
Start Refresh Identity (thread 1)
Aggregated Assignment Profile
Correlated assignment to Identity
Thread 1 starts role assignment logic evaluation.
Start Refresh Identity (thread 2)
Thread 2 starts role assignment logic evaluation.
I have a feeling that thread 1 Refresh doesn’t look at a point-in-time frozen identity. And even if it does, there’s no guarantee that the freeze / snapshot is done before or after step 5. …though this is just speculation at this point…
I asked this exact question to SP and this is the answer I got:
”Hello Sebastian,
We have enabled the FF that you mentioned. This FF will only stop the creation of duplicate provisioning request on Identity refreshes. I believe it was caused because of your use-case, 2 accounts coming from auth source. Now, that it is enabled, you should not see duplicate requests for an Identity.
If you happen to see similar issues happening in the production environment, then yes, you would need this flag in that tenant as well.
Please let us know if you have any concerns.”
In other words, not sure exactly what the FF is called or where it is located..
Another route, if you always have assignments for your people, is to have the logic for the role assignment not trigger until the assignment account is there – or have your lifecycle state not be calculated to active until the assignment account is there (have it checking for one of the assignment attributes).
