Azure MFA - What happens to users registered with a method (SMS TEXT) after you remove that registration method as an option under MFA services?

Question

Azure MFA - What happens to users registered with a method (SMS TEXT) after you remove that registration method as an option under MFA services?

Pete Runyan Admin 31

We have deployed Azure MFA to 260 users. When our users registered for Azure MFA, they were presented with four MFA registration methods:

Phone call
SMS Text
MS Authenticator OTP
MS Authenticator push notification

About 50% of our users selected the SMS Text method.

We now want to remove the SMS Text and MS Authenticator OTP registration methods for any NEW USERS that are created in O365/Azure.

It appears that I can do this here:

If I remove the "text message to phone" and "Verification code from mobile app or hardware token" methods and save those changes, what happens to users who have already registered with those methods? Nothing? Do they have to re-register their MFA method? We want to turn off the text and OTP registration methods for any new users that get created in O365/Azure, but we do NOT want users that have registered with those methods to have to re-register or used a different method.

I can find nothing about what happens to users that have already registered for Azure MFA registration with a method that is then removed from the Azure MFA services setup.

Accepted answer

5 additional answers

Your answer

Answer 1

Marilee Turscak-MSFT 37,206 Microsoft Employee Moderator

If you remove SMS as an option, a user who previously got a phone call with the option to change to another option will no longer be able to change options.

Users who have phone or app as their defaults will not be affected, but users who set text message as their default will be required to re-register. In the registration they will be told that their organization needs further information and that they can only MFA using "call me." Users who previously had only the deselected options registered will be required to register again.

If you have SSPR enabled, changing the authentication methods available may prevent users from being able to use SSPR. From the Changing authentication methods documentation,

Changing the available authentication methods may also cause problems for users. If you change the types of authentication methods that a user can use, you might inadvertently stop users from being able to use SSPR if they don't have the minimum amount of data available.

In that scenario as long as the user has enough registered options (which you can enforce if you want by requiring two or more methods for SSPR) , then you shouldn't have an issue.

The main repercussion is that some users will need to re-register, but that shouldn't be that big of a deal.

Interestingly enough there's a really good blog post on this topic by Microsoft MVP Brian Reid. It's also covered a bit in the first document I linked but not as explicitly.

Pete Runyan Admin 31 Reputation points

2021-01-22T14:14:00.083+00:00

Thank you Marilee! That answers my question exactly. I wish the Azure MFA setup worked differently, as our long-range goal is to have all users registered with the MFA methods MS Authenticator push or phone call only. Since half of our users registered with SMS Text or MS Authenticator OTP, and turning off those methods in the Azure MFA services area would immediately force them to-register or lock them out of resources they need, we will have to undergo a great deal of effort to get them to re-register before disabling the MFA methods we want to get rid of.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2021-01-22T18:10:24.877+00:00

Yeah I can definitely see how that would be an inconvenience! If you leave a feedback request to change this I can share it around with the product team. https://feedback.azure.com/

Maybe they could add some sort of a toggle in the portal to allow existing users to use their previous MFA methods but prevent new users from using them.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2021-01-27T05:56:13.6+00:00

I just got word from a teammate that users should actually be able to use the old methods without re-registering. I had heard from another engineer that they would need to re-register, but my teammate says he's 100% certain that they can continue using the old methods, so there will be less of an impact to existing users. This does not appear to be documented so I'm going to check with the content team to confirm this. Thank you for your patience!
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2021-01-27T06:10:38.79+00:00

For SSPR they may need to re-register (as mentioned in the one document above), but for MFA they should be able to continue with the old methods.
Pete Runyan Admin 31 Reputation points

2021-01-27T14:09:38.99+00:00

Thank you Marilee, but I have to ask for an official response here before we make a change that has the potential to lock half of our users out of being able to access email, sharepoint, our client VPN solution, etc.

So you are ABSOLUTELY SURE that removing the Microsoft Authenticator OTP and SMS TEXT MFA methods from the Azure MFA Services setup WILL NOT REQUIRE USERS THAT REGISTERED FOR MFA WITH THOSE METHODS TO RE-REGISTER?

