Assigning Administrators Ownership of Objects - 26 Apr 2007

Q: Our users can modify the permissions on documents that they've created in sensitive document folders. Why does Windows let end users change the permissions on objects that they create in such folders, and how can we mitigate the risk 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 such as 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 have to 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"”

This command won't prevent users from changing an object's permissions the same day the object is created, so 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 enabling object access auditing at the system level, you need to enable auditing of specific permissions and user groups at the object level. In this scenario, you want to know when any end users modify permissions on sensitive documents. Let’s imagine that all sensitive documents on your server are somewhere 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, as shown in Figure 1.

After you make this change, Windows versions prior to 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, as shown in Figure 2.

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.