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.
To enable the use of SSL (TLS 1.0) for RDP authentication on your session hosts, you have 2 options :
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 :
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 :
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 :
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)
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.
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.
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.
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 :
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.
Windows Server 6/7/2019
Windows Server 3/8/2019
Windows Server 4/28/2019
Windows Server 3/16/2019
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - All rights reserved.
Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.335-2 and following of the intellectual property Code.