Best Regards,

-Pete
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2021-01-28T00:59:44.203+00:00

I have reached out to ask for an official statement.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2021-02-01T20:31:25.39+00:00

Hi Pete, I am still waiting for an official statement. My other contact says that the initial information is correct and they WILL, in fact, need to re-register.

I have asked them to test this and get this added to the official documentation one way or the other.

Will update you as soon as I know for certain!

Answer 2

prunyan 1

Hi Ian,

No, we are not entering passwords for the user accounts we are setting up on the WatchGuards. So there's no issue on having to update the WG user accounts passwords to match the user's AD account password. Another issue however, is there a bug in the WG management web GUI that will cause the web management GUI to slow down and eventually become unresponsive and time out (in the VPN SSL section of the web GUI - everything else in the web GUI continues to work fine). This issue is caused by having such a large number of user accounts setup on the WatchGuard directly. We work around this issue by using the WG System Manager instead. WG knows about this bug in the web GUI, and it is supposed to be fixed with a firmware upgrade soon.

Our experience with the WG and Azure MFA NPS extension is that either the phone call or Microsoft Authenticator PUSH methods work fine. It's only SMS TEXT and MS Authenticator OTP that don't work. Again, if you want the details of how we made all four methods work, we can discuss it. But long story short - you REALLY have to want all four of those methods to go through the setup hassle. And we REALLY wanted it. :-)

Best Regards,

-Pete

Ian Middleton 1 Reputation point

2021-07-08T17:45:52.777+00:00

As I suspected, Watchguard did not offer any new solutions or workarounds aside from pushing us to use their AuthPoint MFA solution. We already have our users trained to use Microsoft Authenticator, so I'd rather not introduce another MFA app. What I haven't been able to confirm anywhere yet is if something like a YubiKey would work as a second factor as it is not text based.

We are a public facing government org. and I don't anticipate WFH to continue much longer once we fully re-open, so I think we will stick with Push and phone call for now. Once we are fully open the staff that do not have corporate phones won't need VPN access and we will be just back to managers who have VPN access and they all have corporate phones.

Thanks for your quick replies. I will definitely keep your solution in mind should circumstances change.
Tristan Colo 1 Reputation point

2021-09-24T09:12:51.247+00:00

We have deployed AuthPoint as the MFA solution for 365 and SSL VPN and that seems to have fixed a lot of issues

This is because Microsoft still incorrectly passes the wrong group attribute in RADIUS (which is a technical issue for Microsoft to fix unfortunately....). We have seen some cases where we have clients that had Microsoft MFA for 365 items and WG MFA for SSL VPN and that has worked well, but as you mentioned that adds another token.

I like AuthPoint because they don't even have SMS as an option for MFA (this should really be phased out as it isn't even regarded as true MFA by NIST since it is easily spoofed - Section 5.1.3.1, Section 5.1.3.1, Section 5.1.3.3, Section 8.1). They have their own third-party TOTP tokens to prevent companies from buying smart-phones for people that are managed in the cloud and pretty affordable.

Sorry that you are having such issues. I am certified in WG FIrewalls, AuthPoint, Wireless, and Endpoint protection if you have any questions.

~T

Tristan Colo

NOTE: If you upgrade your firewall to newest firmware (Latest stable release I have tested is 12.7.1) then there is a direct integration with AuthPoint without needing a RADIUS server, just an AuthPoint gateway if you want AD sync.
Tristan Colo 1 Reputation point

2021-09-24T09:13:19.363+00:00

P.S. I have tested and the issue happens on the fortinet RADIUS VPN integration too. Microsoft just needs to fix their buggy client :/

P.S.S. AuthPoint does a fun thing with RADIUS MFA. The AuthPoint Gateway acts a RADIUS server itself that can use AD for authentication. If you have an old application that integrates with RADIUS but doesn't support push They give you a token option which will have you type in "<password><TOTP>" as the password. So if my password was "pickles9" and my MFA code was "123456", I would just type the password as "pickles9123456" instead of prompting... therefore integrating old applications, or devices that simply don't support push, with AD and MFA.

