RDP Connection warning - rdp file not digitally signed

The Thumbprint and cert used to sign the RDP connection is not generated by WMS, but by the RDS server that you are connecting to. 

See the following article on how to replace the self signed cert with a public CA

https://woshub.com/securing-rdp-connections-trusted-ssl-tls-certificates/

See this section

Signing an RDP File with a Trusted TLS Certificate Thumbprint

Hi,

and thanks for your answer.
I don't know exactly how you imagine doing this. Which file should I digitally sign with the command "rdpsign.exe /sha256 25A27B2947022CC11BAFF261234567DEB2ABC21 "C:\ps\mun-dc01.rdp" as mentioned in the linked instructions?
That's exactly my problem. I dont' have a .rdp file that I could sign because It is 'dynamically' generated by the WMS on each Config Push to the Client.

And I repeat: I'm not talking about the TLS connection to the server. This error is generated even if the Servers would not be reachable. Or also if you enter "IdontCare" as the server address in the rdp configuration.

That was a bad article, my apologies.   Have you changed the certificate used by the RDP Listener?

https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations

The Digitally signed warning is because it is connecting to an RDS server it doesn't trust.   You should see the same message when connecting to it from a regular windows workstation.

Hey buffalobound,

and thanks again for your reply. But you're still missing the point.
"The Digitally signed warning is because it is connecting to an RDS server it doesn't trust." is just not true.

If I create a .rdp file which connects to "this-host-does-not-exist.domain.local" the mentioned warning message still appears. Because the .rdp FILE is not signed. The FILE, not the Connection!

I know enough about TLS encryption of RDP connections to know that's not the problem. Otherwise the message would not appear if the host is unreachable.

I hope you understand now that my problem is the .rdp file generated by the DELL WMS. It has nothing to do with the TLS encryption of the protocol.

Regards,
Daniel

Just a quick update.
Today I got a call from level 3 support. The problem is well known there, and there is currently no solution for it. It has been passed on to development, but there is no promise that it will be fixed. But it will probably be fixed in a future version.

Reviving this old thread, hope it helps you.  I had this come up for a customer and was able to (with a peers assistance) come up with a work around. 

The below is a sample powershell script which when pushed from WMS will add the required registry entries to suppress the warning. 

***Please use at your own risk and test before deploying in production. 

1) Edit the script and replace "your.host.com" with the RDP target you are using and save as a .ps1 file

2) Upload the PS1 file to WMS 

3) Create an App policy for your group/device that executes the PS1

4) When you apply th epolicy to the device, it should reboot, and after reboot when connecting to the RDS host you should no longer get the security prompt for that host. You would have to repeat for any additional hosts you need to connect to.

Script

$null = ls env:
$null = ls variable:
$profile='C:\Users\User'
$sid=Get-LocalUser -Name User | Select-Object SID
$sid=$sid.SID.Value
write-host $sid
$null = New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
#$null = reg load HKU\UserHive "$profile\NTUSER.dat"
$path1="HKU:\"+$sid+"\SOFTWARE\Microsoft\"
write-host $path1
New-Item -Path $path1 -Name "Terminal Server Client"
$path2="HKU:\"+$sid+"\SOFTWARE\Microsoft\Terminal Server Client"
New-Item -Path $path2 -Name "LocalDevices"
$path3="HKU:\"+$sid+"\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices"
New-ItemProperty -Path $path3 -Name "your.host.com" -Value 00000035 -PropertyType DWord
[gc]::collect()
#$null = reg unload HKU\UserHive
$null = Remove-PSDrive -Name HKU

If you are getting an RDP connection warning that says the RDP file is not digitally signed, it means that the Remote Desktop Connection client on your computer cannot verify the authenticity of the RDP file you are trying to use to connect to a remote server.

This warning could be a security risk as unsigned RDP files could potentially be tampered with or could be malicious. Therefore, it is always advisable to use signed RDP files to establish a remote connection.

Here are a few things you can do to address the warning:

Check the source of the RDP file: Make sure that the RDP file is coming from a trusted source. If the file is from an untrusted source, do not use it.

Digitally sign the RDP file: If you have created the RDP file yourself, you can sign it digitally to verify its authenticity. You can use a third-party certificate to sign the RDP file.

I had the same issue with the RDP connection warning on my Wyse thin clients. I found a solution that worked for me. I used a PowerShell script to sign the RDP file with a trusted TLS certificate thumbprint. You can find the script and the instructions here: https://www.dell.com/community/Wyse-Management-Suite/RDP-Connection-warning-rdp-file-not-digitally-signed/m-p/8345992#M844

The script creates a signed RDP file in the C:\Users\Public folder and sets it as the default RDP connection. You can run the script manually or use Wyse Management Suite to deploy it as an app policy.

Best regards, Hanna 

Edit: It doesn't work as expected. presumably because the script is already executed before the user login. I will keep testing.

---------------------------------------

Hey,

first of all sorry for my late response. I haven't had time to look at it in the past few weeks.

I noticed that the user "User" is fixed in the script. Of course, this doesn't work in my environment with the domain login.
So I modified the script to use the current user, which surprisingly seems to work. The challenge was to include the domain when determining the SID, but it works now. Below is the modified script for others, I have also adjusted the registry value.
From a security point of view, this is of course not ideal (man-in-the-middle attacks), but it is no worse than the user blindly confirming the message.

Thank you very much for your efforts to help me.
Regards, Daniel

$null = ls env:
$null = ls variable:
$rdshost="YOUR_RDS_HOSTNAME"
$profile='C:\Users\$Env:UserName'
$username = $Env:UserName+'@'+$Env:UserDomain
$sid=(New-Object System.Security.Principal.NTAccount($username)).Translate([System.Security.Principal.SecurityIdentifier]).value
write-host $sid
$null = New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
#$null = reg load HKU\UserHive "$profile\NTUSER.dat"
$path1="HKU:\"+$sid+"\SOFTWARE\Microsoft\"
write-host $path1
New-Item -Path $path1 -Name "Terminal Server Client"
$path2="HKU:\"+$sid+"\SOFTWARE\Microsoft\Terminal Server Client"
New-Item -Path $path2 -Name "LocalDevices"
$path3="HKU:\"+$sid+"\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices"
New-ItemProperty -Path $path3 -Name $rdshost -Value 00000111 -PropertyType DWord
[gc]::collect()
#$null = reg unload HKU\UserHive
$null = Remove-PSDrive -Name HKU