Double Hop Issue in SharePoint and Custom Web Service

Background and Problem Statement

During development of a project with a client, we encounter double hope issue. We have a custom web-service hosted on a separate server. Web- Service authentication mechanism was set to windows (NTLM) authentication. From the web-service we creating and updating list items in one of SharePoint list.

But the problem was list item was inserting/updating with app pool user of web-service, not with current logged-in user. After research we found that this is double hop issue and we need to configure Karbrose authentication instead of NTLM.

Below diagram illustrates the architecture of the project:

IIS Configuration	Dw Web Server	Dw SharePoint Server
App Pool Identity	Domain\user1	Domain\user1
Windows Authentication	Yes NTLM	Yes NTLM
ASP.Net Impersonation	No	No
Anonymous Access	No	Yes
User Kernel Mode	No	No
App pool user trust for Delegation	No	No

With these above settings, when user was trying to insert/update some item in SharePoint list from client application, web server was not passing authentication token of currently logged-in to SharePoint because due to security reasons. Instead Web Server was passing App Pool Identity user credentials to SharePoint server. 

SharePoint server return unauthorized because It is not possible by design. It is called double-hop.

The first hop is when user hit web service and the second hop is when web service send request to SharePoint server. Windows is preventing double hop by design. To solve that we need Kerberos implementation.

Solution 

To solve the double hop issue, we have to use Kerbrose authentication. Below are the steps to configure Kerbros authentication and solve double hop issue.

Step 1: Start IIS Manager on your Web server, select the website and go to the Authentication section. Disable anonymous authentication and enable Windows Authentication

Step 2: Open the list of providers, available for Windows authentication (Providers). By default, two providers are available: Negotiate and NTLM. Negotiate is a container that uses Kerberos as the first authentication method, and if the authentication fails, NTLM is used. It is required that Negotiate comes first in the list of providers.

Step 3: Go to Advance Setting and unckeck “Enable Keneral-mode Authentication”.

Step 4: The next step includes the registration of Service Principal Name (SPN) entries for the name of the website, which will be accessed by the users.

Run setspn against the service account user used as App Pool user in DW Web Service.

setspn -u -s HTTP/<Web Service HOST Header> <Domain\User>

setspn -u -s HTTP/<FQDN> <Domain\User>

setspn -u -s HTTP/<SharePoint HOST Header> <Domain\User>

setspn -u -s HTTP/<FQDN> <Domain\User>

For example, below are the values:

Domain Name	Utest.org
DW Web Service Host Header	mywebservice
DW Web Service FQDN	mywebservice.utest.org
DW Web Service Host Header	mysharepoint
DW Web Service FQDN	mysharepoint.utest.org
App Pool User	Utest\iis_user

In above case setspn commands will be as follow:

setspn -u -s HTTP/mywebservice UTEST\ iis_user

setspn -u -s HTTP/mywebservice.utest.org UTEST\iis_user

setspn -u -s HTTP/mysharepoint UTEST\ iis_user

setspn -u -s HTTP/mysharepoint.utest.org UTEST\ iis_user

Step 5: Then go to web-service in IIS Manager and select Configuration Editor.

In the dropdown menu select system.webServer > security > authentication > windowsAuthentication

Step 6: Allow delegation for the UTEST\ iis_user so it can delegate the user authentication token from DW Web Service to SharePoint Server.

Go to Active directory, select app pool user, go to delegation tab and select, “Trust this user for delegation to specified service only”.

So the final changes will be as below:

IIS Configuration	Dw Web Server	Dw SharePoint Server
App Pool Identity	Domain\user1	Domain\user1
Windows Authentication	Yes Negotiate NTLM	Yes Negotiate (Optional) NTLM
ASP.Net Impersonation	Yes	Yes
Anonymous Access	No	No
User Kernel Mode	No	No
Use App Pool Identity	Yes	No
App pool user trust for Delegation	Yes	No

Step 7: Restart IIS on all servers. Now DW web service will be authenticated using Kerbrose and you wouldn’t encounter 401 unauthorized