AzureAD Tenant Restriction Support for Teams Devices

Large organizations that prioritize security want to migrate to cloud services such as Microsoft 365, but they must ensure that their users can only access approved resources. Companies have traditionally restricted access by restricting domain names or IP addresses. This strategy fails in a world where software as a service (SaaS) apps are hosted in the public cloud and use shared domain names such as outlook.office.com and login.microsoftonline.com. Instead of restricting users to approved identities and resources, blocking these addresses would prevent them from accessing Outlook on the web entirely. Tenant restrictions are a feature in Azure Active Directory (Azure AD) that addresses this issue . In this blogpost, we look at how MTR devices can potentially implement this capability.

​Organizations can use tenant restrictions to specify which tenants users on their network can access. Azure AD then only grants access to these permitted tenants; all other tenants, including those in which your users may be guests, are blocked. More information on this can be found in the official MS Docs page: Restrict access to a tenant. 

Essentially, the implementation requires the organization to deploy a web proxy capable of TDL Deep Packet Inspection and HTTP header insertion to insert a header into outgoing https messages. This header is the Restrict-Access-To-Tenants: <permitted tenant list>. To support tenant restrictions, client software must request tokens directly from Azure AD, so that the proxy infrastructure can intercept traffic. Fortunately browser-based Microsoft 365 applications currently support tenant restrictions, as do Office clients that use modern authentication (like OAuth 2.0). But what exactly is TLS Deep Packet Inspection (DPI)? Below is a diagram (courtesy of Palo Alto Networks) that explains the difference between regular Web Proxy and DPI Web Proxy:

As shown in the diagram, as HTTPS data is passed back and forth between a client and a webserver, all of the traffic must first go via the inspection appliance, where it is encrypted and checked for any potentially harmful content. When the inspection is finished, the appliance initiates a new SSL session with the end client so that it can decrypt the content and then re-encrypt it. Another name for this kind of interception is known as the "Man-in-the-Middle Attack" but this term is often used in a negative way. However, the concept is similar for DPI. Since the web proxy pretends to be the actual server that each http request is trying to reach, the proxy needs to be able to issue phony certificates for each and every domain. The proxy does not decrypt a connection that is already established between the client and the server; rather, it creates two distinct connections between itself and the server by acting both as a client toward the server and as a server for the client.

The SSL inspection appliance needs to be able to generate SSL Certificates on the fly so that it can decrypt and re-encrypt the content before sending it back to the end users. This indicates that it requires a CA certificate, which is also sometimes referred to as an intermediate or issuing CA certificate, to be put on it. Overall the flow would look something like the diagram below

So the big question is: can we support this in MTR devices such as Teams Rooms and Teams Phones? In order for the clients to trust the certificates issued by the SSL Inspection Appliance, its Root CA certificate must be installed in the clients' trusted Roots certificate repository. For MTRW devices running Windows10, this is possible. However, there is no way to install the SSL Inspection Appliance's Root CA certificate on Android based devices, at the time of this writing. Hence by default Tenant Restrictions may be implemented for MTR on Windows devices but not on Teams Phones, Displays or Panels which run on the Android OS. On a separate note, ADFS and ADFS Proxy servers that use an internal issued CA certificate cannot be supported on Teams Android devices for the same reason and these servers must always use a certificate issued by a public CA provider.