ow often have you been cajoled into troubleshooting a performance issue on an older version of Windows, brought up Task Manager and been bewildered by the list of processes running? Did you suggest a reformat, and sheepishly walk away with your engineering credentials slightly tarnished? Windows Vista brings order to this chaos through its new User Account Control (UAC) feature, which promises to put system administrators, programmers, and end users back in control. This article gives you the process you’ll need to develop UAC-aware applications.

The Model
Imagine that you operate a factory and that all employees have an access card. Regularly, someone at the factory shuts down the assembly line, but you cannot determine who’s doing so. Not only is someone stopping your production, but they are also allowing their friends in the factory. Those friends too, can stop the assembly line and invite their friends into the factory.

Pre-Vista Windows operating systems suffered from this same security model. If you logged in as an Administrator (and most people, particularly home users, did so), you?and any piece of code you installed or started?had carte blanche permissions to access or alter the file system, services, and registry. The solution to the factory’s (and Window’s) woes are one and the same; split the credentials required for different operations. For the factory, require managers to carry an additional security card required when stopping the assembly line. For Vista, provide an additional security token for selective tasks.

Figure 1. Disabling UAC from the Control Panel: Although you can disable UAC from the Control Panel, as this figure shows, you shouldn’t.

By default Vista users run as standard users?and that includes upgraded administrative accounts migrated from Windows XP. Tasks that require elevated permissions, such as installations, registry edits, and firewall configurations, prompt the user to confirm that action, and use an administrative token for authorization. A number of users have complained about the frequent confirmations required to carry out their day-to-day tasks on Vista. Some find it tedious, but I personally find it reassuring. On Vista, I know with better granularity what processes are doing what and how it might impact my operating system.

The Appeal
Before getting into the details of programming for UAC, I must stress that while UAC is a best-practices security model for Vista, it is not required to run Vista. In fact, you can disable UAC completely via Control Panel?> User Accounts (See Figure 1).

Although disabling UAC is tempting, particularly for new Vista users, my advice is, don’t do it. Disabling UAC opens the operating system to a huge variety of issues, especially rogue processes. The point, however, is that UAC-based security is not mandatory, but highly suggested. As such, reaping the benefits of UAC depends on users, system administrators, programmers, and corporate IT policy makers adhering to those best practices. Table 1 details the requirements and the potential benefits of adhering to best practices.

Step 1: Use User-specific Directories in Code
It is essential that applications reference individual user directories to store or access data. Applications that use hard-coded paths or that access protected system directories?and that do not have an embedded manifest?will unceremoniously generate an access exception and crash. To avoid this always use the Environment.SpecialFolder enumeration in your managed code when refactoring or writing new applications. The following code shows an example:

   String path = Environment.GetFolderPath(      Environment.SpecialFolder.LocalApplicationData);                  FileInfo fi = new FileInfo(path + "ProgramData.txt");   FileStream fstr = fi.Open(FileMode.Open);

Using the Environment.SpecialFolder enumeration value lets Vista determine the physical folder appropriate for the current user.

Figure 2. Setup Project Targeting the User’s Application Data Folder: When building setup projects, add configuration files and user data files to the “User’s Application Data Folder” item.

Step 2: Install Configuration and Data Files to User Data Directories
Windows Installer 4.0 provides support for installing user-specific data to the appropriate directories. In your setup projects, select “User’s Application Data Folder in File System,” and add your configuration and data files. Right-clicking on the setup project provides you with several options for packaging the output of your project. Figure 2 illustrates a properly configured setup project for output to the User’s Application Data Folder. In Figure 2, the Primary Content Output contains the ProgramData.txt file which the installed application can access using the SpecialFolder object, as shown in the example code in the preceding section.

Step 3: Create an Application Manifest File
If you attempt to run an application on UAC-enabled Vista without an embedded manifest file, any code or user action?even attempting to display a simple file dialog?can throw unhandled security exceptions. There are many scenarios where you might need to elevate the UAC access level for standard users, especially when porting a legacy application to Vista, and a complete UAC-refactor is not possible. There are three privilege execution levels, as shown in Table 2.

Here’s a sample application manifest that specifies the privilege execution level as asInvoker:

                                             requestedExecutionLevel level="asInvoker">                                              

Vista looks for the execution level whenever an application runs. Here’s the general process:

