An Introduction to AppLocker (Part 3)

by [Published on 15 Oct. 2009 / Last Updated on 15 Oct. 2009]

The tasks that must be completed before creating rules in AppLocker; Which system services must be enabled and how to avoid accidentally locking yourself out of Windows.

If you would like to read the other parts in this article series please go to:


This article continues the discussion on the tasks that must be completed before creating rules in AppLocker. In this article, you will learn which system services must be enabled, and I will show you how to avoid accidentally locking yourself out of Windows.

In my previous article of this series, I explained that AppLocker works on the principle that it is easier to define the applications that you want to allow Windows to run, than it is to try to block every potential unauthorized application. In this article, I want to continue the discussion by showing you how to prepare for the creation of AppLocker rules.

Opening the AppLocker Console

You can access AppLocker through the Group Policy Object Editor. It is located at: Computer Configuration | Windows Settings | Security Settings | Application Control Policies | AppLocker. You can also get to AppLocker by selecting the Local Security Policy shortcut from the Administrative Tools menu. When viewing the Local Security Policy, AppLocker is located at: Security Settings | Application Control Policies | AppLocker.  You can see what the AppLocker container looks like in Figure A.

Figure A: This is what the AppLocker console looks like

The Getting Started Section

As you can see in the figure, the console is divided into three sections. The Getting Started section gives you a warning message which indicates that once you begin creating AppLocker rules, only the applications that are defined by those rules will be allowed to run. There are also a couple of links that you can use to learn more about AppLocker or to determine which editions of Windows AppLocker rules apply to.

The Configure Rule Enforcement Section

The Configure Rule Enforcement section displays a warning message indicating that in order for AppLocker rules to be enforced, the Application Identity Service must be running. If you look at Figure B, you can see that the Application Identity Service is not configured for automatic startup by default.

Figure B: The Application Identity Service is not automatically enabled by default

If you are just experimenting with AppLocker on a single PC, then it is usually best to use the Service Control Manager to set the Application Identity service’s Startup type to Automatic, and then start the service. If you are planning on using AppLocker with all of your Windows 7 desktops, then it is better to enable the Application Identity service at the group policy level. System services are located at Computer Configuration | Windows Settings | Security Settings | System Services within the group policy tree.

If you look back at Figure A, you will notice that the Configure Rule Enforcement section of the AppLocker console contains a Configure Rule Enforcement link. Clicking this link takes you to the AppLocker properties sheet, shown in Figure C.

Figure C: You must decide which rules to enforce

As you can see in the figure above, AppLocker rules are not configured by default. Do not let that fool you though. According to the Windows 7 documentation, “If enforcement is not configured but rules are present in the corresponding rule collection, those rules are enforced”.

Keep in mind that once you start creating rules, any applications that are not explicitly defined by those rules are no longer allowed to run. According to the text from the Windows 7 documentation, simply creating a rule causes the rule to be enforced, even if you have not selected the Configured check box for the rule collection.

To avoid accidentally locking yourself out of Windows, I recommend going ahead and select the Configured check box for all three rule collections. After doing so, you should set the drop down list to Audit Only for each of the rule collections.

When a rule collection is set to Audit Only mode, the rules within that rule collection are not enforced. Instead, any time that a user runs an application that would have been affected by a rule in the collection, information about the rule and the application are written to the AppLocker event log.

There are two main reasons why I recommend that you set each rule collection to Audit Only before you even begin creating any rules. Firstly, doing so is a safety measure. As long as AppLocker is working in Audit mode, you do not have to worry about locking yourself out of the system. Secondly, auditing your rules allows you to test to see how well the rules are working. When you examine the audit logs, you may find that you need to revise your rules because an application that should be prohibited is being allowed to run. On the other hand, you might discover that your rules are too restrictive and that they are impacting critical applications. Auditing allows you to find out exactly how your rules are going to behave, but without the potential for adverse side effects.

Advanced AppLocker Properties

If you look back at Figure C, you will notice that the AppLocker Properties sheet contains an Advanced tab. If you select this tab, you will be given the option of enabling the DLL rule collection, as shown in Figure D.

Figure D: The Advanced tab gives you the option of enabling the DLL rules collection

As you look at the image above, the first thing that you will probably notice is the big, bold text warning you that DLL rules can affect system performance. Let me just say that there is a reason why Microsoft does not list DLL rules amoung the other rule collections on the properties sheet’s Enforcement tab.

If you choose to enable the DLL rule collection, then you must approve every single DLL that is used by authorized applications on your system. This tends to be a really big job, and it is easy to accidentally miss a DLL. If you forget to approve a DLL file, then applications that depend on that DLL will not run correctly.

Of course the warning text in the dialog box tells you that enabling DLL files can affect system performance. The reason why this is the case is because most applications use at least a few DLLs. This means that when a user loads the application, checking to make sure that the application is approved for use is no longer enough. Windows must also check each DLL file, and that takes some time to do.

Depending on how the application is designed, it may need to periodically load DLLs. This action can lead to increased system response time as the user works within the application.

Keep in mind that DLL rules do have their place. If security is of a paramount concern to your organization, then enabling DLL rules might be a good idea. For everyone else though, I would recommend that you avoid enabling the DLL rule collection.


In this article, I have explained that if you are going to use AppLocker, then it is a good idea to set all of the rule collections to audit mode before you create your first rule. That way, you can determine the impact of the rules without having to deal with any side effects that might have resulted. In Part 4 of this series, I will begin showing you how to actually create the necessary AppLocker rules.

If you would like to read the other parts in this article series please go to:

See Also

The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.


Featured Links