If an existing domain policy is already managing security auditing, this may cause the Enhance Security Auditing policy to fail. There are two types of observable failures. The first is where all the remotes in the environment fail the monitor, then they flip to success and auto-close, only to reopen about 90 minutes later. The other behavior is when they all fail and stay failed.
For either condition, here's what is occurring: when a Third Wall monitor finds a failure state, it throws a ticket and runs an auto-fix on the remote. The next time the monitor runs, it sees the settings set properly and closes the ticket.
The issue occurs when the existing domain policy changes those values set by Third Wall. The results you see are determined by the domain's group policy refresh interval. When set to 90 minutes, you'll see the first type of observable failure where tickets come in, auto-close then reappear 90 minutes later. The refresh time for local policies is much faster and will cause the second type of observable failure - where your remotes all fail the monitor and the monitor stays failed. To fix either condition, you'll need to find and remove the conflicting domain or local policy.
Here are the Group Policy paths to the policies that may conflict with your Third Wall settings. Please ensure all polices here are set to 'Not Configured':
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Management
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> DS Access
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Object Access
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Policy Change
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Privilege Use
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> System
Computer Config -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Global Object Access Auditing
Once the domain is no longer altering your Third Wall settings, you should see any open tickets for this policy auto-close within the next five minutes.
If you are unsure this failure is a result of a conflicting domain or local policy, the following test will answer that question. Before beginning, reference the ticket you received. It will list list the failed subcategories that caused the ticket. Be sure to test against the failed subcategory. The following example assumes the 'File System' subcategory is out of sync.
From an Administrative DOS shell, run these commands:
auditpol /get /subcategory:"File System"
It will probably tell you there’s either no auditing, or auditing is enabled for both success and failure. Let’s change that with this command:
auditpol /set /subcategory:"File System" /success:disable /failure:enable
For certainty, run the /get command again to make sure a change happened:
auditpol /get /subcategory:"File System"
Now, do a Group Policy refresh:
Gpupdate /force
…then quickly check the current state again:
auditpol /get /subcategory:"File System"
If a change is observed after running gpupdate then you've confirmed a policy conflict is at work here.
Below is a list of all the changes made by this policy. Use this list to apply the proper modification to the existing policy:
auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable
auditpol /set /subcategory:"System Integrity" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Driver" /success:enable /failure:enable
auditpol /set /subcategory:"Security State Change" /success:enable /failure:enable
auditpol /set /subcategory:"File System" /success:disable /failure:enable
auditpol /set /subcategory:"Registry" /success:disable /failure:enable
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:disable
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:disable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Other Account Management Events" /success:enable /failure:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change" /success:enable /failure:enable
Note: The instructions here will work in most environments but there are some which will need additional steps. These two links will help you to move forward if you're sure the audit policies are disabled on the Domain yet are continuing to be changed on the endpoints:
https://windowsexplored.com/2014/01/31/why-arent-my-windows-audit-policies-working/
https://thirdwallhelp.freshdesk.com/a/solutions/articles/43000586085