Windows 2003 Security Log

In Windows Server 2003, the Security event log has more information than ever before, but it remains a dark and mysterious corner of cryptic event IDs and codes and inaccurate documentation. And we still face the same challenges with reporting, archiving, alerting, and consolidation that we've faced since Windows NT Server. Further difficulty arises from Microsoft's penchant for changing the meanings of numerous event IDs from one version to the next. But if you have the right tools and know what to look for, you can glean a wealth of information from the Security log.

In this first article of several planned on the Windows 2003 Security log, I'll provide an overview of audit policy and the Security log for newbies. Experienced Security log sleuths should look for the "New in Windows 2003" subheading for each Security log category to get an overview of the major changes that Windows 2003 brings to the Security log. Windows divides all security events into nine audit categories, as you can see in Figure 1 which shows the Filter tab of the Event Viewer's Security Properties dialog box. In future articles, I'll examine the categories of the Security log in more detail and show you how to get the most from this important resource.

Event Viewer
You view the Security log with the Microsoft Management Console (MMC) Event Viewer snap-in. All event IDs share some standard fields, and each event ID has a unique description. The standard fields are event ID, date, time, username, computer name, source, category, and type. For many event IDs, the Windows security architecture renders the username field not useful and you must look at the user-related fields in the event description. The computer name always corresponds to the local computer—it's useful only when you consolidate logs from multiple systems into one database. The source field is intended to tell you what part of the system or application reported the event, but all events in the Security log have Security as the source. The category field corresponds to the nine audit categories, and the type is always Success Audit or Failure Audit, which allows you to separate events such as successful logons from failed ones. The description is a combination of static text in your language and a variable list of dynamic strings inserted into the static text at predefined positions. The description strings contain the most valuable information in many events, and tools are available that can help you parse and report on these details. (The Learning Path box lists a series of articles that covers LogParser, a free tool from Microsoft that lets you use SQL Select commands to query the Security log.)

Event Viewer has some search and filter capabilities, but they're pretty limited. With Event Viewer, you can also archive and/or clear a Security log. When you archive a log (by right-clicking it and selecting Save Event Log As), you can opt to save it in the native .evt format, in comma-separated value (CSV) format, or in tab-delimited format.

Event Viewer allows you to view archived logs and live logs on remote systems and usually works just fine. However, if you view a Security log taken from a system running a different language or release version of Windows, you might find that when you try to view an event's details, the description is missing the static text and instead just lists the dynamic insertion strings. Also, viewing a large event log across a WAN connection can be very slow, and if new events are inserted while you're pulling the log down, you'll receive an error message that new events have been inserted.

Event Viewer is also where you configure the maximum size to which the Security log can grow and what Windows should do when the log reaches its size limit. To view these settings, right-click the log and select Properties. You can configure Windows to overwrite older events as needed, stop logging and wait for someone to clear the log, or overwrite events older than the specified number of days. In the last case, Windows will stop logging events temporarily when the log is full and there are no events older than the set number of days.

Security Audit Categories
You can configure Windows 2003 to record any of the nine security event categories to the Security log by enabling or disabling the category's corresponding audit policy. To view a computer's current audit policy, open the Group Policy Editor (GPE) and navigate to Local Computer PolicyComputer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy, as Figure 2 shows. Note that there's a slight difference in naming and listing order between the Security log categories (in Figure 1) and the corresponding audit policies (in Figure 2). Notice in Figure 2 that you can enable each category for success and/or failure events or for no auditing. For instance, you can enable Audit account logon events for failures only, which will result in Windows logging only logon attempts that fail for some reason.

The nine audit categories cover a wide range of activity. You can monitor logon and authentication; administrative activity with regard to maintaining users, groups, and computers; user activity including file access; changes to important security settings; program execution; property level changes in Active Directory (AD); and more. Here's a brief introduction to each event category.

Logon and Authentication
One of the most important ways to monitor user activity as well as detect attacks on your systems is to track logon activity. Because of Windows' domain architecture, logon and authentication are separate concepts: When you log on to your workstation using a domain account, the workstation must authenticate with AD on the domain controller (DC). Two categories of security events enable you to track either or both types of activity: The Logon/Logoff category lets you track logon activity, and Account Logon lets you track authentication events.

Back in the Windows NT days, the Account Logon category didn't exist—you could track only Logon/Logoff. This created a huge problem for people who wanted to track authentication attempts in their domain. Logon/Logoff events are recorded on the computers where the events occur—workstations and member servers—not DCs. You had to try to monitor every workstation and member server for failed logon attempts! Worse, there was no way to detect logon attempts from unauthorized computers.

