When an identity details are aggregated from an Authz Source Named as “UserDB”, the AccountID and AccountName for this source in Account Schema is marked to an attribute named as “UserID”. Hence, when identity is aggregated from mentioned authz source and created in SailPoint ISC, the user gets created with Account Name as “UserID” attribute value which comes from Authz Source. Example.
But, when the user is removed/disabled from Authz Source Named as “UserDB” and is again rehired from WORKDAY, then, all the details are updated as per Workday Identity Profile as Workday Identity Profile has higher priority but the AccountName attribute value is still pointing to Old One as mentioned in above screenshots.
Note that Account Name attribute as highlighted below is dependent on Account Name configured in Account Schema configurations of the source. Hence, i we change the Authz Source of user by rehiring from a different source, why the Account Name from User’s details page still remains the old one and not updated to a new value?
Hi @rohit_wekhande,
Please verify the user email attribute. If the email attribute is the same for both the old and new accounts, it could indeed cause issues with updating the AccountName attribute. SailPoint might be using the email attribute as a unique identifier to correlate accounts, which could lead to the old AccountName persisting.
Note that its a rehire scenario where the same user with Same User ID is getting onboarded from WorkDay. Note that the older User ID is getting retained for the user.
It is as designed by SailPoint. Correlation is always attempted before an identity is created. If the account cannot find an existing identity to correlate to, and it’s an authoritative account source, then it creates an identity.
Here first time, the identity got created from “UserDB”, and I assume, later the identity resides in ISC though it got deleted from UserDB and the same identity gets correlated with Workday during rehire process. The “account name” attribute won’t change, so whatever it was on the identity that’s being created/correlated first time will remain same.
In case, if you want to change the account name, then you need to create a new identity from Workday instead remapping the UserDB’s identity to Workday auth source.
The same issue occurs if you aggregate the non-authoritative source first and auth source later. In this case, the account name will be generated from non-auth source, and it will not change when an auth source is aggregated. So, always it is recommended to aggregate the auth source first.
So, in short, when the identity will be aggregated first, whatever is the value of “AccountName” attribute, that will be populated and then, update of “AccountName” wont happen in SailPoint ISC? is that understanding Correct?
Also, there are cases that during initial aggregation from Authz Source lets say WORKDAY, the UserID is populated as “AccountName” depending upon configurations in Account Schema. But, post AD provisioning, the SamAccountName gets updated in the WORKDAY against UserID field. So, even in this case, the AccountName will remain the old and will not be updated with actual UserID attribute which is coming from Authz Source.
I never tried your use case on changing the AccountName schema attribute value, but my understanding is that it will never change from the first value when the identity was created. Because I had a scenario where the non-auth source got aggregated first, later the auth source aggregated and created an identity with non-auth source’s accountName and it never changed to auth source AccountName value.
