Entra User Management: MFA, SSO, Conditional Access, and User Management Guide 2026

Conditional Access is the most powerful tool in Entra user management, and the most common source of unexpected blockages. A policy that's correctly scoped for 95% of your users will silently destroy the experience for the other 5% if you haven't accounted for edge cases like shared devices, service accounts, break-glass admin accounts, or new hires who haven't yet completed MFA registration.

Start by navigating to Protection > Conditional Access > Policies in the Entra admin center. Look for any policy set to "All users" in the Assignments section. These are your highest-risk policies. For each one, expand the Exclude section, is your break-glass emergency account excluded? Is a dedicated exclusion group listed so you have a controlled way to handle exceptions?

If a user is being blocked unexpectedly, use What If, it's a button right at the top of the Conditional Access blade. Enter the user's UPN, choose the application they're trying to reach, set the IP address and device compliance status, and click What If. It simulates exactly which policies would fire and what the result would be. This is dramatically faster than reading through ten different policies manually.

Common scope conflicts I see:

• A "Require MFA for all cloud apps" policy that doesn't exclude the Microsoft Intune Enrollment app, this prevents devices from enrolling, which then causes them to fail the device compliance check in other policies
• A "Block legacy authentication" policy that catches a line-of-business app still using basic auth (error code AADSTS54005)
• A "Require compliant device" policy applied to users who are on BYOD personal devices with no MDM enrollment path offered

If What If confirms the policy is the blocker, the immediate fix is to add the affected user to the policy's exclusion group, unblock them, then fix the underlying scope issue properly before removing the exclusion. Never leave permanent exclusions in place, schedule a review date.

One of the most impactful features in Microsoft Entra user management is group-based license assignment, instead of managing licenses user by user (which is genuinely painful at scale and extremely error-prone), you assign a license to a group and every member gets it automatically. When a user joins the group, Entra ID assigns the license. When they leave, the license is reclaimed. Clean, automatic, auditable.

But when it breaks, it breaks quietly. Users don't get a useful error, they just find that Teams won't open, or that they're missing an app in the Microsoft 365 portal, and they assume it's a software problem.

Here's how to find and fix license assignment errors. Go to Billing > Licenses > All products, select the license (say, Microsoft 365 Business Premium), then click Licensed groups. Any group showing a warning icon has users inside it with license errors. Click the group name, then click View errors, you'll see a list of affected users with specific error reasons.

The two most common errors:

• CountViolation, you've run out of available license seats. Go to Billing and purchase more, or remove inactive users from the group first.
• MutuallyExclusiveViolation, the user already has a license assigned individually or through another group that conflicts with a service plan in this license. You need to remove the conflicting assignment first.

For bulk-fixing MutuallyExclusiveViolation errors, PowerShell is your friend:

# Find users with license conflicts in a specific group
$groupId = "your-group-object-id"
$members = Get-MgGroupMember -GroupId $groupId
foreach ($member in $members) {
    $user = Get-MgUser -UserId $member.Id -Property "DisplayName,AssignedLicenses,LicenseAssignmentStates"
    $errors = $user.LicenseAssignmentStates | Where-Object { $_.State -eq "Error" }
    if ($errors) {
        Write-Output "$($user.DisplayName): $($errors.Error)"
    }
}

After resolving conflicts, go back to the group's Licenses blade and click Reprocess to trigger immediate re-evaluation. Users should have their licenses applied within a few minutes for small groups, up to a couple of hours for groups with thousands of members.

Dynamic membership groups are genuinely one of the most powerful tools for scaling Entra user management, you write a rule once (like "add all users where department equals Engineering"), and Entra ID handles group membership automatically as HR updates user attributes in your directory. No manual adds, no forgetting to remove someone when they transfer teams.

The catch: dynamic groups require a Microsoft Entra ID P1 license for each unique user who is a member of one or more dynamic groups. I've seen organizations get surprised by this requirement, they set up dynamic groups across their tenant and suddenly need to purchase P1 licenses for every employee, not just admins. Budget for this before you roll it out widely.

When a dynamic group stops updating, the first thing to check is the rule syntax. Go to Groups > [your group] > Dynamic membership rules and look at the rule builder. If it's showing a validation error, the rule won't process. Even a single typo in an advanced rule expression breaks the entire evaluation.

