Per-User Auditing - 28 Jun 2005

The comprehensiveness of Windows auditing can be a double-edged sword: Noncritical messages (i.e., noise) often overwhelm the messages that truly require attention. We can't blame Microsoft for most of the auditing noise. The highly prized Common Criteria security evaluation standard (http://www.commoncriteriaportal.org) requires that OSs be able to audit any action that occurs, and administrators everywhere would yell if the audit log missed a single event that's important to them. Of course, you don't have to capture every event. You can minimize the amount of noise by fine-tuning the audit policy for your environment's particular needs. Windows' new per-user auditing can aid with that task.

Fine-Tuning Audit Policy
Fine-tuning your audit policy involves enabling only the success and failure of needed audit categories and objects. In Windows 2000 and later, the audit policy categories are:

But in Win2K, with the notable exceptions of the Object Access category (which can monitor access or attempted access to specific files, folders, printers, and registry keys) and the Directory Service Access category, auditing reports on the activity of all involved security principals (e.g., users, groups, computers, service accounts). Although you might want to report only on users who try to do something they aren't authorized to do, say adding other users to a privileged group, Win2K auditing also reports when authorized users perform allowed actions. Aside from Object Access and a few other exceptions, auditing is all or nothing.

But what if you want to audit just some users and not others? To address this problem, and to meet additional Common Criteria expectations, Microsoft introduced per-user auditing in Windows XP Service Pack 2 (SP2) and included it in Windows Server 2003 SP1. Per-user auditing provides a way to include or exclude event categories on a per-security-principal basis. You can prevent event log messages from being written for certain users and report on only certain users. For example, you can report on all write attempts to Windows system files for all security principals, except for your antivirus product's service account and the System account. Or you can disable Logon/Logoff auditing globally for all users but selectively record accesses by the Administrator. Yes, you read that right: You can disable global auditing and still record security events for particular users. (Note: In this article, global auditing refers to the effective audit policy settings you've established through Group Policy or Local Computer Policy.)

Per-user auditing can be set per user or computer account but not per group. For obvious reasons, you can't exclude members of the Administrators group or the System account from being included in auditing (if the auditing category is globally enabled), but you can include them in an audit category even when everyone else is excluded. Actually, you can add those two security principals to the per-user auditing configuration database (stored in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaAuditPerUserAuditing), but the settings will be ignored.

Using Auditusr
You can view, modify, and delete per-user auditing settings by using auditusr.exe (located in %windows%system32). To list current per-user auditing settings, type

auditusr

at the command line, as Figure 1 shows.

Before you begin to set new per-user policies, you must know three pieces of information:

You then use Auditusr to create exceptions to your global auditing. The syntax for including or excluding users on a per-category basis is:

auditusr / :

Table 1 shows the four include and exclude commands. If you don't preface security principal names with the domain or workgroup name, Auditusr will attempt to find a local user first, then look for a domain account. You can specify domain names by using NetBIOS names or Fully Qualified Domain Names (FQDNs), which are converted to short names when displayed.

You spell out the full audit category names. Category names that contain spaces, such as Privilege Use, need to be enclosed in double quotes (i.e., "Privilege Use") but aren't case-sensitive. Microsoft says that you can specify consecutive audit categories by including a semicolon between categories, but I couldn't set multiple categories at once in my testing.

Here are a couple examples of Auditusr commands setting inclusion and exclusion of audit categories for a user:

auditusr /if joeuser:Logon/Logoff

auditusr /es joeuser:"Privilege Use"

Unfortunately, as I write this article, Microsoft has little documentation available about the Auditusr tool, so I couldn't verify syntax and expected outcomes.

As Figure 1 shows, Auditusr lists each include-success, include-failure, exclude-success, and exclude-failure category for each user on a separate line. You can clear all per-user settings with the following command:

auditusr /ra

or clear just a particular security principal's involvement with the command

auditusr /r 

Auditusr also has command-line switches (/i and /e) that enable importing and exporting of file lists to automate the process of selective auditing. For Auditusr's complete syntax, type

auditusr /?

at a command prompt.

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.