Microsoft Sentinel – Ingesting Windows Server Event Logs via Azure Arc

Last Updated: 19/11/2024

Following my previous post, I went through the steps required for Ingesting Windows server event logs from Azure VMs into Sentinel. This post expands this topic out by detailing the method and steps to ingest on-premises/Non-Azure VM Windows event logs via Azure Arc.

As with most log collection methods, there is always more than one way, this post will focus on ingesting data directly from individual machines located on-premises that have direct internet connectivity using the Azure Arc method.

There are two main steps to doing this:

1. Onboard machines into Azure Arc
2. Create a Data Collection Rule (DCR) for ingesting Windows server log data into Sentinel

Step 1: Azure Arc Onboarding

Head over to your Azure portal (https://portal.azure.com) and ‘Create a Resource’, find and select ‘Servers – Azure Arc’.

When you select create, you will be direct to a wizard that provides you with the different onboarding methods. Choose the one that suits you, however for this guide I will be using the scripted install for a single server.

You will be prompted to fill in the details of the subscription & resource group, as well as the region.

You can also specify your connectivity method. For this instance, il be using the public endpoint method which sends all traffic over the internet. However, if you have a S2S VPN or ExpressRoute into Azure I would highly recommend utilising the Private Endpoint option. If you’re on-premises machine connects to the internet via a proxy, then you can select ‘Proxy server’ and specify the URL.

Once you are happy with the configuration, you can copy or download the script.

You can then log onto your server of choice and execute this script. Make sure you have local administrator permissions, and you run PowerShell as Admin. Additionally, make sure that ports 443 is open and the following URLs are on your allow list.

The PowerShell script will download the required installation files and configure the azcmagent. You will be prompted to enter in credentials which will require the relevant permissions in Azure (either ‘Azure Connected Machine Onboarding’ or ‘Contributor’ role). Once the script has run successfully, you will see the Azure Arc resource in Azure.

Step 2: Data Collection Rule

Like Azure machines, we now need to create a data collection rule in Sentinel that allows for ingesting Windows server event logs.

Navigate to your Microsoft Sentinel instance and access the ‘Content Hub’, in the search bar search for: “Windows Security Events” and select the solution.

Install the solution, and once installed, select manage. On the management page, select the ‘Windows Security Events via AMA’ data connector, and open the connector page.

From the connector page, select ‘+Create data collection rule’ and the righthand side pane will the collection rule wizard will appear. Fill in the name of the rule and where the object is stored in Azure.

After clicking ‘Next’ you can then scope where this rule will apply to. The rule can be scoped to Subscriptions, Resource Groups and individual VMs.

After you have selected your resources, click ‘Next’ to go to the collection settings. You can now select what level of events you would like to collect. The options are:

• All Security Events – All Windows Security and App Locker Events.
• Common – A standard set of events for auditing purposes.
• Minimal – A small set of events that might indicate potential threats.
• Custom – Allows you to filter and select the events you require by using an Xpath query.

Once you have selected this, you can create the rule. This will then configure the machines in the background to send the Windows event logs into Sentinel. It can sometime take a bit of time before logs start ingesting, mine started within 30 minutes but this was for a single VM located in Azure.

You can check by querying the ‘SecurityEvent’ table from the ‘Logs’ section.

Hopefully this guide helps as a quick way to ingest Windows event logs into Sentinel from on-premises based Windows machines. Of course, there are other ways to ingest data such as using WEF (Windows Event Forwarder) which I will detail out in a separate post.