top of page
Search

Teams AOSP Migration - Device Filters

  • Writer: Mark Webb
    Mark Webb
  • Jul 28
  • 4 min read

While testing migration for Teams Android devices from the "legacy" Device Administrator enrolment profile in Intune to the new AOSP management I wanted to understand the device enrolment process into Entra and Intune in a bit more detail. Mainly due to how the enrolment would interact with Conditional Access since more and more authentication workflows will be impacted by these policies as security teams tighten who and what can access company resources.


Intune Profiles


I'm going to assume anyone reading this is aware of the migration to the new AOSP management of Teams Android devices and has taken steps to prepare their environment. If not, do it now! Unless of course you don't enrol your Teams devices into Intune, in which case you can ignore all of this...I'd recommend doing it though, it gives you better visibility of the devices and means you can report on compliance and add some basic Configuratin Profiles to manage some device settings.


Microsoft are actively moving devices onto the AOSP platform and if you haven't setup your tenant to allow the devices to migrate they will sign out and you'll have to take manual action to get them back online. Details here: https://learn.microsoft.com/en-us/microsoftteams/rooms/android-migration-guide


Initial Device Sign In


When a user (or Common Area Phone account) initially signs in using the code on the screen of a device, the device is registered to Entra before it hits Intune and enrols there. We can see this in the Entra device audit logs as the initial entry shows a very basic set of device information.


screenshot from Entra showing Teams device being added

The audit logs also show this initial activity with the details of what device attributes are added to Entra.

screenshot showing device audit logs of device being added to Entra and being registered to the user

The "Add device" entry has this set of properties added

Entra audit log entry showing the device properties being added

Now, the "issue" we have here is that if you've got any Conditional Access policies which are targetting "All Resources" or any policy which includes "Microsoft Teams Services" as a resource then this authentication flow is going to be captured in that.


If any of those policies then check for things like device compliance or apply any other validation before granting access we need to be able to filter these devices out potentially otherwise the sign in flow will fail at this first stage.


For example, I've setup a Conditional Access policy which applies to All Users and All Resource which requires the device to be compliant.


Without adding any filters in, the sign in to Teams will fail


Entra conditional access detail showing device failing policy due to non compliance

The problem is that because the device hasn't enrolled into Intune yet, no compliance information exists (even if that would result in a Grace state condition) and therefore Entra will block the sign in.


Bit of a chicken and egg scenario going on. So we need some way to filter these devices out of this policy initially so they can sign in and begin their Intune enrolment.


Device Filters


The way we can do this is to use device filters in the Conditional Access policy to exclude them. Normally for a device that already exists in Entra/Intune we'd use something specific like the Manufacturer name or Model name/number to target the specific devices we want but as we can see from the audit log entry above, we get none of that with this initial sign in. All we have is very basic device info.


All that we have that is unique to this device is the display name which in this case is PolyCCX500. Without anything else that's unique, we'll have to use that for our filter.


So we update our device filters in our Conditional Access policy to add an "And" statement to include devices that aren't equal to PolyCCX500. We use an "And" because our policy is a Block one so we're including devices which aren't compliant to then apply a Block. So our updated filter rule looks like this


screenshot from Entra showing how to add a device filter based on a devices display name

Now we've added that, if we try signing in again.....I get a failure still!


conditional access policy log showing device failing policy still due to non compliance

The device it references looks ok and has the display name we've filtered out

Entra sign in log details showing device properties

but obviously something is still not right.


To figure out what was going on and could be causing this, I excluded a specific account from this policy to see what happens in Entra/Intune if we're not checking for compliance.


And what we can see is that after the device has been added to Entra (the first sign in we referenced above and had the display name PolyCCX500), once it has passed this it then proceeds to enrol into Intune. As part of that registration, Intune then updates a number of attributes of the device, including the display name of the device. Again, we can see this in the Audit Logs in Entra.


Entra audit log entry showing Intune updating device properties

The key update is the top one, where Intune updates the device attributes


Entra audit log entry showing the device display name being updated

Intune updates the display name from the initial PolyCCX500 to whatever either your AOSP Enrolment Profile naming convention is (if you set one in the enrolment profile) or if not it'll set it to the default Intune name of username_aosp_date/time or something along those lines. Basically the display name is now different to our Conditional Access filter condition so it seems to be failing again.


So we need a second filter to take care of this....<sigh>


Now we could use the OS Type to filter as that's been updated from Android to AndroidAOSP but that's not particularly specific if you have multiple devices enrolled using this OS Type. But use that if it suits your needs and you're happy with it.


To make it more specific, we can use the Enrolment Profile name filter in the Conditional Access policy though. This you get from viewing the AOSP enrolment profile you have setup in Intune and adding that name into the device filter. Doing that means our update policy filter now looks like this (replace the value of the enrolment profile name with whatever your one is) called:


conditional access log entry showing how to add a second filter condition to filter by enrolment profile name

Now when we sign in, we don't get any sign in errors and we can see that our conditional access policy is successfully excluding the device.


conditional access log detail showing policy now not being applied after filters added

We also see the right order of events in Entra, with the device being added and then updated by Intune.



Entra audit logs showing device being added and updated succesfully

Conclusion


If you're working in an organisation that applies a number of Conditional Access policies that check for device properties then you may need to look at this to help include or exclude Teams devices depending on your setup.


It's also quite useful to understand the sign in flow and how the devices onboard to Entra and Intune for documentation and having an understanding of how the devices are presented across the environment.

 
 
 

Comments


Post: Blog2_Post

Subscribe Form

Thanks for submitting!

  • Twitter

©2023 by Webbys Teams Blog. Proudly created with Wix.com

bottom of page