Internet Explorer Protected Mode Elevation Policy and Administrative Templates

Overview:
You probably have run through the following popup when using Internet Explorer add-ons and extensions:

In this example, I clicked a link in an Internet web page that pointed to an XPS file.
This prompt is due to the fact that Internet Explorer is running in Protected Mode, and tries to open an application or extension outside of Protected Mode.

The IE behavior regarding this prompt is governed by the following registry keys:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy. Some software installation programs register themselves under this key (each with its own subkey GUID) to manage Protected Mode behavior. On the same hand, if Microsoft determines that an application has a vulnerability and presents a danger to end users, Microsoft reserves the right to remove that application at any time from the elevation policy.
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy. When the user checks the “Do not show me the warning for this program again” in the prompt dialog, Internet Explorer writes a subkey GUID and associated values under this key to “register” Protected Mode behavior for a given application for that particular user.

You can check more details at https://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx and https://blogs.msdn.com/b/ieinternals/archive/2009/12/01/understanding-internet-explorer-security-protected-mode-elevation-dialog.aspx

If an administrator wants to deploy specific Protected Mode prompts for specific applications, can do two things:

• Directly change HKLM\HKCU keys. This can be implemented through logon scripts (HKCU part) or PC imaging/software deployment (HKLM part). The caveat is that the setting is not enforced (users can override it) and leaves traces on the system that need to be tracked back.
• Apply changes in Policies branches. This overrides the actual HKM\HKCU keys, enforces behaviors does not alter system configuration and cleanly disappear when the Group Policy settings are removed, so this is the recommended approach.

Managing Elevation Policy through Group Policy:
Using Group Policy infrastructure, you can actually change the Protected Mode behavior, to for example, always prompt for to allow an extension to run. Notice the greyed-out checkbox. This prevents the user to check it and override this prompt.

In the same manner, you can use Group Policy to hide prompts for trusted applications automagically, so if you are deploying an application you can transparently run it through Protected Mode (i.e. Microsoft Office Live Meeting) whenever it gets deployed to the managed desktop computer, without bothering the user with the security warning.

The problem here is that neither Windows Vista nor Windows 7 (or their server counterparts) include an Administrative template to manage these settings out of the box, so https://support.microsoft.com/kb/918239 provides some guidance and templates to manage these configuration. However, the provided ADM/ADMX are not perfect. This is how it looks in GPEditor:

The problems of this ADMX include:

• Hardcoding. The provided ADMX hardcodes registry values for the applications you want to manage in the ADMX itself, not through policy options. It actually behaves as an “configuration set” that applies elevation policies to applications as specified within the ADMX.
• No customization point for administrators. Administrators only can set the policy to Enabled or Disabled, and does the registry changes included in the ADMX. If the ADMX includes three applications with specific elevation policies, administrators cannot configure just one of them or change the elevation policy from what is hardcoded in the ADMX. If there is need for delegated administrators to manage different policies or application sets, they need to generate separate ADMX files.

So I decided to give ADMX creation a try, and end up with the following:

The advantages of this custom ADMX include:

• Information for administrators. ADML file includes details for administrators about what the policy does and how to configure it.
• Allows to customize up to 15 applications (by default).   Administrators can specify executable names, paths, CLSIDs and policy levels. Actually, the ADMX file can easily be extended to support whatever number is needed beyond 15.
• Provide a common GUID space for policies. ADMX file uses registry subkeys under Software\Policies\Microsoft\Internet Explorer\Low Rights\ElevationPolicy in the form of GUIDs like {DEADBEEF-CAFE-DEAD-BEEF-000000000001}, {DEADBEEF-CAFE-DEAD-BEEF-000000000002}, {DEADBEEF-CAFE-DEAD-BEEF-000000000003}, up to {DEADBEEF-CAFE-DEAD-BEEF-000000000015}. For lower OU levels GPOs to override higher level OU GPOs, you just need to customize a few and set the rest to “Disable”.
• Support for variables in extension path. In the extension path textbox, administrators can specify %ProgramFiles%, %SystemRoot% or other variables to avoid hardcoding paths.

Here are the ADMX files. Just copy ADMX to “%SystemRoot%\PolicyDefinitions” and ADML to “%SystemRoot%\PolicyDefinitions\en-US”, or place them in Central Store.

Elevation Policy ADMX.zip

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  Thanks, your custom ADMX is a lifesaver. Is the implementation of this policy considered to be a workaround to deal with ActiveX that are not (yet) IE8/IE9 compatible on Windows 7? I have used your ADMX to account for an EXE which apparantly does not have a GUID - nothing gets written into HKCU-or-HKLM..(SoftwarePoliciesMicrosoftInternet ExplorerLow RightsElevationPolicy). The maker of the ActiveX has acknowledged that their ActiveX needs updating but in the meantime, I'd like some form of workaround if that's even possible. Thanks for your valuable insight.