Problem statement
An enterprise connection has been configured in a tenant to connect Auth0 to Microsoft Azure Active Directory (“Azure AD” ).
The connection is used to support logins from:
- the customer’s own Azure AD domain
- Azure AD domains that belong to “downstream” customers
For example, a customer may have hundreds of “downstream” enterprise customers, each of which has their own Azure AD domain. However, it is necessary to authenticate these employees despite not knowing their domains.
If a user is not a member of the customer’s business organization, an attempt to log in results in the message “access_denied” being displayed, together with the error code AADSTS50020 :
AADSTS50020: User account … from identity provider … does not exist in tenant ‘mysaas’ and cannot access the application ‘<app_name>’ 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.
As a result, users cannot log in via the Azure AD connection.
Symptoms
When a user attempts to login via an Azure AD connection, the authentication flow halts and the user is presented with a message that is similar in form to:
*AADSTS50020: User account from identity provider does not exist in tenant ‘’ and cannot access the application ‘<app_name>’ 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.*
The error message may be accompanied by several related details about the Azure AD sign in failure.
Troubleshooting
This may be a Azure AD configuration issue. As a first step, general guidance for troubleshooting error AADSTS50020 can be found in the Microsoft document: Error AADSTS50020 - User account from identity provider does not exist in tenant
Solution
Reason for observed behavior
The key requirement here is to permit a user to login with an Azure AD connection, even if the user is not associated with the Azure AD domain. However, this is not possible by default. This is because provisioning an Azure AD connection will result in users only being able to log in to the Azure AD that was configured when the connection was created.
This pattern of behavior is present for security reasons. Let us assume that a user could create any Azure AD for free if the user has a Microsoft account. If that user were to be granted access to Azure AD without any constraints, then the logical partition between different organizations would be lost. The outcome of this would be that a user that is associated with a random Azure AD domain like example.com would be able to see what the legitimate users from okta.com can see.
Connection constraints
One possible solution to this problem is to create new Azure AD connections for each customer. But in practice, Auth0 subscription plans impose limits on the number of Enterprise connections that are available to each level of subscription. For example, at the time of this writing, a B2B-Essentials plan permits only 3 enterprise connections.
So take the case of an SaaS software solutions company that has many hundreds of customers: this approach of creating additional Azure AD connections would not be a viable option. And there may be an additional constraint in so far as many customers may be reluctant to share configuration data such as client-IDs and client-secrets for security reasons.
Multi-Tenant AD access
A further option is to create a multi-tenant Azure AD solution. This would permit login with two different accounts from different instances of Azure AD. However, it would depend on the details of the business use case as to whether this is acceptable or not.
If the multi-tenant strategy is chosen, be sure to enable the Use common endpoint option :
(Optional) When enabled, your application will dynamically accept users from new directories. Typically enabled if you selected a multi-tenant option for Supported account types for the application you just registered in Azure AD. When enabled, Auth0 will redirect users to Azure’s common login endpoint, and Azure will perform Home Realm Discovery based on the domain of the user’s email address.
Failure to enable this option may result in an AADSTS50020 error, which invites the user to sign out and sign in again with a different Azure Active Directory user account. Enabling the Use common endpoint option should solve this problem and allow users to successfully sign in with an Azure account that is associated with a different organization.