How to fix error || Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' ||

Question

How to fix error || Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' ||

Lila osman 0

How to fix error || Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' || when app server tried to connect another DB server?

Erland Sommarskog 133.6K Reputation points MVP Volunteer Moderator

2026-03-17T22:06:53.4233333+00:00

What is the exact scenario here? Is user connecting to app server that connects to SQL Server? Or is App server connecting to SQL Server and is then trying to run a query over a linked server with self-mapping?

In either case, it is a matter of a double-hop problem. The AI answer gives a summary of how this can be fixed. I don't know if all points are applicable to your problem, but you did not give much context. In any case, I've never been good at these Kerberos problems myself, so I am not going to suggest something myself.
Anjan Kumar Chippa (Quadrant Resource LLC) 0 Reputation points Microsoft External Staff Moderator

2026-03-23T11:52:37.4633333+00:00

Hi Lila osman,

As we haven’t heard back from you, we wanted to kindly follow up to check if your issue is resolved? If not, can you please explain the issue in detail as the user mentioned above so that we can look more into the issue and provide you the best solution possible.

Thanks and regards,
Anjan Kumar Chippa

Answer recommended by moderator

0 additional answers

Your answer

Erland Sommarskog 133.6K Reputation points MVP Volunteer Moderator

2026-03-17T22:06:53.4233333+00:00

What is the exact scenario here? Is user connecting to app server that connects to SQL Server? Or is App server connecting to SQL Server and is then trying to run a query over a linked server with self-mapping?

In either case, it is a matter of a double-hop problem. The AI answer gives a summary of how this can be fixed. I don't know if all points are applicable to your problem, but you did not give much context. In any case, I've never been good at these Kerberos problems myself, so I am not going to suggest something myself.
Anjan Kumar Chippa (Quadrant Resource LLC) 0 Reputation points Microsoft External Staff Moderator

2026-03-23T11:52:37.4633333+00:00

Hi Lila osman,

As we haven’t heard back from you, we wanted to kindly follow up to check if your issue is resolved? If not, can you please explain the issue in detail as the user mentioned above so that we can look more into the issue and provide you the best solution possible.

Thanks and regards,
Anjan Kumar Chippa

Answer 1

The error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' between an app server and a remote SQL Server is an authentication/delegation problem, typically involving NTLM vs. Kerberos, SPNs, or loopback protection.

Troubleshooting and fixes depend on the scenario:

Check for double-hop / delegation issues
When credentials must be delegated across multiple computers (for example: client → app server → SQL Server), Kerberos delegation must be correctly configured. If delegation fails, SQL Server sees NT AUTHORITY\ANONYMOUS LOGON. Actions:
- Verify Service Principal Names (SPNs) for the SQL Server service and the app server service accounts.
- Use tools such as SQLCheck and follow these guides to diagnose and fix delegation/SPN issues:
  - 0600 Credential Delegation Issue
  - 0650 SQL Server Linked Server Delegation Issues
- Ensure accounts used for delegation are not marked as Sensitive account in Active Directory and that constrained delegation targets include the SQL Server SPN if constrained delegation is used.
Fix SPN problems when no double-hop is involved
If the app server connects directly to SQL Server (no further hop) but SQL Server still logs ANONYMOUS LOGON, the Kerberos handshake may be failing and falling back to NTLM due to SPN issues. Actions:
- Use SQLCheck or Setspn.exe to verify:
  - Required SPNs exist for the SQL Server service.
  - No duplicate SPNs exist.
  - SPNs are registered on the correct service account.
- Review and correct SPNs as needed.
- Optionally use Kerberos Configuration Manager for SQL Server to help detect and fix SPN-related issues.
Address loopback protection issues (same machine or Always On listener)
If the app and SQL Server are on the same machine, or the app connects to an Always On listener from the primary node, loopback protection can cause NTLM-based connections to fail and appear as ANONYMOUS LOGON. Actions:
- Configure one of the following registry keys on the server (preferred: BackConnectionHostNames):
  - DisableLoopbackCheck
  - BackConnectionHostNames
- For Always On listeners, add the listener NETBIOS name and FQDN to BackConnectionHostNames on all nodes in the Availability Group.
- See the linked article on loopback protection for exact registry steps and risks.
Check LANMAN compatibility level / NTLM vs Kerberos
On mixed environments (older pre–Windows Server 2008 and newer servers), LAN Manager compatibility settings can block NTLMv2 or cause mismatches. Actions:
- Set LANMAN compatibility level to 5 on all computers to disallow NTLMv1 and align authentication.
- Prefer switching to Kerberos authentication where possible to avoid LANMAN/NTLM issues.
Linked server specific case
If the app server is actually SQL Server using a linked server to another SQL Server and you see ANONYMOUS LOGON, the linked server security mapping may be wrong. Actions:
- In the linked server’s Security page, avoid Be made without using a security context (this leads to NT AUTHORITY\ANONYMOUS LOGON).
- Use Be made with this security context and supply a valid SQL login, or configure proper Windows authentication/delegation.
Other delegation-related causes
Additional AD and service configuration issues can cause this error:
- Sensitive account: If the account is marked as sensitive, it cannot be delegated in double-hop scenarios.
- Not a constrained target: If constrained delegation is enabled but the SQL Server SPN is not listed as an allowed target, Kerberos will fail.
- Per-Service-SID: This can limit local connections to NTLM and prevent further delegation.

In practice, start by identifying the pattern:

If the error appears only when there is a hop (client → app → SQL), focus on SPNs and Kerberos delegation configuration.
If it appears on same-machine or Always On listener connections, configure loopback protection (BackConnectionHostNames).
If it appears only for linked servers, correct the linked server security mapping.

References:

Share via

How to fix error || Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' ||

0 additional answers

Your answer