- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
But suppose you want to deploy a shortcut that doesn't have the warning, or even better, you want it to use the current credentials automatically without a prompt even showing! To do that, you have to sign the shortcut using a built-in tool and then add that certificate to an allowed list in a Group Policy to tell the system that any RDP shortcut signed by this certificate should work without a prompt.
Certificate prompt: The publisher of this remote connection can’t be identified
Using RDPSign.exe
This command-line tool has been around since the introduction of Remote Desktop Connection 6.1 Client, which appeared in Windows Vista SP1 and Windows XP SP3. Although the tool appears simple, it enables a powerful utility to create trusted shortcuts.
There are only four command-line options to this command: /sha256 HASH, /q, /v, /l. Those mean, respectively, the hash to sign the shortcut with, quiet mode, verbose mode, and a test mode for verifying if the signing would be successful.
Although the first parameter, /sha256, states SHA-256, you need to pass in an SHA-1 Thumbprint even though the certificate itself can and is recommended to be signed using a SHA-256 hash.
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.
Please note that although the parameter says /SHA256, you actually need to pass in a SHA-1 Thumbprint value even for a Signature Hash Algorithm SHA-256 certificate. A quirk of the tool is that the hash that is passed must not have any spaces. Additionally, if you want to use this hash in the GPO, the hash needs to be in all uppercase. When using rdpsign.exe, quotes around the hash are also advisable.
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
Sign RDP file with certificate
If you don't deploy the certificate that you are using to all computers that will need it, this will only work on the system that you signed the RDP shortcut on. You can also use self-signed or CA-signed certificates, but they should be imported PFX certificates that have the private key included.
To jump into the actual process of signing a shortcut, follow along below.
- Retrieve the Thumbprint of the certificate that you are using to sign the shortcut.
- Open the Certificates snap-in (or add the snap-in from an open MMC instance).
- Navigate to either the local computer's certificate store or your personal certificate store and locate the certificate to sign with.
- Open the certificate by double-clicking; click on the Details tab and locate the Thumbprint in the field list.
- Save the value from the Thumbprint, as you will use this to sign the RDP file.
- Prepare the hash for use with the exe tool.
- The hash must have no spaces. Additionally, if you want to use the GPO policy to specify trusted publishers for the RDP shortcut, it must be uppercase. The following PowerShell will convert it to that format.
- ("79 1c dd 50 4e dd ff 9a 85 2b b0 74 30 18 c9 85 07 31 a8 80").ToUpper().Replace(" ","")
# Output
# 791CDD504EDDFF9A852BB0743018C9850731A880
- Open a command prompt.
- Note: It does not have to be an Administrative prompt.
- Use the following example command to sign your RDP file.
- Replace the below hash with the one you previously obtained and prepped.
- The path to the file should be either relative or absolute, and you CANNOT use wildcard characters.
- The original file will be overwritten.
- exe /sha256 791CDD504EDDFF9A852BB0743018C9850731A880 <Path to RDP File>
One additional note is that you can sign multiple files by passing in additional RDP files to sign.
rdpsign.exe /sha256 791CDD504EDDFF9A852BB0743018C9850731A880 <Path to RDP File 1> <Path to RDP File 2> <Path to RDP File 3>
Note: If any files fail to sign, the tool will continue on to the next one and not fail for all.
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.
Specify trusted publishers in GPO
If you want to avoid the below prompt entirely, you can add the SHA-1 Thumbprint into the GPO setting. Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers. This is located under Computer ConfigurationTemplatesComponentsDesktop ServicesDesktop Connection Client.
Trust the publisher before you connect
The main thing to remember is that the SHA-1 hash needs to have no spaces and be in all uppercase. If you used the prior PowerShell command to prep earlier, then you should be good to go.
Example PowerShell:
("79 1c dd 50 4e dd ff 9a 85 2b b0 74 30 18 c9 85 07 31 a8 80").ToUpper().Replace(" ","")
Specifiy SHA1 thumbprints for cetificates Group Policy
One additional note is that this policy setting overrides the behavior of the "Allow .rdp files from valid publishers and user’s default .rdp settings" policy setting.
Conclusion
The warnings that you see serve a legitimate purpose, and for security awareness, it can be useful to keep those warnings in place. Ultimately, though, if you have a series of trusted connections that you want to make available to your end-users, signing those RDP shortcuts can be a very useful tool.
Hi,
There's something I've been searching for an answer on for a couple of days now and cannot find any useful information.
I understand that signing the RDP files removes the warning on the client side so that users can trust a server but surely its even more important for the server to trust the client. I would have thought the client connection would pass the signature though to the server and somewhere on the server (gateway, broker or session host) there would be an allow/block option for signed/unsigned connection requests.
We are not planning to use RDweb. Users will be issued signed RDP files. But I want to configure a rule somewhere to block all unsigned RDP connections.
Do you have any idea if this is possible and where it would be done?
Thanks,
Alex.
did you ever find an answer to this? I'd like to block unsigned rdp connections as well.
Hi Steven,
Unfortunately not.
It seems that Microsoft has only made efforts to enable the blocking by client computers from connecting to servers that aren't trusted but not the other way round. (This is done through group policies enforced upon the client, which means they need to be on a domain which most remote computers at home won't be.)
There seems to be no mechanism to block servers from allowing connections from unsigned connections by remote computers, which surely is the far greater risk. I do not understand why this is and I would be very grateful if someone could explain or provide a solution for blocking unsigned RDP connections.
Dear I want to completely avoid the trust the publisher popup when user will open.rdp file accessing from RDWeb access over public internet. How I can achieve..I tried many ways above noted but not yet fixing.
Thanks
Mahesh