Fix Azure SSO Issues: AADSTS Error Code Guide [2026]

When Azure single sign-on (SSO) fails, the fastest route to the cause is the AADSTS code. Open Microsoft Entra admin center > Entra ID > Monitoring & health > Sign-ins, find the failed attempt, and read the Sign-in error code and Failure reason. That code tells you whether the problem is the user (not assigned, locked, wrong tenant), the app (reply URL, client ID, consent), a policy (Conditional Access, MFA, sign-in frequency), or the device (Seamless SSO Kerberos, missing PRT). The tables and sections below map each common code to the fix.

Microsoft Entra ID (formerly Azure Active Directory, or Azure AD) handles SSO for Microsoft 365, SaaS apps, and custom apps. When it breaks, it breaks at scale: unexpected sign-in prompts, redirect loops, and error pages full of AADSTS codes. For organizations relying on cloud engineering to run their infrastructure, a broken identity layer is one of the most disruptive failures there is. If users are missing from Entra ID entirely, or their passwords are not updating, the problem is upstream in directory sync: see our Entra Connect sync errors guide.

Quick Triage: Azure SSO Not Working?

Get the code. Ask the user for a screenshot of the error page, or find the attempt in the sign-in logs. Every Microsoft sign-in error page has a code and a correlation ID; the sign-in log has the full failure reason.
Look up the code. Use the table below, Microsoft’s error code reference, or https://login.microsoftonline.com/error?code=<number> for codes not in the reference.
Check whether it is one user or everyone. One user points at assignment, MFA registration, device state, or account status. Everyone on one app points at the app configuration or a certificate. Everyone on every app points at a Conditional Access change, a federation or sync problem, or a Microsoft incident.
Run the Conditional Access What If tool for the user and app. If a policy blocks or adds a control you did not expect, that is your answer.
For hybrid users who get prompted on corporate PCs, run dsregcmd /status and check Seamless SSO (sections below).

How Azure SSO Works

Before jumping into logs, it helps to understand the basic Microsoft Entra SSO handshake:

The user opens an application (like Salesforce, Teams, or a custom app).
The app redirects the user to Microsoft Entra ID to authenticate.
Entra ID validates the user with credentials or an existing session (a Primary Refresh Token on joined devices, or a Kerberos ticket through Seamless SSO).
Entra ID evaluates Conditional Access, issues a token, and redirects the user back to the application.

If any of these steps fails because of a misconfiguration, an expired token, or a Conditional Access policy, SSO breaks.

Common Azure SSO Issues and Root Causes

Repeated sign-in prompts. Users authenticate again and again. Usual causes: a Conditional Access sign-in frequency control, a misconfigured reply URL, Seamless SSO not working on domain-joined PCs, or a device without a valid PRT.

Redirect loops. The browser cycles between the app and Entra ID without finishing. This is almost always a mismatch between the reply URL registered in Entra ID and the URL the app actually sends. Even a trailing slash difference can trigger it.

AADSTS error codes. Users see an error page with a code like AADSTS50105 or AADSTS700016. These codes tell you exactly what went wrong, but they need lookup and context. We cover the common ones below.

Access denied after successful authentication. The user signs in without error, but the app shows a permissions page. The user is usually not assigned to the enterprise application, or the token is missing a role or claim the app needs.

SSO works for some users but not others. Inconsistent SSO points at group membership, Conditional Access scope, device compliance state, or licensing.

AADSTS Error Code Reference

The meanings below come from Microsoft’s error code reference and the login.microsoftonline.com/error lookup. Codes are listed roughly by how often we see them in SMB tenants.

