Audit Policy

Applies To: Windows Server 2008

Establishing an organizational computer system audit policy is an important facet of information security. Configuring Audit policy settings that monitor the creation or modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.

There are nine different kinds of events for which you can specify Audit Policy settings. If you audit any of these kinds of events, Windows® records the events in the Security log, which you can find in Event Viewer.

• Account logon events. Audit this to record each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated in the domain controller's Security log when a domain user account is authenticated on a domain controller. These events are separate from logon events, which are generated in the local Security log when a local user is authenticated on a local computer. Account logoff events are not tracked on the domain controller.

• Account management. Audit this to record when someone has changed an account name, enabled or disabled an account, created or deleted an account, changed a password, or changed a user group.

• Directory service access. Audit this to record when someone accesses an Active Directory® Domain Services object that has its own system access control list (SACL).

• Logon events. Audit this to record when someone has logged on or off your computer (either while physically at your computer or by trying to log on over a network).

• Object access. Audit this to record when someone has used a file, folder, printer, or other object. Although you can also audit registry keys, we do not recommend auditing them unless you have advanced computer knowledge and know how to use the registry.

• Policy change. Audit this to record attempts to change local security policies and to see if someone has changed user rights assignments, auditing policies, or trust policies.

• Privilege use. Audit this to record when someone performs a user right.

• Process tracking. Audit this to record when events such as program activation or a process exiting occur.

• System events. Audit this to record when someone has shut down or restarted the computer, or when a process or program tries to do something that it does not have permission to do. For example, if malicious software tried to change a setting on your computer without your permission, system event auditing would record it.

When you implement Audit Policy settings:

• Specify the categories of events that you want to audit. The event categories that you select constitute your audit policy.

• Set the size and behavior of the Security log. You can view the Security log with Event Viewer.

• If you want to audit directory service access or object access, determine which objects you want to audit access of and what type of access you want to audit. For example, if you want to audit all attempts by users to open a particular file, you can configure audit policy settings in the object access event category so that both successful and failed attempts to read a file are recorded.

The Security log records an audit event whenever users perform certain specified actions. For example, the modification of a file or a policy can trigger an event that shows the action that was performed, the associated user account, and the date and time of the action. These events can be both successful and failed attempts to perform actions.

Regular security analyses enable administrators to track and determine whether adequate security measures are in effect for each computer as part of an enterprise risk management program. Such analyses focus on highly specific information about all aspects of a computer that relate to security, which administrators can use to adjust the security levels. More important, this information can help detect any security oversights that may occur in the computer over time. For example, security levels may be temporarily changed to enable immediate resolution of an administration or network issue. However, such changes are often forgotten and never undone. If security levels are not properly reset, a computer may no longer meet the requirements for enterprise security.

Establishing and enabling audit policy settings that record deviations from your enterprise security policy are extremely important for any enterprise network. Audit logs may provide the only indication that a security breach has occurred by recording changes on file permissions, installation of programs, and escalation of privileges. If the breach is discovered some other way, proper audit settings can generate an audit log that may contain important information about the breach, how it occurred, and what systems were affected.

In many cases, failure events are much more informative than success events because failures typically indicate errors. For example, successful logon to a computer by a user would typically be considered normal. However, if someone unsuccessfully tries to log on to a computer multiple times, it may indicate an attacker's attempt to break into the computer with someone else's account credentials. The Event Log item of Group Policy is used to define attributes that relate to the Application, Security, and System logs, such as maximum log size, access rights for each log, and retention settings and methods. Auditing events are stored in the Security event log. For more information about the Event Log, see the Event Log section in this guide.

Before any audit processes are implemented, an organization should determine how to collect, organize, and analyze the data. There is little value in large volumes of audit data if there is no underlying plan to use it. Also consider that audit settings can affect computer performance. The effect of a given combination of settings may be negligible on an end-user computer but quite noticeable on a busy server. Therefore, you should perform some performance tests before you deploy new audit settings in your production environment. A final consideration is the amount of storage space that you can allocate to store the data collected during auditing. Depending on the setting you choose, auditing data can accumulate quickly and can fill up available disk space.

