Password, MFA & Conditional Access Troubleshooting — Practical Guide for IT Pros

Password, MFA & Conditional Access Issues — Practical Troubleshooting Guide for IT Pros

Authentication problems cause the majority of helpdesk tickets. This deep-dive shows common pain points, root-cause checks, remediation steps, PowerShell and Microsoft Graph recipes, and defensive practices so you fix issues faster and reduce repeat incidents.

Length: ~4,000+ words • Audience: IT admins, IAM engineers, helpdesk leads • Scope: Password expiry, SSPR, MFA misconfiguration, Conditional Access (CA) blockers.

Authentication is the gateway to everything. When passwords, MFA or Conditional Access (CA) misbehave, users can't work and helpdesks get overwhelmed. This guide is designed for operational use: checklists, diagnostics, sample PowerShell and Microsoft Graph commands you can paste into a runbook, and a few best-practices to reduce recurrence.

Why these three are linked

Passwords, MFA and Conditional Access are tightly coupled in modern identity stacks (Azure AD / Microsoft Entra ID, Okta, Ping, etc.). For example:

Password expiry or incorrect recovery configuration leads to sign-in failures that surface as "MFA not available" when users attempt to verify their identity during password reset flows.
MFA that is misconfigured or where the user has unregistered methods can block access — sometimes Conditional Access policies then treat the session as non-compliant and block sign-in entirely.
Conditional Access rules (location, device compliance, risk, client app) may block legitimate access — and many admins forget to simulate a rule using "What If" before applying it.

Common pain points (real-world)

Password expiry and users not being warned — SSPR not enabled or misconfigured.
MFA methods unregistered, or users lost their authentication phone.
Conditional Access policies with aggressive conditions (named locations, legacy auth block, device platform) inadvertently blocking remote users or admins.
Admin accounts not excluded from CA during emergency access configuration.
Time skew on hardware tokens or authenticator apps causing TOTP mismatches.
Third-party SSO (SAML/OIDC) misconfigurations with mismatch in claims or session lifetimes.

Operational checklist — first 10 minutes

Tip: When a user reports "I can't sign in", follow this rapid triage checklist to narrow the issue quickly.

Confirm exact error message (copy/paste) and time of attempted sign-in with timezone (use absolute time, e.g., "2025-10-23 14:12 IST").
Ask if the user is on corporate network, VPN, or remote network — note IP and public location if possible.
Check if the user can authenticate with another client (web vs. native app) — helps isolate client-app issues or legacy auth blocks.
Confirm whether the user recently changed device, SIM, phone, or restored from backup.
Check service health (Azure AD / Entra status) and current incidents — if multiple users across org, likely service-side. (Your preferred status dashboard.)

Detailed diagnostics — user-level

Below are step-by-step checks for password, MFA and CA problems, including PowerShell/Graph commands you can run as an admin to inspect the user's configuration and recent authentication attempts.

Password issues & Self-Service Password Reset (SSPR)

Symptoms: "My password expired", "I can't reset my password", SSPR returns error, or email/SMS verification not received.

Checks

Is SSPR enabled for the user? Does the user belong to a group excluded from SSPR?
Has the user registered verification methods? (email alternate, phone, security question where applicable)
Are there Conditional Access policies that block the password reset flow (rare but possible if password reset is gated)?
Is the user's account locked or has sign-in blocked? (Check user account state.)
Is MFA required to perform password reset in your policy? If yes, ensure user has working MFA methods.

PowerShell (AzureAD/MicrosoftEntra) checks

# Connect (MSOnline / AzureADPreview or Microsoft.Graph SDK recommended) # Example using AzureADPreview / MSGraph PowerShell (recommended modern SDK): Install-Module Microsoft.Graph -Scope CurrentUser -Force Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","Directory.Read.All"
Get user object and SSPR info

$userPrincipalName = "alice@contoso.com
"
$user = Get-MgUser -UserId $userPrincipalName -Property "displayName,accountEnabled,userPrincipalName"
$user | Format-List displayName,userPrincipalName,accountEnabled

