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