Lately, it feels like my life has been centered around Azure AD MFA reporting and management. I had a couple of ideas this morning to really streamline some of my day-to-day.
The good thing is, to play with this, all you need is a free Azure AD Tenant. For my purposes, I just needed to be able to enroll an account in MFA and view/modify its MFA properties using the MSOnline module for Powershell.
Today, I published my script, Manage-AzureADMFAMethods on Github.
Unfortunately, the cmdlets available in MSOnline don’t give you a whole lot of options for MFA management. Thus, this script is only to manage…well, MFA Methods. Not MFA as a whole. Maybe another time…with another trial.
In this post I’m going to run through creating the Azure AD Tenant on an outlook.com account, making a new Global admin, and connecting to Azure AD in Powershell and running the script to manage MFA enrollment.
Getting Started in Azure AD
First, I created a new Outlook.com account, so I could start fresh. I didn’t want to make any assumptions about how my account that already had an Azure AD configured worked for this post.
From there, I went to portal.azure.com to access my Azure AD.
You’ve got to actually spin up a new Azure AD Tenant–it won’t be provisioned automatically. You can go to “Create a resource” and search for Azure Active Directory to begin. If you try to go to the AAD blade before this…you’ll just get an error.
Pay attention to what you name your AAD. The Initial domain name will be appended to all of your Azure AD accounts (see “quicksandtechaad.onmicrosoft.com” down in the corner). You can add a friendly domain later if you want to use this tenant long term. But, in my case, this is just a test. I’m not sure if I’m serious about spinning this out into a real Azure environment. This name can’t be changed later–so don’t burn up an initial domain name on a test that you might want later for a real environment.
Using the Script
So the first thing the script does is check for connectivity to Azure AD. If you’ve run the script before, or you’ve already run Connect-MsolService for other purposes, the script can go right ahead. (By the way, make sure you have the MSOnline module–Install-Module MSOnline will do it).
But wait–there’s a tenant but nothing in it…and also no way to connect. The Outlook.com account won’t work with the MSOnline module.
Go to the AAD Blade and create a new user. This user should be a global admin, too–to view the StrongAuthentication properties in Azure, a user has to have the Global Admin or Authentication Admin role.
This is the free, basic version of Azure AD. It doesn’t have the full MFA feature set. It lacks the ability to enforce enrollment through Azure AD Identity Protection. It lacks the ability to enforce the use of MFA through conditional access policies. Still, aka.ms/MFASetup will get you to the additional security verification page to set up an MFA factor, whether or not it is necessary. This page also has the benefit of requiring MFA to access, triggering any previously enrolled, valid factors. It’s a fine candidate to test MFA functions, even in a free tenant.
The account won’t do much, as it is an Azure AD account within the quicksandtechaad.onmicrosoft.com tenant and it isn’t licensed for anything, but it can now be used to log in on login.microsoftonline.com/Azure AD sign in pages.
After supplying the account password, more information is required–the user must enroll a method for MFA.
For this case, I’ve set up the Microsoft Authenticator app and put in a junk phone number. If you had configured the MFA service, there may be more or less options here–like office phone numbers (pulled from the Azure AD account’s properties), alternative phone numbers, etc. The MFA service settings also allow you to disallow certain methods, like SMS.
So now, [email protected] has some stuff filled out for StrongAuthentication properties. By searching for the account again through the script, we’ll get a dump of all this info.
There are a couple of things to note about this. As mentioned, you have to be a Global Administrator or Authentication Administrator to use this.
For Authentication Administrators, at least, the phone number may not be fully visible in the Azure AD blade. The StrongAuthenticationUserDetails property on the MsolUser, however, are not. This might be useful for troubleshooting.
It’s also good to check and see how many distinct and valid MFA enrollments a specific user has. The Phone Apps list will show if the user has configured the Microsoft Authenticator app, on multiple devices, and if the user has any OTP apps (Authy, Google Authenticator, authenticator.cc, etc…). As far as I know, these details cannot be found in the Azure AD portal.
By the way, the script works whether or not you’re using the old “additional security verification” style MFA enrollment or the new “converged” experience with SSPR (“preview features for registering and managing security info – enhanced” as per AAD).
When performing MFA administration, users inevitably lose access to their methods one way or another. The AAD GUI allows admins to “require re-enrollment” so the next time a user hits an MFA enforcement or enrollment workflow, they get brought to the “more info required” prompt and to their respected MFA enrollment experience.
The second option of the script is functionally the same as performing this step in the GUI. Note that this flow does not invalidate any existing access/refresh tokens out there.
Right now Azure AD Sign Ins doesn’t allow for filtering based on MFA. I figure my next steps for the script may be to pull down sign in logs and parse them myself for MFA based events. The MFA results in the sign in logs are useful diagnostic tools to share with users, since you can help users understand things like multiple prompts for multiple apps, or discover when users accidentally set the Microsoft toll free number for sign in verification to their blocked callers list and everything goes straight to voicemail…
Hope someone finds this useful!