Solução de problemas de permissões comuns e problemas relacionados à segurança no ASP.NET

Este artigo apresenta como solucionar problemas comuns de permissões e problemas relacionados à segurança no ASP.NET.

Versão original do produto: ASP.NET
Número de KB original: 910449

Ferramentas úteis

Antes de tentar corrigir qualquer coisa que esteja quebrada, você precisa se familiarizar com algumas ferramentas, o que ajudará você a reduzir o problema. No nosso caso, estaríamos interessados em ferramentas como FileMon, RegMon e Auditoria de Segurança. Para obter mais informações sobre FileMon, consulte FileMon para Windows v7.04.

Para obter mais informações sobre RegMon, consulte Sysinternals do Windows.

Detalhar para isolar o problema

• O aplicativo já funcionou? Se sim, então o que mudou que poderia ter feito o aplicativo quebrar? É possível que atualizações de software ou atualizações de segurança tenham sido aplicadas no servidor. Uma distribuição de código também pode ter causado o problema.
• Páginas de .html e .asp simples servem do IIS?
• O aplicativo foi migrado para uma versão diferente do IIS?
• Outros aplicativos ASP.NET no servidor falham com o mesmo erro? Esse é o único aplicativo que falha?
• O problema ocorre para todos os usuários ou apenas para usuários específicos?
• O problema é reproduzível ao navegar localmente no servidor Web ou é reproduzível para apenas alguns clientes?
• Se você estiver usando a representação, o usuário representado terá o acesso necessário ao recurso?

As perguntas acima são úteis para diagnosticar um problema. Se você estiver postando seu problema em qualquer um dos fóruns ASP.NET e se você já tiver as respostas para a maioria dessas perguntas, é provável que você obtenha um ponteiro rápido ou solução para o seu problema. A chave é postar todo o ASP.NET erro de rastreamento de pilha, se aplicável, em vez de dizer "Estou recebendo um erro negado pelo Access ao tentar executar meu aplicativo ASP.NET. Alguém pode ajudar?" É muito mais fácil para alguém olhar para o rastreamento de pilha e dar-lhe ponteiros quando eles podem ver uma mensagem de erro completa. Então você precisa se perguntar...

Qual é a mensagem de erro exata?

A primeira pergunta que fazemos aos clientes é: "Qual é a mensagem de erro exata?" Se você tiver uma descrição clara da mensagem de erro lançada pelo microsoft .NET Framework, você poderá ignorar esta seção. Se o aplicativo mascarar a mensagem de erro real e lhe fornecer uma mensagem de erro amigável, como: "Ocorreu um erro inesperado. Entre em contato com o administrador do site para obter detalhes", não é muito usado para ninguém. Aqui estão algumas etapas, que ajudarão você a obter a mensagem de erro real.

• Localize e abra o arquivo Web.config no diretório do aplicativo e altere customErrors para mode="Off". Salve o arquivo e reproduza o problema.

• Ainda pode não ser possível ver a mensagem de erro real depois de seguir a etapa acima devido ao tratamento personalizado de eventos/erros feito pelo desenvolvedor do aplicativo. Você pode tentar localizar o evento Application_Error no arquivo Global.asax e comentar qualquer código que use a Server.Transfer("Errors.aspx") função para acessar uma página de erro personalizada.

  //Global.asax 
  void Application_Error(object sender, EventArgs e) 
  { 
      // Code that runs when an unhandled error occurs 
      //Server.Transfer("Errors.aspx"); 
  }
  

Depois de receber a mensagem de erro real, leia-a para determinar se o erro é causado por permissões ausentes em um recurso local ou em um recurso remoto que seu aplicativo ASP.NET está tentando acessar.

O problema ocorre devido a permissões ausentes em um recurso local que o aplicativo ASP.NET tenta acessar

Se você não conseguir obter uma descrição clara do problema devido a uma mensagem de erro personalizada, execute FileMon e reproduza o problema. Pare e salve a captura como FileMon.xls e abra o arquivo no Microsoft Excel. No menu Dados , clique em Filtrar e clique em AutoFilter para usar os recursos de filtragem do Excel. Agora, selecione a lista suspensa na coluna F e procure erros "ACCESS DENIED".

Uma saída filemon de exemplo é mostrada abaixo.

10381 1:01:11 PM w3wp.exe:2320 OPEN C:\winnt\microsoft.net\framework\v1.1.4322\Temporary ASP.NET Files\sessiontest\8832e585\275ec327\global.asax.xml 
ACCESS DENIED NT 
AUTHORITY\NETWORK SERVICE

