Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Level 1 Contributor

Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

Alligned with every reasonable person in this community, we also take umbrage to the best intention, but ill-thought policy of the Microsoft Partner team enforcing necessity for MFA on all accounts. Here are some examples where their present exclusion from MFA is actually entirely valid:

  • Shared devices for resources, like meeting room phones, Surface Hubs, etc
  • Non-interactive accounts for automated scripts; some services like Exchange Online still don't support service principals
  • Break glass accounts; enabling MFA for all accounts without any exemptions violates Microsoft's own guidance on emergency access
  • Ad-hoc guest access (eg, to sales/marketing material) where there isn't a relationship or strong knowledge of readiness of that guest to use MFA; many of our clients are coming to us to help implement MFA so it would be unreasonable to expect them to have MFA configured just to access our resources.

 

What does Microsoft have to say about this?

 

Additionally, what risks does Microsoft associate with these types of accounts not having MFA? They have no delegated access. They can't be used as lateral movement paths in Office 365/Azure AD, because there aren't attacks like this available. It seems nonsensical that these account types can be considered dangerous in ways that require them to also have MFA.

5 REPLIES 5
Level 4 Contributor

Re: Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

Hello, agree or disagree they have multiple reasons for the requirement which you might be able to find over here. https://www.microsoftpartnercommunity.com/t5/Multi-Factor-Authentication-MFA/Guest-accounts-require-MFA/m-p/13022/highlight/true#M562

 

-jon

 

@idwilliams  wrote:

Please note that the program guide for the Cloud Solution Provider program does not make any distinction between the various types of accounts (e.g. admin, non-admin, guest, service, etc..). All accounts are required to have MFA enforced. There are multiple reason behind this, and several of those reasons have been discussed through this thread. Given the highly privileged nature of being a partner and the numerous methods credentials can compromised all accounts are subject to these requirements.

Microsoft

Re: Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

@cc-ashley Lateral attacks are a real thing, and some of them were unfortunately "successful" in CSP Partner environments, this is also why MFA was made mandatory. Unfortunately also many attacks can spread because there are unsecured/unmonitored service accounts.

 

For Exchange Online the limitation is known and Exchange engineering is actively developing a solution, a current available workaround has been published.

 

For Teams Rooms - afaik a fix allowing to support modern auth is planned for Q4, but you are correct that there are no solutions currently (And even when modern auth is supported I have not yet seen how this would be handled from a user experience or admin perspective - so no promisses yet)

 

The guidance for emergency accounts does not recommend to exclude admin users from MFA completely, it says that admins should use a different authentication method. So it is not in conflict, the MFA requirement is an additional requirement to fulfil which limits the options you have for emergency accounts. 

 

It is not required to set up MFA in all guest environments, if you enable MFA for guests in your tenant they just need to register themselves when they access something. So it is only required to inform guest users that they might see the MFA prompt and they will need to register (even if they already registered for MFA in their own org). 

Level 1 Contributor

Re: Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

Please explain how lateral attacks are possible from a guest account to an Azure AD account with MFA, and how MFA on guest accounts fixes that?

 

Unsecured and unmonitored service accounts are a different problem. Indeed partners should be protect them better in general. However, if Microsoft made Service Principals available for automation in all places across Office 365 (and beyond), and provided reporting to show where automated user principals could be replaced with service principals, then, perhaps a blanket MFA enforcement could be valid.

 

So in the meantime while we wait for full support from all areas where MFA would break functionality, does Microsoft intend for us to just have broken experiences? Seems a bit cart before horse.

 

The emergency account guidance includes a break-glass account, which should be an account with a strong password without MFA so that should there be MFA or Conditional Access problems or misconfiguration, this account can be used for access. The Baseline Policy has no exclusions, and therefore you couldn't prevent this account from being protected from this.

 

I think you're missing the point by saying that MFA doesn't need to be configured in each guest environment; each guest user, who might come from an environment that doesn't have MFA today, would have to enroll possibly without guidance or support from their own IT, and maybe limited access to that of the Partner. To say MFA is as simply as following some prompts when signin up for MFA, undermines the very work Partners do to help secure companies in Office 365/Azure.

Level 1 Contributor

Re: Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

Agree that MFA is the right direction, and that Partners need to do more to protect their accounts.

 