Check authentication methods (MS Graph)

Get-MgUserAuthenticationMethod -UserId $userPrincipalName

To list phone and email methods:

Get-MgUserAuthenticationPhoneMethod -UserId $userPrincipalName
Get-MgUserAuthenticationEmailMethod -UserId $userPrincipalName

Check if the account is blocked from sign-in

($user.AccountEnabled) -eq $false

Microsoft Graph (REST) example

GET https://graph.microsoft.com/v1.0/users/alice@contoso.com/authentication/phoneMethods GET https://graph.microsoft.com/v1.0/users/alice@contoso.com/authentication/emailMethods

If methods are missing, SSPR will fail for that user. Re-enroll methods or guide them through the SSPR registration flow.

MFA problems

Symptoms: "I don't receive push", "Authenticator code not accepted", "I lost my phone".

Common root causes

User hasn't registered MFA methods (or removed them).
Authenticator app push not reaching device due to network/Doze mode or OS-level battery optimization.
TOTP time skew on device or hardware token — TOTP requires accurate time.
Phone number changed and SMS delivery fails due to carrier issues.
Conditional Access requiring compliant device / named location incorrectly configured making MFA appear to fail.

Triage steps

Ask user to try a different method (SMS, alternate phone, OATH hardware token, or generate TOTP from a secondary device).
Check Azure AD sign-in logs to see why MFA challenge failed and what method was requested.
If push notifications fail, instruct users to re-register the authenticator app (they can keep existing app but re-add account if necessary).
Check for global service outages for Push notifications (rare) or known issues with upstream providers.
As emergency fallback, use break-glass emergency access admin accounts (pre-configured high-privilege accounts excluded from CA). Do not create ad-hoc global admins while troubleshooting.

PowerShell & Graph diagnostics

# List user's authentication methods (modern Graph SDK) Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All","AuditLog.Read.All" $user = "alice@contoso.com" Get-MgUserAuthenticationMethod -UserId $user
Check sign-in logs to see MFA details (requires AuditLog.Read.All)
Filter sign-ins for the user in last 24 hours

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alice@contoso.com
' and createdDateTime ge 2025-10-23T00:00:00Z" |
Select-Object id,createdDateTime,clientAppUsed,conditionalAccessStatus,authenticationMethods

Example: See conditionalAccessStatus and MFA detail

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alice@contoso.com
'" |
Select-Object createdDateTime,userDisplayName,appDisplayName,conditionalAccessStatus,mfaDetail

Review authenticationMethods and mfaDetail in the sign-in record to learn which challenge was issued and its result.

Conditional Access (CA) problems

Symptoms: "Access is blocked", "Device not compliant", "Location blocked", "Legacy auth is blocked".

Why CA can block legitimate users

Policy targeting too broad (applies to "All users" including break-glass accounts).
Named locations or IP ranges are incorrect — remote users appear to sign in from untrusted location.
Device compliance checks fail due to missing Intune registration, outdated OS, or failed compliance policies.
Baseline assumptions: admin created a CA requiring device compliance for all SaaS apps, unintentionally blocking web clients or service accounts.

Operational checks

Use the "What If" tool in Azure AD Conditional Access to simulate the effect of a policy for a specific user, location, client app and device state. This is critical before enabling policies.
Look at the sign-in diagnostic for the specific sign-in — CA evaluation will show which policy applied and which control caused the block.
Check if the policy uses user risk / sign-in risk — those are dynamic and may change behavior.
Verify exclusions: ensure emergency access accounts and service principals are excluded where appropriate.

PowerShell & Graph: find applied Conditional Access policy

# CA policy metadata is not directly editable with MS Graph in all tenants unless you use the IdentityProtection and Conditional Access APIs. # But you can inspect sign-in logs to see the policy that applied: Connect-MgGraph -Scopes "AuditLog.Read.All","Policy.Read.All" $signins = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alice@contoso.com' and createdDateTime ge 2025-10-23T00:00:00Z" $signins | Select-Object createdDateTime,appDisplayName,conditionalAccessStatus,appliedConditionalAccessPolicies
Example output includes appliedConditionalAccessPolicies (id,displayName,result)
To list all Conditional Access policies (requires Policy.Read.All)

Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies
" | ConvertFrom-Json

The appliedConditionalAccessPolicies collection in the sign-in record shows which policy evaluated and the effect shown as "grantControls" or "result". Use the "beta" endpoint carefully for policy enum details.

Troubleshooting recipes — scenarios & step-by-step fixes

Scenario 1 — Password expired, SSPR not working

Symptoms: User's password expired; SSPR flow throws an error "You can't reset your password because your admin hasn't set up recovery information".

Confirm SSPR configuration in Azure AD (enabled for the correct groups). SSPR configuration.
Check the user's authentication methods via Graph (`/authentication` endpoints). If no methods exist, instruct user to register or temporarily reset their password as an admin.
If admin reset required — use temporary reset with a secure random password, then force user to change at next sign-in and guide them to register SSPR methods.
Consider enabling "Require all users to register" and running a staged rollout, plus helpdesk playbooks to reduce calls.

Scenario 2 — MFA push failing for many users

Check sign-in logs for push failure reasons (app not reachable, user declined, device offline).
Ask a user to ensure Authenticator app notifications are enabled (not disabled by battery/Doze). Recommend OS settings tweaks (e.g., Android battery optimization exclusions).
Verify if an org-wide change (APNs, FCM) impacted push notifications — check Microsoft service status or known issues for push providers.
If push repeatedly fails, ask user to re-register the authenticator (they will keep account but re-registering can clear stale device tokens).

Scenario 3 — Conditional Access unexpectedly blocking third-party app

Identify the sign-in entry and look at appliedConditionalAccessPolicies to see which policy blocked access.
Run "What If" for the user and client app to reproduce the policy effect without changing it.
Temporarily exclude the app or group while analyzing policy conditions and refine policy targeting (narrow users, exclude service accounts, adjust device platform checks).
Add clear logging and policy change tickets in your change control so future CA adjustments are tracked.

Recovery & remediation scripts

Below are reusable PowerShell and Graph snippets for common remediation tasks. Use them inside your admin runbooks and verify permissions/scopes carefully.

1) Bulk enable SSPR for a group

# Using Microsoft.Graph.PowerShell Install-Module Microsoft.Graph -Force Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod,Group.ReadWrite.All"
Example: Enable SSPR for a group via Azure AD portal is typical; programmatic control is often via AzureAD portal or Conditional Access.
If your tenant supports setting password policies via Graph (preview), follow the Graph docs. For most tenants use the portal:

Write-Output "SSPR settings are managed in Azure AD portal; runbook should direct operator to Azure AD > Password reset > Properties"

Some organization-wide SSPR settings remain portal-first. Use automation for user method seeding and monitoring instead of direct toggles where APIs aren't available.

2) Reset a user's MFA methods (re-register) — emergency

# Only perform this after authentication and appropriate approvals. # This removes a user's existing methods and forces re-registration. $user = "alice@contoso.com" # Example using MS Graph PowerShell to delete phone/email methods: Get-MgUserAuthenticationPhoneMethod -UserId $user | ForEach-Object { Remove-MgUserAuthenticationPhoneMethod -UserId $user -AuthenticationPhoneMethodId $_.Id -Confirm:$false } Get-MgUserAuthenticationEmailMethod -UserId $user | ForEach-Object { Remove-MgUserAuthenticationEmailMethod -UserId $user -AuthenticationEmailMethodId $_.Id -Confirm:$false }
To reset Microsoft Authenticator registrations for cloud-only users, consider using Azure AD PowerShell 'Reset-MsolStrongAuthenticationByUpn' (legacy).
Note: Use with caution. Confirm MFA removal will allow re-registration, and communicate to user.

