
David Genenz (Customer) asked a question.
Thanks in advance for any help with this one. We just bought Crestron's Teams Room devices and we seem to be bumping our heads into getting Modern Authentication working properly. On the devices, the Teams admin area is set to Modern Authentication. However, I have a policy in Okta for Office 365 as follows:
Okta Non-Modern Authentication Block
People - users assigned this app
Location - anywhere
Client - Check: Exchange ActiveSync/Legacy Auth and all platforms
Device Trust - Any
Access - Denied
Basically the the accounts are blocked on the Teams Rooms devices with this policy. I have a bypass policy and group where legacy auth is allowed. If I put the accounts in that group, it works fine.
Is anyone aware of whether or not there's an issue with Teams Room devices, Okta and modern authentication and how to resolve it?
Here's a Microsoft article that I found interesting and led to more questions. https://docs.microsoft.com/en-us/microsoftteams/rooms/rooms-authentication. Under the Hybrid modern authentication, it looks like the accounts on the Teams Rooms devices use Oauth 2.0 Resource Owner authentication flows while for federated, it uses Oauth 2.0 SAML Bearer Assertion flows. Makes me curious if this is screwing all of this up. Also curious if I have Okta but created an Azure/O365 native account (skipping Okta entirely for one account), if I used that, does having Okta in play for the tenant still force even the native account to use the SAML bearer flow or does it go to the resource owner flow?
If anyone has any ideas, thank you in advance.

Same issue here. Had to create a Sign-In exception rule for all of our Teams Rooms in order for them to successfully log in. Would love to know how to remove the exception if at all possible.
if you create account like myroom@yourorg.onmicrosoft.com it'll go through ROPC flow, cause onmicrosoft.com domain is managed and cannot be federated. And obviously Okta won't be in play with this scenario.
For federated scenario, I'd start by looking at the sign in log for room account in Okta to see which endpoint it's trying to reach.
What I'm seeing for the Okta authenticated accounts, is they are coming from
sso/wsfed/username13
and
sso/wsfed/active (which I believe is non-modern authentication)
I opened a support case and the Okta Engineer confirmed that my policies were set correctly. Basically, it fully looks like the authentication (or at least part of the total authentication process) is coming across using legacy authentication.
Rather than getting into the whole fun of trying to get both Okta and Microsoft (and the vendor for the devices) on a call, I'm just moving the accounts into O365/Azure natively.
Okta does have an early access feature to allow a custom client option in addition to the modern and legacy/exchange active sync options. It can use the UserAgent information to make custom rules. I didn't opt to go this route at this time. Also, it was interesting that my out of date Teams device (testing device that was sitting on the shelf for months) didn't show any of that information in the Okta log while the newer devices had those fields populated. When I updated the old Teams room device, it did actually populate those fields in Okta.
Microsoft also did just send out a notification today implying that they are going to start blocking legacy authentication down the road. If that's accurate and I'm even remotely understanding any of this, I'm curious if that will break Okta/Teams Rooms devices with the non-modern authentication bypasses in place...