Change to Beta Graph API Requires Update to User Password and Authentication Report Script

Last year, I wrote about how to exploit the newly-added Graph API to report the per-user MFA state for Entra ID accounts. As with all additions to the Graph, the new API used the beta endpoint, which is where APIs function when Microsoft is happy to expose the API in public while still knowing that some work is needed before the API can advance to the production (V1.0) endpoint.

Recently, a reader posted a comment about the article and said that when they ran the script in their tenant, no data showed up in the “Default MFA method” column in the report. I write scripts to illustrate principals and explore what’s possible rather than attempting to create production-ready code. In addition, it’s impossible for me to see what’s happening in another tenant, unless the tenant administrator gives me the necessary account with permissions, and that shouldn’t happen. My default response is therefore to ask people who report issues to do some basic PowerShell debugging by selecting the code where the problem seems to lie and running the commands to see what happens. Besides, I was on vacation, so I didn’t want to spend any time looking into what the issue might be.

Searching for the Problem

To cut a long story short, the person who reported the problem responded with sufficient data to indicate that an issue was present. After returning from vacation, it was time to open Visual Studio Code (and GitHub Copilot) and try to figure out what was happening.

The code looked good, and nothing seemed out of the ordinary. The script used Graph requests rather than cmdlets from the Microsoft Graph PowerShell SDK, but that’s a normal state with newly-released beta APIs because the AutoRest tool that generates SDK cmdlets from the API metadata hasn’t yet included the cmdlets in an SDK release. To make the code easier to read, I replaced a couple of API requests with SDK cmdlets and then noticed that the output from the Get-MgBetaUserAuthenticationRequirement cmdlet no longer contained details of a user’s default MFA method. This was the cause of the problem.

The Downside of Beta Graph APIs

Using beta APIs (or beta cmdlets) is a double-edged sword. The positive is access to functionality sooner than waiting for Microsoft to upgrade an API to a production release. Some APIs stay in the beta endpoint for years, and you can’t predict when Microsoft might consider an API to be reliable, robust, and performant enough to justify promotion from beta to production.

The downside is that beta features are prone to change based on developer and customer feedback, the need to accommodate changes elsewhere in the underlying workload, or as the side effects of bug fixing or tuning for performance. I have no idea why Microsoft removed the default MFA method output from the data reported by the cmdlet. Maybe it was because the UserPreferredMethodForSecondaryAuthentication property contains similar information.

A New User Password and Authentication Report Script

In any case, my script can only report what’s available, so I updated the code to remove the obsolete column and renamed the UserPreferredMethodForSecondaryAuthentication column to be “Preferred MFA method” (Figure 1). The change seemed to make sense at the time. If you disagree, feel free to create a GitHub push request to update the script. I’m happy to review any and all suggestions.

Don’t Depend on Beta Graph APIs

All of this goes to show that developers who rely on beta Graph APIs need to keep a wary eye out for changes that might impact their code. The change can happen at any time and probably won’t be flagged by Microsoft because it is, after all, a change to a beta API that’s expressly not intended for production use. I should learn my lesson (some day). In the meantime, enjoy the updated user password and authentication report script and all the other examples in the Office365itpros GitHub repository. I’m sure there’s a few more bugs lurking there that I need to attend to.

Need some assistance to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.