5 min read
Azure LocalAzure HybridWDACSecurityApplication ControlMEMCM
Created on

Azure Local - WDAC - Part 7 - Managed Installer for software deployed via MEMCM

Intro

This article is part of a series: Navigate to series page

In the earlier parts of this series we created supplemental policies by scanning installed software and generating publisher or hash rules. That approach works well for a small number of known tools. When the number of applications grows — or when software is rolled out through Configuration Manager (MEMCM) — maintaining individual supplemental policies becomes a significant operational burden.

Managed Installer is a WDAC capability that addresses this. When a designated software distribution tool (a “managed installer”) installs software, Windows tags the installed files as originating from a trusted source. WDAC can then be configured to trust those tagged files without a dedicated supplemental policy for each application, as long as no WDAC deny rule matches.

How Managed Installer works

Managed installer uses AppLocker’s ManagedInstaller rule collection (not the standard EXE/DLL rules). When a process matching a managed installer rule runs, Windows monitors files written by that process and its child processes and adds an origin claim to qualifying files. This trust follows the live process tree; it doesn’t continue after the installer process exits or across every security-context boundary. WDAC checks the origin claim when deciding whether to allow execution.

Key limitations to understand before enabling this:

  • Self-updating apps: If an app updates itself (not through the managed installer), the updated files will not have the trusted tag and may be blocked.
  • No kernel driver support: The managed installer tag does not cover kernel drivers. Drivers still need explicit rules in your WDAC policy.
  • Privilege and bypass risk: Administrators could potentially abuse this mechanism. If the managed-installer process runs as a standard user, standard users or malware running as that user might also circumvent the policy’s intent. Managed Installer is best suited to environments where software deployment is tightly controlled and users don’t have local admin rights.
  • Installers that launch the app: If an installer starts the installed app before its process tree exits, files written during that first run can also inherit managed-installer trust. Review deployment behavior before trusting an installer this way.

Prerequisites

  • An Azure Local cluster with WDAC enabled.
  • Configuration Manager (MEMCM) as the software distribution platform for Azure Local nodes.
  • An elevated PowerShell session on the Azure Local nodes.

Step 1 — Create the AppLocker Managed Installer policy XML

AppLocker’s standard GUI and PowerShell cmdlets cannot directly create rules in the ManagedInstaller rule collection. You must generate a standard Exe rule first, then manually edit the XML.

The example below designates Configuration Manager’s ccmexec.exe and ccmsetup.exe as managed installers.

Save the following as C:\wdac\ManagedInstaller.xml:

<AppLockerPolicy Version="1">
  <RuleCollection Type="Dll" EnforcementMode="AuditOnly">
    <FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5"
                  Name="Benign DENY Rule" Description=""
                  UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
      </Conditions>
    </FilePathRule>
    <RuleCollectionExtensions>
      <ThresholdExtensions>
        <Services EnforcementMode="Enabled" />
      </ThresholdExtensions>
      <RedstoneExtensions>
        <SystemApps Allow="Enabled"/>
      </RedstoneExtensions>
    </RuleCollectionExtensions>
  </RuleCollection>
  <RuleCollection Type="Exe" EnforcementMode="AuditOnly">
    <FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e"
                  Name="Benign DENY Rule" Description=""
                  UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
      </Conditions>
    </FilePathRule>
    <RuleCollectionExtensions>
      <ThresholdExtensions>
        <Services EnforcementMode="Enabled" />
      </ThresholdExtensions>
      <RedstoneExtensions>
        <SystemApps Allow="Enabled"/>
      </RedstoneExtensions>
    </RuleCollectionExtensions>
  </RuleCollection>
  <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
    <!-- MEMCM CCMExec -->
    <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87"
                       Name="CMM - CCMEXEC.EXE, 5.0.0.0+"
                       Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
                                ProductName="*" BinaryName="CCMEXEC.EXE">
          <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <!-- MEMCM CCMSetup -->
    <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e"
                       Name="CCM - CCMSETUP.EXE, 5.0.0.0+"
                       Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
                                ProductName="*" BinaryName="CCMSETUP.EXE">
          <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
