Strange behavior encountered on IDN/ISC when there’s a change made to firstName or lastName value in the auth source the initial Identity is getting deleted and a new Identity is being created instead.
If firstName or lastName changes leads to this level of data difference it will lead to major incidents on the client’s end. Can anyone confirm if they see this happen on their respective client environments?
Those four attributes are the fundamental pillars of account creation. If you change them, you are effectively telling Sailpoint that this is a different user, so it creates a new cube for them.
Thanks
Phil.
PS Better to delete the user, then re-add with the correct data rather than trying to amend: id, email, lastname, firstName
But does that not defeat the purpose of Attribute Sync feature.
Usually if someone as a corner case gets their Legal name changed or wants to have a nickname associated in their organization. SailPoint will basically create a new cube and generate an uncorrelated account on tenant level and it will only be detected when the Loopback connector is involved.
This thing is making me uncomfortable not gonna lie. Your thoughts Phil?
There is a difference between an HR source via a connector and a flat file source.
With the former, you can amend these three values “email, lastname, firstName” and Sailpoint will accept the changes, but with a flatfile source, it will create a new cube.
I don’t know if this is a BUG or a feature though.
@phil_awlings@amansingh
In my case, its the other way around. I am seeing that if its a direct connector (SuccessFactors to be precise) and I change the first name of the user on the auth source which is coming into ISC via aggregation, a new identity is getting created and the old one is deleted.
This sounds strange to me. Atleast as long as SailPoint Username (Uid) is not altered, it shouldn’t create a new identity. But open to understand more here.
That definitely shouldn’t be happening.
Is SF your primary source of truth? If its not, that might explain what’s happening due to a mismatch in correlation rules. Its failing to match to the original cube, therefore creates another cube
If anyone wants to recreate it I have made a small pdf file with the exact steps that I have performed to recreate this scenario. identity_breaking_delimited_auth.pdf (788.5 KB)
In the image of your identity profile, the SailPoint Username (UID) is mapped to an account attribute called personId. Can you share an example value of what that account attribute looks like on the source?
I second this observation. It seems like changing the firstname is also affecting the username you have mapped in the identity profile, hence the new identity being created.
Hey All,
So after some more digging I found that the link is breaking at source-level not at the Identity Level.
Meaning if sailpoint detects the change in values for any attribute that is promoted as accountName the identity breaks.
According to any source per my knowledge in both IIQ and IDN (psst I had to show that off ) nativeIdentity or Account ID is the unique identifier and Account Name or display attribute works more like a human friendly meta data that makes.
Officially quoted in the Service Account management documentation: Service Accounts | SailPoint Developer Community
Would still appreciate your attention to this item.
Will share a detailed PDF with screenshots if required.
I’m glad you posted this as I’ve run into a similar experience. Name changes seem like a pretty common use case, so you would hope that ISC would handle it well.
In my testing, I’ve found similar to you, that as long as the source account name and account ID are not changed, the identity cube will be retained. I noticed that the account name on the identity (SailPoint account) matches the account name on the authoritative source. Therefore, it makes sense that a change to the source account name would break the source’s correlation to the identity.
) nativeIdentity or Account ID is the unique identifier and Account Name or display attribute works more like a human friendly meta data that makes.