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

Question

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

Shaun Quarles 0

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

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?
What else can cause the “internal error while attempting Windows Authentication for Azure AD Principals” failure?
Could isolated failures that happen while the login is enabled and unchanged point to a configuration issue with Entra Kerberos or the incoming trust?
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?
What client-side resilience is recommended while this is investigated?

Shaun Quarles 0 Reputation points

2026-10-30T16:34:07.5366667+00:00
Thanks for the replies. Here’s what we’ve found since.

Logon triggers and linked servers. There are no logon triggers. The only linked login mapping is the default self-credential one, so nothing maps to LegacyLogin.

18456 state. All 222 Entra failures in our retained error log (2026-10-23 onward) are state 188. That isn’t one of the documented Entra states (102–111, 132–133). They cover three service accounts and four client VMs.

The burst: 171 of them came in a single burst on 2026-10-28, from 10:20:14 to 10:23:07 UTC. It hit every account and client at once, and we made no change at that time. (Our first post said 149; the full error-log count for that window is 171.)

The rest: leaving out the burst, 23 of the remaining 51 failures fell in minutes :00–:03 of the hour.

The login tests: the LegacyLogin disable tests (2026-10-13 and 10-15) are older than our retained log, so we don’t have their state. We can repeat one under an Extended Events trace if that would help.

Kerberos path. We checked from an affected client VM, running as an affected service account. Tickets come through the expected path: our on-premises domain controller issues the krbtgt/KERBEROS.MICROSOFTONLINE.COM referral, then KdcProxy:login.microsoftonline.com issues MSSQLSvc/<instance>:1433 @ KERBEROS.MICROSOFTONLINE.COM. The SQL service ticket has a one-hour, non-renewable lifetime.

We’re now running a probe every minute on that VM, as the same service account. It purges tickets, requests both tickets, and opens an unpooled connection. This should tell us two things:

Whether getting the tickets also fails when SQL fails.

Whether failures still cluster at :00–:03 at a constant connection rate. If they don’t, the clustering may only reflect our own hourly jobs, which open many new connections at the top of the hour.

We’ll post the results.

Conditional Access. Two policies apply to these service accounts:

One blocks all resources except the <instance> principal application, so it shouldn’t affect SQL.

The other applies only to the <instance> principal application, and requires a Microsoft Entra hybrid joined device. The client VMs are hybrid joined.

We’re confirming whether the second policy is enforced or report-only, and when it changed. We’re also checking the Kerberos server key versions on the incoming trust.

Questions:

What does 18456 state 188 mean for Windows Authentication for Entra principals?

Does Entra evaluate device-based Conditional Access when it issues the MSSQLSvc ticket through the KDC proxy? If so, could an intermittent device-state evaluation produce state 188?

ALTER LOGIN flushes security caches. Could the Entra Kerberos path fail to recover after a flush? That would fit disabling or re-passwording one login triggering instance-wide failures. But we can’t explain why the same change to a different login doesn’t.

State 188 isn’t documented, and we can reproduce the failure on demand. Would a Microsoft moderator be able to help us open a support case, so an engineer can look at the instance’s telemetry for 2026-10-28 10:20 UTC?
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-30T17:02:06.5666667+00:00

ALTER LOGIN flushes security caches. Could the Entra Kerberos path fail to recover after a flush? That would fit disabling or re-passwording one login triggering instance-wide failures. But we can’t explain why the same change to a different login doesn’t.

And if I understood you correctly, re-enabling that login brought things back to normal? That would speak against the issue being related to clearing security caches. But if you want to pursue this theory, you could disable the login and restart the instance. Or just restart the instance. But that is obviously not palatable if you need to have the logins working.

I agree that we would need to know what state 188 means. Else we are only fumbling in the dark.

Would a Microsoft moderator be able to help us open a support case, so an engineer can look at the instance’s telemetry for 2026-10-28 10:20 UTC?

I see that your post already is labelled as being a support case:

But I note that no one from Microsoft Support has engaged in the thread.

What support policy do you have?
Shaun Quarles 0 Reputation points

2026-10-30T17:33:54.41+00:00

We don't currently have an active support policy for this. But we are happy to get one if needed.
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-30T20:06:55.6633333+00:00

I think you need to get one. I've been thinking of asking around my contacts at Microsoft what state 188 might be, but it's not likely that they know it on the top of their head, and I don't want take their time with everything that tickles my curiosity. And, to be frank, I would not be surprised if the answer alone will make us more confused. That is, we would need someone with understanding of the technology to explain the details.

