I have a problem with a SharePoint 2010 application that now runs on SharePoint 2013.

The application has been converted and seems to have no problem "from a code" point of view. The problem comes out when the application tries to connect to an external database.

The connection string is stored with Integrated Security = SSPI, anonymous access is disabled.

I have tried many configuration like:

  • Kerberos
  • NTLM
  • Impersonation
  • All the possible disposition of the configuration

The Application Pool runs with a technical account that is trusted on the environment.

When I run my application I receive an exception like:

Login failed for user "NT AUTHORITY\ANONYMOUS LOGON" at System.Data.SqlClient.SqlInternal...

How can this be possible? I'm correcly signed in in SharePoint, I have the claim service enabled and all the users are part of the Active Directory domain.

Is there any other configuration I don't know?

1 Answer 1


Sounds like the old double-hop problem. In order to let the current user "impersonate" the technical account, you should configure a service that lets you manage the kerberos tokens, it is called C2WTS.


But, if you using BCS you cannot use it; and anyway, it's better to leave it alone: it needs to run under a god-like account.

I hope you could try some of the workarounds listed here


Also, check the "kerberos delegation" topic.

Probably the solution is to use C2WTS with a WCF proxy between it and SharePoint, like this example:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.