The Applocker Dilemma

This blog will discuss how a “NotConfigured“ AppLocker policy can come back to haunt you. I updated it after responding to a question on Reddit.

1. Introduction

Implementing AppLocker is always wise, even when it may “break” your Windows 10 installation.

In one of my last blogs, I pointed out that implementing Microsoft 365 will help you with your ISO 27001 certification journey.  When you have implemented AppLocker correctly, you’re able to cross off some of the categories:

A.9.4.4 Use of Privileged Utility Programs

A.12.2.1 Controls Against Malware

A.12.5.1 Installation of Software on Operational Systems

A.12.6.2 Restrictions on Software Installation

Implementing Applocker could take you some time. If you want to know more about how to implement AppLocker a la minute:

https://call4cloud.nl/2020/06/applocker-a-la-minute

2. The Applocker Issue

Once you have automated the process you can be 99% sure it will not fail you. Let’s look at the remaining 1%?

That 1% will apply when you are changing the existing XML CSP manually. So, what happens?

Last week I was called by a co-worker about a weird problem. When enrolling existing devices into Intune manually (devices were already Azure Ad Joined) all Windows 10 devices instantly got a black screen with a white cursor. Nothing happened when trying to open the task manager. In Safe mode, other users… nothing worked.

So, how do you start troubleshooting when nothing works? Luckily, the devices succeeded in enroling in Intune, so some required apps were automatically installed. One of them was the Solarwinds RMM agent, together with the included Remote Background tool.

Access to the RMM tool gave me access to Remote PowerShell! So, I had some background information about processes, running services, and other insights.  After some digging with of course, limited time and looking into some event logs with PowerShell, I wanted to take a look at the AppLocker event log:

Get-WinEvent “Microsoft-Windows-AppLocker/EXE and DLL”

That just says it all… All errors 8004: DLL’s are blocked! 

3. Solving the Applocker issue

So, I opened Intune to take a look at the DLL AppLocker policy.

<RuleCollection Type="Dll" EnforcementMode="NotConfigured"/>
</RuleCollection>

At first glance, it looked to me as if the DLL policy wasn’t configured. But that’s not exactly the case as it was blocking all DLL’s at that moment. The weird thing is that all existing Windows 10 Azure AD joined devices were working correctly.

After taking a look at the CSP again I realized, the CSP only told me that the “enforcementmode” was configured. There weren’t any additional rules. After talking with the customer, they told me they had removed all rules earlier and put the enforcementmode to “notconfigured” because they were experiencing performance impact and thought it had something to do with DLL AppLocker rules being configured. After they realized it hadn’t anything to do with AppLocker they forgot to change the AppLocker CSP to the old XML…

So I made a few changes to the XML and added the default rules back into it.

After some time, some coffee and manually syncing the device…..

It finally worked! All DLL’s were allowed again!

4. Why doesn’t it work?

But I still wanted to test some more, because I found it a little odd that existing devices had no problems at all.

So, after I applied the fix. I installed a new Windows 10 device to be enrolled into a test tenant. No problem at all, the problem occurs only on existing devices that are manually enrolled in Intune. Strange but okay, I can live with that when I know how to fix it.

When you read my older blog about blocking administrative tools from the Intune education portal, you will know you can enable Applocker within a few seconds from within the Intune Education Portal.

https://call4cloud.nl/2020/06/blocking-administrative-apps-like-the-command-prompt-in-intune

Shall we take a good look at how Microsoft is configuring this Applocker policy?

Are they pushing a Policy with the EnforcementMode to NotConfigured? Shall we take a look at what Microsoft has to say about the Applocker Enforcement settings?

So, let’s read it aloud: “If rules are present in the corresponding rule collection, they are enforced.” Looking back at Microsoft’s own policy, there are rules defined, so they will be enforced even while the enforcement mode is set to “NotConfigured.”

But what about when you remove all the rules and only define the enforcement mode back to “notconfigured”

When you remove the existing rules from the CSP and the EnforcementMode is set to “NotConfigured” it is still Enabled!

When you want to disable Applocker, the only thing working is removing the Applocker Exe policy itself or configuring it to AuditOnly. But then again… always make sure you have configured the rules… no matter what!

5. Don’t forget the most Important rule with Applocker

When working with Applocker, please don’t forget the most important rule! Make sure that when you are configuring a new Applocker policy, don’t forget to add the allow action rules! It’s quite simple when have configured the enforcement mode to Audit Only, the rules that are going to be Audited are the “exclusions” or “deny” rules.

When you didn’t configure the Allow actions rules, the rest will be blocked and you will only end up with everything blocked (except the stuff you configured for auditing!)

Conclusion

Don’t remove the existing rules when you want to change the AppLocker Enforcement method to Not Configured! Configuring the policy to NotConfigured, will not disable the policy! It will remain enabled on your existing devices!

When you want to remove the restrictions, it’s way better to simply remove the CSP. With Windows 1903, these settings are no longer tattooed when you remove the CSP, so they won’t stay active on your devices!

If you want to read some more blogs about Applocker, please take a look at the Applocker Categorie!