Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Microsoft

Re: Implementing Baseline policy: End user protection ;Does this impact Roomaccounts for SRS/MTR and SurfaceHub accounts?

@MVolker : Creating your own risk-based conditional access policies would require to get AzureAD Premium Plan2 - and even then, if a risk is detected, Teams on Surface Hub would fail. Creating your own risk-based policy would also not directly help to achieve compliance since it does not trigger MFA every time (Yes, baseline policy also does not trigger MFA all of the time currently, but this will change)

 

And when technical enforcement starts, if there was no MFA - because no risk was detected - the device would not be able to authenticate. So your own risk-based policy would really not give you much.

 

So currently the only working solution is to exclude this account from MFA - which is, to be very clear on this, not in compliance with the contractual requirements. This will at least work until technical enforcement starts.

 

 

 

Level 2 Contributor

Re: Implementing Baseline policy: End user protection ;Does this impact Roomaccounts for SRS/MTR and SurfaceHub accounts?

Thanks @JanoschUlmer for clarifying that we have no way to get these devices working under the current contractual requirements. We will raise this with our contacts at Microsoft.

 

Micheal

 

Level 1 Contributor

Re: Implementing Baseline policy: End user protection ;Does this impact Roomaccounts for SRS/MTR and SurfaceHub accounts?

Hi @JanoschUlmer, have the Microsoft legal team responsible for the partner contracts been made aware of this issue and do they have any guidance as what partners are meant to do here?

Highlighted
Microsoft

Re: Implementing Baseline policy: End user protection ;Does this impact Roomaccounts for SRS/MTR and SurfaceHub accounts?

@bedwells This is currently being discussed on a technical level, afaik there are no plans to make service-specific exclusions in the the contract/program guide. 

Level 1 Contributor

Re: Implementing Baseline policy: End user protection ;Does this impact Roomaccounts for SRS/MTR and SurfaceHub accounts?

@JanoschUlmerI would suggest it still be made aware to those that manage the partner program/contracts that it is impacting the ability for partners to both use and demonstrate the latest Microsoft technologies to customers and if this is to continue for months without a technical solution then that's a real problem.

We have raised from our side, if it is possible for you to reach out as well that would be appreciated

Level 3 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Not to Muddy the waters on this topic, but from what i understand the way forward with accounts like this one is to user MFA per User activation. If you enable the user for enforced status in MFA this will allow the creation of an application password to user to feed to SRS. However, it seems SRS is modern authentication ready so some folks are having issues with Teams/SRS (Myself included). I am looking for an answer on this one myself.

 

From what i have seen on the meetings and other discussions i have had on these forums, you cannot exlude IP addresses any longer for trusted locations in CA. Each log in has to be MFA on every log in and conditional access will not allow the user of application passwords.

 

I had a few third party applications that i enabled per user MFA for such as voicemail to email, click Dimensions to satisfy the MFA claim and these are working just fine. I took the road of having the appliance or application owner register the MFA for the account, maintain ownership, and the applciation password that comes with it.

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

@dferrell : I have done some testing in the meantime, some small clarifications:

 - App passwords can be created when user status is set to be "enabled", it does not need to be "enforced" (even though it should switch to enforce once registration is done)

 - If app passwords have been created, they can be used even though user is also targeted the same time by conditional access or baseline policy. Maybe this was a bit misleading in some of my answers - userA can have MFA enabled on his user account, and there can be a conditional access policy for userA requiring him to use MFA. App passwords will then still work, in azureAD sign-in logs you can see that MFA requirements have been bypassed since app password was used. Only if you use only conditional access to enforce MFA, and not set MFA for the user account no app passwords can be created.

 

I can confirm that using IP-based exclusions from MFA are not allowed (not possible once technical enforcement starts). For Teams Rooms/SRS it was mentioned to me that the team is working on a solution, but I currently can't give any details on how exactly this will look like.

Level 3 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Thank you for the clarification on that piece. So it will work how i have it set up as well then. I have excluded the accounts from conditional access and just set them to enforced status. It is good to know that the combination will work that way.

 

I wanted to also ask what is the stance on shared mailboxes, resource room accounts, and blocked users? I have made sure to include licensing and conditional access on any user account that needs to log in. Will blocked accounts simply be ignored in the technical requirements? We are in the process of some cleanup and what to know if we would remain in complaince for these items.

 

