“Unknown Publisher”??? Part Two

Hello AskPerf readers, it’s Don Geddes again and I’m back with that post that I promised you about that pesky dialog box that we all know so well. In this post, I’m going to walk through some common client/server scenarios and explain the technical details of what generates the “Unknown Publisher” dialog as well as what has to be done to hide it. I’ll try to make this as brief as possible without losing the important technical details.

To start, I want to describe the common scenarios and configurations that exist today so that you can better understand what your options are. Depending on your specific scenario, you may or may not have an option to hide the dialog, so it is important to know where your configuration fits in these scenarios.

Note: Server Operating System refers to the web server that is running either the Remote Desktop Web Connection in Windows Server 2003 or TS Web Access in Windows Server 2008.

Scenario 1:

Server Operating System: Windows Server 2003
Client Operating System: Windows XP or Windows Vista and you have NO control over the client machines

This scenario is one of the most common, and your only option for hiding the dialog in this scenario is to change your web page so that it sends a signed RDP file to the client. This scenario is also the one that creates the most confusion and frustration.

Server Operating System: Windows Server 2008
Client Operating System: Windows XP or Windows Vista and you have NO control over the client machines

This scenario will become more common as more servers are upgraded to Windows Server 2008, but the good news is that all you need to hide the dialog is built-in to Windows Server 2008.

Server Operating System: Windows Server 2008
Client Operating System: Windows XP or Windows Vista and you have direct administrative control over the client machines (a.k.a an Enterprise)

This scenario is similar to Scenario 2 but it adds the ability to use group policies to configure the client machines and make sure Vista users never see any dialog.

So now that I’ve defined the scenarios, let’s look at the technical details of what is happening with this prompt. First, I will start with a little history of how things used to work and then explain how the RDP 6 client changed things.

In the Remote Desktop Web Connection or TS Web Access scenarios described above, the RDP connection to the Terminal Server is started by a user clicking on a link in a web page. A user visited a web page, and that web page is now trying to open a connection to some other computer by launching the Terminal Server ActiveX control.

In previous versions of the Remote Desktop client, the ActiveX control was not included and had to be downloaded from the web server. This scenario was handled by using a digitally signed msrdp.cab file that contained the ActiveX control and allowing the client to download it from the web server. Since the CAB file was digitally signed, Internet Explorer would extract the msrdp.ocx file contained within it and install it if the user clicked on “Install”. Once the ActiveX control was installed on the client, the user could make any connection they wanted to without any warning prompt because the user had to allow the ActiveX control to install in the first place. It might not be clear to most users what really happened but that is essentially what they did. It was implied that any connection made in this way would be safe because the user allowed the ActiveX control to install. The connection parameters were controlled by the code in the web page itself, so the web page was designed to send the connection parameters to the ActiveX control and allow it to make a connection. The user was not sent an RDP file with connection settings contained within it.

With the RDP 6 client, the ActiveX control is now included with the Remote Desktop client installation package, and any previous versions that were installed are upgraded to the new version. When a user that has upgraded their Remote Desktop client visits a Remote Desktop Web Connection or TS Web Access web page, they no longer need to download the ActiveX control, it is already installed and should be enabled in Internet Explorer via the Manage Add-Ons user interface. If the control is not enabled then a message is displayed informing the user that they must enable the ActiveX control before they can make a connection. Enabling the control though does not imply that the connection itself is safe, especially when device redirection is involved. Every connection that is made to a Terminal Server must now be explicitly allowed by the user on a per-machine basis. So the prompt is designed to inform the user of two things:

1. The Remote Desktop Client cannot guarantee that the server they are attempting to connect to is who it claims to be

2. The remote computer may be allowed to access local resources

The user cannot control the identity verification of the server; this is something that the server administrator must configure. The user can however choose to not allow access to specific local resources, so the checkboxes under “Allow the remote computer to access the following resources on my computer:” are there to give the user a way to disable access to those resources. The user must then click the Connect button before the connection will be made.

In this section I will discuss how to remove the dialog based on the three scenarios mentioned previously. I’ll cover each scenario separately, but the key to understanding how to remove the prompt is to understand that in order to give the user the ability to hide the prompt, the RDP 6 client has the following requirements:

1. An RDP file must be sent from the web server to the client. Windows Server 2008 TS Web Access generates the RDP file on the fly and sends it to the user, whereas Windows Server 2003 Remote Desktop Web Connection does not send an RDP file at all.

2. The RDP file received by the client must be signed, but to be more specific, the RDP file itself must contain a signature blob within it that is generated when the RDP file is signed. This blob allows the client to verify the identity of the server that it is connecting to.