1. All users logged on to Vista have a current access token associated with the process that invokes the application. This is typically the standard user token.
2. When the application is invoked, Vista checks to see if the application manifest specifies a requested execution level. If the application doesn’t have an embedded manifest, Vista runs the application with the same permissions as the invoking process’ access token.
3. When a manifest is present, then the user experience and permissions are determined by a combination of three elements: the invoking process’ access token, the requested execution level (asInvoker above), and the security prompt settings.

Following this process using the manifest shown above, Vista finds the manifest, determines that the requested execution level is asInvoker, and checks the requested level against the user’s access token. When the user’s access token is standard user, Vista will launch the application with standard user permissions.

If the application-requested execution level were highestAvailable or requireAdministrator instead, Vista would check the security prompt setting. The security prompt setting can automatically launch the application, deny such requests, or prompt for credentials, all depending on the invoking process’ access token.

Step 4: Setting Security Policy
The behavior of the three execution levels listed in Table 2 depends on the local security policy, which you can access by running secpol.msc. The security policy provides options for the elevation prompt for standard and administrative users, as shown in Figure 3. There are eight additional UAC-related security policy options. You can find full details by selecting each option, then clicking the Explain tab.

Figure 3. Setting Security Policy: The figure shows the local security policy modified to avoid showing an elevation prompt to standard users.

The decision as to which execution level to specify in the manifest depends on a number of factors, but primarily on the nature of the application and targeted user. If you know that the application targets standard users, and you don’t want to allow them to perform administrative tasks, then restricting the new process to the same standard-user token as the invoker buys you that assurance. In contrast, if your application must occasionally perform administrative tasks, such as opening a firewall port, the highestAvailable setting guarantees that users will be able to accomplish the operations. If you are running an application that is primarily administrative and you need to allow full access, the requireAdministrator setting provides a one-click lowering of Vista’s defenses.

Note that applications ported from early versions of Windows that could?if built for Vista?work as standard-user applications may require administrative token access via the credentials prompt or administrative approval mode until they can successfully incorporate best UAC practices.

Step 5: Embed the Application Manifest
Presumably, future releases of Visual Studio .NET will provide the ability to easily embed the application manifest in the executing assembly. For now, however, it’s a bit cumbersome. One option is to use the manifest tool mt.exe. Another is to use a side-by-side option, where the manifest resides in the same directory as the executing assembly. In my tests, however, using the resource compiler to create and embed a manifest that needs to be included with each build provided the quickest method.

Follow these steps to create and build an embedded manifest:

1. Create a text file with the following content:

   #include    #define IDR_MANIFEST 1 // use 2 for a DLL      IDR_MANIFEST RT_MANIFEST MOVEABLE PURE   {       "                                                                                                "   }

2. Specify the requested execution level. Save the file with an .rs extension. Use the resource compiler rc.exe to compile the resource file.
3. In the project’s properties, select the resulting .rs file as a resource.

Step 6: Test with Standard User Analyzer

Figure 4. Standard User Analyzer: The figure shows the Standard User Analyzer screen after it detected a File Access violation.

Microsoft has created a Standard User Analyzertool (now distributed as part of the Microsoft Application Compatibility Toolkit), which provides helpful information when developing UAC-savvy applications. The Standard User Analyzer lets you launch your application and reports errors and warnings that a standard user would see. As a side note, the Standard User Analyzer is fairly verbose, reporting multiple warnings and errors on a default Windows Forms application. It does, however, also find valuable information, as shown in Figure 4.

Critical Takeaway Points
To work successfully with UAC, developers and administrators need to carefully think though when and why a particular end user might require administrative rights, and except for those particular instances, restrict rights otherwise whenever possible.

1. UAC’s many benefits are only as good as the policies of end users, IT professionals and programmers. To reap those benefits, programmers should adopt a standard-user bias, eschewing administrative access if and when possible.
2. Store user data in user-specific directories, never in system directories.
3. Configure elevation prompts for administrator approval and credentials using secpol.msc
4. Create embedded manifests for applications and assemblies that require elevated permissions. Future releases of Vista will require developers to include this manifest (and will also require applications to be signed).
5. An intelligent security policy must attend to the “weakest link in the chain.” Allowing even one application to run with required administrative-token access can cripple an operating system even when the other 99 percent consists of UAC standard user applications.

With Vista UAC, Microsoft has provided the community with a very flexible account control model. User Account Control can dramatically improve security by factoring out administrative specific tasks that expose critical parts of the operating system. However, it also means that developers must pay more attention to isolating shared and user-specific data and limiting registry and network configuration access, as well protecting the file system. These changes potentially require code modifications and a new familiarity with the process of embedding application manifests.