TEAM: Huntress Managed SIEM (Security Information and Event Management)
ENVIRONMENT: Windows Event Logs (WEL), Intune, Active Directory (AD), local group policy
SUMMARY: Unknown or forgotten leftover policy commonly interferes with Huntress recommended audit policy, so we created this page to help you determine which system is changing policy. This typically involves looking at effective policy using auditpol, gpresult, and dsregcmd.

Table of Contents

Policy Precedence

Effective Policy

Intune

Active Directory (AD)

Local Group Policy

Further Troubleshooting

It's highly recommended that you go through every section as it's incredibly common to find policy being set on systems that have been forgotten, extremely narrow in scope, or aren't in use anymore.

Policy Precedence

First thing to keep in mind is the policy precedence, which is critical for understanding which system is changing effective policy. Conflicting policy from lower tier systems will always be overwritten by higher tiered systems like Intune with MDMWinsOverGP turned on. Because of this and the possibility of forgotten policy, it's highly advised to check every section in this article, even if you don't believe it's a factor!

Intune(*) > AD GPO > Intune(**) > Local GPO > Registry / GUI settings / Huntress

Intune(*) - Intune with MDMWinsOverGP turned on. 
Intune(**) - Intune with MDMWinsOverGP turned off (default state).

Effective Policy

Effective Policy is the policy state on a machine after processing policy from different sources (AD, local GPO, Intune, etc). There is considerable complexity in managing policy scoping and ensuring machines have a healthy connection to AD/Intune, because of this it's highly recommended to only look at effective policy on the machine and ignore tools like Group Policy Editor and Intune's portal (when looking for policy mismatches). This means primarily using tools like auditpol and gpresult on the endpoint itself. 

Since policy is typically applied to a large subset of machines, focusing on one machine will usually fix all or most of the policy mismatches fleet-wide.

Intune 

If you know the machine(s) was Intune enrolled at one point, skip straight to "Generating the Intune Report".

Quick Check for Intune

Since previous policy can still interfere even if Intune isn't running, these below indicators are not a reliable way to prove Intune isn't affecting policy, but they can be used to quickly prove the machine was Intune managed and thus Intune policies need to be examined. If you see these indicators you'll need to proceed through this entire section to be sure Intune is not a factor.

• omadmclient.exe process running indicates the machine is Intune connected.
• In Task Scheduler, under Microsoft > Windows > EnterpriseMgmt > if this section isn't blank then the machine was or is Intune connected.
• Running the command dsregcmd /status will show the current connection status of Intune and AD, however there could be leftover policy as most security settings are not reverted when un-enrolling from Intune and AD.

Generating the Intune report

Use the GUI:The easiest way to see Intune effective policy is to sign into an affected machine's GUI to pull an Intune report. Open Settings > Accounts > Access work or school > find the appropriate account and click Info. At the bottom of this page, select the "Create report" button. 

Use PowerShell: Alternatively, you can run this PowerShell command:

MdmDiagnosticsTool.exe -out c:\Users\Public\Documents\

Interpreting the Intune report

1. A MDMDiagReport.zip or MDMDiagHtmlReport.html file should be created in c:\Users\Public\Documents\
   • If neither file was generated that typically indicates insufficient permissions or OS corruption. Even machines which have never joined Intune should still generate this file!
2. Open MDMDiagHtmlReport.html (may be inside MDMDiagReport.zip)
3. Scroll down to the "Managed policies" category
   • If you don't see this category, the machine's audit policy is/was not being managed by Intune, move down to the section "Active Directory".
4. In this category, you'll be looking for any of the audit policies Huntress recommends. Using your browser to search for "Audit" with highlight-all selected is a good starting point.
5. If you see any of the Huntress Audit Policy categories in here, you'll need to follow our Intune guide to change Intune policy to match Huntress recommendations. Alternatively, if you remove the Intune policies which affect Audit Log Policy, that will allow Huntress to automatically manage the policy (assuming no other higher priority system is controlling policy).

Active Directory (AD)

There are a few different ways to show effective policy from AD, however these two methods are typically the fastest and most thorough.

Quickest method 

Will not show policy conflicts, only the source of any audit log policy change. You will only see results from this command if the machine's audit log policy has been changed from default (in AD or local GPO). Please note this shows all policies with "audit" in the name, thus some results may not be relevant!

If you see results from running the below command and they point towards Audit Logging policies, you'll need to either remove the conflicting GPO or change the GPO to be in line with Huntress recommendations. 

gpresult /scope COMPUTER /V | Select-String -Pattern "audit" -SimpleMatch

In the example below we see 3 policies being configured via a domain policy named "test audit policy". 

