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

Support for Windows Server 2003 ended on July 14, 2015

Microsoft ended support for Windows Server 2003 on July 14, 2015. This change has affected your software updates and security options. Learn what this means for you and how to stay protected.

This article has been archived. It is offered "as is" and will no longer be updated.
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.
More Information
For the first two configuration options please consult your application setup guide. As outlined before, the authentication optimization behavior is by explicit Windows design.
Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Article ID: 2005838 - Last Review: 12/12/2015 05:18:45 - Revision: 5.0

Microsoft Windows Server 2003 Service Pack 2, Windows Server 2008 Enterprise, Windows Server 2008 Standard, Microsoft Windows Server 2003 R2 Standard x64 Edition, Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)

  • kbnosurvey kbarchive KB2005838