Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II

Web Application Proxy is a role in Windows Server 2012 R2. Web Application Proxy brings some functionality of Microsoft Forefront TMG and Microsoft Forefront UAG but not all of them. Since Microsoft phased out Forefront product line except FIM. Web Application Proxy provides functionality or role in Windows Server 2012 R2 for customer who still wants use Microsoft platform to publish their application such as Exchange 2013, Lync 2013 and SharePoint 2013 to external clients and vendors.

Web Application Proxy provides pre-authentication and authorization method using Active Directory Federation Services including multifactor authentication and access control. Deployment of ADFS is separate to Web Application Proxy which means you must have a separate server hosting ADFS role.

Benefits of Web Application Proxy

  • Pre-authentication—Only authenticated traffic can get into the corporate network.
  • Network Isolation—Incoming web traffic cannot directly access backend servers.
  • Selective Publishing—Only specific applications and paths within these applications are accessible.
  • DDoS Protection—Incoming traffic arrives at Web Application Proxy before hitting the corporate network. Because Web Application Proxy acts as a proxy, many DDoS attacks can be prevented from reaching the backend servers.
  • Selective Ports- Apply deny ALL and allow selected ports. This policy will prevent SQL injection.
  • Extended validation– URL validation and verification using public certificate authority. Support strong security and encryption using SHA and 2048 bit certificate encryption.

Web Application Proxy Infrastructure

  • Active Directory Domain Services (AD DS)
  • Internal Domain Naming System (DNS)
  • External DNS Name Resolver or ISP
  • Active Directory Federation Services (AD FS)
  • Active Directory Certificate Services (AD CS)
  • Web Application Proxy Server(s)
  • Public Certificate Authority
  • Internal Enterprise Certificate Authority
  • Backend Application Server(s)

Web Application Proxy Network

Web Application proxy can be deployed in several topologies. In all these scenario Web Application Proxy needs two network adapter.

Edge Firewall: Behind a frontend firewall like Cisco ASA to separate it from internet. Firewall must allow HTTPS (443) traffic to and from Web Application Proxy server.

DMZ: Behind a frontend firewall like Cisco ASA to separate it from internet and before corporate firewall like Cisco ASA to separate it from corporate network. Firewall must allow HTTPS (443) traffic to and from Web Application Proxy server. For client certificate authentication, you must also configure the firewall to allow traffic on port 49443.

Edge Configuration: One network adapter directly connected to internet and another network adapter connected to corporate network. Web Application Proxy can be a member of an Active Directory Domain.

TCP/IP Configuration Examples

Scenario Internal NIC External NIC
non-domain joined IP:




Gateway: NIL


Domain Joined IP:

Gateway: NIL


IP: 203.17.x.x Public IPSubnet:

Gateway:203.17.x.254 Public Gateway

DNS: or Public DNS

DNS Requirement

  • Internal DNS: Web Application Proxy must resolve internal fully qualified domain name of backend application server such as Exchange or SharePoint server. You must configure correct DNS record and TCP/IP Settings of Web Application Proxy Server either using DNS server or editing hosts file in WindowsSystems32DriversEtc location.
  • External DNS: External client must resolve fully qualified domain name of application. In this case, you must configure HOST (A) record in public DNS server. Note that the external URL must resolve to the external IP address of the Web Application Proxy server, or the external IP address of a firewall or load-balancer placed in front of the Web Application Proxy server.

Load Balancer Consideration

Web Application Proxy does not have in-built load balancer or ISP redundancy functionality. Depending on your requirements, you can use any hardware or software load-balancer to balance load between two or more Web Application Proxy Servers.

Domain Joined or non-domain joined

Web Application Proxy can be deployed without joining the server to an Active Directory domain or by joining the Web Application Proxy server to a standalone domain in a perimeter network.

You can deploy Web Application Proxy with a read-only domain controller. However, if you want to deploy Web Application Proxy and DirectAccess on the same server, you cannot use a read-only domain controller.

Authentication Consideration

Web Application Proxy can work with the following authentication protocols.

  • AD FS pre-authentication
  • Integrated Windows authentication
  • Pass-through pre-authentication

Network Time Protocol (NTP)

You must have a proper NTP server in your organization. NTP server can be your domain controller or a Cisco Core Switch. Timestamp must identical between AD FS and Web Application Proxy Server.

Certificate Authority

There are two types of certificate requirements for Web Application Proxy Server- Public CA and Enterprise CA.

  • Public CA: External clients to be able to connect to published web applications using HTTPS, Web Application Proxy must present a certificate that is trusted by clients. In this case you must bind a public certificate with published application in backend server and web application proxy server.
  • Enterprise CA: AD FS certificates must match federation service value. AD FS can use internal Enterprise CA. For examples, Common Name (CN) of Certificate is

Supported Certificate Template

Web Server Certificate with single common name, subject alternative name (SAN) certificates, or wildcard certificates.

Pass-Through Pre-Authentication

When you publish Exchange and SharePoint using Web Application proxy Server, you can pass-through authentication to the specific application instead of AD FS or Web Application Proxy. In this case Web Application Proxy forwards the HTTPS request directly to the backend server using either HTTP or HTTPS. Pass-through authentication is still a worry-free deployment because it prevent DDoS and SQL injection and provide network isolation.

About Raihan Al-Beruni

My Name is Raihan Al-Beruni. I am working as an Infrastructure Architect in Data Center Technologies in Perth, Western Australia. I have been working on Microsoft technologies for more than 15 years. Other than Microsoft technologies I also work on Citrix validated solution and VMware data center virtualization technologies. I have a Masters degree in E-Commerce. I am certified in Microsoft, VMware, ITIL and EMC. My core focus is on cloud technologies. In my blog I share my knowledge and experience to enrich information technology community as a whole. I hope my contribution through this blog will help someone who wants more information on data center technologies.
This entry was posted in Windows Server and tagged , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

4 Responses to Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

  1. Mike says:

    Great article. How would you plan a migration from TMG 2010 to WAP? I have an productive environment with TMG 2010 and Exchange 2010. I am migrating from Exchange 2010 to 2013 and will also replace the TMG. Since you can’t migrate TMG to WAP I am planing to build the WAP from scratch with all the rules and than switch the firewall mapping from the TMG to WAP when ready. After that decomish the TMG. What do you think? How would you do it? Thanks in advance!


  2. Mike says:

    Thanks. If you publish ActiveSync would you set the rule to PassThrough or ADFS? I use PassThrough at the moment and having the problem that I can’t connect Android devices. iOS works fine. The SSL-Cert is only on the WAP. I do not use the SSL-Cert on the Exchange cause I have no internal server names in the Cert and I think that would not work with the clients. Any ideas? Thanks.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s