You can configure the Audit Policy settings in the following location within the Group Policy Management Console in Windows Vista with Service Pack 1 (SP1) and in Windows Server 2008:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

The following sections describe the options and issues for configuring Audit Policy settings for better system management and security.

Audit Policy settings

The vulnerabilities, countermeasures, and potential impacts of all the Audit Policy settings are identical. The options for each of the audit settings are also identical:

• Success. An audit event is generated when the requested action succeeds.

• Failure. An audit event is generated when the requested action fails.

• No Auditing. No audit event is generated for the associated action.

Vulnerability

If Audit Policy settings are not configured, it can be difficult or impossible to determine what occurred during a security incident. However, if Audit Policy settings are configured so that events are generated for all activities, the Security log will be filled with data and hard to use. Also, you can use a large amount of data storage as well as adversely affect overall computer performance if you configure Audit Policy settings for a large number of objects.

If failure auditing is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten.

Countermeasure

Enable Audit Policy settings that support the organizational security policy for all the computers in your organization. Identify the components that you need to monitor to enable your organization to hold users accountable for their actions while they use organizational resources, enables IT departments to detect unauthorized activity efficiently, and tracks those events in log files.

Potential impact

If no Audit Policy settings are configured or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too detailed, critically important entries in the Security log may be obscured by the large number of log entries created by routine activities and computer performance, and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.

Audit account logon events

This policy setting enables auditing of each instance of user logon or logoff on a different computer than the one that records the event and validates the account. Success audits provide useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer.

Failure audits are useful for intrusion detection. However, this configuration of the policy setting also creates the potential for a DoS attack. When the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures in order to fill the Security log and force the computer to shut down.

If you configure the Audit account logon events setting to Success on a domain controller, an event is logged for each user who is validated against that domain controller, even though the user actually logs on to a workstation or server that is joined to the domain.

By default, Auditaccount logon events is set to Success.

Audit account management

This policy setting enables auditing of each account management event on a computer. Examples of account management events include the following:

• User account or group is created, changed, or deleted.

• User account is renamed, disabled, or enabled.

• Password is set or changed.

Success audits should be enabled on all computers in your enterprise. When an organization responds to security incidents, it is critical that they be able to track who created, changed, or deleted an account. Failure audits generate an event when any account management action fails.

Audit directory service access

This policy setting enables auditing of user access of an Active Directory object that has an associated SACL. A SACL is list of users and groups for which actions on an object are to be audited on a Windows–based network.

Success audits generate an event when a user successfully accesses an Active Directory object that has a SACL that indicates that the user should be audited for the requested action. Failure audits generate an event for each unsuccessful attempt. (Both types of events are created before the user is notified that the request succeeded or failed.) If you enable this policy setting and configure SACLs on directory objects, a large volume of entries can be generated in the Security logs on domain controllers. You should enable these settings only if you actually intend to use the information that is created.

Note

You can configure a SACL on an Active Directory object through the Security tab in that object's Properties dialog box. This method is analogous to Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.

Audit logon events

This policy setting enables auditing of each instance of user logon, logoff, or network connection to the computer that records the event. If you log successful account logon events on a domain controller, workstation logon attempts do not generate logon events. Only interactive and network logon attempts to the domain controller itself generate logon events on the domain controller. To summarize, "account logon events" are generated where the account exists, either on the domain controller if the account is a domain account or on the local computer if the account is a local computer account, and "logon events" are generated on the computer where the user is logging on or off.

Success audits provide useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer. Failure audits are useful for intrusion detection. However, the configuration of failure events also creates a potential DoS condition. When the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures in order to fill the Security log, and force the server to shut down.

Audit object access

This policy setting enables auditing of the event generated by a user who accesses an object—for example, a file, folder, registry key, or printer—that has a SACL that specifies a requirement for auditing.

