Threats and Countermeasures Guide: Advanced Security Audit Policy

Applies To: Windows Server 2008 R2

This section of the Threats and Countermeasures Guide discusses advanced security audit policy settings, which are located in Security Settings\Advanced Audit Policy Configuration. 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.

In Windows Server® 2008 R2 and Windows® 7, all auditing capabilities are integrated with Group Policy settings. This allows administrators to configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or the Local Security Policy snap-in for a domain, site, or organizational unit (OU). Windows Server 2008 R2 and Windows 7 make it easier for IT professionals to track when precisely defined, significant activities take place on the network. These features include:

• Advanced audit policy settings, which allow administrators to apply and manage detailed audit policy settings in a more narrowly defined manner than previously through their existing Group Policy framework.

• "Reason for access" auditing, which enables administrators to specify and identify the permissions that were used to generate a particular object access security event.

• Global object access auditing, which allows administrators to define system access control lists (SACLs) for an entire computer file system or registry.

Previous versions of Windows had fewer, although still useful, security auditing options, for example:

• Security auditing was enabled through nine basic settings under Security Settings\Local Policies\Audit Policy. For more information, see Audit Policy Settings Under Local Policies\Audit Policy.

• Additional basic audit policy settings are also available under Security Settings\Local Policies\Security Options. For more information, see Audit Policy Settings Under Local Policies\Security Options.

• In Windows Vista and Windows Server 2008, the number of auditable events was expanded from nine to 53, which enabled an administrator to be more selective in the number and types of events to audit. However, these new audit events were not integrated with Group Policy, and they can only be deployed by using logon scripts that are generated with the Auditpol.exe command-line tool.

Note

For instructions 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 in the Microsoft Knowledge Base.

The nine local audit policy settings under Security Settings\Local Policies\Audit Policy can still be used if client computers do not support advanced audit policy settings. However, where possible it is recommended that you use the more precise auditing capabilities that are provided by the advanced audit policy settings.

Important

Using both the basic audit policy settings under Security Settings\Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use the Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) policy setting under Security Settings\Local Policies\Security Options. This setting will override audit policy settings under Security Settings\Local Policies\Audit Policy and prevent conflicts between similar settings by forcing basic security auditing to be ignored.

For more information about using the basic security audit policy, see the Audit Policy section of Threats and Countermeasures Guide: Security Settings in Windows Server 2008 and Windows Vista.

When you implement advanced audit policy settings:

• Specify the categories and subcategories of the events that you want to audit. The event categories and subcategories 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.

• Determine which objects you want to audit access of and what type of access you want to audit, if you want to audit directory service access or object access. 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. Even if the breach is discovered by means other than auditing, proper audit settings can generate an audit log that may contain important information about the breach, how it occurred, and which 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 in 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 Threats and Countermeasures Guide: 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 that is collected during auditing. Depending on the setting you choose, auditing data can accumulate quickly and can fill up available disk space.

The following sections describe the options and issues for configuring advanced security audit policy settings for better system management and security.

Advanced audit policy settings

The vulnerabilities, countermeasures, and potential impacts of all the advanced audit policy settings are similar. The options for each of the audit settings are identical:

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

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

• Not configured 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 security audit policy settings are configured so that events are generated for all activities, the Security log will be filled with data and difficult 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 policy setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures 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 advanced security 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. These components should allow IT departments to detect unauthorized activity efficiently and track events in log files. For more information about identifying security auditing priorities, and selecting and implementing security auditing settings to address those needs, see Planning and Deploying Advanced Security Auditing Policies.

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.

Important

Applying advanced audit policy settings replaces any comparable basic or local security audit policy settings. If you subsequently change the advanced audit policy setting to Not configured, you will need to complete the following steps to restore the original basic security audit policy settings:

1. Confirm that all Advanced Audit Policy settings are set to Not configured.
   
   
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
   
   
3. Reconfigure and apply local security audit policy settings.
   
   

