A couple of conversations this week, including this prompt by Daniel Glenn – https://x.com/DanielGlenn/status/1812952597759992149 have led me to write up this quick guide to making your cross-tenant, resource account, guest, B2B Collaboration users (note, these are all the same thing) multi-factor authentication easy.
If you don’t do this, then the user needs to set up MFA for every tenant where they have a guest account and MFA is required by Conditional Access rules. This experience you might be familiar with – an entry for all your guest accounts in your Authenticator App and lots of issues reregistering these when you get a new phone.
The only disadvantage to this configuration is that it is done in the guest tenant and not the tenant you are in, your “home tenant”. So as an Microsoft 365 or Entra ID administrator, you can turn this on to improve the MFA experience of your external users, but you directly cannot improve the experience of your users accessing other tenants unless you encourage the admins of other tenants to do this as well. Therefore, this is absolutely something to consider when you set up cross-tenant sync, but it works for all your guest accounts and B2B Collaboration scenarios.
For a side conversation on how this works with Zero Trust, see this related blog post by my colleague Matt Levy.
First of all we need to configure the “resource tenant” to allow MFA to be trusted from the “home tenant”. We can either do this on a tenant to tenant basis, or we can do this for all tenants by modifying the default rule.
In the Entra Portal of the resource tenant, visit External Identities > Cross-Tenant Access Settings and either Default for all external tenants, or under Organizational Settings modify the Inbound Access settings for a tenant you have already added, as shown in the next screenshot.
For either the Default or the specifically added tenant, under Trust Settings click the Trust multifactor authentication from Microsoft Entra tenants and save your changes.
Also in the “resource tenant” I have two Conditional Access rules – MFA for Admins with a short session length, and “Rule CA002” – MFA for all users, which includes “guests” or “B2B Collaboration” users, as the screenshot below shows that this user type is not excluded from the policy – only my break-glass account is excluded. This means that MFA is required to access all my resource tenant resources, for users and guests.
So if I login to my “home tenant” with a new user account, and the home tenant also has an MFA requirement I am going to see the following activities:
- Login to the home tenant for the first time. In my case I issued a Temporary Access Pass (TAP) to the user so that their first login requires MFA registration as I block MFA registration from untrusted locations and devices.
- The user in this blog post has been invited to the “resource tenant” and has a link in their email to follow. The have been granted access in this example to the SharePoint Intranet of the resource tenant. The user clicks the link to the resource tenant – what do you expect to happen?
- What happens is that the user accesses the resource, no further prompts or questions. The “MFA” of the home tenant has been accepted by the resource tenant and access has been granted – no additional MFA is required and the Microsoft Authenticator app (or any other MFA app) only lists one entry.
- To prove the MFA was used, check the sign in logs in the resource tenant after about 15-20 minutes.
- The sign in logs show that “MFA requirement satisfied by claim in the token”, which means the MFA from the home tenant was used, because I was not prompted for MFA registration or entry by the resource tenant.
Let us take a look at some other examples of what could happen. I don’t have many screenshots for all these as it would make the blog post too long – but each of these scenarios are those that I have seen or been asked about:
No MFA Requirement In Home Tenant
This scenario is the same as above, resource tenant requires MFA, but the home tenant does not enforce it and so the user has logged into the home tenant without any MFA before they accessed the resource tenant.
This is easy – the user is prompted from their home tenant MFA to complete MFA and access the resource. If the user has not yet registered for MFA in the home tenant, they are required to register in the home tenant and are subject to any rules the home tenant enforces (for example you can register only from trusted networks). The user never sets up a new MFA in the resource tenant. Here is what my Authenticator App looks like – one entry for the home tenant:
Home Tenant Does Compliant Devices Only – No MFA
This is the same as above. It does not matter what Conditional Access requirement you have in the home tenant, it is the Conditional Access rules in the resource tenant that count. If the resource tenant requires MFA then you will need to register MFA in the home tenant and then use it to access the resource tenant.
Authentication Strengths Required
If the resource tenant has Authentication Strengths enabled and requires a certain level of MFA (for example, phish resistant MFA required) and you have registered in the home tenant an MFA method that the resource tenant blocks (i.e. SMS or Push Notifications in Authenticator), then you will need to register a stronger method until you gain access.
Here the user is required to register a passkey. If I click “I want to set up a different method” then I cannot select a weaker method even if the home tenant allows it on my account.
Home Tenant Has Security Defaults Only (no Entra ID Plan 1)
The resource tenant needs to enable MFA Trust, but the home tenant does not. So if the home tenant has Security Defaults enabled and therefore no Conditional Access rules, MFA in the home tenant is controlled by Security Defaults, and MFA is in the authentication token for user so when the user accesses the resource tenant, MFA is completed from the home tenant.
Resource Tenant Does Not Have Entra ID Plan 1, Security Defaults Only
You cannot enable MFA Trust settings when the resource tenant does not have an Entra ID Plan 1 licence.
The note at the top of the screen says “Entra ID Premium”, and clicking the link will offer to activate Entra ID Plan 2 or the Entra Suite, but neither of these are needed as Entra Plan 1 is sufficient.
Because you cannot enable MFA Trust (or the other two trust options) your guest users need to configure MFA in your tenant, and you need to manage resets and risk of malicious use against the B2B Collaboration accounts that you are hosting, even though they are not users you manage. As shown below, when a user accesses a resource in a “Security Defaults” tenant, they need to register MFA in the resource tenant.
Ideally this would be a great addition to Security Defaults, as it means you don’t need to manage users outside of your tenant for their MFA access – just whether or not they are allowed to access your resources.
Once MFA is registered in this scenario, its just the same as it has been for years in Azure AD/Entra ID when their was no option for MFA Trust – the end user ends up collecting MFA registrations:
Then when it comes to time for a new phone, all that tends to happen is you do not go a renew your access to the resource tenant because you either cannot remember what the one file was you were shared or the reason to work with that tenant has ended or you have no way to contact their IT department to get your MFA reset – and you are not their user – you will probably find they have no idea what you are requesting from them anyway!
If you can remember the resource you are accessing then you cannot get access anyway unless you still have your old phone available and working and set up to receive authenticator push requests.
Photo by Scott Webb: https://www.pexels.com/photo/two-gray-bullet-security-cameras-430208/
Leave a Reply