Success audits generate an event when a user successfully accesses an object that has a SACL. Failure audits generate an event for each unsuccessful attempt (some failure events are to be expected during normal computer operations). For example, many applications (such as Microsoft Office Word) always attempt to open files with both read and write privileges. If the applications are unable to do so, they then try to open the files with read-only privileges. If you enable failure auditing and the appropriate SACL on the file, a failure event is recorded when such an event occurs.

You can audit access to objects that are stored in the Internet Information Services (IIS) metabase. To enable metabase object auditing, you must enable Audit object access on the target computer and then set SACLs on the specific metabase objects whose access you want to audit.

If you configure the Audit object access policy setting and configure SACLs on objects, a large volume of entries can be generated in the Security logs on computers in your organization. Therefore, you should only enable these settings if you actually intend to use the information that is logged.

Note

You must perform a two-step process to enable auditing of an object, such as a file, folder, printer, or registry key, in Windows Server 2008. After you enable the audit object access policy, you must modify the SACLs of the objects whose access you want to audit. For example, to audit any attempts by users to open a particular file, you can configure a Success or Failure audit attribute directly on the file that you want to monitor for that particular event by using either Windows Explorer or Group Policy.

Audit policy change

This policy setting enables auditing of every incidence of a change to user rights assignment policies, Windows Firewall policies, Audit policies, or trust policies.

Success audits are useful for accounting purposes and can help you determine who successfully modified policies in the domain or on individual computers. Failure audits generate an event when a change to user rights assignment policies, Audit policies, or trust policies fails.

If you enable the Audit policy change setting in Windows Vista and Windows Server 2008, logging of configuration changes for the Windows Firewall component is also enabled.

Audit privilege use

This policy setting enables auditing of each instance of a user who exercises a user right.

Success audits generate an event when the exercise of a user right succeeds. Failure audits generate an event for an unsuccessful exercise. If you enable this policy setting, the volume of events that is generated can be very large and cumbersome. You should enable this setting only if you plan to use the information that is generated.

Audit events are not generated for the use of the following user rights, even if success audits or failure audits are specified for the Audit privilege use policy setting:

• Bypass traverse checking

• Debug programs

• Create a token object

• Replace process level token

• Generate security audits

• Backup files and directories

• Restore files and directories

Audit process tracking

This policy setting enables auditing of detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

Success audits generate an event when the process being tracked succeeds. Failure audits generate an event when the process fails.

If you enable Audit process tracking in Windows Vista and Windows Server 2008, Windows also logs information about the operating mode and status of the Windows Firewall component.

When enabled, the Audit process tracking setting generates a large number of events. This policy setting is typically configured to No Auditing. However, the information that this policy setting generates can be very beneficial during an incident response because it provides a detailed log of the processes that were started and when they were started.

Audit system events

This policy setting enables auditing of the restart or shutdown of users' computers, or events that affect either computer security or the Security log.

Success audits generate an event when an event runs successfully. Failure audits generate an event when an event is unsuccessful.

Because few additional events are recorded if both failure and success audits are enabled for system events, and because all such events are very significant, you should configure this policy setting to Enabled on all computers in your organization.

Audit example: Results of a user logon event

After you become familiar with the audit settings in Windows, it may be helpful to consider a specific example. The audits in this example are performed from an individual computer's perspective, rather than from the more holistic perspective that an enterprise administrator might prefer. Because events are recorded on individual computers, you might need to examine the Security logs of multiple computers and correlate the data to determine what occurred.

The following tables show the core events that are written to the event logs of an end-user computer, a file server, and a domain controller, when an authorized user logs on to his or her computer and accesses a file in a shared folder hosted by the file server. Only the core events are documented—other events that are generated by these activities were omitted for the sake of clarity. The names of the accounts and resources involved in this example are:

• Domain = Contoso

• Domain controller = DC1

• File server = FS1

• End-user computer = XP1

• User = John

• Shared folder on FS1 = Share

• Document in the shared folder = document.txt

User Action 1: User logs on to his or her computer

Events recorded on the end-user computer	Success Audit for Event ID 528, user Logon/Logoff for user Contoso\John at computer XP1
Events recorded on the domain controller	Success Audit for Event ID 540, user Logon/Logoff for user Contoso\John at computer DC1
Events recorded on the file server	Not applicable

