ADFS – Federated WebSSO with Forest Trust Scenario and its Limitations

Hi, it's Adam Conkle again. Today I’d like to talk about an ADFS case I had recently where the customer ran into some limitations with their Federated WebSSO with Forest Trust setup. They had their environment set up similar to what is described in the TechNet design article:

As you can see, they implemented a one-way forest trust between their internal network and the DMZ where the DMZ AD trusts the internal AD. Their ADFS-enabled application was not claims-aware. 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 must 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 two-way forest trust. Having ADFS authentication in the picture does not negate the two-way forest trust requirement.

During this process of delegation, a S4U2SELF ticket is requested and we also need to be able to get a TGT 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
• Set your Resource Account option in the ADFS console:

Disadvantage of using this option: High administrative overhead of managing the resource accounts.

Option 2: Create a group-to-UPN mapping for the Account Partner users

• Create a group claim for the Account Partner users
• Create a single resource account on the Resource Partner
• Map that group claim to the UPN of the resource account you created:
  • Open ADFS.msc on the Resource Partner
  • Expand Account Partners and select the appropriate Account Partner
  • In the right pane, select the UPN Identity Claim, right-click, Properties
  • Select the Groups tab and configure an Organizational Claim to map to a user account

Disadvantage of using this option: The identity of individual users is lost. All users from the Account Partner are authenticated to the application with the UPN of the single resource account.

For more information about resource account mapping methods, check out this TechNet Article:
https://technet.microsoft.com/en-us/library/cc779214(WS.10).aspx

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.

Take care,

Adam “I wish I had cooler t-shirts” Conkle

Comments

• Anonymous
  December 09, 2015
  We've got a setup with 2 forests (A & B), a two-way trust between the forests but one-way selective from B to A. For users in B to be able to authenticate the extra privilidge of "allowed to authenticate" is granted on some servers in forest A for users residing in forest B. The ADFS service is implemented in forest A. By granting the "allow to authenticate" to the ADFS servers and proxies the users can authenticate on ADFS but it seems no claims are granted to the users residing in forest B. Users in forest A can log on and get a claim.
  
  We want user of forest B to be able to use de ADFS service as well. What am I overlooking?