How AppLocker had me Stumped

I would like to share an experience I recently had with Microsoft AppLocker that could help others save some valuable time.

Microsoft AppLocker is an application intended to provide control over applications and files on local systems. In my case, however, it led to some severe headaches and, ultimately, an unexpected outcome; one even Microsoft did not anticipate. So, let’s dive into the topic.

At panagenda, we offer a Digital Experience Monitoring solution which requires customers to install a packaged application on Windows. This application has a simple design with minimal requirements, and is signed by a certificate issued by the Global Root CA.

Customers who use AppLocker Rules are requested to add our application to the list of trusted packaged apps if there is no existing rule that trusts all signed packaged apps.  Typically, an AppLocker Administrator adds the rule on an administrative computer. The policy is then exported and applied to Endpoint Manager (formerly Intune) to be deployed to all client devices.

The problem arose tough, when the app got blocked although the allow rule was active and available. Windows Eventlog didn’t provide much detail, other than a very generic message without any details other than that there is no rule which would allow this application. Very helpful, right?

When adding an AppLocker rule in the MMC UI, you typically select the app and make a few adjustments. We advise customers to use wildcards for the package name and version, restricting the rule at the publisher level only (see screenshot).

You might think everything is set up correctly, but it is not.

If you take a look at the Publisher String of the certificate within the app, it looks like this:

Not really special. Pretty much the same as if you would take the publisher’s information for any other application like for instance Adobe.

After creation, the rule needs to be exported as XML and then imported into Endpoint Manager for further distribution to the endpoints. And here is where things went south.

It turns out that in the exported rule, the PublisherName string was truncated after 260 characters!

Microsoft specifies that the Publisher string must match exactly when AppLocker evaluates its rules. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/understanding-the-publisher-rule-condition-in-applocker. The truncated string meant that the evaluation would always fail.

Is export the issue here, or is something else causing the problem?

In fact, it was not the export, but indeed something else. Basically, you create the rule, pick the application and then set the publisher level – you would assume that everything is fine, right? Wrong, if you reopen the rule in the MMC UI you will notice that the Publisher string is already truncated. As the export simply takes what is there, the result is an incorrect publisher string in the export as well.

Even Microsoft was surprised when we brought up this topic to them.

Pretty simple: Export the rule and update the exported XML to include the full Publisher String. Inject the modified XML into Endpoint Manager and deploy it. To verify if the Publisher Condition is configured correctly, run the following PowerShell cmdlet on the user’s PC.

You should see the correct Publisher condition on the Client PC which matches exactly the publisher’s name on the installed packaged.

Remember however that you will need to update the exported XML whenever you modify the rule or create a new export at a later stage, as Publisher will still only have the truncated Publisher String.

Trusting the UI cost hours – even for Microsoft. Next time, question everything, document the weird, and remember: “Wildcards might save the day, but understanding the details saves your sanity.” 😊