Microsoft Sentinel and Azure Monitor Agent

Microsoft is replacing confusing monitor agent army (several different agents) with a new one that is going to replace all current ones. New agent is called Azure Monitor Agent and shorter abbreviation is AMA. When you install AMA, the biggest change is that it is not anymore separately installable .msi or .exe client. AMA is an compute extension that you enable to any Azure virtual machine in very easy way. If your server is not in Azure (so it is in AWS, GCP, on-premises or other cloud), you have to connect it to Azure via Azure Arc and then continue working with a new agent. In this post I will tell how to send your logs from traditional server (was it in Azure or somewhere else) to Microsoft Sentinel.

Azure Monitor Agent – How does it work

To install Azure Monitor Agent for your server, just go and enable the extension for it. There are pretty good guides in Microsoft’s docs that you can follow up. The quickest way to get started for some Linux server is with Azure CLI by using next one-liner:

az vm extension set --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --ids <compute-resource-id>

After you have successfully installed the extension (you can see it from the extension status), you can deploy the Data Collection rule for the server. Data collection rule (DCR) specifies what data should AMA get from the server and to where should it send it. You can specify multiple DCRs for more granual data collection and forward logs to different destinations as you wish. More information about data collection rules under its own paragraph.

When comparing Azure Monitor Agent to Log Analytics agent there are plenty of differences. One big thing is authentication. Log Analytics agent used workspace ID and workspace key to authenticate towards the log analytics workspace. You could not roll keys over, because old clients stopped to report data after that. In Azure Monitor Agent authentication is made with system-assigned managed identity and no separate keys are required.

Azure Monitor Agent with data collection rules sound pretty nice, but still those are under development and in many scenarios in 2/2022 you should still use legacy agent (Log Analytics agent). If you just need basic security logs, nothing else I suggest you already to go with Azure Monitor Agent. You can run both agents side by side, but remember that you will get double data and double price, if you are running data from both agents to the log analytics workspace.

Data Collection Rules

Data collection rule is a really nice resource type that you can use to select more granually what resources you want to gather from the source operating system and where to send those. You can specify multiple DCRs for one server such as security stuff to Sentinel and application logs to operational log analytics workspace. The crucial benefit here is that you do not have to pay Sentinel data ingest price for operational logs that are not required by your security team!

Log analytics tables

You can make DCRs in portal under Azure monitor, but be aware that if you want those be in SecurityEvent table in Microsoft Sentinel, you must create those through Microsoft Sentinel or with IaC (or REST). If you create DCR from portal under Azure Monitor, events will go to event table, not to Security Event table where plenty of ready analytics templates and hunting queries are based on. Technically the difference is under target streams in DCR’s configuration. Target streams (array in DCR) is called Microsoft-Event when you are talking about Event table. When you want it to be in SecurityEvent table, streams should be Microsoft-SecurityEvent. If you think little bit outside-of-the-box, it is quite clear why there are separate tables. Another for operational kind of log management and another for security related log management.

To be clear, create DCRs for servers that are going to send data to Microsoft Sentinel through Sentinel or with Infrastructure as a code, not from Azure Monitor side.

DCR deployment

To connect your DCR to server, you have to add it as an resource under DCR. For couple of servers this is ok, but for more servers, you should use policy management for it. If you create the resource link to the DCR through the Azure portal, it is going to install the AMA for your server automatically as well it is enabling system-assigned managed identity. If you deploy it some other way, remember to ensure that AMA and system-assigned managed identity are also there.

Policy Management

When you want to scale your DCR deployment or automate it, you want to use Azure policies. Azure policies are meant to audit your cloud infrastructure or your guest operating systems for settings that you have defined beforehand. You can also create deployIfNotExists type of policies that will do something if it is not as we want. For monitoring purposes you can ensure that correct DCRs are deployed and AMA is installed for all required workloads. There are couple of built-in policy definitions that you can use to get started with.

