Five posts into this blog and I’ve already had to talk about the Xenith 2 twice. The reasons for this are several: the information is fresh in my mind; the device is newer and lacks extensive documentation on the Googles as yet; I’m trying to stay motivated to keep this little project going by writing often, and I ran into all kinds of problems with these things…
Anyway, in addition to the aforementioned virtual driver error there were a few “gotchas” (as I am told they are called in the biz), so I will keep the exposition short in an attempt to cover everything in a single, hopefully intelligible post.
This particular customer was rolling out all new active directory accounts for its users at the same time as Imprivata, and so all users were given a provisional password that was set to expire. When attempting to enroll credentials on their badges, we noticed it worked just fine from a PC: The user would tap his or her badge; be prompted to enroll it; supply a user name and the provisional password; get prompted to reset it; select a new one, and the badge was enrolled with their newly reset password.
However, when this same workflow was attempted from the Xenith 2, all other things equal, users were invariably met with the dreaded “OneSign could not authenticate you” error. I am sorry to say we never got an actual fix for this, but as workarounds are my custom, I can at least offer the following advice: Have users reset their expired passwords first, spin up their session, tap out and enroll their badge with the newly reset credentials. It is not ideal, and will add a couple of minutes per user to the enrollment process, but if restricting enrollment to PCs is not an option, perhaps that much is.
Account Self-Service: Security Questions
Wanted to put into certain terms that this protocol is not supported from a Xenith device. There is, as of this writing, nothing you can put into your xen.ini file that will allow users to answer Imprivata security questions to reset passwords/access desktops. While we’re on the subject…
Xen.ini Parameter for Imprivata Use
OneSignServer = yourserverhere
Not a “gotcha” as such, but I couldn’t find that information anywhere. I had to get this awesome configuration generator tool (Source: FreeWyseMonkeys) just to figure it out. Seems simple in retrospect, but just in case, there ya go.
Walk-Away Security: Fade to Lock / Inactivity Lockdown
This is by far the biggest one, so I saved it for last. In just about every hospital I have worked, users are notorious for leaving their work unlocked and unattended behind them. Whether they used generic signons in the past, or whether they didn’t use computers at all, they have a strong propensity to walk away from a computer without locking it first. When Imprivata and application SSO comes into play, this can be a security nightmare.
In a PC-based environment, where you have a local Imprivata agent running and automating the connection to the desktop, you are free to make as many computer policies using as many individual timeouts as you’d like, and if you’re using fade-to-lock, they will fade and lock when or if you want any of them to do so. If, however, you are planning on using that same fade-to-lock feature on a zero client that will be connecting to linked clones or other non-persistent virtual desktops, your options become significantly more limited. Because there is no locally installed agent to manage it on a machine-by-machine basis, you have to apply all your settings to the virtual desktops themselves.
Unfortunately, this means you need to commit to a single timeout period for everyone, as there is no way to dynamically update Imprivata policy on singular machines. This is not to say you cannot get a little more granular with the idle timeout period across the environment if you want to use something other than Imprivata to lock them down (I’ll come back to this in another post, probably), but if you plan on using the awesome fade-to-lock functionality, you will have a single computer policy for all your virtual desktops that handles it for you.
Here’s where it gets tricky.
Enabling the fade-to-lock functionality in the computer policy for your virtual desktop is hypothetically all you need to do. In reality, when you are connected to the desktop from a Xenith 2, you find that your timer hits 0, and the desktop just sits there without doing a thing. Anyone can come up, move the mouse, and it’s as though nothing ever happened. Whatever Imprivata is attempting to do to lock the desktop is failing. What this tells me is that we need to adjust the behavior so that whatever happens when that timer hits 0, it disconnects the virtual session. My The workaround I came up with is as follows:
- The first thing we need is the ability to disconnect a session using a command. If you had been using View, tsdiscon would have sufficed. As you are on a Xenith 2, I will presume you are using XenDesktop, and confirm (in case you didnt know for sure) that tsdiscon does not work with XenDesktop. There is an alternative, of course, but do note that this is not a portable .exe but a program that actually does require an installation. Download it from here and install it on your master image.
- There is also a registry setting required for this workaround, so you might as well set it while you’re here:
- Create a procedure code extension object to be triggered when the computer is locked. It should read (unless you installed it to a different path):
“C:\Program Files\Xirtica Software\QuickDisconnect\QD.exe” /DISCONNECT
- Enable this procedure code in your virtual desktops’ computer policy. Additionally, go to your “override user policy” tab and check the box next to Challenges. Set any hotkey you wnat (it really doesn’t matter–just don’t pick one that a user might use in real life) and set it to Lock Computer when it is pressed.
That’s it. The endgame is here is that the timer will count down to 0 and Imprivata will have the ability to lock the virtual desktop itself. When it does so, the procedure code will note the lock and trigger the command that disconnects the virtual session, resulting in a session still available for reconnection and a secure walk-away.
That’s also it for the oddities I noted on these devices. If you’ve got more, let me know.