Updated December 27, 2016
Windows Audit Policy is used to determine the verbosity of Windows Security Logs on domain controllers and other computers on the domain. The recommendations in this document have been found to be most effective from both a best practice and compliance standpoint and are based on customer experience and recommendations from Microsoft.
Setting Windows Audit Policy for use with the SolarWinds Log & Event Manager requires the following.
You can find relevant articles by searching for
audit policy best practice from the page linked above.
Audit account logon events
Logon events represent instances of users logging on to or logging off from a computer that is logging those events. Account logon events are specifically related to domain logon events and are logged in the security log for the related domain controller.
Audit account management
Account management events are the “change management” events on a computer. These events include all changes made to users, groups and machines.
Audit logon events
Logon events represent instances of users logging on to or logging off from a computer that is logging those events. Events in this category are logged in the security log of the local computer onto which the user is logging, even when the user is actually logging onto the domain using their local computer.
Audit object access
Object access events track users accessing objects that have their own system access control lists. Such objects include files, folders and printers.
Audit policy change
Policy change events represent instances in which local or group policy is changed. These changes include changes to user rights assignments, audit policies and trust policies.
Audit privilege use
Privilege use events track users accessing objects based on their level of privilege to do so. Such objects include files, folders and printers, or any object that has its own system access control list defined.
Audit process tracking
Process tracking logs all instances of process, service and program starts and stops. This can be useful to track both wanted and unwanted processes such as AV services and malicious programs, respectively.
Audit system events
System events include start up and shut down events on the computer logging them, along with events that affect the system’s security. These are operating system events and are only logged locally.
Windows Audit Policy is defined locally for each computer, but we recommend using Group Policy to manage the Audit Policy at both the domain controller and domain levels.
To set Windows Audit Policy using Group Policy Object Editor:
Select Success and Failure for all policies except:
For these, only select Failure.
Default Domain Policy applies to all computers on your domain except your domain controllers.
For this policy, select Success and Failure for the following:
You may also select Success and Failure for Audit process tracking to monitor critical processes such as the AV service or unauthorized programs such as games or malicious executable files.
Note: Enabling auditing at the level of Audit process tracking will significantly increase the number of events in the system logs. Therefore, Your LEM database will grow more quickly as it collects these logs. Similarly, there could be bandwidth implications as well. This is wholly dependent upon your network’s traffic volume and bandwidth capacity. Since agent traffic is transmitted to the manager as a real time “trickle” of data, bandwidth impact is typically minimal
Changing from Category-Level Auditing to Sub-Category Auditing
With Windows 2008 and newer operating systems, Microsoft introduced sub-category auditing. Enabling auditing at the category-level will automatically enable all sub-categories. This can result in a higher than expected auditing level. Enabling the sub-category-level auditing will automatically disable the category-level auditing and allow you to fine tune the auditing. Before enabling the subcategory, we recommend setting the sub-category auditing before enabling the sub-category. We provide the PCI auditing settings as a reference, and you can adjust to meet your auditing requirements or to fulfill your auditing preferences.
Open the Group Policy Management Console (or gpedit.msc if not using AD), and go to:
To change the sub-category settings:
Computer-Configuration > Windows-Settings > Security-Settings > Advanced Audit Policy Configuration
To enable the sub-category auditing (which disables the category-level auditing):
Computer-Configuration > Windows-Settings > Security-Settings > Local-Policies > Security-Options > Audit:Force-audit-policy-subcategory-settings ==> enabled
Category / Subcategory
|Security System Extension||No Auditing|
|System Integrity||Success and Failure|
|IPsec Driver||No Auditing|
|Other System Events||No Auditing|
|Security State Change||Success and Failure|
|Logon||Success and Failure|
|Logoff||Success and Failure|
|Account Lockout||Success and Failure|
|IPsec Main Mode||No Auditing|
|IPsec Quick Mode||No Auditing|
|IPsec Extended Mode||No Auditing|
|Special Logon||Success and Failure|
|Other Logon/Logoff Events||Success and Failure|
|Network Policy Server||No Auditing|
|File System||Success and Failure|
|Registry||Success and Failure|
|Kernel Object||No Auditing|
|Certification Services||No Auditing|
|Application Generated||No Auditing|
|Handle Manipulation||No Auditing|
|File Share||Success and Failure|
|Filtering Platform Packet Drop||No Auditing|
|Filtering Platform Connection||No Auditing|
|Other Object Access Events||No Auditing|
|Detailed File Share||No Auditing|
|Sensitive Privilege Use||Failure|
|Non Sensitive Privilege Use||No Auditing|
|Other Privilege Use Events||No Auditing|
|Process Termination||No Auditing|
|DPAPI Activity||No Auditing|
|RPC Events||No Auditing|
|Process Creation||No Auditing|
|Audit Policy Change||Success and Failure|
|Authentication Policy Change||Success and Failure|
|Authorization Policy Change||Success and Failure|
|MPSSVC Rule-Level Policy Change||No Auditing|
|Filtering Platform Policy Change||No Auditing|
|Other Policy Change Events||Success and Failure|
|User Account Management||Success and Failure|
|Computer Account Management||Success and Failure|
|Security Group Management||Success and Failure|
|Distribution Group Management||Success and Failure|
|Application Group Management||Success and Failure|
|Other Account Management Events||Success and Failure|
|Directory Service Changes||No Auditing|
|Directory Service Replication||No Auditing|
|Detailed Directory Service Replication||No Auditing|
|Directory Service Access||Failure|
|Kerberos Service Ticket Operations||Success and Failure|
|Other Account Logon Events||Success and Failure|
|Kerberos Authentication Service||Success and Failure|
|Credential Validation||Success and Failure|
Note: The above auditing includes disabling 9 of the sub-categories that create noise from Windows Filtering Platform. Not disabling this 'noise' can cause in a higher level of events being sent to the LEM, rules firing needlessly, the need for increased resource reservations in the LEM, and excessive number of events logged internally in the Windows security event log.
Dropping events at the entrance to the LEM
Some auditing can be dropped as the event is received by the LEM. Dropping events at the LEM will still require resources on the LEM to accomplish this task, and we advise caution to avoid failing auditing requirements. An example of events that might be dropped would be the Machine Logon and Machine Logoff (if allowed by auditing requirements).
Open the LEM GUI-console, select Manage > Appliances, and select Policy from the gear on the left.
Machine Logon ==> Generic Alert > Audit Alert > Auth Audit > Machine Auth Audit > Machine Logon
Machine Logoff ==> Generic Alert > Audit Alert > Auth Audit > Machine Auth Audit > Machine Logoff
Machine Auth Ticket ==> Generic Alert > Audit Alert > Auth Audit > Machine Auth Audit > Machine Auth Ticket
uncheck the check boxes for the following => console / database / warehouse / rules
Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment. You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.