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.