Azure AD: Increasing Security within the MFA Experience

MFA push notifications – one of the more polarizing MFA options available within Azure AD. From a usability perspective, the perception is that it’s less interruptive and less complex for end users. From a security perspective, it’s a low barrier of entry for a malicious actor; especially when targeting a user who may approve push notifications for MFA without much thought.

We have seen Microsoft implement various methods of interaction into push notifications to try and combat users just hitting Approve without a second thought. The Authenticator App for passwordless, sometimes referred to as phone sign-in, already has number matching implemented. But this never made it into our more common corporate MFA scenarios – until recently when additional options for the Authenticator App showed up in Public Preview.

After reviewing the details within enabling of number matching and additional context, the effort is a handful of minutes of work – organizations can categorize this one under the ‘low effort/high return’ security bucket.

Number Matching

Number matching is the component that creates a stronger second factor for our end users, because they will no longer be able to just hit Approve to that push notification. According to the Microsoft Docs article, once number matching goes GA, it will be enabled within all tenants a few months after. It’s tough to tell at this point whether customers will then have the option to retroactively disable number matching, but the interface makes it seem like it could be possible – not that it would be recommended.

Per Microsoft number matching will support the following scenarios:

• Multi-factor
• Self-service password reset
• Combined SSPR and MFA registration
• AD FS adapter
• NPS extension

Probably should place an asterisk on the NPS extension, because unless you are using PAP as your RADIUS protocol, push notifications will “downgrade” to an Approve/Deny without number matching (there is no ability to interact with EAP/MS-CHAPv2).

Enabling Number Matching

Again, will speculate that the long term goal is that number matching will be enabled by default in all tenants, and it’s going to become the new normal for our end users. But with this in Public Preview at the moment, it’s something we have to opt into.

Also, we have the choice of either enabling number matching for the entire organization or for a group of users; the latter allowing for more finesse in testing, piloting, staged rollouts, and the such.

Referencing the docs article linked above, it’s a relatively straightforward process. The article itself actually comes across at first as if you have to use Graph for updating/creating the policy; when you scroll down within it, you’ll see that it can also be performed through the portal. We’ll run through here looking at the options through Graph and seeing how they impact what the portal looks like.

Before jumping into things, I will note that the changes were relatively quick to notice within my test tenant – within a few minutes the changes were apparent to my test users. Likewise with testing of disabling the settings.

Gathering the Current State

Before making any changes, let’s check out the current state of our policy.

In order to perform the actions within Graph Explorer, you will want to sign-in, and make sure that you consent to Policy.Read.All and Policy.ReadWrite.AuthenticationMethod permissions.

We can do this by running the following query in Graph Explorer:

GET https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

Which in our current tenant returns the following:

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity",
    "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
    "id": "MicrosoftAuthenticator",
    "state": "enabled",
    "includeTargets@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodsPolicy/authenticationMethodConfigurations('MicrosoftAuthenticator')/microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration/includeTargets",
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false,
            "authenticationMode": "any",
            "outlookMobileAllowedState": "default",
            "displayAppInformationRequiredState": "default",
            "numberMatchingRequiredState": "default"
        }
    ]
}

When we look in the portal we see the following:

It’s important to note that default = Microsoft managed. And you may be asking, what exactly is Microsoft managed? Microsoft managed effectively is the setting that allows Microsoft to make a decision as to whether or not these settings should be enabled in your tenant. Back to the thought earlier, eventually Microsoft managed will likely be the way in which Microsoft makes the decision to enable things in your tenant once it’s GA.

Enabling for a Group

If you are looking to enable this for a single group, it’s just a matter of updating the returned content from our Graph query, and running a PATCH. We simply will replace the all_users portion of the policy with the Azure AD groups ObjectID, and update numberMatchingRequiredState with enabled.

PATCH https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity",
    "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
    "id": "MicrosoftAuthenticator",
    "state": "enabled",
    "includeTargets@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodsPolicy/authenticationMethodConfigurations('MicrosoftAuthenticator')/microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration/includeTargets",
    "includeTargets": [
        {
            "targetType": "group",
            "id": "e39dfee7-4551-4836-adbb-859953e2cba6",
            "isRegistrationRequired": false,
            "authenticationMode": "any",
            "outlookMobileAllowedState": "default",
            "displayAppInformationRequiredState": "default",
            "numberMatchingRequiredState": "enabled"
        }
    ]
}

