- This topic is empty.
-
Posts
-
Ok, this will sound strange but we have V10Ls with internal smartcard readers.
The reader works fine in Windows, but does not show as a device in device manager.
If I plug in an external USB smartcard reader this also works fine, but does not show as a device.
So…. How on earth does it work?
Locally attached smartcard reader are only available in the RDP session via PC/SC interface. This means that you can use it login via SC but normally not a lot more.
If your SC application running on the server talks via PC/SC interface everything will work. Otherwise SC will not work in the session.
The device will therefore not appear as a real device in the session.
Maybe Wyse TCX Suite can help to map the device itself to the session.CG
Hi Fred,
The smart card reader (internal or external) is consumed by WTOS via it’s device driver that it loads. Any CCID compliant reader shows up as a locally connected device.
The method of connectivity of the smart card reader to the remote session is different depending on whether you’re using a non-brokered or brokered environment.
If you are using a non-brokered environment and are directly connecting via RDP or ICA, the smart card virtual channel used by these protocols are instantiated once the session is up and running. The GINA (Windows XP/2003) or Credential Provider (Vista/Win7/2008) get notified of the smart card insertion event via the smart card virtual channel and then allow smart card usage. In this scenario, assuming you have the proper smart card cryptographic service provider (CSP), you’ll be able to use that smart card for logon and PKI-enabled (public key infrastructure) applications.
If you are using .NET smart cards, Windows Vista/7/2008 have the Microsoft BaseCSP built-in which make these type of cards really attractive and easier to support. It’s also the card of choice for the WYSE thin clients since they tend to be more “standardized” than the CSP’s that cater to brand-specific cards (i.e. Axalto CSP for Gemalto Cyberflex JAVA smart cards).
If you are using a broker on the WYSE V10L/V10LE/C10LE’s, this changes quite a bit. Essentially, you are opening the contents of the card at the WYSE device level and allowing the certificate on the smart card to pass-through into the session. The disadvantage here is that there’s a limited set of cards that work since the smart cards have to be unlocked using a PIN prompt at the WYSE device WTOS level. WYSE supports .NET cards and Aladdin eTokens today which should cover the majority of the population but don’t support JAVA-type cards since this would require hefty engineering.
My preference would be to take Gemalto .NET v2+ cards, load ’em up with the appropriate certs, and use a simple Microsoft PKI infrastructure for a small shop and enterprise-grade PKI infra for a big shop (we use Entrust here).
If you’re using a broker, both Citrix Xendesktop and VMware View work with the .NET smart card for both logon and in-session reads/writes. It is also great for session-smooth-roaming or hot-seating or whatever they call it today. If you’re not using a broker, then you’ll have better luck on logons and in-session use on odd-ball cards as long as you have the vendors CSP installed. Non-brokered also allows for hot-seating as you can make a session disconnect on smart card removal. 🙂
Hope this helps and sorry for the long email. I figured I’d put everything down in the email that I know since it might help others. 🙂
If there’s any more info you’d like to know, feel free to ping me. I’ve been trying to learn the smart card space and think it’s getting pretty interesting as VDI benefits greatly from it.
Warmest regards,
–Adam
- You must be logged in to reply to this topic.