How to Create and Use Azure AD Cross Tenant Access Policies

Fundamental Requirement for Teams Shared Channels

On March 16, Microsoft launched Teams shared channels into public preview. The introduction of a new mechanism for trans-organization collaboration (Azure B2B Direct Connect) often comes with its own administrative challenges. In this case, it’s the need to establish Azure cross tenant access policies, which must be in place before Teams shared channels can work.

The basis of Azure B2B Direct Connect is that apps respect the credentials gained by users when they authentication against their home tenant. Azure B2B Collaboration takes a different approach and uses guest accounts created and managed in the tenant hosting a resource. Teams shared channels don’t support guest accounts. Everyone who is a member of a shared channel becomes a member through their home tenant account.

Cross-Tenant Access Policies

Launched in preview in February 2022, Azure AD cross-tenant access policies are still very new. In essential, these policies define how a tenant manages inbound and outbound access with external tenants. By default, a single tenant access policy exists in Azure AD. The policy covers both Azure AD B2B Collaboration and B2B Direct Connect. I cover the latter here and will return to the topic of using the settings to control Azure B2B Collaboration in the future. For now, it’s sufficient to say that the default settings for Azure B2B Collaboration allow guest accounts to work as they have done up to now.

In the case of Azure B2B Direct Connect, the default policy disables inbound and outbound connections, meaning that Teams shared channels are limited to internal members. If you want to allow shared channels to support external members, the first item of business is to enable cross-tenant sharing.

You can adopt two sharing models:

• Open access: This means that you’re willing to allow users from all other Microsoft 365 tenants to connect (inbound) to your tenant to access all supported apps (Teams shared channels and SharePoint Online are the big two today). On the outbound side, you’re willing to allow tenant users to connect to resources in other tenants using their credentials. In effect, you’re allowing users to become members in shared channels hosted in other tenants. You could also call this model open federation with other Teams tenants.
• Per-tenant: This model requires the creation of a separate policy per tenant. For instance, to allow users to become members in shared channels hosted by the Practical365.com tenant, you must create a tenant-specific access policy for Practical365.com. If you then want to collaborate with Quest.com, you must create a policy for that domain, and so on. In fact, because you can’t configure a policy to apply to multiple named tenants, a per-tenant access policy is needed each time you want to deviate from the default policy settings. Note that if you limit sharing to specific groups and users from another tenant, you need Azure AD Premium licenses.

Open access is configured by updating the settings in the default policy for cross-tenant access. Per-tenant access requires the creation of separate policies. Both types of access can operate within a tenant. For instance, you might have a default policy which blocks access to all tenants and a separate policy created for Practical365.com. A specific policy for a tenant always takes precedence over the default policy, meaning that Practical365.com users can collaborate in your tenant while users from other tenants cannot.

Remember that you only control one side of the equation. The other tenant you wish to collaborate with must be willing to allow your users to join shared channels in their tenant or allow their users to join shared channels hosted in your tenant. If the other tenant doesn’t have a cross-tenant access policy in place which covers your tenant (open or per-tenant), collaboration comes to a crashing halt. In addition, if the administrators of another tenant decide that they’re only willing to accept connections from specific users or groups, that’s what happens. Negotiation is a good skill to have when setting up the two sides of a cross-tenant access policy.

Another thing to remember is that cross-tenant access settings are an Azure AD mechanism. Teams uses this capability for federated access to shared channels, so the federation settings for external access set in the Teams admin center must include the organizations you want to share channels with. If they don’t, you won’t be able to share channels with users from those organizations.

Creating a Cross-Tenant Access Policy

Let’s assume that you want to start slowly with Teams shared channels and have therefore decided to keep the Azure B2B Direct Connect settings in the default cross-tenant access policy blocked for all tenants. However, you want to test shared channels with a specific partner. To do this, a per-tenant access policy is needed.

Before starting, make sure that you know the tenant identifier (GUID) or primary domain name of the tenant you want to connect with. Azure AD asks for this information when it creates the tenant-specific policy. It’s easy to find your own tenant identifier; to find the identifier for another tenant, you can ask the tenant administrator (after all, you’re asking them to set up their side of the connector) or use this website.

Go to the External Identities section of the Azure AD admin center and select Cross-tenant access settings. Now select Add organization and input the tenant identifier or any of the domain names registered for the tenant. In Figure 1, I input Quest.com, and Azure AD resolved the domain to confirm that it is a valid tenant.

Click Add to continue. Azure AD duplicates the settings from the default tenant cross-access policy to create the tenant-specific policy. At this point, not much has changed. A new policy exists, but its settings are the same as the default. In addition, our counterpart at Quest.com hasn’t create a policy for our tenant.

Inbound Settings

We plan to have some Quest.com users participate in a shared channel in our tenant. To make this possible, we must edit the inbound settings. As you can see in Figure 3, we’ve elected to allow all external users from Quest.com to access our tenant. If necessary, you can restrict access to specific users or groups from the other tenant. That is, if you know the Azure AD object identifiers for those users and groups. Again, this is an area where you need to work with the administrator of the other tenant to obtain the object identifiers of users or groups for whom you want to allow access.

Messing around with object identifiers (like 11c43ee8-b9d3-4e51-b73f-bd9dda66e30c) for individual users is a pain. If restricted access is necessary, it’s more convenient if you agree that each tenant maintains an Azure AD group holding the accounts of those allowed to collaborate. That way, each tenant is in full control of the people from their organization who can use direct connect, and there’s only a single group identifier to configure in the policy.

Trust Settings for Cross-Tenant Access Policies

So far, we’ve focused on what users from an external tenant can connect. Trust settings allow control over how external users connect. Three settings are available for conditional access policies running in your tenant to evaluate user connections. The settings control if the CA policies trust claims made by the external users’ home organization:

• Trust MFA from their home tenant. You must configure the policy to allow conditional access to accept MFA claims from users’ home organization. Note that if your tenant enforces MFA and the external tenant does not, users from that tenant must authenticate using MFA to access your resources.
• Trust compliant devices.
• Trust hybrid Azure AD joined devices.

Outbound Settings

Outbound settings control how users from your tenant can access information in the other tenant. As with the inbound settings, they start off with values inherited from the default cross-tenant access policy.

The basic change you’ll want to make is to decide who is allowed to collaborate outbound. As before, you can allow everyone in the tenant or restrict it to a select few. It’s easier to manage the selected set for outbound access because you don’t need to mess with object identifiers. Instead, I recommend that you create a security group, add the people to have access to that group, and then add the group to the tenant access policy (Figure 4).

Over time, you might accumulate a set of security groups to control collaborative access to external tenants. With this point in mind, it’s important to assign consistent names to each group so that they are easily found.

An advantage of controlling access in this way is that when the time comes for the administrator of an external tenant to interact with you about who should have access, you’ll have an easy answer. Remember, you’ll need to give the external administrator the object identifier of the group. Here’s how to find the object identifier with the Get-MgGroup and Get-AzureADGroup cmdlets.

Get-MgGroup -filter "displayName eq 'Teams Shared Channels with Quest'" | ft id, displayname

Id                                   DisplayName
--                                   -----------
b8ee9d9c-2024-4fb5-ae56-df423febac81 Teams Shared Channels with Quest

Get-AzureADGroup -SearchString "Teams Shared Channels" | ft objectid, DisplayName

ObjectId                             DisplayName
--------                             -----------
b8ee9d9c-2024-4fb5-ae56-df423febac81 Teams Shared Channels with Quest

Recommendations

We’re in the early days of cross-tenant access policies and Teams shared channels. Like anything else, it’s a good idea to avoid over-complicating matters initially. In other words, learn to walk before you run. Here’s the recipe for success:

• Use per-tenant access policies initially until you are happy that you know how to manage Teams shared channels and the organization is happy with issues like compliance, access to confidential information, and so on.
• Use a development tenant to test changes to cross-tenant access policies, especially those that affect conditional access policies.
• Check conditional access policies which target guest access to make sure that they work with inbound direct connections from other tenants.
• Remember that to “configure trust settings or apply access settings to specific users, groups, or applications, you’ll need an Azure AD Premium P1 license.” (see this page). This shouldn’t be an issue for most administrators.
• Cross-tenant access policies are a co-operative effort requiring input from administrators on both sides of the connection. Prepare your side and be ready to work with your counterpart.

Life isn’t perfect and problems will occur. That’s why the most important piece of advice is to keep cross-tenant access policies as simple as possible for as long as possible. There’s no point in creating a potential troubleshooting challenge unless you really must.