Conditional Access public preview functionality reviewed (22H2) – Part 3: Granular control for external user types

In the last couple of months, Microsoft released new functionality for Azure AD Conditional Access. All of this functionality is still in public preview, so please read the following article on what to expect from Preview functionality: Preview Terms Of Use | Microsoft Azure

In these series of articles I will go through the following new functionality:

• Part 1: Authentication Strength
• Part 2: Conditional Access filters for Apps and Workload Identities
• Part 3: Granular control for external user types (this article)

In July, Microsoft made cross-tenant access settings for external collaboration generally available. With

cross-tenant access settings we now have the option to setup a mutual “trust” with external Azure AD organizations, called B2B direct connect. While defining this “Trust” we can also decide whether we want to “trust” already performed MFA from a user in the other Azure AD organization, or if we want to “trust” compliant devices and/or Hybrid Azure AD joined devices from the other Azure AD organization.

The B2B direct connect makes the new “Shared channel” functionality in Microsoft Teams possible.

The addition of B2B direct connect introduced a new challenge when it comes to assigning Conditional Access policies to these new type of external users, which is addressed by the more granular options now available helping you to specify which external user you want to target.

Current Conditional Access policies targeting Guest or external users, have all options enabled, targeting all external Azure AD organizations.

Microsoft defines the following types of Guest or external users:

• B2B collaboration guest users – Most users who are commonly considered guests fall into this category. This B2B collaboration user has an account in an external Azure AD organization or an external identity provider (such as a social identity), and they have guest-level permissions in your organization. The user object created in your Azure AD directory has a UserType of Guest. This category includes B2B collaboration users who have been invited and who have used self-service sign-up.
• B2B collaboration member users – This B2B collaboration user has an account in an external Azure AD organization or an external identity provider (such as a social identity) and member-level access to resources in your organization. This scenario is common in organizations consisting of multiple tenants, where users are considered part of the larger organization and need member-level access to resources in the organization’s other tenants. The user object created in the resource Azure AD directory has a UserType of Member.
• B2B direct connect users – External users who are able to access your resources via B2B direct connect, which is a mutual, two-way connection with another Azure AD organization that allows single sign-on access to certain Microsoft applications (currently, Microsoft Teams Connect shared channels). B2B direct connect users don’t have a presence in your Azure AD organization, but are instead managed from within the application (for example, by the Teams shared channel owner).
• Local guest users – Local guest users have credentials that are managed in your directory. Before Azure AD B2B collaboration was available, it was common to collaborate with distributors, suppliers, vendors, and others by setting up internal credentials for them and designating them as guests by setting the user object UserType to Guest.
• Service provider users – Organizations that serve as cloud service providers for your organization (the isServiceProvider property in the Microsoft Graph partner-specific configuration is true).
• Other external users – Applies to any users who don’t fall into the categories above, but who are not considered internal members of your organization, meaning they don’t authenticate internally via Azure AD, and the user object created in the resource Azure AD directory does not have a UserType of Member.

The different types of guest or external users gives some nice insights in the options we have today to define guest or external users. So, while we would normally invite Guest users by adding them to a Microsoft 365 groups, we also have the option to designate those users as Members in our Azure AD. By doing so we can distinct between these type of users and target different Conditional Access policies against them. It’s also interesting to see that you can designate Azure AD normal users as “Guest” user.

For B2B direct connect users, no accounts are created in your own Azure AD, just as for Service provider users which use Delegated Access Permissions (DAP)/ Granular Delegated Access Permissions (GDAP) to access your tenant in order to perform administrative activities.

The “Other external users” can be more considered as a “catch all” just in case an external user doesn’t meet any of the properties which define the other types of guest users.

Granular control for external user types use cases

Below are some use cases that we can implement:

• Only allow Service Provider to access the environment from predefined locations
  • We tried to create a policy requiring a compliant device in the tenant of the Service Provider and allowing this status to be used in the Azure AD cross-tenant settings, but unfortunately this didn’t work. The compliance status is only available for Guest users in the scenario of accessing a Teams Shared Channel
• Block “Other External Users” from accessing your Office 365 data
• Allow access to “B2B collaboration guest users” after accepting the Terms of Use
• Only allow “B2B direct connect users” when they come from an Compliant or Hybrid AD Joined device

Granular control for external user types conclusion

The granular control for external user types is a necessary addition to Conditional Access, since we don’t have Guest users anymore, but Guest users have many flavours. My main recommendation is to use this option to protect the access for your Service Provider using GDAP making sure that those administrative users cannot access/manage your tenant from anywhere in the world. I would also recommend making sure that Azure B2B direct connect users access your company data from compliant or hybrid AD joined devices only.