They have a bunch of integration guides here

(They also are a per user license cost that is flat rate that gives you unlimited integrations)

Answer 3

I also want to highlight the broader issue that forced our company into this situation with Azure MFA:

We use a WatchGuard Firebox M370 firewall, and many of our users work remotely over a client VPN solution. We use the Azure MFA NPS extension, which allows our WatchGuard firewall to use RADIUS to talk to our NPS server, which then talks to Azure MFA over the Azure MFA NPS extension when our users connect with the WatchGuard VPN client.

The Azure MFA NPS extension does NOT properly return RADIUS attribute 11 when using SMS TEXT or Microsoft Authenticator OTP as the MFA method. (RADIUS attribute 11 includes the group name that user belongs to in our Azure MFA conditional access policies. Since the Azure MFA NPS extension does not return RADIUS attribute 11 with the user's group name, our WatchGuard firewall cannot respond properly and complete the authentication for remote VPN users that registered with SMS TEXT or the Microsoft Authenticator OTP methods.) The Azure MFA NPS extension works fine for our WatchGuard firewall VPN connections for users that registered with the Phone call or Microsoft Authenticator MFA methods, because the Azure MFA NPS extension returns RADIUS attribute 11 for these methods.

This is a known issue. See this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension

Here's the relevant quote from that link explaining the problem:

"Also, regardless of the authentication protocol that's used (PAP, CHAP, or EAP), if your MFA method is text-based (SMS, mobile app verification code, or OATH hardware token) and requires the user to enter a code or text in the VPN client UI input field, the authentication might succeed. But any RADIUS attributes that are configured in the Network Access Policy are not forwarded to the RADIUS cient (the Network Access Device, like the VPN gateway). As a result, the VPN client might have more access than you want it to have, or less access or no access."

What I would like to know is WHY the Azure MFA NPS extension does NOT return RADIUS attribute 11 with the user's group membership for the SMS TEXT or Microsoft Authenticator OTP MFA methods? This lack of functionality is the main reason we will be forced to make half our users re-register with a different MFA method.

Ian Middleton 1 Reputation point

2021-07-07T14:11:21.963+00:00

We have run into the same issue with out Watchguard M470 SSL VPN.

I have a case open with Watchguard but I'm assuming that we will be told that it's a MS problem and they can't do anything about it.

It seems very strange that it works for push notifications but not OTP.

Our biggest issue is that we have many more staff than usual that typically wouldn't have VPN access but are WFH due to COVID and some of those staff do not have company-issued phones so we may run into some push-back if we start forcing people to install the Authenticator app on their personal phones.

Our Cyber Insurance is requiring MFA for our VPN so we are in a tough spot because of this limitation.

Answer 4

Hello Ian,

MS will not be able to help you with your problem with the WatchGuard M470. We were able, however, to come up with a workaround to the MFA method problem. It allows your users to use any of the four MFA methods available via Azure MFA. Caveat - the workaround is not fun, and requires lots of initial manual setup work. The workaround is implemented entirely on the WatchGuard. I do not believe WatchGuard support is aware of this workaround. We came up with it ourselves. A quick summary is as follows:

1) You will need to create some additional authentication servers on your WatchGuard.
2) You will need to create matching local users on the WatchGuard that match your AD accounts. In our case, that meant adding 260 users to the WatchGuard manually. This was distinctly not fun. There is no way to add them in any sort of automated fashion.
3) You will then have to make sure that your authentication server order is setup correctly on the WatchGuard so that users get processed correctly.

Let me know if you want the details, and I can send them along to you.

Best Regards,

-Pete

Ian Middleton 1 Reputation point

2021-07-07T15:24:55.407+00:00

Thanks for the update Pete!

In your step 2, are you entering passwords that match your user's AD passwords for all of your users on those local accounts? If so, how are you handling user password changes?

I just enabled and tested the phone call method and it works, so we may go forward with just the authenticator app and phone call methods as options as the phone call is a bit less heavy-handed of a requirement for those with personal phones.

Answer 5

prunyan 1

Hi Ian,

