Well, this sorry tale started with a desire to enable the Windows firewall on our domain controllers. I'll leave that part of the story for another day, but it did throw up and interesting issue that Microsoft agrees is a bug. I started to see event 5152 filling my domain controller's security event log which appeared to indicate that inbound LDAP packets were being dropped by the firewall. This was obviously a concern. Here is an appropriately redacted example event (note the highlighted port 389 which is (unsecure) LDAP).
Log Name: Security
Date: 12/29/2014 10:23:53 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Keywords: Audit Failure
The Windows Filtering Platform has blocked a packet.
Process ID: 0
Application Name: -
Source Address: 10.150.93.168
Source Port: 50030
Destination Address: 10.20.66.216
Destination Port: 389
Filter Run-Time ID: 540039
Layer Name: Transport
Layer Run-Time ID: 13
When the issue was raised with Microsoft, it appears that this is incorrect. Here is their response:
The packet drop events are being generated as part of a set of “built-in” stealth filters. These stealth filters were introduced in Vista/2008 to ward off port-scanning attacks. Their purpose is to prevent outbound responses (such as TCP resets) to inbound packets sent for the purpose of port IP and port discovery. The 5152 events are misleading in this way because from the text they seem to indicate the INBOUND packet was dropped, when really, it was the OUTBOUND packet that was dropped. Our product team concurs that is just an idiosyncrasy of the implementation. When an inbound packet triggers a reset, the stack classifies the packet against the INBOUND_TRANSPORT_V4_DISCARD layers to determine if the reset should be sent. So in this case, “inbound” really means that the drop occurred during the processing of an inbound packet and before the outbound reset was even generated.
So, armed with this information I was advised that he only course of action was to filter out this white noise by adjusting the auditing settings. This meant using the following policy node scoped to the domain controllers (I used my default domain controller policy):
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policy\Object Access
Specifically, the setting: Audit Filtering Platform Packet Drop and setting it to No Auditing. Now, to be clear, it is more usual to manage auditing with the following (less granular node):
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies
Well then some interesting things happened. The domain controllers started to act like all the auditing was disabled which had various effects in my environment. It turns out that as soon as you configure anything in the more granular advanced section, all settings in the regular section are ignored.
There is an excellent article written by Ned Pyle here:
I don't consider it appropriate to copy-n-paste his words into this blog, but go read it. It also makes it clear that trying to use RSOP to troubleshoot this issue will not work as RSOP is deprecated and in any case, only reads from the data controlled by the regular policy node. The only true way to know what all the audit policies are, is by issuing the following command:
auditpol /get /category:*
The solution is to recreate all the settings from the regular node into the more granular node. If I had time I would try and create a cross walk between each regular setting and the collection of more granular settings that it equates to, but I might have to leave that to someone else.