Results not showing

Sep 2, 2014 at 4:52 AM
Hi,

I have had the solution running for some time on two environments test and prod. All was working well until recently the custom claim mappings I added show in the people picker in the test environment e.g. I have setup a mapping for company and country. When I try to type the same value into the prod people picker I get "a showing 10 results" but none of the additional claims I added show in the list like they used to.

It did work a month ago when deployed and I have tried re-mapping the claims/updating the solution/re-installing the solution so far nothing has fixed it.

Any ideas?
Coordinator
Sep 9, 2014 at 11:51 AM
Hello,
if you go in central admin > change site collection administrators, do you see the claim types?
What is the "claim entity type" of those custom claim types?
Can you run cmdlet below and double check it matches your custom claim types:
(Get-SPTrustedIdentityTokenIssuer "SPTrustName").ClaimTypeInformation| ft MappedClaimType
cheers,
Yvan
Sep 9, 2014 at 11:53 PM
Edited Sep 10, 2014 at 12:23 AM
Hi Yvand,

The command runs fine but I cannot use the in central admin and they don't show up in the people picker browser below are screenshots.

Image

Image

Image
Sep 10, 2014 at 12:35 AM
I had a look at our test environment and it shows the same output with that command and the central admin people picker browser is the same however when setting security on a SharePoint site I can use the extra claims e.g. give HR access to the HR site collection.

I have looked in the ULS logs and the results show there they just don't display in the people picker. Could it be that the test environment AD only has ~50 users but production is ~500?
Coordinator
Sep 10, 2014 at 6:46 AM
I think I understand, are those custom claim types set with a "claim entity type" ( http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.administration.claims.spclaimentitytypes_members(v=office.15).aspx ) other than "User"?
If so this is by design by SharePoint, which won't show them in central administration. This is because it doesn't want to let you set groups as site collection administrators.
Sep 10, 2014 at 11:28 PM
The claims are of type "user" and were setup exactly the same as the LADPCP out of box locality mapping just using different AD attributes. What gets me is that our test environment has the exact same settings and it works fine I can set permissions on any one of the attributes. Live finds the results when I type but does not display them.

Could it be some form of over run/memory issue when too many results are returned to LDAPCP as the only different between our Test and Production is the number of AD users?
Sep 10, 2014 at 11:30 PM
Here are my mappings:
Image
Coordinator
Sep 11, 2014 at 11:27 AM
So custom claim types are set as "FormsRole" (which totally makes sense), so you won't be able to assign permissions on those claim types from central administration (SharePoint design restriction).
But you should definitely be able to find permissions on those claim types from the sites directly.
Did you try with a unique Company/department name (that doesn't match a username)?
Can you take a look at SharePoint logs and filter on LDAPCP area to find how many results are returned?
Sep 12, 2014 at 1:25 AM
Yes I have set a permission on the locality info e.g. office name of Singapore and that works but if I try department of Information Technology I get nothing (it does say showing 1 result but it does not show up). If I look in the logs filtering on LDAPCP all the results I expect to see in the people picker show up.

From the log
[LDAPCP] Added permission created with LDAP lookup: claim value: "Auckland", claim type: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality" to the list of results.
People Picker:
Image

From the log
[LDAPCP] 1 permission(s) to create after filtering
[LDAPCP] Added permission created with LDAP lookup: claim value: "Human Resources", claim type: "http://schemas.#######.###/ws/identity/claims/department" to the list of results.
Image

If you want the full log let me know.
Coordinator
Sep 12, 2014 at 11:33 AM
Interesting, this looks like an issue in SharePoint (LDAPCP really creates the permission as expected, based on the logs).
Do you reproduce with:
  • another browser (Firefox/Chrome)?
  • a new site collection?
Sep 14, 2014 at 10:38 PM
Hi Yvand,

Yes it happens in all site collections and using all browsers. What I cannot figure out is why it works in one environment and not the other. see below for our test system:

Image
Coordinator
Sep 15, 2014 at 11:37 AM
That's very strange indeed, maybe a Fiddler trace would be helpful to figure out if this is a server side issue (permission not sent to browser), or client side (permission sent to browser, but for some reason it doesn't display it).
I keep tinking this is a SharePoint issue (not LDAPCP), based on the logs output, but I can't be sure
Sep 16, 2014 at 1:36 AM
Edited Sep 16, 2014 at 1:37 AM
As you can see below the results are not sent from the server (3 queries tried one for a user one for the locality claim and one for the department). THe one that did not work (department) I have included the request as well.