That sounds good. I hate to see anyone have to go through as much work as we did! The secret sauce (should you come to need it) is understanding the WG authentication servers and the authentication process flow.

1) In our case, we have our default authentication server setup with our internet domain name, and then it is configured to use the WatchGuard Firebox-DB, & RADIUS (to communicate with the on-prem NPS/Azure MFA), and Active Directory authentication processes.
2) Our second authentication server points to our local active directory and uses LDAP. But it's configured in such a way that you need to use some special logon formatting in the WG SSL VPN client to have it work. It's a kind of safety valve in the case the MS MFA service has issues and we have give users some other method for getting in. So it's not really in play in this scenario.
3) Finally we have the regular Firebox-DB authentication server for local accounts on the Firebox. Anyone who gets a local account on the firebox (which is all of our users that use the SSL VPN) get accounts here. It can use the Firebox-DB (and therefore the SSLVPN-Users built-in group) the RADIUS/NPS and LDAP connection pointing to the on-prem AD domain controllers.
4) The authentication server list and the priority order is what makes it all work. Number 1 allows our SSL VPN users to go ahead and authenticate with Azure MFA via NPS/Azure MFA extension and covers the phone call and MS Authenticator push method. If the user is setup to use SMS or MS Authenticator OTP methods, authentication server number 3 kicks in, and despite the fact that the NPS MFA extension does not properly return RADIUS attribute 11 for SMS or MS Authenticator OTP methods when those methods return a success for authentication, number 3 above allows those users to be processed by matching their local accounts in the Firebox-DB setup.

I hope that makes sense. Best of luck to you!

Best Regards,

-Pete

Alex Rourke 21 Reputation points

2021-10-06T19:09:34.3+00:00

Facing the same issues as all of you, I'm trying to get this set up. Thankfully, we only have a dozen or so users who need access to the VPN, so setting them up as local users will work fine for us. @prunyan - I'm having trouble interpreting your directions here. It sounds to me like you have the SSL VPN set up first to look at your RADIUS server (with Azure MFA) and then fallback to Firebox-DB authentication where the username is the same as the one used for RADIUS? Is that correct? Is it also the case that these local accounts are never actually used and that the passwords assigned to them are arbitrary?

We would love to get this working and what you're offering here is the only solution I can find. Any additional information you could give me would be greatly appreciated.
Alex Rourke 21 Reputation points

2021-10-11T15:40:00.933+00:00
I was able to figure this out and get it working with all authentication methods. This solution worked for us because we have <10 users who need access to the VPN. You should have a user group in AD for users who have access to the VPN (in my case, SSL VPN Users).

Make sure RADIUS server is set up appropriately to use Azure MFA (60 second timeout). Configure it in Authentication Servers.

In WSM, go to Setup > Authentication > Users & Groups: Set up group specified above as group for RADIUS authentication server. Set up each individual user in the group as a user on the RADIUS authentication server. We have users log in with their full email address, so that is what we used for the user name when setting this up.

In the SSL VPN setup, only allow the RADIUS server for authentication, select both the group made above and every individual user in that group as available to log in. No need to set users up in Firebox-DB or enable this authentication method.

How it works: When user authenticates using phone or app notification, the group specified above is handed back properly in attribute 11 and the user is authenticated. When the user uses SMS or another code-based authentication, RADIUS attribute 11 won't be handed back (Azure AD MFA bug). However, since the user is directly included as allowed to authenticate in the SSL VPN setup, they will still be authenticated properly.

We don't have security settings per group on our WatchGuard, so I'm not sure how this would work in that case, but this does work with all authentication methods.
Pete Runyan Admin 31 Reputation points

2021-10-11T17:47:23.117+00:00

Nice job Alex - you have summarized the essence of what I had to do in much clearer fashion than the way I stated it, but our solutions are the same. We should charge WG support for our efforts! ;-)

All of that said, MS should still fix their RADIUS codes for SMS and Authenticator OTP, it seems to me.

Share via

Azure MFA - What happens to users registered with a method (SMS TEXT) after you remove that registration method as an option under MFA services?

5 additional answers

Your answer