
4su87 (4su87) asked a question.
Hi all,
This is a random one. I administer an o365 tenancy that has many hundreds of partner organisations working with us using the AAD/Entra ID B2B Guest functionality. We have conditional access policies which enforce MFA for any Guest who signs in to use our tenant. Until recently, this MFA was entirely performed by our tenant, regardless of whether the user had already passed MFA in their home AAD/Entra ID tenant, or using another provider such as Okta.
This was working fine, but was annoying for users - as they were being made to MFA twice with two sets of MFA details.
Microsoft released MFA Trust functionality: Trust multi-factor authentication from Microsoft Entra tenants: Select this checkbox to allow your Conditional Access policies to trust MFA claims from external organizations. During authentication, Microsoft Entra ID checks a user's credentials for a claim that the user completed MFA. If not, an MFA challenge is initiated in the user's home tenant. https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration
After a period of testing with some partner organisations, we enabled this feature for all partners. It has worked well, particularly for AAD/Entra ID only tenants. We're having some issues with organisations using Okta to perform MFA for users synced to AAD/Entra ID.
We think we've narrowed it down to a scenario where the user is not required to pass MFA in Okta to access their organisations system, as they are in a trusted IP location zone. So this user has not passed MFA in their home Okta or home Entra tenant. So when our Entra requests MFA, it throws the user back to that users home Entra to perform the MFA, which then throws the user back to Okta to perform the sign-in/MFA. The problem is when it gets back to Okta, I presume it checks the users conditions and says that MFA doesn't need to be performed because they are in a trusted zone - and it ignores why the request came from my Entra, the their Entra, then on to Okta. So the user signs in again, tries to get back to my Entra tenant, but because the user hasn't passed MFA, we hand them back to their home Entra tenant who hands them back to Okta. There are some assumptions in the mix here because I lose visibility of the user in parts of the process. We've been able to confirm that if that same user attempts to access our tenant from outside the Okta 'trusted' zone, and they are made to MFA to get to their home tenant, then the claim is successfully confirmed by out tenant using MFA Trust.
We've come up with 3 solutions:
- Obtain our partner organisations IP addresses and update our Entra Conditional Access policies to skip MFA for those users when they are in that location. This is not ideal as we will have issues maintaining this going forward.
- Have our partner organisation MFA all users regardless of location. We're not even going to ask them to do this, it's not going to happen.
- Disable MFA Trust for this organisation. This will mean those users go back to maintaining two sets of MFA methods - one in Okta and one in our tenant.
Has anyone else experienced this issue? Any suggestions on how we might be able to solve this?
Thanks,
Justin

Hello @4su87 (4su87) Thank you for reacting out to our Community!
It seems that the main cause of this issue is that your EntraID tenant requires MFA token when the user accesses your application, regardless if they have "passed" the MFA on the Okta side by beeing in their company Trusted zone.
In this case I would say the best option is to disable the MFA Trust for that organisation. Since they will pass the MFA in Okta they will only be prompted for 1 MFA, as long as they are in the zone.
--
Ask the Experts: Okta Device Access Product Team Now Thru 3/22