Sometimes when we run an application on Windows 10 we are presented with a prompt saying “Do you want to allow the following program to make changes to your computer?”. This is a User Account Control (UAC) message telling the invoking user that the application needs to be run at a higher integrity level, and is the same message that we see if we right-click and run as administrator on Windows 10.
Integrity Levels
When a user logs in to Windows 10 they are assigned a security token. This security token contains an integrity level which determines what files, registry and other aspects the user has access to. Standard users typically have a Medium integrity level.
- Untrusted Integrity: Given to anonymous processes.
- Low Integrity: Commonly used for Web-facing software such as browsers.
- Medium Integrity: Applied to standard users and used for most objects.
- High Integrity: Administrator-level access, generally requires elevation.
- System Integrity: Reserved for the Windows kernel and core services.
- Trusted Installer: Used for Windows Updates and system components.
A Low integrity example is Internet Explorer Protected Mode, whereby Low integrity disallows that process from writing to many locations to prevent harmful attacks over the web.
However some applications need to accomplish tasks that standard users don’t have privileges to do, such as writing to the HKLM registry or writing to files in C:\Program Files. So UAC intercepts and prompts the Medium integrity standard user to run the application as a High integrity admin user instead.
Run as Administrator on Windows 10 with App-V 5
This functionality works great. But when you consider that the App-V file and registry locations are essentially sandboxed, the application doesn’t necessarily need to be run as administrator on Windows 10 with App-V 5 in order to write to the virtual registry and file system.
But the problem we have is that when a standard user launches the App-V 5 virtualised application, UAC will still intercept and request a High integrity token. So what we can do is suppress this request for a High integrity request by forcing the executable to run as the invoking user (RunAsInvoker).
Suppress High Integrity Request with RunAsInvoker
Who remembers when we used to add this to an OSD in App-V 4?
<ENVLIST>
<ENVIRONMENT VARIABLE="__COMPAT_LAYER">RunAsInvoker</ENVIRONMENT>
</ENVLIST>Some people were confused with what we were trying to accomplish here, by assuming that we were making the shortcut target run as an administrator on Windows 10 with elevated privileges! But instead what we were essentially doing is overriding the request for High integrity by telling the shortcut target to run as the invoking user instead (with Medium integrity)!
The OSD illustration above was literally setting an environment variable called “__COMPAT_LAYER” to “RunAsInvoker”, and only persisted for the current launch of the shortcut.
Since App-V 4 is no longer supported on Windows 10, there are multiple other ways to run applications as the invoker as opposed to running as administrator.
Set the RunAsInvoker Compatibility Layer During Sequencing
The first option is to create a system environment variable during the sequencing phase called __COMPAT_LAYER (note the double _) with a value of RunAsInvoker
Set the RunAsInvoker Compatibility Layer in a Shortcut
The second option is to create a custom shortcut in your App-V application. Essentially we point the executable to the cmd.exe process and we pass it two commands to process. The first is to set the environment variable
SET __COMPAT_LAYER=RunAsInvoker
and the second is to run the target executable
START "" "C:\Program Files\Alkane.exe"
.
In one line it will look like this:
cmd.exe /c SET __COMPAT_LAYER=RunAsInvoker & START "" "C:\Program Files\AlkaneApp\Alkane.exe"Set the RunAsInvoker Compatibility Layer via the Registry
Another option is to configure a specific executable to RunAsInvoker via the registry:
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files\\AlkaneApp\\Alkane.exe"="RunAsInvoker"You could also add it via a script:
<MachineScripts>
<PublishPackage>
<Path>reg</Path>
<Arguments>add "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v [{AppVPackageDrive}]\Alkane.exe /t REG_SZ /d RunAsInvoker /f</Arguments>
<Wait RollbackOnError="false" />
</PublishPackage>
</MachineScripts>Set the RunAsInvoker Compatibility Layer using a Shim
A while ago I wrote a blog explaining how to create a shim for App-V 5 to run an executable in Windows XP SP3 mode. This same principle applies, but this time you wont select ‘Windows XP (Service Pack 3)’ in the drop own list but instead you’ll only select the RunAsInvoker checkbox under ‘Additional compatibility modes’.
Set the RunAsInvoker Compatibility Layer in the Manifest.xml
And finally (although you shouldn’t really get to this point) you could hack the manifest of the executable.
Briefly, the manifest.xml file contains settings related to how the application should be configured during launch – for example, it can configure the required integrity level. An example would look like this:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>and we would need to change it to this:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>There are two ways to do this. One method is to hack the internal manifest.xml using resource hacker and saving it directly. Another option is to use resource hacker to read the manifest.xml contents and then create an external manifest called (for example) Alkane.exe.manifest. Inside this file we would paste the duplicated content whilst changing the
level
to
asInvoker
. But since Windows typically prioritises reading internal manifests over external manifests, we would need to set a registry configuration to tell Windows to prioritise external manifests instead! To do this we must ensure that the following values are set to a DWORD of 1, and then reboot:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
PreferExternalManifest 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\
PreferExternalManifest 1
If you need a specialist application packaging service to deliver your small or large projects on time and within budget, contact Alkane Solutions.