In a recent deployment of Remote Desktop Services with Windows Server 2012, I experienced a second prompt for credentials. It occurred after successfully authenticating with Remote Desktop WebAccess and launching a RemoteApp from the browser. This blog explains why the second prompt is shown and how to get rid of it.
What the user is experiencing
Launching a RemoteApp from WebAccess is usually a very simple thing to do. After logging on (see first screenshot below), the assigned RemoteApps are displayed (see second screenshot below). When a RemoteApp is launched by clicking on the icon, the user first sees an error to inform him that the connection information is signed by an untrusted publisher (see third screenshot below). After choosing to continue, the user is presented a second credential prompt after he has already authenticated to WebAccess (see fourth screenshow below).
How authentication works with WebAccess
When the user authenticates against WebAccess, the credentials are only known to the browser and the web server running WebAccess. The credentials can only be passed on to the remote desktop client by code that is running inside the browser – only then can the credentials be accessed. For that purpose, WebAccess comes with an addon Internet Explorer.
As soon as the user connects WebAccess for the first time, he should be prompted to allow the addon to install and run (see first and second screenshow below). After authentication against WebAccess, the addon shows an icon in the system tray informing the user that it is handling the credentials (see third screenshot below).
What to do against the second prompt
As I have explained above, WebAccess requires a browser addon to pass the user credentials to the remote desktop client. But addons are only accepted when the URL leading to WebAccess is in the local intranet or in the trusted sites. Otherwise launching the addon will silently fail. In my case, the addon claimed to be working but the user was still seeing a second prompt for credentials.
The addon still does not pass on the user credentials to the remote desktop client if the publisher of the RemoteApp program is not trusted. Therefore, if the user is still seeing the publisher error , the browser addon is not doing its job – yet.
The first step to making the publisher known to the user is configuring a proper certificate. Remote Desktop Services are preconfigured with a self-signed certificate which is not accepted by default. You must at least configure a certificate for the “RD Connection Broker – Publishing” (see screenshow below).
With a proper certificate, the publisher error changes into a warning (see screenshot below). The user is still presented a dialog because the publisher is not trusted explicitly. Therefore, the user must accept the dialog after ticking the checkbox stating: “Don’t ask me again for remote connections from this publisher” (see screenshot below).
This step results in storing the fingerprint of the certificate in the user’s registry:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\PublisherBypassList
… and makes this a permenent configuration in this user profile. You can also deploy trusted publishers in your organization using group policy. The following setting contains a comma separated list of fingerprints (see screenshot below).
The setting is called Specify SHA1 thumbprints of certificates representing trusted .rdp publishers and is located under User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client.
The second credential prompt is caused by the browser addon – provided by WebAccess – is not working correctly. You need to …
- … add the WebAccess URL to the local intranet or trusted sites
- … configure a certificate for signing RemoteApps
Only then will the user be free of the second prompt for credentials.