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.

Adding a cross-tenant access policy for a Microsoft 365 tenant
Figure 1: Adding a cross-tenant access policy for a Microsoft 365 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.

The new cross-tenant access policy is available
Figure 2: The new cross-tenant access policy is available

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.

Editing the inbound settings for B2B Connect in a cross-tenant access policy

Azure cross tenant access
Figure 3: Editing the inbound settings for B2B Connect in a cross-tenant access policy

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).

Defining a group for outbound collaboration with a tenant
Figure 4: Defining a group for outbound collaboration with a tenant

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Charlie Henderson

    Hi Tony,

    With the Cross-Tenant access and B2B Direct, would it be possible to look up the users from each tenant in your “own” address book. Right now we are a company that are collaborating with another one, but we are not getting to get merged anytime soon. There has simply been a request to be able to look up each other within the address book. I do know we can share our calendars with the federation sharing settings, which already are in place, but since we are very new to each other, it would be easier to open the address book and search for name, department, title etc.

    Will B2B Direct sync all users if inbound and outbound allows that?

    1. Avatar photo
      Tony Redmond

      No. Azure Direct Connect is an authentication mechanism not a directory synchronization tool. If you want to share GAL information with another organization, you’ll need a tool like GALsync https://www.galsync.com/. I’m not recommending GALsync as you need to test any tool to make sure that it is a good fit. It’s just an example of what’s available in the market.

  2. Jennifer

    Great article, thanks!

  3. Daniel

    Hy Tony,

    Thanks for your amazing explanation over this new expected feature.

    Did you know what happens with previously created guests users when you enable direct federation for their domain?

    Like until today we have a lot of guests from contoso.com consuming resources at frabikan.com.

    Now fabrikan and contoso established direct federation trusting each other.

    What happens with previously guest created from collaboration days? Theres some “convertion”, should we remove that guest and re-create sharing connections like documents again.?

    1. Avatar photo
      Tony Redmond

      Existing guests remain in place. You’d need to clean them up if you want to remove them. But remember, guest accounts are still used extensively and are very useful. I would not be in a hurry to try and convert.

Leave a Reply