Managing a Custom Shell Using Active Directory
Microsoft Retail and Hospitality
Summary: This article introduces Windows policy-based management, which provides an easy, simplified approach to securing the desktop for point of service, and it explains how to do this across a retail organization. (12 printed pages)
Technology is pervasive—from digital menu boards in restaurants, to gift registry kiosk at the local department store—it's everywhere. As consumers, we increasingly use technology in every aspect of our retail life, and the industry is becoming much more reliant on these types of devices in order to provide end users with services. These touch-points, often referred to as point of service, include all points of contact in the store, on the cruise ship, in the hotel, at the casino, or in the restaurant.
Microsoft provides a number of platform offerings for point of service, including Windows XP Embedded, Windows XP Professional, and, more specifically, Windows Embedded for Point of Service. Each of these platforms provides capabilities that are optimized for specific functions, and they are often selected by customers based on specific deployment or hardware requirements.
Not surprisingly, each platform includes support for Windows Explorer—the operating system shell that we are accustomed to seeing and using every time we sit down in front of our Windows PC. As the basis for our everyday computing experience, Windows Explorer is the portal into our computer. Windows Explorer provides the services necessary for us to interact with the applications installed on our computer, and to manage most of the common settings related to our PC.
While we have grown accustomed to the everyday activities exposed by working with Windows Explorer, this desktop experience was designed with the home or office user in mind—creating a multi-tasking, multi-activity operating environment. When we begin to consider point of service, however, the activities become much more specific for that device, and the services offered by Windows Explorer become, in many cases, irrelevant. In fact, most of the services are probably not desired, because they enable the end user to change the appearance of the device, or access other system services—something not typically reserved for the user of point of service.
This leads us to a fundamental question: How do we protect the desktop from the end user, while still providing the functionality necessary for our point of service? Fortunately, Windows provides a very rich environment for "securing the desktop," including built-in enterprise tools that create an economy of scale when considering hundreds, thousands, or even tens of thousands of devices that may be deployed across a retail organization.
In this article, we will introduce Windows policy-based management, which provides an easy, simplified approach to securing the desktop for point of service, and we will discuss how this can be done across a retail organization. While this article does not serve as a complete reference on device security, it does provide a solid foundation for constructing secure principals for restricting access to specific activities on point of service.
Microsoft Active Directory is a directory service that was introduced in the Windows 2000 product family. Since that time, it has gone through several upgrades, including the latest in Windows Server 2003 R2 and Windows XP Professional SP2. A directory service, much like a directory on your computer's hard disk, provides an organizational structure for storing information.
When we think of Active Directory, we think of a directory service that organizes all the IT resources found within the company. In the case of retail, this would include the servers in the stores, all points of service, users, and devices such as printers—the list goes on. Active Directory provides computing organization that is able to map to your company's organizational structure. Retail often spans geographies, countries, and, in many cases, continents. Within each of these, there are often regions or districts, and then individual entities such as stores. Active Directory provides the facilities to represent this type of organizational structure efficiently.
With the proper organization, it is then possible to group users, computers, and devices such as peripherals to where they reside within the company. All of these are referred to as Active Directory objects, and they are stored in the directory in what are known as organizational units (OU). Active Directory takes the complexity out of managing the connections between these objects, and provides a holistic view of the organization, so that you can think of structure in terms of your business rather than the underlying directory technology.
Active Directory also is responsible for securing all of the objects within the organization. Based off a technology named Kerberos that was originally developed at the Massachusetts Institute of Technology, Active Directory is able to ensure that devices and users that connect to the network are able to do so securely, while also protecting the data that is transmitted between them. Protection starts by first ensuring that users are able to use Windows devices only in the manner that was intended for the organization. In the case of point of service, this includes restricting use to features or functions that are not intended for the end user.
The directory does this through a mechanism known as network policy-based management. Policy-based management enables an administrator at the server to define policies that enable or restrict a user's or device's access to specific configuration settings or, more importantly, capabilities of the system. These policies are then stored in the Active Directory. Each policy defines specific settings for users or devices. Settings are applied by the administrator to specific organizational units, which, as you may recall, form the atomic unit within our Active Directory for organization. When a user or device then connects to the network, Active Directory ensures that the correct policies are applied for the user or device.
An Introduction to Group Policy
Group Policy Objects (GPO) contain well over a thousand settings for controlling access to various features and settings that affect Windows Security, Windows Desktop, Internet Explorer, and Windows Firewall—even software distribution. While it is not always necessary to configure each of these settings, understanding what policies are available greatly simplifies the process of securing the device and, ultimately, restricting a user's access on the point of service to specific activities or applications.
There are two flavors of GPO: Local Group Policy Objects (LGPO), and non-local or Network Group Policy Objects (GPO). While we will focus our attention on GPO, LGPO deserves an introduction in order to understand the distinctions between the two. Keep in mind that GPO, unlike LGPO, was introduced in the previous section as network policy-based management and is managed entirely by Active Directory.
Local Group Policy
Local Group Policy Objects (LGPO) are limited, compared to network GPO, because only one LGPO is present on a computer; this LGPO is stored in a hidden folder on the system drive. As a result, the ability to control individual settings based on users, or to quickly change the configuration of a machine based on its location within an "organization," is restricted compared to network GPO. There are far fewer settings available to machines that are only managed through LGPO, including network security and software restrictions.
Access to LGPO is managed using the Group Policy Object Editor on the machine where the policy is managed. This GPO editor is a Microsoft Management Console (MMC) snap-in named gpedit.msc, and it can be run directly or found under Administrative Tools. Figure 1 shows the Group Policy Editor in Windows XP Professional.
Figure 1. Local Group Policy Object Editor (Click on the image for a larger picture)
A final word on managing local group policy: While local group policy templates can be used to simplify the management of LGPO, there is no built-in reporting mechanism for auditing changes to policy. Users that are part of the Power Users or Administrators group have the ability to change local group policy, and therefore the potential exists for policy to be changed if adequate controls are not in place to prevent changes. This is in contrast to network group policy, which is refreshed on configurable intervals.
Network Group Policy
Network Group Policy Objects (GPO) are far simpler to manage from an enterprise perspective; they are configured centrally and only once for each policy set, and are implemented as a feature of Active Directory. Active Directory is a service of the Windows platform; it is supported by Windows Server, and provides the means to manage strong identities and relationships between users and computers.
The notion of strong identities implies that they span the network instead of only surviving on the local computer. Configuration settings can be managed based on a running user identity, on the groups or organizational units a user belongs to, or on the machine identity itself. Unlike Local Group Policy Objects, GPO is managed centrally, and it is deployed to a computer when the computer attaches to the network or when a user logs into the computer.
Besides having far more controls in place than LGPO, network GPO is refreshed on a configurable, periodic interval. The process of auditing changes and ensuring that the correct policy is in place is greatly simplified.
Point of service applications provide a common application experience that is typically composed of a simple or compound application that provides a consistent look and feel. The experience is typically defined based on the purpose of the device, or it is based on the logged-on user where a device services multiple scenarios.
Network GPO provides a convenient mechanism for setting up and managing the user experience. Since GPO provides the ability to control the look and feel of the device based on the logged-on user, the purpose of a device can be quickly adjusted through policy changes. Very similar to LGPO, network Group Policy is managed using the Group Policy Editor for Active Directory. Figure 2 shows the Group Policy Editor for Active Directory.
Figure 2. Active Directory Group Policy Object Editor (Click on the image for a larger picture)
By creating a custom GPO, the administrator is able to customize the desktop and security settings for a device or user that will be running the point of service application. After creating the GPO once, it is possible to deploy to an unlimited number of managed devices with minimal effort assuming an Active Directory infrastructure is already in place.
A sample GPO to secure the desktop for a single application could, for example, do nothing more than the following:
- Change the user's shell so that Windows Explorer does not run, removing access to the most common desktop functions.
- Automatically start the point of service application and wait for the application to exit before it takes appropriate action. For example, it might be desirable to log out the user or to restart the application if it exits unexpectedly.
- Remove access to common Windows Security dialog functions, which are visible when the user presses CTRL+ALT+DELETE.
To demonstrate we are going to create a GPO that restricts a user's access to a single application. For our application, we will use a sample point of sale application. Since we don't require the services of the Windows Explorer shell, we will replace it with a custom shell that provides only the services that are necessary to start our application and sign out the user when the program exits.
The Custom Shell
Using Group Policy, we can easily replace the Windows Explorer shell with our own "custom shell." In our sample, we are going to replace the shell with a Visual Basic script that Windows Scripting Host will launch when the user signs in. Our shell will provide the following services to the user:
- Launch the point of sale application
- Monitor the point of sale application for termination
- Log off the user
Although primitive, this is all that is required for a functioning shell. In our example, we will name our custom shell myshell.vbs—this is important, because we need to specify this later when we create our Group Policy Object. Our script also makes extensive use of Windows Management Instrumentation (WMI) to access the management functions of Windows. While a thorough discussion of WMI is beyond the scope of this article, its capabilities are documented in the Windows Platform SDK.
The first thing we must do when our shell starts is launch our point of sale application, because this is the only activity that our shell supports. We accomplish this by using the Win32_Process class that is part of WMI.
strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process") errResult = objWMIService.Create("C:\Retail\Application\POS.exe", "C:\Retail\Application\", null, intPosID)
By using the Create method on the Win32_Process class, we are able to instruct our script to start the application that is located under C:\Retail\Application; we will assume for demonstration that our point of sale application was previously deployed as part of a depot process or as part of a centralized push using the services of Microsoft Systems Management Server, Active Directory Software Distribution or other software distribution service. The Create method returns the system process ID for the application, and stores it in the variable intPosID.
Once we have launched the application, we then need to subscribe to the classes events, enabling us to discover when the application has exited.
Our shell will now wait until the process exits, by monitoring for events that originate from a process with our system process identifier. When an exit event is received, we then use the Win32_OperatingSystem class to log off the user.
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set colProcesses = objWMIService.ExecNotificationQuery _ ("Select * From __InstanceDeletionEvent " _ & "Within 1 Where TargetInstance ISA 'Win32_Process'") Do Until False = True Set objProcess = colProcesses.NextEvent If objProcess.TargetInstance.ProcessID = intPosID Then Exit Do End If Loop
Instead of logging off the user, we may have chosen some other sort of action to take, such as restarting the application. For our example we will assume that when the application exits the user should be logged off the system since there are no other activities supported by our shell.
Group Policy Management
Now that we have created our custom shell, it's time to target the users that will receive the custom shell, and to create the Group Policy Object that secures our desktop for the point of sale application. We start by using the Group Policy Management Console (GPMC), which was released for Windows Server 2003.
The GPMC unifies the management of Group Policy by creating a convenient view of both organizational structure and Group Policy–related settings in a single console. The GPMC is downloadable from the Microsoft website, and it runs on both Windows Server and Windows XP.
The first thing we need to do is select the Organizational Unit (OU) that we want to apply our new policy to. For our example, we have already defined an Organizational Unit in Active Directory for our users, named Point of Sale Users (see Figure 3). This could easily be another organizational unit already defined in your Active Directory.
Figure 3. Point of Sale Users OU (Click on the image for a larger picture)
Inside the Point of Sale Users OU, we have defined a user, John Smith. We will use this account later to test our Group Policy Object. Next, we will create a new GPO named Custom Shell GPO, and link it to our OU.
We start by opening the Group Policy Management Console and selecting our Point of Sale Users OU. Next, we right-click our OU, click Create and Link a GPO Here (see Figure 4), and name our new GPO.
Figure 4. Creating a new GPO
Once we have named our new GPO and linked it to the OU, we can start configuring the policy settings for this object. Editing the policy object is done using the Group Policy Object Editor.
Figure 5, shows the new policy linked beneath our Point of Sales Users OU in the Group Policy Management Console.
Figure 5. Newly created and linked GPO (Click on the image for a larger picture)
Configuring the Group Policy Object
Since the policy that we are creating is based on the user, not the computer itself, we will only be modifying the User Configuration portion of the policy object.
Beneath the User Configuration portion of the custom GPO, we find the Administrative Templates (see Figure 6), and in there are the policies that we are going to modify.
Figure 6. Administrative Templates of the custom GPO
The following tables detail each of the policies that we have configured in our Group Policy Object.
Shut Down Command
We have removed access to the Shut Down command. This command normally appears in multiple places, including the Windows Security dialog box that is accessible be pressing CTRL+ALT+DELETE.
Table 1. Start Menu and Taskbar
|Remove and prevent access to the Shut Down command||Enabled|
Custom User Interface
This is the most significant change, because we have replaced the Windows Explorer shell with the custom shell script that we created earlier.
Table 2. System
|Custom user interface||Enabled|
|Interface file name (for example, Explorer.exe)||wscript c:\scripts\myshell.vbs /nologo /b|
The remaining policies remove access to the other options available in the Windows Security dialog box. Figure 7 shows what the Windows Security dialog box might normally look like with no policies defined.
Table 3. System/CTRL+ALT+DELETE Options
|Remove Change Password||Enabled|
|Remove Lock Computer||Enabled|
|Remove Task Manager||Enabled|
Figure 7. Standard Windows Security dialog box (no policies defined)
With our Group Policy Object created and linked to our OU, and our custom shell script and application installed on the client, we are now ready to deploy our point of service. The first time the user John Smith logs in to the device, the GPO that we created will be deployed. The first noticeable change is absence of the standard desktop shown in Figure 8.
Figure 8. Standard Windows desktop (no policies defined) (Click on the image for a larger picture)
Instead, when John Smith logs in, he sees the point of service application interface shown in Figure 9.
Figure 9. Point of service application UI
If John Smith presses CTRL+ALT+DELETE, he would see a Windows Security dialog box with limited options, as shown in Figure 10.
Figure 10. Limited Windows Security dialog box (policies defined)
The policies that were defined in our GPO have now been applied, and the policies that we set have disabled the functions previously accessible in the dialog box. As long as the GPO remains linked to the OU that John Smith resides in, he will be unable to access the Windows Security dialog box or the Windows Explorer shell.
There are well over a thousand settings that can be adjusted by using GPO, and many of these provide even finer-grained control over a user's access to applications and other machine settings. With the appropriate infrastructure and a good understanding of the end user run-time requirements, creating a Group Policy that is right for your point of service can be made both easy and manageable. Not only does GPO provide an efficient way for managing both users and devices, but creates an economy of scale for managing users, devices, and applications across the entire organization from corporate to the store.