Upgrade your tenant restrictions to v2

In a previous blog in the Data Exfiltration series, we discussed different types of tenant restrictions policy. In this blog, we’ll discuss migrating from tenant restrictions v1 to authentication plane tenant restrictions v2. In future blogs, we’ll discuss migrating to Universal tenant restrictions v2.  

Tenant restrictions are a vital tool to help prevent data exfiltration from unauthorized access to external Microsoft Entra ID tenants and consumer Microsoft accounts. Tenant restrictions v1 lets you create an allow list of tenant IDs and Microsoft sign-in endpoints to ensure that users access external tenants that your organization authorizes. While tenant restrictions v1 served well for many years, tenant restrictions v2 offers more granularity and easier policy management with no additional licensing requirements. 

Tenant restrictions v2 has several benefits over tenant restrictions v1. For example, admins can: 

• Update the policy from the Microsoft Entra portal rather than from each network proxy. There’s no need to update the header. 
• Increase the size limitations of your maximum proxy header length. There’s no limit to the number of partners you can add with tenant restrictions v2. 
• Selectively indicate which user groups access which apps in external tenants rather than allowing entire tenants for all identities. 

In this blog post, I’ll explain the differences between how the two tenant restriction types work independently from, and in tandem with, cross-tenant access settings (outbound) to highlight the benefits of upgrading to tenant restrictions v2.  

Getting started with tenant restrictions 

Tenant restrictions require routing all user authentication traffic through a proxy. Typically, the proxy is the on-premises network egress, but it can also be a cloud-based proxy. The proxy injects a header indicating that an allow list of destinations is enforced on the traffic, regardless of the originating device or network location. In tenant restrictions v1, the destination allow list is in the header. In tenant restrictions v2, the header has a tenant ID and policy ID. Traffic arrives at Microsoft Entra ID, which reads the header and enforces the policy. If the traffic destination isn’t in the allow list, the user receives an error message.  

Figure 1: Example of a user getting blocked by tenant restrictions

How tenant restrictions v1 works 

There are two types of identities: internal and external. Your organization creates and manages internal identities with your identity provider (IdP) but doesn’t manage external identities such as personal accounts or those created by an external organization. Tenant restrictions v1 applies to both account types. 

In the following diagrams, two types of identities (green is internal and black is external) are on the corporate network or connected with a virtual private network (VPN). Both identity types go through the corporate network egress proxy when attempting to access Microsoft 365 services. Typically, both receive the same header injection of allowed destinations. This enforcement has some limitations. If you maintain the allow list in the network proxies, administrators update the header at each proxy when you add or remove a tenant. It’s also important to note that the headers have size limitations. 

Figure 2: Tenant restrictions v1 applies to external tenant destinations equally with no user or app granularity

You can improve tenant restrictions v1 by adding cross-tenant access settings. 

Tenant restrictions v1 with outbound cross-tenant access settings 

In Microsoft Entra ID, you can configure the cross-tenant access settings feature to control outbound access on a per-user, per-group, and per-application basis. This policy applies to your internal identities, regardless of device or network location.  

In the following diagram, the users go through the egress proxy. Cross-tenant access settings and tenant restrictions are applied. However, the tenant restrictions v1 allow list is the only policy that applies to external identities. This option improves internal user management, but the architecture has limitations.  

Both tenant restriction v1 and cross-tenant access settings are evaluated, and the most restrictive policy is applied. However, cross-tenant access settings only apply to internal identities. If you allow access to an external tenant for your users, even with group or application restrictions, you enable all external identities to access any resource in those tenants. 

Figure 3: Cross-tenant access settings adds user and app granularity for internal identities

Tenant restriction v2 with cross-tenant access settings 

Tenant restriction v2 works in tandem with cross-tenant access settings. Tenant restriction v2 is a cloud-based policy that applies to external identities. Internal users’ access is controlled by cross-tenant access settings. This separation allows per-user and per-application granularity for internal and external identity scenarios. 

In the following example, the organization puts group and application restrictions on their internal identities. However, they can block other external identities from accessing external tenants unless they create exceptions. In this case, an exception is made for Bob from Tenant C. He is allowed access to only Microsoft Exchange so he can check email while on the corporate network. 

Figure 4: Tenant restrictions v2 adds granular user and app awareness to external identities

The previous diagram demonstrates the flexibility that tenant restrictions v2 offers. Because tenant restrictions v1 and v2 have the same licensing requirements, the one-time migration involves recreating policies and updating the header injection at your network proxies.  

You can learn more in the tenant restrictions v2 migration deployment plan.  

To further enhance tenant restrictions, learn about Universal tenant restrictions. This feature adds data layer protection and prevents token infiltration that can bypass your corporate network proxy’s tenant restrictions header injection. The feature injects the headers and has a low latency connection to Microsoft 365 resources without needing to hairpin traffic through your corpnet proxies. 

Jeff Bley

Senior Product Manager, Microsoft

LinkedIn

Learn more about Microsoft Entra: 

• Related Articles: ​ 
  • Learn more at Configure Tenant Restrictions v2 
• See recent Microsoft Entra blogs 
• Dive into Microsoft Entra technical documentation 
• Learn more at Azure Active Directory (Azure AD) rename to Microsoft Entra ID 
• Join the conversation on the Microsoft Entra discussion space 
• Learn more about Microsoft Security