Consider the following scenario:
- You configure a SharePoint Server 2013 farm to use claims authentication together with the Kerberos network protocol.
- You create a custom web service that runs under IIS on a different server on a nonstandard port. For example, you create http://wcfserver:456/MyService.wcf. This web service IIS site is configured to use Kerberos authentication.
- You create a claims-aware custom web part for SharePoint that calls the web service.
- You set the following service principal names (SPNs) for the MyService app pool account, and then set the SharePoint application pool account to be trusted to delegate to these SPNs:
setspn -A HTTP/wcfserver:456 domain\wcfapppool
setspn -a HTTP/wcfserver.domain.com:456 domain\wcfapppool
- The custom SharePoint code tries to call the WCF service.
System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate'.
There's a known issue in which some Kerberos clients (including the .NET Framework) don't form service principal names correctly. This issue occurs when the client tries to authenticate with Kerberos-enabled web applications that are configured on nondefault ports (ports other than 80 and 443). This occurs because the client does not correctly form the SPN in the TGS request by specifying it without the port number (as displayed in the SPN of the TGS request).
To resolve this issue, create additional SPNs for the WCF service that don't include the port number, and then set the SharePoint application pool account to be trusted to delegate to those SPNs. For example, create the following:
setspn -A HTTP/wcfserver domain\wcfapppool
setspn -a HTTP/wcfserver.domain.com domain\wcfapppool
Article ID: 4019825 - Last Review: 2017 Apr 21 - Revision: 5
Microsoft SharePoint Server 2013