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

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.

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…

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.

The process for connection is as follows:

1. Client tunnel RDP connection through HTTPS.
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).
3. Remote machine beleives that the request has come directly from the client and responds appropriately.

It all sounds straightforward enough but, as Austin explained, there are some gotchas too:

• As for when tunneling RPC through HTTPS with Outlook and Exchange, the certificate must be recognised as valid – there is no manual option to trust a site if there are certificate issues (as there would be when browsing the Internet). There are two possible options:
  1. Establish a corporate public key infrastructure and install the appropriate certificates on the client. The downside to this is where clients don’t allow certificates to be installed by users (e.g. in a kiosk scenario).
  2. Alternatively, purchase a certificate from a trusted certification authority.
• At least initially, few organisations will have a PKI based on Windows Server 2008 and, due to the removal of the Xenroll ActiveX control from Windows Vista (see Microsoft knowledge base article 922706), Windows Vista and Windows Server 2008 computers cannot use the WIndows 2000/2003 CA web interface (or indeed the equivalent interfaces on the Thawte or Verisign websites). It should be possible to craft an appropriate web server certificate using the MMC Certificates snap-in, but the common name for the server needs to be fully qualified and the MMC tools insert an unqualified name in a computer certificate. Thankfully there is another method – using the certreq.exe command line tool and a .inf file with the certificate template information (the syntax is described in Microsoft knowledgebase article 321051 and certutil -csplist will list the trusted cryptographic service providers), for example:

  [Version]
Signature="$Windows NT$

  [NewRequest]
Subject = "CN=servername.domainname.tld"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

  [EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

In terms of best practice, Austin had some more advice to give:

• Use a dedicated Terminal Services Gateway Server.
• Consider placing the gateway server behind an ISA server.
• Terminate the SSL connection in the DMZ and put the Terminal Services Gateway Server on the corporate network
• VPNs may still have a place in the infrastructure – Terminal Services gateway servers are best used where no local copy of the data is required or where bandwidth issues mean that the user experience over a VPN experience is poor.

Further information

Microsoft Terminal Services.
Microsoft Terminal Services team blog.
Terminal Services in the Windows Server 2008 Technical Library.