Microsoft Intune 401 Errors – RBAC, Autopilot, and Scope Tags

The next decisive check is to call the documented scope-tag collection endpoint with an Intune RBAC permission; if that succeeds while the Intune portal still returns tenant-wide 401 errors, open a Microsoft support case for tenant-side Intune provisioning or authorization investigation.

1. Retest Graph with the exact RBAC request

A 400 Bad Request is different from 401 Unauthorized and does not, by itself, establish an RBAC or tenant-provisioning failure.

In Graph Explorer or your REST client, obtain a delegated work or school account token containing either:

• DeviceManagementRBAC.Read.All for reading
• DeviceManagementRBAC.ReadWrite.All for creating or changing RBAC objects

Then issue this exact request:

GET https://graph.microsoft.com/beta/deviceManagement/roleScopeTags
Authorization: Bearer {token}
Accept: application/json

The collection endpoint takes no request body and should return 200 OK with a collection when authorized. It also requires an active Intune license for the tenant.^1^

Interpret the result as follows:

• 200 OK: Intune RBAC data is available through Graph. The portal’s broad 401 behavior is then a separate portal/service authorization problem.
• 401: Capture the response body and request-id; inspect the token’s scp claim to ensure it includes the required delegated RBAC scope.
• 403: The token is authenticated but not authorized for the operation.
• 400: Capture the complete response body. Confirm that the request is GET, has no body, and uses the exact collection path above.

Your reported /beta/deviceManagement/roleScopeTags path is structurally correct, so its full 400 response—including error.code, error.message, request-id, and timestamp—is needed to determine why Graph rejected it. Avoid treating /deviceManagement returning 200 as proof of access to every child resource; each operation has its own permission requirements.

For a write test, creating a scope tag requires DeviceManagementRBAC.ReadWrite.All and a POST to the same collection.^2^ Do not use that test until the read request works.

2. Check enterprise-app assignment only if sign-in logs show AADSTS50105

Since roles and licensing have already been verified, do not repeat those checks. Instead, examine the affected sign-in in Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs.

If—and only if—the failure contains AADSTS50105, the relevant enterprise application has Assignment required? enabled but the user lacks a qualifying assignment. An Application Administrator, Cloud Application Administrator, or service-principal owner should:

1. Go to Entra ID → Enterprise apps → All applications.
2. Select the application identified in the failed sign-in.
3. Open Properties and review Assignment required?
4. If assignment must remain enabled, open Users and groups → Add user/group, assign the affected user directly or through a group of which the user is a direct member, and select Default Access if no named role exists.
5. If assignment is not intended, set Assignment required? to No and save. This broadens token eligibility, so use it only when consistent with the organization’s access policy.
6. Retest with the affected account, not a Global Administrator, because that assignment requirement does not apply to Global Administrators.^3^

A generic Intune portal 401 does not establish this condition; skip this branch if AADSTS50105 is absent.

3. Escalate the tenant-wide pattern

Because multiple independent Intune administration surfaces are affected—Tenant Status, Autopilot profiles, scope tags, and custom RBAC roles—while basic device-management calls work, the available evidence cannot confirm whether the remaining fault is tenant provisioning, portal authorization, or another service-side state.

Open an Intune support request and provide:

• Tenant ID and affected account UPN
• UTC date/time and time zone for each reproduction
• Portal session ID shown in Copy error details
• The complete portal 401 payload
• Graph request-id, client-request-id, status, and complete response body
• Exact Graph URL and HTTP method
• Sanitized token claims: aud, tid, scp/roles, and exp—never the Bearer [Token] itself
• Confirmation that several Intune blades fail while /deviceManagement and /managedDevices return 200
• Whether another administrative account has the same result

Microsoft’s troubleshooting guidance specifically recommends supplying the correlation ID, affected UPN, tenant ID, browser, time/time zone, and traces when escalation is required.^4^

References

1. List roleScopeTags
2. Create roleScopeTag
3. Error AADSTS50105 - The signed-in user isn't assigned to a role for the application
4. Troubleshoot application sign-in