User Action 2: User connects to the shared folder called Share

Events recorded on the end-user computer	Not applicable
Events recorded on the domain controller	Success Audit for Event ID 673, Account logon for user John@contoso.com for service name FS1$ Success Audit for Event ID 673, Account logon for user FS$@contoso.com for service name FS1$ Success Audit for Event ID 673, Account logon for user XP1$@contoso.com for service name FS1$ (These are all Kerberos authentication protocol service ticket requests.)
Events recorded on the file server	Success Audit for Event ID 540, user Logon/Logoff for user Contoso\John at computer FS1 Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share with access types READ_CONTROL, ReadData (or ListDirectory), ReadEA, and ReadAttributes Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share\document.txt with access types READ_CONTROL, ReadData (or ListDirectory), ReadEA, and ReadAttributes

User Action 3: User opens the file document.txt

Events recorded on the end-user computer	Not applicable
Events recorded on the domain controller	Not applicable
Events recorded on the file server	Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share\document.txt with access types READ_CONTROL, ReadData (or ListDirectory), WriteDate (or AddFile), AppendDate (or AddSubdirectory or CreatePipeInstance), ReadEA, WriteEA, ReadAttributes, and WriteAttributes Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share\document.txt with access types ReadAttributes Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share with access types ReadAttributes

User Action 4: User saves the file document.txt

Events recorded on the end-user computer	Not applicable
Events recorded on the domain controller	Not applicable
Events recorded on the file server	Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share\document.txt with access types SYNCHRONIZE, ReadData (or ListDirectory), WriteDate (or AddFile), AppendDate (or AddSubdirectory or CreatePipeInstance), ReadEA, WriteEA, ReadAttributes, and WriteAttributes Success Audit for Event ID 560, Object Access for user Contoso\John to the object named C:\Share\document.txt with access types READ_CONTROL, SYNCHRONIZE and ReadData (or ListDirectory)

Although this example may look like a complex series of events, it has been greatly simplified. The listed actions would actually generate dozens of logon, logoff, and privilege use events on the domain controller and file server. When the user opens the file, scores of object access events are also generated, and each time the user saves the file many more events are generated.

Per-user Selective Auditing

Available in Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP with Service Pack 2 (SP2), per-user selective auditing allows for selective audit levels on individual user accounts. For example, audit levels can be set to report only logon and logoff activity for all users while auditing all activity for a specific user. Per-user selective audit can also be used to reduce the volume of events in the Security log by allowing certain accounts to be excluded from audit generation for certain activities. Only user accounts can be audited using this functionality; security and distribution groups cannot be audited. Accounts that belong to the local Administrators group cannot be excluded from auditing by using the per-user selective audit mechanism.

Valid selective auditing categories are:

• Account Logon

• Account Management

• Directory Service Access

• Detailed Tracking

• Logon/Logoff

• Object Access

• Policy Change

• Privilege Use

• System Event

