Forum Discussion
Enabling Tamper Protection with Tenant Attach
I am trying to determine how, if possible, to enable Tamper Protection but the various combination of current portals, features, and their preview/production status is making it difficult to follow. ...
- I don't think it means that policies are not applying. Have you tried simulating any attacks to test for the policies? Do you see any events being reported in Eventvwr or Advanced hunting for the same?
I've found Windows Defender event ID 5013, which gets logged every time Tamper Protection blocks a change from taking place. With that getting shipped into my central logging I can see that ConfigMgr antimalware policies are causing this to trigger with every group policy refresh, with messages such as:
Tamper Protection Ignored a change to Microsoft Defender Antivirus.
Value: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\real-time protection\DisableOnAccessProtection = 0x0()
I'm now switching the test back to get its antimalware policies from MEM, to see if that change the number or frequency of 5013 events. But this seems to indicate that ConfigMgr antimalware policies, or at least some of them, are not compatible with the user of Tamper Protection.
Tamper Protection Ignored a change to Microsoft Defender Antivirus.
Value: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\real-time protection\DisableOnAccessProtection = 0x0()
I'm now switching the test back to get its antimalware policies from MEM, to see if that change the number or frequency of 5013 events. But this seems to indicate that ConfigMgr antimalware policies, or at least some of them, are not compatible with the user of Tamper Protection.
I don't think it means that policies are not applying. Have you tried simulating any attacks to test for the policies? Do you see any events being reported in Eventvwr or Advanced hunting for the same?
- I was able to generate event ID 5013 and verify the attempt was unsuccessful, using the below commands.
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableIOAVProtection $true -DisableEmailScanning $true -DisableBlockAtFirstSeen $true
I also tried wiping all existing definitions with the other command below. Unlike the above 2 tests, this command returns an error and does not log any Event Viewer events. None of these tests resulted in Microsoft 365 Defender incidents or alerts.
& "$ENV:ProgramFiles\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All
I believe my issue with the 5013 events appearing is from my ConfigMgr antimalware policies also applying to the test device, which lines up with:
https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection?view=o365-worldwide#what-happens-if-i-try-to-change-microsoft-defender-for-endpoint-settings-in-intune-microsoft-endpoint-configuration-manager-and-windows-management-instrumentation-when-tamper-protection-is-enabled-on-a-device.
When policies are defined through MEM with Tenant Attach they are taking priority over ConfigMgr, but every gpupdate causes around 25 instances of event 5013 and I believe that would be from the ConfigMgr policies attempting to apply. We have our registry-based group policy settings defined to full reapply at each refresh, and not only when there is a change.
After all of this, my main source of confusion is - how and where can we define and update policies (scheduled scans, exceptions, etc.) when Tamper Protection is enabled? Does that answer change depending on where/how Tamper Protection gets enabled?- If I understand this correctly then I think the problem here is that you have multiple policy providers. Why not deploy all Defender policies using ConfigMgr and tamper protection using tenant attach?
- My only concern with that has been the 5013 events "Tamper Protection Ignored a change to Microsoft Defender Antivirus", and this still occurs even when only ConfigMgr policies are applied.
After going through each of the events I do not see any cases where we're trying to actually change a setting that Tamper Protection protects. The event must be happening because ConfigMgr is trying to write those registry values, even though they would match what is already there.
My initial concern about not being able to apply ConfigMgr antimalware policies looks to be answered. It can apply them, just that it will also attempt to apply configurations that Tamper Protection will prevent and log the 5013 events even if you are just duplicating the secure defaults Tamper Protection is trying to protect. And there appears to way to have ConfigMgr antimalware policies apply without generating the event so it becomes known, but expected behavior instead of something that could more reliably be alerted on.
