The last couple of years, Microsoft has been pushing the usage of Multi Factor Authentication for logins to their Cloud Services. MFA, which requires that users authenticate with at least two factors, can reduce the risk of identity compromise by as much as 99.9 percent over passwords alone.

Now that more and more companies are implementing MFA, having the user account and password of a user by using phishing techniques is not enough anymore. But where security evolves, attacker evolve as well. 

One of the ways an attacker can circumvent MFA is by using a technique called SIM swapping, and more and more news articles surface where SIM swapping is being used to get access to an account.

Someone who wants to initiate SIM swapping will gather all kinds of information about the person which is targeted. That information is then used to contact the victims mobile phone provider asking to port the telephone number to another SIM card. From that point forward any phone call but also any SMS will be sent to the person having possession of the SIM card.

And with all the data breaches which happen today, attackers have enough personal information available to convince the phone company that the caller is also the owner of the phone number, or employees of the phone companies are bribed to perform the SIM swap. On a personal note, I often see that SMS messages are displayed on the locked screen of the user, which could potentially mean that if the phone gets stolen, it’s also possible to read the code from the locked screen.

Once an attacker has control over the phone number and knows the username and password of the user, it can login on behalf of the compromised user and do all kinds of bad stuff.

Within Microsoft environments, having the option to use SMS or phone call is an option which is standard enabled. And while having MFA configured is way better than not having any multi factor authentication, evolving with the methods attackers use is a must. Therefore we must get rid of SMS sign in or Phone verification and move towards other MFA methods which are more safe.

As you can see, we ultimately want to move towards Passwordless, I already wrote about this in an earlier article which can be found here: Have you already started your journey towards Passwordless authentication on your Modern Workplace?

Within Microsoft environments that safe way is by using the Microsoft Authenticator app, or by using a Security key.

Disclaimer: At time of writing this functionality is in public-preview, which means that Microsoft allows any customer with the proper Azure AD license to evaluate the new feature. Microsoft Customer Support Services will supply support services during this phase, but normal service level agreements do not apply. See also: Supplemental Terms of Use for Microsoft Azure Previews

In July this year Microsoft announced the public preview of “Authentication Methods to nudge to download Microsoft Authenticator“. And with this option available, we now have the option to push our users towards using the Authenticator app by friendly asking them to register the app if they use SMS or Phone call as their primary multi factor authentication method.

If you want to know which authentication methods have been configured for your users you can use the “User registration details” report, which can be found under the monitoring section of the Authentication Methods policy. The report displays your users and shows the registered methods.

So what we are targeting here, are users which have Mobile Phone configured, but not the Microsoft Authenticator App. These users will be nudged using this new functionality. I will show later in this article what the end user experience looks like.

So let’s continue with how to configure this functionality.

User registration details

How to configure the Nudging functionality

Before you can configure this functionality I advise you to check the necessary prerequisites, which are:

  • Only Azure MFA is supported, so if you still have an on-premises MFA this will not work
  • Users who have already set up Microsoft Authenticator will not be nudged, even though their primary method is SMS
  • Microsoft Authenticator must have been enabled in the MFA registration policy and Authentication methods policy

The Authenticator settings can be verified by visiting the Azure Active Directory admin center and select Security -> Authentication Methods. For the Authentication methods either Any or Push needs to be configured, if Passwordless is specified, the Nudging will not be applicable.

Authenticator settings in the Authentication Methods policy

The MFA registration policy is defined on the Multi -factor authentication page, which can be verified by visiting the Azure Active Directory admin center and select Security -> MFA -> Configure | Configure cloud-based MFA settings.

Verification options in the MFA registration policy

Enabling Nudging via the Graph API

Nudging can be enabled directly in the Graph API, chances are that Microsoft is going to incorporate these settings in the Portal GUI later on, but for now we can use the Graph Explorer to make the necessary changes.

The Microsoft documentation provides really good guidance on how to do this, and even provides several .JSON files which you can load (after modification) into the Graph Explorer to enable the functionality. Below is an example for how I configured this in our tenant, but if you want to implement this more granularly you have the option to scope to Groups. You can also specify the snooze duration, since the end user has the option to snooze the notification for an x amount of days if the value is more than 0 (in days)

Be aware to thoroughly read the documentation, fully understand what you are doing before making any modification. Compare using the Graph Explorer, with using the Registry Editor within Windows. You can make advanced settings, but you can easily screw things up as well.

Graph Explorer

The next slideshow shows the end user experience for a user which doesn’t have the Authenticator app configured as an MFA method.

The Nudge itself – Improve your sign-ins

So, once all your users have the Microsoft Authenticator app configured (we can use the report mentioned earlier for that), we can actually start phasing out the Mobile Phone text and call options as an available and accepted method. We can do this by modifying the MFA registration policy.

MFA Registration policy

What will be the impact if we remove these methods?

If we remove the authentication methods in the MFA registration policy, this will impact your users, below are some answers to the questions I could think of.

What if user account which still only has SMS configured?

Once removed, and user only has Phone registered, the user only has the option to register one of the other available authentication methods before the login is complete and the user can access the resource.

Can the user still see the registered phone as a sign-in method?

Once removed, not see-able for the end user anymore while the administrator can still see it as a registered method.

User view
Administrator view

What about the default sign-in method?

If user had Phone (text/call) configured as default sign-in method before the MFA registration policy change, the next time the user signs in, they will be asked for the configured Microsoft Authenticator app method, which will be set as default as well.

Default sign-in method for user

If you have configured MFA within your organization, and that is working fine a next possible step would be to further improve your security by removing the Phone options from the authentication methods available. And while ultimately you may want to move towards Passwordless, there are some cases where this isn’t possible yet.

 You can also use Phone as a method when doing a password reset, you might want to consider removing that option as well, making the Authenticator app, Email and Security questions the available options left to use when Self Service Password Reset (SSPR) is being used. See the following article for more information about SSPR: Enabling Self Service Password Reset (SSPR) for your Modern Workplace users

Self Service Password Reset – Authentication methods

There is also still this concept of SMS-based authentication. SMS-based authentication is used in specific scenario’s and allows users to sign in without providing, or even knowing, their user name and password. They use their phone number as their username and will be sent an SMS which serves as a temporary password. Microsoft makes this method available to login to Teams and is specifically created for so called “Frontline Workers”. It will be interesting to see, if Microsoft comes up with a safer solution for this specific scenario.

https://www.microsoft.com/security/blog/2020/03/05/it-executives-prioritize-multi-factor-authentication-2020/

https://eu.usatoday.com/story/tech/columnist/2021/09/01/two-factor-authentication-why-you-shouldnt-always-choose-text-option/5682053001/

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/flash-whitepaper-why-mfa-is-a-top-priority-in-2020/ba-p/1194467

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#public-preview—-authentication-methods-nudge-to-download-microsoft-authenticator

https://docs.microsoft.com/en-us/azure/active-directory/authentication/how-to-nudge-authenticator-app

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-sms-signin

Previous articleHoneypot: The Last Reconnaissance
Next articleFixing Asus RoG freezes and crashes
avatar
I started my career in 1995 as a System Engineer in the broadcast industry, building and maintaining video editing suites and television studio's and later specializing in Telecine equipment. In 1998 I switched to a first line support function within the Information Technlogy on the dealing room of a large bank, working my way up to a 3rd line support engineer. From this position i started to work on projects, which eventually resulted in projects where I worked across the border. In this period I implemented and designed several deployment solutions for mass rollout of workstations, laptops and servers. Since 2009 I switched to a consultancy function mainly focusing on but not limited to System Center design and implementation projects, besides that I became a Microsoft Certified Trainer (MCT) and currently teach System Center Related Classes (SCCM, SCOM and SCSM). In Januari 2010 I received the Microsoft MVP award with the expertise Setup & Deployment which was extended in 2011 and 2012. In 2013 and 2014 I was awarded the VMware vExpert award. In october 2014 I received the Microsoft MVP award with the expertise System Center Cloud and Datacenter Management (SCCDM).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.