Ok, you have now ascertained that the nairjash3 account was created by ISC from this identity (unless someone performed a manual correlation manually) and the nairjash account was either created “out of band” and correlated with this identity or created by ISC from a different identity, un-correlated from that identity and correlated to this identity.
Going back to my response earlier, please fix AD and run an aggregation. There does not appear to be an issue with ISC, it is doing what it is supposed to be doing.
As we know, you do still have a problem with your provisioning policy, but that is a separate (genuine) issue, which should be fixed in parallel. What you are seeing here (i assume) is a symptom of your problem with provisioning.
Before proceeding, we need to verify whether this is a new hire, rehire, termination/reactivation, or duplicate account creation scenario.
Observations:
LA00rphe7 was created first and is currently disabled.
LA00rphe was created later and is currently enabled.
The disabled account appears to contain email and other required attributes, while the enabled account is missing some attributes.
Since creation date alone is not sufficient to determine which AD account should be retained, we need to review the provisioning/HR history and account audit records to identify the correct AD account. Until this validation is completed, deleting the disabled account is not recommended.
I am a little confused about the exact issue here.
Are you mainly trying to remove the duplicate/disabled AD account, or is the actual problem that ISC is picking values like email/UPN from the disabled account instead of the active account?
Just want to understand what you are trying to solve right now before suggesting anything.
The root cause was a misconfigured attribute in the CHUBBFSAD account creation profile. The attribute was configured as "employeeID " (with a trailing space) instead of “employeeID”.
During provisioning, SailPoint attempted to populate this non-existent AD attribute and Active Directory rejected the request with the error:
“The specified directory service attribute or value does not exist.”
As a result, the AD account was created, but the provisioning process did not complete successfully, preventing proper correlation back to the identity.
During subsequent identity refreshes, SailPoint considered the account missing and repeatedly attempted to create it again. Each retry generated a new unique account name by incrementing the uniqueness counter, resulting in the duplicate accounts that were observed.
he numbered CNs listed below are the duplicates created by the retry loop. For each identity, keep the single account currently correlated to the identity in ISC and remove the others:
Jaiswal, Anjali - OU=IN - JaiswaAn2 through JaiswaAn7
Here the mail value picking which one is correlated that mail value picked by sailpoint, Whether it is disabled or enabled.
Just to reconfirm my understanding, the current issue you are checking is about the mail value, right? You want to confirm which AD account SailPoint is picking the mail value from when multiple AD accounts are linked to the same identity, whether the account is disabled or enabled.
My understanding is that SailPoint will not automatically pick the mail value based only on whether the account is enabled or disabled. It will pick the value based on the account that is currently correlated and used by the identity attribute mapping or transform logic.
So if a disabled AD account is still correlated to the identity, and the mapping is reading from that account, SailPoint can still pick the mail value from the disabled account.
Please try this:
Identify the one correct AD account that should remain for the identity.
Make sure that account is the correct correlated account in ISC.
Update that AD account with the proper mail, userPrincipalName, employeeID, and any other required attributes.
Remove, delete, or uncorrelate the duplicate numbered accounts after confirming they are not needed.
Run AD account aggregation and identity refresh.
Check Identity Profile preview to confirm the mail value is now coming from the correct account.
So, in simple terms, clean up the duplicate accounts first, keep only the correct AD account, and then make sure the identity attribute mapping reads from that correct account.
Interesting that ISC re-provisioned accounts. In this situation, the incomplete account would still remain correlated, so ISC shouldn’t attempt to re-create, unless the failures were manually uncorrelated (removed from the Identity).