Windows Server Remote Desktop Services

RSAT lets IT admins manage Windows Server roles and features from a Windows 10 PC.
Allow remote connections. Create users who will connect by remote desktop. Next, we will create the users who will be able to connect remotely to the server. We will then add these users to the corresponding group.

How to enable Remote Desktop (RDP) on Windows server 2012

Each user or device accessing a licensed Windows Server requires a Windows Server CAL or a Windows Server and a Remote Desktop Services (RDS) CAL. With the User CAL, you purchase a CAL for every user who accesses the server to use services such as file storage or printing, regardless of the number of devices they use for that access.

Intro:

In this how-to we will walk you through on How-To Enable RDP in Windows Server 2012.

Remote Desktop Protocol (RDP) is a protocol expanded by Microsoft that allows you to connect and control another computer via an existing network making it a remote connection.

Keep in mind that you can also use consle access to your server from VPSie console in case of emergencies as needed or to modify/configure RDP or network settings.

Prerequisites

A Server with Windows Server 2012. If you do not have a server already, you can create and spin a new server up in under 2 minutes.
RDP client from remote machine – this can be native windows RDP client on windows or MAC client such as 2X parallels client.

Enable RDP in Windows Server

Open the Server Manager from the taskbar/ Click on Local Server / Locate Remote Desktop under Properties which is currently Disabled and Click on Disabled

Server managerSystem Properties window will appear. Select Allow remote connections to this computer and its recommended to check the box below.System allow screen

You can also add specific users in the Select Users tab. By default, the administrator is allowed. You can add other users by clicking Select Users/ Click Add/ insert a username and click OK.

Remote Desktop username to allow – administrators already have access.

You can now verify that RDP is enabled and you can see that the status went from Disabled to Enabled.

Confirm

Also make sure Firewall rules has been updated to allow incoming traffic – easiest way for testing is to disable firewall completely from control panel :

Go to Control Panel -> System and Security -> Windows Firewall

Click on the left sidebar the link:

Turn Windows Firewall on or off

and then select for each level to turn it on or off.

The last thing I want to to say, either you are getting dirty hands on linux or windows, do not turn off firewall. You can disable it for a while or for testing purposes, but if you want to stay secure ( as secure as you can ) do not turn it off.

Note: It’s recommended to add firewall rules to allow traffic as needed rather than disabling it however for quick test that would be easier – to accomplish this :

Enable the rule that permits access through the Windows Firewall.

1. Search for Firewall and open “Windows Firewall and Advanced Security”.

2. Find the rule “Remote Desktop – User Mode TCP-in” and ENABLE Rule

Congratulations! You have just Enabled RDP in Windows Server 2012. Thank you for following along in this How-To and check back with us for any new updates.

We are constantly adding new apps as they are demanded by our users to insure a smooth and easy integration that would lead to a better overall user’s experience .

Try any of these one click Apps free for one full month today!

As systems administrators we are often tasked with implementing countermeasures to mitigate risks that we can’t completely address. The intent of this post is to cover methods of reducing the risk presented by having Remote Desktop Services (formerly Terminal Services) available on the network.

The risks that I will cover are:

Man in the Middle attacks
Sniffing / Traffic capture
Brute Force Attacks
Information Disclosure

This post was updated 2019.05.28 to fix broken links, add commentary for Windows 2016 and Windows 2019, and add instructions for enabling CredSSP for WinXP as a client since the Microsoft link is dead.

Threats

Man in the Middle (MitM) attacks

The essential premise here is that an attacker, via a couple methods, can cause RDP traffic to flow through a host he controls. This allows the attacker to view the traffic [1] and in some cases manipulate it to reduce the security level negotiated between the server and client.

Sniffing / Traffic capture

An attacker does not necessarily need to be a part of client/server communications in order to see traffic. There are a variety of techniques that allow an attacker to record the network traffic at the client, server, or on the network. Even if this traffic is encrypted with TLS there are methods of leveraging compromised TLS (x.509) certificates to perform offline attacks against the packet capture [2].

Brute Force Attacks

There are multiple tools such as Hydra [3] and ncrack that will attempt to try combinations of usernames and passwords in an effort to determine valid credentials. These attacks, while typically very noisy, can be very fast and effective. They have the downside of potentially causing a denial of service as well. This is due to the target RDS server allocating resources for the user before they log in. It is not unusual to see a poorly crafted brute force attack consume 100% of the target’s CPU by trying to attempt too many connections simultaneously.

