Esto es probablemente una combinación de suplantación y una falta de coincidencia de los diferentes métodos de autenticación que se producen.
Hay muchas piezas; Trataré de revisarlos uno por uno.
Impersonation es una técnica para cambiar "temporalmente" la cuenta de usuario con la que se está ejecutando un subproceso. Básicamente, el hilo obtiene los mismos derechos y acceso, ni más ni menos, que la cuenta que se está suplantando. Tan pronto como el hilo termina de crear la página web, "vuelve" a la cuenta original y se prepara para la próxima llamada. Esta técnica se usa para acceder a recursos a los que solo tiene acceso el usuario que inició sesión en su sitio web. Mantenga el concepto por un minuto.
Ahora, de forma predeterminada ASP.NET ejecuta un sitio web en una cuenta local llamada ASPNET. Nuevamente, de manera predeterminada, solo la cuenta ASPNET y los miembros del grupo Administradores pueden escribir en esa carpeta. Su carpeta temporal está bajo el ámbito de esa cuenta. Esta es la segunda pieza del rompecabezas.
La suplantación no ocurre por sí sola. Debe activarse intencionalmente en su web.config.
<identity impersonate="true" />
Si el ajuste no se encuentra o establece en false, el código se ejecutará pura y simplemente bajo la cuenta ASPNET se mencionó anteriormente. Dado su mensaje de error, estoy seguro de que tiene la suplantación = verdadero. ¡No hay nada de malo en ello! La suplantación tiene ventajas y desventajas que van más allá de esta discusión.
Queda una pregunta: cuando utiliza la suplantación, ¿qué cuenta se hace pasar por?
A menos que especifique la cuenta en el archivo web.config (full syntax of the identity element here), la cuenta suplantada es la que el IIS entregó a ASP.NET. Y eso depende de cómo el usuario se haya autenticado (o no) en el sitio. Esa es tu tercera y última pieza.
La cuenta IUSR_ComputerName es una cuenta con pocos derechos creada por IIS. De forma predeterminada, esta cuenta es la cuenta en la que se ejecuta una llamada web si el usuario no pudo ser autenticado. Es decir, el usuario entra como "anónimo".
En resumen, esto es lo que le está pasando:
Su usuario está tratando de acceder al sitio web, y IIS no se pudo autenticar la persona que por alguna razón. Debido a que el acceso anónimo está activado, (o no vería IUSRComputerName accediendo a la carpeta temporal), IIS permite al usuario de todos modos, pero como un usuario genérico. Su código ASP.NET se ejecuta y suplanta a esta cuenta genérica IUSR___NombreDeEquipoComputador; solo que ahora el código no tiene acceso a las cosas a las que tuvo acceso la cuenta ASPNET, incluida su propia carpeta temporal.
Otorgando IUSR_ComputerName ESCRIBIR el acceso a la carpeta hace que sus síntomas desaparezcan.
Pero eso solo los síntomas. Necesita revisar ¿por qué la persona viene como "Anónimo/Invitado"?
Hay dos escenarios posibles:
a) que la intención de utilizar IIS para la autenticación, pero la configuración de autenticación de IIS para algunos de sus servidores están equivocados.
En ese caso, debe deshabilitar el acceso anónimo en esos servidores para que se produzcan los mecanismos de autenticación habituales. Tenga en cuenta que aún podría necesitar otorgar a sus usuarios acceso a esa carpeta temporal, o usar otra carpeta, una a la que sus usuarios ya tengan acceso.
He trabajado con este escenario muchas veces, y francamente le da menos dolores de cabeza para renunciar a la carpeta Temp; cree una carpeta dedicada en el servidor, establezca los permisos adecuados y establezca su ubicación en web.config.
b) Usted no desea autenticar la gente de todos modos, o si desea utilizar la autenticación de formularios ASP.NET (que utiliza el acceso anónimo de IIS para evitar los chequeos en IIS y ASP.NET permite manejar la autenticación directamente)
Este caso es un poco más complicado.
Debería ir a IIS y deshabilitar todas las formas de autenticación que no sean "Acceso anónimo". Tenga en cuenta que no puede hacer eso en el cuadro del desarrollador, porque el depurador necesita la autenticación integrada para habilitarse. Por lo tanto, su caja de depuración se comportará un poco diferente que el servidor real; Solo ten cuidado con eso.
Luego, debe decidir si debe desactivar la suplantación o, a la inversa, especificar la cuenta para suplantar en el archivo web.config. Haga lo primero si su servidor web no necesita recursos externos (como una base de datos). Haga lo segundo si su sitio web necesita ejecutarse bajo una cuenta que tenga acceso a una base de datos (u otro recurso externo).
Tiene dos alternativas más para especificar la cuenta para suplantar. Uno, podría ir a IIS y cambiar la cuenta "anónima" para que sea una con acceso al recurso en lugar de la que IIS administra para usted.La segunda alternativa es esconder la cuenta y la contraseña cifradas en el registro. Ese paso es un poco complicado y también va más allá del alcance de esta discusión.
¡Buena suerte!