KCD scenarios supported by Windows Server 2012 R2 and Windows Server 2016

Applies to: Windows Server 2012 FoundationWindows Server 2012 DatacenterWindows Server 2012 Standard More

Symptoms


Consider the following scenario:

  • Forest A is a user forest that contains user accounts, a server that is running Internet Information Services (IIS), and an ADFS server.
  • Forest B is a Perimeter Network forest (also known as DMZ, demilitarized zone, and screened subnet) that contains a Windows Application Proxy (WAP) server.
  • All domain controllers are running Windows Server 2012 R2.
  • Two-way forest trust is built between Forest A and Forest B.
  • Both the Web Application Proxy (WAP) and IIS services are running under a Network Service account.
  • You have configured Kerberos constrained delegation (KCD), and set the PrincipalsAllowedToDelegateTo value on the IIS machine account to the WAP server machine object. For more information, see Kerberos Constrained Delegation Overview.
  • A user in Forest A want to authenticate to the WAP server in forest B.
  • WAP authentication is handled by ADFS in ADATUM, and a token that has a UPN claim is returned to the WAP server. The WAP server uses the token to use KCD to access the server that's running IIS.
In this scenario, the authentication fails, and the following Kerberos error entry is revealed in a Network trace on the WAP server:
WAP ---> rootdc1.adatum.com KerberosV5:TGS Request Realm: ADATUM.COM Sname: http/iis.adatum.com {TCP:232, IPv4:220} rootdc1.adatum.com ---> WAP KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_POLICY (12) {TCP:232, IPv4:220}

 

More information


This behavior is by design. The following table indicates the support for Kerberos constrained delegation (KCD) scenarios in Windows Server 2012 R2 and Windows Server 2016.

Client forest to services forest Supported
Client or front-end forest to back-end forest Supported
Client or back-end forest to front-end forest Not supported
Client forest to front-end forest to back-end forest Not supported


This support matrix can be summarized as follows:

  • A delegating server can delegate to a target resource outside its own forest for identities from its own forest.
  • A delegating server can delegate to a target resource inside its own forest for identities in its own forest and from other trusted forests.
  • A delegating server can't delegate to a target resource outside its own forest for identities outside its forest.

In these scenarios, the user and the WAP server must be located in the same forest. Or, the server that's running IIS and the WAP must be located in the same forest.