Fortunately, Windows 2000 introduced the Account Logon category, which although poorly named—it should have been called the Authentication category—lets you capture all domain account logon events at the DC. You still have to monitor all your DC Security logs, but that's way better than monitoring every computer Security log on your network.

The Logon/Logoff category still has its uses, despite the arrival of Account Logon. For one thing, Logon/Logoff can help you track an entire logon session. Account Logon events tell you who's trying to log on where and when, but Logon/Logoff events tell you how long they remain logged on. Logon/Logoff events also provide more detail information about why a logon/authentication attempt failed.

New in Windows 2003: Win2K has one set of event IDs for successful authentication events and a different set for failed authentications. Account Logon events didn't change in Windows XP, but in Windows 2003, the category logs some additional details, and Microsoft inexplicably eliminated the specific event IDs for failed authentication events and merged them with their corresponding authentication success events.

Account Management and Directory Service Access
The Account Management category allows you to track changes to users, groups, and computers and is invaluable for monitoring a number of activities. The best way to manage access is to grant it to groups, not directly to users. The Account Management category allows you to easily identify when a group's membership changes. An attacker who gains administrator access to a system often starts by creating a new user account for use in future attacks. Account Management makes tracking new-user-account creation easy. One other way Account Management helps is that it makes administrators accountable for their actions. If someone accidentally deletes a user account or misapplies some kind of change to a user or group, Account Management provides an audit trail.

The Directory Service Access category provides low-level auditing on AD objects and their properties. Because this category is related to AD, enabling auditing for it on non-DC computers has no effect. The Directory Service Access category overlaps to a degree with Account Management because users, groups, and computers are AD objects. However, Account Management reports high-level changes to users, groups, and computers, and Directory Service Access provides very low-level auditing on AD objects, including users, groups, and computers. Account Management has a unique event ID for each type of object and each access that can be performed against the object. Directory Service Access, on the other hand, reports just one event, event ID 566, for all types of activity. Event ID 566 lists the object type, the object name, the user who accessed the object and the type of access the user had to the object. In the event that Figure 3 shows, the administrator has changed the job title in Susan's account.

Although Directory Service Access is a powerful category, it can be a bit overwhelming to use. On Win2K DCs, the Directory Service Access audit policy's default setting logs all successful and failed attempts to modify AD objects, a setting which results in a lot of events. Additionally, the object type and property names in event ID 566 come directly from AD's schema and can be rather cryptic. For instance, a user's city field is the l field (for locality) and the last name is sn (for surname). Account Management is usually a more practical category to use for auditing maintenance of users, groups, and computers, but Directory Service Access provides the only way to audit changes made to other important AD objects such as GPOs and organizational units (OUs).

New in Windows 2003: Windows 2003 fixes a bug in Win2K that pertains to user password changes and resets. Although the Win2K documentation says that Win2K logs event ID 628 for password resets, Win2K actually logs event ID 627 for both password changes and resets and always reports these events as a password change. Windows 2003 logs event ID 627 for password changes and event ID 628 for password resets.

Auditing File Access
The Object Access category gives you the ability to monitor access to files, folders, printers, registry keys, and system services, but most people use this category to monitor files and folders. If you enable this category, your Security log will immediately start showing some events logged in connection with objects accessed in the SAM. However, you won't see any access events for files or other objects because every object has its own audit settings and auditing is disabled on most objects by default. This is a good thing, because if you tried to audit every access attempt on every file and other object, your system would grind to a halt and your Security log would quickly fill—no matter how much space you allocated to it. I recommend using this category only for important files on which audit trails are critical.

To enable auditing for a given object, open the object's Properties dialog box, select the Security tab, click Advanced, select the Auditing tab, and click Add. For instance, in Figure 4, you see the audit settings for 1^st Quarter Cost Centers.xls, which I opened from Windows Explorer. Notice that you can specify users or groups whose access to this file you wish to audit, as well as exactly which types of access you want to audit and whether to record successful and/or failed access attempts. After you enable auditing on an object, Windows begins recording open and close and other events according to the audit policy for that object.

