I have my first instances of users with real multiple Entra accounts.
both are attached to the affected identities through correlation.
The role just needs to add a specific group and was a direct entitlement in the role.
the affected users are getting
[“Update operation failed for null, Error: Update operation failed. Native identity is empty or null”,“Update operation failed for null, Error: Update operation failed. Native identity is empty or null”]
now, I assume this is due to the users having two accounts, because as far as I know it’s only happening for these two users.
I tried to switch it up to an access profile with Multiple Account Options enabled, which should pick the correct account as I have an attribute I can add to just these additional accounts. so I added the attribute does not equal NP-Account to the access profile, added it to the role, added it to the accounts, aggregated the data in, applied the changes and we still get the same error.
I may not be using it properly, but this is my first instance where I need to choose which account gets the group.
The role is being automatically applied to the identity, so the multiple account options should be applying it, but it is not.
Does anyone have any thoughts on getting this to work?
Did you validate your logic in determining which account to use? If not use search to validate the logic is working as you expect it to.
The way I have managed this in the past is to create a source where the second account gets pulled in. This comes with pros and cons. A pro of this design is that you can build rules, transforms, and workflows that won’t impact all the other users. Con of this design is that you have another source to manage.
In my environment all admins have 2 entra accounts. Their normal account for Microsoft 365 and their Admin accounts to manage Azure. And what we did was create a source for each so that the correlation logic would work as planned. This allows us to set exact workflows around the admin accounts that won’t impact the normal accounts.
yes, they match, the logic is sound. since at this point it’s two users I have to solve for. it’s easy to validate. I have a few additional sources for just that purpose. for the population, it’s not worth it to do it again for entra. but that is how my admin accounts on-prem are segregated as well.
If I’m reading your post correctly, this is a known issue with a fix coming from engineering at a future date (‘planned’ per the ideas portal).
Role Assignment Criteria leverages only the latest correlated account when evaluating whether a role should be assigned. Even if you add assignment criteria on an access profile tagged to that role, it will pick the most recently correlated account.
I’ve been able to get around this before by removing the account you want the access sent to, and re-aggregating. There are some more notes from engineering in the below idea: https://ideas.sailpoint.com/ideas/GOV-I-5001
I’d recommend up-voting