Share all details related to your problem, including any error messages you may have received.
I have configured Identity Attribute as ‘empid’ and Display Attribute as empty in the authoritative HR application schema.
When I run the aggregation, it creates 6 identities in SailPoint as per data in HR source file, which is correct. However, when I had updated the Display Attribute value with attribute like ‘email’ and then again ran aggregation, it created duplicate records for same accounts(excluding one account for which email was empty) in SailPoint. The HR aggregation result shows 5 new duplicate identities created in SailPoint. I observed that the new duplicate accounts have HR application linked to it while the HR link has been deleted from all original identities.
I have a doubt, when Identity Attribute ‘empID’ was already defined in application schema why duplicate records got created when Display Attribute ‘email’ was updated in schema. Since Identity Attribute is a unique attribute(and not Display Attribute) in SailPoint, so any changes made to Display Attribute in schema should have reflected in the original identities rather than creating new duplicate records. And not sure why original identities were left with empty HR link while duplicate records had them linked to it. DuplicateAccountIssue.zip (232.9 KB)
1.Question: I have a doubt, when Identity Attribute ‘empID’ was already defined in application schema why duplicate records got created when Display Attribute ‘email’ was updated in schema.
In your case initially all 6 identities were created with the empty display attribute and then after you updated the display attribute to ‘email’ it considered as a brand new identity and creates new identities. So, Identity in SailPoint IIQ is created based on the Display Attribute and not the identity Attribute
Question : And not sure why original identities were left with empty HR link while duplicate records had them linked to it.
Yes correlation will happen based on Display attribute only, which is the reason the one with the empty email got attached and the remaining got removed
also, in your aggregation task, Run the account aggregation task by enabling Detect deleted accounts and Disable optimization of unchanged accounts options to see if the previously created identities still exists.
You specify “empid” for Identity Attribute and “Empty” for Display Attribute in your HR File configuration schema. Every identity has been given a unique username that is simply “empid.”
Identity with unique usernames (email) are created when you declare Display Attribute as “email” for the second time.
Old records are still present as duplicate accounts (orphaned accounts, uncorrelated accounts), so to get out of them, select the task tab and execute the “Prune Identity Cube” task.
Any accounts that have no correlation or reference will be deleted.
I would say best approach would be set Identity Attribute as the one is unique identifier for any user and use the same one for the correlation config with the name attribute mapping .
I have not written identity creation script to onboard these users. Users were imported to SailPoint based on attribute mapping and then running aggregation task.
@vnautiyal2 ,
I just checked your zip file attached , to me problem seems like you 1st set the identity attribute in schema as something different and then again you changed . old identity created are orphan ( you will see no application name in application tab) . run prune task to delete the identity with no Auth source . you will be set.
Thanks, Vishal. The identity attribute which I have used in application configuration is unique for each user. As per your suggestion, I mapped the identity attribute(empid) with name attribute under Account Correlation. Then I cleaned all the identities from warehouse and removed the Display Attribute(email) and ran the HR aggregation which created 6 identities with empID as username, and then I again added back Display Attribute(email) in application configuration and reran the aggregation. But this time it didn’t create any duplicates and correlated with the existing accounts.
I read somewhere that we should only configure manager correlation and not account correlation for an authoritative application. But in my case defining account correlation fixed the issue with duplicate account creation so I am little confused if this is the right configuration or is there any impact of it.
Thanks for your feedback, Rohit. It helped. I followed your suggestion to run the prune task to remove the old identities and it cleared those old duplicate accounts. However, my concern was more into how to prevent it in first place from creating duplicates. Based on @vishal_kejriwal1 comment, I created an account correlation for empID and mapped it with Name attribute in SailPoint. Then I cleared all identities from warehouse and ran aggregation first time without defining Display Attribute(i.e., email) and second time with Display Attribute and it created no duplicate accounts. All the identities were correlated with the existing accounts.
Thanks for answering the queries.
Yes I think you are right, the correlation is happening based on Display attribute and that could be the reason why it created duplicate entries when I updated the Display Attribute. Once I mapped the Identity attribute(empID) to Name attribute in account correlation and did a retest, it didn’t create any duplicate anymore even with Display attribute defined in schema.
To summarize what is going on, and as you have already observed:
When IdentityIQ is aggregating accounts, it first attempts to correlate them with existing identities according to any configured correlation logic. If correlation fails, it falls back to matching the account display name with the name of an existing identity cube. If there is no display name attribute configured, then it attempts to match the account native identity with the name of an existing identity cube. If all of this fails, then IdentityIQ will create a new identity cube. When it creates the new identity cube, it will set the cube name to the display name of the account or to the account native identity if there is no display name attribute configured. Once you configured a display name attribute, IdentityIQ tried to use it and did not try to correlate the accounts using the account native identity. As a result, it failed to associate those accounts with the existing identities and created new cubes. Because you configured a display name attribute, IdentityIQ used that to populate the name on the new cubes.
It’s rather bizarre behavior, because display names usually have no guarantee of uniqueness and are often mutable, which makes them rather unsuitable for use as identifiers without additional context.