Audit account logon events

Use this category of audit policy settings to record each instance of a user logging on to or logging off from another computer when that 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.

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 policy setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures to fill the Security log and force the computer to shut down.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Credential Validation	This security policy setting determines whether the operating system generates audit events on credentials that are submitted for a user account logon request. These events occur on the computer that is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Because domain accounts are used much more frequently than local accounts in enterprise environments, most of the Account Logon events in a domain environment occur on the domain controllers that are authoritative for the domain accounts. However, these events can occur on any computer, and they may occur in conjunction with Logon/Logoff events, or on separate computers.	Not configured
Audit Kerberos Authentication Service	This security policy setting allows you to generate audit events for Kerberos authentication ticket-granting ticket (TGT) requests. If you configure this policy setting, an audit event is generated after a Kerberos protocol authentication TGT request. Success audits record successful attempts and Failure audits record unsuccessful attempts.	Not configured
Audit Kerberos Service Ticket Operations	This security policy setting determines whether the operating system generates security audit events for Kerberos protocol service ticket requests. Events are generated every time Kerberos is used to authenticate a user who attempts to access a protected network resource. Kerberos protocol service ticket operation audit events can be used to track user activity.	Not configured
Audit Other Account Logon Events	This security policy setting allows you to audit events that are generated by responses to credential requests submitted for a user account logon that are not credential validation or Kerberos protocol tickets. Examples include new Remote Desktop sessions and Remote Desktop disconnections, locking and unlocking a workstation, invoking or dismissing a screen saver, detection of a Kerberos protocol replay attack, in which a Kerberos protocol request with identical information was received twice, access to a wireless network that is granted to a user or computer account, or access to a wired 802.1x network that is granted to a user or computer account.	Not configured

Audit account management

This category of security audit policy settings enables auditing of each account management event on a computer.

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.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Application Group Management	This security policy setting determines whether the operating system generates audit events when application group management tasks are performed, such as when an application group is created, changed, or deleted; or a member is added to or removed from an application group.	Not configured
Audit Computer Account Management	This security policy setting determines whether the operating system generates audit events when a computer account is created, changed, or deleted. This policy setting is useful for tracking account-related changes to computers that are members of a domain.	Not configured
Audit Distribution Group Management	This security policy setting determines whether the operating system generates audit events when a distribution group is created, changed, or deleted; or a member is added to or removed from a distribution group. These audit events are only logged on domain controllers.	Not configured
Audit Other Account Management Events	This security policy setting determines whether the operating system generates user account management audit events when: The password hash of an account is accessed. This typically happens when the Active Directory® Migration Tool (ADMT) is moving password data. The Password Policy Checking application programming interface (API) is called. Calls to this function could be part of an attack from a malicious application that is testing whether password complexity policy settings are being applied. Changes are made to domain policy under Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy or Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.	Not configured
Audit Security Group Management	This security policy setting determines whether the operating system generates audit events when a security group is created, changed, or deleted; a member is added to or removed from a security group; or a group's type is changed. Security groups can be used for access control permissions and also as distribution lists.	Success
Audit User Account Management	This security policy setting determines whether the operating system generates audit events when a user account is created, changed, deleted, renamed, disabled, enabled, locked out, or unlocked; a user account password is set or changed; a security identifier (SID) history is added to a user account; the Directory Services Restore Mode password is set; permissions on accounts that are members of administrators groups are changed; or Credential Manager credentials are backed up or restored. This policy setting is essential for tracking events that involve provisioning and managing user accounts.	Success

Audit process tracking

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

