LDAPCP - SharePoint 2013 - No results

Mar 5, 2013 at 5:28 PM
Edited Mar 5, 2013 at 5:29 PM
First off, this is an excellent solution and one that we are excited about. Unfortunately, we've run into an issue with our solution. We are using a clean 3-node install (2 WFEs, 1 CA/App Server) of SharePoint 2013 and installed/trusted the solution based on documentation. Our problem is sometimes it works, others it doesn't. When it doesn't we get the generic:

Sorry, we're having trouble reaching the server.

An extract of the ULS logs when looking for a user with the string "hair" (we get tons of results/returns but I'm omitting those for ease of reading):
  • 03/05/2013 13:11:05.68 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Connect to AD this server is member of, with application pool credentials cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.86 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope ([LDAPCP] Sending LDAP query to server). Execution Time=114198.909637957 cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.87 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] The LDAP Query "(|(&(objectclass=user) (mail=hair))(&(objectclass=user) (userPrincipalName=hair))(&(objectclass=user) (givenName=hair))(&(objectclass=group) (sAMAccountName=hair))(&(objectclass=user) (displayName=hair))(&(objectclass=user) (cn=hair)))" returned 71 result(s) cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.92 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Create PickerEntity: Claim type: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, value: P-BCS-CCJ Chair-Modify cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.92 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Create PickerEntity: Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, value: lchaire@xyz.com cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.92 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Create PickerEntity: Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, value: lchaire@xyz.com cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.92 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Create PickerEntity: Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, value: hair@xyz.com cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.92 w3wp.exe (0x0320) 0x16D8 Unknown LDAPCP 00000 Medium [LDAPCP] Create PickerEntity: Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, value: hair@xyz.com cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.95 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Monitoring nass High [Forced due to logging gap, cached @ 03/05/2013 13:12:59.86, Original Level: Verbose] ____{0}={1} cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.95 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (SPClaimProvider.FillSearch()). Execution Time=114335.745325174 cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:12:59.98 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (SPClaimProviderOperations.SearchAll()). Execution Time=114451.052228705 cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.03 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Claims Authentication ajau6 High [Forced due to logging gap, cached @ 03/05/2013 13:13:00.03, Original Level: Verbose] SPSecurityTokenServiceManager!GetProviderByName: Returning Trusted Login Provider for input {0} cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.03 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Claims Authentication ajau6 High [Forced due to logging gap, Original Level: Verbose] SPSecurityTokenServiceManager!GetProviderByName: Returning Trusted Login Provider for input {0} cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.04 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (Microsoft.SharePoint.ApplicationPages.ClientPickerQuery.ClientPeoplePickerWebServiceInterface.ClientPeoplePickerSearchUser). Execution Time=115387.327299978 cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.11 w3wp.exe (0x0320) 0x16D8 0x6FB704F agw13 High [Forced due to logging gap, cached @ 03/05/2013 13:13:00.04, Original Level: Verbose] Leaving Microsoft.SharePoint.ApplicationPages.ClientPickerQuery.ClientPeoplePickerWebServiceInterface.ClientPeoplePickerSearchUser cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.11 w3wp.exe (0x0320) 0x16D8 SharePoint Portal Server Microfeeds aizmj High serviceHost_RequestExecuted cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.17 w3wp.exe (0x0320) 0x16D8 0xC33B004 aiyhu High [Forced due to logging gap, cached @ 03/05/2013 13:13:00.13, Original Level: Verbose] End: TaxonomyCsomProcessingHandler.ClientServiceHost_RequestExecuted cade049c-9c2a-9064-b7b1-5f986bc38f8d
  • 03/05/2013 13:13:00.17 w3wp.exe (0x0320) 0x16D8 SharePoint Foundation CSOM agw11 Medium End CSOM Request. Duration=117744 milliseconds. cade049c-9c2a-9064-b7b1-5f986bc38f8d
In this example, the claim we're looking for is (UPN) hair@xyz.com which shows up in the ULS listing above but we still get no return/selection on the People Picker/Share link. The weird thing is it works randomly. Any help would be greatly appreciated.

Thanks,

Roger
Coordinator
Mar 6, 2013 at 9:30 AM
hello Roger,
First many thanks for your great feedback.
I will help you to troubleshoot your issue.
Can you confirm the extract above is recorded even when nothing is returned in the people picker?
What version of LDAPCP do you use (please check the properties of the dll)?
I can add additional logging in the tool, for example when the permission (which is a PickerEntity object) is actually added to the people picker list, but if no error is recorded in the log, I have no idea why nothing shows in the people picker.
cheers,
Yvan
Mar 6, 2013 at 12:36 PM
Perhaps you should force the domain controller queried by the claim provider and see if you are not bumping between one working domain and one that is not
Mar 6, 2013 at 7:01 PM
Yvand,

Thanks for the follow-up. I can confirm that any/all queries that have an entry does actually show up in the logs regardless of them showing in People Picker (as I said, sometimes the values show up in PP, other times, we get the message). We are currently running LDAPCP v1.3.0.0, I didn't retract/reinstall but did and update with:
  • Update-SPSolution -Identity ldapcp.wsp -LiteralPath "D:\LDAPCP\v1.3.0.0\LDAPCP.wsp" -GACDeployment
