Home 

Implement AppLocker Rules in Windows Server 2016

We can implement AppLocker rules using group policy in a Windows domain to limit the execution of arbitrary executable files. AppLocker takes the approach of denying all executables from running unless they have specifically been whitelisted and allowed.

AppLocker is available in Windows Server 2008 R2 and newer, and Windows 7 Enterprise edition or newer on the client side. Note that it’s only available for particular editions, for example in Windows 10 you need Enterprise edition to make use of AppLocker. The AppLocker requirements can be found here.

Note that before you implement AppLocker rules in a production environment it is important to perform thorough testing. AppLocker will not allow anything to run unless it has been explicitly whitelisted, which could cause problems in your environment if users are not able to run required software to do their job.

This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more related posts and information check out our full 70-744 study guide.

Rule Types

Before proceeding let’s discuss the types of rules that we can create with AppLocker.

• Executable Rules: These rules apply to executables, such as .exe and .com files.

• Windows Installer Rules: These rules apply to files used for installing programs such as .msi, .mst and .msp files.

• Script Rules: These rules apply to scripts such as .bat, .js, .vbs, .cmd, and .ps1 files.

• Packaged App Rules: These rules apply to the Windows applications that may be downloaded through the Windows store with the .appx extension.

With each of these rules we can whitelist based on the publisher, path, or file hash.

• Publisher: This method of whitelisting items is used when creating default rules as we’ll soon see, it works based on checking the publisher of the executable and allowing this. If the publisher, file name or version etc change then the executable will no longer be allowed to run.

• Path: Executables can be whitelisted by providing a folder path, for example we can say that anything within C:\executables is allowed to be run by a specific active directory user group.

• File Hash: While this may be the most secure option, it is inconvenient to work with and manage. If a file changes at all, for instance if an executable is updated, it will not be allowed to run as the allowed hash will have changed too.

Now we’ll actually implement AppLocker rules using group policy.

Implement AppLocker Rules

We’ll start by opening Server Manager, selecting Tools, followed by Group Policy Management.

From the Group Policy Management window that opens, we’ll select the group policy objects folder within the domain, right click and select new to create a new group policy object (GPO). In this case we’ll create one called AppLocker.

Once the base GPO has been created, right click it and select Edit. This will open the Group Policy Management Editor (GPME). From within GPME, select Computer Configuration > Policies > Windows Settings > Security Settings > AppLocker Control Policies > AppLocker.

From here we can view the main AppLocker interface where we can create executable, windows installer, script, and packaged app rules. We can get started with the default settings by clicking the “Configure rule enforcement” link on this screen which opens up the following window.

By default each of these four items is unticked and not enabled, we can tick the box next to “Configured” to enable it. This will set the rule to “Enforce rules” by default, however we can optionally click the drop down to change it to “Audit only” which will allow executable files to run and only log the action. In this case we’ll enable all items, leave them on enforcing, and click OK to save the settings.

Now that the rules are enforcing, we need to set the actual rules themselves. We’ll first create default AppLocker rules, followed by automatic AppLocker rules, and end with a custom AppLocker rule.

Default AppLocker Rules

We’ll first create the default rules, these are a baseline set of rules that still allow the operating system and built in applications to function normally. Right click the “Executable Rules” and select “Create Default Rules” as shown below.

We can see the default rules that have been created below.

These default rules allow all users to to execute files within the Program Files and Windows folders. Additionally, local administrators are able to execute anything anywhere, so it’s still important that administrator accounts only be used for administrative tasks, while standard user accounts are used everywhere else. If any of these actions are not desirable for you, simply delete or modify the rule.

We can also right click “Windows Installer”, “Script Rules”, and “Packaged App Rules” and create default rules there as well. With these default rules in place, if a non administrative user attempts to execute anything that is not within the directories specified above, they will receive an error.

Automatically Generate AppLocker Rules

While these default rules are a good starting point, ideally we should further customize the rules as per your organizational requirements. We can right click these items, and again we’ll select “Executable Rules”. Rather than “Create Default Rules” as shown previously select “Automatically Generate Rules”.

Note that this will generate custom rules based on the computer that you’re generating them on, in this case our domain controller where GPME is open. Ideally you would want to create AppLocker rules on a SOE image so that common elements that are deployed to all machines can have rules created for them.

From the Folder and Permissions window, we’ll just leave the defaults shown below and click next to proceed.

Next on the rule preferences screen we’ll leave the default and create publisher rules for files that are digitally signed. While using hashes is considered quite secure, it is also pretty inconvenient as new hashes would be required every time a file is updated or modified.

Do that also by c : \ programfiles (x86)

Finally on the review rules window, we can check the rules that will be created. Click the create button to proceed.

We’ll see an AppLocker warning advising that we should first create the default rules, select yes if you have not already created them as shown previously.

We can now see that our rules have been created.

Once the executable rules have been created for Executable Rules, we can do the same for Windows Installer Rules, Script Rules, and Packaged App Rules.

Custom AppLocker Rules

We can also create complete custom rules by right clicking any of the 4 rule items and selecting “Create Rule”.

On the before you begin page, click next.

On the permissions page, select if you want to allow or deny access and to the user or group in which it should apply.

On the conditions page, select if we want to allow or deny based on publisher, path, or file hash as discussed previously.

In this example I’ve selected path, so after clicking the browse folders button I can browse to the folder that I want to allow.

We can optionally add exclusions here, for instance we may want to allow a user to execute everything on their desktop except for a specified file.

Finally we can give our custom rule a name and description, by default the name will be automatically populated.

We can now see a summary of our custom rule below the default rules that we created earlier, confirming that it’s now active.

In order for AppLocker rules to work correctly, the client must be running the AppIDSvc service. Even if we implement AppLocker rules with group policy if the service is not actually running they will not be enforced.

Summary

We have used group policy to implement AppLocker rules within our Windows environment, preventing untrusted executable files from running which will help defend against a lot of security threats in Windows.