Azure Single Sign On (SSO) can streamline access across cloud and SaaS apps—but when it breaks, it breaks at scale. Whether users are getting unexpected sign in prompts, looping redirects, or mysterious “AADSTS” error codes, Azure SSO issues can disrupt productivity and erode trust quickly. For organizations relying on cloud engineering to power their infrastructure, a broken identity layer is one of the most impactful failures to address.

In this post, we’ll walk through common root causes, actionable steps for troubleshooting, and best practices to ensure your identity layer stays resilient.

First, Understand the Flow

Before jumping into logs, it helps to understand the basic Azure AD SSO handshake:

User accesses an application (like Salesforce, Teams, or a custom app).
The app redirects the user to Azure AD to authenticate.
Azure AD validates the user via their credentials or existing session (e.g., Windows Integrated Auth or PRT).
If successful, Azure AD issues a token and redirects the user back to the application.

If any one of these steps fails—due to misconfigurations, expired tokens, or conditional access policies—SSO breaks.

Common Symptoms and Root Causes

Understanding what users experience helps you narrow down the issue before diving into logs. Here are the most frequent SSO failure patterns and what typically causes them.

Repeated sign-in prompts. Users are asked to authenticate over and over, even though they have already signed in. This usually points to a token caching issue, a misconfigured reply URL, or a Conditional Access policy that blocks the session from being established. It can also occur when the application expects a different authentication protocol than what Azure AD is configured to provide.

Redirect loops. The browser cycles between the application and Azure AD without ever completing authentication. This is almost always caused by a mismatch between the reply URL configured in Azure AD and the URL the application actually sends during the authentication handshake. Even a trailing slash difference can trigger a loop.

“AADSTS” error codes. Users see a generic error page with a code like AADSTS50105 or AADSTS700016. These codes are Azure AD’s way of telling you exactly what went wrong, but they require lookup and context to act on. We cover the most common codes below.

Access denied after successful authentication. The user authenticates without error, but the application shows a permissions or access denied page. This typically means the user is not assigned to the enterprise application in Azure AD, or the application requires a specific claim or role that is not present in the token.

SSO works for some users but not others. When SSO is inconsistent across the user population, the root cause is usually tied to group membership, Conditional Access policy scope, device compliance state, or licensing. Users who are not in the correct Azure AD group may be excluded from access, while users on non-compliant devices may be blocked by policy.

AADSTS Error Code Reference

The table below covers the most frequently encountered AADSTS error codes and their recommended fixes.

Error Code	Meaning	Recommended Fix
AADSTS50105	User not assigned to the application	Assign the user or their group to the Enterprise App in Azure AD
AADSTS50107	MFA required but not completed	Verify MFA registration for the user; check Conditional Access MFA requirements
AADSTS50020	User account is from a different tenant	Confirm the user’s tenant is allowed; check multi-tenant app configuration
AADSTS700016	Application or client ID not found in the tenant	Verify the App Registration exists and the client ID matches
AADSTS65001	User or admin has not consented to the application	Grant admin consent in the Enterprise App permissions blade
AADSTS50076	MFA is required by Conditional Access	Ensure the user has registered for MFA; review Conditional Access policy scope
AADSTS50011	Reply URL mismatch	Update the reply URL in the App Registration to match the application’s redirect URI exactly
AADSTS90072	External tenant sign-in not allowed	Add the external tenant as an allowed identity provider or adjust cross-tenant access settings

For a comprehensive list, Microsoft maintains a full AADSTS error code reference.

How to Troubleshoot Azure SSO Step-by-Step

Start in the Azure AD Sign-in logs:

Filter by user, app, and timestamp
Look for AADSTS error codes like:

`AADSTS50107` – Missing MFA

AADSTS50020 – User not in tenant
AADSTS700016 – App/client not found
AADSTS50105 – User blocked by Conditional Access

2. Review Enterprise App Settings

Navigate to Azure Active Directory → Enterprise Applications:

