How-To

Azure AD B2B Direct Connect

• By Paul Schnackenburg
• 07/29/2022

At Microsoft's recent Inspire conference, Azure AD B2B Direct Connect and one of the first features built on this technology, Microsoft Teams Connect shared channels, were released to General Availability. Both are interesting technologies, and in this article I'm going to cover both, but it's the Direct Connect feature that'll have the most long-term impact.

Problems with Trust, Federation and Cross-Organization Collaboration
This is not a new issue. I can remember teaching eager students 20 years ago about forest trust in Active Directory and all the options that were available for controlling which users had access to what resources in each separate organization. That sounded great in theory, but in the real world required a WAN link connecting the physical networks of the two organizations and configuration on both ends of the connection and user training to know how to actually invite users from the other business to access resources. I remember listening to an interview with a Microsoft employee who said even staff rarely used it because they didn't know if the other organization was connected or not, so it was just easier to send the document in an email.

The next tech to come along was federation, Active Directory Federation Services (ADFS) or third-party options, all with the goal of making it easier to collaborate between different organizations. This also met with mixed success, particularly as it takes a lot of expertise and management to maintain ADFS infrastructure and configuration, let alone secure it (just ask the orgs that got their networks owned through their ADFS in the SolarWinds hack).

Today, though, we have one benefit that wasn't widespread 10 years ago: cloud computing and Software-as-a-Service (SaaS) offerings. Surely this should make cross-organization collaboration easier to manage and secure?

Take 1: Azure AD B2B
Microsoft has had a solution in place for a long time: the concept of inviting a guest account to your tenant. By default, invited guest users can even invite other external users to your tenant. The main point here is that these accounts aren't managed by you (apart from granting access to resources and deleting them when they're no longer required). You don't manage their passwords or account details, and if they leave their organization (and the account is disabled/deleted) the account will stop granting access to your resources. The invited accounts can come from another Azure AD tenant, from any email address, any other SAML/WS-Fed identity provider or Google/Facebook accounts. Predictably there are a few security settings around these guest accounts and options for managing them. You can have a process where they're invited by certain users in your organization who have been delegated that task, or you can allow every internal user to invite external users (the default). The latter can happen as part of the act of sharing a file in SharePoint or OneDrive with them or giving them access to a Team or SharePoint site.

However, there are some drawbacks to this approach. One is that your Azure AD tenant will be littered with guest accounts (unless you've got good account lifecycle management and clean out stale accounts regularly). Second, as you implement basic security hygiene and force all your users to perform Multi-Factor Authentication (MFA) to prove that they are who their username and password say they are, you can't control what MFA settings already apply to a guest user. So they might have to do double MFA, first when they log in to their account in their home tenant, and then again when they access a resource in your tenant.

For completeness sake, I'll mention Azure AD B2C. If your organization develops an app that's available publicly and you want consumers to be able to use Facebook, Google or an email to log in to your app -- but you don't want to roll your own account solution (and you really shouldn't) -- you can use Azure AD B2C as a managed service. The accounts for your application(s) end up in a separate AAD tenant. For many years there has been talk about bringing B2C together with B2B, but this hasn't happened yet.

Take 2: Azure AD B2B Direct Connect
This brings us to Direct Connect, a new and complementary service. Here, both organizations must have an Azure AD tenant (which includes every business using Office 365, even if they don't use any other Azure services).

There are two main benefits. First, no guest accounts are created in your tenant; they are still housed in their organization's directory. Second, you have more control over the settings for each individual organization that you're collaborating with, compared to Azure AD B2B.

Today, the only application using Direct Connect is Teams Connect shared channels, but the documentation repeatedly points out this fact, leading me to believe that other Microsoft cloud services will be included in the future.

Remember, this isn't an either/or proposition, but Direct Connect has some very interesting options that'll add flexibility as you configure collaboration between yours and another business.

Direct Connect Setup and Configuration
To get started, sign in as a Global Administrator to entra.microsoft.com, (or aad.portal.azure.com) and go to Azure Active Directory -- Cross-tenant access settings. Start by checking out the Default settings "tab."

Note that the default for both inbound (external users accessing a Teams shared channel in your tenant) access and outbound (your users accessing resources in another tenant) access is All blocked. This means no Direct Connect collaboration can happen unless you take action, and an administrator in the other organization takes similar actions.

This is done on the Organizational settings tab where you click + Add organization and enter their domain name or Tenant ID. Once you've added their tenant, you can alter the settings from the default to allow collaboration to happen. It's again broken down by inbound and outbound access and also by users/groups (or allow everyone in your business or everyone in the partners organization) and by application. Today, the only application in the list is Office 365 (which is just Teams shared channels) but there are options for both additional Microsoft applications and third-party applications in the future.

There's a warning that appears when you configure outbound settings, as the partner tenant will receive some basic information about user accounts in your directory.

Furthermore, you can control whether you trust the MFA state of users in the other tenant, or the compliance state of their devices with MDM policies, or the hybrid Azure AD state of devices. This should obviate the "double MFA" issue which is not a good user experience.

This control is the main reason I think Direct Connect has a bright future ahead. Organizations are understandably wary of inviting external users to access their "stuff," but business imperatives are trending toward more short- or long-term cross-organization collaboration.

As more applications are brought into this model, I can certainly see that the ability to only allow a specific group of people from the other organization to access specific apps and resources, and likewise only allowing certain groups of your users to access apps in the partner tenant will make security teams happier.

Licensing for Direct Connect builds on the current Monthly Active Users (MAU) model where the first 50,000 accounts are included for free. This replaces the old "each paid account gives you five guest accounts" model and works well for most small and medium enterprises as they're unlikely to have external collaboration through both B2B and Direct Connect over the limit.

It's worth mentioning the third tab, Microsoft cloud settings -- still in preview -- which allows you to connect Azure public cloud tenants to Azure Government or Azure China tenants.

If you need to automate the creation of cross-tenant settings at scale, there's an API, for which instructions are here.

This article provides a good comparison of B2B, Direct Connect and B2C and when to use what. Cross-tenant access settings (Direct Connect) control whether your users can authenticate with external AAD tenants, whereas external collaboration settings (B2B) dictate which of your users can invite external users. They work together, and for some examples see here.

Teams Connect Shared Channels
Once the configuration has been completed in both tenants, you're ready to configure shared channels. This requires checking some settings in the Teams admin center, so log in and expand Users -- External access. Under "Teams and Skype for Business users in external organizations," ensure that the domain you've configured earlier isn't blocked

Then head up to Teams -- Teams policies and create a scoped policy for the users who should be able to create shared channels (or use the Global policy if you want everyone to be able to) and enable (they're on by default): Create shared channels, Invite external users or Join external shared channels to suit your needs.

Here I created a Shared channel in a Team.

And then I invited two external users from the organization I've set up Direct Connect with.

Conclusion
The modern IT landscape for information workers is an increasingly fluid environment, with users working in agile Teams, in different locations and on different devices, all while collaborating with internal and external users regularly. These new features will be very useful to put some guardrails in place to manage that interaction, while still maintaining security and control. It'll be interesting to see how Direct Connect evolves and which applications will be added in the future.