Configure Azure AD diagnostic settings ^
Currently it's still in preview, but in your Azure portal, you can browse to the Azure AD tab and check out Diagnostic Settings. Just like on most other Azure resources that support this, you can now also forward your AAD logs and events to either an Azure Storage Account, an Azure Event Hub, Log Analytics, or a combination of all of these. These targets all serve different use cases; for this article, we will use Log Analytics.
If you have not created a Log Analytics workspace yet, go ahead and create one via the portal or using the command line or Azure Cloud Shell:
$rgName = 'aadlogs'
$location = 'australiasoutheast'
New-AzResourceGroup -Name $rgName -Location $location
New-AzOperationalInsightsWorkspace -ResourceGroupName $rgName -Name 4soaadlogs -Location $location -Sku free
This will create a free Log Analytics workspace in the Australia SouthEast region. The next step is to configure the actual diagnostic settings on AAD.
Unfortunately, there is no straightforward way of configuring these settings for AAD from the command line, although articles exist that explain workarounds to automate this configuration. Usually, this should really be a one-time task because companies generally tend to have only one or a very small number of AADs. Not being able to automate this should therefore not be a massive deal.
In this dialogue, select an existing Log Analytics workspace, select both types of logs to store in Log Analytics, and hit Save.
There will be a note that to export the sign-in logs to any target, you will require an AAD P1 or P2 license. You can check the documentation to find all the other features you will unlock by purchasing P1 or P2, a highly recommended option.
With these licenses, AAD will now automatically forward logs to Log Analytics, and you can consume them from there.
Querying AAD logs with Log Analytics ^
In the Log Analytics workspaces > platform - Logs tab, you gain access to the online Kusto Query Language (KQL) query editor. In my environment, the administrator I want to alert has a User Principal Name (UPN) of email@example.com. We can run the following query to find all the login events for this user:
SigninLogs | where OperationName == "Sign-in activity" | where UserPrincipalName == "firstname.lastname@example.org"
Executing this query should find the most recent sign-in events by this user. If there are no results for this time span, adjust it until there is one and then select New alert rule.
You can now configure a threshold that will trigger this alert and an action group to notify in such a case. An action group can be an email address in its easiest form or a webhook to call.
It is important to understand that there is a time delay from when the event occurred to when the event is available in Log Analytics, which then triggers the action group. This can take up to 30 minutes.
In just a few minutes, you have now configured an alert to trigger automatically whenever the above admin now logs in.