I'm not sure where to find the DLL to check the version (assuming it's installed in the GAC on 2013). Searching for it in the GAC via the command line shows it living in the C:\Windows\assembly\temp\NJ9LFK3N64\, which seems odd but I'm not sure if that's what you need me to check.

r3dLiN3,

We've tried targeting any of our DCs directly and this appears to be hit or miss based on our environment (we have over 10 and our user base in AD is over 25K).


After looking at this with some of our AD experts, what we've found is that LDAPCP build the LDAP query as wildcards:
 (|(&(objectclass=user) (mail=*cakin*))(&(objectclass=user) ......
The "*" at the front of our query forces AD to not use it's index on the field so we're searching across all our records. This was confirmed with running LDP and just making an LDAP call from the SharePoint WFE node with the following:

50+ Second Query
 (|(&(objectclass=user) (mail=*cakin*))(&(objectclass=user) ......
1-3 Second Query
 (|(&(objectclass=user) (mail=cakin*))(&(objectclass=user) ......
At this point, we're wondering if we need to modify Yvand's great code to not do a wildcard in front of the user input and/or possibly isolate a DC to solely be used for querying against SharePoint 2013. Any thoughts or ideas?

Thanks,

Roger
Coordinator
Mar 7, 2013 at 1:37 PM
hello Roger,

In .NET 4.5 the GAC is in a new location: C:\Windows\Microsoft.NET\assembly

The performance impact that you mentioned with the wildcard is very interesting, to be honest I was not aware of this.
So I'm implementing an option to not use the wildcard in front of the keyword. It will be available in the admin page and developers can also change it in the inherited classes.

I'm also reviewing the logging to add a message when the permission is actually added to the list of permissions displayed in the people picker, that should help you to troubleshoot the issue.

For your information, the next version also adds possibility to:
  • define a keyword to resolve an input without searching in LDAP. For example, user types EXT:joe@contoso.com => LDAPCP automatically creates permission for "joe@contoso.com"
  • specify a prefix that will be added to each permission: for example LDAP query returns "groupName" => LDAPCP will create permission like "DOMAINNAME\groupName"
All of those features are already implemented and I'm currently testing and optimizing them.
I hope to release the new version before the end of the month.

cheers,
Yvan
Mar 8, 2013 at 3:27 PM
Yvand,

Thanks for the info on the GAC library location...much easier than before with the hidden folder structure within Windows. Having said that, the Product Version I have for the LDAPCP.dll is 1.3.0.0.

Also, your added features will be most welcoming and would greatly improve the functionality of the tool to leverage AD's indexing features. I look forward to trying it out.

Thanks,

Roger
Coordinator
Mar 19, 2013 at 8:46 AM
Edited Mar 19, 2013 at 8:46 AM
hello,
yesterday I released an update that addresses the performance issue discussed here: now by default LDAP lookup does not contain wildcard anymore at beginning, but it can be changed in admin page.
It also introduces a lot of new customization capabilities for the developers and I added a new sample class "CustomClaimTypeLookup" in developer package that describe them.
Please carefully follow procedure in homepage to update correctly.
And feel free to give me your comments :)
cheers,
Yvan
Apr 16, 2013 at 3:29 PM
Yvan,

Sorry for the late response (other responsibilities pulled me onto different projects). The new version speeds up the performance substantially and it's running great in our large environment. I have a question regarding the keyword and prefix functionality you suggested, is it part of the CustomClaimTypeLookup or something you've yet to implement within the GUI management portion of your tool.

Finally, this request might be in our config vs. your tool we're looking to control/restrict what comes back in the search query. We've configured the STS provider in SharePoint 2013 to use the following claim types:
In our search results, we return any/all matching values of the above claim types. What we'd like to do is restrict the returned values to only 2 claim types (UPN and Role). Essentially we'd like to instruct our users to search for either the LDAP group or the UPN (we make UPN = email) when they want to share content. This simplifies the necessary training and/or confusion on entries that show up in the Share/People Picker pop-up (right now they see UPN, email, given name, etc.). One suggestion is to only receive those types via the STS configuration but we'd like to have those values accessible in SharePoint for other reasons, we just don't want them in the searches. Any suggestions?

Thanks,

Roger
Coordinator
Apr 17, 2013 at 12:21 PM
Hello Roger,
no worries, and thanks for the feedback!
As of now, the keyword and prefix functionalities are only available through a custom version of LDAPCP (I added sample CustomClaimTypeLookup to show how to do it), but I'm considering to make those settings available through admin page.
It's definitely possible to restrict claim types returned to UPN and Role using a customized version of LDAPCP.
All you need to do override PopulateAttributesDefinition method to define your table of AttributeHelper objects that will contain only the Role and the UPN (I assume the identity claim type is the UPN otherwise you must add it too).
cheers,
Yvan