How to Implement Software Restriction Policies on Windows Server 2012 R2

Software Restriction Policies (SRP) are the predecessor to AppLocker, providing application control capabilities on all editions of Windows Server 2012 R2—including Standard edition, which does not support AppLocker enforcement. SRP uses rules based on file hash, certificate, path, or network zone to allow or deny software execution, providing a simpler but less powerful alternative to AppLocker. This guide covers configuring SRP through Group Policy in both Disallowed (whitelist) and Unrestricted (blacklist) modes, with practical examples for each rule type.

Prerequisites

  • Local Administrator or Domain Admin access
  • GPMC for domain-wide deployment
  • An inventory of software that should be permitted to run on the target servers
  • Understanding that SRP and AppLocker should not be used simultaneously on the same computer—SRP takes precedence on machines with both configured

Step 1: Access Software Restriction Policies

In a GPO, navigate to:

Computer Configuration → Windows Settings → Security Settings → Software Restriction Policies

If no SRP policies are defined, right-click Software Restriction Policies and select Create New Policies. This creates the default SRP settings object.

On a standalone server, open secpol.msc → Software Restriction Policies.

Step 2: Set the Default Security Level

The default security level determines what happens to software that doesn’t match any explicit rule:

  • Unrestricted (default) — Software can run unless explicitly blocked by a rule. This is blacklist mode.
  • Disallowed — Software is blocked unless explicitly allowed by a rule. This is whitelist mode and the recommended setting for servers.
  • Basic User — Software runs without administrator privileges even if the user is an administrator.

Right-click Security Levels → Disallowed → Set as Default. A warning will appear—click Yes.

Important: Before switching to Disallowed mode, you must create allow rules for all software that should run, or you will be locked out of the system.

Step 3: Configure Enforcement Settings

Right-click Enforcement → Properties:

  • Apply software restriction policies to: All software files (including DLLs) — Note: applying to DLLs significantly increases overhead; start with “All software files except libraries”
  • Apply software restriction policies to the following users: All users except local administrators — This prevents SRP from blocking administrative tools needed for server management

Step 4: Create Path-Based Allow Rules

Path rules match based on file or folder paths. Create allow rules for standard Windows locations:

Right-click Additional Rules → New Path Rule:

# Standard allow rules (create each as a path rule via GUI or GPO):

# Allow Windows system directory
# Path: %WINDIR%  Security Level: Unrestricted

# Allow Program Files (32-bit)
# Path: %PROGRAMFILES%  Security Level: Unrestricted

# Allow Program Files (64-bit)
# Path: %PROGRAMFILES(X86)%  Security Level: Unrestricted

# Allow specific application directory
# Path: D:ApplicationsApprovedApp  Security Level: Unrestricted

# Deny execution from user-writable locations (common attack vectors)
# Path: %APPDATA%  Security Level: Disallowed
# Path: %LOCALAPPDATA%  Security Level: Disallowed
# Path: %TEMP%  Security Level: Disallowed
# Path: %USERPROFILE%Downloads  Security Level: Disallowed

Via secedit template for bulk configuration:

[Version]
signature="$CHICAGO$"

[System Access]

[Software Restriction]
HKLMSoftwarePoliciesMicrosoftWindowsSaferCodeIdentifiersPaths{GUID}
; Path rules are stored as registry values under:
; HKLMSoftwarePoliciesMicrosoftWindowsSaferCodeIdentifiers

; View existing SRP rules via registry:
Get-ItemProperty "HKLM:SoftwarePoliciesMicrosoftWindowsSaferCodeIdentifiers" -ErrorAction SilentlyContinue

Step 5: Create Hash-Based Rules

Hash rules match a specific file by its cryptographic hash. They remain valid even if the file is renamed or moved, and are the most secure rule type for allowing specific executables:

Right-click Additional Rules → New Hash Rule:

  1. Click Browse and select the file to hash
  2. Windows calculates the SHA-256 and MD5 hashes automatically
  3. Set Security Level to Unrestricted (allow) or Disallowed (block)
  4. Add a description identifying the software version

Use PowerShell to calculate file hashes for documentation:

# Calculate hash for documentation
Get-FileHash -Path "C:Program FilesMyAppmyapp.exe" -Algorithm SHA256

# List all executables in a directory with their hashes (useful for creating hash rules)
Get-ChildItem -Path "C:Program FilesMyApp" -Recurse -Include "*.exe","*.dll" |
    ForEach-Object {
        $hash = Get-FileHash $_.FullName -Algorithm SHA256
        [PSCustomObject]@{
            File = $_.FullName
            Hash = $hash.Hash
        }
    } | Export-Csv "C:SRPAppHashes.csv" -NoTypeInformation

Step 6: Create Certificate-Based Rules

Certificate rules allow all software signed by a specific publisher certificate. This is the most scalable approach for commercial software packages:

  1. Export the publisher certificate from a signed executable
  2. Right-click Additional Rules → New Certificate Rule
  3. Browse to the exported certificate file
  4. Set Security Level to Unrestricted
# Extract publisher certificate from a signed executable
$cert = (Get-AuthenticodeSignature -FilePath "C:Program FilesMyAppmyapp.exe").SignerCertificate

# Export the certificate for use in SRP
if ($cert) {
    $certBytes = $cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
    [System.IO.File]::WriteAllBytes("C:SRPMyApp-Publisher.cer", $certBytes)
    Write-Host "Certificate exported: $($cert.Subject)"
}

Enable certificate rule processing in SRP Enforcement settings (it is disabled by default for performance reasons).

Step 7: Configure Designated File Types

SRP evaluates files against its rules based on a list of designated file types. Review and customize this list:

Right-click Designated File Types → Properties. The default list includes executable types like .EXE, .COM, .BAT, .CMD, .VBS, .JS, .WSF. Consider adding:

  • .PS1 (PowerShell scripts)
  • .MSI (Windows Installer)
  • .HTA (HTML Applications)

Step 8: Test in Audit Mode

SRP does not have a native audit mode equivalent to AppLocker’s. Instead, test by keeping the default level as Unrestricted and creating Disallowed rules for specific paths you want to block, then checking Event ID 865/866 in the Application log:

# SRP generates events in the Application log:
# Event ID 865: Access to restricted application was blocked
# Event ID 866: Access to restricted application from network zone was blocked
# Event ID 867: Access to restricted application based on hash was blocked

Get-WinEvent -LogName Application |
    Where-Object { $_.Id -eq 865 -or $_.Id -eq 866 -or $_.Id -eq 867 } |
    Select-Object TimeCreated, Id, Message | Format-List

Summary

Software Restriction Policies on Windows Server 2012 R2 Standard edition provide application control capabilities where AppLocker enforcement is not available. By setting the default security level to Disallowed, creating Unrestricted path rules for Windows directories and approved application paths, adding Disallowed rules for user-writable attack vectors like %APPDATA% and %TEMP%, and using hash or certificate rules for specific approved executables, you have implemented a whitelist-based application control policy. Migrate to AppLocker when upgrading to Enterprise or Datacenter edition for more robust rule management and better logging.