When Windows Vista launched, we made the decision to disable User Account Control – UAC – because it seemed to be an unnecessary complication. We were already tightly locking down our PCs with Group Policy and none of our users have admin rights, so our exposure to threats was comparatively limited. We kept UAC disabled through Windows 7 and our limited use of Windows 8.1, but as we prepped for Windows 10, we needed to completely revisit UAC.

In Windows 10, Metro apps – which includes the Edge browser – require UAC to be enabled to work properly. With UAC disabled we had inconsistent behavior, where sometimes Metro apps would launch, and other times they would fail with the below error:

So it was time to turn UAC back on.

We immediately ran into problems with a couple of end-user applications that were requesting elevation. Since our users do not have admin rights and therefore cannot elevate, these applications would not run. What made no sense though is these were programs that had worked fine with UAC off, and with standard user rights, so it stood to reason they didn’t actually need elevation to function.

Thus began my exploration into why these applications were requesting elevation. They weren’t installers, and they weren’t trying to write to protected directories. Turns out they were just poorly coded.

UAC-compliant applications are supposed to explicitly request the level of permissions they require through an application manifest.

You can use mt.exe found in the Windows SDK to extract and change application manifests.

To extract:     mt.exe –inputresource:myexecutable.exe;#1 –out:extracted.xml

The manifest itself is just XML, so open with whatever plain-text editor you like and look for the section like this:

<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
   <requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>

Notice the “level” parameter, set here to “requireAdministrator” – this, not surprisingly, tells Windows that the application requires administrator rights and thus must request elevation.

Change “requireAdministrator” to “asInvoker” – this will allow the app to run in the security context of the user launching it. Now we need to import the edited manifest back into the application.

To import:    mt.exe –nologo –manifest “editedmanifest.xml” –outputresource:”myexecutable.exe;#1″

Once that was done, our problem application stopped asking for elevation. Problem solved.

Understand though that this only works because the application didn’t need admin permissions – it just wanted them. An app that actually requires admin rights will not work properly without them.

There was one lingering question I had though: Why did this app actually work with UAC turned off? Turns out the answer is simple. With UAC disabled, when a standard user runs an application that’s set to “requireAdministrator,” the elevation fails silently, allowing the app to launch. Since this particular app didn’t need elevation, it ran fine, and we had no idea of the underlying problem.

Now if we could just get the developer to do things properly…