Make sure SSO mode matches what the app expects (e.g., SAML vs OAuth2). Microsoft’s guide on debugging SAML-based SSO is a valuable reference here.
Validate:

Reply URLs (redirect URIs)

Identifiers (Entity ID, App ID URI)
Certificates (expiration and thumbprint match)

Apps like Workday or ServiceNow often require certificate updates every year. Microsoft’s guide on troubleshooting SAML-based SSO covers additional certificate and configuration issues.

3. Use the MyApps Test Tool

Have the user go to myapps.microsoft.com, click the app, and review the real-time authentication flow. This helps isolate whether the issue is user-specific, app-specific, or tenant-wide.

4. Validate Conditional Access

Conditional Access is a critical component of any security and compliance strategy. Check for policies in Azure AD → Security → Conditional Access that may:

Block sign-in by location
Require compliant or hybrid-joined devices
Trigger unexpected MFA prompts

Tip: Use Report-only mode to test new policies before enforcing them. For more detail, see Microsoft’s documentation on troubleshooting Conditional Access sign-in problems.

5. Inspect Domain and User Settings

Verify the user’s UPN matches the expected domain suffix (e.g., user@company.com)
Check that the domain is verified and federated if needed
For Hybrid setups, confirm Seamless SSO is enabled and GPOs are configured properly

Hybrid Azure AD Join & PRT Issues

In hybrid environments, SSO often relies on Primary Refresh Tokens (PRTs) issued when a device is Azure AD joined or hybrid joined. If devices are not joined correctly, or if the user signs into a local account instead of a domain account, SSO will not work. Proper device management is a key part of delivering modern workplace solutions that work reliably for end users.

Check device status via:

dsregcmd /status on Windows
Azure AD portal > Devices

A healthy device should show:

AzureADJoined = YES
PRT = YES

If the PRT field shows “NO,” the device has not successfully obtained a token from Azure AD. Common causes include stale device registrations in Azure AD, clock skew between the device and Azure AD (tokens are time-sensitive), and network configurations that block the required Azure AD endpoints. In environments with web proxies, ensure that traffic to login.microsoftonline.com, device.login.microsoftonline.com, and enterpriseregistration.windows.net is allowed without SSL inspection.

For organizations managing hundreds or thousands of devices, we recommend using Microsoft Intune or a similar endpoint management platform to enforce hybrid join configurations at scale. This avoids relying on individual users or local IT staff to troubleshoot device join issues one at a time.

Token Lifetime and Session Persistence

Even when SSO is configured correctly, users may experience unexpected sign-in prompts due to token lifetime policies. Azure AD issues several types of tokens, including access tokens (typically valid for 60-90 minutes), refresh tokens (valid for up to 90 days by default), and PRTs. If a Conditional Access policy enforces sign-in frequency, users will be prompted to re-authenticate at the specified interval regardless of their token state.

Review your tenant’s token lifetime policies and Conditional Access sign-in frequency settings to ensure they align with your organization’s security requirements without creating unnecessary friction. A policy that forces re-authentication every hour may be appropriate for a financial trading application but would be disruptive for a general-purpose collaboration tool like Teams.

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

Advanced SSO Error Scenarios

Beyond the common AADSTS errors covered above, several more nuanced scenarios can break SSO in ways that are harder to diagnose.

SAML Assertion Clock Skew

SAML assertions include timestamps that define when the assertion is valid. If there is clock skew between Azure AD and the service provider (the application), the assertion may be rejected as expired or not-yet-valid, even though the authentication itself succeeded. This commonly occurs with on-premises applications or third-party SaaS apps that run their own time servers.

To diagnose, capture the SAML response using a browser extension like SAML-tracer and compare the NotBefore and NotOnOrAfter timestamps against the service provider’s system clock. Most SAML implementations allow a clock skew tolerance of 3-5 minutes, but some are stricter. If clock skew is the issue, synchronize the service provider’s time source with a reliable NTP server and consider increasing the skew tolerance in the app’s SAML configuration.