When enabled, the Audit process tracking settings can generate a large number of events. However, the information that these policy settings generate can be very beneficial during an incident response because they provide a detailed log of the processes that were started and when they were started.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit DPAPI Activity	This security policy setting determines whether the operating system generates audit events when encryption or decryption calls are made into the data protection application interface (DPAPI), which is used to protect secret information such as stored passwords and key information. For more information about DPAPI, see Windows Data Protection.	Not configured
Audit Process Creation	This security policy setting determines whether the operating system generates audit events when a process is created (starts), and the name of the program or user that created it.	Not configured
Audit Process Termination	This security policy setting allows you to generate audit events when an attempt is made to end a process. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when a process ends.	Not configured
Audit RPC Events	This security policy setting determines whether the operating system generates audit events when inbound remote procedure call (RPC) connections are made.	Not configured

Audit directory service access

This category of security audit policy settings enables auditing of user access of an Active Directory object that has an associated SACL.

Note

A SACL is list of users and groups for which actions on an object are to be audited on a network that is running the Windows operating system.

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.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Detailed Directory Service Replication	This security policy setting can be used to generate security audit events with detailed tracking information about the data that is replicated between domain controllers. This audit subcategory can be useful to diagnose replication issues, but it can create a very high volume of event data.	Not configured
Audit Directory Service Access	This security policy setting determines whether the operating system generates events when an Active Directory Domain Services (AD DS) object is accessed. Important Audit events will only be generated on objects with configured SACLs, and only when they are accessed in a manner that matches the SACL settings.	Not configured
Audit Directory Service Changes	This security policy setting determines whether the operating system generates audit events when objects in AD DS are created, deleted, modified, moved, or undeleted. Changes to Active Directory objects are important events to track to understand the state of the network policy. Directory Service Changes auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Important Audit events will only be generated on objects with configured SACLs, and only when they are accessed in a manner that matches the SACL settings.	Not configured
Audit Directory Service Replication	This security policy setting determines whether the operating system generates audit events when replication between two domain controllers begins and ends.	Not configured

Audit logon and logoff events

This category of security audit policy settings enables auditing of each instance that a user logs on, logs off, or connects over the network connection. Instances 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. 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.

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 policy setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures to fill the Security log, and force the server to shut down.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Account Lockout	This security policy setting allows you to audit security events that are generated by a failed attempt to log on to an account that is locked out. Account lockout events are essential for understanding user activity and detecting potential attacks.	Success
Audit IPsec Extended Mode	This security policy setting determines whether the operating system generates audit events for the results of the Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Extended Mode negotiations.	Not configured
Audit IPsec Main Mode	This security policy setting determines whether the operating system generates events for the results of the IKE protocol and AuthIP during Main Mode negotiations.	Not configured
Audit IPsec Quick Mode	This security policy setting determines whether the operating system generates audit events for the results of the IKE protocol and AuthIP during Quick Mode negotiations.	Not configured
Audit Logoff	This security policy setting determines whether the operating system generates audit events when logon sessions are terminated. These events occur on the computer that was accessed. In the case of an interactive logon, these would be generated on the computer that was logged on to. Logon events are essential to understanding user activity and detecting potential attacks. Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown taking place; in this case, a logoff event will not be generated.	Success Note There is no failure event in this subcategory because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record.
Audit Logon	This security policy setting determines whether the operating system generates audit events when a user attempts to log on to a computer. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a share, events are generated on the computer hosting the resource that was accessed. Logon events are essential to tracking user activity and detecting potential attacks.	Success for client computers Success and Failure for servers
Audit Network Policy Server	This security policy setting determines whether the operating system generates audit events for RADIUS (IAS) and Network Access Protection (NAP) activity on user access requests (Grant, Deny, Discard, Quarantine, Lock, and Unlock). NAP events can be used to understand the overall health of the network.	Success and Failure
Audit Other Logon/Logoff Events	This security policy setting determines whether the operating system generates audit events for other logon or logoff events, such as when a Remote Desktop session disconnects or connects, a workstation is locked or unlocked, a screen saver is invoked or dismissed, a user is granted access to a wireless network, a user is granted access to a wired 802.1x network, or a replay attack is detected. The latter indicates that a Kerberos protocol request was received twice with identical information. This condition could also be caused by network misconfiguration.	Not configured
Audit Special Logon	This security policy setting determines whether the operating system generates audit events when a special logon is used or a member of a special group logs on. A special logon is a logon that has administrator-equivalent privileges, and it can be used to elevate a process to a higher level. Special Groups is a Windows feature that enables the administrator to find out when a member of a certain group has logged on. The administrator can set a list of group security identifiers (SIDs) in the registry. If any of these SIDs is added to a token during logon and this auditing subcategory is enabled, a security event is logged. For more information about this feature, see article 947223 in the Microsoft Knowledge Base. Users who hold special privileges can potentially make changes to the system. It is recommended to track their activity.	Success

