AADSTS50105: User Isn't Assigned to a Role for the Application

AADSTS50105 — "The signed in user is not assigned to a role for the application" means your sign-in worked but the app refused you. This guide explains why, what a user can do, and the exact admin steps that fix it, including the nested-group trap that makes a correctly-grouped user fail anyway.

The Error

AADSTS50105: The signed in user is not assigned to a role for the
application.

Microsoft's internal name for the code is EntitlementGrantsNotFound. You may also see it worded as "Your account is not authorized to access this application" or "The signed in user isn't assigned to a role for the signed in app".

Why This Happens

Entra ID does two separate things when you open an application. First it authenticates you — password, MFA, Conditional Access. Then it authorizes you — checks whether you are allowed to open this particular app.

AADSTS50105 is thrown at the second step. Everything about your identity checked out. What is missing is an assignment.

It appears when both of these are true:

1. The enterprise application has Assignment required set to Yes, and
2. Your account is not in that application's Users and groups list, directly or via a directly-assigned group.

That is the entire cause. Microsoft states it plainly: the user must belong to a group that is assigned to the application, or be assigned directly.

Two things this is not: it is not a password problem, and it is not a licensing problem. A fully licensed Microsoft 365 user gets this error all day long if nobody added them to the app.

If You're a User (Not an Admin)

You cannot fix this yourself. It requires directory permissions you do not have.

1. Check your organization's app portal at myapps.microsoft.com. Some applications are published there as self-service, letting you request access without raising a ticket.
2. If it isn't there, contact your IT administrator and give them:
   • The full error text, including AADSTS50105
   • The name of the application you were opening
   • The account you signed in with
   • The time it happened, and the Request ID from the error page if one is shown

That last detail saves your admin real time — it lets them find the exact sign-in log entry rather than guessing.

Do not reset your password, clear cookies repeatedly, or try a different browser. None of those touch the cause.

Admin Fix 1: Assign the User or Group

Requires: Cloud Application Administrator, Application Administrator, or Global Administrator.

1. Sign in to the Microsoft Entra admin center.
2. Go to Identity → Applications → Enterprise applications.
3. Select the application the user was trying to open.
4. Select Users and groups.
5. Select Add user/group.
6. Choose the user, or a security group, and assign it.

Assigning a group rather than individual users is the better long-term pattern — new starters inherit access from group membership instead of needing a manual step. Just read the next section before you rely on it.

Admin Fix 2: The Nested Group Trap

This is the one that wastes afternoons, and it is worth checking before anything else if the user looks like they should already have access.

Microsoft does not support nested groups for application assignment. The group must be assigned to the application directly.

So this fails:

User  →  member of  →  "Finance Team"
                       "Finance Team"  →  member of  →  "All Finance"
                                                        "All Finance"  →  assigned to app

The user is transitively in an assigned group, the membership looks correct in every group view, and Entra ID still throws AADSTS50105.

This works:

User  →  member of  →  "Finance Team"  →  assigned to app

To fix it, either assign Finance Team to the application directly, or assign the user directly. If you rely on a nested group structure elsewhere in your directory, application assignment is the one place it will not carry through.

Admin Fix 3: Turn Off Assignment Required (Consider Carefully)

Setting Assignment required to No stops the error immediately for everyone.

1. Enterprise applications → the application → Properties
2. Set Assignment required? to No
3. Save

What this actually does: every user in your tenant who can authenticate can now open the application. There is no per-user gate left.

That is a reasonable choice for something the whole organization should have — an intranet, a company directory, a general-purpose SaaS tool you have licensed for everyone. It is the wrong choice for finance, HR, payroll, or anything holding regulated data, where the assignment list is the access control.

Do not use this as a quick fix to close a ticket. If you find yourself reaching for it because group assignment is fiddly, fix the group instead.

Verify the Fix

1. Have the user sign out completely — sign out of the app and of Entra ID, then close the browser. An existing token will keep failing even after the assignment is correct.
2. Test in a private or incognito window to rule out cached tokens entirely.
3. Check the sign-in logs. In the Entra admin center, go to Monitoring → Sign-in logs, filter to the user, and confirm the entry now shows success. If it still shows AADSTS50105, the assignment did not apply the way you think — check for nesting.

Give it a few minutes. Assignment changes are usually near-instant but not always.

Prevent It Coming Back

• Assign groups, not people — but assign them directly to each application.
• Document which group governs which app. The most common cause of a repeat AADSTS50105 is a new starter added to the wrong group by someone who did not know the mapping.
• Include app assignment in onboarding. Licensing a user is not the same as granting them applications, and treating those as one step guarantees this error on day one.
• Audit assignments periodically. Enterprise applications → the app → Users and groups shows exactly who has access, which is also useful evidence at review time.
• Watch for group-type mismatches. Some applications and licensing models behave differently with dynamic groups versus assigned groups; if a dynamic group is in play, confirm the user actually matches its membership rule.

Related Errors

If you need to inspect or script assignments across many applications, connect with PowerShell — see how to install and connect to Exchange Online PowerShell for the module setup pattern, and use the Microsoft Graph PowerShell module for application assignment work.

Related Articles

• Customizing Admin Roles for Delegated Administration in Office 365
• Configuring Conditional Access Policies in Office 365