Remote app smartcard passthrough for multiple apps. RD Broker smartcard sessions.

Question

Hello,

We have an issue with connecting to multiple remote apps published on the same RD Broker but different session hosts, when using smartcards (Yubikeys).

A user can launch a remote app, authenticate using their Yubikey and PIN and the first app successfully loads. The user can then launch a second remote app through the same RD Broker without being prompted for a PIN or any credentials as long as the second remote app is hosted on the same session host.

The problem starts when a user then tried to load a second remote app published on the same RD Broker but hosted on a different session host. The broker doesn't seem to be able to pass through the smartcard credentials or prompt again for new smartcard credentials. The user then gets an error stating that "Smartcard logon is required and was not used."

We can see that when the user attempts the failed second remote app connection, the username is supplied to the session host as "@@BFHDDHFG..." etc (some form of hash unique to that user or smartcard from the existing successfully connection?) Not sure if this is stored on the RD Broker. We don't seem to be able to change it.

Because we publish all of our remote apps using the same RD Broker through work resources, users can only use 1 remote app at a time (almost all of our remote apps have their own unique session host). If we provide remote app rdp shortcuts which point directly to the session hosts then users can authenticate against 2 or more session hosts and launch multiple remote apps.

This seems to be related to how the RD Broker forwards smartcard credentials to the session hosts.

Any help on where to look next would be much appreciated.

Thanks.

Answer 1

Hello Falcon_20,

Thank you for reaching out to Microsoft customer support. I understand that you are experiencing issues with smartcard passthrough for multiple remote apps published on the same RD Broker but different session hosts.

Based on the information you have provided, it seems that the RD Broker is not able to pass through the smartcard credentials or prompt again for new smartcard credentials when a user tries to load a second remote app published on the same RD Broker but hosted on a different session host.

To resolve this issue, you may want to check if the smartcard redirection policy is enabled on the RD Session Host servers. You can do this by opening the Group Policy Editor and navigating to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection.

I hope the above information is helpful to you.

If you have any doubts, please feel free to let me know.

Best regards

Bblythe Xiao

Answer 2

Hi Xiao,

Thank you for the reply. Our group policy applied to the setting hosts has the "Do not allow smart card device redirection" set to "Disabled". Smart card passthrough does work for the first remote app.

We have noticed in the Windows 10 clients, the RDP UsernameHint field is being populated with the @@ values (seems to be based on username/yubikey certficiate). When the user attempts the second connection to the RD Broker this UsernameHint is passed through to the other session host and fails the login. Is there anyway to stop this behaviour?

HKEY_USERS<SID>\SOFTWARE\Microsoft\Terminal Server Client\Servers\

Answer 3

Hello Falcon_20,

Based on the information you provided, it seems that the issue may be related to the RDP UsernameHint field being populated with the @@ values.

To stop this behavior, you may want to try clearing the RDP cache on the Windows 10 clients.

To do this, you can navigate to the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default.

Then, delete the MRU* keys under this key. This should clear the RDP cache and prevent the UsernameHint from being passed through to the other session host.

I hope this helps! Let me know if you have any further questions.

Best regards

Bblythe Xiao

Answer 4

Hi Xiao,

We have deleted those. It does not make any difference. As soon as the first remote app is opened, the @@ value returns and the second remote app login tries to pass this value to the second session host.

The MRU* value is recreated in the registry as well.

Is there anything else we can try?

Answer 5

Hello Falcon_20,

If the MRU* keys are still being recreated in the registry even after they have been deleted, it's possible that there is a Group Policy setting that is causing this behavior. You may want to check the Group Policy settings on the affected computers to see if there are any policies that are causing the MRU* keys to be recreated.

To check the Group Policy settings that may be affecting the MRU* keys, you can use the Group Policy Management Console (GPMC) to view the policies that are applied to the affected computers.

1. Open the GPMC by typing "gpmc.msc" in the Run dialog box or the Start menu search box.
2. Navigate to the Group Policy Objects folder in the left pane, and select the policy that is applied to the affected computers.
3. In the right pane, click on the "Settings" tab to view the policy settings.
4. Look for any settings related to Remote Desktop Services or Terminal Services that may be affecting the MRU* keys, such as "Allow users to connect remotely using Terminal Services" or "Do not allow passwords to be saved".
5. If you find any settings that may be causing the issue, you can either modify the settings or disable the policy to see if it resolves the issue.

If you're not sure which policy is causing the issue, you can try disabling policies one at a time until you find the one that is causing the MRU* keys to be recreated.

You can also try disabling the RDP client's ability to cache credentials by setting the following Group Policy setting: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Do not allow passwords to be saved. This will prevent the RDP client from caching any credentials, including the RDP UsernameHint field.

If the previous steps did not resolve the issue, you may want to try the following:

1. Ensure that the smartcard is properly inserted and recognized by the system.
2. Verify that the smartcard reader driver is up-to-date.
3. Check if there are any third-party applications or firewalls that may be blocking the smartcard passthrough.
4. Try using a different smartcard or a different computer to see if the issue persists.
5. Check if there are any updates or patches available for the RD Broker or the RD Session Host servers.

If none of these steps resolve the issue, I suggest you post on the “Active Directory” plate for further assistance to resolve smartcard issue.

Best Regards,

Bblythe Xiao