Using Audit Policies to Track Activities Performed by Specific Users

Our developers don't have update access to production data, files, and code, but they occasionally need to be able to make an off-hours emergency change to production code. To allow such changes, we have a process whereby Operations controls how and when a developer can obtain a username and password that has Administrator organizational unit (OU) access. After a developer obtains the credentials, logs on, corrects the problem, and logs off, Operations changes the password.
However, I want to see exactly when the developer logged on and off and any activities he or she performed (e.g., browsing payroll files, updating code unrelated to the problem, changing configuration settings). Is there a Windows 2000 Active Directory (AD) configuration or setting I can use to capture, trace, track, and audit all activity performed by a specific user ID?

With regard to changing policy or configuration items, you need to enable the Audit account management, Audit policy change, and Audit system events auditing categories. To track a username's logon session, enable the Audit account logon events category. These four policies audit all usernames and provide crucial audit trail information, so I recommend enabling them on all systems.

The one audit policy for which you can and should limit logging is Audit object access, which lets you track changes to the registry and file system. When you enable Audit object access, Windows won't log all access events on all objects because that would quickly fill up a log.

After you've enabled object auditing at the system level, you must enable auditing for the objects, users, and types of access you want to track. In Windows Explorer, right-click the root of the volume (e.g., C:\) and select Properties. Select the Security tab, click Advanced, and select the Auditing tab. Click Add, enter the username you want to audit—for example, EMERGFIX—then click OK. Next, select the permissions you want to audit. In your case, I'd recommend enabling auditing at the root of each volume on the server for Write Data, Append Data, Write Attributes, Write Extended Attributes, Delete, Change Permissions, and Take Ownership.

The Audit object access policy will record all changes made to files on the system by EMERGFIX, but won't fill up the log with events generated by other users. Windows will begin auditing all files or folders modified by EMERGFIX and generate instances of event IDs 560 (Object Open), 564 (Object Deleted), and 567 (Object Access Attempt), which describe the objects and types of access exercised.

You can also enable auditing for ReadData to monitor the files viewed by EMERGFIX, but doing so might generate a glut of events if EMERGFIX runs a program that looks at many files. Instead, you might want to identify sensitive folders and enable Read-Data auditing on only those folders.

To audit changes made to the registry, open regedt32, right-click HKEY _LOCAL_MACHINE, and select Permissions. Then, follow the process described above for adding an audit entry for EMERGFIX, but this time enable auditing for Set Value, Create Subkey, Write Owner, and Write DAC. Using this audit policy, you'll catch all changes EMERGFIX makes to HKEY _LOCAL_MACHINE. Don't include any of the other registry hives; they're either shortcuts to keys under HKEY _LOCAL_MACHINE or apply to only the current user's profile and have little effect on security.

End of Article