SQL Managed Instance: disabling an unused SQL login breaks Windows Authentication for Microsoft Entra principals instance-wide

Question

Environment

• Azure SQL Managed Instance using Windows Authentication for Microsoft Entra principals (incoming trust-based flow). Working reliably since late September 2026.
• Applications connect with Integrated Security=SSPI as hybrid service accounts synced from on-premises AD to Entra ID, running as IIS application pool identities.
• Client VMs are hybrid Microsoft Entra joined (DomainJoined: YES, AzureAdJoined: YES).
• Client libraries: .NET SqlClient, EF Core 10.0.x, and EntityFramework 6.

Problem

New Entra Kerberos sign-ins intermittently fail on the instance, for every Entra login and from all client VMs, with:

Error 18456: Login failed for user ‘[service account]’. Reason: There was an internal error while attempting Windows Authentication for Azure AD Principals.

Existing pooled connections keep working; only new connections fail.

We can reproduce this on demand. Disabling a specific legacy SQL authentication login (ALTER LOGIN [LegacyLogin] DISABLE), or changing its password, immediately causes instance-wide Entra authentication failures. Re-enabling it, or restoring the old password, clears them within minutes. Doing the same to a different SQL login has no effect.

We also see the same error with no change to that login. These are daily isolated failures, often clustered just after the top of the hour (:00–:03), plus one burst of 149 failures over about three minutes across three service accounts and four client VMs.

What we’ve ruled out

• No client uses the login. An Extended Events session capturing successful logins for it, validated by a test connection from SSMS, recorded zero application logins before and during a controlled disable test. No failed sign-ins as that login appear in the error log during any incident.
• No connection strings reference it. No application connection strings reference it or use SQL authentication.
• No server-level role or ownership. It is not the instance admin login, holds no server roles, and owns no databases, schemas, endpoints, SQL Agent jobs, or credentials.
• Nothing executes as it. No code executes as it, no linked server uses it, and there is no logon trigger.
• Database users aren’t the cause. Removing its database users caused no problem. Only disabling the login or changing its password reproduces the failure.

Questions

1. What in Windows Authentication for Microsoft Entra principals on SQL MI could depend on a specific SQL authentication login, and how can it be safely disabled or removed?
2. What else can cause the “internal error while attempting Windows Authentication for Azure AD Principals” failure?
3. Could isolated failures that happen while the login is enabled and unchanged point to a configuration issue with Entra Kerberos or the incoming trust?
4. Does anything in the Entra Kerberos authentication flow run on an hourly cadence that could explain failures clustered just after the top of the hour?
5. What client-side resilience is recommended while this is investigated?

Answer 1

Have you checked the SQL Server errorlog more messages related to this login failure? Maybe there is a clue.

I can think of a possible reason, but it is very far-fetched. That is, you could have a logon trigger that makes a call on loopback linked server setup with login-mapping using this login. But that would be really crazy. A start, though, is to check if you have any logon trigger at all.