Problem with SSO between Azure gov cloud and Azure National Cloud?

[jblanchard]

I’ve run into a problem I haven’t seen before. I am trying to get a customer set up with an AAD connection to our SaaS product. I went through the whole process as I have with other operational customers, but this one threw a curveball at me.

The error we receive is:

AADSTS900381: Request redirection failed. Tenant ‘.onmicrosoft,com’ specified belongs to the National Cloud ‘MicrosoftOnline,COM’, but Current Cloud Instance ‘microsoftonline,us’ does not federate with ‘MicrosoftOnline,COM’/

This error seems to imply that because our SaaS product is in the gov cloud, and the customer tenant is part of the “National Cloud ‘MicrosoftOnline,COM’”, they can’t federate. From what I gather, National Cloud means “physically isolated instance of Azure”.

For reference, we use the Auth0 .NET SDK’s AuthenticationApiClient’s to create the redirect uri, as well as validate the token response.

Is this something in Auth0’s court, our court (the SaaS product in the gov cloud) or our customer’s court (the AAD in the National Cloud)?

I’m not quite sure who to talk to about this.

(I replaced addresses with comma, since the forum thought they were links and wouldn’t let me post)

[ktal90]

Hello. Was this ever resolved? I’m getting a similar error trying to connect to a customer’s Azure AD in their Azure Government. I am getting AADSTS900432: Confidential Client is not supported in Cross Cloud request. My guess is that this is because the connection in Auth0 is hitting https://login.microsoftonline.com instead of https://login.microsoftonline.us. Auth0 team, is it possible for you allow us to hit another Azure AD endpoint to support connecting to Azure Government?

[jblanchard]

I’m still not sure if I’ve gotten to the bottom of the problem yet. Here’s the latest:

The gist of the response I got from Auth0:
After discussing this with the rest of the Support Team, the recommendation here would be to instead create an Enterprise OIDC connection instead. The reason being is that this will allow you to configure any domain URL. One of our Staff Support Engineers Nico wrote up a rather comprehensive how-to for just this type of situation:

Connect to Azure AD using an OIDC Enterprise connection

Question: How can I connect to Azure AD using an Enterprise OIDC connection? Why would I? Answer: Auth0 offers the Azure AD connection type to connect to Azure AD domains. It works well, but you can also use a generic OIDC Enterprise connection to connect to Azure AD. Here’s why you’d want to use an OIDC Enterprise connection instead of the built-in Azure AD connection: The OIDC Enterprise connection uses the Implicit grant (*) by default. It does not require a client secret to be configure…

The response I got from Microsoft about this:
On 1 June 2018, the official Azure Active Directory (AAD) Authority for Azure Government changed from https://login-us.microsoftonline.com to https://login.microsoftonline.us. This change also applied to Microsoft 365 GCC High and DoD, which Azure Government AAD also services. If you own an application within a US Government tenant, you must update your application to sign users in on the .us endpoint. Starting in July 2020, Azure AD will begin enforcing the endpoint change for public cloud users, blocking public cloud users from signing into apps hosted in US Government tenants (microsoftonline.us tenants).

See: Azure Government AAD Authority Endpoint Update | Azure Government (microsoft.com)

See: Azure Government Identity - Azure Government | Microsoft Docs

[ktal90]

Thanks @jblanchard!

Auth0 team, could you please allow us to set the Azure AD endpoint so we can reliably and easily allow Azure Government users to authenticate with us?