New clients MFA is all out of whack and not sure how to fix it.

Yeah the problem is Security Defaults does NOT enforce MFA on all users. It only enforces MFA on ADMINS. It uses MFA on users only at specific times, like accessing the security section of the account. It's not great...

BUT from what I've seen if the user takes the time to do phone signon, it'll consistently enforce MFA for the account.

And again if you see this behavior on the tenant open a ticket with Microsoft. They need to know people are upset they're taking away a feature to sell another $3 / month / user, and that isn't OK.

Docs for Security Defaults here: https://learn.microsoft.com/en-us/a...-do-multifactor-authentication-when-necessary

This is what's enforced on users
I appreciate all your input on this thread. You are well beyond my knowledge and it's great to have someone like you here.
 
Yeah the problem is Security Defaults does NOT enforce MFA on all users. It only enforces MFA on ADMINS. It uses MFA on users only at specific times, like accessing the security section of the account. It's not great...
man o man Im doing too many things here and not paying attention...deleted the wrong post.


Im not sure what you mean by admins only? It states all users, which has been my experience with it as well for as long as I can remember. Does it allow you to granularly control all the different conditions like CA does, no, but its better than managing per-user mfa where over time things can get missed or someone can turn off the MFA and forget to re-enable it.
1682091982291.png

If OP doesnt have the manpower or expertise yet to tackle CA, then secdefaults is the next best thing to get some resemblance of security standards across the tenant.

Here's the problem.

In my test tenant I enabled security defaults for my tenant.

Then I registered a test user with security defaulted azure based MFA with Legacy MFA disabled (no business premium or conditional access enabled, only business standard).

Even after registration I was able to login to the account from a different computer/IP/location using single factor.

Why?

I did this by logging into a test computer in incognito I have at my uncle's company.

Why?
Thats interesting. I have never seen that with a default tenant configuration with secdefaults enabled. It requires user when they login to setup MFA. Sure you have X days to put it off but after the grace period you are forced to set it up.

I just popped onto my dev sandbox and verified secdefaults were on, created a user, logged in, was prompted to setup MFA, and now whenever I login from anywhere I am prompted for the MFA code on the account.
 
man o man Im doing too many things here and not paying attention...deleted the wrong post.


Im not sure what you mean by admins only? It states all users, which has been my experience with it as well for as long as I can remember. Does it allow you to granularly control all the different conditions like CA does, no, but its better than managing per-user mfa where over time things can get missed or someone can turn off the MFA and forget to re-enable it.
View attachment 14538

If OP doesnt have the manpower or expertise yet to tackle CA, then secdefaults is the next best thing to get some resemblance of security standards across the tenant.


Thats interesting. I have never seen that with a default tenant configuration with secdefaults enabled. It requires user when they login to setup MFA. Sure you have X days to put it off but after the grace period you are forced to set it up.

I just popped onto my dev sandbox and verified secdefaults were on, created a user, logged in, was prompted to setup MFA, and now whenever I login from anywhere I am prompted for the MFA code on the account.
Complete the Authentication Method migration, it won't pop anymore. It's only consistent when O365 Single User MFA is enforced, which is flipped all on with security defaults, and then flipped OFF when you complete the auth migration.

And again, the auth migration is being FORCED ON US coming September with completion to be done January.

The behavior you're observing is OUT OF DATE.

And yes, we all need to be screaming about it, because the old normal WORKED WONDERFULLY, and needs to be the new normal. But it isn't.
 
Yeah the problem is Security Defaults does NOT enforce MFA on all users. It only enforces MFA on ADMINS. It uses MFA on users only at specific times, like accessing the security section of the account. It's not great...

BUT from what I've seen if the user takes the time to do phone signon, it'll consistently enforce MFA for the account.

And again if you see this behavior on the tenant open a ticket with Microsoft. They need to know people are upset they're taking away a feature to sell another $3 / month / user, and that isn't OK.

Docs for Security Defaults here: https://learn.microsoft.com/en-us/a...-do-multifactor-authentication-when-necessary

This is what's enforced on users
and you're sure thats not being confused with session persistence? It would seem very odd that you can log into any other device or application w/o being prompted for MFA just because you signed in somewhere else.

