AppLocker effective policy: test the intended user's rules

What Is an AppLocker Effective Policy?

An AppLocker effective policy is the policy that applies on a particular Windows computer through Group Policy, combining its local AppLocker policy with applied domain AppLocker policies. Reviewing that policy helps answer which rules should affect a file for an intended user. A GPO named "AppLocker" describes an administrative label; it does not establish those rules, their mode or a blocked execution. Get-AppLockerPolicy reference

For an Active Directory team investigating an application-control finding, the useful result is an evidence record tied to a device, user and workload. Identify the deployment channel, preserve the effective policy, review its collections, evaluate representative files and plan a controlled execution test. Keep missing measurements visible until an administrator can collect them.

This walkthrough uses primary documentation checked on 4 October 2026 and the collector implementation described below. PowerShell commands are documentation-based examples for authorized administrators. They were not executed against an endpoint for this article; no test output or successful remediation is claimed.

How It Works: Identify the Deployment Channel and Collections

Step 1: Separate Group Policy from CSP deployment

Ask the device-management owner whether AppLocker arrives through Group Policy or the AppLocker configuration service provider (CSP). Microsoft's Get-AppLockerPolicy reference explicitly says the cmdlet only understands GP deployments and can return incorrect data when the policy was applied through CSP. An empty GP export cannot settle the CSP question.

The AppLocker CSP reference documents application launch restrictions with collection-specific policy nodes. For a CSP-managed device, preserve the owning management profile, collection payloads and device application evidence through that channel. Define how the management team will establish the device's applied state before claiming coverage. This article's GP export procedure cannot provide that evidence for CSP.

Record the following before choosing the verification path:

These fields are a proposed review record. Populate them with actual observations; a policy name or an unconfirmed assignment is insufficient to close a row.

Step 2: Record collections and enforcement modes

Microsoft defines five AppLocker rule collections: executable files, Windows Installer files, scripts, DLLs, and packaged apps and installers. A test limited to executables leaves other applicable collections unexamined. The DLL collection is not enabled by default; review its compatibility and performance implications before adding it to the pilot.

For each relevant collection, retain its rules, user or group SIDs, conditions, exceptions and configured mode. The CSP reference's XML schema includes AuditOnly, Enabled and NotConfigured values for collection enforcement. Preserve the exact value observed, alongside the console setting and deployment source; do not summarize the whole policy as "enabled" because one collection is enforced.

Microsoft's Audit only procedure distinguishes evaluating rules and logging decisions from enforcing them. An audit collection can identify files that would be denied while those files continue to run. Record an absent collection or ambiguous mode as a separate review issue rather than inferring protection from another collection.

If the estate also uses WDAC, our App Control policy identity and activation verification guide explains CiTool inventory and Code Integrity policy evidence. Our Defender ASR endpoint GUID and action verification guide checks behavior-rule configuration with Get-MpPreference. Retain each control's own evidence when they coexist.

Detection: Export, Evaluate and Correlate Execution Evidence

Step 1: Export the GP-deployed effective policy

On the assessed GP-managed computer, Microsoft's testing procedure uses an administrative Windows PowerShell session to export the policy:

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Choose an authorized evidence location and preserve the original export with host, time and deployment-channel details. Review all applicable collections before testing files. Export failure is a collection failure; an export with unexpected content requires investigation against the intended configuration. Neither outcome becomes a compliant result by omitting the device.

Use this export to evaluate the observed GP state. If a proposed policy is evaluated instead, identify it as a candidate and retain it separately. Testing a candidate XML file does not establish that a device has received that candidate.

Step 2: Test representative files for the intended user

The same Microsoft procedure provides this example, using an Office directory and a sample user:

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Replace the directory, identity and output location with approved values for the assessment. This command evaluates files against the specified policy and exports filtered decisions. Its filename does not make the CSV an execution-block log. The example's executable filter also does not test scripts, installers, DLL dependencies or packaged apps.

The Test-AppLockerPolicy reference lists Allowed, AllowedByDefault, Denied and DeniedByDefault as decision filters. Retain an unfiltered evaluation as well as any focused denied-file report. Otherwise an empty denied-only report cannot reveal which files were evaluated or confirm that intended prohibited cases were included.

Specify a representative individual account for nested-group rules, as the cmdlet reference recommends. Testing a group name or the administrator who collected the export can answer a different authorization question from the intended user's access. Repeat the evaluation for materially different user populations and retain their identities with the results.

Build a finite test set with application owners. Include approved launch, installation, update and script workflows where relevant, plus benign files intentionally outside the approved application set. For each case record the expected decision, the file or package identity, applicable collection, user and evaluation result. Missing files and evaluation errors remain explicit gaps. Do not manufacture a passing result from a narrow directory scan.

