AdminPackStudio

Posted on Oct 15

AADSTS50105 User Not Assigned to a Role for the Application: A Read-First Enterprise App Assignment Triage

#azure #security #sysadmin #powershell

Helpdesk: "Finance can't open the new expense app. Red page says AADSTS50105, the signed in user is not assigned to a role for the application. IT already tried from a Global Admin account and it worked fine, so they want to set Assignment required to No." Ten minutes later a second ticket: a contractor who is in the Finance-Users nested security group still can't get in, and someone is asking whether to exclude the app from Conditional Access.

Don't flip Assignment required? yet. AADSTS50105 is an assignment failure, not a Conditional Access block and not a "user doesn't exist" failure: Microsoft Entra ID authenticated the user, found them in the tenant, then refused a token because the enterprise application's service principal has Assignment required? = Yes and this user has no qualifying assignment. It only resolves when the whole chain holds: the error really is 50105 (not 50020 / 53003 / 501051) → you are looking at the enterprise app whose Application ID matches the error → Assignment required is Yes (expected for a restricted app) → the user is assigned directly, or is a direct member of an assigned group → the role on that assignment is Default Access or a named app role the app actually exposes → you verify with the affected user, not a Global Administrator. Microsoft's own remediation is to assign the user (or a group they belong to) — or, only if that matches policy, turn assignment required off.

If the message says the account does not exist in the tenant, that's AADSTS50020; read the AADSTS50020 guest and wrong-tenant triage. If the sign-in gets past assignment and is then denied by policy, that's AADSTS53003; see the AADSTS53003 Conditional Access triage. If the error names a device, see AADSTS135011. This post covers AADSTS50105 for enterprise apps that require user or group assignment, read-only first.

TL;DR

Read the app name, App ID, and user in the message (and the Correlation ID / Trace ID / timestamp). Microsoft's error lookup page says the admin configured the app to block anyone who isn't specifically granted access.
Open the enterprise app by App ID, not by a similar display name. Confirm Assignment required? = Yes on Properties. That setting is the cause when the user has no assignment.
Qualifying access is only: a direct user assignment, or membership in a group that is assigned and the user is a direct member of that group. Nested groups do not cascade. Group-based assignment needs Entra ID P1 or P2.
Default Access satisfies the assignment check when the app exposes no named roles, but it does not add a roles claim to the token. Named app roles do.
Global Administrators bypass the check. If it "works for IT," that proves nothing. Test with the affected user after you assign them.
Don't turn Assignment required off unless every otherwise-authorized user in the tenant should get a token. Microsoft warns that change broadens eligibility; Conditional Access still applies, but you've removed the app's allow-list.

Where in the chain did it break?

Step	What should be true	Typical symptom when it breaks
1. Right error	Code is `50105` / EntitlementGrantsNotFound; account exists in tenant	Message is `50020` (no object), `53003` (CA), or `501051` (app-only)
2. Right enterprise app	Enterprise app App ID matches the AppId in the error	Looking at a gallery twin, an app registration only, or a different environment's SP
3. Assignment required	Properties shows Assignment required? = Yes	Setting is No but something else blocks (consent, CA, disabled SP)
4. Qualifying assignment	User assigned directly, or direct member of an assigned group	Nested group only; wrong group; assignment on a different app
5. Role on the assignment	Default Access or a named app role the SP exposes	App expects a named role / `roles` claim; only Default Access was granted
6. Consent when required	Admin consented when Assignment required is Yes (user consent blocked)	Consent / permission errors after assignment is fixed
7. Verify	Affected (non-GA) user signs in cleanly in a private window	GA test "succeeds"; user still 50105

Write down the exact error text, Correlation ID, Trace ID, Timestamp, the app URL or My Apps tile, and whether the tester was a Global Administrator.

Step 1: Decode the exact message (read-only)

Microsoft's error-code reference names 50105 EntitlementGrantsNotFound and summarizes it as: the signed-in user isn't assigned to a role for the signed-in app — assign the user to the app. The live lookup page (https://login.microsoftonline.com/error?code=50105) is more specific:

Your administrator has configured the application {appName} ('{appId}') to block users unless they are specifically granted ('assigned') access to the application. The signed in user '{user}' is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator.

Every placeholder matters. Pull them out so nobody misreads a similar app name:

$msg = @'
AADSTS50105: Your administrator has configured the application Contoso Expense ('aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee') to block users unless they are specifically granted ('assigned') access to the application. The signed in user 'alex@contoso.com' is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator.
'@

$pattern = "application (?<appName>.+?) \('(?<appId>[0-9a-fA-F-]{36})'\).*signed in user '(?<user>[^']+)'"
if ($msg -match $pattern) {
  [pscustomobject]@{
    AppName = $Matches.appName
    AppId   = $Matches.appId
    User    = $Matches.user
  }
}

Microsoft notes that error codes and messages can change; use https://login.microsoftonline.com/error?code=50105 for the current wording, and keep the Correlation ID from the page for the sign-in log.

The codes that look like 50105 but aren't

Code (Microsoft's name)	What it means	Where to go
`50020` (`UserUnauthorized`)	Authenticated identity has no user object in the resource tenant	AADSTS50020 triage
`53003` (`BlockedByConditionalAccess`)	Account found; Conditional Access blocked the token	AADSTS53003 triage
`501051`	App-only / client service principal not assigned a role on a resource that requires assignment	Step 6 (app-to-app); different from user 50105
`65001` / consent errors	User or admin hasn't consented to the app	Step 5 (admin consent when assignment is required)
`50057` (`UserDisabled`)	User account is disabled	Enable the account; not an assignment issue
`135011`	Device used during auth is disabled	AADSTS135011 triage

Microsoft's 50020 troubleshooting article also lists Assignment required as a cause that can surface as 50020 in some guest/app paths, while the error-code reference maps "not assigned to a role" to 50105. Read the code on the page you have; both point at the same Users and groups check.

Step 2: Open the right enterprise application (read-only)

The assignment check lives on the enterprise application (service principal), not only on the app registration. Microsoft's troubleshoot article applies the check to apps using SAML, OpenID Connect, OAuth 2.0, WS-Federation, or Application Proxy preauthentication.

Sign in to the Microsoft Entra admin center.
Browse to Microsoft Entra ID > Enterprise apps > All applications.
Filter or search by the Application ID from the error (more reliable than display name).
Open Properties.
Read Assignment required?

Assignment required?	Read it as
Yes	Unassigned users (and, for app-only, unassigned client apps) should not get a token. 50105 is expected until you assign.
No	This app is not enforcing the allow-list. If the user still fails, you likely have the wrong SP, a consent problem, a disabled SP, or Conditional Access — not 50105's cause.

Also note Enabled for users to sign-in? and Visible to users? on the same Properties page. Visible controls whether the tile shows in My Apps; it is not a substitute for assignment when Assignment required is Yes. Microsoft's assign-users quickstart sets Visible to Yes after assignment so assigned users can find the app.

# Read-only: find the service principal by AppId from the error
Connect-MgGraph -Scopes 'Application.Read.All', 'Directory.Read.All'
$appId = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'   # from the error
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"
$sp | Select-Object DisplayName, AppId, Id, AppRoleAssignmentRequired, AccountEnabled, ServicePrincipalType

AppRoleAssignmentRequired is the Graph property behind Assignment required?. If this returns nothing, the AppId is wrong or you're in the wrong tenant.

Step 3: Who is actually assigned? (read-only)

Microsoft's cause statement is narrow. For a user, access comes from either:

The user is assigned directly to the application, or
A group is assigned, and the user is a direct member of that group.

An assignment to Default Access satisfies the requirement when the application doesn't expose a named application role. Default Access does not add a roles claim to the token. If the app's code or SAML claims expect a role value, Default Access alone will get the user past 50105 and then fail inside the app — different symptom, same place to look.

# Assignments on the enterprise app (who has access)
$spId = $sp.Id
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $spId -All |
  Select-Object PrincipalDisplayName, PrincipalType, PrincipalId, AppRoleId, CreatedDateTime |
  Format-Table -AutoSize

# App roles this SP exposes (empty → Default Access GUID is used)
$sp.AppRoles | Select-Object DisplayName, Value, Id, IsEnabled | Format-Table -AutoSize

# Does this user have any app role assignment on this resource?
$userUpn = 'alex@contoso.com'
$user = Get-MgUser -UserId $userUpn
Get-MgUserAppRoleAssignment -UserId $user.Id -All |
  Where-Object { $_.ResourceId -eq $spId } |
  Select-Object ResourceDisplayName, AppRoleId, PrincipalType, CreatedDateTime

The default AppRole ID when no named roles exist is 00000000-0000-0000-0000-000000000000 (Default Access), per Microsoft's assign-users documentation.

Nested groups (the Monday trap)

Microsoft states twice, in plain language: assignment does not cascade to nested groups, and nested group memberships aren't currently supported. For predictable access, assign the user directly or use a group of which they are a direct member.

# Direct group memberships only (transitive memberOf is a different check)
Get-MgUserMemberOf -UserId $user.Id -All |
  Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.group' } |
  ForEach-Object {
    [pscustomobject]@{
      GroupId     = $_.Id
      DisplayName = $_.AdditionalProperties.displayName
    }
  }

If Finance-Users is assigned to the app, but Alex is only in Finance-Users via All-Staff → Finance-Users, Alex is not a direct member for this feature. That matches the error page text ("not a direct member of a group with access").

Licensing

Group-based assignment requires Microsoft Entra ID P1 or P2. Direct user assignment does not need that SKU for the assignment feature itself. If the portal won't let you pick groups, check licensing before redesigning the group model.

Step 4: Confirm intended policy before you change anything

Microsoft's resolution has two branches. Pick the one that matches policy, not the one that clears the ticket fastest.

Intended policy	Prefer	Avoid
Only selected users/groups should use this app	Keep Assignment required = Yes; add the user or a direct-member group; choose Default Access or the correct named role	Setting Assignment required = No "temporarily"
Every otherwise-authorized user in the tenant should get a token	Set Assignment required? to No, then Save	Leaving it Yes and assigning "All users" without thinking about guests and service accounts

Microsoft's warning on the second path: setting Assignment required to No broadens token eligibility to include unassigned users and applications. Conditional Access and app-specific authorization still apply, but the allow-list is gone.

Roles Microsoft lists for updating properties and assignments: Cloud Application Administrator, Application Administrator, or a current owner of the service principal. The assign-users portal article also lists User Administrator among roles that can assign users. Prefer least privilege that can still complete the change.

Portal path when you keep assignment required (after the read-only checks):

Enterprise app → Users and groups → Add user/group.
Select the user or group.
Under Select a role, pick a named app role, or Default Access if none exist.
Assign.

# CHANGE (only after Steps 1–3): assign Default Access to one user
# Connect-MgGraph -Scopes 'Application.ReadWrite.All', 'AppRoleAssignment.ReadWrite.All'
# $params = @{
#   PrincipalId = $user.Id
#   ResourceId  = $sp.Id
#   AppRoleId   = '00000000-0000-0000-0000-000000000000'
# }
# New-MgUserAppRoleAssignment -UserId $user.Id -BodyParameter $params

Step 5: Admin consent when assignment is required

Microsoft's restrict-app article: when an application requires assignment, user consent for that application isn't allowed, even if user consent would otherwise be permitted. Grant tenant-wide admin consent for apps that require assignment.

If assignment looks correct and the next error is consent-related (65001 / admin consent required), fix consent — don't turn off Assignment required to "make consent work."

Step 6: App-only failures are 501051, not 50105

If a daemon / client credentials flow fails with a message like the client application isn't assigned to a role for the resource, Microsoft documents that as AADSTS501051 under "restrict a Microsoft Entra app to a set of users." The fix is to assign the client service principal to the resource service principal (often Default Access via Graph/API; the portal UI is aimed at users and groups). Don't chase Users and groups for a human identity when the failing principal is an app.

Step 7: Read the sign-in log (read-only)

Find the failed sign-in with the Correlation ID and timestamp from the error page:

Entra admin center → Monitoring & health > Sign-in logs (or the enterprise app's Sign-in logs blade).
Confirm Failure reason / status references assignment or 50105.
Confirm Application / Resource App ID matches Step 2.
Confirm User is the person from the ticket (not a break-glass or GA test account).

If the log shows Conditional Access failure with 53003, stop this triage and use the CA article. If it shows the user doesn't exist in the tenant, use the 50020 article.

Step 8: Verify with the affected identity

Microsoft is explicit: test with the user who received the error. Do not use a Global Administrator to verify the assignment, because the assignment requirement does not apply to that role.

Practical verify checklist:

Assign the user (or fix direct group membership) — one identity first.
Wait a short replication window if you just changed group membership (see Timing).
Have the user open a private/InPrivate window (or sign out of all Microsoft sessions).
Use the app's direct link or My Apps; confirm they reach the app without 50105.
If the app still fails after sign-in with a permissions or "access denied" message inside the product, check named app roles / roles claims (Step 3) — you cleared 50105 but the app authorizes on role values.

Timing: when "still broken" is just waiting

Change	What to expect
Direct user assignment on the enterprise app	Often effective on the next sign-in; still use a private session so old errors aren't cached in the client
Group membership add	Directory group evaluation can lag briefly; re-check direct `memberOf`, then retry
Assignment required Yes → No	Broadens eligibility on next token request; CA policies still evaluate
Nested group "fix"	Will not start working after waiting — Microsoft does not support nested assignment for this feature

When a change is justified

Finding	Prefer	Avoid
Assignment required Yes; user not on Users and groups	Assign the user or a group they directly belong to; Default Access if no named roles	Setting Assignment required = No for one VIP
User only in a nested group under an assigned group	Assign the nested group itself, or a flat group, or the user directly	Waiting for nesting to "sync"
GA can sign in; user cannot	Expected — assign the user; verify as that user	Using GA success as proof the app is fine
App needs a `roles` claim	Assign a named app role the SP exposes	Assuming Default Access populates `roles`
Every tenant user should access this LOB app	Assignment required = No (Microsoft's documented option)	Assigning thousands of users one-by-one without a group strategy
Client credentials / daemon gets 501051	Assign the client SP to the resource (Graph/API)	Adding a human user to Users and groups for an app-only call
After 50105 is gone, user hits 53003	Tune Conditional Access (report-only first)	Turning off Assignment required to dodge CA
Guest hits 50020, not 50105	Fix invite / redemption / tenant first	Adding app assignments for an object that doesn't exist

Keep break-glass accounts documented so a bad CA change after you fix assignment doesn't lock everyone out — see Entra ID break-glass accounts after mandatory MFA.

FAQ

What does AADSTS50105 mean?
Microsoft Entra ID signed the user in, then refused a token for that application because the enterprise app has Assignment required? = Yes and the user has no qualifying assignment. The official name is EntitlementGrantsNotFound. The error page names the app, App ID, and user.

How do I fix AADSTS50105?
Open the enterprise app by App ID → confirm Assignment required is Yes → Users and groups → assign the user, or a group of which they are a direct member → choose Default Access or the correct named app role → verify with that user in a private window. Only set Assignment required to No if policy says everyone in the tenant should be able to get a token for this app.

Why does it work for Global Admins but not for normal users?
Microsoft documents that the assignment requirement does not apply to Global Administrators. A successful GA test does not mean the app is open to everyone. Always verify with the affected account.

Do nested groups work for enterprise app assignment?
No. Microsoft states that assignment does not cascade to nested groups and that nested group memberships aren't currently supported. Use direct membership or a direct user assignment.

What's the difference between AADSTS50105, AADSTS50020, and AADSTS53003?
50105: user exists; app requires assignment; user isn't assigned. 50020: the authenticated identity has no matching user object in the tenant (guest / wrong tenant / personal account path). 53003: user and assignment checks passed far enough for Conditional Access to evaluate and block. Fix assignment for 50105; fix directory/redemption for 50020; read the CA policies for 53003.

AADSTS50020 User Account Does Not Exist in Tenant (lookup failure before assignment matters)
AADSTS53003 Blocked by Conditional Access (account found; a policy blocked it)
Your organization has disabled this device (AADSTS135011) (device object, not app assignment)
Entra ID break-glass accounts after mandatory MFA (emergency access that survives a bad follow-up policy change)
Conditional Access without the Monday lockout (report-only → enforce after assignment is clean)

Free checklist

Once users can sign in to the app, the next request is usually "require MFA for this app" or "block legacy auth," and that's where a rushed Conditional Access change locks the same people out again. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts50105-user-not-assigned-to-application

If you want a starting policy set and the exclusions pattern written down before app-specific CA grows, the Entra ID Conditional Access Starter Pack has a starter policy library, a break-glass and exclusions playbook, and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=aadsts50105-user-not-assigned-to-application

Admin Pack Studio; not affiliated with Microsoft. Steps 1–3 and 7 only read: string parsing, `Get-Mg` cmdlets, and GET-only Graph requests. Adding or removing app role assignments, changing Assignment required, granting admin consent, and clearing client sessions are deliberate changes. Make them one user or one group at a time, and check current Microsoft Learn for portal labels and role names.*

DEV Community