We are having an problem in AD Account in Active Directory from ISC.
There was an issue that occurred when rehiring an identity from Workday source which had been terminated greater than 60 days ago. Their active directory account (was uncorrelated & their Oracle account was uncorrelated. On rehire, the OED account correlated but the active directory account did not. This caused a duplicate active directory account to be created. In addition, a SailPoint ISC account was not created for the user on rehire. Please investigate this issue & how this can be resolved in the future.
Can anyone help me on this how can I fix it.
Due to license constraints, we are not saving the terminated identities if their date of termination is greater than 60 days whereas the disabled AD account will still have the EmployeeID. So how can we correlate the AD account to the Identity Cube once it is recreated during Rehire scenario ?
I’m assuming “duplicate account” means that ISC is creating an additional account for the user because the previous one isn’t currently correlated to the new identity? Does your WorkDay record still contain the account ID value from their previous account? We do our rehire account provisioning from the account value on our PeopleSoft record, and the provisioning will typically fail if the account already exists in the domain but wasn’t correlated to the identity. We also delete AD accounts +30-days after a term, but the auth record continues to be sent for 90-days, so it’s not often that there is a situation where the account exists but isn’t correlated.
If you don’t have the account value when the WorkDay rehire record is aggregated, I’m wondering if you could use a transform to set the “Next Processing Date”(nextProcessing) attribute in the identity profile far enough into the future to allow the AD aggregation/correlation to take place before any provisioning happens? I believe the minimum time you can set that attribute forward is 1 hour beyond the current time.
This looks like an account correlation issue during rehire, not only a provisioning issue.
In this case, the AD account was already existing but became uncorrelated after termination. During rehire, ISC did not match the existing AD account, so the provisioning plan treated the user as a new account and created a duplicate AD account.
Recommended checks/solution:
Check AD source account correlation
Verify the AD account correlation configuration.
Do not depend only on email, username, or display name because these can change during rehire.
Use a stable unique attribute such as employeeNumber, employeeID, workerId, or Workday ID if available.
Run/verify AD account aggregation before provisioning
Make sure the old AD account is aggregated into ISC before the rehire provisioning runs.
If the account is uncorrelated, manually verify why the correlation failed.
Fix the existing account first
Correlate the old AD account back to the identity.
Remove/disable the duplicate AD account as per company process.
Run Identity Refresh and source aggregation again.
Review Joiner/Rehire workflow
The rehire workflow should check whether an existing AD account already exists before creating a new one.
If an account exists, the workflow should enable/update/reactivate the existing account instead of creating a new AD account.
Review Create Account profile
Check what attribute ISC is using as the AD nativeIdentity / sAMAccountName / userPrincipalName.
If the generated value is different from the old account value, ISC will create a new account.
For future prevention
Strengthen AD correlation rules using a stable HR identifier.
Ensure AD aggregation runs before rehire provisioning.
Add a workflow or provisioning check to detect existing AD accounts before account creation.
Keep terminated accounts correlated where possible instead of allowing them to remain uncorrelated.
So the main fix is: correct the AD correlation logic and rehire workflow so ISC can find and reactivate the existing AD account instead of creating a duplicate one.
manually correlate the original disabled AD account to the recreated identity
disable/remove the duplicate AD account if not required
run identity refresh/aggregation to ensure all accounts are properly linked.
In the future, to avoid these issues
Maintain terminated identities longer than 60 days (if licensing permits) for systems where account reuse is expected during rehire scenarios. And also create rehire workflow to enable all the linked accounts automatically.