In Windows Vista and Windows Server 2008, the command-line tool used to set per-user auditing policy for selective auditing is Auditpol. For a command-line reference on the use of Auditpol, see Auditpol (https://go.microsoft.com/fwlink/?LinkID=84473).

Expanded Auditing Policy in Windows Vista and Windows Server 2008

In Windows Vista and Windows Server 2008, auditing has been expanded to support auditing subcategories for each of the categories discussed in the previous section. These subcategories allow you to fine-tune your auditing strategy to reduce the number of extraneous entries in the auditing logs and allow each organization to focus their auditing on the events that are important to them.

If you are going to use auditing subcategories, you should not use Group Policy to define and distribute your auditing policies. The Group Policy Management Console configures only the top-level auditing categories and enables all of the subcategories within the category and thus cannot be used to set more targeted audit policy. Instead, auditing policy that uses auditing subcategories must be defined by using the command-line tool auditpol.exe and distributed by means of a script.

The following table identifies the auditing subcategories:

Category-Subcategory	Description	Default Setting
System - Security System Extension	Reports the loading of extension code such as authentication packages by the security subsystem.	No Auditing
System - System Integrity	Reports on violations of integrity of the security subsystem.	Success and Failure
System - IPsec Driver	Reports on the activities of the Internet Protocol security (IPsec) driver.	No Auditing
System - Other System Events	Reports on other system events.	Success and Failure
System - Security State Change	Reports changes in security state of the system, such as when the security subsystem starts and stops.	Success
Logon/Logoff - Logon	Reports when a user attempts to log on to the system.	Success
Logon/Logoff - Logoff	Reports when a user logs off from the system.	Success
Logon/Logoff - Account Lockout	Reports when a user's account is locked out as a result of too many failed logon attempts.	Success
Logon/Logoff - IPsec Main Mode	Reports the results of Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Main Mode negotiations.	No Auditing
Logon/Logoff - IPsec Quick Mode	Reports the results of IKE protocol and AuthIP during Quick Mode negotiations.	No Auditing
Logon/Logoff - IPsec Extended Mode	Reports the results of AuthIP during Extended Mode negotiations.	No Auditing
Logon/Logoff - Special Logon	Reports when a special logon is used. A special logon is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level.	Success
Logon/Logoff - Other Logon/Logoff Events	Reports other logon/logoff-related events, such as Terminal Services session disconnects and reconnects, using RunAs to run processes under a different account, and locking and unlocking a workstation.	No Auditing
Object Access - File System	Reports when file system objects are accessed. Only file system objects with SACLs cause audit events to be generated, and only when they are accessed in a manner matching their SACL.	No Auditing
Object Access - Registry	Reports when registry objects are accessed. Only registry objects with SACLs cause audit events to be generated, and only when they are accessed in a manner matching their SACL.	No Auditing
Object Access - Kernel Object	Reports when kernel objects such as processes and mutexes are accessed. Only kernel objects with SACLs cause audit events to be generated, and only when they are accessed in a manner matching their SACL. Typically kernel objects are only given SACLs if the AuditBaseObjects or AuditBaseDirectories auditing options are enabled.	No Auditing
Object Access - SAM	Reports when SAM objects are accessed.	No Auditing
Object Access - Certification Services	Reports when Certification Services operations are performed.	No Auditing
Object Access - Application Generated	Reports when applications attempt to generate audit events by using the Windows auditing application programming interfaces (APIs).	No Auditing
Object Access - Handle Manipulation	Reports when a handle to an object is opened or closed. Only objects with SACLs cause these events to be generated, and only if the attempted handle operation matches the SACL. Handle Manipulation events are only generated for object types where the corresponding Object Access subcategory is enabled, for example File System or Registry.	No Auditing
Object Access - File Share	Reports when a file share is accessed.	No Auditing
Object Access - Filtering Platform Packet Drop	Reports when packets are dropped by Windows Filtering Platform (WFP). These events can be very high in volume.	No Auditing
Object Access - Filtering Platform Connection	Reports when connections are allowed or blocked by WFP. These events can be high in volume.	No Auditing
Object Access - Other Object Access Events	Reports other object access-related events such as Task Scheduler jobs and COM+ objects.	No Auditing
Detailed Tracking - Process Termination	Reports when a process terminates.	No Auditing
Detailed Tracking - DPAPI Activity	Reports encrypt or decrypt calls into the data protections application interface (DPAPI). DPAPI protects secret information such as stored password and key information.	No Auditing
Detailed Tracking - RPC Events	Reports remote procedure call (RPC) connection events.	No Auditing
Detailed Tracking - Process Creation	Reports the creation of a process and the name of the program or user that created it.	No Auditing
Policy Change - Audit Policy Change	Reports changes in audit policy including SACL changes.	Success
Policy Change - Authentication Policy Change	Reports changes in authentication policy.	Success
Policy Change - Authorization Policy Change	Reports changes in authorization policy including permissions (DACL) changes.	No Auditing
Policy Change - MPSSVC Rule-Level Policy Change	Reports changes in policy rules used by the Microsoft Protection Service (MPSSVC.exe). This service is used by Windows Firewall and by Microsoft OneCare.	No Auditing
Policy Change - Filtering Platform Policy Change	Reports the addition and removal of objects from WFP, including startup filters. These events can be very high in volume.	No Auditing
Policy Change - Other Policy Change Events	Reports other types of security policy changes such as configuration of the Trusted Platform Module (TPM) or cryptographic providers.	No Auditing
Account Management - User Account Management	Reports each event of user account management, such as when a user account is created, changed, or deleted; a user account is renamed, disabled, or enabled; or a password is set or changed.	Success
User Account Management - Computer Account Management	Reports each event of computer account management, such as when a computer account is created, changed, deleted, renamed, disabled, or enabled.	No Auditing
User Account Management - Security Group Management	Reports each event of security group management, such as when a security group is created, changed, or deleted or when a member is added to or removed from a security group.	Success
User Account Management - Distribution Group Management	Reports each event of distribution group management, such as when a distribution group is created, changed, or deleted or when a member is added to or removed from a distribution group.	No Auditing
User Account Management - Application Group Management	Reports each event of application group management on a computer, such as when an application group is created, changed, or deleted or when a member is added to or removed from an application group.	No Auditing
User Account Management - Other Account Management Events	Reports other account management events.	No Auditing
DS Access - Directory Service Changes	Reports changes to objects in Active Directory Domain Services (AD DS). The types of changes that are reported are create, modify, move, and undelete operations that are performed on an object. DS Change auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema.	No Auditing
DS Access - Directory Service Replication	Reports when replication between two domain controllers begins and ends.	No Auditing
DS Access - Detailed Directory Service Replication	Reports detailed information about the information replicating between domain controllers. These events can be very high in volume.	No Auditing
DS Access - Directory Service Access	Reports when an AD DS object is accessed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL. These events are similar to the directory service access events in previous versions of Windows Server.	No Auditing
Account Logon - Kerberos Ticket Events	Reports the results of validation tests on Kerberos tickets submitted for a user account logon request.	No Auditing
Account Logon - Other Account Logon Events	Reports the events that occur in response to credentials submitted for a user account logon request that do not relate to credential validation or Kerberos tickets.	No Auditing
Account Logon - Credential Validation	Reports the results of validation tests on credentials submitted for a user account logon request.	No Auditing

For instruction on how to use auditpol.exe to create detailed audit policies for computers running Windows Vista and how to distribute those setting by using a script, see article 921469, "How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain" (https://go.microsoft.com/fwlink/?LinkID=82447).

Additional references

The following links provide additional information about topics that relate to Audit policy settings for computers that run Windows Vista or Windows Server 2008:

• For more Audit policy information, see "Security Auditing" in the Windows Server 2008 Technical Library (https://technet.microsoft.com/en-us/library/cc771395.aspx).

• For an overview of Windows Server 2008 auditing and compliance issues, see the TechNet magazine article "Auditing and Compliance in Windows Server 2008."

• Article 921469, "How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain"(https://go.microsoft.com/fwlink/?LinkID=82447) describes a procedure that administrators can use to deploy a custom audit policy that applies detailed security auditing settings for Windows Vista and Windows Server 2008-based computers.

• Article 947226, "Description of security events in Windows Vista and in Windows Server 2008" (https://support.microsoft.com/kb/947226/en-us) describes various security-related and auditing-related events in Windows Vista and in Windows Server 2008. This article also provides information about how to interpret these events. All these events appear in the Security log and are logged with a source of "Security-Auditing. This information can also be downloaded as a reference spreadsheet "Security audit events for Windows Server 2008 and Windows Vista: from the Download Center (https://www.microsoft.com/downloads/details.aspx?FamilyID=82E6D48F-E843-40ED-8B10-B3B716F6B51B&displaylang=en)

• Article 947223, "Description of the Special Groups feature in Windows Vista and in Windows Server 2008" (https://support.microsoft.com/kb/947223/en-us) describes how to audit when members of identified special groups log on to the computer.