If you are deploying a virtual desktop environment in a hospital setting, you can be absolutely assured that a user will, at some point, walk away from a computer and leave a session unlocked.
Without application-level single sign-on, this is a big security hole. With application-level single sign-on, it is a security nightmare, and I don’t doubt that it would constitute a smorgasbord of HIPAA violations. I imagine this is a problem that exists in other arenas as well, but alas, my scope of experience is as-yet limited.
In my last post, I gave an explanation of how to use Imprivata fade-to-lock from within the VDI using computer policy (albeit couched within an explanation of a workaround specific to Xenith 2 devices). Again, this is perfectly effective, and if it suits your needs, this article will bore you. That aside, if you are using a PC-based environment with Imprivata, this article will bore you even more. That is, the workaround here described is rendered moot when you have endpoints that accept their own computer policies.
However, if you are not using Imprivata, or you are using it with zero clients that do not allow for fade-to-lock, this may interest you.
For example, let’s say you have a few PCs in a publicly accessible room where random people wander in and out from time to time. It might behoove you to have an idle session timeout in this area set for one minute. This will combat the possibility of an outsider gaining access to the network or protected information.
Maybe you have another area that is behind locked doors and used only by employees with ID. You don’t want these people complaining that their computers keep locking whenever they glance down at their cell phones to read a text message, so you might want an idle session timeout of 10 or more minutes. So how do we stay secure and keep everyone happy?
Using a combination of AppSense and the Windows screensaver, we can meet both of their needs. As with many of the things I discuss, this presumes a device naming scheme that indicates the physical location of a device. It also presumes your ability to use that computer name as a condition within AppSense. If needed, you can refer to this post of mine for how that can be accomplished.
Did you know you can set any program you want to be a screensaver? You may be able to intuit the remaining steps yourself if I explain that we are going to set up a session disconnect command as a screensaver. From there, it’s simply a matter of updating the time before screensaver activation as a user roams. In the interest of a full walkthrough, though:
- Before we begin, you will need to know the disconnect command appropriate for your environment. If you are using View, you are going to be using a tsdiscon command as your screensaver. If you are using Citrix XenDesktop, you will need a tool provided by Xirtica Software called QuickDisconnect (available here). In the latter case, the tool requires an installation on your master image. You’re going to need a recompose to make this work anyway, so hopefully that isn’t a huge concern.
- Once you have your method available, you will need to turn it into a usable screensaver. As I do not have a reliable webhost to host these files for you, nor the desire to create each variation at this time, I will simply explain: Either through the use of AutoHotkey (with its simple compiler) or otherwise, write a script that runs either tsdiscon in the case of View, or /PATH/TO/QD.exe /DISCONNECT in the case of XenDesktop.
- Then compile the script to an .exe, and simply change the .exe extension to .scr. That’s it for that.
- To install the screensaver, place it in the %systemroot%\system32 folder, right-click and choose “Install.” You can, at this point, recompose your pool. The rest will be handled by AppSense.
- In your environment manager config, create a new node, referred to herein as “Set Screensaver.”
- Create an action to set the “Force specific screensaver” ADMX policy. In case you didn’t guess, you want to force the screensaver you made in step 2.
- Also in this node, create a condition to check against the name of the endpoint computer and value it with a string to reflect the area that needs its own timeout. For example, if all machines in the unsecured public area of my earlier example are WAITINGROOM-01 through “WAITINGROOM-10, “If computer name contains WAITINGROOM” will be one of your conditions. Create as many more of these as you need to cover all the areas requiring their own timeout settings.
- For each condition, create a Set Registry Value action that sets a reg_sz value for HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop\ScreenSaveTimeout to be the number of seconds until the session disconnects. For example, set the string to 60 if you want the timeout to be one minute. Set this value accordingly for each of the conditions you created in step 6.
- Trigger your “Set Screensaver” node at both login and at session reconnected/session unlocked.
And voila! As users roam about your premises, AppSense will check what computer they are accessing from and, based upon that device’s name, will change the Windows screensaver timeout period. You now have dynamic idle session timeout!
Once the screensaver is activated using Windows’ internal idle activity monitor, Windows will indiscriminately run a command that just so happens to disconnect their session. As a final word of warning: Windows has a preview of the screensaver built into the “Set Screensaver” section of the control panel. Accessing it after the steps above will “preview” your disconnect command, which will look remarkably similar to actually disconnecting your session. Don’t be alarmed–it just means it’s working.