Teams Phones Conditional Access Configuration

Overview

This guide will go over the primary steps of configuring your Azure, Intune and Teams Environment set up to apply conditional access policies to your Teams devices. 

It is important to note that every campus will likely have different requirements depending on their specific security policy. This guide will set the foundation but you will likely need to adjust one or more conditional access policies to tailor the exact configuration for your environment.

It is also important to note that these actions should take place before phones are connected to your LAN. Devices that have been previously connected may need to be factory reset to re-enroll and acquire the proper status, this is particularly relevant to the Intune portion.

Contents

Azure Dynamic Group

Intune AOSP Device Policy

Conditional Access Considerations and Example

 

Azure Dynamic Group

The first item we will cover is setting up a dynamic group in Azure Entra ID. This will automatically collect any Audiocodes devices that log into your Azure tenant. It can be used as any other group whether that be for Conditional Access policies, license assignment, update deployments, etc.

In Azure, enter Entra ID, if you are unfamiliar with access, you can search for it across the top search field and it will populate in the results

On the left hand pane, expand "Manage", then select "Groups"

On the groups page, select, "New Group"

On the New Group setup page set the following:

• Group Type: Security
• Group Name: Put in whatever fits your organization best (e.g., Audiocodes_Devices_Dynamic)
• Group Description: Optional, but it can be useful if your naming convention does not explain the group members
• Entra roles can be assigned: Leave this off
• Membership Type: Select "Dynamic Device"
• Add Dynamic Query: See note below
• Owners: Add at least one person here that will be able to adjust settings on the group

For the dynamic query there are three main things we want to be included

• The device OS:  device.deviceOSType -eq "Android"
• The device Manufacturer: device.deviceManufacturer -eq "Audiocodes"
• The device Models: device.deviceModel -eq "XXXX"

We use the "-and" and  "-or" operators to complete the query. You can add as many devices as are needed for your organization to cover the devices you have. Below is an example of a query that will automatically join multiple models of Audiocodes devices. The below requires the OS to be Android and from there will also include any devices with Audiocodes listed as the manufacturer or any of the specific models listed.

Once you've entered your dynamic query, if you already have some devices logged in, you can test against them with the Validate Rules, tab along the top. once you are satisfied, click on save to return to the main group creation page, then click "Create" to establish the group.

After a short period, if you have devices connected, you should see the group begin to populate.

 

Intune AOSP Device Policy

The Intune AOSP device policy is the magic that enables easier configuration of Conditional Access by getting a device into a "Compliant" state to grant access and avoid repeated sign-outs or holds for MFA prompts on the desktop phones. While Intune is not a requirement to run Teams phones, getting conditional access policies to work as expected without out it can be extremely frustrating.

There are two actions required, first we will create an enrollment profile that will enable Intune to manage the Android Teams Devices, then we will set up a compliance policy for them.

Creating the Enrollment Profile

To start enter the Intune admin center and select "Devices" on the left pane, then on the right pane, drill down into "Android"

Under "Android", select "Enrollment"

Scroll down to "Android Open Source Project (AOSP), then select "Corporate-owned, user-associated devices". We will use this even for devices that will be shared as those are still logging in with an "admin user" account.

Click on "Create Policy"

There are only two things we are required here. First, provide a name for your policy (e.g., "AOSP - Teams Devices"). Optionally, you can include a description if your naming convention can cause confusion. The second required item is setting "For Microsoft Teams devices" to "Enabled". Then at the bottom select, "Next", "Next", Complete. 

You should now see you new policy under the enrollment settings, as you add devices, you will see the enrolled devices count tick up. Note however any existing devices must first be removed from Intune before they will re-enrol. It is also recommended to factory reset the device itself to clear out any previous local configuration it may have saved.

Creating the Compliance Policy

Now that we have an enrollment profile that lets intune mange the devices we will create a compliance policy that allows devices to receive a "Compliant" check for conditional access usage. 

From the main Intune admin center page, select "Devices" on the left pane, then select "Compliance" on the right pane

From here, select "Create Policy", a additional pane will pop up on the right. On this pane, select "Android (AOSP)" as the platform, then click "Create"

This will load a new page with sections. 

Under "Basics" set your prefered name for the policy and add a description as desired, then select "Next"

