• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Azure Active Directory / How to Create and Use Azure AD Cross Tenant Access Policies

How to Create and Use Azure AD Cross Tenant Access Policies

April 7, 2022 by Tony Redmond 3 Comments

Table of Contents

  • Fundamental Requirement for Teams Shared Channels
  • Cross-Tenant Access Policies
  • Creating a Cross-Tenant Access Policy
  • Inbound Settings
  • Trust Settings for Cross-Tenant Access Policies
  • Outbound Settings
  • Recommendations

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

1
2
3
4
5
6
7
8
9
10
11
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.

Azure Active Directory, Blog, Teams Azure AD cross-tenant access, Teams Direct Connect, Teams Shared Channels

About 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. Jennifer says

    April 8, 2022 at 8:10 pm

    Great article, thanks!

    Reply
  2. Daniel says

    April 8, 2022 at 9:23 am

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

    Reply
    • Tony Redmond says

      April 8, 2022 at 10:06 am

      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.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland