Eu tenho um serviço em execução em um servidor (A) que tradicionalmente é executado na conta do sistema local. Agora o servidor SQL foi movido do servidor A para um novo servidor B.
Eu tentei adicionar a conta de computador do servidor a [domain \ servera $] ao servidor SQL no servidor B e dei a ela todos os direitos que poderia desejar (sa), mas o serviço ainda não consegue se conectar.
O erro que encontro no log de serviço para esse momento é o seguinte
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 =
Não sei por que o serviço acha que está fazendo logon como LOGON ANÔNIMO.
Alguma idéia?
Atualização: eu escrevi um serviço de teste em execução no sistema local que causa essa mensagem no criador de perfil do SQL:
"O login falhou para o usuário 'NT AUTHORITY \ ANONYMOUS LOGON'. Motivo: Falha na validação do acesso ao servidor baseada em tokens com um erro de infra-estrutura. Verifique erros anteriores."
Atualização: acho que agora é um problema do Kerberos. O Kerberos não funciona porque o SQL da conta de domínio não pode registrar seus nomes principais de serviço (setspn -L mostra isso) e, portanto, o Kerberos não pode ser usado e o NTLM é usado e o NTLM não funciona para o domínio \ computer $ razão.
Por fim, ERRORLOG mostra que o servidor SQL registra um erro sobre não conseguir registrar o SPN para o serviço do SQL Server. Isso confirma minha teoria, eu acho.
Atualização: Acho que a solução é conceder a conta de domínio em que o SQL Server está sendo executado é confiável para delegação no AD para que ele possa registrar seu SPN quando o SQL Server for iniciado.