Windows Forwarded Events connector with Windows Security Events NRT rules

Yes, this is expected with the current table design. The Windows Forwarded Events connector writes events to WindowsEvent, while the Windows Security Events NRT rules were built for data collected in SecurityEvent. An analytics rule does not automatically look in both tables, so a rule that queries SecurityEvent will not detect the same event when it arrives through WEF in WindowsEvent.

First, confirm the fields used by the forwarded events in your workspace:

WindowsEvent | where EventID in (1102, 4732) | project TimeGenerated, Computer, Channel, EventSourceName, EventID, EventData, RenderedDescription | take 20

For an immediate test, create a copy of the affected rule and change the query to use WindowsEvent, for example:

WindowsEvent | where EventID == 1102

Add a Channel filter only after checking the results above, because the exact channel value should be verified in the collected data. Rules that need account names, group names, or other event details will also need their field extraction rewritten, since SecurityEvent and WindowsEvent do not have the same schema.

If the NRT rule editor accepts WindowsEvent, a custom NRT rule is the closest equivalent. If it does not, create a scheduled analytics rule using WindowsEvent with a short frequency instead. ASIM may be useful, but only if the installed parser actually normalizes your forwarded WindowsEvent records; it should be tested rather than assumed.

The alternative is to collect the same security audit events through the Windows Security Events connector so they enter SecurityEvent and work with the existing templates. Avoid enabling both paths for the same events unless duplicate ingestion and duplicate alerts are acceptable.

I've seen this done before, although I wasn't the one who originally set it up. I know it's possible, but I haven't found any official documentation describing the process.

If I were approaching it, I'd first get the WEF collection working normally and verify that the expected events are being collected. Once that path is working, I'd update the DCR to send the data to the SecurityEvent table instead.

Comparing the published schemas, only two differences really stand out. Provider should be renamed to EventSourceName, and EventData should be converted from dynamic to string. I'd start with the minimal transformation below and only make additional schema changes if validation or ingestion indicates they're necessary.

source | project-rename EventSourceName = Provider | extend EventData = tostring(EventData)

I'd be interested to hear if anyone has tried this recently and whether there are any additional adjustments required with the current AMA/DCR implementation.

Yes—this behavior is expected for these specific templates. Your WEC/WEF, Arc, and AMA path is working because forwarded records reach WindowsEvent, while Windows Security Events via AMA writes to SecurityEvent. An NRT rule evaluates only the tables referenced by its KQL, so a template starting with SecurityEvent cannot detect event 1102 or 4732 stored in WindowsEvent; the connector itself is not failing.

Create a custom NRT rule based on the template logic, query WindowsEvent, filter EventID, and project only fields needed for alerts and entity mappings. For 4732, inspect EventData and map the member and group values present in your records. Test against recent events, enable the rule, then prevent duplicate detections. If you require the unchanged SecurityEvent templates, collect the source machines through Windows Security Events via AMA. Use an ASIM-based template only when its documented parser and schema explicitly support these records; ASIM is not an automatic bridge.