Introduction
Designing a computer kiosk, where people can walk up and access a set of information online without being able to access all websites, is an application that seems tailor made for a thin client. Low power usage, remote management, no data stored locally - these are all things you want when you're deploying a computer in a public area. However, locking down the machine -- Xenith side and windows side -- can be tricky. Here's a quick guide to get you going
A Dedicated User
The first thing you need to do is setup a user account that will you can use for the kiosk. You'll need the machine on the domain, but presumably most users accessing an information kiosk are not going to have a logon to your domain.
So create a user, and give them logon access only to the Kiosk VM(s). You'll also want to make the password something totally unrelated to any other password you use on your systems. While I haven't found a way to extract the password for the Xen.ini auto logon, I'm sure it's possible; it pretty much has to be passed to it/stored in cleartext.
Locking down the Thin-Client - Xen.ini config
Note: These configurations are done on Firmware 2.0_104 - mileage may vary on different firmware
Beyond the usual lock-down you'd have on any thin client, there's a few special configurations for the Xen.ini file you'll want in a Kiosk environtment
USB Devices
You probably won't want users to be able to plug in USB devices to the Kiosk - all sorts of bad things could happen, and there's really no reason to have it in a kiosk. Physical security goes a long way here (have the thin client in a locked cabinet where users can't access it) but you can disable forwarding of USB Devices through Xen.ini as well. It'll look something like this; disabling sound is optional.
SessionConfig=ALL unmapprinters=yes unmapserials=yes disablesound=yes unmapusb=yes unmapclipboard=yes
Auto Login
As I mentioned, users accessing a public information kiosk probably won't have credentials for your domain. This means you'll have to log them on automatically with the generic user. This will make the thin-client invisible to the user, and prevent domain users from logging in with their accounts. The configuration will look like this
Signon=Yes
DefaultUser=kioskusr
Password=asupersecurepassword
DomainList="yourdomain"
Disable Thin Client Lock
You won't want users to be able to lock the terminal - since your target audience won't have any idea what the password is. So you'll want to disable the key sequences that can lock the terminal.
Note: There seems to be a bit of a bug with the key sequences config. According to the documentation, all you should need is "KeySequence=No" in my testing that doesn't work you must user the following.
KeySequence=yes ctrl+alt+down=no ctrl+alt+left=no ctrl+alt+right=no win+L=no
Other Considerations
Those are all of the configurations I made special to Xen.ini for a kiosk. However, your default Xen.ini may be less locked down than mine, so here's some other configs that will probably be necessary.
- Disable G key reset: "EnableGKey=no"
- Lockdown Thin: "Privilege=None, LockDown=yes"
- Disable that annoying system beep: "Device=audio mute=3"
XenDesktop Setup
Note: This setup is on XenDesktop 5.6 - setup may differ (and in fact does) on different versions.
I won't go through the process of setting up machines on XenDesktop. If you haven't created machine pools and delivery groups yet, you're reading the wrong guide. This is just a quick note to show how to assign a VM to specific thin-client. This works better than assign a VM to the kiosk user, because it prevents the kioskusr account from being used on other thin clients.
Full information can be found
On Citrix's Support Site. From PowerShell on the DDC, run the following commands - replacing "domain\machine" with your kiosk machine name, and the IP with the address of your thin client.
Add-PSSnapin Citrix.Broker.Admin.*
Set-BrokerPrivateDesktop DOMAIN\MACHINE_A -AssignedIPAddress 10.11.132.7
Windows Customization/Lockdown
Locking down windows so that users cannot get out of the Kiosk mode is key. You don't want users to be able to access any files or other programs on the machine. Optionally you'll also want to restrict web browsing so that users cannot access things like facebook,news sites, or any inappropriate content. For this example I am using Google Chrome because it has a built-in kiosk mode and a bunch of add-ins that make it easier to restrict web browsing.
Some of these precautions are redundant, and you may be able to make a secure environment with just some of them. My goal was to create a system that was easy to manage while being escape-proof, so there's generally a reason for the redundancy.
Disabling CTRL+ALT+DELETE
The most difficult thing to disable on windows is the ctrl-alt-delte sequence; however it is necessary to disable this so that users cannot use it to escape the kiosk mode. The ctrl+alt+delete sequence is embedded deep in the windows operating system and, because it is a security concern and would break normal usage, cannot be disabled through conventional means. The only way to disable is to stop the interpreting of the ctrl,alt, and delete keystrokes (or at least ctrl, and alt). To do this, we must re-write the scan codes for those keys in the registry. I won't go into much detail here, because the article I'm linking does a pretty good job of explaining how to do this, and how it all works.
Don't reboot the machine after you apply this before reading the next section.
With that,
enjoy this wonderful article
Removing the CTRL+ALT+DELETE for Logon
The most notable thing disabling ctrl+alt+delete does is break the logon process. If you can't press ctrl+alt+delete to logon, you're going to lock yourself out of the machine. Even XenDesktop utilizes this (it has to) so we need to turn it off.
So in keeping with the spirt of just linking to other sites,
here's the Microsoft KB article on how to disable the "require ctrl+alt+delete for logon" feature.
Using AutoHotKey to reassign keys
The northcode article on remapping keys in the registry does a good job of disabling most of the problem keys that allow users to escape from a kiosk mode. It doesn't get all of them though. Notably F1, which usually brings up help menus, and right-clicking, which brings up all sorts of difficult-to-manage context menus. Now, we could add this through the scan code method above, but I find it more useful to use the program AutoHotKey (ahk) to do some remappings. This is because it is far easier to manage and more humanly readable, and because it is simple to remap things to something other than nothing.
Example
Sendmode Input
SetTitleMatchMode 2
F1:: Send {Browser_Home}
F9::.
RButton::.
The first two lines just configure some settings for the AHK program, you can read more about what they do specifically on the AHK website (Sendmode Input | SetTitleMatchMode). The next line re-binds the F1 key to the browser home button. This is useful because
the home button will be hidden in Kiosk mode, and the normal home-button hotkey (alt+home) will be disabled.. The other two lines rebind F9 and the Right mouse button to do nothing. You can read a whole list of keys/rebindings here on the AHK website.
I rebound all of the Fkeys and most shift+key shortcuts (user's can fill out forms on my kiosk, so disabling the shift key all together is not practical).
Using AutoHotKey as an Idle Timer
Generally when you have a kiosk, it is in a public area. So you'll probably want a nice welcome page to greet each new user. Since the users can hardly be expected to go back to the home page themselves when they are done, we need a way of detecting when a user has walked away from a kiosk, and sending the browser back to the home page. It turns out this is pretty simple to do with AutoHotKey.
Loop
{
WinActivate Chrome
if A_TimeIdle >= 90000
{
Send {Browser_Home}
}
Sleep 3000
}
This starts an infinite loop that checks how long a user has been idle every 3 seconds. The WinActivate Chrome line is another bit of security. Sometimes when the thin auto-logs-in, the taskbar is visible - that is chrome is not the active window; so someone resetting the thin client could theoretically escape the kiosk mode. This command forces chrome as the active window if it is not currently. Because it does this every three seconds, it also adds security because it means someone won't be able to do much if the user finds a way to alt-tab out of chrome.
A_TimeIdle is a system variable in AHK, it automatically keeps track of how long it has been since the last mouse/keyboard input. In my script, if there hasn't been any input in 90 seconds (90000 milliseconds), it resets to the home page. I choose A_TimeIdle here rather than A_TimeIdlePhysical (which detects only physical mouse/keyboard input, not input from programs/scripts) because otherwise after 90 seconds it would refresh the page every 3 seconds. Using A_TimeIdle, when the
Send {Browser_Home} command is sent, it detects that as input, and resets the counter; it will wait another 90 seconds before refreshing again.
The last line is just a simple wait command that prevents the loop from running too quickly and hogging system resources.
Another way I found works, if you want to check for idle more often, but not have the page refresh constantly, is to run the check, but then set a delay after the first refresh. For example, This Script checks every 30 seconds, but then waits 2 minutes after it detects idle before it checks again.
Loop
{
WinActivate Chrome
if A_TimeIdle >= 30000
{
Send {Browser_Home}
Sleep 120000
}
Sleep 3000
}
I'm realizing this post is probably already waaaay too long, so I'm going to arbitrarily cut it here. Stay tuned for next installment where I'll detail setting up chrome in kiosk mode, setting up startup/login scripts, and restricting user access to unauthorized websites.
Next part is up!