Token Claim Mismatches

Some applications require specific claims in the SAML token or OAuth2 JWT to authorize users correctly. For example, an application might expect a department claim or a custom role claim that Azure AD does not include by default. When these claims are missing, the user authenticates successfully but receives an authorization error from the application.

Review the application’s documentation to identify required claims, then configure them in the Enterprise App’s Single sign-on > Attributes & Claims blade. For custom claims, you may need to define claim mapping policies or use the Microsoft Graph API to configure optional claims on the App Registration. This is a common issue when migrating applications from ADFS to Azure AD, since ADFS claim rules are not automatically translated.

For applications registered as multi-tenant, users from external tenants must consent to the application’s permissions before they can sign in. If your organization requires admin consent for all applications (a common security and compliance configuration), external users will see AADSTS65001 until an administrator in their tenant grants consent.

To resolve this, provide the external organization’s administrator with a direct admin consent URL:

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

Alternatively, configure the application to request only delegated permissions that do not require admin consent, or use the Azure AD admin consent workflow to allow users to request approval from their administrators.

Seamless SSO Failures on Domain-Joined Devices

Azure AD Seamless SSO allows domain-joined devices to authenticate silently using Kerberos tickets. When this fails, users are prompted to enter credentials even though they are on the corporate network. Common causes include:

The AZUREADSSOACC computer account’s Kerberos decryption key has not been rolled over (Microsoft recommends rolling it every 30 days)
Group Policy settings that add Azure AD URLs to the browser’s Intranet zone are not applied or have been overridden
The device cannot reach the autologon.microsoftazuread-sso.com endpoint

# Check Seamless SSO status in your tenant
Connect-AzureAD
Get-AzureADSSOStatus -Enable $true

# Roll over the Kerberos decryption key
Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

For organizations troubleshooting broader Active Directory replication issues, note that Seamless SSO depends on the AZUREADSSOACC computer account being properly replicated across all domain controllers. If AD replication is broken, some domain controllers may have an outdated Kerberos key, causing intermittent SSO failures.

Conditional Access Troubleshooting Deep Dive

Conditional Access policies are one of the most powerful security features in Azure AD, but they are also one of the most common causes of SSO failures when misconfigured.

Using the What If Tool

The What If tool in the Azure portal (Azure AD > Security > Conditional Access > What If) allows you to simulate a sign-in and see which policies would apply. Enter the user, application, device platform, and location, and the tool returns which policies would be evaluated, which would grant access, and which would block or require additional controls.

This tool is invaluable for diagnosing why a specific user cannot access a specific application. It eliminates guesswork by showing the exact policy evaluation chain.

Common Conditional Access Misconfigurations

Misconfiguration	Symptom	Fix
Policy applies to “All cloud apps” including the Azure portal	Admins locked out of Azure portal	Exclude the “Microsoft Azure Management” app or create a separate policy for admin access
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 to include current VPN egress IPs and office IP ranges
Sign-in frequency set too aggressively	Users prompted for credentials every hour	Adjust frequency to 24 hours for low-risk apps; keep short intervals for high-risk apps
Policy excludes break-glass accounts incorrectly	Emergency access accounts subject to MFA	Ensure break-glass accounts are excluded from all Conditional Access policies and have MFA pre-registered

Testing Conditional Access Changes Safely

Never deploy a new Conditional Access policy directly in enforcement mode. Use the following workflow:

Create the policy in Report-only mode and leave it for at least one week
Review the sign-in logs filtered by the policy to identify which users and apps would be affected
Verify that no critical users or service principals would be unexpectedly blocked
Switch the policy to On and monitor the sign-in logs closely for the first 24-48 hours
Keep a break-glass account excluded from all policies to ensure emergency access is always available

For organizations managing Azure Key Vault alongside identity infrastructure, be aware that access denied errors in Key Vault can sometimes trace back to Conditional Access policies that block service principal authentication.

SSO Integration Testing Checklist

