Monthly Archives: March 2016

Lesson learned – some audit policies cannot just be enabled simultaneusly

Today I learned that the some audit policies cannot be enabled at the same time.

To be able to audit logon events throughout our organization we have enabled the usual audit policies in the Domain Controller group policy:
auditpolicies
At some point someone decided to audit if there were happening changes to our audit policies, through the “Advanced Audit Policy Configuration”. This additional audit policy was made through the Group Policy Management Console on a Windows 2012R2 server. Here it’s possible, without issues or hints that it’s a bad idea, to make this policy. When this got enforced on domain controllers, they stopped logging the above events in their security event-logs. This made it impossible to help users that got locked out without knowing where from and why, because the typical “bad password” events did not get logged. This is where you get the client ip of the session that is giving the bad password, mostly because it’s been hanging around since before the user last changed their password.

If you look on technet, sure Microsoft mentions that if you enable both the audit policies and the advanced audit policies, it can cause odd behaviour – https://technet.microsoft.com/en-us/library/dd692792(WS.10).aspx

If the admin had looked and wondered about the explanation Microsoft put in the policy configuration, he would/should have made the change that is required to have both Audit Policy and the Advanced Audit Policy Configuration:

advancedauditpolicesHere it tells you to enable the “Audit: Force audit policy subcategory settings (Windows Vista or later)” under Windows Settings/Security Settings/Local Policies/Security Options.