Como você pode ver pelos resultados filtrados, reduzimos a causa do problema. FileMon mostra que a conta NT AUTHORITY\NETWORK SERVICE não tem permissões NTFS na C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files pasta. Isso deve ser direto para corrigir.

A maioria das pessoas tende a reinstalar o Microsoft .NET Framework ou até mesmo ir para a extensão da reinstalação do sistema operacional. Essa não é uma etapa de solução de problemas recomendada e não garante que o problema não se repita. Vou fornecer um exemplo desse tipo. Problemas intermitentes geralmente são difíceis de isolar e solucionar problemas. Nesse cenário, o aplicativo do cliente funcionaria bem por algumas horas e, de repente, falharia com o erro abaixo. O cliente já havia tentado reinstalar o .NET Framework bem como o sistema operacional. Isso parecia corrigir o problema por alguns dias, mas depois reapareceu.

A execução do FileMon não mostrou nenhum erro DO ACCESS DENIED . Todas as permissões necessárias para a conta ASPNET estavam em vigor. A única maneira de se recuperar do problema é reinicializar a caixa. Nem mesmo uma redefinição do IIS ajudaria. Você está pensando "Ah, a Microsoft Software sempre precisa de uma reinicialização para se recuperar?" Bem, você está errado!

A chave aqui é examinar de perto a mensagem de erro. O erro diz claramente que "não é possível abrir um arquivo para gravação", e não o erro habitual ACCESS DENIED , então estou pensando que é algum outro processo que está segurando um bloqueio em um arquivo ou pasta e não permitindo que ASP.NET escreva nele. Faz sentido que uma reinicialização estava matando o outro processo e o aplicativo ASP.NET comece a funcionar novamente até que o processo desonesto bloquee o arquivo novamente. A coisa lógica a fazer seria desativar todos os programas antivírus, spyware de terceiros ou qualquer outro software de monitoramento de arquivos executado no servidor. Não quero apontar nenhum software de terceiros específico. Mas, em geral, o software antivírus é conhecido por causar muita dor para aplicativos IIS e ASP.NET. Outro problema conhecido causado pelo software antivírus é a perda de sessão devido à reciclação do AppDomain quando a pasta Bin ou os arquivos .config são tocados.

Monitore seu aplicativo para ver se o problema ocorre novamente. Se você executar vários programas antivírus, use o método trial-and-error para determinar qual programa específico está causando o problema.

Consulte ASP.NET ACLs (Controle de Acesso Listas Obrigatório).

Em vez disso, use um prompt de comando e execute o seguinte comando:

cacls %windir%\assembly /e /t /p domain\useraccount:r

Como alternativa, antes de usar o Windows Explorer, cancele o registro Shfusion.dll com o seguinte comando para fornecer permissões por meio da GUI:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32-u shfusion.dll

Depois de definir permissões com o Windows Explorer, registre novamente Shfusion.dll com o seguinte comando:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32 shfusion.dll

O problema ocorre devido a permissões ausentes em um recurso remoto que o aplicativo ASP.NET está tentando acessar

Quando seu aplicativo ASP.NET está acessando um recurso remoto como o microsoft SQL Server ou um compartilhamento UNC (Convenção Universal de Nomenclatura), há muitas coisas que podem dar errado. Além disso, muitas coisas podem estar configuradas incorretamente no recurso remoto. Você precisará solucionar esses problemas para que o recurso funcione.

Sua primeira etapa seria ver se você pode se conectar ao servidor remoto por meio do Windows Explorer.

1. No servidor remoto, crie uma pasta chamada Teste. Nas guias Compartilhamento e Segurança da pasta Teste, adicione seu domínio/conta e também a conta de processo que é usada pelo aplicativo ASP.NET e forneça a ambos o Controle Total.

2. No servidor IIS, faça logon com seu domínio/conta, clique em Iniciar, clique em Executar e digite o caminho de compartilhamento UNC do servidor remoto: \\RemoteServerName*\Test.

   Se você não conseguir acessar essa pasta, entre em contato com o Administrador de Rede para corrigir esse problema. Somente então o aplicativo ASP.NET pode acessar o compartilhamento.

