Azure RBAC / Entra Roles: MFA, SSO, Conditional Access, and User Management Guide 2026

Before changing anything, you need a clear picture of what's actually assigned. Surprises happen when you start modifying role assignments without knowing the baseline state. This is especially true in environments where multiple admins have been adding assignments over time without documentation.

Open the Microsoft Entra admin center at entra.microsoft.com. In the left nav, go to Identity > Roles & admins. Click All roles to see every built-in and custom Entra role in your tenant. For a targeted audit, use Microsoft Graph PowerShell instead:

# Connect to Microsoft Graph with required permissions
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

# List all active role assignments in the tenant
Get-MgRoleManagementDirectoryRoleAssignment | Select-Object RoleDefinitionId, PrincipalId, DirectoryScopeId

This will return every role assignment, including ones made through Privileged Identity Management (PIM) that might not be obviously visible in the UI. Pay attention to the DirectoryScopeId column. A value of / means tenant-wide scope. A value like /administrativeUnits/<guid> means it's scoped to an administrative unit. A value pointing to an application registration GUID means it's scoped to just that resource.

Note: Azure CLI is not supported for Microsoft Entra role assignments. If you see advice online telling you to use az role assignment list for Entra roles, that's incorrect, that command only covers Azure resource roles. You need either the Microsoft Entra admin center, Microsoft Graph PowerShell, or the Microsoft Graph API directly.

When the audit completes, you should have a clear list of who has what at which scope. That list is your troubleshooting baseline. If a user is missing a necessary assignment, you'll add it in the next steps. If someone has broader access than they should (like tenant-wide scope when they only need object-level access), you'll flag that for remediation.

This is where most issues get fixed. You're going to either confirm an existing assignment's scope is correct or create a new assignment at the right scope. Remember the core principle: Microsoft Entra RBAC is a two-part process, first you have a role definition (a collection of permissions), and then you create a role assignment that connects a security principal to that definition at a specific scope.

In the Microsoft Entra admin center, navigate to Identity > Roles & admins > All roles. Find the role you want to assign, for example, Application Administrator or a custom role you've created. Click on it, then click + Add assignments.

In the assignment panel, the first thing to set is scope. You have three options:

• Tenant, the user can act on all resources of the relevant type across your entire directory
• Administrative unit, permissions are limited to objects inside a specific administrative unit you select
• Resource, permissions are limited to one specific Microsoft Entra resource, such as a single app registration or enterprise application

For example, if a developer only needs to manage the Contoso Expense Reports app registration, set scope to the specific app registration. Don't assign Application Administrator at tenant scope just because it's easier, that grants them the same permissions over every app registration in your directory.

After setting scope, select the user, group, or service principal as the security principal. Click Assign. The assignment takes effect in the directory almost immediately. As covered earlier, the user will need to sign out and back in to get a refreshed token.

If you're using PowerShell:

$roleDefinitionId = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Application Administrator'").Id
$principalId = (Get-MgUser -Filter "userPrincipalName eq 'dev@contoso.com'").Id

New-MgRoleManagementDirectoryRoleAssignment `
  -RoleDefinitionId $roleDefinitionId `
  -PrincipalId $principalId `
  -DirectoryScopeId "/"

Replace "/" with "/administrativeUnits/<unit-id>" or "/applications/<app-id>" to scope to an administrative unit or specific resource respectively.

Built-in Entra roles cover a lot of ground, but they're fixed. You can't modify them. When your requirements don't match any built-in cleanly, say, you need someone who can read user profiles and reset passwords but shouldn't be able to delete users or manage groups, a custom role is the answer.

Custom Entra roles require Microsoft Entra ID P1 or P2 licensing. If you try to create one without the right license, you'll hit an error in the portal. Check your license tier first at Identity > Overview > Licenses.

To create a custom role, go to Identity > Roles & admins > All roles > + New custom role. Give it a clear, descriptive name. On the Permissions tab, search for specific permissions from the preset list. For password reset, look for microsoft.directory/users/password/update. For reading user profiles, add microsoft.directory/users/standard/read.

Here's the important thing about custom role permissions: they come from the exact same permission set used in built-in roles. You're not inventing new capabilities, you're selecting a subset. This keeps the permission model consistent and auditable.

Using PowerShell to create a custom role:

$rolePermissions = @{
  allowedResourceActions = @(
    "microsoft.directory/users/password/update",
    "microsoft.directory/users/standard/read"
  )
}

New-MgRoleManagementDirectoryRoleDefinition `
  -DisplayName "Password Reset Operator" `
  -Description "Can read user profiles and reset passwords" `
  -IsEnabled $true `
  -RolePermissions @($rolePermissions) `
  -TemplateId (New-Guid).Guid