Ill dig into it a little later on when I have more time but that seems back-asswards.
 
Im not sure what you mean by admins only? It states all users, which has been my experience with it as well for as long as I can remember.
View attachment 14538
It states..."all users"....but...only states (looking at your yellow highlight)..that all users need to REGISTER for MFA. Doesn't mean it challenges MFA all the time, like when it should.

SD is very "fuzzy" with its logic...it's a very...very basic, sleep, lazy version of Risky Login logic. ...and it's far from consistent. Better than nothing, but not at all confidence inspiring.
 
It states..."all users"....but...only states (looking at your yellow highlight)..that all users need to REGISTER for MFA. Doesn't mean it challenges MFA all the time, like when it should.

SD is very "fuzzy" with its logic...it's a very...very basic, sleep, lazy version of Risky Login logic. ...and it's far from consistent. Better than nothing, but not at all confidence inspiring.
interesting... I swear on any tenant accounts we still have left using only sec defs, I am always prompted for MFA on new sign-ins for regular users, no matter where I sign-in from. If for some reason it no longer works that way after moving to authentication policies, that's odd. I get that MS might have some fancy AI making those determinations, but all it takes is for it to be wrong 1 time. Just more a reason to keep pushing clients into more mature licensing like biz premium, especially if the goal is to get the moved completely to cloud. With all the other features you get, its worth it.
 
@YeOldeStonecat Is correct, and this is why I have tickets open with Azure.

@putz Yes, again this is normal behavior IF YOU'RE USING O365 MFA, which has been normal for years. If you have that feature configured, and you enable Security Defaults, Azure will always pop for MFA on login.

The problem is O365 MFA IS GOING AWAY, with forced migrations starting in September. So if you got into your Azure portal, did a search for Authentication and opened up the recently separated Azure AD Authentication Methods applet, you'll see the migration details right there, and if you COMPLETE that migration, O365 MFA is NOW DISABLED and you're left with the true Security Defaults.

Which does NOT ENFORCE MFA on users, unless they muck with specific "risky" operations. Unless the user enrolls in phone signon, which I HIGHLY encourage anyway. So my tenants haven't really noticed, but there's no enforcement anywhere so it's very squishy.

And again I have tickets open with Microsoft on this, because they removed a feature to sell it back... it doesn't look good. And all they have to do to "fix" the problem is CHANGE Security Defaults such that it enforces MFA on all users all the time. If a tenant in those conditions wants to get around that, the only fix becomes Conditional Access, which is now an easy upsell based on need, instead of stupid on the part of Microsoft.

Also, Security Defaults won't require MFA to join a machine to Azure AD... unless you get into AAD's device blade and flip the switch... which is also baffling.

P.S. @putz Look at your screen grab... read the 2nd bullet point until it sinks in.
 
Last edited:
@putz Yes, again this is normal behavior IF YOU'RE USING O365 MFA, which has been normal for years. If you have that feature configured, and you enable Security Defaults, Azure will always pop for MFA on login.
Ahh yeah that makes sense. Im just so used to tenant accounts having the security defaults on by default, and we don't ever go in and mess with the 365 MFA settings anymore. I guess I didnt even realize MS was still factoring those in when security defaults are on.
 
@YeOldeStonecat Is correct, and this is why I have tickets open with Azure.

@putz Yes, again this is normal behavior IF YOU'RE USING O365 MFA, which has been normal for years. If you have that feature configured, and you enable Security Defaults, Azure will always pop for MFA on login.

The problem is O365 MFA IS GOING AWAY, with forced migrations starting in September. So if you got into your Azure portal, did a search for Authentication and opened up the recently separated Azure AD Authentication Methods applet, you'll see the migration details right there, and if you COMPLETE that migration, O365 MFA is NOW DISABLED and you're left with the true Security Defaults.

Which does NOT ENFORCE MFA on users, unless they muck with specific "risky" operations. Unless the user enrolls in phone signon, which I HIGHLY encourage anyway. So my tenants haven't really noticed, but there's no enforcement anywhere so it's very squishy.

