Yvand/EntraCP

Add mapping cause issue on People Picker

Closed this issue · 4 comments

Hello @Yvand ,

I would like to report another point.

Starting point: initial configuration and ensured that People Picker is working from CA and a SharePoint site.

Then I add a new mapping betwwen an Azure AD object and a claim type like this:
image

This one is correctly added into the table:
image

Now go to Change site collection administrators, click on Browse icon. As expected, I have the new claim 'Entity' on the left, as the DisplayName for this Claim Type is registered as this.
However, if I enter a user name, it does not work anymore:
image
I presume that issue is the same as the one I reported #164 here.

Moreover, there is something else: from the SharePoint sites, the People Picker is also broken. This was never happen before on my side.
image

Could you please check if you can reproduce this issue?

Let me know if you need more information.

Yvand commented

@julmsy for the claim type to be visible in the people picker, it must exist in the SPTrustedIdentityTokenIssuer where AzureCP is set.
Below is a sample script to add a new claim type to an existing SPTrustedIdentityTokenIssuer:

# Add a claim type to an existing SPTrustedLoginProvider
# Define new claim type
$ctype = "http://new/claim/type"
$ctypeName = "<newclaimtypename>"
$trust = Get-SPTrustedIdentityTokenIssuer "Proseware"
# 1: Add new claim type in ClaimTypes collection
$trust.ClaimTypes.Add($ctype)
$trust.Update() 
# 2: Create the new mapping and add it to the SPTrustedLoginProvider
$mapping1 = New-SPClaimTypeMapping $ctype -IncomingClaimTypeDisplayName $ctypeName –SameAsIncoming
Add-SPClaimTypeMapping -Identity $mapping1 -TrustedIdentityTokenIssuer $trust  

Edit: Now I see that the custom claim type exists in the SPTrustedIdentityTokenIssuer since AzureCP does not show it in red.
Did this claim type exist originally when you created the SPTrustedIdentityTokenIssuer, or did you add it after? If you added it after, did you use the same script as above?

Yes I confirm that Claim Type exists in the SPTrustedIdentityTokenIssuer.
This Claim Type was created since the beginning of the farm (more than one year ago), and was created by SharePoint DSC.

Yvand commented

@julmsy this issue occurs because of the property CompanyName, which causes this error:
Microsoft.Graph.ServiceException: Code: Request_UnsupportedQuery Message: Unsupported or invalid query filter clause specified for property 'companyName' of resource 'User'.

I can reproduce it easily in Graph Explorer with this simple query:
https://graph.microsoft.com/v1.0/users?$filter=startswith(CompanyName, 'yvan')

I did some research on Internet. Surprisingly, the query starts working if I add $count=true and sends the HTTP header ConsistencyLevel=eventual:
https://graph.microsoft.com/v1.0/users?$filter=startswith(CompanyName, 'yvan')&$count=true

I'm not sure if I can set this header and property in the pretty outdated version of the Graph library that AzureCP is using, and I cannot easily update it because so many dependency problems happen with newer versions, due to the fact that AzureCP must run in SharePoint 2013 to SE...

Edit: doc on user properties.

Yvand commented

I was able to fix this through #168, I will see if I can improve a bit before merging