AzSentinel – Version 0.6.8

Version 0.6.8 is available in PowerShell Gallery with bunch of bugfixes and new features.


First step of finally adding support for DataConnectors 😛

New YAML example file

This new YAML example shows how you can configure multiple rules in one YAML file, with the same properties as in JSON format

List of other fixes:

  • #101 Get-AzSentinelAlertRuleAction doesn’t return playbookName in 0.6.6
  • #93 Get and remove Hunting Rules broken
  • #75 Bug Report – Get-AzSentinelHuntingRule

AzSentinel – Version 0.6.6

Version 0.6.6 is available in PowerShell Gallery with bunch of bugfixes and new features.

Support for multiple rules

From this version you can manage all type of Analytics rules from one template. The import and New-AzsentinelAlertRule functions are also optimized to import new rules much faster.

The layout of JSON file is updated to add support for the following Analytics rules:

  • Scheduled
  • Fusion
  • MLBehaviorAnalytics
  • MicrosoftSecurityIncidentCreation

JSON schema:

As you can see you can define all the rule types in the same template file. For each rule type you can find the properties on the following link. Below an example of a setting file containing all types of Analytic rules

You can also use the New-AzSentinelAlertrule function to create this kind of rules. You have now the switch “-Kind” that you can use to create other type of analytic rules.The default value is Scheduled rule. Below some examples:


New function to add comment to Azure Sentinel incidnent


Thanks to ramirezversion, This function return all the the Analytics rule templates

List of other fixes:

Issue/PR IDFix by
#91 Update-AzSentinelIncident deletes various incident properties #89
#87 Fixed an issue that caused enabled in alert groupingConfiguration to be set to true everytime due to an error in the code
#78 Handle nextLink for Playbooks

AzSentinel – Version 0.6.5

Good news guys! A new version of AzSentinel is available in PowerShell Gallery with bunch of bugfixes and new features.

Before we jump to all the good stuff, please let me thank everyone for their great feedback, support and mostly patience :p I know this version took really long and I received lots of messages. So sorry for that. The reason that it took longer is because I started my own company a couple of months ago and that kept me quite busy. As I promised I will keep maintaining this module until the Microsoft official PowerShell module is released. With that said, below you’ll find a list of changes in this new version.

1. (Breaking) changes

In this version I have decided to drop the compare functionality. This means that from now on if an alert exists, you don’t get the popup message to confirm the new changes. Why, you ask. Well with the new Incident settings and Alert grouping, the Alert Class contained child objects and I had a really hard time to fix this in the compare functionality. So I asked around and understood that people don’t use this option that much, because most of the time deployments are done through Pipeline. So I still use it in some of the functions. Like to decide if a playbooks is assigned and if we need to remove it for example. Maybe we can bring this back in the next version. Let me know what you think about this decision and if you have any tips.

Another one is the output of “Import-AzSentinelAlertRule”. In the current version it’s returned with Write-Output and this has different result than the return function. Also, instead of writing each rule output one by one, I collect it in a temp variable and return at once. This also speeds up the loop process. So how do you know if your rule was created successful or not? Well I have added a new property value named “status” and it returns 3 values:
Created: if a rule doesn’t exist and is created;
Ok: if a rule exists and gets updated;
Failed: if there was an issue, with this one you will also get an error output at the beginning of the output (so scroll up).

In the upcoming version I will try to implement more performance optimization. If you have feedback please create an issue on GitHub or get in touch with me.

2. Support for Incident settings

Also new in this version is support for Incidnet settings. You can use CreateIncidnet property in the JSON/YAML template or use the -CreateIncidnet switch when using New-AzSentinelAlertRule command. If you don’t configure this then the Microsoft default settings will be applied and your existing rules (JSON) are backwards compatible.

3. Alert grouping

Also, this new version contains support for Alert grouping. You can configure this by adding the following properties to your JSON/YAML template for each rule or by using the New-AzSentinelAlertRule with the same properties. If you don’t configure this then the Microsoft default settings will be applied and your existing rules are backwards compatible.

or by using the following switches:

