Automatically allow apps deployed by a managed installer with App Control for Business

App Control for Business includes an option called managed installer that helps balance security and manageability when enforcing App Control policies. This option lets you automatically allow applications installed by a designated software distribution solution, such as Microsoft Configuration Manager or Microsoft Intune.

How does a managed installer work?

Managed installer uses a special rule collection in AppLocker to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and any child processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.

You can then configure App Control to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your App Control policy. When that option is set, App Control will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, App Control will allow it to run based purely on its managed installer origin.

Understand origin claims

When managed installer or the Intelligent Security Graph (ISG) authorizes a file, App Control records why that file is trusted by adding a kernel-managed extended attribute (EA) to the file. Known as its origin claim, the EA captures the source of the file's reputation, so that Code Integrity can later evaluate the file without re-checking its original source. The origin claim is called $KERNEL.SMARTLOCKER.ORIGINCLAIM. An origin claim records what wrote the file, indicates that the process that wrote the file was trusted as either a managed installer or based on reputation, and whether the trust was inherited from a parent. You can use the fsutil command to view this EA on a file. For the exact steps, see Using fsutil to query extended attributes for managed installer (MI).

• Managed installer origin: The file was written by a process that your policy trusts as a managed installer (for example, a deployment tool like Microsoft Configuration Manager or Microsoft Intune). This trust is based on how the file arrived on the device, not on the file's properties, signatures, or hash value. For more information, see Security considerations with managed installer.
• Intelligent Security Graph (ISG) origin: The file received a favorable reputation response or it inherited the favorable reputation response from the parent process which was an installer that created the file. These reputation responses come from Microsoft's security intelligence services called the Intelligent Security Graph. Reputation is tied to the specific file, so if the file is modified, the reputation no longer applies and the origin claim is no longer honored. If that happens, the file is reevaluated by App Control the next time it runs. For more information, see Authorize reputable apps with the Intelligent Security Graph (ISG).

Origin claims propagate down a process tree. When a managed installer runs, or when an installer receives a trusted-installer reputation response from the ISG, it passes equivalent trust to the files it writes and to the child processes it starts. That trust continues to flow down the live process tree through child processes, their children, and later generations, so that all the files an installer needs to install and run an app are authorized.

Propagation isn't unlimited. It ends when the trusted process tree breaks, including in these cases:

• The original installer process ends. Trust is scoped to the lifetime of the trusted process tree. A file created after the original managed installer or ISG-trusted installer process exits doesn't inherit its origin claim. In the extended-attribute data, such a file is marked as a "child of a child" and isn't authorized to run on its own—it must be allowed by other means, such as an explicit rule, managed installer origin, or ISG reputation.
• A process crosses a security boundary. If a process is spawned under a different user or security context, the parent process can pass along its origin claim to the child process. If it doesn't, then the process tree is broken and any files created by the child process or its children aren't authorized based on the initial process's origin claim.

After the process tree breaks for any reason, any files created must be authorized by other means, including if they run as a managed installer or receive a trusted-installer reputation response from the ISG.

Security considerations with managed installer

Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules do. Managed installer is best suited where users operate as standard user, and where all software is deployed and installed by a software distribution solution such as Configuration Manager.

Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of your App Control policies when the managed installer option is allowed.

If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of your App Control policies.

Some application installers may automatically run the application at the end of the installation process. If the application runs automatically, and the installer was run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This extension could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.

Known limitations with managed installer

• App Control, based on managed installer, doesn't support applications that self-update. If an application that was deployed by a managed installer later updates itself, the updated application files won't include the origin information from the managed installer, and they might not be able to run. When you rely on managed installers, you must deploy and install all application updates by using a managed installer, or include rules to authorize the app in the App Control policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.

• Some applications or installers may extract, download, or generate binaries and immediately attempt to run them. Files run by such a process may not be allowed by the managed installer heuristic. In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. Proper review for functionality and security should be performed for the application before using this method.

• The managed installer heuristic doesn't authorize kernel drivers. The App Control policy must have rules that allow the necessary drivers to run.

Configure managed installer tracking with AppLocker and App Control

To turn on managed installer tracking, you must:

• Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs.
• Enable AppLocker's Application Identity and AppLockerFltr services.

Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs

The AppLocker policy creation UI in GPO Editor and the AppLocker PowerShell cmdlets can't be directly used to create rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.

1. Use New-AppLockerPolicy to make an EXE rule for the file you're designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.

   Get-ChildItem ${env:ProgramFiles(x86)}'\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
   

2. Manually change the rule collection Type from "Exe" to "ManagedInstaller" and set EnforcementMode to "AuditOnly"

   Change:

   <RuleCollection Type="Exe" EnforcementMode="NotConfigured">
   

   to:

   <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
   

3. Manually edit your AppLocker policy and add the EXE and DLL rule collections with at least one rule for each. To ensure your policy can be safely applied on systems that may already have an active AppLocker policy, we recommend using a benign DENY rule to block a fake binary and set the rule collection's EnforcementMode to AuditOnly. Additionally, since many installation processes rely on services, you need to enable services tracking for each of those rule collections. The following example shows a partial AppLocker policy with the EXE and DLL rule collection configured as recommended.

   <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>
   

4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Configuration Manager and Microsoft Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This condition-based inclusion ensures the policy will merge successfully on devices that may already have an AppLocker policy in place.

   <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">
       <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT&reg; INTUNE&trade; from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
         <Conditions>
             <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
               <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
             </FilePublisherCondition>
       </Conditions>
       </FilePublisherRule>
       <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" 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>
       <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" 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>
   

5. Deploy your AppLocker managed installer configuration policy. You can either import your AppLocker policy and deploy with Group Policy or use a script to deploy the policy with the Set-AppLockerPolicy cmdlet as shown in the following PowerShell command.

   Set-AppLockerPolicy -XmlPolicy <AppLocker XML FilePath> -Merge -ErrorAction SilentlyContinue
   

6. If deploying your AppLocker policy via script, use appidtel.exe to configure the AppLocker Application Identity service and AppLocker filter driver.

   appidtel.exe start [-mionly]
   

   Specify "-mionly" if you don't plan to use the Intelligent Security Graph (ISG).

Enable the managed installer option in App Control policy

In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your App Control policy. This setting can be defined by using the Set-RuleOption cmdlet with Option 13.

Below are steps to create an App Control policy that allows Windows to boot and enables the managed installer option.

1. Copy the DefaultWindows_Audit policy into your working folder from "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"

2. Reset the policy ID to ensure that it is in multiple-policy format, and give it a different GUID from the example policies. Also, give it a friendly name to help with identification.

   For example:

   Set-CIPolicyIdInfo -FilePath <XML filepath> -PolicyName "<friendly name>" -ResetPolicyID
   

3. Set Option 13 (Enabled:Managed Installer).

   Set-RuleOption -FilePath <XML filepath> -Option 13
   

4. Deploy your App Control policy. See Deploying App Control for Business policies.

Verify your managed installer setup using an audit mode App Control policy

Follow these steps to confirm your managed installer setup using an audit mode App Control policy.

1. Deploy the App Control policy in audit mode with the managed installer and ISG options enabled. Audit mode lets you observe what App Control would authorize without blocking apps.
2. Deploy your managed installer, such as Microsoft Intune or Microsoft Configuration Manager, and install the apps that you want to evaluate through that managed installer.
3. Confirm the expected authorizations by reviewing origin events centrally in Advanced hunting. Use the origin action types AppControlCodeIntegrityOriginAllowed, AppControlCodeIntegrityOriginAudited, and AppControlCodeIntegrityOriginBlocked for event IDs 3090, 3091, and 3092 as the signals that managed-installer origin or ISG reputation authorized a file.
4. For local verification, use the fsutil checks in the managed installer and ISG technical reference to review the extended attributes on files.
5. After you validate the expected behavior, you can move your App Control policy from audit to enforced mode with greater confidence that your apps will continue to run normally.

Remove the managed installer feature

To remove the managed installer feature from the device, you'll need to remove the managed installer AppLocker policy from the device by following the instructions at Delete an AppLocker rule: Clear AppLocker policies on a single system or remote systems.

Related articles

• Managed installer and ISG technical reference and troubleshooting guide