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