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.
Essentially, the implementation requires the organization to deploy a web proxy capable of TLS 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:
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