AADSTS50105 is the error Microsoft Entra ID returns when an enterprise application has Assignment required set to Yes and the person signing in has no qualifying assignment to it. Switching Assignment required off makes the error disappear, which is why it is the most common fix and often the wrong one. This post covers what the assignment check actually counts, why a user who is plainly in the right group can still fail it, and the order I would check things in.
It is a spoke of every AADSTS error code, grouped by cause, which sits under the Conditional Access and sign-in policy hub. Every Microsoft fact below was checked against Microsoft Learn on 31 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so what follows is the documentation read carefully, plus where I would expect it to bite.
What AADSTS50105 actually checks
The message reads: AADSTS50105: The signed in user is not assigned to a role for the application. According to Microsoft’s troubleshooting article for error AADSTS50105, the cause is always the same pair of facts: the application’s service principal has Assignment required set to Yes, and the user has no app role assignment to it. The check can apply to apps that use SAML, OpenID Connect, OAuth 2.0, WS-Federation or Application Proxy preauthentication, so the protocol does not narrow it down.
Only two things satisfy the check for a user. Either the user is assigned to the application directly, or a group is assigned and the user is a direct member of that group. An assignment to Default Access counts when the app exposes no named role, but Default Access adds no roles claim to the token.
The word role in the message misleads people. It does not mean an Entra directory role such as Application Administrator. It means an app role assignment on the enterprise application, and Default Access is one of those.
The checks in order
- Open the failed sign-in for the affected user and note the application name and application ID. The enterprise application to inspect is the one in the tenant that refused the sign-in.
- In the Microsoft Entra admin center, browse to Entra ID, Enterprise apps, All applications, select the app, then Properties. Read the value of Assignment required.
- Select Users and groups. Look for the user, or for a group the user is a direct member of.
- If access is meant to come through a group, open the user’s group memberships and confirm the assigned group is listed as a direct membership, not reached through another group.
- If the assigned group is dynamic, confirm the user is actually in it today. A rule the user should match is not the same as a membership that has been processed.
- Test with the user who saw the error. Do not test with a Global Administrator, for the reason in the failure modes below.
| What you find | What it means | Fix |
|---|---|---|
| User not listed, and no group they belong to is listed | Genuinely unassigned | Assign the user, or a group they are a direct member of |
| User is in a group that is itself a member of the assigned group | Nested membership, which the check does not follow | Assign the inner group, or the user |
| No option to assign a group at all | The tenant has no Microsoft Entra ID P1 or P2 | Assign users directly, or license the tenant |
| Sign-in works for an administrator, fails for the user | Global Administrator is exempt from the check | Test as the affected user |
| Dynamic group assigned, user changed department recently | Membership not processed yet | Check the group’s rule processing status |
| A service or daemon fails with AADSTS501051 | An app-only assignment failure, not a user one | Assign the client application, not a user |
Nested groups: the AADSTS50105 cause that looks like a bug
Microsoft Learn is blunt about this. The guide to assigning users and groups to an application says the assignment does not cascade to nested groups and that nested group memberships are not currently supported. The troubleshooting article repeats it as advice: do not rely on nested group membership.
The pattern that produces the ticket is familiar. Someone assigns a broad group such as All Finance to the app, and All Finance contains Finance UK and Finance US as member groups. Every user in those inner groups is refused with AADSTS50105, while anyone added straight to All Finance gets in. It looks random until you read the memberships.
The fix is to assign the groups that hold the users directly. If you want one group per app, make it a group whose members are users, not other groups.
Group-based assignment needs Microsoft Entra ID P1
Learn states that group-based assignment requires Microsoft Entra ID P1 or P2. Without it, assignment is user by user. If you are deciding whether that is worth paying for, what P1 adds over the free tier, and when P2 is worth it covers the licence side.
Do not confuse this with group-based licensing, which assigns product licences rather than app access. Its failures are a separate problem, covered in why group-based licence assignment fails.
Dynamic groups can be assigned to an app too, and they carry their own lag. If a user’s attribute changed this morning and the rule has not been reprocessed, the user is not in the group and AADSTS50105 is the correct answer. Why an Entra dynamic group is not updating covers how to read the processing status.
Turning Assignment required off
The troubleshooting article gives two resolutions, and the second is to set Assignment required to No. It also warns that doing so broadens token eligibility to include unassigned users and applications. Conditional Access and any authorisation inside the app still apply, but the assignment gate is gone.
That is a legitimate choice for an app the whole organisation should use. It is a poor choice for an app that holds HR, finance or customer data and does no authorisation of its own, because the assignment list was the only thing deciding who got a token.
The newsletter
Get the next Entra ID fix like this one by email
Subscribe and get the free 8-page Intune troubleshooting field guide (PDF), then new fixes about twice a month. From a Microsoft MVP.
Checking assignments with Microsoft Graph PowerShell
The portal answers the question for one app. For several, I would read the flag and the assignment list with Microsoft Graph PowerShell. I have not run this against a production tenant; it uses the documented Get-MgServicePrincipal and Get-MgServicePrincipalAppRoleAssignedTo cmdlets.
# Read the Assignment required flag and list who is assigned to one enterprise application.
# Replace the appId with the application ID from the failed sign-in.
$appId = '00000000-0000-0000-0000-000000000000'
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -Property Id, DisplayName, AppRoleAssignmentRequired
$sp | Select-Object DisplayName, AppRoleAssignmentRequired
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $sp.Id -All |
Select-Object PrincipalDisplayName, PrincipalType, AppRoleId
A group in that list grants access only to its direct members. If the user is not one, the list explains the error on its own.
The failure modes
- Testing as a Global Administrator. Learn notes that the assignment requirement does not apply to Global Administrators. An admin who signs in to prove the fix worked has proved nothing about the user.
- Switching the check off to fix one user. The ticket closes and the app is now open to every account in the tenant.
- Switching the check on and breaking consent. Microsoft’s guide to restricting an app to a set of users says that once an app requires assignment, user consent for it is no longer allowed, so grant tenant-wide admin consent first. Otherwise users swap AADSTS50105 for a consent error.
- Expecting a roles claim from Default Access. Default Access passes the Entra check but adds no roles claim. An app that authorises on roles will then refuse the user with its own error, after Entra has let them through.
- Guests from another tenant. A guest who is not assigned can surface a different code. How AADSTS50020 overlaps with assignment for guest accounts covers that case; the setting to check is the same.
- Treating AADSTS501051 as the same error. It is the app-only version, where a client application rather than a user lacks the assignment. Assigning a user does nothing for it.
What I would do differently
I would treat Assignment required as a design decision made when the app is added, written down with the reason, rather than a toggle someone flips during an incident.
I would assign one group per app, with users as direct members, and keep nesting out of app access entirely. Nesting is convenient for mail and permissions elsewhere, and that convenience is exactly what makes AADSTS50105 look random.
And I would keep a test account that is not a Global Administrator for every sign-in investigation. Most of the wasted time on this error comes from proving a fix with an account the check never applied to.
The two resolutions and the exact portal path are in the Microsoft Learn troubleshooting article linked near the top. Use it for the procedure, and the assignment list to find out which of the causes above you have.
Last verified: 31 October 2026.
