SC-200 Windows Security Events in Microsoft Sentinel: AMA, DCRs and WEF

Pick the connector by the Windows log you need and by where the agent may run: Windows Security Events via AMA for the Security log of machines that can run the Azure Monitor Agent, Windows Forwarded Events via AMA for events gathered on a Windows Event Collector through Windows Event Forwarding (WEF), and the specialised AMA connectors for DNS and firewall logs. All of them use the Azure Monitor Agent (AMA) and a data collection rule (DCR). The Log Analytics agent (MMA) was retired in August 2024, so the Security Events via Legacy Agent connector is not a current choice; its replacement is Windows Security Events via AMA, which writes to the same SecurityEvent table so existing content keeps working.

Two constraints decide most connector questions. If the built-in Windows security analytics rules must work unchanged, the data has to land in SecurityEvent, which points to Windows Security Events via AMA. If no agent may be installed on the endpoints, only WEF to a collector running AMA meets it. Defender for Endpoint onboarding is not a substitute: its telemetry lands in Defender XDR tables such as DeviceEvents and DeviceLogonEvents, not in the Security event log tables. Syslog, CEF, Azure activity and custom-log connectors are covered in the lesson on ingesting Syslog, CEF, Azure activity, threat indicators and custom logs.

You enable Windows Security Events via AMA from its connector page (installed with the Windows Security Events solution from the Content hub) by creating a data collection rule, choosing the machines it applies to and choosing which events it collects; the wizard installs the Azure Monitor Agent on any selected machine that lacks it.

• Which machines appear. The Resources tab lists only Azure virtual machines, scale sets and Azure Arc-enabled servers. An on-premises or other-cloud server must be onboarded to Azure Arc first, because a DCR is associated with an Azure resource and Arc is what turns a non-Azure machine into one. Azure VMs never need Arc. Eligibility comes only from being an Azure resource, so installing some other agent or sensor does not add a server to the list, and this Security log flow needs no data collection endpoint.
• Where the rule lives. The DCR can be created in any subscription and resource group in the tenant; it does not have to sit with the machines or in the workspace's resource group. Azure Monitor does require a DCR that sends to a Log Analytics workspace to be in that workspace's region.
• Associations, not scopes. Selecting a subscription or resource group in the wizard associates the rule with the machines found there at that moment. A VM created later gets no association and sends nothing.
• Covering future machines. Assign Microsoft's built-in Azure Policy initiative that deploys the Azure Monitor Agent and associates a specified DCR. Policy acts every time a VM, scale set or Arc-enabled server is created, and a remediation task applies it to machines that already exist. Because the wizard's associations are a one-time snapshot, policy is what keeps coverage current without manual work.

The connector offers three pre-built event sets drawn from the Security and AppLocker logs (All events, Common and Minimal) plus Custom, where you write your own XPath filters; the set you choose decides both what you can detect and what you pay to ingest.

The sets nest: every Minimal event ID is also in Common, and both are drawn from the Security and AppLocker logs that All events collects in full. Because every pre-built set comes from the Security and AppLocker channels, none of them collects the System, Application or Setup logs. A System event such as service installation 7045 needs a Custom XPath on the System channel. When events exist in Event Viewer but never reach SecurityEvent and no custom filter is in place, compare the missing event IDs with the contents of the set the rule uses: the set definition, not the agent, decides what is sent.

A custom filter in a DCR is written as LogName!XPathQuery: the Windows event channel name, an exclamation point, then an XPath 1.0 query; when XPath cannot express a filter, a KQL transformation in the same DCR can filter rows before they are stored.

Security!*[System[(EventID=4624 or EventID=4625)]]
System!*[System[(EventID=7045)]]

• The left side is the channel the agent subscribes to (Security, System, Microsoft-Windows-AppLocker/EXE and DLL), never the workspace table name such as SecurityEvent.
• To match either of two IDs use or; an event has one ID, so and between two IDs matches nothing.
• Microsoft documents a limit of 20 expressions in one box; add further entries rather than packing more into one.
• The agent supports XPath 1.0 only, and the Windows event log implements a subset of it. String functions such as contains() and starts-with(), and XPath 2.0 functions such as matches(), are rejected; equality tests on System and EventData fields work, so an exact match on a full value (for example a fixed NewProcessName path) is the XPath way to narrow events.
• Analytic and Debug channels cannot be collected by Windows event collection, because the agent uses the EvtSubscribe API, which cannot subscribe to them.

Test before you deploy on a Windows machine with Get-WinEvent -LogName 'Security' -FilterXPath '*[System[(EventID=4625)]]' (drop the Security! prefix and pass the log name separately). Returned events mean the query is valid; "No events were found" can still be a valid query that matched nothing; "The specified query is invalid" means a syntax or unsupported-function error. Only a command that evaluates the XPath string itself, as -FilterXPath does, validates it; other ways of listing events can return similar results without testing your expression.

Transformations handle what XPath can't. DCRs created by the Sentinel AMA connectors support an ingestion-time KQL transformation that runs in the pipeline before storage, so dropped rows are never billed. For example, to keep only process-creation events with an encoded command line while passing every other event:

source
| where EventID != 4688 or CommandLine contains "-enc"

Filtering after storage does not cut ingestion: scheduled analytics rules and summary rules read data that has already been ingested and paid for.

The table is decided by the DCR stream, not by the log the event came from: the Sentinel connector's Microsoft-SecurityEvent stream writes to SecurityEvent, a generic Azure Monitor Windows event data source uses Microsoft-Event and writes to Event, and forwarded events use Microsoft-WindowsEvent and write to WindowsEvent.

