WEC in an Active Directory Environment

In the preceding sections we’ve introduced each of the individual components comprising WEC.  Here we will provide an overall treatment of event flow from beginning to end, showing the interplay between collectors, forwarders, subscriptions and event logs.  First, we will explore event flow in a typical AD environment and then in a non-domain environment.  In both scenarios we start with the configuration steps and then follow with the resulting flow of events.

Starting with an AD environment where all the collectors and forwarders are within the same trusted domain scope, meaning that there can be multiple domains and forests, but they all trust each other.

Setup

• Designate a Windows server as the collector and configure it
  • Run “winrm qc”
  • Run “Wecutil qc”
• Determine which computers will be forwarding events to the collector
  • Do you need to create a group in AD and populate it with those computer accounts?
    • Remember those computers will need to reboot after applying the group policy change for the group membership change to take effect
• If not using Forwarded Events as destination, create a custom event log (see Creating Custom Event Logs for WEC Destinations)
• Create a source-initiated subscription with
  • One or more computer accounts or groups from AD (local domain of the collector or any other trusted domain)
  • Destination log set to Forwarded Events or  the event log created in the previous stepXpath query filter specifying which logs to collect from each forwarder
• Configure a group policy object (GPO) which will be applied to  all the computers specified in the subscription (the GPO can be applied to additional computers but only those computers specified in the subscription will actually send events).  The GPO(s) should define
  • An entry for the collector in the Target Subscription Manager policy
  • WinRM system service to automatically start

• Grant the Network Service Read access to the Security Log (if the subscription sources events from the Security log)

See Forwarder Not Sending Security Log Events Because of Permissions

• Setup consumption of the destination logs by downstream SIEMs or log management solutions

Event Flow

When a given forwarder computer next applies group policy, it will configure the WinRM service to automatically start.  Once the computer reboots or is otherwise commanded to start the WinRM service, it will take notice of the target subscription manager also defined in the GPO and connect to the collector via WinRM and Kerberos. 

The forwarder will subscribe to all subscriptions on that collector where its computer account is indicated according to the include/exclude entries on the subscription.  It will recheck for subscription changes as defined by the Refresh= parameter in the target subscription manager entry. 

If the subscription specifies “send existing events”, the forwarder will start with the oldest events and forward all the applicable history of events matching the criteria in the xpath filter until caught up.  If the subscription specifies sending only new events, the forwarder will start sending matching events as they occur according to the frequency and batching specified on the subscription.  If the forward has no events to send, it will still notify the subscription that it is still active according to the subscription’s heart beat interval.

If a forwarder is disconnected from the collector or is shutdown for a time, when the forwarder’s local WinRM service reconnects to the collector, it refreshes which subscriptions still apply to it and begins sending events where it left off.  This is possible because the collector maintains a registry entry for each forwarder of each subscription that includes a bookmark recording the last record number of each source event log.  This record number is a forward only counter that always increments even if events age out of the source event log or if the source event log is cleared. 

What if you change the xpath query filter on a subscription to which a forwarder is already subscribed?  The forwarder will see the change and resubscribe, treating it as a new subscription and either reforward events or begin forwarding new events as described above.  The same applies if you change the allowed forwarder entries so that a forward is excluded and then re-included to a subscription.

WEC is highly reliable, even in heavily loaded conditions and with unexpected interruptions, to send each event once and only once despite network outages or other interruptions. 

The only scenarios we have identified where Windows Event Fowarding (WEC) can lose events occurs

• if a given forwarder is interrupted long enough for unforwarded events to age out of the log based on the log’s retention settings and its maximum size.  If you configure a large enough maximum log size (such as 200MB) on forwarders using group policy or Intune, you can greatly limit the chance of losing events.  These settings can be managed via group policy and Intune.
• An existing subscription is modified, causing a forwarder to resubscribe when it was also not fully caught up with sending events.

These are edge cases and can largely be avoided by reasonable log retention, maximum log size and by erring on the side of more and simpler subscriptions rather than trying to specify one big subscription that covers multiple event logs and types of events.

The foregoing describes a single collector scenario.  To stand up multiple collectors it’s simply a matter of adding entries to the target subscription manager policies and defining the desired subscriptions on each collector.  Forwarders will check in with each collector based on the refresh interval in the subscription manager setting and subscribe/unsubscribe according to newly created, modified or deleted subscriptions.

---

Manage, Scale and Heal Windows Event Collection with Supercharger
Download • Enterprise Pricing • Ask Sales