Prepopulate MFA phone authentication (Multi-Factor Authentication) details on a user in Azure Active Directory – This is the act of getting a known second factor added to a user’s account details in Azure AD automatically. These details are also known as the user’s “Strong Authentication Methods.”
Normally MFA enrollment is a manual process done with the Microsoft Authenticator App during first sign-in to a Modern Authentication capable app or website. However, a more basic second factor is most often know to IT. And that is the user’s cellular/mobile number, which, in a corporate environment, is usually owned and assigned by HR or IT.
With a recent addition to the Microsoft Graph API, it is now possible to add or replace a user’s strong authentication phone method programmatically. Although still on the Beta endpoint of the Graph API, you can use this with high confidence in production today – although it requires jumping through some hoops, which is why we wrote you this article. So it will be easier for you to configure and maintain.
A little history…
There have been various attempts and solutions for prepopulating MFA details throughout the last few years. In 2015, it became possible to do some parts of what this solution does with the MSOnline PowerShell Module. But when the backends of Self Service Password Reset (SSPR) and Azure Multi-Factor Authentication (MFA) got merged and brought us the magic of “Combined Registration,” the possibility to script against the strong authentication details was lost for some time, and only resurfaced with the option to get insights… Until now!
Overview of the MFA Automation solution
TL; DR; It will enable you to register the users automatically for MFA and SSPR at the same time!
The MFA Automation solution for prepopulating new and existing users with phone authentication details makes use of the following Microsoft technologies:
- Azure Automation.
- Microsoft Graph API (beta).
- Azure AD (P1).
- Combined registration
- (optionally) Azure Log Analytics.
- An Azure Subscription.
The cost of running this solution is next to nothing unless you have a considerable amount of users, in which case it is still very cheap compared to the amount of time saved.
Please notice the requirement for Azure AD P1, which is because you need to enable combined registration and have a license for Self-Service Password Reset (SSPR).
This article will cover the following subjects and guide you into a ready state for running in production.
- Required permissions
- Use cases for the MFA Pepopulation solution
- Installation of the solution in Azure
- Output explanation
- Log Analytics for enhanced monitoring
- Script explanation
- Opportunities for enhancements
DISCLAIMER: This solution is provided freely to the community as inspiration only. While we have done our best to test the solution for production use, we cannot take any responsibility for data loss or damage caused by the script or instructions provided in this article.
Permissions for the solution are a bit tricky since we initially wanted this to run with application permissions and not delegated as a user. But as the documentation states, only delegated permissions can be used to update a user’s authentication details. Furthermore, the user that we delegate the permissions to needs to be assigned some pretty hefty permissions (either of the roles listed below will do):
- Global admin
- Privileged authentication admin
- Authentication admin
In the installation guide, you will be using the “Authentication Admin” role. Because you always want to start with the least possible permissions. But in some cases, the “Privileged Authentication Admin” might be your role of choice since it can read the current phone number, which the “authentication admin” can not.
Since you will be working with authentication details and require the highest level of access in your tenant, you must have the “Global Administrators” role during the solution’s implementation. But if you are using Azure PIM, you must be prepared to grant an active, permanent assignment of “Authentication Admin” to the solutions service account.
Use cases for the Prepopulate MFA phone authentication solution
For companies that want to supercharge their MFA enrollment, this solution will allow them to achieve the following:
- Have the user registered for MFA and SSPR as part of the account provisioning process.
- Lockdown MFA registration completely.
- Get to compliant Multi-Factor Authentication state in record time!
- Have SSPR work from the user’s first day of work!
- Register those pesky users that never seem to get caught by
Installation of Prepopulate MFA phone authentication solution in Azure
This is what you came for!
Expand the following accordion items to read the guided steps. And remember that each part should be completed entirely and in order.
NB: As a good measure of caution, the guide assumes that you will be testing this solution on a small group of users. These users should be put in an Azure AD Security group. You will need the name of that security group in the “Configuring the Automation Account” part.
The script will output statistics and results in a specific format. This is to enable easy parsing by Log Analytics and enable a monitoring workbook for the results. Some example outputs from the script:
In addition to this output, the script also generates verbose logging, if enabled, for troubleshooting purposes.
Log Analytics for enhanced monitoring
Logging is important, especially when dealing with highly privileged details such as Multi-Factor Authentication. But accessing the logs in the Azure Automation account requires permission to read details on the job.
You might not want too many people to have access to the automation account itself. Forwarding the job stream to log analytics gives you the option to delegate access to the job logs.
This article’s scope does not include configuring Log Analytics – The following examples are provided as a recommendation on how to use Log Analytics with this MFA automation solution.
The recommended queries are as follows:
You can manually run all these queries or create a workbook containing all the queries above to have your own monitoring dashboard for the solution.
The monitoring dashboard could end up looking like this:
The workbook example can be downloaded from the same Github repository as the MFA Prepopulate script and imported into your monitoring workspace in Azure.
Authentication methods – Usage and Insights (Preview)
Microsoft recently released a dashboard into public preview, that allows you to monitor the overall status of your MFA and SSPR deployment. This dashboard can also help you asses how far your are with your journey, but keep in mind, the data also includes guest/external accounts.
We have been generous with inline comments, so please look at the source code in our GitHub repository if you would like to understand the inner workings.
Opportunities for enhancements
Some thins we never got around to automating.
Securing the Automation account
If you followed the guide explicitly, you now have a RunAs account with “Contributor” access to the subscription you provisioned the automation account into. For this solution, we are not using much of that access. If you want to limit the permissions of the account, look at the official documentation here:
Auto Renewing the RunAs account’s self-signed certificate
The RunAs account you created in this guide has a self-signed certificate that expires in one year. It would be best if you considered monitoring certificate expiration or adding some auto-renew solution.
Dealing with new Microsoft features often comes with some caveats that you must know before implementing and running this solution.
We hope you appreciate the tool we have provided to the community and will do us the honor of following us on Twitter and Linkedin for more great EMS content in the future!