11

I've setup a basic group policy consisting of the default Applocker rules. Per Microsoft's technet article on the subject, any files not explicitly allowed to run by the policy are supposed to be blocked from running. After deploying this policy and verifying it was being applied to the correct user using gpresult, I was still able to download and run an exe from the internet, an exe that was saved to the user profile's temp folder. It was at that point I did more googling, and saw that the App Identity service had to be running, and it wasn't: So, like any good admin, I started it, set it to automatic, and rebooted just in case. The policy still didn't work after restarting. Below is a screenshot of the current policy.

enter image description here

I added the deny rules explicitly because the default rules weren't working. I correctly applied the policy to the machine and verified that the rules are enforced (it says so in the screenshot). I used the Test-AppLockerPolicy cmdlet to verify that the rule is should be blocking the EXEs and MSIs from running, but it doesn't. Open to most suggestions, no matter how ludicrous they may sound.

Update

Forgot to add that I checked the event log for AppLocker during this whole fiasco, and it was blank. Not a single entry the entire time.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
  • 2
    Look in the event log under `Applications and Services Logs` -> `Microsoft` -> `Windows` -> `AppLocker`. In those logs you should see allowed/denied message, and also "The AppLocker policy was applied successfully to this computer.". – longneck Oct 18 '13 at 13:46
  • 2
    Also, you can set your Group Policy that contains your AppLocker rules to also start the Application Identity service. – longneck Oct 18 '13 at 13:47
  • @longneck you are right 100%: I forgot to add that I checked that log, and it was blank! And yes, eventually if I get this policy working right I will add that service to start automatically via the same gpo for consistency. – MDMoore313 Oct 18 '13 at 13:50
  • There are separate rules for "Windows Installer Rules". I don't know if that's relevant to your EXE but it's worth a look. If you drop a copy of an installed program's EXE (winword.exe, etc.) into a folder that's not permitted in your Executable Rules, is the user able to execute it? – joeqwerty Oct 18 '13 at 14:35
  • @joeqwerty by 'Windows Installer Rules' are you referring to MSI files? That would be *horrible* if MS differentiated between 'Installed Program' EXEs and 'Windows Installer' EXEs, hopefully it's just extension based. – MDMoore313 Oct 18 '13 at 14:37
  • I'm saying I don't know how it handles that and that would be something I would test. I'm using AppLocker rules and haven't experienced the issue you're having, so it bears some additional investigation. – joeqwerty Oct 18 '13 at 14:43
  • @joeqwerty I see, yeah it's up there in the screenshot, with the same rules (Allow from Windows\Installer and deny everything else), from their documentation it only applies to MSIs. thnx for the info though. – MDMoore313 Oct 18 '13 at 14:46
  • 1
    Is the user a local Admin? Is the machine Windows 7 Pro? – joeqwerty Oct 18 '13 at 14:48
  • @joeqwerty Great questions, I *double checked* just now and the user is not an admin (that would be pretty embarrassing considering it's supposed to be a restricted account per production GPOs right now...), and it's indeed Windows 7 Enterprise. – MDMoore313 Oct 18 '13 at 14:56
  • How are you defining your deny path rule? Have you possibly forgot to add wildcard to the path *? – Fannar Levy Feb 21 '14 at 16:49
  • @FannarLevy It's in the screenshot, deny from running exe's under the user profile folder. You think I need an asterisk somewhere?At the end of the path? I'd have to go back and look at how it's defined, but what boggles me is that the test-applocker cmdlet *confirms* it's supposed to be blocked, so the path has to be correct, right? – MDMoore313 Feb 21 '14 at 16:59
  • If the rules are correctly defined and "Application Identity" service is running then AppLocker should block. – Fannar Levy Feb 21 '14 at 17:12
  • First make sure you meet requirements, ex. Windows 10 Pro is not supported: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-to-use-applocker – metablaster Jun 21 '20 at 16:27

2 Answers2

4

If your path block was not defined correctly then that would explain you situation.

For example if you were to use the %userprofile% environment variable. There are only a subset of the environment variables available through GPO/AppLocker and that's not one of them.

I have had success with the following path rule:

%osdrive%\users\*
Fannar Levy
  • 151
  • 4
  • Seconded here. I ran into the exact same issue with using the %userprofile% EV where it would not work. But switching over to the %osdrive%\users\* did the trick. – Get-HomeByFiveOClock Jul 16 '15 at 18:58
  • Switched jobs, for some reason I didn't see this answer before I left (July '14), I would have definitely tried it, it sounds like the culprit. – MDMoore313 Sep 15 '15 at 15:43
1

This is an old thread but I came across it when implementing AppLocker on our own network.

AppLocker requires the use of the Application Identity service, which is set to Manual on a default install of Win7/Server 2008 R2. You must set the Application Identity service to Automatic startup or the rules will not be enforced. You can do this with the Group Policy object where AppLocker rules are defined.

Wes Sayeed
  • 1,862
  • 6
  • 27
  • 41
  • Sup Wes! Yeah I saw that too, set it to auto with no avail, hope this thread helped you though – MDMoore313 Apr 25 '16 at 23:53
  • 1
    It did :-) It works fine w/ Win7. Win10 is another story. Can't even change the startup type of the service. Was going to post another question for that. I came across your thread while looking for help w/ AppLocker and ClickOnce applications. – Wes Sayeed Apr 25 '16 at 23:57