So we’re using Windows 10. And we’ve previously implemented Applocker, which prevents security threats such as Ransomware.
Today’s challenge though? Adding a local Canon Inkjet printer.
And I’ll need Administrator Rights for that.
Though, it’s not the driver itself which needs admin rights, rather the Canon Inkjet status software:
Did a quick search over at the Microsoft Update Catalog, for my Canon Inkjet. No stand-alone driver for it.
Perhaps it’s time for a new printer?!?
On our “standard” workstations we have enabled Microsoft Applocker, which blocks unauthorised software from being installed.
We also have “Unrestricted” workstations, where there is no Microsoft Applocker, and customers can install anything they want.
All our workstations start out as “standard” workstations, and get moved to “Unrestricted” when a customer explicitly requests it.
We do occasionally encounter the issue where Applocker Rules are Still Enforced After The Service is Stopped.
Our fixes are as follows.
Option 1
Option 2
SrpV2 registry key and entries under HKEY_LOCAL_Machine\Software\Policies\Microsoft\WindowsOption 3
SrpV2 registry key and entries under HKEY_LOCAL_Machine\Software\Policies\Microsoft\Windowsgpupdate /forceNormally one of those options will work for us.
(shout out to: Google Chrome, Mozilla Firefox and Microsoft’s SharePoint Designer)
Gee thanks guys.
We implemented AppLocker to improve our IT security, and you chaps decided to be clever. The typical call to the Help Desk was
“My Google Chrome doesn’t work anymore.”
Well no, we block applications which are installed into the users profile directory. Which is what Google Chrome/Firefox/Sharepoint Designer do.
The fix was to install Google Chrome with an Admin account.
Welcome, strangers, to the show
I’m the one who should be lying low
Saw the knives out, turned my back
Heard the train coming, stayed out on the track
In the middle, in the middle, in the middle of a dream
I lost my shirt, I pawned my rings
I’ve done all the dumb things– Paul Kelly, Dumb Things
Microsoft AppLocker is a wonderful technology which allows your IT Department to prevent malicious programs from being run on your work computer. Great in theory, and my experience is that it works with some wrinkles. It broadly works by using Group Policy to configure what is a “Trusted” location.
Applocker and Active Setup
Active Setup allows you to execute commands once per user, early, during login. For example, you might want to do this to configure iTunes for each user who logs onto the computer.
Each Active Setup command has a file path to the commands that you need to run. If you don’t trust this file path in Applocker, your Active Setup fails.
If you are using System Center Configuration Manager (SCCM), then it’s likely that you’ll see this failure.
Suggestion:
If you are going to add a “Path” rule to fix this issue, you need to add two. One for EXEs and another one for MSIs.
Removing AppLocker via Group Policy
So for whatever reason, you have a class of “”special”” computers which AppLocker is not to apply to. So you remove the AppLocker Group Policy from the “”special”” computer. And it still seems to have AppLocker blocking programs.
What gives?
Well what seems to be happening is this:
The fix?
This causes AppLocker to finish removing the registry settings.
