do we avoid auditing failed synchronize file access

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

Will,
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.

"Will" wrote in message

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

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.
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.
If your theory is right, then we should remove Synchronize from the DACL? It won't matter if Synchronize is in the SACL? 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?
-- Will
"Roger Abell [MVP]" wrote in message

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.

"Will" wrote in message 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

"Will" wrote in message

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.

"Roger Abell [MVP]" wrote in message 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.

"Will" wrote in message 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

I'm setting the DACL on the root and inheriting the DACL to c:\windows and c:\windows\system32. To my surprise, every program inside of c:\windows\system32 has been stripped of its DACL inheritance and given its own ACL, and the inheritance rule I am setting for system32 is not being picked up by the files in system32 that do not inherit. This may be contributing to the symptoms I'm seeing (still trying to figure it out).
Is there any particular reason for Windows giving every file in SYSTEM32 its own DACL that is not inherited? I certainly don't want to overwrite thousands of files' and dozens of folders' DACLs when some of those probably really do need different settings. Nor do I want to have to pick apart 1000 file DACLs and think about whether they could inherit or not.
-- Will

If you check "setup security.inf" you will see it has an extensive filesystem section, resulting in what you are describing. We have asked MS before why they are not leveraging inheritance and instead setting explicit perms on each file. I never really have heard a statement that to my way of thinking explains it, let alone argues in favor of it. In Wistler beta times some of us tried to get this changed in order to enable more direct and simple NTFS perms oversight and management, but no go.
"Will" wrote in message

I'm setting the DACL on the root and inheriting the DACL to c:\windows and c:\windows\system32. To my surprise, every program inside of c:\windows\system32 has been stripped of its DACL inheritance and given its own ACL, and the inheritance rule I am setting for system32 is not being picked up by the files in system32 that do not inherit. This may be contributing to the symptoms I'm seeing (still trying to figure it out).
Is there any particular reason for Windows giving every file in SYSTEM32 its own DACL that is not inherited? I certainly don't want to overwrite thousands of files' and dozens of folders' DACLs when some of those probably really do need different settings. Nor do I want to have to pick apart 1000 file DACLs and think about whether they could inherit or not.
-- Will

Well, this is chaos. Complete and utter chaos.
Sprinkle in two weeks of hard work to investigate the NTFS permissions under system32. Add three pinches of pure guesswork to decide if any arbitrary file must inherit or not. Add six or so problem tickets with Microsoft to debug the problems we are going to create by doing any of this work.
That's my recipe for what it will take to get this under control on just one computer.
How can I force just the files in the system32 folder to start inheriting, without touching the folders in system32 and without touching files and subfolders under those?
-- Will
"Roger Abell [MVP]" wrote in message

If you check "setup security.inf" you will see it has an extensive filesystem section, resulting in what you are describing. We have asked MS before why they are not leveraging inheritance and instead setting explicit perms on each file. I never really have heard a statement that to my way of thinking explains it, let alone argues in favor of it. In Wistler beta times some of us tried to get this changed in order to enable more direct and simple NTFS perms oversight and management, but no go.

Too funny, or perhaps too pessimistic (?)
I believe you can accomplish what you outline by use of the Security Configuration and Analysis mmc snapin and a custom template. To make the template, create a new template and in the filesystem section add the root directory that you want to be the inheritance root and define what should be the perms inherited, and (this is first key part) on the way ok'ing out check the radio button to configure and then . . . replace existing Now, for each subfolder that should not be affected, nor have its contained files/subfolders affected, at that subfolder and just pass over the permissions (does not matter) and then (second key part) select the radio for Do not allow perms to be replaced. So, you need to add the one spec that will apply to the new inheritance point and the files within, and then you need to add one "do not allow" for each subfolder. The result is that when used this sets that folder and its files and does not touch any subfolders or their files. In case you have not used the Security Templates snapin, right click on your new template and Save. Then, with the Sec Config and Analysis tool open database, providing any name for a new working database if needed, then right click and import template, nav'ing to the newly saved and be sure to check to clear the database. Then right click and analyze, perhaps look around to make sure it looks like it will do what and only what you think is in the template, then right click and configure (which uses what is in the database, hence the import of first clearing during import and then analyzing to load template result to database).
"Will" wrote in message

