The time comes to change or remove a CSP. So you go about your directory removing configuration that allows the CSP to have remote admin access to your tenant.
You might do this anyway, even if the CSP is still a current partner, because there is the inherent risk that the CSP is a backdoor route into your organization and a route for malicious actors.
One of the things to “tidy up” is to remove exemptions in your Conditional Access rules for “service provider users” – this is a class of external tenant that has the “IsServiceProvider” flag set to true when you query the Cross-Tenant Access Policy in Graph.
So you try to remove the Cross-Tenant access settings for your partner using Graph. You might try these:
Connect-MgGraph -scopes "Policy.Read.All"
Get-MgPolicyCrossTenantAccessPolicyPartner
The above will get you a list of your cross-tenant partners – returning each and showing TenantID and if any are “IsServiceProvider”:
Then using Graph you try to delete it – but you get an error message when trying to delete it via Graph or via the Entra portal:
Connect-MgGraph -scopes "Policy.ReadWrite.CrossTenantAccess"
Remove-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
The error reads (via Graph): “Service provider write not supported in impersonation flow.” Or, via the Entra portal you get “insufficient privileges”:
The reason for this is that the CSP organization is still recorded in the M365 Admin Console as your partner. In https://admin.microsoft.com : Settings > Partner Relationships the partner is listed under “Granular delegated administrative privileges (GDAP)”. Remove the partner from here – they don’t stop being your partner, but it means they cannot use accounts from the partner to manage your tenant – you need to provide accounts, and preferable with MFA and restrictions you would give your own users.
Once the partner relationship is deleted, its possible to use either Graph or Entra portal to remove the cross-tenant relationship as “IsServiceProvider” is now false.
Conditional Access rules that have inclusions/exclusions for “Service provider users” for guest or external users will no longer apply to this remote tenant. Tidy these up if you are moving/removing the CSP. If you are just securing your tenant some more you should leave the cross-tenant relationship in place and ensure that MFA Trust is enabled for it, or for the default organization relationship.
When the cross-tenant relationship and GDAP configuration was in place, (isServiceProvider=true), then MFA Trust was turned on implicitly.
MFA Trust ensures that any Entra ID MFA done source tenant is trusted through to your resource tenant, and allows the source users a greater scope of MFA Authentication Methods – for example, users in their own tenant can do passkeys, but guests in your tenant cannot. If the guest MFA is trusted via the cross-tenant trust, then the guest can do passkeys in their own tenant and have that trusted through to your tenant – a win/win all around. This is laid out in the table below and which can be found here:
Therefore removing the GDAP relationship and leaving the cross-tenant relationship in place means that MFA Trust was in use, but is no more in use. Therefore MFA Trust should be turned back on.
In addition to MFA Trust, you can also trust compliant devices from the CSP (and any other) guest tenant. This would mean that your service desk/technical staff from the CSP, who are listed in you sign-in logs as “service provider” and not by individual name, might be required by your CA rules to use a compliant device from their org to access your resources.
Add Authentication Strength’s to this and you can force your guests to use phish resistant authentication as well. I would say thats a win/win/win for all!
Photo by Pixabay: https://www.pexels.com/photo/brown-field-and-blue-sky-46160/
Leave a Reply