The curious case of Defender ASR rules not enforcing from Intune

 
It was a cold gloomy day when I set out on a mission to fix an issue involving ASR rules. Something which I may have done a dozen of times so I said to myself, why it should be any different this time. But if history has taught me anything, it is that no two issues are the same, despite how much they resemble and that for every issue there is a possible solution. You just have to stay relentless and you will eventually make it to the other side.

The issue..

It all began with the ASR rules in 'block mode' starting to block macros on a set of devices. Pretty routine at this stage as the logical thing to do is either to configure necessary exclusions or put the relevant ASR rule in a non restrictive state like 'Audit' mode. The problem is that no matter what changes I made to the ASR rules, they simply didn't make any difference. Macros continued to be blocked and the events in Advanced hunting would confirm the same.



When I checked the registry on the devices in question, the value did show as changing to 2 for the ASR rule 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b (Block Win32 API calls from Office macros) which means 'Audit' matching the policy I created.


To make matters interesting, whenever I made any changes and tested on a pool of test devices, the changes would reflect. This was a weird behavior, but this eventually set me on the right path. When I checked for the OU of the test devices, they were in a different OU to those experiencing issues. This made me think could it be GPO that is causing all this? You see, Intune policies sit in the registry location HKLM:\Software\Policies\Microsoft\Windows Defender\Policy Manager.

I ran CMPivot (Just because I configured the devices as Co-managed :-) ) to query the registry.



Whereas, GPO policies for Defender sit in a different location which is HKLM:\Software\Policies\Microsoft\Windows Defender

I checked for HKLM:\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR and found the first evidence of ASR settings being applied through GPO. In the screenshot below, one can see that both ExploitGuard_ASR_Rules and ExploitGuard_ASR_ASROnlyExclusions are enabled.



Things started to unravel pretty quickly. One may argue that this can be addressed using MDMWinsOverGPO, but it will be wrong to think like that as the CSP only supports the Policy CSP. Also, it does not support Defender CSP or even Update Policy CSP for that matter. So, if a conflicting policy is applied via MDM and GP, the setting applied from GP takes precedence.


Good, now we were getting somewhere. One final validation was to identify the GPO in question and for this I ran the RSOP.msc to reveal the policy in question.



Now that I had all the ducks in a row, it was just a matter of getting the relevant GPO un-assigned and the ASR rules from Intune got enforced. The Audit policy came into effect and the Macros were no longer getting blocked. 


All was good with the world again and I lived another day to tell my tale through this blog. On to my next conquest now. Thank you for reading and look out for my blog space as I am working on some interesting content to be shared in the coming weeks. Stay tuned..

Comments

  1. This article is a gem! I appreciate the detailed research you put into it. It’s refreshing to see such thoroughness!

    ReplyDelete

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

Prevent users from running certain programs or applications on Windows endpoints using Intune

Intune: Configure Printers for Non-Administrative Users