KB2002.410
Problem: System Change Log reports do not include who made an account change.
This article applies to System Change Log.
Last Updated: 19 November 2010
Problem
System Change Log reports do not include who made a change to a monitored path, even though you have the Include User Information
checkbox checked on the control panel applet.
Details
By default,
Background
File/Object Success Auditing must be enabled before any user account lookups can take place. If
auditing is not enabled when a change happens, then there will be no record of the change.
(i.e., you cannot enable auditing today and hope to find out who did something yesterday.)
In order for System Change Log to determine the person responsible for making a change, it must
be able to read the Security Log on the machine where the service is running and find the relevant
audit records that correspond to a file/folder change. If the relevant Security Log entry is not
present at the time System Change Log tries to look up the responsible person
(perhaps because auditing isn't enabled or the wrong audit events are being logged), then the user
account information will be omitted from the System Change Log report.
IMPORTANT NOTE: The Security Log records the filename that was changed, and System Change Log matches this
up with the monitored path information to determine who made the change. Unfortunately, the Security Log
does not record the "real" path information for file changes on Windows 2000/XP/2003 dynamic volumes.
The only information recorded is the system internal reference information saying where on the dynamic
volume the file resides. There is currently no way to match this with a drive letter and path after the
fact (the mappings allow going from drive letter and path to virtual location, but not backward). Therefore,
System Change Log will never be able to provide "whodunnit" information for changes to file residing on
dynamic drives. "Real" drives on your system (that is, hard disks with drive letters associated with them)
can be monitored just fine.
Solutions
Enable Success auditing for the type of File/Object activity that corresponds to the type of changes
you have set System Change Log to monitor. For example, if you have set System Change Log to monitor
file deletions in a particular folder, set the
To test that auditing is functioning properly, make some changes to a file in a folder for which auditing is
enabled and then use Event Viewer to inspect the Security log and look for records with an Event code of 560
(Category Object Access, Source Security, etc.). At least one of the 560 entries should include the
name of the file which was modified and the action taken.
If you cannot find 560 audit records relating to the file change, then you have not successfully enabled auditing.
You should double-check to be sure you have:
- Enabled overall success auditing for Object Access using the Local Security Policy MMC snap-in found in Administrative Tools
(called File and Object Access and found in User Manager in NT4)
- Selected the correct auditing events to record for a specific folder using Explorer/My Computer (or File Manager in NT4)
- Disabled the Inherit from parent... option in the Advanced Security Settings for the folder unless you
understand how auditing settings filter down from higher-level folders.
Here is a sample showing something similar to what you should see if auditing is enabled
correctly:

Event Viewer Security Log

Detail Record from Security Log
|
|