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.
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.
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
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.
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.
If you try to delete this cross-tenant access settings, even as global admin, this results in an error message.
The actual graph error message is
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.
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.
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”.
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.
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.
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:
Let us know if there are any concerns. We will be closing the case.
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.
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?).
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.
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.