4. Alert aggregation (private preview)

This is a new feature that Ofer has talked about in his latest presentation and in my opinion one of the must have features in Azure Sentinel Alert creation process. This option gives you the possibility to treat each event as a separate alert in Sentinel. This way instead of having one alert rule attached to your incident which contains 12 events, you can e.g. have 12 separate alerts assigned to one incident or 12 incidents each having one or more alerts. You can now enable this feature using -AggregationKind “AlertPerRow” in the New-AzSentinelAlertRule function or by using “aggregationKind”: “string” property in your template.


You have the following options:
– SingleAlert (default value)
– AlertPerRow

5. Rename-AzSentinelAlertRule

Also, you can use the Rename-AzSentinelAlertRule to rename your existing Rules.

6. Set-AzSentinel updated

In this version the Set-AzSentinel command will automatically enable the required Resource Providers if those are not enabled in your Subscription.

  1. Microsoft.SecurityInsights
  2. Microsoft.OperationsManagement

7. Get-AzSentinelPlayBook updated

And finally, there were some issues with the number of playbooks returned. Shout-out to @stehod for solving this issue.

AzSentinel – Version 0.6.2

New version of AzSentinel is available in PowerShell Gallery with bunch of bugfixes and some new features. See below a list of the changes in this version.

1. Configure Action for Alert Rules

From this version it’s possible to configure “Actions” for the Alert Rules through New-AzSentinelAlertRule by using the -playbookName switch. Or by configuring JSON “PlaybookName” property for each Alert rule. You only need to provide the logic APP name that you want to assign to your Alert rule. The function will automatically search the Logic App in your Subscription, the logic App is also tested to see if it’s compatible for Azure Sentinel!
This option is backwards compatible, if you don’t have the “PlaybookName” covered in your JSON template no changes will be applied. Thanks sbroosnokia for the feedback!
Below the new JSON layout:

To make this feature available the following new functions are added to AzSentinel:

Get-AzSentinelAlertRuleActionUse this function to see if a Alert rule has Action configured
New-AzSentinelAlertRuleActionConfigure Action for an existing Alert rule
Remove-AzSentinelAlertRuleActionRemove configured Action

2. Update Incident

In this version there is also an Update-AzSentinelIncident function available that you can use to update existing incidents. Not all the properties are currently available in Update function, but in feature version I will extend the possibilities. See below a list of current possibilities:


Close Incident with argument:

Change incident status to inProgress:

Add label to existing labels:

3. Bugfixes

Below list of hotfixes:

titleurlthanks to:
Time Format conflict #38
Issue using Import-AzSentinelAlertRule #27

ARM: Deploy Logic App with connection configured for Azure Sentinel connector

Azure Sentinel team has developed a great connector for Azure Sentinel, which you can use to automate your Logic App. The Azure Sentinel Connector currently contains the following actions:

In this blog we will focus on how to deploy a logic App configured with the correct Connection credentials for the Azure Sentinel connector through ARM template.

When adding the Azure Sentinel trigger step or an action to the logic App, we need to provide a connection which will be used to authenticate the Azure Sentinel environment:

Most of the time this is automatically created  through the Azure Portal, with your current user credentials if you have the right permissions. But that’s not what we are looking for 😛 So the other option is to select “Connect with Service Principal” and provide a Client ID and secret, which will be used to access the Azure Sentinel resource:

Reader permission is enough if you only want to read data. However, if you for example want to use the “Update Accident” action from the Azure Sentinel connector suit, the SPN needs to have higher privilege’s.

Now we know that we can use a Client ID and secret to authenticate, it’s time to create the “Managed API” connection resource with the correct properties. You can achieve this with the configuration below:

So next we need to combine all the configuration and link all the resources together in the ARM template to deploy our solution. Below a simple Logic App, which contains Azure Sentinel trigger step and a “Get Incident” action:

The Logic App must always start with “When a response to an Azure Sentinel alert is triggered” step.

After deploying the above ARM template the resources below will be created:

Here you see how the Azure Sentinel actions in the Logic App are automaticity configured to use the azureSentinel connection: