Microsoft Teams is a great collaboration tool, and the integration of external parties is already a powerful tool in today's hybrid workplace. Working with guest in Microsoft Teams is based on a feature called Azure AD B2B Collaboration and working on files on SharePoint Online was the first service leveraging the Azure AD guest user feature. Up until now this awesome work had one major caveat: The infamous Teams Tenant switch. With Shared Channel, Teams Connect and Azure AD B2B Direct Connect this last flaw is gone. This post will show you what it takes to enable your organization to participate from this public preview of Shared Channels, because by default external collaboration is turned off in your and your partners Azure AD tenant.
Microsoft Teams is finally starting the public preview for Shared Channels and Teams Connect. The last public update was given at the Microsoft Ignite Fall 2021 event with a great session by Arun Das about external collaboration. Shared Channels is a powerful feature that will immediately enable new ways of collaboration inside your organization. The feature has many facets and there are great blog posts out there introducing you to the overall functionality. As with most recent updates to the service there are great Microsoft Docs articles that have all the detailed information an IT Pro will need to understand and deploy the feature.
This blog won’t look too much into the overall features of sharing a channel with a single user or with a whole team but rather we will focus on the basic infrastructure needed to enable and control external collaboration with a new feature called Azure AD B2B Direct Connect. Until now collaboration in Microsoft Teams with an extern user required the guest to be added to your Azure AD tenant. This feature is called B2B Collaboration and in early March Microsoft introduced a new cross tenant access feature. This change was foreshadowing the new controls needed to enable collaboration in Shared Channels. Guest user identities in Azure AD have been a constant topic in discussions with customers and partners. Inviting a user into a Team (fundamentally a Microsoft 365 Group) required the creation of a user in your tenant. Security, the IAM team, and data protection was concert about the access a guest would have to organization data and how the overall lifecycle would look like to control this identity. This (missing) object in your Azure AD is the biggest differentiator between Azure AD B2B Collaboration and Azure AD Direct Connect. Yes… no more guests if the user is only invited to Shared Channels in Teams. One could think “great, but how do I control who my users can invite?” I’m an enterprise and I need to have compliance rules enforced. The good (or bad) news: by default, none of you users can join a Shared Channel in another organization and no user from a foreign tenant can be invited to your Shared Channels. To control the collaboration Microsoft introduced cross tenant access features. If you already looked this up with the mentioned release in the B2B Collaboration you are well prepared and most feature will translate to B2B Direct Connect. Let's have a look at the basics for cross tenant access policies.
To enable external collaboration, we need to configure a trust relationship with other organizations. The good news the process is simple thanks to a great implementation in the well-known Azure Portal and the Azure AD blades. If we click on “External Identities” and “Cross-tenant access settings (preview)” you will notice that currently there is no organization configured.
To verify the rules applied by default we need to check the “Default settings” tab. With one click you can see that B2B collaboration is allowed and B2B direct connect is blocked. B2B collaboration (guest access to a complete team, files in SharePoint or AAD apps) is enabled and only thanks to cross tenant access introduced by Shared Channels you also gain controls to limit collaboration on the currently available model at the identity level. To be honest it is a bit more complex because there are multiple levels to control guests and sharing content (guest invite, domain whitelists, guest access for teams, sharing in SharePoint Online, …). For the moment we need to focus on AAD controls using cross tenant access policies. Each feature has two directions:
- Inbound access settings: This will control if a guest can access your content in your organization. This direction could already be controlled on multiple levels, but this new org-based approach offers more fine-grained controls the before.
- Outbound access settings: This will control if your users are allowed to access content in other organizations. This is a new control you didn’t have prior the work done for Shared Channels.
Remember this is working for B2B collaboration and B2B direct connect and if needed will allow even more control out of the current B2B collaboration model if needed. If you are like me and you love the open model that we already have and love, you just need to change the Inbound and Outbound default settings for B2B direct connect. Allowing “External users and groups” and “Applications” will put you in a “open federation.”
But we are not done yet! This is a two-way config! With the introduction of cross tenant access and the default off state you also need to contact the Azure AD admin of your (future) invited guests. If the other tenant isn’t also on a “open federation” and by default no one is, the other tenant needs to add your tenant and allow all users (or some users or a group) to use B2B direct federation. If you are a larger organization with multiple tenants doing this internally might be easy, but if people need to work with organizations that you don’t already have contact on an IT Pro level this is a challenging situation. You and your users want to get rid of tenant switching, but every channel with a new guest from a yet unknown organization will need to configure cross tenant access settings. This post might be a great starting point to get the conversation started and I will further support you in providing some arguments why they don’t have be afraid of this configuration.
But first let’s have a look at the steps needed to enable collaboration with a single tenant. We will leave the default settings for the tenant for B2B direct connect disabled. Now we add an organization by providing the tenant id. It is also possible to lookup the ID using the email domain of the target guest users. I’m using “microsoft.com” as an example.
Now we need to explicitly allow inbound and/or outbound access for B2B direct connect. We select the “B2B direct connect” tab and customize the settings. For “External users and groups” and for “Applications” we configure “Allow access” and set “Applies to” to “All external users and groups” / “All applications”.
With this configuration our users are now allowed to invite users from the Microsoft tenant, and we allow the Microsoft tenant to invite our users. Attention: This is only half the solution! Next you need to contact Microsoft (the IT organization) and ensure they have the same configuration for your tenant. Can you imagine this process? I can because we already tried this in the private preview and let me tell you… Microsoft is a real enterprise customer :smiling_face_with_smiling_eyes:
With the given options we have so many possible ways to be even more fine grained. Limit to a group that is managed in the other tenant, or you can limit the apps available to the users. I would highly recommend keeping it simple. Troubleshooting an access issue across two tenants could be really challenging. This new model will not add a guest to your tenant so monitoring and checking access can be done in the sign-in logs.
Please keep in mind that you can also change the default for B2B collaboration. If you are currently allowing the invitation of guests or even if you as an IT manages guests through a process, changing these settings can have an immediate impact on your current collaboration environment (Teams, SharePoint, Apps, …). Please test any change in a staging environment.
With all of these “basic” information you can decide on a suitable B2B direct connect configuration. Having an open federation makes troubleshooting a lot easier because blocking will come in almost all cased from the other tenant. Request to enable Shared Channel with users in your organization will be very rare. The chosen default from Microsoft was not an intention to make this hard, but to let you make a conscious decision to open collaboration with all or just a few tenants.
Here are a few additional information that would also be worth a complete new post:
- The “Trust settings” configuration for in- and outbound allows to trust Multi Factor Authentication performed in the home tenant of the guest. If the user is using strong authentication (for example MFA) this claim can be checked in your own Conditional Access settings. You only must ensure the CA policy is targeting “All guest and external users” as a principal, because we cannot target a single guest as there is no guest in your tenant. The fine-grained control is replaced by the cross-tenant access policy you configured.
- “Trust settings” also allows to check the device for compliance or if it is joined to on-prem AD. For larger organizations with multiple tenants this is a great way to enforce device compliance across tenants that conform to the same rules. You trust the admin of the guest tenant that “is compliant” is compiled from the equal policies.
- Access Reviews (from Identity Governance an AAD P2 feature) will work with guests in a shared channel. The owner of a team needs to review all users that are a direct member of the team and now also any B2B direct connect user from the Shared Channels of the team.
Here are a set of to-dos that you should start today:
- Get two test tenants and play around with this feature to ensure you don’t destroy the current collaboration setup
- Enable “Trust multi-factor authentication from Azure AD tenants” for in- and outbound settings for both B2B modes to get rid of the double MFA
- Check your current Conditional Access policies that targets guests and ensure “All guest and external users” is used because CA is not aware of the users UPN but it knows if it is a guest in general
- Check your if you are using Microsoft Defender for Cloud Apps (formally MCAS) session controls because this is currently not working because it is looking for a B2B guest in your AAD
- If you configure cross tenant access policies to restrict access to only a few organizations this requires Azure AD P1, but yours should already have this in place for conditional access.
Bio
Marco Scheel is a Lead Cloud Architect at glueckkanja-gab AG (Offenbach, Germany).
Marco started his consultancy career with on-premises SharePoint Server infrastructure. Going cloud as an early adopter he was challenged with the introduction of Office 365 groups and later Microsoft Teams. Helping customers to make the best out of the modern collaboration tools inside Microsoft 365 is driving his motivation to adopt and adapt new features from Microsoft online services.
https://twitter.com/marcoscheel
To write your own blog on a topic of interest as a guest blogger in the Microsoft Teams Community, please submit your idea here: https://aka.ms/TeamsCommunityBlogger