And again I have tickets open with Microsoft on this, because they removed a feature to sell it back... it doesn't look good. And all they have to do to "fix" the problem is CHANGE Security Defaults such that it enforces MFA on all users all the time. If a tenant in those conditions wants to get around that, the only fix becomes Conditional Access, which is now an easy upsell based on need, instead of stupid on the part of Microsoft.

Also, Security Defaults won't require MFA to join a machine to Azure AD... unless you get into AAD's device blade and flip the switch... which is also baffling.

P.S. @putz Look at your screen grab... read the 2nd bullet point until it sinks in.

That's pretty much exactly what I think about this situation. Per-user MFA is tedious ... since you have to enable it per user but it challenges MFA EVERYTIME.

I was able to test what was considered a "risky" login using security defaults by firing up a VPN and what I found was the MFA was not challenged in the following cases.

- Login to portal.office.com using a different computer
- Login to portal.office.com using a different computer at a different location
- Login to portal.office.com from an adjacent state (CA to Utah)
- Login to portal.office.com from a state across the country (CA to NY)

So what the hell is risky then?

MFA is only challenged when logging into portal.office.com then clicking "view account" which I believe sends you into Azure land which then does in fact challenge MFA.

BUT

You can still click Outlook and access the entirety of the users Outlook data without being challenged by MFA.

I can't imagine how a login from CA and then a login from NY in a matter of a few minutes doesn't trigger an MFA challenge.

This MFA stuff really would just be solved by requiring MFA on ALL users by enabling security defaults. It's honestly crazy to me that it isn't that way by default.

When I login to my free gmail account I get challenged every time using the conditions above. This SIMPLE but REQUIRED feature is now $22 a month for business premium. Yes I get it, you get other stuff that is well worth the cost but I'm only talking about MFA here.

True MFA should not be hidden behind ANY paywall EVER.

For Microsoft to do what you described above which was to remove an option and re-sell it to you just seems rediculous.
 
Azure Active Directory Premium P1 is $7.20 / user / month, $6 if you do an annual commitment.
Business Standard is $15 / user / month, or $12.50 if you do an annual commitment.
Business Premium is $26.40 / user / month, or $22 if you do an annual commitment.

So if you do pure month to month, it's $22.20 / user / month if you do Standard + AAD P1, which saves $4.20 / user / month relative to Premium.

But yes, I do very much see this, again MANDATORY change which goes into effect in September, is to force those on smaller subs to bolt in that extra $7.20 / user / month.

As for the definition of "risky", it's mucking with account security settings, or trying to setup an email forward. But yes, the attacker can read all he wants, he can DELETE all he wants. Though presumably if he reads too much or too many accounts he gets black listed into permanently having to POP MFA... but it's certainly NOT ENOUGH.

And we really need to keep screaming at Microsoft to make all MFA all the time the DEFAULT. I really think that's what will happen in the end, but this Summer is going to SUCK.
 
This thread has been very educational - digging out all of the nuances is next to impossible unless you make it a field of study. I'm grateful some of you have done that!
 
That's kind of what I experienced ... I could login to the account using Single-Factor Auth even with MFA enabled through Azure but any "change" to the account itself resulted in an MFA requirement.

But being able to access Outlook from a foreign device using Single-Factor Auth (which is what I experienced) even when MFA is enabled is unacceptable.

It's also unacceptable that conditional MFA already WAS a thing using per-user MFA, and their taking that option away, and selling it back to you under a P1/Biz Prem license.

Using a Business standard license ... this isn't true



I was able to log in to OWA and access Outlook from a different device on a different IP in a different city using single-factor authentication. Only when I attempted to make changes in "My Profile" was a prompted for MFA.

Edit: I know you both are saying "but all the extra stuff you get!" I get it. But for right now I just want MFA.
This is exactly what we are currently questioning. Found that any user account created in the last few months or so do not get asked for MFA when accessing office.com > email etc.. Only when account changes need done are they asked for MFA.

