Written by Michael Ibarra, Security Engineer, Mid-Atlantic Region
November 1, 2022
Many organizations use Microsoft Active Directory (AD) Group Policy (GPO) to standardize, provision, and apply changes to employee workstations. Changes to the Windows Registry, installed software, and Windows Update sources can be staged and pushed out to thousands of machines with relative ease.
For environments where Microsoft Edge is not the default web browser, Google Chrome is a common choice. Typically, large organizations will deploy managed policies that enforce their Acceptable Use Policy (AUP), including mandatory browser extensions to assist in Single Sign On (SSO) authentication and access to corporate applications. Google’s Enterprise policy provides guidance on how to configure dozens of parameters to meet any organization’s use case for managed employee browser sessions.
Other organizations, including those “born in the cloud,” use Google Workspace for domain, user account, and policy configuration. Cloud Management for Chrome is a natural choice for these scenarios, where Microsoft AD and GPOs are not mandatory. Google Workspace empowers businesses to maintain controls quickly, agilely, and securely through centralized, “infrastructure-less” policies.
What happens, however, when an organization needs to utilize both GPOs (Windows Registry-based) and Google Workspace policies (Chrome browser/application-based)? Some puzzling behaviors result, requiring specific steps to correct. This white paper will seek to clearly identify observed behaviors and offer solutions for resolving them.
Suppose an organization has users with Windows laptops, working remotely and on-prem throughout a given week. This organization has an on-prem AD environment with various GPOs in place, governing Windows Updates settings, etc. This organization also maintains a legacy Google Workspace environment with groups of users assigned specific Chrome browser extensions.
Google’s enforcement of which extensions are automatically installed is governed exclusively by each user’s Chrome profile if they are signed in with their Google Workspace account. The necessary configuration to enforce these controls is, therefore, contained entirely within Chrome’s application settings. The Windows Registry is not utilized in this scenario, as all Chrome extension settings are defined and applied using the Google Workspace admin dashboard.
Suppose another organization has the same user base, but without a presence in Google Workspace. Chrome is still the default browser, but extensions are managed exclusively by GPOs within the AD environment. Changes are applied to the Windows Registry (typically at user login), defining which extensions are required and/or allowed. These Registry keys are written to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome.
Key values 1, 2, and 3 correspond to individual extensions, identified by the value strings in the Data column. These are defined within a specific GPO and govern what extensions Chrome will forcibly install and enable.
Now, suppose an organization has several Google Workspace-defined extensions. This organization plans to deploy Check Point’s Harmony Browse solution as an installed extension. To do this, they must deploy it locally on each laptop, running it manually (using EXE), or via GPO (using MSI). In either case, it must be installed in a way that impacts the Windows Registry. This is significant because it forces Chrome to handle extensions delivered by two different means.
When an application is installed, the Windows Registry is modified with various keys and values relevant to the application and the settings it requires to run. This is true for Harmony Browse, which is installed either as a component of Harmony Endpoint or as a standalone application. In either case, Harmony Browse writes several entries for Chrome’s configuration to the Windows Registry.
Allowed Chrome extensions:
Required Chrome extensions:
And herein lies the problem: whether Harmony Browse is added to a laptop with already installed extensions (managed by Google Workspace), or to a brand new, freshly imaged laptop with extensions yet to be installed (by Google Workspace), the Windows Registry values in HKLM will always take precedence. In fact, they override any other extensions installed via Google Workspace.
Because Google Workspace installs extensions without modifying the Windows Registry, and the Windows Registry overrides anything not defined in the Registry, Google Workspace’s installed extensions will be effectively removed. And this is exactly what testing shows.
This presents a considerable problem for organizations utilizing Google Workspace for extension policies if they wish to install Harmony Browse (or Endpoint) using the required EXE or MSI installer.
There is only one “workaround” that solves this issue: cease using Google Workspace’s extension policies and utilize the Windows Registry (via GPO) instead.
This works because Chrome looks at a single source for its list of allowed and forced extensions. This is apparent in the list of forced extensions installed below.
Key 1 indicates Harmony Browse; this would be present no matter what other extensions are installed, since this is inserted by the EXE/MSI installer. Keys 2 and 3 refer to extensions previously installed using Google Workspace; because they are now listed alongside key 1, there is nothing the Windows Registry “overrides” within Chrome’s internal configuration. This, therefore, is the only solution that retains all desired extensions.
Pros
Cons
Through understanding a Windows application’s use of the Registry, overlapping and opposing behaviors can be resolved through creatively rethinking the boundaries of the solution itself.
Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)