Error code	What it means	Recommended fix
AADSTS50105	The signed-in user isn’t assigned to a role for the app	Assign the user or their group to the enterprise app, or turn off “Assignment required”
AADSTS50011	Reply URL mismatch: the reply address is missing or doesn’t match the app registration	Add the exact redirect URI (scheme, host, path, trailing slash) to the app registration
AADSTS700016	Application not found in the directory/tenant	Check the client ID, the tenant in the sign-in URL, and whether the app was consented in this tenant
AADSTS65001	The user or administrator hasn’t consented to the application	Grant admin consent in the enterprise app’s Permissions blade, or enable the admin consent workflow
AADSTS50076	MFA required by a configuration change such as Conditional Access	Have the user complete MFA; confirm the policy scope is intended
AADSTS50079	User must register for MFA	User completes security info registration
AADSTS53003	Access blocked by Conditional Access	Find the blocking policy in the sign-in log’s Conditional Access tab
AADSTS50126	Invalid username or password	Expected occasionally; many in a row from unknown IPs means password spraying
AADSTS50053	Account locked (too many failed sign-ins) or sign-in blocked from a malicious IP	Wait for lockout to clear, investigate the source IPs
AADSTS50057	The user account is disabled	Re-enable the account in on-premises AD or Entra ID
AADSTS50055	Password expired	User resets the password
AADSTS50020	User account from an identity provider doesn’t exist in this tenant	Invite the user as a guest, or have them sign in with an account from this tenant
AADSTS90072	External account doesn’t exist in the tenant so it can’t satisfy MFA; also caused by an ImmutableID mismatch on synced users	Add the guest, or fix the source anchor mismatch in directory sync
AADSTS50107	The requested federation realm object doesn’t exist	Fix the federation or domain configuration the login request points at (details below)
AADSTS50197	The user could not be found; try signing in again	Confirm the account exists and wasn’t recently deleted or renamed
AADSTS50089	Authentication failed because the flow token expired	Expected after long idle sign-in pages; user starts again
AADSTS70044	Session expired or invalid due to Conditional Access sign-in frequency checks	Expected by design; adjust sign-in frequency if prompts are too frequent
AADSTS50133 (SsoArtifactRevoked)	Session isn’t valid because of password expiration or a recent password change	User signs in again with the new password
AADSTS700020	The access grant requires interaction	App must send an interactive sign-in request
AADSTS90097	An error occurred during admin consent processing	Retry consent as an admin with the right role; review the app’s requested permissions
AADSTS10040141	The request is invalid	Generic malformed request (details below)
AADSTS1100001	Non-retryable error with an underlying extensibility error code	Check custom authentication extensions or claims providers configured on the app
AADSTS5000820	Sign-in blocked by a Federated Token Validation policy	Review the tenant’s federated token validation settings with your admin
AADSTS135018	Invalid challenge received from FIDO assertion	Retry with the passkey or security key; update the browser and authenticator
AADSTS9002326	Cross-origin token redemption is permitted only for the ‘Single-Page Application’ client type	Register the redirect URI under the SPA platform, or remove the Origin header from non-browser token requests
AADSTS81010	Seamless SSO failed because the user’s Kerberos ticket has expired or is invalid	User signs in from a domain-joined device on the corporate network (see Seamless SSO section)

For anything not listed, Microsoft maintains the full AADSTS error code reference.

AADSTS10040141: The request is invalid

AADSTS10040141 does not appear in Microsoft’s published reference table. The lookup at login.microsoftonline.com/error returns only “The request is invalid.” In practice that means Entra ID rejected the shape of the request rather than the user. Work through it like this:

Find the failed attempt in the sign-in logs and open Additional Details; the failure reason there is often more specific than the error page.
Check whether users reach the sign-in page from an old bookmark or a saved login URL. Stale login.microsoftonline.com URLs with expired parameters produce invalid requests. Have the user start from the app or myapps.microsoft.com instead.
For custom apps, compare the authorization request against the app registration: client ID, tenant, redirect URI, response type, and scopes.
Clear the browser session (or test in a private window) to rule out corrupted cookies.

If every user hits it on the same app, it is the app’s request. If one user hits it everywhere, it is their browser or bookmark.

AADSTS50107: The requested federation realm object doesn’t exist

Despite older blog posts (including an earlier version of this one) describing AADSTS50107 as an MFA error, Microsoft defines it as “The requested federation realm object ‘{name}’ doesn’t exist”: the login request was malformed and couldn’t be matched to an existing authentication endpoint. You typically see it when:

