Q: Our users can modify the permissions on documents they create in sensitive document folders. How can we mitigate the risk that this capability permits or prevent users from changing object permissions altogether?
A: In Windows, every object has an owner who has full control of the object, including the ability to modify its ACL. By default, when a new object (e.g., a file) is created, the user who created it automatically becomes the owner. Ownership takes precedence over permissions, so the owner has full control no matter what the object’s permissions.
To prevent users from changing the permissions on objects, you must change ownership of the objects. To be safe, you should also find a way to detect when users change permissions on objects so that you can respond appropriately. You can use the SetACL open-source utility (http://setacl.sourceforge.net/index.html) to change object ownership from the command line. The following command schedules a batch file that runs every night and assigns ownership of all files on the server to the Administrators group:
SetACL.exe -on "c:\" -ot file -actn setowner -ownr "n:S-1-5-32-544;s:y"”
SetACL.exe -on "c:\" -ot file
Because this command won’t prevent users from changing an object’s permissions the same day the object is created, I also recommend a detective measure that uses the Security log. To make Windows record an event in the Security log whenever permissions are modified on an object, first enable the Audit object access audit policy for Success events. You can find this audit policy by running gpedit.msc and loading your local computer’s Group Policy Object (GPO).
After you enable object access auditing at the system level, enable auditing of specific permissions and user groups at the object level. You want to know when any end users modify permissions on sensitive documents. Suppose that all sensitive documents on your server are under C:\files and that a group called EndUsers gives you information about everyone but administrators. Open the C:\files properties dialog box, select the Security tab, and click Advanced. On the Auditing tab, add an entry for EndUsers that audits successful use of the Change Permissions permission.
After you make this change, Windows versions before Vista will begin logging event ID 560 (Object Open). Vista will log event ID 4670 ( Permissions on an object were changed). These events report both the name of the object and the name of the user who modified its permissions. (To distinguish instances of event ID 560 that indicate permission changes from the other types of access that can generate event ID 560, look for WRITE_DAC in the event’s description.)