Last Updated: 10/03/2025
If you are planning to use Microsoft Sentinel, then you will no doubt want to ingest the Azure Activity log source. As this contains the subscription-level events for your Azure environment. However, there seems to be a step which trips people up when you implement Azure Activity scoped by Management Groups.
This guide will show the differences between scoping to individual subscriptions and scoping to management groups.
Azure Activity – The Basics
The Azure Activity data connector allows us to ingest subscription-level events from our Azure environment. It’s a very handy data source to ingest if you are using services within Azure, as you effectively have the audit log for your Azure.
Better yet, ingesting this data source is free of charge, so there isn’t much of a downside to ingesting.
The setup and configuration of this data source requires the use of Azure Policy. An Azure Policy is required to configure the diagnostic settings of the subscription to point the logs to the Sentinel workspace.
The way the policy works is, once implemented any future resources will obtain this configuration. For existing resources, a remediation task is required. Where the remediation task is run from is based on your configuration is generally what trips people up (myself included).
Azure Activity Scoped by Subscription
This is the most common configuration, and Microsoft documentation outlines these instructions.
Note: Locate and install the ‘Azure Activity’ solution in the content hub first.
Note: Ensure you have the correct permissions to create & edit Azure policies for your subscription.
If we navigate to our Microsoft Sentinel instance and go to the ‘Azure Activity’ data connector. You will be presented with the following instructions:
From here, we can ‘Launch Azure Policy Assignment Wizard’. This will load up the relevant Azure Policy we need for the data connector.
We can then adjust our scope, and for this example we will select a single subscription. Next, we can navigate to ‘Parameters’.
In the parameters, we want to select the Log Analytics Workspace we want to send the Azure Activity logs to. Next, navigate to: ‘Remediation’.
In this section, we want to ‘Create a remediation task’. In order to execute the changes, we will need to give the policy permissions by way of a Managed Identity. For this example, I chose ‘System Assigned’ and changed the location to the same location as my Sentinel instance.
We can then ‘Review + create’ this policy.
Note: The policy can sometimes take an hour to implement.
Azure Activity Scoped by Management Groups
For those of you with multiple subscriptions, there is an easier way to configure all these together. The method is Azure Activity scoped by Management Groups. However, these subscriptions will need to be part of a Management Group.
The configuration is very similar to the above, the slight change is the remediation task.
Note: Locate and install the ‘Azure Activity’ solution in the content hub first.
Note: Ensure you have the correct permissions to create & edit Azure policies for your subscriptions within the Management Group.
Configure the Policy
If we navigate to our Microsoft Sentinel instance and go to the ‘Azure Activity’ data connector. The following instructions are presented to us:
From here, we can ‘Launch Azure Policy Assignment Wizard’. This will load up the relevant Azure Policy we need for the data connector.
We can then adjust our scope, this time, we will select the Management Group.
Next, we can navigate to ‘Parameters’.
In the parameters, we want to select the Log Analytics Workspace we want to send the Azure Activity logs to. Next, navigate to: ‘Remediation’.
As you can notice, the option to create a remediation task does not exist. This is due to scoping to a management group. Create the remediation task after establishing the policy.
Next, We will still create a managed identity, making sure to select the location for it.
Once we are happy, lets ‘Review + create’ the policy.
Create the Remediation Task
Let’s now navigate to ‘Policy’ within Azure. Locate the newly created policy.
The non-compliance is due to existing resources not having the configuration. You will see a list of resources that are non-compliant, these will be your Azure subscriptions. To address this, we will need to select ‘create remediation task’.
Check the scope, locations and resources within the remediation task. Once we are happy, we can click ‘Remediate’. This will create and execute the remediation task that will configure the existing resources in scope. In this example, it will be my single subscription as part of that Management Group.
Check back on the policy page to validate that the resources are now compliant, and the configuration has been completed.
Note: This can take a bit of time to propagate.
Validating the Azure Activity Data Connector
If we check back in our Microsoft Sentinel instance, we can see that the data connector is now active.
As a final check, we can run a KQL query to summarise by Subscription ID, to ensure we are pulling logs from our multiple subscriptions.
AzureActivity
| summarize by SubscriptionId
This will pull back a list of the Subscription ID GUIDs which you can compare to your list of subscriptions.
Conclusion
Hopefully this guide helps any of you who are scratching your head wondering why the Azure Activity data connector is not functioning as expected. The differences between the configurations are very minor, but easy to miss.
The Microsoft documentation seems to outline the subscription method as the only way. However, creating a policy for each subscription can be tedious. Additionally, configuring it by a management group should ensure that any new subscriptions added to the Management Group will instantly have that configuration (as it’s a new resource), although I have yet to test this.
Thank you for reading, and if you haven’t done so already, check out my Microsoft Sentinel Cheat Sheet for handy tips.