As for which level of support policy you need, I don't know. Developer support is only 30 USD/month, but that is enough to have this escalated to someone with knowledge enough, I don't know. Then again, if you only want access to telemetry, developer support should do, I guess.

Strange that you question was labelled PCS, if you don't have a support plan.
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-31T09:56:34.6833333+00:00

By the way, just to clarify: You found the state, 188, by looking in the SQL Server errorlog, and not in any other log? The reason I ask is that message 18456 often comes with supplementary text which is not exposed to the client, but which is written the SQL Server errorlog. Of course, it is possible that for this obscure state, that the developers did not bother to add any clarifying text.

The easiest way to look at the errorlog is to simply run xp_readerrorlog.

3 answers

Your answer

Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-30T17:02:06.5666667+00:00

ALTER LOGIN flushes security caches. Could the Entra Kerberos path fail to recover after a flush? That would fit disabling or re-passwording one login triggering instance-wide failures. But we can’t explain why the same change to a different login doesn’t.

And if I understood you correctly, re-enabling that login brought things back to normal? That would speak against the issue being related to clearing security caches. But if you want to pursue this theory, you could disable the login and restart the instance. Or just restart the instance. But that is obviously not palatable if you need to have the logins working.

I agree that we would need to know what state 188 means. Else we are only fumbling in the dark.

Would a Microsoft moderator be able to help us open a support case, so an engineer can look at the instance’s telemetry for 2026-10-28 10:20 UTC?

I see that your post already is labelled as being a support case:

But I note that no one from Microsoft Support has engaged in the thread.

What support policy do you have?
Shaun Quarles 0 Reputation points

2026-10-30T17:33:54.41+00:00

We don't currently have an active support policy for this. But we are happy to get one if needed.
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-30T20:06:55.6633333+00:00

I think you need to get one. I've been thinking of asking around my contacts at Microsoft what state 188 might be, but it's not likely that they know it on the top of their head, and I don't want take their time with everything that tickles my curiosity. And, to be frank, I would not be surprised if the answer alone will make us more confused. That is, we would need someone with understanding of the technology to explain the details.

As for which level of support policy you need, I don't know. Developer support is only 30 USD/month, but that is enough to have this escalated to someone with knowledge enough, I don't know. Then again, if you only want access to telemetry, developer support should do, I guess.

Strange that you question was labelled PCS, if you don't have a support plan.
Erland Sommarskog 138.6K Reputation points MVP Volunteer Moderator

2026-10-31T09:56:34.6833333+00:00

By the way, just to clarify: You found the state, 188, by looking in the SQL Server errorlog, and not in any other log? The reason I ask is that message 18456 often comes with supplementary text which is not exposed to the client, but which is written the SQL Server errorlog. Of course, it is possible that for this obscure state, that the developers did not bother to add any clarifying text.

The easiest way to look at the errorlog is to simply run xp_readerrorlog.

Answer 1

Dependency on the login: Nothing documented. In the documented flow, the instance exchanges the Kerberos ticket with Entra ID for a token, and no SQL login is involved. Your repro suggests an undocumented dependency: something needs that login enabled with that exact password. It could be connecting as the login or only checking its state. Keep it enabled with the working password and open a Microsoft support case. Don't disable it until Microsoft identifies the dependency.
Other causes: Failures or throttling in the Entra token exchange, problems with the instance's service principal, Conditional Access blocking that principal, proxy throttling under high Windows-auth connection volume, or platform events.
Trust issue? Probably not, since every client and account fails at once. To confirm, run klist get MSSQLSvc/<miname>.<dnszone>.database.windows.net:1433 during a failure. If it returns a valid ticket from kerberos.microsoftonline.com, the trust worked and the failure is on the instance side.

Answer 2

The documented Kerberos-to-Microsoft Entra authentication flow contains no dependency on a SQL-authenticated login or its password, so keep LegacyLogin enabled with its known working password and open an Azure SQL Managed Instance support case before disabling, changing, or dropping it again.

In this flow, the client submits a Kerberos ticket to SQL Managed Instance, which exchanges it with Microsoft Entra ID for a token; an unrelated SQL login is not a documented input ^1^. Your controlled reproduction—combined with the dependency checks already completed—is therefore an undocumented coupling, not a supported SQL-login dependency with a documented self-service removal procedure.

Do not drop and recreate the login as a diagnostic step. Give Microsoft Support:

