Global Object Access Auditing is Magic
Hi folks, Ned 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.
Jealous much?!
Beginning in Windows Vista, a new granular auditing system was added by this guy. 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 set this stuff easily and not juggle some scripts and auditpol.exe.
Way better than this
Tucked away here in the new policy is a little known section called Global Object Access Auditing (GOAA – an acronym I just invented).
STOP!!!
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.
Effective audit settings are explained here
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 entire computer, 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.
LSASS.EXE 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, LSASS 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 also 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.
Other Notes
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 AUDITPOL.EXE /RESOURCESACL 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 /type value that the arguments are - rather disappointingly - case sensitive. So /type: file will not work but /type:File will.
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:
+ 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. :-)
Until next time.
Ned “admit it, you were excited” Pyle
Comments
Anonymous
March 11, 2011
The comment has been removedAnonymous
March 11, 2011
The comment has been removedAnonymous
March 11, 2011
Actually one serious question on GOAA... are there any Client Side Extension updates for non-R2 2008 servers, or are you only able to manually configure those server settings via AUDITPOL commands? I've heard/read that non-R2 2008 won't be able to make use of the GPO settings... Thanks again! SteveAnonymous
March 11, 2011
Nope, Vista and 2008 are on their own. A customer with a Premier contract can talk to their TAM about a backport request but it would need to be mighty compelling, as you're basically asking us to spend a ton of money in order for you NOT to buy our later operating system. Unlikely... For now, you have to continue using these workaround articles: 921469 How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain. 921468 Security auditing settings are not applied to Windows Vista-based and Window Server 2008-based computers when you deploy a domain-based policyAnonymous
March 11, 2011
dang... Thanks for the confirmation anyway though! Looks like another excuse to right some handy dandy PowerShell scripts! :)Anonymous
March 11, 2011
right = write, obviously... stinkin' hands type too fast sometimes!!