Smart card logon with RSA KSP certificates works with mstsc but fails in RDM using X.509 credential (LSA error, affected by DisableCapiOverrideForRSA)

Hello

We're had several reports of this although the reason is not clear at the moment. RDM is just marshalling the smartcard thumbprint to the RDP control, so it shouldn't involve either the CSP or the KSP at our level. We're investigating it and I've linked your post to the ticket so you can be informed once we have an update. In the meantime, the workaround is to set the registry key as written in your post.

Sorry for the inconvenience and thanks for your patience

Kind regards,

Hello Richard,

Thanks for letting me know! I just wasn't able to find any Bug Report regarding the Issue.

Do you know if the Error only occurs with RSA KSP Certificates or also with ECC Certificates?

If there's anything I can do to help you fix the issue, just let me know.

BR Sebastian

Hello

I'm not sure if it's a problem with ECC certificates; but I also suspect it won't change anything. In my lab, my setup is broadly the same as yours (RSA KSP certificates on similar infrastructure) but after installed the update on my workstation, I still couldn't reproduce the issue.

I don't doubt the validity of the problem, since we've had multiple reports. It's just hard to understand where the problem is creeping in. From our side, all we do is marshal the certificate thumbprint to a "magic string" that's usable as the "username" for Microsoft's RDP control (which only accepts usernames and passwords, not certificate authentication). So I can't understand how the upstream code (either SSP / Kerberos or the smart card stack) is behaving differently versus a certificate chosen with CredUI.

I'm asking another developer, who is an expert in smart card, to take a look at this and I hope he can do that and give some feedback before the new year.

Thanks for your patience

Kind regards,

Hello,

The thing I'm suspecting, is that since the certificate is chosen by thumbprint, it chooses the wrong one. For me certutil -scinfo for RSA KSP Certificates gives back both, CSP and KSP in the same Slot, both with the same Thumbprint.
ECC Certificates don't have the CSP Slot since the're KSP-only. That yould at least make it logical for me, that with only a CSP cert in mstsc, i get the same error as with RDM regardless.

If I find time today or tomorrow, I'll try if ECC works and report back.

BR Sebastian

Hello

Your hypothesis sounds reasonable. If that does turn out to be the case, there may not be much we can do than report the issue to Microsoft and encourage users to reconfigure their smart card certificates. How this works on our side: the MS RDP control only accepts a username and password for authentication, not a certificate. The solution is to call CredMarshalCredential, passing it the SHA1 of the certificate you want to use; which returns a "magic string" encoding the certificate. This "magic string" is set as the username for RDP and, if provided, the smart card PIN is the password field. My assumption is that on the other end, CredSSP or the smart card stack detects the magic string and calls "CredUnmarshalCredential" to get back the hash and identify the certificate. So - our involvement here is minimal.

If you manage to test with an ECC certificate, please let me know if it works.

The other thing that would be interesting is how it behaves if you _don't_ set the PIN on the certificate in RDM. This should still select the certificate, but force CredUI to open to ask for the PIN. I wonder if it's able to "know" to use the KSP in this case.

Please, let me know if something isn't clear or you have any questions

Kind regards,

Hello Richard,

Sorry this took a bit longer. I tested with the ECC Certificates today, but the Error in RDM is the same (LSA unreachable).

Without setting the PIN on the certificate it selects the correct Certificate an then asks for the PIN, but this always works, no matter the Configuration

DisableCapiOverrideForRSA (obviously) does not change this behavior.

So basically RDM is unable to use KSP Smartcards for RDP with the PIN saved. With DisableCapiOverrideForRSA=0 and RSA KSP Smartcards it only works for mstsc and RDM because RDM is allowed to fallback to CSP.

Kind Regards,
Sebastian

Hello

Thanks for the investigation and getting back to me! So, for now, it seems that not saving the PIN and entering it manually could be another (albeit inconvenient) workaround.

because RDM is allowed to fallback to CSP

As I've written above, all RDM is doing is marshalling the certificate thumbprint and (optionally) the PIN using the Microsoft API designed for that, at our level we have no knowledge of how the key is stored or any way to select how the key is used. We simply pass the thumbprint to the RDP ActiveX control as a text string.

This is looking more and more like a bug on Microsoft's side. We have a developer investigating this and hope to confirm that, and find if there's another way to workaround this issue.

Thanks again,

Hello

A quick update here that we didn't forget about this, we are still investigating.

In the meantime the deadline for the registry workaround has been extended by Microsoft to February 2027. I guess lots of vendors are struggling with this.

Thanks and kind regards,

Hello,

Thanks for letting me know.
So you aim to have the new API workflow implemented before the new deadline?

Thanks
Sebastian

Hello,

Thanks for letting me know.
So you aim to have the new API workflow implemented before the new deadline?

Thanks
Sebastian

@sebastianbayer

I'm aiming to have some news much sooner than that, but right now it's not clear if this is tied to a specific certificate configuration and/or a bug on the Microsoft side. Our options are quite limited right now because we're simply calling the proper Microsoft API to enable this behaviour, 99% of the workflow is actually outside of RDM (in Windows internals).

I hope to have some news about this soon.

Kind regards,