Workarounds, cheat codes, and occasional black magic

Imprivata: Thin Client Preventing New Users from Logging In

Scenario: User A logs into a session on a thin/zero client, then walks away for 10 minutes without disconnecting. Imprivata, configured to secure the idle workstation at that time, attempts to lock the machine. The box returns to the local login screen, but the username and domain are pre-populated, and new users cannot login over User A before manually signing them out of the local device. In other words, the device is behaving like an Imprivata Type 1 (Single-User) machine. Ostensibly, it looks like Imprivata is preventing new users from logging in.

As it turns outs, the problem here is not with Imprivata, but with the device’s configuration .ini file. To make matters stranger, it seems both Wyse ThinOS and Xenith Pro 2 devices interpret a proximity card tap differently from how they interpret a hotkey/idle lockdown trigger. This can result in badge taps working as expected, even if users can’t manually type their credentials. This problem may exist on devices beyond these, but I have only personally confirmed it on these two types so far. At any rate, the fix is thankfully quick and simple:

In your .ini (either wnos.ini for ThinOS or xen.ini for a Xenith device), simply add the following to the same line as your OneSignServer parameter:

OneSignServer=your.appliance’s.fqdn.here

EnableFUS=yes

FUS, in this case, is Fast User Switching. This is entirely separate from Imprivata’s own functionality that shares the name, so even if the thin device’s computer policy has FUS configured, you may still need to add it to the configuration .ini file.

Check to see if you have a grace period configured for the PIN in the user’s Imprivata policy. If you want them to be prompted for a PIN every time they tap, the grace period should be set to zero. It sounds to me like the rest of the workflow is behaving correctly.