Managed installer and ISG technical reference and troubleshooting guide

Note

Some capabilities of App Control for Business are only available on specific Windows versions. Learn more about App Control feature availability.

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.

Enabling managed installer and Intelligent Security Graph (ISG) logging events

Refer to Understanding App Control Events for information on enabling optional managed installer diagnostic events.

Using fsutil to query extended attributes for managed installer (MI)

Customers using App Control for Business with managed installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the extended attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:

Example:

fsutil.exe file queryEA C:\Users\Temp\Downloads\application.exe

Extended Attributes (EA) information for file C:\Users\Temp\Downloads\application.exe:

Ea Buffer Offset: 410
Ea Name: $KERNEL.SMARTLOCKER.ORIGINCLAIM
Ea Value Length: 7e
0000: 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................
0010: b2 ff 10 66 bc a8 47 c7 00 d9 56 9d 3d d4 20 2a ...f..G...V.=. *
0020: 63 a3 80 e2 d8 33 8e 77 e9 5c 8d b0 d5 a7 a3 11 c....3.w.\......
0030: 83 00 00 00 00 00 00 00 5c 00 00 00 43 00 3a 00 ........\...C.:.
0040: 5c 00 55 00 73 00 65 00 72 00 73 00 5c 00 6a 00 \.U.s.e.r.s.\.T.
0050: 6f 00 67 00 65 00 75 00 72 00 74 00 65 00 2e 00 e.m.p..\D.o.w.n...
0060: 52 00 45 00 44 00 4d 00 4f 00 4e 00 44 00 5c 00 l.o.a.d.\a.p.p.l.
0070: 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 i.c.a.t.i.o.n..e.x.e

From the output shown above, find the first row of data labeled "0000:", which is then followed by 16 two-character sets. Every four sets form a group known as a ULONG. The two-character set at the front of the first ULONG will always be "01" as shown here:

0000: 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

If there is "00" in the fifth position of the output (the start of the second ULONG), that indicates the EA is related to managed installer:

0000: 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your App Control policy trusts managed installers.

0000: 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00

If instead the starting value for the third ULONG is "02", then that indicates a "child of child". "Child of child" is set on any files created by something that was installed by a managed installer. But, the file was created after the managed installer completed its work. So this file wouldn't be allowed to run unless there's some other rule in your policy to allow it.

In rarer cases, you may see other values in this position, but that will also run if your policy trusts managed installer.

Using fsutil to query extended attributes for Intelligent Security Graph (ISG)

When an installer runs that has good reputation according to the ISG, the files that the installer writes to disk will inherit the reputation from the installer. These files with ISG inherited trust will also have the KERNEL.SMARTLOCKER.ORIGINCLAIM EA set as described above for managed installers. You can identify that the EA was created by the ISG by looking for the value "01" in the fifth position of the output (the start of the second ULONG) from fsutil:

0000: 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00

More troubleshooting steps for managed installer and ISG

Both managed installer and the ISG depend on AppLocker to provide some functionality. Use the following steps to confirm that AppLocker is configured and running correctly.

  1. Check that AppLocker services are running. From an elevated PowerShell window, run the following commands, and confirm that STATE shows as RUNNING for both appidsvc and AppLockerFltr:

    sc.exe query appidsvc
    SERVICE_NAME: appidsvc
    TYPE               : 30  WIN32
    STATE              : 4  RUNNING
                            (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
    WIN32_EXIT_CODE    : 0  (0x0)
    SERVICE_EXIT_CODE  : 0  (0x0)
    CHECKPOINT         : 0x0
    WAIT_HINT          : 0x0
sc.exe query AppLockerFltr
    SERVICE_NAME: applockerfltr
    TYPE               : 1  KERNEL_DRIVER
    STATE              : 4  RUNNING
                            (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
    WIN32_EXIT_CODE    : 0  (0x0)
    SERVICE_EXIT_CODE  : 0  (0x0)
    CHECKPOINT         : 0x0
    WAIT_HINT          : 0x0

    If not, run appidtel start from the elevated PowerShell window and check again.

  2. For managed installer, check for AppCache.dat and other *.AppLocker files created under %windir%\System32\AppLocker. There should minimally be a ".AppLocker" file created for each of EXE, DLL, and MANAGEDINSTALLER rule collections. If you don't see these files created, proceed to the next step to confirm the AppLocker policy has been correctly applied.

  3. For managed installer troubleshooting, check that the AppLocker effective policy is correct. From an elevated PowerShell window:

    Get-AppLockerPolicy -Effective -XML > $env:USERPROFILE\Desktop\AppLocker.xml

    Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can be set to AuditOnly or Enabled, depending on whether you want AppLocker to audit or enforce the rules. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in Automatically allow apps deployed by a managed installer with App Control for Business.

Boot or service timeouts when relying on managed installer or the ISG for boot-critical binaries

When you enable managed installer tracking or the ISG, boot-critical binaries can cause boot delays or service start timeouts if your policy authorizes them only through managed-installer origin tracking or ISG reputation. Managed-installer and ISG authorization decisions aren't always available early enough in the boot path.

To mitigate this issue, authorize boot-critical binaries, services, and drivers needed early in boot with explicit allow rules in your App Control policy. Use signer rules, file attribute rules, or file hash rules instead of relying on managed installer or the ISG for these files. For more information about ISG behavior, see Use App Control for Business with Intelligent Security Graph (ISG).

  • Last updated on