Howerver, I do not have CA or MFA set on the resource rooms, shared mailboxes, or blocked accounts. Any info or guidance on this would be appreciated.

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

For Shared Mailboxes - usually it should not be a problem to enable MFA for them. Per default shared mailboxes have a disabled user account. Even if this user account is still enabled, enabling MFA for this account - which is required - should not cause issues with user access since users will authenticate using their own user account and not log in with the user account of the shared mailbox. If you have a scenario where people are logging in with credentials of the shared mailbox, this will be a problem.

Same applies to resource rooms - I do not see an issue enabling MFA for those accounts per se - but it depends on how these accounts are used. E.g. if there is a meeting room display device using this account to get calendar info, this would certainly be affected.

 

For blocked users - from contract perspective there are no exclusions, so generally the recommendation is to enable MFA for all accounts.

From technical perspective - once technical enforcement starts the user account would need to be enabled for MFA once it will be activated again, otherwise authentication would not be successful. They are not exactly "ignored" - if user account is disabled or blocked from sign-in there will be no authentication happening, so any technical enforcement will simply not apply. It would be recommend to define CA policies for MFA in a way that once those accounts are enabled again, the will be automatically targeted by a policy that enforces usage of MFA.

Level 3 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

For the Shared mailbox and resource rooms would you recommend per user MFA activation? I do not believe i have enough licensing to cover all of these with CA.

 

The blocked accounts i have will most likly be removed from Office 365, however what about the shared mailboxes that are cloud only vs on-prem and synced? Will MFA impact those any differently?

 

I have other CA policy in play such as country blocking etc. if would enable the baseline policy and i have a few accounts that are using app passwords. Will the baseline policy break those accounts. I know that you told me app pw will work with CA as long as the user is set to enabled status etc. I just want to make sure the baseline wont have an adverse impact on the accounts i have already taken time to fix.

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

For the licensing part - general rule is that only users can be licensed - so if only licensed users are using shared mailboxes or resource accounts it should be fine (Disclaimer: Official, legally binding licensing statements can only be found in the licensing documents, in this case the Online Services Terms).

Also technically the system does not require to have licenses assigned to those user accounts, so I do not see issues with the number of licenses.

 

MFA on shared mailboxes do not behave differently if they come via synced accounts or cloud-only accounts - at least not in a way that I see relevant for enabling MFA. As said, usually the user account is not active anyway.

 

Baseline policies + users with app passwords can also be combined.

Level 3 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Thank you for the clarification. I ended up adding the accounts to CA and testing. I did not appear to need a license to add those to the CA i already have created that enforces MFA on each logon. I did this for all resource accounts and sharedmailboxes. So this should cover them under CA that enforcces MFA.

Level 4 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?


@JanoschUlmer wrote:

For Shared Mailboxes - usually it should not be a problem to enable MFA for them. Per default shared mailboxes have a disabled user account. Even if this user account is still enabled, enabling MFA for this account - which is required - should not cause issues with user access since users will authenticate using their own user account and not log in with the user account of the shared mailbox. If you have a scenario where people are logging in with credentials of the shared mailbox, this will be a problem.

Same applies to resource rooms - I do not see an issue enabling MFA for those accounts per se - but it depends on how these accounts are used. E.g. if there is a meeting room display device using this account to get calendar info, this would certainly be affected.

 

For blocked users - from contract perspective there are no exclusions, so generally the recommendation is to enable MFA for all accounts.

From technical perspective - once technical enforcement starts the user account would need to be enabled for MFA once it will be activated again, otherwise authentication would not be successful. They are not exactly "ignored" - if user account is disabled or blocked from sign-in there will be no authentication happening, so any technical enforcement will simply not apply. It would be recommend to define CA policies for MFA in a way that once those accounts are enabled again, the will be automatically targeted by a policy that enforces usage of MFA.


Hi Janosch, I may be missreading this reply. Do we need to have MFA "Enabled" or "Enforced" those are two different MFA states.

 

You mention that MFA Enforcement is based on reviewing Azure AD Sign-in Logs. At the end of the day is that the only thing that ca be checked? We could have 100's of guest accounts without MFA enabled or enforced and as long as there are no successful sign-in attempts, they will not affect our MFA Compliance score?

 

Thanks,

-jon

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

@JonW : If you use set up MFA per user you set the user state to enable, and it should change to "enforce" once the user does the registration. See this article for more details: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

 

In terms of compliance - as long as the status is just set to "enable" a MFA prompt might not be triggered, and any sign ins without doing MFA would lower the score for the MFA compliance report.

 