As long as we get a 204 response, everything was successful. Looking in the portal again, after a refresh we will see:

If you’re using the Authenticator App for passwordless (phone sign-in), this is where it can become confusing. If you had previously targeted all users for allowing passwordless through the Authenticator App, and now you’ve added this group, you’ll notice the targeting has changed. Subsequently if you have users go to enroll for passwordless through the Authenticator App, they will see:

We will want to make sure that we are now targeting two groups – a group that will allow for passwordless through Authenticator App, and the second being used for number matching. In our tenant this looks like:

PATCH https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity",
    "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
    "id": "MicrosoftAuthenticator",
    "state": "enabled",
    "includeTargets@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodsPolicy/authenticationMethodConfigurations('MicrosoftAuthenticator')/microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration/includeTargets",
    "includeTargets": [
        {
            "targetType": "group",
            "id": "e39dfee7-4551-4836-adbb-859953e2cba6",
            "isRegistrationRequired": false,
            "authenticationMode": "any",
            "outlookMobileAllowedState": "default",
            "displayAppInformationRequiredState": "default",
            "numberMatchingRequiredState": "enabled"
        },
        {
            "targetType": "group",
            "id": "44a9449d-ae6e-4d0b-bd40-c599dcb07441",
            "isRegistrationRequired": false,
            "authenticationMode": "any",
            "outlookMobileAllowedState": "default",
            "displayAppInformationRequiredState": "default",
            "numberMatchingRequiredState": "default"
        }
    ]
}

And if we look in the portal we will see:

In this instance, Security Ring 0 is the group with number matching enabled, and Security Ring 1 is the group with number matching left to default (Microsoft managed).

A few items to note:

• You cannot enable number matching on more than one group, if you attempt to do so through Graph you’ll receive a 400 error, and within the portal the option is greyed out.
• You cannot enable number matching on a group and also reference the all_users context. One may wish that you could target all users and then just selectively enable number matching on the group, however, if you attempt to reference all_users and a group within the policy, you’ll receive a 400 error.

Enabling for All Users

The enablement for all users is even simpler. Same PATCH process, but instead we just leave the group set to all_users, and change numberMatchingRequiredState to enabled.

PATCH https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity",
    "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
    "id": "MicrosoftAuthenticator",
    "state": "enabled",
    "includeTargets@odata.context": "https://graph.microsoft.com/beta/$metadata#authenticationMethodsPolicy/authenticationMethodConfigurations('MicrosoftAuthenticator')/microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration/includeTargets",
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false,
            "authenticationMode": "any",
            "outlookMobileAllowedState": "default",
            "displayAppInformationRequiredState": "default",
            "numberMatchingRequiredState": "enabled"
        }
    ]
}

Now when we go look in the portal:

Disabling Number Matching

Ideally you will not be in a position to need to disable number matching, but in the case that you need to, it’s just a matter of setting numberMatchingRequiredState to default. Again, if you set this to disabled, there may be a chance that you will be in a state where your tenant will miss when this rolls out across all tenants.

Additional Context

Along with number matching, we can enable additional contextual information about where the user is coming from with a map showing the rough geographic area, as well as what application is requesting the approval. Details of this process come from the Microsoft Docs article.

While both mechanisms provide some additional security mechanisms to our end users, additional context alone is not going to prevent an unengaged user from selecting Approve, which is why additional context in itself should be considered a passive security mechanism. Number matching, to contrast, is active, because the user will not be able to perform MFA without interaction.

Enabling Additional Conext

To enable additional context, whether for all users, or for a group, follows the same processes as enabling number matching. The only difference is we are focusing on the property displayAppInformationRequiredState.

Out of the box, this property will be set to default when observing it’s value through Graph, or Microsoft managed in the portal. We can toggle this to enabled or disabled.

A few items to note specific to additional context:

• When enabling additional context and using the Authenticator App for passwordless (phone sign-in), the app only receives policy information every 7 days. Because of this, users may not see a behavioral change for up to 7 days after.
• The NPS extension does not support providing additional context. Being that the NPS extension is simply signaling for MFA to be called and primary authentication is happening against Active Directory, it makes sense that user location context is not available.

Final Notes

As with all things that impact and change the way our users interact with our systems, while this may be an easier win from a security perspective, organizations will want to make sure that they communicate this change properly to end users. A rushed rollout or lack of communication is an almost certain way of creating friction with our end users, and potentially hurting the efforts to increase organizational security.