Entra ID AADSTS50105: User Not Assigned to Enterprise Application

When a user signs in to an application protected by Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context , two separate questions are answered. The first is whether the person can prove who they are. The second is whether that person is permitted to use this particular application. AADSTS50105 belongs to the second question. The user authenticated successfully, but the application’s service principal, shown in the portal as an enterprise application, is configured to issue tokens only to users and groups that have been explicitly assigned to it, and this user has no such assignment.

The error text usually reads along the lines of: your administrator has configured the application to block users unless they are specifically granted access. That wording is a useful clue, because it tells you the block is deliberate configuration rather than a fault. This guide builds the mental model, walks through diagnosis in a non-production tenant, and explains the two legitimate fixes. It also explains why choosing between them is a security decision and not merely a convenience.

#Learning Objectives

• Explain the difference between authentication and authorisation to an application in Entra ID.
• Distinguish an app registration from an enterprise application (service principal).
• Diagnose AADSTS50105 from the sign-in error and the enterprise application’s properties.
• Choose between assigning a user or group and disabling assignment required, and justify the choice.
• Validate the fix and describe how to reverse it.

#Prerequisites

• An isolated or non-production Entra tenant with a test enterprise application and a test user. Do not use production data or credentials.
• An administrative role able to manage enterprise applications and assignments in that tenant. Confirm your product version, portal layout and permissions before changing anything.
• Basic familiarity with sign-in flows, and with users and groups.

#Content

#

The mental model

An application registration is the global definition of an application: its identifiers, redirect URIs and permissions requested. An enterprise application is the service principal, the local instance of that application in your tenant. Tenant-specific policy lives on the service principal, including who may sign in. One property, commonly labelled Assignment required, controls whether only assigned users and groups can obtain a token for the application.

The data flow is: the user is redirected to Entra ID, authenticates, and Entra ID evaluates policy for the target service principal. If assignment is required and no assignment exists for the user, directly or through a group, Entra ID refuses to issue a token and returns AADSTS50105. The application itself never sees the request succeed; the trust boundary is enforced by Entra ID, which is why changing app code does not help.

#

Terminology

• Assignment required: a service principal setting restricting token issuance to assigned identities.
• Assignment: a link between a user or group and the application, optionally with an app role.
• Group-based assignment: access inherited through group membership; availability of nested group assignment and licensing requirements should be confirmed in current documentation.

#

Choosing a fix

Assigning is the safer default because it widens access by exactly one identity or group. Disabling the requirement widens access for everyone and should be an explicit decision by the application owner.

#Examples

#

Worked example

Input: a test user, Test User A, opens the test application and sees AADSTS50105. Observation: the sign-in log entry for that attempt shows the error code, the application name and the user. Inspection: on the enterprise application, Assignment required is set to Yes, and the Users and groups list does not include Test User A or any group they belong to.

Interpretation: authentication succeeded, authorisation to the application failed by design. The inference is that no assignment exists. The recommendation is to add the user, or better a group representing the audience. A possible exception is a group-membership lag or the user being in a different tenant than expected, which you should rule out by checking the user’s identity in the sign-in log.

#Exercises

#

Exercise: reproduce and fix in a lab

Objective: reproduce AADSTS50105 and resolve it with a scoped assignment.

Setup: a non-production tenant, a test enterprise application with Assignment required set to Yes, and a test user and test group that are not assigned.

1. Sign in as the test user and note the error. This confirms the baseline and produces the evidence you will compare against.
2. As the administrator, open the enterprise application, then Users and groups, and assign the test group. Assigning a group, not an individual, mirrors production practice.
3. Add the test user to the group. Allow time for group membership to propagate; the delay varies, so confirm current guidance.
4. Sign in again in a fresh private browser session so stale tokens are not reused.

Expected evidence: the second sign-in succeeds and the sign-in log shows a successful entry.

Pass condition: success after assignment, and the error returns when the user is removed from the group.

Stop conditions: stop if the application is not one you own in the lab, if the tenant is production, or if the error code differs from AADSTS50105.

Cleanup: remove the group assignment, the test user and the test group, and restore the original Assignment required value.

#Validation Guidance

Validate with evidence rather than a single successful page load. Compare the sign-in log before and after: the error code should change from 50105 to success for the same user and application. Confirm the user can reach only what the assignment intends, and that an unassigned second test user is still blocked. If you disabled the requirement, confirm that was an approved decision and that the unassigned user now succeeds, since that proves the scope widened as expected.

Rollback is simple: remove the assignment, or set Assignment required back to Yes. Existing tokens may remain valid until they expire, so rollback is not instantaneous.

#Common Mistakes

• Disabling assignment required to make the error disappear. Cause: treating it as a fault. Correction: assign a group. Recovery: restore the setting to Yes.
• Assigning individuals instead of groups. This creates unmanaged exceptions; use groups with an owner.
• Editing the app registration instead of the enterprise application. The setting is on the service principal.
• Retesting with a cached session. Use a fresh session before concluding the fix failed.
• Confusing this with consent errors. See AADSTS65001, which concerns consent rather than assignment.

#

Production bridge

In production, changes to assignments should go through the application owner and your normal change process. Prefer groups governed by access reviews, as described in recurring access reviews, and give administrators only the role needed, ideally just-in-time via PIM. Escalate to the application owner if the audience is unclear, and to your security team if disabling the requirement is requested for a sensitive application. Whether a given configuration is supported for your licence is a point to verify in current documentation.

#Key Takeaways

• AADSTS50105 means authentication worked but the user lacks an assignment to an application that requires one.
• The control sits on the enterprise application, not the app registration.
• Assigning a group is the least-privilege fix; disabling the requirement widens access for everyone.
• Prove the fix with sign-in log evidence, and keep rollback to a single reversible setting.

Before closing the work, check that the sign-in log shows success for an assigned user and failure for an unassigned one, record who approved the assignment, and keep the original Assignment required value noted so you can restore it. The next safe decision is whether the group has an owner and a review cycle.