Suplantación de identidad en IIS 7.0

Question

Tengo un sitio web que funciona correctamente en IIS 6.0: autentica usuarios con credenciales de Windows y, luego, cuando habla con el servicio que visita la base de datos, pasa las credenciales.

En IIS 7.0, la misma configuración de configuración no pasa las credenciales, y el DB se golpea con NT AUTHORITY \ ANONYMOUS.

¿Hay algo que me falta? Desactivé el acceso ANÓNIMO en mi sitio web de IIS 7.0, pero no puedo hacer que funcione.

Estos son los ajustes que estoy usando tanto en IIS 6.0 y 7.0:

<authentication mode="Windows"> 
<identity impersonate="true"> 

Lo que ha cambiado de 6.0 a 7.0?

Answer 1

Ha habido cambios entre IIS7 e IIS6.0. Encontré para ti una publicación de blog que en realidad podría ayudarte (click here to see it).

¿Está ejecutando su aplicación en modo integrado o en modo clásico? Por lo que vi, poner el atributo Impersonate en true debería mostrar un error 500 con el siguiente mensaje de error:

Error interno del servidor. Esto es HTTP Error 500.19: no se puede acceder a la página solicitada porque los datos de configuración relacionados con la página son no válidos.

Aquí es la solución que se propone:

Solución:

1) Si la aplicación no se basa en suplantar la identidad del usuario que solicita en el BeginRequest y etapas AuthenticateRequest (la solo etapas donde la suplantación no es posible en modo integrado), ignore este error agregando lo siguiente aweb.config 210 de su aplicación:

<validation validateIntegratedModeConfiguration="false" 

/>

2) Si su aplicación depende de suplantación en BeginRequest y AuthenticateRequest, o si no está seguro de , pasar a modo clásico.

Espero que haya sido útil para comprender cómo funciona ahora IIS 7.0.

Answer 2

Interesante ... Tengo el problema opuesto: No se puede obtener la autenticación para pasar desde el navegador del cliente, a través del servidor web y en la base de datos dentro de una gran red corporativa a través de firewalls.

También creo que la autenticación de "usuario de extremo a extremo" en la base de datos es una mala idea y un posible riesgo de seguridad. No hay nada que impida que el usuario final cargue SQL Query y se conecte directamente a su base de datos, ¡así que será mejor que bloquee su esquema!

@Esteban - Clarificado mi no muy útil para ayudarlo respuesta.

Answer 3

Normalmente, si realiza una autenticación de doble salto como esta, Kerberos suele estar involucrado a menos que la primera autenticación sea Básica.

Me gustaría comprobar la autenticación en los servidores IIS 6 y asegúrese de que es la misma en IIS 7.

Si el cuadro de IIS 6 se establece en Windows Integrada, entonces usted necesita para comprobar la configuración de Kerberos - SPN , Delegación, etc.

Answer 4

¿El servidor SQL está configurado para que el SQLServer pueda confiar en él? Me he encontrado con esto antes con WebDAV donde tuvimos que tener el servidor ejecutando IIS en el que el servidor de archivos confiaba para autenticarse en nombre del servidor de archivos.