la mejor manera de conectar el servidor sql (autenticación de Windows vs autenticación de SQL Server) para la aplicación asp.net

Question

Tengo una base de datos y un sitio que tiene autenticación de formularios. Está funcionando bien con VS2008. Esta vez, estoy usando "Trusted_connection = True". Pero cuando se abre desde el exterior o directamente desde el navegador, recibo el mensaje de error "Error de inicio de sesión para el usuario 'NT AUTHORITY \ ANONYMOUS LOGON'".

Sé que esto se debe a un permiso. El servidor SQL se basa en la autenticación de Windows.

• ¿Cuál es el mejor enfoque para administrar al usuario para conectar SQL Server?
• ¿Debo activar la autenticación de SQL Server?

Deseo saber qué hacer para que la producción se sienta y no haya ningún problema durante el despliegue.

Nota: SQL Server está instalado en el servidor de dominio.

Answer 1

La autenticación del sitio no tiene nada que ver con la autenticación entre ASP y SQL. La 'autenticación de formularios' en realidad no es una forma de autenticación verdadera, es solo un rol y membresía para la aplicación ASP.Net, sin relación con la infraestructura de seguridad.

Cuando ejecuta su sitio desde Visual Studio está iniciando el servidor web Visual Studio con su propia cuenta, y este servidor web se autenticará en SQL Server usando NTLM/Kerberos como usted, ya que se ejecuta con sus credenciales.

Cuando visita el sitio desde el navegador, su sitio se ejecuta desde el grupo de aplicaciones IIS con la identidad de dicho grupo de aplicaciones, que generalmente es un usuario local llamado IUSER _... Este usuario local, cuando se autentica con SQL El servidor que utiliza NTLM/Kerberos se autenticará como el usuario anónimo, ya que la cuenta local no tiene ningún significado en la máquina/dominio remoto que aloja el servidor SQL.

La solución es cambiar la identidad del grupo de aplicaciones a un usuario que puede autenticarse bien con SQL Server. Para esto, la máquina de hospedaje de IIS debe estar unida al mismo dominio que la máquina de host de SQL Server (o un dominio que confía en el dominio de máquina de host de SQL Server) y la identidad de la agrupación de aplicaciones debe cambiarse a una cuenta de este dominio. Así que si el equipo de SQL Server se ejecuta en un equipo unido al dominio FOO, entonces:

• asegúrese de que la máquina de IIS se unió a Foo
• crear un usuario de dominio FOO \ MyWebApp
• cambio del grupo de aplicaciones la identidad de Foo \ MyWebApp
• agregar un inicio de sesión de SQL para FOO \ MyWebApp
• conceder el permiso necesario en SQL a FOO \ MyWebApp

la alternativa de utilizar SQL Autenticación es malo por varias razones (posibilidad de exponer la contraseña en la web.config, posibilidad de exponer la contraseña durante la autenticación en el cable). Si la máquina de hospedaje de IIS no está unida al dominio, entonces puede usar cuentas duplicadas (cuentas locales con el mismo nombre y contraseña tanto en host IIS como en SQL) pero también tiene fallas: no puede funcionar con Kerberos, la contraseña de la cuenta para mantenerse sincronizado en los dos hosts, etc.

Answer 2

Un enfoque es crear una cuenta de servicio para que la use la aplicación. Usted crea la cuenta en Active Directory o similar. En IIS, configure el grupo de aplicaciones para que funcione bajo esa cuenta de servicio. En SQL Server, conceda permisos para la cuenta de servicio, ya sea directamente o poniendo la cuenta de servicio en un rol.

Aquí hay un artículo sobre how to do that.

Answer 3

Cree una cuenta de servicio administrado en el dominio donde pertenecen tanto la máquina del servidor SQL como la máquina del servidor web (IIS) o la confianza. A continuación, ejecute el grupo de aplicaciones de los servidores web en la cuenta de servicio administrado. Cree un inicio de sesión de SQL Server utilizando la cuenta de servicio administrado. Lea la siguiente publicación de Technet para obtener más información sobre la creación de cuentas de servicio administradas;

http://technet.microsoft.com/en-us/library/dd548356(v=ws.10).aspx