Not so long ago, we implemented a solution on a Windows terminal server. As usual, they threw shortcuts for connecting to the desktops of employees, and said - work. But users turned out to be intimidated by Cybersecurity. And when connecting to the server, seeing messages like: “Do you trust this server? Exactly, exactly? ”, They got scared and turned to us - but is everything okay, can I click on OK? Then it was decided to do everything beautifully, so that there would be no questions or panic.

If your users still come to you with similar fears, and you are tired of ticking “Do not ask again” - welcome under cat.

Zero step. Training and Trust Issues

So, our user clicks on the saved file with the .rdp extension and receives the following request:

Malicious connection.

To get rid of this window, use a special utility called RDPSign.exe. Full documentation is available, as usual, at the official website, and we will analyze an example of use.

First we need to take a certificate to sign the file. He can be:

• Public.
• Issued by an internal Certificate Authority.
• Completely self-signed.

The most important thing is that the certificate has the ability to sign (yes, you can select
EDS accountants), and client PCs trusted him. Here I will use a self-signed certificate.

Let me remind you that trust in a self-signed certificate can be organized using group policies. A little more details - under the spoiler.

How to Make a Certificate Trusted with the Magic of GPO

First, you need to take an existing certificate without a private key in .cer format (this can be done by exporting the certificate from the Certificates snap-in) and put it in a network folder that is accessible to users for reading. After that, you can configure Group Policy.

Importing a certificate is configured in the section: Computer Configuration - Policies - Windows Configuration - Security Settings - Public Key Policies - Trusted Root Certification Authorities. Next, right-click to import the certificate.

The configured policy.

The client PCs will now trust the self-signed certificate.

If the trust issues are resolved, we go directly to the signature issue.

Step one. Sweepingly signing the file

There is a certificate, now you need to find out its fingerprint. Just open it in the "Certificates" snap-in and copy it on the "Composition" tab.

We need the imprint.

It is better to immediately bring it to the proper form - only capital letters and without spaces, if any. It is convenient to do this in the PowerShell console with the command:

("6b142d74ca7eb9f3d34a2fe16d1b949839dba8fa").ToUpper().Replace(" ","")

Having received a print in the desired format, you can safely sign the rdp file:

rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp

Where .contoso.rdp is the absolute or relative path to our file.

After the file is signed, it will no longer be possible to change some of the parameters through the graphical interface, such as the server name (really, otherwise what's the point of signing?) And if you change the settings with a text editor, then the signature "flies".

Now, when you double-click on the label, the message will be different:

A new message. The color is less dangerous, already progress.

Let's get rid of him too.

Step two. And again questions of trust

To get rid of this message, we again need a group policy. This time the road lies in the section Computer Configuration - Policies - Administrative Templates - Windows Components - Remote Desktop Services - Remote Desktop Connection Client - Specify SHA1 fingerprints of certificates representing trusted RDP publishers.

We need a policy.

In the policy, it is enough to add the imprint already familiar to us from the previous step.

It's worth noting that this policy overrides the "Allow RDP files from valid publishers and custom default RDP settings" policy.

The configured policy.

Voila, now no strange questions - only a login-password request. Hm…

Step three. Transparent login to the server

Indeed, if we have already logged in to the domain computer, then why do we need to re-enter the same login and password? Let's pass the credentials to the server "transparently". In the case of simple RDP (without using RDS Gateway), we will come to the rescue ... That's right, group policy.

We go to the section: Computer Configuration - Policies - Administrative Templates - System - Passing credentials - Allow the transfer of default credentials.

Here you can add the necessary servers to the list or use a wildcard. It will look like TERMSRV/trm.contoso.com or TERMSRV/*.contoso.com.

The configured policy.

Now, if we look at our label, it will look something like this:

Do not change the username.

If RDS Gateway is used, you will also need to allow data transfer on it. To do this, in the IIS Manager, you need to disable anonymous verification in the "Authentication Methods" and enable Windows Authentication.

configured IIS.

Do not forget to restart the web services with the command:

iisreset /noforce

Now everything is fine, no questions and requests.

Only registered users can participate in the survey. Sign in, you are welcome.

Tell me, do you sign RDP labels for your users?

• 43%No, they are trained to press “OK” in messages without reading, some even put “Don’t ask again” checkboxes themselves.28

• 29.2%I carefully place the label with my hands and make the first login to the server together with each user.19

• 6.1%Of course, I like everything in order.4

• 21.5%I don't use terminal servers.14

65 users voted. 14 users abstained.

Source: habr.com