Two Factor Authentication for Remote Desktop Services

There is a fair amount of information out there about how to accept two factor authentication (2FA) for connecting to Remote Desktop Web Access (RDWA), but this leaves out the truly important connection to the RD Gateway (RDGW).  About a year ago Freek Berson, an MVP in RDS wrote a blog post that addresses this very topic for Terminal Services and ISA.  In this post, along with Freek’s help (thanks again!) I’ll show you how to set up Remote Desktop Services (RDS in 2008 R2) and Threat Management Gateway (TMG 2010) to secure your RDS environment with 2FA using RSA SecurID. You should understand that there are two connection paths that we’re talking about protecting here.  Both use HTTPS encapsulation, but only one of them actually connects a Web Browser to a web site, the RD Web Access page.  The second connection is between the RDP Client (mstsc.exe) and the RD Gateway server.  Users will access the RDWA to get a list of RDP files which are configured to launch their RDP Client and connect them via the Gateway to the RD Session Hosts reach their applications or desktops.  Most of the 2FA solutions you’ll find out there are actually securing only the RDWA connection and do not address the Gateway.  This is a huge security loop hole and it is important that it be addressed to truly protect RDS with 2FA. Here’s what we’ll cover in this article.

1. RDS Connections (Understanding the Workflow)
2. RDS Preparation (Certificate, RDWA Auth, Pre-Auth)
3. TMG Preparation (Certificate, SecurID)
4. TMG Listener (Credential Collection and Delegation)
5. TMG Rule: RDWA
6. TMG Rule: RDGW
7. Client Connection Testing

By the time you reach the end, you’ll have a fully secured RDS environment.  So let’s get started!  

RDS Connections

The following illustrates the two connection paths that are used when in an RDS environment. Without 2FA, connections to the RDS environment are established directly to the RDWA and RDGW services which independently validate user credentials.  These roles can co-exist on the same server, but they are still independent connections established by two different client applications.  One being the Web Browser (IE), the other being the RDP client (mstsc).

n this scenario, users can connect to the RDGW without any needing to establish a connection to the RDWA first.  This is sometimes desirable because users can save RDP files to their computers, double click them and immediately access their Desktops or RemoteApps without ever needing to open their web browser. We are going to change that model so that TMG will instead accept and validate their user credentials as well as a SecurID token (2FA, OTP, etc) and then passes the windows credentials into the RDS environment.  The TMG server will present a web login form, so users will need to use a web browser to connect to the RDWA first to authenticate, and if they haven’t, then they will not be able reach the Gateway.

Because connections to the Gateway use the mstsc client, it cannot understand the web login form, so users must use the RDWA first, and then establish connection to the Gateway.  TMG will handle all of the initial authentication and be able to vet the credentials without needing to prompt the user to login to subsequent connections, at least until the session expires (configurable).  

RDS Preparation

Before digging into 2FA too much, take some time to validate your RDS environment is completely working.  It is far easier to troubleshoot and correct any misconfigurations now than it will be once you have a few more services in play.  Here’s a couple keys pieces to check:

1. One Certificate to Rule them All. 
2. Functioning RemoteApp and Remote Desktop
3. Single Sign-On.

The key to making this work is configuring TMG to use one Listener for both the RDWA and RDGW services.  This allows the credentials for one to be used on the other.