The Security Log Haystack – Event Forwarding and You
Hi. This is your guest writer Mark Renoden. I’m a Senior Premier Field Engineer based in Sydney, Australia and I’m going to talk to you about the use of Event Forwarding to collect security events. This is particularly useful when:
- You have specific events you’re looking for (e.g. account lock out investigations)
- You have an aggressive audit policy resulting in rapid security event log roll over
- You have a lot of servers (and therefore logs) to watch
Historically, you’d use a tool like EventCombMT to skim the security logs across your servers for the events of interest but in the case where security event logs quickly roll over, it might come too late.
I'll take the account lock out example. Before I dive into the details of Event Forwarding, there’s some preparation you need to do first. These steps are different for Windows Server 2003, and Windows Server 2008/2008 R2.
Preparing Windows Server 2003 SP2
I’ll show you how to prepare your Windows Server 2003 machines so you’re able to collect security events from them.
1. Make sure you have the Windows Firewall/Internet Connection Sharing (ICS) service started and configured to start automatically.
This doesn’t mean you need the firewall configured – only that you have the service running which is required for the Windows Event Collector service. For example, your Windows Firewall/Internet Connection Sharing (ICS) service can be running but your firewall can be off.
2. Download and install the Windows Remote Management package from
https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21900
3. Grant the Network Service account READ access to the security event log by appending (A;;0x1;;;NS) to the following registry value:
Key: HKLM/SYSTEM/CurrentControlSet/Services/EventLog/Security
Value: CustomSD
For example, the default security descriptor with READ for the Network Service appended is:
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;NS)
The CustomSD registry value accepts a security descriptor using the Security Descriptor Definition Language (SDDL). You can read more about SDDL here:
https://msdn.microsoft.com/en-us/library/aa379567(v=VS.85).aspx
You can deploy this step on a larger scale using Group Policy as detailed in:
How to set event log security locally or by using Group Policy in Windows Server 2003
https://support.microsoft.com/kb/323076/en-auFor Windows Server 2008 or later, you can also use Group Policy Preferences to deploy registry settings
Information about new Group Policy preferences in Windows Server 2008
https://support.microsoft.com/kb/943729
Preparing Windows Server 2008 and Windows Server 2008 R2
Just like Windows Server 2003, you have to prepare your Windows Server 2008/2008 R2 machines for collection of security events. To do this, simply add the Network Service account to the Built-in Event Log Readers group.
If instead, you’d like to be more specific and restrict Network Service account READ access to just the security event log, you can modify the security event log security descriptor as follows.
1. Open up a command prompt and run:
wevtutil gl security
This command tells you the current security descriptor for the security event log – specifically in the channelAccess value. The default value is:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
Again, you want to append read access for the Network Service. In my example, your new security descriptor will be:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
2. At the same command prompt, run:
wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
Note: This is all one command on the same line.
Configure the Member Server to Collect Events
Now that your server (in my example the Domain Controllers) configuration is complete, you need to configure the member server as the collection point.
1. On the member server that will be collecting the events, open a command prompt and run:
winrm qc
wecutil qc
Answer YES to any prompts you see.
The first command (winrm qc) configures the member server to accept WS-Management requests from other machines while the second command (wecutil qc) configures the Windows Event Collector service.
2. At the same command prompt, execute the following command and record the port:
winrm enumerate winrm/config/listener
3. Open the Event Viewer
4. In the left-hand pane, click Subscriptions, then right-click Subscriptions and then left-click Create Subscription.
5. Specify a subscription name and then select Source computer initiated.
6. Click Select Computer Groups…
7. Click Add Domain Computers… and specify Domain Controllers (or a security group that includes the servers you’re interested in).
8. Click OK and OK.
9. Back on the Subscription Properties screen, click Select Events… and specify the events you wish to capture.
In my example, I’m looking for logon failures leading to account lockouts. These are logged as event 675 on Windows Server 2003 and event 4771 on Windows Server 2008 / 2008 R2.
10. Click OK.
11. Back ok the Subscription Properties screen, click Advanced… and choose Minimize Latency.
12. Click OK and then OK to close the Subscription Properties screen.
13. Open a command prompt, run:
wecutil ss <subscription name> /cm:Custom /dmi:1
Note: This step is only necessary if event collection is time critical.
Policy for Event Forwarding
Having prepared the servers for collection of security events, you now require a Group Policy Object applied to them. This GPO will specify the member server (running Windows Server 2008 or later) where events are collected.
You must create and edit the GPO from a Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2 system. These are the only operating systems that provide policy settings for Windows Remote Management and Event Forwarding.
In my example, I want security events collected from my Domain Controllers. My member server is member.contoso.com running Windows Server 2008 R2.
1. Open the Group Policy Management Console (GPMC), create a new GPO and link it to the Domain Controllers OU.
2. Right-click the new GPO and open it for editing.
3. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service
4. In the right-hand pane, open Allow automatic configuration of listeners.
5. Set the policy to Enabled and set the IPv4 and IPv6 filters to * .
6. Click OK.
7. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Event Forwarding
8. In the right-hand pane, open Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager.
9. Set the policy to Enabled and click Show… .
10. Add the value Server=<member_server>:<port> where <port> is the port recorded earlier.
11. Click OK and OK.
12. Close the GPO editor.
13. Restart the Windows Remote Management (WS-Management) service on the Domain Controllers.
14. Wait. You need to be patient. Group Policy has to apply, the Windows Remote Management (WS-Management) service on the Domain Controllers has to pick up those policy settings and the Windows Event Collector service on the member server has to start talking to the DCs.
Once all of that settles down, you’ll see the events in the Forwarded Events log on the member server.
Conclusion
Now you’re fully prepared to nail down those troublesome problems in environments with high churn security logs!
- Mark ”If it’s there I’ll find it” Renoden
Comments
Anonymous
August 29, 2011
I had done this about a year ago with my 2003 DCs. It was a pain. I am very happy to see this published and all in one place. Allan "You better get busy then" MillerAnonymous
August 29, 2011
Awesome post... Event Forwarding is your friend! For anyone interested, you can couple Event Forwarding with PowerShell to essentially get a "poor mans" auditing utility. Basically forwarding then parsing data from Security log audit events into SQL for alerting and reporting. Definitely not looking to self promote, but thought I'd share if anyone can find it useful. I know it has definitely come in very handy around here, so hopefully someone else can find some use of the work. Please don't use the comments here for any troubleshooting or assistance if you decide to use the module. Anything additional regarding the utility should be posted at the CodePlex link... pseventlogwatcher.codeplex.com/documentation Thanks! SteveAnonymous
September 28, 2014
The Security Log Haystack – Event Forwarding and You - Ask the Directory Services Team - Site Home - TechNet BlogsAnonymous
October 12, 2014
The Security Log Haystack – Event Forwarding and You - Ask the Directory Services Team - Site Home - TechNet Blogs