#1 2020-09-14 03:19:05

From: France, Cognac
Registered: 2020-09-14
Posts: 1

App code” for example for a user that is using SMS

2FA Azure Active Directory Azure AD MFA security self-service password reset  smartphone  sms text message           Impact of Removing SMS As an MFA Method In Azure AD.
August 16, 2019.

8 Comments on Impact of Removing SMS As an MFA Method In Azure AD

There are a number of  general  recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with).
You should always be looking at MFA with an app ( Microsoft  Authenticator or other) or hardware device.
But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already  registered  their phone number.
My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), .

What happens if you have SSPR enabled (and what happens if you do not)

Each of the  scenarios  in that article allowed the user to register a phone number and then to have a text message sent at login.
If the user  registered  with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option).
Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “ mobile app ” whilst registering.
The  registration  page looks as follows:        So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:        Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance).
If the user clicks  “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:        To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional  cloud-based  MFA settings (or click Multi-Factor Authentication in the Users page of the same portal).
You will see the below once you click the Service Settings tab:        This dialog includes the “skip multi-factor  authentication …” box which you only have if you have Azure AD P1 or P2 licence.
The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.
So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method.
First change is that  “sign in another way” message is now missing.
A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:        Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.

What about users who when they registered for MFA set SMS as their default

Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:        Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register.
In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard.
This is shown in the following series of images:                    Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option.
Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)    If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.
This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:        In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR.
So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.
So to disable SMS is only a problem in Azure AD for the user – as it means that at the next login they need to register again (so not a real problem).
I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method.
So that issue is clearly fixed now.
So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.
←     MFA and End User Impacts                →     Baseline Policy Replacements: Conditional Access MFA for Administrators                                        8 replies on “Impact of Removing SMS As an MFA Method In Azure AD”.

Matthew Levy says:                              August 19

2019 at 10:58 am                                 It’s a pity “Insights – Authentication methods registration details” doesn’t give you a report on the users that are using SMS as their default.
It only says: “Mobile phone, App notification, App code” for example for a user that is using SMS, then Authenticator app on his phone.
So the Mobile phone option could be used for SMS and/or Call but the default is not reflected in the Insights report.
Reply                                  Brian Reid says:                              September 18, 2019 at 7:22 pm                                 It does now.
I saw it the other week.
I think you need to click things that don’t look like links to see it.
Reply By Post Author                                       Jeff Brixhamite says:                              November 28, 2019 at 5:00 pm                                 Without doubt SMS is the weakest yet most popular second factor out there and any option to replace it should be considered.
Hardware tokens, fido keys and mobile apps are probably the best alternatives, but if it’s a choice of 2FA via SMS vs no 2FA then clearly 2FA with SMS is still a better option and I guess currently the cost factor is the main driving force.
Reply                                     John says:                              January 16.

2020 at 11:25 am                                 I have also disabled SMS for my tenant

but using the enhanced registration portal and Identity Protection.

SMS is still an option for my users…

Can you explain this.
Reply                                  Brian Reid says:                              January 16, 2020 at 4:56 pm                                 Do you have SMS enabled for self service password reset.
Reply By Post Author                                  John says:                              February 6, 2020 at 8:31 am                                 No, we are not using this feature yet….
Reply                                  stefan says:                              March 31, .

2020 at 6:27 pm                                 @John: Same here

Even though SMS is not an activated in our global MFA options I can still register it from the combined registration.
SSPR is deactivated as well.
Reply                                  Brian Reid says:                              June 17, 2020 at 12:51 pm                                 OK – so I took a further look at this.
You need to register the number of methods in the combined wizard that match the number you have set in the SSPR configuration.
This will include registering (optionally, as you can skip this) a phone even though phone or SMS is disabled in the legacy MFA settings.
You cannot use a phone call or SMS to perform MFA if it is disabled though – so when you login your default method is active (push to authentication most likely) and if you ignore that push (or its not working) you can choose the option to use another method.
Though phone/text where registered you cannot use them here.
Administrators are always enabled for password reset, and always for two methods which includes app and phone regardless of your settings.
If you test with a non-admin user you will not be asked for phone/text if that is disabled.