This is a common trap: an administrator builds a DCR from Azure Monitor that collects the Security log, records arrive, yet Sentinel's built-in Windows rules never fire, because the data is in Event. Recreating the collection through the Windows Security Events via AMA connector (same agent, different stream) fixes it, because the stream, not the filter or the machine, sets the table. When you deploy DCRs by ARM template or the REST API, as an MSSP might, put Microsoft-SecurityEvent in both the windowsEventLogs data source and the data flow.

Every collector that reads the same events and sends them to the same workspace uploads its own copy, so overlapping DCR associations or two agents running side by side double the ingestion bill.

• Overlapping DCRs. A machine can be associated with several DCRs and each collects what it defines. If two teams both associate a Common-set rule with the same servers and workspace, SecurityEvent doubles. The least-effort fix is to delete one rule's association with those servers. Any event both rules still select is collected twice, so the fix has to remove the overlap, not just narrow one rule; where a rule is stored has no effect on what it collects.
• MMA to AMA migration. While the Log Analytics agent and AMA both collect the Security log to one workspace, every record appears twice. Microsoft's guidance is to pilot AMA, avoid double ingestion during testing by removing the legacy agent's workspace configuration, and uninstall the Log Analytics agent from each machine once AMA is validated.
• Multiple destinations. One DCR with two workspace destinations stores and bills the data in both.

Windows Event Forwarding is the Windows-native way to collect events from many machines without installing an agent on them: sources use the built-in forwarding client, configured by Group Policy, to send events over WinRM to a Windows Event Collector (WEC) server, and only that collector runs the Azure Monitor Agent with the Windows Forwarded Events connector.

Choose WEF when change control forbids agents (including the Azure Arc Connected Machine agent) on endpoints such as thousands of workstations, when you already run a WEF infrastructure, or when endpoints can't reach Azure directly. The Windows Forwarded Events connector's prerequisites are the Windows Event Collector service enabled and running on the collector and AMA installed there; the connector's DCR reads the collector's ForwardedEvents log and you can filter it with XPath like any other DCR. Group Policy only configures the sources; the collector is the one machine that needs the agent.

The trade-off is the destination table: forwarded events go to WindowsEvent, so content written for SecurityEvent needs adapting (see the last section). A common hybrid is AMA on servers (SecurityEvent) and WEF for workstations (WindowsEvent).

A WEF deployment needs three things on every source (the collector's URI, a running WinRM service and permission to read the Security log) and, on the collector, subscriptions that say which machines may participate and which events to send.

Minimum source configuration (by GPO)

1. Configure Configure target Subscription Manager with the collector's URI.
2. Set the Windows Remote Management (WinRM) service to start automatically.
3. Add Network Service to the local Event Log Readers group. The forwarding client runs as Network Service, and without this membership it can forward System and Application events but not the secured Security channel, which is the classic "everything except Security arrives" symptom.

The Windows Event Collector service runs on the collector, not on sources, and sources need no AMA.

Subscription types

To restrict a source-initiated subscription to domain controllers when GPO points every server at the collector, put a group of the DCs' computer accounts in that subscription's ACL. The subscription ACL, evaluated against computer accounts, is what decides which sources take part. By default a subscription forwards only events generated after the source received it; enable read existing events when you need history, as Microsoft suggests for targeted subscriptions on suspect devices.

In a domain WEF is already mutually authenticated and encrypted with Kerberos, delivery timing is set per subscription by its delivery optimization mode, and each collector handles roughly 3,000 events per second, so large fleets are scaled out across several collectors.

Authentication and encryption

Between domain members the connection is encrypted with Kerberos by default whether HTTP or HTTPS is selected, only the collector can decrypt it, and source and collector mutually authenticate (NTLM is a fallback that a GPO can disable). HTTPS with certificates, a server certificate on the collector and client certificates on the sources, is the option when Kerberos isn't available, such as workgroup or perimeter-network machines. Adding certificates to domain workstations adds work without adding protection.

Delivery optimization

One subscription has one mode. For mixed needs, such as critical events (log cleared 1102, new service) within a minute but routine events with few WAN connections, split them into a small Minimize latency subscription for the critical events and a Minimize bandwidth one for the rest. Heartbeats only prove a source is alive.

Format and sizing

The default Rendered Text format adds the localized description and can double or triple event size; the Events (binary) format is far more compact and roughly doubles what a collector accepts. Plan about 3,000 events per second per collector on commodity hardware (bounded by disk I/O, connections and registry size) and split sources across collectors, each running AMA, when load exceeds that. Publishing several collector URIs to the same sources is for high availability: sources forward to every configured collector, so each receives the full stream.

Forwarded events, including Security log events, are stored in WindowsEvent rather than SecurityEvent, so built-in rules that query SecurityEvent don't see them until you adapt the queries to WindowsEvent or use ASIM parsers.

Microsoft notes that many built-in Windows security rules, including some near-real-time rules, query SecurityEvent. With data only in WindowsEvent you can: rewrite the rule queries for WindowsEvent, base the detections on the ASIM parsers (which normalize both tables), or, if WEF isn't required, collect with Windows Security Events via AMA instead. Filters and rule types never change the destination table, and the Windows Security Events connector on the collector would collect only the collector's own Security log.

Both tables expose EventID, so one query can cover servers on AMA and workstations on WEF:

union SecurityEvent, WindowsEvent
| where EventID == 4625

In WindowsEvent the event-specific fields sit in the dynamic EventData column and the source channel in Channel. Defender for Endpoint tables such as DeviceLogonEvents use their own schema with no EventID column.