Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you have determined to be valuable in your risk assessment.
In this blog post, I discuss a common security audit policy configuration I come across in a number of environments (with special focus on Account Management). I also highlight the difference between basic and advanced security audit policy settings. Lastly, I point you to where recommendations that can help you fine-tune these policies can be obtained.
Background
It may appear that events relating to user account management activities in Active Directory (AD) are not logged in the security event logs on domain controllers (DC). This is an example of a view on one DC:
Here we see a lot of events from the Filtering Platform Packet Drop and Filtering Platform Connection subcategories - the image shows ten of these within the same second!
We see the following events on the same log about two minutes later (Directory Service Replication):
It can also be seen that there was an event relating to a successful Directory Service Access (DS Access) activity, but this is only one out of quite a bit!
Running the following command in an elevated prompt helps in figuring out what triggers these events:
auditpol /get /category:"DS Access,Object Access" The output below reveals that every subcategory in both the Policy Change and DS Access categories is set to capture success and failure events.
Note: running auditpol unelevated will result in the following error:
Error 0x00000522 occurred:
A required privilege is not held by the client.
To complete the picture, this is what it looked like in the Group Policy Editor:
Do we need all these security audit events? Let us look at what some of the recommendations are.
Security auditing recommendations
Guidance from tools such as the Security Compliance Manager (SCM) states that if audit settings are not configured, it can be difficult or impossible to determine what occurred during a security incident. However, if audit settings are configured so that events are generated for all activities the security log will be filled with data and hard to use. We need a good balance.
Let us take a closer look at these subcategories:
Filtering Platform Packet Drop
This subcategory reports when packets are dropped by Windows Filtering Platform (WFP). These events can be very high in volume. The default and recommended setting is no auditing on AD domain controllers.
Filtering Platform Connection
This subcategory reports when connections are allowed or blocked by WFP. These events can be high in volume. The default and recommended setting is no auditing on AD domain controllers.
Directory Service Replication
This subcategory reports when replication between two domain controllers begins and ends. The default and recommended setting is no auditing on AD domain controllers.
These descriptions and recommendations are from SCM but there is also the Policy Analyzer, which is part of the Microsoft Security Compliance Toolkit, you can look at using for guidance. There’s also this document if you do not have any of these tools installed.
- Audit Policy Recommendations
Tuning audit settings
Turning on everything – success and failures, is obviously not inline with security audit policy recommendations. If you have an environment that was built on Windows Server 2008 R2 or above, the advanced audit policy configuration is available to use in Group Policy.
Important
If you already have settings configured in the basic audit policy and want to start leveraging the advanced audit policy in order to benefit from granularity offered by the latter, you need to carefully plan for the migration.
In case you are wondering what I mean by granularity, see a comparison of the two below.
Basic Audit Policy Settings
In this example, I set the audit directory service access (DS Access) category to success:
Notice that all subcategories are affected as there is no granularity offered here (every subcategory is set to success):
Side note: take a look back at the Group Policy Management Editor window focusing on Audit Policy while we are here. Notice that audit policy change is set to no auditing instead of not defined. Here is the difference between the two:
- Not defined means that group policy does not enforce this setting – Windows (Server) will assume the default setting
- No auditing means that auditing is turned off – see example below
Advanced Audit Policy Settings
On the other hand, the advanced security audit policy does offer fine-grained control. The example below demonstrates granularity that could be realized when using the advanced security audit policies:
| Subcategory | Setting |
|---|---|
| Audit Detailed Directory Service Replication | No Auditing |
| Audit Directory Service Access | Success and Failure |
| Audit Directory Service Changes | Success |
| Audit Directory Service Replication | No Auditing |
The output of auditpol confirms expected the expected result:
The outcome
After turning off basic security audit policies and implementing the advanced settings based on the recommendations shared above, the security event logs start to make sense since a lot of the “noise” has been removed. We start seeing desired events logged in the security log as depicted below:
Keep in mind that these events are local to each DC, and that the event logs are configured to overwrite events as needed (oldest events first) by default. Solutions such as System Center Operations Manager Audit Collection Services can help capture, centralize and archive these events.
Till next time…