To totally unlock this section you need to Log-in
Remote Desktop has been the must as remote administration tool for many IT professionals and sadly many even expose it to the internet leading to brutefoce attacks and Man in the Middle attacks in the past (and even during this period).
But now before viewing how to enable RDP encrypted connections, it is better to review some basic security considerations.
Updating the system
Remember those annoying updates notifications? They do come in very useful to ensure the security and stability of your operation system (among other things). The software used for RDP benefits from security updates from the developers on a constant basis, due to its crucial importance. If you’re using older Windows variants, consider switching to a newer one and that the update system is up an running.
Use very strong passwords (recommended would be more than 14 characters)
This is a general tip as using plain words are much easier to crack or guess. The best option here would be using a password of minimum 12 characters, lowercase and uppercase, a symbol and a number. Something like “Th1s1sMyP@$$WorD07” is fairly complex and rather secure as long as you do not store it in plain text or write it down somewhere in an unsafe place. Consider using Keepass, it’s a very useful tool with both linux, windows and android/iOS clients.
Check firewall configuration
By default, Windows has a fairly reliable firewall and easily configurable but some features are not required for workstation use such as file sharing rules , printer sharing or other non-used network features. It very much depends on what you are using it for.
An extra layer of security would be adding an IP range lock. Basically , this locks the RDP server to listen only to IPs specified in the desired IP range. This is a double-sided sword and use only if you are certain your IP address is fixed and does not change randomly like a dynamic one OR you have a VPS set as a connection gateway or vpn used solely to connect to your RDP. A bit overkill but there are even more intricate ways than this. The IP lock can be added at Windows Firewall > New Rule > Scope feature where the IP range can be defined.
Change RDP port
It is commonly known that Windows Remote Desktop port is 3389 and thus attacks are generally targeted at this port. A common practice would be to change it to a random free port and add the change to the firewall. Make sure you don’t get locked out during the process.
- Connect to the server via RDP
- Go to Windows Firewall > Advanced Settings > Inbound > New Rule > Port > TCP > Insert desired port here > Give it a name.
- Click on Start > Run > regedit
- Search for this subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
- Double-click on PortNumber > Select Decimal base > Type the port number > Press Ok
- Exit regedit
- Restart server
- Pray you have set the correct firewall rule or port and your provider offers VNC or KVM/IPMI access just in case.
Set a lockout policy
Further improving RDP security, Windows does offer the option to lockout RDP login for a certain period of time, after a certain number of incorrect guesses. This option is turned on by default but can be easily enabled.
- Go to Start > Programs > Administrative Tools > Local Security Policy
- At Account Policies > Account Lockout Policies > Account lockout threshold > Set this value to 3 > Confirm the next prompt of 30 minutes each (can be changed afterwards)
- Press Ok > Close Local Security Policy
- Restart the server.
A consideration about Self-Signed Certificate Warning
Let's say that we want to secure an RDP session: by default, Windows generates a self-signed certificate. During the first connection to an RDP/RDS host using the mstsc.exe client we will probably (surely) see the following warning:
The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed. Certificate error: The certificate is not from a trusted certifying authority.
To proceed and establish an RDP connection, we will have to click Yes, but if we want to prevent the RDP cert warning from appearing every time, even for other users or collegues that will probably use the same approach to connect to services and applications using RDP, we can check the Don’t ask me again for connections to this computer option.
When we click on the Don’t ask me again for connections to this computer option, the RDP certificate thumbprint will be saved in the CertHash parameter of the registry key with the RDP connection history on the client computer (the HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\ key).
If we want to reset the Don’t ask me again for connections to this computer option and show again the warning so "the RDP server could not be verified", we will need to remove the certificate thumbprint from the registry.
IMPORTANT NOTE: take always note that, even though a self-signed certificate is used to establish a connection, the RDP connection/session will be secure and the network traffic will be properly encrypted.
Step 1 - Creating the RDP Certificate Template
The first step about securing the RDP connections is to create a certificate template for this specific purpose on a Certification Authority (any AD domain has a CA available).
So, we can use an internal CA to issue a corporate SSL/TLS certificate and make it trusted at domain level. Using this certificate, we will be able to authenticate to an RDP server when connecting, in a secure way.
If we already have a corporate Microsoft Certificate Authority deployed in our domain we can configure automatic issue and connection of certificates to all Windows computers and servers in the domain, obviously.
First, we need to create a new type of certificate template for RDP/RDS hosts in your CA:
- Run the Certificate Authority console and go to the Certificate Templates node.
- Duplicate the Computer certificate template (Certificate Templates -> Manage -> Computer -> Duplicate).
In the General tab, specify the name of new certificate template – RDPAuth. Make sure that the value in the Template Name field matches the Template display name:
In the Compatibility tab, specify the minimum client version used in your domain (for example, Windows Server 2012 R2 for the CA and Windows 10 for your clients). Thus, stronger encryption algorithms will be used.
For RDP we need to make sure that the proper extensions are set so it will work on both Windows and other platforms for TLS. On the Extensions tab we click on Edit to modify the extensions for the certificate that will be issued.
We now select Client Authentication and click Remove. Leave the Server Authentication in this list.
After removing the Client Authentication policy we now click on Add and in the window that appears we click on New to create a new policy specific for use of RDP TLS.
Now, let's create a new policy, specifying a name like "Remote Desktop Authentication" and providing to it a Object Identifier (OID) of 1.3.6.1.4.1.311.54.1.2, that will identify the certificate as one that can be used to authenticate a RDP server.
Now, moving to the Security tab we need to identify those systems that can enroll using this new certificate template. Domain Computers is already present and with the Enroll permission but if you also plan to enable RDP on Domain Controllers add the Domain Controllers group and ensure the Enroll permission is selected.
Also, if we want to enable AutoEnroll for these systems (specially for Domain Controllers), to avoid to request manually new certificates for these systems before the certificates expires, we can assign to Domain Controllers, for example, also the Autoenroll permission:
Save/OK the certificate template.
If you have computers that are not able to enroll using the certificate template a quick way to identify it is a permission issue is to look in the Event Viewer and look under the System Windows Log for events with ID 1064 from the source TerminalServices-RemoteConnectionManager.
Now, in the Certificate Authority mmc snap-in, click Certificate Templates folder and select New -> Certificate Template to Issue -> choose the template you have created (RDPAuth):
Deploy RDP SSL/TLS Certificates (Active Directory GPO)
Now we need to configure a domain GPO to automatically assign RDP certificates to computers/servers according to the configured template we have previously created.
We need to open the Domain Group Policy Management console (gpmc.msc), create a new GPO object and link it to the OU containing RDP/RDS servers or computers to automatically issue TLS certificates to secure RDP connections.
We need to move to the following GPO section Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security.
Then we enable the Server Authentication Certificate Template policy, specifying the name of the CA template we have created earlier (RDPAuth).
It is supposed that all domain computers trust the corporate Certificate Authority, so the root certificate has been added to the Trusted Root Certificate Authorities using GPO.
Then in the same GPO, we enable also the Require use of specific security layer for remote (RDP) connections policy and set the value SSL for it:
While under security settings we also recommend enabling NLA since this and TLS will break most public RDP brute forcing tools. Select Require user authentication for remote connections by using Network Level Authentication policy and double click on it. On the Properties screen select Enable and clicking on OK.
To automatically renew an RDP certificate, we need to move to the Computer configuration -> Windows settings -> Security Settings -> Public Key Policies section of the GPO and enable the Certificate Services Client – Auto-Enrollment Properties policy: now we will enable the Renew expired certificates, update pending certificates and remove revoked certificates and Update certificates that use certificate templates options.
Another policy to consider, since we do not want users to simply accept and always trust RDP server replies (since this would defeat the purpose of all these settings) we want to ensure that clients always validate the server certificate, and to do this we will have to select, always in the same GPO we are defining, Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client, the we need to Enable the Configure Authentication for Client and select the Warn me if authentication fails option.
To track what systems have enrolled and have the certificates deployed you can open the Certificate Authority management console and user Issued Certificates you will be able to see the certificates currently issued.
Another way to get a list of issued certificates, on a CA server, is to use the PSPKI PowerShell module available in at https://github.com/PKISolutions/PSPKI this allow us to export the data in to a CSV, XML, HTML or use it inside of scripts.
To list all certificates that where issued and are valid for the RDPAuth Template we use the Get-IssuedRequest cmdlet and set a filter for the template name.
Get-CA | Get-IssuedRequest -Filter "CertificateTemplate -eq RDPAuth"
Once all is done, update group policy settings on the client computer, by using gpupdate /force fo example, launch the Local Computer certificate console (certlm.msc) and make sure that the Remote Desktop Authentication certificate issued by your CA has appeared in the Personal -> Certificates section.
When connecting to a server using RDP, you won’t see a request to confirm that the certificate is trusted (to see the request, connect to the same server the certificate is issued for using its IP address instead of the FQDN, so the Remote Desktop Client will show again the warning, now expected). Click View certificate, go to the Details tab and copy the value in the Thumbprint field.
The same Thumbpint can be checked, even with the Requester Name(the client which requested this certificate type) by using the Issued Certificates section of the Certification Authority console (on the CA server, not the client); in this way we can make sure that an RDPAuth (like in this example) certificate has been issued for the specific Windows server/computer.
Finally, we can compare this thumbprint with the certificate thumbprint used by the Remote Desktop Service, always on the server.
We can view the value of the RDS certificate thumbprint (the certificate template thumbprint) in the registry (HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations, the TemplateCertificate parameter) or using the following PowerShell command:
Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices|select SSLCertificateSHA1Hash
Firewall Configuration
We will now enable the firewall rule allowing RDP on the host, so we go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Windows Firewall with Advanced Security -> Inbound Rules and right click on it and select New Rule:
Now we will use predefined rules, but in a production environment it would be better to consider the creation a custom rule for TCP and UDP port 3389 and limiting it to a set of management hosts or to a subnet where management systems reside so as mitigate the risk of lateral movement in the case of a compromise.
But for now we select Predefined and from the dropdown menu select Remote Desktop.
Once finished you can close the GPO and wait for the client computers to apply the policy or forcing an update by using gpupdate /force on a client testing machine to check proper execution of the GPO rules.
Deploying CA Template Certificate other platforms
MacOS
On a MacOS system, to add the certificate on the system store to be able to validate that your connection is not being intercepted using RDP client, we will need to have the Certificate Enrollment Web Service role installed on the CA server. To do so, we will have to use a web browser to download the needed CA certificate using our web browser by navigating to https://host name or IP/Certsrv, providing our domain credentials and selecting the link Download a CA certificate, certificate chain or CRL.
A window will appear asking we where do we want to add the certificate to your keychain. If we want it only for the current uses under keychain select login, if you want it to be available to all users select system and click Add.
After that we will be asked if we want to trust or not the certificate. Click on Always Trust. Let's note that, when using the Remote Desktop Client, we need to make sure to use FQDN when specifying the PC name.
Android
For this you will need to have the Certificate Enrollment Web Service role installed so we can use your browser to download the CA certificate using the web browser by navigating to https://host name or IP/Certsrv provide your domain credentials and select the link Download a CA certificate, certificate chain or CRL.
By selecting install CA certificate link a window will appear asking for a name for the certificate. Let's provide one and click on OK to confirm.
We will get a warning on the certificate. This is normal since it is a CA certificate only available for the actual user and not trusted by the system.
Just like on MacOS X we will need to use a FQDN on the PC Name field while connecting to the RDP remote server/computer.
iOS
On iOS the process is similar to all other system seen above, where we navigate to the certificate enrollment web service and Authenticate.
When we download click on the CA download link we will be moved to a screen where we will see the details of the certificate and we can press Install.
We will be asked for the passcode of the phone to make sure it is you the owner the one that wants to add the certificate; after that it will provide a warning explaining the dangers of installing untrusted CA certificates on the device. Click on Install it will aks again and put the word Install in red so as to make sure it is something you want to do.
After this we will now see that the certificate is trusted and you can use the Microsft Remote Desktop Client app to connect to hosts with RDP enabled. Remember just like with previous examples you need to use FQDN for the PC name field.
Using RDPSign for RD Farm profiles
A .rdp file is a basically a simple file (filled with parameters) that defines the connection settings for a Remote Desktop or RemoteApp session. You can easily edit, copy and distribute it.
Let's say we want to deploy RDP files for one or more applications deployed on a RDS infrastructure, but once deployed they get the following screen (we have obviously already deployed a trusted certificated for all RDS roles):
Take note also that when we open the remote desktop connection client (mstsc.exe) and type in the FQDN address of the farm we will get no errors.
This behavior is expected because, when we save an RDP file, with all the settings, the file itself is not signed in any way, and therefore not trusted.
We can solve this situation, removing this warning on RDP files, by going on a server where we have already installed the certificates in the Personal Certificate store, opening the certificate, and finding its thumbprint value, in the Details tab.
Once copied the thumprint value, and go to a command prompt and we will type the following (the hash must have no spaces):
rdpsign /sha256 <hash> <your-rdp.file.rdp>
The parameter /sha256 is only available in Windows Server 2016 and Windows 10 and above; before that, it was named /sha1. Therefore, if you are following this on a prior version of Windows, you will need to pass in a Signature Hash Algorithm SHA-1 encoded certificate rather than a Signature Hash Algorithm SHA-256 certificate.
Now we can distribute the RDP file to your users by mail , script or GPO and when they try to connect the next time, they will see the following (no warning):
NOTE: if we want to avoid even the above prompt entirely, we can add the SHA-1/SHA-256 thumbprint into the following GPO setting, Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers located under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client. In this kind of GPO we will need to specify the hash also without spaces and in uppercase mode; we can do this easily in Powershell with the following approach:
("{SHA1 or SHA256 Hash").ToUpper().Replace(" ","")
If you attempt to sign an RDP file with an SHA-1 certificate on the newer version of Windows, you will encounter the following error:
Unable to use the certificate specified for signing. Error Code: 0x8007000d The rdp file could not be signed. Error Code: 0x8007000d
One additional note is that you can sign multiple files by passing in additional RDP files to sign.
rdpsign.exe /sha256 651CDD504EDDFF9A852BB0233018C9850731A880 <Path to RDP File 1> <Path to RDP File 2> <Path to RDP File 3>
If any files fail to sign, the tool will proceed to the next one.
If you want to verify that the RDP shortcut has been signed, you can open the shortcut in Notepad and look for the following lines:
*signscope:s:Full Address,Alternate Full Address,Use ….* *signature:s:signatureishere*
Generally, the higher a version of rdpsign.exe you use, the more backward compatible the shortcut file will be. So use the newest version of rdpsign.exe that you have access to.
 |