Maintaining a consistent and comprehensive auditing strategy for the Windows Server is an important part of any organization’s security plan. IT administrators have several choices at their disposal when it comes to auditing Windows Server; they can either deploy third-party solutions or make use of native methods. Whichever method you are using, there are few common mistakes that you should look to avoid. This article will help you overcome these common problems in the event that you encounter them.
Enabling “Audit Filtering Platform Connection”
While enabling all group policies in Auditing subcategories, make sure to read up about the consequences of enabling each “Object Accesses” policy. If enabled, a policy named “Audit Filtering Platform Connection” generates an unmanageably high volume of events. This security policy logs all events when connections are allowed or blocked by Windows Firewall and the Windows Filtering Platform. Even Microsoft recommends that you not configure this policy.
If this policy is enabled, multiple instances of the following event IDs are logged:
5031, 5140, 5150, 5151, 5154, 5155, 5156, 5157, 5158, 5159
If keeping track of all instances of all permitted or blocked connections with Windows Firewall and the Windows Filtering Platform is important to you, some third-party auditing solutions enable you to track this in a more efficient manner.
Configured Everything for Both Success and Failure
Instead of enabling logs for both success and failure events, it is recommended that you decide which type of event you want to record. For simply monitoring changes or accesses, you won’t need to record failure events. It’s important that you decide what’s best for your organization before you configure this option otherwise you may find yourself bombarded with an unmanageable number of irrelevant logs.
Maximum Log Size
Usually administrators set the event log size (100 MB by default) to 4 GB or more in order to record every single instance. However, event logs are memory-mapped files, which means that logging events in the Event Viewer consumes the same amount of RAM as the maximum event log size you have set. This essentially means that the 4 GB or more space is already occupied and this leaves you much less RAM with which to run the system.
Verification of Applied Audit Policies
In his blog post regarding viewing effective audit policies, Pyle Wisdom suggests not using the “GPRESULT /H” command to check the status of group policies. He suggests executing the “auditpol /get /category:*” command to view the effective audit policies.
Enabling Audit: Force audit policy subcategory settings
If you have enabled “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”, domain-based policies for computers running Windows Vista and Windows 2008 or higher will not be applied.
If this policy is still not enabled even after disabling it, you should follow this Microsoft Support KB article to make a slight change in the Windows Registry.
Change in Number of Digits
The security event IDs in Windows Server 2003 and Windows Server 2003 R2 have three digits only, but Windows Server 2008 and above have four. So if you are using a third-party auditor program, then make sure to configure it correctly as per this thumb rule.
Event Viewer Limitations
If you are using native auditing, the Event Viewer will be your only effective option for auditing logs. However, the Event Viewer does have some limitations. Sometimes multiple events are generated for a single action; such as renaming an object or moving an object to another container. Manually separating these logs can be a painful and time consuming process. There is no option to create categories of events with the same properties. because of this, the Event Viewer should not be looked at as the only auditing tool. Other auditing techniques, such as Windows PowerShell or third-party solutions, should also be considered.