Exam 70-124: Objective 6.1: Auditing Windows 2000

Auditing is enabled by doing either a local audit or a Group Policy audit. You can set auditing options on a local Windows 2000 machine by going to the Local Security Policy MMC found in the Administrative Tools folder. We are only concerned with the Audit Policy for now. Here, you can specify what you need to audit and adjust auditing for the following events:

  • Logon events

  • Account logon events

  • Object access

  • Directory service access

  • Privilege use

  • Process tracking

  • System events

  • Policy change

Windows 2000 Local Auditing

For the exam, you are expected to know practically every detail of auditing Windows 2000. You might not be asked very detailed questions such as "What exact Event ID occurs when you have a password attempt failure?" Instead, you will most likely see scenario-based questions for which you'll need every bit of auditing knowledge you possess to decipher what needs to be accomplished in the given scenario.

Audit Account Logon Events

When using auditing for logon events, you are auditing each instance of a user either logging on or off a system on which the account is validated. When you successfully audit an account logon, you will see an entry in the Event Viewer security log. As you can see in Figure 10.2, you have a logon/logoff event (ID 528) that was successful. You can also get more information from the event as you look deeper into the description pane of the dialog box shown. You can see that there was a successful logon (and a successful audit of that logon) for the user rshimonski using the XP1 workstation on the XP1 domain. The logon ID, Type, and Process fields further identify the logon activity.

click to expand
Figure 10.2: Viewing Logon Event Auditing

Audit Account Management

When using auditing for account management events, you are auditing each instance of a user doing one of the following:

  • A user account or group has been created, altered, or possibly deleted.

  • Passwords are changed or set.

When you successfully audit account management, you will see an entry in the Event Viewer Security Log. In Figure 10.3, you have a member add (ID 636) and the event was successful. In the figure shown here, you can see that a group member was added, which triggered the auditing of the event. Here, it is clear that the changes were made where a local group member was added. This caused the audit (account management) to take place and show up in the Event Viewer Security Log. It's a good idea to audit account management if you want to catch users or even administrators adding accounts to groups and giving or getting rights and permissions that they should not have.

click to expand
Figure 10.3: Viewing Account Management Auditing

Audit Logon Events

When using auditing for logon events, you are auditing each instance of a user doing one of the following:

  • Logging on to this computer

  • Logging off this computer

  • Making a network connection to this computer

When you successfully audit logon events, you will see an entry in the Event Viewer Security Log. In Figure 10.4, we see a member add (ID 680) and that the event was successful. As you can see, the Event ID is 680. This identifies the account used for the successful logon attempt. This event also indicates the authentication package used to authenticate the account. The authentication package shown in Figure 10.4 has been audited.

click to expand
Figure 10.4: Viewing an Audit Logon Event

Audit Object Events

When you use auditing for object events, you audit each instance of a user accessing an object-for example, a file, folder, Registry key, printer, and so forth-that has its own system access control list (SACL) specified.

When you successfully audit object events (such as a file, folder, Registry key, printer), you will see an entry in the Event Viewer Security Log. Figure 10.5 shows a member add (ID 562) and that the event was successful.

click to expand
Figure 10.5: Viewing an Audit Object Event

Audit Policy Change

When using auditing for audit policy events, you audit each instance of an actual policy change on the system. A simple example is shown in Figure 10.6, which shows that auditing is turned on (success and failure based) on multiple items. This was an actual policy change to the system, and the Event Viewer recorded it. This type of audit determines if any type of policy is altered in any way; it is recorded for your analysis to see if anyone is trying to change any policies on the system without permission or perhaps for a malicious reason. The most important thing you need to remember is that whenever you make a change to a policy, as long as you have auditing turned on, you can see if any auditing policies have changed in the Event Viewer.

click to expand
Figure 10.6: Viewing an Audit Policy Change Event

When you successfully audit policy changes, you will see an entry in the Event Viewer Security Log. In Figure 10.6, we have a massive change in our success and failure-based auditing (everything was turned on), which caused a new event ID (ID 612) to generate. Turning on all the auditing options lets you know if someone else is trying to change a policy. If an attacker is able to penetrate the system, the attacker can turn off auditing, make a change, then turn auditing back on. Having all the auditing options turned on determines whether to audit every incidence of a change to user rights assignment policies, audit policies, or trust policies. If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all.

Audit Privilege Use

When using auditing for privilege use events, you audit each instance of a user exercising a user right. When you successfully audit privilege use, you see an entry in the Event Viewer Security Log. In Figure 10.7, we have a member add (ID 578), and the event was successful.

click to expand
Figure 10.7: Viewing an Audit Privilege Use Event

Audit Process Tracking

When using auditing for process-tracking (or detailed tracking) events, you audit for events such as program activation, process exit, handle duplication, and indirect object access. When you successfully audit process-tracking events, you see an entry in the Event Viewer Security Log. In Figure 10.8, we have a member add (ID 593), and the event was successful. It is advisable to audit process if you want to track use of a specific process as shown in Figure 10.8. You might want to see if batch commands are being run on a server where you have none-for example, if you hardened a DMZ-based server and you do not have any batch files running net-based commands such as stopping and starting services on the system.

click to expand
Figure 10.8: Viewing an Audit Process-Tracking Event

Audit System Events

When using auditing for system events, you audit each instance of a user restarting or shutting down the computer. This auditing also occurs when an event that affects either the system security or the Security Log occurs. Winlogon.exe is an example of a system process that could trigger a system event in the Security Log. When you successfully audit system events, you see an entry in the Event Viewer Security Log. In Figure 10.9, we have a member add (ID 520), and the event was successful. In this example, we changed the system time, which caused the auditing of a system event in the Security Log.

click to expand
Figure 10.9: Viewing an Audit System Event

Exam Warning 

Memorize everything you can do in the audit policy. You need to recall all this information from memory while working through complex scenarios on the exam.

In Exercise 10.01, you learn how to set basic auditing on a local system. You can also audit with Group Policy. We look at GPO auditing as well later in the chapter, but in Exercise 10.01, you learn how to audit a Windows 2000 system locally.

Exercise 10.01: Auditing with Local Security Policy

start example
  1. To edit the local security policy on the machine, go to Start | Settings | Control Panel | Administrative Tools | Local Security Policy. You can see the Local Security Policy shown in Figure 10.10.

    click to expand
    Figure 10.10: Opening and Using the Local Security Policy

  2. Once Local Policies is opened, click the Audit Policy folder (see Figure 10.11). Once that folder is opened, double-click the Audit account logon events policy found in the right pane of the MMC.

    click to expand
    Figure 10.11: Enabling Auditing on a Local Machine

  3. Once you double-click it, you will be able to edit the policy. Add a check mark to both the Success and Failure check boxes, as shown in Figure 10.12.

    click to expand
    Figure 10.12: Setting Success- and Failure-Based Auditing

  4. Click OK, and then close the Local Security Policy MMC. You have just successfully configured auditing on your system.

  5. Now that you are done, you can go back through the last section and see if you can recreate some of the events described earlier in the chapter. You can then look at the listings of events in the rest of the chapter as a reference to other events you might encounter from time to time during your audits. You can see these events within the Event Viewer.

  6. To get to the Event Viewer to display the Security Log, open the Computer Management console and drill down to the Security Log. If you successfully set up auditing on the system and did something to set off an auditable event, you will see the event listed within the log. A sample of these events is shown in Figure 10.13.

    click to expand
    Figure 10.13: Viewing Events Generated within the Security Log

end example

start sidebar
Head of the Class…
Test Your Policies

Always test a newly created policy on a test computer before applying it to your network. Just like anything else you do on a production network, you never want to roll something out without doing a risk analysis on it. Doing a simple risk analysis on your changes will make you look like a superstar. It's astounding how many times changes are pushed out on a production network without proper testing, often with disastrous consequences. Many disasters can be avoided by a little planning. Your polices should be no different. Not much harm can come from a local security policy running with the events being overwritten as necessary, but the most important thing to watch out for is overwriting needed events with excessive events you might not need to know about. This situation, of course, can be fixed by adjusting log size to higher size limits or by frequently checking and saving your logs. By testing your policies, you will know ahead of time what you need to turn on to achieve a desired logging event. Again, this kind of attention to detail makes you look like a professional, not an amateur who only knows how to turn on system auditing.

end sidebar

You have just enabled auditing on all successful logon events as well as failure-based logon events. Although this action might not seem very exciting, you will see how important it is later in the chapter, when we start to check the Event Logs to find and analyze logon attempts to your system. Now that we have completed discussion of local policies, its time to look at the Event Viewer in more detail.

The Event Viewer

The Windows 2000 Security Log can be viewed using the Windows 2000 Event Viewer MMC. We will get into more specific uses of the Event Viewer later in the chapter, but for now let's take a brief look at it and its uses. The Event Viewer (located within the Computer Management Console or in its own separate console located within the Administrative Tools folder) is used to collect and separate system-generated events into specific logs for viewing and analysis. You can filter the logs depending on what you are looking for (only warning-based events, for example), and you can save all recorded event data for future analysis.

Exam Warning 

The security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller. The settings are also refreshed every 16 hours, whether or not there are any changes.

Auditing with Group Policy

Now that you know the fundamentals of a local security policy audit, let's move on to using Group Policy. For the exam, you will be expected to know both methods, and know them well. Here we look at the fundamentals of GPO-based auditing.

Auditing with Group Policy, you can set the audit on the following levels:

  • Site

  • Domain

  • OU

  • Local machine

It is important to remember where you can set auditing, because there are so many places that it can be configured when you're working with Group Policy. Auditing is enabled using Group Policy, at the site, domain, OU, or local machine level. You will find the audit policy settings in the actual GPO that you create. In Figure 10.14, you can see Group Policy set on a site; we have drilled down to the Audit Account Logon events setting. Here we can set the site to be audited for account logon events that turn up as either a success or a failure. It's that easy.

click to expand
Figure 10.14: Enabling Auditing Using Group Policy

When thinking of proper design, you should set your auditing at the highest possible level in Active Directory to get the highest level of control. The Active Directory is a hierarchical database, so you want to audit from the top down. Doing so allows you to set specific site-level settings for the entire organization.

If you have specific systems that you do not want to audit and you do not incorporate them into the Group Policy audit policy, you can add these later. This can also be done using a Windows 2000 resource kit tool called Auditpol.exe.

Note 

To access Group Policy for a local machine, start a new MMC (MMC /a for author mode) and then add the Group Policy snap-in, making the local computer the focus of the snap-in. Author mode access to a console is used to grant full access to all MMC functionality, including the ability to add or remove snap-ins. You can make a new MMC by going to the Run dialog box and typing and running MMC.

start sidebar
Damage & Defense…
Auditing and Your Security Policy

Have you ever worked somewhere and tried to access files on a folder, wondering before you did whether someone would know you tried to get into the folder? If you have ever thought this way, you are taking your first steps into realizing what auditing can do for you. When people are newly hired into a company, it's a good idea to have Human Resources make sure that they read and sign the posted security policy. This policy should include a clause that alerts the new hire to the fact that all data will be mapped to the local machine, so the new hire will not need to browse the network looking for any other data. If he or she does, it's at their own risk, because we are auditing access on file shares throughout the network. If new hires try to access something they shouldn't, they could be caught and reprimanded accordingly.

This policy is not intended to scare new hires but to warn them that the company is auditing the systems it runs, and that the company takes network and systems security very seriously. It also does a good thing; it encourages new hires to trust the network and systems and makes them more apt to save critical and private data to the network (to be secured and backed up) instead of to their local machines, where many end users keep data they don't want anyone to see. The workstation happens to be the easiest place to get the data from-but they might not realize that. Make sure that you incorporate auditing into your security policy because everyone will benefit.

end sidebar

Events to Audit

Windows 2000 provides several categories of auditing for security events. When designing your enterprise audit strategy, you can pick some or all of the following categories:

  • Logon events

  • Account logon events

  • Object access

  • Directory service access

  • Privilege use

  • Process tracking

  • System events

  • Policy change

Remember, as we mentioned earlier, you need to enable auditing and then watch the events collect in the Event Viewer Security Log. In the following sections, we look at common event IDs that are returned when auditing is enabled for specific categories. It is not only important that you know this information for the exam; you should also be very familiar with the entire process of starting the audit, gathering the collected events, and then using the event IDs to try to figure out what is going on in the system.

Logon Events that Appear in the Event Log

Table 10.1 shows the event IDs that you will see when you audit logon events. This table shows the most common events that you will see in the Security Log.

Table 10.1: Logon Events that Appear in the Event Log

Event

Description

528

A user successfully logged on to a computer.

529

The logon attempt was made with an unknown username or a known username with a bad password.

530

The user account tried to log on outside the allowed time.

531

A logon attempt was made using a disabled account.

532

A logon attempt was made using an expired account.

533

The user is not allowed to log on at this computer.

534

The user attempted to log on with a logon type that is not allowed, such as network, interactive, batch, service, or remote interactive.

535

The password for the specified account has expired.

536

The Net Logon service is not active.

537

The logon attempt failed for other reasons.

538

A user logged off.

539

The account was locked out at the time the logon attempt was made. This event can indicate that a password attack was launched unsuccessfully, resulting in the account being locked out.

540

Successful network logon. This event indicates that a remote user has successfully connected from the network to a local resource on the server, generating a token for the network user.

682

A user has reconnected to a disconnected Terminal Services session. This event indicates that a previous Terminal Services session was connected to.

683

A user disconnected a Terminal Services session without logging off. This event is generated when a user is connected to a Terminal Services session over the network. It appears on the terminal server.

start sidebar
Notes from the Underground…
Hack Alert, Hack Alert!

So you want to be a star auditor of Windows systems. Here is a tip to help you reach your goal. If you turn on success- and failure-based auditing of logon events and event ID 531 starts showing up frequently (as shown in Figure 10.15), you could have a big problem.

