[BUG] M365 connector auth fails for secondary UPN domain on single multi-domain Entra tenant

[G-wine-IE]

What happened?

Environment

• Claude plan: Team/Enterprise
• Interface: claude.ai (tested on iOS, Windows Edge, Windows Chrome)
• Connector: Microsoft 365 (pre-built)

Description

Users whose UPN is on a secondary domain of a single Entra tenant cannot
authenticate to the M365 connector. Users on the primary domain authenticate
successfully. Both domains are in the same single Entra tenant — this is NOT
a multi-tenant scenario.

Note: Global Admins in our environment use a different UPN domain to end users.
The issue persists even after deleting the connector, removing the Enterprise
Apps in Azure, and re-completing admin consent using a Global Admin account on
the secondary domain — suggesting the failure is on Anthropic's backend.

What Has Been Ruled Out

• Azure sign-in logs show success for both domains
• Assignment required = No on both M365 MCP Client and M365 MCP Server apps
• Secondary domain users are confirmed Claude org members
• Admin consent re-run manually via Anthropic's documented URLs as secondary
  domain Global Admin — no change
• Tested across iOS, Windows Edge, Windows Chrome — not a client/cache issue
• No conditional access policies or group restrictions in place

Hypothesis

Anthropic's backend OBO token exchange or org-matching logic may be keying
off the UPN domain suffix rather than the Entra tenant ID (GUID). The tenant
ID is identical for all users regardless of UPN domain.

What did you expect to happen?

Expected Behaviour

All users in the same Entra tenant should authenticate regardless of which
verified domain their UPN uses. At minimum, there should be a way to clear
the cached UPN association on Anthropic's backend.

Actual Behaviour

Secondary domain users cannot connect. Azure sign-in logs show SUCCESS —
the failure is post-authentication on Anthropic's side.

Steps to reproduce

Steps to Reproduce

1. Single Entra tenant with two verified domains (primary.ie and secondary.ie)
2. M365 connector enabled in Claude org settings
3. Admin consent completed by Global Admin (both automatic flow and manual URL
   method attempted)
4. User with primary.ie UPN connects successfully
5. User with secondary.ie UPN fails
6. Deleted connector and Enterprise Apps in Azure, re-ran admin consent
   authenticated as secondary.ie Global Admin — still fails

Area

OAuth / Authentication

MCP Server (if applicable)

M365

Error messages or logs

On trying to connect user using secondary.ie UPN sees this error:
Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: "ofid_70b21b9e04a44df5"

Additional context

Additional Context

Support ticket open with no response. This will affect any organisation
using multiple verified domains on a single Entra tenant.

[G-wine-IE]

Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: "ofid_70b21b9e04a44df5"

Support Ticket with more details logged (Conversation ID for your records: 215473601277500)

[crondinini-ant]

Thanks for the detailed write-up and for including the reference ID — that let me pull the exact flow from our logs.

I looked up ofid_70b21b9e04a44df5 and the failure is happening at the token exchange step. Your user signs in to Microsoft successfully, Microsoft redirects back to us with an authorization code, and then when our backend tries to swap that code for an access token at login.microsoftonline.com/common/oauth2/v2.0/token, Microsoft rejects the request with HTTP 400 and error code AADSTS53003: "Access has been blocked by Conditional Access policies. The access policy does not allow token issuance."

So the block is coming from Entra, not from us. Our backend never gets a token to work with, which also means there's nothing on our side keyed off the UPN domain or tenant ID — we never reach the point where we'd look at either.

I know you ruled out Conditional Access already, and I think what's tripping things up is that Azure sign-in logs can show Success for the interactive sign-in while a CA policy still blocks the token issuance that happens a moment later. Those are separate stages, and the Sign-in logs "Basic info" tab only reports the first one. If you open the sign-in entry for that user and click the Conditional Access tab, you should see which policy applied and what it did to the token request. Microsoft's correlation ID for this specific attempt is a2b9178d-8a19-47cf-be88-98a946a5be44 (trace 572b44db-65c5-48cd-b4d5-0236155c2400, timestamp 2026-03-24 18:39:19Z) if you want to jump straight to it.

As for why primary-domain users sail through while secondary-domain users don't: CA policies are often scoped by group membership, directory role, or user/sign-in risk rather than by domain suffix directly, so two users in the same tenant can hit different policies without anything in the config explicitly mentioning the domain. A few things worth checking: whether secondary-domain users land in a different security group that a policy targets, whether Microsoft-managed policies or Security Defaults are enabled (these don't always show up in the main CA policy list), and whether there's a policy scoped to the "M365 MCP Client" or "M365 MCP Server" enterprise apps specifically.

Once the policy is adjusted to allow token issuance for those users, the connector should start working — there's no cached state on our side to clear, since we never received a token to cache in the first place.

We should be surfacing the AADSTS53003 code in the error message you see rather than the generic "check your credentials" text, so I'll file that as a follow-up on our end.

[G-wine-IE]

Thanks Camila, really appreciate the detailed response and the correlation ID — that's exactly what we needed.
We'll dig deeper into the Conditional Access rules on the sign-in logs now using the correlation ID provided.

Cheers
G

[crondinini-ant]

Sounds good @G-wine-IE
I'll close the issue now for easier tracking of open issues without a reply, feel free to reopen if the issue persists.