</AppLockerPolicy>

Note: Only include managed installers that are present and supported on the target operating system.

Configuration Manager setup: When using a custom managed-installer policy, Configuration Manager requires additional setup. Either deploy one of its inbox App Control policies or configure the client by including the /ManagedInstaller switch when running ccmsetup.exe. See Configuration Manager client installation properties.

Step 2 — Deploy the AppLocker policy

Apply the AppLocker managed installer policy on each Azure Local node:

Set-AppLockerPolicy -XmlPolicy "C:\wdac\ManagedInstaller.xml" -Merge -ErrorAction SilentlyContinue

Then start the AppLocker Application Identity service and filter driver:

# Start AppLocker services required for managed installer tracking
appidtel.exe start -mionly

The -mionly flag is correct if you are not using the Intelligent Security Graph (ISG). If you use ISG, omit it.

Verify the AppLocker policy was applied:

Get-AppLockerPolicy -Effective -Xml | Select-String "ManagedInstaller"

Note: Managed installer tracking begins the next time a matching process starts. If the Configuration Manager client is already running, restart the relevant service for tracking to activate.

Step 3 — Enable the Managed Installer option in your WDAC policy

Add Option 13 (Enabled:Managed Installer) to the App Control policy that will authorize managed-installer-origin files:

$policyPath = "C:\wdac\BasePolicy.xml"

# Enable managed installer trust
Set-RuleOption -FilePath $policyPath -Option 13

Set-RuleOption only changes the XML; it does not deploy the policy. Don’t copy a generic BasePolicy.cip directly into the active policy folder: multiple-policy-format policies must be named after their PolicyID, and Azure Local policy changes should follow the supported cluster deployment process. Azure Local documents Add-ASWDACSupplementalPolicy for deploying a correctly formed supplemental policy; it isn’t a replacement for enabling Option 13 in the policy that needs the option. See Manage Application Control for Azure Local.

For a locally managed multiple-policy-format policy, follow Microsoft’s policy deployment instructions, including the required {PolicyID}.cip filename and activation method. Test the change in audit mode before enforcing it.

Step 4 — Verify managed installer tagging

Deploy a test application through Configuration Manager after enabling the AppLocker policy and the WDAC option. Then check whether the installed file received the managed installer origin tag:

# Query the Code Integrity origin-claim extended attribute on a deployed binary
$file = "C:\Program Files\YourApp\app.exe"
fsutil.exe file queryEA $file

Look for the $KERNEL.SMARTLOCKER.ORIGINCLAIM extended attribute in the output. The attribute’s value distinguishes managed-installer origin from other origin claims; use Microsoft’s verification guide to interpret it. AppLocker event logs can help troubleshoot policy processing, but filtering their message text for ManagedInstaller isn’t a reliable way to verify a file’s origin claim.

Handling self-updating applications

If an application managed by Configuration Manager later updates itself outside of the managed-installer process tree, the newly written files won’t inherit the managed-installer origin claim and may be blocked in enforced mode.

The recommended mitigations are:

  1. Disable auto-update in the application and always deploy updates through the managed installer.
  2. Create a supplemental publisher policy for applications with unavoidable self-update behavior (as described in Part 2).

Recommendation

Managed Installer is most effective in environments where:

  • A large number of applications are deployed through Configuration Manager on Azure Local nodes.
  • Standard users do not have local admin rights on the Azure Local nodes.
  • You want to reduce the number of manually maintained supplemental policies.

For Azure Local management hosts and operational tooling that falls outside the managed installer scope, continue to use supplemental policies as described in the earlier parts of this series.

Official Microsoft reference: Automatically allow apps deployed by a managed installer