Information Disclosure

Unauthenticated RDP connections to servers can expose sensitive information about the target environment. Usernames, domain names, and potentially other hosts of interest to the attacker can be displayed after the connection. The screen shot on the right below ( click to enlarge) shows that the user logged in as Administrator is connected from WinServer01. Management servers and workstations are often a treasure trove of credentials and typically have more access to bypass firewalls than most other hosts.

Mitigation

The good news is that mitigating these risks can be done by changing 3 settings. The changes are compatible with every supported Microsoft operating system and many 3rd party RDP clients. The settings can be changed via GUI, PowerShell, and Group Policy.

Set the Security Layer to SSL (TLS 1.0)

Note: TLS is enabled by default for Windows 2012 and higher. Also, despite saying TLS 1.0 this setting uses the versions of TLS supported by the OS and will try negotiate the highest TLS version that the server cipher suite configuration will permit.

This setting requires the use of TLS 1.0 or higher encryption to protect the session as opposed to the legacy RDP encryption. In addition to increasing the strength of the encryption, it also enables the detection of MitM attacks by requiring the server to present a TLS (x.509) certificate as proof of identity. Ideally every server would have a certificate issued from a trusted authority but even when using self-signed certificates this can allow observant users to detect MitM after the first connection. If both the client and the server support and require the use of TLS cipher suites that provide Forward Secrecy (ECDHE, DHE) then sniffed RDP sessions cannot be decrypted after the fact even if the RDP Server’s TLS certificate is compromised. Further, any efforts spent hardening the TLS configuration of the server or client will result in better security for their RDP sessions.

In the right environment, this setting will completely mitigate MitM and sniffing risks. It also provides the benefit of being able to assure stake holders and interested 3rd parties such as customers and auditors that their traffic is being protected using well known and widely accepted encryption.

Enable Network Level Authentication (NLA)

Note: NLA is enabled by default in Windows 2012 and higher.

Network Level Authentication requires a user connecting via RDP to authenticate before a session is allowed to be established to a server. It can leverage Kerberos, NTLM, and PKI for authentication when those technologies are available. Additionally, due to its use of the Microsoft CredSSP protocol, all of the traffic during the session is sent over TLS 1.0 or higher. This effectively enforces the Security Layer setting discussed above and all that it entails.

The use of NLA completely mitigates the Information Disclosure issue as described above, and currently breaks all of the popular RDP brute force tools.

Set the Encryption Level to High

By default, Windows allows the server and client to negotiate the encryption level. Setting Encryption Level to ‘High’ requires that at least 128 bit encryption is used or the server will not allow the client to connect. Depending on the requirements of the environment, Encryption Level can be set to FIPS instead. This setting doesn’t directly address one of the risks above but may make it more resilient to unforeseen downgrade attacks against the deployed cryptography.

Deployment

The settings can be deployed to the environment in a couple of ways.

GUI

On Windows 2003 and 2003 R2 the values can be change via the GUI by going to Start, Administrative Tools, Remote Desktop Services, and then clicking Remote Desktop Session Host Configuration. Under Connections, right click on RDP-tcp and click Properties. All of the settings covered above can be configured on the General tab of the resulting window. Once the desired settings are in place, click Apply. This change takes effect immediately but does not affect any sessions currently connected. This will allow the new settings to be reverted easily if testing shows that they cause problems.

The location of this GUI in Windows 2008 is Start, Administrative Tools, Terminal Services, and then clicking Terminal Service Configuration. Under Connections, right click on RDP-tcp and click Properties.

For Windows 2008 the default settings are Security Layer: Negotiate, Encryption level: Client Compatible, and NLA: Not required.

It is worth noting that if you go to Server Manager, Configure Remote Desktop that you will be presented with fewer options.

On Windows Server 2016 and 2019 NLA can be configured by going to Server Manager, Local Server, and then clicking on Remote Desktop in the Properties section on the right.

The PowerShell code snippet below will configure all three settings discussed above. It requires local Administrative rights and is known to work on Windows 2008 R2, 2012 R2, 2016, and 2019. Information on the values can be found in References [5] [6] and [7] at the bottom of this blog entry.