3. Crie um arquivo chamado CreateUNCFile.aspx com o código abaixo e salve o arquivo no diretório do aplicativo.

   <%@ Page Language="vb" %>
   <%@ Import Namespace="System.IO" %>
   <html>
   <head>
   <title>Writing to a Text File</title>
   <script runat="server">
       Sub WriteToFile(ByVal sender As System.Object, ByVal e As System.EventArgs)
           Dim fp As StreamWriter
               fp = File.CreateText("\\<RemoteServerName>\Test\" & "test.txt")
               fp.WriteLine(txtMyFile.Text)
               lblStatus.Text = "The File Successfully created! Your ASP.NET process is able to access this remote share"
               fp.Close()
       End Sub
   </script>
   
   </head>
   <body style="font: 10pt verdana">
               <h3 align="center">Creating a Text File in ASP.NET</h3>
       <form id="Form1" method="post" runat="server">
                           Type your text:
                           <asp:TextBox ID="txtMyFile" TextMode="MultiLine" Rows="10" Columns="60" Runat="server" /><br>
                           <asp:button ID="btnSubmit" Text="Create File" OnClick="WriteToFile" Runat="server" />
                           <asp:Label ID="lblStatus" Font-Bold="True" ForeColor="#ff0000" Runat="server" />
       </form>
   </body>
   </html> 
   

4. Verifique se você modifica <RemoteServerName> na linha de código a seguir

   fp = File.CreateText("\\<RemoteServerName>\Test\" &"test.txt")
   

   Para que ele reflita o nome do servidor remoto.

5. Abra o Windows Internet Explorer e navegue até de http://**IISServerName**/**AppName**/CreateUNCFile.aspx um computador cliente diferente do servidor IIS.

6. Se o arquivo Test.txt for criado com êxito, seu aplicativo ASP.NET poderá se autenticar no recurso remoto.

7. Se a criação de arquivos falhar de um navegador cliente Explorer Internet, mas funcionar se você procurar na mesma página do próprio servidor IIS, é provável que você esteja correndo para um cenário de "Double Hop". Se você estiver usando Web Parts personalizados para acessar recursos remotos que exigem autenticação e autorização do usuário, provavelmente encontrará o problema do "Double Hop". Para acessar seu recurso remoto, talvez seja necessário fornecer as credenciais do usuário final ao recurso para que a saída do recurso seja limitada aos dados que o usuário final tem permissão para acessar.

As etapas acima pressupõem que você tenha a Autenticação NTLM ativada no IIS. A Autenticação Básica não usa Kerberos.

Para obter mais informações, confira Solucionar problemas de falhas do Kerberos no Explorer da Internet.

Para obter mais informações sobre métodos de autenticação do IIS, consulte Documentação técnica aposentada do Visual Studio 2003.

Há várias outras causas para a mensagem de erro "Aplicativo do Servidor Indisponível". O log de eventos é sua melhor aposta para obter mais detalhes sobre a causa do problema.

Erros relacionados ao IIS

Os logs do IIS são úteis em casos de erros relacionados à autenticação do IIS.

O que você precisa procurar são os códigos status e sub-status para esse erro específico.

2006-10-12 22:47:28 W3SVC1 65.52.18.230 GET /MyAPP/login.aspx - 80  
MyDomain\UserID_91 65.52.22.58 Mozilla/4.0+  
(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 401 3 5

Vemos um 401 com o substatus 3, que indica "Não autorizado devido à ACL no recurso".

Isso indica permissões NTFS ausentes em um arquivo ou pasta. Esse erro pode ocorrer mesmo que as permissões estejam corretas para o arquivo que você está tentando acessar, mas as permissões padrão e os direitos do usuário podem estar ausentes em outras pastas SYSTEM e IIS. Por exemplo, você poderá ver esse erro se a conta IUSR_ComputerName não tiver acesso ao diretório C:\Winnt\System32\Inetsrv.

A outra coisa de interesse aqui é o código status 5. Você pode usar o comando net helpmsg para obter mais informações sobre este código status:

C:\Documents and Settings\User> net helpmsg 5

Acesso negado.

Vamos tentar outro código de status comum, o código 50:

C:\Documents and Settings\User> net helpmsg 50

A solicitação não tem suporte.

A ideia é usar todas as informações registradas disponíveis para obter o máximo de detalhes sobre o problema em questão.

Recursos

Para saber mais, veja:

• Introdução ao ASP.NET Identity

• Como criar uma conta de serviço para um aplicativo ASP.NET 2.0

• Criando aplicativos de ASP.NET seguros: autenticação, autorização e comunicação segura