Entra External Id with Microsoft Identity throwing AADSTS500208 unless user is Global Admin

I have a bizarre issue happening. We have two levels of user managed in our Entra Customer (preview) tenant using Microsoft Entra External Id (in preview). Advisor and Client.

Advisors are only added through direct invitation and granted the Advisor group in the tenant. Advisor accounts are created in an older Azure AD workforce tenant (our corporate accounts).

Clients are able to register through our User Flow for the application and are added to a Client group.

Our application is a .net 8.0 blazor interactive mode application using Microsoft.Idenity with a DownstreamApi.

Advisors can hit our site, be redirected to the Entra User Flow to sign in, and then are brought back to our application with claims.

Clients hit the site, go to authenticate, and then an error is thrown when they are returned to /sign-in/oidc. My test client account was created through the user flow using a gmail account (but not using google oauth, just the email).

The error in my logs:

Message contains error: 'invalid_request', error_description: 'AADSTS500208: The domain is not a valid login domain for the account type. Trace ID: <> Correlation ID: <> Timestamp: 2024-05-24 14:54:37Z', error_uri: 'error_uri is null'.

The AzureAD section for my application, which works fine for advisors in out Test environment in Azure, is as follows:

"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "33...33",
  "ClientId": "bb...bb",
    
  "EnablePiiLogging": false, // set to true to enable PII


  // If the app calls downstream APIs
  "ClientCredentials": [
    
    {
      "SourceType": "ClientSecret",
      "ClientSecret": "<<omitted>>"
    }
  ],
  "SendX5C": false,

  "AllowWebApiToBeAuthorizedByACL": false,

  // If the app is a web app:
  "ResetPasswordPath": "/MicrosoftIdentity/Account/ResetPassword",
  "ErrorPath": "/MicrosoftIdentity/Account/Error",
  "WithSpaAuthCode": false,

  "Scopes": [ "User.ReadBasic.All", "user.read", "email" ]
},

// Downstream APIs
"DownstreamApis": [
  {
    "ClaimsProvider": {
      "BaseUrl": "https://my-api.azurewebsites.net/api",
      "Scopes": [ "api://my-api.azurewebsites.net/88...88/ClaimsProvider.Read" ]
    }
  }
]

I thought perhaps there was bleed-through on my corporate account, so I ran my test in an incognito browser instance and what appears to happen is after I log in and it sends me to my application at /sign-in/oidc, if I retry accessing the root url it sends me back to the user flow again as if my first login was never done/persisted. This is in the same incognito window without closing. There is no error in the userflow when I login, only after I land back in the application on the default redirect page, which works just fine for advisor accounts.

The account in Entra created when I register through the user flow:

User type: Member
Creation Type: Local account
Identities: myFakeAccount@example.com

And the advisor Accounts who got the invitation and work look like this:

User type: Member
Creation Type: Invitation
Identities: ExternalAzureAd

We also have this issue with any local developers who are not in the Global Admin group. They have 2 Azure accounts attached to VS (one for corporate, one for the customer tenant), but when they try to access the app with the above configuration, they get the same error. Changing the AzureAd config locally to the below fixes it for their Advisor account but does not fix the Client account when the same config is deployed into Azure

"AzureAd": {
  "Authority": "https://33...33.ciamlogin.com/33...33/v2.0",
  "Instance": "https://33...33.ciamlogin.com/33...33/v2.0",
  "Domain": "myTenant.onmicrosoft.com",
  "ClientId": "bb...bb",

  //... rest of config the same
}

The App service is hosted on our corporate tenant subscription in Azure and configured to use the Entra Customer tenant for authentication. The app service in Test is configured as:

App Service authentication: Enabled
Restrict access: Allow unauthenticated requests
Token store: Enabled

My Identity Provider is configured as:

Identity provider: Microsoft
App registration: Unable to resolve app registration name from registered application ID
Supported account types: Unable to resolve account type information from registered application ID
Application (client) ID: bb...bb
Client secret value: Click to edit secret value
Issuer URL: https://myTenant.ciamlogin.com
Allowed token audiences: [blank]
Client application requirement: Allow requests only from this application itself
Identity requirement: Allow requests from any identity
Tenant requirement: Allow requests from specific tenants
Allowed tenants: 33...33

UPDATE

Based on a recommendation from someone at MSFT, I updated my Entra applications to change the sign in user type in the manifest.

"signInAudience": "AzureADandPersonalMicrosoftAccount",

Which, according to this resource should allow any type of account to have access.

But, now when trying to access the downstream API, I'm getting a new error that I can't seem to find much information on.

AADSTS500207: The account type can't be used for the resource you're trying to access.

I was able to get around this issue by changing the configuration.

{
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "33...33",
  "ClientId": "bb...bb",

must be changed to

{
  "Instance": "https://33...33.ciamlogin.com./33...33/v2.0",
  "Authority": "https://33...33.ciamlogin.com./33...33/v2.0",
  "Domain": "myEntraTenant.onmicrosoft.com",

I was able to get help from MSFT support, so I'd like to share the information they gave me in hopes it will help someone in the future.

One very important point is that you are working with an "Entra ID External Identities" tenant (often referred to as a CIAM tenant or "Customer Identity Access Management").

I believe that an important part of the change that caused authentication to begin working was changing login.microsoftonline.com to {TenantId}.ciamlogin.com as this is how External Identities user flows must be called. The "login.microsoftonline.com" domain is for "internal" Oauth2 flows. For example, in your workforce tenant, all authentication http requests will be made with a domain of "login.microsoftonline.com". This changes for External Identities.

and they provided a reference to this documentation

On a side note, if you are running locally in your dev environment using an Azure AD account that exists in multiple tenants, if you are not a Global Admin you might see the error:

AADSTS500207: The account type can't be used for the resource you're trying to access

We resolved this by having developers change their local configs to use the second configuration instead of the first.