When deploying SSO for a new application or modifying an existing configuration, use this checklist to validate the integration before rolling it out to all users.

Pre-Deployment Validation

App Registration created with correct redirect URIs (no trailing slash mismatches)
SSO mode configured correctly (SAML, OAuth2/OIDC, or linked)
SAML signing certificate is valid and not expiring within 60 days
Required claims and attributes are 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 sign-in from a managed/compliant device and an unmanaged device
Test sign-in from inside the corporate network and from an external network
Verify MFA is triggered only when expected by policy
Confirm the application receives all required claims by inspecting the token
Test single logout (SLO) if configured to ensure session cleanup works

Ongoing Monitoring

Configure Azure AD 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 certificates proactively for SAML-based SSO apps
Document app configs—including reply URLs, identifiers, and roles
Monitor logs continuously using Azure Monitor or Sentinel
Use groups for access control, not individual users
Automate testing with tools like Microsoft Graph or Playwright if you manage many apps
Partner with a provider offering managed IT services to handle ongoing monitoring and maintenance of your identity infrastructure

Frequently Asked Questions

Why is Azure SSO not working?

Azure SSO can fail for a variety of reasons, including misconfigured reply URLs, expired SAML certificates, Conditional Access policies blocking sign-in, or device join issues in hybrid environments. The best first step is to check the Azure AD Sign-in logs for specific AADSTS error codes, which will point you toward the root cause. Use the Conditional Access What If tool to simulate the sign-in and identify which policy is causing the block.

How do I troubleshoot Azure Single Sign-On?

Start by reviewing the sign-in logs in the Azure portal, filtering by the affected user and application. Look for AADSTS error codes, then validate your Enterprise App configuration (SSO mode, reply URLs, certificates). Test the authentication flow via myapps.microsoft.com and check Conditional Access policies for any rules that may be blocking access. For SAML applications, capture the SAML response with a browser extension to verify assertion timestamps and claim values.

What is Azure AD SSO?

Azure AD Single Sign-On (SSO) is a feature of Microsoft Entra ID (formerly Azure Active Directory) that allows users to sign in once and access multiple cloud and SaaS applications without re-entering their credentials. It supports protocols like SAML, OAuth 2.0, and OpenID Connect, and can be extended to on-premises apps through hybrid configurations.

How do I fix AADSTS error codes in Azure?

AADSTS error codes are returned by Azure AD when authentication fails. Each code maps to a specific issue—for example, AADSTS50107 means MFA is missing, AADSTS700016 means the app or client ID was not found, and AADSTS50105 means the user is not assigned to the application. Look up the specific code in Microsoft’s error code reference, then address the underlying configuration or policy issue.

How do I test Conditional Access policies without breaking access?

Use Report-only mode when creating or modifying Conditional Access policies. In this mode, the policy is evaluated during every sign-in but not enforced, so you can see which users would be affected in the sign-in logs without actually blocking anyone. Leave the policy in Report-only mode for at least one week before switching to enforcement, and always verify that break-glass accounts are excluded from all policies.

What causes SSO redirect loops in Azure AD?

Redirect loops are almost always caused by a mismatch between the reply URL (redirect URI) configured in the Azure AD App Registration and the URL the application sends during the authentication handshake. Even minor differences like a trailing slash, HTTP vs HTTPS, or a different port number can cause the loop. Check the reply URL configuration in both the Azure portal and the application’s settings, and ensure they match exactly.

Need Help Managing Azure Identity?

Exodata specializes in designing, securing, and supporting enterprise identity environments on Microsoft Azure. Whether you’re integrating SSO for hundreds of SaaS apps or troubleshooting hybrid join problems across your fleet, our team can help ensure your users get seamless, secure access—every time. Contact us to discuss your Azure identity needs.

Need help with Azure identity and SSO? Contact us to get expert guidance on configuring, securing, and troubleshooting your Azure AD single sign-on environment.

← Back to Blog

Fix Azure SSO Issues: AADSTS Error Guide [2026]