AADSTS500200 error when using personal Microsoft account to grant access to Azure Resource Manager

Ashish Sharma 0 Reputation points
2026-03-16T20:49:04.87+00:00

AADSTS500200 error when using personal Microsoft account to grant access to Azure Resource Manager (https://management.azure.com/user_impersonation) despite correct app configuration

I'm building a .NET Web API where users (with any Microsoft account – work/school or personal like Outlook/Gmail) can connect their Microsoft account. After connecting, my backend needs to programmatically create Azure resources (VMs, web apps, etc.) on their behalf using the Azure Resource Manager API.

1. Requirement

  • Users log in to my app using email/password (local JWT authentication).
  • They then link their Microsoft account via OAuth 2.0 (delegated permissions) to allow my app to manage Azure resources in their subscription.
  • My app must obtain a refresh token with https://management.azure.com/user_impersonation scope so it can later acquire access tokens and call ARM APIs to deploy resources.

User's image

User's image

2. Problem When I initiate the OAuth flow using the v2.0 endpoint with the scope https://management.azure.com/user_impersonation, personal Microsoft accounts (e.g., @outlook.com, @gmail.com) fail with the following error after login:

AADSTS500200: User account '{email}' is a personal Microsoft account. Personal Microsoft accounts are not supported for this application unless explicitly invited to an organization.

it's also happening via tried with Work/school accounts. The same error occurs even if I use the v1.0 endpoint with resource=https://management.azure.com/ instead of scopes.

3. What I've tried

Verified that my app registration in Azure AD is configured for "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts" (the third option). The manifest shows "signInAudience": "AzureADandPersonalMicrosoftAccount".

Added and granted admin consent for both Microsoft Graph (User.Read) and Azure Service Management (user_impersonation) delegated permissions.

Set a verified publisher domain under Branding & properties (required for apps supporting personal accounts).

Registered the exact redirect URI (https://localhost:7001/api/v1/azure/callback) under Web platform.

Tried the v1.0 OAuth endpoint with resource parameter (as suggested for personal accounts) – same error.

Tested with a brand new, never-used personal Outlook account – still fails.

Checked that the personal account has an active Azure subscription.

Despite all these steps, the error persists. I've searched extensively but can't find a solution.

Could anyone point out what I'm missing? Is there an additional configuration required for personal Microsoft accounts to consent to Azure Service Management permissions? Or is there a known limitation with delegated user_impersonation for personal accounts?

Any help would be greatly appreciated!

AADSTS500200 error when using personal Microsoft account to grant access to Azure Resource Manager (https://management.azure.com/user_impersonation) despite correct app configuration

I'm building a .NET Web API where users (with any Microsoft account – work/school or personal like Outlook/Gmail) can connect their Microsoft account. After connecting, my backend needs to programmatically create Azure resources (VMs, web apps, etc.) on their behalf using the Azure Resource Manager API.

1. Requirement

Users log in to my app using email/password (local JWT authentication).

They then link their Microsoft account via OAuth 2.0 (delegated permissions) to allow my app to manage Azure resources in their subscription.

My app must obtain a refresh token with https://management.azure.com/user_impersonation scope so it can later acquire access tokens and call ARM APIs to deploy resources.

2. Problem
When I initiate the OAuth flow using the v2.0 endpoint with the scope https://management.azure.com/user_impersonation, personal Microsoft accounts (e.g., @outlook.com, @gmail.com) fail with the following error after login:

AADSTS500200: User account '{email}' is a personal Microsoft account. Personal Microsoft accounts are not supported for this application unless explicitly invited to an organization.

it's also happening via tried with Work/school accounts. The same error occurs even if I use the v1.0 endpoint with resource=https://management.azure.com/ instead of scopes.

3. What I've tried

Verified that my app registration in Azure AD is configured for "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts" (the third option). The manifest shows "signInAudience": "AzureADandPersonalMicrosoftAccount".

Added and granted admin consent for both Microsoft Graph (User.Read) and Azure Service Management (user_impersonation) delegated permissions.

Set a verified publisher domain under Branding & properties (required for apps supporting personal accounts).

Registered the exact redirect URI (https://localhost:7001/api/v1/azure/callback) under Web platform.

Tried the v1.0 OAuth endpoint with resource parameter (as suggested for personal accounts) – same error.

Tested with a brand new, never-used personal Outlook account – still fails.

Checked that the personal account has an active Azure subscription.

Despite all these steps, the error persists. I've searched extensively but can't find a solution.

Could anyone point out what I'm missing? Is there an additional configuration required for personal Microsoft accounts to consent to Azure Service Management permissions? Or is there a known limitation with delegated user_impersonation for personal accounts?

Any help would be greatly appreciated!

Microsoft Security | Microsoft Entra | Microsoft Entra ID

1 answer

Sort by: Newest
Most helpful Newest Oldest

  1. AI answer

    2026-03-16T20:49:50.93+00:00

    AADSTS500200 in this scenario is caused by using the wrong authority/endpoint for the type of accounts that should sign in, not by the user_impersonation permission itself.

    For an app whose signInAudience is AzureADandPersonalMicrosoftAccount, the authorization request must target one of the “common” endpoints that accept both organizational and personal accounts. If the request is sent to a tenant‑specific authority such as:

    https://login.microsoftonline.com/<YourTenantNameOrID>

    then:

    • Only users from that tenant can sign in.
    • Users from other organizations or personal Microsoft accounts will fail with errors like AADSTS50020/500200 indicating that the account is not supported for this application.

    To fix this, change the authority used in the OAuth flow to match the supported account type of the app registration:

    • For multitenant organizational accounts only:
      https://login.microsoftonline.com/organizations
    • For multitenant + personal Microsoft accounts (your case):
      https://login.microsoftonline.com/common
    • For personal Microsoft accounts only:
      https://login.microsoftonline.com/consumers

    Configure this URL as the Authority (or authorization endpoint base) in the .NET app and in any manual authorization/consent URLs that are generated. Once the correct /common (or /consumers) endpoint is used, personal Microsoft accounts can complete the sign‑in and consent flow, and the app can request tokens for https://management.azure.com/.default or https://management.azure.com/user_impersonation as designed.

    If organizational users from other tenants should also be able to sign in, avoid tenant‑specific authorities in all authorization and token requests; otherwise they will also receive the same error.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.