ClickOnce application suddenly blocked by AppLocker Group Policy

Posted in : Applications, Microsoft, Security, Windows, Windows Server By Hanessa Milaszewski Translate with Google ⟶

4 years ago

INTRODUCTION
With the release of the Windows 7 and corresponding server operating system, the AppLocker technology has become a quintessential tool for system administrators to utilize. Thanks to it, administrators can restrict or allow end-users to run certain applications based on its publisher value, file path or even its unique file hash, all within an On-premise Domain-wide level. In other words, it is a given implementation within an enterprise environment to further defend itself from the many and various threats that can stem from executing suspicious programs.
In this post however, I would like to share an isolated issue in which an already known application was suddenly blocked by an AppLocker Group Policy and how it being a ClickOnce executable required some creative thinking right on the spot.

SCENARIO
At one of our customers we have implemented the AppLocker technology to be based upon Publisher-exceptions alone, as each user only requires executing the same set of applications and not more in order to carry out their workload on their Windows 10 clients.
One of these applications happens to be delivered by an external vendor through a ClickOnce application on their website, meaning that the user is expected to click on a link in order to execute a program located on the vendor’s part.
INVESTIGATION
Before this had been working flawlessly, however we were now met with an error message stating that the application could not be started.

Fortunately, a more distinct explanation would display when I clicked on Details… on the aforementioned message. This in turn showed a notepad file summarizing that the application is being blocked by a group policy (translated from Swedish in the screenshot below).

With this and the customer’s scenario in mind, I quickly gathered that something with this specific application had been altered from the vendor’s part in a way that made the corresponding AppLocker Publisher-rule invalid suddenly. This would be straightforward to remedy by using AppLocker’s own ability to create rules using the application as a reference file and then determine any disparity with the publisher value. That was until I realized that I was dealing with a ClickOnce application with the file format “.application”.
SOLUTION
Knowing that AppLocker supports only a specific set of file formats when creating reference-based rules, I realized that I would have to figure out the application’s current publisher value in another way. Even more so when the vendor of this application did not have any apparent contact details at the time and that the issue was starting to become urgent for the customer, all while maintaining the AppLocker implementation.
So, what did I do? Well, I had an idea and decided to try renaming the .application-file to an .xml-file.

Opening the .xml-file would then lead me straight to the sought-after publisher value, via the “publisherIdentity name” attribute.

With this at hand, I reviewed the GPO containing the existent AppLocker-rule for this ClickOnce application. Sure enough, there was a disparity between the rule’s publisher value compared to the actual value in the .xml-file. I therefore opened the rule and edited the publisher value to correspond with the new value immediately.

Once the updated publisher rule was saved and after the users rebooted their clients, the application in question could be run as intended again.

If you have any questions or opinions regarding this matter, feel free to email me at hanessa.milaszewski@xenit.se