MI resource name and region, affected database names, and precise UTC test windows.
The exact ALTER LOGIN operation and the times at which failures begin and recover.
SQL error-log rows including the 18456 state. States 102–111 and 132–133 identify Entra failures; an unlisted state can indicate unexpected internal processing ^2^.
Extended Events capturing error_reported for 18456, login, client_hostname, client_app_name, and connection identifiers during one controlled test. Creating an XE session requires ALTER ANY EVENT SESSION ^3^.
Evidence that the affected principal is not AzureSQLConnectivityChecker. MI’s automatic connectivity test intentionally generates 18456 approximately every ten seconds under that login; it does not explain failures naming your service accounts ^4^.

Investigate the independent intermittent failures

The failures occurring while LegacyLogin is unchanged could have a separate Kerberos/incoming-trust cause.

Capture tickets in the failing IIS worker identity’s security context. Tickets from an administrator’s interactive session do not establish what the application-pool identity has cached. During an incident, have the Windows/IIS administrator capture equivalent klist results from the worker-process identity context:
```
   klist get krbtgt/kerberos.microsoftonline.com
   klist get MSSQLSvc/<mi-name>.<dns-zone>.database.windows.net:1433
   klist
```
The SQL service ticket should be from the kerberos.microsoftonline.com realm ^5^.
Branch on the returned Kerberos error:
- 0x6fb: validate the SQL SPN and incoming-trust Trusted Domain Object.
- 0x52f: review Conditional Access affecting the application named <instance-name> principal. Microsoft documents excluding that MI service principal as mitigation ^5^. This weakens a security control: only use a narrowly scoped exclusion after Conditional Access/security-owner review, document the exception, and test it before broader deployment.
- 0x51f: on the affected client, run:
```
     netsh winhttp reset autoproxy
     netsh winhttp reset proxy
```
  Then remove only ProxyMgr registry subentries configured with port :8888, restart the client, and retest. Registry changes are risky; export the key first and have the Windows administrator perform the change ^5^.
Validate the incoming trust and GPO using domain/enterprise and Hybrid Identity administrator credentials. Get-AzureADKerberosServer should show CloudTrustDisplay as Microsoft.AzureAD.Kdc.Service.TrustDisplay. If the KDC proxy policy is absent or incorrect, enable: Administrative Templates → System → Kerberos → Specify KDC proxy servers for Kerberos clients Add this mapping, preserving the documented spaces:
- Name: KERBEROS.MICROSOFTONLINE.COM
- Value: <https login.microsoftonline.com:443:<tenant-id>/kerberos />
^6^
Validate MI identity configuration with an Entra administrator: Azure portal → SQL managed instance → Identity must have its system-assigned service principal enabled, and <instance-name> principal must have admin consent ^7^.

No supplied Microsoft documentation identifies an hourly authentication task that would explain :00–:03. Treat that timing as correlation evidence, not an established cadence. Include it in the support case and correlate it with ticket results, Conditional Access logs, domain-controller events, and exact UTC timestamps. Kerberos key rotation is a separate documented operation whose changes can take several hours to propagate—not an hourly process ^6^.

Client-side containment

Microsoft documents setting pooled connection lifetime to less than five minutes for this feature, preventing reuse after security-cache invalidation ^5^. The cited MI guidance does not specify the provider-specific connection-string keyword or units; confirm those against the exact Microsoft.Data.SqlClient or System.Data.SqlClient version before deployment rather than assuming the syntax is identical.
For EF Core, enable bounded execution-strategy retries:
```
  options.UseSqlServer(connectionString, sql =>
      sql.EnableRetryOnFailure(
          maxRetryCount: 3,
          maxRetryDelay: TimeSpan.FromSeconds(15),
          errorNumbersToAdd: null));
```
This does not establish that every 18456 is retryable. Add authentication errors only after identifying a narrowly scoped transient signature; generic 18456 retries can mask permanent configuration or credential failures ^8^.

EF6 can enable SqlAzureExecutionStrategy, but its documented built-in transient list does not include 18456:

  public sealed class EfConfiguration : DbConfiguration
  {
      public EfConfiguration() =>
          SetExecutionStrategy(
              "System.Data.SqlClient",
              () => new SqlAzureExecutionStrategy(3, TimeSpan.FromSeconds(15)));
  }

^9^

Use bounded backoff with jitter, log every retry, and retry an entire transaction rather than an individual statement within it ^10^.

References

Answer 3

Erland Sommarskog 138.6K MVP Volunteer Moderator

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.

0 comments

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

3 answers

Escalate the reproducible login coupling

Investigate the independent intermittent failures

Client-side containment

Your answer