Condividi tramite

Auditing Changes to Audit Policy

  • Articolo

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we've always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it's not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting "audit changes to audit policy"?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say "don't generate audit".

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the "Audit Policy Change" subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the "Audit Policy Change" subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Comments

  • Anonymous
    November 02, 2010
    Any idea why event id "4719 System audit policy was changed" on Windows 2008 always shows “System” as the one who changed the policy i.e. the Subject fields don't identify who actually changed the audit policy. This problem doesn’t exist in Windows 2003 even id 612.

  • Anonymous
    November 02, 2010
    It doesn't always log as LocalSystem, it depends on how you set audit policy. If you use auditpol.exe you will get the user name of the user who ran auditpol. If you use secpol.msc or gpedit.msc to edit audit policy, the event will show up as LocalSystem. This has to do with how Windows works (which oddly enough changes from version to version). The audit event always records the user account from the token of the process that called the audited API (in the case of audit policy, it's AuditSetPolicy or LSASetInformationPolicy(AUDIT_POLICY). If you run a tool which calls the API directly, then your account will end up in the event.  This is what AuditPol.exe does. If you run a tool which sets configuration for another process, which then calls the auditable API, then you get the user account information about the token of the calling process.  So when you use GPEDIT or SECPOL.MSC you are talking to the Group Policy Client which runs as LocalSystem and eventually calls the auditable API.  In this case the event correctly records LocalSystem, which is the context of the caller. Yes, we know that this doesn't always generate the audit trail that users desire, and we actually are investigating whether there is anything we can do for a future release.

  • Anonymous
    November 02, 2010
    Thanks Eric for the explanation, I appreciate it. We look forward to hearing more on this issue and a possible fix from Microsoft. Thx.

  • Anonymous
    November 04, 2010
    FYI - Following Windows 2008 Event IDs do not always show the "Perpetrator" field who actually made the chagne and generated the event. Event_ID – 4739 / 643 Domain policy changed – not able to get user ID taking the negative action, Is available in W2K3 event ID 643. Event_ID – 4719 / 612 Audit policy changed – not able to get user ID taking the negative action, Is available in W2K3 event ID 612.                                         Event_ID – 4704 / 608 User right assigned – not able to get user ID taking the negative action, Is available in W2K3 event ID 608. Event_ID – 4717 / 608 System security access granted – not able to get user ID taking the negative action, Is available in W2K3 event ID 608. Thanks

  • Anonymous
    March 21, 2011
    Hi Eric.. do you have any update on this? my audit policy setting gets cleared automatically once this event 4719 starts generating.. Thanks.

  • Anonymous
    March 22, 2011
    Hi Subrat, The 4719 event is not causing your audit policy to get cleared, it's logged when some other process clears your audit policy. This is most commonly caused by misunderstanding the use of the "Advanced Audit Policy" settings in Windows Server 2008 Group Policy.  This mechanism actually clears out all existing policy settings before it sets the specified settings; it does not have a "do not manage this setting" kind of capability as do other policies manageable in Group Policy.  I've mentioned to the auditing team that this is a change in behavior from previous versions of audit policy, maybe they will change it in a future version of Windows. Eric

  • Anonymous
    March 22, 2011
    In GPO it was showing auditing is enbled; when I use auditpol.exe then its says not configured for all categories. when I set the auditing using audipol /set; the audit enables for couple of minutes. after that the event 4719 generates and the setting gets cleared.  This was the scenario earlier. Thanks for your reply; so I checked in Advance audit policy setting - non of them were configured. I configured the auditing in Advance audit policy settings; and now its working fine.. Thanks Again!!!! Cheers...

  • Anonymous
    September 02, 2011
    on the domain controllers in my system each is getting 4719 90 times every 5 minutes..it's bad enough that 4719 tells me absolutely nothing worthwhile, worse yet that I can't turn this garbage off - which fills my security log to the point that I can't see actual important sec log events....

  • Anonymous
    September 04, 2011
    I'm sorry you don't think that 4719 tells you anything worthwhile.  In fact it records who changed an audit policy setting, what setting was changed, and what it was changed to.  So, for instance, if you're worried about administrators trying to cover their tracks by turning off audit policy, this would be something to look at. Domain controllers apply policy every 5 minutes.  So evidently you are applying advanced audit policy on your domain controllers OU. If you don't care about this event, then turn off "Audit changes to audit policy" under the "Policy Change" category for your DC's, and you'll suppress these events.

  • Anonymous
    November 10, 2011
    Spoke with premier support today and received the fix.  This issue arises b/c there is an audit .csv file in the following location which needs to be deleted for the machine to receive the group policy again.  Delete the file and to a gpupdate /force and that should do it.   c:windowssystem32GroupPolicyMachineMicrosoftWindowsNTAuditaudit.csv Contains : Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value