Chapter 2
Audit Policies and Event Viewer

A Windows system's audit policy determines which type of information about the system you'll find in the Security log. Windows uses nine audit policy categories and 50 audit policy subcategories to give you more-granular control over which information is logged.

By default, if you define a value for a policy in one of the top-level categories—either in the computer's Local Security Policy or in an applicable GPO—then that top-level policy will usually override any configurations that you make at the subcategory level. Under Windows’ default behavior, subcategory policies take effect only when you leave the related top-level category undefined in the Local Security Policy and in all applicable GPOs. If a category policy is defined, then all subcategory policies under that policy will be defined. We stress usually and default behavior because the new Group Policy Object Editor (GPE) Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings setting (under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options) reverses that behavior. If you enable this setting, then your subcategory configurations will override how the applied Group Policy sets the top-level policies.

Audit Policy Categories

Each Windows system on your network has nine audit policy categories and 50 policy subcategories, which you can enable or disable. (Windows NT has only seven categories; Windows 2003 has nine categories but no subcategories.) Look at the Local Security Policy. You will see policy settings for only the main categories:

• Audit account logon events
• Audit logon events
• Audit account management
• Audit directory service access
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events

An event in the Windows Security log has a keyword for either Audit Success or Audit Failure. When you enable an audit policy (each of which corresponds to a top-level audit category), you can enable the policy to log Success events, Failure events, or both, depending on the policy. All nine audit policies generate Success events, but only some policies generate Failure events.

Don’t fall for the recommendation to enable only Failure events for each category. A common misconception is that a Failure-only audit policy will alert you to all suspicious events. In reality, many of the most important events in the Security log—events such as changes to critical user accounts and groups, account lockouts, and changes to security settings—are Success events.

To view a system’s audit policy settings, you can open the MMC Local Security Policy console on the system and drill down to Security Settings\Local Policies\Audit Policy as shown below.

When you open an audit policy, you may or may not be able to modify it, depending on whether the policy has been defined in a GPO that has been applied to the local system. In the example below, only Audit process tracking can be changed. The other policies have been set by a group policy. If the computer is a member of an AD domain, then the computer automatically applies appropriate GPOs from the domain. Any policy that is defined in a GPO overrides policies that are defined in the system’s Local Security Policy object and becomes the effective setting.

Windows always displays the effective settings in the MMC Local Security Policy console. (If you can modify a setting, then you know that the policy hasn’t been defined in any applicable GPOs that are defined in AD. When set by Group Policy, a scroll icon appears next to the setting.) We recommend that you use the Local Security Policy console only to view a system’s audit policy—not to configure it.

As with all security settings, the best practice is to use Group Policy to centrally manage your audit policy. Using local settings can be risky: A group policy could override the local policy settings. Microsoft warns you of this behavior on each policy’s Local Security Setting tab shown below.

Audit Policy Subcategories

What about subcategory settings? The big advantage of using subcategories is the ability to limit the number of events that result from the related category, thus reducing (though not eliminating) unnecessary noise.

You can control these policies in Group Policy under Advanced Audit Policy Configuration.

You can also use Auditpol to determine which subcategories are being audited. If you are performing a baseline of a system, Auditpol gives you the ability to see what is really happening. Take a look at an example of what you will see when you use the auditpol /get /category:* command.

But by default, subcategory settings will take effect only if the top-level policy is undefined. However, you can reverse this behavior by enabling the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings security option as shown below.

Note that the default installation of this option is actually Not defined rather than Disabled, as the option’s Explain tab states. We strongly recommend that you set this option to be either Enabled or Disabled, for consistent auditing across your enterprise. If this option is enabled and you set a policy subcategory, then no category policy will override it. The subcategory setting will take over on Windows systems. (Subcategories cannot be set on earlier Windows versions, so only policy categories are effective on legacy systems.) If this option is enabled but you haven’t specifically configured any subcategory settings for a policy, those subcategories will follow the main category policy. This complex hierarchy of setting priorities can yield unintended results.

