Yvand/EntraCP

Dealing with Duplicate Entries due to multiple Claims Provider

Closed this issue · 9 comments

Hi Yvand,

This is a question more than a bug I think. We have some user entries in AzureAD which will share a number of details with the same users AD claim such as their email for example. When searching in a people picker field we require exact matches on AzureCP which we use to filter out the AD duplicates which works for searching.

However if you assign a user via People Picker to a field on a list item using their AD username. Save the list item, and then edit it again it then picks up the duplicate entries and asks the user to resolve. It will do this every time the user edits the list item which is non-ideal as not all users will correctly identify which one is the correct claim.

With the aim of solving this is there a way we can filter out duplicate entries from AzureAD without hindering the ability to share with guest users? I get the feeling I might be missing something really simple as we dont have this issue with previous claims providers on older instances.

Yvand commented

hi @Charlie-Gunn, during validation (when a user is already added and is displayed again), SharePoint should never receive multiple results.
Where do those multiple results exactly come from (which claims providers return them)?
How many authentication modes are enabled on the web application ?

Hi @Yvand we have two AD Forests (one of which hosts the domain on which SharePoint is present) as well as users coming in from AzureAD. People picker is able to return results from all three of these claims.

Domain 1 and Domain 2 both authenticate via their AD claim to SP. These domains dont share any users. But both have accounts present in our AzureAD Platform. This isnt something I can get changed for reference and as far as I am aware its AD synced so user properties will be close to identical.

The problem manifests as below:

I am adding a user from the Local AD domain to a person field on the list item. I am selecting the local AD claim via their username and saving the list item. When I edit this same list item later I am forced to pick from either the users Local AD claim, or their AzureAD claim. I want to know if there is a way to get around this or if this is intended. One guess was knowing if there is a way to filter which groups AzureCP is able to people users from?

Yvand commented

@Charlie-Gunn so do I understand correctly that 1 user comes from AD and 1 user comes from AAD (AzureCP)?

@Yvand So both accounts are relate to the same user (hence why they are identical in this case).

But you are correct that 1 comes from AD and 1 comes from AAD (AzureCP)

Yvand commented

@Charlie-Gunn I did not test the person field specifically, but as you suspect it sounds definitely by design: Since both claims providers (Windows and AzureCP) return a result, SharePoint gets 2 entries instead of 1 expected, and it throws the error.
I don't see a simple solution to this issue

We tried looking into possibly filtering AzureCP's results using possibly AzureAD groups? That way we can use a group which contains all of our guest accounts and only pick results from there.

I tried looking at how to do this possibly using PowerShell and the only solution I can find is just a blanket remove all AD/AAD users. Or I can filter by an AD OU but its actually a section of the AAD users I want to filter.

If there is anything you are aware of that we might be missing when it comes to filtering out some but now all AAD results? If not we might need to go back to the drawing board.

Yvand commented

Sorry for my late reply.
AzureCP does not offer a way to filter AAD objects based on their group membership.
Did you consider filtering results on AD side, using property SPPeoplePickerSettings.ActiveDirectoryCustomFilter ?

Not a viable option with the setup and requirements unfortunately as I did pose this as an option.

Thank you for the information.

stale commented

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.