Whether you enable Microsoft Windows Terminal Services for end-users or enable remote desktop connectivity on a Windows Server 2003 for administrative purposes, security issues may arise depending on how you have configured your server. However, with the introduction of Service Pack 1 for Windows Server 2003, you now have the opportunity to establish a secure Remote Desktop Protocol (RDP) connection to your server using TLS/SSL based authentication.

Common threats

Let us start by looking at some common threats.

First of all, you don’t want to allow unauthorized users to connect to your servers, but up until now, this has been very difficult to protect against, when you have enabled remote desktop connections on your servers.

If your password policy in your domain is configured to lock user accounts after a predefined number of logon tries, then your Terminal Services (RDP) enabled server becomes an entry point for a user based DoS (Denial of Service) attack against your domain. One could easily connect to the terminal server and attempt to log on with various usernames and passwords. Depending on the password policies, the username that has been tried may get locked, thus preventing the real user to log on.  

In addition, if weak passwords are used, hacking tools such as TScrack 2.0 can be used to establish a dictionary based attack against servers that have the Windows Terminal Services enabled. This tool by the way, will also perform the before mentioned DoS attack.

The threat becomes even bigger, when the server running Microsoft Windows Terminal Services is accessible from the Internet through an RDP connection on port 3389, even though you have an advanced firewall such as ISA Server in front of it. A scenario that is common especially for Microsoft Small Business Server users.

The good news however, is that you can prevent these attacks. The solution is certificate based computer authentication. If the computer cannot authenticate itself by presenting a valid certificate to the terminal server it is trying to connect to, then the RDP connection will be dropped before the user has a chance to attempt to log on.

How to enable TLS/SSL based authentication

Before we get started, there are some prerequisites you should be aware of.

On the server side the following is required:

• Ensure your terminal server is running Windows Server 2003 including SP1
  
  
• You also need a TLS/SSL based certificate that should be installed with the following specifications:
  • The certificate should be computer based
  • The certificate's purpose should be server authentication
  • The certificate’s private key should be available
  • Since it is a computer based certificate, it should be stored in the computer account certificate store on the terminal server

On the client side the following is required:

• The client computer must be running Microsoft Windows 2000, Windows XP, Windows Server 2003 or Windows Vista
  
  
• For Windows 2000, XP and Windows Server 2003, the remote desktop client version 5.2 or newer should be used. This client can be found in the following folder on a Windows Server 2003 SP1 based server:
             
              %systemroot%\system32\clients\tsclient\win32\msrdpcli.msi

• The last important requirement is that only authorized clients should be able to trust the root Certification Authority (CA) that has issued the computer based certificate residing on the terminal server. This will ensure that a TLS/SSL connection can be established from a trusted client.

Now that you know what is needed, it is time to learn how to make it all happen.

Request a TLS/SSL certificate

The first thing we need to do is install a computer based TLS/SSL certificate on the terminal server. The certificate can be obtained using one of the following approaches:

• You can use the easy and less secure way which doesn’t require a PKI or certificate authority. The tool for that is SelfSSL.exe which is included in IIS 6.0 resource kit. You can download the resource kit here.
  
  
• Or you could obtain a SSL certificate from a 3rd party CA
  
  
• Another option is using your own certificate from your own PKI based on Microsoft Certificate Services.

For this article, we will create the SSL certificate issued by a PKI based on Microsoft Certificate Services. And there is a reason for this. With your own Microsoft based PKI, you get granular control of the certificate trust list and thereby the clients that should trust the root CA responsible for issuing the TLS/SSL certificate. This will ensure that only trusted computers are allowed to authenticate to your terminal server.

We will assume that you already have installed Microsoft Certificate Services somewhere in your infrastructure. The process you have to use for requesting a TLS/SSL based certificate, depends on whether you request the certificate from an enterprise CA (Active Directory integrated), or a stand-alone CA. For the remainder of this article we will assume that an enterprise CA is used.

1. From the Start Menu on the terminal server, you click Run, type mmc and then click OK.
2. From the File Menu you click Add/Remove Snap-in.

Figure 1

3. Click Add. In the Add Standalone Snap-in window, you click Certificates, and then click Add.
4. Select Computer account, and then click Next.

Figure 2

5. Select Local computer (the computer this console is running on) and then click Finish.
6. In the Add Standalone Snap-in window, you click Close, and then click OK in the Add/Remove Snap-in window.
7. In the MMC console you click Certificates (Local Computer)
8. Select the View Menu, and click Options.
9. In the View Options dialog box you select Certificate purpose, and then click OK.

Figure 3

10. Locate Server Authentication in the right pane, click All Tasks, and then click
    Request New Certificate.
11. The Certificate Request Wizard starts. Click Next.
12. In the Certificate types list, you select Server Authentication or Computer depending on your Certificates Services setup, and select the Advanced check box, then click Next.

