|
Posted by Roger Abell [MVP] on July 4, 2006, 11:23 pm
Please log in for more thread options >I think you are onto something here. At least some of the systems I am
> seeing the Synchronize audit messages on were new installs on a file
> system
> that was once used for Windows 2000 and has legacy folders still
> installed.
>
> I will start reading about SACLs, but do you have any syntax document for
> SetACL? I downloaded it and the command line help is beyond awful. The
> syntax is among the obscurest and least obvious of any utility I have ever
> used. That one needs to go to the UNIX hall of fame. I looked on the
> SourceForge page for documentation and found only an article written by
> the
> author, useful for concepts only not syntax of SetACL.
>
Fully agreed, and I can offer no help beyond what you have likely already
turned up at SourceForge and via Google.
> Does any third party make a high quality GUI based security permissions
> editor that shows all of the DACL / SACL attributes that can be set,
> including Synchronize? I'm willing to pay for something, particularly if
> it has the ability to build templates that can be applied via command line
> tools, so I can partly automate correcting this on multiple machines.
>
You really should look into scripting, or use of the new system management
security namespace introduced with .Net Framework version 2. Xcacls.vbs
grabs the DACL object, but the SACL object is available and handled 100%
similarly to what xcacls.vbs does with the DACL.
I guess your issue (for reACLing or adjusting the existing DACLs) depends
on how extensive that legacy storage - where by extensive I do not so much
mean size of the store but variability in its ACLing, amount of points
establishing
new inheritances, etc.. Again, xcacls.vbs could be used to just make sure
that
Synch is allowed without mod of what is there now, including the inheritance
structure.
> If your theory is right, then we should remove Synchronize from the DACL?
> It won't matter if Synchronize is in the SACL?
No. Synchronize should be granted with the other DACL grants. Its not
being so done too often was likely one of the reasons behind the GUI
change with Whistler era Windows.
> I'm a bit confused really,
> because if we include Synchronize in the DACL, then shouldn't it be
> ignored
> since it is automatically granted anyway? And if we include Synchronize
> in
> the SACL, it shouldn't really matter since the privilege is always granted
> as well?
>
I am not sure I see what you are getting at.
Event reporting of permissions failures merely states how things are
compared to what is being requested. It does not venture into what
ought to be.
Were everything ACL'd with XP or later, then audit that includes Synch
should not be throwing access failures as Synch would have been granted.
When something attempts access to a secured resourse it states the
accesses that it is requesting. These are either all filled, or there is a
shortfall, and if there is a shortfall and the object is being audited for
failures by the principal making the request, then an audit record is cut.
If Synch was correctly granted then it would not trigger these. But,
keep in mind that the ACL bits can be used other than on NTFS objects,
so saying "why bother with Synch" anymore overlooks other uses.
>
>> I am wondering whether you have some storage that originally existed in
>> Windows 2000 or earlier ? or was ACLed as part of an install using an
>> installer written back in that era ??
>>
>> Starting with XP Synchronize was no longer shown as a separate bit one
>> could specify (or not) in an ACE definition using the NTFS security
> dialog.
>> Instead, it was just always granted behind the scenes. So, in essence,
> the
>> failures you are seeing for Sync are actually errors in how the storage
>> is
>> ACLed.
>>
>> The result of this however is, as you have found, that the bit is now
>> also
>> not separately available for specifciation in you audit SACL definitions.
>>
>> Perhaps you could approach this issue by correcting the areas where there
>> are failures triggered for the grant of Synchronize. XCacls.vbs lets one
>> get at that (the E in a detailed permissions spec).
>> http://support.microsoft.com/default.aspx?scid=KB;EN-US;825751
>> XCacls.vbs does not let one get at the SACL, just the DACL however.
>> However, if you are into scripting, then it is only a small modification
>> to follow the example of xcacls.vbs but altering the SACL instead.
>> Alternative, SetAcl can alter SACLs and can be used in fine detail.
>> http://setacl.sourceforge.net/
>> A further alternative would be to use a security template to set the
>> SACL after editing the SDDL to remove the DACL part.
>>
>>
>>
>> > After turning on auditing of files in Windows 2003 and Windows XP, I
> have
>> > quickly learned that nearly all program execution in Windows involve
>> > certain
>> > kinds of file access that are not granted to a user with read/executive
>> > priviletges. These accesses generate audit events. The most
> offensive
>> > privileges required are:
>> >
>> > read attribute
>> > read extended attribute
>> > write attribute
>> > write extended attribute
>> > synchronize
>> >
>> > Luckily, I can turn off security auditing on read and write of
> attributes.
>> > Is there a way to turn off security audting of a failure to get the
>> > synchronize privilege? My security logs are occasionally full of
>> > these
>> > security failure events, and it is driving me crazy having to wade
> through
>> > noise.
>> >
>> > If this is something they addressed in Vista / Longhorn I would like to
>> > know
>> > about that as well.
>> >
>> > --
>> > Will
>> >
>> >
>>
>>
>
>
| 
XML Sitemap