How to Block Installation of Google Chrome

You’ve set up your infrastructure to provide the most productive work environment possible for your users.  You adhered to company management and IT policies and created a system to control access to the Internet for the company’s and user’s protection.  Then you discover someone found a way to bypass those controls.  Welcome to today’s world in IT administration.  Managing your users is not too different from parenting your children.  They are going to test the boundaries.  If they can, they will.

I recently had been tasked with preventing users from installing and running Google Chrome.  This company had an extensive Group Policy system in place to control how users are able to access the web via Internet Explorer.  Whether or not it was because an astute user discovered they could bypass those controls using Google Chrome, or it was just “automagically installed”, it was against the company’s IT security policy.  These users do not have local administrator permissions on their machines, but alas, that is not necessary to install Chrome.  Standard users can install it.  Google Chrome installs to the user profile, in the \AppData\Local folder rather than the Program Files folder.  Users have full administrative rights to their profiles folder, so therein lies the problem for us hall monitors. This is where Group Policy Software Restriction Policies come to the rescue to block Google Chrome from installing and running.

How to configure the policy to block installation of Google Chrome.

1. Edit or create a new GPO contain the settings to disable Chrome.
2. Navigate to User Configuration -> Windows Settings -> Security Settings
3. Right-click Software Restriction Policies, and select New Software Restriction Policies.
4. Right-click Additional Rules, and choose New Path Rule
5. In the Path field, type exe.
6. Select Disallowed in the Security level drop down menu, and click OK to save the rule. 
7. Add the following rules by repeating steps 4-6:
   • Chrome.exe
   • Gears-Chrome-Opt.msi
   • Chrome_Installer.exe
   • GoogleUpdate
   • C:\Program Files\Google\Chrome\Application
   • C:\Program Files (x86)\Google\Chrome\Application
   • C:\Users\%username%\AppData\Local\Google\Chrome\Application\Chrome.exe
8. When complete, this is how the Additional Rules in your Software Restriction Policy should look:
9. Link the GPO to the domain, or for more refined restriction, to a specific OU.
10. If you should need to also block Mozilla Firefox, you’ll need to create 2 rules with these Paths:
    • Firefox exe
    • Firefox Setup*.exe

Installation of Google Chrome will now be disabled, and users will receive a notification that their system administrator has blocked the program.  But now what do you do for admins or web designers who have permission to run Chrome, or other web browsers – for testing or whatever the need may be?  Fortunately, you can control how Group Policies are applied by filtering the scope of the Group Policy Object.  I need to point out that this process should be performed using group membership rather than individuals to simplify administrative overhead of keeping the filtering up to date. The following steps contain additional configuration for allowing Chrome access for specific groups.

How to allow Chrome access for specific groups.

1. To exempt a group from being blocked, for example, Domain Admins, delegate permissions.
2. In the GPO, on the Delegation tab, click on the Advanced
3. Select the target group in the top window, and scroll down to Apply group policy in the bottom window, and check the box under Deny. Click OK.
4. In the example above, I also created an AD security group, Google Chrome Block Exception, and added it by clicking the Add button. Then, I denied the policy from applying by checking the box.  This group allows us to add members who need to use Chrome, but we don’t have to make them a Domain Admin.

You have now disabled Google Chrome for all users that are not specifically allowed access to it.  At the end of the day, it’s just another tool we system admins have in our arsenal to combat the introduction of unauthorized applications into our network.  That could compromise the security and productivity we’ve implemented in our network, which might make the end of the day come much later.

About the Author

Donny Hilbern is a network and systems consultant specializing in analyzing, designing, and implementing network and enterprise systems.  Donny has been working in the IT field for over 25 years, with nearly 20 years of that time invested in network and system administration and infrastructure technology.  He has experienced a number of undocumented or lightly documented issues during that time.  His desire is to leverage that experience in sharing about some of those issues and how they were resolved to make IT work for his clients.