The Windows Server 2003 Security Log Revealed

Windows system's audit policy determines what type of information you'll find about that system in the Security log. Each Windows system on your network has nine audit policies (Windows NT has only seven), which can be enabled or disabled:

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

An event in the Windows Security log is either type Success or type Failure. When you enable an audit policy you have the choice of enabling it for success events, failure events, or both, depending on the policy. All nine audit policies generate success events but only some of the policies generate failure events. Don’t fall for the recommendation to enable failure events only 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 maneuver to Security Settings\Local Policies\Audit Policy, as Figure 2‑1.

Figure 2‑1 The nine audit policies in Local Security Settings

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

When you open one of the audit policies, 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. If the computer is a member of an AD domain, the computer automatically applies appropriate GPOs from the domain. Any policy defined in a GPO overrides policies defined in the system’s local policy object and becomes the effective setting.

Windows Server 2003 and Windows XP always display the effective settings when in the Local Security Settings dialog box. (If you can modify the setting, the policy isn’t defined in any applicable GPOs defined in AD.) Windows 2000's Local Security Policy console puts the system’s local setting from effective setting in separate columns.

I recommend that you use the Local Security Policy console only for viewing a system’s audit policy—not for configuring it. As with all security settings, the best practice is to use Group Policy to centrally manage your audit policy.

Versions earlier than Windows 2003 disable all nine audit policies by default. Windows 2003 enables a few categories by default but the options selected make no sense from a security standpoint. Use Group Policy to push out the audit policy you want rather than relying on default settings.
Let’s drill down just a bit into each of the audit policies.

Audit Account Logon Events

Microsoft should have named the Audit account logon events policy Audit authentication events. On DCs, the policy tracks all attempts to log on with a domain user account, regardless of where the attempt originates. If you enable this policy on a workstation or member server, it will record any attempts to log on by using a local account stored in that computer’s SAM.

Audit Logon Events

The Audit logon events policy records all attempts to log on to the local computer, whether by using 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.) To track all domain account authentication, you should use Audit account logon events.

Audit Account Management Events

The Audit account management events 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. On DCs, the policy logs changes to domain users, domain groups, and computer accounts. On member servers, it logs changes to local users and groups.

Audit Directory Service Access

The Audit directory service access policy provides a low-level audit trail of changes to objects in AD. The policy tracks the same activity as Audit account management events, but at a much lower level. By using this policy, you can identify exactly which fields of a user account or any other AD object were accessed. Audit account management events provides better information for monitoring maintenance to user accounts and groups,  but Audit directory service access is the only way to track changes to OUs and GPOs, which can be important for change-control purposes.

Audit Object Access

The Audit object access policy handles auditing access to all objects outside AD. The first use you might think of for the policy is file and folder auditing, but you can use it 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 you want to track. To configure an object’s audit policy, open the object's Properties, select the Security tab, click Advanced, and then select the Auditing tab, which Figure 2‑2  shows. Be warned: This policy can really bog down your server if you enable it on too many objects.

Figure 2‑2 Audit policy for a folder

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

Audit Policy Change

The Audit policy change policy provides notification of changes to important security policies on the local system, such as changes to the system’s audit policy or, when the local system is a DC, changes to trust relationships.

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 you find in the Local Security Policy under Security Settings\Local Policies\User Right Assignment. This category generates a lot of noise and I usually recommend leaving it disabled.

Audit Process Tracking

The Audit process tracking policy tracks each program that is executed, either by 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 and thereby paint a detailed picture of a user’s activities.

Audit system events

The Audit system events policy logs several miscellaneous security events.

Event Viewer

The preceding 9 audit policies allow you to fire up the Windows auditing function.  Once 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, which Figure 2‑3shows. 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. To view another computer's logs, right-click the root in the details pane and select Connect to another computer. You will need to have the manage auditing and security log and access this computer from the network user rights on the target system.
Event Viewer shows only basic information about each event. You usually need to open an event’s Properties, as Figure 2‑4 shows, to see the whole story. Each event has a number of standard fields (I call them header fields) and a description field.
The header fields tell you the event ID, the date and time the event occurred, whether the event is a Success or Failure, and the event’s source and category. All events in the Security log list the source as Security, so the Source field is pretty useless. Security events fall into nine categories, which correspond to the nine audit policies, as Figure 2‑5 shows. The Category field specifies the category into which the event falls. The User field isn't usually of much value because so many events simply list SYSTEM as the user. This is especially true of events in the Logon/Logoff and Account Logon categories.

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

Figure 2‑3 Event Viewer

Figure 2‑4 Event Properties