Search String :Daniel
[{"Key" : "i:0e.t|#### federation services|daniel@#######.biz", "Description" : "userPrincipalName=Daniel@#######.biz", "DisplayText" : "Daniel@#######.biz", "EntityType" : "User", "ProviderDisplayName" : "#### Federation Services", "ProviderName" : "LDAPCP", "IsResolved" : true, "EntityData" : {"DisplayName" : "Daniel"}, "MultipleMatches" : []}]

Search String: Auckland
[{"Key" : "c:0\u003c.t|#### federation services|auckland", "Description" : "physicalDeliveryOfficeName=Auckland", "DisplayText" : "\u0028Office\u0029 Auckland", "EntityType" : "FormsRole", "ProviderDisplayName" : "#### Federation Services", "ProviderName" : "LDAPCP", "IsResolved" : true, "EntityData" : {}, "MultipleMatches" : []}]

Search String: human res
<Request xmlns="http://schemas.microsoft.com/sharepoint/clientquery/2009" SchemaVersion="15.0.0.0" LibraryVersion="15.0.0.0" ApplicationName="Javascript Library"><Actions><StaticMethod TypeId="{de2db963-8bab-4fb4-8a58-611aebc5254b}" Name="ClientPeoplePickerSearchUser" Id="44"><Parameters><Parameter TypeId="{ac9358c6-e9b1-4514-bf6e-106acbfb19ce}"><Property Name="AllowEmailAddresses" Type="Boolean">false</Property><Property Name="AllowMultipleEntities" Type="Boolean">true</Property><Property Name="AllUrlZones" Type="Boolean">false</Property><Property Name="EnabledClaimProviders" Type="Null" /><Property Name="ForceClaims" Type="Boolean">false</Property><Property Name="MaximumEntitySuggestions" Type="Number">30</Property><Property Name="PrincipalSource" Type="Number">15</Property><Property Name="PrincipalType" Type="Number">5</Property><Property Name="QueryString" Type="String">human res</Property><Property Name="Required" Type="Boolean">true</Property><Property Name="SharePointGroupID" Type="Number">0</Property><Property Name="UrlZone" Type="Number">0</Property><Property Name="UrlZoneSpecified" Type="Boolean">false</Property><Property Name="Web" Type="Null" /><Property Name="WebApplicationID" Type="String">{00000000-0000-0000-0000-000000000000}</Property></Parameter></Parameters></StaticMethod></Actions><ObjectPaths /></Request>

Result is empty:
[{}]
Coordinator
Sep 18, 2014 at 1:32 PM
Indeed, the server doesn't send the permission.
To tell you the truth, I don't know how to go further without taking an IDNA trace, which requires deep analysis and I don't have the time for this.
If you have a Microsoft Support contract, you may open a support case to SharePoint dev support team.
I'm sorry I can't help you further, issue is really strange and I never faced it...
Please let me know if you manage to resolve it somehow in the future.
Yvan
Oct 2, 2014 at 10:49 PM
Hi Yvand,

Thanks for that I have opened a ticket with Microsoft however I find it weird that it works for claim types that LDAPCP has by default when installed and only affects claim types that I add manually.
Oct 6, 2014 at 2:24 AM
Edited Nov 12, 2014 at 12:26 AM
Just to keep this thread up to date on progress this looks to be changes from the August CU applied. Still checking and working on it with MS at this stage to confirm the exact cause.

[edit] was not the update both environments are on the latest Cu and the results are the same. Still have a case open with MS.
Dec 5, 2014 at 4:22 AM
Hi Yvand,

We have this solved now finally. After Microsoft said no to supporting it due to using a custom claim provider we removed all ADFS config and created the trusted token issuer and setup LDAPCP again and it is now working.

The last thing to solve is figure out why Active Directory results also show in the people picker after we set the AD claim provider visible status to false.
Marked as answer by Terafirma on 12/4/2014 at 9:26 PM