Before we dive headfirst into the Cross-Tenant Access Settings including the new Tenant Restrictions, let us just quickly review one other area in the Microsoft Entra portal that deals with External collaboration. Based on some recent questions received, I think folks often get these all these concepts jumbled up and confused. Of course, they all deal with external collaboration and access scenarios, but they are each separate and unique controls that do very different things. So, let’s be sure we understand one from the other before we go much further.

In the Microsoft Entra portal, navigate to External Identities > External collaboration settings.

On this page:

• Guest user access: Defines what details guest users can see in your directory.
• Guest invite settings: Defines who can invite guests into your tenant.
• Collaboration restrictions: This setting only applies to invitations into your tenant; here we can restrict invites by DNS domain name only (not by tenant).
  • Note: This toggle cannot rescind existing invitations that were already sent, it only affects invites going forward. And to be absolutely clear, it only applies to invites sent from our tenant to external domains.

Okay, with those concepts behind us, let’s move on.

Cross-Tenant Access Settings:

Navigate to External identities > Cross-tenant access settings. These settings control access (not just invitations) between tenants. For example, we can control B2B collaboration (that is, guest access) and B2B Direct Connect (a.k.a. external access). To understand the difference between these two, let’s start by considering B2B collaboration, first.

B2B Collaboration: This is the “everyday sharing” experience that you are most likely used to already. When you invite someone external into your organization to collaborate on something, there will be a guest account object in your directory that corresponds to that external user. The default for this type of access (both inbound and outbound) is allowed—in other words, by default you can send invitations to and accept invitations from any tenant.

Notice that we can change the defaults for both inbound and outbound access.

• Inbound access: When you allow guests from external tenants into your home tenant.
• Outbound access: When you allow your internal users to become guests in external tenants.

If we were to turn off the Inbound access, that means that external guests will no longer be able to access resources in your tenant. That looks like this:

If we were to disable Outbound access, it means that our own users would be unable to accept invitations to collaborate with outside tenants if and when such invites arrive. That looks like this:

It is important to note that these settings do not prevent invitations from being sent out or received, but when a recipient attempts to accept an invite, this is the message they will see.

Remember: the default B2B collaboration experience (that is, the experience of inviting a guest, or being invited as a guest to collaborate cross-tenant) is wide open: allow all inbound and outbound access. In other words, by default anyone can become a guest in your tenant, and anyone from your tenant can become guests in other tenants.

Now let’s contrast this with B2B direct connect.

B2B Direct Connect: In this scenario, you can invite users into your tenant to collaborate on resources directly. In other words, there is no guest object that merely represents that user, but rather, the external user has “direct” access to resources you share with them in your tenant. This connection requires administrator intervention from each organization: a typical user cannot do this themselves. For example, if you had two partner organizations working very closely with one another for extended periods of time, a direct connect arrangement might simplify things, but it is not supposed to be an “everyday” sharing tool for most organizations. Therefore, the default for this type of connection is blocked (closed).

Block lists vs. Allow lists

You can choose to configure your cross-tenant B2B settings either as a “block list” or as an “allow list.”

Establishing a “Direct Connect” relationship with another organization is kind of a big deal. You will want to have a solid working relationship and a high level of trust between organizations whenever you do this, therefore it is recommended to leave the defaults as-is for B2B Direct Connect. In other words, you will want to block Direct Connect by default, and only open it for specific trusted organizations that you explicitly add and configure on the Organizational Settings tab. We would consider this an “Allow list” because you deny-by-default, and only allow specific connections inbound and outbound.

With regard to B2B collaboration, the exact opposite is true. By default, all guest access is allowed. If you leave this setting in place, you can still choose to build your own “block list” and close inbound or outbound invitations on a per-tenant basis. For example, think about competitors like Coke and Pepsi who might not want to share their proprietary secrets or strategies between one another, but who still want the flexibility to collaborate with other organizations at large. This is what most companies will opt to do.

But you can also choose to close inbound and/or outbound guest access by default. In this case, just like with Direct Connect, you could still open access for specific tenants that you want to collaborate with. An example might be defense contractors who only ever collaborate with specific vendors and departments in government; such an entity may not tolerate their information being shared to any other unauthorized organization. This configuration will be rare, but it will exist in some tenants.

Therefore, whether you choose an open or closed default policy, any of the tenants that you add to the Organizational Settings tab will have their own Inbound and Outbound settings that will override the default configuration. The vast majority of tenants out there will use an Allow list for B2B Direct Connect (and only as needed), and then a Block list (if anything) for B2B collaboration. Very rarely, B2B collaboration might be set up as an Allow list, similar to Direct Connect. But I would not do this unless I had a very clear directive based on business needs. Still with me?

Just one more important note: these settings are all applied at the tenant level. Remember: there could be many other DNS domain names associated with that tenant. Therefore, this is a bit different than just restricting invitations according to domain name, which we can do elsewhere.

Tenant Restrictions

Last of all we will consider Tenant restrictions.

Here is how Microsoft summarizes the differences between Inbound settings, Outbound settings, and Tenant Restrictions (from Microsoft Learn):

Think of the different cross-tenant access settings this way:

• Inbound settings control external account access to your internal apps.
• Outbound settings control internal account access to external apps.
• Tenant restrictions control external account access to external apps.

End quote.

More precisely, the purpose of Tenant restrictions is to prevent users from accessing external applications from your internal network or devices using external accounts. External accounts could include corporate identities issued by other organizations, or, accounts that users may have created from unknown tenants themselves.

The scenarios you would be attempting to prevent here might include a malicious insider who is trying to exfiltrate data by signing into an external account from an internal device, or, an attacker who has copied an access token from a device in an external tenant, and attempts to replay it from a corporate joined device.

Are there other ways to prevent this type of exfiltration or data leakage? Sure, but this is one more tool in our toolbelt to consider.

Although this activity already appears to be “blocked” by default, you cannot enforce these restrictions without completing additional configurations to enable the necessary client-side tagging, e.g., by using Global Secure Access. What that means is, the Global Secure Access service will tag your corporate traffic as it leaves corporate managed devices and networks, so that Microsoft can see that you are not supposed to allow an external identity from those particular devices or networks when accessing external applications. (And no, you cannot enforce this on non-corporate joined devices or external networks outside of your control).

On paper this sounds really good. But again, it means you need to set up the Global Secure Access client on your corporate managed devices and networks. There are some other pretty neat things we can do with Global Secure Access, so we will explore this another day (please note: at the time of this writing, Global Secure Access is still in preview, and I’ve already run into a couple of hiccups with it—so I am following these developments until we reach General Availability).

I will have more to say about Global Secure Access soon. For now, you can read more about the Tenant Restrictions configuration at: https://aka.ms/tenant-restrictions-enforcement

Stay tuned!