AADSTS50105: User not assigned to a role for the app

What does AADSTS50105 mean?

EntitlementGrantsNotFound: The signed in user isn’t assigned to a role for the signed in app. Assign the user to the app.

Microsoft’s troubleshooting article gives the cause:

The enterprise application’s service principal has Assignment required? set to Yes, and the requesting user doesn’t have an app role assignment

Is it an attack?

Almost always not. The usual causes are a new joiner who hasn’t been added to the app’s group yet, someone following a link to an app they don’t use, or an assignment made through a nested group. The troubleshooting article notes that nested group membership isn’t honoured for assignment, so only direct members of the assigned group get in.

The security point is what 50105 represents: “Assignment required” is a least-privilege control, and 50105 is it refusing access. That is the outcome you want.

Pattern	Likely meaning
One user, one app, a few attempts	Missing assignment or nested group. Benign.
New starters failing on day one	Provisioning lag. Benign.
One account trying many apps it isn’t assigned to, in a short window	Investigate. A compromised account exploring what it can reach (reasoning, not a Microsoft statement).
Rising 50105 on a sensitive app (admin portals, finance, HR)	Either a broken group, or people trying an app they aren’t entitled to. Check which.

Microsoft’s description says “the signed in user”, so the credential stage succeeded before this check. Whoever produced the row either is that user or holds their credentials.

How do I find it in my logs (KQL)?

Accounts hitting many different apps they aren’t assigned to:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50105"
| summarize DeniedApps = dcount(AppId),
            AppNames = make_set(AppDisplayName, 10),
            IPs = make_set(IPAddress, 10),
            Attempts = count()
          by UserPrincipalName
| where DeniedApps >= 3
| sort by DeniedApps desc

Daily 50105 per app, to see a broken assignment or a new pattern:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "50105"
| summarize Users = dcount(UserPrincipalName), Attempts = count()
          by AppDisplayName, AppId, bin(TimeGenerated, 1d)
| sort by TimeGenerated desc, Users desc

The threshold of 3 apps is a starting point, not a tested value. Tune it to your tenant.

How does Conditional Access affect it?

• 50105 is not a Conditional Access result. Assignment is a property of the enterprise application, checked separately from your CA policies.
• A policy that targets “All resources” still applies to the user’s other apps. Assignment decides who gets a token for this app; Conditional Access decides under what conditions. Use both.

How do I fix AADSTS50105?

For the user: ask your IT team for access to the app. Tell them the app name and the time you tried.

For admins:

1. Open Enterprise applications > the app > Users and groups, and assign the user, or add them to a group that is assigned directly (not through a nested group).
2. Do not set Assignment required? to No as a quick fix. Microsoft’s troubleshooting article warns: “Setting Assignment required? to No broadens token eligibility to include unassigned users and applications.”
3. Remember Global Administrators are not a test of the setting. Microsoft notes: “The assignment requirement doesn’t apply to Global Administrators.” An app that works for an admin and fails for everyone else is behaving as configured.