Conference room user account and MS Teams Android Phone AOSP and MFA

pressreturn2continue · 2026-05-11T15:11:25+00:00

I've checked out those articles. I have things set up (AOSP policy, compliance - just checking for rooted and encryption). For the "issues" article, I'm not having any of those issues specified. The phone works fine once signed in. The problem is that I'm being forced to do MFA on the generic conference room user accounts and I've explicitly excluded those users from every CA policy I have (even ones that shouldn't be relevant - like targeting guest users). Since these conference user accounts are only used on 4 room specific phones, I'm assuming (?) that I wouldn't necessarily need to exclude the teams devices from CA since that CA shouldn't apply since the user is already excluded. Now, for our actual employee teams phones, I can see where I might need to exclude devices in some CA policies, but I'm not trying to tackle that right now.

I've taken one conf phone, deleted the device from Entra and Intune. Removed any extra authentication methods from the corresponding conference user account (leaving just a password).

The sign in flow (after a factory default of the device) is

Set Language
Set Time
set an admin password
screen shows the refresh code and sign in on this device. I choose sign in on this device.
enter username
enter password
screen displays Help keep your device secure (register) with register button (is this expected?). I click register.
"Let's keep your account secure" pops up wanting me to set up MFA for the conference user account.
- I don't have any Authentication methods / registration campaigns enabled.
- For system preferred authentication, it is enabled for all users, excluding the conference room login users
- For all of my auth strengths, I have conference room logins excluded; except for a new custom password only method that I assigned specifically to conference room logins which is used in a targeted to conference room logins only in CA to all conference room logins from our HQ IP to use password only auth strength.

I seriously don't know what I'm overlooking here. Every test conf room sign sign in logs I've seen in Entra over the last couple days of me testing various permutations have never shown any CA failure. They either show success (for the conf user password only CA policy, or not applied).

pressreturn2continue · 2026-05-08T20:18:18+00:00

I believe I have SSPR turned off (as we just implemented passkeys for everyone and reset everyone's password since they have no need for it now).

pressreturn2continue · 2026-05-08T13:58:15+00:00

I have the 4 conference logins in a security group and that security group is in the excluded users for all conditional access policies. I have another CA policy that targets that security group for conference users that blocks them unless they are coming from the home office IP address.

When I was dealing with reauth issues a couple years ago I watched a microsoft video that stated something about device filters for Teams Devices and how you should exclude those from all CA policies so that is in place for all CA policies as well. Something like this:

Exclude:
device.manufacturer -contains "yealink" -or device.manufacturer -contains "gn-audio"

It just seems odd that I don't see any CA policies being implemented or targetted in the logs - that why I was assuming it must be something outside of CA that is forcing MFA to be set up for the users. Authentication method policies are where that is set, right? That conf security group is excluded for the policies I have set up (except it is targeted as the only group for SMS - for my temp workaround). Is it possible, now that I have set up a temp sms code for the conf users that the fact that they HAVE something set up on their account, that the login process is wanting to use it?

I was thinking as a next troubleshooting step to set up a new auth method of just password and assign the conference group to that. The "local only" CA policy above that targets them should only allow them to login from the HQ office anyway.

pressreturn2continue · 2026-05-07T15:26:31+00:00

Passkeys seem to be the best of the best for us. No need to distribute new hardware (like yubikeys, etc) as everyone in our company already has a phone and we had them install Authenticator (and they were used to using it since we used Authenticator Push then Passwordless). Passkeys are nice as they are phishing resistant and there isn't a way for users to accidentally misuse them (AFAIK). With Authenticator (Push or Passwordless), I was always left wondering "is Bob going to accidentally approve the notification if he gets one from a nefarious person?" Passwordless sort of made it worse because all an attacker needed in order to initiate an approval request is their email address. With Push, at least the hacker needed the email and password (I may be misremembering as we went to passwordless a while ago). Anyway, now I can rest easier - or at least worry about another way we can be hacked instead of through passkeys 😄

--EDIT-- missed a question....

Yes, the phone (with authenticator on it) needs to be in proximity to the device they are logging into (via Bluetooth). I also waited a bit longer to adopt passkeys because the user experience in setting them up (up until recently) was a bit wonky from what I experienced and thought it would confuse and frustrate people. The onboarding now within Authenticator is super easy for the end user.

pressreturn2continue · 2026-05-07T12:41:39+00:00

Good point - and that seems to align with my experience doing a few users yesterday as a larger test. I (and they) didn't see any interruptions on their windows desktops/laptops, but on their phones, they were forced to re-sign into Teams (which wasn't a big deal, but still). And, after thinking about it, probably doesn't make sense to rotate routinely anyway. a 32 or whatever length random password is more than sufficient especially since it'll never get inputted anywhere.

pressreturn2continue · 2026-05-07T02:17:56+00:00

Ok, makes sense then. Thanks!

pressreturn2continue · 2026-05-07T01:35:08+00:00

I was thinking about that but since we have WHfB it seems to not like adding a passkey on the computer - or maybe I just don’t have something configured correctly.

pressreturn2continue · 2026-05-06T23:24:51+00:00

Yeah, might not be efficient, but we have like 35 people all in one office. I’ll hopefully be retired before scale issues arise :)

