AD FS 2.0 and One-Way Cross-Forest Trusts

So you want to make some of your applications available using federation but you have multiple forests. What can you do? Well, if you have two-way trusts between your forests, you’re in luck, because AD FS works very well if you have two-way trusts between the forests. But what if you have only a one-way trust between forests? Then what?

For this scenario, we will assume that you want to provide SSO to multiple applications for users from two different forests. The applications may reside in one or the other of the forests or may be cloud-based (and thus in neither forest).

With a two-way trust in place between your AD forests and your AD FS server in forest “A,” AD FS is able to provide authentication for all the users from both forests and query AD for their attributes using the two-way trust. See figure 1. All users will be able to use federation to log-on to the federated applications.

But wait, what if the users in one of the forests are actually partner or customer accounts and the forest is not fully trusted, so we just have a one-way trust? If the AD FS server is joined to the partner forest, then partner users can authenticate to AD FS and AD FS can query the partners AD for their attributes. In addition, internal users from the employee forest can authenticate to AD FS across the one-way trust. Oh, but wait, we have a problem. In this scenario, AD FS cannot query the employee forest for user attributes because the service account under which AD FS runs in the partner forest has no permissions to query AD in the employee forest. Authentication works, but AD FS cannot provide additional information to populate claims, so federated logon will fail for most applications. See figure 2.

You may be thinking that the answer to this dilemma is to place the AD FS server in the employee forest, but that presents its own set of issues. Placing the AD FS server in the employee forest would allow internal users from the employee forest to authenticate to AD FS and would allow AD FS to query the employee forest for user attributes, but users from the partner forest would be left out in the cold. They would not be able to authenticate to AD FS because the direction of the trust means that the applications in the employee forest don’t trust users from the partner forest. Attempts to logon to federated applications for partner users would fail before they had barely begun.

There are at least three options for resolving this dilemma:

1. Restrict yourself to only using certain attributes.
2. Set up an AD FS server for each forest.
3. Put the AD FS server in the partner forest but run it under an account in the employee forest.

It turns out that with a one-way trust you can actually get some attributes for the user. So as long as you only attempt to use the attributes that are provided in a one-way trust scenario, you can use a one-way trust to authenticate the user and create the federation claims.

The attributes that are available include:

• Name – in the form DOMAIN\sAMAccountName
• Windowsaccountname – in the form DOMAIN\sAMAccountName
• Primarygroupsid –in the form of a Security ID (SID) such as S-1-5-19
• Groupsid – a list of group SIDs that the user is a member of, for example S-1-1-0, S-1-5-11

From a basic functionality perspective, option 2 works well. Using this design, partner users can authenticate to the partner AD and the partner AD FS can query AD for their attributes; the same is true for employees and the employee forest. However, in this case in addition to the need for twice as many AD FS servers, the home realm discovery problem rears its ugly head. See figure 3.

The basic stumbling block with this option is that if a user attempts to access internal web application 1 (see figure 3), that application doesn’t know if it should send the user to be authenticated at the AD FS server for the partner or employee forest. There are various approaches to addressing this but it can be a very difficult problem to solve. Out of the box, AD FS will prompt the user to choose which organization or realm they should be sent to (for example Employee or Partner). See figure 4.

Now let’s look at option 3—the AD FS server resides in the partner forest operating under a service account from the employee forest. This design has the basics covered. Users from the partner forest can authenticate to the partner AD and AD FS can query the partner AD for the user’s attributes because the one-way AD trust allows users from the employee forest to do AD lookups in the partner forest. Users from the employee forest can authenticate to the employee AD and AD FS can query the employee AD for the user’s attributes because the service account for AD FS is a member of the employee forest.

Because there is only one AD FS server in this scenario, there is no home realm discovery problem. Internal applications will not need to prompt users to identify which AD FS server should be used for their authentication, simplifying the user experience. And, as an added bonus, you only need half as many servers as that required for option 2. See figure 5.

Lest you be thinking that this option is the bee’s knees for all multi-forest unidirectional trust AD FS scenarios, be aware that it doesn’t work if there are more than two forests that don’t trust one another. AD FS can only run as one service account, so there can only be one untrusted connection for this solution to work.

As can be seen in the following table, each option has advantages and disadvantages so you have to choose the one that best fits your situation.

• Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services
  https://technet.microsoft.com/en-us/library/dd807071%28WS.10%29.aspx
  “Employees with user accounts anywhere in forests that are trusted by this forest (through a two-way Windows trust)”
• Active Directory Federation Services (AD FS) 2.0
  https://technet.microsoft.com/en-us/library/adfs2%28WS.10%29.aspx
• HomeRealmDiscoveryPage Class Overview
  https://msdn.microsoft.com/en-us/library/ee895364.aspx