How to Implement a Windows-Based Kiosk

What is a kiosk? In the context of this article a kiosk is a Windows workstation having limited functionality, usually placed in an area with public access. A person can walk up to it and, without having to log on, access information in the form of a database, application, internet, etc.

Define Requirements
Designing the Solution
Pilot Deploy
References

A few of my projects as an AD Engineer for the XYZ Company were to design and facilitate implementation of kiosk systems across the United States. These kiosks had varied requirements defined by the stakeholders, but one commonality was that they were required to be members of the Domain. Therefore, locking down the workstations and providing only the required level of access were crucial to security.

Rather than re-engineer the solution for later versions of Windows, I’m presenting it as originally designed in a Windows 2000 Server and 2000 Professional environment. I’m relying on my memory and hope it doesn’t fail me on any of the particulars.

Define Requirements

In this example the kiosk will be in a common area where different employees, who do not have domain credentials, will use the system to access a custom application via web browser. The kiosk must automatically present the application when the machine is powered on, and if the user closes the program it must automatically restart. The user must not be able to log off, shutdown the system, or access anything other than the application, with the exception of a local printer.

Designing the Solution

I considered creating a base image with all or some settings configured and applying the rest with Group Policy, but I decided to go with a default OS install and apply nearly all settings with Group Policy. This would be easier than maintaining multiple images with drivers for different machines. Since the workstations were new installs, setup technicians could assist in configuring the local printer and verify the kiosk is functional.

The Group Policy wasn’t as complicated as first anticipated because of some pre-defined Group Policies named Intellimirror Scenarios. They needed to be downloaded from Microsoft and imported into Active Directory. Fortunately there was a scenario named Kiosk that looked like it was custom made for my requirements. Only a few additional GPO settings needed to be configured. I created a domain user account to use for auto-logon and edited a registry key setting, configured IE settings including default homepage (the URL to the application), and the policy was ready to lab test. The GPO would be linked to the OU containing the kiosk computer objects and use Loopback Processing Replace Mode. This was necessary because Default Domain Policy had user settings defined that were less restrictive than those required for the kiosk. When the user (auto-logon) authenticates the user’s policies are applied and then the settings defined in the kiosk GPO “Loopback” and apply.

Pilot Deploy

Since the solution involved several layers the entire install was tested and verified before moving into production deployment. The kiosk OU was created, computer objects pre-created in the OU, GPO configured and linked to the kiosk OU, User account for auto-login created in the Users Container, and detailed instructions for the set up technician as follows:

Set up a machine and install the operating system.
Set up and install a local printer.
Configure TCP/IP settings and join the domain (restart).
Restart a second time.

In theory a second restart should not be needed to apply the GPO. In some cases multiple restarts were needed, but when the policies were applied the configuration worked perfectly. The stakeholder verified the requirements were met and approved the solution for production.

I hope this information is useful.