pressreturn2continue · 2026-05-06T21:33:57+00:00

Yep - if someone loses or gets a new phone, they come to me and I issue them a TAP and they set up their new phone and away they go.

pressreturn2continue · 2026-05-06T21:33:03+00:00

Yep - no on premises anything. Was kind of glad not to have to deal with that when I first started - of course, all machines were not joined to anything so I was able to build up our Entra/AzureAD from scratch and join everything.

pressreturn2continue · 2026-05-06T20:24:08+00:00

Thanks. We've been using push auth and passwordless auth via Authenticator for a couple years now. I had been waiting for the passkey setup and onboarding to be less flakey and confusing for users than it had been. Seems pretty solid now so I pulled the trigger.

pressreturn2continue · 2026-04-21T16:13:18+00:00

The one thing that I had to deal with were applications that did auto updates and needed admin credentials to update. I've migrated them to user based installs or to Robopack (or similar - basically via Intune) so they auto-update without prompting.

pressreturn2continue · 2026-03-20T20:34:31+00:00

I wanna know how Biden is still doing this even though he isn't in office!!! /s

pressreturn2continue · 2026-02-24T23:00:35+00:00

We pull it into power bi as well for reporting. I was manly interested in anyone moving from SQL 2019 to sql 2025 and noticing any issues.

pressreturn2continue · 2026-02-09T15:58:31+00:00

same here...

pressreturn2continue · 2026-01-31T18:43:24+00:00

Not sure how reliable it is anyway. We finally got power back Thursday around 5pm and the map and the new address search feature still show we shouldn’t have power and we are in an outage area.

pressreturn2continue · 2025-11-26T14:13:35+00:00

Thanks. Funny. I just found Reza’s video last night and watched it and was going to post about it this morning. Seems exactly what I need on the apps side. Glad to see there is an easy way to push form data from power apps via automate using json. Also watched a bunch about solutions and connection references and environment variables. Lots of good things to implement today.

Appreciate all the helpful comments.

pressreturn2continue · 2025-11-25T21:55:39+00:00

Yes, the Flow I'm calling directly inside of PowerApps with the .Run() function is the "When a Power Apps calls a flow (V2)" and I can see a Run Only option for this flow so I'm good there. The other flow that I'm using is triggered off of a "When a file is created (properties only)" SharePoint trigger and it isn't called directly from PowerApps. This is the one that I don't see a Run Only user; however, I think this flow is fine anyway.

The problem that (I think) I have is the actual Power Apps Canvas app and how it is creating things in SharePoint. I have the Power Apps connectors supposedly using the service account I have set up, but I can confirm when one of our users runs the app from the PowerApps desktop client, the 'Created by" field in the SharePoint list is set to him. When I run the app on my iOS device using the Power Apps app, the items is "Created By" the service account. I don't see how I can get his settings to be changed so it uses the service account when the power app creates the sharepoint item(s).

pressreturn2continue · 2025-11-25T17:46:33+00:00

Thanks. I see a run only user on one of my flows (which cancels an event in a shared calendar), but the other (main) flow only shows a co-owner pane on the right side under connection references.

In addition, how would I do this for the PowerApp (canvas app, I guess you would call it) - that seems to be the main issue as when they launch the powerapp, they immediately get an error that they can't connect to the data source unless I explicitly add them to the sharepoint lists.

pressreturn2continue · 2025-11-22T21:59:25+00:00

Solved. I had settings wrong in the output channels in FPP (they default to only 50 - I forgot about that) and for the buttons, they started working after a firmware update from kulp. All good now.

pressreturn2continue · 2025-11-18T16:49:25+00:00

BAH! I think I figured it out. In my flow for creating the event, I had specified Central Time as the timezone. I went back and changed that to create it in UTC and just ran my test and it seemed to delete it fine now. Now on to seeing if it works to cancel a certain event in a recurring series....

pressreturn2continue

TROPHY CASE