Kerberos Constrained Delegation May Require Protocol Transition in Multi-hop Scenarios

This solution document has been fast published as a Knowledge Base article. Click the following link to view the published content on support site: 2005838

You setup several interacting services on a Windows Server system for Kerberos delegation as middle-tier. Therefore you have already a Kerberos double-hop scenario between these services on the middle-tier server before a back-end server resource is accessed. Unconstrained delegation and constrained delegation with protocol transition works, but constrained delegation for Kerberos-only authentication fails. It is connected to the first service instance as front-end with a valid user ticket but on the next service-to-service hop the middle-tier server is not requesting a Kerberos ticket and also not for the back-end server, the authentication fails.

In the constrained delegation setup only the first service instance has the evidence ticket from the caller. Every service is running in its own Logon User ID (LUID) and the evidence ticket cannot be reused between them. An internal loopback optimization prevents requesting a ticket when the SPN for the second service contains the hostname and protocol negotiation is configured. The token is just duplicated for the second service session access. Without a ticket the second service needs Kerberos Protocol Transition to be allowed to request a Kerberos ticket on behalf of the front-end user when accessing the back-end server resource.

If protocol transition is not be an acceptable configuration you have the following options to configure constrained delegation for Kerberos-only authentication:

• Configure the next service instance for Kerberos instead of Negotiate.
• Configure the next service instance for using an alternate Service Principal Name (SPN) different from the host name, i.e. by using a host header.
• Run the services as Local System account or Network Service account. This option is less secure than using a service account.
• Distribute the services to different servers.

For the first two configuration options please consult your application setup guide. As outlined before, the authentication optimization behavior is by explicit Windows design.