SharePoint 2013: Authentication via BDLC – Known Issues and Workarounds
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.
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
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
- 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
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.
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
- If the secure store is used within BDLC to store the connection string
- If the connection string contains some of the following
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.
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. Make sure that you are using the field types “Windows User Name” and “Windows
Password” for the credential fields (see screenshot below).
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.