If requirements 1 and 2 are met, the user is allowed to check a box titled “Don’t ask me again for remote connections from this publisher”. Checking this box writes a key to the client registry that is based on the certificate that is used to sign the RDP file. The next time the user opens this same connection and is sent an RDP file with the same signature, the prompt will not display. The key is named PublisherBypassList and is written under:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client

When an RDP file is signed, two additional parameters are added to let the RDP client know that the connection is signed. You can see this by looking in the RDP file itself and looking for the signscope and signature fields:

The “s” after signature designates a string value and this field would be populated with a hash that is generated from the signature.

So how do you implement RDP signing? In this next section I will give you the details for each of the previously mentioned scenarios.

In this scenario, you cannot meet requirement 1 because the Remote Desktop Web Connection does not send the client an RDP file. Even if you modify your web page to send an RDP file to the client, you do not have a way to sign the RDP file and satisfy requirement 2. With no way to allow the client to verify the identity of the Terminal Server that it is connecting to, the user will never be allowed to click the check box and write the registry key that hides the prompt.

Also keep in mind that since you do not control the machine that is used to connect to your website, you cannot also control the RDP client that is being used. If a Windows XP machine that is still running the older 5.1 or 5.2 client connects, then they will not see the prompt.

The good news is that you are not alone in this scenario and there may be light at the end of the tunnel soon. Also, if you have access to a Windows Server 2008 server but cannot deploy it yet, there is a way to use rdpsign.exe to sign an RDP file that can be then served from a Windows Server 2003 web server. This will require that you modify your web page to send the user an RDP file, and if you use IIS you need to add a mime type value for application/x-rdp so that Internet Explorer knows what to do with the file that it is sent.

If you’re running Windows Server 2008 and TS Web Access, all that you need to sign your RDP files is built-in. What you need to do is make sure you use the correct certificate to sign the RDP file and then use either the RemoteApp user interface or the command-line tool rdpsign.exe to sign the RDP file. The built-in help has information on how to sign your RDP file, here is an excerpt with the details:

If you use a digital certificate, the cryptographic signature on the connection file provides verifiable information about your identity as its publisher. This enables clients to recognize your organization as the source of the RemoteApp program or the remote desktop connection, and allows them to make more informed trust decisions about whether to start the connection. This helps protect against the use of .rdp files that were altered by a malicious user.

You can sign .rdp files that are used for RemoteApp connections by using a Server Authentication certificate [Secure Sockets Layer (SSL) certificate], a Code Signing certificate, or a specially defined Remote Desktop Protocol (RDP) Signing certificate. You can obtain SSL and Code Signing certificates from public certification authorities (CAs), or from an enterprise CA in your public key infrastructure hierarchy. Before you can use an RDP Signing certificate, you must configure a CA in your enterprise to issue RDP Signing certificates. For more information, see the Windows Server 2008 Terminal Services Deployment Guide ( http://go.microsoft.com/fwlink/?LinkId=79603 ).

If you are already using an SSL certificate for terminal server or TS Gateway connections, you can use the same certificate to sign .rdp files. However, if users will connect to RemoteApp programs from public or home computers, you must use either of the following:

• A certificate from a public CA that participates in the Microsoft Root Certificate Program Members program ( http://support.microsoft.com/kb/931125


• If you are using an enterprise CA, your enterprise CA-issued certificate must be co-signed by a public CA that participates in the Microsoft Root Certification Program Members program.

Once you’ve signed your RDP files, users that connect to the TS Web Access site will download the signed RDP file and receive a prompt similar to the following:

The user then clicks the checkbox “Don’t ask me again for remote connections from this publisher” and the dialog will not display again for connections to this server.

If you have Windows Server 2008 and you also control the client machines that are connecting, you can use group policy to configure Vista clients to always trust RDP files from specific publishers. Unfortunately this policy is only supported on Windows Vista but when configured properly, Vista clients would never see a prompt at all as long as the RDP file is signed.

To do this, configure the following policy:

Computer Configuration/Administrative Templates/Windows Components/Terminal Server/Remote Desktop Connection Client

Policy: Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

You must ENABLE this policy and then specify the SHA1 thumbprint from the certificate(s) used to sign your RDP files.

And with that, we’ve reached the end of this post.  There is a lot of information here, hopefully this sheds some light on the issue and will help you work through some of the pain points.  This issue is one that we are keeping an eye on, so stay tuned to our blog for other potential workarounds for Scenario 1.

- Don Geddes

Share this post :