Don’t rely on the Local Security Policy console or GPMC alone to determine what is being audited. The Auditpol command will tell you exactly what’s happening. Just make sure that Group Policy has already been applied when you use Auditpol. (Group Policy might take some time to replicate and to be applied after a change).

Top-Level Auditing

For the moment, let’s suppose that you have disabled the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings option, and let’s examine the nine top-level audit policy settings one by one. We’ll delve into the granular subcategory settings later.

Audit Account Logon Events

Microsoft should have named the Audit account logon events policy Audit authentication events. On DCs, this policy tracks all attempts to log on with a domain user account, regardless of the attempt’s origination. On a workstation or member server, the policy records any logon attempt that uses a local account that is stored in the computer’s Security Account Manager (SAM).

The policy has four subcategories:

• Credential Validation
• Kerberos Authentication Service
• Kerberos Service Ticket Operations
• Other Account Logon Events

We’ll discuss this policy and its subcategories in detail in Chapter 4.

Audit Logon Events

The Audit logon events audit policy actually controls the Logon/Logoff category. The policy’s main objective is to record all attempts to use either a domain account or a local account to log on to or off of the local computer. On DCs, this policy records attempts to access the DC only. The policy does not, for example, track a user who uses a domain account to log on at a workstation. (In that case, the user isn’t logging on to the DC; the DC is simply authenticating the user.) In such an instance, a network logon event (event ID 4624) would appear in the DC’s Security log because to apply Group Policy for the user, the workstation must log on as the user to the DC. But to track all domain account authentication, you should use the Audit account logon events policy.

The policy has nine subcategories:

• Logon
• Logoff
• Account Lockout
• IPsec Main Mode
• IPsec Quick Mode
• IPsec Extended Mode
• Special Logon
• Other Logon/Logoff Events
• Network Policy Server

As you can see, some of these subcategories have nothing to do with logons or logoffs. We’ll discuss this policy and its subcategories in detail in Chapter 5.

Audit Process Tracking

The Audit process tracking policy records events in the Detailed Tracking category. This policy’s primary purpose is to track each program that is executed by either the system or by end users. You can even determine how long the program was open. You can tie this policy, the Audit logon events policy, and Audit object access policy together by using the Logon ID, Process ID, and Handle ID fields within various event descriptions, thereby painting a detailed picture of a user’s activities.

The policy has four subcategories:

• Process Creation
• Process Termination
• DPAPI Activity
• RPC Events

We’ll discuss this policy and its subcategories in detail in Chapter 6.

Audit Object Access

The Audit object access policy handles auditing access to all objects that reside outside of AD. The first use you might think of for this policy is file and folder auditing. You can also use the policy to audit access to any type of Windows object, including registry keys, printers, and services.

Furthermore, to audit access to an object such as a crucial file, you must enable more than just this policy; you must also enable auditing for the specific objects that you want to track. To configure an object’s audit policy:

1. Open the object's Properties dialog box.
2. Select the Security tab
3. Click Advanced.
4. Select the Auditing tab as shown below

However, be warned: This policy can bog down servers. Audit only crucial objects and audit only for crucial access (e.g., Write access).

The policy has 11 subcategories:

• File System
• Registry
• Kernel Object
• SAM
• Certification Services
• Application Generated
• Handle Manipulation
• File Share
• Filtering Platform Packet Drop
• Filtering Platform Connection
• Other Object Access Events

We’ll discuss this policy and its subcategories in detail in Chapter 7.

Audit Account Management

The Audit account management policy, which you can use to monitor changes to user accounts and groups, is valuable for auditing the activity of administrators and Help desk staff. This policy logs password resets, newly created accounts, and changes to group membership; one of the Account Management category’s subcategories, Other Account Management Events, logs changes to lockout and password policy. On DCs, the policy logs changes to domain users, domain groups, and computer accounts. On member servers, the policy logs changes to local users and groups.

The policy has six subcategories:

