Jump to content
EduGeek EdSec 2026 is Go! 27th Oct in Derby! Join us for a day of EdTech security focused talks, networking, and an evening social ×

Recommended Posts

Posted

Lots of our users are getting Google Chrome installed on their machine here suddenly and Chrome, as much as it's personally my preferred browser, has a history of playing havoc with some of our programs, or not being supported by vendors. Even more-so, it seems, after we uninstall it if it's been the default browser (which it sets itself as during install, it seems)

 

Internet shortcuts break, MSOffice sometimes breaks, bad registry keys left behind, etc. which results in us having to do a full reimage of the machine to fix.

 

Software Restriction Policy may be useful here, but with an updated EXE (hash no longer matching) or a renamed file (name no longer matching) will cease to work

Creating read-only sections on C:\ may be another route to look down, but may not be useful as t'interwebs says Chrome sometimes installs to AppData and some other locations. We're in the middle of switching to local profiles so we can't create read-only directories in AppData either.

There's always the option of stopping them being LocalAdmins but that's there as a legacy thing and I'm not 100% sure if there's no reason for them to have it anymore.

 

(I think they're downloading flash updates, which they shouldn't need to do as Flash is updated over policy using their offline msi from /distribution3.html.. But I know there's a few users that actually download it intentionally)

 

Anybody else had these problems, found any decent ways to block Chrome installing?

Posted

We block all executables from running except those installed to the "Program Files" and Windows folders (via AppLocker, but SRP should also work).

 

Standard users can't install anything themselves or write to the two folders above so that prevents anything running that we don't approve of. :)

 

None of our staff have local admin rights either.

Posted

Our staff had to be local admin because of SIMS, though now we're using Solus3 that shouldn't be an issue, however there's so many different programs used all over the network that I'm not exactly partial to the idea of just swapping that over.

 

I didn't realise SRP can block folders though I'm hesitant to use an explicit whitelist without a lot of research into it.. For a start, there's plenty of exes in the Windows directories xP

I presume an explicit whitelist would also stop them installing it from external devices, too?

 

I personally do think making them not localadmins is the right path to head down in the long-run, though. Just wondering if there was a quicker solution for the meantime.

Posted

You wouldn't need to have local admin rights to install Chrome anyway. It's rights to the user profile directory. So assuming the users have rights to their own profile they could still install it.

 

Obviously if as above if you block EXE files from running this would prevent it.

Posted
Alternative could be to install it universally and control it using admx - would stop users downloading and you could make sure it's not set as default.
Posted

Hi,

Yes SRP will block directories, you can set a white list of windows, program files etc. These are usually default. Then if you have an odd program installed somewhere else you can add that directory to the list as well. Then you can whitelist on publisher, so some of those apps that update frequently that run from appdata will work. I call out gotomeeting and webex here.

Then you need to add in the locations that you run scripts from like sysvol and netlogon. Apply the policy to a test account to get everything tweaked.

If you have the enterprise version configure applocker, much more flexible then srp, but similar policies apply. You will need to define exe, and script rules separately though.

Now if the user was not an admin you have stopped them from installing anything, however because they can write to program files, they can just run the installer from there. You will stop most users, but not the determined ones.

 

Another idea is to run a chrome uninstall script at login, it won’t stop them from installing it, but they might get the hint. Get yourself a copy of pdq inventory, so you know what is out there on your network.

 

Cheers,

Posted
Hi,

Yes SRP will block directories, you can set a white list of windows, program files etc. These are usually default. Then if you have an odd program installed somewhere else you can add that directory to the list as well. Then you can whitelist on publisher, so some of those apps that update frequently that run from appdata will work. I call out gotomeeting and webex here.

Then you need to add in the locations that you run scripts from like sysvol and netlogon. Apply the policy to a test account to get everything tweaked.

Looks like SRP and non-admin is the way forward, then.. Thanks! I'll get looking into it.

 

Another idea is to run a chrome uninstall script at login, it won’t stop them from installing it, but they might get the hint. Get yourself a copy of pdq inventory, so you know what is out there on your network.

Half of the issues being caused is because Chrome gets uninstalled and leaves behind reg keys etc that FUBAR other programs.

Posted
I didn't realise SRP can block folders though I'm hesitant to use an explicit whitelist without a lot of research into it. For a start, there's plenty of exes in the Windows directories

I didn't explain it very well. :)

 

The entire "Program Files" and the Windows folders including subfolders would be whitelisted so you wouldn't have to allow individually EXEs. :)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...