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

[JohnF]

Those systems have saved creds tied to the account for signing into teams.

Would suspect that enforcing MFA globally as currently being suggested/required will be break that functionality.

We currently have conditional access restrictions on accounts such as that to only allow logon from our IP addresses to prevent external abuse of accounts.  Does location restriction meet your MFA requirements (something you know....something you own [creds/IP address respectively seem to in my eyes, but not sure what your rules are, and quite honestly, based on the call earlier today, doesn't sound like you're quite sure what the rules are going to be either).

Let me know how we should proceed.

Thanks.

[dferrell]

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.

[JanoschUlmer]

@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.

[dferrell]

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.

[JanoschUlmer]

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.

[JonW]

---

@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

[JanoschUlmer]

@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.

[JohnF]

Any update on the handling of room systems?  Thanks.

[rexchoi]

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

[JanoschUlmer]

Teams engineering did not publish any update yet on this.

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

[sreedwilson]

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?

[dferrell]

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.

[JanoschUlmer]

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.

[dferrell]

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.

[hwaarsing]

I need to implement the Baseline polices as we are a CSP.
Admin policy is enabeld, no problem.

Does anybody knows what the impact is when enabeling Enduser protection policy recarding Surfacehub and room system accounts (SRS/MTR)? These accounts must be enabeld a an user, but they cannot use MFA. not even a application password works.
I don't have a test tenant availible where i can test these policies without interupting normal business.

[JanoschUlmer]

@hwaarsing : Those room devices will not work in the future with this baseline policy. Right now the end user protection baseline policy will not enforce MFA for every access - so it will not break something right now -  but this will change as baseline policies will envolve (specifically for enforcing MFA for CSP users). It will take also few months until things change in Teams Rooms that might resolve some problem (Support for modern auth. - but no promises).

[JohnF]

Your comment "Right now the end user protection baseline policy will not enforce MFA for every access - so it will not break something right now" doesn't make sense.

It will not enforce it for every access...but it will be enforced for setup and periodically afterwards, so...sure seems like it'll break something right now.  Can you explain a bit more clearly as to how this won't break it?

Thanks.

[JanoschUlmer]

@JohnF : The end user protection baseline policy does currently only trigger MFA when a sign-in risk is detected, so it might be that no MFA will be triggered at all after this policy has been enabled (unless the user would for example change networks often and thereby the sign-in would be considered risky).

I mentioned this just to make clear that if you right now enable the policy and you see nothing break and no MFA, this might change and you should not assume that it will stay this way. 

[MVolker]

@JanoschUlmer 

We have implemented the new MFA requirements using our own Conditional Access policies so that we can have a few exceptions for Legacy Auth requirements using App Passwords as you have advised this is allowed currently.

Since we are not using the Baseline policies we are now forcing MFA on all users no matter of what Risk Category. This is now causing issues with our Surface Hub 2S and performing Demonstrations for our customers to help sell these products. Teams on the Surface hub does not give you the ability to enter the App Password at all. What options do we have to get the Surface Hubs working with the new Security Requirements. So that we can Demo and Sell these devices.

[JanoschUlmer]

@MVolker : For Teams Rooms and Teams on Surface Hub there is currently no solution.

To my knowledge Teams engineering is working on the authentication issues and should have a solution available in the coming months, I can not share a more concrete ETA as of now.

[MVolker]

@JanoschUlmer
While the Teams engineering team are working on the authentication issues are we able to create a custom conditional access policy for the Surface Hub user accounts that enforces MFA on Risky logins similar to the baseline users policy? And create very complex passwords for these user accounts, so that my staff are able to continue performing customer demonstrations?
Thanks
Micheal

[JanoschUlmer]

@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.