Well, this is chaos. Complete and utter chaos.
Sprinkle in two weeks of hard work to investigate the NTFS permissions under system32. Add three pinches of pure guesswork to decide if any arbitrary file must inherit or not. Add six or so problem tickets with Microsoft to debug the problems we are going to create by doing any of this work.
That's my recipe for what it will take to get this under control on just one computer.
How can I force just the files in the system32 folder to start inheriting, without touching the folders in system32 and without touching files and subfolders under those?
-- Will
"Roger Abell [MVP]" wrote in message If you check "setup security.inf" you will see it has an extensive filesystem section, resulting in what you are describing. We have asked MS before why they are not leveraging inheritance and instead setting explicit perms on each file. I never really have heard a statement that to my way of thinking explains it, let alone argues in favor of it. In Wistler beta times some of us tried to get this changed in order to enable more direct and simple NTFS perms oversight and management, but no go.

It's not the syntax of how to use a template that is hard work. It's the understanding of what protections to use on each file that is the nightmare.
Is there any command line or GUI tool that would automate the creation of a template? I am thinking we will dedicate one computer of each type as a reference computer, and then take snapshots of just permissions on its file system to use on other machines.
Alternately, do you know of a backup package that has clear and separate options for backing up DACL and SACL for each file system object, and - this is key - has a restore option that allows you to restore either or both DACL / SACL and *not* restore the file data itself.
-- Will
"Roger Abell [MVP]" wrote in message

Too funny, or perhaps too pessimistic (?)
I believe you can accomplish what you outline by use of the Security Configuration and Analysis mmc snapin and a custom template. To make the template, create a new template and in the filesystem section add the root directory that you want to be the inheritance root and define what should be the perms inherited, and (this is first key part) on the way ok'ing out check the radio button to configure and then . . . replace existing Now, for each subfolder that should not be affected, nor have its contained files/subfolders affected, at that subfolder and just pass over the permissions (does not matter) and then (second key part) select the radio for Do not allow perms to be replaced. So, you need to add the one spec that will apply to the new inheritance point and the files within, and then you need to add one "do not allow" for each subfolder. The result is that when used this sets that folder and its files and does not touch any subfolders or their files. In case you have not used the Security Templates snapin, right click on your new template and Save. Then, with the Sec Config and Analysis tool open database, providing any name for a new working database if needed, then right click and import template, nav'ing to the newly saved and be sure to check to clear the database. Then right click and analyze, perhaps look around to make sure it looks like it will do what and only what you think is in the template, then right click and configure (which uses what is in the database, hence the import of first clearing during import and then analyzing to load template result to database).
"Will" wrote in message Well, this is chaos. Complete and utter chaos.
Sprinkle in two weeks of hard work to investigate the NTFS permissions under system32. Add three pinches of pure guesswork to decide if any arbitrary file must inherit or not. Add six or so problem tickets with Microsoft to debug the problems we are going to create by doing any of this work.
That's my recipe for what it will take to get this under control on just one computer.
How can I force just the files in the system32 folder to start inheriting, without touching the folders in system32 and without touching files and subfolders under those?
-- Will
"Roger Abell [MVP]" wrote in message If you check "setup security.inf" you will see it has an extensive filesystem section, resulting in what you are describing. We have asked MS before why they are not leveraging inheritance and instead setting explicit perms on each file. I never really have heard a statement that to my way of thinking explains it, let alone argues in favor of it. In Wistler beta times some of us tried to get this changed in order to enable more direct and simple NTFS perms oversight and management, but no go.