Group Policy

The previous two options are good for testing and configuring non-Active Directory joined systems but will not scale usefully. Deployment in Active Directory environments can be performed using Group Policy. I recommend creating a GPO just for these settings so that they can be deployed for testing or in stages. All of the relevant settings can be found under Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity.

Potential Issues

There are a couple of concerns to be aware of. First, for those in the unfortunate position to still have to support Windows XP clients there are some steps you need to take.

Upgrade to Service Pack 3
Enable CredSSP on Windows XP Service Pack 3
1. Click Start, click Run, type regedit, and then press ENTER.
2. In the navigation pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
3. In the details pane, right-click Security Packages, and then click Modify.
4. In the Value data box, type tspkg. Leave any data that is specific to other SSPs, and then click OK.
5. In the navigation pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProviders
6. In the details pane, right-click SecurityProviders, and then click Modify.
7. In the Value data box, type credssp.dll. Leave any data that is specific to other SSPs, and then click OK.
8. Exit Registry Editor.
9. Restart the computer.
Install Remote Desktop Client 7.0 (last to support Windows XP) [9]

Note: While Windows XP can be configured as a RDP server it does not support CredSSP (NLA) in server mode.

Second, always be aware that the risks in any environment are dynamic even if there are no changes to the configuration or software. NLA defeats brute force attempts today, but this may change tomorrow if Hydra is updated to support CredSSP. Like any other control, implement it if it is appropriate, test it to make sure it’s working, assume it will be insufficient without warning at some future date, and layer it with other controls and detection mechanisms.

There are quite a few resources that cover this topic and I will link to many of them in the references section below. For those of you wishing to implement these settings in conjunction with an internal PKI I strongly recommend Carlos Perez’s blog post from 2012 titled Configuring Network Level Authentication for RDP and a post from 2015 titled RDP TLS Certificate Deployment Using GPO. I wish that I had been aware of them when I was implementing this in my environments. Also, the Microsoft Remote Desktop Services Blog has an article from 2008 titled Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks that discusses NLA in conjunction with Kerberos and NTLM.

– Tom Sellers

References

1. Portcullis Labs – SSL “Man-In-The-Middle” attacks on RDP example: https://labs.portcullis.co.uk/blog/ssl-man-in-the-middle-attacks-on-rdp/

2. Portcullis Labs – Retrospective decryption of SSL-encrypted RDP sessions: https://labs.portcullis.co.uk/blog/retrospective-decryption-of-ssl-encrypted-rdp-sessions/

3. THC Hydra: https://github.com/vanhauser-thc/thc-hydra

4. TechNet – Configure Security Settings for Remote Desktop Services Connections : https://technet.microsoft.com/en-us/library/cc753488.aspx

5. Developer Network: SetEncryptionLevel method of the Win32_TSGeneralSetting class: https://msdn.microsoft.com/en-us/library/aa383800(v=vs.85).aspx

6. Developer Network: SetSecurityLayer method of the Win32_TSGeneralSetting class: https://msdn.microsoft.com/en-us/library/aa383801(v=vs.85).aspx

7. Developer Network: SetUserAuthenticationRequired method of the Win32_TSGeneralSetting class: https://msdn.microsoft.com/en-us/library/aa383441(v=vs.85).aspx

Remote Desktop Services Windows 10

8. Microsoft Support – Enabling CredSSP on Windows XP SP 3 (DEAD LINK, LEFT FORREFERENCE) – http://support.microsoft.com/kb/951608

9. - Remote Desktop Client 7.0 (last to support Windows XP SP3 ): http://support.microsoft.com/kb/969084

10. TechNet – Configure Network Level Authentication for Remote Desktop Services Connections: https://technet.microsoft.com/en-us/library/cc732713.aspx

11. TechNet – Secure RDS (Remote Desktop Services) Connections with SSL: https://technet.microsoft.com/en-us/magazine/ff458357.aspx

12. Developer Network – [MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting: https://msdn.microsoft.com/en-us/library/cc240445.aspx

13. Developer Network – [MS-CSSP]: Credential Security Support Provider (CredSSP) Protocol: https://msdn.microsoft.com/en-us/library/cc226764.aspx