Advanced security auditing FAQ

Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is the features and services for an administrator to log and review events for specified security-related activities.

Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks. Monitoring these events can provide valuable information to help administrators troubleshoot and investigate security-related activities.

The basic security audit policy settings in Security Settings\Local Policies\Audit Policy and the advanced security audit policy settings in Security Settings\Advanced Audit Policy Configuration\System Audit Policies appear to overlap, but they're recorded and applied differently. When you apply basic audit policy settings to the local computer by using the Local Security Policy snap-in (secpol.msc), you're editing the effective audit policy. Changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe.

There are several other differences between the security audit policy settings in these two locations.

There are nine basic audit policy settings under Security Settings\Local Policies\Audit Policy and settings under Advanced Audit Policy Configuration. The settings available in Security Settings\Advanced Audit Policy Configuration address similar issues as the nine basic settings in Local Policies\Audit Policy, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account sign-in, and the advanced audit policy provides four. Enabling the single basic setting would be the equivalent of setting all four advanced settings. In comparison, setting a single advanced audit policy setting doesn't generate audit events for activities that you aren't interested in tracking.

In addition, if you enable success auditing for the basic Audit account logon events setting, only success events will be logged for all account sign-in activities. In comparison, depending on the needs of your organization, you can configure success auditing for one advanced account logon setting, failure auditing for a second advanced account logon setting, success and failure auditing for a third advanced account logon setting, or no auditing.

The nine basic settings under Security Settings\Local Policies\Audit Policy and the advanced audit policy settings are available in all supported versions of Windows.

Basic audit policy settings aren't compatible with advanced audit policy settings that are applied by using group policy. When advanced audit policy settings are applied by using group policy, the current computer's audit policy settings are cleared before the resulting advanced audit policy settings are applied. After you apply advanced audit policy settings by using group policy, you can only reliably set system audit policy for the computer by using the advanced audit policy settings.

Editing and applying the advanced audit policy settings in Local Security Policy modifies the local group policy object (GPO). If there are policies from other domain GPOs or logon scripts, changes made here may not be exactly reflected in Auditpol.exe. Both types of policies can be edited and applied by using domain GPOs, and these settings will override any conflicting local audit policy settings. Because the basic audit policy is recorded in the effective audit policy, that audit policy must be explicitly removed when a change is desired, or it will remain in the effective audit policy. Policy changes that are applied by using local or domain group policy settings are reflected as soon as the new policy is applied.

If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the Audit: Force audit policy subcategory settings to override audit policy category settings policy setting under Local Policies\Security Options. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.

By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked at a lower level.

For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of extra settings. To accomplish this customization, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level. The only exception is if you take special steps to apply group policy loopback processing.

The rules that govern how group policy settings are applied propagate to the subcategory level of audit policy settings. This coverage means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.

All objects in Active Directory Domain Services (AD DS), and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object's security descriptor can contain two types of ACLs:

• A discretionary access control list (DACL) that identifies the users and groups who are allowed or denied access
• A system access control list (SACL) that controls how access is audited

The access control model that is used in Windows is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.

If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing isn't configured entirely unless a SACL has been configured for an object and a corresponding Object Access audit policy setting has been configured and applied.

In security auditing in Windows, the computer, objects on the computer, and related resources are the primary recipients of actions by clients including applications, other computers, and users. In a security breach, malicious users can use alternate credentials to hide their identity, or malicious applications can impersonate legitimate users to perform undesired tasks. Therefore, the most consistent way to apply an audit policy is to focus on the computer and the objects and resources on that computer.

Audit policy capabilities can vary between computers running different versions of Windows. The best way to make sure that the audit policy is applied correctly is to base these settings on the computer instead of the user.

However, when you want audit settings to apply only to specified groups of users, you can accomplish this customization by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This configuration results in an audit of attempts by members of the Payroll Processors OU to delete objects from this folder. The Object Access\Audit File System audit policy setting applies to Accounting Server 1. Because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.

No. Basic and advanced audit policy settings are available in all supported versions of Windows. They can be configured and applied by local or domain group policy settings.

A success audit event is triggered when a defined action, such as accessing a file share, is completed successfully.

A failure audit event is triggered when a defined action, such as a user sign-in, isn't completed successfully.

The appearance of failure audit events in the event log doesn't necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may mean that a user mistyped the password.

System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This requirement has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.

Security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This application of SACL can be useful for verifying that all critical files, folders, and registry settings on a computer are protected. It's also useful to identify when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy 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 behavior also applies to a single registry setting SACL and a global object access auditing policy. This resultant SACL from the combination means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.

Often it isn't enough to know simply that an object such as a file or folder was accessed. You may also want to know why the user was able to access this resource. You can obtain this forensic data by configuring the Audit Handle Manipulation setting with the Audit File System or with the Audit Registry audit setting.

To track access control changes, you need to enable the following settings, which track changes to DACLs:

• Audit File System subcategory: Enable for success, failure, or success and failure
• Audit Authorization Policy Change setting: Enable for success, failure, or success and failure
• A SACL with Write and Take ownership permissions: Apply to the object that you want to monitor

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

1. Set all Advanced Audit Policy subcategories to Not configured.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
3. Reconfigure and apply the basic audit policy settings.

Unless you complete all of these steps, the basic audit policy settings won't be restored.

Changes to security audit policies are critical security events. You can use the Audit Audit Policy Change setting to determine if the operating system generates audit events when the following types of activities take place:

• Permissions and audit settings on the audit policy object are changed
• The system audit policy is changed
• Security event sources are registered or unregistered
• Per-user audit settings are changed
• The value of CrashOnAuditFail is modified
• Audit settings on a file or registry key are changed
• A Special Groups list is changed

Finding the right balance between auditing enough network and computer activity and auditing too little network and computer activity can be challenging. You can achieve this balance by identifying the most important resources, critical activities, and users or groups of users. Then design a security audit policy that targets these resources, activities, and users. Useful guidelines and recommendations for developing an effective security auditing strategy can be found in Planning and deploying advanced security audit policies.

The integration of advanced audit policy settings with domain is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy group policy objects for a domain can also be used to plan and deploy security audit policies. On an individual computer, the Auditpol command-line tool can be used to complete many important audit policy-related management tasks.

There are also other computer management products, such as the Audit Collection Services in System Center Operations Manager, which can be used to collect and filter event data. For more information, see How to install an Audit Collection Services (ACS) collector and database.

Users who examine the security event log for the first time can be a bit overwhelmed. The number of audit events that are stored there can quickly number in the thousands. The structured information that's included for each audit event can also be confusing. For more information about these events, and the settings used to generate them, see the following resources:

• Windows security audit events
• Windows 10 and Windows Server 2016 security auditing and monitoring reference
• Advanced security audit policy settings

To learn more about security audit policies, see the following resources:

• Planning and deploying advanced security audit policies
• Windows 8 and Windows Server 2012 security event details
• Security audit events for Windows 7 and Windows Server 2008 R2