Once the custom role definition exists, assign it exactly as you would a built-in role, select the principal, set the scope, create the assignment. You can assign the same custom role definition many times at different scopes. One user might have it at tenant scope; another might have it scoped to a specific administrative unit. The definition is reusable.

Here's a scenario I see constantly: an admin assigns an Entra role correctly, the user can see it in their account settings, but they still can't perform the action. The error message is something vague like "Authentication required" or "Your sign-in was blocked." This is almost always a Conditional Access policy running interference.

Conditional Access sits above RBAC in the authorization chain. Even if a user has the right Entra role with the right scope, a Conditional Access policy can block the sign-in or the specific action entirely. The most common culprits:

• MFA not satisfied: A policy requires MFA for privileged directory roles, but the user signed in without completing MFA (common when signing in from a trusted location that was recently removed from the trusted IP list)
• Non-compliant device: A policy requires Intune-compliant devices for directory admin actions, and the user's machine failed compliance
• Sign-in risk block: Microsoft Entra ID Protection flagged the sign-in as medium or high risk, and a policy blocks risky sign-ins from completing

To diagnose, go to Protection > Conditional Access > Sign-in logs in the Microsoft Entra admin center. Filter by the affected user and the timeframe of the failed access. Look for sign-in entries with a status of Failure or Interrupted. Click into the entry and go to the Conditional Access tab. You'll see exactly which policy applied, what condition it checked, and what it decided. This is the most direct way to find out which policy is blocking access.

If MFA is the issue and the user legitimately completed MFA, check whether their MFA methods are still valid. A phone number change or an authenticator app reset can leave the account in a state where existing sessions think MFA is satisfied but new policy checks disagree.

# Check MFA registration status for a user
Get-MgUserAuthenticationMethod -UserId "user@contoso.com"

For SSO issues where users are getting authentication prompts they shouldn't be seeing, check the enterprise application's SSO configuration under Applications > Enterprise applications > [App name] > Single sign-on. Verify the SAML entity ID, reply URL, and signing certificate haven't expired. An expired SAML certificate will break SSO silently and produce very unhelpful error messages in the browser.

If you're managing access at scale, assigning roles directly to individual users doesn't hold up. You end up with dozens of direct assignments that are impossible to audit cleanly. Groups are the answer, but not just any group. Microsoft Entra RBAC has a specific requirement: a group must be flagged as a role-assignable group before you can assign Entra directory roles to it.

This is a one-time, irreversible setting per group. Once a group is marked as role-assignable, its membership can only be managed by Global Administrators, Privileged Role Administrators, and group owners. This tighter control is intentional, a group with a directory role assignment is a high-value target, and Microsoft restricts who can modify its membership to prevent privilege escalation through group membership changes.

To create a role-assignable group, go to Identity > Groups > All groups > + New group. Set the group type to Security. You'll see a toggle labeled Microsoft Entra roles can be assigned to the group. Set that to Yes. You cannot flip this toggle on an existing group, you have to create a new one. Plan ahead.

Using PowerShell:

New-MgGroup `
  -DisplayName "Entra-AppAdmins" `
  -MailEnabled $false `
  -MailNickname "entra-appadmins" `
  -SecurityEnabled $true `
  -IsAssignableToRole $true

For service principals, the identities used by applications, hosted services, and automation tools, role assignments work the same way as for users. Get the service principal's object ID (not the application ID, they're different), then create the role assignment with that object ID as the principal. A common mistake is using the application ID instead of the service principal object ID, which silently fails or assigns to the wrong object.

# Get service principal object ID
$sp = Get-MgServicePrincipal -Filter "displayName eq 'MyAutomationApp'"
$sp.Id  # This is the object ID you need for role assignments

Once your role-assignable groups are set up, manage access by managing group membership rather than individual role assignments. Onboarding a new developer means adding them to the right group. Offboarding means removing them. Your role assignment list stays clean and auditable.