I was so under the impression security defaults would ask the use for MFA on a new device (it doesn't), a IP address that is not listed anywhere in the customers tenant etc...

I noticed that old accounts that have been around for a while do ask for MFA.. Strange.
 
Yeah, ...the "security defaults"...are...well, better than nothing, but not nearly.....not nearly...as good as leveraging "conditional access".
Security defaults are a bit fuzzy. Gray if you will. They use "risk"...but...sometimes it might prompt, sometimes it might not prompt....it does its own "considering risk". Based on location, and device being sign in from. (such as a new device..it should...but I know...not always...sometimes not even often...lol). Also...it depends on the role. Security defaults will almost always prompt MFA for any Administrator role. And...it may prompt for MFA for standard users...when they go into something a little more important on their account, such as changing security settings (adding a new phone, etc).

Some more in depth reading...
 
I've been teaching this to my staff for a year and failing...

So now I'm finally picking up the M365 Lighthouse torch, because no one else will... and the bloody Baseline will deploy the configurations now... because I can't take it anymore, people get it wrong and leave HUGE HOLES.

I swear I can't find a single tenant with security info registration taken care of, and if that one is there the legacy defaults policy is missing.

People, for the love of all that is good and right in the world, there are FOUR CORE POLICIES!

MFA for Users
MFA for Admins
Securing Security Info Registration
Disable Legacy Authentication

All four of them are Conditional Access templates, you don't even need to understand them JUST DEPLOY THEM!

AND, the bottom two? Those you make customers sign a bloody liability waiver to enable the configuration of ANY EXCEPTIONS.

I'm about ready to do that for all four of them, but there are needs for exemptions in various circumstances for users, but those processes should be a new policy not just "single factor only meh".

But I'll get off my soap box now, I swear authentication is just as FUBAR as DNS is for most places. Going to resort to grumbling about trespassing on lawns here soon...
 
So now I'm finally picking up the M365 Lighthouse torch, because no one else will... and the bloody Baseline will deploy the configurations now... because I can't take it anymore, people get it wrong and leave HUGE HOLES.
I've mentioned that a few times. Remember, the thread where you debated Lighthouse was only for Azure..and I kept saying...there's ALSO a Lighthouse for 365 :) Granted...it does need a bit more cooking in the oven.
 
I kept saying...there's ALSO a Lighthouse for 365

No one can possibly say that Microsoft doesn't have a hand in this mess by having too freakin' many "security product lines" that are quite "fuzzy" through "opaque" to administer correctly.

It's like Outlook branding, but on steroids and separated among multiple brands. Consolidation in one line, with one standard way of administering the features available (which will vary) would go a very long way toward decreasing the very issues decried here.
 
@thecomputerguy this whole post excites me, I have been turning away larger migrations for years, only doing under 10 users. I figured it was time to get back in the game, hoping to do 50 and under now.

So it was helpful for me, take time to make your own documentation from what you read here. I saved this post so I can use it over the weekend.

How do you practice this before doing it for clients? I have avoided a couple of smaller migrations because, well, I didn't want to mess up their stuff.
 
How do you practice this before doing it for clients? I have avoided a couple of smaller migrations because, well, I didn't want to mess up their stuff.

Start up a thread about it, gather good answers.
I started going email migrations ==> Exchange Server big time back when...Small Business Server 2000 was out...I was a big "SBSr"....and did lots of migrations from small businesses POP email into Exchange...of SBS.

And then..when 365 came out..similar....lots of migrations from on prem Exchange...into 365 land. And of course....from other personal emails...to 365...or Google Workplace...to 365.

Through repetition..and repetition...you learn what to look out for, you learn what to keep on your front burner, you learn the "gotchas". And...yup...there's that first client to be nervous on.

So...start a thread...I can type a few chapters on it...but will keep it short.
 
I've mentioned that a few times. Remember, the thread where you debated Lighthouse was only for Azure..and I kept saying...there's ALSO a Lighthouse for 365 :) Granted...it does need a bit more cooking in the oven.
Actually, for what I need it to do it's darned near perfect now. It's improved substantially over the last year from what I can see.

The issue is maintaining a different baseline for each customer, which template baselines to pull from with isolated configuration sets.

So I can get reports in the licensing module so the sales numties can know what to sell without bugging me.

My authentication baseline is already built, because basically it's just the default baseline limited to just the authentication bits. Which I'll take that as a win for now because I've got more tenants than I can count that are all screwed up. And I brought M365 Lighthouse to operations' attention a year ago, and they've done f'all with it. So now I'm doing it.
 
Last edited:
Back
Top