Figure 4

Note: If your certificate server is also a domain controller which is often the case with a Microsoft Small Business Server setup, then you should select Domain Controller Authentication from the list.

13. (This step and their options may vary depending on the certificate type).
    In the next window you see the Cryptographic Service Providers list. Here you select Microsoft RSA SChannel Cryptographic Provider. If available, leave the Key Length default option of 1024. And again, if available, you select Mark this key as exportable check box enabling you to copy the certificate to another computer if needed. Click Next.
14. Browse for the name of your Certification Authority in the CA box and click Next. Type a name for the certificate in the Friendly name box. Click Next, and then click Finish.

Configure the Terminal Services

Let us move on and enable TLS/SSL in terminal services on the server.

From Administrative Tools menu you start the Terminal Services Configuration Tools. In the left pane you click Connections. In the right pane you right-click RDP-Tcp, and select Properties.

Figure 5

First we need to select the certificate we created in the previous section.

Figure 6

1. In the General tab you click the Edit button.

Figure 7

2. Select the certificate and click OK.

Figure 8

3. Still in the General tab, you select SSL as the security layer and set the encryption level to High, then click OK.

The server is now ready, so let us move on to the workstation.

Configure the workstation

The first thing we need to do is configure the client to trust the CA responsible for issuing the server certificate on the terminal server. The best way to do this is by using a group policy, but for the sake of simplicity, we’ll install the trusted root CA on our client, using a web browser.

1. From a browser on your client, you enter the following URL:
   
   http://server/certsrv
   
   where server should be replaced with the computer name of the CA.

Figure 9

2. Click on Download a CA certificate, certificate chain, or CRL.
3. On the top of the screen, you click Install this CA certificate chain.

Figure 10

4. You may get prompted whether you trust the web site or not. Select Yes and then click Yes again to install the certificate.

The next thing we need to do on the client is upgrade the remote desktop client to version 5.2 or higher. If you use Windows Server 2003 with SP1 or Vista, then step 1 and 2 can be ignored.

1. As indicated in the prerequisites, you find the supported remote desktop client at the following location on the terminal server:
   
   %systemroot%\system32\clients\tsclient\win32\msrdpcli.msi
   
   Simply install the new remote desktop client from the above path.
2. (This step is optional). The new remote desktop client will not upgrade the built-in remote desktop client in Windows XP. So in order to avoid having two different versions of a remote desktop client installed on your computer, you simply copy the two files found in %ProgramFiles%\Remote Desktop to the following locations where you replace the existing files:
   
   %Systemdrive%\Windows\System32\dllcache
   %Systemdrive%\Windows\System32
   
   Note: Because of Windows File Protection, you may get prompted whether you want to replade the original files or not. Click Yes to verify that you want to overwrite the files.
3. Next you start the Remote Desktop client and select the Security tab which is a new tab that is included with the updated remote desktop client.

Figure 11

4. In the Authentication list you either select Attempt Authentication (recommended) or Require Authentication.

Figure 12

5. You can now connect and logon to the terminal server by entering the FQDN of the terminal server. Notice the small key lock on the upper-left corner, when running in full screen mode.
6. If you want to, try to test from a client that does not trust (or rather, does not have access to the certificate trust list) for the Certificate Authority in your infrastructure and see the difference. If you have configured your terminal server correctly, then non-trusted computers will be denied access.

Before you try it out

The steps covered in this article assume you are running terminal services in an Active Directory domain environment, and also running your own Microsoft based PKI. It should be noted however, that this is not a requirement, as long as you focus on the security when computers need to trust the CA hierarchy.

With the wrong configuration, a non-trusted computer will get an error message when trying to connect, but still be able to view the certificate on the terminal server. When you choose to view the certificate you also get the option to trust the issuing CA, even though the computer is not a trusted computer. And then you’ve gained nothing, except added complexity. So be careful how you make computers trust your certificate hierarchy.

Here’s what you need to do. Per default, the certificate trust list can be found in %systemroot%\system32\certsrv\CertEnroll and the file has the .CRT extension. This is also the file being downloaded, when you click on the “Download Certificate Trust Lists” on the web interface for Microsoft Certificate Services. Simply move the file to a protected location or ensure that only trusted users are allowed to read the CRT file.

In our example we used a mmc snap-in to request the certificate. You could just as well make an advanced certificate request from a browser and point to the default certificate website on your issuing CA. Another option could be the Certificate Request Wizard found in IIS, which is normally used for requesting SSL certificates.

If you already have an SSL certificate installed on the server for other purposes, then go ahead and use this certificate for your Microsoft Terminal Services. Just make sure that you still have control of who can trust your CA hierarchy, and also be aware that the URL associated with the existing SSL certificate will also be the FQDN to use when establishing a RDP connection to the terminal server, both from your internal network or the Internet.

External link: http://support.microsoft.com/kb/895433/en-us