Audit object access

This security audit policy setting enables auditing of the event that is 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.

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.

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

If you do not configure the policy settings in this category selectively, 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 an object, such as a file, folder, printer, or registry key. After you enable the Audit object access policy, you must modify the SACLs of the objects that you want to monitor. 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 Windows Explorer or Group Policy.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Application Generated	This security policy setting determines whether the operating system generates audit events when applications attempt to use the Windows Auditing application programming interfaces (APIs) to create, delete, or initialize an application client context, or for application operations. The level, volume, relevance, and importance of these audit events depend on the application that is generating them. The operating system logs the events as they are generated by the application.	Not configured
Audit Certification Services	This security policy setting generates events when a wide variety of Active Directory Certificate Services (AD CS) operations are performed, such as when AD CS starts, shuts down, is backed up, or is restored; certificates are requested, issued, or revoked; and security permissions for AD CS role services are modified.	Not configured
Audit Detailed File Share	This security policy setting allows you to audit attempts to access files and folders on a shared folder. Detailed File Share audit events include detailed information about the permissions or other criteria that are used to grant or deny access. Note The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting only records one event for any connection that is established between a client computer and file share.	Not configured
Audit File Share	This security policy setting determines whether the operating system generates audit events when a shared folder is accessed. Audit events are not generated when shared folders are created, deleted, or when share folder permissions change. Combined with File System auditing, File Share auditing allows you to track what content was accessed, the source (IP address and port) of the request, and the user account that was used for access.	Not configured
Audit File System	This security policy setting determines whether the operating system audits user attempts to access file system objects. These events are essential for tracking activity for file objects that are sensitive or valuable, and these events require extra monitoring. Note Audit events are only generated for objects that have configured SACLs, and only if the type of access requested (such as Write, Read, or Modify) and the account that makes the request match the settings in the SACL.	Not configured
Audit Filtering Platform Connection	This security policy setting determines whether the operating system generates audit events when connections are allowed or blocked by the Windows Filtering Platform, such as when an application is blocked from accepting incoming connections, a connection is allowed or blocked, a binding to a local port is allowed or blocked, or an application or service is allowed or blocked from listening on a port for incoming connections.	Not configured
Audit Filtering Platform Packet Drop	This security policy setting allows you to audit packets that are dropped by the Windows Filtering Platform. A high rate of dropped packets may indicate attempts to gain unauthorized access to computers on your network.	Not configured
Audit Handle Manipulation	This security policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Enabling Audit Handle Manipulation also enables the logging of "reason for access" data within generated events. Only objects with configured SACLs generate these events, and only if the attempted handle operation matches the SACL. Note Handle Manipulation events are only generated for object types where the corresponding File System or Registry Object Access subcategory is enabled. For more information, see Audit File System or Audit Registry.	Not configured
Audit Kernel Object	This security policy setting allows you to audit attempts to access the system kernel, which include mutexes and semaphores. Only kernel objects with a matching SACL generate security audit events. Note The audits generated are usually only useful to developers.	Not configured
Audit Other Object Access Events	This security policy setting determines whether the operating system generates audit events for the management of Task Scheduler jobs or COM+ objects.	Not configured
Audit Registry	This security policy setting determines whether the operating system audits user attempts to access registry objects. Audit events are only generated for objects that have configured SACLs specified, and only if the type of access requested (such as Write, Read, or Modify) and the account that makes the request match the settings in the SACL.	Not configured
Audit SAM	This security policy setting allows you to audit events that are generated by attempts to access Security Accounts Manager (SAM) objects including SAM_ALIAS (a local group), SAM_GROUP (a group that is not a local group), SAM_USER (a user account), SAM_DOMAIN (a domain), and SAM_SERVER (a computer account).	Not configured

