AADSTS500208 Error for Entra External ID Users in .NET 8 Multitenant App

Question

TLDR:

Users from Entra External ID without role assignments receive the error "AADSTS500208" when trying to log into a multitenant .NET 8 application. The login works fine for users from the workforce tenant and those with role assignments from the External ID tenant.

Goal: Enable users to log in without needing role assignments from the External ID tenant.

---

A collection of applications forms our SaaS service for customers, with a unified portal app allowing B2B customers to manage their systems.

Previously, a single tenant (our workforce) managed both internal users and customers. With the introduction of Entra External ID, we aimed to separate internal and external users into distinct tenants while keeping our application multitenant.

Despite working with this setup since the Entra External ID preview, numerous challenges have arisen. A specific issue remains unresolved, prompting this inquiry. A related issue was found here, but the response was insufficient.

The application registration resides in our Workforce tenant, and a service principal is created and configured in our External tenant. Various in-app configurations were tested without success across all users. Below are the modified values to ensure no internal information is disclosed.

appsettings.json

  "WorkforceTenant": {

    "Instance": 

    "https://login.microsoftonline.com",

    "Domain": "workforceDomain",

    "TenantId": "workforceTenantId",

    "ClientId": "workforceAppRegistrationClientId",

    "CallbackPath": "/signin-oidc"

  },   

  "MultiTenant": {

     "Instance": "https://login.microsoftonline.com",     "Domain": "common",     "TenantId": "common",     "ClientId": "workforceAppRegistrationClientId",     "CallbackPath": "/signin-oidc"   }, 

...```

**Program.cs**

`...`

`builder.Services.AddSingleton<IConfidentialClientApplication>(sp => ConfidentialClientApplicationBuilder.Create(builder.Configuration["WorkforceTenant:ClientId"])`

`    .WithClientSecret(builder.Configuration["WorkforceTenant:ClientSecret"])`

`    .WithAuthority(new Uri($"{builder.Configuration["WorkforceTenant:Instance"]}/{builder.Configuration["WorkforceTenant:TenantId"]}"))`

`    .Build());`

`builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)`

`    .AddMicrosoftIdentityWebApp(options =>`

`    {`

`        builder.Configuration.Bind("MultiTenant", options);`

`        options.TokenValidationParameters.ValidIssuers = new[]`

`        {`

`            "https://login.microsoftonline.com/{workforceTenantId}/v2.0",`

`            "https://login.microsoftonline.com/{externalTenantId}/v2.0"`

`        };`

`    })`

`    .EnableTokenAcquisitionToCallDownstreamApi()`

`    .AddDistributedTokenCaches();`

`...`

The above code allows successful logins for users from the workforce tenant and for external tenant users with administrative roles assigned, such as Global Administrator or Guest Inviter. However, the goal is to avoid granting B2B customers administrative roles in the External ID tenant, which leads to empty role assignments.

When users from the external tenant without role assignments attempt to log in, the following error is encountered:

> AADSTS500208: The domain is not a valid login domain for the account type.

Some discussions suggest that the ciamlogin.com endpoints should be utilized for External ID. Switching the multitenant configuration to that endpoint results in another error:

`"Authority": "https://{externalTenantId}.ciamlogin.com/{externalTenantId}/v2.0"`

the user is instead faced by another error

> AADSTS500206: The account type can't be used for the application you're trying to log into

This second error from the .ciamlogin.com is the same even if the user has role assignments assigned.

The users we use for our applications are of type "Member" and Creation type "Local account". The issue occurs regardless of whether users are added manually via the Entra ID Admin center or through our application integrating with the Graph API in the External ID tenant.

Any assistance would be greatly appreciated. 🙏

Appreciate any help.

Answer 1

Hi Daniel,

Its seems based on the the provided details, now you want users from an external tenant (set up for customers as you mentioned) to log in without requiring administrative roles. I am no expert but can give some pointers that might potentially resolve the issues you're facing with your Azure AD B2B configuration:

1. Authority Configuration:
   • You’ve attempted to use ciamlogin.com endpoints, which are specific to CIAM scenarios. Ensure that the app registration in your external tenant is set up to accept such logins. However, it appears there might be a disconnect because the error suggests an authority or account type mismatch.
   • Consider the use of common endpoints like https://login.microsoftonline.com/common for broad multi-tenant applications unless your scenario specifically requires ciamlogin.com.
2. Resource Tenant Setup:
   • In your workforce tenant, ensure that you’ve configured the application registration and have provided the necessary permissions:
   • API Permissions must include delegated permissions that external users need.
   • Consider using application permissions only if backend services are accessed without user context.
3. Check Role Requirements:
   • If role assignments are causing issues, verify if any RBAC (Role-Based Access Control) within the app itself requires roles for access.
4. Investigate User Type Handling:
   • Ensure that the local account users created in the Entra External ID tenant are mapped correctly within your application's authentication logic.
5. Consider Tenant ID and Domain Handling:
   • Ensure your configuration allows for multi-tenant access by using the common endpoint effectively. Avoid narrowly defined tenant IDs unless necessary.
6. Debugging Authentication Flows:
   • Use Azure AD’s diagnostic capabilities to trace failed sign-ins. Check for how tokens are being issued, what claims are present, and whether applications can still validate tokens correctly for these external users.
7. Application Code Configuration:
   • Since you have applications already working for certain conditions, ensure that the TokenValidationParameters do not inadvertently filter valid tokens.

Hope that help you resolve the issue. Do let me know if you get any success or have any follow up questions after applying above suggestions!

cheers!