Using registry-based group policies in applications

Group policies let you control and tweak thousands of Windows settings. But group policies aren’t limited to Windows or Microsoft applications: we can also use group policies to manage custom applications, either by registering a group policy extension for the app, or (more commonly) by using registry-based policies.

The idea of registry-based policies is quite straightforward:

• An Administrative Template File (ADMX) defines the set of available policies, and which registry key and value each policy corresponds to. For example, a policy Enable automatic updates might correspond to the value EnableUpdates = 1 in HKLM\Software\Policies\Your\App.
• After determining the effective set of policies that should apply to a user or computer, Windows populates the registry keys and values based on the mapping defined in the ADMX.
• When a user launches the group policy-enabled application, the application checks the respective registry keys and values, and adjusts its behavior or feature set accordingly.

By convention, the registry keys used for registry-based policies are:

• HKLM\Software\Policies\Your\App (and HKCU\Software\WOW6432Node\Policies\Your\App) for computer policies
• HKCU\Software\Policies\Your\App for user policies

Preferences vs policies

Policies differ from preferences: Preferences reflect a user’s choice, and it’s typically at the user’s discretion to change a preference. In contrast, policies mandate a certain behavior, and users are not supposed to change or override them.

Preferences are also commonly stored in the registry, typically in:

• HKLM\Software\Your\App (or HKCU\Software\WOW6432Node\Your\App) for computer preferences
• HKCU\Software\Your\App for user preferences

Things get interesting when there is a preference and a policy to control the same thing: for example, an application might allow a user to enable or disable automatic updates and also allow administrators to control the same setting via group policy. In such a scenario, we might have up to registry keys/values to consider:

• Preference in HKLM\Software\Your\App (compute preference)
• Preference in HKCU\Software\Your\App (user preference)
• Policy in HKLM\Software\Policies\Your\App (computer policy)
• Policy in HKCU\Software\Policies\Your\App (user policy)

Evaluating policies

So what’s the right order to process preferences and policies in if the various registry keys/values contradict another?

• Policies vs preferences: The idea of a policy is to constrain the possible settings a user can configure, so policies should always have precedence over preferences.

• Computer preferences vs user preferences: While there is no hard-and-fast rule, the convention typically is that HKCU overrides HKLM – that is, the user can override whatever settings have been configured at the machine level.

• Computer policies vs user policies: Surprisingly, I couldn’t find any authoritative information in the Microsoft docs on whether computer policies should override user policy, or vice versa. However, The Ultimate Windows Server 2003 System Administrator’s Guide provides an answer (p 301, emphasis mine):

  Both user-related and compute-related Administrative Template nodes are used to modify Registry settings. The related Registry database settings are located in the HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM) Registry keys. Whenever policy changes are made to the Administrative Templates portion of the GPO, the Registry keys HKCU and HKLM are also updated. If there is a conflict between computer and user settings, the computer settings take priority.

  Notice the difference to preferences: While HKCU typically overrides HKLM for preferences, it’s the other way round for policies.

Taking these rules into consideration, the order or priorities should be:

1. Policy in HKLM (Computer policy)
2. Policy in HKCU (User policy)
3. Preference in HKCU (user preference)
4. Preference in HKLM (machine preference)

And consequently, the order in which to process settings should be:

1. Preference in HKLM (machine preference)
2. Preference in HKCU (user preference)
3. Policy in HKCU (user policy)
4. Policy in HKLM (computer policy)

Security

HKCU is a user’s private hive, and users have full read/write access to most parts of this hive, including HKCU\Software. Does that mean user’s can simply edit their user policies, rendering them ineffective? Luckily, this isn’t the case.

The DACL of HKCU\Software\Policies disables inheritance and defines more restrictive access than the rest of HKCU\Software. In particular, the DACL only grants users read-access – so users can read their policies, but they can’t change them. Obviously, this protection is only effective as long as a user doesn’t have administrative privileges. A local administrator can grant themselves access to the registry keys, and modify them at will.

For more details on the security benefits and pitfalls of group policy, Exploiting Windows Group Policy for Reconnaissance and Attack is an interesting talk to watch.

• Share this article: