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.
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).