However, forcing that all Partner tenant sign-ins, including their guests (regardless of the interactions of access), doesn't stand-up. There aren't any reasons linked in that thread that provide any depth about the risk associated with guests.

Highlighted
Microsoft

Re: Ill-thought-through wrecking ball to crack a nut: MFA for non-MFA-able devices and accounts?

Guest accounts can now also be granted access & permissions in Partner Center (Though not for CSP purposes - yet), afaik this is one reason. The other reason is that a guest user is able to get information in a tenant that makes further attacks easier (e.g. area of social hacking). I agree with you that the risk of guest access can be debated for this scenario (I did raise doubts myself, especially how MFA on guest accounts increases the security posture - but while I have some knowledge on this topic, I'm not that security expert that can have a deep dive discussion on that and question what other experts have deemed to be necessary). 

 

I would encourage you to test the behavior of enforcing MFA for guests - it is really not something the IT of the guest user would need to be involved, the user will not set up MFA in his home tenant, he will only set up registration for his guest user in the inviting tenant. Of course you as Partner do important work planning & deploying MFA for customers, didn't want to neglect this, this step is not about setting up the MFA service within customer tenants.

Actually, even if MFA has been set up in home tenant, guest user would be forced to register

 

For break glass accounts the guidance is - (emphasis added):

 

  • The authentication mechanism used for an emergency access account should be distinct from that used by your other administrative accounts, including other emergency access accounts. For example, if your normal administrator sign-in is via on-premises MFA, then Azure MFA would be a different mechanism. However if Azure MFA is your primary part of authentication for your administrative accounts, then consider a different approach for these, such as using Conditional Access with a third-party MFA provider.
  • The device or credential must not expire or be in scope of automated cleanup due to lack of use.
  • You should make the Global Administrator role assignment permanent for your emergency access accounts.

Exclude at least one account from phone-based multi-factor authentication

To reduce the risk of an attack resulting from a compromised password, Azure AD recommends that you require multi-factor 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 should not have the same multi-factor authentication mechanism as your other non-emergency accounts. This includes third-party multi-factor authentication solutions. If you have a Conditional Access policy to require multi-factor authentication for every administrator for Azure AD and other connected software as a service (SaaS) apps, you should exclude emergency access accounts from this requirement, and configure a different mechanism instead.

 

Certainly this guidance can be interpreted in different ways reg. the details, but it does not say "exclude a break glass account for MFA completely", it says "use not the same method for all".

A real conflict of the break-glass-account guidance and the Partner Center Security requirement would happen when Microsoft would for example say "you need to have one global admin account without any MFA configured to have a supported environment". However, the break-glass accounts are a recommendation and not a requirement. It might be an organizational requirement of course - interestingly I get mixed feedback from other Partners on that, so it is not a requirement for every organisation since some have determined that the risk of a MFA failure is more in other areas like having set only one 2nd factor method - while for other it is so important that they even decide to split tenants. 

Also, there is almost nothing which can protect you fully from a misconfiguration. Even when you have set up a break glass acount with no MFA, if another admin misconfigures the conditional access policy to include the emergency account, you may lock out this account again - so naturally this concept has some limits when it comes to protect yourself from misconfiguration. Protecting against service outage is still possible with using multiple MFA methods, multiple token devices, multiple MFA services.

 

You are correct that baseline policies do not allow for exceptions, but baseline policies were provided as an additional option to make the configuration easier and to provide a cost-free option for enabling MFA, even a no-cost option to get identity protection features usually only available with a AAD P2 license. If you need to make exceptions because of what has been discussed above you can do so using e.g. conditional access - but this is not for free. It is not that Microsoft forces you to use the baseline policies, you can argue though that the security requirements effectively force Partners in certain scenarios to think about adding licenses to allow for more sophisticated scenarios.

 

Reg. the broken scenarios - I fully agree with you, I would use another analogy though :-) It is more like cart is already rolling while the horses catch up...  

When you think of Microsoft as one entity it may be irritating that this enforcement breaks not only some 3rd party services, but also first party services. Reality is that within Microsoft there are many, many different teams which need to be coordinated, and during this coordination it can happen that one part has to make a decision and go pubic with it while the other part is not yet ready.  Of course, this is not something you as Partner should suffer from, in this specific case it could not be avoided though. So it is a valid complain and in an ideal world it would have been done in a more coordinated fashion.