3) Query sign-in failures and count top failure reasons (sample)

# Pull last 7 days sign-in logs and aggregate failure reasons $from = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ") $filter = "createdDateTime ge $from" $signins = Get-MgAuditLogSignIn -Filter $filter -All $signins | Where-Object { $_.status.errorCode -ne 0 } | Group-Object -Property @{Expression={$_.status.failureReason}} | Sort-Object Count -Descending | Select-Object Name,Count | Format-Table -AutoSize

Useful Graph API endpoints & queries

Keep these endpoints handy in your runbook.

GET /auditLogs/signIns — sign-in logs including CA evaluation and MFA details.
GET /users/{id}/authentication — list and manage user MFA and auth methods.
GET /identity/conditionalAccess/policies (Beta) — list CA policies (read-only in many tenants).
GET /identityProtection/riskDetections — if using Identity Protection, view user risk detections.

Best practices & hardening (to prevent repeated tickets)

Emergency Break-Glass Accounts: maintain at least two emergency admin accounts excluded from Conditional Access and MFA (secure, monitored, only used in emergencies).
Staged CA rollouts: use pilot groups first and run "What If" simulations to test effectiveness.
SSPR Adoption Campaign: enforce or strongly encourage MFA & SSPR registration during onboarding and periodic reminders for non-registered users.
Monitoring: automate sign-in failure alerts for spikes — correlate with service incidents or CA policy changes.
Documented Runbooks: for password resets, MFA reset, and CA exceptions. Ensure helpdesk has appropriately scoped delegated permissions (e.g., Password Reset Admin) not global admin.
Time Sync: for TOTP hardware tokens and servers, make sure NTP is correctly configured.

Policies & governance — change control for CA

Because Conditional Access policies can block access to critical systems, treat CA changes carefully:

Submit a change request describing the scope, affected users/apps, and planned rollout.
Run "What If" and log results. Include test user sign-ins demonstrating expected behavior.
Schedule changes during low-impact windows and maintain a rollback plan.
Notify impacted groups and update internal KB articles once changes are live.

Security trade-offs

Every control brings friction. Your goal is to balance security and usability — too strict and you create helpdesk load and shadow-IT; too lenient and you increase risk. Some pragmatic trade-offs:

Require MFA everywhere but allow trusted device cookies for a limited time.
Use named locations (trusted IPs) carefully — avoid hardcoding dynamic IPs.
Prefer conditional access requiring compliant devices for high-risk apps rather than blanket restrictions.

Sample helpdesk playbook (copy-paste friendly)

Helpdesk Playbook - Authentication Triage (Quick Steps) 1. Get exact error text and timestamp from user. 2. Ask whether user changed device/phone/SIM recently. 3. Try web.sign-in from an Incognito window. 4. Check https://portal.azure.com -> Azure AD -> Sign-ins for that user at the timestamp. 5. Look at appliedConditionalAccessPolicies and failure reason. 6. If Password expired: reset password (Password admin role) -> force change at next sign-in -> assist user to enroll SSPR. 7. If MFA failure: verify authentication methods -> if appropriate, reset methods after approval -> guide re-enrollment. 8. If CA blocked: run "What If" -> consider temporary exclusion & open a change request to update policy. 9. Document action in ticket and advise user on next steps to avoid recurrence.

Troubleshooting advanced cases

Time-based One-Time Password (TOTP) mismatches

If users report codes "not working" for authenticator apps or hardware tokens:

Check device time — even a few minutes skew can cause failure. Advise to set time to network-provided time (auto-sync).
For hardware tokens, verify token serial and provisioning information. Re-issue if tampered.

Legacy authentication and Conditional Access

Legacy authentication (IMAP, POP, SMTP AUTH) doesn't support modern controls like MFA. Blocking legacy auth can break older clients or service accounts. Mitigations:

Identify legacy auth usage from sign-in logs and migrate apps to modern auth or service principals with app-only tokens.
Whitelist specific service accounts with strict controls or use secure application access patterns (managed identities, service principals) rather than user accounts.

