Closed ferragusNM closed 9 months ago
I can’t say I’ve run across that particular setup.
RDP often takes a specialized route for smartcard redirection so that may be why it behaves differently. Do you have the smartcard mini driver (e.g., OEM or ActiveClient) installed on the VM and is it the same version on the physical client?
Also does certutil -scinfo
complete successfully on both?
Interesting. I'm working remote today, so I'm on the Physical Windows workstation and VPN'd into the systems in question (which is the setup that works without problems - maybe I can use this to pitch going back to 100% WFH?) Ran certutil -scinfo on the physical box just to have a baseline, no problems of course, then RDP's into a VMware Windows VM (where PuTTY-CAC works) and the certutil command hangs. So as you said "RDP often takes a specialized route for smartcard redirection". I'll be in the office Friday where I can test things further. Thanks and Happy Thanksgiving!
@ferragusNM Any luck with this?
I am not sure if this applies to your setup, but working with Windows, RDP, Certificates, FIDO and PuTTY-CAC I observed the following:
Closing due to inactivity. Please reopen if necessary.
Here's the setup: FreeIPA with external trust to (.gov) Active Directoy controller. PuTTY-CAC to client linux box from physical Windows workstation (Win10) works fine. On a Linux Workstation, using QEMU Virtual Machine Manager, we open a console into a locally running VM with Windows 10 on it. Using USB rediretion we aupply the PIV card to said VM and all is well. From the VM, RDP into other Windows resources is also fine, but PuTTY-CAC into linux client now fails. Any ideas on if I should even try to figure this out? From native linux I can use openssh and pcscd to make the ssh connection, so I can live without PuTTY-CAC on the windows VM running on that system.
Thoughts and comments appreciated.