SharePoint 2013: Authentication via BDLC – Known Issues and Workarounds

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.

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.

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. 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.

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. 

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.

READY TO GO NEXT STEPS?