Audit policy change

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

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. Success audits are useful for accounting purposes, and they 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.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Audit Policy Change	This security policy setting determines whether the operating system generates audit events when changes are made to the audit policy, including permissions and audit settings on the audit policy object, changing the system audit policy, registration and de-registration of security event sources, changing per-user audit settings, changing the value of CrashOnAuditFail, and changing audit settings on an object.	Not configured
Audit Authentication Policy Change	This security policy setting determines whether the operating system generates audit events when changes are made to authentication policy, including creation, modification, and removal of forest and domain trusts; changes to the Kerberos protocol policy under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy, or namespace collision, such as when an added trust collides with an existing namespace name. In addition, audit events are logged when any of the following user rights are granted to a user or group: Access this computer from the network, Allow logon locally, Allow logon through Remote Desktop, Logon as a batch job, or Logon as a service. Note This setting is useful for tracking changes in domain and forest level trust and for privileges that are granted to user accounts or groups.	Success
Audit Authorization Policy Change	This security policy setting determines whether the operating system generates audit events when user rights are assigned or removed, and when the Encrypting File System (EFS) policy is changed.	Not configured
Audit Filtering Platform Policy Change	This security policy setting determines whether the operating system generates audit events for IPsec services status changes, changes to IPsec settings, changes to the Windows Filtering Platform engine and providers, and IPsec Policy Agent service activities.	Not configured
Audit MPSSVC Rule-Level Policy Change	This security policy setting determines whether the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe), which is used by Windows Firewall. The tracked activities include active policies when the Windows Firewall service starts; changes to the Windows Firewall settings, Group Policy settings, rules, and exception list; and rules ignored or not applied by the Windows Firewall service. Note Changes to firewall rules are important to understand the security state of the computer and how well it is protected against network attacks.	Not configured
Audit Other Policy Change Events	This security policy setting determines whether the operating system generates events for security policy changes that are not otherwise audited in the Policy Change category, such as Trusted Platform Module (TPM) configuration changes, kernel-mode cryptographic self-tests, and cryptographic provider operations.	Not configured

Audit privilege use

This category of audit 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.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit Sensitive Privilege Use	This security policy setting allows you to audit events that are generated when a privileged service is called or when sensitive user rights such as the following are used: Act as part of the operating system Back up files and directories Create a token object Debug programs Impersonate a client after authentication Manage auditing and security log Take ownership of files or other objects	Not configured
Audit Non-Sensitive Privilege Use	This security policy setting allows you to audit events that are generated by the use of non-sensitive user rights, such as: Access Credential Manager as a trusted caller Access this computer from the network Add workstations to the domain Allow log on locally Change the system time Force shutdown from a remote system Perform volume maintenance tasks	Not configured
Audit Other Privilege Use Events	This security policy setting is not used in this version of Windows.	Not configured

System

This category of audit policy settings enables auditing the restart or shutdown of users' computers, or events that affect either computer security or the Security log. For example, if malicious software tried to change a setting on your computer without your permission, System event auditing would record it.

Note

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 enable these policy settings on all computers in your organization.

The following table describes the settings that are included in this category and their default settings. For more information about the events that are generated by these settings, see the Security Audit Policy Reference.

