Azure Portal Access Issue After Free Azure Account Creation (AADSTS5000228 / AADSTS16000)

Question

Azure Portal Access Issue After Free Azure Account Creation (AADSTS5000228 / AADSTS16000)

Bogdan Kobzak 0

Subject: Azure Portal Access Issue After Free Azure Account Creation (AADSTS5000228 / AADSTS16000)

Hello,

I am attempting to create a free Azure account for development and application registration, but I am consistently encountering errors when trying to sign in to the Azure Portal.

My Goal: To gain access to the Azure Portal in order to register an application within my new Azure AD directory (PII).

Steps Taken:

1.

I attempted to join the Microsoft 365 Developer Program but did not qualify.

2.

Subsequently, I initiated the process of creating a free Azure account.

3.

During the registration process, I successfully created an administrator account for a new directory: PII.

4.

When attempting to sign in to the Azure Portal (portal.azure.com) using both my personal Microsoft account (PII) and the new administrator account (PII), I consistently receive errors indicating a denial of access to a tenant that is not my own directory.

Problem: The Microsoft authentication system appears to be incorrectly routing my request. Instead of directing me to my own OmegaLauncher.onmicrosoft.com directory, it attempts to authenticate me against a different tenant (with ID or the 'Microsoft Services' tenant), to which my accounts do not have access.

Error Details I Received:

Error 1 (repeatedly):
Error code: interaction_required

Error message: interaction_required: AADSTS5000228: Access to '' tenant is denied. Please contact your administrator.

Trace ID: Correlation ID:

Timestamp: 2026-05-03 11:59:13Z
Error 2 (upon sign-in attempt):
Error message: Selected user account does not exist in tenant 'Microsoft Services' and cannot access the application in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.
Error 3
{

"sessionId": "",

"errors": [

{

  "errorMessage": "interaction_required: AADSTS16000: User account &#39;{EUII Hidden}&#39; from identity provider &#39;live.com&#39; does not exist in tenant &#39;Microsoft Services&#39; and cannot access the application &#39;&#39;(Microsoft_Azure_SupportPortalExtension) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account. Trace ID: 2822f296-cfb8-47b8-8bd0-966483837000 Correlation ID: 493ca730-910e-40b0-b19b-ef45cd9a9fc5 Timestamp: 2026-05-03 12:03:28Z",

  "clientId": "PII",

  "scopes": [

    "/.default"

  ]

}
  ]

}  
My Accounts:



I am unable to access my own directory and register my application. I kindly request your assistance in resolving this access and authentication routing issue.

Thank you.

Moved from: Microsoft 365 and Office | Subscription, account, billing | For business | Other

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-04T01:10:42.6766667+00:00
Hello Bogdan Kobzak

Based on your description, it appears that you have created a Microsoft personal account, not an Azure work or school account. This is why you’re encountering errors when trying to access the Azure Portal.

Issue: When users try to login to Azure portal using their personal Microsoft Account (Outlook, Hotmail..) they are getting AADSTS160021 or AADSTS16000 or AADSTS50020 errors.

Reason: When signing in to the Azure portal with a personal Microsoft account, you are automatically connected to the Microsoft Services tenant (Tenant ID: f8cdef31-a31e-4b4a-93e4-5f571e91255a).

You can verify this by navigating to Microsoft Entra ID > Overview, where you’ll see this Tenant ID.

This default tenant does not have a directory associated with it, which you can confirm by going to the Settings blade. As a result, you cannot perform administrative actions such as:

Creating users or groups

Registering enterprise applications

Managing resources

In short, it’s a system tenant with restricted capabilities, and administrative access is not granted by default.

Solution: To fully utilize the Azure portal, you need to create your own tenant instead of relying on the Microsoft Services tenant.

Follow these steps:

Open an in-private/incognito browser window (to avoid automatic sign-in via SSO).

Navigate to https://azure.microsoft.com/en-us/free/ to sign up for a free Azure account.

During the setup, you’ll be prompted to create a new directory (tenant). Once completed, you will become the Global Administrator of this new tenant, giving you full access to manage Azure resources.

Let me know if you need help with the sign-up process or configuring your new tenant.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-05T10:13:30.8633333+00:00

Hello Bogdan Kobzak

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

1 answer

Your answer

Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-04T01:10:42.6766667+00:00

Hello Bogdan Kobzak

Based on your description, it appears that you have created a Microsoft personal account, not an Azure work or school account. This is why you’re encountering errors when trying to access the Azure Portal.

Issue: When users try to login to Azure portal using their personal Microsoft Account (Outlook, Hotmail..) they are getting AADSTS160021 or AADSTS16000 or AADSTS50020 errors.

Reason: When signing in to the Azure portal with a personal Microsoft account, you are automatically connected to the Microsoft Services tenant (Tenant ID: f8cdef31-a31e-4b4a-93e4-5f571e91255a).

You can verify this by navigating to Microsoft Entra ID > Overview, where you’ll see this Tenant ID.

This default tenant does not have a directory associated with it, which you can confirm by going to the Settings blade. As a result, you cannot perform administrative actions such as:

Creating users or groups

Registering enterprise applications

Managing resources

In short, it’s a system tenant with restricted capabilities, and administrative access is not granted by default.

Solution: To fully utilize the Azure portal, you need to create your own tenant instead of relying on the Microsoft Services tenant.

Follow these steps:

Open an in-private/incognito browser window (to avoid automatic sign-in via SSO).

Navigate to https://azure.microsoft.com/en-us/free/ to sign up for a free Azure account.

During the setup, you’ll be prompted to create a new directory (tenant). Once completed, you will become the Global Administrator of this new tenant, giving you full access to manage Azure resources.

Let me know if you need help with the sign-up process or configuring your new tenant.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-05-05T10:13:30.8633333+00:00

Hello Bogdan Kobzak

Following up to see if the above provided information was helpful. If you have any further queries do let us know.

Answer 1

The sign-in errors indicate that the accounts are being authenticated against the wrong tenant (“Microsoft Services” / tenant ID 1379c189-7504-4a55-b193-5a2481634bf6) instead of the OmegaLauncher.onmicrosoft.com tenant, and that the account does not exist in that tenant.

Based on the provided context, there are two main patterns that match this behavior and provide concrete remediation steps:

Account is being treated as a personal Microsoft account and routed to the Microsoft Services tenant
When a personal Microsoft account (for example, Outlook, Hotmail, or other MSA) is used to access Microsoft Entra admin center or Azure resources, it is associated with the Microsoft Services tenant by default. In that tenant there is no linked directory where directory-level actions (like app registration) can be performed. This is expected behavior and leads to errors that the account does not exist in the target tenant and cannot access the application. In this scenario, to have a directory where app registrations and Entra ID operations are possible, an Azure account with its own tenant must be created. The documented steps are:
1. Go to the Azure account signup page (for example, via Try Azure for free).
2. Complete creation of an Azure account.
3. A new tenant is created alongside the Azure account, and the creator is made Global Administrator of that tenant, with full access to that directory.
This ensures that sign-in is associated with a tenant where directory operations are allowed, instead of the Microsoft Services tenant.
Sign-in is being forced to a tenant where the account does not exist (AADSTS50020 / AADSTS16000 pattern)
The error message pattern:

User account from identity provider does not exist in tenant and cannot access the application. The account needs to be added as an external user in the tenant first.

matches the documented AADSTS50020/AADSTS16000 behavior where:
- The account is from one identity provider (for example, live.com / personal Microsoft account),
- The sign-in is being processed against a different tenant (for example, Microsoft Services or another organization’s tenant), and
- The account is not present as a guest in that tenant.
In such cases, the guidance is:
- The account must either be added as an external user in that tenant, or
- The sign-in must be directed to the correct tenant where the account actually exists and has permissions.
For application sign-in scenarios, this is often caused by using an endpoint that forces authentication to a specific tenant instead of allowing organizational or common accounts. The documented fix is to use the correct sign-in URL/authority for the intended audience:
- Multitenant apps: https://login.microsoftonline.com/organizations
- Multitenant + personal accounts: https://login.microsoftonline.com/common
- Personal accounts only: https://login.microsoftonline.com/consumers
If an endpoint like https://login.microsoftonline.com/<SomeOtherTenantId> is used, users from other tenants cannot sign in unless added as guests.
Practical steps to regain access to the correct Azure tenant
From the context, the following concrete actions are supported and applicable to similar “wrong tenant / blocked tenant / misrouted sign-in” issues:
1. Clear cached sign-in state and try again
  One documented resolution for being unable to access Azure due to persistent wrong-tenant routing is to:
  - Sign out of all Microsoft accounts in the browser.
  - Clear all site data / cookies for Microsoft and Azure sign-in pages.
  - Then attempt sign-in again.
2. Ensure sign-in is explicitly targeting the correct tenant
  If sign-in keeps going to Microsoft Services or another tenant, explicitly target the correct tenant in the Azure portal URL by including the tenant name or ID. For example, use the pattern:
  - https://portal.azure.com/<TenantName>.onmicrosoft.com or
  - https://portal.azure.com/<TenantId>
  This pattern is documented as a way to reach a specific tenant when a tenant is blocked or inaccessible and can help bypass automatic routing to Microsoft Services or another tenant.
3. If the tenant is blocked or inactive
  If a tenant has been blocked due to inactivity (AADSTS5000225), the documented options are:
  - A tenant administrator can request reactivation within 20 days by contacting Microsoft via global support phone numbers.
  - Alternatively, sign up again via the Azure signup flow, which may recognize an existing free account and prompt to upgrade to a pay-as-you-go account to restore access.
  While the error codes in the question are AADSTS5000228 and AADSTS16000, the remediation pattern for blocked/inaccessible tenants shows that explicitly targeting the tenant and, if necessary, going through the signup/upgrade flow can restore access.
When the account does not exist in the tenant at all
For errors that state the account does not exist in the tenant and cannot access the application (AADSTS50020/AADSTS16000 pattern), the documented resolution is:
- The account must be added as an external user in that tenant before it can access the application, or
- A different account that is already part of that tenant must be used.
If there is no other Azure AD account in that tenant and the account is purely a personal Microsoft account, it cannot add itself as an external user to that tenant. In such cases, the practical path is to:
- Use or create an Azure account that has its own tenant (as in point 1), and
- Perform app registrations and directory operations in that tenant instead of trying to use the Microsoft Services tenant.

In summary, the supported remediation steps from the context are:

Use an Azure account that has its own tenant (created via the Azure signup flow) so that sign-in is not tied to the Microsoft Services tenant.
Clear all browser sign-in state and explicitly target the correct tenant in the Azure portal URL using the tenant name or ID.
Ensure that any application sign-in flows use the correct authority URL (organizations, common, or consumers) rather than a hard-coded tenant that the account does not belong to.
If a tenant is blocked or inactive, follow the documented reactivation or upgrade paths, or contact Microsoft support as the tenant administrator.

References: