Por que o IIS usa a conta IUSR_Machine para carregar o aspnet_isapi.dll quando deveria usar a conta do pool de aplicativos?

2

Recentemente, recebi a tarefa de consertar um servidor Windows Server 2003 que estava executando o IIS 6.0:

HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.

Ele começou a fornecer essas respostas depois que o patch de atualização do Windows kb2633880 foi aplicado, o que parece ter alterado algumas permissões padrão com o IUSR_Machine conta e o diretório do framework .Net.

O problema é que todas as solicitações de recursos do asp.net (por exemplo, .aspx) não funcionaram enquanto todas as outras ações foram feitas (por exemplo, texto, html). O aplicativo é configurado para atender a solicitações anônimas usando a conta IUSR_machine e o Serviço de Rede para a conta do pool de aplicativos.

Verifiquei que a conta do Serviço de Rede pode acessar o diretório C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 , mas a conta IUSR_machine não pode. Depois de conceder acesso à conta IUSR_machine ao diretório C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 , o problema é resolvido. Isso parece muito estranho para mim.

Minha pergunta é por que o IIS não está usando a conta do meu pool de aplicativos (Serviço de Rede) para carregar o aspnet_isapi.dll? A partir da resolução de problemas acima, parece bastante claro que, de facto, está a utilizar a IUSR_machine para isto, o que parece ser uma falha de segurança. A marca de identidade no web.config não está configurada para que seja o padrão.

Eu gostaria de receber algum conselho sobre isso, obrigado.

    
por James 14.03.2012 / 02:48

1 resposta

1

Eu não posso responder às suas expectativas, mas os padrões para praticamente todos os sistemas ou DLLs do .Net são para que os usuários tenham acesso de leitura.

Aspnet_ISAPI é um filtro e uma extensão, portanto pode ser carregado pela inicialização do W3WP (como conta do Pool de aplicativos) ou pelo acesso a um arquivo mapeado por script (o mapeamento de script na verdade executa a DLL no contexto do usuário o trabalho, como seria de esperar).

    
por 14.03.2012 / 04:32