3 min read
How will my tenant be affected by it?
If you already follow best practices and enforce MFA with either Conditional Accss policies or Security Defaults for all users accessing “All cloud resources” or just the “Microsoft Admin Portals” and “Windows Azure Service Management API”, then you will not feel the effect of this change, but if your company uses for example Azure CLI or Azure PowerShell scripts with hardcoded user account credentials, then they will be blocked from running, due to not being able to complete the MFA prompt.
Service Principals and Managed Identities are not affected by this change and will continue to run as normal.
How do I check which accounts are affected by this?
The easiest and most simple way to check if any user accounts are logging in to Azure PowerShell and Azure CLI with only single factor authentication is to check the sign-in logs. Below is a guide to check the default sign-in logs that are saved one month back for all users using the Entra admin center, and how to remediate it using a Managed Identity.
Note that depending on your setup, there may be accounts that only runs every few months or longer, that may not show up on the logs, which is why it is important to export sign-in logs and other important logs to a secure storage solution and keeping them for more than 30 days.
- Sign into the Microsoft Entra admin center and go to Users > All users > Sign-in logs and change the date to “Last 1 month”
- Press the Download button and pick Download CSV and then press Download on the “InteractiveSignIns_...” and the “NonInteractiveSingIns_...”
- When you have downloaded the CSV files, import them into an Excel table and filter by Application ID, for:
04b07795-8ddb-461a-bbee-02f9e1bf7b46 (Azure CLI)
and
1950a258-227b-4e31-a9cf-717495945fc2 (Azure Powershell)
Now you have the sign-in logs for all accounts that uses the affected app.
- Now you can go to the “Authentication requirement” collum and filter by “Single-factor authentication”
That leaves you with the list of all user accounts that sign-in without performing MFA. In this case there is one user account called nomfauser@mj-tech.dk that signs in using Azure Powershell (Az module) non-interactively in our test tenant.
How do I mitigate this?
Instead of using standard user accounts, it is recommended to utilize Service Principals or Managed Identities for all non-human logins, like PowerShell Scripts.
Ideally, Service Principals should use certificate authentication or using secrets that are stored securely in an Azure Key Vault.
Managed Identities are able to sign-in without utilizing secrets or certificates, if they are logging in from Azure Resources like Automation Accounts, Logic Apps, Azure Virtual Machines and many more.
In this example the user “nomfauser@mj-tech.dk” is used for an Azure Automation Account Runbook. Below I will show how to convert it to a more secure system assigned Managed Identity instead.
- First go to the specific Automation Account and then Account Settings > Identity
- Press “On” on the Status setting and afterwards “Save”, you will then be presented with the Managed Identity’s Object ID.
- Assign the Managed Identity the necessary permissions, remember to follow best practices and follow principal of least privilege.
After the necessary permissions has been given to the Managed Identity, then we need go to the Runbook in question and change the PowerShell script to instead utilize the Managed Identity instead of the user account. Below we can see the insecure hardcoded credentials that the script currently uses. - Change the script to authenticate using the Managed Identity by using the line “Connect-AzAccount -Identity”.
And there we go, now it will use its own Managed Identity for Authentication instead of a user account.
If you do not have time to convert all affected user accounts to either Service Principals or Managed Identities then you have the option to postpone the mandatory enforcement until the September 30, 2025 through this link using a Global Administrator account: https://aka.ms/managemfaforazure
Need help securing your Microsoft 365 services?
Remember to follow best practices regarding storing Service Principal secrets securely and following principal of least privilege.
If your organization needs assistance securing your Microsoft 365 services, Entra ID tenant or Azure Resources you can get both security assessments and hardening provided by itm8 Cyber Security. For additional information, read more at: https://itm8.com/cyber-security/identify and https://itm8.com/cyber-security/protect.