New-AppLockerPolicy not respecting third party publishers

Prerequisites

[X] Existing Issue: Search the existing issues for this repository. If there is an issue that fits your needs do not file a new one. Subscribe, react, or comment on that issue instead.
[X] Descriptive Title: Write the title for this issue as a short synopsis. If possible, provide context. For example, "Typo in Get-Foo cmdlet" instead of "Typo."
[X] Verify Version: If there is a mismatch between documentation and the behavior on your system, ensure that the version you are using is the same as the documentation. Check this box if they match or the issue you are reporting is not version specific.

Summary

When attempting to whitelist a third party binary using a command like the following, the publisher data is not being included. Most notably, New-AppLockerPolicy -RuleType Publisher fails with New-AppLockerPolicy : The rules cannot be created. Required file information is missing from the following file , even when the data exists.

This makes the resulting policies much more fragile and prone to breaking between versions. This appears to only have an impact on third party tools.

Details

The following commands allow reproduction of the behavior. I have tested this on Server 2019, Server 2022, and Windows 11. I tried three general cases, one from another vendor entirely (BeyondTrust), one from SysInternals (MS but not a default) and the Intune Management Extension (documented well for WDAC and similar). Only Intune will show the Publisher data as a condition.

$fileName =  ".\xxxx.exe"
Get-AppLockerFileInformation $fileName | fl 
Get-AppLockerFileInformation $fileName | New-AppLockerPolicy  -User Everyone -Xml
Get-AppLockerFileInformation $fileName | New-AppLockerPolicy  -AllowWindows -User Everyone -Xml -RuleType Publisher

BeyondTrust

Sysmon

Intune

For anything except the Intune extension I get "New-AppLockerPolicy : The rules cannot be created. Required file information is missing from the following file". However the results of Get-AppLockerFileInformation $fileName consistently show this is not accurate.

Additionally, I used the exact same process (passing Get-AppLockerFileInformation via pipe to New-AppLockerPolicy) in the past successfully. A few years ago (roughly 2021 / early 2022 based on my git repo commits) I did the same thing for GoogleUpdate.exe and merged it to an applocker config file.

Suggested Fix

I believe there is something forcing only a preapproved list of certificate vendors to be supported.

So almost immediately after posting this issue, I believe I have found the underlying cause.

For the Intune publisher string returned by Get-AppLockerFileInformation the structure of the 'Publisher' line of XML is as follows.

Publisher : O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® INTUNE™\MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE,1.83.107.0

If I blow this up a bit and use the backslashes as delimiters (probably what is happening internally?) I get the following:

O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US <=== Publisher Name
\
MICROSOFT® INTUNE™  <=== Product Name
\
MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE <=== Binary Name
,
1.83.107.0 <=== BinaryVersionRange values

This corresponds well to the <Conditions> statement in the XML created as output:

<Conditions>
    <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
                            ProductName="MICROSOFT® INTUNE™"
                            BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
        <BinaryVersionRange LowSection="1.83.107.0"
                            HighSection="1.83.107.0"/>
    </FilePublisherCondition>
</Conditions>

If I do Get-Item on the bomgar file, the internal file name, fileversion, product, etc are missing..

OriginalFileName is missing for Sysmon.

As opposed to the Intune agent, which is fully filled in.

It looks like we just need to have it detailed as to exactly which of these fields are mandatory to have AppLocker handle these fields are needed to work correctly, or have a way to ignore / accept only blank fields without having to fall all the way back to using hashes for verification.

MicrosoftDocs / windows-powershell-docs