Today, a colleague came up to me to ask me a question on a weird situation he encountered while troubleshooting an Active Directory Federation Services (AD FS) implementation at a customer site.

Note:
We didn’t implement this situation, but after solving this challenge, we gave some great pointers to get the environment sorted.

The situation

This customer has a highly redundant Active Directory environment, hosted by Domain Controllers that have never experienced any problems. They also have a single Windows Server 2012 Full installation, with the Active Directory Federation Services Server Role installed and configured with a relying party trust that instructs it to be the identity provider for a web application.

On the perimeter network (DMZ), a Windows Server running Forefront Threat Management Gateway (TMG) is deployed. In TMG, a Web Publishing Firewall Rule was configured to pass traffic, destined for the AD FS server address to the AD FS server on the internal network.
The rule is configured without Authentication Delegation, as you can see on the Authentication Delegation tab in the screenshot of the Web Publishing rule, below (rule name removed to protect the innocent):

The challenge

In the case of this customer, when colleagues accessed a claims-enabled web application they would get a password prompt instead of the AD FS logon page when they’d be using Internet Explorer:

When these colleagues would use Google’s Chrome or Mozilla’s FireFox, the AD FS logon page would display correctly.

The customer wanted a consistent logon experience for their employees on each of these browsers. The systems administrator, obviously, wanted to eradicate the Windows Authentication taking place outside of the network.

The solution

Because of the way Forefront Threat Management Gateway (TMG) is implemented at this customer, the Active Directory Federation Services (AD FS) Server misinterprets the location where the authentication request is originating from. When we looked at the Global Authentication Policy in AD FS Management, we saw the default settings still applied, allowing Windows Authentication from the Intranet.

We unchecked the option for Windows Authentication for the Intranet:

After we clicked OK, the problem was solved for this customer; regardless of the browser capabilities, employees would get the AD FS logon page served.

Concluding

15 Minutes of work. One happy customer. 3 billable hours.

Note:
Although this document specifically mentions AD FS 2.1 on Windows Server 2012, the same applies to AD FS 3.0 on Windows Server 2012 R2.