This project has moved. For the latest updates, please go here.

Unexpected error during connection to LDAP server

Oct 23, 2015 at 8:25 PM
I have the strange situation, that the cn and displayname attributes are not returned by the LDAP because of some missing permissions. If I leave the default claim mapping with cn and displayname, then I get no results. If I remove these two on the mapping page then I get this error message:

[LDAPCP] Unexpected error during connection to LDAP server LDAP://contoso.com:389/ou=USERS,ou=GLOBAL,o=Partners,c=com: System.NullReferenceException: Object reference not set to an instance of an object., Callstack: at ldapcp.LDAPCP.<>c__DisplayClass64_0.<SearchObjectsInLDAP>b__1(DirectoryEntry directory)

Both attributes are present in the LDAP, cn is always filled, diplayname sometimes not, but as I mentioned the permissions do not allow to return these two attributes. (they are therefore not in the Novell LDAP answer, not only empty)

Am I missing something, are there any workarounds for this situation?
Coordinator
Oct 26, 2015 at 1:01 PM
Hello,
can you copy the full callstack of the error?
thanks,
Yvan
Oct 27, 2015 at 2:03 PM
There is not much more in the ULS log. Should I change some log levels?

0x3380 Logging Correlation Data xmnv Medium Name=Request (POST:https://contoso.com:443/sites/gw_TEST_HU/_vti_bin/client.svc/ProcessQuery)
0x3380 Authentication Authorization agb9s Medium Non-OAuth request. IsAuthenticated=True, UserIdentityName=0#.w|domain\U322222, ClaimsCount=92
0x19B0 CSOM agw10 Medium Begin CSOM Request ManagedThreadId=78, NativeThreadId=6576
0x19B0 Logging Correlation Data xmnv Medium Site=/sites/gw_TEST_HU
0x19B0 General adelw Medium Culture Not Found 'ui-ui'.
0x19B0 Microfeeds aizmk High serviceHost_RequestExecuting
0x19B0 LDAPCP Core 1337 Medium [LDAPCP] LdapcpConfig PersistedObject changed, refreshing configuration
0x19B0 LDAPCP LDAP Lookup 1337 Medium [LDAPCP] Connect as cn=U322222,ou=users,ou=contoso,c=com to LDAP://ldap.contoso.com:389/ou=USERS,ou=GLOBAL,o=Partners,c=com.
0x19B0 LDAPCP LDAP Lookup 1337 Unexpected [LDAPCP] Unexpected error during connection to LDAP server LDAP://ldap.contoso.com:389/ou=USERS,ou=GLOBAL,o=Partners,c=com: System.NullReferenceException: Object reference not set to an instance of an object., Callstack: at ldapcp.LDAPCP.<>c__DisplayClass64_0.<SearchObjectsInLDAP>b__1(DirectoryEntry directory)
0x19B0 LDAPCP LDAP Lookup 1337 Medium [LDAPCP] Querying of LDAP servers finished in 173ms (current timeout is 10000ms)
0x19B0 LDAPCP LDAP Lookup 1337 Medium [LDAPCP] This LDAP query did not return any result: "(| (&(objectclass=user)(uid=HLW*)) (&(objectclass=user)(mail=HLW*)) (&(objectclass=group)(uid=HLW*)) (&(objectclass=user)(sn=HLW*)) )"
0x19B0 Monitoring b4ly High Leaving Monitored Scope (SPClaimProvider.FillSearch()). Execution Time=204.115956078217
0x19B0 Monitoring b4ly High Leaving Monitored Scope (SPClaimProvider.FillSearch()). Execution Time=4679.80951489645
0x19B0 Monitoring b4ly High Leaving Monitored Scope (SPClaimProviderOperations.SearchAll()). Execution Time=4884.29549006927
0x19B0 Monitoring b4ly High Leaving Monitored Scope (Microsoft.SharePoint.ApplicationPages.ClientPickerQuery.ClientPeoplePickerWebServiceInterface.ClientPeoplePickerSearchUser). Execution Time=4884.85938855357
0x19B0 Microfeeds aizmj High serviceHost_RequestExecuted
0x19B0 CSOM agw11 Medium End CSOM Request. Duration=4893 milliseconds.
0x1394 Micro Trace uls4 Medium Micro Trace Tags: 0 nasq,2 agb9s,1 agw10,6 adelw,0 aizmk,204 b4ly,4679 b4ly,0 b4ly,0 b4ly,0 aizmj,0 agw11
0x1394 Monitoring b4ly Medium Leaving Monitored Scope (Request (POST:https://contoso.com:443/sites/gw_TEST_HU/_vti_bin/client.svc/ProcessQuery)). Execution Time=4898.45057123182
Coordinator
Oct 28, 2015 at 4:03 PM
Edited Oct 28, 2015 at 4:03 PM
Hello,
this is a known issue that will be fixed in the next version, which I hope to release before end of next week.
Thanks,
Yvan
Oct 29, 2015 at 8:37 PM
Edited Nov 6, 2015 at 8:10 PM
Hi Yvan,

I'm happy to test it. It would be interesting to know where the issue was, as the query did arrived on our Novell eDirectrory server.

BR,
Miklos
Nov 6, 2015 at 1:12 PM
Edited Nov 6, 2015 at 8:10 PM
Hi Yvan,

the new version 3.9 fixed the error, I no longer get an exception. I see that the expected amount of results are given back, but in the next line I have "0 permission(s) to create after filtering". Which filter could cause this? I would expect to show all 9 results.
The only filter I see is the default filter with !(objectclass=computer)

[LDAPCP] Connect as cn=U322222,ou=users,ou=contoso,c=com to LDAP://ldap.contoso.com:389/ou=USERS,ou=GLOBAL,o=Partners,c=com.
[LDAPCP] Querying of LDAP servers finished in 90ms (current timeout is 10000ms)
[LDAPCP] Got 9 result(s) from all LDAP server(s) with query "(| (&(objectclass=user)(mail=HLWPR*)) (&(objectclass=user)(uid=HLWPR*)) (&(objectclass=user)(cn=HLWPR*)(!(objectClass=computer))) (&(objectclass=user)(sn=HLWPR*)) )"
[LDAPCP] 0 permission(s) to create after filtering

I have also looked at the peoplepicker, there is no filter active:

PS C:\Users\U322222> $wa = Get-SPWebApplication https://sharepoint.contoso.com
PS C:\Users\U322222> $wa.PeoplePickerSettings

SearchActiveDirectoryDomains : {}
ActiveDirectoryCustomQuery :
ActiveDirectoryCustomFilter :
OnlySearchWithinSiteCollection : False
PeopleEditorOnlyResolveWithinSiteCollection : False
DistributionListSearchDomains : {}
ActiveDirectorySearchTimeout : 00:00:30
NoWindowsAccountsForNonWindowsAuthenticationMode : True
ServiceAccountDirectoryPaths : {}
ReferralChasingOption : None
ActiveDirectoryRestrictIsolatedNameLevel : False
AllowLocalAccount : True
ShowUserInfoListSuggestionsInClaimsMode : True
UpgradedPersistedProperties : {}

Thanks in advance,
Miklos
Coordinator
Nov 9, 2015 at 3:07 PM
Edited Nov 9, 2015 at 3:13 PM
hello,

this is not an issue in LDAP filter since LDAP returns results.
To troubleshoot this behavior 2 things are needed:
  • Your list of claim types mapping with LDAP objects
  • Details of LDAP objects returned by LDAP server with this PowerShell script to run as w3wp account:
# LDAP Filter
$Filter = "(| (&(objectclass=user)(mail=HLWPR*)) (&(objectclass=user)(uid=HLWPR*)) (&(objectclass=user)(cn=HLWPR*)(!(objectClass=computer))) (&(objectclass=user)(sn=HLWPR*)) )"

# LDAP Server Informationen
$ldapServer = "ldap.contoso.com:389"
$ldapBase = "ou=USERS,ou=GLOBAL,o=Partners,c=com"
$ldapUser = "cn=U322222,ou=users,ou=contoso,c=com"
$ldapPassword = "**********"
$ldapAuth = "None"

# Anmelden am LDAP Server
$directoryEntry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$($ldapServer)/$($ldapBase)" , $ldapUser, $ldapPassword, $ldapAuth)

# Sucheanfrage definieren
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $directoryEntry
$objSearcher.PageSize = 1000
$objSearcher.Filter = $Filter
$objSearcher.SearchScope = "Subtree"

$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults)    {$objItem = $objResult.Properties; $objItem}
thanks,
Yvan
Nov 9, 2015 at 4:03 PM
With both w3wp accounts that we use I have run the script, and it returned correct results. To make it simple I have modified the parameter so that only one result is being returned. (Parameter HLWPRNP* )

Claim mapping:
mail    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
uid     http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
cn      linked to identity claim
sn      linked to identity claim

Claim entity type for all four is User. Additional LDAP filter is only used for cn with the default (!(objectClass=computer)).
Setting the LDAP class to bsPartnerAccount (instead of users) has also not helped. Is there perhaps a fix filter for "user"?
Name                           Value                                                                                                                 
----                           -----                                                                                                                 
fullname                       {77 105 107 108 111 115 32 80 97 108 102 105}                                                                         
objectclass                    {bsGACertIdent, inetOrgPerson, organizationalPerson, person, ndsLoginProperties, top, gaAuxUser, gaTrackingInfo, bsPartnerAccount, bsUsers}                                                      
description                    {20150928092438Z#EMAIL_VERIFY|20150928092438Z;MOBILENO_VERIFY|20150928092438Z;REG_STARTED|20150928092438Z;, 2015092...
uid                            {HLWPRNP6}                                                                                                            
groupmembership                {99 110 61 71 76 79 66 65 76 95 83 80 95 65 76 76 85 83 69 82 83 44 111 117 61 83 104 97 114 101 112 111 105 110 11...
mail                           {miklos.palfi@contoso.com}                                                                                              
sn                             {Palfi}                                                                                                               
securityequals                 {99 110 61 71 76 79 66 65 76 95 83 80 95 65 76 76 85 83 69 82 83 44 111 117 61 83 104 97 114 101 112 111 105 110 11...
o                              {Contoso Business Services GmbH}                                                                                         
cn                             {HLWPRNP6}                                                                                                            
givenname                      {Miklos}                                                                                                              
displayname                    {80 97 108 102 105 32 77 105 107 108 111 115}                                                                         
mobile                         {+49 176 9999999}                                                                                                     
telephonenumber                {+49 176 9999999}                                                                                                     

Coordinator
Nov 9, 2015 at 4:26 PM
Edited Nov 9, 2015 at 4:28 PM
Ok, you anticipated my next question :)
Then I still have a few remarks:
  • objectClass "user" definitely exists in LDAP server since it returns results when you build LDAP filter with this class. So why does LDAP not return this class in the result set?
  • with objectClass "bsPartnerAccount", does LDAP also return 1 result (that is filtered out by LDACP)?
Can you test the following:
  • delete both entries "linked to identity claim"
  • confirm objectClass "bsPartnerAccount" is set on both upn and email claim types
    Then check if you still repro and:
  • how many results from LDAP?
  • confirm that it is filtered out by LDAPCP
thanks,
Yvan
Nov 9, 2015 at 4:47 PM
I have no clue why the objectClass is not included in the result set. I have checked it also with an LDAP Browser (Softterra), there it is also not returned, but the LDAP query runs successful.

With the same HLWPRNP* parameter.
[LDAPCP] Got 1 result(s) from all LDAP server(s) with query "(| (&(objectclass=bspartneraccount)(uid=HLWPRNP*)) (&(objectclass=bspartneraccount)(mail=HLWPRNP*)) )"
[LDAPCP] 0 permission(s) to create after filtering
Thanks,
Miklos
Coordinator
Nov 10, 2015 at 2:51 PM
I don't expect it will make a difference, but can you try with objectclass bsUsers ?
thanks,
Yvan
Nov 10, 2015 at 4:23 PM
Yvan, many thanks, it did make a difference! Now we have the results displayed in PeoplePicker.

Only one thing remains. As you can see above some attributes are displayed in clear text, some are displayed as a string of numbers. Those in cleartext are working as expected, we can filter on them, display them. But those with the sting of numbers are not working, if I add them as an attribute to display then I get only "System.Byte[]".
givenname                      {Miklos}                                                                                                              
displayname                    {80 97 108 102 105 32 77 105 107 108 111 115}           
Do you have an idea how to solve this?

Thanks,
Miklos
Nov 11, 2015 at 9:44 AM
Edited Nov 11, 2015 at 10:53 AM
I have found only this
SearchResults forum entry.

We are running SharePoint 2013 on Windows Server 2012 (not yet R2).

With Windows 2008 your test script from above works also well, the attribute values are displayed correctly.
Only on Windows 2012 these values are displayed as "System.Byte[]".

Do you think it is possible to solve this here in the LDAPCP like in the forom entry above? In paralel I have opened a support case at Microsoft.
Nov 11, 2015 at 7:12 PM
Hotfix kb2802148 ("0x8000500C" error when you use ADSI to read data from an OpenLDAP server from Windows 8 or Windows Server 2012) should fix this behaviour, I will test it in the coming days.
Coordinator
Nov 12, 2015 at 2:28 PM
hello Miklos,
I'm happy to know that using bsPartnerAccount works, I'll try to find out why exactly when I find some time :)
I was not aware of this behavior with the System.Byte[], can you please confirm if the kb2802148 fixed the problem once you tested it?
thanks,
Yvan
Dec 4, 2015 at 8:02 AM
Hi Yvan,

I can confirm that the Hotfix kb2802148 fixed the issue where only System.Byte[] was displayed instead of the LDAP attribute value.

Thanks and Regards,
Miklos
Marked as answer by Yvand on 12/4/2015 at 4:55 AM
Coordinator
Dec 4, 2015 at 12:56 PM
Great, thanks for giving the confirmation!
Yvan