Processo e identidade de solicitação no ASP.NET

Este artigo descreve os direitos de acesso concedidos à conta do processo padrão e descreve algumas situações em que eles podem ser extremamente restritivos a determinadas tarefas.

Na instalação padrão no Microsoft Windows 2000 e no Microsoft Windows XP, o ASP.NET executa um código de aplicativo Web em um processo de operador. Por padrão, a identidade desse processo usa uma conta local chamada ASPNET (cujo nome completo é aspnet_wp). Nas versões beta do ASP.NET, a identidade do processo é System, uma ferramenta administrativa extremamente poderosa que possui muitos direitos de acesso no computador. Para conseguir uma instalação padrão com menos privilégios, a versão final do ASP.NET usa a conta ASPNET mais fraca, mais indicada para a maioria dos aplicativos Web.

Observação Por padrão, se você estiver usando os Serviços de informações de Internet (IIS) 6.0 da Microsoft, os aplicativos da Web ASP.NET serão executados no contexto de segurança da conta NetworkService.

Configurar a identidade do processo

É possível configurar a identidade do processo na seção <processModel> do arquivo Machine.config no subdiretório Config do diretório raiz de instalação. Os atributos userName e password controlam a identidade do processo. Os valores padrão desses atributos são: Os valores machine e AutoGenerate instruem os ASP.NET a usar a conta ASPNET incorporada e uma senha aleatória, com boa criptografia, armazenada na Autoridade de segurança local (LSA) para essa conta.

Caso queira usar um processo com mais direitos de acesso, você pode definir o atributo userName para System, o que faz o processo do operador do ASP.NET ser executado com a mesma identidade do processo Inetinfo.exe. Por padrão, o processo Inetinfo.exe é executado como a identidade System. Ao configurar o processo do operador ASP.NET para usar a identidade System, ele pode acessar grande parte dos recursos do computador local. Em computadores executando o Windows 2000 ou o Windows XP, a conta System também possui credenciais de rede e pode acessar recursos de rede como a máquina local. Para configurar o processo para ser executado como a identidade System, altere o atributo userName na seção <processModel> da seguinte forma:

Permissões padrão para a conta ASPNET

A conta ASPNET é criada como uma conta local durante a instalação do ASP.NET. Ela pertence apenas ao grupo Usuários do computador em questão. Por isso, ela possui todos os direitos ligados a esse grupo, podendo acessar todos os recursos aos quais ele tem acesso. A conta ASPNET herda os seguintes direitos de usuário do grupo Usuários:

• SeChangeNotifyPrivilege
• SeUndockPrivilege
• SeInteractiveLogonRight
• SeNetworkLogonRight

Além desses, a conta também recebe os seguintes direitos por padrão:

• SeServiceLogonRight
• SeBatchLogonRight
• SeDenyInteractiveLogonRight

O ASP.NET concede permissões de acesso completo específicas para a conta ASPNET nas seguintes pastas:

• Arquivos temporários ASP.NET
• %windir%\temp

Além disso, o ASP.NET concede a permissão de leitura para o diretório de instalação do Microsoft .NET Framework.

A seguinte lista resume as ACLs (listas de controle de acesso) necessárias à conta ASPNET. As instalações padrão do Windows 2000 e do Microsoft .NET Framework possuem essas ACLs.

• Local: %installroot%\ASP.NET Temporary Files
  Tipo de acesso: Leitura/gravação na pasta e Listar conteúdo de pasta na pasta raiz da unidade
  Conta: Contas do processo de representação configuradas
  Descrição: O local para a compilação dinâmica do ASP.NET. Sob este local, é gerado um código de aplicativo em um diretório para cada aplicativo. É possível usar o atributo tempDir na seção <compilation> para configurar o local raiz.
  
  Observação Caso machine.config seja alterado para salvar os arquivos temporários do ASP.NET em um local diferente, a conta ASPNET deve ter o tipos de acesso Listar conteúdo de pasta na raiz da unidade.
• Local: %windir%\temp
  Tipo de acesso: Leitura/gravação
  Conta: Conta de processo
  Descrição: O local usado pelos serviços Web de XML para gerar proxies em série.
• Local: Diretório do aplicativo
  Tipo de acesso: Leitura
  Conta: Contas do processo de representação configuradas
  Descrição: O local para o conteúdo do aplicativo (necessário apenas acesso de leitura).
  Para obter informações adicionais, consulte o seguinte site da Microsoft (em inglês):
  http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp (http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp)
• Local: Raiz do site na Web (%systemdrive%\inetpub\wwwroot ou o caminho indicado pelo site padrão)
  Tipo de acesso: Leitura
  Conta: Contas do processo de representação configuradas
  Descrição: O ASP.NET tenta ler os arquivos de configuração e acompanhar as alterações na unidade:\inetpub\wwwroot\web.config.
• Local: %installroot% hierarchy
  Tipo de acesso: Leitura
  Conta: Contas do processo e de representação configurada
  Descrição: ASP.NET deve conseguir acessar conjuntos do .NET Framework no arquivo Machine.config (no \subdiretório Config em %installroot%).
• Local: %windir%\assembly
  Tipo de acesso: Leitura
  Conta: Contas do processo de representação configuradas
  Descrição: Cache global de conjuntos que contém os conjuntos compartilhados.

Para obter informações adicionais sobre os ACLs padrão em computadores com o Windows 2000, consulte "Configurações de controle de acesso no Windows 2000" na seção REFERÊNCIAS.

Observação Por padrão, a conta ASPNET normalmente não tem os direitos de acesso apropriados para realizar algumas das tarefas descritas nesse artigo.

Acessando os recursos

As seções a seguir descrevem como usar diversos recursos. É possível acessar muitos deles localmente, caso a representação esteja ativada e a conta representada tenha acesso ao recurso. Porém, a representação costuma não funcionar quando se tenta acessar recursos remotos, a menos que o aplicativo use um mecanismo de autenticação que possa ser delegado, como as autenticações Kerberos ou Básica. Também é possível usar serviços COM+ para acessar recursos, o que está descrito na seção Como executar o código com uma identidade fixa.

Como usar os recursos de arquivo

Para permitir que um aplicativo executando a conta ASPNET grave nos arquivos, é possível representar um usuário específico no código antes de gravar nos arquivos ou é possível conceder permissões de gravação à conta ASPNET. É possível conceder permissões de gravação para um arquivo específico ou para hierarquias de diretório.

Importante Ao conceder permissões de gravação para um arquivo específico ou para hierarquias de diretório à conta ASPNET, todos os aplicativos da Web ASP.NET executando em uma conta ASPNET no servidor também são capazes de gravar nesse arquivo ou nas hierarquias de diretório. Para obter informações adicionais sobre como representar um usuário específico no código , clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft: Para alterar a lista de controle de acesso para um arquivo, execute as seguintes etapas:

1. Abra o Windows Explorer.
2. Selecione o arquivo ou pasta cujas permissões deseja alterar.
3. No menu Arquivo, clique em Propriedades.
4. Clique na guia Segurança. Marque a caixa de seleção correspondente às permissões ACL.

Também é possível usar um script ou a ferramenta de linha de comando Cacls.exe (que acompanha o Windows) para alterar a ACL para um arquivo.

ASP.NET 1.1 usa a pasta <Nome da unidade>\Documents and Settings\<Nome do computador>\ASPNET para armazenar os arquivos de processo (em que <Nome da unidade> é a unidade no computador na qual o ASP.NET está instalado e <Nome do computador> é o nome do computador).

Ativando a representação

Com a representação, a entidade de solicitação é executada no contexto de segurança, como usuário autenticado ou como usuário anônimo. No ASP.NET, a representação é opcional, não estando ativada por padrão. Para ativar a representação no nível do computador ou aplicativo, adicione a seguinte diretiva de configuração na seção <system.web> dos arquivos Machine.config ou Web.config:

Como usar os bancos de dados

Aplicativos que usam a autenticação SQL para se conectar a um banco de dados não costumam ser afetados pela alternância da conta ASPNET. Isso também acontece com os aplicativos que usam a autenticação e a representação integradas. Porém, se um aplicativo não estiver sendo representado e estiver usando uma autenticação Windows, será necessário conceder o acesso ao banco de dados para a conta ASPNET.

Não é possível usar essa conta durante a tentativa de autenticação para o Microsoft SQL Server, usando a autenticação integrada do Windows em pipes nomeados. No entanto, é possível usar a conta ASPNET com a autenticação integrada do Windows por meio do transporte TCP.

Caso um aplicativo precise usar um banco de dados do Microsoft Access, a conta ASPNET deve ter permissão para gravar nesse arquivo de banco de dados. Os administradores precisam ajustar as permissões de acordo.

Como usar o log de eventos

Aplicativos que precisam gravar no log de eventos podem fazer isso ao mesmo tempo em que são executados com a conta ASPNET. Caso precise criar uma nova categoria de log de eventos, um aplicativo deve criar uma chave do Registro na seção HKEY_LOCAL_MACHINE, pois a conta ASPNET não é capaz de fazê-lo.

Para criar a categoria durante o tempo de execução, é necessário ativar a representação e, em seguida, representar uma conta com mais direitos de acesso. Um administrador também pode criar a categoria e o aplicativo é capaz de gravar na categoria durante a execução.

Se os aplicativos precisarem criar novas categorias de log de eventos, crie-as durante a instalação. Após a sua criação, a conta ASPNET é capaz de gravar no log de eventos do aplicativo.

Usando os serviços de diretório e o Active Directory do sistema

Se um aplicativo da Web precisar de acesso ao Active Directory, ele pode usar a representação em um ambiente que dê suporte à delegação. Como alternativa, o aplicativo também pode fornecer credenciais explícitas para o construtor DirectoryEntry no espaço para nome System. DirectoryServices, para poder acessar o Active Directory. Se o aplicativo usar credenciais explícitas, os aplicativos deverão armazená-las corretamente, usando uma técnica como a das seqüências de caracteres de construção COM+ ou APIs de proteção de dados do Windows.

Usando os contadores de desempenho

A conta ASPNET possui permissão suficiente para gravar (mas não para ler) dados do contador de desempenho. Caso o aplicativo precise ler esses dados ou criar categorias para o contador de desempenho, as permissões Administrador ou Usuário avançado serão necessárias

Se os aplicativos precisarem criar novas categorias para o contador de desempenho, crie-as durante a instalação. Após a sua criação, a conta ASPNET será capaz de gravar nos contadores.

Também é possível usar a ferramenta Monitor de desempenho (Perfmon.exe) para acompanhar os contadores de desempenho com a conta ASPNET.

No Windows 2000, execute as seguintes etapas:

1. Execute o Editor do Registro.
2. Localize a seguinte chave do Registro:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
3. Clique na guia Segurança.
4. Adicione à identidade do processo de operador as seguintes permissões:
   • Valor de consulta
   • Valor definido
   • Criar subchave
   • Enumerar subchaves
   • Notificação de controle de leitura

No Windows Server 2003, adicione a identidade ao grupo IIS_WPG.

Iniciando servidores COM fora do processo

Aplicativos que precisam iniciar servidores COM fora do processo durante a execução da conta ASPNET podem especificamente conceder permissões de inicialização para a conta, usando a ferramenta Dcomcnfg.exe.

Problemas de depuração

Por padrão, não é possível fazer uma chamada de serviço Web XML a partir de um aplicativo cliente. Para isso, é necessário adicionar a conta ASPNET ao grupo Usuários depuradores no computador no qual o serviço está sendo executado.

Executando o código com uma identidade fixa

Em serviços COM+, é possível executar códigos com uma identidade fixa. É possível usar a classe ServicedComponent do espaço para nome System.EnterpriseServices com o objetivo de gravar componentes de código gerenciados que usam serviços COM+. É possível reunir a funcionalidade privilegiada em uma classe derivada de ServicedComponent e executar essa classe como um aplicativo de servidor COM+ com uma identidade configurada.

Compilando os arquivos em código em compartilhamentos UNC

No ASP.NET, é possível usar diversos métodos para desenvolver arquivos de aplicativos:

• É possível usar o HTML em um arquivo .aspx e armazenar o código da página em um conjunto previamente compilado no diretório Bin. Esse é o modelo do Microsoft Visual Studio .NET.
• Você pode reunir todo o código e o conteúdo HTML em um único arquivo de origem compilado por demanda.
• É possível colocar a apresentação em HTML em um arquivo do ASP.NET e compilar, de forma dinâmica, todos os códigos-fonte correspondentes ao arquivo, usando um atributo src na diretiva <%@ Assembly %>.

Observação Se o conteúdo do aplicativo estiver em um compartilhamento de rede, o compilador começará na conta ASPNET, que não possui credenciais de rede para acessar o arquivo. Caso use compartilhamentos de rede, não será possível usar o atributo src para indicar um arquivo. É necessário usar um dos outros métodos.

Usando o ASP.NET em controladores de domínio primário ou de backup

Por padrão, se você estiver usando o ASP.NET 1.1 em um controlador de domínio, os aplicativos da Web ASP.NET serão executados no contexto de segurança da conta IWAM_<Nome do computador> (no qual <Nome do computador> é o nome do computador).

Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft: voltar ao início

Lendo a metabase do IIS

A conta ASPNET não pode ler a metabase do IIS. Se um aplicativo precisar acessar as configurações da metabase, é possível conceder acesso de leitura a alguns nós dela, usando o utilitário Metaacl.exe

Caso um aplicativo precise usar os arquivos .disco, que dependem da capacidade de leitura da metabase do ISS para fornecer serviços de diretório, será preciso conceder acesso de leitura da metabase para a conta ASPNET.

Usando o gerenciamento do sistema e WMI

O WMI (Windows Management Instrumentation) é um recurso administrativo extremamente eficaz que lhe permite gerenciar e acompanhar computadores com o Windows. No entanto, quando os aplicativos ASP.NET são executados na conta ASPNET, ela possui apenas as mesmas permissões padrão de Todos. Entre essas permissões estão a leitura de dados WMI, a gravação de dados do provedor e a execução de métodos do provedor no computador local. Informações adicionais sobre os mecanismos de segurança da WMI podem ser obtidas na documentação SDK da WMI ou na MSDN.

Observação No Windows 2000 sem o SP3 (Service Pack 3) ou mais recente ou no Windows XP sem SP1 (Service Pack 1)ou mais recente, aplicativos da Web do ASP.NET executados na conta ASPNET podem não funcionar e uma mensagem de erro "Acesso negado (0x80041003)" é exibida. Isso acontece porque a conta não possui privilégios suficientes para acessar determinados espaços para nome da WMI. Para resolver esse problema, instale o Windows XP SP1 (ou mais recente) ou o Windows 2000 SP3 (ou mais recente). Para solucionar o problema, execute as seguintes etapas:

1. Abra o snap-in Console de gerenciamento da Microsoft (MMC) do Gerenciamento do computador.
2. Expanda Serviços e aplicativos e selecione Controle WMI.
3. Clique com o botão direito do mouse em Controle WMI e clique em Propriedades.
4. Na caixa de diálogo Propriedades de controle WMI, clique na guia Segurança.
5. Expanda Root, selecione CIMV2 e clique em Segurança.
6. Na caixa de diálogo Segurança, clique em Avançado.
7. Na caixa de diálogo Configurações de segurança avançadas, clique em Adicionar. Selecione Nome_do_computador_local\ASPNET e clique em OK.
8. Na caixa de diálogo Entrada de permissão, veja se Aplicar em está definido para Este espaço para nome e subespaços para nome.
9. Verifique se as caixas de seleção Permitir "Ativar conta" e Permitir "Ativação remota" estão selecionadas.
10. Clique em OK nas caixas de diálogo até voltar para a caixa Propriedades do controle WMI.
11. Repita as etapas de 5 a 10 para os outros espaços para nome da WMI a serem acessados pelo aplicativo.
12. Reinicie o IIS. Para isso, execute IISRESET na linha de comando.

Por padrão, o ASP.NET gera uma senha com boa criptografia para a conta ASPNET. Por isso, essa solução é segura, uma vez que a senha dessa conta não é compartilhada entre computadores ou é redefinida para um valor que não seja o padrão.

Interagindo com a Área de trabalho

Quando os serviços do IIS são configurados para permitir a interação com a Área de trabalho, a conta ASPNET não precisa dos direitos apropriados para acessá-la, devido às DACLs (Discretionary Access Control Lists) na estação da janela padrão e na Área de trabalho. Os administradores podem alterar essas listas ou é possível executar o processo com uma conta que permita acessar esses objetos.

Removendo o ASP.NET

Ao remover o ASP.NET, a conta ASPNET é desativada e permanece no sistema. A conta ASPNET pode ser excluída, caso não haja intenção de reinstalar o ASP.NET.

Se o ASP.NET for reinstalado após a exclusão explícita da conta, será criada uma nova conta ASPNET com um novo SID (identificador de segurança). Dessa forma, todas as ACLs referentes à conta ASPNET anterior não se aplicam à nova conta.

Para obter informações adicionais sobre as Listas de controle de acesso padrão no Windows 2000, consulte o seguinte documento da Microsoft (em inglês): Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft: