A Farewell to Viral Tenants

Microsoft announced that after October 31, 2021, email one-time passcode (OTP) authentication would become the default method for authentication in business-to-business (B2B) collaboration scenarios, and viral Azure Active Directory (Azure AD) tenants would no longer be created. But what does this mean—now that the deadline has passed—for an Azure AD administrator who has B2B partners or is considering using B2B?

What is a Viral Tenant?

“Viral” or unmanaged Azure AD tenants are tenants that were created when a user from a DNS namespace that isn’t associated with an existing Azure AD implementation redeemed a B2B invitation into an Azure AD tenant. Viral tenants are used to store the credentials for authenticating the user in the B2B context of the target Azure AD tenant.

For example, Joe at Contoso invites bob@fabrikam.com to collaborate on a project using Azure B2B. The namespace fabrikam.com isn’t associated with an Azure AD tenant, so when Bob redeems the invitation, an unmanaged “viral” tenant is created for fabrikam.com, and Bob is directed to create a credential for an ID in that tenant.

Viral tenants fall firmly into the category of “seemed like a good idea at the time.” They likely contributed to making Azure B2B accessible early on, but they have a couple of issues:

  1. There is no link between the viral tenant identity and the organization the user belongs to (other than for self-service password reset—SSPR). If Bob is terminated, Fabrikam can’t revoke his access in any tenants that he is a guest in. The best Fabrikam can do is inform the administrators of those tenants and hope they revoke access.
  2. The existence of a viral tenant can provide roadblocks to an organization establishing its own Azure AD tenant. At a minimum, the organization must “claim” any viral tenants and convert them to a managed status. If the organization has multiple namespaces associated with it (fabrikam.com, fabrikam.co.uk, etc.), then they may end up with multiple tenants that need to be merged due to the existence of (possibly unknown) viral tenants.

Likely for these reasons, Microsoft is deprecating the use of unmanaged tenants. Moving forward, users who have identities in viral tenants will retain them, but new viral tenants won’t be created—and new users won’t be added to existing viral tenants.

New users who would have previously qualified for an identity in a viral tenant will instead leverage either email OTP authentication (if not explicitly disabled in the tenant) or be required to create a Microsoft account.

Email One-Time Passcode Authentication

Email OTP authentication works by emailing the user a passcode when they attempt to access resources as a guest. The user must then enter the passcode in the authentication prompt within 30 minutes to complete the authentication. They are then authenticated for 24 hours.

For example, the user fred@dactest.com attempts to log on to the FooBarQux tenant and receives the following prompt:

The user then receives an email with a verification code:

Entering the verification code in the logon prompt results in a successful authentication to the Azure tenant.

This approach has the advantage that it creates an explicit link between the guest user’s email account and access. If the guest user is terminated in their home organization, they presumably lose access to their email account and would no longer have access to authenticate using the OTP method.

The disadvantage of this method is that the user must have access to their email to authenticate, and email delivery times aren’t instantaneous—which creates more friction for the logon process.

As of November 1, 2021, Microsoft enabled email OTP authentication by default on all new tenants and is rolling it out to existing tenants that haven’t participated in the preview. The majority of tenants will have email OTP authentication enabled by January 2022. Administrators can choose to explicitly disable the feature in their tenant if they aren’t ready to support it, or if the authentication model is problematic for their use cases.

An Opportunity

As Microsoft rolls out this update, the end user experience for new B2B guests will change. Even if you disable the email OTP authentication method, users will no longer have viral accounts created (they will instead be forced to register Microsoft accounts)—so some process changes will need to be accommodated.

Administrators can instead look at this change as an opportunity; if the B2B redemption status of existing viral accounts is reset after email OTP authentication is enabled, the guest user will start using email OTP authentication when they re-redeem their invitation. This addresses the major weakness of the viral tenant from the perspective of the inviting tenant: that the user could be disabled or terminated in the source organization and not be reflected in the unmanaged tenant.

This may not suit every organization but given the increasing multi-factor authentication (MFA) requirements, the number of scenarios where a guest needs to access your tenant but can’t access their email should be very few.

Resist the temptation to disable this feature; instead, consider migrating existing users to email OTP authentication to improve your overall security posture with guest accounts.

Need assistance with deploying Azure AD B2B in your tenant? Ravenswood Technology Group can help. Contact us today!


WHAT WE DO

Remediating LDAP Client Security

Remediating LDAP security issues is important because the default configurations on domain controllers (DCs) and clients are open to various attacks. Learn how to remediate those issues.

Monitoring for LDAP Client Security

Applications that use Lightweight Directory Access Protocol (LDAP) are prevalent in virtually every organization that uses Active Directory (AD). Unfortunately, the default AD configuration provides

A Farewell to Viral Tenants

Microsoft announced that after October 31, 2021, viral Azure Active Directory tenants would no longer be created for B2B collaboration.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.