Service account & automation breakage

Conditional Access can unintentionally block automation using user credentials. Use service principals with certificate-based auth or managed identities where possible. Exclude such service principals explicitly from user-targeted CA when necessary — but prefer upgrading automation to modern auth.

Operational metrics to track

Daily sign-in failure rate (per 1,000 sign-ins)
Number of SSPR-related tickets per week
MFA reset requests per month
Number of Conditional Access policy changes and incidents correlated with CA changes

Useful links & resources

Bookmark these internal/external resources in your runbook. (The links below are intentionally concise — make sure operators have direct access to tenant portals and monitoring dashboards.)

cloudknowledge.in — Operations & Guides
Azure AD Sign-in logs: Azure Portal → Azure Active Directory → Sign-ins
Conditional Access What If: Azure Portal → Security → Conditional Access → What If
Microsoft Graph API documentation: https://learn.microsoft.com/graph/ (use Graph Explorer for testing)

Appendix — Example Graph queries and their expected outputs

These examples show quick diagnostics you can run (with appropriate privileges).

1) Get last 10 sign-ins for a user and include conditional access details

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=userPrincipalName eq 'alice@contoso.com'&$orderby=createdDateTime desc&$top=10

--> Response contains: id,createdDateTime,appDisplayName,clientAppUsed,ipAddress,conditionalAccessStatus,appliedConditionalAccessPolicies,mfaDetail

2) Fetch user's registered authentication methods

GET https://graph.microsoft.com/v1.0/users/alice@contoso.com/authentication/methods

--> Response contains list of methods: phone, sms, authenticator, fido2, email, etc.

Communication templates

Use the templates below when notifying users after remediation.

Template: Resolved - MFA re-enrollment required Subject: Action required: re-enroll your MFA methods

Hi ,

We resolved the sign-in issue with your account. To restore full access, please re-enroll MFA using the Microsoft Authenticator app:

Install Microsoft Authenticator on your phone.

Go to https://aka.ms/mysecurityinfo
 and follow the steps to add a new Authenticator account.

If you need help, reply to this ticket and schedule a short session.

Thanks,
IT Support

Prevention checklist to include in onboarding

Enable SSPR & require registration during onboarding.
Enroll MFA and verify push/SMS delivery.
Provide a short "how to" doc with screenshots for Authenticator registration and SSPR.
Ensure emergency admin accounts are created and their credentials are stored securely (password manager + auditable access).

Final notes & operational advice

Authentication incidents are high priority: they impact productivity and security. Having repeatable, permissioned runbooks, well-scoped Conditional Access policies, and ongoing monitoring dramatically reduce mean-time-to-restore (MTTR). Always test CA changes with "What If", and avoid ad-hoc global admin escalations — prefer scoped admin roles for helpdesk and password resets.

Azure AD authentication failure Azure AD MFA issues Azure AD sign-in logs troubleshooting.Azure AD What If simulation Azure conditional access problems Azure MFA code invalid Azure MFA not prompted Azure password reset failed Conditional Access best practices Conditional Access policy block Conditional Access simulation Azure Conditional Access troubleshooting Entra ID audit logs PowerShell Entra ID blocked sign-in Entra ID conditional access misconfiguration Entra ID MFA configuration Entra ID sign-in errors Entra ID user MFA methods Entra ID What If tool Graph API MFA troubleshooting MFA authentication failed MFA device lost fix MFA registration check PowerShell MFA reset PowerShell script MFA troubleshooting guide MFA unregistered users Microsoft Authenticator issues Microsoft Entra ID password reset Microsoft Graph conditional access Microsoft Graph sign-in logs password expiry Entra ID password reset policy Azure AD password troubleshooting Azure PowerShell password reset script self service password reset sspr SSPR enable PowerShell SSPR not working troubleshoot authentication errors Entra ID troubleshoot MFA Entra ID troubleshoot sign-in Azure AD