How to install and configure Web Application Proxy for ADFS

The Web Application Proxy (WAP) is a role service of the Remote Access server role in Windows Server 2012 R2. One of the primary roles of the WAP is to performs pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and in this capacity the WAP functions as an AD FS proxy.

In general, WAP provides reverse proxy functionality for web applications in the corporate network which allows users on most devices to access internal web applications from external networks.

Using WAP, you can configure additional features provided by AD FS, including: Workplace Join, multifactor authentication (MFA), and multifactor access control. Also WAP can be part of a DirectAccess infrastructure deployment, or when securely publishing Exchange or SharePoint services.

Pre-requisites:

• Server running Windows Server 2012 R2 Essentials, Standard, or Datacenter.
• At least 1 network adapter installed in the server, connected to the internal network either directly, or through a firewall or NAT device.
  If 2 adapters are used, the first adapter must be connected to the internal network, and the second adapter must be connected to the external network; Internet or public DMZ network.
• It is recommended to place all WAP server(s) in a DMZ network, which is separated from the internal, corporate network by an internal firewall. The WAP servers can be either joined to an DMZ Active Directory for management purposes, or left as standalone computers in a WORKGROUP.
• The user account used for the procedure must have local Administrator permission on the WAP server(s), and have access to an account that have local Administrator permissions on the AD FS servers.
• All network traffic for AD FS to and from client devices always occur over HTTPS, so firewalls must allow TCP/443 from the external network/Internet into the WAP server (or the Virtual IP if using Load Balancing across a server farm). If the WAP servers are placed in a DMZ, a firewall placed between the DMZ and the internal network must furthermore allow TCP/443 from each of the WAP servers internal IP to the AD FS server (or the Virtual IP if using Load Balancing across a server farm).
• A public or internally signed certificate with Server Authentication purpose. The certificate Subject must match the address in the published services, and the certificate must be trusted on each client.

This guide will focus on publishing AD FS, and will not cover Integrated Windows authentication and Kerberos constrained delegation, and only mention that it is supported in the Web Application Proxy. The main requirements in this scenario are that the WAP servers must be domain-joined to a Active Directory with Windows Server 2012 domain controllers, and there must be trusts between a user forest and the WAP forest and to a resource forest. For additional information, see Kerberos Constrained Delegation across Domains. It is also assumed that the WAP server have only one network adapter.

It is recommended to enable proper Network Time Protocol (NTP) or another time synchronization method on all Web Application Proxy and AD FS servers.

First, install the Remote Access role and then configure the Web Application Proxy to connect to an AD FS server. This procedure must be repeated on all servers where Web Application Proxy must be deployed.

Start Add Roles and Features on the WAP Proxy server

Select Role-based or feature-based installation, and click Next

Click Next

Select Remote Access, and click Next

Click Next

Click Next

Select Web Application Proxy

Select Add Features

Click Next

Select Export configuration settings

Save DeploymentConfigTemplate.xml (see example in appendix)

Click Install

Wait while the installation is completed …

Click on the Open the Web Application Proxy Wizard link

Click Next

At the Federation Server page, supply the requested information:

• In Federation service name:
  Enter the address of the Federation service name, like fs.adatum.dk
  
• In User name/Password:
  Enter the internal/corporate domain credentials for an account that is member of the local Administrators group on the internal ADFS servers (does not have to be the ADFS service account)
  or
  Enter the internal/corporate domain ADFS service account credentials, as used during the ADFS configuration.

NOTE:
These credentials will only be used once in order to create a proxy trust, and they are not stored.

Click Next

On the AD FS Proxy Certificate page, select a certificate, from the list of certificates installed on the WAP server, to be used for AD FS proxy functionality. The certificate selected here should be the one that whose subject match the Federation Service name, for example, fs.adatum.dk or *.adatum.dk.

Click Next

Click Configure

Wait until the WAP has completed the configuration (this may take from a few seconds to a few minutes …)

When the WAP has successfully connected to the AD FS service, verified the specified certificate and account, and completes the configuration, click Close

After closing the Web Application Proxy Configuration Wizard, the Remote Access Management Console will automatically open.

Before proceeding further, logon to any other WAP servers in the same server farm. Repeat the above described process to install Web Application Proxy. Then open the Open the Web Application Proxy Wizard link, add the Federation service and comple the initial WAP configuration.

Now, switch to the first/primary WAP server, and open the Remote Access Management Console

Create a new pass-through publishing by clicking Publish in the right menu.

Click Next

Select the Pass-through preauthentication method, and click Next

On the Publishing Settings page, enter this information:

Note:
The External and Backend server URL must be the same !

Select the External certificate:

Click Next

Click Publish

Wait for the ADFS Application to be published …

Click Close

Now the ADFS service is published in the WAP.

NOTE:
With multiple WAP servers, setup in a NLB cluster, it is only required to make the publication on the primary server. The remaining NLB cluster nodes will get the configuration automatically, simply press Refresh in the Remote Access Management Console, after the pass-through application is published.

Verify the Operations Status, and the servers are working as expected.

The WAP must now be made accessible from the Internet, by adding a Host A record in the public DNS zone, which point the federation service name (fs.adatum.dk) to the public IP of the WAP listener.

Last, verify that https://fs.adatum.dk/adfs/ls/IdpInitiatedSignon.aspx is available and working from the public Internet (modify the URL to your domain!).