
close
close
Upcoming FREE Conference on Identity Management and Privileged Access Management
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.
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.
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)
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.
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.
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.
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.
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.
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)
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)
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)
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.
More in Windows Client OS
March Patch Tuesday Updates Bring New Windows 11 Features and Fixes for 74 Vulnerabilities
Mar 14, 2023 | Laurent Giret
Windows 11 Version 22H2 "Moment" Update Brings AI-Powered Bing to the Taskbar
Feb 28, 2023 | Laurent Giret
Windows File Sharing with SMB: Port 445, 139, 138, and 137 Explained
Feb 20, 2023 | Michael Reinders
Microsoft Releases New Driver and Firmware Controls for Windows Update for Business
Feb 17, 2023 | Rabia Noureen
Most popular on petri