Dealing with User Account Control (UAC)

While testing the implementation of my previous blog, Installshield Automation Using c#, a build error number -6017 occurred. This error states that COM information cannot be extracted from the COM server in the project. The only reason this could happen is because I ran the IS project without administrative privileges.

So this brought me to my new blog topic ‘UAC’.

With the arrival of Vista, windows 7 and Server 2008 and having developed applications that run on the those platforms, one thing that I have consistently dealt with is, permissions to resources. Reason being the new technology namely, UAC, which was introduced by Microsoft on the latest windows releases. The main purpose of this feature is to protect the OS by running applications with reduced privileges.

UAC has two dialogs; A blue one which indicates that the application is trusted and signed.

A yellow dialog that show that your application is not digitally signed and it is not fully trusted.

User Account Control prevent low privilege applications from doing the following :

1. Perform a window handle validation of higher process privilege.
2. SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.
3. Use thread hooks to attach to a higher privilege process.
4. Use Journal hooks to monitor a higher privilege process.
5. Perform DLL injection to a higher privilege process.

src: http://msdn.microsoft.com/en-us/library/aa905330.aspx

In my development, how do I deal UAC it?

There are several methods  that can be used:

1.     Including a UAC manifest that will cause the application to request administrative privileges at start up:

a.    To add a manifest file in VS2008, just right click on your solution then from the menu choose add>new Item. Now from the new Item dialog box select the “Application Manifest File”. Edit the file as follows.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

    <security>

      <requestedPrivileges>

        <requestedExecutionLevel level=" requireAdministrator”    uiAccess="false"/>

        </requestedPrivileges>

       </security>

  </trustInfo>

</assembly>

b.     Under VS2010 it is a little different. Right click the Project and select Properties. Select the "Application" tab and then click "View Windows Settings". This opens the manifest, and then you can make the changes you need. VS2008 procedure works too.

     2. The second method is to isolate the part of your code that requires elevated privileges into an application that uses a UAC manifest to require administrator privileges. Your application does not need to run as admin, when these privileges are required you should invoke the external application. Here is some code prototype you could use.

    using System.Security.Permissions;

    using System.Diagnostics;

            ProcessStartInfo processInfo = new ProcessStartInfo();

            processInfo.Verb = "runas";

            processInfo.FileName = [Add filename here];

            Process.Start(processInfo);

     If you would like your application to behave differently depending on if the current user has admin rights, you can use the code below;

        WindowsIdentity identity = WindowsIdentity.GetCurrent();

        if (identity != null)

        {

            WindowsPrincipal principal = new WindowsPrincipal(identity);

            return principal.IsInRole(WindowsBuiltInRole.Administrator);

        }

The code will return true if administrative and false otherwise.