• User Account Management
• Computer Account Management
• Security Group Management
• Distribution Group Management
• Application Group Management
• Other Account Management Events

We’ll discuss this policy and its subcategories in detail in Chapter 8.

Audit Directory Service Access

The primary purpose of the Audit directory service access policy is to provide a low-level audit trail of changes to objects in AD. By using this policy, you can identify exactly which fields of a user account, or any other AD object, were accessed.

The policy tracks the same activity as does the Audit account management policy, but at a much lower level. The information that Audit account management provides is better used for monitoring the maintenance of user accounts and groups. Using the Audit directory service access policy is the only way to track changes to OUs and GPOs—an important task for change-control purposes.

The policy has four subcategories:

• Directory Service Access
• Directory Service Changes
• Directory Service Replication
• Detailed Directory Services Replication

We’ll discuss this policy and its subcategories in detail in Chapter 9.

Audit Privilege Use

The Audit privilege use policy tracks the exercise of user rights. Microsoft uses the terms privilege, right, and permission inconsistently. In this policy's case, privilege refers to the user rights that you find in the Local Security Policy (under Security Settings\Local Policies\User Right Assignment). This policy generates a lot of noise; we usually recommend that you leave it disabled.

The policy has three subcategories:

• Sensitive Privilege Use
• Non Sensitive Privilege Use
• Other Privilege Use Events

We’ll discuss this policy and its subcategories in detail in Chapter 10.

Audit Policy Change

The primary purpose of the Audit policy change policy is to notify you of changes to important security policies on the local system. Such changes include changes to the system’s audit policy or, if the local system is a DC, changes to trust relationships.

The policy has six subcategories (one of which has the same name as the top-level policy):

• Audit Policy Change
• Authentication Policy Change
• Authorization Policy Change
• MPSSVC Rule Level Policy Change
• Filtering Platform Policy Change
• Other Policy Change Events

We’ll discuss this policy and its subcategories in detail in Chapter 11.

Audit System Events

The Audit system events policy logs several miscellaneous security events. The policy has five subcategories:

• Security State Change
• Security System Extension
• Security Integrity Events
• IPsec Driver Events
• Other System Events

We’ll discuss this policy and its subcategories in detail in Chapter 12.

Using Event Viewer to View Events

The preceding audit policies allow you to fire up the Windows auditing function. But when Windows starts sending events to the Security log, you need a way to view them. The only built-in tool for accessing the Security log is the MMC Event Viewer snap-in as seen below.

By default, Event Viewer displays the local computer’s event logs, but you can easily use the console to view the logs of other computers on the network. (You must have Manage auditing and security log and Access this computer from the network user rights on the target system.) To view another computer's logs, right-click the root in the left pane, and select Connect to another computer .

On the preview pane's General tab, Event Viewer shows more information about each event; select the Details tab to see all of the information. You might also want to open the event’s Properties for a different view of the information as shown below.

You’ll see standard fields (called System fields) and a Details field in the upper scroll box of the Properties General tab. System fields in the lower section of the tab display the event ID, the date and time that the event occurred, whether the event is a Success or Failure (look in the Keywords field), the event’s source, and the event’s category (in the Task Category field).

All events in the Security log list the source as Security, with the exception of events That have to do with the logging mechanism itself (the source for those tasks is Eventlog). Security events fall into 50 task categories, which correspond to the 50 audit policy subcategories. The User field isn't typically of much value because many events simply list N/A.

Select the Details tab for a different view of the information. This is where you’ll find the valuable information about the event. You can choose a “friendly” view or you can see the data in XML format as displayed below.

When you view an event’s details, you are actually seeing two types of information that have been merged. Each event ID has a static description that contains defined placeholders; dynamic strings of information that are connected with a particular instance of the event are merged into these placeholders. Take a look at the information for an instance of event ID 4624. This is the output that you’ll see when you use the Details tab’s Copy button. The information appears twice, first in the “friendly” format and then in XML format. Note that the fields offer a combination of static information that appears in every event and dynamic information that is inserted as the event is constructed.

