Authentication via BDLC for SharePoinrt 2013

The Layer2 Business Data List Connector for SharePoint (BDLC) solves many issues that still exist with Microsoft SharePoint out-of-the-box external data integration. It makes it as easy as possible to connect native SharePoint lists to almost any external data source, codeless and bi-directional. All SharePoint list features are available for the connected list. The following FAQ is about BDLC authentication options using SharePoint 2013.

SharePoint 2013: Authentication via BDLC – Known Issues and Workarounds

General Information

While classic authentication in Microsoft SharePoint Server 2010 (domain-based NTLM) is no challenge for the Layer2 Business Data List Connector (BDLC), the change to claims-based authentication in SharePoint 2013 and 2010 requires a completely different handling of authentications by BDLC.

In on-premises environments, there are three different authentication tokens:

  • The SharePoint user token which represents the currently logged on user inside of SharePoint,
  • the affiliated Windows user token, 
  • and the Claims token.

In classic authentication, the Windows user identity is always the token of the current SharePoint user.
A typical behavior in Claims is that the Windows identity is impersonated to an anonymous user account (NT Authority\IUSR or NT Authority\Anonymous Logon) as follows.

  • SharePoint user: Mydomain\MyLogin
  • Windows Identity: NT Authority\IUSR  
  • Claims token: 0#.w|Mydomain\MyLogin

The BDLC, now as server software, performs several actions in the context of the Windows identity. In detail, these are:

  • Data access to an external database
  • When certain sub providers are instantiated (e.g. the ACE Provider inside an OleDB Provider)
  • The licensing process and the access to the license file of BDLC located in the BDLC feature directory

If a data connection uses integrated security (depending on data provider), the access to the data source is therefore performed as the affiliated Windows identity, which is impersonated to anonymous. Without any adjustments from BDLC, this will fail.

Note: Do not give the IUSR account permissions to access your data source as this would be a severe security risk!

The BDLC has had impersonation handling implemented since version 6. With the given claims account, we’re able to impersonate to the original Windows account in the most cases (there are exceptions which will be explained later). BDLC uses for impersonation the "Claims to Windows Token Service" of SharePoint, so this service has to be activated in every claims-based environment with BDLC.

How to Enable Claims to Windows Token Service
Start the “Claims to Windows Token Service” from Central Administration -> Services on Server. This change will affect your SharePoint application immediately, no IIS reset or application pool recycling necessary. You need to have full farm administrator’s permission to do so.
 
SharePoint-Claims-to-Windows-Token-Service-Layer2.jpg
 
Fig.: Start Claims to Windows Token Service in the services section of the SharePoint CA.
 
Please also refer to this Microsoft KB article for more: http://support.microsoft.com/kb/2512597. Activating this service for the first time will place a configuration entry in a special config file of this service. This file c2wtshost.exe.config is located in C:\Program Files\Windows Identity Foundation\v3.5. The node <allowedCallers> will be extended with an entry for your SharePoint account, normally this is the WSS_WPG group. Per default, you will not need to make any changes to this file.

Once the service is up and running, BDLC will impersonate in certain cases back to the Windows token (similar to non-claims based configuration):
  • If the secure store is used within BDLC to store the connection string (advised)
  • If the connection string contains some of the following keywords:

    o Integrated Security
    o Trusted_Connection
    o IntegratedWindows
    o Securestore
    o Microsoft.Ace.OleDb
 
Exceptions:
There are two scenarios that will behave in other ways.
 
1. Background Update
The background update is triggered by the SharePoint timer service and runs under the account of this service. In most cases, this is an account with elevated rights. The token table looks like this:
  • SharePoint user: SystemAccount 
  • Windows identity: mydomain\myserviceaccount 
  • Claims token: <empty>

Any impersonation from Claims will have no effect due to the absence of a Claims token. So remember to give permissions to external data sources to the timer service account as well.

 
2. Write Back
When performing a write back operation on a list, BDLC steps in immediately after the user hits “OK” in the so called synchronous event handling of SharePoint (“ItemAdding”, “ItemUpdating” or “ItemDeleting” events). Inside this event, the token table looks like this:
  • SharePoint user: Mydomain\MyLogin 
  • Windows identity: Mydomain\myApplicationPoolAccount 
  • Claims token: <empty>

Again, there is no Claims token and BDLC is unable to impersonate to a proper Windows identity affiliated with the user that triggered this update. The only available token is that of the application pool account.

This affects several scenarios with BDLC:

  • Using Integrated Security, the current SharePoint user is ignored and BDLC will access the data source in the context of the application pool.
  • Using secure store, you have to give user permissions to the secure store application as well as to the application pool account. Otherwise, BDLC is unable to find and access the given secure store application.
1. Using Integrated Security

Using integrated security, we have some Windows network security related limitations that need to be considered known as "Double Hop Issue".

