I shared this workflow a couple of years back, and it’s since become one of the most referenced articles on this blog. It’s something that has been a part of just about all of my AppSense deployments since its inception. However, as time passed, the configuration evolved to be much cleaner, and I thought it was time for an update. So, without further adieu, here’s how we can manipulate AppSense to act only when a session roams from one endpoint to another. As an added bonus, we’ll even look at how to run them only when that session roams to a new department, building, or area.
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.
BGinfo, in case you’re by some chance unfamiliar, is a Microsoft utility for displaying session information on the wallpaper. It is often used on both servers and desktops for the purpose of quickly identifying the current Windows user, the name of the machine, and any other handy information one might want to have at hand. However, in one of Imprivata’s most common use cases, a generic account is used to enter the Windows environment, while a type-2 (kiosk) OneSign agent acts as an authentication gateway for each SSO user who shares that machine.
In this scenario, displaying the currently logged-in Windows user in BGInfo is a bit of a moot point, as it will always be the same for everyone. It doesn’t give any actual indication as to who is presently using the device. The problem is that, by default, there is no environment variable or single point for BGinfo to reference in order to display the current SSO user–that is, the one who just authenticated to Imprivata. Thankfully though, it’s not hard to set this up.
I have touched on the subject of troubleshooting zero clients for Imprivata usage before. However, I have been reminded in recent weeks about something I neglected to cover, and which probably deserves its own post anyway. I am referring to a commonly recurring problem that arises when one attempts to mix Imprivata, zero clients, and proximity cards.
Under certain circumstances, attempting to use proximity cards to “tap out” of an active virtual session on a zero client fails. That is, the card reader beeps, but the session remains open. I have also seen other strange behavior as well, such as a user being able to “tap over” his or her own session–where Imprivata locks the zero client and then logs them back in as themselves. Furthermore, this issue does not seem to be exclusive to View or XenDesktop, and obviously, neither of these scenarios is acceptable. Thankfully, the fix is a simple registry change in your master image.
Hypothetically, setting up your policies properly is enough to allow for User A to login to a desktop, get his Citrix virtual desktop, and then lock the machine confident that his session is secure and inaccessible to User B who logs in next. Unfortunately, as of this writing (and version 4.8, hotfix 1), that’s not always the case.
If you find that, unlike the ideal situation above, you notice that Citrix Receiver stays open during the switch and User B is able to see User A’s session after the fact (Followed shortly by a second Receiver session opening over top of the first), there are a few things to consider. First, take a look at your policy.
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.
I cannot decide if it is more infuriating to Google a problem and get no results or to get a single result that is not helpful in any way.
I came across this problem at a customer recently and the only thing the search giant could offer me was a singular thread on a forum somewhere that basically said “We had this problem. Then it went away and we can’t reproduce it. Nevermind I guess.”