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:
|
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/<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 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
|
|
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
|
