It says Azure Services, not just the portal. Does this include SAML auth apps? That would kill us in K-12. Try having a kid in pre-k or 3rd grade do MFA.
Mandatory Intune (computer certificate) with Conditional Access is also good.
PSA: When configuring Conditional Access, always have an emergency break glass account!
Yes, with a 30 + random character password and if your lucky enough to have the licensing for it (Because security seem to be a feature...), with warning by email/sms when the account log to the tenant.
Trusted devices. Assuming Timmy is issued an iPad or chromebook or something from the school district. That device better me enrolled in MDM and compliant. Then you can save Timmy from his impending MFA nightmare.
Working at a CSP, from what I have heard, Microsoft will only be pushing these Security defaults to tenants that do not already have Security defaults or Conditional Access policies in place. (They are going to make sure Admin roles have MFA enabled) If you already have conditional access in place, you should not be affected. Of course, its Microsoft, so no guarantees.
Sure. But there is no mention in this post that those will then bypass any requirement for MFA.
We allready do this for service accounts that can't have MFA.
We have that already. This blog post has has very little information as to what is actually changing, so it's hard to figure out what we'll need to do.
Honestly, getting them to do MFA sounds trivial compared to getting them to use passwords and systems in general in a safe and responsible way.
I'm not saying this doesn't suck right now but it might save you a huge headache in the long run.
It's not trivial at all. It's a huge lift to get thousands of K-12 students to register and use MFA in an area where families are worried about where food is coming from, let alone how to get their kid logged into an MFA enabled website for school. They would just tell the kid not to do it.
>It's not trivial at all.
Have you read the whole comment? Getting these kids to adhere to security best practices is impossible. Thus, COMPARED to that, enabling mfa is trivial. And i acknowledged it sucks, i'm not trying to downplay it i'm pointing out it's probably worth the effort.
If you need to throw out all basic security, then... Don't use Azure based tech in the environment?
Mandatory MFA isn't coming out of left field here.Ā The right solution for the environment is likely going to be found somewhere between the current solution and the enforced solution, but dooming about it solves nothing.
For the record, I've been getting emails about this for nearly a year along with the cutover to the new auth backend.Ā This should not be blindsiding any azure admins.
Edit: I think you have read it the way I believe the author actually intended (enforced MFA for accessing the Azure portal specifically), but my response below was more intended to address the "Good, its 2024 everyone should be using MFA anyway" responses.
I was waiting for a comment like this.
Like most people on this sub (I assume) I am 100% for MFA in the vast majority of situations. However, taking the announcement at face value, can you truly not think of ANY situations where MFA might be unworkable?
The comments on the article are a good starting point. I'll repeat a few here:
>Our USERS are already using MFA.
>What about SERVICE type accounts? We limit those to only login from our on-premise devices. Hope you aren't requiring more.
>What about GUESTS? Our guests are often elderly or technically challenged. Force MFA on them as well?
>Yeah, what about students who aren't allowed mobile phones in the classroom?
>This would be phenomenally difficult for us - we are a Trust of Special Educational Needs schools and as such, would be unable to facilitate this at all with our students. This should be obvious to Microsoft and in spite of the clear security advantages of MFA for staff and other connected adult accounts, we would be at odds with our student base and their ability if we were to enforce this kind of security requirement at login etc. Can I ask if this is controllable using conditional access in some way??
It's a managed policy that's already in a lot of tenants (it's been in ours for months) - it's also in "Microsoft Managed" mode by default. You can change this to on/off at your choosing. I disabled it because we already have stronger MFA policies in place.
This way to exclude users isn't new, it's conditional access 101 my good human. I'd suggest reading up on how those policies work - they're quite helpful.
- D
I do know what conditional policies are, trust me, we have plenty of them. This article is worded poorly, without explaining what and where will be changed hence everyone in this topic talking about it
Oh that parts true yes. Though I find a lot of the recent MS Graph articles to be worded either vaguely (or with useless examples or none at all) - a decline it seems.
Hopefully the article gets a rewrite :)
Yeah I hope so too, told my MS contact it is bad and the worst part is no one replies to those people in comments. This is night and day compared to exchange blog when you have MS people respond to you in comments
Without having any more details (because this is a very ambiguous blog post), I am assuming that they are talking about just the Azure portal. So my answers below are with that context.
>What about SERVICE type accounts?
Use the API, or a managed identity if it's an Azure service needing to use the service account.
>What about GUESTS? Our guests are often elderly or technically challenged. Force MFA on them as well?
I really don't see how this is a valid argument. Educate your users/guests. Stop using this as an excuse to be lazy. These are the users that need the extra security.
>Yeah, what about students who aren't allowed mobile phones in the classroom?
FIDO2 Keys. MFA isn't just a code on a phone.
If this is a blanket across everything in Azure/O365 land, then yes, this could be interesting, I agree.
Largely agree. But FIDO2 keys aren't a workable solution for young children. Even for older children, deploying Yubikeys or whatever across districts of thousands of preteen students is not my idea of a fun time.
Hopefully its all exactly as you say (an ambiguous blog post)
Smart cards built into student IDs like a lot of hospitals and what not have? Those are considered password less MFA for Azure, and are fairly cheap, and easy to put in a form that people including kids won't forget or lose easily. And if they do it's pretty easy and cheap to replace.
You (or someone in your position) is going to have to figure out how to handle MFA for young schoolage children eventually, probably sooner than later because this isn't going to get waved away for long
I can plan all I want but it's not my call. If MS forces student accounts to use MFA I can 100% guarantee our division will immediately move off Azure for authentication.
> I really don't see how this is a valid argument. Educate your users/guests. Stop using this as an excuse to be lazy. These are the users that need the extra security.
Security on guest accounts should usually be enforced at the permissions layer, not the login layer. Guest accounts generally have far less access to resources and are often completely stateless or wiped/reset between uses. Being inherently untrusted is what makes them guest accounts instead of regular users.
That said, Microsoft's named-user licensing doesn't seem terribly accommodating of the concept of a guest account to begin with...
> If you aren't already doing it, why not?
I work for a school in The Netherlands, our government has banned phones in class by law. Our students all have a school account within the Microsoft ecosystem.
If they enforce this, it means we will have to invest in 5k+ tokens.
Another absolute shitty posting from Microsoft. So thin on details. This leaves way more questions than it answers. I wonder if they have some kind of rule internally where they are told to be as ambiguous with their posts as possible.
Working with Azure and O365 and dealing with shit like this is one reason why I hate my job so much.
I'm willing to bet significant money that the original technical write-up that got sent to the Corporate Communications Department contained the relevant pointers and details needed to deduce most of our questions here.
But Corp-Comms almost universally wrecks these sort of things claiming it isn't inclusive enough of the non-technical people who aren't the target audience.
What if we use a third-party MFA solution? We're set up with Duo, not Microsoft's native MFA. As far as the portals are concerned, MFA is disabled since Duo is done via a conditional access policy that applies to everyone. Is this going to force us to double up?
You'll probably need to move to duo as an external authentication method, or if you're federated to duo, make sure your passing an MFA claim.
https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-methods-in-microsoft/ba-p/4078808
If you're using a 3rd party authenticator and you've enrolled in MFA using that app by scanning the QR code, you're golden. That counts as MFA.
If you've configured a 3rd party (Like RSA or Duo) as a custom control, you're probably in for a world of hurt. Custom Controls do not count as MFA as stated in the [documentation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/controls#known-limitations).
Get rid of the custom control implementation and enroll your users the right way.
The ā*right*ā way? For some of us this approach is asking thousands of users to re-enroll each time theyāve got a new app. Itās not supportable nor sustainable at scale.
We have M365 federated with a 3rd party idP for SSO with all MFA policies configured at the idP. Single enrollment for end user, single enrollment to support. There *is* (*apparently*) a newish way to pass the token info through to MS, but itās unfortunately not as simple as flipping a switch without risking an authentication loop.
Yeah. Microsoft doesn't count that as MFA if it's leveraged a Custom Control in Conditional Access.
It's clearly stated in their own documentation and Custom Controls has been a preview feature since 2020, never having moved to general release.
If you're leveraging that somewhere else that isn't Conditional Access then it probably won't be a problem.
I've also got thousands of users. The answer is user education combined with sensible security directives.
Additionally, not allowing 3rd party applications to be implemented without SAML SSO. When you have one iDP and everything is truly SSO, there's only one enrollment for MFA with an authenticator app. Not once every time a new app shows up.
Iām thoroughly confused by what youāre saying. Sounds like youāre pushing two contradicting points.
All of our apps are integrated to SSO via a 3rd party idP (*including M365*). That idP is where MFA enrollment is. MS is currently not aware theyāve done MFA by the time they get to a MS service. The challenge is getting MS aware that MFA is being done, just not by them. (*WITHOUT asking users to do a second enrollment.*)
Why would they need a second enrollment if you're using SSO?
I'm not asking to out of cynicism, I'm asking out of curiosity. I haven't ever worked in an environment where AzureAD wasn't the primary IDP. I've read some docs here and there but I haven't ever seen it in the real world.
It feels to me like I'm not accounting for something obvious to someone with that experience in our back and forth here.
My MFA enrollment is with the third party idP. When MFA is asked for, itās the idP asking for the MFA push whether itās from a config on tenant level or individual app level. When it makes that connection to MS, even if I require an MFA push to access it - MS is not (by default) made aware that MFA ever happened. It occurred entirely prior to completing the connection to MS. And since ALL connections go through the 3rd party idP, youāve fulfilled your MFA req. Unfortunately to MAKE MS aware that MFA has occurred, itās not quite as simple as a checkbox.
Oh, okay. Thanks for breaking out the crayons and apple juice for me there, lol.
I think you're right to be concerned, but I would hope that if Microsoft is gonna let its products be accessed using a 3rd party directory service, they had better behave like every other vendor out there that accepts AzureAD SAML for identity.
Ha! All good.
They have (*quasi recently*) introduced hooks to allow 3rd party idPs to pass along their exciting tokens to "trust" however it's really nowhere near as "*check checkbox and you're good to go*" as you'd assume it to be. We tried enabling it once early on and created an authentication loop. Lots of considerations to work through first.
if MFA is now enforced for the Azure Portal - that's fine it should be enforced.
if MFA is enforced for Microsoft 365 suite or Entra ID - [https://youtu.be/VX5rjTramis?si=6eBsllOOiE55-qvl&t=22](https://youtu.be/VX5rjTramis?si=6eBsllOOiE55-qvl&t=22)
I work in K-12 (with over 4000 students) and just bringing up this conversation in meetings just starts wars....
In our country they banned phones in class and the idea is at some point school premises. Yet the government is forcing digital education so most kids have byod laptops to use in class.
Token vendors rubbing their hands.
Well what about break glass account which they say to never be in any conditional access policies nor have MFA enabled
EDIT: to clarify, we setup break glass account years ago per MS assessment and then their recommendation was no CAs nor MFA on this account.
EDIT2: MS said it is just azure portal and there will be process to exclude accounts. More info will follow once I get it.
The recommendation most likely here is going to be that you buy & configure a hardware token for your breakglass account and store it in a safe. Or you have multiple MFA devices configured for it and have them held by different senior people at the company.
The hardware token one is the recommended approach for AWS root accounts, I don't see why Azure would be any different.
A simple way to have MFA on breakglass accounts is to just use the standard TOTP 2FA. You can do this with M365 if you choose 'I want to use a different authenticator' at the MFA enrolment.
Unlike the Microsoft Authenticator 2FA, the TOTP seed can be used at any point in the future to add that TOTP into any app etc, and TOTP 2FA codes can be generated completely offline - as long as the device has the correct time.
So steps are: setup MFA using the TOTP option, when presented with the TOTP QR code (which contains the TOTP seed), print it and store the hard copy somewhere safe - either in the same envelope as the breakglass credentials or split up elsewhere intentionally depending on risk tolerance.
In order to complete the MFA enrolment, you need to verify one 2FA code - so you will need to add the TOTP seed into something to get that first code, then delete it once the enrolment is finished.
> That will not help you if whole MFA service is down
If MFA is enforced for all users, they're not getting in anyway. Unless you were bold enough to temporarily disable MFA for key users during the outage.
Yeah because company would be like sure, letās take day off everyone because of MS! Of course they would tell me do disable this temporary
EDIT: also there is second line of protection which is hybrid join/intune requirement which is still in place when MFA is off
I mean MFA being down is pretty close to their authentication system being down. What, are users going to demand I remove their passwords or drive to the nearest datacenter and fetch them data?
Dunno what you will do, my users would be fine with mix of corporate IP/hybrid join and Intune - they would be protected without MFA (they wouldnāt even see it internally in the first place)
There's nothing that can be done. If an hour or a day of outage is too costly, then there needs to be a re-review of why we're in the cloud in the first place.
Besides, I think in 5 years we've been affected by one MFA outage (which lasted like an hour). An MFA outage may be a malicious attempt to get people to disable MFA. Otherwise, the authentication system is down. Nothing can be done.
> It is not always about **cost**
{Insert metric here}
Users should also have measures in place to mitigate outages, if possible. Such as, make sure those critical files are synced locally before super important meeting.
> imagine government being down lol
The government is operating?
That doesn't say no MFA? In fact, it says they recommend MFA on all accounts
> Exclude at least one account from phone-based multifactor authentication
To reduce the risk of an attack resulting from a compromised password, Microsoft Entra ID recommends that you require multifactor authentication for all individual users. This group includes administrators and all others (for example, financial officers) whose compromised account would have a significant impact.
> However, at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts.
It is kinda poorly worded (by MS) but You forgot to put whole quote which states to exclude emergency account from MFA and configure other mechanism (if you have it). What you gonna do if MFA is down and canāt login from any account? Then there is no point for emergency account because you wonāt sign in with it.
> However, at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts. This includes third-party multifactor authentication solutions. If you have a Conditional Access policy to require multifactor authentication for every administrator for Microsoft Entra ID and other connected software as a service (SaaS) apps, you should exclude emergency access accounts from this requirement, and configure a different mechanism instead. Additionally, you should make sure the accounts don't have a per-user multifactor authentication policy.
This is what I says under āwhy you should have such account ā
> The administrators are registered through Microsoft Entra multifactor authentication, and all their individual devices are unavailable or the service is unavailable. Users might be unable to complete multifactor authentication to activate a role. For example, a cell network outage is preventing them from answering phone calls or receiving text messages, the only two authentication mechanisms that they registered for their device.
> Unforeseen circumstances such as a natural disaster emergency, during which a mobile phone or other networks might be unavailable.
> at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts. This includes third-party multifactor authentication solutions.
> you should exclude emergency access accounts from this requirement, and **configure a different mechanism instead.**
Right, so they aren't recommending no MFA, they're recommending different MFA
No one in their right mind would recommend no MFA on any account, much less one with full admin rights to the environment.
This is exactly what I said, have other mechanism but what you will do if whole MFA is down and you donāt have other mechanism? You are shit out of luck. There are ways to protect such account as constant monitoring and having 2 people knowing parts of password
> This is exactly what I said
That's not what you said. You said MS recommended no MFA. That's not true.
> what you will do if whole MFA is down and you donāt have other mechanism?
That's exactly why MS is recommending another mechanism.
I have specified in my post now (edit) that that was recommendation years ago when we setup our emergency account with help of MS. What other mechanism you are talking about when whole MFA service is down? Even your 3rd party MFA, FIDOs are connecting through azure - I am talking about whole service being down - what are you going to do then?
> Even your 3rd party MFA, FIDOs are connecting through azure - I am talking about whole service being down - what are you going to do then?
If MS MFA and DUO (in our case) are both down at the same time, I have far more important things to worry about.
If you have 2 MFA providers, the odds of them both experiencing outages at the exact same time is so small, that it's irrelevant for most use cases.
[cabaseline202212/Conditional Access demystified-v1.4 - December 2022.pdf at main Ā· kennethvs/cabaseline202212 Ā· GitHub](https://github.com/kennethvs/cabaseline202212/blob/main/Conditional%20Access%20demystified-v1.4%20-%20December%202022.pdf)
You're misunderstanding at a totally different level. You need to familiarize yourself with the entire contents of the whitepaper or have someone who understands Conditional Access Policy take a look at your Conditional Access Policy.
Microsoft does not say breakglass accounts should have no MFA. Microsoft recommends that the MFA method be separate from your other normal MFA methods.
Go buy a couple of Yubikeys, and make 2 breakglass accounts with a new CAP using the tokens as your MFA. Build that CAP totally separate from everything else.
You are pointing me to 100 page paper, I donāt have time to look through all of this. I am not misunderstanding anything, I did say in my other comment MS recommends different mechanism. But what are you going to do when whole MFA service is down? You wonāt login. Also we did setup emergency account with MS years ago and havenāt touched it since and then recommendation was no MFA and no conditional access.
Most likely this will be like Security Defaults. If you already control it with CAPs, my guess is that at most you have to disable some new default policy.
We've had a Microsoft Managed conditional access policy in our list in report only mode for a few months, but that only says it will require MFA for users with admin roles. We made sure to exclude our break glass global admins from it already. I wonder if they'll add another Microsoft Managed policy that applies to all users and start enforcing both at the same time?
https://i.imgur.com/lDAT1D8.jpeg
That report only one was actually in "Microsoft Managed" for us by default. I moved it to disabled because I don't like MS turning on policies at their leisure. Our custom CA's are stricter anyways :)
Yeah we've got a policy that applies to literally any Entra role, so I'm not sure the Microsoft managed policy would ever be applied. We're just interested in how it will work so we're gonna leave it alone and see.
Only basic "security defaults". Hardware keys (yubikeys) are not allowed without P1 or P2.
At least that is what our VAR and MS told us. The option is visible, but we aren't allowed to use it.
Passwordless authentication, including FIDO2, is included in the free Entra license. Not sure how you're not allowed to use it or what that even means.
https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing
How are people handling using Okta as a IDP, and allowing the Okta MFA token to satisfy these types of things? just deal with the double prompt for MFA?
We have been using Okta for years for MFA for O365 and other apps. We donāt have the licenses for conditional access. What we did was enable security defaults after hours, and then disable them. We are no longer getting promoted to set up MFA for O365. There is some Okta documentation that advises to do this.
Schools absolutely do not need/want kids using MFA - too complicated, wastes a whole lot of time resetting MFA when they decide to delete the Authenticator app because they couldnāt download Fortnite
How does everyone here handle service accounts and MFA? We have a number of service accounts that are used by Dynamics, Github or Atlassian integrations where MFA is not possible. In good cases we can use MFA and create access tokens but it's not supported everywhere.
Same issue here with service accounts, only way Is to setup conditional access, no other solution found.
We set It IP related, so It does not ask for mfa only if the service account tries to log from a specific ip address.
You can go a step further and limit the apps that CA allows as well and actually serve a block message if they try from any other location or any other app outside of the one listed.
IP + app restrict + platform restrict if possible + exchange access policy or enterprise app assignment restrict = victory
Just as well written as their post a few months ago leaving the Windows 11 upgrade decision to clients who are "unmanaged". They later clarified that domain controlled is managed.
Funny how the text is written assuming someone doesn't know what MFA is in the first place.
Someone from MS commented "MFA will be required when logging in to the azure portal (portal.azure.com) and the entra portal (entra.microsoft.com).Ā "
Ok that makes sense. Was the article written by Copilot?
So if you click on the link in the article at the bottom (If you do not wait to wait for the roll-out, set up MFA now with the MFA wizard forĀ [Microsoft Entra](https://aka.ms/EntraIDMFAWizard).) it takes you to a wizard that lets you turn on and off features, like requiring MFA for external and guest users, exclude users/groups, etc. It basically takes you through the pre-made CA policies and settings (like what MFA methods can be used, etc). If it's just following these guidelines, then this likely to force tenants that have ZERO MFA configurations in place and likely won't affect those that are already set up with either Microsoft Default CA policies or have their own policies in place. There's even a link at the bottom of the wizard to 'Learn more about emergency administrator accounts'.
Hopefully this is just to scare the late bloomers into bringing their security into this millenium.
this explains why Microsoft announced that 3rd party integration for 2FA , probably needed to make sure they cover companies using DUO etc as 2FA before moving forward with adding more 2fa enforcement's.
This is about āConditional Accessā replacing old authentication method and also about personal users that have office subscriptions. Normal admins are able to configure Conditional Access as they want.
Maybe I'm dumb, but we already are forced to use MFA for about 10% of our users.
All the settings I've seen in entra ID Admin Center had no option to disable MFA for users.
I have no education in m365 admin stuff, I just have to figure it out somehow.
I'm based in Germany btw. Maybe it's different here? (Regarding forcing users into MFA)
Hello everyone, my name is Naj Shahid and I am a product manager in Azure leading this initiative. I have posted a comment in the tech community blog post that should clarify and help some of the questions.
Please see my comment here: [https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/bc-p/4143356/highlight/true#M6078](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/bc-p/4143356/highlight/true#M6078)
Thanks for replying. Can I suggest though, it would probably be better to make a very clear and obvious edit to the original blog post? Not everyone reads the comments.
Actually, they do not say no MFA. They should have a separate MFA method than the rest of your company. It should also be excluded from all conditional access policies. [Manage emergency access admin accounts - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#exclude-at-least-one-account-from-phone-based-multifactor-authentication)
[cabaseline202212/Conditional Access demystified-v1.4 - December 2022.pdf at main Ā· kennethvs/cabaseline202212 Ā· GitHub](https://github.com/kennethvs/cabaseline202212/blob/main/Conditional%20Access%20demystified-v1.4%20-%20December%202022.pdf)
[Buy YubiKeys at Yubico.com | Shop hardware authentication security keys](https://www.yubico.com/store/)
Please make sure to put this in your project task list, as it seems you've got some reading and work to do.
I was wondering why my main tenant was requiring me enroll in the app instead of honoring my SMS and 1pass 2fa.
Huge PIA, since I already have to have DUO, really didnt want a 2nd dedicated authenticator app outside of 1password or my yubi key.
>Schools... I don't know. Shouldn't you teach proper safety at schools as well? It's different for elementary school as you cannot expect those students to have 2fa devices..
Our country has laws against using mobile devices in class.
> Those definitely SHOULD have mfa.
Depends, our test accounts a simply login test accounts with zero rights.
Enforced MFA to get to the Azure portal? Good. If you aren't already doing it, why not?
It says Azure Services, not just the portal. Does this include SAML auth apps? That would kill us in K-12. Try having a kid in pre-k or 3rd grade do MFA.
As someone else here has mentioned: IP-based Conditional Access Policy and you are golden.
Mandatory Intune (computer certificate) with Conditional Access is also good. PSA: When configuring Conditional Access, always have an emergency break glass account!
Do you mean just exclude a break glass account from the CA?
Yes, with a 30 + random character password and if your lucky enough to have the licensing for it (Because security seem to be a feature...), with warning by email/sms when the account log to the tenant.
Yep: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
what if the break glass now need mfa....
We bought a physical yubikey for our break glass mfa. It lives in the safe, PW is in the IT PW manager.
Surgicaly implanted passwords in the IT managerš
I have RFID and NFC implants. That's possible!
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
We have that in place, but it doesn't help when they are off network.
Little Timmy shouldnāt be checking his outlook outside the school dayā¦work life balance ? š
Little Timmy needs to sign into Azure federated apps to do his homework though.
Timmy gets to learn about MFA!
You know what they say, you're never too young to learn about security, or something like that.
I hear there is a new cybercrime syndicate phishing kids logins and finishing their homework. Dastardly
>I hear there is a new cybercrime syndicate phishing kids logins and finishing their homework. Dastardly ~~Dog~~ Hacker ~~ate~~ deleted my homework!
Remote Access Toddlers
Timmy needs to learn the Alphabet and do his homework before he can even write the letters MFA.
Reverse classroom, do homework at site, and do reading at home.
Better yet, stop giving kids homework and let them be kids after school instead of grooming them for the rat race most places want you sucked into.
Agreed.
And if the reading is a document, inside the azure federated LMS?
Little Timmy's reading material gets auto-downloaded on their device on-site.
Or better yet give Timmy a real book made out of paper...
Itās not gonna be the kid complaining, itās going to be adult that has to help the kid youāll hear complaints from.
And the adult who will go raise hell at the school. district office, and public board meetings.
No more homework š¤· toodalooo
Trusted devices. Assuming Timmy is issued an iPad or chromebook or something from the school district. That device better me enrolled in MDM and compliant. Then you can save Timmy from his impending MFA nightmare.
They don't bring devices home because they either don't come back, or they come back broken and we have to fix them.
I don't understand what that has to do with it.
How are they supposed to do homework if they don't have a device? Everything is online these days.
Then also include a user group with all the students in list of who not to apply the policy.
Yeah, we already have this in place. if this change MS is doing can't be worked around via a CA policy then what?
Working at a CSP, from what I have heard, Microsoft will only be pushing these Security defaults to tenants that do not already have Security defaults or Conditional Access policies in place. (They are going to make sure Admin roles have MFA enabled) If you already have conditional access in place, you should not be affected. Of course, its Microsoft, so no guarantees.
Sure. But there is no mention in this post that those will then bypass any requirement for MFA. We allready do this for service accounts that can't have MFA.
.... and then pay extra for a ton of P1's or P2's?
Create a CA policy to exclude them. This is a baseline.
We have that already. This blog post has has very little information as to what is actually changing, so it's hard to figure out what we'll need to do.
Security defaults aren't on for all tenants. My read is this a notice that's going to apply to all of them
>Try having a kid in pre-k or 3rd grade do MFA. Just vaccinate the kids, then have them press their foreheads against the RFID reader to login. /s
We thought about that, but couldn't swing the extra budget for the rfid readers in out student laptops.
Honestly, getting them to do MFA sounds trivial compared to getting them to use passwords and systems in general in a safe and responsible way. I'm not saying this doesn't suck right now but it might save you a huge headache in the long run.
It's not trivial at all. It's a huge lift to get thousands of K-12 students to register and use MFA in an area where families are worried about where food is coming from, let alone how to get their kid logged into an MFA enabled website for school. They would just tell the kid not to do it.
>It's not trivial at all. Have you read the whole comment? Getting these kids to adhere to security best practices is impossible. Thus, COMPARED to that, enabling mfa is trivial. And i acknowledged it sucks, i'm not trying to downplay it i'm pointing out it's probably worth the effort.
Who is paying for the device? Not all 3rd graders has phones.
Again, never said it was easy.
it's not even practical.
If you need to throw out all basic security, then... Don't use Azure based tech in the environment? Mandatory MFA isn't coming out of left field here.Ā The right solution for the environment is likely going to be found somewhere between the current solution and the enforced solution, but dooming about it solves nothing. For the record, I've been getting emails about this for nearly a year along with the cutover to the new auth backend.Ā This should not be blindsiding any azure admins.
With the most modern MFA that would mean something like face or pin though?
Some university students struggle with 2fa
Maybe they will understand the concept better than some Admins. š¤Ŗš¬šš
Edit: I think you have read it the way I believe the author actually intended (enforced MFA for accessing the Azure portal specifically), but my response below was more intended to address the "Good, its 2024 everyone should be using MFA anyway" responses. I was waiting for a comment like this. Like most people on this sub (I assume) I am 100% for MFA in the vast majority of situations. However, taking the announcement at face value, can you truly not think of ANY situations where MFA might be unworkable? The comments on the article are a good starting point. I'll repeat a few here: >Our USERS are already using MFA. >What about SERVICE type accounts? We limit those to only login from our on-premise devices. Hope you aren't requiring more. >What about GUESTS? Our guests are often elderly or technically challenged. Force MFA on them as well? >Yeah, what about students who aren't allowed mobile phones in the classroom? >This would be phenomenally difficult for us - we are a Trust of Special Educational Needs schools and as such, would be unable to facilitate this at all with our students. This should be obvious to Microsoft and in spite of the clear security advantages of MFA for staff and other connected adult accounts, we would be at odds with our student base and their ability if we were to enforce this kind of security requirement at login etc. Can I ask if this is controllable using conditional access in some way??
You can do mfa and have trusted zones. Inside the trusted zones, it won't prompt. Outside the classroom, it will.
talked with MS, they said it is just for azure portal and there will be a way to exclude users, more info to come.
It's a managed policy that's already in a lot of tenants (it's been in ours for months) - it's also in "Microsoft Managed" mode by default. You can change this to on/off at your choosing. I disabled it because we already have stronger MFA policies in place. This way to exclude users isn't new, it's conditional access 101 my good human. I'd suggest reading up on how those policies work - they're quite helpful. - D
I do know what conditional policies are, trust me, we have plenty of them. This article is worded poorly, without explaining what and where will be changed hence everyone in this topic talking about it
Oh that parts true yes. Though I find a lot of the recent MS Graph articles to be worded either vaguely (or with useless examples or none at all) - a decline it seems. Hopefully the article gets a rewrite :)
Yeah I hope so too, told my MS contact it is bad and the worst part is no one replies to those people in comments. This is night and day compared to exchange blog when you have MS people respond to you in comments
I will admit, one benefit of doing MS stuff for a larger org - more opportunity for direct contact with people that aren't level 1 support.
Without having any more details (because this is a very ambiguous blog post), I am assuming that they are talking about just the Azure portal. So my answers below are with that context. >What about SERVICE type accounts? Use the API, or a managed identity if it's an Azure service needing to use the service account. >What about GUESTS? Our guests are often elderly or technically challenged. Force MFA on them as well? I really don't see how this is a valid argument. Educate your users/guests. Stop using this as an excuse to be lazy. These are the users that need the extra security. >Yeah, what about students who aren't allowed mobile phones in the classroom? FIDO2 Keys. MFA isn't just a code on a phone. If this is a blanket across everything in Azure/O365 land, then yes, this could be interesting, I agree.
Largely agree. But FIDO2 keys aren't a workable solution for young children. Even for older children, deploying Yubikeys or whatever across districts of thousands of preteen students is not my idea of a fun time. Hopefully its all exactly as you say (an ambiguous blog post)
Smart cards built into student IDs like a lot of hospitals and what not have? Those are considered password less MFA for Azure, and are fairly cheap, and easy to put in a form that people including kids won't forget or lose easily. And if they do it's pretty easy and cheap to replace.
You (or someone in your position) is going to have to figure out how to handle MFA for young schoolage children eventually, probably sooner than later because this isn't going to get waved away for long
They'd just switch off Azure
MFA for everyone is coming. Too many people have been bitten by not having it, and misery loves company.
It's not coming in July
You're right, it's not. But if you don't have a plan for it by now, when are you going to make one?
I can plan all I want but it's not my call. If MS forces student accounts to use MFA I can 100% guarantee our division will immediately move off Azure for authentication.
Are you one-to-one? Windows Hello.
What about something like a NFC smart card/FIDO token in the form factor of a bracket?
Even if it survives the children, it won't survive (some of) the parents
> I really don't see how this is a valid argument. Educate your users/guests. Stop using this as an excuse to be lazy. These are the users that need the extra security. Security on guest accounts should usually be enforced at the permissions layer, not the login layer. Guest accounts generally have far less access to resources and are often completely stateless or wiped/reset between uses. Being inherently untrusted is what makes them guest accounts instead of regular users. That said, Microsoft's named-user licensing doesn't seem terribly accommodating of the concept of a guest account to begin with...
Guests should be using MFA. When you say "service account", do you mean a shared account like "reception"? Establishing a CA policy is still possible.
hi you mean establishing a CA policy for all service accounts, but how can we achieve SA using MFA policy.
Conditional Access policy dictating their scope and use is best practice. What do you mean by SA?
Service Accounts.
Any thoughts on how are we going to implement for Service Accounts or breakglass accounts .
The answer to some of those questions are usb keys such as YubiKey
Agreed, for some. Not sure how that plays out in the K-12 EDU space though
> If you aren't already doing it, why not? I work for a school in The Netherlands, our government has banned phones in class by law. Our students all have a school account within the Microsoft ecosystem. If they enforce this, it means we will have to invest in 5k+ tokens.
Can we accomplish this using certificates ?
For break glass accounts?
Because I'm not sub-literate and can maintain strong passwords and not tell them to other people.
Another absolute shitty posting from Microsoft. So thin on details. This leaves way more questions than it answers. I wonder if they have some kind of rule internally where they are told to be as ambiguous with their posts as possible. Working with Azure and O365 and dealing with shit like this is one reason why I hate my job so much.
I'm willing to bet significant money that the original technical write-up that got sent to the Corporate Communications Department contained the relevant pointers and details needed to deduce most of our questions here. But Corp-Comms almost universally wrecks these sort of things claiming it isn't inclusive enough of the non-technical people who aren't the target audience.
I think co-pilot wrote that blog post.
Nah, not enough flowery adjectives.
What if we use a third-party MFA solution? We're set up with Duo, not Microsoft's native MFA. As far as the portals are concerned, MFA is disabled since Duo is done via a conditional access policy that applies to everyone. Is this going to force us to double up?
You'll probably need to move to duo as an external authentication method, or if you're federated to duo, make sure your passing an MFA claim. https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-methods-in-microsoft/ba-p/4078808
If you're using a 3rd party authenticator and you've enrolled in MFA using that app by scanning the QR code, you're golden. That counts as MFA. If you've configured a 3rd party (Like RSA or Duo) as a custom control, you're probably in for a world of hurt. Custom Controls do not count as MFA as stated in the [documentation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/controls#known-limitations). Get rid of the custom control implementation and enroll your users the right way.
The ā*right*ā way? For some of us this approach is asking thousands of users to re-enroll each time theyāve got a new app. Itās not supportable nor sustainable at scale. We have M365 federated with a 3rd party idP for SSO with all MFA policies configured at the idP. Single enrollment for end user, single enrollment to support. There *is* (*apparently*) a newish way to pass the token info through to MS, but itās unfortunately not as simple as flipping a switch without risking an authentication loop.
Yeah. Microsoft doesn't count that as MFA if it's leveraged a Custom Control in Conditional Access. It's clearly stated in their own documentation and Custom Controls has been a preview feature since 2020, never having moved to general release. If you're leveraging that somewhere else that isn't Conditional Access then it probably won't be a problem. I've also got thousands of users. The answer is user education combined with sensible security directives. Additionally, not allowing 3rd party applications to be implemented without SAML SSO. When you have one iDP and everything is truly SSO, there's only one enrollment for MFA with an authenticator app. Not once every time a new app shows up.
Iām thoroughly confused by what youāre saying. Sounds like youāre pushing two contradicting points. All of our apps are integrated to SSO via a 3rd party idP (*including M365*). That idP is where MFA enrollment is. MS is currently not aware theyāve done MFA by the time they get to a MS service. The challenge is getting MS aware that MFA is being done, just not by them. (*WITHOUT asking users to do a second enrollment.*)
Why would they need a second enrollment if you're using SSO? I'm not asking to out of cynicism, I'm asking out of curiosity. I haven't ever worked in an environment where AzureAD wasn't the primary IDP. I've read some docs here and there but I haven't ever seen it in the real world. It feels to me like I'm not accounting for something obvious to someone with that experience in our back and forth here.
My MFA enrollment is with the third party idP. When MFA is asked for, itās the idP asking for the MFA push whether itās from a config on tenant level or individual app level. When it makes that connection to MS, even if I require an MFA push to access it - MS is not (by default) made aware that MFA ever happened. It occurred entirely prior to completing the connection to MS. And since ALL connections go through the 3rd party idP, youāve fulfilled your MFA req. Unfortunately to MAKE MS aware that MFA has occurred, itās not quite as simple as a checkbox.
Oh, okay. Thanks for breaking out the crayons and apple juice for me there, lol. I think you're right to be concerned, but I would hope that if Microsoft is gonna let its products be accessed using a 3rd party directory service, they had better behave like every other vendor out there that accepts AzureAD SAML for identity.
Ha! All good. They have (*quasi recently*) introduced hooks to allow 3rd party idPs to pass along their exciting tokens to "trust" however it's really nowhere near as "*check checkbox and you're good to go*" as you'd assume it to be. We tried enabling it once early on and created an authentication loop. Lots of considerations to work through first.
if MFA is now enforced for the Azure Portal - that's fine it should be enforced. if MFA is enforced for Microsoft 365 suite or Entra ID - [https://youtu.be/VX5rjTramis?si=6eBsllOOiE55-qvl&t=22](https://youtu.be/VX5rjTramis?si=6eBsllOOiE55-qvl&t=22) I work in K-12 (with over 4000 students) and just bringing up this conversation in meetings just starts wars....
In our country they banned phones in class and the idea is at some point school premises. Yet the government is forcing digital education so most kids have byod laptops to use in class. Token vendors rubbing their hands.
Well what about break glass account which they say to never be in any conditional access policies nor have MFA enabled EDIT: to clarify, we setup break glass account years ago per MS assessment and then their recommendation was no CAs nor MFA on this account. EDIT2: MS said it is just azure portal and there will be process to exclude accounts. More info will follow once I get it.
The recommendation most likely here is going to be that you buy & configure a hardware token for your breakglass account and store it in a safe. Or you have multiple MFA devices configured for it and have them held by different senior people at the company. The hardware token one is the recommended approach for AWS root accounts, I don't see why Azure would be any different.
A simple way to have MFA on breakglass accounts is to just use the standard TOTP 2FA. You can do this with M365 if you choose 'I want to use a different authenticator' at the MFA enrolment. Unlike the Microsoft Authenticator 2FA, the TOTP seed can be used at any point in the future to add that TOTP into any app etc, and TOTP 2FA codes can be generated completely offline - as long as the device has the correct time. So steps are: setup MFA using the TOTP option, when presented with the TOTP QR code (which contains the TOTP seed), print it and store the hard copy somewhere safe - either in the same envelope as the breakglass credentials or split up elsewhere intentionally depending on risk tolerance. In order to complete the MFA enrolment, you need to verify one 2FA code - so you will need to add the TOTP seed into something to get that first code, then delete it once the enrolment is finished.
> A simple way to have MFA on breakglass accounts is to just use the standard TOTP 2FA. Honestly yeah. Recovery codes in a safe.
That will not help you if whole MFA service is down, only thing I can think of is 3rd party service MFA but if that is also broken then what?
> That will not help you if whole MFA service is down If MFA is enforced for all users, they're not getting in anyway. Unless you were bold enough to temporarily disable MFA for key users during the outage.
Yeah because company would be like sure, letās take day off everyone because of MS! Of course they would tell me do disable this temporary EDIT: also there is second line of protection which is hybrid join/intune requirement which is still in place when MFA is off
I mean MFA being down is pretty close to their authentication system being down. What, are users going to demand I remove their passwords or drive to the nearest datacenter and fetch them data?
Dunno what you will do, my users would be fine with mix of corporate IP/hybrid join and Intune - they would be protected without MFA (they wouldnāt even see it internally in the first place)
There's nothing that can be done. If an hour or a day of outage is too costly, then there needs to be a re-review of why we're in the cloud in the first place. Besides, I think in 5 years we've been affected by one MFA outage (which lasted like an hour). An MFA outage may be a malicious attempt to get people to disable MFA. Otherwise, the authentication system is down. Nothing can be done.
It is not always about cost, imagine government being down lol
> It is not always about **cost** {Insert metric here} Users should also have measures in place to mitigate outages, if possible. Such as, make sure those critical files are synced locally before super important meeting. > imagine government being down lol The government is operating?
No way they will recommend this as no MFA is if MFA breaks then you can use break glass account.
Per MS this is only azure portal and there will be process to exclude accounts. Once I know more I will update this and other comment
when everyone is fully remote the physical tokens lose a little bit of luster.
> nor have MFA enabled Do you have a link to that?
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
That doesn't say no MFA? In fact, it says they recommend MFA on all accounts > Exclude at least one account from phone-based multifactor authentication To reduce the risk of an attack resulting from a compromised password, Microsoft Entra ID recommends that you require multifactor authentication for all individual users. This group includes administrators and all others (for example, financial officers) whose compromised account would have a significant impact. > However, at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts.
It is kinda poorly worded (by MS) but You forgot to put whole quote which states to exclude emergency account from MFA and configure other mechanism (if you have it). What you gonna do if MFA is down and canāt login from any account? Then there is no point for emergency account because you wonāt sign in with it. > However, at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts. This includes third-party multifactor authentication solutions. If you have a Conditional Access policy to require multifactor authentication for every administrator for Microsoft Entra ID and other connected software as a service (SaaS) apps, you should exclude emergency access accounts from this requirement, and configure a different mechanism instead. Additionally, you should make sure the accounts don't have a per-user multifactor authentication policy. This is what I says under āwhy you should have such account ā > The administrators are registered through Microsoft Entra multifactor authentication, and all their individual devices are unavailable or the service is unavailable. Users might be unable to complete multifactor authentication to activate a role. For example, a cell network outage is preventing them from answering phone calls or receiving text messages, the only two authentication mechanisms that they registered for their device. > Unforeseen circumstances such as a natural disaster emergency, during which a mobile phone or other networks might be unavailable.
> at least one of your emergency access accounts shouldn't have the same multifactor authentication mechanism as your other non-emergency accounts. This includes third-party multifactor authentication solutions. > you should exclude emergency access accounts from this requirement, and **configure a different mechanism instead.** Right, so they aren't recommending no MFA, they're recommending different MFA No one in their right mind would recommend no MFA on any account, much less one with full admin rights to the environment.
This is exactly what I said, have other mechanism but what you will do if whole MFA is down and you donāt have other mechanism? You are shit out of luck. There are ways to protect such account as constant monitoring and having 2 people knowing parts of password
> This is exactly what I said That's not what you said. You said MS recommended no MFA. That's not true. > what you will do if whole MFA is down and you donāt have other mechanism? That's exactly why MS is recommending another mechanism.
I have specified in my post now (edit) that that was recommendation years ago when we setup our emergency account with help of MS. What other mechanism you are talking about when whole MFA service is down? Even your 3rd party MFA, FIDOs are connecting through azure - I am talking about whole service being down - what are you going to do then?
Trusted locations?
> Even your 3rd party MFA, FIDOs are connecting through azure - I am talking about whole service being down - what are you going to do then? If MS MFA and DUO (in our case) are both down at the same time, I have far more important things to worry about. If you have 2 MFA providers, the odds of them both experiencing outages at the exact same time is so small, that it's irrelevant for most use cases.
Do you not have breakglass accounts tied to a fido2 token?
And what you going to do when MFA service is down?
[cabaseline202212/Conditional Access demystified-v1.4 - December 2022.pdf at main Ā· kennethvs/cabaseline202212 Ā· GitHub](https://github.com/kennethvs/cabaseline202212/blob/main/Conditional%20Access%20demystified-v1.4%20-%20December%202022.pdf)
Can you point me to the page you are talking about
You're misunderstanding at a totally different level. You need to familiarize yourself with the entire contents of the whitepaper or have someone who understands Conditional Access Policy take a look at your Conditional Access Policy. Microsoft does not say breakglass accounts should have no MFA. Microsoft recommends that the MFA method be separate from your other normal MFA methods. Go buy a couple of Yubikeys, and make 2 breakglass accounts with a new CAP using the tokens as your MFA. Build that CAP totally separate from everything else.
You are pointing me to 100 page paper, I donāt have time to look through all of this. I am not misunderstanding anything, I did say in my other comment MS recommends different mechanism. But what are you going to do when whole MFA service is down? You wonāt login. Also we did setup emergency account with MS years ago and havenāt touched it since and then recommendation was no MFA and no conditional access.
Most likely this will be like Security Defaults. If you already control it with CAPs, my guess is that at most you have to disable some new default policy.
We've had a Microsoft Managed conditional access policy in our list in report only mode for a few months, but that only says it will require MFA for users with admin roles. We made sure to exclude our break glass global admins from it already. I wonder if they'll add another Microsoft Managed policy that applies to all users and start enforcing both at the same time? https://i.imgur.com/lDAT1D8.jpeg
That report only one was actually in "Microsoft Managed" for us by default. I moved it to disabled because I don't like MS turning on policies at their leisure. Our custom CA's are stricter anyways :)
Yeah we've got a policy that applies to literally any Entra role, so I'm not sure the Microsoft managed policy would ever be applied. We're just interested in how it will work so we're gonna leave it alone and see.
How will this affect Tenants without P1 or P2 licenses?
MFA is included in every license.
Only basic "security defaults". Hardware keys (yubikeys) are not allowed without P1 or P2. At least that is what our VAR and MS told us. The option is visible, but we aren't allowed to use it.
Passwordless authentication, including FIDO2, is included in the free Entra license. Not sure how you're not allowed to use it or what that even means. https://www.microsoft.com/en-us/security/business/microsoft-entra-pricing
Huh. I didn't see this specific page, there is way too many of them. Hey, I don't know either. I just asked my boss to ask our VAR.
How are people handling using Okta as a IDP, and allowing the Okta MFA token to satisfy these types of things? just deal with the double prompt for MFA?
We have been using Okta for years for MFA for O365 and other apps. We donāt have the licenses for conditional access. What we did was enable security defaults after hours, and then disable them. We are no longer getting promoted to set up MFA for O365. There is some Okta documentation that advises to do this.
Iām in the same boat but have no idea what you mean by ā*enable security defaults*ā.
Well thatās good. Ā MFA is paramount these days. Ā Iām surprised there are companies still not using it.
Schools absolutely do not need/want kids using MFA - too complicated, wastes a whole lot of time resetting MFA when they decide to delete the Authenticator app because they couldnāt download Fortnite
For Azure Services only or Entra Authentication in general including exchange online etc.?
How does everyone here handle service accounts and MFA? We have a number of service accounts that are used by Dynamics, Github or Atlassian integrations where MFA is not possible. In good cases we can use MFA and create access tokens but it's not supported everywhere.
Same issue here with service accounts, only way Is to setup conditional access, no other solution found. We set It IP related, so It does not ask for mfa only if the service account tries to log from a specific ip address.
You can go a step further and limit the apps that CA allows as well and actually serve a block message if they try from any other location or any other app outside of the one listed. IP + app restrict + platform restrict if possible + exchange access policy or enterprise app assignment restrict = victory
Its just a Baseline policy being moved to default. Turn it off if you must.
The blog post is labelled as "test" and hasn't been put out on any of their social feeds. Chances are they didn't mean to publish itĀ
It's a good move to enhance security. It is a proactive step to safeguard accounts by implementing MFA for all azure users.
Just as well written as their post a few months ago leaving the Windows 11 upgrade decision to clients who are "unmanaged". They later clarified that domain controlled is managed. Funny how the text is written assuming someone doesn't know what MFA is in the first place.
Someone from MS commented "MFA will be required when logging in to the azure portal (portal.azure.com) and the entra portal (entra.microsoft.com).Ā " Ok that makes sense. Was the article written by Copilot?
Azure portal users only https://preview.redd.it/a366s9g7xw0d1.png?width=1155&format=png&auto=webp&s=be7fb75fbbcabb82c70425ab61eb449aab1fed21
This has been coming for some time ..
So if you click on the link in the article at the bottom (If you do not wait to wait for the roll-out, set up MFA now with the MFA wizard forĀ [Microsoft Entra](https://aka.ms/EntraIDMFAWizard).) it takes you to a wizard that lets you turn on and off features, like requiring MFA for external and guest users, exclude users/groups, etc. It basically takes you through the pre-made CA policies and settings (like what MFA methods can be used, etc). If it's just following these guidelines, then this likely to force tenants that have ZERO MFA configurations in place and likely won't affect those that are already set up with either Microsoft Default CA policies or have their own policies in place. There's even a link at the bottom of the wizard to 'Learn more about emergency administrator accounts'. Hopefully this is just to scare the late bloomers into bringing their security into this millenium.
this explains why Microsoft announced that 3rd party integration for 2FA , probably needed to make sure they cover companies using DUO etc as 2FA before moving forward with adding more 2fa enforcement's.
Can we still keep, or is it still best practice to have a "break glass" account that doesn't use MFA?
This is about āConditional Accessā replacing old authentication method and also about personal users that have office subscriptions. Normal admins are able to configure Conditional Access as they want.
You mean motherfucking authentication?
Maybe I'm dumb, but we already are forced to use MFA for about 10% of our users. All the settings I've seen in entra ID Admin Center had no option to disable MFA for users. I have no education in m365 admin stuff, I just have to figure it out somehow. I'm based in Germany btw. Maybe it's different here? (Regarding forcing users into MFA)
In the past, I was able to deactivate MFA for each user, this setting is now read-only
Hello everyone, my name is Naj Shahid and I am a product manager in Azure leading this initiative. I have posted a comment in the tech community blog post that should clarify and help some of the questions. Please see my comment here: [https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/bc-p/4143356/highlight/true#M6078](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/microsoft-will-require-mfa-for-all-azure-users/bc-p/4143356/highlight/true#M6078)
Thanks for replying. Can I suggest though, it would probably be better to make a very clear and obvious edit to the original blog post? Not everyone reads the comments.
They said this back in October too.
Did this start early got prompted this morning out the blue....
So what about breakglass accounts that MS recomends with full global admin and no MFA?
Actually, they do not say no MFA. They should have a separate MFA method than the rest of your company. It should also be excluded from all conditional access policies. [Manage emergency access admin accounts - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#exclude-at-least-one-account-from-phone-based-multifactor-authentication)
[cabaseline202212/Conditional Access demystified-v1.4 - December 2022.pdf at main Ā· kennethvs/cabaseline202212 Ā· GitHub](https://github.com/kennethvs/cabaseline202212/blob/main/Conditional%20Access%20demystified-v1.4%20-%20December%202022.pdf) [Buy YubiKeys at Yubico.com | Shop hardware authentication security keys](https://www.yubico.com/store/) Please make sure to put this in your project task list, as it seems you've got some reading and work to do.
I was wondering why my main tenant was requiring me enroll in the app instead of honoring my SMS and 1pass 2fa. Huge PIA, since I already have to have DUO, really didnt want a 2nd dedicated authenticator app outside of 1password or my yubi key.
I just made the totp the main one that is always defaulty chosen, and uploaded it into my 1password.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
At a glance, service accounts, "kiosk" accounts, test accounts. Oh and schools.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
>Schools... I don't know. Shouldn't you teach proper safety at schools as well? It's different for elementary school as you cannot expect those students to have 2fa devices.. Our country has laws against using mobile devices in class. > Those definitely SHOULD have mfa. Depends, our test accounts a simply login test accounts with zero rights.