• Secure access to your RDS infrastructure
• Restrict remote desktop access

When you set up a RDS infrastructure (which is based on the Microsoft RDP protocol), it's important to secure it as much as possible to avoid hacker attacks and/or theft of confidential data.
For this, it's possible to secure the authentication of the RDP protocol in various ways and in particular through the use of SSL certificates.

Indeed, on Windows Server 2012 and 2012 R2, it's possible and recommended to use the SSL security layer (TLS 1.0) which allows the server to be authenticated before sending data to this server.
This means that if an attacker tries to trick the user with a fake server, the client PC will be able to detect this phishing attempt and will not communicate with this fake server.
This will prevent your users from sending their credentials (username / password) to a fake server.

1. Enable the server authentication with SSL (TLS 1.0)
   1. Use SSL (TLS 1.0) for server authentication (via GPO)
   2. Use SSL (TLS 1.0) for server authentication (via the server manager)
2. Enable Network Level Authentication (NLA)
   1. Enable Network Level Authentication (NLA) through GPOs
   2. Enable Network Level Authentication (NLA) through the Server Manager
3. Check server authentication

1. Enable the server authentication with SSL (TLS 1.0)

1.1. Use SSL (TLS 1.0) for server authentication (via GPO)

To enable the use of SSL (TLS 1.0) for RDP authentication on your session hosts, you have 2 options :

• to set the correct group policy through your Active Directory server
• or do it on each session host server via the server manager

However, be aware that group policies has priority over the setting available in the server manager.

On your Active Directory server, open Group Policy Management and go to : Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security.

Then, double-click on the "Require use of specific security layer for remote (RDP) connections" policy.

Enable this policy and select "Security layer : SSL (TLS 1.0)".

As you can see, you have the choice between 3 options :

• Negotiate : which corresponds to the "Client compatible" option which allows to choose the best method according to what is supported by the client and by the server.
  This option is useful for compatibility, but some clients may not authenticate the server before connecting to it and therefore sending their credentials to a fake server.
• RDP : this is the classic RDP method that uses weak encryption and the server will not be authenticated
• SSL (TLS 1.0) : which allows you to authenticate the server in a secure way thanks to a SSL certificate and which is supported since Windows XP (as indicated on the Microsoft "Support for SSL/TLS protocols on Windows" page)

In production, since all your clients will be compatible with this SSL (TLS 1.0) security layer, we strongly recommend that you enable it.

However, be aware that this requires the use of a valid certificate that you can create for free through a Windows Server certification authority and import the generated certificate from the server manager.

Once you have set up this Group Policy, be sure to update the security policy for your session host servers :

Batch

gpupdate /force

1.2. Use SSL (TLS 1.0) for server authentication (via the server manager)

If you want to change the security layer to use on each session host server, open Server Manager and go to Remote Desktop Services -> Collections -> [Collection name] -> Tasks -> Edit Properties.

In the "Security" section, you will find the same options :

• RDP security layer : weak encryption and NO server authentication. So, possibility to send his credentials to a pirate server without knowing it.
• Negotiate : this poses a security problem, since the remote server may not be authenticated and can be replaced by a hacker server without your user knowing it.
• SSL (TLS 1.0) : allows you to secure the RDP authentication and to authenticate the remote server to avoid fakes servers.

Select "SSL (TLS 1.0)" and click OK.

Important : this security layer requires the use of a valid certificate on the session host server. As explained in our tutorial : RDS - Deploy a RDS infrastructure (session-based desktops)

2. Enable Network Level Authentication (NLA)

When NLA is not enabled, Terminal Server sessions are created entirely in the background as soon as someone tries to connect to one of your session hosts.
Which means that if a hacker or a malicious person launches a DDOS attack on your server with a long list of bad identifiers, your server will consume unnecessarily a lot of resources to create its Terminal Server sessions in the background.
The DDOS attack may therefore make your server inaccessible or very slow, while the identifiers used were not even valid.

To avoid such attacks, Microsoft has created the NLA which consists of checking the credentials used by the user before creating the session in the background. Thus, if an attacker tries to connect with false identifiers, the session will not be created in the background and his connection attempt will be directly refused.

2.1. Enable Network Level Authentication (NLA) through GPOs

To enable Network Level Authentication (NLA) through Group Policies, you must enable this policy : Require user authentication for remote connections by using Network Level Authentication.
This policy is available in : Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security.

Enable the policy, and then exit the Group Policy Editor and force the policy update of your session hosts.

2.2. Enable Network Level Authentication (NLA) through the Server Manager

If you want to enable Network Level Authentication (NLA) through the properties of each collection, be aware that this is already enabled by default.
Nevertheless, if you are looking for this parameter, go to the properties of each collection.

In the "Security" section, you will see that the NLA is already enabled by default with the "Allow connections only from computers running Remote Desktop Services with Network Level Authentication" box.

3. Check server authentication

From a client computer, launch a desktop published on your RDS infrastructure.

Once connected, you will see a small padlock in the blue bar at the top of the screen.
By clicking on this small padlock, you will see that the identity of the remote computer was verified by using Kerberos.

Click on "View certificate" (if possible).

As you can see, our certificate :

• ensures the identity of a remote computer (in this case : our RDS session host server)
• is issued to : RDS.informatiweb.lan
• is issued by our local certification authority : InformatiWeb CA

In the Details tab, you will find that this server is used for server authentication.

Note that this certificate is considered valid because the certificate of our CA is part of the trusted certificate authorities of our client computers.