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!

Comments are closed.

Skip to main content