Posted on November 2, 2016 · Posted in Windows Server 2012

Auditing Windows Server: Common mistakes and how to avoid them

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.

gpo audit policies: object access

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.

max security event log size

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.

Conclusion

Whilst auditing Windows Server you may find yourself experiencing any of the above common problems. Hopefully this guide will have given you some advice to avoiding them. If the problems persist then you may find it makes more sense to deploy an automated third-party solution. These solutions, like LepideAuditor Suite, take the manual processes and automate them in order to give you the easiest auditing experience possible.

 

Previous:
Next:
Related Articles