Instalei um aplicativo da web .net em um servidor IIS do Windows Server 2003, executando em um pool de aplicativos NETWORK SERVICE
e conectando-me ao SQL Server em uma máquina diferente usando Segurança Integrada. A máquina SQL Server também está executando o Windows Server 2003. O aplicativo Web, portanto, se conecta como identidadeDOMAIN\COMPUTER$
e essa conta tem login e usuário no SQL Server para que tudo funcione bem.
Também instalei um serviço .net do Windows no mesmo servidor IIS que se conecta à mesma máquina SQL Server. O serviço do Windows é executado como LOCAL SYSTEM
e, portanto, também deve se conectar como identidadeDOMAIN\COMPUTER$
. Instalei este mesmo produto em mais de uma dúzia de empresas diferentes, normalmente tudo funciona como esperado, mas em um caso recente o serviço do Windows não conseguiu se conectar ao banco de dados, recebendo o erro:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
Alguma idéia de por que esse seria o caso do SISTEMA LOCAL e não do SERVIÇO DE REDE? Para contornar isso a curto prazo, tive que mudar para um login do SQL Server, mas preferiria usar a Segurança Integrada se houvesse uma solução fácil para isso. Não houve mensagens de erro no log de eventos de segurança ou sistema, embora eu não tenha feito nada para ativar o log adicional.
Normalmente eu presumo que isso é algum tipo de problema do tipo Kerberos/AD, e os seguintes artigos comoesseeesseajudaria. Mas o fato de funcionar no NETWORK SERVICE sugere que as coisas normais que eu verificaria já estão ok (por exemplo, os SPNs foram configurados corretamente e a conta do domínio da máquina está habilitada para delegação?). Então, qual configuração está errada?
Não tenho acesso aos servidores sem o auxílio da equipe de TI do meu cliente e há outros aplicativos instalados no servidor que preciso estar atento para não atrapalhar, o que torna a solução de problemas um pouco mais delicada. Qualquer sugestão para solução de problemas será muito apreciada!
Responder1
Você pode querer confirmar se a conexão de segurança é NTLM ou Kerberos. Se estiver revertendo para NTLM, a conexão será anônima.
Existe uma política de grupo que permite usar a identidade do computador quando o NTLM é usado.
Segurança de rede: permitir que o sistema local use a identidade do computador para NTLM
http://technet.microsoft.com/en-us/library/jj852275%28v=ws.10%29.aspx
Para obter mais informações sobre como configurar o SPN para facilitar a autenticação Kerberos no seu SQL Server:
Em particular, observe o seguinte:
Um SPN para SQL Server é composto pelos seguintes elementos:
- ServiceClass: identifica a classe geral de serviço. É sempre MSSQLSvc para SQL Server.
- Host: Este é o nome de domínio DNS totalmente qualificado do computador que está executando o SQL Server.
Porta: Este é o número da porta em que o serviço está escutando.
por exemplo: MSSQLSvc/myserver.corp.mycomany.com:1433
Responder2
Ainda estou apostando no problema do SPN. Não presuma apenas que eles estão lá. Verifique o registro adequado de SPNs para SQL Server. Verifique também se há duplicatas ( setspn -x
).
Network Service
funciona porque quando o SPN não está lá, ele ainda pode recorrer à autenticação NTLM.
Local System
não funciona porque acessa apenas recursos de rede como DOMAIN\Computer$
se pudesse usar Kerberos. Caso contrário, ele volta para uma sessão nula, e é por isso que você vê Anonymous Logon
.