¿Cómo configurar correctamente la identidad del grupo de aplicaciones de IIS 7?
Después de haber implementado mi sitio web en IIS7.5, encontré un comportamiento extraño: cuando la identidad del grupo de aplicaciones deja de serApplicationPoolIdentity por defecto (como se recomienda enIdentidades del grupo de aplicaciones IIS)Ninject Parece que se ignora, ya que aparece el siguiente error, al crear el primer controlador:
System.InvalidOperationException: se produjo un error al intentar crear un controlador de tipo '..MainController'. Asegúrese de que el controlador tenga un constructor público sin parámetros. ---> System.DirectoryServices.DirectoryServicesCOMException: Se produjo un error de operaciones.
Traté de concederFullAccess aIIS AppPool\<MySiteAppPool> a la carpeta, que contiene el sitio (incluidas todas las subcarpetas y archivos), pero esto no cambió nada.
Sin embargo, cuando configuro la identidad del grupo de aplicaciones en cualquier cuenta de dominio (incluso una simple, sin privilegios administrativos, así como sin ningún acceso a la carpeta con el sitio), funciona normalmente.
Ninject se instala de acuerdo aConfigurando una aplicación MVC3 tutorial a través del paquete NuGet.
No estoy seguro, si es relevante, se supone que el sitio funciona en una intranet de dominio con autenticación de Windows.
Entonces, el único problema parece ser con la identidad del grupo de aplicaciones. En la medida en que estoy ansioso por usar la forma recomendada, me encantaría tener laApplicationPoolIdentity, no una cuenta de dominio.
¿Con qué se puede conectar esto? ¿Es posible mezclar todos estos juntos?
Aquí hay un hilo SO con un problema similar:ASP.NET MVC 4 + Ninject MVC 3 = No se ha definido ningún constructor sin parámetros para este objeto. Sin embargo, tampoco hay una respuesta adecuada en absoluto.
Como sugerí un comentario eliminado, traté de usarNetworkSerive como la identidad. Y funcionó correctamente. Sin embargo, supongo que esto no es mucho mejor que una cuenta de dominio sin privilegios.
EDITAR
De repente, se encontró otra dependencia: la identidad del grupo de aplicaciones se usa para la autenticación de Windows en el servidor SQL, aunque esperaba que las credenciales del usuario del lado del cliente se usaran allí.
Basado en comentarios
Acuerde que se puede acceder a un servidor de SQL remoto con las credenciales autenticadas mediante la suplantación.
Sin embargo, todavía no está claro cuál es el problema con ApplicationPoolIdentity y Ninject.
El artículo mencionado en la parte superior de esta pregunta me hizo suponer que esto podría deberse al hecho de que la cuenta virtualno tiene perfil de usuario. Este aspecto no me queda claro, ya que aún se puede permitir que IIS cargue el perfil de usuario con elLoadUserProfile atributo. No puedo obtener, ¿qué va a cargar IIS si no hay un perfil para la cuenta virtual?
Se dice allí:
IIS no carga el perfil de usuario de Windows, pero algunas aplicaciones pueden aprovecharlo de todos modos para almacenar datos temporales. SQL Express es un ejemplo de una aplicación que hace esto. Sin embargo, se debe crear un perfil de usuario para almacenar datos temporales en el directorio del perfil o en la sección del registro. El perfil de usuario para la cuenta NETWORKSERVICE fue creado por el sistema y siempre estuvo disponible. Sin embargo, con el cambio a identidades de grupo de aplicaciones únicas, el sistema no crea ningún perfil de usuario. Solo los grupos de aplicaciones estándar (DefaultAppPool y Classic .NET AppPool) tienen perfiles de usuario en el disco. No se crea ningún perfil de usuario si el administrador crea un nuevo grupo de aplicaciones.
Sin embargo, si lo desea, puede configurar los Grupos de aplicaciones de IIS para cargar el perfil de usuario configurando el atributo "LoadUserProfile" en "true".
Encontré el siguiente hilo en serverfault.com:
Allí también se indica que la identidad del grupo de aplicaciones no puede funcionar como un servicio de red, en particular, consultar el AD.