Step 3: Review the correct AppLocker logs

Microsoft's monitoring procedure places AppLocker logs under Applications and Services Logs → Microsoft → Windows → AppLocker. Review EXE and DLL for those file types and MSI and Script for installers and scripts; include Packaged app-Deployment and Packaged app-Execution when those collections are in scope.

The AppLocker event reference documents these useful distinctions:

Microsoft's script rule documentation qualifies script-block events: the script host implements enforcement. PowerShell scripts reported as blocked can still run in Constrained Language Mode; authorized scripts run in Full Language Mode. For a script test, record the host, language mode and observed operations rather than treating event 8007 alone as proof that no script code ran.

Retain full event details, including file, time, rule context and identity, with the test record. An event for one attempted file cannot establish coverage for every workload or user. Quiet logs require a check of exercised activity, collection permissions and retention before interpretation.

Remediation: Validate a Recoverable Audit-to-Enforcement Pilot

Step 1: Approve expected behavior before changing rules

Resolve three operational decisions: which evidence covers the deployment channel, which collections and modes affect the intended user, and which allowed and prohibited scenarios will be validated in the laboratory. Name the policy owner, application approvers and recovery operator. Preserve the current policy and an approved recovery procedure before distributing a change.

Use recoverable pilot equipment and benign test material. Agree which required workflows must remain available and which prohibited cases must fail after enforcement. A failure in a required administration or business workflow stops expansion until its owner reviews the rule. An unexpected allowed result for a prohibited case also needs investigation; successful business use alone does not establish the intended restriction.

Step 2: Configure Audit only and exercise the pilot

For a GPO-managed policy, use Group Policy Management Console to manage the owning GPO. Microsoft's Audit only procedure directs administrators to open AppLocker → Properties → Enforcement, select Configured for each chosen collection, choose Audit only, and confirm. Local Security Policy is the corresponding tool for local policy management.

Before exercising the pilot, verify that Application Identity (AppIDSvc) is running. Microsoft states that stopping this service prevents AppLocker enforcement. For Group Policy deployment, configure automatic startup in at least one GPO that applies AppLocker rules, under Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Retain the observed service state with the policy export. Application Identity service procedure

After application, collect the policy again and repeat the intended-user evaluations. Exercise the approved scenarios in the pilot and review audit events against expected decisions. Ask application owners to explain dependencies and proposed exceptions. Keep every exception tied to a specific requirement, approver and review decision. Do not convert every audited file into an allow rule merely to remove audit noise.

Step 3: Enforce approved collections and validate execution

Microsoft's Enforce rules procedure uses the same Properties → Enforcement tab: select Configured for the collection being changed and choose Enforce rules. Make that change through the established owner and channel after the pilot review. A CSP deployment needs its own approved management procedure.

Re-export the GP policy after application, compare collections and modes, and repeat the rule evaluation. Then perform the approved execution tests as the intended user on the pilot. Record actual behavior and corresponding events for both required and prohibited scenarios. If behavior differs from the evaluation, investigate the policy artifact, application state, user context and applicable collection before expanding.

Progress to additional populations only when named reviewers accept the evidence and recovery readiness. Preserve unknown devices and untested workloads in the change record. The completion criterion is the approved behavior observed on the assessed population, with limitations and exceptions recorded.

How EtcSec Detects This

EtcSec's etc-collector includes ANSSI_R37_APPLOCKER_NOT_ENFORCED. At commit 0423094759d50002457031317098417993e19510, Detect() in public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 lowercases each collected GPO's DisplayName and searches for applocker, wdac, code integrity or srp. One matching name is sufficient to leave Count 0; no matching name produces Count 1, with Medium severity. This count is not a count of unprotected endpoints.

The predicate reads no AppLocker XML rules, collection modes or user-specific authorization. It does not establish GPO application to a device. A suggestive name can suppress the signal without enforcement; a real policy under another name can leave the signal present. Renaming a GPO changes this heuristic without proving any security improvement.

The LDAP provider in public/internal/providers/ldap/client.go:1007 retrieves GPO metadata. Its search failure returns an error, but public/internal/audit/engine.go:521 discards the GetGPOs error while assigning the returned GPOs. Consequently, this signal alone cannot distinguish a failed GPO collection from a successful collection with no name hints. Establish collection quality independently before interpreting it.

R37 is a historical detector identifier, not the normative AppLocker recommendation number. The code associates this check with ANSSI PA-099 R11. The PA-099 guide, dated 2 October 2023, page 28 recommends system and software hardening that contributes to Tier isolation. This broad recommendation does not turn the name heuristic into an AppLocker-specific compliance test.