AADSTS20012 An Error Occurre | Meaning And Fix Steps

If you work with Microsoft Entra ID (Azure AD) and see the message “AADSTS20012: An error occurred when we tried to process a WS-Federation message,” it can block sign-ins or logouts right when you need them most. The full text often mentions that the message is invalid, malformatted, or carries potentially dangerous characters, which points straight at a problem with the federation message itself rather than a simple password issue.

This guide walks through what aadsts20012 an error occurre really means, where it usually shows up, and how to fix it in a practical way. You will see patterns from real-world cases, learn where to look in Azure and in your identity provider, and get a set of checks you can run in a few minutes before you open a ticket with your vendor or Microsoft 365 admin.

What AADSTS20012 An Error Occurre Actually Means

Within Microsoft Entra ID, the code AADSTS20012 maps to the label WsFedMessageInvalid. The platform throws this error when it receives a WS-Federation or SAML message that it cannot parse safely. In the official wording, the message is “invalid, malformatted, or contains potentially dangerous characters,” which lines up with a broken or altered sign-in or sign-out payload rather than a service outage or user lockout.

In practice, this shows up in browser-based sign-ins, mobile app prompts, and single logout flows. A common pattern is the Microsoft sign-in page saying “Sorry, but we’re having trouble signing you in” followed by AADSTS20012 and the note about a WS-Federation message. In some cases the login still works after a refresh, while in others every attempt fails until the federation setup is corrected.

The core idea is simple: Azure AD expects a WS-Fed or SAML message with certain fields, signatures, and encodings. When the identity provider or application sends something that does not match those expectations, aadsts20012 an error occurre and the platform refuses to continue the flow. That protects your tenant from tampered messages but also means a small misconfiguration can block real users.

• View the full error text — On the Microsoft sign-in page, expand any “More details” link so you can see the code, timestamp, request ID, and correlation ID.
• Note the scenario — Check whether the error appears during sign-in, during logout, or only with a specific relying party such as Salesforce, Office 365 email, or a custom app.
• Capture the URL — Copy the browser address bar when the error appears, since it often contains WS-Fed or SAML parameters that help an admin track the broken step.
• Check the Microsoft error portal — Visit https://login.microsoftonline.com/error with the code 20012 to see current documentation and suggested actions for this error family.

Common Causes Behind AADSTS20012 An Error Occurre

Although every tenant has its own setup, the same types of mistakes show up again and again when this code appears. Most of them sit in either your SAML or WS-Fed configuration, rather than in user accounts.

