Why can't I see my local smartcard readers when I connect via RDP?
The way smartcard redirection works is that there is a code snipped in Winscard.dll that is only invoked at the point in time when it loads.
- If Winscard is being loaded in a Terminal Session - all calls to that specific instance of Winscard are redirected to Winscard.dll on the host initiating the RDP connection
- If Winscard is being loaded in a physical Console session - all calls to that specific instance of Winscard are handled locally.
This check is only performed when each instance of Winscard.dll is loaded – which means that if you first log on physically to a Console session and then RDP into it afterwards it won’t affect any already running processes that have already loaded Winscard which will still only be looking for local smartcard readers.
An example of this would be applications that perform CryptoAPI operations, like Outlook sending a signed or encrypted mail; If you open Outlook while physically logged on and send an encrypted or signed mail and then RDP to the same session without closing Outlook in the meantime then Outlook will still only be aware of local smartcard readers and smartcards as the instance of Winscard it is using has already made that decision when it was loaded during the previous CryptoAPI operation.
The reverse is also true; if you RDP into a session from the start you will never see any local smartcard readers as Winscard will detect it’s running in an RDP session and no calls to Winscard will ever reach the local PC/SC layer – everything will be redirected to the connecting client.
The net effect of this design is that in order for the application to become aware of new smartcard readers (such as the remote redirected reader from the RDP session that is now connected instead of the Console session) the application needs to reload the Winscard.dll – for all intents and purposes this means exiting the application and restarting it.
From the CSP Cookbook, Figure 4. Redirection with Terminal Server:
Footnote: I was discussing this with one of the smartcard devs on a distribution list the other day and according to him it was really a regression in Windows 7 where you could have redirects that had different status depending on the Remote or Local connection state at the time the process was created *and* that it had been addressed in Windows 8.
The Smart Card Cryptographic Service Provider Cookbook