You can group policy definitions to initiatives for clarified assignments. When you have a policy definition or an initiative you assign it for some resource group, subscription or management group to assign it for Azure resources under that level. This post is not focusing more closely about Azure policy management itself, but there are plenty of good tutorials and training in the internet for example in Microsoft Learn.

For Azure resources there are already two working initiatives that you can use for AMA and DCRs:

• Configure Linux machines to run Azure Monitor Agent and associate them to a Data Collection Rule
• Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule

This is a good start and Microsoft updates these initiatives and policies on behalf of you. There are also some caveats. First of all, system-assigned managed identity must be enabled on each device before the Azure Monitor Agent is installed on those. You can enable it automatically with built-in policy definitions. Be aware when enabling system-assigned managed identity for resources that has already user-assigned managed identity in place. You might break authentications, because system-assigned managed identity is the first one in use, if there are more than one identity for use and fir example specific user-assigned managed identity is not specified.

Linux initiative

Linux initiative deploys Azure Monitor Agent for our Linux virtual machines (Microsoft.Compute/virtualMachines) and deploys the DCR for those as well. It does also the same thing for non-Azure devices that are connected as Azure Arc to Azure (Microsoft.HybridCompute/machines). More about Azure Arc shortly in another paragraph in this post. This initiative works like a charm and I encourage you to use it.

Windows initiative

Windows initiative should work almost same, but not enough. If you have only particular resources in Azure, you can use this. As you see when comparing to Linux initiative, Azure Arc policy definitions for Windows devices are missing.

Ensure that Azure Monitor Agent is installed for your virtual machines, virtual machine scale sets and azure arc enabled servers before you deploy DCR. For Arc enabled servers you can use the built-in policy definition Configure Windows Arc machines to run Azure Monitor Agent. For virtual machines and virtual machine scale sets you can use initiative called Configure Windows machines to run Azure Monitor Agent and associate them to a Data Collection Rule that includes as well the DCR deployment rule. To deploy DCR for Arc for servers enabled device, you have to use custom policy definition.

Azure Arc for Servers

Azure Arc is a way to connect non-Azure workloads to Azure for management and monitoring purposes. There are several things that you can connect to Azure as a hybrid workload such as servers and Kubernetes infrastructures. This post focuses little bit about Azure Arc for servers. More information about Azure Arc, you can find from Microsoft Learn.

Azure Arc for server is a client that you can install on a supported operating system. For the installation you must specify resource group and location where the device is going to be connected. After client is installed and connection is made successfully, you can manage the non-Azure server through ARM (Azure resource manager). You can deploy extensions (for example Azure Monitor Agent) for it or data collection rules etc. When you connect a server with Azure Arc, it gets as well an system-assigned managed identity. Your server can use it to access Azure resources such as Log Analytics workspace with Azure Monitor Agent.

Azure Arc connection

There are several ways to connect your server with Azure Arc. For testing purposes the easiest way is generating a script with Azure portal wizard and running it in the server itself. More about Azure Arc connection methods from its documentation.

When generating a script it is an easy way to get one server connected to Azure. Open Azure Arc –> Servers –> Add –> Single server wizard and choose the location for device. At the end you get a script that you can run on a computer’s Powershell with admin privileges and everything is done!

After you have connected non-Azure server to Azure, you can use same deployment methods to deploy DCRs and Azure Monitor Agents to those and connect data sources such as security event logs to Microsoft Sentinel.

Connection is currently going through the public internet but, of course it is secured by TLS. In future there will be a possibility to use private link service for connection method. More about private link from another post.

Summary

As a conclusion Azure Monitor Agent and Data collection rules works like a charm when you want to onboard servers to Microsoft Sentinel. If your requirements are other than security events, consider legacy agent as long as your requirements are not supported by Microsoft. AMA and DCRs are the future in Azure Monitor world as well as when connecting servers to Sentinel.

Use it and be happy!