Contents

You always trust your CSP - Cross Tenant MFA and GDAP

Entra ID Multifactor Authentication is on everyone’s mind, as Microsoft will enforce the usage of MFA for most of the Admin portals starting October 2024. But many in the industry are a step ahead and had MFA enforced already and are thinking about how to make MFA more convenient for everybody involved.

Let me introduce you to cross-tenant access settings for B2B collaboration and especially inbound trust settings for MFA. With this you can configure if you trust another tenants MFA configuration and don’t require the users from this tenant to setup a second set of MFA in your tenant.

This not only makes it more convenient for the external users to interact with resources in your tenant (e.g. join a Teams team or a Shared Channel), but also allows them use strong authentication methods to do so. As you see in the table below, normally a external user can only use a limited set of MFA methods. But if you trust the home tenants MFA, they now can use a lot more methods and even something strong like a passkey to meet your MFA requirements.

/en/trust-csp-cross-tenant-mfa-gdap/images/AuthenticationStrengthMfaMethodsForExternalUsers.png
Authentication strength MFA methods for external users

Cloud Service Providers and GDAP

With this knowledge in mind, let me introduce Cloud Service Providers (CSP) to the mix. A Microsoft CSP can offer their services to you as a customer and normally needs access to your environment to fulfill the service. For this Microsoft has created granular delegated admin privileges or GDAP for short.

With GDAP you enter a partner relationship with the CSP. You can check which relationships you currently have in the Microsoft admin portal.

/en/trust-csp-cross-tenant-mfa-gdap/images/GDAPrelationships.png
Granular delegated admin privileges in the Microsoft admin center

In this example my tenant has two relationships (you can have multiple, even with the same partner) and I granted them the Entra roles “Security Reader” and “Security Administrator”. This way the CSP can assign those roles in their tenant to identities and they can access my tenant without the need to create a single user for this partner in my tenant.

Sign-in logs

When a CSP user accesses my tenant this is logged in the User sign-ins logs. The actual username is hidden from the logs and only a general name like “ACME technician” is displayed. The user id can still be used to identify the actual user.

Also the cross tenant access type is marked as “Service provider”.

SigninLogs
| where TimeGenerated > ago(1h)
| where CrossTenantAccessType == "serviceProvider"
| project TimeGenerated, UserDisplayName, UserId, IPAddress, DeviceDetail, ResourceDisplayName

/en/trust-csp-cross-tenant-mfa-gdap/images/SigninLogsServiceProvider.png
Signin logs of a CSP user in Log Analytics

As you can see in this example from Log Analytics, other data like IP address and deviceId are completely or partially hidden from me as the customer.

Cross-Tenant access settings

So far so good.

Beginning in early 2024 there was a change and each CSP provider was automatically added to the cross-tenant access settings UI in the Entra portal.

/en/trust-csp-cross-tenant-mfa-gdap/images/CrossTenantAccessSettings.png
Inbound settings for this CSP is set to default, which does not trust MFA

When you look at the graph data for this entry (https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/partners) you can see that there is a special flag called isServiceProvider set to true for this partner setting.

/en/trust-csp-cross-tenant-mfa-gdap/images/isServiceProvider.png
A special flag for service providers

If you try to delete this cross-tenant access settings, even as global admin, this results in an error message.

Failure
Insufficient privileges to complete the operation.

/en/trust-csp-cross-tenant-mfa-gdap/images/InsufficientPrivilegesToCompleteTheOperation.png
Insufficient privileges to complete the operation.

The actual graph error message is

Failure
Service provider write not supported in impersonation flow.

/en/trust-csp-cross-tenant-mfa-gdap/images/ServiceProviderWriteNotSupportedInImpersonationFlow.png
Service provider write not supported in impersonation flow

You must delete the relationship through the Partner relationships in the Microsoft admin center.

Implicit MFA trust for CSPs

But now let’s come to the fun part. We have a method to configure incoming access settings including the ability to trust another tenants MFA. By default this setting is not configured for a CSP with a GDAP relationship.

/en/trust-csp-cross-tenant-mfa-gdap/images/InboundTrust.png
isMfaAccepted is set to false for this CSP according to the response

In a short unscientific poll on Twitter I asked how many of you would allow the CSP to “bring their own MFA”. A majority of my, more or less security interested participants, were not to thrilled.

/en/trust-csp-cross-tenant-mfa-gdap/images/TwitterPoll.png
64,6% of participants don't want to trust their service providers MFA