An app or link sends a domain hint or realm for a domain that is not federated (or no longer is) in your tenant.
A domain was converted from federated to managed, but an app or AD FS relying party still points at the old realm.
A third-party IdP federation was removed or renamed.

Check the domain’s authentication type under Entra ID > Domain names, confirm any federation configuration with Microsoft Graph PowerShell (Get-MgDomainFederationConfiguration -DomainId contoso.com), and update the app’s sign-in URL or domain hint.

”Seamless single sign on failed for the user”

The full sign-in log message reads: interaction_required|Seamless single sign on failed for the user. This can happen if the user is unable to access on premises AD or intranet zone is not configured correctly. The message names both causes, and Microsoft’s Seamless SSO troubleshooting guide adds a few more. Check these in order:

Intranet zone: https://autologon.microsoftazuread-sso.com must be in the user’s Local intranet zone, usually via Group Policy. Putting it in Trusted sites instead blocks sign-in.
Domain and network: the device must be joined to AD, the user must be signed in with a domain account, and the device must be able to reach a domain controller (on the corporate network or on VPN).
Kerberos ticket: run klist and confirm there is a ticket for AZUREADSSOACC. If not, run klist purge and try again. Users in too many groups can have tickets too large to process.
Clock: the device, AD, and domain controllers must be within five minutes of each other.
Feature state: confirm Seamless SSO is still Enabled under Entra ID > Entra Connect > Connect Sync, and that the AZUREADSSOACC computer account exists and is enabled in each forest.
Browser: Seamless SSO does not work in Firefox private browsing or on iOS and Android mobile browsers.

If the device is also Microsoft Entra joined or hybrid joined, SSO through the PRT takes precedence over Seamless SSO, so check dsregcmd /status as well (next sections).

How to Troubleshoot Azure SSO Step by Step

Go to Entra ID > Monitoring & health > Sign-ins in the Microsoft Entra admin center:

Filter by user, application, and time.
Open the failed attempt and read the Sign-in error code, Failure reason, and Additional details.
Check the Conditional Access tab to see which policies applied and what they required.
Note the Correlation ID in case you need to open a Microsoft support case.

2. Review Enterprise App Settings

Go to Entra ID > Enterprise apps and open the application:

Make sure the SSO mode matches what the app expects (SAML, OIDC/OAuth 2.0, password-based, or linked). Microsoft’s guide on debugging SAML-based SSO is a good reference.
Validate the reply URLs (redirect URIs), the identifier (Entity ID or App ID URI), and the signing certificate (expiration date and thumbprint match on the app side).
Check Users and groups to confirm the affected user is assigned, directly or through a group.

SAML apps like Workday or ServiceNow need their signing certificate renewed before it expires. Microsoft’s guide on troubleshooting SAML-based SSO covers further certificate and configuration issues.

3. Test from My Apps

Have the user open myapps.microsoft.com and launch the app from there. If it works from My Apps but not from a bookmark, the bookmark or the app’s own sign-in URL is the problem. For SAML apps, the enterprise app’s Single sign-on > Test button runs the flow and shows the error with resolution guidance.

4. Validate Conditional Access

Conditional Access is a critical part of any security and compliance strategy. Under Entra ID > Conditional Access, look for policies that:

Block sign-in by location or named location
Require compliant or hybrid-joined devices
Require MFA or a specific authentication strength
Enforce a short sign-in frequency

Use Report-only mode to test new policies before enforcing them. Microsoft’s documentation on troubleshooting Conditional Access sign-in problems covers more scenarios. For building policies that do not lock people out, see our Conditional Access setup guide.

5. Inspect Domain and User Settings

Verify the user’s UPN uses the expected, verified domain (for example user@company.com, not user@company.local or onmicrosoft.com).
Check whether the domain is managed or federated under Entra ID > Domain names.
For hybrid users, confirm the account is syncing cleanly. UPN or ImmutableID mismatches from directory sync show up as sign-in failures; our Entra Connect sync troubleshooting guide covers those.
For hybrid setups using Seamless SSO, confirm the feature is enabled and the intranet zone GPO applies.

Microsoft Entra Hybrid Join and PRT Issues

On Windows, SSO to Microsoft 365 and Entra-integrated apps relies on the Primary Refresh Token (PRT), issued when a device is Microsoft Entra joined or Microsoft Entra hybrid joined (formerly Hybrid Azure AD join). If the device is not joined correctly, or the user signs in with a local account, SSO will not work. Proper device management is a core part of delivering modern workplace solutions that work for end users.

Run dsregcmd /status as the signed-in user (not elevated). For a healthy hybrid joined device you want:

AzureAdJoined : YES and DomainJoined : YES (hybrid joined) in Device State
DeviceAuthStatus : SUCCESS in Device Details
AzureAdPrt : YES with a recent AzureAdPrtUpdateTime in SSO State

If AzureAdPrt shows NO, the SSO State section often includes AcquirePrtDiagnostics with the server error code and description, frequently an AADSTS code you can look up above. Common causes include stale or deleted device objects in Entra ID, clock skew, and proxies that block or inspect traffic to login.microsoftonline.com, device.login.microsoftonline.com, and enterpriseregistration.windows.net. If DeviceAuthStatus reports the device is disabled or deleted, the device has to re-register.

For hundreds or thousands of devices, enforce join and compliance settings centrally with Microsoft Intune instead of fixing devices one at a time.

Token Lifetime and Session Persistence

Even with SSO configured correctly, users may see prompts because of token lifetimes and sign-in frequency. Entra ID issues access tokens (by default valid for a variable lifetime of 60 to 90 minutes), refresh tokens, and PRTs. If a Conditional Access policy enforces sign-in frequency, users must re-authenticate at that interval regardless of token state; the sign-in log records these as AADSTS70044.

Align sign-in frequency with the sensitivity of the app. Forcing re-authentication every hour may suit a finance system but is disruptive for Teams or Outlook.

Organizations that need help balancing security and user experience often benefit from a managed cloud provider with deep Microsoft identity experience.

Advanced SSO Error Scenarios

SAML Assertion Clock Skew

SAML assertions include timestamps that define when the assertion is valid. If the service provider’s clock is off, the assertion may be rejected as expired or not yet valid, even though Entra ID authenticated the user. This is common with on-premises applications and third-party apps that run their own time sources.

Capture the SAML response with a browser extension like SAML-tracer and compare the NotBefore and NotOnOrAfter timestamps with the service provider’s clock. Most SAML implementations allow 3 to 5 minutes of skew; some are stricter. Sync the service provider to a reliable NTP source and, if needed, raise its skew tolerance.

Token Claim Mismatches

Some applications require specific claims in the SAML token or OIDC JWT, such as a department claim or a custom role claim that Entra ID does not include by default. When those claims are missing, the user authenticates but the app returns an authorization error.

Identify the required claims from the app’s documentation, then configure them under the enterprise app’s Single sign-on > Attributes & Claims. For custom claims you may need claims mapping policies or optional claims on the app registration. This comes up often when moving apps from AD FS to Entra ID, since AD FS claim rules do not translate automatically.

For multi-tenant applications, users from other tenants must consent to the app’s permissions before they can sign in. If their organization requires admin consent (a common security and compliance setting), they will see AADSTS65001 until an admin in their tenant consents.

Give the external organization’s administrator a direct admin consent URL:

https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={app-client-id}

Alternatively, request only delegated permissions that do not need admin consent, or enable the admin consent workflow so users can request approval.

Seamless SSO Failures on Domain-Joined Devices

Seamless SSO lets domain-joined devices authenticate silently with Kerberos. When it fails, users on the corporate network are prompted for credentials and the sign-in log shows AADSTS81010 or the “Seamless single sign on failed for the user” message covered above. Beyond the checklist in that section, two problems are specific to the AZUREADSSOACC computer account:

The Kerberos decryption key has not been rolled over. Microsoft recommends rolling it at least every 30 days with Update-AzureADSSOForest, and running that command only once per forest per rollover.
The account is not replicated. Seamless SSO depends on AZUREADSSOACC being consistent across all domain controllers. If Active Directory replication is broken, some DCs may hold an outdated key and SSO fails intermittently.

