Blog du Tristank

So terrific that 3 of 4 readers rated it "soporific"

How TSWeb / TSAC / Remote Desktop Web Connection Client Works

[Update 16 Aug 2004] I’ve posted some sample TSWeb HTM file that handles different ports too, and steps for how to get it working* with ISA 2004 (or other Port Address Translation-capable firewalls) in this post: Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb.

There’s a common misconception that TSWeb allows you to connect to a Terminal Server over HTTP. The reality is that you just use HTTP to transfer the Remote Desktop Client ActiveX control to the client browser, which then runs and makes a regular RDP connection to the Terminal Server, just like the regular Remote Desktop client would, but presented in a browser window.

Short version: HTTP and RDP are used to connect to a TSWeb server. HTTP (TCP 80) is used to download the ActiveX control, which then connects directly using RDP (TCP 3389) to whatever server is specified by the page for the actual Terminal Server interface. Clients that can’t use port 3389 through a firewall won’t be able to connect, so clients that exclusively have Web protocol access are not able to use this method to connect. (They’ll be able to download the client and the page, but not able to do the actual Terminal Server part).

Long version:

Since the Terminal Services Advanced Client (TSAC), we have offered a web client version of the Terminal Server Client – nowadays called the Remote Desktop Client.

The TS Web client package can be installed on any Web server – it’s essentially a CAB file that contains the program itself (the ActiveX control) and some HTML or ASP to display a web page – it’s done using standard <OBJECT> tags. The web page is designed to ask your browser to download the CAB file, run the ActiveX control and pass some basic parameters to it, such as the server name and resolution.

There are several possible advantages to this method:

  • You limit the users’ need to learn server names – clicking links is all they have to do
  • You can control client settings centrally, from the web server, by editing the HTML page
  • You can upgrade the client software on the server 1

The disadvantages:

  • 1 Non-administrators generally won’t have permission to install ActiveX controls. On Win9X, no problem, everyone’s an administrator, but on more modern OSs, this can make deployment trickier – you’d have to actually roll out the client via, say, SMS or Active Directory.
  • You need to ensure client connectivity to both the Web server, and the Terminal Server
  • Clients can easily use MSTSC to connect directly to the Terminal Server – by itself, using the Web Client does not increase security because the web server’s security settings are not at all related to the Terminal Server security. You need to adjust the properties of the RDP Connection Object in the Terminal Services Configuration MMC to restrict which users or groups have permission to use Terminal Services (and any other security settings you need), just as you would as if the clients were connecting directly to it. Because they are.

And after typing most of this, here’s the KB article that also describes how it works…

270897 How Terminal Server Advanced Client Connects to a Terminal Server

See also
294720 How to Server Publish a Terminal Server with ISA

I love it when that happens*.

Helpful Picture:

[Updated 20 May 2004] This Helpful* Picture illustrates TSWeb Publishing when ISA Server 2000 is used – being fairly ISA-centric myself, I figured I’d pop this in. The top one is how you’d probably do it with an Integrated mode ISA Server (if you have routers in front of ISA but use ISA as the primary client connection behind them, then it works for that model too). The other one is how you’d do it if you have a separate firewall doing the NAT/Firewall stuff, and a cache-only ISA Server that publishes your websites.

For the Integrated scenario, you Web Publish the IIS instance hosting TSWeb, and then Server Publish the RDP protocol (you’ll need to create an RDP Server protocol definition for TCP 3389 Inbound, no secondary connections).

Quick Bullets:

  • The Web Server doesn’t need connectivity to the Terminal Server.
    • Connections are Client -> Web Server and Client -> Terminal Server
  • The client uses RDP to connect to the TS, not HTTP
    • so the client can’t connect if it only has Proxy connectivity (eg, just 80 and 443)
    • the server doesn’t proxy the client connection
      • you can’t connect to random servers on the internal network through the server – the client computer needs to be able to directly access the internal machine, or a port forwarded to the internal machine
      • OK, so technically you can access it using the RDP client through the server again , but a) that’s cheating and b) you’re adding more overhead, so it’s probably not the best idea
  • You need one external IP Address and port combination per internal server
    • if you have multiple TSs or WinXP Pro machines and only one IP address, use PATto forward from different external ports to 3389 on the internal machine.
      • eg, external IP:3390 -> Internal Desktop: 3389
      • using the out-of-box web client, this needs to be scripted using AdvancedSettings2: rdpclient.AdvancedSettings2.RdpPort = 3390 before connecting…
      • But as it happens, if you’d rather not fiddle with VBscript, this was the subject of Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb , which links to a generic connection page I fiddled up that allows the user to specify their own port,

If you liked this, you’ll also love TS Licensing in 90 Words Or Less and Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb.