New Graph API Reveals MFA Preferred Authentication Method for User Accounts

In his copious spare time when he’s not reviewing chapters of the Office 365 for IT Pros eBook in his technical editor role, Vasil Michev writes for his blog. A recent post covers the Graph API to configure multi-factor authentication methods for Azure AD user accounts. This API is helpful because it fills in a gap in Graph coverage.

We’ve been able to report authentication methods set on accounts for quite a while, but setting methods has been problematic, especially with the upcoming deprecation of the Microsoft Services Online module (MSOL). Until now, the MSOL cmdlets to deal with “strong authentication methods” are what people have had to use in automation scenarios. Go to Vasil’s blog to learn about how to fetch and set the preferred MFA authentication method for Azure AD accounts (the signInPreferences object for accounts), or read up on the documentation.

Vasil makes the point that the new APIs have not yet appeared in the form of cmdlets in the Microsoft Graph PowerShell SDK. This is because a process needs to run (called AutoRest) to generate the SDK cmdlets from Graph APIs. Microsoft runs the process regularly, but some delay is always expected.

Invoke Graph Requests

The workaround is to use the Invoke-MgGraphRequest cmdlet. Here’s an example of using the cmdlet to fetch details of all Azure AD user accounts that have at least one assigned license (to filter out accounts used for room mailboxes, etc.) The filter used with the Get-MgUser cmdlet is a good example of using a lambda operator with what Microsoft calls a complex Azure AD query (the check assigned licenses). Because it’s a complex query, we need to use the ConsistencyLevel parameter and pass eventual as its value. If you haven’t seen this kind of filter used to find accounts before, store it away because it’ll be one that you use time and time again in your scripts.

After fetching the set of users, it’s a matter of running the query to return the authentication sign in preferences for each account and storing the details in a PowerShell list object. Here’s the code:

Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All

$Report = [System.Collections.Generic.List[Object]]::new() 
ForEach ($User in $Users) {
 $Uri = ("https://graph.microsoft.com/beta/users/{0}/authentication/signInPreferences" -f $User.Id)
 $AuthData = Invoke-MgGraphRequest -Uri $Uri -Method Get

 $ReportLine = [PSCustomObject]@{
    User   = $User.displayName
    UPN    = $User.userPrincipalName
    'System preferred MFA enabled' = $AuthData.isSystemPreferredAuthenticationMethodEnabled
    'System preferred MFA method'  = $AuthData.systemPreferredAuthenticationMethod
    'Secondary auth method'        = $AuthData.userPreferredMethodForSecondaryAuthentication }
  $Report.Add($ReportLine)

}

System Preferred Authentication Policy

An important factor to take into account is the existence of the Entra ID system-preferred authentication policy, which is now generally available. When this policy is active (as it soon will be for all tenants), Azure AD uses the strongest authentication method available to an account. A note in the documentation for updating authentication methods says that “this value is ignored except for a few scenarios where a user is authenticating via NPS extension or ADFS adapter.” That’s something to consider when updating user accounts.

Progress, Not Perfect

I don’t think anyone would say that things are perfect in terms of the transition from the old MSOL and Azure AD PowerShell modules to the Graph (APIs or SDK cmdlets). Migrations are never perfect, and we’ll be coping with the effects of this changeover for many months to come. That being said, it’s nice to see progress, albeit in small steps.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Managing Authentication Methods for an Entra ID User Account with PowerShell

Microsoft product manager Merill Fernando (of Graph X-Ray fame) posted an interesting tweet about a script he wrote to remove all the authentication methods from a user account. Entra ID supports a wide range of authentication methods (Figure 1) ranging from the classic username/password combination to using the Microsoft Authenticator app.

At the recent TEC conference, Microsoft VP for Identity Security Alex Weinert made a passionate plea for more Microsoft 365 tenants to secure their accounts with MFA. It’s shocking that only 26.64% of all user accounts use MFA. The figure for accounts holding an administrative role is higher at 34.15%, but that’s still poor. We need to do a better job of moving accounts to the right-hand methods shown in Figure 1.

Scripting Authentication Methods

Merill acknowledges that the script “is not pretty” because the Microsoft Graph does not currently support a way to find the default authentication method for an account. In short, the script attempts to delete an authentication method and if it fails it assumes that the method (like the Microsoft Authenticator app) is the default and leaves it to the last. You can only remove the default authentication method from an account if it’s the last and only method.

In any case, it’s a good script to have around just in case you need to reset an account. I’m not sure how often you’d want to do this, but I guess you might. All contributions to the admin toolbox are gratefully received.

Authentication Methods and the Microsoft Graph PowerShell SDK

