RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


A Programmer's Exploration of Vista's User Account Control : Page 3

Vista's User Account Control (UAC) improves security, but making it work smoothly requires a little more developer work. Find out what you need to know to code Vista UAC-aware applications.

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:
  2.    #include <winuser.h>
       #define IDR_MANIFEST 1 // use 2 for a DLL
           "<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" 
              <asmv3:trustInfo xmlns:asmv3=
                      uiAccess=""false"" />
  3. Specify the requested execution level. Save the file with an .rs extension. Use the resource compiler rc.exe to compile the resource file.
  4. 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.

John Douglas is the founder and Director of Mycos Technologies, a .NET-centric outsourcing company and Microsoft Certified Partner in the Custom Development Solutions Competency located in Chiang Mai, Thailand.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date