Please find out more here: https://www.google.de/#q=double+hop+issue).
In case your data source does not run directly on the SharePoint server (e.g. runs as separate SQL Server) you will end up with an error message in BDLC saying that the access for anonymous user (NT Authority\IUSR or likewise) is denied. Even if you are directly on your SharePoint server, this will be the case because the authentication from your browser client to IIS will use up the first hop (see details here: http://weblogs.asp.net/owscott/iis-windows-authentication-and-the-double-hop-issue).

In this case you can use SQL user logins (when using a SQL server as data source and this is supported by settings), or to provide specific user credentials (for other data sources) within your connection string.
If you cannot give user credentials to your data source, BDLC has a workaround with its ability to make use of the SharePoint Secure Store Service and to avoid the use of credentials in the BDLC settings page. With this option, you could set up an integrated security login with one given Active Directory (AD) user that will be used by BDLC as an impersonation target. All actions against the data source will take place within the context of this given user.
 
2. Using Secure Store
 
Please follow the instructions on our website to set up a Secure Store application for BDLC usage (http://www.layer2solutions.com/en/community/FAQs/BDLC/Pages/SharePoint-External-Data-Secure-Store.aspx ). Make sure that you are using the field types “Windows User Name” and “Windows Password” for the credential fields (see screenshot below).
 
SharePoint-Edit-Secure-Store-Target-Application-Layer2.jpg
 
Enable an AD account to log in to your SQL server and store its credentials in the Secure Store. The connection string should provide the “Integrated Security=true” phrase (or “Trusted_Connection=true”). When you set the BDLC connection to use this Secure Store application, BDLC will be able to use Integrated Security with this given user. Please note that it is not possible to deliver the current users token to your data source.

Helpful Topics

How to Get the Application Pool Account?

In Central Administration, select Security -> Configure service accounts. Select your SharePoint web starting with “Web Application Pool”. The connected pool account can be displayed as shown below.

 

SharePoint-Get-Application-Pool-Account-Layer2.jpg
 

 

Layer2 BDLC Authentication Summary for SharePoint 2013

​To successfully authenticate your external data source using integrated authentication in a claims-based SharePoint environment, the Claims to Windows Token Service should be up and running. You have to use the SharePoint Secure Store. Following this best practice, you can use integrated authentication as supported by your data sources without any issues and security risks.
Share this site on Xing
Share this site on Google+
Share this site on LinkedIn

The software allows you to couple SharePoint's flexible presentation capabilities with a relational databases' correlation and extraction mechanism. The folks there are very helpful and responsive to questions.

Related Contacts
Frank Daske

Frank Daske

Business Development Manager
+49 (0) 40 28 41 12 - 30
[email protected]

Please note that the 011 exit code must be dialed first for all international calls made from the USA, Canada and Australia.

Related News

SharePoint 2016 Data Integration

The Layer2 Business Data List Connector (BDLC) closes many gaps that still exists with Microsoft SharePoint 2016 out-of-the-box external data integration via Business Connectivity Services (BCS).

Layer2 Business Data List Connector V7 Released to Close Gaps with SharePoint External Data Integration

​Layer2 has announced version 7 of their top-rated Business Data List Connector (BDLC) that connects 100+ external data sources with SharePoint lists codeless and closes many gaps that still exist with out-of-the-box SharePoint external data integration.
Related Downloads
NoDoc Image

Business Data List Connector PAD File

This XML-based PAD file offers a product description for resellers to download and publish.
PDF Image

Customer Solution Case Study: WealthVest Marketing Benefits From SharePoint Data Integration Using Layer2 Business Data List Connector

"By using the Layer2 Business Data List Connector for SharePoint app we can provide native SharePoint lists as a simple, easy-to-use, and familiar interface to manage mission critical business data."
PDF Image

Flyer: Layer2 Partner Program

Partner with us as a software distributer, reseller or SharePoint, Office 365 or Azure service provider. We are offering a free Partner Program with up to 30% Discount, free NFR licenses etc. Please download for more.
PDF Image

How to connect ANY external data source directly to native SharePoint lists?

Download this step-by-step introduction to the Layer2 Business Data List Connector (BDLC) for SharePoint.
PDF Image

How to integrate SAP data with SharePoint via NetWeaver & OData

You simply have to enter an URL to the data collection to integrate and sync SAP data with native SharePoint lists.
PDF Image

Product Flyer: Business Data List Connector for SharePoint

SharePoint on-premises external data integration with 100+ sources: Product flyer (PDF) in English for download.
PDF Image

Testimonial: How the US Defense Contract Management Agency (DCMA) integrates SharePoint with Oracle using BDLC

"Layer2 Business Data List Connector (BDLC) software provides a powerful mechanism for surfacing external data through lists, and drastically improves platform stability and development cycles."
Related Links

Are you looking for partners in your region?

Please find a local partner here.

Layer2 BDLC for SharePoint Community Group @ LinkedIn

​Are you already @ LinkedIn? Please join our group to share your experience.

Purchase Layer2 Business Data List Connector via ComponentSource

​ComponentSource has offices in the USA, UK and Japan supporting over 125,000+ Customers, in over 180 Countries. They are also an approved Federal Government supplier through the GSA Schedule.
 
cs-award-top-100-publisher-2014-15-large.gif

Sign Up for Layer2 Product Newsletter

We keep you up-to-date about new Layer2 product releases, added features and fixed issues.