This blog will be about how a “NotConfigured“ AppLocker policy can come back to haunt you.
Implementing AppLocker is always a wise thing to do even when there is a possibility it “breaks” 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
If you want to know more about how to implement AppLocker a la minute:
Once you have automated the process you can be 99% sure it will not fail you. So, what’s the remaining 1%?
That 1% will be 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. When trying to open the task manager, nothing happened. Safe mode, other users… nothing worked.
So how do you troubleshoot, when nothing works? Luckily the devices succeeded to enrol 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 PowerShell! So, I had some background information about processes, running services, and some 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 DLL’s are blocked! So, I opened Intune to take a look at the DLL AppLocker policy.
<RuleCollection Type=”Dll” EnforcementMode=”NotConfigured” />
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 it only told me that the “enforcementmode” wasn’t 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.
After some time, some coffee and rebooting the device it finally worked!
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 who are manually enrolled in Intune. Strange but okay, I can live with that when I know how to fix it.
When you want to change the AppLocker Enforcement method to notconfigured, don’t remove the existing rules! It’s also better to simply remove the CSP as with Windows 1903 the setting are not tattooed anymore when you remove the CSP so they won’t stay active on your devices!