SQL Server Magazine

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_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Audit\PerUserAuditing), 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:

• the audit categories that are already enabled locally
• the security principal accounts that you want to change
• whether you want to include security principals in or exclude them from the categories

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 /<command>
 <securityprincipalname>:<auditcategory>

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 <securityprincipalname>

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.

   Prev. page   [1] 2     next page