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 actuallyset this stuff easily and not juggle some scripts and auditpol.exe.
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
No comments:
Post a Comment