Merill’s script uses cmdlets from the Microsoft Graph PowerShell SDK. I like the PowerShell SDK a lot, but sometimes it goes overboard in terms of the number of cmdlets it uses. I think this is due to the way that Microsoft generates the SDK modules and cmdlets from Graph APIs using a process called AutoRest. It’s nice to have a way to generate code automatically, but sometimes human intelligence could do better. Usually, Microsoft generates a new version of the SDK monthly, but sometimes errors creep in and several versions appear in a month (this just happened when versions 1.12 had several minor updates (current version is 1.12.3).

For instance, every authentication method has a separate cmdlet to add (New), update, and remove it from an account. The set of cmdlets used to remove methods in Merill’s script is:

• Remove-MgUserAuthenticationFido2Method
• Remove-MgUserAuthenticationEmailMethod
• Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod
• Remove-MgUserAuthenticationPhoneMethod
• Remove-MgUserAuthenticationSoftwareOathMethod
• Remove-MgUserAuthenticationTemporaryAccessPassMetho
• Remove-MgUserAuthenticationWindowHelloForBusinessMethod

Seven different cmdlets (you can’t remove the classic password method with one of these cmdlets), or 21 when you add the others for adding and updating methods. It would be simpler all round if the SDK consolidated everything so that we had one cmdlet to add, one to update, and one to remove authentication methods. However, I suspect that because separate API requests exist for each method, we are condemned to work with a confusing mass of cmdlets.

Reporting Authentication Methods

I decided that it would be a good idea to find out what authentication methods are in use. Microsoft makes this information available in the Entra ID admin center, but it’s no fun to simply accept what Microsoft wants to deliver in an admin portal. Instead, if we understand how the technology works, we can adapt it for our own purposes. For instance, I want to focus on tenant accounts rather than including guest accounts in the mix, and I want to extract some information about each authentication method to include in the report.

I already have a script to create an Authentication Method Report for Entra ID and another script to report administrator accounts that aren’t protected with MFA, but there’s always room for another (and this version extracts a little more information about each authentication method, like the phone number used for SMS challenges). Here are the important bits of the code (the full script is available from GitHub):

Write-Host "Finding licensed user accounts"
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
If (!($Users)) { Write-Host "No licensed users found... exiting!"; break }

$i = 0
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($User in $Users) {
 $i++
 Write-Host ("Processing user {0} {1}/{2}." -f $User.DisplayName, $i, $Users.Count)
 $AuthMethods = Get-MgUserAuthenticationMethod -UserId $User.Id
 ForEach ($AuthMethod in $AuthMethods) {
  $P1 = $Null; $P2 = $Null
  $Method = $AuthMethod.AdditionalProperties['@odata.type']
  Switch ($Method) {
     "#microsoft.graph.passwordAuthenticationMethod" {
       $DisplayMethod = "Password"
       $P1 = "Traditional password"
     }
     "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod" {
       $DisplayMethod = "Authenticator" 
       $P1 = $AuthMethod.AdditionalProperties['displayName']
       $P2 = $AuthMethod.AdditionalProperties['deviceTag'] + " " + $AuthMethod.AdditionalProperties['phoneAppVersion'] 
     }
     "#microsoft.graph.fido2AuthenticationMethod" {
       $DisplayMethod = "Fido 2 Key"
       $P1 = $AuthMethod.AdditionalProperties['displayName']
       $P2 = Get-Date($AuthMethod.AdditionalProperties['createdDateTime']) -format g
     }
     "#microsoft.graph.phoneAuthenticationMethod" {
       $DisplayMethod = "Phone" 
       $P1 = "Number: " + $AuthMethod.AdditionalProperties['phoneNumber']
       $P2 = "Type: " + $AuthMethod.AdditionalProperties['phoneType']
     }
    "#microsoft.graph.emailAuthenticationMethod" {
      $DisplayMethod = "Email"
      $P1 = "Address: " + $AuthMethod.AdditionalProperties['emailAddress']
     }
    "#microsoft.graph.passwordlessMicrosoftAuthenticatorAuthenticationMethod" {
      $DisplayMethod = "Passwordless"
      $P1 = $AuthMethod.AdditionalProperties['displayName']
      $P2 = Get-Date($AuthMethod.AdditionalProperties['createdDateTime']) -format g
    }
  }
  
  $ReportLine   = [PSCustomObject] @{ 
     User   = $User.DisplayName
     Method = $DisplayMethod
     Id     = $AuthMethod.Id
     P1     = $P1
     P2     = $P2 
     UserId = $User.Id }
  $Report.Add($ReportLine)
 } #End ForEach Authentication Method
} #End ForEach User

The code doesn’t include choices for every possible authentication method because examples aren’t available in my tenant. It’s easy to update the code to handle a method like the temporary pass. Figure 2 shows the output generated by the script.

One thing that puzzles me is why my account has multiple methods listed for the Microsoft Authenticator app. Both relate to my iPhone 11, but Entra ID might have created the second record after I renamed the phone. It’s something to look at when the time is available.

You can analyze the data to get further insights. For instance:

Write-Host ""
Write-Host "Authentication Methods found"
Write-Host "----------------------------"
Write-Host ""
$Report | Group-Object Method | Sort-Object Count -Descending | Select Name, Count
Authentication Methods found
----------------------------

Name          Count
----          -----
Password         33
Phone            21
Email            11
Authenticator     5
Fido 2 Key        2
Passwordless      1

The other scripts show how to deal with other aspects of reporting that might be important to you, like checking accounts for administrative roles, date of last sign-in, and so on. The nice thing about PowerShell is its flexibility. Cut and paste from different scripts to create a new take and meet your requirements. That’s a great capability to have.

Learn more about how Entra ID and the Microsoft 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.