Using Applocker to protect your users from themselves, and you from your users

Windows AppLocker is useful for restricting access levels for certain users, and to give them limited control over their machine. Here’s a nice straightforward how-to on setting it up and enforcing it.

Before you do anything else, check the Application Identity Service is running before you start.

This will save you pain and heartache later on.

Suppose we already have a list of files and directories that you think users should be allowed to run stuff out of.

Assuming you’re doing this on your Gold Build – i.e. you don’t have any malicious files here – you can snapshot the publisher for any signed files, and the hashes of any files which aren’t signed. First start PowerShell, and import the appropriate module.

Then we can take a whitelist of disk locations you think are OK, and PowerShell will compute conditions that allow the files it finds – either using digital signatures or direct file hashes.

This will produce a policy file, which you can import into the GPO as a starting point.

It will however clear out any pre-existing rules – you have been warned!

So that step will have dealt with what “Everyone” can do – it’s important then to go and add rules for yourself and for Administrators so you don’t effectively lock yourself out.

To do this, I’ve use the “add default rules” option for each of Executable / Windows Installer and Scripts. Then I deleted the rules I didn’t want (Everyone can run any exe within C:\Windows or C:\Program Files) and retained the ones I did (Administrators can run anything).

Also add yourself specifically, just in case. You can take it out when everything is running smoothly.

Fallback rules, to make sure we don’t lock ourselves out:

Then we need to start actually checking, by setting the enforcement properties:

Setting enforcement to “Audit only”

Then it is possible to put the MSI/EXE/Script enforcement to “Audit only” to check that the policy is operating as desired. The Event Logs can be reviewed for potential issues, and the enforcement can be moved to “Enforce” once any problems have been ironed out.

Reviewing “audit only” failures before you move to full enforcement:

This is by far the best option if you’re trying to apply this to an existing environment. If you are building a new system from the ground up, you might go straight to Enforcement.

Suppose you are running a Citrix-based service – you wouldn’t want your users to be able to run anything signed by Microsoft, because “cmd.exe” is one such program and you specifically want that blocked for non-administrators.

However, if you have desktop users, then the condition “digitally signed by Microsoft” may be sufficient. You will also need to whitelist any other vendors – or perhaps if you know you have control of “C:\Program Files”, you can just whitelist everything within this.

Now, when you think you have everything adequately covered, you can move to full enforcement:

Here I have logged in as a limited privilege user in order to test out the policy:

Oops – we didn’t restrict PowerShell! If you let someone run PowerShell, because it was accidentally within one of the directories we said was OK, you are giving them a lot of leeway. Clearly, you can do a lot from PowerShell, so you need to think carefully about the business requirements of your users.

Now, if the user happens to click on a random exe file, like “evilexe.exe” in my example, you get a pop up as follows:

One slight caveat – it also appears that this policy blocks you from running “control.exe” (the Windows Control Panel) directly, but does not seem to stop you clicking on “Control Panel” on the Windows start menu. Therefore, you need to use AppLocker in conjunction with your other standard Group Policies.

It was still possible to start Control Panel from the Start Menu, even when the user couldn’t directly run “control.exe”:

Overall, I was pleasantly surprised by the functionality and flexibility of AppLocker, and it has a role to play in securing access where you need the user to have limited control over their machine.

Another caveat: where your policy has exact file hashes, you will need to recompute them if you update any of the files – so prefer path-based or signature-based conditions where you can.