SQL Server Magazine

To maintain a secure network, you must audit server and workstation activity and examine event logs frequently for signs of intrusion or unexpected events. On a network with only one or two servers, you can examine log files manually. However, when you're the network cop for more than a couple of servers, the manual process is tedious and time-consuming.

Administrators typically monitor the success and failure of logon events, changes to local accounts, and changes to local security policy. Although logon success events can help you reconstruct a specific user's activities, you look primarily for events that document a consistent pattern of failed logons or failed attempts to change the local security policy. The same is true for events you monitor in the System log—you worry about a server when you see an event documenting a service that couldn't log on or couldn't perform as expected (e.g., constant complaints from the browser that it can't retrieve a list of servers from the browse master, messages that the Windows Time Service was unable to locate a Network Time Protocol—NTP—time server).

If you support a global network, you probably have a budget for tools that automate these repetitious sifting and sorting tasks. However, in small and midsized businesses, you must often expend time rather than dollars to reduce how long scanning log files for critical events takes. The Microsoft Windows 2000 Server Resource Kit has two great utilities—AuditPol and Dumpel—that help you expedite changes to security auditing and reduce the time it takes to isolate critical events in the system event logs.

AuditPol: The Security Audit Tool
For this article, I assume that you know how to enable security auditing with either Group Policy or Local Security Policy. (If you need a quick refresher, read Randy Franklin Smith, "Auditing Windows 2000," http://www.secadministrator.com, InstantDoc ID 9633.) As you know, each time you use Group Policy or Local Security Policy to adjust security audit settings, you must force a policy refresh to update the settings on each target system. When you use the Microsoft Management Console (MMC) Local Security Authority snap-in to modify security audit settings, you must remember to manually refresh the policy by typing

secedit /refreshpolicy machine_policy

at a command prompt. If you don't refresh the policy, the system remembers but doesn't activate the new audit settings until the next scheduled Group Policy refresh or until you reboot the system (rebooting forces a refresh of the security policy). When you suspect that a system is under attack, you need to implement security audit changes immediately, without manually forcing or waiting for a scheduled refresh to occur. For more information, see "Using AuditPol to Change Security Audit Settings Immediately," http://www.secadministrator.com, InstantDoc ID 23684.

Getting started with AuditPol. The AuditPol tool lets you immediately change the audit criteria on a local or remote system. You can use AuditPol to display current security audit settings, to enable or disable security auditing, and to adjust the audit criteria for nine categories of security events. (Because AuditPol doesn't identify audit categories with the same names you see in the MMC Group Policy snap-in or the MMC Local Security Policy snap-in, I include the snap-in category name in parentheses.)

• Account events (account logon events) monitor logon attempts on a domain controller (DC).
• Directory (directory service access) is a generic category that you enable to audit access to DC objects.
• Logon events (logon events) monitor logon attempts on the local system.
• Object access (object access) is a generic category you enable before you can track access to a specific file, folder, or shared resource.
• Policy events (policy change) track changes to the local security policy.
• Privilege events (privilege use) monitor operations that grant elevated privileges to user or group accounts.
• Process (process tracking) is a generic category you enable to audit access to a specific process.
• SAM events (account management) monitor changes to individual or group accounts on the local system in the SAM database.
• System events (system events) include system and service startup and shutdown, messages from the browser, RRAS, or the Win32 Time Service.

AuditPol uses straightforward syntax:

auditpol [\\computer] [/enable | /disable] [/category:type]
[/category:type] ...

You can type

auditpol /?

at a command prompt to display command-line Help. The computer-name argument, \\computer, governs the system on which AuditPol runs. If you omit the computer-name argument, the utility runs on the local system. To run the command on a remote system, you must enter the name of the remote system. You can identify the remote system in several ways—for example, the three commands

auditpol \\machine1
auditpol \\machine1.mydomain.com

and

auditpol \\10.1.1.42.

all display the security audit settings on Machine1 with IP address 10.1.1.42. As Figure 1 shows, the first line of output from any of these commands indicates whether security auditing is enabled. The remainder of the output reflects the system's current audit settings.

The /enable argument turns on security auditing. Because /enable is the default, you can safely omit it when you add or remove categories or alter the type of events you want to audit. To display the current security audit settings, use AuditPol without arguments and with or without a computer name.

The /category:type argument lets you enable security auditing by category and event type. You can use up to nine /category arguments in the command, each argument correlating to one of the nine categories of security audit events in Group Policy's computer configuration\windows settings\security settings\local policies\audit policy container and in Local Security Policy's security settings\local policies\audit policy container. Combining /category arguments lets you fine-tune the events you want the Security log to record. For each category, you can specify the type of events the system should record: success, failure, all (success and failure), or none.

   Prev. page   [1] 2 3 4     next page