The Seamless SSO cmdlets live in the AzureADSSO.psd1 module on the Entra Connect server, not in the retired AzureAD PowerShell module. Run these on the Connect server:

# Load the Seamless SSO module
cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
Import-Module .\AzureADSSO.psd1

# Authenticate with a Hybrid Identity Administrator account
New-AzureADSSOAuthenticationContext

# List the forests where Seamless SSO is enabled
Get-AzureADSSOStatus | ConvertFrom-Json

# Roll over the Kerberos decryption key (domain admin creds, DOMAIN\user format)
$creds = Get-Credential
Update-AzureADSSOForest -OnPremCredentials $creds

If you are not a domain admin but were delegated permissions, Microsoft says to add -PreserveCustomPermissionsOnDesktopSsoAccount to the last command.

Conditional Access Troubleshooting Deep Dive

Conditional Access is one of the most powerful security features in Microsoft Entra ID, and one of the most common causes of SSO failures when misconfigured.

Using the What If Tool

The What If tool (Entra ID > Conditional Access > Policies > What If) simulates a sign-in. Enter the user, application, device platform, location, and client app, and it returns which policies would apply, which would grant access, and which would block or require additional controls. It removes the guesswork about why one user cannot reach one app.

Common Conditional Access Misconfigurations

Misconfiguration	Symptom	Fix
Policy targets “All resources” with a block or strict control	Admins locked out of the admin portals	Exclude break-glass accounts and test admin policies in report-only mode first
Device compliance required but Intune enrollment not completed	Users on personal devices blocked	Create a separate policy for unmanaged devices that requires MFA instead of compliance
Named location IP ranges outdated	Remote workers blocked despite VPN	Update named locations with current VPN egress and office IP ranges
Sign-in frequency set too aggressively	Users prompted every hour (AADSTS70044 in logs)	Use longer intervals for low-risk apps; keep short intervals for high-risk apps
Directory sync account included in MFA policies	Entra Connect configuration or sync fails with MFA errors	Exclude the sync service account from MFA policies
Break-glass accounts not excluded	Emergency access accounts blocked during an outage	Exclude break-glass accounts from all policies and alert on every sign-in to them

Testing Conditional Access Changes Safely

Never deploy a new Conditional Access policy straight to enforcement:

Create the policy in Report-only mode and leave it for at least one week.
Review sign-in logs filtered by the policy to see which users and apps would be affected.
Confirm no critical users, service accounts, or service principals would be blocked unexpectedly.
Switch the policy to On and watch the sign-in logs closely for the first 24 to 48 hours.
Keep a monitored break-glass account excluded from all policies.

If you manage Azure Key Vault alongside identity, note that access denied errors in Key Vault can trace back to Conditional Access policies that affect service principal authentication.

SSO Integration Testing Checklist

Use this checklist when deploying SSO for a new application or changing an existing configuration.

Pre-Deployment Validation

App registration created with correct redirect URIs (no trailing slash mismatches, correct platform type such as Web or SPA)
SSO mode configured correctly (SAML, OIDC/OAuth 2.0, or linked)
SAML signing certificate valid and not expiring within 60 days
Required claims and attributes mapped in the token configuration
User or group assignment completed in the enterprise app
Conditional Access policies reviewed for impact on the new application

Post-Deployment Testing

Test sign-in with a standard user account (not an admin)
Test from a managed/compliant device and an unmanaged device
Test from inside the corporate network and from an external network
Verify MFA is triggered only when policy expects it
Confirm the application receives all required claims by inspecting the token
Test single logout (SLO) if configured

Ongoing Monitoring

Configure sign-in log alerts for the new application
Set up certificate expiration alerts (SAML apps)
Schedule quarterly access reviews for the application’s user assignments
Monitor Azure Monitor metrics for the application’s infrastructure dependencies

Best Practices to Prevent Future Issues

Renew SAML certificates proactively and track their expiration dates.
Document app configurations, including reply URLs, identifiers, claims, and roles.
Monitor sign-in logs continuously with Azure Monitor or Microsoft Sentinel.
Use groups for access control, not individual user assignments.
Roll the Seamless SSO Kerberos key at least every 30 days, or move devices to Microsoft Entra join or hybrid join so PRT-based SSO does the work.
Keep directory sync healthy, because many “SSO” failures for hybrid users are really sync problems.
Automate testing with Microsoft Graph or Playwright if you manage many apps.

How Exodata Helps

Exodata designs, secures, and supports Microsoft identity environments for SMBs and mid-market teams. Whether you are integrating SSO for dozens of SaaS apps, chasing a recurring AADSTS error, or fixing hybrid join across your fleet through our managed IT services, our engineers can find the root cause and keep it fixed. Contact us to talk through your Azure identity setup.

Frequently Asked Questions

Why is Azure SSO not working?

The most common causes are a reply URL mismatch, an expired SAML signing certificate, a user who is not assigned to the enterprise app, a Conditional Access policy blocking or adding requirements, and device problems in hybrid environments such as a missing Primary Refresh Token or a failing Seamless SSO Kerberos ticket. Start with the sign-in logs in the Microsoft Entra admin center and read the AADSTS error code on the failed attempt.

What is an AADSTS error?

AADSTS stands for Azure Active Directory Security Token Service. An AADSTS code is the error number the Microsoft Entra ID token service returns when authentication or authorization fails. Each number maps to a specific cause, such as AADSTS50105 for a user not assigned to the app or AADSTS50011 for a reply URL mismatch. You can look up any code on the Microsoft Entra error lookup page at login.microsoftonline.com/error.

How do I fix AADSTS10040141?

AADSTS10040141 means “The request is invalid”, so Entra ID rejected the format of the sign-in request rather than the user. Have the user start from the application or the My Apps portal instead of an old bookmarked sign-in URL, clear browser cookies or test in a private window, and for custom apps compare the authorization request with the app registration’s client ID, tenant, redirect URI, and scopes.

What does “Seamless single sign on failed for the user” mean?

It means the Kerberos part of Microsoft Entra Seamless SSO failed, so the user was prompted instead of signed in silently. The usual causes are that autologon.microsoftazuread-sso.com is not in the browser’s Local intranet zone, the device cannot reach a domain controller, the user is signed in with a non-domain account, or the AZUREADSSOACC computer account key is out of date.

What does AADSTS50107 mean?

AADSTS50107 means the requested federation realm object does not exist. The sign-in request referenced a federated domain or realm that Microsoft Entra ID cannot match, often because a domain was converted from federated to managed, a federation was removed, or an app sends a domain hint for the wrong domain. It is not an MFA error.

How do I troubleshoot Azure single sign-on?

Review the sign-in logs for the affected user and application and note the AADSTS code and failure reason. Validate the enterprise app configuration, including SSO mode, reply URLs, identifiers, certificates, and user assignment. Test the flow from the My Apps portal, run the Conditional Access What If tool, and for hybrid users check dsregcmd /status and Seamless SSO. For SAML apps, capture the SAML response to verify timestamps and claims.

What is Azure AD SSO?

Azure AD single sign-on, now Microsoft Entra ID SSO, lets users sign in once and reach multiple cloud, SaaS, and on-premises applications without entering credentials again. It supports SAML, OAuth 2.0, and OpenID Connect, and extends to on-premises apps through Microsoft Entra application proxy and hybrid identity features like Seamless SSO.

How do I test Conditional Access policies without breaking access?

Create or change the policy in Report-only mode. The policy is evaluated on every sign-in but not enforced, so the sign-in logs show who would be affected without blocking anyone. Leave it in Report-only mode for at least a week, then enforce it, and always keep monitored break-glass accounts excluded from all policies.

What causes SSO redirect loops in Azure?

Redirect loops are almost always caused by a mismatch between the reply URL registered on the app in Microsoft Entra ID and the URL the application sends during sign-in. Small differences such as a trailing slash, HTTP versus HTTPS, or a different port are enough. Compare the redirect URI in the app registration with the application’s own settings and make them match exactly.

← Back to Blog