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 Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit 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.
Previous
Register