Personally I’m on the “Yes” category because I want to enforce phishing resistant auth methods and even device compliance if possible.

But for those of you which selected “No” I got bad news.

When a technician is accessing my tenant I can see that it shows the Authentication method as “Previously satisfied” for all all sign-ins and even that the user has used “Phishing-resistant MFA”.

/en/trust-csp-cross-tenant-mfa-gdap/images/PreviouslySatisfied.png
Previously satisfied, even if incoming MFA is not accepted?

/en/trust-csp-cross-tenant-mfa-gdap/images/PreviouslySatisfiedLogAnalytics.png
In Log Analytics the detailed information shows also only previously satisfied

SigninLogs
| where TimeGenerated > ago(1h)
| where CrossTenantAccessType == "serviceProvider"
| mv-expand todynamic(AuthenticationDetails)
| project AuthenticationDetails
| evaluate bag_unpack(AuthenticationDetails)
| sort by authenticationStepDateTime asc

Did you notice what this implies?

  • My tenant has a cross-tenant access setting that does NOT trust the incoming MFA for the service provider
  • The service provider has a unique tag set to true named isServiceProvider
  • The identity from the service provider tenant uses a phishing resistant authentication method

This means: My tenant trusts the service providers tenants MFA. Even if this is not visible in the UI or the Graph endpoint.

Note
One important note about this default behavior: It cannot be changed in any way. regardless of what you set using the UI or Graph.

Hello MSRC

After discovering this behavior around the 26.03.2024 I first thought it was a fluke or maybe just missing in the documentation. But when there was no change in documentation or behavior in July 2024 I decided to involve the MSRC.

/en/trust-csp-cross-tenant-mfa-gdap/images/meme.png
You documented all the changes, right?

My submission from 29.07.2024 was tracked as VULN-131330 and resolved on the 23.08.2024 with the following response.

Upon investigation, we determined that this issue is not of security concern. We have published guidance in the documentation below:

https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration#to-change-inbound-trust-settings-for-mfa-and-device-claims

Let us know if there are any concerns. We will be closing the case.

/en/trust-csp-cross-tenant-mfa-gdap/images/MSRCResponse.png
MSRC response detailing that this behavior is intended and now documented

What changed in the documentation on the 21.08.2024 is the following addition

this setting is not applied if an external user signs in using granular delegated admin privileges (GDAP), such as used by a technician at a Cloud Service Provider that administer services in your tenant. When an external user signs in using GDAP, multifactor authentication is always required in the user’s home tenant, and always trusted in the resource tenant.

/en/trust-csp-cross-tenant-mfa-gdap/images/GitHubDiff.png
Docs were changed on

It was later refined to the current text

Note that this setting is not applied if an external user signs in using granular delegated admin privileges (GDAP), such as used by a technician at a Cloud Service Provider that administers services in your tenant. When an external user signs in using GDAP, MFA is always required in the user’s home tenant, and always trusted in the resource tenant. MFA registration of a GDAP user is not supported outside of the user’s home tenant. If your organization has a requirement to disallow access to service provider technicians based on MFA in the user’s home tenant, you can remove the GDAP relationship in Microsoft 365 admin center.

Authentication Strength to the rescue

As I mentioned before I don’t really mind the change in behavior as it can bring more security, depending on the security posture of your partner. And since all Microsoft partners are required by their contract with Microsoft to enforce MFA they should already have a good security posture anyways (you do, or?).

/en/trust-csp-cross-tenant-mfa-gdap/images/RequireMFAForPartner.png
Microsoft requires partners to use MFA

Also if a user has not setup MFA in their home tenant, they can’t access your resources.

But what I mind is the lack in communication around this change. As you could see from my poll, many people felt they don’t want to trust the MFA of their CSP, but were already behind the scenes. There was no mention of it in any documentation that implied otherwise.

Some part of the official documentation are still not updated today and imply this trust is not present.

/en/trust-csp-cross-tenant-mfa-gdap/images/GDAPFrequentlyAskedQuestions.png
GDAP frequently asked questions

Mitigation

If you want to keep control over what kind of MFA method a service provider can use to access your tenant, you can create a Conditional Access Policy and enforce Authentication Strength.

This way you can ensure they are not using an SMS or phone call but are required to use a FIDO2 security key. I did a whole post on it when it was released, so if you are not familiar with it check it out:

Conditional Access Authentication strength

When you also trust incoming device compliance you can even go further and require the CSP to only work from a compliant device. Of course what is defined as compliant is out of your hands. But this closes the door for e.g. AiTM attacks.