GCC High: Unable to authenticate to Defender (Connect-IPPSSession) via app-only auth (Service Principal)

[buidav]

🐛 Summary

When attempting to ScubaGear with Defender against a GCC High tenant we're unable to authenticate to Security & Compliance via the Connect-IPPSSession cmdlet. This causes the Security & Compliance cmdlets to fail and show up as errors on the report.

Note that this error does not appear when running via the default interactive login.

Export-DefenderProvider : Error running Connect-IPPSSession. Connecting to remote server ps.compliance.protection.office365.us failed with the following error message : The WS-Management
service does not support the SOAP version specified in the request. For more information, see the about_Remote_Troubleshooting Help topic.

To reproduce

Invoke-SCuBA -ProductNames defender -CertificateThumbprint "examplethumbprint" -AppID "exampleid" -Organization gcchightenant.onmicrosoft.us -M365Environment gcchigh

Expected behavior

No errors occur on GCC High tenants when running via app-only auth.

Any helpful log output or screenshots

[buidav]

Found the fix! This requires no code changes to ScubaGear itself.
The strategy of just waiting for a fix to appear worked out.

TLDR

• Use Microsoft Exchange Online Protection's Exchange.ManageAsApp scope NOT Office 365 Exchange Online's Exchange.ManageAsApp scope which our SPs have been using. See latest 08/13/2024 comment
• User roles such as Global Reader or Exchange Admin/Security and Compliance admin still need to be assigned to the SP for our functional tests/regular ScubaGear

Long version

The documentation below was added on August 22nd, 2023 to the App Registration docs.
https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#modify-the-app-manifest-to-assign-api-permissions
Ensure that these scopes specifically are added to the App's manifest for Security and Compliance PowerShell in GCC High and DOD.

Note

You can assign these scopes directly using the GUI no need to modify the app manifest directly like the documentation point us to. Not sure why the documentation points to the complicated route first.

"requiredResourceAccess": [
    {
        "resourceAppId": "00000007-0000-0ff1-ce00-000000000000",
        "resourceAccess": [
            {
                "id": "455e5cd2-84e8-4751-8344-5672145dfa17",
                "type": "Role"
            }
        ]
    },
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000", 
        "resourceAccess": [
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            }
        ]
    }
],

What we were specifically missing was this "resourceAppId" 00000007-0000-0ff1-ce00-000000000000
which corresponds to Microsoft Exchange Online Protection.

Adding the JSON above to the App's manifest and granting this specific Exchange.ManageAsApp fixes our authentication issues.

Note that 00000003-0000-0000-c000-000000000000 is Microsoft Graph
and the ID e1fe6dd8-ba31-4d61-89e7-88639da4683d is just the User.Read which is usually granted by default for all applications.

So just this snippet under the requiredResourceAccess key is all we need.

    {
        "resourceAppId": "00000007-0000-0ff1-ce00-000000000000",
        "resourceAccess": [
            {
                "id": "455e5cd2-84e8-4751-8344-5672145dfa17",
                "type": "Role"
            }
        ]
    },

.

[schrolla]

Based on the above then, is the fix to point to this solution and permissions in the README so GCC High users are aware?

[schrolla]

@buidav Just following up. Are there any documentation changes needed (README additions) or can we consider this issue resolved and close?

[buidav]

@buidav Just following up. Are there any documentation changes needed (README additions) or can we consider this issue resolved and close?

This is resolved on our end in the test tenants.
However, I was going to add the documentation updates to #218 since they are highly related.

[buidav]

Update both Microsoft Exchange Online Protection's Exchange.ManageAsApp scope AND Office 365 Exchange Online's Exchange.ManageAsApp are needed to successfully authenticate to GCC High.

Contrary to what the documentation says.