I must have misunderstood your requirement <quote> How can I force just the files in the system32 folder to start inheriting, without touching the folders in system32 and without touching files and subfolders under those? </quote> To me this said, "I want to set inheritable permissions at system32, but I do not what this to alter any subfolder in system32 or files/subfolders of those unaltered subfolders of system32". From this I understood that you also wanted files in system32 to inherit from system32, but evidently you also want to leave the existing explicity permissions on those files but only add inheritance from system32. If the filesystem is XP or newer then I believe that you only need to have a script pass over the files only in system32 setting the Inheritance Requested flag in the DACL (and/or SACL) of each. I would have to examine more closely, by test cases, however whether indeed that SD flag is in and of itself sufficient to cause the change.
I am not aware of either a good tool for autogeneration of a template, nor one that can accomplish what you specify in a restore. Template generation itself is not too hard except for the determination of what truely is and is not inherited if the code must handle all cases for the origin history of the storage being examined. Template generation is only a matter of reading the SD (security descriptor) and converting the ACLs to SDDL syntax and then spitting out a template text line; the tough part is determining what lines do not need to be emitted.
-- Roger Abell Microsoft MVP (Windows Server : Security)
"Will" wrote in message

It's not the syntax of how to use a template that is hard work. It's the understanding of what protections to use on each file that is the nightmare.
Is there any command line or GUI tool that would automate the creation of a template? I am thinking we will dedicate one computer of each type as a reference computer, and then take snapshots of just permissions on its file system to use on other machines.
Alternately, do you know of a backup package that has clear and separate options for backing up DACL and SACL for each file system object, and - this is key - has a restore option that allows you to restore either or both DACL / SACL and *not* restore the file data itself.
-- Will
"Roger Abell [MVP]" wrote in message Too funny, or perhaps too pessimistic (?)
I believe you can accomplish what you outline by use of the Security Configuration and Analysis mmc snapin and a custom template. To make the template, create a new template and in the filesystem section add the root directory that you want to be the inheritance root and define what should be the perms inherited, and (this is first key part) on the way ok'ing out check the radio button to configure and then . . . replace existing Now, for each subfolder that should not be affected, nor have its contained files/subfolders affected, at that subfolder and just pass over the permissions (does not matter) and then (second key part) select the radio for Do not allow perms to be replaced. So, you need to add the one spec that will apply to the new inheritance point and the files within, and then you need to add one "do not allow" for each subfolder. The result is that when used this sets that folder and its files and does not touch any subfolders or their files. In case you have not used the Security Templates snapin, right click on your new template and Save. Then, with the Sec Config and Analysis tool open database, providing any name for a new working database if needed, then right click and import template, nav'ing to the newly saved and be sure to check to clear the database. Then right click and analyze, perhaps look around to make sure it looks like it will do what and only what you think is in the template, then right click and configure (which uses what is in the database, hence the import of first clearing during import and then analyzing to load template result to database).
"Will" wrote in message Well, this is chaos. Complete and utter chaos.
Sprinkle in two weeks of hard work to investigate the NTFS permissions under system32. Add three pinches of pure guesswork to decide if any arbitrary file must inherit or not. Add six or so problem tickets with Microsoft to debug the problems we are going to create by doing any of this work.
That's my recipe for what it will take to get this under control on just one computer.
How can I force just the files in the system32 folder to start inheriting, without touching the folders in system32 and without touching files and subfolders under those?
-- Will
"Roger Abell [MVP]" wrote in message If you check "setup security.inf" you will see it has an extensive filesystem section, resulting in what you are describing. We have asked MS before why they are not leveraging inheritance and instead setting explicit perms on each file. I never really have heard a statement that to my way of thinking explains it, let alone argues in favor of it. In Wistler beta times some of us tried to get this changed in order to enable more direct and simple NTFS perms oversight and management, but no go.

"Roger Abell [MVP]" wrote in message

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.

I hate to be dense, but clearly I am not getting something.
I went to both a Windows NT and Windows 2000 system. Nothing in either the DACL or SACL of either system says "SYNCHRONIZE"
If my file system is a legacy Windows 2000 or earlier file system, by default would it have granted Synchronize access or not? And how does that change in Windows XP and later?
-- Will