Use the Validate Rules feature, add a few test users (both ones you expect to be included and ones you expect to be excluded) and click Validate. Entra will tell you whether each user would match the rule and why. This is invaluable for debugging rules that are syntactically valid but logically wrong.

A common dynamic group rule for department-based membership:

(user.department -eq "Engineering") -and (user.accountEnabled -eq true)

Important: dynamic group membership updates are asynchronous. After a user's attribute changes (say, their manager updates their department in the HR system and it syncs to Entra), it can take anywhere from a few minutes to several hours for the group membership to update, depending on tenant size and service load. If you need immediate group membership for an urgent situation, you can temporarily switch the group type to Assigned, add the user manually, then switch back, but be aware this resets the dynamic membership evaluation and Entra will re-sync all members from scratch when you switch back.

Single sign-on configuration in Entra user management is where I see the most variety in failure modes, because every application implements SSO slightly differently, even when they all claim to support SAML 2.0 or OpenID Connect. The errors range from infuriating (a blank white page after the Entra login redirect) to at least somewhat helpful (AADSTS70011: The provided value for the input parameter 'scope' is not valid).

When an enterprise app SSO is broken, start in Enterprise Applications > [your app] > Single sign-on. If the app uses SAML, scroll down to the SAML Signing Certificate section, check the expiration date. An expired SAML certificate is one of the most common SSO failure causes I encounter, and it's entirely preventable. Entra will warn you 60 days before expiry, but those warnings often go to a mailbox nobody monitors.

For SAML apps, use the Test single sign-on button on the SSO configuration page. It runs a full authentication flow and shows you exactly where it fails, including whether the Identifier (Entity ID) or Reply URL (ACS URL) doesn't match what the application is expecting. Error AADSTS50011 specifically means the Reply URL in Entra doesn't match the one the app sent in its authentication request, fix it by adding the exact URL the app is sending as an additional Redirect URI.

For provisioning user access to enterprise apps at scale, use group assignment rather than individual user assignment:

1. In the app, go to Users and groups > Add user/group
2. Search for and select the security group that contains your target users
3. Assign the appropriate app role if the app uses role-based access

When you combine dynamic membership groups with group-based app assignment, new users who match your dynamic rule get automatic SSO access to the app, zero manual work per user. That's the Entra user management architecture you want to build toward. For apps that support SCIM provisioning, also configure automatic provisioning under the app's Provisioning section so accounts get created inside the app's own user directory automatically.

If you're a Microsoft partner managing client tenants, or if you're an enterprise IT administrator dealing with a CSP partner who manages your Microsoft 365 environment, understanding the difference between Delegated Admin Permission (DAP) and Granular Delegated Admin Permission (GDAP) is essential. Getting this wrong doesn't just cause access errors, it's a security risk.

The old DAP model gave CSP technicians Global Administrator and Helpdesk Administrator roles over your entire tenant. That's an extremely broad permission grant. Microsoft has been pushing hard for everyone to migrate to GDAP, which lets you specify exactly which roles the partner needs, scoped to specific workloads, with an expiration date. It's a much healthier security posture.

To see what delegated relationships currently exist in your tenant, go to the Microsoft Entra admin center > External Identities > Cross-tenant access settings, or sign in to the Microsoft 365 Admin Center and navigate to Settings > Partner relationships. You'll see a list of all active DAP and GDAP relationships, their expiration dates, and the roles granted.

If a GDAP relationship has expired and your CSP partner has lost access, here's what happens on your side: your Global Administrator will see a notification banner on the Delegated Administration page in the Entra admin center. The partner needs to initiate a new GDAP relationship request, you'll approve it by reviewing the requested roles, the partner tenant, and the proposed expiration date. Only a Global Administrator in your tenant can approve a new GDAP relationship request. If your Global Administrator account is also the break-glass account and you're having trouble accessing it, see the Advanced Troubleshooting section below.

For your own internal Entra user management, use the built-in limited administrator roles instead of handing out Global Administrator broadly. The three most commonly needed roles that avoid over-provisioning are:

• Application Administrator, can manage enterprise applications, app registrations, and application proxy settings, but cannot manage Conditional Access policies directly
• Cloud Application Administrator, same as Application Administrator but without application proxy management
• Application Developer, can create and update app registrations but has no access to enterprise application management

Assigning these scoped roles instead of Global Administrator means a compromised account causes far less damage. Always assign the least-privileged role that gets the job done.