Compliance Settings is the main area of concern. You may adjust to your needs. The minimum recommended settings are:

• Device Health-> Rooted Devices -> Block
• Encryption-> Require Encryption->Yes

Once these are set, select "Next" at the bottom

Actions for noncompliance are again able to be adjusted to your needed. The minimum recommended setting is to leave the default "Mark device noncompliant" set to immediately (0 is immediate). Once finished, select "Next" at the bottom

Scope tags are optional if you use them, if not in use simply click "Next" at the bottom to get to the "Assignments" tab. Here we will use the dynamic group we created earlier in Entra. Once selected as included, click "Next" at the bottom, then "Create" on the final review Tab.

Once created you should see your new policy under the Devices->Compliance policy list. This policy will now apply to all the devices detected by your dynamic group and as long as they comply with the settings you selected will get marked as "Compliant" for purposes of Conditional Access

 

Conditional Access Setup and Example

Conditional Access is what sets the security access for both your users and your devices. One common usage is prompting for MFA across Microsoft Services. 

For those new to Conditional Access, it is highly recommended to read thru the Microsoft Learn documentation that goes into greater depth on it's overall usage. Additionally, Microsoft has specific guidance and suggestions related to Teams Room and Shared Devices.

In this section we will review some factors to consider when incorporating Microsoft Teams devices into those policies. Keep in mind there is no one size fits all for Conditional Access. Each campus will ultimately need to create and adjust policies to fit their specific needs. 

Recommendations / Considerations

• Exclude your devices and resource accounts from your existing policies and create individual polices for each. While user sign-ins to both rooms and devices are evaluated separately by conditional access, having devices and resource accounts separate will give you increased flexibility to tailor to your needs.  
   
• Create a group (or groups if wanting to set seperate polices) of users who will be provided phones. This will enable you to more tightly control access to services.
   
• Resource accounts used for Teams Rooms will not support MFA interactively. This is commonly missed and it's never fun for your technicians doing the initial setup who unexpectedly find themselves getting looped on the sign-in due to this. 
   
• Having devices using Intune to establish compliance will help you avoid headaches. This will apply both to your users not getting kicked out/ prompted to reauthenticate to their desk phones but also enables Teams Rooms a method to bypass the traditional MFA methods.
   
• There are four services (resources) that are interacted with when using a Teams device (phone or room), that conditional access will act upon. You will want to be sure all of these are included in the scope of any policy that will apply to interaction with the devices. These are:
  • Office365
  • Microsoft Teams Services
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
     
• Devices and Users are not evaluated by the same policy (in practice). Microsoft says this is no longer a limitation but any attempt I have made to consolidate users and devices into the same policy has lead to unexpected results in the Conditional Access evaluations.
   
• After they are initially created, run your policies in Test Mode first. Attempt to log into some devices in relation to how the particular policy is configured. While you will not be able to actually log with the access policy when in test mode, you will be able to see what is attempting to evaluate against your created policy and can confirm the correct items are attempting to use it.  More importantly, you will be able to see what other items are attempting to use it that were not expected so you can go back to adjust to allow/prevent as needed. This should be done before devices are handed to users to avoid any issues. 
   
• If you are new to conditional access completely. Before turning any policy on it is recommended that at minimum your test users have MFA set up via Microsoft on their accounts. Long term you will want all Teams Devices users to have MFA enabled before deploying a policy to them. 
   
• Always apply new policies to a subset of users (and if already deployed subsets of devices as well) rather than blanket "All" users/groups and test the policy is working as expected. This is particularly important if you have not previously used conditional access. At worst, you could potentially block all you users from access with a mis-configured policy. The alternative is also true, you may allow everyone in inadvertently to all services. More commonly you may introduce unexpected MFA prompts or disconnects.
   
• If you have current MFA polices for user access set up in conditional access, for your particular setup you may need to adjust the existing policy to prevent MFA prompting on Teams devices. In an ideal scenario you are excluding evaluation from those devices from your main MFA policies and setting up a user policy for evaluating Teams Phone login separately, but this may not be possible with all configurations.
  
   

Policy Examples

Policies are created under "Conditional Access" you can find this in Azure by using the search bar at the top. The full name is "Microsoft Entra Conditional Access" but a search for "conditional" or "access" is usually sufficient for it to appear as a top result.

Example - Exculding MFA on user logins for Teams Devices

For this example we'll start with a new policy, but it is probable if you are already using conditional access you have an existing policy or policies that would need to be adjusted, not newly created.

On the conditional access main page, select "New Policy"

First give it a name, in this case we'll use "Example - Excluding Users Logins on Devices"

Next under "Assignments" we will select who the polcy applies to (keep in mind you want seperate policies for any user groups and any device based groups). In this senario, we'll just go with "All User" for simplicity but it is unlikely you would create any policy with just this setting. In most cases you'd at least want to include an exclusion group that contains at least one or more "break glass" accounts, particularly during intial configuration. 

Next under "Target Resources" for this example, we'll again just select "All Resources" with no exclusions as it isn't particularly relevant to what we want to show in this example. In practice this is rare, in most cases you are targeting specific resourses such as "office 365" for either inclusion or exclusion. Even when doing blanket MFA across your platform, best practice is to still break out indivdual resources that may require specific settings regarding their access that differ from your baseline. As noted prior, you will most likely be adjusting an existing policy to cover excluding Teams Devce User logins, not starting from scratch. 

Under "Network" we'll skip configuration for this example. Often you are setting to this to "Any network or location" when dealing with users. To note though, if you were setting different polices based on something like differnet subnets this is where you would limit it to specifc networks. Creating named Networks in Azure for use in Conditional Access is beyond the scope of this particular guide but it is something you may want to consider if for example you wanted people to always have to MFA on phones in a public location, but not within user offices. 

The next section, "Conditions" has wide ranging usage related to what access requests will be evaluated by the policy, related to Teams Devices, the two primary areas to take note of are "Device Platforms" and "Filter for Devices". In this senario since we are doing a exclusion we'll be skipping the "Device Platforms" but if we were doing a specific policy just for Teams Devices, we could reduce potential exposure by using the "Android" setting as, to my knowlege, they are all based on that platform.  In this example we will be focusing on "Filter for Devices". We will be using a combination of the device.manufacturer and the device.model properties to set our exclusion. In the example you'll see we are excluding any devices with AudioCodes as the manufacturer along with the C455HD and C450HD models.

Access controls is where we set various additional requirements to allow access, at least one is required to create a policy (or alternatively one "Session" selection). In this example as it is our theoretical "All user MFA policy" we want to require multifactor authentication as that is the expectation for our fictional users to take, except when using the Teams Devices as our exclusions have established. In our example we are going to use "Require multifactor authentication" however the newer "Require Authentication strength" would also be a suitable choice here. Note that Azure may give you a warning if the policy will impact the account you are using to set up the policy.

Session is not required here, but to meet the 'essence' of the policy we're creating we'll set a fourteen day frequency (i.e. users will need to re-mfa every 14 days for this policy). 

We have now set up our policy, so we would click the "Crate" button to put it into play. In a real-world scenario for a new policy we would want to be sure we we first create using "report-only", verify it is doing what we expect and then later go back to turn the policy to "on" state.  For adjusting an existing policy, we would want to be sure we are excluding at least one account that has the ability to change the policy to ensure we have the ability to go back and make any corrections should it inadvertently block accounts unexpectedly.

 

Example - Policy for Users On Teams Devices

For this example, rather than going through each option as in the previous example we will only highlight the items that need configuration.

Users - While you can use "all users" the recommendation is to put all users who will be logging into a Teams device into a group and use that group for who should be included

Target Resources - We are going to include the 4 related Teams Device services (Microsoft Teams Services, Office 365, Office 365 Exchange Online, Office 365 SharePoint Online)

Conditions - We are going to include anything with the manufacturer "Audiocodes" and any of the models we have in use in our environment

Access Controls -> Grant - We are going to use the device compliance we set up with our earlier Intune configuration as the method of granting access

And with that we would create the policy. As configured this will only apply to users in the selected groups, when attempting to access the selected resources on the devices we are including to filter. It will grant access as long as the device is reporting as compliant. 

For a device specific policy, it would be created the same as this policy, but under the "Users" section, rather than user groups, we would use the dynamic device groups we created earlier in this guide that includes all the devices.