{"id":830,"date":"2007-07-10T21:51:12","date_gmt":"2007-07-10T20:51:12","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/2007\/07\/some-more-about-terminal-services-gateway-servers.htm"},"modified":"2007-07-10T21:51:21","modified_gmt":"2007-07-10T20:51:21","slug":"some-more-about-terminal-services-gateway-servers","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2007\/07\/some-more-about-terminal-services-gateway-servers.htm","title":{"rendered":"Some more about Terminal Services Gateway Servers"},"content":{"rendered":"

In an earlier post, I mentioned Austin Osuide’s recent Windows Server User Group presentation on Terminal Services Gateway Server<\/a> and what follows is some of the detail from that session.<\/p>\n

Terminal Services Gateway Server is a server role in Windows Server 2008 – effectively a protocol translator that allows authorised users to remotely access resources on a corporate LAN using RDP over HTTPS.<\/p>\n

Up until now, it’s been necessary to open TCP port 3389 to allow RDP traffic through the corporate firewall but by encapsulating the RDP traffic within an SSL-secured tunnel, control may be exercised over which computers (and hence which applications), users can connect to and from. Other advantages include the fact that there is no need for a VPN infrastructure, so connectivity can be gained from any PC, anywhere (home, hotel, business partner or client premises, mobile or wireless hotspot). Then there are other advantages for IT organisations looking to reduce costs…<\/p>\n

Consider a large outsourcer, with many support teams, each supporting a single customer’s infrastructure. What if one team (with the appropriately scaled resources) could manage multiple networks? Maybe even in an offshore scenario? As an IT professional, I’m not keen on this and as a customer I would be concerned about the potential impact on security but what if my managers could convince the customer that they can maintain security in a global infrastructure such as this? Using technologies such as network access protection (NAP) the health of any connected devices can be ensured and terminal services gateway servers can be deployed to control who can connect to which computers – perhaps only to defined administrative servers with a controlled application set.<\/p>\n

The process for connection is as follows:<\/p>\n

    \n
  1. Client tunnel RDP connection through HTTPS.<\/li>\n
  2. Terminal Services Gateway strips out the HTTPS encapsulation and forwards the request to the terminal server\/remote desktop (if the request passes appropriate policy checks – connection authorisation policies control who can connect and resource authorisation policies control what they can connect to, using user-defined or built-in groups for servers).<\/li>\n
  3. Remote machine beleives that the request has come directly from the client and responds appropriately.<\/li>\n<\/ol>\n

    It all sounds straightforward enough but, as Austin explained, there are some gotchas too:<\/p>\n