Auditing Permission Changes on a Folder

We have three shifts of IT staff, and more than once I've had to repair folder permissions because someone messed them up. How can I determine who changed permissions on a folder?

You'll need to enable auditing for successful object access events on the servers on which the folders reside, and you'll need to enable auditing on the folders you want to monitor. To enable auditing for successful object access events, you can either use an existing Group Policy Object (GPO) that's applied to your file servers or, if you don't already control auditing through Group Policy, you can enable it in each server's Local Computer Policy. Either way, set the Audit object access policy under Local Computer PolicyComputer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy (in Group Policy Editor—GPE) to a Security Setting of Success.

To enable auditing on a folder, open the folder's properties dialog box, select the Security tab, click Advanced, and select the Auditing tab of the Advanced Security Settings window. Be careful which permissions you enable for auditing because you can easily fill up your log with access events. In your case, you want to monitor only for successful uses of the permission that lets a user change an object's ACL—the Change permissions permission. Figure 1 shows that I've enabled auditing of successful Change permissions events on the DeptFiles folder. I've also specified Everyone as the name of the audit entry because I want to audit everyone.

After you enable object access auditing at the system level and for a specific folder, you'll start seeing event ID 560 (Object open) in the Security log. Look for instances of event ID 560, such as the one in Figure 2 in which the Object Name in the description is the name of a folder on which you enabled auditing. Then look in the Accesses field for WRITE_DAC, which is the system name for Change permissions. Figure 2 shows that Fred changed permissions on C:DeptFiles.

In the Security log, you'll also see a subsequent event ID 562 (A handle to an object was closed) with the same Handle ID as in event ID 560. Event ID 562 is just the corresponding close for the open in event ID 560.

If your server is running Windows Server 2003, you'll also see event ID 567 (Object Access Attempt) in between event IDs 560 and 562. Event ID 567 is part of Windows 2003's new operation-based auditing. Operation-based auditing lets you identify permissions that a user actually exercises as opposed to permissions that a user has but doesn't use. For instance, a program might open a file for read and write access (triggering an event ID 560 that shows both read and write access) but never actually write any data to the file. Windows 2003 logs event ID 567 the first time an application actually uses each permission while the file is open. A permission change operation is atomic (i.e., the object isn't opened for delete and then deleted—it's just deleted), so there's no need to look for event ID 567—it should always be there.

—Randy Franklin Smith