¿Con qué cuenta se ejecuta ASP (clásico) cuando la autenticación integrada de Windows está activada?

Question

Tengo un archivo ASP que intenta realizar una solicitud de servicio web a un servicio web ASP.NET que se ejecuta en el mismo servidor en el mismo directorio virtual. En IIS, el directorio virtual está configurado para deshabilitar el acceso anónimo y la "autenticación integrada de Windows" está activada.

Entonces, el problema es que cuando la máquina del usuario solicita ejecutar la página ASP o incluso ejecutar manualmente el archivo WebService.asmx .NET, funciona porque las credenciales del usuario se pasan; sin embargo, cuando el archivo ASP intenta invocar el servicio web, obtenemos un 401.2 - No autorizado: acceso denegado debido a la configuración del servidor.

Por ejemplo:

• "DIRECTORIO\usuario1" desde un navegador en la máquina del usuario solicita Service.asmx, que funciona bien.
• "DIRECTORIO\usuario1" desde un navegador en la máquina del usuario solicita File1.asp, que funciona bien.
• _________ desde File1.asp en el servidor solicita Service.asmx que devuelve 401.2

Así que supuse que necesitaba establecer permisos NTFS en WebService.asmx para permitir permisos de lectura y ejecución de la cuenta ASP, pero no sé con qué cuenta se ejecuta y, tras pensarlo más después de leer algunas de las respuestas, parece que no llegan al nivel NTFS, IIS rechaza completamente la solicitud porque el acceso anónimo está desactivado.

¿Indica esto que necesitamos ejecutar el proceso ASP en una cuenta de dominio?

Answer 1

El ASP clásico se ejecuta haciéndose pasar por el usuario autenticado en el servidor en la sesión HTTP. Debe otorgar permiso a los usuarios que se autentican para ejecutar la aplicación ASP clásica o permitir el acceso anónimo.

Si ya probó "Usuarios autenticados" y no funciona, entonces diría que no tiene ningún problema de permiso de archivos.

¿Qué quiere decir cuando dice "...el archivo ASP intenta invocar el servicio web..."? ¿Está diciendo que el script ASP está realizando una solicitud HTTP al servidor? Si es así, las credenciales del usuario no se transmitirán en esa solicitud porque la "autenticación integrada de Windows" no le da al servidor una contraseña de texto sin formato para usar al autenticarse en otros servidores (o en sí mismo).

Editar:

Según su comentario, entonces, como se indicó anteriormente, el servidor no tendrá credenciales para autenticar al usuario porque la autenticación integrada de Windows no le da al servidor una contraseña de texto plano para pasar a otros servidores (o a sí mismo, que es otro servidor en este caso). ).

Tres cosas que puedes probar:

• Si puede hacer que WebService.asmx permita el acceso anónimo, su llamada HTTP de servidor a sí mismo debería funcionar (deberá permitir explícitamente el acceso anónimo permitiendo que IUSR_xxx lea el archivo).ymodificando la configuración de "Acceso anónimo y control de autenticación" para "Acceso anónimo" en el archivo mismo a través del complemento de la consola de administración de IIS, ya que ese archivo heredará la configuración habilitada de "Autenticación integrada de Windows" y deshabilitada de "Acceso anónimo" del directorio en el que se encuentra).

• Si el control que está utilizando para generar la solicitud HTTP admite proporcionar de forma transparente las credenciales del usuario que inició sesión al servidor remoto, puede habilitar la "autenticación básica" en el script ASP clásico (que le da al servidor una contraseña de texto sin formato para pasar a otros servidores) para que su control de solicitud HTTP pueda pasar esa contraseña en texto plano durante la solicitud de WebService.asmx. En ese momento, querrá solicitar SSL al acceder al script ASP clásico para mantener las contraseñas de texto sin formato fuera del cable.

• Finalmente, podría simplemente codificar algunas credenciales de autenticación básica en el script ASP clásico y habilitar la autenticación básica en el archivo WebService.asmx. Eso significa que WebService.asmx siempre verá el acceso del mismo usuario.

Ninguna de esas son soluciones muy buenas. Se encuentra con un problema "clásico" que vimos con el "ASP clásico" al intentar autenticarse en un nivel de back-end (base de datos, etc.) como el usuario que se autenticó para ejecutar el script ASP clásico.

Answer 2

Si la autenticación integrada está activada y el usuario está utilizando un navegador que realizará la autenticación integrada de Windowsyel usuario inicia sesión como una cuenta que se traduce en un servidor web (por ejemplo, la máquina cliente está en el mismo dominio que el servidor web), su script se ejecutará como la cuenta de ese usuario.

Si algo de lo anterior es falso (por lo que el servidor no puede acordar una cuenta de usuario con el navegador del cliente), entonces se utilizará IUSR_<machine>de forma predeterminada lo que haya configurado como usuario anónimo, o si la navegación anónima está deshabilitada, el usuario obtiene un error 401.*.

Esto supone que otras opiniones de autenticación están equivocadas. No estoy seguro de qué tiene prioridad si tiene habilitados los esquemas de autenticación Básico e Integrado de Windows al mismo tiempo.

Puede ver el usuario que el servidor web está utilizando actualmente para solicitudes a un área en particular ingresando un script que consulta la colección reqeust.servervariables y genera los valores relevantes: el nombre de usuario está allí.

Answer 3

Parece que está intentando realizar una autenticación de "doble salto". Por lo general, esto ocurre en el contexto de un servicio SQL backend, pero creo que podría aplicarse a un servicio separado que se ejecuta en el mismo servidor (aunque no estoy 100% seguro). Busque en MSKB ese término, "doble salto" y obtendrá algunos documentos que explican cómo configurar la delegación para permitir que esto funcione. Aquí hay uno para empezar,http://support.microsoft.com/kb/326985

Lo que necesita es que el servidor IIS esté configurado en "Delegación permitida". Cuando el usuario se autentica mediante la autenticación integrada de Windows, debería recibir un ticket de Kerberos (esto NO funcionará si obtiene la autenticación NTLM).

Para poder delegar, deberá agregar un SPN al servidor. Asegúrese de que los usuarios accedan a la página web con el FQDN real para el que el servidor tiene un SPN en AD. El nombre principal del servicio (SPN) es lo que el agente Kerberos del usuario utilizará para crear el ticket Kerberos correcto que permitirá que el servidor IIS se haga pasar por el usuario cuando entregue la solicitud al siguiente servicio.

Answer 4

¿Es importante que el servicio web utilice las credenciales del usuario que inició sesión? Si está utilizando algo como MSXML2.ServerXMLHTTPRequest para realizar la llamada al servicio web, ¿podría simplemente proporcionar credenciales en el método .Open para proporcionar un conjunto fijo de credenciales al servicio web?