Introduction to AppLocker
AppLocker is an application whitelisting feature in Windows Server 2019 (Enterprise and later editions) that allows administrators to control which applications, scripts, installers, and DLLs are allowed to run based on configurable rules. Unlike software restriction policies (its predecessor), AppLocker is rule-based, auditable, and can be managed through Group Policy and PowerShell. AppLocker is a powerful defense against malware, unauthorized software, and privilege escalation attacks because it prevents attackers from running their tools even if they gain user-level code execution. This tutorial covers creating and deploying AppLocker policies on Windows Server 2019.
AppLocker Rule Collections
AppLocker organizes rules into five collections: Executable Rules (controls .exe and .com files), Windows Installer Rules (controls .msi, .msp, .mst files), Script Rules (controls .ps1, .bat, .cmd, .vbs, .js files), Packaged App Rules (controls Windows Store/UWP apps), and DLL Rules (controls .dll and .ocx files). Each collection can be independently configured in Audit Only or Enforce mode. Enable DLL rules only after thorough testing as they significantly increase the number of rules needed and can impact performance.
AppLocker Rule Types
AppLocker has three rule condition types: Publisher Rules (most flexible and resilient—based on digital signature publisher name and product version, survives file moves and updates), Path Rules (based on file or folder path—easy to configure but fragile, since moving or renaming a file bypasses the rule), and File Hash Rules (based on cryptographic hash—most specific but requires updating when files change with updates).
Opening AppLocker
Access AppLocker through the Local Security Policy (secpol.msc) for local configuration or through Group Policy Management for domain-wide deployment. Navigate to Application Control Policies > AppLocker. For domain deployment, create a GPO linked to the appropriate OU.
secpol.msc
gpmc.msc
Creating Default AppLocker Rules
Start by generating the default rules, which allow Windows system files and Program Files to run for all users, and allow Administrators to run anything. These defaults ensure Windows itself continues to function after AppLocker is enabled. In the AppLocker console, right-click Executable Rules and select Create Default Rules.
# PowerShell: Create default AppLocker rules
$policy = Get-AppLockerPolicy -Local
$defaultRules = New-Object System.Collections.Generic.List[Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.AppLockerRule]
# Generate default rules for each category
Get-AppLockerFileInformation -Directory C:Windows -Recurse -FileType Exe |
New-AppLockerPolicy -RuleType Publisher,Hash -User Everyone -Optimize |
Set-AppLockerPolicy -Merge
Creating Publisher-Based Rules
Publisher rules are the most maintainable rule type. They allow a specific publisher’s signed applications to run and survive software updates because the publisher name stays the same. Create a publisher rule for Microsoft-signed executables.
# Generate AppLocker policy from existing executables using publisher rules
Get-AppLockerFileInformation -Directory "C:Program Files" -Recurse -FileType Exe |
New-AppLockerPolicy -RuleType Publisher -User Everyone -Optimize |
Set-AppLockerPolicy -Merge
# Create a specific publisher rule for a vendor application
$fileInfo = Get-AppLockerFileInformation -Path "C:Program FilesNotepad++notepad++.exe"
$rule = New-AppLockerPolicy -FileInformation $fileInfo -RuleType Publisher -User Everyone
$rule | Set-AppLockerPolicy -Merge
Creating Path-Based Rules
Path rules allow or deny execution based on file or folder paths. Wildcards are supported. Use path rules to allow execution from approved software deployment folders. Note that path rules can be bypassed by copying files to an allowed path, so combine them with proper NTFS permissions that prevent users from writing to the allowed paths.
# Allow execution from a specific deployment folder
$newRule = [Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.FilePathRule]::new(
[System.Guid]::NewGuid(),
"Allow Software Deployment Folder",
"Allow deployment scripts",
[Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.PolicyDecision]::Allowed,
"%WINDIR%*",
"Everyone"
)
# Better approach: use the GUI or generate via Get-AppLockerFileInformation
Get-AppLockerFileInformation -Path "C:DeployedApps*" -FileType Exe |
New-AppLockerPolicy -RuleType Path -User Everyone |
Set-AppLockerPolicy -Merge
Configuring Audit Mode
Always start AppLocker deployment in audit mode before enforcing. Audit mode logs what would be blocked without actually blocking anything. This lets you identify gaps in your rules before enforcement causes application failures.
# Set AppLocker to Audit mode (not Enforce)
# In Group Policy: Application Control Policies > AppLocker > Properties
# Set each rule collection to "Audit only"
# Review audit events to find what would be blocked
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-AppLocker/EXE and DLL'
Id = @(8003, 8006) # 8003=would be allowed, 8006=would be denied
StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message | Sort-Object Id
Enforcing AppLocker Policy
After reviewing audit mode results and adding rules for all legitimate software, switch to enforcement mode. Configure this in the AppLocker Properties dialog for each rule collection, changing from “Audit only” to “Enforce rules.”
# Apply AppLocker policy via Group Policy
# Or use Set-AppLockerPolicy to apply an XML policy file
Get-AppLockerPolicy -Local -Xml | Out-File C:AppLockerPolicy.xml
# Review and modify the XML, then apply:
Set-AppLockerPolicy -XmlPolicy C:AppLockerPolicy.xml
Enabling and Starting the Application Identity Service
AppLocker enforcement requires the Application Identity service (AppIDSvc) to be running. Configure it to start automatically.
Set-Service -Name AppIDSvc -StartupType Automatic
Start-Service -Name AppIDSvc
Get-Service AppIDSvc | Select-Object Name, Status, StartType
Testing AppLocker Policy
Test whether a specific file would be allowed or denied by the current AppLocker policy using Get-AppLockerPolicy with the -Test switch or Test-AppLockerPolicy.
# Test if a specific executable is allowed
Get-AppLockerFileInformation -Path "C:ToolsPsExec.exe" |
Test-AppLockerPolicy -Path "C:ToolsPsExec.exe" -User Everyone
# Get effective policy for current user
Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path "C:Toolsmimikatz.exe"
Conclusion
AppLocker on Windows Server 2019 provides a robust, policy-driven approach to controlling what code runs in your environment. Starting with default rules and publisher-based rules for known-good software, then auditing for two to four weeks before enforcement, is the proven deployment methodology. AppLocker is particularly effective on servers where the set of legitimate applications is well-defined and stable. Combine AppLocker with Windows Defender Application Control (WDAC) for defense-in-depth—AppLocker handles user-context enforcement while WDAC operates at the kernel level.