Azure AD System-Preferred Authentication Policy

System-Preferred Authentication Policy Selects Strongest Available Authentication Method

Updated 16 May 2023

Microsoft 365 message center notification MC523051 (3 March 2023) announces the public preview of another Azure Active Directory tweak to make multi-factor authentication (MFA) the de facto authentication method for Microsoft 365 tenants. The preview rolled out on 1 March and should be effective in all tenants. There is no matching Microsoft 365 roadmap item, probably because this is an Azure AD change. However, everything Azure AD does impacts Microsoft 365, so it’s a good idea to pay attention to the updates applied to the directory.

What System-Preferred Authentication Means

System-preferred authentication is a method to allow the system to decide which authentication method to use when a user signs in. Settings in the tenant authentication policy control how system-preferred authentication works. The settings are:

• Enabled: Azure AD can decide which authentication method to use for the group covered by the policy. A special “all_users” group covers every Azure AD account in the tenant. You can define a different security or Microsoft 365 group if you want to limit the policy to specific users.
• Disabled: The policy is disabled for the selected group.
• Default: Azure AD can decide.

Essentially, when the system-preferred authentication policy is on within a tenant, Azure AD evaluates the authentication methods registered for an account and selects the strongest available method. For instance, the account shown in Figure 1 has several registered authentication methods available to satisfy an MFA challenge issued by Azure AD. When the system-preferred authentication policy is disabled or is enabled for specific users, accounts that are not covered by the policy see and can select from all available methods. For instance, instead of using the Microsoft Authenticator app, they could choose to receive an SMS text message on their phone that they then input to satisfy the challenge.

When the system-preferred authentication policy is enforced, Azure AD only shows the strongest authentication method. In this case, the strongest authenticator method is to approve a request on the Authenticator app, so that’s the challenge made by Azure AD. Users don’t get to choose from the other methods unless the Authenticator app is unavailable for some reason.

If an account doesn’t have a registered MFA method, it will continue using user/password credentials because that’s the strongest authentication method available for the account.

We’ve seen Microsoft emphasize authentication strengths in other ways previously. For example, in October 2022, Microsoft introduced the ability for conditional access policies to evaluate access to resources based on the strength of authentication used in a sign-in.

Where this is all leading to is revealed in the latter part of MC523051. Here we learn that when the system-preferred authentication policy is generally available (May 2023), administrators can update the policy through the Entra admin center (or Azure AD admin center). However, three months later (July 2023), Azure AD will enforce system-preferred authentication method choice for all accounts.

Update: In an April 6 update to MC523051, Microsoft announced that they have pushed the enforcement date for all accounts out to October 2023. On May 16, 2023, Microsoft announced that the system-preferred authentiction policy is now generally available.

A Mechanism to Help Organizations Dump SMS MFA Challenges

The key statement in the announcement is that the new policy “is an excellent approach for users to move away from the less secure telephony methods.” Microsoft wants customers to dramatically improve the percentage of accounts protected by MFA. In September 2022, Microsoft revealed that only 26.64% of all Azure AD accounts use MFA. The figure is better for accounts that hold an administrative role (34.15%), but that’s nothing to shout about.

In addition to increasing the use of MFA, Microsoft wants people to use better MFA. In other words, they want people to replace phone-based SMS challenges with authentication methods like FIDO2 keys, Windows Hello, or the Microsoft Authenticator app, all of which are resistant to phishing attempts. Recent updates to the Authenticator app like number matching and location details also help combat the effects of MFA challenge fatigue where users simply react to a challenge without thinking about where the challenge originated. Microsoft plans to implement number matching for all users of the Authenticator app on May 8, 2023.

I rather like the approach Microsoft is taking. It’s important to move users to better and stronger authentication methods to resist the probing of attackers. The remarkably successful campaign to remove basic authentication from email connection protocols deprived attackers of many account-compromised attack vectors like password sprays. Now, attackers focus on how to break through the barriers erected by MFA using techniques like SMS man-in-the middle and token theft.

I said that increasing MFA usage and dumping SMS challenges is the #1 thing for Microsoft 365 security administrators to do in 2023. System-preferred authentication helps achieve that goal.

Enabling the System-Preferred Authentication Policy

Because the necessary UI is not in the Microsoft Entra admin center, you can only enable or update the system-preferred authentication policy via a Graph API. The easiest methods to use are the Graph Explorer or the Invoke-MgGraphRequest cmdlet from the Microsoft Graph PowerShell SDK. The Graph Explorer is a good option for administrators who aren’t very experienced with Graph interaction.

Both methods require consent to use the Policy.ReadWrite.AuthenticationMethod permission to update the policy. If you’re a tenant administrator, you can grant consent through the Graph Explorer or when you run the Connect-MgGraph cmdlet to start an SDK session.

Figure 2 shows using the Graph Explorer to update the policy. To get to this point, I:

• Signed into my account (or any account holding the tenant administrator role).
• Selected PATCH as the command type (I want to update the policy).
• Selected Beta as the endpoint because the feature is not available through the production (V1.0) endpoint.
• Entered https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy as the URI for the Graph API.
• Created a request body for the PATCH command.

The request body is a JSON construct to tell the Graph what to do. In this instance, it says that the policy is enabled for the members of the group with identifier 76becc23-7aa4-4508-9162-dd7ba8d1e7b6. To enable the policy for everyone in the tenant, replace the identifier with the special all_users group.

{
    "systemCredentialPreferences": {
        "state": "enabled",
        "includeTargets": [
            {
                "id": "76becc23-7aa4-4508-9162-dd7ba8d1e7b6",
                "targetType": "group"
            }
        ]
    }
}

The response to a successful command is “No content 204.” This isn’t very satisfactory, so we can check the policy to see its settings by running a GET command against the same URI,

To validate the policy settings with the Microsoft Graph PowerShell SDK, run these commands:

Connect-MgGraph -Scopes Policy.ReadWrite.AuthenticationMethod
Select-MgProfile Beta
$Uri = "https://graph.microsoft.com/beta/authenticationMethodsPolicy"
$Policy = Invoke-MgGraphRequest -uri $uri
$Policy['systemCredentialPreferences'].IncludeTargets

Name                           Value
----                           -----
id                             76becc23-7aa4-4508-9162-dd7ba8d1e7b6
targetType                     group

The updated policy settings are effective immediately. Signing in as an account in the membership of the specified group should result in Azure AD selecting the strongest available authentication method and using it without offering the user the choice of their registered methods. Remember, if the account doesn’t use MFA, Azure AD continues to accept username/password credentials.

Update: The Microsoft Entra admin center now includes the option to manage the settings for the system-preferred authentication policy (Figure 3).

See Microsoft’s documentation for more information about configuring the system-preferred authentication policy.

Microsoft Authenticator App is Now the Standard

Viewing the system-preferred authentication policy as a single feature is a mistake. It’s part of a long-running Microsoft campaign to steadily improve the security of Azure AD account sign-ins. This latest step makes SMS MFA challenges less attractive to users because they won’t be able to go direct to the SMS method if a stronger method exists. The Microsoft Authenticator app is now the standard for MFA with Azure AD. Take that hint and embrace it.