The search for a Forefront TMG replacement (Part 4: Windows Server 2012 R2 + web application proxy)

Forefront TMG has now been discontinued and a replacement will have to be found sooner or later. There are now several manufacturers who are filling the gap left by Forefront TMG. I will test some promising solutions and publish a howto for each of them. Finally, there will be an article comparing the solutions and listing the pros and cons from my point of view. So much for the plan.

I have therefore created a standard test environment that I will use for all solutions. The test environment has a relatively simple structure:

There is a Windows Server 2012 R2 with the name DC1 on which the Domain Controller role and Outlook 2013 are installed. Exchange 2013 is also installed on Server 2012 R2. The Exchange servers have the names EX1 and EX2. This is always the starting point for all solutions.

I defined a few evaluation criteria in advance in order to be able to draw a conclusion later. Mind you, these are my own criteria, which probably say little about the quality of the individual products. But more on that later.

So this article is about the new role "Web Application Proxy" which is included in Server 2012 R2. The web application proxy is also a reverse proxy for websites and can also be used for Exchange. The Web Application Proxy role requires Active Directory Federation Services to authenticate users. I will therefore describe the installation and configuration of the Active Directory Federation Services and the configuration of the web application proxy. I have again adapted my test environment for this purpose:

The Active Directory Federation Services (AD FS) are installed on DC1, the web application proxy on a Windows Server 2012 R2 with the name Proxy1. Proxy1 is an Active Directory member. Valid certificates are required for ADFS, so I use a wildcard certificate from an internal certification authority for my test

Since the web application proxy cannot be set up without ADFS, I first install the role on the server DC1

Once the installation is complete, the role can be configured

In the first dialog, "Create the first federated server in a federated server farm." is selected

The user can stay that way

In the next dialog, a valid SSL certificate must be selected. For the sake of simplicity, I have used a wildcard certificate from an internal CA. Furthermore, a DNS name for the federated service and a display name must be entered

An AD account must now be created for the service

The configuration is saved in a database, for my test I use the Windows Internal Database

Now you can install

Parallel to the installation, the DNS name for the network service can already be entered on the DNS server

Once the installation is complete, the configuration of the trust relationship with the web application proxy can be finalized by opening the AD FS console and creating a "Claims not supported trust relationship...."

Enter display name

and then enter the following URL:

The remaining settings can be adopted according to the default settings

In the next dialog a new rule is created, I start with a "allow all" rule

We should now be able to find our new position of trust under the item Positions of trust

The web application proxy can now be installed on the Proxy1 server

In this case, only the web application proxy is required

The configuration can be started directly after installation

Enter the DNS name and administrator account of the AD FS server

Then select the certificate, I use my wildcard certificate here again

Almost finished....

Now an SPN is required, open the ADSI Editor and search for the computer account of the proxy server in the naming context. Add 2 values for the attribute "servicePrincipalName": "HTTP\PROXY" and "HTTP\Proxy.frankysweb.local", i.e. once the short name and once the FQDN of the server preceded by HTTP\

Now the delegation must be activated by opening the "Active Directory Users and Computers" console and adding the Exchange server(s) with the HTTP protocol to the computer account of the proxy server

Finally, the Exchange URLs must be published on the proxy server. The "Publish New Application Wizard" is executed in the Remote Access console for this purpose.

OWA and ECP are authenticated with the ADFS method, the remaining URLs with PassThrough, here the example for OWA

Select the position of trust that was created above

Enter URLs

And repeat the process for ECP according to the same scheme. EWS, AutoDiscover, ActiveSync, OAB and Outlook Anywhere are published with PassThrough authentication.

Once all the rules have been entered, the login window of the network service appears

Phew, done... Maintaining the table...