Reg. your questions on guest users - yes, the score would not be lowered if those users do not sign in. However, from contract perspective you would still not be compliant because it is required to configure users for MFA.

Level 2 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Any update on the handling of room systems?  Thanks.

Level 1 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Still waiting on an update on how to handle room systems.

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Teams engineering did not publish any update yet on this.

If I hear something I will update the thread for sure.

Influencer

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Hi @JanoschUlmer - any news here?  We have thousands of dollars of Teams Rooms Systems that are sitting idle.  Specifically, one Surface Hub 2S and two Teams meeting rooms.  

 

I totally understand that you are the messenger here and don't set the policy.  This has been an open thread for 5 months plus - who can we escalate to in the Partner world?

Visitor 2

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Hi @JanoschUlmer, happy new year. I wanted to echo the sentiment of other posters and ask whether there is any channel with which we could escalate requesting resolution of this issue.

 

Similar to the other poster, we have multiple Logitech Group systems sitting idle since last year. Please let us know if there are any updates.

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Generally you can contact your account team and ask them for escalation (Partner Development Manager, Service Account Manager if you have an ASfP support contract). In parallel you can open a support ticket in Teams support - they can also give a more detailed response about an ETA for an update. Then you can push for feedback on a respective UserVoice feedback item

However, development has already started - I doubt the update will be delivered faster when escalating via the account teams. 

 

Also, something to clarify here since it wasn't discussed in this thread before and some more guidance was published since my earlier answers: Even though the agreements (MPA) do not allow for any excluded accounts, the technical enforcement - as far as it is planned and documented currently - will not impact this scenario. So technically you can exclude the Teams Room-Account from MFA currently without technical problems, and then switch to Modern Auth as soon as the update is ready. Again - technically possible even though not officially compliant (see also the list of potential technical exceptions here)

Level 2 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Any update on this. Our teams room device just sits saying Cannot Fetch Calendar.

 

Any help would be greatly appreciated. 2600$ of equipment just sitting!

Microsoft

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

I have not seen a ETA. So for now, you would need to exclude the account from MFA to make it work (So if you use AzureAD Security Defaults, you would need to switch the setup to custom Conditional Access policies)

Visitor 1

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

I can't believe that there is no real solution for this yet. Just last monday MS mailed us that Conditional Accesses has to be changed to security default. So no conditional policies are accepted anymore.

 

There is Meetingroom lisence, why cant we just disable mfa from those?

 

We do have multiple Teamsrooms devices and we cannot use them now.

ps. We are 10 minutes away from migrating teams rooms to another tenant just to make it work.

 

Level 2 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

We use the meeting room license and its works great if you disable MFA in MFA portal. the only thing that we are having trouble with is the screen keeps saying "cannot fetch caledar" GRR.

 

microsoft is making teams into a mainstream platform, but they are not support the people using it everyday. you can never get ahold of anyone at MS and they tell you to go to your reseller. the resellers have no clue about it either. i guess you have to be a massive company like GM or Ford or whoever uses teams in the massive corp world then microsoft will do whatever they need.

Level 1 Contributor

Re: The new MFA for Partners requirements - what will that do to our Skype/Teams room system?

Same issue here. My company just migrated one of our video rooms from a Cisco solution to a Lenovo ThinkSmart Hub 500.

 

The hub is able to receive direct calls and call others from the hub, but the room's calendar is not showing, and so we are missing the ability to join meetings directly on the hub's screen.

 

The calendar is working when we turned off the security defaults (temporary) for testing, but as other has pointed out, this is not a viable solution due to the partner requirements.

 

Also, see this post on the Lenovo forums that describe the same issue we're facing; https://forums.lenovo.com/t5/ThinkSmart/Thinksmart-Hub-500-Error-quot-signing-in-quot-at-the-top-of-the/td-p/4546770

 

The sign-ins log in Azure AD also show's that the meeting room user running on teams rooms in the hub is failing to authenticate:

  • Application: Office 365 Exchange Online
  • Status: Failure
  • Sign-in error code: 53003
  • Failure reason: Access has been blocked due to conditional access policies.

 

  • Authentication method: CloudOnlyPassword
  • Result detail: Access has been blocked due to conditional access policies.
  • Requirement: Primary Authentication

 

  • Policy Name: Security defaults
  • Grant Controls: block
  • Result: Failure