- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
Go back into your GPO and go to Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Right-click on AppLocker and choose Properties. Check the box next to Configured for each area of AppLocker that you’ll be testing and change the pull-down to Audit only. This will log all of the rule results to the Event Log without actually blocking any applications.
AppLocker - Properties Audit
I like to keep my AppLocker rules in a dedicated GPO. If you’re setting up AppLocker the same way, you can now link your GPO to an OU for testing. At this point, I haven’t configured what to do with the Application Identity Service (AppIDSvc). When I tested initially, I applied the GPO to a few volunteers’ computers (with the rules in Audit mode) and manually started AppIDSvc remotely and left the Startup type as Manual. I asked the users to let me know if they rebooted their computers so I could also restart AppIDSvc. With the rules in Audit mode, nothing should be blocked. But why take anything to chance? Should a user have problems with AppLocker, simply rebooting will disable AppLocker.
Now, you wait. After a few days, you can check the Event Log to see what’s getting blocked. Microsoft has a dedicated area of the Event Log just for AppLocker that makes things easy. In the Event Viewer, go to Applications and Services Logs > Microsoft > Windows > AppLocker and you should see “EXE and DLL” and “MSI and Script.” You should be able to skim through these events and see Warnings where things would be blocked by AppLocker if the rules were not in Audit. On my test system, you’ll see that the user ATL\testuser ran Google Chrome that is installed in the user’s profile in AppData. Since I’m looking to block applications from users’ profiles, this is the expected behavior I’m looking for.
AppLocker - AppLocker Event Log blocked app
After you’ve gotten comfortable with your rules, you can move on to enforcing them. First off, I still haven’t set the Application Identity Service (AppIDSvc) settings anywhere in Group Policy. The AppIDSvc service is disabled by default. By starting the service manually on the client computer, the end user has the fallback position of rebooting to disable AppLocker should the rules break something. Go back into the GPO and go to Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies, right-click on AppLocker, and choose Properties. Make sure Configured is still checked and change the pull-down to Enforce Rules. Since we’re testing the policy, you can run a quick gpupdate on the client to refresh the Group Policy.
AppLocker - AppLocker Enforce Rules
Once you’ve made sure that AppIDSvc is running and still set to Manual, you’re back to waiting. The good news is that now your customer is going to see the block messages in addition to the entry you’ll see in the Event Log. The end user will be told that, “This program is blocked by group policy. For more information, contact your system administrator.”
AppLocker - End user message for blocked app
Back in the Event Viewer, you’ll see that the Warnings are now Errors that AppLocker is enforcing rules.
AppLocker - Event Viewer application blocked
You should now be at the point where you have a pretty good idea of what works and what doesn’t work for your AppLocker rules. In the next, and final, part of this series, I’ll discuss the best way to enable the Application Identity Service for your computers and some of the common issues I’ve seen during an AppLocker implementation.