Some time ago one of our customers asked us if it were possible to publish their RD Web using RSA authentication through ISA/TMG.
This turned out to be little to no issue, we simply followed this guide by Sole to configure this setup.
After initially satisfying the customer with our swift response he returned to us several days later to report that his employees found a way to circumvent the RD Web entirely (and the RSA logon) by using the native RD client (mstsc) and connecting to the farm using the RD gateway.
To prevent this from happening we needed to come up with a way to force users to be logged on to ISA/TMG when they attempt to make a connection to the RD gateway. This was no small task by any means, because neither ISA nor TMG is able to delegate authentication for RDS, they both simply lack the tools needed to intercept the application specific authentication that RD uses.
After some intensive Bing-ing we stumbled across this very handy guide (by an unknown author (for as far as we call tell (if you are (or know) the author, please contact us so we can give credit where it is due)) which describes the setup we were aiming for in great detail.
After setting up the environment according to the previously mentioned guide, we tested the setup, only to be greeted by a familiar error:
Some intensive debugging using my favorite tools (Fiddler 2 (Link), Wireshark (Link) and of course the good old ISA/TMG Monitor (requires TMG or ISA 2006 Supportability update (Link) or SP1(Link) for drilldown purposes) learned that even though the original RD Web session was authorized and bound to the user’s SecurID username, the actual RD session (which users initiate from the RD Web interface) was being denied due to not being bound to a user (well, a user other than “anonymous”).
This did in fact prove that the security measures we put in place were working ( :) ) but that the single sign on wasn’t ( :( ).
The solution to this, as always, proved to be simple. To get SSO between the RD Web and the Microsoft RD client to work, all we needed to do was the following:
- Double-check whether both publishing rules were using the same Web Listener (they were)
- Change the Web Listener’s cookie settings to “On all computers” (under the “Froms” tab of the Listener, click the “Advanced” button to reach these settings)
(please take notice of the fact that we’ve set the cookie’s validity timeout to a maximum of 10 minutes, this way we can assure ourselves of the fact that malicious users will not be able to exploit this cookie to circumvent our security measures*)
- Add the domain name used in SSO (the one your clients connect to, and which you’ve added to the Web Listener’s SSO settings) to the “trusted sites” in IE
- Logoff from the RD Web Access, reload the site and logon again…
And Presto! Now we were able to logon to the RD environment from the RD Web Access, whilst keeping all unauthenticated users from directly connecting to the RD Gateway.
* Because of the cookie validity period, users will only be able to logon to the RD Gateway via RD Web Access for a maximum of 10 minutes. After that, user sessions to the RD Gateway will fail due to being unauthenticated, requiring the user to logon to the RD Web Access again.
(Originally posted on: http://www.forefrontblog.nl/2011/05/06/publishing-rds-web-rsa-and-preventing-direct-logon/)
