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.