Wow, that's informative--thanks for that. Microsoft had a seminar in our city about 5 years ago, and I actually asked one of their support folks about this. He had no idea what I was talking about and said that he had never heard of that before, so I figured I was out of luck.
That said, it is unfortunately not a solution for me, because of this: "Make sure that the user account that is used to move the object has the Change Permissions permission set. If the permission is not set, grant the Change Permissions permission to the user account." If I gave folks the ability to change permissions on these secured directories, I would have no end of problems. Actually, I have the permissions set the way I do to keep folks from monkeying around with that stuff in the first place. Bill Mayo -----Original Message----- From: Crawford, Scott [mailto:[email protected]] Sent: Wednesday, April 28, 2010 1:31 PM To: NT System Admin Issues Subject: RE: The finer points of NTFS ACLs (was: Software installs on new PCs) The values you want are HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Fo rceCopyAclwithFile HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Mo veSecurityAttributes This KB details this: http://support.microsoft.com/kb/310316 -----Original Message----- From: Mayo, Bill [mailto:[email protected]] Sent: Wednesday, April 28, 2010 12:08 PM To: NT System Admin Issues Subject: RE: The finer points of NTFS ACLs (was: Software installs on new PCs) +infinity We do exactly what you describe, and I always have issues (mostly when doing file migrations due to server moves) related to people copying files from one secured directory to another and the permissions not getting updated. When the permissions are set to inherit from parent, it seems to me that Windows should re-assess that on a file copy. Bill Mayo -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Wednesday, April 28, 2010 12:45 PM To: NT System Admin Issues Subject: The finer points of NTFS ACLs (was: Software installs on new PCs) On Wed, Apr 28, 2010 at 11:54 AM, James Rankin <[email protected]> wrote: > We see this problem where people create folders under shared drives, > that each new folder is owned by the creating user who then has the added rights. > The solution is some weekly subinacl tasks that re-take ownership of > the whole fileserver structure back to BUILTIN\Administrators Wouldn't it be better to just remove "CREATOR OWNER" from the ACL on the folder? All our shared folders are set so only the group(s) which should have permission are present. The only good use for "CREATOR OWNER" I've found is kludging around apps that insist on writing to their own program directory. So grant users "Create File" on "This folder only", and separately grant "CREATOR OWNER" "Modify" on "Files only". Now users can create the file, but can't touch anything else. My biggest beef is that if you move an object within a "drive" on Windows, Windows does not update the ACL on the object to reflect different permissions in its new location. So, for example, when a file is moved from the QA-only pre-release folder to the whole-company general-release folder, the file still has permissions for pre-release and nobody else can read it. Anyone got a fix for *that*? -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
