Saturday, May 30, 2015

Securing RD Gateway with Web Application Proxy - Part 1


So you've spun up an RDS 2012 R2 environment and you are allowing external access via RD Gateway. You've trained your users on how to use RD Web Access to login in order to access their applications and virtual desktops from home. Maybe you've even installed a two-factor authentication product that integrates with RD Web Access to add an additional layer of protection for your environment. Great!

Wait a minute....

Here's what's not always clear. In regards to remote access to your enterprise environment, RD Web Access is really just a front-end for RD Gateway. RD Web Access is completely optional. You can still gain access to your production environment by interacting with RD Gateway directly using mstsc.exe or the Remote Desktop App on an Android or IPhone device. You don't need to use RD Web Access at all.

So what happens when your two-factor authentication software only integrates with RD Web Access, and not RD Gateway directly? Doesn't that mean someone could access your environment remotely without requiring 2FA by using one of the methods listed above?


This could be a huge problem for your company depending on your internal security policies or compliance requirements. So what options do you have if your vendor doesn't do RD Gateway? Switching vendors is not always feasible, depending on your timeline and budget. There must be something else we can do...

Enter Web Application Proxy

Web Application Proxy is a role in Windows Server 2012 and 2012 R2 that replaces some of the functionality found in Microsoft's UAG and TMG products. It acts as a reverse proxy to allow you to securely deliver your internal web applications to external users. As of the August 2014 Update Rollup for Server 2012 R2, Web Application Proxy (here on out referred to as WAP) supports securely publishing RD Gateway, as can be seen in this TechNet blog post. Finally a supported solution to secure RD Gateway without switching to a 2FA vendor that supports direct integration with RD Gateway!

WAP Graphic from TechNet

But how do we setup and configure WAP to host RD Gateway connections? Microsoft is still working on their official documentation. Besides the aforementioned blog post, there is only a single article I could find on TechNet detailing how to configure WAP for RD Gateway - and the details are very sparse.

This blog post will serve as one of the first resources for installing and configuring the necessary infrastructure components required to host RD Gateway connections behind WAP. Please be warned that these posts will be long and screenshot-heavy.


Before starting, we'll need the following items:
  • Minimum of one 2012 R2 server in your internal network for AD Federation Services.
  • Minimum of one 2012 R2 server in an externally facing DMZ network for Web Application Proxy.
  • The WAP server will need to have KB2975719 (August 2014 Update Rollup) as well as KB2982037 (HttpOnly Update) installed in order to work properly with RDS.
  • You'll either need to open the appropriate ports in your internal firewall (80/443) so the WAP server can talk to the RD Gateway server, or you can also make the WAP server dual-homed, with interfaces on both the DMZ network and internal networks, depending on your level of risk tolerance.
  • Both the ADFS server and WAP server need to be in the same Active Directory domain as your RDS servers.
  • An SSL certificate from a trusted third-party certificate authority for ADFS.
  • Access to the SSL certificate in use by your RD gateway server and/or RD Web Access (if they are using the same external URL)
  • A public IP address that will be forwarding ports 80/443 to your WAP server.
  • Your RD Gateway server will need an interface connected to your internal network (it may be in the DMZ network now).
  • If your domain controllers are not running Server 2012 or 2012 R2, you'll need to create a service account to be used by AD Federation Services.

Installing and Configuring AD Federation Services

We'll start by installing and configuring ADFS. Connect to the server you'll use to host ADFS, and make sure you are logged in with a domain administrator account. Open Server Manager, and install the ADFS server role.
Installing Active Directory Federation Services

Server Manager will install the ADFS role. Once ADFS has been installed, you'll be prompted to configure ADFS. Click the link in Server Manager to begin configuring ADFS.
It's time to configure ADFS

The Active Directory Federation Services Configuration Wizard will open. Make sure the option to Create the first federation server in a federation server farm is selected, and click Next.
Configuring ADFS

Once again, make sure you are using a domain administrator account and click Next.
Configuring ADFS

Select the SSL certificate you purchased for ADFS and installed on the server. When you select the certificate, the Federation Service Name will automatically populate based on the subject of the certificate. You can also input a display name for ADFS. Click Next.
Configuring ADFS

Next you'll need to select a service account used to run ADFS. If your domain controllers are 2012+, you'll have the option of using a Group Managed Service Account, which is the preferred option. However if your domain controllers are still 2008 R2 (as in my example domain), you'll need to use a regular service account. Select the service account, enter the password, and click Next.
Configuring ADFS

You'll need to specify whether to use the Windows Internal Database, or a SQL Server instance to store the ADFS database. If you have an existing highly-available SQL Server instance, I'd recommend using that. If not, Windows Internal Database should be fine, which I'll be using for this demo. Click Next.
Configuring ADFS

Review the options you selected, and click Next.
Configuring ADFS

Once the prerequisite checks have completed successfully, click Configure.
Configuring ADFS

Once configuration is completed, click Close.
And we're done!

Installing and Configuring Web Application Proxy

Next we'll install and configure WAP. On your WAP server, open Server Manager, and install the Remote Access role. Click Next.
Installing Web Application Proxy

When prompted for the Role Services, select Web Application Proxy. Be sure to install all related management consoles. Click Next.
Installing Web Application Proxy

Follow the remaining prompts to install Web Application Proxy. The wizard will inform you that additional configuration is required. We'll do that next. Click Close.
Web Application Proxy is installed!

From Server Manager, click Tools and open the Remote Access Management console.

The Remote Access Management console will open. In the left pane, select Web Application Proxy and then click the link to run the Web Application Proxy Configuration Wizard.
Configuring Web Application Proxy

The Web Application Proxy Configuration Wizard will open. On the welcome screen, click Next.
Configuring Web Application Proxy

Enter the Federation Service Name that you used for ADFS. You'll also need to enter credentials to be used to connect the ADFS - most likely using your domain administrator credentials. Once the information is populated, click Next.
Configuring Web Application Proxy

Select the certificate to be used by WAP - you can select the same certificate as ADFS. Then click Next.
Configuring Web Application Proxy

Finally, click the Configure button to finish.
Configuring Web Application Proxy

Once configuration is complete, click Close.
WAP configuration is complete!

Back in the Remote Access Management console, you can select Operations Status in the left pane, and see that your WAP configuration is healthy and configured correctly.
WAP looks good!

The final step for WAP is to publish an external DNS record pointing to your WAP server. Doing this will depend on your DNS vendor, so I'll leave that part up to you. Use the public IP address you allocated in the prerequisites to publish the DNS record.

Stay tuned for Part 2!

We've successfully installed AD Federation Services and Web Application Proxy, and performed basic configuration of both products. In part two of this series, we'll configure all the "secret sauce" pieces that will make RD Gateway accessible behind your new WAP server. Thanks for reading!


  1. Hi,

    Thanks for the arcticle, have you done the second part yet ?. I'm looking to do similar scenraio but without wap and will be using third party Reverse proxy, I just need to get the concept of its intergartion. If you have ever done the second part please do share with me @

    1. If anyone is still looking for part2:

  2. Nice post. I was checking constantly this blog and I am impressed! Extremely helpful information specially the last part I care for such info a lot. I was seeking this particular information for a very long time. Thank you and good luck. 1337x

  3. Pretty good post. I have just stumbled upon your blog and enjoyed reading your blog posts very much. I am looking for new posts to get more precious info. Big thanks for the useful info. 1337x

  4. If you've ever accessed the Internet from an office environment,chances are your communications passed through a proxy. You may not already know what a proxy does. The only IP address an Internet host is aware of is the IP address of the proxy. torrentz2