Monday, May 9, 2011

Force the use of RD WebAccess (block direct mstsc.exe connections)

Consider the following scenario:
You have one or more RD Session Host servers running on which you installed and configured applications and settings. You want to publish this full desktop using a full desktop to your end-users using RD WebAccess and via RD WebAccess only.
When you publish the full desktop via RD WebAccess (whether it’s via a RD Gateway or not). Users will be able to directly contact the RD Session Host (or via RD Gateway) using their local Remote Desktop Client (mstsc.exe). Why? Because RD WebAccess does nothing more than provide you with the rdp-settings to use after you have authenticated. When you start a full desktop session via RD WebAccess mstsc.exe is launched under the hood. Therefore, when you have knowledge of the name of the RDS farm (and the FQDN of the RD Gateway) you will be able to bypass the RD Webaccess and just launch mstsc.exe
Remember that there is difference between in the way the .rdp is built when launching a RemoteApp or a full desktop. (see here: http://microsoftplatform.blogspot.com/2011/05/rd-webaccess-and-unknown-publisher.html )
Microsoft states this scenario as “expected behavior”. And, there right about that of course. Access is possible because of the way RD WebAccess works. (RD WebAccess is not some form of proxy). In some scenario’s the ability to access the environment could in fact be thought of as a form of workaround when the RD WebAccess temporarily unavailable.
There are multiple scenarios however, in which being able to connect directly is not the desired functionality.
For example, when you have made heavy customizations on your RD WebAccess page and want to inform users with news of updates on the availability of your environment using this page you would want to have your users to actually go through the RD WebAccess page to take note of those updates.
Another scenario is where you have setup a form of Two Factor Authentication (2FA) on your RD WebAccess page and want your users to always use this 2FA. By having them access the environment without accessing the RD WebAccess they can actually bypass the 2FA.
A solution for this scenario can be achieved by making use of ISA (or TMG). My colleague explains the way we successfully set this up thoroughly in a blog post here: http://www.forefrontblog.nl/2011/05/06/publishing-rds-web-rsa-and-preventing-direct-logon/
You can find a detailed configuration in the blog post above but basically what you do is you create two rules in ISA that use the same HTTP listener. The first rule will have the destination of the RD WebAccess server; the second rule will have the destination of the RD Gateway server. By doing so (based on cookie authentication) you will only be able to access the RD Gateway (and thus the RDS farm) by making first authenticating on the RD Webaccess rule (on which you could configure your 2FA as well). This will force users to always use RD WebAccess.
Small note:
A change in a .aspx file that RD Webaccess uses is also necessary, for RD WebAccess based on Windows Server 2008 R2 the change should  be:
RDPstr += "pre-authentication server address: s: https://<RDWebAccess FQDN>/rdweb\n";
RDPstr += "require pre-authentication:i:1\n";
RDPstr += "";
And note that the cookie is authorized for 10 minutes by default. This value can be changed in ISA, but during testing make sure that you delete your browsers cookies before testing the inability of directly connecting using mstce.exe

4 comments:

  1. I know this post is pretty old. However with ISA/TMG/UAG all going out of favor and being somewhat replaced with Web Application Proxy in 2012+, I wrote a series of blog posts detailing how to setup RD Gateway 2012 R2 behind WAP.

    Part 1 - http://frozentundrait.blogspot.com/2015/05/securing-rd-gateway-with-web.html
    Part 2 - http://frozentundrait.blogspot.com/2015/06/securing-rd-gateway-with-web.html

    ReplyDelete
  2. Hi Tom,

    That's a great walkthrough you posted, well done and thanks for sharing that here!

    On a side note yes, in the mean time technology has cached up and even Microsoft themselves now have a out of band MFA solution that works with RD Gateway as well (Azure MFA Server) which is also interesting in terms of costs, because it's a very simple (and relatively cheap) solution based on a fixed per user per month price. Also see: http://www.rdsgurus.com/uncategorized/step-by-step-using-windows-server-2012-r2-rd-gateway-with-azure-multifactor-authentication/

    ReplyDelete
  3. Hello,

    Azure MFA does nothing to increase the security of RDWeb once a user has been able to connect and download the RDP file. It would be nice if there was a straightforward way to expire these files or to require MFA for each connection...

    ReplyDelete
    Replies
    1. Hi Jason,

      You're correct that Azure MFA does not secure RD Web Access out of the box. That is why the general advice is to secure RD Gateway with MFA. That way it does not matter how or when you got the .RDP files, with every RDP connection you make you go through the RD Gateway and thus through MFA.

      Delete