Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks

[MicrosoftSecurityandComplianceTeam]

First published on CloudBlogs on Jul, 21 2008

General Intro

“Man In The Middle (MITM) attack” is a term used to describe a class of security vulnerabilities in which an attacker intercepts communication between two parties and impersonates each one to the other. The attacker can view and/or modify the traffic without the two parties knowledge. As a result, a user might be tricked into entering his credentials on a spoofed server. Even though RDP traffic between the client and server is encrypted, the attacker can potentially bypass RDP encryption if he is able to get the keys used to establish the session. Thus, server authentication is necessary to prevent MITM attacks.

Significant improvements in authentication and security have been made in Terminal Services that can protect against such attacks. Terminal servers running Windows 2003 Server SP1 and later support the ability for a TS client to authenticate a TS server, which protects against MITM attacks. In Windows 2003 Server SP1 and later, you can configure the TS server with a SSL/TLS server certificate that will allow the client to verify the server’s identity. In Windows Server 2008, Network Level Authentication (NLA) is designed to be secure against MITM, and it supports the ability to authenticate the server with either a SSL/TLS server certificate or Kerberos.

Terminal servers running Windows 2003 Server without SP1 or earlier do not support a clients’ ability to authenticate the terminal server. With these earlier versions, you must ensure that your network is tamper-proof by using network level protection mechanisms (for example, IPSec) in order to protect against MITM attacks.

Server authentication mechanisms that can protect against MITM attacks

1. Network Level Authentication (NLA): NLA uses the Credential Security Support Provider (CredSSP) Protocol to perform strong server authentication either through TLS/SSL or Kerberos mechanisms, which protect against MITM attacks. In addition to improving authentication, NLA also helps protect the remote computer from malicious users and software by completing user authentication before a full RDP connection is established; an additional benefit is that fewer resources are used on the remote computer prior to authentication. Please see this MSDN article or the protocol specification for more details on the CredSSP protocol.

NLA with Kerberos

This is one of the most secure server authentication schemes for protecting against MITM. Both client and server should be a part of the same or a trusted domain.

NLA with TLS/SSL

There are scenarios in which Kerberos cannot be used for server authentication, which include:

o Terminal server farms, because farms do not have a Kerberos identity in Active Directory

o Internet connection scenarios (for example through TS Gateway), in which the client does not have access to Key Distribution Center (KDC)

o The terminal server is not domain-joined

In such scenarios where Kerberos cannot be used for server authentication, deploying SSL/TLS certificates that are issued by a trusted Certificate Authority will enable the client to identify the server’s identity and protect against MITM attacks. You will need to deploy these certificates to each TS server on which you want to have server authentication and ensure that they have the server name in the Subject field.  To set the SSL certificate for a connection on Windows Server 2008:

1. At a command prompt, run tsconfig.msc. (Note: tsconfig.msc is only available on Server SKUs.)

2.  Double-click the RDP-TCP connection object.

3.  On the General tab, click Select .

4.  Select the certificate you want to assign to the connection, and then click OK .

5. Please see this TechNet article on configuring trusted rdp publishers on the client side via Group Policy.

NLA with NTLM

If SSL/TLS certificates are not configured on the server and Kerberos authentication is not possible due to the reasons stated above, CredSSP will use the NTLM authentication mechanism to establish trust between the client and server. NTLM can verify a target server’s domain membership; however, if you would like to ensure strong server authentication, you must disable allowing credential delegation with NTLM-only server authentication. To disable these policies on Windows Server 2008, follow these steps:

a. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.

b. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

c. Ensure the following policies for NTLM-only server authentication are disabled:

i. “Allow Default Credentials with NTLM-only Server Authentication”

ii. “Allow Fresh Credentials with NTLM-only Server Authentication”

iii. “Allow Saved Credentials with NTLM-only Server Authentication”

2. Pure SSL/TLS is a standard mechanism that enables clients to authenticate to servers and provides a secure channel by encrypting communications. To use SSL/TLS, you must obtain certificates issued by a trusted Certificate Authority and configure them on each terminal server on which you want to have server authentication.

a. See steps above for setting SSL certificates on Windows Server 2008.

b. See this Knowledge Base article for information on how to configure Windows Server 2003 SP1 to use TLS for server authentication.

3. Network Level Protection mechanisms can be used to mitigate MITM attacks when the server OS version does not support NLA or pure SSL/TLS server authentication mechanisms. For example, you can configure IPSec policies on these earlier versions of TS in order to get mutual authentication and protect RDP traffic against MITM attacks.

a. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

b. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

4. A virtual private network (VPN) tunnel can be set up to secure your connection and prevent MITM attacks when users are connecting to servers on your network via the Internet. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Mitigation mechanisms supported on different Server OS versions

The table below provides a summary of mitigation mechanisms available for various server OS versions and corresponding clients.

	Server OS Version
Client OS	Windows Server 2000, 2003 Windows Server 2003 SP1 / R2 Windows Server 2008
Windows XP SP2 and earlier	Network Level Protection or VPN Pure SSL/TLS Pure SSL/TLS
Windows XP SP3*, Windows Vista, Windows Vista SP1	Network Level Protection or VPN Pure SSL/TLS NLA or Pure SSL/TLS

* Windows XP Service Pack 3 now supports NLA; therefore if you have Windows Server 2008 in your environment, it is strongly recommended that you upgrade to Windows XP SP3 or later in order to take advantage of Network Level Authentication. See this Knowledge Base article for more details on upgrading to TS Client 6.1 with Windows XP SP3.

· Note that CredSSP is not enabled on Windows XP SP3 by default; therefore you will also need to perform the steps outlined in this KB article to turn on CredSSP.

· Also note that even though RDP Client 6.1 is available on Windows XP SP2 now, NLA is still not supported on Windows XP SP2.

Windows Server 2003 SP1 and higher

Strong server authentication, which prevents MITM attacks can be achieved on Windows Server 2003 SP1 and higher, using the two server authentication mechanisms described above. Pure SSL/TLS can be used for Windows Server 2003 SP1 and Windows Server 2008. In addition, Windows Server 2008 uses NLA for clients that support it.

Earlier Server OS versions prior to Windows Server 2003 SP1

As shown in the table above, TLS/SSL certificates can only be deployed on Windows Server 2003 SP1 and later, while NLA is available only on Windows Server 2008. Windows Server 2003 without SP1 and earlier does not support NLA or pure SSL/TLS server authentication mechanisms. Therefore, on earlier Server versions, you will need to use network level protection mechanisms (such as IPSec) to get mutual authentication and protect RDP traffic against MITM attacks. Alternatively, you can set up a VPN tunnel for your connection.

1. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

2. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

3. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Client SKU used as a TS server

If you are connecting remotely to client operating systems, then only Windows Vista and Windows Vista SP1 that support Network Level Authentication will be able to provide strong server authentication with Kerberos as Windows Server 2008 described above. NLA with SSL/TLS is not possible on Client SKUs. On a downlevel client OS, you can configure VPN to secure your communications. See this KB article on configuring VPN on Windows XP.