New in Windows 2003: The Win2K Security log does a good job of telling you which types of access a user and his or her application has to an object but not which types of access the user actually exercised. For instance, Bob might open a document to which he has read and write access. At that point, Win2K logs event ID 560, which shows that a user with List Folder / Read Data and Create Files / Write Data access types opened a file. When Bob closes the file, Win2K logs event ID 562, which shows a user closed a file. But in Win2K, there's no event to indicate whether Bob actually changed the file. Windows 2003 introduces event ID 567. If Bob changed the file on a Windows 2003 machine, you would see an event ID 567 between the open and close events. Event ID 567 tells you the name of the object, the user, and what type of access the user actually exercised. If you don't see an event ID 567, then you know the user didn't update the file.

Tracking Program Execution
The Detailed Tracking category gives you the ability to track each program that's being executed on the Windows system being monitored. On workstations, you can see all the applications the user starts (event ID 592) and closes (event ID 593). You can tie the two events together using the process ID found in the description of both events. You can use process tracking with logon/logoff auditing and file open/close auditing to assemble a picture of when a user logged on, which programs he or she ran, and which files he or she accessed with those programs.

New in Windows 2003: Windows 2003 adds two new events to Detailed Tracking. Event ID 601 lets you know when a new service is installed. This event is useful for monitoring for new services being installed on servers or workstations, whether legitimate or unauthorized, but be aware that this event applies only to system services and not to user applications opened from the desktop. Also, this event won't help you catch Trojan horses or backdoor programs because they don't usually install themselves as a service. The new event ID 602 informs you when a scheduled task is created; however, there's no event for when someone modifies, deletes, or attempts to execute a scheduled task. We should have the ability to audit all these events, not to mention the ability to schedule events remotely.

User Rights
To control a user's ability to perform system-level functions, such as changing the system time or shutting down the system, Windows uses user rights, or privileges. You can track the use of such rights with the Privilege Use category. For most rights, Windows logs a Privilege Use event (event ID 577 or event ID 578) when a user exercises a right. A few rights, though, are exercised so frequently that Microsoft opted not to log them each time they're used; instead, when a user holding any of these rights logs on, Windows just logs the fact that the user has the right in event ID 576.

New in Windows 2003: Win2K logs event ID 578 when someone views or dumps the Security log, but for some reason, Windows 2003 doesn't. Likewise, when someone takes ownership of a file or some other object, Windows 2003 fails to log an event (Win2K does log an event). Perhaps these bugs will be fixed in the first service pack for Windows 2003; a number of audit-related bugs were fixed in Win2K service packs.

Policy Changes
Some Policy Change events that Microsoft documentation claims are logged never appear in the Security logs that I see. Likewise, some IP Security (IPSec)-related event IDs never seem to be logged (event IDs 613, 614, and 616), although others are logged (event ID 615). The Policy Change category does, however, log other security-configuration-related changes, including changes to trust relationships, Kerberos policy, Encrypting File System (EFS), and Quality of Service (QoS).

New in Windows 2003: In Win2K, event ID 615 is in the Detailed Tracking category; in Windows 2003, it moves to the Policy Change category. This is just one example of the baffling and needless changes I've discovered while comparing Win2K and Windows 2003 events. One other interesting change: Documentation states that Windows logs event IDs 608 and 609 when a user right is assigned or revoked, respectively. However, Win2K doesn't log these events at all. Windows 2003 does log event IDs 608 and 609 for changes in user right assignments except for logon rights such as Allow logon locally and Access this computer from the network. Windows 2003 logs changes to these logon right assignments with event IDs 621 and 622 (system security access granted and revoked, respectively) rather than the documented event IDs 608 and 609. Such inexplicable and undocumented changes wreak havoc on monitoring and reporting software that filters and analyzes events based on category, event ID, or the expected position of fields in the description.

System Events
The System Event category is a catchall for miscellaneous security-related events. Windows uses events in this category to let you know when the system starts up (event ID 512) and shuts down (event ID 513) as well as when different types of security modules (e.g., logon processes and authentication packages) are loaded during the start-up process. Two particularly useful events are event ID 517, which tells you that the Security log was cleared and who cleared it, and event ID 520, which is new in Windows 2003.

New in Windows 2003: The only new System Event that I've actually seen in my testing of Windows 2003 is event ID 520, which alerts you that the system date or time was changed and includes the new and old date or time in the description.

The Security log is an incredibly powerful tool for tracking users and IT staff members and detecting intrusions, but it has its challenges as well. The better you understand its idiosyncrasies, the more you can accomplish with the Security log and the more value you will derive from any Security log–related reporting and alerting tools you might have invested in. I look forward to sharing in future articles more of what I've learned over many years of research into the Security log.

AUTHOR'S NOTE:
This article series is based on Monterey Technology Group's "Security Log Secrets" course.