Here are two equivalent commands that enable security auditing on a DC named Machine1 for all types of system, domain logon, policy, and Directory Service (DS) access events:
auditpol \\machine1 /enable /system:all /account:all /policy:all
/directory:all
and
auditpol \\10.1.1.42 /system:all /policy:all /account:all
/directory:all
The command
auditpol \\machine1 /privilege:none
disables security audit logging for privilege events only but leaves all other settings intact. You don't enter the /disable argument to disable a specific category of event logging: You simply specify none for the type of events the system should log.
Disabling security auditing. The /disable argument sets the audit type to none for all nine categories of events. When you use the command AuditPol /disable, don't let the utility's feedback mislead you. For example, when you use the command
auditpol \\machine1 /disable
you'll see output similar to the output that the top half of Figure 2 shows. The first line of output from this command contains the text (0) Audit Disabled, followed by a list of the previously active security audit settings. Despite this seemingly misleading output, AuditPol correctly sets the audit type to none for all nine categories.
You can eliminate this misleading output by using a slightly different version of the above command:
auditpol \\machine1 /system:none /logon:none /policy:none
/account:none /disable
This command updates the type of audit for four categories to none, then disables auditing. As you see in the lower half of Figure 2, the output accurately reflects the status of all security audit categories.
You can verify that AuditPol is working correctly in two ways. First, if you're auditing policy changes, look in the Security log for a record with a source of Security and event ID 612 (audit policy change) for a confirmation of the changes similar to the confirmation that Figure 3 shows. Second, you can display the active settings with the Local Security Policy snap-in. You might need to refresh the security settings; if so, right-click Security Settings in the left pane and select Reload from the drop-down menu.
Here is a sequence of commands that you can use to familiarize yourself with AuditPol.
auditpol \\machine1
auditpol \\machine1 /logon:all /sam:all /system:all /account:all
/policy:failure
auditpol \\machine1 /disable
(Of course, you need to substitute a valid computer name for the \\machine1 argument. If you omit the computer name, AuditPol runs on the local system.) The first command displays the current security audit settings. The second command enables auditing for five categories of events. The third command disables auditing for all categories and events.
Monitoring Critical Events with Dumpel
Dumpel is a command-line tool you can use to extract events from the System, Security, or Application log on a local or remote system. With suitable tweaking in a script and a quick entry in the Win2K Task Scheduler, you can run Dumpel at preset intervals (e.g., several times a day, once a week) based on your current perception of system stability and network vulnerability.
I like Dumpel because it's faster and cleaner than the GUI-based alternatives. You can run Dumpel more quickly than you can run the Windows NT Event Viewer on a local or remote system. Dumpel is cleaner because, although you can create a custom MMC console that incorporates the Event Viewer on multiple systems, you still must wade through thousands of entries manually. Although you can use the filter option in Event Viewer to reduce the number of events you must scan, the filter doesn't let you select multiple events by event ID, which makes the GUI version time-consuming. Dumpel's big advantage is its powerful set of command-line arguments that extract only those events that signal problems. Dumpel has two obvious uses: to generate a quick snapshot of key system or security events and to monitor the success or failure of regularly scheduled production or backup jobs.
Getting started with Dumpel. Dumpel's syntax is complicated, but the arguments give you a great deal of flexibility in controlling which events to extract and the amount of data you want to view for each event. The syntax is
dumpel -f file [-s \\computername] [-b] [-l eventlog [-m source]]
[-e EventID1, EventID2, ...] [-r] [-t] [-c] [-d x]
The -f file argument specifies the output file in which Dumpel will store the events you monitor. As with most Win2K commands, you can use the > redirect operator to save the utility's command-line output (stdout) to the device, directory, and filename you choose. If you redirect the output, you don't need the -f file argument.
The -l eventlog argument functions in two ways. When you extract events from an active event log, -l identifies the type of log file you want Dumpel to examine: security, system, or application. This argument is required and defaults to the Application log. If you run Dumpel on a saved copy of an event log, (i.e., an event log you previously saved in .evt format), use -l to specify the name of the saved event file. I explain below how to extract records from a saved event-log file.
The -s system argument instructs Dumpel to access the event log you indicate with the -l argument on a remote system. If you omit the -s system argument, Dumpel accesses the event log you specify with -l on the local system. You can identify a remote system with a NetBIOS name, a Fully Qualified Domain Name (FQDN), or a TCP/IP address. For example, each of these three equivalent commands extracts all events in the Security log on a remote system named Machine1:
dumpel -s machine1 -l security >%temp%Machine1SecLog.txt
dumpel -s \\machine1 -l security >%temp%Machine1SecLog.txt
dumpel -s 10.1.1.26 -l
security >%temp%
Machine1SecLog.txt
Prev. page
1
[2]
3
4
next page 
