In part 2 of this tutorial I discuss a few best practices that you should take into account when you prepare the final set of your AppLocker rules.

By now, you should have a pretty long list of rules that have been generated by the GPMC. I would consider these rules as a starting point and not something you should use in production. If you’ve looked through the list, you’ll notice that there is a lot of redundancy. If you scanned the entire C:\ drive, you may also notice some things that you actually want to block with AppLocker. Here are some things I did to clean up my rules:

Use the default rules ^

If you’re going to use the default rules, you should be able to pare down some of the rules that were automatically generated. You don’t need 100+ rules for executables in the Windows or Program Files folder if you’re already allowing everything in those folders to execute.

Use publisher digital signatures ^

Most of the reputable software companies like Microsoft, Adobe, Citrix, Cisco, VMware, etc. do a relatively good job at digitally signing their executables. Several of these companies tend to have their installers end up in temporary folders inside of AppData that will be blocked if you don’t include a Publisher rule. Instead of allowing Adobe Reader, Acrobat, Illustrator, Photoshop, InDesign, etc. individually, you can use a publisher rule that allows anything digitally signed by Adobe.

AppLocker - Adobe Publisher Rule

AppLocker - Adobe Publisher Rule

Specify file paths IT controls ^

If you have file shares that are read-only to users/computers that are controlled by IT that are used for network applications or software distribution, consider creating path rules to allow those paths if the applications residing there aren’t digitally signed. This includes Sysvol! If you’re controlling scripts with AppLocker, they could be blocked from running in Group Policy if you haven’t created a rule to allow them to execute.

Keep hash rules to a minimum ^

Using hash rules can get dangerous really quick. The biggest downside to Hash rules is that you have to constantly update them. Every time an application update comes out, you’ll have to make sure you have the most current hash as well as the previous hash until you’ve patched all your machines. That could get time consuming very quickly.

Use descriptive names for rules or use descriptions ^

The default names that are created aren’t necessarily helpful at letting you know why the rule was created. If you have a Publisher rule named “Signed by O=Acme Software, Inc. , L=ATLANTA, S=GEORGIA, C=US,” you can’t really tell that the rule was created for software signed by Acme Software that is used by your Accounting department. There’s also a Description field if you need to include more detailed information like a reference back to a support ticket.

Does ‘Everyone’ need to be able to run that app? ^

I, like many other people, support several applications that don’t behave well in Program Files on Windows 7, but will run without major issues if you put them in a folder on the C:\ drive. Another pitfall of these applications for me is that they aren’t digitally signed requiring me to use a Path or Hash rule. If you have applications like this, consider giving a Group the ability to run the application instead of ‘Everyone.’ The same is true for software distribution shares and other resources used by IT; you don’t necessarily need to let ‘Everyone’ execute files from those locations.

UAC matters ^

Users with Admin rights are probably going to see deny messages. Microsoft has a TechNet article that explains the default rules that can be created for AppLocker. Unfortunately, it fails to explain that if you have UAC enabled, users with local Admin rights are going to see AppLocker deny messages. Why? The default AppLocker rule that allows all executables for Builtin\Administrators assumes that a user with Admin rights has used elevated privileges. This means that any Admin will need to right-click and choose “Run as Administrator” any time they need the allow Builtin\Administrators to run all executables rule.

The way around this is to create a Path rule that uses * as the path and a Group that you specify. You can essentially duplicate the ‘All files’ rule for BUILTIN\Administrators and just change the group. Just be aware that this is removing the AppLocker protections for this group. Do this very sparingly.

You should now have what you need to generate a list of AppLocker rules that you can start testing. In my next article, we’ll cover auditing your rules on a test computer to determine if your AppLocker rules are working the way you want them to and pushing the rules out to everyone.

Articles in series

Applocker tutorial

0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account