Hello !
My question is the same than the following post but I’m creating a new one since new replies are no longer allowed.
For us, the identity attribute “Account Name” seems corresponding to the account attribute designed as “Account Name” from the account schema for the authoritative source and this fits the need.
However, we got an exception and it seems that the identity attribute “Account Name” could be defined by the UID.
Would you please help to confirm how this attribute is defined ?
Hi Tima,
Could you please elaborate a bit more about the issue you have? It’s actualy not completly clear for me what you want to achieve and what the issue is
Account Name designates the “name” of the account being aggregated, which becomes the internal name for that “basic” identity cube.
In IDN, the Account Name in your screenshot is the unique name of the identity, therefore you should be setting your Account Name in your source schema to something unique such as an Employee ID from an HR source.
The other post you referenced is incorrect. UID and Account Name are not the same. UID/SailPoint Username is mapped in the identity profile and is used to log in to IDN and perform password reset. Account Name is the unique name of the identity which is generated from the Account Name on the source schema where the identity is created from.
Hi Tima, I also have a weird behaviour with this attribute. For example, I have an authoritative source in which account id and acount name is the personal id of the user. When Identities are created, it takes this id as uid attriubte, and identity “Account Name” shows also this id.
Later, when identity gains AD and other systems, uid changes, and I do not why, Account Name appears with the same value of the Display Name attribute.
As clients did not comply about this, we never research this, but I would like to know too, some time will come a client that will comply
There seems to be a situation in Workday where occasionally the FILENUMBER of the account as it gets aggregated by IDN comes through as the Worker Name. In troubleshooting this with customers we’ve found that it seems to have something to do with Pending employees on-boarded in HR before all the background checks and other paperwork are completed. Haven’t been able to dig down to the exact root cause yet though.
Hello,
We have an explanation from the support.
An identity is created via non authoritative source in the backend for holding the uncorrelated account. This is an expected behavior.This identity is not visible on the UI as there is no auth source available for it yet and as it is not correlated. Its account name corresponds to the account attribute marked as “Account Name” from the non auth source.
Once we ran the aggregation for the auth source, this identity got correlated and is made visible on the UI. Thus, if both sources have not the same account attribute marked as “Account Name”, the identity attribute account name will not be from the auth source.
Hi Tima, I had another response xD they told me that the Account Name was the Account Name defined in the source schema of the authoritative source (which make sense too), but in some of our tenants we have this Account Name value with the display name value of identity, so they are stilll making an analysis of this particular case.
Hi Julian, thank you for your feedback. Maybe it depends on the use case. For us, it’s about a reentry (with uncorrelated accounts from the non authoritative source). Otherwise, the identity attribute account name is defined from the auth source as it should be
Yes, I think that too. I remembered a case we had, in which identities that were deleted and re created remained with old Account Name, as support told you. Perhaps the expected way in normal situation is this attribute to be the Account Name of source, but it may vary depending of other scenarios. I will return if support finds something in one of our cases.
We are also seeing the same thing, the UID and the account name for identities which are correlated to an Azure account are different (our auth source is Workday), the UID is the filenumber from workday and the account name is the email attribute (which i guess is from azure). But the ones which arent correlated to the Azure account they have the same UID and the account name which is the filenumber. Is there any challenges to having different values for UID and account name in the identity cube?
