Practical Graph: Nag Users to Upgrade to a Strong Authentication Method

Find Accounts Using SMS for MFA and Ask Them to Upgrade to a Stronger Authentication Method

Microsoft introduced the concept of authentication strength for conditional access policies in 2022. The idea is simple. Each type of authentication is assigned a different strength from weak to very strong. Conditional access policies can use authentication strength to decide whether a connection to a resource should succeed or be rejected. For instance, a conditional policy to protect access to a SharePoint Online site holding very confidential material could reject connections unless a phishing-resistant authentication strength proves the identity of a user. In this context, phishing-resistant means something like a FIDO2 key or the Microsoft Authenticator app.

Unfortunately, many users believe that they protect their accounts with multifactor authentication (MFA) by using SMS as the authentication method. Although receiving a one-time passcode via SMS (or even WhatsApp in some geographies) and using the code to respond to an authentication challenge is safer than relying on traditional password credentials, the fact is that using SMS for MFA responses is outdated. Many commentators consider SMS to be no longer secure enough to use in production. The weakness of using SMS for MFA responses is not just an issue for Entra ID and Microsoft 365, as evident in a recent report that 95% of Coinbase accounts taken over by attackers in 2023 used SMS for MFA. If you want more information about why getting away from SMS is good for Entra ID, read this article.

I usually hate to nag, but sometimes people need a little nagging to do better. In this article, I explain how to find which user accounts are using SMS for MFA responses and how to nag those people to upgrade to a more robust and secure authentication method through personalized email.

Setting the Scene

The script I wrote uses the Microsoft Graph PowerShell SDK in app-only mode. As you might recall, the normal Graph SDK interactive sessions use delegated permissions, which mean that the available information depends on the administrative roles held by the signed-in user. I wanted code that could run as a background process and could send email from a shared mailbox, so that means using app-only mode. This involves creating a registered app in Entra ID, assigning permissions to the app, and uploading an X.509 certificate. The required permissions are:

• User.Read.All: Read details of user accounts. The User.ReadBasic.All permission is not sufficient as the script filters for licensed accounts to avoid processing utility accounts like those created for room and shared mailboxes.
• UserAuthenticationMethod.Read.All: Read the authentication methods registered for user accounts. This is how we discover if someone is still using SMS.
• Mail.Send: Send a message from a user or shared mailbox. In app-only mode, Mail.Send allows access to all mailboxes unless it’s restricted by RBAC for applications.

After making sure that all prerequisites are met, we can connect to the Graph and find some accounts:

$Thumbprint = '32C9529B1FFD08BCD483A5D98807E47A472C5312'
$AppId = '9e289bb8-05bd-486a-aaec-55ecac4aa6eb'
$TenantId = 'a662313f-14fc-43a2-9a7a-d2e27f4f3478'
Connect-MgGraph -NoWelcome -AppId $AppId -TenantId $TenantId -CertificateThumbprint $Thumbprint

# Find licensed user accounts
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" `
    -ConsistencyLevel eventual -CountVariable UsersFound -Sort "displayName" `
    -Property Id, DisplayName, GivenName , UserPrincipalName, UserType, Mail
If (!$Users) {
    Write-Host "No user accounts found"
    Exit
}

Checking User Authentication Methods

The next stage in the script is to check the authentication methods registered for each licensed account. The script calls the Get-MgBetaUserAuthenticationSignInPreference cmdlet to retrieve the user’s sign-in preferences. Here we discover if the account uses the systems-preferred authentication method (meaning that Entra ID picks the strongest available authentication method), and the user’s preferred method for secondary authentication (like SMS).

The output below shows that the account uses the system-preferred authentication method and that the user prefers the “push” method, meaning that Entra ID sends push notifications for response in the Microsoft Authenticator app:

$Methods = Get-MgBetaUserAuthenticationSignInPreference -UserId $User.Id

$Methods

IsSystemPreferredAuthenticationMethodEnabled UserPreferredMethodForSecondaryAuthentication
-------------------------------------------- ---------------------------------------------
True                                         push

The script can use user sign-in preference information to find the accounts that don’t use the system-preferred method and have selected SMS as their preferred secondary authentication method. The output is a list of users and their authentication methods.

We might not want to send nagging emails to some accounts, so the script includes arrays of individual users and a domain to exclude when the script creates two lists: accounts that use SMS and accounts that don’t use MFA (no registered method). Exclusions allow for situations where it doesn’t make sense to send nagging messages to users who might be in the process of switching to a new authentication method.

# Define domains and specific users that we don't want to send nagging emails to
[array]$UserNoNag = 'Azure.Management.Account@office365itpros.com'
[array]$DomainsNoNag = 'office365itpros.org', 'contoso.com'

# Find people using SMS as the authentication method that aren't in the excluded list of accounts or domains
[array]$UsersToNag = $Report | Where-Object {
    ($_.Method -eq 'SMS') -and ($_.UserPrincipalName -notin $UserNoNag) -and `
    ($_.UserPrincipalName.Split('@')[1] -notin $DomainsNoNag)
}
# Do the same for users who have no MFA method
[array]$UsersNoMFA = $Report | Where-Object {
    ($_.Method -eq 'None') -and ($_.UserPrincipalName -notin $UserNoNag) -and `
    ($_.UserPrincipalName.Split('@')[1] -notin $DomainsNoNag)
}

Sending Nagging Email About Upgrading to a Stronger Authentication Method

The code to send nagging emails to accounts to ask them to dump SMS and choose a stronger authentication method is straightforward:

• Define the account that the message comes from.
• Define an HTML-format body part customized for each user.
• Create a message structure containing the message parameters like To, subject, body, and so on.
• Call the Send-MgUserMail cmdlet to send the message. Figure 1 shows an example of a message delivered to a user’s mailbox.

Automate the Nagging Process

Running a periodic job to scan user accounts to find those who use SMS for multifactor authentication is a great use case for Azure Automation. The PowerShell code used here could be easily adapted to run as an automation runbook and linked to a schedule to run weekly, monthly, or whatever other period is deemed appropriate. You could even include some code in the runbook to update a Microsoft list in a SharePoint Online site with statistics about accounts still using SMS (and those with no registered MFA method) to track progress toward stronger authentication.

No Nagging in My Tenant

You can download the script described in this article from GitHub. If your tenant decides that it’s a bad idea to send nagging email to users, consider generating a report of the current MFA status for user accounts. You can then select your upgrade targets from that list and use whatever method you consider most appropriate to deliver the necessary coaching to cajole users to upgrade to a stronger authentication method.

Or if you really want to come down hard, remove SMS from the set of allowed authentication methods and see what happens. Be prepared for some squawks!