AMA? Monitor Servers with the Azure Monitor Agent (and Sentinel!)
With the trusty Log Analytics agent (SCOM, anyone?) heading for deprecation in 2024 now is the best time to start moving to the new Azure Monitor Agent (AMA) for monitoring servers and endpoints.
The Azure Monitor Agent makes use of an improved data collection architecture which allows IT administrators and Ops teams to specify which data should be collected from each individual endpoint. This was traditionally difficult with the Log Analytics agent where settings configured at an operating system level applied to all agents targeted by the Log Analytics workspace owning the configuration.
The core function of the Azure Monitor Agent is to make use of data collection rules (and endpoints). These rules specify the logs to collect as well as target the resources for that log collection; on-premises machines, machines in other clouds or Azure virtual machines alongside Windows 10/11 endpoints which is currently in preview.
Monitoring using the Azure Monitor Agent is only one piece of the puzzle, this works well for Azure virtual machines but if your servers are in another ̶c̶a̶s̶t̶l̶e̶ cloud or on-premises then you’ll need to make use of the Azure Connected Machine agent which is a feature of Azure Arc.
In this post I’ll run through connecting an Azure Windows VM, Azure Linux VM and a VM ‘elsewhere’ (AWS, but the same steps are used on-premises). These resources will be sending logs into a Microsoft Sentinel instance although if the intention is to just send data and logs to Azure Monitor the agents are setup in the same way. I’ll be starting from a ‘blank canvas’ with the VMs as the only existing resources and following through the Azure portal from Microsoft Sentinel. As is common with Azure, there are many ways and interfaces available to achieve the same goal.
Azure Windows Virtual Machine
Starting from the Microsoft Sentinel workspace select data connectors and search for ‘Windows’:
From here you can see all of the options relating to Windows Server log collection (including the in-preview DNS events!). It’s also noticeable that the Log Analytics agent is no longer there. Open the connector page for Windows Security Events via AMA.
The connector page is pretty blank, but you’ll see the prompt to create a ‘data collection rule’. Select this and it will pop out the rule creation modal. You’ll have to give the rule a name e.g., WindowsCommonLogs and select a subscription and resource group for it to be deployed within. Following this it will move to the resource selection screen. (It can help to keep data collection rules in a single resource group for management).
It’s possible to select one or many machines and in this case, I’ll select the Azure Windows virtual machine to onboard, it’s possible to onboard further machines after using the same rule. Through the collect options it’s possible to configure the level of logging from the Windows endpoints you’ve targeted, I’d generally recommend Common as a baseline although it’s possible to collect All, Common, Minimal or specify custom x-path rules. The differences being:
- All 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. By enabling this option, you won’t be able to have a full audit trail.
- Custom — Allows you to filter and select the security events to stream by using Xpath queries.
When created by refreshing the data collection rule page in Sentinel you’ll see the rule has been created.
Or by navigating to the data collection rule resource itself.
You’ll also see that the Azure Monitor Agent has been provisioned on the virtual machine extension blade.
In time logs will be sent to the targeted Sentinel workspace.
So, onboarding an Azure Windows virtual machine is straightforward! To onboard further machines with the same rule navigate to the data collection rule within the portal and target more machines, or if desired offboard machines by ‘deselecting’ them.
Azure Linux Virtual Machine
Whilst there is no direct method within Microsoft Sentinel to onboard a Linux virtual machine to the workspace using the Azure Monitor Agent, it is still possible via the Azure Monitor interface. By navigating to Azure Monitor and data collection rules it’s possible to select Linux as the operating system target, as well as view all data collection rules.
When creating a new rule, you’ll see that ‘custom’ is also available, which is used for text log collection.
The resources page looks slightly different from the Sentinel data collection rule blade, although the process to select an Azure virtual machine is the same.
When the virtual machine is selected the types of logs to be collected need to be chosen, this is one of the main benefits of a data collection rule as it’s possible to choose the specific Linux facilities to log. Whereas before this was at a workspace level it’s possible to create multiple data collection rules with different facility settings for specific purposes all sending logs to the same -or differing- locations.
When the data collection rule is created in time logs will be available in the Syslog table, and as with Windows it’s possible to target more resources from the data collection rule interface.
On-premises or other clouds
To begin collecting logs from virtual machines or servers hosted in other locations we need to make use of Azure Arc to connect the machines to Azure before we can start using data collection rules and the Azure Monitor Agent. For this example, I’ll run through connecting a Windows virtual machine to Azure Arc, and then enable logging to Microsoft Sentinel using a data collection rule. To start navigate to the Azure Arc service and virtual machines.
When adding a new virtual machine for the first time you’ll be prompted with three options, adding a single machine, adding multiple machines or adding machines via update management. Adding single machines is great for testing or capturing servers which fall outside of a managed deployment scope, it requires authentication via a user account for the most part. For this I’ll create a script which can onboard multiple machines.
You will need to create a resource group for the machine reference resources to deploy into. It is possible to change this resource group to deploy servers into different groups. Also, whilst Azure Arc is an Azure service, there are no additional costs for utilizing the connected machines, charges exist for Azure Policy or sending logs to Microsoft Sentinel.
When onboarding multiple machines into Azure Arc a service principal is required, by following the initial steps you will be prompted to create a principal with the following information. Be sure to copy the client ID and secret to a secure location! As with all service principals (also known as Azure AD App Registrations) you can manage the secret and permissions through Azure AD post-creation. (Unfortunately, you may have to restart the Azure Arc process after creating the first principal, so it can locate it for selection).
Following the onboarding steps, it’s possible to preset tags for any machines which are to be onboarded using the script. For example, which cloud account or physical location they are in.
The portal will generate the PowerShell script, or a script for use with SCCM or Ansible. Note that you’ll have to populate the service principal ID and secret, so creating it (or not selecting it) as part of the workflow won’t impact the onboarding.
This script also be deployed via Microsoft Intune, GPO or other software deployment tools. Connected to your target virtual machine run the script to connect the machine to Azure.
Before you proceed, it’s always worth checking that the service principal has the required permissions on the subscription or resource group.
The script output is fairly straightforward.
Within a few minutes of running the script you will see the machines within the selected resource group.
And by selecting a machine you’ll be able to see shared metadata from the connected machine agent.
With the machine now onboarded into Azure Arc, we can proceed to onboard logs into the Microsoft Sentinel workspace. To achieve this we can create a new data collection rule or make use of the one created earlier for WindowsCommonLogs.
By selecting the data collection rule and choosing to add a resource, we now see the Azure Arc connected virtual machine.
You’ll see a few portal notifications about the actions taking place on the machine, if you navigate to the machine (by clicking its name or via the resource group it’s in) and go to extensions you’ll see the Azure Monitor Windows Agent.
In time logs will appear within Microsoft Sentinel SecurityEvents.
And that’s it!
Whilst the initial setup of the data collection rules can take some time, alongside Azure Arc for on-prem/other cloud machines it’s certainly worth the effort considering the benefits of targeted data collection and ease of ongoing management. Managing the majority of the process from the Azure portal (or the command line, omitted above) makes for a straightforward management experience. In all onboarding virtual machine log sources to Microsoft Sentinel is a lot faster.
Some notes
In this post I haven’t covered how to collect other Windows logs. For Application, System or other Security logs. It’s possible to create a separate data collection rule for these.
I’d recommend using x-path queries for these to finesse log ingestion and limit costs.
In this post I assumed log collection over the internet. A fantastic feature of Azure Monitor is the ability to use data collection endpoints with private links. I’ll cover this in a separate post.
It is possible to collect text and IIS logs with the Azure Monitor Agent as documented here. This is not currently possible within the Azure portal and must be done through templates/API requests.
Finally, there is no way to match the current CEF/Syslog forwarding capability of the CEF Forwarder. This is available in private preview for sign up.
