Windows Client OS

Setting Application Control Policies with Microsoft's AppLocker

tiny-people-working-on-computer-hero-img

In today’s Ask the Admin, I’ll show you how best to set up application control policies in Windows using AppLocker.

AppLocker was introduced in Windows 7 and can be used to prevent users from running executables, scripts, Windows Installer packages, and Windows Store apps (Windows 8 and higher) in Windows 7, Windows Server 2008 R2 and later. AppLocker is only available in Enterprise and Ultimate editions of Windows.

Why is application control important?

Removing administrative privileges from users goes a long way in protecting devices from unwanted configuration change and malware, but alone doesn’t provide protection against scripts and portable software that might install itself into the user’s profile. That’s where AppLocker comes in, by preventing users from running installer packages or scripts that haven’t been identified as trusted by IT.

Sponsored Content

Maximize Value from Microsoft Defender

In this ebook, you’ll learn why Red Canary’s platform and expertise bring you the highest possible value from your Microsoft Defender for Endpoint investment, deployment, or migration.

Configure AppLocker

AppLocker is much easier to set up than Software Restriction Policies (SRP), which is the Windows XP technology that AppLocker replaces. In this article, I’ll show you how to set up AppLocker in Local Computer policy in Windows Server 2012 R2, but you could easily apply the same settings to multiple computers using Active Directory Group Policy.

Configure an MMC console (Image Credit: Russell Smith)
Configure an MMC console (Image Credit: Russell Smith)

Let’s start by configuring a management console. Alternatively, you can configure a Group Policy Object for your domain following the instructions in “How to Create and Link a Group Policy Object in Active Directory” on Petri.

  • Log in to Windows Server 2012 R2.
  • Click the Start button and on the Start screen type mmc.
  • In the search results pane on the right, right click the MMC icon and select Run as administrator from the menu. Enter administrative credentials if prompted.
  • In the MMC console window, press CTRL+M to add a new snap-in.
  • In the Add or Remove Snap-ins dialog, select Group Policy in the list of available snap-ins, and click Add.
  • In the Select Group Policy Object window, keep the default setting of Local Computer and click Finish.
  • In the Add or Remove Snap-ins dialog, select Services in the list of available snap-ins, and click Add.
  • In the Services dialog, keep the default setting of Local Computer and click Finish.
  • In the Add or Remove Snap-ins dialog, click OK.

Create default rules

To ensure that AppLocker policies don’t completely disable Windows, there’s a set of default rules that enable trusted applications, scripts and installer packages to run. Trust is defined as an executable or script located in a protected system location, such as the %windir% directory, or signed by a certificate.

  • In the left of the MMC console, expand Local Computer Policy, Windows Settings, Security Settings, Application Control Policies, AppLocker.
  • Right click Executable Rules and select Create Default Rules from the menu. You’ll see the rules appear to the right. Note that members of the built-in Administrators group are allowed to run all files.
  • Repeat the previous step for Windows Installer Rules, Script Rules, and Packaged app Rules.
The default AppLocker rules (Image Credit: Russell Smith)
The default AppLocker rules (Image Credit: Russell Smith)

The default rules block many scripts, executables and Windows Installer packages, but the default Windows Installer rule extends trust to a wide range of publishers. For example, I don’t want users to install Google Chrome, which doesn’t require administrative rights to install and can be downloaded as an .msi package. The Chrome .exe installer package will be blocked by the default executable rules because it cannot be added by a standard user to the trusted locations defined in AppLocker policy.

The exception to the rule — blocking Google Chrome

It’s best practice to avoid using AppLocker to deny rules because deny always take precedence and can be circumvented by modifying the files the rule is designed to block. To block the Google Chrome .msi installer I’m going to add an exception to the default Windows Installer rule that allows all digitally signed .msi files to run.

To perform the following steps, you’ll need to download the Chrome .msi file from Google’s Chrome for Work website.

  • Click Windows Installer Rules in the left of the MMC window.
  • In the central pane, right click the Publisher rule that allows All digitally signed Windows Installer files, and select Properties from the menu.
  • In the Allow Properties dialog, click the Exceptions tab.
  • Make sure that Publisher is selected under Add exception and then click Add.
  • In the Publisher Exception dialog, click Browse to select a reference file.
Add an exception to a default AppLocker rule (Image Credit: Russell Smith)
Add an exception to a default AppLocker rule (Image Credit: Russell Smith)

The reference file will be the Google Chrome .msi file downloaded earlier, which contains information about the certificate Google uses to sign the Windows Installer file.

  • In the Open dialog, locate the .msi file and click Open.
  • In the Publisher Exception dialog, move the slider upwards to Product Name. This ensures the exception only blocks installers signed by Google named Google Chrome.
  • Click OK in the Publisher Exception dialog.
  • In the Allow Properties dialog, click OK.

Enable rule enforcement

AppLocker can run in enforcement or audit only mode. Audit mode is useful for observing how your rules will work in your environment. In audit only mode, AppLocker writes to the Event Log when a user launches a script or application that matches a rule.

Configure AppLocker in enforcement mode (Image Credit: Russell Smith)
Configure AppLocker in enforcement mode (Image Credit: Russell Smith)
  • Right click AppLocker in the left of the MMC window and select Properties from the menu.
  • On the Enforcement tab of the AppLocker Properties dialog, check Configured for each of the rule types and make sure Enforced is selected in the menus.
  • When you’re done, click OK.

Start the Application Identity service

The final piece of the puzzle is to make sure that the Application Identity service automatically starts when Windows boots.

Set the Application Identity service to start up automatically (Image Credit: Russell Smith)
Set the Application Identity service to start up automatically (Image Credit: Russell Smith)
  • In the MMC console window, click Services in the left pane.
  • Locate Application Identity in the list of services and double click it.
  • On the General tab of the Properties dialog, set the service startup type to Automatic in the dropdown menu.
  • Click Start under Service status, and then click OK.

Testing AppLocker

To test AppLocker, you should log on to the server as a standard user because the default rules allow administrators to run all applications.

Windows AppLocker blocking a Windows Installer file (Image Credit: Russell Smith)
Windows AppLocker blocking a Windows Installer file (Image Credit: Russell Smith)

Any applications or scripts defined by the AppLocker rules as untrusted should fail to start, including the Google Chrome .msi file we downloaded previously. An error message will be displayed stating that system policy prevents installation.

 

 

 

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (2)

2 responses to “Setting Application Control Policies with Microsoft’s AppLocker”

  1. <p>Application whitelisting is a very important part of client security. Utilizing a whitelist in AppLocker can be cumbersome and create delays that impact organizations, that said I still use threatlocker for application whitelisting and prevent unwanted code running. </p>

    • <blockquote><a href="#16071"><em>In reply to kenlang:</em></a><em> Just had a look at Threadlocker, looks interesting that been said, the more 3rd party products you put on your system the greater the attack vector, I do like </em><em style="background-color: rgb(255, 255, 255);">Threadlocker</em><em> ability to let you know who running what easily..<span class="ql-cursor"></span><span class="ql-cursor"></span></em></blockquote><p><br></p>

Leave a Reply

IT consultant, Contributing Editor @PetriFeed, and trainer @Pluralsight. All about Microsoft, Office 365, Azure, and Windows Server.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

 
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: