A cloud-based identity and access management service for securing user authentication and resource access
Hello Akihiro Kushikawa,
Greetings! Thanks for raising this question in the Q&A forum.
This points to a provisioning failure that happened at the time the tenant was created, not something broken afterward. AADSTS50058 in the Azure portal context means the session has no usable token for that resource, and AADSTS16000 in the Entra admin center context means the directory cannot resolve which identity/tenant context to use for that operation. Both pointing back to the same tenant, combined with the missing initial *.onmicrosoft.com domain and NoSubscriptionsFound, indicates the tenant object was created but never finished the backend provisioning steps that normally assign the default domain and wire up the directory correctly. This is a known failure pattern when a brand new Entra tenant is created directly from a personal Microsoft account rather than through the standard Azure sign-up flow, and it is not something that can be fixed from the user side since the directory itself is incomplete.
- This is not a sign-in or permissions problem, so further sign-in retries will not help Since both portals authenticate successfully and only fail once they try to read tenant configuration, repeating sign-in attempts, clearing cache, or trying different browsers will not change the outcome. The fix has to happen on the backend provisioning side.
- Confirm there is truly no usable path inside either portal first While you have already checked Azure Portal and the Entra admin center, also try:
and the Microsoft 365 admin center athttps://entra.microsoft.com/#view/Microsoft_AAD_IAM/TenantOverview.ReactViewhttps://admin.microsoft.com, in case that surface, which uses a slightly different backend path, lets you reach Support even though the others don't. If it also fails the same way, that confirms the tenant level provisioning gap. - Since you cannot raise a support request through the broken tenant, use a channel that does not depend on it You do not need a working Azure portal session to get Microsoft's attention on a tenant provisioning defect. Use:
Choose Microsoft Entra ID as the product area and describe this as a tenant that failed to provision correctly, including the Tenant ID, both error codes, and the fact that the initial onmicrosoft.com domain never appeared. Phone or chat support through this portal does not require a working sign-in session to the affected tenant.https://support.microsoft.com/contactus - Provide the exact details below so the case routes correctly the first time
- Tenant ID:
f8cdef31-a31e-4b4a-93e4-5f571e91255a - Both error codes, AADSTS16000 and AADSTS50058, and where each one occurs
- Confirmation that no subscriptions or resources exist
- Confirmation that you are open to deletion if recovery is not possible
- Tenant ID:
- If support asks you to verify ownership without portal access Be ready to confirm the Microsoft account email used to create the tenant and the approximate date/time of creation, since that is what they will use to locate the provisioning record on their side.
- Going forward, create new Entra tenants through the standard Azure flow For future test tenants, create them from within an existing working Azure subscription or through
https://signup.azure.comrather than directly from a personal Microsoft account context, since that flow has more consistent provisioning behavior for the default domain and directory setup.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.