La aplicación web que se ejecuta como SERVICIO DE RED puede conectarse a SQL Server, pero el servicio de Windows que se ejecuta como SISTEMA LOCAL no puede

4

He instalado una aplicación web .net en un servidor IIS de Windows Server 2003, ejecutándose en un grupo de aplicaciones NETWORK SERVICEy conectándome a SQL Server en una máquina diferente usando Seguridad integrada. La máquina de SQL Server también ejecuta Windows Server 2003. Por lo tanto, la aplicación web se conecta como identidad DOMAIN\COMPUTER$y esa cuenta tiene un inicio de sesión y un usuario en SQL Server para que todo funcione bien.

También he instalado un servicio de Windows .net en el mismo servidor IIS que se conecta a esa misma máquina SQL Server. El servicio de Windows se ejecuta como LOCAL SYSTEMy, por lo tanto, también debe conectarse como identidad DOMAIN\COMPUTER$. He instalado este mismo producto en más de una docena de compañías diferentes, normalmente todo funciona como esperaba, pero en un caso reciente el servicio de Windows no pudo conectarse a la base de datos, obteniendo el error:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

¿Alguna idea de por qué este sería el caso del SISTEMA LOCAL y no del SERVICIO DE RED? Para solucionar esto a corto plazo, tuve que cambiar para usar un inicio de sesión de SQL Server, pero preferiría usar Seguridad integrada si hay una solución fácil. No había mensajes de error en el registro de eventos de Seguridad o Sistema, aunque no había hecho nada para habilitar el registro adicional.

Normalmente supongo que este es un problema de tipo Kerberos / AD, y seguir artículos como este y esto ayudaría. Pero el hecho de que funcione desde el SERVICIO DE RED sugiere que las cosas normales que comprobaría ya están bien (por ejemplo, los SPN se han configurado correctamente y la cuenta de dominio de la máquina está habilitada para la delegación). Entonces, ¿qué configuración está yendo mal?

No tengo acceso a los servidores sin la ayuda del equipo de TI de mi cliente y hay otras aplicaciones instaladas en el servidor que debo tener en cuenta para no interrumpir, lo que hace que la solución de problemas sea un poco más delicada. ¡Cualquier sugerencia para solucionar problemas es muy apreciada!

sql-server authentication kerberos .net windows-authentication Rory
fuente

Respuestas:

4

Es posible que desee confirmar si la conexión de seguridad es NTLM o Kerberos. Si está volviendo a NTLM, la conexión será anónima.

Hay una política de grupo que permite usar la identidad de la computadora cuando se usa NTLM.

Seguridad de red: Permita que el sistema local use la identidad de la computadora para NTLM
http://technet.microsoft.com/en-us/library/jj852275%28v=ws.10%29.aspx

Para obtener más información sobre cómo configurar el SPN para facilitar la autenticación Kerberos para su servidor SQL:

http://blogs.msdn.com/b/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

En particular, tenga en cuenta lo siguiente:

Un SPN para SQL Server se compone de los siguientes elementos:

  • ServiceClass: identifica la clase general de servicio. Esto siempre es MSSQLSvc para SQL Server.
  • Host: este es el nombre de dominio DNS completo de la computadora que ejecuta SQL Server.

  • Puerto: este es el número de puerto en el que escucha el servicio.

    por ejemplo: MSSQLSvc / myserver.corp.mycomany.com: 1433

Greg Askew
fuente
Gracias, eso parece útil. ¿Sabe qué sucede con los procesos que se ejecutan como SERVICIO DE RED cuando la conexión vuelve a NTLM sin esa política configurada? es decir, ¿es normal que el proceso use la cuenta de la máquina cuando se ejecuta como SERVICIO DE RED pero anónimo cuando se ejecuta como SISTEMA LOCAL si la conexión se realiza a través de NTLM, si esa política no está configurada?
Rory
1
Esa restricción es solo para LocalSystem. NetworkService siempre usa la identidad de la computadora.
Greg Askew
2

Todavía estoy apostando el problema de SPN. No asumas que están ahí. Verifique el registro adecuado de SPN para SQL Server. También verifique si hay duplicados ( setspn -x).

Network Service funciona porque cuando el SPN no está allí, todavía puede recurrir a la autenticación NTLM.

Local Systemno funciona porque solo accede a los recursos de la red como DOMAIN\Computer$si pudiera usar Kerberos. De lo contrario, vuelve a una sesión nula, por lo que ves Anonymous Logon.

Ryan Ries
fuente