By Post Author                                       Leave a Reply Cancel reply

Your email address will not be published.
Required fields are marked Comment Name   Email   Website         This site uses Akismet to reduce spam.
Learn how your comment data is processed.
Select Category  2003  2004  2007  2008  2008 R2  2010  2012  2012 R2  2013  2016  2019  2FA  64 bit  AADConnect  aadrm  AADSync  access  acdc  active directory  activesync  add-in  ADDS  ADFS  ADFS 2.0  ADFS 3.0  ADFS Connector  AdminSDHolder  adsiedit  Advanced Threat Protection  agent  AIP  android  antivirus  anycast  app password  Application Guard  archive  asterisk  asterisknow  ATP  Authentication  autodiscover  autodiscover v2  az  Azure  Azure Active Directory  Azure AD  Azure Information Protection  AzureAD  backup  baseline  bing  bios  booking  bpos  branding  cafe  calendar  certificates  Chrome  citrix  Click To Run  Click2Run  cloud  Cloud PBX  Clutter  cmak  compliance  conditional access  conversation  crm  cross-forest  cyber bullying  dell  Deployment  device  device registration  dirsync  dkim  DLP  dmarc  DNS  domain  door  download  draytek  DSC  duplicate  dynamic delivery  Dynamics  EAS  ebs 2008  Edge  EM+S  email  encryption  Endpoint Manager  enterprise mobility + security  Entourage  EOP     Exchange Online Protection  error  EWS  exchange  exchange online  Exchange Server  EXO  ExpressRoute  federation  FIDO  firewall  Focused Inbox  FOPE  Free/Busy  GeoDNS  Global Catalog  GPO  Group Policy  groups  hosting  hotfix  https  hybrid  hyper-v  IAmMEC  IFilter  iis  illustration  install  Intune  iOS  ip  iPad  iPhone  ipsec  ipv4  ipv6  iQ.
Suite  IRM  isa  ISA Server 2004  ISA Server 2006  JetNexus  journal  journaling  Kemp  kerberos  lab  licence  Live Event  load balancer  Load Master  loadbalancer  logo  Lync Server  mailbox  malware  management  mcafee  mcas  mcm  mcsm  mdatp  MDM  media player  MFA  microsoft  Microsoft 365  Microsoft Cloud App Security  Microsoft Defender Advanced Threat Protection  Microsoft Teams  migration  Mobile Device Management  mobile phones  modern authentication  monthly channel  move  msExchDelegateListBL  msExchDelegateListLink  MSOL  multi-factor auth  Multi-Factor Authentication  MVP  MX  ndr  Netscaler  networking  NTL  OAuth  OD4B  ODFB  off  offensive  Office  Office 365  Office 365 Advanced Threat Protection  Office 365 Groups  Office 365 ProPlus  oledb  OneDrive  OneDrive For Business  openmanage  orange  organization relationships  osma  Outlook  owa  OWA for Devices  password  paxton  pbx  permissions  PFDAVAdmin  phish  phishing  phone factor  pkcs  pki  places  policy  powershell  pptp  preview  Proof Of Concept  proxy  pst  PSTN  PSTN Conferencing  Public Folders  recovery  remote desktop  remote web workplace  retention  retention policies  rms  room  router  rras  rtp  rules  rww  Safe Attachments  Safe Documents  Safe Links  Salesforce  sbs 2008  SCOM  sdk  search  security  Security and Compliance Center  self-service password reset  semi-annual channel  send-on-behalf  server administrator  server core  shared mailbox  sharepoint  sip  Skype For Business Online  Skype for Business Server  smarthost  smartphone  sms  smtp  spam  spf  spoof  spv  SQL  sql express  SSL  SSO  sspr  sstp  starttls  storage card  Stream  supervision  sync error  sysprep  Teams  TechEd  terminal server  Terminal Services  text message  Threat Management  TLS  tmg  token2  transport  transport agent  ts gateway  Uncategorized  unif  unified messaging  update  upgrade  vc++  vhd  virtual pc  virtual server  virtualisation  vista  visual studio  vm  VNet  Voicemai  voicemail.


Basketball Star Slot

Board footer

Powered by FluxBB