Efficient collaboration while maintaining security standards is often difficult, especially when it comes to the end-user experience. Business-to-business (B2B) transactions are made in the cloud, but the cloud itself is a dangerous place. Passwords should not be accepted as the only credential, and multifactor authentication (MFA) should be the standard. In this context, it is less than useful that the MFA status is – thus far – only valid within the boundaries of the tenant and that other tenants are not trusted. If two communication partners are committed to a modern work approach with zero trust, things become even more difficult: The device status cannot be transferred either.

New Possibilities with xTAS

Cross-tenant access settings (xTAS) offer an opportunity to improve this situation. The feature is designed to control collaboration fully across tenant boundaries and let organizations control inbound and outbound collaboration by defining tenant-wide and partner-specific rules (Figure 1).

Figure 1: The default settings for cross-tenant access for B2B collaboration give you free rein. If so desired, you can establish more granular controls at the user or group level.

These policies describe exactly how collaboration with partners should look. For your Azure Active Directory (AAD), resources, apps, and users, you can define which partner companies you want to allow for collaboration, under what conditions this takes place, and the partner companies allowed to invite your employees. Restrictions previously applied for both: You could either define the companies approved for collaboration freely or use an allow or deny list. A more granular approach was not available. Until now, you could not use the B2B settings to control who from your own company was allowed to be a guest in other companies.

xTAS changes this state of affairs: In both trust directions, you can define for each partner company whether collaboration is desired, and it even works at the user and group levels. For example, if you only want one project team to be able to collaborate with a supplier in that supplier's Office 365 while ruling out the rest of the organization, you can simply define this arrangement with group memberships. In this way, you ensure granular control and help delegate management tasks to the project teams, letting them steer the group themselves.

Trusting a Partner Company

You can create the ruleset on two levels. You start by defining a standard company-wide policy that governs collaboration: Are your own employees allowed outbound collaboration? Should you generally be able to invite other companies? Once you have created the corporate policy, go into detail and describe collaborations with individual partner companies: Which of your employees, defined by group membership, can collaborate with Fabrikam [1]? Which project teams are allowed to collaborate with Contoso – and how should Contoso be allowed to operate in its own tenant environment? The individual configuration per partner company regulates collaboration in a very granular way. You always manage two aspects: incoming access and outgoing access. If no rule exists for a partner, the default rule applies.

Especially if close collaboration with selected partners is the norm, or if other clients in the same group of companies need to be more closely connected, you will probably want to fine-tune some security configurations. If you trust account management, MFA and credentials, and partner device management, you can take a user's MFA status and device health from Intune and accept it in your conditional access (CA) rules. In this way, you are not only trusting the users, but also the other company's security settings and processes.

If contractual agreements stipulate that the respective IT processes must be disclosed and must comply with certain standards, you will probably want to reflect these standards in the collaboration settings. An advantage for the employees is that if MFA is mandatory, staff do not need to set up and complete MFA twice when working across tenant boundaries. Your own CA rules could also be simplified: You will not need to define and maintain as many MFA or device exceptions for partners.

Granular Collaboration Management

By default, xTAS allows free collaboration and your coworkers can be invited by others to participate. You can create advanced policies in Azure Active Directory | External Identities | Cross-tenant access settings on the Azure portal. You will see two tabs – Organizational settings for the detailed configuration of partner companies and Default settings for the default rules – which give you an overview of the basic settings broken down into Inbound access settings and Outbound access settings . Clicking Edit lets you prohibit collaboration completely or allow it in a granular way by exempting individual users or groups.

The Organizational settings option lets you configure the same settings, but for a partner. If no settings are stored yet, you can start the creation process by selecting Add organization . On the right side of the screen, you can now specify your business partner's AAD client: The domain name is all you need (e.g., contoso.com ). Once you have selected the correct tenant, it is displayed in the main window. Initially, the inherited from default settings apply – for both incoming and outgoing access.

Clicking on one of the two links will take you to the detailed settings page. Customize settings lets you define who is allowed to collaborate in the inbound and outbound directions. The default for the inbound settings is All external users and groups , which means that all employees at Contoso are allowed to collaborate with you and have access – if they have been invited by one of your coworkers. If this is not desired and you only want to grant collaboration to a very specific group of Contoso employees, regardless of invitations, you need to use Select external users and groups . You will then need to agree with Contoso which users and groups are to be allowed. You then enter the object IDs of the permitted collaboration partners from the Contoso tenant in a list. The same functionality, only in reverse, is available for outbound settings. You store the object IDs of the users and groups who are allowed to work on the Contoso tenant from your own client.

The MFA and device data settings for inbound access are found in the Trust settings for Contoso. Once you are sure that the partner company's identity verification and device management complies with your requirements, you can trust the data from Contoso's tenant in Customize settings by selecting from various options. Trust multi-factor authentication from Azure AD tenant , Trust compliant devices , and Trust hybrid Azure AD joined devices are your choices. You can mix the settings to suit your needs, driven by the level of confidence you have in Contoso's IT managers. Selecting one of these settings causes the Conditional Access Rules on your tenant to wave Contoso through, assuming the Contoso tenant has completed MFA and device testing.