Using the Built-In Searches
EventCombMT contains built-in searches, such as the search for duplicate SIDs in AD, FRS failures, and hardware disk errors. One of my favorite built-in searches is the search for account lockouts. Finding which DC is responsible for locking out a user and the events leading up to the lockout isn't an easy task if done manually. To load this predefined search, select Built In Searches, Account Lockouts on the Searches menu. The utility automatically selects the DCs and the account-lockout events that Table 1 lists.
Accounts typically get locked out in the following manner: When a user attempts to log on and fails because of a bad password, each attempt is logged with event ID 529. After the account has exceeded the maximum number of attempts and the account is locked out, the PDC emulator records event ID 644 to mark the occasion. Subsequent attempts to log on using the locked out account are logged on the DC with event ID 539.
Event IDs 529 and 539 are among the most difficult to find because they're logged locally at the computer at which the logon attempt occurs and might not even be logged at all if the account lockout occurs on a computer that doesn't audit logon and logoff events. However, you can always locate event ID 644 entries on the PDC emulator. The event ID 644 entry should tell you on which machine to look next. If that machine isn't auditing logon and logoff events, you need to enable the logging of these events to investigate future account-lockout events.
In large network environments, searching for individual account failures can be quite time- and resource-consuming. When investigating locked-out accounts in such an environment, start by searching for event ID 644 first to learn details of the lockout, including the machines that tried to perform the authentication. Then, expand your search to event ID 529 to see the individual failed attempts. Other events can also indicate a failure to authenticate, as Table 2, page 16, shows. The events in Table 2 are logged locally at the computer at which the logon attempt occurred.
As I described earlier, event IDs 528 and 540 denote successful logons. Event ID 528 is logged locally at the computer at which the logon occurred, whereas event ID 540 is logged at the appropriate authenticating DC. Within each event, the log records the type of logon. For example, Web Table 1 (http://www.secadministrator.com, InstantDoc ID 37450) lists the logon types for event ID 528. You can use these event IDs and logon types to build an account history for a user.
Building Custom Searches
In addition to using EventCombMT's built-in searches, you can build and save custom searches. For example, if you want to learn when new accounts are created, you can search for event IDs 624 and 626. You can learn when users change their passwords by searching for event IDs 627 and 628.
Shutdowns and blue screens are worth searching for and investigating to find possible service problems. Table 3 shows the event IDs for these events. Finding event ID 6008 without a corresponding event ID 1001 might represent a hung server, or the server might have been powered down.
Occasionally, shutdown and blue-screen events can be evidence of a security problem. A malicious user might be trying to boot to another OS or otherwise interfere with the typical startup sequence. For security purposes, you'll also want to monitor event logs for event IDs 612 and 517. These events represent a change to the audit policy and a clearing of the Security log, respectively. Malicious users and intruders will often try to change what's being audited to minimize what's logged or clear the event log to cover their tracks. If a log has been cleared, the log will include not only event ID 517 but also the user account that was used to clear the log.
Be Proactive
Frequently checking your logs for failures and suspicious events exemplifies good administration skills and helps you proactively monitor system security. Using EventCombMT to search many computers at once can quickly give you a better picture of what's going on in your environment, enabling you to react faster to incidents.
End of Article
Prev. page
1
2
[3]
next page -->
