First published on TechNet on Mar 10, 2011
here again. I mentioned this once in a
Friday Mail Sack
but today I circle around and explain a well-hidden security feature added in Windows 7 and Windows Server 2008 R2:
Global Object Access Auditing
Oh boy, auditing! I bet you are excited!
What is it and how to enable it
You should be familiar with the security auditing of Windows by now; it’s been around since NT.
Beginning in Windows Vista, a new granular auditing system was added by
. It meant you could now specify in more (or less!) detail what types of data you wanted to audit. This allowed fancy moves like auditing what AD attributes were changed and even what their new values became.
Garbage in, garbage out
Starting in Windows 7 a new control mechanism called
Advanced Audit Policy Configuration
was added that let you actually
this stuff easily and not juggle some scripts and
Tucked away here in the new policy is a little known section called Global Object Access Auditing (GOAA – an acronym I just invented).
At this point you want to start clicking and touching. It’s only human. Unless you are using a test computer,
resist that urge.
If you start enabling anything in Advanced Audit policy, it will take effect immediately;
even if you do not click Apply.
Any pre-existing legacy audit policy will be overwritten and this new policy will start being used. If you enable a few things and then disable them, you will turn policy settings off – meaning that you are now auditing nothing. Undoing this is a pain in the neck, so don’t start touching audit policies until you are done testing and ready to roll out to production.
I’ll be writing more about effective auditing settings and dealing with all this in a follow up post very soon.
When you look at the policy, you will see that it has a curious configuration dialog. In your test computer, note the File and Registry nodes, and that they only contain a “configure” option:
Click that button and you will see the usual security dialog where you assign file or registry auditing:
Global auditing lets you create System Access Control Lists (SACL) for the
, based on file and registry. This means that instead of manually altering and maintaining SACLs on 10TB of shared files, you can instead define them implicitly and
not actually modify the files at all
. You can then troubleshoot an unexplained file deletion, see who keeps changing permissions on a folder, or satisfy an auditor.
This is extremely cool.
is the process that handles Windows security auditing. In the usual on-file auditing system it sees when files and registry keys are being opened, notes the SACL attached to that file, and sends the auditing data into the security event log. When the file is opened using GOAA,
also adds to the SACL in memory, then reads it like it had been assigned on the resource directly. Sort of psyches itself out.
So even though I have no auditing configured on these files:
Deleting a file gives me my audit trail:
To be clear here: you must
turn on “Object Access \ Audit File System” or “Object Access \ Audit Registry” in order to have the actual auditing end up in your event log, just like always – GOAA does not enable all auditing, it just adds the magic SACL.
GOAA and the actual on-file audit entries of NTFS can coexist without issues. So if each has different settings, the combined SACL will be used for auditing. There’s no way they could conflict; worst case, they would be redundant. You only get a discrete audit event per action as well – there’s not a “GOAA event” and a regular event.
You can also use
to view and set these settings outside of group policy; this is an important distinction as the usual
auditpol.exe /get /category:*
will not show these effective settings. Note that when specifying the
value that the arguments are - rather disappointingly - case sensitive. So
will not work but
The only reason you’d ever set through this utility would be in an unmanaged environment with no security policy being applied by the domain. And since you can’t manage the computer, odds are you can’t get to the audit logs remotely to see what’s happening, so this is one of those “not very likely” scenarios.
As far as what actions you should audit – that’s up to you. The
Book of Fitzgerald
states that enabling Failure auditing is usually a bad idea. Auditing “List Folder / Read Data” and their ilk of file access entries are probably not very useful. I recommend you invest in an
audit collection product
if this is going to be enabled all the time as your logs are only useful if they are retained.
And yes, this works great with DFSR. Since you are not actually changing a file when you use GOAA, you are not going to trigger unnecessary replication with the act of setting up auditing in the first place. For example, here I add a SACL to a replicated file the old fashioned way. Note in the DFSR debug log how this triggers a USN update and the file changes get replicated to all partners via RDC:
20110308 20:08:04.339 2788 USNC 2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
+ RecordLength: 104
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0xF00000000E19C
+ ParentFileRefNumber: 0x70000000038A3
+ USN: 0x85c658
+ TimeStamp: 20110308 20:08:04.339 Eastern Standard Time
+ Reason: Close Security Change
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x20
+ FileNameLength: 44
+ FileNameOffset: 60
+ FileName: I am some user goo.rtf
But if I change my GOAA policy, nothing happens. It’s hard to show you a debug log of nothing happening so you’ll just have to take my word for it. :-)