Apr 17 2020 03:43 PM
Apr 17 2020 03:43 PM
When I visit Azure Active Directory -> Users -> Multi-Factor Authentication, our initial accounts show "Multi-Factor Auth Status" as "Disabled", but we are seeing MFA prompts. I find it confusing that something shows "disabled" that is really turned on somehow??? Is there more than one type of MFA?
We just received a trial for G1 as part of building a use case for moving to Office 365. I setup the tenant space by confirming our identity and I am a Global Administrator. I was prompted to setup MFA on my second logon, but I don't recall being offered any option other than text message. My understanding is that I had to turn on MFA for our accounts so I just setup SMS to get logged on the second time.
Apr 18 2020 03:33 AM
Apr 18 2020 08:12 AM
Yes, our tenant space is setup to use the security defaults as mentioned on this page https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-d.... If you turn off Security Defaults, the multi-factor authentication page still shows that no accounts have MFA setup, even though they are setup for MFA. It really seems like when Security Defaults was implemented they must have setup things to ignore the existing MFA settings altogether. I would really like to see that MFA is turned on for a user whether using the fancy Conditional Access that I am reading about or Security Defaults.
Apr 18 2020 10:28 AM
Have you turned the security defaults off now? If so, it may take a while for the settings to take effect throughout your tenant.
Once you can verify that these settings are no longer applying, I'd recommend using Conditional Access Policies for MFA instead of relying on the Security defaults as these apply blanket settings. You can find this at https://portal.azure.com under Azure Active Directory > Security > Conditional Access.
You will see some Baseline policies there. Don't enable those as they also apply blanket settings, and they are due to be deprecated. I'd highly suggest you create your own CA Policies. I'd recommend at the minimum a policy to require MFA for all privileged admin roles, but don't forget to exclude your permanent break glass account(s) from this policy as you don't want to get locked out.
Apr 18 2020 10:30 AM
Sep 10 2020 08:53 AM
@Gervs Sorry to bring a dead thread back but we're having a similar issue with Security Defaults disabled. Though it's not every user. We're currently tracking one high profile user. Our tenant responds that MFA is disabled when checked via powershell. (The script works properly for other users so we know the script is good). The users still gets MFA prompts and his account allows for additional security settings even though the MFA is "Disabled".
Any clues as to why this might happen to a small number of users and why it may happen even though default security settings are/have been off?
Sep 10 2020 08:57 AM
If your tenant was created on or after October 22, 2019, it is possible security defaults are already enabled in your tenant. In an effort to protect all of our users, security defaults is being rolled out to all new tenants created. (referenced from https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-d...)
1. Go to https://portal.azure.com
2. Use the search bar on the upper middle part of the page and search of "Azure Active Directory".
3. Under Azure Active Directory, search for Properties on the left-hand panel. It is in-between of User Settings and Security.
4. Under the Properties, click on Manage Security defaults.
5. Under the Enable Security defaults, toggle it to NO.
6. Wait for few minutes for propagation then try to sign-in using InPrivate or Incognito.
Sep 10 2020 09:00 AM
Jan 10 2021 10:16 AM
I had the same problem. I already had disabled the security default settings.
I solved the problem with deleting the saved information.
Afterwards, the login in a incognito window was possible without asking for MFA.
Apr 27 2021 09:47 PM
We are having this issue with a new tenant.
All users have MFA Disabled and Enable Security defaults are also set to No, yet as I am adding each account to Access work or school on new PC I get prompted to setup MFA. I just click Next and then close the window. It's a pain, but the account is successfully added and credentials are used to open O365 etc.
Apr 28 2021 03:36 AM - edited Apr 28 2021 03:39 AM
This is all down to a new and ill-conceived UI from Microsoft. They've basically combined MFA setup with account recovery setup. Prior to this change, if you had self-service password reset enabled, on first login users would be prompted to setup a recovery phone and email. If MFA was enabled, they'd be prompted to setup MFA.
The combined approach is highly confusing when not wanting MFA. It still allows a user to setup MFA even when it's disabled on the account in Azure. Indeed it's designed to make you think you have to set it up. Just more nonsense from unskilled product managers and developers with little experience of the real world and zero common sense.
Same with the Security Defaults. These force use of MFA for all accounts, despite Microsoft's own recommendation to have at least one GA account not using MFA in case of MFA issues. Indeed a non-MFA GA account is needed for hybrid operation as well as for any 3rd party services that need access to the 365 tenant.
Anyhow, the solution is to ignore the initial presentation of the setup. For option 1, select Phone instead of Authenticator App from the dropdown. Then complete the phone verification as it used to be done. Then select Email for option 2 and complete that. Account is now setup with password reset info needed but without MFA enabled.
That still leaves the issue that, if the user chose to enable MFA during initial account setup, this won't reflect in AAD. That still shows MFA as disabled!
May 18 2021 10:20 AM
What we found is that you can enable MFA through MyAccount.Microsoft.com > Security Info > Update Info. If it is enable here, the Azure portal continues to show that it is not enabled yet if functions. If set up this way, then changing it in Azure has virtually no effect (except your powershell reporting will be correct again).
Let me know if I am wrong on any points, but it seems to hold true for us.