SQL Server Login Failed for User 'NT AUTHORITY\ANONYMOUS LOGON'

If you're seeing "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'" in SQL Server, you're probably stuck with a double-hop problem. It's frustrating because SQL Server is running, your credentials are valid, but it just won't let you in. Here's the fix that works 90% of the time in production.

The Quick Fix: Switch to SQL Authentication (Temporary)

If you need things working now, switch your connection to use a SQL Server login instead of Windows Authentication. This bypasses Kerberos entirely. Create a SQL login in SSMS:

CREATE LOGIN app_user WITH PASSWORD = 'StrongPa$$word!';
CREATE USER app_user FOR LOGIN app_user;
GRANT CONNECT, SELECT, EXECUTE TO app_user;

Then update your connection string to use User ID=app_user;Password=StrongPa$$word!;. This isn't the long-term fix, but it'll unblock you fast.

The Real Fix: Kerberos Delegation

The error happens when you connect from one machine to SQL Server on another, and SQL Server then tries to access a third resource (like a file share or another database) using your credentials. Windows won't forward your credentials beyond the first hop unless you set up Kerberos delegation.

Here's the step-by-step:

1. Register a Service Principal Name (SPN) for the SQL Server service account. Open PowerShell as admin on your domain controller or on the SQL Server itself:
   setspn -S MSSQLSvc/your-sql-server-name.domain.com:1433 domain\sql-service-account
setspn -S MSSQLSvc/your-sql-server-name:1433 domain\sql-service-account
   Replace with your server's FQDN and short name.
2. Enable Kerberos authentication in SQL Server — it's usually on by default, but verify: in SQL Server Configuration Manager, check that the service account is a domain account (not LocalSystem or NetworkService). LocalSystem can't do delegation reliably.
3. Set up delegation on the service account. Open Active Directory Users and Computers, find the SQL Server service account, go to the Delegation tab, and select "Trust this user for delegation to any service (Kerberos only)". Or if you want tighter control, use "Trust this user for delegation to specified services only" and add the SPN for the resource SQL Server needs to access (like a file server's CIFS SPN).
4. Test with a tool like klist tickets on the client machine to verify you have a Kerberos ticket for the SQL Server SPN, not a NTLM one. If you see krbtgt or NTLM in the output, delegation isn't working.

Why This Works

By default, Windows uses NTLM for network authentication when Kerberos fails. NTLM can't delegate credentials — it sends an anonymous token instead. That anonymous token hits SQL Server, and SQL Server says "I don't know who NT AUTHORITY\ANONYMOUS LOGON is." Registering the SPN and enabling delegation forces Windows to use Kerberos, which can forward your credentials to the next server.

Less Common Variations

Sometimes the error pops up in specific situations:

• Linked Servers: When querying a linked server using Windows Auth, the same double-hop issue appears. The fix is identical — set up delegation for both SQL Server instances, or use SQL Auth on the linked server connection.
• Reporting Services (SSRS): If SSRS is on one box and SQL Server on another, and reports use Windows integrated authentication, you'll see this error. Delegation for the SSRS service account is the answer.
• SQL Server Agent jobs: Jobs that run under a proxy account and access remote resources can trigger it. Use a domain account for the proxy and configure delegation.
• PowerShell Invoke-SqlCmd: Running from a remote machine? WinRM can trip this up. Use -Credential with a SQL login or set up CredSSP (not recommended for security reasons).

Prevention for the Future

Don't leave this bite you again:

• Use SQL Authentication for application connections whenever possible — it's simpler and avoids Kerberos headaches entirely.
• Standardize service accounts. Every SQL Server service should run under a dedicated domain account, not LocalSystem. Document the SPNs in your environment.
• Monitor SPN conflicts. If two service accounts have the same SPN, authentication fails silently. Use setspn -X to check for duplicates.
• Test linked servers with SQL Auth first during setup, then switch to Windows Auth only after delegation is verified.

I had a client last month whose entire print queue died because of this — the print server was trying to authenticate to SQL Server for logging, and the anonymous logon error killed it. Once we registered the SPN and turned on delegation, everything worked. It's almost always the same root cause.