EFEnterprise IT Fixes

Microsoft · Microsoft Entra ID

AADSTS50105: assign the user to the Microsoft Entra enterprise app

AADSTS50105 means the enterprise app requires assignment and the signed-in user lacks a qualifying assignment; verify the access policy before changing it.

Short answer

AADSTS50105 means the enterprise application requires assignment, but the affected user has no qualifying assignment to it. Check the application’s Assignment required? setting and intended access scope. If access should remain restricted, assign the user directly or through a group of which they are a direct member, using the required app role. Set assignment to No only when the application is meant to be available to all otherwise-authorized users in the tenant.

Our diagnostic lens

Keep the access path in layers: sign-in identity → enterprise-app assignment gate → app role in the token → authorization inside the application. AADSTS50105 points to the assignment gate. It does not establish that the user needs a broader directory role, and a successful token does not prove the app’s own permissions are correct. Check the assignment requirement, then the user’s direct assignment or direct group membership. Use the affected account for the test; a highly privileged admin account may not exercise the same assignment check.

Problem / symptoms

An otherwise-authenticated user reaches the application sign-in flow, but Entra rejects access at the enterprise-app assignment gate. Check this layer regardless of which supported federation mode the application uses.

Exact error

AADSTS50105: the user has no qualifying assignment to this application.

Record the affected identity, application, timestamp, and correlation ID from the sign-in error or the matching Entra sign-in event.

Environment and scope

This applies to enterprise apps whose Properties restrict access to assigned users. It is an application-access gate, separate from Conditional Access, app consent, or the user’s application-specific permissions after sign-in.

What the evidence establishes

Microsoft states that a user can satisfy the requirement through a direct user assignment or through an assigned group when the user is a direct member. Nested group membership should not be relied on for predictable assignment behavior. If the app exposes no named role, the documented Default Access role can satisfy assignment without adding a roles claim to the token.

Investigation

  1. In Entra ID → Monitoring & health → Sign-in logs, locate the failed event by user, app, time, and correlation ID. Confirm the failure is AADSTS50105.
  2. Open Entra ID → Enterprise apps → All applications → the affected app → Properties. Check Assignment required? and confirm that the setting matches the access policy the owner intends.
  3. Open Users and groups and check whether the affected user is assigned directly or is a direct member of an assigned group. Confirm that the assigned app role is correct.
  4. If the user is in a nested group, verify direct membership or use a direct user assignment in line with the organization’s access design.
  5. Test with the affected non-administrator identity. A highly privileged directory administrator may bypass this app gate, so a successful sign-in with that account is inconclusive.

Likely causes

The application is configured to allow assigned users only, and the affected account has no assignment that satisfies that gate. The code does not mean the user needs a higher directory role or that the application should become available to everyone.

Suggested troubleshooting steps

If access should remain limited, assign the intended user or direct-membership group under Users and groups, selecting the app role the owner expects. If the application has no named role, use Default Access where appropriate. Group assignment is available with the Microsoft Entra ID P1/P2 licensing tier.

If all otherwise-authorized users should be able to access the application, an administrator can set Assignment required? to No. That broadens who can obtain a token for the app; make that change only after the app owner confirms that this is the intended policy. Other controls, including Conditional Access and app-side authorization, continue to apply.

How to check the result

  • Retry with the affected user’s account after the assignment has been saved and propagated.
  • Confirm the sign-in event no longer reports AADSTS50105 and identifies the intended application.
  • Verify both an assigned user and a user outside the intended access scope so the change preserves the intended boundary.

Vendor sources

Found a gap or outdated step?

Send a correction so this guide can improve.

Give feedback

Related guides

Identity and access

AADSTS50020: troubleshoot a Microsoft Entra account or tenant mismatch

AADSTS50020 means the identity presented for sign-in is not recognized in the resource tenant; verify the account, tenant, app type, and guest invitation.

AADSTS50020Identity and access

AADSTS50076: diagnose the Microsoft Entra MFA requirement

AADSTS50076 usually signals a required MFA step after a policy, account, or sign-in-context change; inspect the sign-in event.

AADSTS50076Identity and access

AADSTS53003: find which Conditional Access policy blocked sign-in

AADSTS53003 means Conditional Access blocked the request; use the matching sign-in event to identify the policy and unmet condition before changing access.

AADSTS53003