You can use this page to create an audit policy for servers in your organization. Auditing is the process that tracks the activities of users and records selected types of events in the security log. An audit policy defines the types of events that you want to collect.

Collecting and monitoring audit events consumes disk space and other resources. Before selecting an audit policy, review "Auditing Security Events Best Practices" (http://go.microsoft.com/fwlink/?LinkId=92229).

You can use Microsoft Operations Manager (MOM) to collect audit events from multiple servers at a single repository.

The following table describes each of the three audit policy objectives that you can select with the Security Configuration Wizard (SCW).

Audit policy objective Description Audit event type and policy settings

Do not audit

No auditing is performed. CPU cycles and disk space are spared so that other processes can have better performance.

Caution

No audit information will be available to detect intruders, to find unauthorized access attempts, or for any other purpose.

None

Audit successful activities

Auditing successful activities results in fewer event log entries than auditing both successful and unsuccessful activities. Use this option to record only what users actually access, not what they try to access.

Note

If you only audit successful activities, then unauthorized intrusion attempts will not appear in the log. Unauthorized intrusion attempts are characterized by large numbers of unsuccessful activities.

Audit account logon events: Success, Failure

Audit account management: Success

Audit directory service access: Success

Audit logon events: Success, Failure

Audit object access: Success

Audit policy change: Success

Audit privilege use: Not audited

Audit process tracking: Success

Audit system events: Success, Failure

Audit successful and unsuccessful activities

This means that you intend to use audit events to track the attempts of users to gain access to areas for which they are not authorized, in addition to tracking successful task completion.

Note

Do not select Audit successful and unsuccessful activities unless you review security logs regularly. If users attempt to access a resource for which they are not authorized, they can create so many failure audits that the security log becomes full. When the security log is full, the oldest audit entries are overwritten.

Audit account logon events: Success, Failure

Audit account management: Success, Failure

Audit directory service access: Success, Failure

Audit logon events: Success, Failure

Audit object access: Success, Failure

Audit policy change: Success, Failure

Audit privilege use: Not audited

Audit process tracking: Success, Failure

Audit system events: Success, Failure

Additional references

  • Audit Policy
  • Audit Policy Summary