Picture this: you’re logging in to your favorite enterprise app that uses Azure AD SSO. Everything used to work great… and then boom — sudden login errors. A dreaded 405 Method Not Allowed error slaps you in the face like a cold pancake. What happened? And more importantly — how do you fix it?
TL;DR
After changing tenants in Azure AD, SSO stopped working and returned a 405 error on the SAML endpoint. This was caused by outdated or incorrect metadata and misconfigured RelayState values. Updating the service provider with new metadata and RelayState from the correct Azure tenant fixed it. Everyone could log in again like it was 1999.
What Even Is a 405?
A 405 Method Not Allowed error means, “Hey! That request method isn’t allowed here.” It’s like knocking on someone’s window instead of the door and wondering why they don’t let you in.
In our case, the SAML endpoint URL expected a POST, but it got a GET or something else. Azure AD got confused. It didn’t like our enthusiastic knock.
Where It All Went Wrong
Here’s the story:
- Everything was working just fine with Azure AD SSO.
- Then someone said, “Let’s change tenants!”
- You migrated users and apps to a new Azure AD tenant.
- Login stopped working. Users began submitting tickets.
After some digging, you noticed that instead of getting a happy login redirect, people were getting a 405 error from the SAML endpoint.
The Sneaky Little Culprits
The problem boiled down to two small but mighty configuration pieces:
- Metadata — This tells your app where to send login requests and what to expect back.
- RelayState — This optional value helps send users to the right place after login.
When you changed tenants, the old metadata URL and RelayState still pointed to the old Azure tenant. But your new Azure tenant had different SAML settings, keys, and identifiers. This mismatch triggered the 405 error.
Let’s Talk About Metadata
SAML metadata is like the instruction manual for SSO. It tells your app:
- Where the login buttons live (the login URL)
- Where to send logout requests
- What certificates to trust
- What identifiers to expect
If you change tenants but forget to update your app’s metadata, it will try to contact your ex-tenant. That’s like phoning your old landlord about your new mailbox keys. It just won’t work.
To fix it, you need to go to your new tenant’s Azure portal and download the current SAML metadata file. It usually looks like this URL:
https://login.microsoftonline.com/{tenant_id}/federationmetadata/2007-06/federationmetadata.xml
Replace {tenant_id} with your new Azure AD tenant ID.
Then upload this metadata to your app (e.g., a third-party SAML service provider like Salesforce, ServiceNow, or your custom app). Voila — your app now points to the right place.
RelayState Drama
The RelayState is sent along with the SAML request to help Azure know where to send users after login. Often, it’s a specific page or dashboard inside your app.
But sometimes, the RelayState contains tenant-specific values. If those values still reflect your old tenant’s URLs, Azure AD doesn’t like it. It sees the mismatch and can throw that pesky 405 error.
So, you updated your metadata. But it still fails? That’s usually a sign your RelayState also needs love.
Check your app or Identity Provider (IdP) configuration. If the RelayState is hardcoded, update it to match paths used by your new tenant. If you’re lucky and it’s generated dynamically by Azure, reconfigure your app to stop overriding it.
Getting Fancy: A Checklist that Saves Sanity
Here’s a simple list that turned grumpy users back into happy campers:
- Go to your new Azure tenant’s portal
- Navigate to Enterprise Applications > Your App
- Click SAML-based Sign-On
- Find the Federation Metadata XML link and download it
- Upload that metadata to your SAML service provider
- Double-check Reply URLs, Identifiers, and Logout URLs
- Update or remove stale RelayState values
- Test login from both incognito and existing sessions
- Watch your users celebrate like it’s Friday afternoon
Still Seeing 405? Do This:
If updating metadata and RelayState didn’t help, check these:
- Your app’s SAML configuration is using HTTP POST Binding not Redirect
- The Assertion Consumer Service (ACS) URL in Azure matches the one in your app
- Clock skew — tokens may fail if your server time is off by more than 5 minutes
A Quick Metaphor
Imagine you moved to a new house but left all your Amazon deliveries going to your old address. Someone out there is still getting your packages — and you’re stuck wondering why they never arrive. That’s exactly what’s happening when SAML metadata still points to your old Azure tenant.
Fix your address. Get your login deliveries back on track.
Wrapping Up
SSO seems magical… until it isn’t. That 405 error isn’t magical either — it’s just a confused doorman blocking your users because they brought the wrong invitation.
Fix the metadata, polish the RelayState, and make sure both your app and Azure AD speak the same SAML language.
Once everything aligns, users log in smoothly once again. No more tickets. No more cold pancakes.
Bonus Tips
- Always save your working metadata files before you make changes
- Use browser dev tools to inspect SAML requests and responses if stuff breaks
- Azure AD logs help a lot — go to Sign-In Logs under the Azure AD blade
- Document the correct metadata and RelayState after migration so future-you knows what’s what
Happy SAMLing!
And remember: even when login breaks, you’ve got the tools — and now the knowledge — to bring order back to the land of SSO.
Published on November 24, 2025 under .
