Login Failed for ''NT Authority\Anonymous Logon''

• Glenn Owens

  SSCrazy

  Points: 2099

  More actions

  June 10, 2005 at 7:31 am

  #88655

  Last night (late) I was notified that on of our servers was indicating that the SQL Scheduler was hung. After poking around the internet for a while, and without finding a satisfactory course of action, I restarted the SQL Server and Agent - that took care of the problem. After the restart I performed integrity checks on all of the databases (including Master and MSDB) - no errors found (yet another crisis averted )

  This morning I was greeted by three job failures on the same server as had been hung. All three jobs failed with: Login Failed for 'NT Authority\Anonymous Logon' [SQLState 28000](Error 18456). As the jobs all used linked servers within stored procedures the research lead to a double-hop authentication issue. Once again not finding any really satisfying answers on the internet I changed the security context under which the linked server was being accessed - specified an account/password for the remote server.

  I am wondering why, however, that jobs which have executed successfully for literally years have all-of-a-sudden begun to fail in this manner. I checked with the SA community - no changes to the remote server or security, policies, etc. have been made.

  I'm hoping that someone might be able to shed some light on these issues.

  Thanks

  Glenn

• gbn

  SSCertifiable

  Points: 6429

  More actions

  June 10, 2005 at 11:39 am

  #564706

  We have lots of linked servers with SPNs and security account delegation and pass-through SQL auth. In fact exclusively except for our remaning SQL 7

  Any time I see "anonymous user" it is usually because the user has no network login rights within the server GPO.

  It could also occur if one of:

  1. The connecting server needs rebooted (it has an issue)

  2. The connecting server is not trusted for delegation

  3. The calling account is "sensitive and cannot be trusted for delegation"

  4. There is no SPN for the connecting server in AD

  (This list is not exhaustive but it's what I'd check first)