Per-User Auditing

Reducing the Noise
Configuring per-user auditing reminds me a little of configuring software restriction policies. You first have to define an overall strategy, then you make the exceptions to the global policy.

Per-user auditing can be useful in removing the noise from your current audit logs. Most administrators combing their managed log files have wished they could stop some repetitive event, such as events generated by the account of a service (e.g., tape backup, antivirus, management tool) that runs continuously or frequently and creates useless log noise.

The process of auditing itself can be your enemy in generating noise. As a security measure, I have the Detailed Tracking (i.e., process tracking) and Object Access audit categories enabled to catch any malicious hacker actions. Although you might have been taught that enabling Detailed Tracking always results in too much event log noise, this isn't usually the case on dedicated domain controllers (DCs), which typically don't stop and start a lot of programs and processes during their normal duties after they're up and running. However, I frequently use Remote Desktop to check the log files of DCs. In gross violation of the Star Trek Prime Directive, the very act of me logging on remotely and opening the event log generates events. Refreshing the event log screen creates two event messages. Now that per-user auditing is available in Windows 2003 SP1, I can use a simple batch file at logon to limit the messages related directly to me and my remote monitoring activities.

Per-user auditing can be used to improve security. For instance, on most of the Windows machines under my control, I rename the Administrator and Guest accounts. I then create two bogus accounts, heavily restricted and with long, complex passwords, that I put in their place. I give them the names Administrator and Guest and even copy the default descriptions of the original accounts. I've always wanted a way to be alerted if an intruder attempts to use the bogus accounts. Per-user auditing can report any events involving the two bogus accounts to the event log and not report the same events for all accounts.

It might be a good idea to always export your per-user-auditing settings to a file for documentation, change management, and rebuilding purposes. In a troubleshooting scenario, you might need to disable per-user auditing to rule out its impact on a problem. You can export the settings, clear them, continue troubleshooting, then import the settings when you're done troubleshooting.

When you change per-user-auditing settings, the changes are recorded by event ID 806 (Per User Audit Policy was refreshed), which Figure 2 shows, and event ID 807 (Per user auditing policy set for user), which Figure 3 shows. Event ID 806 isn't all that helpful, but its appearance can alert you to the fact that per-user auditing is enabled or that its settings are being changed. Event ID 807 at least reveals which user is involved. Unfortunately, the audit categories shown in event ID 807's Description section aren't the categories modified.

Incidentally, malicious hackers might not yet be aware of per-user auditing and thus probably aren't checking for it. Per-user auditing settings are maintained in a different place from other auditing settings, so if hackers check audit settings manually or by using an automated command-line tool that reveals enabled audit policy, they won't have a complete picture of your auditing settings. Of course, hacker tools will eventually be upgraded to account for per-user auditing, but use this edge while you can.

Caveats
Although per-user auditing answers an auditing need, it isn't perfect. Because Auditusr resides in the System32 folder, to which authenticated users typically have Read and Execute permissions, nearly any user can execute and reveal the current per-user-auditing settings for any defined user. Typical end users can't change the settings, but listing which security principals aren't tracked for which audit categories might help an already-logged-on intruder in his or her exploration attempts.

Also, don't expect per-user auditing to include or exclude all event messages concerning a user. Per-user auditing filters only messages that have the predefined security principal's name in the message's User field. Many event messages specify another User but mention the predefined security principal in the message Description. For instance, event ID 682 records a user's successful logon to a Winstation session. The User on the event is usually the System account, and the filtered-out user's name is in the event log message Description. In addition, although per-user auditing adds even more granularity to an already granular system, you can't use it to stop just one type of event log message for a security principal—it's still all or nothing for an audit category.

Last, per-user auditing seems to cause some interesting interactions (bugs?) between the different audit categories. For instance, when I globally disabled the Logon/Logoff category but used per-user auditing to enable an administrative user, some of that user's Privilege Use actions were also logged. When I disabled Logon/Logoff for the administrative user, the event log didn't pick up the Privilege Use audit messages either. I suspect this cross-over has to do with the way that different audit categories track usage. The lesson here is that you should test per-user auditing thoroughly before you count on it.

Per-user auditing is an interesting feature with specific applications, but you should use caution anytime you alter the legitimate logging or auditing trail. For instance, you might want to remove a tape backup service account from appearing in the audit logs as it goes about its nightly duties. A per-user audit filter might remove the tape backup's presence from the event logs and reduce the noise, but it might also hide the actions of a malicious hacker who uses the service account to conduct his or her rogue actions. Furthermore, if you don't appropriately protect and manage per-user auditing, malicious intruders could use it many other ways to prevent their actions from being monitored. Fine-tuning your audit policy means appropriately balancing capturing what's important against the noise of too many events. Unaudited events can be used against your environment.

Some administrators will prefer to capture all auditing events and filter the noise out of the log after the fact. This approach ensures a reliable audit path that you can reconstruct if the need arises. You can use the filtering provided by the Event Viewer application, any of Microsoft's event-log monitoring tools (e.g., Microsoft Systems Management Server—SMS, Microsoft Operations Manager—MOM, EventCombMT, Microsoft Audit Collection System—MACS), or one of dozens of third-party log monitors.

Per-user auditing provides another tool in the already powerful Windows logging arsenal. If you use it appropriately, event logs will have reduced noise and contain more relevant events.