click to expand
Figure 10.15: Event ID 531 Appears Frequently

Event ID 531 is a logon attempt on a disabled account. This is a problem if it is the Guest account that was logged on to or the account of an employee that is either away or has been removed. If you find these events, you have a few options available to you. First, if you have accounts on your network that you no longer need, delete them. Next, ensure that your Guest account is still disabled by default. Lastly, if any employee goes on an extended vacation and that person's account has excessive rights, make sure that you watch that account activity closely. See who else knows about this account's excessive rights; you might have a very bad IT professional out there who knows too much for his or her own good.

Lastly, the auditing of an account in this fashion is the making of a honeypot-a trap you set to nail someone trying to log on with default accounts. Essentially, a honeypot is the system you set up to attract and "trap" attackers who attempt to penetrate your systems. By setting a trap like this, you might find someone trying to crack your systems.

end sidebar

Exam Day Tip 

You do not have to memorize every event ID for the exam. However, it serves you best to be familiar with them to help you eliminate the wrong answers from questions you see on the exam.

Local Logon Attempt Failures

You can use the event IDs to start figuring out what's causing a particular problem. For instance, if you think you have a local login attempt, you can monitor for failures. Failed events result in event IDs of 529, 530, 531, 532, 533, 534, and 537. Of these, you could focus on 529 and 534, which could possibly mean that a cracker outside your network is trying to guess at your user account by arbitrarily trying any username and password you have available, such as the Administrator account.

You do, however, want to make sure you use good judgment in suspecting possible attacks. What if a user forgot his or her password and they are just trying to remember it? This could make you believe that a cracker is trying to make an attempt on your systems. The judgment call you need to make is one of frequency. How many times is the attempt occurring? When does it occur? You would be right in being suspicious if, for example, this activity is happening in the middle of the night when nobody should be accessing the systems.

Account Misuse

If you think you are suffering account misuse, you might want to keep an eye on the following events: 530, 531, 532, and 533. These all represent possible issues revolving around account misuse. Either a set of credentials was entered incorrectly (username and password) or something else happened, such as the Cap Lock key being on, for example, that could prevent a user from properly accessing and using an account.

Another form of problem could arise from restrictions on logon hours. Often you set restrictions and then get errors if a user tries to log on to a system outside the allotted times. Figure 10.16 shows you this phenomenon by which a user could log in after 6:00 p.m. to try to download a file or perhaps print a document, and that activity could be construed as misuse. Because the settings were set to deny a logon after 6:00 p.m., an event would be generated as possible misuse of the system. Again, you must use your judgment at times like this.

click to expand
Figure 10.16: Logon Hours Configuration

Note 

Keep on the lookout for event ID 539. ID 539 is an indication that an account has been locked out. This indication could mean that someone using a password-cracking tool might be trying to do a brute-force attack on your systems.

Account Logon Events

Account logon events are audited as logon event IDs, recorded when a user logs on to a system or a domain controller. Table 10.2 shows event IDs that you will see when you audit account logon events. This table shows the most common events that you will see in the Security Log:

Table 10.2: Account Logon Events that Appear in the Event Log

Event

Description

672

An authentication service (AS) ticket was successfully issued and validated.

673

A ticket-granting service (TGS) ticket was granted.

674

A security principal renewed an AS ticket or a TGS ticket.

675

Pre-authentication failed.

676

Authentication ticket request failed.

677

A TGS ticket was not granted.

678

An account was successfully mapped to a domain account.

680

Identifies the account used for the successful logon attempt. This event also indicates the authentication package used to authenticate the account.

681

A domain account logon was attempted.

682

A user has reconnected to a disconnected Terminal Services session.

683

A user disconnected a Terminal Services session without logging off.

When auditing account management, you need to look at creating, deleting, and changing properties on user accounts, users, and groups. When these properties are changed, they show up in the Event Viewer Security Log. Table 10.3 shows the event IDs that you will see when you audit account management events. This table shows the most common events that you will see in the Security Log.

Table 10.3: Account Management Events that Appear in the Event Log

Event

Description

624

User account created.

625

User account type change.

626

User account enabled.

627

Password change attempted.

628

User account password set.

629

User account disabled.

630

User account deleted.

631

Security-enabled global group created.

632

Security-enabled global group member added.

633

Security-enabled global group member removed.

634

Security-enabled global group deleted.

635

Security-disabled local group created.

636

Security-enabled local group member added.

637

Security-enabled local group member removed.

638

Security-enabled local group deleted.

639

Security-enabled local group changed.

641

Security-enabled global group changed.

642

User account changed.

643

Domain policy changed.

644

User account locked out.



MCSE. MCSA Implementing & Administering Security in a Windows 2000 Network Study Guide Exam 70-214
MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214)
ISBN: 1931836841
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net