Not so long ago, we implemented a solution on a Windows terminal server. As is customary, we threw shortcuts for connection onto the employees' desktops and said — get to work. However, users became anxious about Cybersecurity. When connecting to the server, seeing messages like: 'Do you trust this server? Are you sure?' they became frightened and turned to us — is everything okay, can they press OK? That's when it was decided to make everything look nice to avoid any questions and panic.

If your users still come to you with such fears, and you are tired of checking the 'Don't ask again' box — welcome below the fold.

Step zero. Preparation and trust issues

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

‘Malicious’ connection.

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

First, we need to obtain a certificate to sign the file. It can be:

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

The most important thing is for the certificate to have the ability to sign (yes, you can take one from the accountants' digital signatures), and for client PCs to trust it. 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 bit more detail — under the spoiler.

How to make a certificate trusted using GPO magic

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

The certificate import configuration is set in: Computer Configuration — Policies — Windows Configuration — Security Settings — Public Key Policies — Trusted Root Certification Authorities. Then, right-click to import the certificate.

Configured policy.

Now client PCs will trust the self-signed certificate.

If trust issues are resolved, we move on to the signing question.

If trust issues are resolved, we move directly to the question of signing.

Step one. Signing the file broadly.

The certificate is available; now we need to find its thumbprint. We will simply open it in the 'Certificates' management console and copy it from the 'Details' tab.

The thumbprint we need.

It's better to immediately format it correctly — only uppercase letters and no spaces, if there are any. This can be conveniently done in PowerShell with the command:

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

Having the thumbprint in the right format, we can confidently sign the rdp file:

rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp

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

Once the file is signed, you won’t be able to change certain parameters via the graphical interface like the server name (after all, what would be the point of signing it?). And if you change settings with a text editor, the signature will be invalidated.

Now, when double-clicking the shortcut, the message will be different:

New message. The color is less alarming, already progress.

Let's get rid of it as well.

Step two. Again, trust issues.

To eliminate this message, we will again need a group policy. This time the path leads to Computer Configuration — Policies — Administrative Templates — Windows Components — Remote Desktop Services — Remote Desktop Connection Client — Specify SHA1 thumbprints of certificates representing trusted RDP publishers.

The policy we need.

In the policy, it is sufficient to add the thumbprint we are already familiar with from the previous step.

It is worth noting that this policy overrides the 'Allow RDP files from trusted publishers and user-defined RDP settings specified by default' policy.

Now client PCs will trust the self-signed certificate.

Voila, now there are no strange questions — just a request for login and password. Hmm...

Step three. Transparent login to the server.

Indeed, if we have already authenticated upon logging into a domain computer, 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), group policy will come to our aid.

Navigate to: Computer Configuration — Policies — Administrative Templates — System — Credential Delegation — Allow credentials delegation set by default.

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

Now client PCs will trust the self-signed certificate.

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

The username cannot be changed.

If you are using RDS Gateway, you will also need to allow data transmission on it. To do this, in the IIS Manager, you need to disable anonymous authentication in 'Authentication Methods' and enable Windows authentication.

Configured IIS.

Don't forget to restart the web services with the command:

iisreset /noforce

Now everything is fine, no questions or requests.

Only registered users can participate in the survey. Please log in, please.

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

• 43%No, they are trained to click 'OK' on messages without reading, some even check the 'Don't ask again' box themselves.

• 29.2%I carefully place the shortcut by hand and make the first login to the server together with each user.

• 6.1%Of course, I like everything to be orderly.

• 21.5%I do not use terminal servers.

65 users voted. 14 users abstained.

Source: habr.com