October 15 Date for First Round of Azure MFA Requirement Enforcement

Microsoft’s decision to enforce multifactor authentication (MFA) for access to Azure properties certainly caused a great deal of kerfuffle. The original May 14, 2024 announcement didn’t help itself by proclaiming that “Microsoft will require MFA for all Azure users,” an assertion that led people to believe that any sign-in to Azure AD (Entra ID) would require MFA. At the time, I thought the idea is sound but the communication was woeful.

Roll forward to June 27, 2024, and a follow-up post to the Core Infrastructure and Security blog in the Microsoft Technical Community attempted to clear the confusion. Given the number of questions since, the signs are that people are still unsure what’s happening. Let me try to unravel the situation.

First, not everyone is affected by the change. MFA is only enforced for access to some Azure cloud properties. According to message center notification MC862873, Microsoft will require MFA for access to the Entra admin center, Azure portal, and Intune admin center (including services like Windows 365 Cloud PC) on or after October 15, 2024. Although I am not certain, Windows 365 Cloud PC seems like the only place where non-administrators might be affected by the MFA requirement.

Phase 2 of the implementation in early 2025 will see the requirement spread to the Azure CLI, Azure PowerShell, and infrastructure as code (IaC) tools. The good news is that only administrator accounts typically use these sites. Normal users are unaffected by the change. And anyway, administrator accounts should be protected by MFA. If they are not, the tenant has other problems.

Second, Microsoft 365 tenants that use Security Defaults already mandate MFA for connections to administrator portals.

Third, tenants that don’t use Security Defaults and have conditional access policies in place to control connections instead probably have a policy to require MFA for connections to administrative sites. Microsoft even publishes a policy template to make it easy for tenants to enable this control.

Workload identities, such as the managed identities used with Azure Automation, are unaffected. However, if Azure Automation runbooks include user identities (username and password credentials) for authentication, they might not work after Microsoft deploys the requirement for MFA access to Azure. For instance, if a runbook uses the Azure PowerShell module, it must use a managed identity or service principal (app) to connect.

Break glass accounts are affected too. If ever needed, these accounts are likely going to access Azure administrative sites and use Azure administrative tools, so the new guidance is to modify the previous practice of using a long and complicated password and add the protection for the accounts with a strong MFA authentication method like FIDO2 or certificates.

Postponing the Azure MFA Requirement

Microsoft says that they will allow a grace period to tenants who need some extra time. Organizations that use non-Microsoft MFA solutions might be in this category (support for external MFA providers is in preview). If in doubt, use the link in the message center notification post to request a postponement (Figure 1).

More information is available in the Microsoft planning document covering the new requirement.

Microsoft’s Script to Reveal Access to Azure Administrative Tools

In their post, Microsoft says that the Export-MsIdAzureMfaReport cmdlet from the MSIdentityTools PowerShell module as a way to uncover accounts likely to be affected by the change. The cmdlet “exports the list of users that have signed into the Azure portal, Azure CLI, or Azure PowerShell over the last 30 days by querying the sign-in logs,” so it’s a useful way to get an insight into who might be affected by the MFA requirement. I ran the cmdlet for my tenant and found that I need to act for an account used for utility background jobs (Figure 2).

The data used by the cmdlet is available to administrators to create their own version. For instance, the script covered in this article explains how to combine data from several sources to create a picture of MFA usage within a tenant.

No Need to Panic – the Azure MFA Requirement is a Good Thing

The bottom line is that there’s no need to panic unless you have a bunch of background jobs that use user credentials for authentication or forget to update your break glass accounts. Normal users will make unperturbed progress through the change. This is predominantly a good update to force administrators who haven’t yet understood the absolute need to protect their accounts with MFA to change their behavior. After all, why leave an open door ready for the bad guys to kick in?

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Debugging, Cost, and Tracking for Azure Automation PowerShell

As you might have noticed, I’ve spent some time recently investigating how to exploit Azure Automation with Microsoft 365 PowerShell modules, exploring topics such as using Microsoft Graph PowerShell SDK with Run As accounts to Managed Identities with Exchange Online.

I cheerfully admit that I am still an Azure Automation PowerShell novice, but I’ve enjoyed probing the ins and outs of topics like Managed identities and understanding how things fit together to run jobs on the Azure infrastructure. Working with Azure Automation is certainly different to putting together PowerShell scripts for interactive use, but it’s a technique that I believe Microsoft 365 tenant administrators should master because it’s a great (and secure) way to run resource-intensive scripts on a scheduled basis. Or indeed, scripts that need to run periodically to adjust settings, like the one to update new teams to block team members from creating regular channels. In any case, here are three lessons I’ve learned over the last year or so.

Debugging Azure Automation PowerShell is Different

Debugging code in Azure runbooks is one of the more interesting challenges. When a runbook (PowerShell script) executes, it essentially runs on a headless server. Your code either runs or it doesn’t, and there’s no way to step through commands in a script as you can interactively. If code doesn’t run as expected, it becomes a matter of breaking code up into segments to identify where the problem occurs and inserting old-time output statements to gain clues about what might be going wrong.

Microsoft documentation recommends using the output stream to log progress and information about processing. That’s just a sophisticated way of saying that you insert Write-Output commands in the code to output details of variables. I did this with PRINT statements when I was a COBOL programmer in the 1980s and I’m still doing it today. Technology changes, but some debugging techniques remain in situ. It works both for the output of scheduled jobs and when you execute a runbook in the test pane.

Figure 1 shows the output of a run of the Azure Automation version of the script used to generate the Microsoft 365 Groups Expiration Report. The original article explaining the principle behind the script is available here.

Cost of Azure Automation PowerShell is Minimal

You need a paid Azure subscription to use Azure Automation. The subscription pays for costs such as the small amount of storage used to store runbooks and the compute costs for running the code. Originally, I was concerned that I would rack up considerable costs, especially when running scheduled jobs. However, the actual costs are very modest and most months I end up with a total of a couple of dollars.

The bottom line is that running PowerShell scripts with Azure Automation is unlikely to break the bank unless you execute some highly resource-intensive scripts on a very frequent basis. But in saying that, it’s always a good idea to keep an eye on costs until you’re happy that you understand the cost profile. Suffice to say that I am no longer concerned about expenditure on Azure Automation, at least not for the work that I do (famous last words…).

Tracking Access for Azure Automation PowerShell

Tenant administrators tend to like to know what’s happening. To gain an insight into the usage of Azure Automation accounts, we can analyze the Azure AD sign-in logs for the service principals of these accounts. For example, this code uses the Microsoft Graph PowerShell SDK to connect and fetch audit records for service principal events. It then groups the records to show the count of events for each service principal:

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Select-MgProfile Beta
[array]$AuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 2000 -Sort "createdDateTime DESC"
$AuditRecords | Group-Object ServicePrincipalName | Sort-Object count -Descending | Format-Table Name, Count

Name                                                              Count
----                                                              -----
ExoAutomationAccount_Y6LgjDYIfPnxmFzrqdbaClsnTD/gN4BNnVMywiju5hk=   119
Graph Microsoft 365 Groups Membership Report                         84
Clean up Exo Mailboxes                                                6
PS-Graph                                                              6
ServiceCommunications                                                 5
PopulateOrgContacts                                                   2

Each access to a resource (like signing into the Graph) generates an audit record.

$AuditRecords | ? {$_.ServicePrincipalName -eq "Clean up Exo Mailboxes"} | Format-Table ServicePrincipalName, CreatedDateTime, ResourceDisplayName, ipaddress

ServicePrincipalName   CreatedDateTime     ResourceDisplayName IPAddress
--------------------   ---------------     ------------------- ---------
Clean up Exo Mailboxes 12/08/2022 05:33:12 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 07/08/2022 15:32:34 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 03/08/2022 16:24:01 Microsoft Graph     78.17.104.68
Clean up Exo Mailboxes 02/08/2022 23:23:50 Microsoft Graph     78.17.104.68
Clean up Exo Mailboxes 02/08/2022 17:08:26 Microsoft Graph     51.171.212.123
Clean up Exo Mailboxes 01/08/2022 20:41:35 Microsoft Graph     51.171.212.123

In passing, the large number of sign-ins for the service principal for the app used by the Graph-based Microsoft 365 Groups Membership Report arise from a mistake I made when publishing the report script in GitHub. Unhappily, I included the tenant identifier and app identifier for my tenant (now fixed), and people continue to try to run the script using those values. In the last week, I’ve seen sign in failures from many locations, as I discovered by looking at sign in logs with a failure status.

ForEach ($R in $AuditRecords) {
 $Status = $R.Status.ErrorCode
 $City = $R.Location.City
 If ($Status -ne 0) {
 Write-Host ("{0} Status {1} City {2}" -f $R.CreatedDateTime, $Status, $City, $R.IPAddress) }
}
26/08/2022 20:20:49 Status 7000215 City Sanger
26/08/2022 18:16:44 Status 7000215 City Edmonton
25/08/2022 19:34:10 Status 7000215 City Montreal
25/08/2022 19:33:47 Status 7000215 City New Berlin
25/08/2022 19:24:09 Status 7000215 City Montreal
25/08/2022 11:16:23 Status 7000215 City Leigh
25/08/2022 11:11:15 Status 7000215 City Amsterdam
25/08/2022 10:42:51 Status 7000215 City London
25/08/2022 07:54:12 Status 7000215 City Frederiksvaerk
24/08/2022 19:44:03 Status 7000215 City Montreal
23/08/2022 20:57:05 Status 7000215 City Wellington
23/08/2022 13:43:48 Status 7000215 City Kobenhavn

The script contains a note to tell people to change the values to match a registered app in their tenant, but it seems to be ignored. The moral of the story is to always be sure to obscure authorization details in scripts available publicly.

Azure AD sign-in records for managed identities are fetched with:

[array]$AuditRecords = Get-MgAuditLogSignIn -Filter "(signInEventTypes/any(t:t eq 'servicePrincipal'))" -Top 2000 -Sort "createdDateTime DESC"

These records tell us what resources (services) the scripts run by the managed identity use. For instance, these records are generated by calls made to connect to Teams (as an administrative app), run a Graph request, fetch secrets from Azure Key Vault, and fetch an access token using the Azure management API.

$AuditRecords | Format-Table CreatedDateTime, ResourceDisplayName

CreatedDateTime     ResourceDisplayName
---------------     -------------------
30/08/2022 15:35:02 Skype and Teams Tenant Admin API
30/08/2022 15:35:01 Microsoft Graph
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:35:00 Azure Key Vault
30/08/2022 15:34:49 Windows Azure Service Management API

More to Discover About Azure Automation PowerShell

A great deal of information is available for administrators to fetch and analyze to help understand the usage of Azure Automation in their tenant. I’m not done with my investigations yet. I expect to find other interesting aspects of Azure Automation to investigate. And when I do, I shall share my findings.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.