There are a number of settings for Google Chrome which are applied as "policies". Under the hood, these are registry entries, typically located at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. These policies are nominally designed to be enabled by Group Policy in an Active Directory environment (using ADM or ADMX files). Many of them work whether the computer is joined to a domain or not; presumably Chrome is just reading the registry value.

However, some policies only work when the computer is joined to Active Directory or "or Windows 10 Pro or Enterprise instances that enrolled for device management" (see link). Since the policy configuration values are ultimately just registry entries, then Chrome must be going out of its way to check if the computer is in Active Directory.

What I want to know, is there a way to deceive Chrome about the computer's Active Directory membership, or some way to otherwise convince Chrome to honor these policies regardless?

  • Chrome engages in a number of questionable privacy related actions - some are network related, such as reporting "metrics". Others are more invasive, like the software reporter tool or chrome cleanup. I want to disable these things, but the policy only works if your computer is in an Active Directory, and I don't have one of those.
    – William
    Jun 11, 2019 at 12:41
  • You can configure group policies locally (gpedit.msc, run as admin) & Google does suggest doing it that way. However I can't speak to that specific policy or those that mentioned needing AD chromium.org/administrators/policy-templates
    – gregg
    Jun 18, 2019 at 16:45
  • The problem is Gregg that although you can set the policies through local group policy Chrome just ignores a few of them if you aren't domain joined or enrolled in some other device management
    – Patrick
    Jun 24, 2019 at 15:28

3 Answers 3


I have found, or rather "created" a solution. I don't recommend this, but it has worked.

Here's some background. Google Chrome restricts certain policies to computers which are domain members. I have not found an explicit reason for this, but the gist I get from reading documentation and notes suggests that this is a security precaution, as if a domain administrator has magical security powers. Chrome checks for domain membership by using the IsOS function exported by the SHLWAPI dll. The DLL is imported into "chrome.dll", which is typically located in a directory like c:\Program Files (x86)\Google\Chrome\Application\75.0.3770.80\chrome.dll.

It is possible to apply a binary patch to chrome.dll to redirect calls to IsOS to another function exported by SHLWAPI. A good match I have found is "ChrCmpIA" which will always return true given the arguments which are otherwise passed to IsOS. chrome.dll imports IsOS by ordinal (rather than by name) - IsOS has an ordinal of 437, and ChrCmpIA has an ordinal of 587. An ordinal of 437, as stored in the DLL looks like this 0xb5,0x01,0x00,0x00,0x00,0x00,0x00,0x80 . It can be replaced with 0x4b,0x02,0x00,0x00,0x00,0x00,0x00,0x80 . As of version 75, Chrome has two ordinal exports of 437, only the first should be patched. A program like HxD can do this without too much trouble. I've used this on Chrome 75.0.3770.80 (64-bit), as installed by the enterprise MSI package; it may work on other versions too (as this recipe does not use hard-coded addresses).

Standard disclaimers - Back up your chrome.dll first (or be prepared to reinstall). Don't do this, except for "educational purposes". Use this strategy at your own risk; there is a slight possibility of data loss, being fired, deportation and revocation of citizenship, or even influenza.

  • 1
    I don't consider this to be a good answer; I think it's only adequate (so I'm not going to mark it as the accepted answer, at least not for a while). It's possible that there might actually not be a good answer; I've skimmed the Chromium source code, and the IsOS hack is the best I found.
    – William
    Jun 18, 2019 at 20:16
  • Not sure why you got the downvote, this is the clearest, indeed only, attempt to provide a functional and useful answer to the question posed. It's brilliantly hacky though, which I appreciate, but I'm not sure I'm ready to roll this out across the estate just yet :)
    – Patrick
    Jun 24, 2019 at 15:27
  • If you want to take the API-override approach, a much more robust (and supportable) technique would be the Windows' Application Compatibility Shims framework. A custom shim can transparently intercept API calls, change parameters, handle the call itself, or redirect the call. Apr 3 at 2:58

We can fake the domain enrollment as shown in this article.
Supported in various Windows 10 and 11 editions except Home.

  1. Make a system restore point or a backup first
  2. Save the following code into a "fake-domain.reg" file (quotes enforce the extension)
  3. Run regedit as Admininstrator
  4. Import the file from its File menu
  5. Open chrome://policy in the browser and click Reload policies

; # Fake MDM-Enrollment - Key 1 of 2 - let a Win10 Machine "feel" MDM-Managed

; # Fake MDM-Enrollment - Key 2 of 2 - let a Win10 Machine "feel" MDM-Managed
  • This actually works.
    – trlkly
    May 8, 2023 at 0:52

You could:

  • Spin up a Linux VM.
  • Configure a SAMBA to act as a Domain controller.
  • Join your Windows PC to that domain

I don't think you would even need to leave the domain controller running. It would remain joined even when the VM is off.

SAMBA CONFIG: https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller

  • 1
    The question was specifically about getting the chrome policies to apply where no domain existed. A solution of 'get a domain' doesn't really answer the question that was asked, although it would of course resolve the issue.
    – Patrick
    Jun 18, 2019 at 12:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .