After an organization deploys Windows Terminal Services, it's only a matter of time before someone asks to use...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
it from beyond the network perimeter. Terminal Services Gateway is a secure way to access Terminal Services remotely, and the feature is simple to set up and deploy.
To establish a Terminal Services session remotely before Terminal Services (TS) Gateway existed, administrators had to open a firewall port with the Remote Desktop Protocol (RDP). This method posed a major security risk because the RDP can be used to remotely control network servers.
On the other hand, a TS Gateway, which was first introduced in Windows Server 2008, is a single-purpose virtual private network (VPN), and as such, the RDP is encapsulated within the Hypertext Transfer Protocol Secure (HTTPS) protocol. Therefore, all remote sessions are encrypted with Transport Layer Security (TLS). The encapsulation process also adds a layer of protection -- since the RDP port isn't open, a hacker can't discover you are using RDP by doing a port scan.
Setting up a TS Gateway is simple and primarily consists of installing the TS Gateway role service, which results in the installation of the Internet Information Services (IIS) Web server and Network Policy and Access Services.
Configuring the certificate
Using a Terminal Services Gateway requires knowing how to work with Secure Sockets Layer (SSL) certificates.
As mentioned above, sessions that use a Terminal Services Gateway are encrypted with TLS. To enable this encryption, you need to provide IIS with a certificate it can use. It doesn't matter where the certificate comes from as long as the client computers using the TS Gateway trust the certificate.
I've seen small organizations try to take the cheap way out and use a self-signed certificate. This certificate generally won't work because no client machine is going to trust it, and when users attempt to connect to the TS Gateway, the following message will appear:
This computer can't connect to the remote computer because the certificate authority that generated the Terminal Services Gateway server's certificate is not valid. Contact your network administrator for assistance.
The above message isn't unique to self-signed certificates. Users will receive this message anytime their computers do not trust the certificate being used by the TS Gateway server.
To avoid this error message, use a certificate from a well-known, commercial certificate authority. By default, Windows is configured to trust certificates from most of the better-known certificate authorities.
Another option is to use a certificate generated in-house. Windows Server can be configured to act as an enterprise certificate authority. Such a certificate authority can generate the necessary certificate for a TS Gateway server. The catch is that clients are once again not going to trust the certificate by default. However, this isn't always a deal-breaker.
If clients will be accessing the TS Gateway only with company-issued computers, then you can configure client computers to trust certificates issued by the in-house certificate authority. Of course, this isn't an option if clients are accessing the TS Gateway via a public kiosk because you won't be able to configure the kiosk to trust your root certificate.
When you install Certificate Services, Windows creates a website to perform certificate requests. The site's URL is usually "http://<your enterprise certificate authority's FQDN>/CertSrv." Upon accessing this site, you can choose to download a certificate chain or certificate-revocation list (CRL).
After the server's certificate is downloaded, you can import the certificate into the client computer. The exact method for doing so depends on the client computer's version of Windows.
In Windows Vista, enter the CertMgr.msc command at the Run prompt. This will cause Vista to open the Certificate Manager console. Next, navigate through the console tree to Certificates -- Current User | Trusted Root Certification Authorities | Certificates. Right-click on the Certificates container, and select the All Tasks | Import commands from the shortcut menus.
An example of the certificate import process is show in Figure 1.
Words of caution
The preferred method for encrypting the Terminal Services Gateway server's encapsulated RDP traffic is to use an SSL certificate from a commercial certificate authority. If decide to deploy your own enterprise certificate authority, you must make sure to not deploy it onto the same server running the TS Gateway. Exposing a certificate authority to the outside world is a huge security risk.
Furthermore, remember that the T S Gateway server has two jobs: provide remote access to Terminal Services over the HTTPS protocol, and shield your Terminal Servers from being directly exposed to the Internet. As a result, you should deploy a TS Gateway in a manner similar to Figure 2.
Although the diagram above is simplified, note that the gateway server contains two network interface cards, both of which are connected to firewalls. One firewall separates the gateway server from the Internet, and the other separates the gateway server from the back-end network.
The diagram also shows that communications between the gateway server and the Internet use the HTTPS protocol. The gateway server then strips off the HTTPS encapsulation and proxies the RDP packets to the back-end Terminal Servers.
ABOUT THE AUTHOR:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server and has received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Posey has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Posey's personal website at www.brienposey.com.