Utility Spotlight
The Shared Computer Toolkit
Jeremy Moskowitz
One of the most common requests I get at my Group Policy forum,
GPanswers.com, is how to take machines and "lock them down." People want to ensure their machines can’t be broken by Joe User or Harry Badguy. The out-of-the-box Group Policy settings can go a long way toward solving this conundrum. But the settings can only take you so far.
Computer lockdown can get complex fast. You might not know who’s walking up to the machine, but you may still have to give them some portion of your network resources, such as Internet browsing, file viewing, or printing.
You would typically find computers like these in public places like universities, airports, hotels, community centers, museums, kiosk stands, and conference centers. These aren’t the kinds of machines that your typical business workers use day to day; these are machines where people need sporadic access, people you may or may not trust.
.gif)
Figure 1 Getting Started with the SCT
What you need is a way to restrict anything from being written to the Windows® partition. You need a way to trap the bad stuff, but keep the good stuff like critical Windows updates and antivirus updates. You want to lock down Windows so it’s much harder to get to the under-the-hood stuff like the C:\Windows directory. And you need a way for new users to get a guaranteed profile, so you’re dictating their experience, not fighting to clean up after them. You might also want to manage exceptions. That is, you might want to have a known or trusted user use this shared PC for some specific task, and to make sure that his data and settings stick around.
What you need is the Shared Computer Toolkit (SCT). The SCT is not specifically meant to be loaded on every desktop to restrict the actions of day-to-day employees (though I’m sure some enterprising geeks will attempt to roll it out to an entire corporation). It’s also not really meant as a "parental control" device either, though some attributes of the Shared Computer Toolkit might be useful for this.
Requirements
To use the SCT, you need to be running Windows XP Service Pack 2 (SP2) with at least 1GB of unallocated space (though having 10 percent of the hard drive unallocated is recommended). This unallocated space will be converted into a special protection partition by the SCT. You might also want to create a second partition for Use data, also known as a persistent partition. For instance, if someone uses this machine for his daily work, you might want him to be able to save Microsoft® Word documents on this additional partition.
One of the tricks is starting with a machine that is already running Windows XP SP2 and carving out some unallocated space. Typically, when Windows is installed, the entire hard drive is used. However, any commercially available repartitioning tool will make it possible.
You can use SCT both with computers that are joined to a domain and those that are not. I’ll examine both scenarios here.
Getting Started
After you’ve repartitioned the computer, take the following steps to use the SCT:
- Install all the applications that you want to make available on the shared computer.
- Remove Windows components that you don’t want people to use (or would be potentially dangerous to use) like IIS or Outlook® Express.
- Install the SCT after installing the required User Profile Hive Cleanup Service (UPHClean).
- Configure the SCT.
Once the SCT has been configured, its goal is to keep your computer as clean as the day you installed it. So be careful that you’re not loading junk on your shared computer as you’re preparing it for use.
At the heart of the SCT is the Windows Disk Protection (WDP) service. The goal of WDP is to trap writes to the Windows system volume and temporarily store them on the protected partition so users can’t actually do any permanent damage to the real Windows partition. Once the session is over (and the computer is rebooted), any accompanying potential damage is vanquished.
The SCT cannot prevent certain attacks. Even though the SCT will help you lock out common functions like direct access to Windows Explorer, that doesn’t mean an application you’ve installed and made available for use doesn’t have Explorer-like capabilities. For instance, many applications allow you to browse the contents of the hard drive when you’re in their File | Open dialog boxes. The SCT will ultimately prevent the disruption of Windows—that is, the WDP ultimately discards any writes to the system volume. However, it is incapable of preventing this kind of poking-around attack if enabled by an installed application.
To download the SCT, go to
microsoft.com/windowsxp/sharedaccess. The SCT installation is a wizard-driven snap to use. It does require an additional package called UPHClean, which is popular with Terminal Services administrators whose users have difficulties logging off Terminal Services while saving their User Profiles settings. UPHClean is now a required component for this SCT. It would have been nice if the SCT installation didn’t make you download it separately, but simply made it part of the SCT installation.
Configuring the SCT inEight Easy Steps
Once SCT has been installed, configuring it is made easier with a Getting Started page (see Figure 1), which guides you through the step-by-step process. The second step, as seen in Figure 2, is mostly configuring security-related Group Policy settings within the local Group Policy Object (GPO). In most cases, you’ll want to make sure all boxes are checked.
.gif)
Figure 2 Group Policy Settings for Security
In Step 3, you create a new local user and give it a name of your choosing, such as Public. Step 4 has you configure the user account the way you want: choose the desktop wallpaper, accept first-time run settings and license agreements (for programs such as Windows Media® Player, Microsoft Office, and Adobe Acrobat Reader), add printers, and so on. Your configuration of this profile will determine how all public users of this machine will see it.
In Step 5, select the Public profile and lock down some additional settings, as seen in Figure 3. There are too many options to delve into right here. Thankfully, the recommended settings can all be selected with one checkbox. Defaults here include the restriction on running applications from USB thumb drives, restricting the running of system tools (such as regedit.exe), and preventing users from right-clicking within Internet Explorer®. Optional restrictions, such as "Remove CD and DVD burning features" and "Prevent printing from Internet Explorer," are welcome additions.
.gif)
Figure 3 Restricting User Options
You actually test the Public profile before you go into lockdown mode in Step 6. This enables you to see what the user will see, but still makes it easy for you to go back and make changes.
Step 7 contains the secret sauce—the Windows Disk Protection service, which requires a reboot before it can be configured. Here, you can specify whether to retain changes made by public users and how critical updates will be handled (see Figure 4).
The WDP features a very, very strong protection mechanism with four choices.
.gif)
Figure 4 Windows Disk Protection
Clear Changes with Each Restart Once this function is turned on, the system is officially protected. All historically vulnerable parts of the system, such as the registry, services, even critical boot files like boot.ini and NTLDR, are protected from permanent harm.
Save Changes with Next Restart Once the SCT has been running for a while, you might want to add another application to the system or make another permanent change. Select "Save changes with next restart" and you’ll have skirted around WDP this one time and integrated your changes. Restart the computer before you load your new application, so as not to keep something bad or unknown. Then, once loaded, select "Save changes with next restart."
Retain Changes for One Restart If you’re installing a new application that requires a reboot, select this option. Once you’ve loaded and configured the application correctly, pick the "Save changes with next restart" option to permanently seal in your changes.
Retain Changes Indefinitely If you want to load many applications and watch their interactions over time, you might select this option. Once you’re ready to accept your changes, select "Save changes with next restart." If you want to back out of all changes, select "Clear changes with each restart." This functionality is great for training centers where a new class comes in every week and you want students to have free rein over the computer. You can let them do what they want and they can restart the computer as often as necessary. At the end of the week, just clear the changes and the computer will be restored to its Monday morning state.
Another way to think about these settings is that once WDP is turned on, all changes are written to the protection partition until you choose "Save changes with next restart," and they are merged with the real partition.
All About Updates It’s likely your other corporate computers are downloading critical Windows updates from Microsoft or from Windows Server™ Update Services (WSUS) by themselves (see
my article about corporate WSUS settings in
TechNet Magazine). But computers using the SCT need for you to grab these updates manually. When it’s time to automatically install patches, the interactive user is logged off, and during the critical updates installation time, no users (other than administrators) can log on. It should be noted that when critical updates are downloaded, they are always written directly to the "real" Windows partition and not the protection partition. The process is quite elegant: an automatic reboot clears any potentially damaging changes users might have introduced, and then the updates are written. This ensures that only the critical updates make it onto the disk.
Large Environments
So far, the discussion has been for one standalone PC—not a domain environment. One PC is a good start, but corporations, schools, and other organizations will need to use this in a larger environment. The two additional scenarios to consider are domain-connected SCT machines and a mass deployment of the SCT (domain-joined or not).
If your target SCT machine or machines are domain-joined you can, of course, go through all the steps I’ve listed to get the job done. But that means you have to visit each and every computer to do the job. Instead, the SCT team (thankfully) rounded up their hard work and made a Group Policy Application Distribution and Management (ADM) template file that snaps into the Group Policy Editor. This file (SCTSettings.adm) is located in the C:\Program Files\Microsoft Shared Computer Toolkit\bin directory. This enables you to make mass changes on multiple SCT-enabled machines, as seen in Figure 5. The ADM template is a little rough around the edges and could use some refinement of the Explaintext entries, but it’s a really good start.
There are some additional technical obstacles to overcome with domain-joined machines. For instance, how do you run around to 1,000 SCT-enabled machines and reconfigure their disk-protection settings? Thankfully, there’s a DiskProtect.wsf provided for scripting the behavior of your SCT-enabled machines. You also need to manually implement the suggested software restriction policy settings which prevent system tools and unwanted programs from running. This is all explained in Chapter 10 of the Shared Computer Toolkit Handbook, which is available in the Shared Computer Toolkit program folder on the Start menu after you install the Toolkit.
The next hurdle is mass deployment. How do you get the SCT bits and pieces on the target machines in the first place? The suggested avenue here is to embed the preinstalled SCT and corresponding bits inside your "ghost-style" or "RIPrep" image build. Or, if you deploy clean machines, you could simply script the UHPClean and SCT installation using a postinstallation script or use Group Policy Software Installation and simply assign both UHPClean and the SCT to your shared computers via Active Directory® and Group Policy.
Once you have the required bits on the machines, use the included Group Policy ADM and VSB files to control the computers after they’ve been deployed.
There are just a few other issues to think about. Every computer running Windows must be expressly validated by Windows Genuine Advantage. This becomes a bit of a problem because each machine needs to be touched, either by installing an Internet Explorer ActiveX® control (see "
Running the Windows Genuine Advantage Validation Tool") or running an HTML application, or HTA (see "
Validate Windows Using an Alternate Method").
Also, how do you remotely repartition a computer’s hard drive if you don’t want to trot over to it? Remember, every SCT computer needs the required protection partition. There are some possibilities through the use of software such as Systems Management Server (SMS) and some custom scripting solutions, but if you have your own ideas of how to mass validate computers via an HTA or remotely repartition a computer, don’t keep it a secret! Let me know and I’ll post a follow-up on
GPanswers.com.
Final Outcome
Once the computers have been deployed, your users log on with the username you set; in my examples it was Public. If you were using a domain account, you could use domain credentials as well. Once they’re logged on, it really is a restricted, fully managed machine as seen in Figure 6. SCT is a really great tool with lots of potential uses. The tool itself as well as the documentation is well thought out, and the additional control via Group Policy is just icing on the cake.
Online support for the tool is available at the
Microsoft newsgroups.
.