Implement AppLocker Rules in Windows Server 2016
Posted by Jarrod on May 1, 2017 Leave a comment (1) Go to comments
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.
Before proceeding let’s discuss the types of rules that we can create with AppLocker.
With each of these rules we can whitelist based on the publisher, path, or file hash.
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.
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.
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.
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.
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.
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.