Microsoft attempts to explain some of these event fields, but for a much more detailed (and clear) explanation, see our wiki.

The EventData section appears toward the end of this output. You need to understand how this section works because it is in this section that the important event details reside. In the case of event ID 4624, you must look at string 6 to determine the name of the user who logged on (LAB2008$). String 9 tells you the type of logon that was attempted (type 3—a network logon). These dynamic strings are also important when you have a Security log–management solution or want to use a utility, such as Microsoft LogParser, to analyze the log. Many of the typical alerts that such solutions let you define require criteria that are based in part on one or more strings from an event's description. In most cases, filtering based on event ID alone isn't sufficient. When designing a report that is based on the Security log, you’ll often find that you need to parse one of the report columns from a string in the event’s description. If you are shopping for a Security log–management product, make sure that it provides the flexibility to create alert criteria and reports that are based on specific string numbers within the description.

Event Viewer Filter

The filter in the new Event Viewer is also a big improvement as shown in the screenshot below. In the action pane on the right of Event Viewer, click Filter current event log to access the filter. For the Security log, the only event source available is Microsoft Windows security auditing . You must choose this source in the Event sources drop-down box before you can see and choose which subcategories (called task categories in this GUI) to filter.

You can use a filtered view to save a subset of event logs for further analysis. You can save a filtered view for later use as a custom view.

Searching for Events

The Find feature provides a useful way to correlate events. In the action pane on the right of Event Viewer, click Find to access this feature. For example, you can search for a logon ID to find when a user logged on, the audited objects that the user accessed, and when the user logged off as shown below. If the filter or Find functions are slow, try limiting the time period that is specified in the Logged drop-down box to reduce the number of events that must be processed.

Attach Task

The ability to attach a task to an event is a handy feature in Windows. The simplest method is to select the desired event in Event Viewer and then click the Attach Task To This Event option in the actions pane. This action starts the Create Basic Task wizard. The wizard asks you to name the task and prompts you to define the program, email message, or display message that you want to occur when that event ID is logged. After you complete the wizard, you can view the event, its properties, and its history by opening the MMC Task Scheduler snap-in, which you can fine on the Start Menu under All Programs\Accessories\System Tools.

Often, though, you'll need to be a little more specific with your trigger criteria than simply specifying an event ID. The good news? Any criteria that you can specify in a custom view filter, including advanced XML filters, can also be specified in an event trigger. The bad news? You can't use Event Viewer to create the trigger—you must use Task Scheduler instead:

1. Open Task Scheduler
2. Click Create Task
3. On the General tab, specify the name and description of the event, as well as which account the task should execute under

Using Event Viewer to Configure the Security Log

Aside from using Event Viewer to view security events, you use it to configure the maximum size of the Security log. Right-click Security in the left pane, then select Properties to open the Log Properties dialog box shown below.

Windows will not grow the log beyond the size you specify. Nowadays you can set log sizes very large - even in gigabytes.

No matter which maximum size you configure, the log will eventually reach it. You can configure Windows to do one of three things at that point. Don’t choose the Do not overwrite events (Clear logs manually)option; if you do, Windows will just stop logging events when the log reaches its maximum size. (Although you can use the CrashOnAuditFail option to configure Windows to crash when logging stops, we don’t recommend this approach for most commercial scenarios. See http://support.microsoft.com/kb/823659 for details about CrashOnAuditFail.) The Archive the log when full, do not overwrite events option is also useful, perhaps for a small group of servers, but you will need to attend to it periodically so that the logs don’t fill the storage location to capacity. However, this feature is no substitute for a full log-management solution that moves logs to separate and secured archive.

That leaves the Overwrite events as needed (oldest events first) option, which we select for nearly every project. (This is where log-management applications come into play: You’ll need one if you want to store a large quantity of events from multiple servers. You can learn about good log-management applications during the sponsor presentations in our monthly Security log webinars, which you can find at www.ultimatewindowssecurity.com/securitylog.)

Note that the Log Properties dialog box also displays the log file’s location and current size, as well as various dates and times that are associated with the log. From this dialog box, you can also clear the log. When you clear the Security log, Windows immediately logs event ID 1102. Although this event falls under the Audit system events category, Windows always logs the event, regardless of your audit policy. When you clear the log, Event Viewer gives you the option of saving a copy first.

You can use Event Viewer to dump the Security log to a file, either in the process of clearing the log or independently. Right-click Security in the left pane and select Save As to choose the format in which to save the log. If you specify event file (EVTX) format, Event Viewer will save a copy of the log in the same EVTX format that the live log uses. If you use this format, you’ll need to use a tool that supports EVTX files, such as LogParser or the Event Viewer itself. You can also specify comma-separate value (CSV) or tab-delimited (TXT) format.

Note that when you save the Security log, Windows requires you to save it to a local volume of the server. You can subsequently copy the file elsewhere on the network, but the dump application programming interface API that Event Viewer uses can save the log only to a local volume. By default, Event Viewer stores the Security log as %systemroot%\System32\Winevt\Logs\Security.evtx, but you can change the location by editing the registry. Microsoft usually warns against editing the registry and encourages you to back up the system first. That being said, here’s the procedure:

1. Open a registry editor
2. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security subkey
3. Set the File value to any path name on the local system. (The File value is data type REG_EXPAND_SZ, so you can include environment variables in the path name.)

Why would you want to change the location of the log file? Perhaps you want to offload the file I/O that is associated with the Security log to a different volume.

Event Viewer occasionally will report that the Security log is corrupt and will refuse to display it. Usually, all you need to do to make the problem go away is close and re-open Event Viewer.

Security Log Integrity

The Security log is fairly secure. To erase events or otherwise tamper with the Security log or audit policy, you need physical access to the target system, Administrator authority to that system, or Write access to a GPO that applies to that system.

Larger IT departments should implement separation of duty between operations and security-monitoring staff. To protect the integrity of Security logs from rogue administrators, you must export events from the Security log, as frequently as possible, to a separate server that is both physically and logically out of reach of the local server’s administrator and other operations staff. Security-monitoring staff then can monitor the security activity that the servers report and can review the activity of operations staff, as needed.

Subscriptions

You can use subscriptions to forward events from another computer to a collector system. This method is no match for log-management software but can be useful if you need to watch for only a few events. Windows Event Collector and subscriptions can be set up using the Wevtutil program. Subscriptions can also be set up in Event Viewer.

A Powerful New Utility: Wevtutil

Microsoft introduced Wevtutil in Windows Server 2008. This utility allows control over nearly every aspect of the event logs. You can also use Wevtutil to reveal the event-log schema. As with many tools, Wevtutil doesn’t come with enough documentation, but don’t be afraid to dive in.

You will likely be surprised by just how many logs exist. To enumerate logs, use the wevtutil el command; to enumerate publishers, use wevtutil ep. To learn about the Security log, try this command:

wevtutil gp Microsoft-Windows-Security-Auditing /ge:true /gm:true /f:xml > junk.xml

You’ll get a ton of information about the log and every possible event. (Keep in mind that not every event works like it was designed to do.) You can also use this tool can to run queries, export logs, archive logs, modify the configuration of logging, and clear the Security log. You’ll find Wevtutil much easier to use and more powerful than the unsupported LogParser, which was needed for Windows Server 2003.

Bottom Line

To prevent a lot of unwanted noise events from being dumped into your Security log you must configure audit policy at the subcategory level.

Event Viewer is much improved compared to the version back in Windows Server 2003. You can now analyze the merged data from multiple logs in one view and take advantage of much more flexible filtering. Although Event Viewer provides new features for automatic archival and attachment of actions to events, it is no replacement for a real log-management system. Anyone with more than a few systems or the need for a high-integrity audit trail should consider the latter.