Add Number Matching and Additional Context to the Microsoft Authenticator App
I’m a big fan of using multi-factor authentication (MFA) to protect Azure AD accounts. At the danger of sounding like a broken record, basic authentication is a horrible thing to use for cloud accounts. Password spray attacks can steal user credentials and lead to tenant compromise. Microsoft is doing its best to remove basic authentication for Exchange Online by October 2022, an effort which I believe will help tenants protect user accounts better, even if it comes with some pain to upgrade clients, apps, and so on.
Another part of the puzzle is to improve the way MFA works to make it easier and more secure. A November 18 blog by Microsoft VP Alex Simons, one of the TEC 2021 keynote speakers, reveals two new features for the Microsoft Authenticator app. I think all Microsoft 365 tenants should consider enabling number matching and additional context as soon as possible. Thirty minutes of administrator work will improve user security (including the time to read the instructions). That’s not always the case.
Update: October 25, 2022: Microsoft has made number matching and additional context generally available.
Two New Capabilities
Number matching means that when a user goes through an MFA challenge, they see a number that they must enter in the Authenticator app to complete the authentication process (Figure 1). This mechanism is already used for passwordless authentication.
Additional context means that the Authenticator app displays extra information to users when asked to approve an authentication request. Two pieces of information appear. The same of the app requesting authentication and their sign-in location based on the device’s IP address. Of course, the accuracy of a device’s IP address depends on many factors, and in some cases will be plain wrong (today, Authenticator running on my iPhone told me I was in Offaly, some sixty miles from my real location in Dublin). However, it’s good enough to reassure people that the sign-in attempt is not from somewhere impossible, and when combined with number matching (Figure 2), gives the user enough information to understand a more complete context of the authentication request. The app name is that known to Azure AD, so Office 365 Exchange Online means OWA.
Updating Additional Context and Number Matching Through the Azure AD Admin Center
You can enable additional context and number matching for Authenticator by updating the settings in the Azure AD admin center. Go to the Authentication methods blade, select Microsoft Authenticator, and click the […] option to the far right under target to reveal the Configure fly-out. Set the value of both Show additional context in notifications and to Enabled (Figure 3).
Both features are labelled preview. It’s likely that they will become generally available in the near future.
Updating the Authenticator Configuration with the Graph Explorer
Although the easiest way is to configure the two features is to use the Azure AD admin center, you can also use the Graph Explorer to patch the Authenticator configuration.
The Graph Explorer is a tool that every Microsoft 365 tenant administrator should master to a point where they can run queries. The Graph APIs underpin many parts of Microsoft 365, and some settings and data are accessible only through Graph queries. Even if you don’t plan to ever write Graph API calls, you can still run commands through the Graph Explorer to see how queries work and what they return, and to occasionally update tenant settings. Although a GUI option exists in this case, it’s still a good example of how to use the Graph Explorer.
To enable number matching for the Microsoft Authenticator via the Graph, do the following.
- Open the Graph Explorer and sign in with a tenant administrator account.
- Input this query into the command box. Make sure that you chose the beta endpoint (the default is V1.0) and then click Run query.
https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator
- You will likely get an error because the Graph Explorer (an app) doesn’t have the necessary permission to access the Authenticator configuration. Click Modify Permissions and then the Open the permissions panel link to select Policy.ReadWrite.AuthenticationMethod from the set of Graph permissions. Click Consent and you’ll see the normal Permissions requested dialog to grant consent to the app. Accept the consent request and return to the Graph Explorer.
- Run the query again. This time the Graph Explorer has the necessary permission, and you’ll see the current configuration in the response box.
- Copy the JSON-formatted output and paste it into the request body box above. Change the value of the numberMatchingRequiredState (number matching) and displayAppInformationRequiredState (additional context) properties to Enabled. Only change the values. Don’t change the formatting or structure of the request body.
- By default, the Graph Explorer runs GET queries to return information. You want to update the settings, so select PATCH from the drop-down query type list. The information displayed by Graph Explorer should look like Figure 4. Click Run query to make the change. If you see a “No content – 204” response, the change is successful. You can validate that the configuration settings are what you expect by changing the query type to GET and running the query to see the current configuration.
Of course, you can also check the Authenticator configuration in the Azure AD admin center.
Limiting Features to a Specific Group
The approach described above enables number matching for everyone in the tenant. You can also limit the feature to a designated group by changing the Id property from “all_users” to the object identifier of an Azure AD group. For instance, let’s assume that you have a group called Azure AD Testers. To get the group identifier, look it up in the Azure AD admin center and copy the identifier from the group properties (Figure 5).
Alternatively, run this PowerShell command after connecting to the Azure AD endpoint:
Get-AzureADGroup -SearchString “Azure AD Testers” ObjectId DisplayName Description -------- ----------- ----------- 36fcfd60-9ad8-48ed-8c3c-ef36fc5d0c94 Azure AD Testers People who do early testing of Azure AD features
Update the Id property with the group identifier (36fcfd60-9ad8-48ed-8c3c-ef36fc5d0c94 in our example) and run the PATCH query to limit access to the features to the members of the designated group. Remember to run the GET query afterwards to check that the configuration contains the expected values.
Personally, I consider number matching and additional context to be so valuable that these features should be available to all users. However, I acknowledge that in enterprise tenants, a requirement to test and document any new feature before general introduction probably exists, so it’s good to have this flexibility.
MFA Marches On
Microsoft is gradually improving the capabilities and ease of use of multi-factor authentication and having a solid authenticator app is a big part of that work. It’s a mystery why MFA is not used by more Microsoft 365 tenants to protect users. Although I don’t think that number matching and additional context will tilt the balance to convince more to use MFA, there’s no doubt that the weight of evidence shows that MFA is a big part of stopping attackers penetrating Microsoft 365 tenants and compromising user accounts. Let’s hope the trend continues.
Does additional context require passwordless or would it work with just push?
I don’t believe it requires passwordless but I can’t be certain. Test it and see!
Do you know of a procedure to bypass additional context/number matching when the request to sign in is via a mobile app on the same device where authenticator resides? i.e. users complain of overlapping notifications and unable to see number matching without leaving the app on that device that they are trying to login to.
The users must be generating many authentication requests over a short period. I certainly have never had an issue with competing authentications. I can see how it might happen, but I have never had to cope with the situation.
Application context without location would be cool. We had a hard time to convince everybody to install authenticator on their private phones. If it shows their location, they will feel tracked
One observation that I have is that the additional context only appears on phones running the Authenticator app. Because it’s on a phone and the apps are very graphical, it seems to me that users will accept the context, especially as it is not very granular when it comes to precise locations!
Hi Tony,
What licensing levels/options are needed to implement these settings?
Thank you,
Chris
You need to be licensed to use MFA. The Office 365 plans include basic MFA while you can pay more for extra functionality through Azure AD premium licenses. See https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing.
Hi Tony,
Number matching is a feature that we implemented at least 3 years ago at IDEE.
We found it had more to do with how insider-threats -at the IDP i.e. Microsoft, the client or the SaaS MFA provider (IDP then) can manipulate authorization and the controls for it including the matching numbers.
As to your point about adoption, yes, a phone is a device we all have. But then again not everyone wants one, wants one or wants to use one. We found the same, especially in Europe.
This is why we have gone phone-free MFA at IDEE. It’s end-to-end passwordless (so not FIDO2) and use-case agnostic and GA in January ’22.
How is this good for MS365? Integration takes 20 min and so like many-a-time the best companion to a core Microsoft product is not made by Microsoft. We think it’s ok.
Hi Alex,
Of course, third party solutions are also available to help increase the security of Microsoft 365 tenants. However, it usually takes much longer than 30 minutes to organize the procurement of any third-partyy software. The point here is that you can put the Microsoft implementation of number matching and additional context into production within 30 minutes (and at no cost).
TR
Additional Context should probably be switched on in all tenants immediately.
The biggest issue is users hitting approve in the blind. This solves that problem. Duo has had this for years.
If you use the Azure AD MFA NPS plugin on-premise to secure for example the RDS Gateway of VMware Horizonservices there is no ‘gui’ to enter the response.
So somehow the ‘approve’ routine cannot (I guess it never will) be disabled for some MFA services.
Yes”I’m agree to save my data and policy.
I love that you included the Graph method 😍
Thanks. It’s a learning experience for people who haven’t gone near the Graph Explorer (or Graph queries in general).