Getting “Login failed for user ‘NT AUTHORITYANONYMOUS LOGON’” when browsing External list on a Claims + Kerberos Web Application


Pass through authentication not working for BCS on a WebApplication which is Claims based and using Kerberos.

While you try to access the External List based on User’s Identity  you received the following error

Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’


In this post I will talk about the reason and what are the different workarounds for this issue. I will not be discussing the steps of how to create Web Application in Kerberos or how to set up SPN


For Service Applications which are not claims aware have the ability to utilize claims to windows token service to convert Claims token. At this time BCS does not leverage C2WTS. More details can be found in the following Guide

Workaround 1 – Classic Mode

Use Web Application in Classic Mode

Unfortunately conversion of Claims > Classic is not supported. So you will need to create new web Application migrate all the contents again.

Workaround 2 – Revert to Self (BCS Authentication)

1) By Default Revert to Self is disabled. We will need to run following CMDlets from PowerShell to enable it


#Copy the ID of BCS Service Appliction

$bcs = Get-SPServiceApplication -ID "BCS ServiceApp ID"

$bcs.RevertToSelfAllowed = $true


2) We will need to modify External Content type by using SharePoint designer and have it use BDC Identity


Select BDC Identity under Default and Client TAB and click on OK.

Now it will let all the users browse to the external list.

Note – Whenever end user brows to the external list, it is the BCS AppPool account which is used to pull the data and not the User’s Identity. Please ensure that BCS App Pool have permissions on the database.

Workaround 3 – Impersonate Windows Identity

If you need to use User’s Identity and do not wish to move to Classic mode then we will need to setup Secure Store Service for this.

Secure Store service will help in converting Claims

1) Browse to Manage Service Application > New >Secure Store Service


2) Browse to Secure Store Service Application. If you get the following error

“Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator”


Please ensure Secure Store Service is started in Central Administration

3) Click on Generate New Key and Provide a Pass Phrase


It’s not mandatory to provide your Farm Pass Phrase, this can be different then Farm Pass Phrase which you would have provided while creating the farm.

4) Click on New and provide the details.

Target Application ID can be anything; it’s not required to be same as Service Application Name


5) Click on Next


6) Accept all the default options and click on Next

Provide account which would manage Secure Store Service, this account should also have permissions on BCS Service Application.


7) Now we need configure External Content type to use Secure Store Service

8) Edit External Content type connection properties from SharePoint designer

a. Authentication Mode – Impersonate Windows ID

b. Secure Store Application ID – BCS (This is the value which we provided in Target Application ID in Secure Store Service )


Make these changes in both Default and Client TAB

9) Click OK and Save the changes made in SharePoint Designer.

10) Browse the External list as end user and it will ask you to Authenticate.


Users will need to go through this trouble only once as Secure Store Service needs to store the account details in its database.

11) Click on Continue to this site


12) Provide user credentials and click on OK


13) You will notice that it still did not show you the contents. This is because now we are trying to pull this data as the end user.

If our end user does not have permission on the SQL database then it will give error. This can be confirmed from the SQL Logs

Grant end users permission on the database, minimum would be data reader.

14) Now Authenticate again to the list and this time it should show you the results.


I would like to thank Hiran Salvi for his contribution in finding the resolution.

Comments (20)

  1. sharepoint administrator certification says:

    The given information in this article is very informative

  2. SharePoint Development Training Online says:

    Information was good, I like your post.
    Looking forward for more on this topic."> SharePoint Development Training Online

  3. Jeremy L. says:

    You rock!

  4. Fred B says:

    These might allow users to access the external list but #2, as Matt points out, is not recommended and #3 has its share of problems (passing credentials in clear text over the wire if you don’t have an SSL connection).

    As Jack requested, when you have a double hop (DB not on the same server as the WFE) yes there is a way to pass through credentials (Authentication Mode: User’s Identity) with SPNs and Kerberos delegations. To do this, you need to have a domain service account
    set for the application pool where the BCS application is hosted and then you set delegations against that account. This way you are telling the DB server to recognize the client claim coming through BCS because the service account can vouch for its authenticity.
    The request will complete to the level of permission given at the DB level via an AD group membership or directly.

  5. GB says:

    Excelent tip. I thought "Impersonate Windows ID" on BCS was only to impersonate a given credential, didn’t know it could store and impersonate users credentials to other systems.

  6. Matt says:

    Got the third workaround to work in SP 2010 Enterprise. Since Microsoft recommends against the second workaround in production environments, I’ll stick with the third, even if it’s annoying for users to enter their credentials the first time they access
    the external list.

    quote from Microsoft regarding security at:

    "RevertToSelf is a popular authentication mechanism that is carried over from the last release of SharePoint. Using RevertToSelf means to connect to the external system as the IIS application pool that is servicing the request. For external lists, this means
    the application pool for the content page. For timed workflows, this means the process that runs the workflow. Because the application pool of a SharePoint farm is a very highly privileged account, it is not a recommended security practice to use RevertToSelf
    in deployment environments.

    Enabling RevertToSelf is the same as elevating all SharePoint users who can create or edit BDC models as farm administrators. We recommended that you use use [sic] Secure Store instead if it is available."

    Thanks for the article!

  7. Paresh Panchal says:

    Very Good & Professional method..thanxs

  8. Deiveegam says:

    Thanks !!!!
    its done with Workaround 2 – Revert to Self (BCS Authentication) — sp2010

  9. Roman says:

    Thanks! With workaround 2 I found my solution with SP 2013.

  10. ANGIE says:

    Thanks for workaround 3… 🙂

  11. Alexei says:

    Workarounds 1 and 2 are great when using Sharepoint Foundation 2013. Much obliged!!!

  12. sachin says:

    I did revert to self true in SP 2013 with claims mode but i do not see use bdc identity in SP designer

  13. Bav says:

    Great, exactly what I have searched for a long time…

  14. Sasiradhika1 says:

    Hey Harmeet..I just tried the  workaround 2 and even stopped and started the BDC service from Manage service application right after the changes were made and I am still seeing the Login failed for user 'NT AUTHORITYANONYMOUS LOGON'. Cant think of what am I doing wrong.

  15. Jack says:

    Are there any workarounds to use Kerberos for BDC in SP 2013?

  16. Anonymous says:

    I am using data connection in visual web part, not SPD

  17. Anonymous says:

    Thanks Harmeet, this really helped. Saved my day!

Skip to main content