Azure AD B2B Direct Connect
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.