• Generic logout URLs — Many articles still show the old WS-Fed sign-out endpoint https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 as a logout URL. When an app sends logout traffic here as a single logout endpoint, Azure AD can treat the incoming message as invalid and raise AADSTS20012 during sign-out.
• Wrong single logout URL in the service provider — Products such as Informatica, Salesforce, and Netscaler often include a field for a single logout service URL. If that field points to a generic URL instead of a tenant-specific SAML logout endpoint (for example https://login.microsoftonline.com//saml2), the logout message that reaches Azure AD may not match expectations.
• RelayState or query string changed in transit — In some setups an appliance or reverse proxy HTML-encodes characters such as the ampersand in the RelayState value. That small change means Azure AD receives a message that no longer matches the original request and responds with AADSTS20012.
• Misconfigured federated identity provider — When a domain is federated to a third-party identity provider, any mistake in that system’s WS-Fed or SAML response, such as missing claims or an unexpected issuer, can cause this error. Microsoft forum replies often point affected tenants to their external identity provider or vendor to clean up the configuration.
• Corrupt or stale session cookies — In a smaller set of cases, old cookies or mixed sessions across tenants can confuse the WS-Fed flow. Clearing browser data or testing in a private window sometimes clears an isolated AADSTS20012 without any admin work.

Overall, this code rarely points to a temporary outage. It almost always reflects a configuration problem with WS-Federation or SAML on either the Azure side or a linked provider, which is good news because a focused clean-up usually restores sign-in and logout flows.

AADSTS20012 Error In Azure Ad Ws-Federation Sign-Ins

When users hit AADSTS20012 during sign-in, the WS-Fed or SAML response that returns from the identity provider to Azure AD is the main suspect. In a federated Microsoft 365 setup with a registrar such as GoDaddy, the identity provider often sits outside your direct Azure portal, so the fix may require coordination across teams, but you can still narrow down the root cause quickly.

• Confirm whether the domain is federated — Ask an admin to check the domain status with PowerShell or the Entra admin center. If the domain is set to “Federated,” Azure AD expects WS-Fed or SAML traffic from an external identity provider.
• Check sign-in logs for the user — In the Entra admin center, open Sign-in logs, filter by the affected user and time window, and look for entries that match the AADSTS20012 timestamp and correlation ID from the error page.
• Compare a successful sign-in — If any user in the same tenant can still sign in, compare their sign-in log entry with the failed one. Fields such as application ID, URL, and identity provider can show where the broken flow branches.
• Review the relying party configuration — On the identity provider side, check the WS-Fed or SAML settings: entity ID, reply URL, certificate, and claim rules. Any mismatch with the Azure enterprise app or Microsoft 365 configuration can lead to an invalid message.

Once you know which identity provider sits in front of Azure AD for the affected app, you can share AADSTS20012 details with that team. Many public threads have confirmed that this error disappears once the identity provider vendor corrects its WS-Fed configuration or issues a tenant-specific logout and reply URL.

Step-By-Step Fixes For AADSTS20012 In Common Scenarios

The exact fix depends on where the error appears. This section walks through the most common scenarios that admins report when aadsts20012 an error occurre: during Microsoft 365 sign-in with a hosted domain, during SAML single logout from a cloud app, or during B2B access where Azure AD acts as the service provider for another identity system.

Fixing AADSTS20012 During Microsoft 365 Sign-In

• Verify the user account — Confirm that the affected user can sign in directly at https://portal.office.com with a different device or network, or that another account in the same tenant hits the same error. This separates individual account issues from tenant-wide federation problems.
• Check DNS and domain federation — Ensure that the domain’s DNS records match Microsoft 365 guidance and that the domain is set either as “Managed” or “Federated” in a way that matches your actual design.
• Review identity provider metadata — Export the SAML or WS-Fed configuration from the identity provider and confirm issuer, audience, and reply URLs match the enterprise app or Microsoft 365 settings in the Entra portal.
• Rotate or confirm certificates — If the identity provider recently renewed its signing certificate, make sure Azure AD has the correct public key and that no old certificate still appears as active in the configuration.
• Test with a clean browser — Ask the user to try a private browser window or another browser. If the sign-in works there, clear cookies or cached data for the Microsoft login domain on the original browser.

Fixing AADSTS20012 During SAML Or WS-Fed Logout

Many admins see AADSTS20012 only after users click a logout button from a third-party app such as a cloud integration platform, Salesforce sandbox, or a reverse proxy portal. In those cases, the logout request heading toward Azure AD is often the broken piece.

• Inspect the logout URL in the app — Open the SAML or WS-Fed settings in the app and note the logout URL. If it uses the generic WS-Fed sign-out endpoint from older samples, plan to change it.
• Switch to a tenant-specific SAML logout URL — For many service providers, a better choice is a tenant-specific URL such as https://login.microsoftonline.com//saml2. This matches documented patterns for SAML single logout and avoids the generic WS-Fed endpoint that often leads to AADSTS20012.
• Test leaving the logout URL empty — Some vendors document a workaround where clearing the single logout service URL stops the error. In that case, the app signs the user out locally while Azure AD session timeout cleans up the cloud session later.
• Capture SAML traces for logout — Use a browser extension or proxy to capture the SAML logout request and response. Check that the RelayState is not altered, that signatures look correct, and that the message format matches the Azure expectation.

Quick Scenario Table For AADSTS20012

How To Read Logs And Error Details For AADSTS20012

Good troubleshooting for this code depends on solid data. The error page already gives a timestamp, request ID, and correlation ID. With those three pieces and the user’s UPN, you can track the full event inside the Entra sign-in logs and any upstream audit trail on your identity provider.

• Copy identifiers from the error page — Ask the user to send the full message, including the “Request Id,” “Correlation Id,” and exact time. Screenshots help, but text is even better for search.
• Open sign-in logs in Entra — In the Entra admin center, open the sign-in logs blade, filter by username and a narrow time range that covers the error time, and then look for entries that show AADSTS20012 in the status details.
• Drill into the sign-in record — Once you locate the event, open it and review the application, IP, client app type, protocol, and any linked conditional access details. This shows exactly which app and protocol triggered the invalid WS-Fed message.
• Match with identity provider logs — Share the same timestamp and correlation ID with the team that manages your external identity provider. Their logs often show the raw SAML or WS-Fed message that left their system and reveal a missing claim, bad redirect URL, or encoding change.
• Use the Microsoft error lookup page — Keep a tab open to the error lookup portal with your code and compare its current description with what you see in logs. That page may also link to fresh guidance for that code.

With this combined view, you can see whether AADSTS20012 arises from a single app, a single identity provider, or a wider pattern across the tenant. That shapes the fix plan and makes any vendor ticket far easier to handle.

When To Escalate AADSTS20012 To Your Identity Provider

Some AADSTS20012 cases clear with small tenant-side changes, such as adjusting logout URLs or cleaning up stale cookies. Others sit entirely in an external identity provider or registrar, and no change in the Entra portal will solve them. A few clear signs tell you when to pull in extra help.

• The error started right after a vendor change — If GoDaddy, Salesforce, a reverse proxy, or any other linked system recently changed certificates or SAML endpoints and AADSTS20012 appeared on the same day, that system likely holds the fix.
• Only federated domains fail — When managed domains sign in without trouble but federated domains trigger AADSTS20012, the issue almost always lives in the federated identity provider configuration.
• Logs show valid traffic up to Azure AD — If sign-in logs in Entra show clean inbound traffic, but the error page still flags an invalid WS-Fed message, a deeper protocol review may require vendor engineers or Microsoft 365 tenant admins with extended tools.
• Multiple apps break at once — When more than one SAML or WS-Fed app starts failing with the same code, a shared identity provider, proxy, or logout endpoint is usually at fault, and a central fix works better than one-off tweaks.

When you do escalate, send a packet of clear facts: the full AADSTS20012 text, timestamps, request and correlation IDs, SAML or WS-Fed traces if you have them, and a short note on when the issue began. That saves time on basic triage and moves the case straight toward configuration review and protocol detail. With the right information in front of the right admin or vendor team, this error code usually turns into a manageable clean-up rather than an ongoing mystery.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback