Microsoft

AppSec can help restrict application access in Win2K

Restrict user access to a predefined set of programs with Microsofts Application Security Registration Utility.


Administrators rely on an arsenal of tools and tricks as they wage their never-ending battle to maintain server security and stability. One common strategy is to restrict user access to a limited set of authorized programs. Savvy administrators in charge of numerous Windows Terminal Servers and/or Citrix servers have long relied on Microsoft’s Application Security Registration Utility to accomplish this. Commonly known as AppSec, this comprehensive, easy-to-use GUI-based application allows you to restrict user access to a predefined set of programs. Let's take a look at how to install and configure Appsec.exe and see why it's the tool of choice for application restriction.

Preliminary details
We need to mention a few important facts about AppSec before proceeding. First, AppSec is computer-specific and not user- or group-specific. This means you must install and configure the program on each server you intend to administer. It also means that the program will limit application execution to the list specified for any user logged on to the system who is not an administrator of that machine.

Second, AppSec can be used to restrict access only to 32-bit applications, by default. However, if Ntvdm.exe is added to the list of authorized applications, you can also restrict 16-bit apps. Third, AppSec restricts executable files by name. This means that a user could theoretically replace a valid executable file with a different unauthorized file. For example, a user could change the name of the prohibited Sol.exe (Solitaire) to the authorized Excel.exe and run the popular card game. Windows 2000 security must be used to prevent a user from replacing or renaming application files in this manner.

Get the latest version of AppSec
A search on Microsoft’s Web site for information pertaining to AppSec will point you to the Microsoft Windows 2000 Resource Kit CD. I can save you some valuable time here: Although you may find a version of AppSec on the Resource Kit CD, it is missing three critical files—Appsec.cnt, Appsec.dll, and Instappsec.exe. AppSec will not work properly without these files. However, you can fix your installed Resource Kit version of AppSec by installing Microsoft’s AppSec hotfix. You can also download the corrected version of the AppSec tool here.

Working with AppSec
Now let's look at the process of installing and configuring AppSec. Once you have the correct version of AppSec downloaded to your system, finish the installation by double-clicking on Instappsec.exe from within the installation directory. You are now ready to run the Appsec.exe utility. When you open AppSec, you should see the list of authorized applications, as shown in Figure A.

Figure A


To add applications to this list, simply click Add. Then, in the Add Authorized Application dialog box, type the path to the applications or click Browse to locate the applications. When you finish adding applications, the list should contain all the executables your users are authorized to run. (You can also remove applications you don't want users to access.)

Remember that any executable not included in this list will not run when a nonadministrator logs on to the system. Users trying to run an unauthorized application will receive a message telling them that they do not have the required permissions to run the application.

Application tracking
One problem with application restriction is that one application will sometimes invoke another application. A common example is Microsoft Outlook, which calls Winword.exe if Microsoft Word is set as the e-mail editor. AppSec has a handy feature that shows you what executables are invoked when a particular application is used.

The Start Tracking button lets you run applications just as the typical user would and track all other executables that are launched by the system. Running this feature on my system revealed that, due to my e-mail scanning option, Norton used the executable Navw32.exe. I might not have noticed this had it not been for this application-tracking feature. It let me know that the executable Navw32.exe could be added to the list of authorized applications.

Figure B shows the results of running application tracking on my system.

Figure B


What about Group Policies?
If you're familiar with Windows 2000 Group Policies, you know that there's a setting you can enable to prevent Windows from running programs that are specified as disallowed (Figure C). Using Group Policy restrictions for executables offers the advantage of letting you set restrictions based on groups.

Figure C


Unfortunately, this prevents users from running only programs that are started by the Windows Explorer process. They may still be able to run programs that are started by the system process, such as Task Manager, or by other processes. Access to the command prompt by the user can totally negate the effectiveness of controlling applications using Group Policies, since this does not prevent them from starting programs in the command window that they otherwise would not be permitted to start using Windows Explorer.

A big improvement
Before AppSec, admins who wanted to restrict access to applications were limited to the old tricks of editing the RestrictRun registry key or even deleting unwanted executables. RestrictRun modifications were somewhat effective, but they could be easily circumvented by running the restricted executable from the command shell. Manually deleting files was often time-consuming and could keep admins from running applications they needed for troubleshooting.

Windows 2000 Group Policies added some enhancements to restricting authorized executables; however, it suffers from some of the same problems as RestrictRun. That's where Microsoft’s AppSec comes in. It's clearly the tool to use when it comes to restricting executables.

Editor's Picks

Free Newsletters, In your Inbox