NW Doc

When Microsoft Windows 2000 was released many years ago, administrators were blessed with new functionality called Terminal Services which easily allowed remote administration of a server. The functionality or the concept was actually not new. Administrators of Windows operating systems as well as other platforms are plenty familiar with the concept of remote administration. For Windows and some many other platforms, remote administration was accomplished through the use of 3rd party tools which meant the purchase of an extra remote administration tool license for every server that is deployed. While the licensing costs generally weren't terrible, especially for what is gained in return (ease of remote administration, working from home in your pajamas while smoking a cigar like I'm doing now), the costs could add up quickly for infrastructures with large numbers of servers to remotely administrate. What was new, however, was that Windows 2000 introduced a remote administration tool that was built into the OS with no bolt-on licensing costs needed. The tool was called Terminal Services and other than a few minor quirks that it had such as software installation problems in Terminal Services, drive letters not dynamically added/removed without a logoff/logon, not a true console0, etc., it was a God send and still is to this day.

The release of Windows XP brought us an overhauled remote administration tool. The Terminal Services client was still a viable tool but the version in Windows XP called Remote Desktop Connection was, well, cooler. In typical Microsoft fashion, the new tool brought with it some added functionality to make administrator's lives even easier.

Fast forward to the year 2006. A new version of the Remote Desktop Connection (5.2) had been released for download from Microsoft which added the ability for more secure communications. Then finally Windows Server 2003 Service Pack 1 was released which delivered a slightly updated version of the tool (5.2.3790.1830) which allows the initiating client to require secure communication with a remote server which is what I wanted to write about a little today. Today we live in a world where security is held in much higher regard. Sure it was talked about in the 1990s and for those who are old school certification nuts, you probably even got a few exam questions on security way back when, but today with the events of 9/11, terrorists, internet availability and anonymity, wireless networks, and computer hacking, maintaining a secure network has really come to the forefront as a hot topic. This writing will showcase a method to securing communications between a server and a client using the Remote Desktop Connection and the Remote Desktop Protocol (RDP).

In the example that follows, we will have a Windows client named client.contoso.com and a server named server.contoso.com which is running Windows Server 2003 SP1. Neither machine is a member of a domain; both are running as members of a workgroup. Our example will make use of digitally signed certificates using with server.contoso.com being a stand alone root CA. In a practical environment, not every server that you RDP to needs to be running a CA, in fact, most servers won't be running a CA, but since we only have two machines in our example, I chose the server to run the CA services. In your environment, you may already have a stand-alone or enterprise CA. Either can be used to issue certificates to the machines in which you wish to establish a secure RDP session with. It is assumed that by this point, you already have a CA in place in your infrastructure or you are making use of an external CA. You also have configured the server to receive remote desktop connections. In our example, we have obtained a certificate and installed it already on server.contoso.com.

First we configure the server. Under Administrative Tools, open Terminal Services Configuration. Double click RDP-TCP to configure the properties of Terminal Services using the RDP protocol. Under the general tab to the right of the word certificate, click Edit. Choose the installed certificate that you wish to associate with the Terminal Services connection over RDP:

Back under the general tab, you will now be able to choose SSL for the security layer. This is what ultimately requires the use of certificates for the RDP communication on the server side. Take a quick look at the encryption level setting. Choices are client compatible, high, or FIPS. Client compatible means enforce the highest level of encryption that the connecting client supports. High means enforce the highest level of encryption that the server supports. FIPS means enforce FIPS encryption on both the server and the client. FIPS is government approved level of encryption.

Now let's move over to the client. The first thing we need to is ensure that the client trusts the CA chain that the server's certificate was issued from. If this has not been done already, I will quickly walk you through the steps involved with a stand-alone CA. On the client, open a web browser and go to http://servername/certsrv/. Click Download a CA certificate, certificate chain, or CRL:

Choose Install this CA certificate chain:

Choose Yes:

Choose Yes:

At this point you can close the web browser on the client machine:

Ensure that on the client, Remote Desktop Connection version 5.2.3790.1830 is installed (read Download RDP 5.2). If it is not installed, you can install it from a server running Windows Server 2003 SP1. The source files are located on the server in c:'windows'system32'clients'tsclient'.

Open the Remote Desktop Connection client. Click on the Options button so that you can view all configurable options. Click on the Security tab. Choose Require Authentication in the pull down box.

Click on the General tab. Enter the FQDN name of the server you will be connecting to. It is important here to enter the FQDN name:

You will receive the following warning. Click the button labeled View Certificate:

Click Install Certificate:

Click Next:

Click Next:

Click Finish:

Click Yes:

Click OK:

Click OK and you the Remote Desktop Connection will close:

Now that the certificate is installed on the client, we may connect. Remember to use the FQDN here because that is what is contained in the server's certificate:

We have now established a secure encrypted Remote Desktop Connection from the client to the server:

Clicking on the small padlock at the top of the screen ensures are secure connection by displaying the certificate that is in use: