Compartilhar via

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

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

Versão original do produto: ASP.NET
Número original da base de conhecimento: 910449

Ferramentas úteis

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

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

Faça uma busca detalhada 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. Um lançamento de código também pode ter causado o problema.
  • As páginas .html e .asp simples são servidas pelo IIS?
  • O aplicativo foi migrado para uma versão diferente do IIS?
  • Outros aplicativos ASP.NET no servidor falham com o mesmo erro? Este é o único aplicativo que falha?
  • O problema ocorre para todos os usuários ou apenas para usuários específicos?
  • O problema pode ser reproduzido durante a navegação local no servidor Web ou é reproduzível apenas para alguns clientes?
  • Se você estiver usando 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 do 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 problema. A chave é publicar todo o erro de rastreamento de pilha do ASP.NET, se aplicável, em vez de dizer "Estou recebendo um erro de Acesso Negado ao tentar executar meu aplicativo ASP.NET." Alguém pode ajudar?" É mais fácil para alguém olhar para o rastro da pilha e dar orientações quando pode 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 gerada pelo Microsoft .NET Framework, ignore esta seção. Se o aplicativo mascarar a mensagem de erro real e 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 é de muita utilidade 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 ir para 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.

Dica

Você pode entrar em contato com seu desenvolvedor para descobrir como ver a mensagem de erro real. É possível que seu desenvolvedor esteja registrando-o em um arquivo ou recebendo notificações por email. Lembre-se sempre de fazer um backup de qualquer arquivo que você vai alterar. Com um backup disponível, você sempre pode reverter quaisquer alterações.

O problema ocorre devido à falta de permissões 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 , selecione Filtrar e selecione AutoFiltro para usar os recursos de filtragem do Excel. Agora selecione a lista suspensa na coluna F e procure por erros "ACESSO NEGADO".

Um exemplo de saída do FileMon é mostrado 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 nos resultados filtrados, reduzimos a causa do problema. O 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 simples de corrigir.

Dica

Uma boa etapa seria alterar a conta do processo de ASP.NET para uma conta de administrador para ver se isso corrige o problema. No IIS 6.0 e versões posteriores, você alteraria a identidade do IIS AppPool para "Sistema Local" para ver se o aplicativo funciona.

Observação

Isso não deve ser usado como uma solução, mas apenas como uma etapa de solução de problemas.

A maioria das pessoas tenderia a reinstalar o Microsoft .NET Framework ou até mesmo chegar ao ponto de reinstalar o sistema operacional. Esta 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. 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 e o sistema operacional. Isso pareceu resolver o problema por alguns dias, mas depois reapareceu.

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

A chave aqui é para 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á mantendo um bloqueio em um arquivo ou pasta e não permitindo que ASP.NET grave nele. Faz sentido que uma reinicialização esteja matando o outro processo e o aplicativo ASP.NET comece a funcionar novamente até que o processo não autorizado bloqueie o arquivo novamente. A coisa lógica a fazer seria desligar 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 específico de terceiros. Mas, em geral, o software antivírus é conhecido por causar muito sofrimento para os aplicativos IIS e ASP.NET. Outro problema conhecido causado pelo software antivírus é a perda de sessão devido à reciclagem do AppDomain quando a pasta Bin ou os arquivos .config são tocados.

Dica

A maneira mais fácil de desativar os serviços de terceiros é:

  1. Selecione Iniciar, selecione Executar e digite msconfig.
  2. Selecione Serviços e marque Ocultar todos os serviços da Microsoft.
  3. Selecione Desabilitar Tudo para interromper os serviços de terceiros.
  4. Selecione Iniciar, selecione Executar e digite iisreset para recarregar o CLR no processo de trabalho.

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

Observação

Se o mesmo erro for reproduzível 100% das vezes, seu software antivírus pode não ser a causa. Pode haver outras causas para esse erro. Tente criar um aplicativo de teste de ASP.NET simples para isolar se o mesmo erro ocorre para uma página Test.aspx. Em caso afirmativo, verifique se as ACLs (Listas de Controle de Acesso) necessárias estão todas em vigor para ASP.NET.

Consulte as Listas de Controle de Acesso (ACLs) Necessárias do ASP.NET.

Dica

A %SystemRoot%\Assembly pasta é o cache de assemblies global. Você não pode usar diretamente o Windows Explorer para editar ACLs para esta pasta.

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 conceder permissões por meio da GUI:

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

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

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

O problema ocorre devido à falta de permissões 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 de Nomenclatura Universal), há muitas coisas que podem dar errado. Além disso, muitas coisas podem estar configuradas incorretamente no recurso remoto. Você precisa solucionar esses problemas para que o recurso funcione.

Seu primeiro passo seria ver se você pode se conectar ao servidor remoto por meio do Windows Explorer.

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

  2. No servidor do IIS, faça logon com seu domínio/conta, selecione Iniciar, selecione 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. Só então seu 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. Certifique-se de modificar <RemoteServerName> na seguinte linha de código

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

    Para que reflita o nome do seu servidor remoto.

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

  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 em um navegador cliente do Internet Explorer, mas funcionar se você acessar a mesma página diretamente no servidor IIS, é provável que você esteja enfrentando um cenário de "Salto Duplo". Se você estiver usando Web Parts personalizadas para acessar recursos remotos que exigem autenticação e autorização do usuário, você provavelmente enfrentará o problema de "Salto Duplo". 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, consulte Solucionar problemas de falhas do Kerberos no Internet Explorer.

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

Dica

Se você puder se conectar ao compartilhamento UNC remoto, mas não puder se conectar ao servidor remoto que está executando o SQL Server a partir do aplicativo ASP.NET, talvez seja necessário verificar ou definir os SPNs (Nomes da Entidade de Serviço) para o SQL Server. Tente habilitar apenas a Autenticação Básica para seu aplicativo no IIS e veja se você é capaz de se conectar ao servidor remoto que está executando o SQL Server.

Existem várias outras causas para a mensagem de erro "Aplicativo de servidor indisponível". O registro de eventos é sua melhor aposta para obter mais detalhes sobre a causa do seu problema.

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 de status e substatus 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 se as permissões estiverem corretas para o arquivo que você está tentando acessar, mas as permissões padrão e os direitos de 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.

Dica

Selecione Iniciar, selecione Executar e digite logfiles para abrir a pasta que contém os logs do IIS. Como alternativa, na página de propriedades do site no IIS, selecione a guia WebSiteName e, em formato de log ativo, selecione Propriedades para ver o diretório e o nome do arquivo de log.

A outra coisa de interesse aqui é o código de status 5. Você pode usar o comando net helpmsg para obter mais informações sobre esse código de 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 terá suporte.

Dica

Sempre que você receber outra mensagem genérica e infame de "500 Internal Server Error", é uma boa ideia desabilitar mensagens de erro HTTP amigáveis, para que você receba uma descrição detalhada do erro. Não se esqueça de olhar no visualizador de eventos, pois ele também pode conter mais informações.

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: