Como configurar corretamente a identidade do pool de aplicativos do IIS 7?
Tendo implantado meu site no IIS7.5, encontrei um comportamento estranho: quando a identidade do pool de aplicativos é deixada para serApplicationPoolIdentity por padrão (como recomendado emIdentidades do pool de aplicativos do IIS)Ninject parece ser ignorado, como eu recebo o seguinte erro, ao criar o primeiro controlador:
System.InvalidOperationException: Ocorreu um erro ao tentar criar um controlador do tipo '..MainController'. Certifique-se de que o controlador tenha um construtor público sem parâmetros. ---> System.DirectoryServices.DirectoryServicesCOMException: Ocorreu um erro de operação.
Eu tentei concederFullAccess paraIIS AppPool\<MySiteAppPool> para a pasta, contendo o site (incluindo todas as subpastas e arquivos), mas isso não mudou nada.
No entanto, quando defino a identidade do pool de aplicativos para qualquer conta de domínio (mesmo que simples, sem privilégios administrativos, bem como sem acesso à pasta com o site), ela funciona normalmente.
Ninject é instalado de acordo comConfigurando um aplicativo MVC3 tutorial através do pacote NuGet.
Não tenho certeza, se for relevante, o site deve funcionar em uma intranet de domínio com autenticação do Windows.
Portanto, o único problema parece estar na identidade do pool de aplicativos. Tanto quanto eu estou ansioso para usar o caminho recomendado, eu adoraria ter oApplicationPoolIdentity, não uma conta de domínio.
Com o que isso pode estar conectado? É possível misturar tudo isso junto?
Aqui está um encadeamento SO com um problema semelhante:ASP.NET MVC 4 + Ninject MVC 3 = Nenhum construtor sem parâmetros definido para este objeto. No entanto, nenhuma resposta adequada também existe.
Como um comentário excluído sugeriu, tentei usarNetworkSerive como a identidade. E funcionou corretamente. No entanto, acho que isso não é muito melhor do que uma conta de domínio sem privilégios.
EDITAR
De repente, encontrou outra dependência: a identidade do pool de aplicativos é usada para a autenticação do windows no sql server, embora eu esperasse que as credenciais do usuário do lado do cliente fossem usadas lá.
Baseado nos comentários
Concorda que um servidor sql remoto pode ser acessado com as credenciais autenticadas por meio de representação.
No entanto, ainda não está claro qual é o problema com ApplicationPoolIdentity e Ninject.
O artigo mencionado no topo desta pergunta me fez supor que isso poderia ser causado pelo fato de que a conta virtualnão tem perfil de usuário. Esse aspecto ainda não está claro para mim, pois ainda é possível habilitar o IIS para carregar o perfil do usuário com oLoadUserProfile atributo. Não consigo, o que o IIS vai carregar, se não houver perfil para a conta virtual?
Diz-se aí:
O IIS não carrega o perfil de usuário do Windows, mas alguns aplicativos podem aproveitá-lo de qualquer maneira para armazenar dados temporários. O SQL Express é um exemplo de aplicativo que faz isso. No entanto, um perfil de usuário deve ser criado para armazenar dados temporários no diretório de perfil ou na seção do Registro. O perfil de usuário da conta NETWORKSERVICE foi criado pelo sistema e estava sempre disponível. No entanto, com a mudança para identidades exclusivas do Pool de Aplicativos, nenhum perfil de usuário é criado pelo sistema. Apenas os Pools de Aplicativos padrão (DefaultAppPool e Classic .NET AppPool) possuem perfis de usuário no disco. Nenhum perfil de usuário é criado se o administrador criar um novo pool de aplicativos.
No entanto, se desejar, você pode configurar pools de aplicativos do IIS para carregar o perfil de usuário, definindo o atributo "LoadUserProfile" como "true".
Eu encontrei o seguinte tópico no serverfault.com:
Como posso atribuir a permissão do diretório ativo à identidade padrão do pool de aplicativos?
Lá também é declarado que a identidade do pool de aplicativos não pode funcionar como um serviço de rede, em particular, consultar o AD.