Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 4)

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

• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 1)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 2)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 3)

Introduction

In part one of this series, we began with an overview of AppLocker, how it differs from SRP, system requirements, and how to get started configuring it and in Part 2, we took you through the process of planning your AppLocker policies. In Part 3, we looked more deeply into how to create your AppLocker rules and policies. In this final installment of the series, we will wrap up the discussion by covering how to enable the DLL rule collection, how to create exceptions to rules, how to edit and delete rules, and how to import and export AppLocker policies between computers. 

The DLL rule collection

The other rule collections are already enabled when you set up AppLocker, and waiting for you to put rules into them. The DLL rule collection, on the other hand, has to be explicitly enabled. Why is the DLL rule collection different? DLLs (Dynamic Link Libraries) are not directly executable, but are shared libraries of code used by multiple programs that have a dependency on those files, and changes to or blocking of DLLs can create unintended consequences.

Another caveat is that using DLL rules can slow things down for users, because AppLocker will check every DLL that is loaded by an application to determine whether it is allowed. This can have a negative impact on performance. Using DLL rules can also result in numerous events being recorded in the event log.

You can see, then, why Microsoft felt it prudent to make it a little more difficult to create rules that might block the use of DLLs, since you really need to know what you’re doing or you might end up rendering needed applications unable to run. Enabling DLL rules isn’t difficult, but it does require an extra step. Note that there is no audit-only mode for DLL rules, either.

DLLs can be implemented with the .dll, .ocx or .drv extensions, but the last one is for legacy system drivers and DLL rules can only be created for .dll and .ocx files. (.OCX files are libraries that contain ActiveX controls).

Enabling the DLL rule collection

As with most of the other actions pertaining to configuration of AppLocker, you can enable the DDL rule collection in one of two ways: using Group Policy to apply to multiple computers in a GPO or using the Local Security Policy MMC to enable it for an individual computer.

In either case, in the GPMC or the LSP snap-in, here’s the procedure:

1. Navigate to Application Control Policies in the left pane, right click AppLocker, and select Properties.
2. Click the Advanced tab in the Properties dialog box.
3. Put a check in the Enable the DLL rule collection check box, as shown in Figure 1.
4. Click OK.

Figure 1

Creating DLL rules

Once you have enabled the DLL rules collection, you can create DLL rules. The DLL Rules collection will show up in the AppLocker node in Group Policy or the Local Security Policy MMC, along with the other rules collections, as shown in Figure 2.

Figure 2

Before enforcing DLL rules, ensure that you’ve created allow rules for all of the DLLs that are used by your allowed applications. There are three default rules available:

• All DLLs rule: allows members of the local admin group to run all DLLs.
• Microsoft Windows DLL rule: allows all users to run DLLs that are located in the Windows folder.
• All DLLs in Program Files Folder rule: allows all users to run DLLs that are located in the Program Files folder.

New DLL rules are created in the same way as rules in other collections: right click DLL rules in the left console tree and select Create new rule, which will open the Create DLL Rules wizard. You will select the rule action (allow or deny), user or group to which it is to apply, and rule condition type (publisher, path or hash) just as with other types of rules.

Exceptions to rules

You have undoubtedly heard the old saying that “there’s an exception to every rule.” That’s not necessarily true when it comes to AppLocker, but it’s good to know that you can create exceptions if you need to exclude a rule from applying to specific files or folders.

Exceptions are created as part of the rule creation process. Exceptions, like rules, are created via Group Policy or the Local Security Policy MMC and can be of the publisher, path or hash condition type.

Rule exceptions are not for excluding specific users in a group from having the rule applied to them. If you need to do that, the solution is to create a second rule. For example, you create a rule that allows everyone to run all programs in the Windows folder. Then you create an exception for regedit.exe. So this rule now allows everyone to run all programs in the Windows folder except for the Registry Editor. Now, if you have a user who needs to run the Registry Editor, you create a second rule that allows user (or subgroup) X to run regedit.exe.

Note that deny rules override allow rules, so you can’t accomplish what you want to do here by creating a rule that denies everyone the right to run regedit.exe and then create the allow rule for user X, because the deny rule would override. Instead, you need to do it by making an exception as described above.

Editing and deleting rules

It would be nice if you could just “set it and forget it” but the real world rarely works that way, and AppLocker is no exception to that rule. Your application ecosystem changes over time. New applications are deployed, and old ones are retired. Or situations and policies change, and you no longer need to prohibit the applications that you once did.

You can delete rules that are no longer relevant. Once again, you do it with either Group Policy or the Local Security Policy MMC. Just navigate to the rule in the appropriate rule collection, right click it and select Delete. When using Group Policy, the GPO will need to be refreshed before the change takes place. When using the LSP MMC, the change becomes effective immediately.

Importing and exporting AppLocker policies

You can export AppLocker policies from a GPO in order to make changes to the policy. You need to have Edit Setting permission for the GPO. If you are a domain admin, enterprise admin or a member of the Group Policy Creator Owners group, you already have this permission. Here’s how to do it:

1. In the GPMC, right click AppLocker in the left console tree and select Export Policy.
2. Enter a name for the exported policy in the name field of the dialog box.
3. Select the location where you want to save the exported policy.
4. Click Save.
5. Click OK.

To import a policy into a GPO, it must first have been exported as an XML file. Again, you need the Edit Setting permission to perform this task:

1. In the GPMC, open the GPO to which you want to import the AppLocker policy.
2. Right click AppLocker in the left console tree.
3. Select Import Policy.
4. In the dialog box, navigate in the file system to the location of the XML file to which you exported the policy, select it and click Open.
5. Click OK.

How to test an AppLocker policy

It’s a good idea to test your AppLocker policy before you import it into another computer. This will allow you to see whether any of the rules in your rule collections will be blocked. Do this on a computer that has the AppLocker policies applied. You run the testing tool using a PowerShell cmdlet. Here are the steps to follow:

1. First, start Powershell as an administrator.
2. Next, add the AppLocker cmdlets into Powershell using the import-module AppLocker command.
3. Then export the AppLocker policy using the Get-AppLockerPolicy Powershell cmdlet with the following syntax: Get-AppLockerPolicy –Effective –XML > <path.xml> where “path.xml” is the path to the exported XML policy file.
4. Now use the following cmdlets to select the directory, run the Test-AppLockerPolicy cmdlet and export the results of the test to a file so you can analyze them:
   Get-ChildItem <DirectoryPathtoReview> -Filter <FileExtensionFilter> -Recurse | Convert-Path | Test-AppLockerPolicy –XMLPolicy <PathToExportedPolicyFile> -User <domain\username> -Filter <TypeofRuletoFilterFor> | Export-CSV <PathToExportResultsTo.CSV>

There are several Powershell cmdlets that can be used for creating, testing and managing AppLocker policies. For more information about the cmdlets, use the Get-Help cmdlet or see the TechNet website.

Summary

AppLocker is a powerful tool for Windows administrators that vastly improves on the old Software Restriction Policies and gives you more control over the applications users can run. AppLocker policies and rules can be used to block or allow the use of various types of executable files by different computer users and groups. In this four-part series, we’ve discussed both conceptual issues and the “how to” of creating, managing and deleting AppLocker policies, rules, and exceptions.

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

• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 1)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 2)
• Managing AppLocker in Windows Server 2012 and Windows 8/8.1 (Part 3)