Refining the output. Use the /format argument to include only fields of interest rather than all the text associated with events you want to isolate. The /format argument accepts a string of case-sensitive alpha-betic characters that identify output fields. Dumpel outputs the fields in whatever order you place them in the string. The format fields you can manipulate are
- d - date
- t - time
- T - event type (success or failure)
- C - event category
- I - event ID
- S - event source
- u - user
- c - computer
- s - strings (event message text)
By default, Dumpel outputs event records with the format dtTCISucs (/format dtTCISucs). This order produces one line of output per event formatted as follows:
date (d)—time (t)—event type (T)—event category
(C)—event ID (I)—event source (S)—user
(u)—computer (c)—strings (s)
With logon failures, you're primarily interested in the computer and the account that caused the logon failure. An alternate format places important information at the beginning of each line. You instruct Dumpel to format records this way with the argument /format dtIucTCSs.
date (d)—time (t)—event ID (I)—user
(u)—computer (c)—event type (T)—event category
(C)—event source (S)—strings (s)
To save additional time, you can omit the field name in the /format argument to reduce the output to only a few columns. With logon-failure records, the workstation name and account appear in the event-log message text. To generate a one-line report for each logon failure that contains only the date and time, the event ID, and the message text, use the argument /format dtIs as follows:
for %i in (machine1, machine2, machine3, machine4) do
dumpel -s %i -l security -m security -e 529 537 581 /format
dtIs>>%temp%\LogFails.txt
If you add /format dtIs to the command line that extracts logon-failure records on multiple systems, in moments, you have an output file that concisely documents all known logon failures (assuming the list of event ID's covers all known logon-failure events).
Figure 5 shows the output this command produces; because the data is minimal, you need only a minute or two to scan the output and decide whether you have a problem. Figure 5 shows a problem that occurred a couple of years ago.
OS components write events to the event log in different formats. Sometimes important information is in the event-log header and sometimes in the message text. To generate minimum output, use Event Viewer to review carefully the information you want to extract for each event and format Dumpel's output accordingly. In some cases, you might want to completely suppress the output of the event message text. If so, use the -ns (no strings) argument.
By default, Dumpel creates a space-delimited output file. If you prefer to load the output report into a spreadsheet, Dumpel can create either a tab-separated file (the -t argument) or a Comma Separated Value (CSV) file (the -c argument).
Let AuditPol and Dumpel Help You Monitor System Security
If you haven't looked at the Win2K resource kit recently, you might want to resurrect it from the archives and test-drive AuditPol and Dumpel. Although I've focused on extracting data from the Security log, Dumpel works equally well on the System and Application logs. Because these utilities modify security audit settings and access Security logs, I recommend that you restrict access to users who are authorized to perform these types of operations.
After you're comfortable with each tool, you can write a script that invokes the utility with arguments that reflect the names of the machines and the events you want to monitor. If you're good with batch files or VBScript, you can write a pretty sophisticated script that does exactly what you need. Then, schedule your script to run daily or weekly and email the output to you. In a few hours, you can recoup the hours spent in the manual version of this task, which frees up time for more productive, or at least more intellectually challenging, activities.
End of Article
Prev. page
1
2
3
[4]
next page -->
