Enabling SSL for Remote Desktop

5,348

From TechNet:

A certificate is needed to authenticate an RD Session Host server when SSL (TLS 1.0) is used to secure communication between a client and an RD Session Host server during RDP connections. You can select a certificate that you have already installed on the RD Session Host server, or you can use the default self-signed certificate. You can enable SSL for Remote Desktop connections using the RDP-Tcp Properties dialog box, which is accessed from the Remote Desktop Session Host Configuration snap-in.

By default, Remote Desktop connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Remote Desktop Connection client application do not support this high level of encryption. If a high level of encryption is needed to support legacy clients, the encryption level of the connection can be configured to send and receive data at the highest encryption level supported by the client.

There are four levels of encryption available:

Low
Data sent from the client to the server is encrypted using 56-bit encryption. Data sent from the server to the client is not encrypted.

Client Compatible
Encrypts client/server communication at the maximum key strength supported by the client. Use this level when the terminal server is running in an environment containing mixed or legacy clients. This is the default encryption level.

High
Encrypts client/server communication using 128-bit encryption. Use this level when the clients accessing the terminal server also support 128-bit encryption. When encryption is set at this level, clients that do not support this level of encryption will not be able to connect.

FIPS Compliant
All client/server communication is encrypted and decrypted with the Federal Information Processing Standards (FIPS) encryption algorithms. FIPS 140-1 (1994) and its successor, FIPS 140-2 (2001), describe U.S. government requirements for encryption.

The RDP-Tcp Properties dialog box, which is accessed from the Remote Desktop Session Host Configuration snap-in, allows you to configure the encryption level.

Share:
5,348

Related videos on Youtube

Ryan
Author by

Ryan

Updated on September 18, 2022

Comments

  • Ryan
    Ryan over 1 year

    Ok so I'm trying to remove a number of my systems from our Nessus scan from having this medium vulnerability.

    Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness

    I set the following GPO setting:

    Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Require Use of Specific Security Layer for Remote (RDP) Connections: SSL (TLS 1.0)

    Once I do this my Windows 7 clients no longer have the Nessus problem however RDP no longer works from Linux or Windows clients. I get the following errors:

    From clients:

    Linux:

    [ryan@gobo ~]$ rdesktop -0 win7
    Autoselected keyboard map en-us
    ERROR: recv: Connection reset by peer
    

    Windows:

    "the connection cannot proceed becuase authentication is not enabled
    

    One the server system (Windows 7 box running RDP):

    Log Name:      System
    Source:        TermDD
    Date:          4/9/2012 4:28:58 PM
    Event ID:      50
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      gobo-vm
    Description:
    The RDP protocol component X.224 detected an error in the
    protocol stream and has disconnected the client.
    

    and this one:

    Log Name:      System
    Source:        Schannel
    Date:          4/9/2012 4:07:54 PM
    Event ID:      36870
    Task Category: None
    Level:         Error
    Keywords:      
    User:          SYSTEM
    Computer:      gobo-vm
    Description:
    A fatal error occurred when attempting to access the SSL server 
    credential private key. The error code returned from the 
    cryptographic module is 0x8009030d. The internal error state is 
    10001.
    

    I've seen solutions on this being a permission problem with the cert, as in the Network Service account doesn't have permission to access it but I can't find where the cert is on the filesystem to check it.

    Other than that I'm out of ideas/options. I look for the wise here.