Comprehensive method

Will create a file showing effective policy after local and AD GPO processing (does not include Intune!) 

Use the command below to generate the file, and then open it in your browser. This file can be quite large, so it's suggested you click "show all" at the very top and then search for the text "audit". If you see search results under the Policy section that matches the text "audit", if those policies are also configured by Huntress you'll need to either remove the conflicting GPO or change the GPO to be in line with Huntress recommendations. 

gpresult -h GPResultForHuntress.html

In the example below we see 5 potential policy conflicts, highlighted with a yellow box. The AD GPO which is setting this policy is named "test audit policy", highlighted with a blue box. Policies set at the local level will have "Local Group Policy" under the Winning GPO column (green box is just illustrating how local policy appears). 

Using the name of the GPO found under the Winning GPO column, edit or remove the AD GPO which is conflicting with Huntress recommendations. Once the policy is changed or removed you'll need to either wait for the change to propagate through the network, or run gpupdate /force on the affected machine(s) to speed up the propagation.

Local Group Policy

Check your local group policy for configurations by opening Local Group Policy Editor, then navigating to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration. If you see any policy in here you have two basic choices:

• Remove all the local policy that conflicts with Huntress recommendations. That will allow the Huntress agent to manage audit log policy. 
• If you wish to continue using Local Group Policy Editor, change any conflicting policy to match the Huntress recommendations. 

You'll also need to browse the computer to look for audit.csv, which can contain local group policy that isn't visible in the GUI editor above. Look in these two locations:

c:\Windows\security\audit\audit.csv 
c:\Windows\System32\GroupPolicy\Machine\Microsoft\WindowsNT\Audit\audit.csv

Remove both files and reboot to allow Huntress to manage audit log policy.

Further Troubleshooting

There are third party systems which can also manage Windows Audit Logging Policy so in some cases you may need to dig further to find the source. 

One suggestion is to use Huntress SIEM to dig for further info. 

1. The primary event ID, 4719, is off by default on some systems so it's highly recommended you turn on Audit Policy Change in Local Group Policy Editor first. You can find the policy in Computer Configuration  ➡️ Windows Settings ➡️ Security Settings ➡️ Advanced Audit Policy Configuration ➡️ System Audit Policies ➡️ Policy Change ➡️ Audit Audit Policy Change (success and failure)
2. If 4719 logging was off, you'll need to wait at least 24 hours before proceeding to give the logs some time to populate with data.
3. Go into the Agent's landing page and select "Logs", or click the Windows Event Log source in SIEM Sources. Change the time span to the last 7 days and then use this search:

from logs | where event.code in (4715, 4912, 4885, 4719) | keep winlog.event_data.AuditPolicyChanges, winlog.event_data.SubcategoryId, winlog.event_data.ClientProcessId

4. The screenshot below has some example data you might see from this query. The columns highlighted in red are most likely to be useful for investigating.
   • winlog.event_data.AuditPolicyChanges indicates what changes occurred.
   • winlog.event_data.SubcategoryId indicates which category of Audit Policy was changed.
   • winlog.event_data.ClientProcessId indicates the PID of the process which changed policy. 

Because PIDs can be reused quickly, you should correlate the PID captured when the audit policy changed with the process that owned that PID at that time. Continuing with the above example, the Task Manager in this case identified PID 1240 as Huntress and PID 1776 as the Group Policy Client. 

You may be able to use Huntress Process Insights (EDR) to trace the PID, however some processes like Huntress start with Windows and thus may only be visible for about 16 hours in Huntress Process Insights data. In most cases this method is only effective for up to 16 hours after reboot, thus you may need to establish when policy is being changed so that you can reboot the machine a few minutes before. In this manner, you can correlate the PID with Huntress EDR data.

1. Go into the Agent's landing page
2. Click on Process Insights, then select the Process Events tab
3. Expand the time range to 16 hours and then search for the below (replace 1240 with the PID you're trying to trace)

Pid == "1240"

This is not an exhaustive list, but you may see these processes involved in policy change:

• Microsoft.Tri.Sensor.exe or Microsoft.Tri.Sensor.Watcher.exe - Microsoft Defender for Identity
• Microsoft.IdentityServer.ServiceHost.exe - Active Directory Federation Services (AD FS)
• MsSense.exe or MsMpEng.exe - Microsoft Defender for Endpoint
• Service Host: Group Policy Client - Local Group Policy
• secpol.msc - Microsoft Management Console (Local Security Policy)
• mmc.exe - Microsoft Management Console (loading GPO's)
• auditpol.exe - command line tool for altering policy. This can be executed by 3rd party programs so you may need to trace the Parent PID!