We’re a Linux-mostly shop, running only “Microsoft Windows” machines for specific software environments not available for Linux. One of those environments is DATEV “Unternehmen online”, which is bound to “Internet Explorer” and to using the DATEV (Windows-only) “Sicherheitspaket”, enabling access to their web pages via SmartCard-based encryption keys.
Like most of our Linux systems, one of our two Windows machines is a Xen-based VM, with ThinClient-type Linux boxes as KVMSUSB servers (keyboard, video, mouse, sound, USB devices all are on the ThinClients and redirected to the according VM).
The problem turned out to be giving access to the SmartCard reader, attached to the Linux ThinClient, to the Windows VM.
The components of this environment
So, what do we have for a start?
- A beautifully silent Shuttle XS35v4 PC running as a Thin Client
- OpenSUSE 13.1 64bit with latest updates (we’ll stick to that since it’s what comes closest to a “long-term stable release”, rather than completely upgrading every few months)
- ReinerSCT SmartCard readers (“cyberJack e-com”, “cyberJack RFID komfort”), attached via USB to the XS35 PCs
The virtual machine is
- Microsoft Windows 8.1 64bit
- running on a “SLES 11 SP3”-based server via Xen 4.2.5, with sufficient memory
Connecting ThinClient and VM
Many moons ago, we had created a similar environment using a then-current “OpenSUSE 12.something” on the ThinClient side, and “Microsoft Windows XP SP2” on the virtual machine. It turned out to be quite a problem, since the then-standard “rdesktop” program (used as the Linux client program to access the Windows VM via RDP) came without the required SmartCard support compiled it. And WinXP required a lot of “registry voodoo” to make that constellation work, but in the end, after quite some hours spent with trying and failing, we succeeded and had an operational setup.
This time, with OpenSUSE 13.1, “xfreerdp” is what the distribution maintainers decided upon as the primary tool for RDP access, while “krdc” remains the graphical front-end.
Hassles, tries, and errors
In the end, setting the new environment up was muss easier than the earlier try with “rdesktop” and Windows XP – but it took quite some time to get there. Main reason for this is the lack of proper documentation for “xfreerdp”, or rather: When you fail go get it running and start searching the ‘net, you get lots of information, but most of it won’t help you.
An example: You’ll easily find out that there’s some way to specify SmartCard reader redirection. A freeRDP wiki page talks about new-style command line options to use, making it look like the following invocation might work:
myclient:~ > xfreerdp /smartcard /u:superadmin /v:vmwin.local transport_connect: getaddrinfo (Name or service not known) Error: protocol security negotiation failure
As you can see, this didn’t work. You can use the old way of specifying things… there is something call “RDP device redirection”, the according module is called “rdpdr”… and there’s some documentation on how to specify according parameters:
--plugin rdpdr --data smartcard:<name> -- - redirect smartcard with name <Name>So, great, what’s wrong with that? Especially as in a FreeRDP issue from 2012 it’s mentioned that the parameter needs to be “smartcard” now, not “scard” (as it had been called until then)?
myclient:~ > xfreerdp --plugin rdpdr --data smartcard:CYBERJACK -- -u superadmin vmwin.local loading plugin rdpdr connected to vmwin.local:3389 Password: freerdp_load_library_symbol: failed to open /usr/lib64/libfreerdp-1_0/smartcard.so: /usr/lib64/libfreerdp-1_0/smartcard.so: cannot open shared object file: No such file or directory freerdp_load_plugin: failed to load smartcard/DeviceServiceEntry
Looking at the content of “/usr/lib64/libfreerdp-1_0” it’s quickly obvious that the module is called “scard.so”… the connection will work either way, but the reader won’t be available. But you’ll only see the error message if you’re running “xfreerdp” from the command line, not when you simply adjust the invocation parameters in the KRDC connection settings…
To make a pretty long story short: There’s much out there, some of it contradicting, and only after quite some “try and err” the actually working combination turned up. It’s non-obvious: Even if you have everything set up properly to configure sharing of your SmartCard reader, you also have to explicitly redirect audio, prior to redirecting the SmartCard reader, in order to make Windows 8.1 recognize the reader! (This is mentioned in the docs as required for Windows Server 2012… but Win 8.1 needs it, too.)
The solution
So what finally gave us access to the reader from within the virtual machine, was starting xfreerdp with the following parameters:
myclient:~ > xfreerdp –plugin rdpsnd –data pulse — –plugin rdpdr –data scard: — -u superadmin vmwin.local
(Please not that we didn’t specify the actual reader with the “scard:” attribute – leaving that empty works fine for our ThinClients with only a single reader attached. The colon behind the parameter is required, though.)
When using KRDC (the KDE front-end to remote connections), you need to specify the following options only, in the “extended settings” field:
--plugin rdpsnd --data pulse -- --plugin rdpdr --data scard: --
Now when you open your session to the Windows 8.1 virtual machine via RDP protocol, the “krdc” configuration that comes with OpenSUSE 13.1 will start “xfreerdp” and give access to the first SmartCard reader of the client.