The new MFA for Partners requirements - what will that do to our Skype/Teams room system?
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.
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?
@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.
@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
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.
Yes, currently does it not broke it. But someone must sign-in in browser and go within the MFA registration for these service accounts. As we test, the web sign-in is blocked to time when MFA registration is complete after registration expires.
What are the suggestions for dealing wth Surface Hub devices, conference room equipment, and Lobby phones? The Surface hub deployment plan basically says to setup a service account for the hub (https://docs.microsoft.com/en-us/surface-hub/surface-hub-2s-account) this way you can invite the Hub to a meeting and easily join when the time comes. Other conference rooms (other meeting room equipment or even just conference room phones), and Lobby phones also require similar service accounts. How are people going to deal with these accounts once MFA is required?
We have a lot of Skype rooms that use a user account with an E5 licenses. These accounts are used to log into our Polycoms.
The requirements state that all users should have MFA enforced and that no IP/Location exclusions can be used.
How can be adopt this requirement with our rooms?
Is it enough if we create a Conditional Access Policy that only allows sign-ins from our Offices?
I had this same question due to an HP slice using the newest SRS. It has to authenticate and has a meeting room license to get the services it needs. I didnt see a way around this either. We also have email relays and service accounts for services like Clique that access CRM.
I just found another post about this same topic (sorry for the duplication): https://www.microsoftpartnercommunity.com/t5/Multi-Factor-Authentication-MFA/The-new-MFA-for-Partners-requirements-what-will-that-do-to-our/m-p/11161#M100. It seems like MSFT doesn't have a good answer yet. The last reply there, was that we may need to purchase Azure AD Premium and use that to create app Passwords for these systems. That doesn't look like it'll work because I can't use an app password to log into Teams.
Yes it seems confusing, i have a user based MFA deployment that does allow for app passwords now. It seems like the baseline policy wont allow app passwords or is unknown from what ive read and heard. Either way it seems like those accounts will break.
@JanoschUlmer Any update on this one? Seems like confrence phones is a pretty big issue for everyone, and I havent heard anything from Microsoft on how these new policies are going to work for any of these room systems. We have new Yealink Teams phones that support modern auth / MFA, but I can't imaging how that would work in a shared confrence phone scenario.
We also have some older phones assigned to users on users' desks that don't support modern authentication that we've created some CA exclusions for to allow legacy auth to work before we can replace them. If the intent is we have to buy new phones for everyone we'd like to know sooner then later.
Sorry, I have no update on this one. All I can currently say is that engineering for Teams is working on Modern Auth support for Teams Room, hopefully we get some updates in the coming months (not before August 1st unfortunately).
If the baseline policies are used, those devices will fail to authenticate if they are using legacy auth, or ask for 2nd factor if using modern auth (which is obviously a problem for a shared meeting room).
So for those devices which are using legacy auth, you can not enable the baseline policy. You need to create your own conditional access policies for the majority of user accounts to enforce MFA, then make an exception in the CA policy for the accounts used by those devices - and enable MFA directly for the (device) user account to allow to configure app passwords. This is currently the only known workaround to me.
As a last resort the only alternative would be to split the tenants - e.g move internal production to another tenant and keep the current tenant just for CSP business. I know, this would not be an easy process for most.
Thank you for the update. We'll go the route of creating custom CA policy and excluding the Surface Hub. We'll try using an App Password again, but last time I checked, an App Password did not work wile logging into MS Teams. I don't know what else we can do until the MS Teams department fixes this.
@JanoschUlmer I want to bump this question before tomorrow's office hours. App Password don't seem to work for logging into the Teams desktop app, so I'm not sure what we'll do about our Surface Hub and the additional surface hubs we plan on purchasing. August 1 is getting closer and we need solid answers for how to keep using these devices as resources that can be invited to meetings. Thank you.
when reading the following im not sure such accounts will be affected.
By August 1, 2019 these partners are required to take following actions:
- Enable multi-factor authentication for all users in partner tenants
All users in partner tenants must use multi-factor authentication (MFA) when signing into Microsoft commercial cloud services or transacting in CSP through Partner Center or via APIs. Baseline protection policies that include multi-factor authentication are available at no cost for all users of partner tenants.
What is your opinion on this ?
The requirement affects all user accounts, also room devices use some form of authentication and would be affected by the baseline policy. So from a contractual view, there is no exception (See CSP program guide for details).
However, we are currently evaluating if using AAD Premium Plan 1 and app passwords (for enabling legacy protocols to work) might be possible, we will update you as soon as we are able to confirm this. If this would work depends on how the enforcement will be checked later.
Just maybe such app does not support modern auth at all. We have a tablet with meeting room system attached and it need to access with password to EWS. We try to enable baseline policies and this immediately stops working. With the AAD Premium and custom CA policies, we can easily allow this to work, but it seems that it broke the requirements to CAP be working.
I'm in the same boat, we have some old phsyical Skype/Teams phones that utilize legacy auth. I've already disabled ALL Legacy Auth for everyone externally using custom CA rules, with some exclusions for JUST internal legacy auth for these phone connections to keep these aging phones around until we can replace them.
If this change is going to force us to buy new phones for everyone, I think we're all going to have a bad time.