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

EventId 8307

Jul 10, 2013 at 11:42 AM
Hi,

First of all thank you for this tool. It really helped us with the non resolving issues you get when using SharePoint 2010 in an ADFS environment.

but on some of our web front-ends we see the following message:

Event ID: 8307
Event Description: An exception occurred in LDAPCP claim provider when calling SPClaimProvider.FillResolveClaim(): Thread was being aborted..

Path: SERVERNAME\Security Token Service
Alert Monitor: Claims Auth Provider Exception Error

Perhaps you can help us resolve this issue?

We have the following server environment:

6 WFE's
3 APP servers
1 SQL Cluster
  1. All servers are hosted in our own data center.
  2. We have setup a site-to-site VPN with our Customers Datacenter
  3. The Domain controller that is configured on LDAPCP is located on the customers site.
Could this be some timing issue?

Rgds,

Redjesh
Coordinator
Jul 10, 2013 at 12:15 PM
hello Redjesh,
thanks for your feedback.
I never saw this error, can you check the SharePoint logs on this server and filter on category "LDAPCP"?
There should be more details about the error.
Which version of LDAPCP are you using ?
cheers,
Yvan
Jul 11, 2013 at 2:25 PM
Hi Yvand,

We are using the SharePoint 2010 version: LDAPCP 2010 v3.0.0.0

I have checked the log files but it seems this message is not occurring every time but I have found it in the ULS Logs:

[LDAPCP] Error during LDAP connection: Thread was being aborted.. Callstack:
at System.DirectoryServices.Interop.UnsafeNativeMethods.IntADsOpenObject(String path, String userName, String password, Int32 flags, Guid& iid, Object& ppObject)
at System.DirectoryServices.Interop.UnsafeNativeMethods.ADsOpenObject(String path, String userName, String password, Int32 flags, Guid& iid, Object& ppObject)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
at ldapcp.LDAPCP.SearchObjectsInLDAP(String filter)

Also we have another question:

We have a test account in our test AD having displayname “Firstname Lastname” and as surname “Lastname”

The LDAPCP / Peoplepicker returns 0 results when querying on “Lastname”

The Uls shows this entry:
[LDAPCP] this LDAP query did not return any result result: "(|(&(objectclass=user) (sAMAccountName=Lastname*))(&(objectclass=user) (mail=Lastname*))(&(objectclass=user) (displayName=Lastname*))(&(objectclass=user) (cn=Lastname*))(&(objectclass=user) (Surname=Lastname*)))"
Coordinator
Jul 15, 2013 at 11:09 AM
hello Redjesh,
the callstack of the error shows that there was an error during the bind to the DC.
The problem is between the System.DirectoryServices API (that probably calls a RPC method) and the DC, LDAPCP is victim of this error.
From the code there is nothing to change, you need to troubleshoot why randomly the bind doesn't work. You should be able to reproduce the same error outside of the claims provider.
Hope it helps.
cheers,
Yvan
Jul 15, 2013 at 11:21 AM
Edited Jul 15, 2013 at 11:21 AM
Hi Yvand,

I think you are right. We have the environment firewalled so that means that alle sharepoint servers are only allowed to communicate to the DC over LDAP port nr. 389 no RPC port is allowed. Perhaps we should open this port as well? Is that what you mean by "probably calls a RPC method?

thnx
Coordinator
Jul 16, 2013 at 11:42 AM
Edited Jul 16, 2013 at 11:42 AM
Hello Redjesh,

actually I did a mistake, there is no RPC call performed during a LDAP search, so the port 389 should be enough for this specific operation.
But depending on your topology SharePoint will likely need additional ports to work properly. Check article http://technet.microsoft.com/en-us/library/cc262834(v=office.14).aspx to get more info.
Regarding your issue, since it is random, sometimes the bind doesn't work with the DC, but it's probably not a configuration issue otherwise it would occur everytime.

I forgot to reply to the question on the Lastname: this is expected because:
  • for performance reasons the wildcard is added after the value typed, so it searches "Lastname*", not "Lastname", which doesn't allow to find a value like 'Firstname Lastname'
  • By default LDAPCP doesn't search attribute "sn" (that contains the lastname).
You can resolve the lastname by adding "sn" LDAP attribute in the claims settings page (choose option "Query user input on this LDAP attribute but create permission with the LDAP attribute associated with the identity claim")

cheers,
Yvan