As you can see, they implemented a
forest trust between their internal network and the DMZ where the DMZ AD trusts the internal AD. Their ADFS-enabled application was not
. It was an
NT token-based application
, so it needed to be protected with the
NT token-based Web Agent
. The application also did Kerberos delegation to a backend SQL server (not shown). They had user accounts in both the internal AD and the DMZ AD which needed access to this application.
The forest trust is utilized by ADFS only when both the Account Partner (their internal AD) and Resource Partner (their DMZ AD) ADFS consoles are configured as follows:
-On the Account Partner:
-On the Resource Partner:
When ADFS is utilizing the forest trust and a user from the internal AD accesses the application, the user SID from the Account Partner AD is now available on the Resource Partner side where the NT token is built. The NT token-based Web Agent builds an NT token local on the web server. Once the NT token is built and used to access the application, ADFS authentication is complete. Next, their application needs to access SQL, so we must
transition to Kerberos
to do delegation to the backend SQL service.
Whenever we need to do Kerberos delegation with Federated WebSSO with Forest Trust it
be configured for
Kerberos Protocol Transition and Constrained Delegation
. If you have read documentation on Kerberos Constrained Delegation, you will remember that cross-forest authentication requires a
forest trust. Having ADFS authentication in the picture does not negate the two-way forest trust requirement.
During this process of delegation, a
ticket is requested and we also need to be able to get a
for the Account Partner domain. Without a two-way trust in place, this TGT request will fail with S_PRINCIPAL_UNKNOWN.
Rather than use the Federated WebSSO with Forest Trust , you have two other options:
Option 1: Create resource accounts in the Resource Partner forest
Create an Alternative UPN suffix in the Resource Partner forest that matches the UPN suffix of the Account Partner forest
Create user accounts in the Resource Partner forest with the same usernames and UPN suffixes as the Account Partner forest
To conclude, the Federated WebSSO with Forest Trust scenario will work just fine with a one-way forest trust when there is no Kerberos delegation involved. As soon as you need to delegate Kerberos with your ADFS-enabled application and you are using Federated WebSSO with Forest Trust, you must be using the NT Token-based Web Agent and you must have a two-way forest trust in place. If a two-way trust will not work for your environment, consider the alternative options described above.