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

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.

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.

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.