1

I have a service running on one server (A) which traditionally runs under the local system account. Now SQL server has moved from server A to a new server B.

I tried adding the computer account of server a [domain\servera$] to SQL server on server B and gave it all the rights it could possibly want (sa) but the service still cannot connect.

The error I find in the service log for that moment is the following

enbase 
ODBC database error:
Connect()
szSqlState = 28000
pfNativeError = 18456
szErrorMsg = [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
pcbErrorMsg = 100
LoginId = !!UnknownUser!!
ODBCRowNumber = 0
SSrvrLine = 0
SSrvrColumn = 0
SSrvrMsgState = 0
SSrvrSeverity = 0
SSrvrProcname = 
SSrvrSrvname =

I don't know why the service thinks that it is logging on as ANONYMOUS LOGON.

Any ideas?

Update: I wrote a test service running under localsystem that causes this message in SQL profiler:

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors."

Update: I think now that this is a Kerberos issue. Kerberos doesn't work because the domain account SQL is running under cannot register its Service Principal Names (setspn -L shows as much) and hence Kerberos cannot be used and NTLM is used and NTLM doesn't work for domain\computer$ for some reason.

Finally, ERRORLOG shows that SQL server logs an error about not being able to register the SPN for the SQL Server service. This confirms my theory, I think.

Update: I think the solution is to grant the domain account SQL Server is running under is trusted for delegation in AD so that it can register its SPN when SQL Server starts.

Andrew J. Brehm
  • 1,611
  • 7
  • 37
  • 57

2 Answers2

2

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

You're not using the machine account to connect...

LoginId = !!UnknownUser!!

You're not providing the right credentials.

You do know that what is known externally as DOMAIN\MACHINE$ is internally the NT Authority\Network Service account, I hope :)

adaptr
  • 16,576
  • 23
  • 34
  • I thought it was also localsystem? – Andrew J. Brehm Jan 31 '12 at 17:42
  • Network service account is what you'll need to use if you are ACL'ing with the Computer Account$. – Tatas Jan 31 '12 at 18:06
  • http://blogs.msdn.com/b/dataaccesstechnologies/archive/2010/01/29/testing-connection-to-sql-server-from-a-service-running-under-local-system-account.aspx claims the opposite. But regardless, I cannot use the network service account. – Andrew J. Brehm Jan 31 '12 at 18:07
  • Local System = admin rights on the machine, but no network access. Local Service = low-level permissions and no network access. Network Service = low-level permisisons + remote network access. – adaptr Feb 01 '12 at 12:52
  • Again, that contradicts Microsoft's documentation. It is wrong. – Andrew J. Brehm Feb 01 '12 at 15:04
  • 1
    Specifically, http://msdn.microsoft.com/en-us/library/ms143504.aspx says that the local service account has the same privileges as members of the users group while local system has "has extensive privileges on the local system and acts as the computer on the network". I don't know where you found your definitions of the accounts, but it is wrong. Local system does have network access. – Andrew J. Brehm Feb 01 '12 at 15:05
  • There is no way to gain access to a windows service remotely with a client machine's Local * accounts. I don't know what point you think you are making, but you're not making it. – adaptr Feb 01 '12 at 15:36
0

I believe this problem was solved by creating an SPN for the account that SQL server runs under. If the SPN exists, the client can authenticate with Kerberos and logs in as the client computer's domain account domain\clientcomputer$ which can be given the appropriate access to the SQL server.

Andrew J. Brehm
  • 1,611
  • 7
  • 37
  • 57
  • This document http://www.microsoft.com/en-us/download/details.aspx?id=4754 is very helpful for troubleshooting such issues, as is this article http://blogs.msdn.com/b/dataaccesstechnologies/archive/2010/01/29/testing-connection-to-sql-server-from-a-service-running-under-local-system-account.aspx – Rory Sep 08 '13 at 17:08