The Windows Server 2008 Security Log Revealed

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 Vista® and Windows Server 2008 use nine policy categories; these operating systems also introduced policy 50 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 subcategy policies under that policy will be defined. I 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 Catergories

Each Windows 2008 or Windows Vista 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 only the nine categories and no subcategories.) Look at the Local Security Policy. You will see 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 2008 Security log has a Keyword for either Audit Success or Audit Failure. When you enable an audit policy, you can enable it to log Success events, Failure events, or both, depending on the policy. All nine audit policy categories generate Success events but only some categories 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 are Success events such as changes to critical user accounts and groups, account lockouts, and changes to security settings.

To view a system's audit policy settings, you can open the Local Security Policy console on the computer and drill down to Security Settings\Local Policies\Audit Policy (Figure 2-1).

Figure 2-1. Audit Policy settings can record Success or Failure events (or both)

This book is part of the
Security Log Resource Kit.

Buy it now!

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 that Fig 2-1 shows, 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 Server 2008 always displays the effective settings in the Local Security Settings dialog box. (If you can modify a setting, then you know that the policy hasn't been defined in any applicable GPOs that have been defined in AD.) However, I 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 the policy's Local Security Setting tab (Fig 2-2).

Figure 2-2. Audit process tracking policy is set for Success and Failure

Audit Policy Subcatergories

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

There's a catch, though. Microsoft doesn't provide subcategory settings in Group Policy. (We can't believe it either!) You can set subcategories only by using a command-line program called Auditpol (Figure 2-3). Auditpol cannot be run on a remote computer. To set the policy on all systems you would need to run a script using that uses this tool.

You can also use this tool 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. Figure 2-3 shows an example of what you will see when you use the auditpol /get /category:* command.

Figure 2-3. Use the Auditpol command-line tool to review subcategory settings

As we mentioned earlier, by default any subcategory settings will take effect only if the top-level policy is undefined. However, this behavior can be reversed by the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings security option (Fig 2-4).

Figure 2-4. You can force audit policy subcategories to override category settings

Note that the default installation of this option is actually “Not defined” rather than “Disabled,” as the Explain tab will say if you open that. We strongly recommend that you choose enabled or disabled for consistent auditing across your enterprise. If this option setting is enabled and you have set a policy subcategory, then the policy for each category will not override it. The subcategory setting will take over on Windows Vista and Windows Server 2008 systems. (Because subcategories cannot be set on Windows versions earlier than Windows Vista or Windows Server 2008, only policy categories will be effective on legacy systems.) If this option setting 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 have numerous effects on your audit policy (Figure 2-5).

Audit policy category

Subcategory set through Auditpol?

Force audit policy subcategory…setting





The category setting is ignored; the subcategory setting takes precedence




All subcategories for this policy are enabled by default




The subcategory setting is ignored; the category setting takes precedence




The subcategory setting is ignored; the category setting takes precedence

Enabled for Success Only



Success only auditing occurs

Enabled for Success Only



Success only auditing occurs

Enabled for Success Only



The category setting is ignored; the subcategory setting takes precedence

Enabled for Success Only



Subcategory policy auditing occurs

Not Defined



No auditing occurs

Not Defined



Subcategory policy auditing occurs

Not Defined



No auditing occurs

Not Defined



Subcategory policy auditing occurs

Figure 2-5. Effective audit policy is determined by several settings

If you enable both category and subcategory settings, you can end up with 150 different auditing result combinations (50 subcategories times 3 category settings—Success, Failure, or no auditing). So don’t rely on the Local Security or GPMC alone to determine what is getting audited. The Auditpol command will tell exactly what's happening. Just make sure Group Policy has already been applied when you use Auditpol (it may take a while for Group Policy to replicate and 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 categories one by one. Later, we'll delve into the granular subcategories.

Audit Account Logon Events

Microsoft should have named the Audit account logon events policy category Audit authentication events. On DCs, this policy tracks all attempts to log on with a domain user account, regardless of where the attempt originates. On a workstation or member server, the policy records any logon attempts that use 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 category and its subcategories in detail in Chapter 4.

Logon Events

This audit policy actually controls the Logon/Logoff audit category. (see figure 2-3)The main objective of the Audit logon events policy is to record all attempts to log on to or log off of the local computer by using either a domain account or a local account. On DCs, this policy records attempts to access the DC only. The policy does not, for instance, 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.) Still, in such an instance a network logon event (4624) will appear in the DC's security log because the workstation must log on to the DC as the user to apply Group Policy for that user. But to track all domain account authentication, you should use Audit account logon events.

The Audit logon events 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 category and its subcategories in detail in Chapter 5.

Audit Account Management Events

The Audit account management events policy category, 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 policy's subcategories, Other Account Management Events, logs changes to 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 category and its sub-categories in detail in Chapter 8.

Audit Directory Service Access

The primary purpose of the Audit directory service access policy category 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 Audit account management events, but at a much lower level. The information that Audit account management events provides is better for monitoring maintenance of user accounts and groups, but using Audit directory service access 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 category and its subcategories in detail in Chapter 9.

Audit Object Access

The Audit object access policy category 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, auditing access to an object such as a crucial file requires you to enable more than just this category; 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.
  • 2. Select the Security tab.
  • 3. Click Advanced.
  • 4. Select the Auditing tab (Figure 2-6).

Figure 2-6. Configure a file's audit policy to enable object access auditing

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

Warning: If you enable it on too many objects, this policy category can bog down your server.

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 category and its subcategories in detail in Chapter 7.

Audit Policy Change

The primary purpose of the Audit policy change category (which includes a subcategory of the same name) 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:

  • 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 category and its subcategories in detail in Chapter 11.

Audit Privilege Use

The Audit privilege use category 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 category generates a lot of noise; I 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 category and its subcategories in detail in Chapter 10.

Audit Process Tracking

The Audit process tracking category'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, Audit logon events, and Audit object access events together by using the Logon ID, Process ID, and Handle ID fields within the 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 category and its subcategories in detail in Chapter 6.

Audit system events

The Audit system events category logs several miscellaneous security events.

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 (Figure 2-7). The MMC has been redesigned for Windows Server 2008 and is a big improvement over the Windows Server 2003 MMC. 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.

Figure 2-7. Use Event Viewer in Windows Server 2008 to view security events

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 (Figure 2-8).

Figure 2-8. View an event's Properties for additional information

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 having 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 (Figure 2-9) or you can see the data in XML format (Figure 2-10).

Figure 2-9. View event details in a "friendly" manner

Figure 2-10. View event properties in XML format

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. Figure 2-11 shows all the information for an instance of event ID 4624. (This is the output 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.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/13/2008 3:43:27 PM
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
User: N/A
An account was successfully logged on.

            Security ID:                    S-1-0-0
            Account Name:               -
            Account Domain:            -
            Logon ID:                       0x0

Logon Type:                               3

New Logon:
            Security ID:                    S-1-5-18
            Account Name:               LAB2008$
            Account Domain:            ACME
            Logon ID:                       0xddff1
            Logon GUID:                  {f78082ae-69a7-e484-9a7a-1d73a19191c1}

Process Information:
            Process ID:                     0x0
            Process Name:                -

Network Information:
            Workstation Name:        
            Source Network Address:            fe80::8593:751d:52bf:5ea0
            Source Port:                   60777

Detailed Authentication Information:
            Logon Process:               Kerberos
            Authentication Package:   Kerberos
            Transited Services:          -
            Package Name (NTLM only):       -
            Key Length:                    0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Event Xml:
<Event xmlns="">
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<TimeCreated SystemTime="2008-10-13T19:43:27.484Z" />
<Correlation />
<Execution ProcessID="576" ThreadID="664" />
<Security />
<Data Name="SubjectUserSid">S-1-0-0</Data>
<Data Name="SubjectUserName">-</Data>
<Data Name="SubjectDomainName">-</Data>
<Data Name="SubjectLogonId">0x0</Data>
<Data Name="TargetUserSid">S-1-5-18</Data>
<Data Name="TargetUserName">LAB2008$</Data>
<Data Name="TargetDomainName">ACME</Data>
<Data Name="TargetLogonId">0xddff1</Data>
<Data Name="LogonType">3</Data>
<Data Name="LogonProcessName">Kerberos</Data>
<Data Name="AuthenticationPackageName">Kerberos</Data>
<Data Name="WorkstationName"> </Data>
<Data Name="LogonGuid">{F78082AE-69A7-E484-9A7A-1D73A19191C1}</Data>
<Data Name="TransmittedServices">-</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x0</Data>
<Data Name="ProcessName">-</Data>
<Data Name="IpAddress">fe80::8593:751d:52bf:5ea0</Data>
<Data Name="IpPort">60777</Data>

Figure 2-11. Use the Copy button to combine both views on the clipboard

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

Randy's Security Log Encyclopedia: For developers:

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 is 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 (Figure 2-12). In the action pane on the right of Event Viewer (Figure 2-13), 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.

Figure 2-12. The Event Viewer filter is much improved

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 (Figure 2-13), 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 (Figure 2-13). If the filter or Find functions are slow, try limiting the time period specified in the Logged drop-down box, to reduce the number of events that must be processed.

Figure 2-13 Use the Event Viewer's Find option to correlate events

Attach Task

The ability to attach a task to an event is a handy feature in Windows Vista and Windows Server 2008. 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 (Figure 2-14).

Figure 2-14. Change the log size in the Security Log Properties dialog box

Windows will not grow the log beyond the size you specify. I recommend that you set the Maximum log size to no larger than 299 megabytes (306,176 KB); 300MB seems to be the point at which Windows Server 2008 stability and performance becomes a bit flakey.

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, I don't recommend this approach for most commercial scenarios. See 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, however attention will need to be given to it periodically so that the logs don't fill the storage location to capacity.

That leaves the Overwrite events as needed (oldest events first) option, which I 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 my monthly Security log webinars, which you can find at

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. When you right-click Security in the left pane and select Save As, you can 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 about editing the registry and encourages you to backup 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.


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 Wecutil program. Subscriptions can also be set up in Event Viewer.

A Powerful New Utility: Wevtutil

Microsoft introduced Wevtutil in Windows Vista and 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.


The Windows Server 2008 Security Log Revealed is only available as part of the Security Log Resource Kit.

Pick the edition that's right for you!


This book is part of the Security Log Resource Kit. Buy it now!