Name	Description	Default setting
Audit IPsec Driver	This security policy setting determines whether the operating system audits the activities of the IPsec driver, and it reports any of the following events: Startup and shutdown of IPsec services Packets that are dropped due to integrity check failure Packets that are dropped due to replay check failure Packets that are dropped due to being in plaintext Packets that are received with an incorrect Security Parameter Index (SPI). (This can indicate malfunctioning hardware or interoperability problems.) Failure to process IPsec filters Security Note A high rate of packet drops by the IPsec filter driver may indicate attempts to gain access to the network by unauthorized systems.	Not configured
Audit Other System Events	This security policy setting determines whether the operating system audits the startup and shutdown of the Windows Firewall service and driver, security policy processing by the Windows Firewall service, and cryptography key file and migration operations.	Success and Failure
Audit Security State Change	This security policy setting determines whether the operating system audits changes in the security state of a system, and it reports system startup and shutdown, changes of system time, and system recovery from CrashOnAuditFail. Important Some auditable activity may not be recorded when a system reboots due to CrashOnAuditFail.	Success
Audit Security System Extension	This security policy setting determines whether the operating system audits events that are related to security system extensions. This can include when a security extension code is loaded (such as an authentication, notification, or security package). It also includes when a service is installed. An audit log is generated when a service is registered with the Service Control Manager. The audit log contains information about the service name, binary, type, start type, and service account. Important Attempts to install or load security system extensions or services that are critical system events that could indicate a security breach. These events are expected to appear more often on a domain controller than on client computers or member servers.	Not configured
Audit System Integrity	This security policy setting determines whether the operating system audits events that violate the integrity of the security subsystem, which can include any of the following events: Audited events are lost due to a failure of the auditing system. A process uses an invalid local procedure call (LPC) port in an attempt to impersonate a client computer, reply to a client computer’s address space, read to a client computer’s address space, or write from a client computer’s address space. A remote procedure call (RPC) integrity violation is detected. A code integrity violation with an invalid hash value of an executable file is detected. Cryptographic tasks are performed. Important Violations of security subsystem integrity are critical and could indicate a potential security attack.	Success and Failure

Global Object Access Auditing

Global Object Access Auditing policy settings allow administrators to define computer SACLs per object type for the file system or the registry. The specified SACL is then automatically applied to every object of that type.

Auditors will be able to prove that every resource in the system is protected by an audit policy by just viewing the contents of the Global Object Access Auditing policy settings. For example, the policy setting Track all changes made by group administrators shows that this policy is in effect.

Resource SACLs are also useful for diagnostic scenarios. For example, setting a Global Object Access Auditing policy setting to log all the activity for a specific user and enabling the Object Access audit policy for a resource (file system or registry) to track Access denied events can help administrators quickly identify which object in a system is denying a user access.

Note

If both a file or folder SACL and a Global Object Access Auditing policy setting (or a single registry setting SACL and a Global Object Access Auditing policy setting) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the Global Object Access Auditing policy. This means that an audit event is generated if an activity matches either the file or folder SACL or the Global Object Access Auditing policy.

The following table describes the settings that are included in this category and their default settings. For more information about using Global Object Access Auditing, see the Advanced Security Auditing Step-by-Step Guide.

Name	Description	Default setting
File System	This security policy setting allows you to configure a global SACL on the file system for an entire computer. Note This policy setting must be used in combination with the File System security policy setting under Object Access.	Not configured
Registry	This security policy setting allows you to configure a global SACL on the registry for a computer. Note This policy setting must be used in combination with the Registry security policy setting under Object Access.	Not configured

Additional references

The following links provide additional information about security audit policy settings:

• For more security audit policy information, see Security Auditingin the Windows Server 2008 and Windows Server 2008 R2 Technical Library.

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

• Security Audit Events for Windows 7 and Windows Server 2008 R2 is a downloadable reference spreadsheet that lists all events that appear in the Security log and are logged with a source of Security-Auditing.

• Article 947223 in the Microsoft Knowledge Base describes how to audit when members of identified special groups log on to the computer.