Figure 2‑5 Audit policies and corresponding categories

You’ll find the real details about an event in the Description field. When you view an event’s description you are actually seeing two types of information that have been merged. Each event ID has a static description that contains defined placeholders into which dynamic strings of information connected with a particular instance of the event aremerged. The easiest way to explain the static and dynamic elements of an event description is with an example. Figure 2‑6 illustrates the merger of static and dynamic information for an instance of event ID 529.

Figure 2‑6 Event description

It’s important that you understand how event descriptions work because this is where the important details about the event reside. In the case of event ID 529, you need to look at string 1 to determine the name of the user who failed to log on. String 3 tells you the type of logon  that was attempted (a network logon in this example). These dynamic strings are also important when you have a Security log–management solution or are trying to analyze the log by using a utility such as Microsoft LogParser. Many of the typical alerts that you can define by using Security log–management solutions require criteria 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 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 it provides the flexibility to create alert criteria and reports that are based on specific string numbers within the description.

Event Viewer provides basic filtering and search capabilities. To filter the displayed events, right-click Security in the details pane, select View, then select Filter to open the dialog box that Figure 2‑7 shows. In this example, I’ve selected Security as the event source and Account Management as the category. (You must specify the source before you can select a category.) I’ve also filtered out Success events. If your logs are very large and filter updates are taking a long time, try further limiting the filter by specifying a From and To date and time range.

Figure 2-7 Filter criteria

The only other useful analysis feature in Event Viewer is the Find option. Right-click Security, select View, then select Find.  Figure 2‑8 shows a search for instances of event ID 590 (which identifies executed programs)  that contain “excel” in the description. These Find criteria will locate the next occurrence of Microsoft Excel being started. Unfortunately, you can’t specify precise string numbers in the Find criteria. You can look only for the occurrence of a sequence of characters. You’ll find the same limitation in many Security log–management solutions. For instance, finding all occurrences of event ID 529 with a logon type of 2 can be problematic unless you search for “Logon Type: 2”.

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

Figure 2-8 Searching 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 details pane, then select Properties to open the log's Properties dialog box, which Figure 2‑9 shows. Windows will not grow the log beyond the size you specify. I recommend that you set the Maximum log size to no larger than 199 megabytes; 200MB seems to be the point at which Windows gets a bit flakey in terms of stability and performance.

No matter what maximum size you configure, the log will eventually reach it. You can configure Windows to do one of three things at that point. I recommend that you choose the Do not overwrite events (clear the log manually) option because if you do, Windows will just stop logging events when the log reaches its maximum size. (You can actually use the CrashOnAuditFail option to configure Windows to crash if this happens, but I don’t recommend it for most commercial scenarios. See http://support.microsoft.com/kb/823659 for more details on CrashOnAuditFail.) You run a similar risk by using the Overwrite events older than X days option. If events pour in so fast that the log reaches maximum size before any events expire, Windows stops logging events until some do expire. That leaves the Overwrite events as needed option, which Iselect for nearly every project.

Note that the Security Properties dialog box also displays the log file’s location and current size, as well as various dates and times 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 517. Although event ID 517 is part of the 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.

Figure 2-9 Security log properties

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 and select Save As, you have the option to choose the format in which to save the log. If you specify event file (EVT) format, Event Viewer saves a copy of the log in the same EVT format that the live log uses. You can also specify comma-separate value (CSV) or tab-delimited (TXT) format. If you use the EVT format, you’ll need to use a tool that supports EVT files, such as LogParser. You can also use Event Viewer to view logs saved in EVT 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 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\config\SecEvent.evt, but you can change the location by editing the registry. In a registry editor, maneuver to the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\Services\Eventlog\Security subkey and set the File value to any path name on the local system. Because the File value is data type REG_EXPAND_SZ, 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 to a different volume the file I/O associated with the Security log.

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. (If you ever run into a truly corrupt event log,  http://support.microsoft.com/kb/172156/ explains how to fix the problem.) The only time I’ve encountered a corrupt Security log was when a rogue administrator tampered with the log. This brings us to the subject of 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 applied to the system. The only shrink-wrapped tool that you can use to selectively delete events from the Security log is WinZapper, written by Peter Nordahl and found at http://www.ntsecurity.nu/toolbox/winzapper/. (For more information about WinZapper, see my article “Avoiding WinZapper's Sting” at http://www.windowsitpro.com/Article/ArticleID/15674/15674.html.) 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 out reach (both physically and logically) of the local server’s administrator and other operations staff. Security-monitoring staff then can monitor the security activity reported by the servers and review the activity of operations staff, as needed.

The Windows Server 2003 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!