While Active Directory and AD FS admins may feel that they are on top of things as new Operating Systems versions only typically appear every 3 years. However, when adding Azure AD to the mix, a constellation emerges where the change rate of Azure AD may suddenly wreak havoc…

A recent change

Recently, Microsoft has made a change in the way that the multi-factor authentication (MFA) registration information for Azure AD Business to Business (B2B) guest users is stored. Previously, the Azure MFA registration for guest users in their home tenant was used. However, since the change, an MFA registration is created in the inviting tenant.

Note
MFA registrations in on-premises identity providers (like Azure MFA Server integrated with AD FS) are rejected by default in the context of Azure AD B2B, unless specific settings are configured between the two Azure AD tenant (the home tenant and the inviting tenant).

Reasoning behind this change

I don't pretend to know why Microsoft made this change, but I can guess.

Microsoft is moving authentication method management towards the Authentication Methods blade and decommissioning the current blades and portals where authentication methods can be managed:

1. The Legacy PhoneFactor portal, labeled Additional cloud-based multifactor authentication settings in the Azure Portal and Entra Portal.
2. The Authentication methods pane for Password Reset in the Azure Portal and Entra Portal.

To this purpose, Microsoft offers a Migration path, currently in Public Preview. Its end goal is to offer one management pane to control which authentication methods are allowed, and which methods are prohibited.

Going forward, this means that two organizations can configure authentication method policies that don't include a common method. For instance, the inviting tenant would require a multi-factor authentication method that the guest's home tenant would not allow as an authentication method. In this case, (secure) collaboration would not be possible. Storing the multi-factor authentication registration in the inviting tenant solves this potential problem.

Issues regarding this change

However, this change also introduces some issues…

Updating the processing agreement towards guests

With default settings, test message and phone call are allowed multi-factor authentication methods. When a guest registers at least one of these methods, the phone number of the guest is stored in the Azure AD tenant. The stored phone number may be personal date and, therefore, subject to privacy regulations like GDPR.

Of course, the purpose of storing this information is to secure access, so this is not where the problem lies. Only admins with specific roles have access to this information, so this is also not where I see the biggest problems. However, subjects should be aware that this information is stored when they use text messages or phone calls to satisfy the multi-factor authentication requirements to access the shared functionality. This may require an addendum to the processing agreement towards guests.

Providing the right expectations when collaborating

As people in your organization access shared functionality, it should be clear to them, that:

• Your organization's tenant admins cannot view, change or remove the multi-factor authentication registration information in the other organization's tenant.
• You may be tempted to completely disable text messages and phone calls as multi-factor authentication methods. To ensure continued access when a device is lost, stolen or decommissioned, people in your organization should register at least two multi-factor authentication methods that are independent of a certain device. This may lead to registration of the Authenticator app and a phone number as fallback method. Otherwise, multi-factor authentication for guest access needs to be re-registered by contacting the other organization's service desk to have their admins issue a temporary access pass (TAP).

Indeed, that second expectation may amplify the first issue.

Updating the guest access policies

As multi-factor authentication registration information is stored in the inviting tenant, but the password (hash) is stored in the home Azure AD tenant, this change also dictates that when a guest user wants to setup Password-less authentication, a password first needs to be set in the inviting Azure AD tenant…

I see organizations limit Azure AD's Self-service Password Reset (SSPR) feature to a limited set of user accounts, instead of the All Users group. The All Users group includes all guest accounts. When selected as the scope for SSPR, it enables guests to set a password and, therefore, enables Password-less options.

In some organizations, such a change in policy might require a change in philosophy.

Concluding

The recent change by Microsoft to store personal information for the people in your organization in Azure AD tenants of organizations that you collaborate with might prompt you to reconsider guest access policies.

You may be tempted to completely disable text messages and phone calls as multi-factor authentication methods, but this may not be the smartest thing to do. You may think that you are not impacted by this change because your organization is using AD FS with a custom multi-factor authentication provider, but this would be a wrong way of thinking.

Offering collaboration services requires thought. Trust in terms of IAM, typically, requires 100% trust.