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.
Hi Tony,
Thanks for the all the details.
I have a question regarding to pre-tenant access that may need your suggestion. Can I allow the access from another specific tenant but restrict the access to read-only? The restriction must be applied on tenant level and could not be overridden by any per-user settings. Thanks.
No. Access policies allow access. They don’t distinguish between types of access. If you want to restrict access to specific information, use sensitivity labels.
Hello Tony,
I have a strange issue and I ask you for your help. I opened a case with Microsoft, but it stucked. So I ask you if you have ever faced this:
User Alex Wilber of tenantA.onmicrosoft.com created a shared channel and invited two users of tenantB.onmicrosoft.com: AdeleV_tenantB.onmicrosoft.com and DiegoS_tenantB.onmicrosoft.com
The two users can see the Shared Channel in MS Teams, but AdeleV is able to click the link “review permission”, it opened a consent window she can accept and everything works fine. DiegoS clicked the link “review permission” but nothing happens. He can post messages, but is unable to open the file tab.
Does anybody have an idea? I’m getting crazy.
Thanks a lot.
I would file a support incident with Microsoft. I can’t debug your situation without access to the data… but Microsoft support can.
Hello,
i don´t know if this is what i really need. In my scenario i have Tenant A with B2C and Tenant B with normal AAD. I need enable to all users from Tenant B sign in to my application in Tenant A B2C. For now i do it with IDP and it works fine but not so clear. When i tried B2B direct connect i can connect but user not create in Tenant A B2C tenant but maybe i set something bad. Is there any way or IDP is best way?
Thank you for help
If you have a working solution today, why change?
In any case, without knowing details of the app, conceptually you need an inbound policy for A that allows users from B to execute an app (or all apps) and an outbound policy on B that allows users to run the app on A (or all apps). Is that what you have?
You could always file a support incident with Microsoft and ask them to check. They can see your data and setup. I can’t, so any advice is based on what I think is happening rather than what I know is happening.
Thank you for your response. Yea it’s working for now but i don’t know if it’s perfect. Yes, exactly. I need enable users from B sign in to A without invite email. I need create user on sign in to tenant A. And i don’t know if IDP is best solution or i can use B2B direct way. Yean you have right i can. Thank you
Hi also I tried to use the B2B direct feature to allow users of tenant B to sign in into our OIDC based application that is registered on a single-tenant A. I created B2B direct allow rules for both inbound and outbound between the two tenants for all users and all applications.
Nevertheless I get the error message
“Selected user account does not exist in tenant ‘…’ and cannot access the application ‘…’ in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account”
when trying to login with an Account from B.
It seems the OIDC endpoint that is provided by the AAD tenant does not respect the configured direct policy at all only the collaboration policy (if I disable B2B collaboration between the tenants I get the message that login is blocked for that organization)
Did anybody get the B2B direct auth flow working with an app that is using OIDC?
Hello,
I have configured the Azure AD Cross tenant policy, but the users in the partner tenant don’t receive the invitation.
I must created the account before as guest ?
If you want the partner accounts to access a shared channel, they must be invited to the channel.
If you want the partner accounts to have guest access to Teams, Groups, or Sites, then they must be invited to become guest members in those containers.
So if i understand even if I configure the organization settings under Cross-tenant access settings, it will be mondaroy to create the account of my partner as guest account in my tenant and then limit access to these guest account on organization settings
Yes, magic doesn’t happen after a cross-tenant access policy is created. You still must invite people to share – and the admin of their tenant must allow them to share by installing a cross-tenant access policy that allows access to your tenant.
Ok Thanks you for your reply.
But if for example i make restriction to give access just for some partener users to my tenant. and if i send invitation or create a guest account for user don’t listed on the restriction, he will be able to access ressources or not ?
If you apply a restriction using a policy (for instance, by limiting access to a set of accounts), then an account that isn’t specified in the policy won’t be able to access content controlled by Direct connect (like shared channels) or B2B Collaboration (guest accounts), depending on where you choose to limit access.
Hey Tony,
Any chance the Azure AD Cross Tenant Access Policies will allow us to delegate Full Access permissions for a Shared Mailbox to an external user? If so, would you mind posting the steps to allow just a single external user to few shared mailboxes? (specifically during a T2T migration that’s dragging on longer than they ever should). Thanks!
These policies aren’t for Exchange Online mailbox access. That’s covered by mailbox permissions. What specifically do you want an external user to be able to do in a shared mailbox?
https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide says:
User permissions: You need to give users permissions (membership) to use the shared mailbox. Only people inside your organization can use a shared mailbox.
External users: You can’t give people outside your business (such as people with a Gmail account) access to your shared mailbox. If you want to do this, consider creating a group for Outlook instead. To learn more, see Create a Microsoft 365 group in the admin center.
External users can access items in a group mailbox. Is that what’s needed?
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?
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.
Great article, thanks!
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.?
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.